总结我的思路,如何在验证中发现和定位Bug​：验证目的

本文转自公众号“数字芯片实验室”，作者：夏晶 。谢谢

发现Bug，发现所有的Bug，或者证明没有Bug，是验证存在的唯一目的。无论任何验证语言、任何验证环境、任何验证方法学、任何FeatureList，都是为了达成这一目的而使用的方法，或者说手段。

偏离了这一目的的任何工作和努力，都是屎、大便、Shit。

绝对不要被任何华丽的技巧、方法、经验所迷惑，无论验证环境有多么美丽，无论验证语言有多么的HighLevel，都不要迷惑。不要为了追求完美、高效的环境而沉迷其中，陷阱往往就在美丽的后面。有时候，最简单的，才是最直接的，任何武术，直拳最有效。

以SV为例，SV有高层次的语法和结构，能够更大限度发挥激励的控制和Random测试的效率。但是对于发现Bug的目的而言，它只对其中的20%目标达成有突出贡献，而剩余的80%，其作用和普通的Verilog并无二致。

当然，我不是指要放弃SV，因为其有效贡献的20%工作，是普通Verilog很难或者无法完成的工作。OK，所以顺便涉及另一个问题，设计人员需要学习SV吗？有多少设计人员能够在检视或简单UT中发现80%的Bug，而需要SV去完成最后20%？不要看见别人用SV，就屁颠屁颠地跟潮流，想清楚SV能为达成最终的目的带来什么贡献才是关键。

设计人员和验证人员相互沟通，真正的障碍是验证方法学，而不是验证语言。

以TC为例，对于一个验证人员，跑通全部TC，意味什么？代码覆盖率100%，意味什么？验证差不多完成？在我看来，相当于验证工作大致完成了90%，而有一句老话怎么说的？行百里路，半九十。也就是所，实际上剩下10%，才是最艰辛的工作。也许某条TC什么也没干，然后因为什么也没干而Pass了，或者没有实现验证者的意图，所以也Pass了。

只有，而且也只有，有充足信心证明全部Bug被发现、或者没有Bug，才能说明验证差不多完成。