验证漫谈

xinu2009

讨论到最后，讨论到做人的根源了。
技术讨论的场地，各种大牛之间的争论也像骂大街一样么？
不管是不是马甲，何必恐吓人家问人家家人呢，都是打工的，又何来小人之说呢？
小时候，老师说，人能不能成功在于一个人的勤奋，
上大学发现一个人的性格是那么的重要，
后来仔细的体会了下花花世界，才发现一个人的成就是由他的胸襟造就。
各位大牛仁者见智，何必因为这网络上虚拟的争吵降低了身价。

wenjg76

"我和同事都是中国人，但是我们写文档发工作mail都用英文，有时候需要用中文写文档反而写不出来。"

看到这话，我笑死了.........................
没想到EE论坛里，也有这么娱乐的.

hover99

没想到搞成了火药厂。
VMM1.1之前是无法支持OVM那种工厂模式，原因很简单vmm里面一些参数是通过new传递过去的。VMM1.2之后全面引入OVM的东西，这也就是我说VMM比OVM落后的根本原因，更糟糕的是VMM1.2无法向下兼容VMM1.1。工厂模式是OOP固有的，不过实现起来严重依赖于工程师的素质。就像c++和java，理论上讲c++秒杀java，但是从工程上来讲，c++严重依赖于工程师的素质，高效的c++在平庸的工程师手中往往比java效率更低。验证方法学其实就是让大量平庸的工程师能写出高手才能写出的测试平台。副作用就是后台的复杂程度越来越高，潜规则越来越多。
至于楼主说我们的验证方法很落后，这就是我站出来发贴的初衷，不要迷信大公司，大公司的技术往往趋于保守。M公司根本没有所谓自己的一套验证方法学，NV没有，AMD也没有，LSI也没有，IBM或许有，但是IBM半导体现在也没有出彩之处。
恕我寡闻，还没有见到不用random测试的，random测试的最大优点就是在“蒙”，去“蒙”出导致设计出错的条件，通常对于已知条件的测试（比如输入的组合）random要想有效率必须加入反馈技术，否则大量direct测试是必须的（大量的规整的case很容易用脚本产生，效率反而比random要高）。但是，高效的random是否可以替代大量的case这也是不一定的，跟具体项目有关。
另外，我也没说过我们部门所有人都是做验证的，大部分人做设计的同时也要做验证（设计和验证完全分开是效率极低的做法），但是这些人是不可能对验证方法学有很深入的了解，验证平台是必须屏蔽实现细节的，有些公司甚至使用脚本来产生测试向量。

最后，和楼主说两句。楼主表现得太强势了，面对一个人，你肯能会产生上，中，下三种判断，不过你潜意识的会使用最差的判断。比如说，我说验证的目的不是为了找bug而是证明设计是在多大程度上是可靠的。你潜意识里马上把我当作连验证和DFT都搞不清的菜鸟。又比如，我说我们部门验证的核心人员只有两个，你马上把其余人当成笨蛋。我又说以前的项目有大量的case，你又想到有大量的case都是因为用的是direct测试甚至连random seed都没接触过。单纯看你的推断是合理的，但是联系起来看，你会潜意识的对其他人作出最差的判断。从不如自己的人身上也能学到东西，这样的人才是高人。

我的一个观点，未来的趋势是testbench和test case分离，写testbench的人可以不负责建立test case。楼主说这是错误的，我倒是很像听听楼主的见解。

rhythm1988

回复 34# hover99


hover99,感觉你终于有那么一丝丝地悟了，不枉我费尽口舌地讲啊讲啊，待续。。。

呵呵！难得有你这样的老家伙出来当炮灰，你看hongjian77多“睿智”啊，直接马甲，想占个便宜就走，这是老江湖的做法，只是唉。。。还是那句话，出来混，迟早是要还的。
以我的感觉而言，实际上是喜欢你的执着劲，屡败屡战，还勇敢地继续站出来。
对我而言，有教无类，因才施教。
假以时日，给你适当地引导，你能在这个领域中有所作为的。
为什么对你下重手呢？有个理论叫“空杯理论”，你是有经验的人士，属于杯子不空的那种（实际上，我也是！真正不空的，就是那些飘过去的）
杯子不空呢也不是什么大事，只是你一直不愿意把杯子倒空，我只好帮帮你喽。
不要以为我是落井下石，我是想给你一条绳子，想不想上岸，就是你的事情了。
顺便说一下，你们现在的做法实际上是国内十年前的做法，给你一个佐证，因为你是“土洋结合”，可能听过这个故事，十年前，有拨人用TCL也搞了个验证平台出来，那时候他们就搞了随机。
如果你知道这码事，就不会认为我有“你又想到有大量的case都是因为用的是direct测试甚至连random seed都没接触过”之类的想法了。
不知道他们做法和你们现在是否很类似？
实际上随机并不新鲜，SV把随机进化到受约束的随机了。
闲话说完了，还是进入正题吧。
由于没有太多时间一一回复他的观点，那么，我就只说几个重点问题：

