第一个，spec 理解错误。这个问题比较致命。有些bug是designer理解错了spec导致的，然后dv也理解错了，最终导致bug没有验证出来。另外一类是designer 理解正确但是写code引入了bug，dv理解错了spec，认为bug正常，从而导致bug没有修掉。
第二个，testplan没有列全。dv的后续验证行为都是根据testplan进行执行，很多时期bug没有验到是因为testplan没有列全。如何保证testplan的完备性？找designer 一起review不失一种很好的办法。
第三个，验证环境的架构不合理，这包括scoreboard 检查数据的机制不全，monitor到的信号不全，driver输出的激励局限性，random的数据可能局限性等等问题。从而导致漏验一些场景。
第四个，盲目相信code coverage。很多dv认为code coverage 收全design就大概率没有问题。实际上在我们的设计中很多时序问题靠code coverage是没法发现的。如果我们的function coverage也没有写全，此类问题很容易漏掉。
第五个，假pass，从而导致该验证的没有验证到。这类问题表现在验证环境可能有bug，自己没发现，或是 第三条提到的验证架构的局限性，导致bug没有验证到。
第六个，忽视了log中的warning或者是violation，导致一些有问题的design被放任不管，从而导致流片风险。
第七个，实际应用的场景没有验证到，验证的场景实际不会用到，这表现在写test的时候没有考虑软件的应用情况，比如某模块在实际应用中会被频繁调用实现某一算法，但是在验证的时候只考虑了单一场景，从而忽视在实际应用中可能存在的问题。
第八个，关注了模块功能，没关注模块性能，从而导致功能上没有bug，但是性能上有bug。
第九个，芯片验证中漏掉重要的检查，比如寄存器属性，reset值，模块 reset行为等等。从而导致bug漏掉。
第十个，芯片验证的文档缺失，bug管理缺失，导致有些bug虽然已经发现，但是没有提醒designer修掉，从而导致流片风险。
第十一个，一些验证人员关注RTL验证，但是在gate leverl simulation 和 power simulation 中缺乏经验，没有做全，导致一些时序bug 和功耗问题漏验。
除了上面十一条，在我们的验证工作中还有很多风险。如何做好验证，除了验证工程师自身的因素以外，还需要一套完善的验证流程。
原作者：梨果爱秋天
更多回帖
