你的case真的pass了吗？

来源| 杰瑞IC验证（ID:Jerry\_IC）

|原创作者| Q哥

动态仿真是芯片前端验证最常见的手段，通过给DUT施加激励，然后检查输出结果或者内部行为，确保DUT功能和性能的正确性。

验证新手经常犯的一个错误是，看到所有case都PASS就觉得万事大吉。

事实上，这个case是真的PASS了吗？

有没有可能是出错了没及时报告？

或者测试激励根本就没有成功注入，DUT根本就没有动起来或者一直在空转？

那么，如何判定一个case是真的PASS了呢？

除了人工查看log和确认波形等手段，Q哥今天主要聊一聊如何根据仿真log自动排查各种假PASS的情况。

1 TestBench错误自检

通常大家会在TestBench里检查到异常行为或者数据比对出错的时候，打印一条错误信息。

尤其是在UVM环境里，使用uvm\_error、uvm\_fatal、uvm\_warning非常方便。

根据这些错误信息，就可以判定Cass PASS或FAIL。

单独跑一个Case的时候，人工查看没有问题。

但是大批量测试的时候，就需要使用脚本来汇总错误，生成测试报告，以及后续处理：比如Case PASS就删除仿真产生的临时文件以便节约磁盘空间，Case FAIL就删除当前case的覆盖率数据，等等。

为了便于脚本自动识别case是否PASS，Q哥比较推荐的做法是如代码片段1所示：

代码片段1 TB错误自检

在uvm\_test或者env的final\_phase里面，检查UVM\_ERROR和UVM\_FATAL的个数，如果不都为零，打印CASE FAIL；否则打印CASE PASS。

之后通过脚本在仿真log里面检索CASE PASS，就可以初步判断case是否PASS。

这里也可以酌情考虑加上UVM\_WARNING的个数。

UVM的好处是内部会自动记录uvm\_error、uvm\_fatal、uvm\_warning、uvm\_info的个数，通过get\_severity\_count即可得到它们的计数。

如果使用纯Verilog或者SV，需要大家自行添加计数，然后在TB结尾做类似的判断。

