IC验证经验《总结我的思路,如何在验证中发现与定.pdf

DocumentTitle SecurityLevel: 有人认为我验证做得很牛，也有人认为我的验证早就丢下了；有人认为我发现了各个项 目的不少问题，也有人认为我在CMM库的几百个问题单大部分属纯净水。 好吧，无论怎样，我还是把我在验证中如何发现和定位Bug的思路稍微描述总结一下， 纯属灌水。以前华仔曾经叫我写过一次，我随手写了一点点，这次还是详细一点吧，主要分 几点：视角、技巧、思路、经验。 这里主要还是共享给验证的同志们，但对设计的同志其实我觉得是没有什么差别的。 目的： 发现Bug，发现所有的Bug，或者证明没有Bug，是验证存在的唯一目的。无论任何验 证语言、任何验证环境、任何验证方法学、任何FeatureList，都是为了达成这一目的而使 用的方法，或者所手段。偏离了这一目的任何工作和努力，都是屎、大便、Shit。 绝对不要被任何华丽的技巧、方法、经验所迷惑，无论验证环境有多么美丽，无论验证 语言有多么的HighLevel，都不要迷惑。不要为了追求完美、高效的环境而沉迷其中，陷阱 往往就在美丽的后面。有时候，最简单的，才是最直接的，任何武术，直拳最有效。 以SV为例，SV有高层次的语法和结构，能够更大限度发挥激励的控制和Random测 试的效率。但是对于发现Bug的目的而言，它只对其中的20%目标达成有突出贡献，而剩 余的80%，其作用和普通的Verilog 并无二致。当然，我不是指要放弃SV，因为其有效贡 献的20%工作，是普通Verilog很难或者无法完成的工作。OK，所以顺便涉及另一个问题， 设计人员需要学习SV吗？有多少设计人员能够在检视或简单U 中发现80%的Bug，而需 要SV去完成最后20%？不要看见别人用SV，就屁颠屁颠地跟潮流，想清楚SV能为达成最 终的目的带来什么贡献才是关键。设计人员和验证人员相互沟通，真正的障碍是验证方法学， 而不是验证语言。 以TC为例，对于一个验证人员，跑通全部TC，意味什么？代码覆盖率100%，意味什 么？验证差不多完成？在我看来，相当于验证工作大致完成了90%，而有一句老话怎么说 的？行百里路，半九十。也就是所，实际上剩下10%，才是最艰辛的工作。也许某条 C 什么也没干，然后因为什么也没干而Pass了，或者没有实现验证者的意图，所以也Pass了。 只有，而且也只有，有充足信心证明全部Bug被发现、或者没有Bug。但这个充足的 信心怎样说明？后面我再详细说明。 视角： 有多大的视角，就能发现多少的Bug。引用CCTV 的一句台词，心有多大，舞台就有多 大。 我比较不喜欢看到的，就是一个验证人员跑来告诉设计人员，说某某TC Fail了，波形 在XXX，请分析。我不能认定这位验证人员的工作是否合格，只能表达强烈的情绪，特别是 最后发现Fail的原因是验证环境问题的时候。这种验证人员，对设计人员、项目经理，都是 巨大的风险。因为设计和验证，是一定需要有交集的，并且耦合越大，风险越小，只能提 Feature、写TC 的验证人员，就像初三的新月一样，反而需要别人去耦合，如果设计人员视 野不足，野心不够，就存在空隙了。 1 16 2014-04-22 HUAWEIConfidential Page ,Total DocumentTitle SecurityLevel: 一个验证人员，如果能够发现设计中的Critical Path并告诉PR，一定不会得到批评， 反而会在实现工作中得到更多的发言权，和更多的发展。一个验证人员，如果仅仅只能跑写 TC、跑TC，那么多年得不到晋升恐怕也怨不得别人。 OK，回到原点。验证人员必须要懂得代码，懂得分析逻辑，甚至能够通过代码分析出 可能的疑点，更好的，能够理解整个系统的运作，理解前端后端的实现，找出设计人员视角 的盲区，才能更好的发现Bug，解决Bug。 当然，某些同志会认为，验证人员，发现实现的问题耽误了主业，而且实现的问题，实 现人员更容易发现。OK，这里同样存在一个视角的问题，你的视角和实现人员的视角是不 一样的，也许觉得很容易发现的