UVM重点归纳(一）

1 factory 机制

1.1 利用工厂机制的一般实现步骤：

1.继承

范式：

class comp_type/obj_type extends uvm_component/uvm_object;

实例：

class comp1/obj1 extends uvm_component/uvm_object;

2.注册

范式：

​​​​​​​`uvm_component/object_utils(comp_type/obj_type);

实例：

`uvm_component/object_untils(comp1/obj1);

3.new函数声明

范式：

function new (string name="comp1/obj1",uvm_compinent parent=null(obj1无此项));

实例：

function new (string name="comp1/obj1",uvm_compinent parent=null(obj1无此项));

4.实例化

范式：

comp_type/obj_type 实例名

实例：comp1 c1,c2;

           obji o1,o2;

5.覆盖

范式：

类型覆盖：orig_type::type_id::set_type_override(new_type::get_type());

实例覆盖：orig_type::type_id::set_inst_override(neew_type::get_type(),"orig_inst_path");

​​​​​​​实例：

类型覆盖：comp1::type_id::set_type_override(comp2::get_type());

实例覆盖：obj1::type_id::set_type_override(obj2::get_type(),"");

6.创建

范式：

comp_type::type_id::create(string name, uvm_component parent);

           obj_type::type_id::create(string name);

实例：

c1=comp1::type_id::create("c1",null);

o1=obj1::type::id::create("o1");​​​​​​​

一些细节：

1. 在uvm中的创建一定使用以上范式，尽管使用new函数也可以实现，但是会使后边很多工厂自带的方法失效；

2.覆盖一定在创建之前；

3.特别注意覆盖中返回的句柄，有时需要根据实际情况进行cast转换；

了解更多关于工厂机制的内容请点击下边链接：

工厂机制&覆盖方法https://blog.csdn.net/weixin_45680021/article/details/124256876​​​​​​​

1.2 uvm_coreservice_t 类 

​​​​​​​factory 机制并不是object类型也不是component 类型，它存在于uvm_coreservice_t类中；uvm_coreservice_t在仿真开始时例化（run 0 时刻），用户无需额为例化；另外以上关于工厂机制的覆盖，创建也可以通过直接使用factory的方法实现；

uvm_coreservice_t 主要包括：

1. 唯一的uvm_factory，该组件用来注册，覆盖和例化；

2.全局的report_server，该组件用来做消息统筹和报告；

3.全局的tr_database，该组件用来用来记录transaction，便于后续调试；

4.get_root()方法用来返回当前uvm环境的结构顶层对象；

1.3 域的自动化​​​​​​​ 

范式：

`uvm_(object/component)_utils_begin(object_type/component_type)

`uvm_field_{int,enum,real,object,string,event,array_int}(ARG,FLAG);

ARG:表示成员变量；

FLAG：标记的数据操作（UVM_ALL_ON/ UVM_COPY)；

`uvm_(object/component)_utils_end

实例：

`uvm_component_utils_begin(com1)

`uvm_field_int(volume,UVM_ALL_ON)

`uvm_field_enum(color_t,color,UVM_ALL_ON)

`uvm_field_string(name,UVM_ALL_ON)

`uvm_component_utils_end

 域的自动化是uvm环境搭建中重要的一部分，可以减少验证人员的工作量，大大解放验证人员的双手，详细了解此部分内容请点击以下链接：

核心基类方法@域的自动化https://blog.csdn.net/weixin_45680021/article/details/124285897

2. phase 机制

phase机制，phase机制主要是使得UVM的运行仿真层次化，使得各种例化先后次序正确。SV 中可以通过构建函数来实现对象的例化，但是只通过new函数无法实现层次化；在UVM 中，phase机制的出现正好解决了这个问题，而且层次化的构建是在例化之前就已经确定的。

