UVM学习笔记(1) 初识UVM框架

         上一篇文章发出去，才发现排版好丑，发现排版确实很影响人的胃口，不过是技术笔记类的文章，不做纠结了，以后写文章再不废话了

         ============================= 割==============================

    验证基础

         真是不想多废话，选了个标题都弄了10分钟，格式好费时间，又废话了。

         我接触验证的时间和我上班的时间一样，到目前为止，马上到三年了，验证给我最初的印象就是帮别人测试东西的，非常没有技术含量，简直可以说是擦屁股的，做好了，和我没关系，我漏了bug，都是我的锅，哪有这么坑的工作让我做。我入门第一天，我师父问我，你想做设计还是想做验证呢，我说设计啊，多有创意，我师父说，啊，设计的名额已经满了，我是做验证的，所以你也来做验证吧，我屮艸芔茻，心中一万只草泥马奔过，你都定了还问个毛线啊，咋办，那就验呗。咋验？不会，是不是要被开除了，可能吧

                         

           

         一个简单的验证平台。大概就是这样的。一个人发号施令，翻译成中国话和英文，分别送给不同的人，自己消化了再拿出来比对一下到底是不是一样的，咦，怎么有点恶心

        

         好吧，我还是简单的陈述一下什么是验证，什么是我所认为的验证：以高级语言为参考模型，对verilog构建的时序模块进行检查、比对、校验的一种质量保证活动。高级语言，说白了就是C++一类，可以面向对象又或者比较容易实现数据结构的语言类型，听说有人拿Perl、makefile写验证环境，真是个变态。验证的基本框架就是上图所示，至于各个芯片的情况不同，验证环境的结构多少是有些变化的，比如我现在的B模块，是个数据环，比对完了还不行，还要拿出来继续用，还要送回到RM，构成了一个数据环，因此，验证环境并不是一成不变的，而是可以进行多种多样的优化，我们不以写得漂亮为目的，也不是以找了多少bug为目的，以保证芯片代码最后没有问题为目的，发现了1000个bug又能怎么样呢，最后漏一个，就是实打实的一个，管你发现了多少，该废还是要废，你可以按部就班的梳理测试点，也可以鸟枪法，总之bug到处都是，然而能做的完美的却又没有多少个。

         跑题了，写着写着就像吐槽，单纯的做个技术狗还真不容易，好了，验证的基础其实需要在实践中慢慢体会，是一种比较死板又可灵活的套路，不会一成不变，接下来，我们就该请出主角，UVM，来初步认识一下什么是个UVM。

  UVM基础

UVM的全程为，Universal Verification Methodology，意为通用验证方法学，前身是OVM，貌似是mentor弄的一套东西，本质上，验证方法学只是对systemverilog进行一些常用类的封装，按照一套统一的流程，进行验证活动，经过多次对比之后，发现方法学只是各个验证公司间博弈的产物，eetop上有人说过真正牛逼的验证应该是自己有一套合适的验证方法，鉴于他的名字已经叫“通用”了，所以应该对各个验证结构来说是比较通用的。

UVM_PHASE

UVM的流程核心是phase，phase的中文意思是相，跟VMM1.1的九步法比起来，是要繁琐很多，但是用起来才发现这些隔离的phase是非常方便对于仿真的精确控制的，粗略来说，分为头4、尾4共8个function类型的phase，只干事，不消耗时间，中间有一个run_phase还有个4x3个小phase，run_phase和这12个phase是并行的，只是run_phase自己独成一派，而其他的12个就要乖乖的顺序执行了，用一些伪代码来表示这个过程更加明确一些

fork
    begin
        run_phase();
    end
    begin
        phase1();
        phase2();
        ……
        phase12();
    end
join_none

核心流程对于理解各个组件之间的仿真顺序至关重要，现在我们知道了phase这个玩意儿，就要说说UVM中包含的验证组件了，其实还有更重要的一个机制对于phase的控制非常精细，这个就是uvm_objection，不过这个在这里讲的话可能没什么概念，后面我们再说

UVM_OBJECT

在我一开始搭建demo的过程中，遇到了如下组件，是非常常见

agent、driver、monitor、sequencer、sequence、rm、checker、scoreboard

其实这些组件与VMM所构建的验证环境大同小异，而这些组件的老家全都是uvm_object，作为一个对象存在，何为object？我个人理解为一个事实存在的实体，一个对象，这个object可能会随着时间的推进，消失或者重建，更类似于指针使用过程中的instance，刚刚接触UVM的人可能都把这个和uvm_component分不清楚，至少我是这样的，uvm的书中大多有基类继承关系的介绍，而component是object的娃，于是在各个组件的使用过程中，可以有如下体会： component伴随仿真的生命周期存在，而object是根据使用需要来决定是否存在，暂且这么理解，在我搭建环境的时候，在一个叫config聚合类的东西里继承于Object，就是一个集中从cmdline中获取config value的cfg类，这个继承于uvm_object，说来也比较合理，cfg的配置变量在使用的时候才会被实例化，这里顺带要提到一个要注意的地方，就是uvm_config_db#set(……)的使用，uvm_object在环境中是没有一席之地的，也就是说，我不能通过env.xxx.xxx.xx来索引到一个object组件，他不能成为环境中的一份子，所以，我们如果想对某个object中的某个变量进行set的话，就要对这个object整体进行set，uvm_object可玩性不高，因为他是一个非常基本的类，所以他的子孙非常多，但是自己的可玩性比较低，感觉就跟我们本科生上班一样，说是可塑性高，实际上就是说你啥都不会，哈哈。或许我对uvm_object的见解比较低，这个我们就暂且先聊这么多。