其一,关于基础的问题，即关于“验证的目的”问题。对于原则性的问题，如果有人要修改，我一定是讨论到底的。不为别的，这个问题（概念）是我们的起点，我们整个验证工作的基石，不能有半点偏差和含糊，“差之毫厘，谬以千里”。
唉。。。我在8楼的回帖中，仅仅是希望你来解释一下，还写了很多可能来推测你具体的想法，并且很希望你写点东西来指导我，并且我的论点和论据都全了，自认为写出了自己的意思！关乎“菜鸟”何事？要不我是“菜鸟”怎样？心理上能平衡一点不？能真正focus到问题的本身上了吗？
真正郁闷的是11楼又出来说了一次可靠性这个问题，并且说这个问题之前，海阔天空，云遮雾绕地说了一堆工程什么的，可怜我这样的老家伙，脑子已经不灵光了，楞是没看懂，这些话之间有什么直接联系。
BTW:这次还没看懂！

其二，关于随机和testcase等问题的解释，我的理论来源主要来自于《SystemVerilog for verification》（第二版）这本书的第一章的图1-5，需要注意到的是你也了解验证的出口是功能覆盖率，所以我才用这张图。但为什么你们已经到了VMM还坚持原来的做法，我就搞不明白了。其实还想说具体点，算了，只送四个字：“不破不立”。

其三，关于大公司保守和迷信等问题，以我所了解的EDA用户会议，DAC等业界会议而言，保守的一定有，但不保守的很多，从IC公司在欧美研究所的论文看，保守的很少很少。当我们决定从事验证这个行业的时候，是考虑山中无老虎呢？还是？这个问题不多说了。

其四，关于工厂模式的应用，在20楼回答beginner001中已经点过了，这里再多说两句，工厂模式也是应用，关键在OOP的那些原则，依据那些原则，方法学没有的我就自己做上去。其实你说到了方法学、模式、C++/java等等，本来想多讲一点，为了防止更多地曲解，我还是不讲了。
顺便说点题外话，我是按照《Computer Architecture:A Quantiative Approach》那本书中提到的architect的要求来规划自己的团队，所以在我的团队中，不会呆板地依据方法学，唯一不破的可能只有OOP的原则，其它的都是技术手段。现在提出来给你参考。

最后，忍不住在回帖中又写了点！还有一些你对我的猜测，只能由你了。
还有，你能不能把贵公司的大名站内短信给我，回复了你这么多，没有功劳也有苦劳吧！这个要求不过分吧！