UVM 的 phase机制主要有9个，外加12个小phase。主要的 phase有 build phase、connect phase、run phase、report phase、final phase等，其中除了run phase是 task，其余都是function，然后build phase和 final phase都是自顶向下运行,其余都是自底向上运行。Run phase和12个小phase( reset phase、configure phase、main phase、shutdown phase）是并行运行的，有这12个小phase主要是进一步将run phase 中的事务划分到不同的phase进行，简化代码。注意，run phase和 12个小phase最好不要同时使用。从运行上来看，9个phase顺序执行，不同组件中的同一个phase执行有顺序，build phase为自顶向下，只有同一个phase全部执行完毕才会执行下一个phase。

run_phase 和 main_phase 的区别：

run_phase和main phase（动态运行）都是task phase，且是并行运行的，后者称为动态运行(run-time)的phase。如果想执行一些耗费时间的代码，那么要在此phase下任意一个component中至少提起一次objection，这个结论只适用于12个run-time的phase。对于run_phase则不适用，由于run_phase与动态运行的phase是并行运行的，如果12个动态运行的phase有objection被提起，那么run_phase根本不需要raise_objection就可以自动执行。

phase机制时序图： 

UVM仿真的开始：

在顶层环境中调用全局函数run_test()，验证人员可以考虑在调用时传递test名称，也可以不传递，而选择在仿真时通过传递参数+UVM_TESTNAME=来选择test。

uvm_root:

run_test()的方法是由uvm_root提供的，uvm_root作为UVM唯一的顶层类，其继承于uvm_

component，注意在uvm环境中，顶层类有且只有一个。uvm_root的职责是通过创建组件是指定的parent来构成层次，如果parent设置为null,那么他将作为uvm_root 的子组件；调用其方法run_test()将进行如下的初始化：

1.得到正确的test_name；

2.初始化objection机制；

3.创建uvm_test_top实例；

4.调用phase中的控制方法，安排所有组件的执行顺序；

5.等待phase结束，关闭进程；

6.报告总结和结束仿真；

UVM仿真的结束：

结束当真的机制有且只有一种，就是利用objection挂起机制来控制仿真的结束；

run_phase 机制的挂起与落下objection：

raise_objection();

drop_objection();

set_drain_time():设置退出时间

注意：run开始后至少要有一个组件立即挂起objection，否则仿真将会立即退出。

建议：在sequence中使用objection机制，可以在body()的首尾部分挂起的落下objection.

 以上内容只是对phase机制的一个简单介绍，许多细节的内容请点击以下链接：

phase机制https://blog.csdn.net/weixin_45680021/article/details/124295347 

3.config机制

在SV的世界里，只有当所有的环境后才准备好，如果想要在顶层环境对底层环境做配置时，需要通过句柄进行一层一层的传递，这要很不利于软件的封装复用，而且极容易出错；

在uvm中，config机制的出现，彻底改善了以上的弊端，通过uvm_cinfig_db #(T)::set()和uvm_cinfig_db #(T)::get()的配对使用，可以在环境构建前从顶层直接对任意底层进行配置，传递的对象可以是virtual interface，单一变量，对象。

范式：

uvm_config_db #(T)::set(uvm_component cntxt,string inst_name,string field_name,T value);

uvm_config_db #(T)::get(uvm_component cntxt,string inst_name,string field_name,T value)

实例：

uvm_config_db #(virtual intf)::set(uvm_root::get(),"uvm_test_top.c1","vif",intf);

get方法中的前两个参数构成了从顶层到配置层的路径，第三个参数是类中的变量，最后一个参数是传递的数值

uvm_config_db #(virtual intf)::get(this," ","vif",vif);

set方法中的前两个参数一般都是以上形式，因为是当前层，第三个，第四个参数分别表示变量和值；

环境结构层次如下：

使用config机制特别需要注意：

1.set/get的路径一定要一致；

2.传递的参数一定要一致；

3.一定是先set后get； 

关于set/get方法的一些后台操作理解：

1.set的路径和数据实际上被放置到uvm_pkt唯一的全局变量uvm_pkt::uvm::resources中；

uvm_resources是uvm_resource_pool的唯一实例，在该实例中有两个resource数组来存放配置子信息，一个由层次索引，一个由类型索引；

2.get方法被调用后回自动到uvm_resources中按照路径寻找值，如果可以找到，则返回1，找不到返回0；

以上内容只是对config的精简介绍，关于具体用法请点击以下链接：

config机制应用https://blog.csdn.net/weixin_45680021/article/details/124304969

 4.消息机制

一个好的验证环境的搭建离不开信息报告的打印，在UVM中由专门的一套信息机制，提供了一系列丰富的类和方法来生成和过滤消息；

范式：

方法调用：function void uvm_report_info(string id，string message，int verbosity= UVM_LOW,string filename="",int line=0);

宏调用：`uvm_info(ID,MESSAGE,VERBOSITY)

string id:消息ID

string message：消息内容；

int verbosity：冗余度，有UVM_NONE/LOW/MEDIUM/HIGH/FULL/DEBUG

string filename：文件名（不做定义，系统自己打印）

int line: 行号（不做定义，系统自己打印）

一般使用宏定义的方法更加简洁，还有其他的严重级别，比如WARNING/ERROR/FATAL,请对应的处理方式及实现代码演练请参考以下文章：

​​​​​​​消息机制https://blog.csdn.net/weixin_45680021/article/details/124316347

消息管理是由uvm_report_handler类来实现的，而每一个uvm_report_object类中都有一个 uvm_report_handler实例，不管是上边的方法调用还是宏调用，都是针对uvm_report_ handler做出的配置。

​​​​​​​