标志位或者状态寄存器的flag bit该如何验证呢

yueyuedong

如标题所示，flag相关的信号该怎么验证好呢，比如说状态寄存器里面有一些表示sum求和大于某个值之后拉起来的flag，一般用断言检查，用断言的话，就不可避免的去看设计代码，然后用设计代码中的其他相关信号去检查这个flag，但是这样做又有如下两个问题：
1.我检查的思路很容易被设计代码影响，导致检查的思路和设计差不多，发现不了问题
2.我用来检查flag的信号也是设计代码中的，如果这些信号出错，且这些信号属于中间信号，又且这些信号出错不会导致其他问题，只会导致flag问题，同样也发现不了flag的问题
3.还有一个比较尴尬的问题是，设计代码中，这个flag是一大堆信号有效之后拉起来flag，我想不到更好的办法，检查的时候就是把这一大堆信号拉出来，等他们都有效，就去检查flag是否拉起来了，这不是自己检查自己嘛，肯定发现不了问题的。
大家给提提建议

lhy624689564

同有此疑问，蹲一个大佬解答

gavina_zhao

蹲一个

qsh123_123

1，要避免验证的assertion check被设计思路影响的想法是对的，验证插入的assertion check不应该过于依赖设计代码。在验证ENV环境合适的位置插入断言，而不要直接插入到设计代码里面进行assertion check——后者是设计做的事情。设计也可以且应该插入断言的。假如你使用过一些商业IP的话，也会发现商业IP里面在一些关键的信号和标志flag里面有设计插入的断言检查。

2，对于有具体运算逻辑的寄存器相关的assertion检查，我个人建议的做法是验证只跟release出来的design spec和寄存器表格（文档化！文档化！文档化！）进行交互。额外写一个只有assertion的文件，在寄存器模型里面用`include的方式嵌入进去寄存器模型里面（例如产生相关寄存器的前门访问读/写的时候进行断言检查）；当其中的一些逻辑判断信息是不充分的条件的时候，尝试一下从reference model里面抽象出来——所以有一些assertion也可以插入到reference model里面进行DUT行为的判断。不过最好注意一下，reference model的行为往往会比DUT要提前完成，最好只在里面做逻辑行为和结果的assertion check，时序上的check参看下面的3。

3，至于那些需要对接口进行的assertion check和flag status监控，个人建议放在你的interface/monitor里面，进行接口时序相关的断言检查。注意，验证尽可能只做外部接口的接口时序检查，至于内部模块和内部逻辑的时序检查——这部分assertion最好是designer来编写和插入。

最后，简单总结下，验证完全可以采用一定程度的黑盒子验证策略，开放出来的关键标志位和状态寄存器的flag，最好从用户的思维角度去推导这些flag会在什么时候什么场景下trigger、翻转、生效，这样子进行更好地避免收到designer设计思路的影响。

eaglezhang01

状态寄存器不是给user看的吗？user很清楚拿到状态后接下来要干什么事，要干的事能正确干完就可以了吧，至于说用design的信号check design的信号实际是可以这么做的，至少可以验证那段逻辑是否正确，这和de自己写assertion是同样的道理，至于你用到的信号是否是正确的那就继续往前推，这种方法虽然不完美，但是应该想尽办法找bug