没想到搞成了火药厂。 VMM1.1之前是无法支持OVM那种工厂模式，原因很简单vmm里面一些参数是通过new传递过去的。VMM1.2之后全面引入OVM的东西，这也就是我说VMM比OVM落后的根本原因，更糟糕的是VMM1.2无法向下兼容VMM1.1（个人感觉兼容这个词好像没有在OOP中出现过），。工厂模式是OOP固有的（这句话有个因果关系的颠倒），不过实现起来严重依赖于工程师的素质（感觉恰恰相反，是降低了对工程师素质的要求，不然叫模式干嘛，其实方法学也可以叫模式，只是一种复合模式）。就像c++和java，理论上讲c++秒杀java，但是从工程上来讲，c++严重依赖于工程师的素质，高效的c++在平庸的工程师手中往往比java效率更低。验证方法学其实就是让大量平庸的工程师能写出高手才能写出的测试平台。副作用就是后台的复杂程度越来越高，潜规则越来越多。 至于楼主说我们的验证方法很落后，这就是我站出来发贴的初衷，不要迷信大公司，大公司的技术往往趋于保守。M公司根本没有所谓自己的一套验证方法学，NV没有，AMD也没有，LSI也没有，IBM或许有，但是IBM半导体现在也没有出彩之处。（这个推理古怪，类似的推理在验证中就有，永远不能证明bug不存在，想想你的逻辑思维方式，是不是类似于想证明bug不存在） 恕我寡闻，还没有见到不用random测试的，random测试的最大优点就是在“蒙”，去“蒙”出导致设计出错的条件，通常对于已知条件的测试（比如输入的组合）random要想有效率必须加入反馈技术，否则大量direct测试是必须的（大量的规整的case很容易用脚本产生，效率反而比random要高）。但是，高效的random是否可以替代大量的case这也是不一定的，跟具体项目有关。 另外，我也没说过我们部门所有人都是做验证的，大部分人做设计的同时也要做验证（设计和验证完全分开是效率极低的做法），但是这些人是不可能对验证方法学有很深入的了解，验证平台是必须屏蔽实现细节的，有些公司甚至使用脚本来产生测试向量。 最后，和楼主说两句。楼主表现得太强势了，面对一个人，你肯能会产生上，中，下三种判断，不过你潜意识的会使用最差的判断。比如说，我说验证的目的不是为了找bug而是证明设计是在多大程度上是可靠的。你潜意识里马上把我当作连验证和DFT都搞不清的菜鸟。又比如，我说我们部门验证的核心人员只有两个，你马上把其余人当成笨蛋。我又说以前的项目有大量的case，你又想到有大量的case都是因为用的是direct测试甚至连random seed都没接触过。单纯看你的推断是合理的，但是联系起来看，你会潜意识的对其他人作出最差的判断。从不如自己的人身上也能学到东西，这样的人才是高人。 我的一个观点，未来的趋势是testbench和test case分离，写testbench的人可以不负责建立test case。楼主说这是错误的，我倒是很像听听楼主的见解。

五月一

回复 11# hover99

“在testbench完成之后，需要改变的只是test case而不是testbench。我们用oop技术去屏蔽验证平台的实现细节，只开放最顶层的部分给test case，就像操作系统向开发者提供api一样。我们把写test case的人看做是验证平台的用户。我们部门20多人精通验证的只有2个人，但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验。如果testbench和test case由同一个人完成，那么当他用1个月的时间写完testbench之后，又要花费3个月去建test case来验证。如果很快有第二版出来，那么他又不得不重复上面的工作，试想在这种情况下，验证工程师除了对他所验证的模块更熟悉之外，在验证方法学上有学到了什么？更可悲的是，当他对设计熟悉到一定程度的时候，很可能会把他熟悉的这部分交给他设计，然后又找一个新人给他做验证，如此循环。”

   对你说的testcase 和testbench的区别很感兴趣，能详细说下区别么？让我们拿一个实际模块级的项目来说吧，spec都是在不断的更新，在spec v0.1时，design and verification就开始同步工作了。可能到spec v0.5时，验证工作已经按照现有的spec完成了，搭建好了平台，跑完了所有的testcase，但这个时候由于trade-off，designer和A&A讨论后，发现design要修改，这时验证的平台已经不满足要求了，则需要很大的精力去修改。我一直在考虑这个事情，如何才能在验证的初期阶段就尽可能的避免这种情况的出现（我觉得现实项目中很多）？我的这个问题是不是可以理解为如何搭建一个健壮的testbench？

  对于testcase而言，可以是源于function coverage的，的确run testcase会花费很多时间，但是我觉得交给其他人跑可能效果也不好，因为个人理解对于验证而言，不止是发现bug，还要协助定位bug。如果交给新人做，或者对这个模块了解很小的，可能从无法发现更深的bug。想听听你的见解。

  另外声明： 出于每个人的见解和环境不一样，不参加任何技术外的争论~

diligent15

   

回复  hover99

“在testbench完成之后，需要改变的只是test case而不是testbench。我们用oop技术去屏蔽 ...
五月一 发表于 2011-7-17 06:50

                               
登录/注册后可看大图

    个人觉得在spec做了大的改动的时候还是需要修改tb的细节实现部分的，这是任何技术都避免不了的吧。
我现在做的一个项目的子系统就经常变动，虽然我使用的是erm架构，但是还是或多或少的修改tb的，只是
不需要修改大的架构。

rhythm1988

打酱油，路过。。。顺便占个位置

wangjunweiair

哎！！！！！！！！！！！！！！！！！！

ztspac

对于前辈们的讨论，受教了！
我属于菜鸟级别的，正在一公司实习，做IC验证，主要就是写testcase做覆盖率分析，看来路漫漫而修远啊！

gangersun

全是牛人呀，领教了。