uvm 形式验证_UVM 实战 第二章总结 一个简单的UVM验证平台

一个简单的UVM验证平台

1：面向对象的编程语言的特性：封装(变量和methods在一个类里)，继承(派生，子类拥有父类所有特性)和多态(调用同一个函数但最终状态不一样(必须是virtual methods))。

2：UVM是一个库，在这个库中，几乎所有的东西都是由类(class)来实现的。

3：当实现一个功能时，首先要想到的是从UVM的某个类派生出一个新的类，在这个新的类中实现所期望的功能。所以使用UVM的第一条原则是：验证平台的所有的组件应该派生自UVM中的类。

4：factory机制会自动实例化并按照顺序执行所有phase。所以所有派生自uvm_component及其派生的类都应该使用uvm_component_utils宏注册。

5：UVM中通过objection机制来控制验证平台的关闭。在每个phase中，UVM会检查是否有objection被提起(raise_objection)，如果有，那么就待这个objection被撤销(drop_objection)后停止仿真，如果没有，则马上结束当前phase。

6：raise_objection语句必须在main_phase中第一个消耗仿真时间的语句之前。

7：绝对路径的使用大大减弱了验证平台的可移植性，因此，从根本上来说，应该尽量杜绝在验证平台中使用绝对路径，避免使用绝对路径有两种方法，一，使用宏(不推荐)，二，使用interface(推荐)。

8：在类中使用的是virtual interface。但是UVM通过run_test语句实例化了一个脱离了top_tb层次结构的实例(uvm_test_top)，建立了一个新的层次结构，所以UVM引进了config_db机制，用于interface和class之间的通信。

9：super.build_phase语句用于执行父类的build_phase中的一些必要操作。所以必须显式的调用它。

10：build_phase和main_phase不同的一点在于，build_phase是一个函数phase，而main_phase是一个任务phase，build_phase不消耗仿真时间，build_phase总在仿真时间为0时执行。

11：config_db的set和get都有四个参数，前两个参数表示寄信收信的地址，第三个参数用于确认身份，即寄信和收信的第三个参数必须完全相同，第四个参数表示寄信或收信的实体。

12：无论传递给run_test的参数是什么，创建实例的名字都为uvm_test_top。

13：使用双冒号访问的函数都是静态函数。

14：验证平台各个组件之间，传递的信息都是基于transaction的。这是一个抽象的概念，可以简单理解成包。

15：transaction的基类是uvm_sequence_item，在UVM中所有的transaction都要从它这里派生，也只有从uvm_sequence_item中派生的transaction才可以使用sequence机制。

16：uvm_env 是一个容器类，在这个容器类中实例化driver，monitor，reference model和scoreboard等。

17：实例化一个class有两种方式，一种是直接调用new函数，一种是使用factory提供的实例化方式type_name::type_id::create(name,parent)的方式，验证平台中的组件都应该使用第二种方式实例化。

18：build_phase的执行顺序是由树根到树叶，因为build_phase主要完成各个组件的实例化，实例化的时候要指定parent参数，如果从树叶到树根执行会导致parent参数无法指定。

19：除build_phase以外的phase都是由树叶到树根的顺序执行，像connect_phase，如果从树根到树叶的顺序执行(端口的实体有时在monitor或者driver上，agent上通常只是一个指针)，这时在model连接agent端口的时候就会报空指针错误。

20：验证平台中实现监测DUT行为的组件是monitor。

21：driver和monitor的代码很相似，其本质是因为二者处理的是同一种协议，所以UVM通常将二者封装在一起，成为一个agent。因此，不同的agent就代表了不同的协议。

22：只有uvm_component才能作为树的结点，像transaction这种使用uvm_object_utils宏实现的类是不能作为UVM树结点的。

23：UVM数最晚在build_phase时段完成，但约定成俗仅在build_phase中完成实例化。

24：reference model用于完成和DUT相同的功能(一般用高级语言处理)。

25：将transaction通过端口发送出去使用write函数，这是一个uvm_analyse_port的内建函数。

26：connect_phase用于各组件之间的连接，在build_phase执行完后马上执行。

27：field_automation机制可以简化验证平台的的搭建，提高效率。transaction中的成员变量使用uvm_field注册后，可以直接使用copy，compare，print等函数，无需自己定义。

28：pack_bytes()和unpack_bytes()函数用于打包byte流和解包byte流，但函数的参数必须是一个动态数组，解包时要指定其大小才能正常工作。

29：sequence机制用于产生激励，它是UVM中最重要的机制之一。

30：在使用sequence时要引入sequencer。sequence就像是一个弹夹，里面的子弹是transaction，而sequencer是一把枪，弹夹只有放入枪中才有意义，枪只有在放入弹夹后才能发挥威力。

31：每一个sequence都应该派生自uvm_sequence，并且在定义时指定要产生的transaction类型。每一个sequence都有一个body任务，当一个sequence启动之后被自动执行body的代码。

32：uvm_do宏是UVM中最常用的宏之一，它用于创建transaction的实例化并将其随机化，最终将其送给sequencer。

33：sequencer主要做两件事情，一，检测仲裁队列中是否有某个sequence发送来的transaction的请求。二，检测driver是否申请transaction。这样就会出现有sequence发送但没有driver申请transaction，有driver申请但没有sequence发送transaction和刚好sequence发送刚好driver请求transaction的三种情况。

34：sequencer和driver通过内建的端口连接，driver通过get_next_item任务向sequencer申请transaction。

35：uvm_do产生一个transaction并交给sequencer后不会立即执行下一次uvm_do宏，而是等待在那里，直到driver返回item_done信号，此时，uvm_do宏才算执行完毕，返回后开始执行下一个uvm_do，并产生新的transaction。

36：sequence可以使用start任务手动启动，seq.start(i_agt.sqr);start任务的参数是sequencer指针，如果不指明此指针，则sequence不知道将产生的transaction交给哪个sequencer。在UVM中，objection一般伴随着sequence，通常只在sequence出现的地方才会提起和撤销objection。

37：sequence大多数情况是使用default_sequence的形式启动，uvm_sequence的基类中有一个变量名为start_phase，类型为uvm_phase的变量。在sequencer启动default_sequence时会自动将phase赋给starting_phase，因此，可以在sequence中使用starting_phase进行提起和撤销objection，从而，objection完全与sequence关联在了一起，在其他任何地方都不必再设置objection。

38：真正的测试用例都是基于base_test派生的一个类。在base_test里一般完成实例化env，log的打印，设置超时退出等等。

39：UVM中的测试用例的启动可以使用run_test(“test_case_name”)；的方式启动(很少用)，也可以使用run_test() 即不指定具体的test case然后再仿真命令行使用+UVM_TESTNAME=my_case_name的方式来启动测试用例(比较常用)；

40：通常UVM启动和执行的流程为：

module top_tb ->全局的run_test() ->启动验证平台->根据UVM_TESTNAME产生具体的test case的实例 ->依次执行build_phase 形成UVM树 ->顺序执行UVM树各结点的connect_phase，main_phase等-> 所有phase执行完毕，结束仿真。UVM 树