uvm中的field_automation主要实现了class中的基础元素的copy,compare等函数, 实现方式分为两种:1)用户注册,field系列宏:uvm内部调用static status container中的function:     2)用户自己实现do_copy,do_print等函数,调用static printer内的函数: uvm_object中实现了print,sprint等函数,实现调度接口,调度status_container和do_function: statu

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

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

我们可以在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

在2.3.3节中引入my_mointor时,在my_transaction中加入了my_print函数: 在2.3.5节中引入reference model时,加入了my_copy函数: 在2.3.6节引入scoreboard时,加入了my_compare函数. 上述三个函数虽然各自不同,但是对于不同的transaction来说,都是类似的:它们都需要逐字段地对transaction进行某些操作. 那么有没有某种简单的方法,可以通过定义某些规则自动实现这三个函数呢?答案是肯定的.这就是UVM中的

原文地址: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的具体应用 第一部

在现代IC设计流程中,当设计人员根据设计规格说明书完成RTL代码之后,验证人员开始验证这些代码(通常称其为DUT,Design Under Test).验证工作主要保证从设计规格说明书到RTL转变的正确性,它包括但不限于以下几点: DUT的行为表现是否与设计规格说明书中的要求一致 DUT是否实现了设计规格说明书中的所有功能 DUT对于异常状况的反应是否与设计规格说明书中的一致 DUT是否足够稳健,能够从异常状态恢复到正常的工作模式 图1 验证发现DUT中的bug 随着芯片规模的增大,验证占整个芯