本文发散式分享几个有效的bug发现手段或者验证方法。

一、final chk

final chk的思想是在执行完成一个测试用例（或者一个简单的命令）之后，然后查看下当前设计DUT的状态。比如说一个cacheline，在完成一笔read/write之后，该cacheline应该是可以被替换（evict）的。

形象一点，当你在饭店吃完饭，座位资源应该是能够被释放掉的。

这种验证方法就是验证设计DUT的自我清除能力。一个很简单的final chk方法就是在完成任何一个测试用例之后，可以随机发送一些常规操作，可能有幸能够发现这类问题。但是最完备，但可能粗暴的方法就是执行完一个测试用例之后，用探针查看DUT的状态和参考模型的状态（所有寄存器和变量的值都是一个符合预期的值）。

时间足够并且验证人员了解DUT实现的情况下，个人倾向后者即使用最完备的方式检查所有设计状态。

二、default test

设计DUT中会存在很多的default:语句，看起来不是主要分支，但很多时候default分支也做了很多非常关键的事情，甚至default分支会比一些主要分支更加复杂和繁忙。

对于一个用户，很多时候不做决定，倾向于留白，只会去配置自己会修改的寄存器配置。default test是指验证人员做尽量少的实际工作，接受默认值，然后执行一些操作。

“江湖不是打打杀杀,江湖是人情世故”。

很多时候，default test case fail，设计可能会说不符合实际约束，用户应该怎样怎样~ 这个时候就涉及到验证和设计的话语权问题了。从验证的角度看，最好是default场景下，芯片是能够work的。如果在正式发布的产品中，用户不愿再配置而希望使用默认值，就非常令人尴尬。