扁鹊见蔡桓公，立有间，扁鹊曰：“君有疾在腠理，不治将恐深。”桓侯曰：“寡人无疾。”扁鹊出，桓侯曰：“医之好治不病以为功!”居十日，扁鹊复见，曰：“君之病在肌肤，不治将益深。”桓侯不应。扁鹊出，桓侯又不悦。居十日，扁鹊复见，曰：“君之病在肠胃，不治将益深。”桓侯又不应。扁鹊出，桓侯又不悦。居十日，扁鹊望桓侯而还走。桓侯故使人问之，扁鹊曰：“疾在腠理，汤熨之所及也;在肌肤，针石之所及也;在肠胃，火齐之所及也;在骨髓，司命之所属，无奈何也。今在骨髓，臣是以无请也。”居五日，桓侯体痛，使人索扁鹊，已逃秦矣。桓侯遂死。

一日，与行同学偶然聊起学生时代的课文，竟脱口而出“君有疾在腠理，不治将恐深”。蔡桓公在他人生的最后35天中，能完成一个成语，讳疾忌医，也算是他对中华文化做出的一大贡献。讳疾忌医的故事和其中的哲理早已深入人心，不再赘述。从IC验证者角度看，此故事之中还蕴含了一个报错力道的问题。

若把蔡桓公生病比作仿真出错，把扁鹊比做IC验证者，在设定仿真报错的力道时，分了四个等级，按照错误的严重程度由弱到强，依次是：在腠理，在肌肤，在肠胃和在骨髓。前三级错误都能容忍，第四级不能容忍，一旦出现，仿真必须终止。

图1 扁鹊

UVM支持的仿真报错的力道，在我看来也有三种，按严重程度由轻到重，依次是UVM_WARNING、UVM_ERROR和UVM_FATAL。如下图所示。

图2

第一种称为告警。当代码存在一些不合理，但是当前不会导致功能出错，仿真器会报告警。例如赋值语句的位宽不匹配，再例如随机constraint不合理导致产生消耗巨大存储资源的数组等等。IC验证者写代码时，通常很少会用到UVM_WARNING。因为威胁和警告都是针对别人的，很少有人会郑重其事的自己警告自己。如果非让说说在编码中使用告警的场合，搜肠刮肚想到的一个牵强附会是比较重要的提示和备注(比UVM_INFO报的信息更重要)。例如，有些信息担心遗忘或被忽略，可以用UVM_WARNING。有些信息希望代码被重用的时候发现，也可以用UVM_WARNING。

第二种是报错。当仿真发生了与验证者预期不相符的情况，则需要通过UVM_ERROR报错。例如报文比对出错。

第三种是发生了致命错误。若一种错误会让仿真不能正常执行，则一定是UVM_FATAL。例如BFM没有get到interface。其他错误并不影响仿真进行，但已然有不符合预期的行为发生，可以是UVM_FATAL，也可以是UVM_ERROR。这取决与验证者如何把握仿真的报错的力道。并无标准规范，仁者见仁智者见智。而这也是本文讨论的重点。

窃以为，处理正常业务报文(transaction)比对错误报UVM_ERROR之外，其他的仿真中发生的与验证者期望不一致的情况，都应该当作致命错误上报UVM_FATAL。一旦发生该类错误，仿真立即终止。

这种设置优点如下所示：

其一，在仿真波形中容易找到错误位置。一旦出错，仿真立即终止，在仿真波形的最右端，即仿真时间的末端，就是出错的位置。

其二，减少错误仿真时间消耗。如果仿真已经出现错误，放任仿真继续进行，后续的仿真出错的概率较大。即使后续的仿真不再出错，那么等仿真结束后，仿真依然是FAIL的，验证者依然需要debug错误的问题。根据经验，验证者debug含有多个报错的仿真时，通常只看第一个报错，debug出root cause后，修改代码，再重新仿真。通常不会再纠结仿真log的其他剩余报错。毕竟，验证者追寻的仿真PASS对UVM_ERROR的容忍度是0。有1个错误和有5000个错误在判断仿真是否PASS时，是一样的。

凡事有利即有弊。此设置的缺点有二：

其一，会降低验证平台的报文完整性，进而对debug的效率有一些负面影响。

例如，验证者通常会在monitor中把数据报文全部采集完成之后，或打印或发送到下级组件。如果使用了UVM_FATAL策略，当报文的传输的中间时刻发生错误，则仿真终止，报文信息未完整采样，也不能打印或下发到下级组件。

其二，每次报错只处理一个问题，需要“小步快跑”，多次仿真才能完成收敛。

图3 小步快跑

两权相害取其轻，人人心中都有一杆秤。好坏善恶，各位看官也自己掂量掂量。

常言道，勿以善小而不为，勿以恶小而为之。若把仿真中任何不符合预期的情形比做一个恶，验证者也不应该在仿真中股息和纵容任何的“恶”的发生，无论大小。

如果可以穿越，让我代替扁鹊去见蔡桓公。初见之时，考虑到患者身份的特殊性，便会把病情的严重程度和发展趋势一并相告，甚至直接下发病危通知。而不是轻描淡写的说一句：君有疾在腠理，不治将恐深。

文章来源：公众号“IC验证之家”，作者：一直特立独行的猪

相关推荐：

数字ic验证|浅谈数字逻辑的可验证性设计

数字ic验证|浅谈IC验证中的打包思想

模拟芯片的未来十年