uvm的factory机制,通过实例一个static类型default factory,并且通过宏将所有例化extend出来的object,component register到该factory的内部变量中:所以有了可以override的条件: register通过注册一个proxy,该proxy是一个参数化的class,实现对被代理class的create: uvm_component_registry,是对uvm_component的proxy基类,目标component通过定义一个参数化的

首先在Systemverilog中便有对于重载的最基本的支持. 1)定义task/function时,使用virtual关键字.那之后在test_case中调用时,便使用句柄指向的对象的类型而不是句柄的类型来调用task/function. 好处:bird为基类,parrot为扩展类.bird类型的句柄可以指向parrot类型的对象,(进而在这种情况下,这个句柄可以直接赋值给parrot句柄) 当这样的一个句柄调用bird和parrot都有的task.function时,带virtual关键字的

UVM中的类包括:基类(base)------------uvm_void/uvm_object/uvm_transaction/uvm_root/uvm_phase/uvm_port_base 报告(reporting)--------uvm_report_object/uvm_report_handler/uvm_report_server/uvm_report_catcher Factory---------uvm_*_register/uvm_factory 配置(config)----

UVM中Driver,transaction,sequence,sequencer之间的关系. UVM将原来在Driver中的数据定义部分,单独拿出来成为Transaction,主要完成数据的randomize and constrained. 在Transaction之上有增加一层sequence,它可以调用,控制同一类型的transaction. 在UVM中增减component名叫sequencer,来留下与sequence的接口,并控制sequence的启动,定义与UVM环境中其他的co

总结一下UVM中的寄存器访问实现: 后门访问通过add_hdl_path命令来添加寄存器路径,并扩展uvm_reg_backdoor基类,定义read与write函数,最后在uvm_reg_block类中 通过set_backdoor()来将相应的寄存器与它对应的后门访问的读写函数对应起来.其中read和write函数以路径名来直接操作. 前门访问通过总线操作来实现,在其中有uvm_adapter的扩展类,扩展了函数reg2bus和bus2reg,并在uvm_reg扩展类中用default_ma

UVM中的regmodel继承自VMM的RAL(Register Abstract Layer),现在可以先将寄存器模型进行XML建模,再通过Synopsys 家的工具ralgen来直接生成regmodel,提供后门访问,十分方便. 寄存器模型建模: 1)定义一个寄存器,如下;也可以在该class中定义covergroup,sample的function等.在以后的component中在采样. class  reg_invert  extends uvm_reg; rand  uvm_reg_f

UVM中的factory机制一般用在sequence的重载,尤其是virtual sequence.当Test_case变化时,通过virtual sequence的重载,可以很容易构建新的测试. 因为virtual可以控制选择sequence,sequence的启动,执行顺序等. 在build_phase阶段,不需要改变default_sequence,不需要改变别处代码. Transaction的重载,可以在不改变sequence,default_sequence的情况下,改变Transac

我们可以在uvm中实现HDL的后门访问,具体包括的function有uvm_hdl_check_path,uvm_hdl_deposit, uvm_hdl_force,uvm_hdl_release,uvm_hdl_read, task 有uvm_hdl_force_time. 这么做与直接用SV中force, release 有什么区别,有什么好处?这么做的话函数的输入是字符串而不是HDL(hardware description language, 硬件描述语言 )的层次结构.有了字符串就可

一般UVM环境中的Driver组件,派生自uvm_driver. uvm_dirver派生自uvm_component. class  uvm_driver #(type REQ = uvm_sequence_item, type RSP = REQ)  extends uvm_component 其中定义了两个Ports:seq_item_port,driver一般用这个接口向sequencer索要sequence. rsp_port,driver向相应的sequencer发送response

UVM的寄存器模型,对一个寄存器bit中有两种数值,mirror值,尽可能的反映DUT中寄存器的值.expected值,尽可能的反映用户期望的值. 几种常用的操作: read/write:可以前门访问也可以后门访问,如果在env的顶层定义过uvm_auto_predict(1),则UVM会在这两个操作后自动调用do_predict函数 来更新寄存器模型中的mirror值. peek/poke:只用于后门访问,而且完全不管硬件的行为,如向只读寄存器写数据,仍可以写入.应用很少.会自己更新mirro

