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=<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做出的配置。
文章来源:https://www.toymoban.com/news/detail-634020.html
文章来源地址https://www.toymoban.com/news/detail-634020.html
到了这里,关于UVM重点归纳(一)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!