uvm_info、uvm_warning,uvm_error、uvm_fatal

1、warning/error/fatal调试语句

调试语句除了uvm_info,UVM内部根据问题的严重性(severity)由低到高,还引入了uvm_warning/uvm_error/uvm_fatal。

它们也是UVM预定义的宏,格式跟umv_info很像,只是不再需要设定啰嗦程度了;因此不能通过调整啰嗦容忍等级来忽略。

uvm_warning是打印一些警告信息,用来提醒仿真中的潜在问题。虽然这些问题暂时可能没什么错,但还不能完全忽视。

uvm_error用来记录仿真中的错误,达到一定数量,仿真就提前结束。

uvm_fatal是严重错误,一旦执行到了,仿真就立即提前终结。

那么问题来了:

当我们专门进行异常测试的时候,由于施加的激励本身就是错误的,这时候难免会触发TB里面原先的uvm_error或者uvm_fatal;导致测试提前终结。

这些uvm_error或uvm_fatal如果是自己写的,倒是可以通过打补丁让它们对异常测试case网开一面。但如果是其他人写的或者用的VIP,那就有点棘手了。

好在UVM调试信息机制已经考虑到这个问题了。

在仿真过程中,UVM内部会记录每条调试语句的严重程度。

默认情况下,uvm_info语句的严重程度就是UVM_INFO,uvm_error的严重程度就是UVM_ERROR,以此类推。

2、修改调试语句的严重程度

类似于调整啰嗦容忍等级,我们可以通过下面这个命令行plusargs来修改调试语句的严重程度。

这里<comp>和<id>的设置方法跟uvm_set_verbostity一样,不再赘述。

<current severity>是当前的严重程度,<new severity>是想要改成的严重程度。

例如下面这个仿真参数,就是把uvm_test_top.env0下面所有子子孙孙组件里msg id为BAD_CRC的uvm_error语句,改成uvm_warning。

对于msg id是BAD_CRC的uvm_fatal语句,并不受影响。

这个plusargs不单能把UVM_ERROR变成UVM_INFO,反过来也可以把UVM_INFO变成UVM_ERROR,就看大家实际的需求了。

如果将UVM_ERROR改成UVM_INFO,那么这时候它的啰嗦程度是什么呢?

答案是UVM_NONE,也就是啰嗦程度最低。

除了命令行plusargs参数,也可以在TB中,通过component对象调用API来动态修改严重程度(如下图所示),用法类似于上一篇提到的修改verbosity的API。

下面这两个API的区分在于是否按msg id进行过滤,不再赘述。

3、调试语句引发的调试行为

设置容忍等级虽然可以屏蔽啰嗦程度高的uvm_info语句,但是如果想屏蔽啰嗦程度为UVM_NONE的语句呢?

又或者,当我们把uvm_fatal/uvm_error改成了uvm_warning/uvm_info以后,仿真虽然没有终结,但是这些信息仍在刷屏怎么办?

除了啰嗦程度(verbosity)和严重程度(severity),UVM内部为每个调试语句都记录了一个调试行为(action),它是一个多比特的变量,每一比特都代表一种行为。

action如果有多个比特为1,就同时执行多项调试行为;

如果全部为0,就什么都不干,记为UVM_NO_ACTION。

默认情况下,调试语句对应的行为是根据严重程度决定的。

4、修改调试语句的调试行为

UVM提供了下面的命令行plusargs参数,可以修改调试语句对应的调试行为。

这里的<comp>和<id>用法和uvm_set_verbosity及uvm_set_severity一样。

<severity>是代表调试语句的严重程度。如果通过uvm_set_severity修改过严重程度,那么uvm_set_action会根据修改后的严重程度进行过滤。

<action>是执行到当前调试语句时采取的调试行为。

例如配置下面这个命令行参数,就可以无视uvm_test_top.env0下面所有子子孙孙组件中严重程度为UVM_ERROR的所有调试语句;

也就是说,既不会打印信息到屏幕,也不会计入错误个数。

相比之前提到的uvm_set_verbosity,uvm_set_action简直是大杀器啊!

完全可以通过修改调试行为,更直接的屏蔽调试信息,不必再管什么啰嗦程度和容忍等级。

uvm_set_action也可以在TB中通过component对象调用API来实现(如下图所示),用法类似于verbosity对应的API,这里不赘述。

总结

通过修改调试语句的严重性和对应的调试行为,可以避免仿真提前结束,或者更为直接的屏蔽调试信息。

但是Q哥需要给大家特别强调下,修改调试语句的严重性和调试行为,属于掩耳盗铃颠倒黑白的做法,一定要慎之又慎,避免操作不当,掩盖了原本应该报出的错误。

美好的时光总是短暂的,今天就跟大家聊到这里。接下来,Q哥将给大家献上如何定制uvm调试信息的结构,如何打印彩色信息到屏幕上,等等进阶的uvm调试技巧使用心得。

敬请期待!

日积月累,进步从一点一滴开始,加油!!

相关推荐
apple_ttt6 天前
SystemVerilog学习——构造函数new
fpga开发·fpga·systemverilog·uvm
apple_ttt8 天前
SystemVerilog学习——虚拟接口(Virtual Interface)
fpga开发·fpga·systemverilog·uvm
逍遥xiaoy5 个月前
SystemVerilog测试框架示例
systemverilog·uvm
谷公子的藏经阁6 个月前
设计模式在芯片验证中的应用——迭代器
设计模式·systemverilog·uvm·芯片验证·design pattern
小桶qa8 个月前
【APB协议 & UVM_Sequencer & Driver & Monitor_2024.03.04】
ic验证
小邦是名小ICer1 年前
7.2 uvm_resource_db in UVM
uvm
小桶qa1 年前
【验证概括 & SV的数据类型_2023.12.18】
linux·ic验证
一只迷茫的小狗1 年前
UVM建造测试用例
uvm
小桶qa1 年前
【同步FIFO_2023.12.13】
linux·ic验证