大家有没有想过，这里为何还需要判断UVM\_FATAL的个数呢？在执行到这里之前，\`uvm\_fatal语句应该早就结束仿真了吧？

看过Q哥之前文章uvm\_info高级技巧（2）点击跳转的朋友们应该还记得，uvm\_fatal是可以被掩盖掉，或者指鹿为马当作uvm\_error甚至uvm\_info的。

所以并不一定会提前结束仿真。

另一个问题，这里为什么要用$display，而不用uvm\_fatal和uvm\_info呢？

原因同样是因为uvm\_fatal和uvm\_info可能会被屏蔽掉，可能影响后期离线检索。

再来一个问题（欢迎爱提问题的朋友），为什么不直接排查仿真log里的UVM\_ERROR和UVM\_FATAL？

而是在这里根据UVM\_ERROR和UVM\_FATAL的个数来打印CASE PASS，之后再查找CASE PASS？这不是多此一举吗？

别急！这是因为仿真可能在没有uvm\_error和uvm\_fatal的情况下异常结束，比如超时、磁盘满了，或者提交到服务器的任务被管理员kill掉了，等等。

用脚本排查仿真log很可能发现不了任何错误，最终会误判CASE PASS。

这并不是我们所期望的！

2 排查各种运行错误

TestBench自检的错误通常都是我们预先给仿真工具挖的坑，我们是心知肚明的。

实际跑仿真的时候，还有很多意想不到的错误是仿真工具给我们埋的雷，不仔细看log很容易就忽视了。

而这些错误，很可能意味着仿真激励无效甚至掩盖DUT的bug。

这里Q哥说一些常见的错误，主要手段都是用脚本在仿真log里检索错误关键字，排查各种仿真错误，进一步鉴定假PASS。

2.1 排查SVA断言错误

动态仿真过程中，检查到不符合assertion描述的异常行为时，也会打印一条Offending信息，告诉大家哪条assertion语句检查失败，如图1所示;

图1 assertion错误信息

这种错误TB自检完全发现不了。仿真结束后，需要在仿真log里面排查Offending关键字，来确保CASE FAIL。

2.2 排查随机约束错误

随机约束失败是验证新手容易忽视的一个错误。

要命的是，有些仿真器并不会因为随机失败就提前结束仿真。

如果Testbench里面没有对激励的有效性进行判断，可能会导致case最终误报PASS，原本要测试的feature并没有被测到啊！

对于显式的随机约束，只需要在randomize之前加上assert就好了，如代码片段2所示。

代码片段2　随机失败结束仿真

对于像\`uvm\_do\_with、\`uvm\_rand\_send等内嵌的隐式随机约束，不能直接加assert，需要在仿真log里面对随机约束失败进行排查。

另外提醒大家，这里需要根据所用的仿真器打印的log进行具体排查，比如VCS，通常会打印下面的信息，那么根据Solver failed这两个关键字进行排查就可以了。

图2 VCS随机约束失败信息

2.3 排查参考模型错误

对于使用参考模型进行bit-true match比对的case，务必要检查参考模型运行时的错误信息。

需要额外强调下，参考模型的打印信息很可能没有记录在仿真log里，需要在调用参考模型的时候，单独记录到其他log里。

比如在Testbench里面通过$system系统任务调用C-Model时，可以通过加上“|& tee ref\_model.log”，把C-Model打印到屏幕的信息，同时记录到ref\_model.log这个文件里；后续对这个log进行排查，确保C-Model运行无误。

2.4 排查类型转换错误

数据类型转换失败，也是验证新手容易忽视的错误。

最常见的就是把一个int变量直接赋值给一个枚举变量时，类型转换失败，如下面代码片段3所示。

代码片段3 int类型赋值给枚举

虽然VCS等仿真器在编译的时候就会警告这种赋值可能有问题，但是通常编译log里面的Warning实在太多了，根本没注意到。

图3 VCS Warning：int转枚举

跟上面提到的随机失败类似，数据类型转换失败很可能导致case的输入参数是无效的，仿真虽然没报错，但是测试点并没有被测到。

解决办法很简单，如代码片段4所示，对于不同类型赋值的时候，尽量使用$cast转换。

代码片段4 用cast转换不同数据类型

这样错误会光明正大爆出来，如图5所示。之后再排查关键字“Error-”就可以了。

图5 VCS错误提示:cast转换失败

3 预防DUT空转

除了前面提到的各种可能忽视的错误，Case仍然可能因为无效激励没有动起来，或者虽然动起来了，读写的数据都是0，也就是DUT在空转，从而出现假PASS。

那么如何预防DUT空转呢？

Q哥这里说几点思路，具体实施大家根据实际情况取舍。

首先，就是对激励的有效性做检查。这一点可能比较难，建议先对关键的输入参数进行检查。除了直接检查数据，也可以通过功能覆盖率里面定义illegal\_bins 自动排查。

其次，排查assertion log。如果DUT没有动起来，那么所有的assertion都是空成功。

再次，对monitor和scoreboard里的关键信号或者数据检查进行计数，尤其是对于非0数据进行计数，然后在final\_phase里判断这些计数器是不是0，就可以确定是否空转。

总结

如何确保一个case真的pass了？

就像如何确保一颗芯片没有bug，从哲学上来说，这是不可能完成的任务，我们只能尽可能降低出错的可能性。

所以Q哥本文说的都是各种假PASS 的情况，难免有所纰漏。

希望抛砖引玉，提醒大家在验证工作中对各种潜在的风险保持警惕，把bug扼杀在摇篮里。

——The End——

作者：杰瑞IC验证，Q哥
文章来源：处芯积律

推荐阅读