Callback机制,其实是使用OOP来实现的一种程序开发者向程序使用者提供的模块内部的接口.可以在Test_case的高度改变其他component的一些行为. Systemverilog中已经提供的Callback函数pre_randomize,post_randomize.对于UVM和VIP来说,其他的CallBack函数都是自己程序的开发者事先 留下的hook. Callback的实现: 1)首先直接从component扩展出新的类来实现pre_do等function不可取.因为comp

UVM的正则表达是在uvm_regex.cc 和uvm_regex.svh 中实现的,uvm_regex.svh实现UVM的正则表达式的源代码如下: `ifndef UVM_REGEX_NO_DPI import "DPI-C" context function int uvm_re_match(string re, string str); import "DPI-C" context function void uvm_dump_re_cache(); impo

UVM中有需要从cmmand line 输入参数的需求,所有uvm_svcmd_dpi.svh和uvm_svcmd_dpi.cc 文件就是实现功能. uvm_svcmd_dpi.svh的源代码如下,我们可以看SV采用import的方式导入C代码函数,所有者写函数的实现在uvm_svcmd_dpi.cc 中.当定义了UVM_CMDLINE_NO_DPI的宏时,所有函数返回值要么是NULL,要么是“?”. // Import DPI functions used by the interface t

文件: src/dpi/uvm_dpi.svh 类:  无   SystemVerilog DPI,全称SystemVerilog直接编程接口 (英语:SystemVerilog Direct Programming Interface)是SystemVerilog与其他外来编程语言的接口.能够使用的语言包括C语言.C++.SystemC等.直接编程接口由两个层次构成:SystemVerilog层和外来语言层.两个层次相互分离.对于SystemVerilog方面,另一边使用的编程语言是透明的,但

1.get_full_name() 获取这个节点的完整层次,这函数在object中就有定义,但是在component类中进行了重载,实现输出从uvm_test_top到当前节点的路径(是通过执行m_set_full_name是保存路径在m_name中).返回值如:env.agt.drv(这些名字不是类名,是实例名字) 2.get() 这个函数在很多类中都有,比如uvm_object_register #(T,Tname)和uvm_factory都要这个get()函数,这个函数都是通过单例模式返回

1)uvm_component从uvm_report_object继承而来,提供的功能包括: 1)Hierarchy,-----searching and traversing component hierachy 2)Phasing-----调用uvm_phase以及预先定义的很多phase 3)config-------调用config_db的methods 4)report-------调用uvm_report的methods 5)Factory-----调用factory的methods

原文地址:http://bbs.eetop.cn/viewthread.php?tid=452518&extra=&authorid=828160&page=1 在新的项目中再次用到了UVM,距离上次项目自己写UVM代码已经快一年,所以很多UVM的细节东西自己也记不太清楚了,只能记得UVM各个点的主线,这次重拾UVM,又重点看到了factory部分,所以就在此mark一下,做个笔记. 在记录中肯定有不对和偏颇的地方,一个人的看法毕竟有死角,所以看到不会的地方请大家及时拍砖和轻喷.

如何在有效的使用uvm_config_db来搭建uvm验证环境对于许多验证团队来说仍然是一个挑战.一些验证团队完全避免使用它,这样就不能够有效利用它带来的好处:另一些验证团队却过多的使用它,这让验证环境变得不稳定. 本文讨论如何简单有效平衡的在验证环境中使用uvm_config_db,让它验证环境贡献最多的力量,却又不会成为验证环境搭建的累赘. 接下来=通过三部分来进行阐述: uvm_config_db的使用方法 uvm_config_db的作用对象 uvm_config_db的具体应用 第一部

override功能是UVM中一个比较重要的功能,这个功能也是在factory里面实现的,我们会在env或者具体的case中使用override功能. class case_x extends base_test;     function void build_phase(uvm_phase phase);        -        set_type_override_by_type(my_driver::get_type(), new_driver::get_type());    

从名字上面就知道,uvm_factory用来制造uvm_objects和component.在一个仿真过程中,只有一个factory的例化存在. 用户定义的object和component types通过typedef或者宏在factory中注册,factory产生和保存轻量级的代理(proxy):   1.  uvm_object_registry #(T,Tname) for objects    2.  uvm_component_registry #(T,Tname) for compo

uvm_void The uvm_void class is the base class for all UVM classes. uvm_object: The uvm_object class is the base class for all UVM data and hierarchical classes. uvm_object是一个uvm中data和component共同的基类,里边集成了很多东西如recorder,reporter等,还定义了许多公用的接口.该类继承自uvm_vo