完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
在上一节中,**《IC验证"UVM验证平台加入factory机制"(六)》**虽然输出了“main_phase is called”,但是“data is drived”并没有输出。而main_phase是一个完整的任务,没有理由 只执行第一句,而后面的代码不执行。看上去似乎main_phase在执行的过程中被外力“杀死”了,事实上也确实如此。
UVM中通过objection机制来控制验证平台的关闭。细心的读者可能发现,在上节的例子中,并没有如**《IC验证"一个简单的UVM验证平台"是如何搭建的(五)》**所示显式地调用 finish语句来结束仿真。但是在运行上节例子时,仿真平台确实关闭了。在每个phase中,UVM会检查是否有objection被提起 (raise_objection),如果有,那么等待这个objection被撤销(drop_objection)后停止仿真;如果没有,则马上结束当前phase。 加入了objection机制的driver如下所示:
在开始学习时,读者可以简单地将drop_objection语句当成是finish函数的替代者,只是在drop_objection语句之前必须先调用 raise_objection语句,raise_objection和drop_objection总是成对出现。加入objection机制后再运行验证平台,可以发现“data is drived”按照预期输出了256次。 raise_objection语句必须在main_phase中第一个消耗仿真时间 [1]的语句之前。如$display语句是不消耗仿真时间的,这些语句可 以放在raise_objection之前,但是类似@(posedge top.clk)等语句是要消耗仿真时间的。按照如下的方式使用raise_objection是无法 起到作用的:
加入virtual interface 在前几节的例子中,driver中等待时钟事件(@posedge top.clk)、给DUT中输入端口赋值(top.rx_dv<=1‘b1)都是使用绝对路 径,绝对路径的使用大大减弱了验证平台的可移植性。一个最简单的例子就是假如clk信号的层次从top.clk变成了top.clk_inst.clk, 那么就需要对driver中的相关代码做大量修改。因此,从根本上来说,应该尽量杜绝在验证平台中使用绝对路径。 避免绝对路径的一个方法是使用宏:
这样,当路径修改时,只需要修改宏的定义即可。但是假如clk的路径变为了top_tb.clk_inst.clk,而rst_n的路径变为了 top_tb.rst_inst.rst_n,那么单纯地修改宏定义是无法起到作用的。 避免绝对路径的另外一种方式是使用interface。在SystemVerilog中使用interface来连接验证平台与DUT的端口。interface的定义 比较简单:
那么如何在driver中使用interface呢?一种想法是在driver中声明如下语句,然后再通过赋值的形式将top_tb中的input_if传递给 它: class my_driver extends uvm_driver; my_if drv_if; …endclass 读者可以试一下,这样的使用方式是会报语法错误的,因为my_driver是一个类,在类中不能使用上述方式声明一个 interface,只有在类似top_tb这样的模块(module)中才可以。在类中使用的是virtual interface:
在声明了vif后,就可以在main_phase中使用如下方式驱动其中的信号:
可以清楚看到,代码中的绝对路径已经消除了,大大提高了代码的可移植性和可重用性。 58剩下的最后一个问题就是,如何把top_tb中的input_if和my_driver中的vif对应起来呢?最简单的方法莫过于直接赋值。此时一 个新的问题又摆在了面前:在top_tb中,通过run_test语句建立了一个my_driver的实例,但是应该如何引用这个实例呢?不可能像 引用my_dut那样直接引用my_driver中的变量:top_tb.my_dut.xxx是可以的,但是top_tb.my_driver.xxx是不可以的。这个问题的终极 原因在于UVM通过run_test语句实例化了一个脱离了top_tb层次结构的实例,建立了一个新的层次结构。 对于这种脱离了top_tb层次结构,同时又期望在top_tb中对其进行某些操作的实例,UVM引进了config_db机制。在config_db机 制中,分为set和get两步操作。所谓set操作,读者可以简单地理解成是“寄信”,而get则相当于是“收信”。在top_tb中执行set操作:
在my_driver中,执行get操作:
这里引入了build_phase。与main_phase一样,build_phase也是UVM中内建的一个phase。当UVM启动后,会自动执行 build_phase。build_phase在new函数之后main_phase之前执行。在build_phase中主要通过config_db的set和get操作来传递一些数据, 以及实例化成员变量等。需要注意的是,这里需要加入super.build_phase语句,因为在其父类的build_phase中执行了一些必要的操 作,这里必须显式地调用并执行它。build_phase与main_phase不同的一点在于,build_phase是一个函数phase,而main_phase是一个 任务phase,build_phase是不消耗仿真时间的。build_phase总是仿真时间($time函数打印出的时间)为0时执行。 在build_phase中出现了uvm_fatal宏,uvm_fatal宏是一个类似于uvm_info的宏,但是它只有两个参数,这两个参数与uvm_info宏 的前两个参数的意义完全一样。与uvm_info宏不同的是,当它打印第二个参数所示的信息后,会直接调用Verilog的finish函数来结 束仿真。uvm_fatal的出现表示验证平台出现了重大问题而无法继续下去,必须停止仿真并做相应的检查。所以对于uvm_fatal来 说,uvm_info中出现的第三个参数的冗余度级别是完全没有意义的,只要是uvm_fatal打印的信息,就一定是非常关键的,所以无 需设置第三个参数。 config_db的set和get函数都有四个参数,这两个函数的第三个参数必须完全一致。set函数的第四个参数表示要将哪个interface 通过config_db传递给my_driver,get函数的第四个参数表示把得到的interface传递给哪个my_driver的成员变量。set函数的第二个参 数表示的是路径索引,即在2.2.1节介绍uvm_info宏时提及的路径索引。在top_tb中通过run_test创建了一个my_driver的实例,那么 这个实例的名字是什么呢? 答案是uvm_test_top:UVM通过run_test语句创建一个名字为uvm_test_top的实例。读者可以通过把代码 $display("the full name of current component is: %s", get_full_name());中的语句插入my_driver(build_phase或者main_phase)中来验证。 无论传递给run_test的参数是什么,创建的实例的名字都为uvm_test_top。由于set操作的目标是my_driver,所以set函数的第二 个参数就是uvm_test_top。set函数的第一个参数null以及get函数的第一和第二个参数可以暂时放在一边,后文会详细说明。 set函数与get函数让人疑惑的另外一点是其古怪的写法。使用双冒号是因为这两个函数都是静态函数,而 uvm_config_db#(virtual my_if)则是一个参数化的类,其参数就是要寄信的类型,这里是virtual my_if。假如要向my_driver的var变 量传递一个int类型的数据,那么可以使用如下方式:
而在my_driver中应该使用如下方式:
从这里可以看出,可以向my_driver中“寄”许多信。上文列举的两个例子是top_tb向my_driver传递了两个不同类型的数据,其 实也可以传递相同类型的不同数据。假如my_driver中需要两个my_if,那么可以在top_tb中这么做:
在my_driver中这么做:
|
|
相关推荐
1 个讨论
|
|
路过学习,谢谢分享。
|
|
|
|
|
|
你正在撰写讨论
如果你是对讨论或其他讨论精选点评或询问,请使用“评论”功能。
1367 浏览 1 评论
助力AIoT应用:在米尔FPGA开发板上实现Tiny YOLO V4
1046 浏览 0 评论
2442 浏览 1 评论
2146 浏览 0 评论
矩阵4x4个按键,如何把识别结果按编号01-16(十进制)显示在两个七段数码管上?
2408 浏览 0 评论
1894 浏览 50 评论
6018 浏览 113 评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-23 19:26 , Processed in 0.937883 second(s), Total 47, Slave 37 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号