验证漫谈

为了增加可信度，先八卦一下本人的经历，本人从事IC这个行当超过十年，最开始的设计是用原理图方式做的，新千年后转向两个HDL语言
，从事的主要是通讯芯片的设计和验证工作，最近的一个完成的事情是建立一个团队并实现大规模复杂芯片的验证平台，用的主要技术 手段是SC/SV+OVM.
平心而论，本人决非所谓高手、牛人。所谓的高手是什么，举个例子，IC行业用TCL语言的人不少，这个语言的发明人觉得研究中用C不爽，干脆自己写一个语言好了，同样的例子是linux和android的发明人，这些才是典型的高手。 所谓以无厚入有间就是指这种人。
我想来论坛一定有高手，只是大音希声，大道无形罢了！
之所以想讲一下验证，主要是以前工作忙，也不是喜欢管闲事，上了论坛，下两本书，打个酱油就走了。但潜水多年，发现问题还是那些问题，心态还是那些心态，没有什么变化，本着人人为我，我为人人的心态，就倚老卖老一次吧。
漫谈也得有点主线，下面就从国内的验证生态圈到验证技术发展再到验证职业生涯，说一说看法，顺便可能会跑题说说以前贴子提到的一些问题。
首先，验证生态圈，俗话说：男怕入错行、女怕嫁错郎。就验证而言，理论上和其余IC工作一样，没什么可以特别讲的，不过我们是在中国，那就有点中国特色了。先说源头吧，还是在伟大的天朝高等教育制度上了。举个例子，那本XIA老师挂名的VMM方法学的中译本，我是看得相当地累(中国语文太差)，翻译有三点要求，信达雅，雅就算了，至少要达吧，要把原文给“达”过来吧，很可惜没有。好在我是先看的原文，后来发现团队中小伙子们总问一些古怪的问题，追踪溯源，拿过来一看，唉，XIA老师你又毁人不倦了。天朝的整个高等教育体制就是一个杯具，如果谁站出来说自己没有悲剧的话，那我还真要恭喜你，你父母的钱花的值得。BTW:本人就是应该被恭喜的范畴之列，本人的硕士导师我是感激一辈子了，可惜他为了种种原因，给大日本帝国服务去了，实际上损失的还是莘莘学子们。
跑题了，再回来说上面这个例子。XIA老师总算是有点名气，没“达”到，至多是水平不够高。还有一本验证方面的入门书，中文叫《编写测试平台》的，我是直接禁止团队成员看，“信达雅”根本就不着边，南辕北辙的地方多了去了。伯格龙老兄要是知道自己的书译成这样，不吐血才怪呢！
如果我们是这样的起点的话，那有什么古怪的情况都不奇怪了，学生四年七年运气好，进了一个正规的公司，那也比非大陆的学生晚了三五年的，起点不一样，发展能一样吗?
顺便比较一下，台湾和大陆的中译本的翻译人员和水平，大陆就不多说了，比如booch经典的《面向对象分析与设计》台湾译本是由几位具有几十年编程经验的程序师翻译的，还诚惶诚恐怕译不好，这就是差距。
如果大家的起点如此之低，那国内的验证生态圈水落船低就不足为奇了。再说说国内业界的生态圈，三大门派：纯洋鬼子，假洋鬼子和土财主。纯洋鬼子的核心在大陆之外毋庸置疑的，大陆就是个低成本的实验室（工厂），验证的核心和理念基本都不在大陆，派几个台湾人，香港人和新加坡人来管理一下就行了，买办的管理我不熟悉，但我接触的几个leader的思路和空间都被限制得比较死，具体不说了，得罪人。假洋鬼子的道道就太多了，基本上就是捞一票的心理，不说验证也就罢了，说多了，怕大家心里有阴影。说句实话，土财主们反而愿意做好验证，因为没有退路，只有往前走，没靠山，只有靠自己，但做事情就有点八仙过海了，准确地讲，不规范，感觉近来要好了一些。OK，顺便回答前面帖子里有个人说要帮设计人员找bug的疑惑和问题。这事情要分几方面来讲，首先，从你的说法上，大致可以看出你们的验证不够规范的地方，大家都知道验证是分层进行的，从unit到block到system，这个bug是那个层面的呢，功能性的还是连接性的，功能性的最多到block就应该消灭了，要有验证报告存档和审查，只有连接性的是system层面要考虑的，那么unit层面的呢，那才是设计人员必须要自己解决的问题，所以bug不能一概而言，这些都是Writing Testbenches那本书里讲过的，其次，你提供的VIP和平台可以达到那个层面呢?是system还是block呢?平台本身是否有测试报告呢?不然你怎么让设计人员信服，是设计出差而不是平台出错了。最后，况且验证策略有白、黑、灰三种，策略不同，定位的主体也是不同的，总的原则是让合适的人干合适的工作，验证人员不应把自己放在设计人员的对立面，只有一起尽在掌控中，才算是合格的验证人员，不然为什么boss要给你高薪呢?总要有个道理吧。
说完了验证的现状，再说说验证技术，看了一下最近的帖子，有个感觉普遍都还在应用操作层面。就拿讨论VMM和OVM的优劣的问题来说说，实际上这根本就不算是问题，无所谓谁优谁劣。其实有个人说了实情，Marvell就是自己的一套。对于业界的领先公司而言，那几个EDA公司就是追随者，技术上不存在领先的问题。所谓VMM和OVM都是大公司不玩了，他们再总结总结，把共性的东西提取一下，给没有实力去自己研发的Fabless厂商提供一个解决方案而已。以OVM为例，不到20K的源码，按业界工程师300行每月的产量，也就不到10个工程师团队的一年工作量，大公司要靠这个那还有江湖地位啊。诸位看看IBM的EDA，基本上就是自己的独立王国，EDA供应商的东西是最外围的，核心的永远是自己开发的，随便拿个出来，不好意思，就是标准，比如sugar语言，不就构成了PSL的基础了。另外再举个例子，写Writing Testbenches那本书的老兄伯格龙，我记得在synopsys的大客户全球支持团队(好像是这个名字或者类似)，做的工作就是给业界大公司提供验证方面的支持。不继续扩展下去，点到为止。
下面结合职业生涯再讲讲验证工作和技术等等问题。
如果你选择了验证，或者是被验证了，我个人觉得和所有的研发工程师一样，没有什么区别。用狄更斯的话就是，这是个最好的年代，也是个最坏的年代。关键还在自己，如果你自己没有设置上限，那还有什么可以限制你的呢?
最后说一些体会：
1）IC上所有的工作都是殊途同归，唯一限制你的只有你的眼界，把眼光放远一点；
2）做事情要踏实，贪多嚼不烂，学多，不如学精，等能力上了一个台阶后，其它基本上触类旁通了，就好像武打小说的任督二脉，没打通，什么都白搭；
3）把基础打扎实，多看看老外的书，深入体会一下老外的思路和想法，比如：把VMM之类的搞懂了，还得想想为什么?本来想讲讲学习路线图，不过这属于技术经验，只供BOSS使用，另外讲了对初学者没有好处，这是一个复杂的多方位的学习体系，必须由leader来领路；
4）IC这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
其它的再补充吧！

大牛终于出来说话了，很是受教啊，呵呵

小编看的出来在这方面有很丰富的经验。呵呵。前辈啊！你说得很多东西我也很有体会，大公司一般里面用自己开发的工具还是很多的。

讲的很经典哟，就是国人很浮躁惹的祸，不能静下心来做事。

小编真是牛啊

同行的牛人，一定要支持，说出来国内的很多真实写照，浮躁是根本问题所在呀。

本来也想写一篇关于验证的文章，没想到被小编抢先了。
其实小编有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。ic公司关心的是产品，工程师反而没有太多精力去搞什么方法学，即便搞出来也会受到项目组的抵制（假如现有的平台已经成功流片了多个产品，你会推翻它再搞一套新的吗）。
验证的目的是保证产品在多大程度上是可靠的，而不是找到bug。另外，本人认为验证工程师水平比较低的原因大部分验证工程师将大部分的时间花在建test case上，结果大致大部分人认为验证是一个技术含量比较低的工作，有一两年经验马上转去做设计。如果把debug能力作为验证工程师的重要素质，那么培养验证工程师的方向完全错了。
个人认为验证方法学主要解决三个问题，复用；testbench和test case的分离；testbench的鲁棒性。第一个问题（不仅包括项目之间的横向复用更包括自底向上的垂直复用）没啥好说的，无非就是节省工作量。第二个问题的本质就是分工，建test case的工程师需要对产品本身有更深入的了解，甚至就是设计工程师。第三个问题最关键，高效率的工作写testbench和设计基本上同步进行，这样就会导致写testbench的时候，设计是不确定的，极端情况是你的验证工作已经完成，这个时候设计突然改动了，这个时候就能体现出一个高水平的验证工程师的价值。所以从这一点上看，OVM比VMM1.1先进一代（VMM1.2基本上和OVM没啥区别），OVM比VMM晚了2年，技术上先进也是合理的。
最后，所谓中文译本基本上都是学生翻译的，而且很多术语根本就没有翻译标准。最好的参考资料就是英文的ref guide。当年夏老师那本verilog还是公认的有水平。
现在很多初创公司验证水平还停留在verilog的层次上，而对他们来说验证恰恰是最重要的，而且这些公司往往无法得到eda公司的支持，所以我认为验证服务还是有市场的。

本来也想写一篇关于验证的文章，没想到被小编抢先了。
其实小编有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。
LZ：有一个理论叫冰山理论，也许你看见的和听说的，只是水面上的部分，可能水下的部分更多。
一般老外的工程师都相当严谨，没有把握的东西一般不拿出来show。

ic公司关心的是产品，工程师反而没有太多精力去搞什么方法学，即便搞出来也会受到项目组的抵制（假如现有的平台已经成功流片了多个产品，你会推翻它再搞一套新的吗）。
LZ：很多公司都是死在这种思路上，具体讲，中层没有动力去更新自己，导致支持不了高层的策略，公司慢慢地就落伍了。这种温水煮青蛙的例子太多了。
举个例子：5、6年前的soc项目，现在可能只是一个subsystem，如果是你做验证怎么办?以不变应万变?
没有精力去搞?项目组也抵制?能不能PM给我那些公司?以后听说谁去那个公司要小心。
你说的情况只存在于老的项目中，项目处于维护状态，才停滞下来。BOSS也不会投入在已经不需要大量投入的项目。
验证的目的是保证产品在多大程度上是可靠的，而不是找到bug。
LZ：严格地讲，这句话概念上有错误。对于IC的验证有着严格的定义，我希望你是表达上的错误，混淆了verification（验证）、Reliability（可靠性）和Test（测试）等概念。
老外的书在这几个概念和方法上是有严格定义和界限的，并不是想当然中的那样。
如果你在我的团队中，我会希望你写一篇文章来描述你这个定义，论文中要有业界公认的定义是什么，你对定义的态度和看法，是希望在此基础上更广泛或更精确?还是愿意修改已有的定义。
如果你有兴趣，不妨就你说的验证的目的再写一点东西。
可以很坦白地告诉你，我从来没有看过那个资料里把验证的目的和可靠联系在一起，如果有希望你能告诉我。
最后把我的理论来源告诉你：在《writing tesebenches》中有这样一句话：The issues of design safety and reliability and techniques
for ensuring them are beyond the scope of this book. But it is the role of a verification engineer to ask those questions.

另外，本人认为验证工程师水平比较低的原因大部分验证工程师将大部分的时间花在建test case上，结果大致大部分人认为验证是一个技术含量比较低的工作，有一两年经验马上转去做设计。
LZ：test case是testbench的一部分，花时间构筑test case无可厚非，但将此作为验证工程师水平比较低的理由，就有点不靠谱了！
不能因为也许是你的环境是这样，就认为是这样的逻辑关系。
给你一个忠告：有机会就找个好的团队，正规地培养一下。

如果把debug能力作为验证工程师的重要素质，那么培养验证工程师的方向完全错了。
LZ：debug能力是整个IC行业，乃至整个IT行业的基本而且重要的能力，相比较起来，会不会验证或者什么方法学都没有那么重要！简单地讲，靠debug能力可以吃一辈子饭，其它的技术可就不一定了。

个人认为验证方法学主要解决三个问题，复用；testbench和test case的分离；testbench的鲁棒性。第一个问题（不仅包括项目之间的横向复用更包括自底向上的垂直复用）没啥好说的，无非就是节省工作量。第二个问题的本质就是分工，建test case的工程师需要对产品本身有更深入的了解，甚至就是设计工程师。第三个问题最关键，高效率的工作写testbench和设计基本上同步进行，这样就会导致写testbench的时候，设计是不确定的，极端情况是你的验证工作已经完成，这个时候设计突然改动了，这个时候就能体现出一个高水平的验证工程师的价值。
LZ：相信上面这段内容是你思考的结果，不过很可惜只得皮毛，另外还有一些偏差，限于篇幅原因，不展开讲。
等你上了一个台阶的话，自己再来看你的理解。从整个描述讲，贵公司在整个开发流程上还有相当多的漏洞或者不足。

所以从这一点上看，OVM比VMM1.1先进一代（VMM1.2基本上和OVM没啥区别），OVM比VMM晚了2年，技术上先进也是合理的。
LZ：没有必要纠结这个问题，有一句话，批判的武器不如武器的批判，OVM有历史继承性，并不是晚的原因，技术上也没有先进性，所谓先进与否要从基础原理上看，比如：OOP等等。
最后，所谓中文译本基本上都是学生翻译的，而且很多术语根本就没有翻译标准。最好的参考资料就是英文的ref guide。当年夏老师那本verilog还是公认的有水平。
LZ:所谓水平要分层次，语言是拿来用的，XIA老师的verilog后来是人手一本了，仿佛当年谭校长的c语言，可是语言之外还有很多东西。作为一部介绍Verilog的教材够了，所以我说至多水平不够高，呵呵。

现在很多初创公司验证水平还停留在verilog的层次上，而对他们来说验证恰恰是最重要的，而且这些公司往往无法得到eda公司的支持，所以我认为验证服务还是有市场的。

谢谢lz分享经验，受教育了

验证人员是不是以后还是要往系统设计方面发展啊

很不幸，本人就在小编所说的M公司，而且在最核心的部门和美国工程师合作了2年，至少在去年我们最先进的产品仍然是使用verilog来验证的。非常不幸，你对大公司的评价和对我个人的评价完全陷入了悖论。在M公司（小编说的纯洋鬼子）和以前的公司（小编说的土财主），都遇到这么一个问题，当我们试图用新的验证技术去替换旧的验证环境时，会发现有大量的test case需要大量的人力去移植，结果时间和人力上都无法满足，好的情况就是两套环境并存并持续若干个项目，最终转移到新的平台，有一个有趣的现象在两套环境并存的过程中，几乎所有以前抱怨过老环境的人都认为老环境还是可以接受的。验证的最终就是追求功能覆盖率，新老技术都能做到这一点，只不过新技术效率更高并且更不依赖于验证工程师的素质。结果就是在新老技术交换过程中，效率更低下。所谓大公司的包袱救治指的这个。其实这种例子有的是，最典型的莫过于塞班，诺基亚算不算大公司?大家都知道塞班落伍了，但是提高技术甚至推到重来，诺基亚偏偏就是做不到。另外一个例子，synopsys的vip很多都是vera的，在大家看来太落后了，为什么还能存在?这是因为这些vip已经经过了大规模的验证，重写虽然可能提高效率甚至不用花费大量的时间开发，但是必须要重新花费大量的时间来验证vip本身的可靠性。所以这些vip从vera时代一直延续过vmm时代，最终到uvm终于无法适应了，只能重写。
所以说，技术上的革新都是被动的。革命在西方就是贬义词，大家更喜欢用进化，而进化本来就有被动适应的意思。
验证方法学只是一个手段，产品才是目的。对于pm来讲，最好是可以使用最简单的技术来完成任务。这就是工程和研究的区别！
如果你的验证平台在设计freeze之后，每一周都能找出若干个bug，我想pm不会觉得你的工作有多出色而是对你的验证感到绝望。我这里所说的验证可靠性，是指的是在流片之前pm有多大的信心来保证芯片回来是work的。如果我的验证平台一个bug都没发现，但是我能保证所有的可能情况都测试过了，你能说这个验证平台不合格吗?
小编认为test case是testbench的一部分，我觉得你并没有理解vmm或者ovm的精髓。如果仔细研究vmm或者ovm，你就会发现，vmm/ovm花了很大的努力去把二者分开。小编说的大客户支持（CAE）里面的工程师是验证架构工程师，所谓验证架构就是开发testbench的人。而且按照vmm或者ovm的理念，在testbench完成之后，需要改变的只是test case而不是testbench。我们用oop技术去屏蔽验证平台的实现细节，只开放最顶层的部分给test case，就像操作系统向开发者提供api一样。我们把写test case的人看做是验证平台的用户。我们部门20多人精通验证的只有2个人，但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验。如果testbench和test case由同一个人完成，那么当他用1个月的时间写完testbench之后，又要花费3个月去建test case来验证。如果很快有第二版出来，那么他又不得不重复上面的工作，试想在这种情况下，验证工程师除了对他所验证的模块更熟悉之外，在验证方法学上有学到了什么?更可悲的是，当他对设计熟悉到一定程度的时候，很可能会把他熟悉的这部分交给他设计，然后又找一个新人给他做验证，如此循环。
实际情况是，相当一部分验证工程师在工作1，2年后会转为设计，还有一部分会专注于写test case，对他们来讲debug是一个重要能力（话说回来，写RTL和debug自己的RTL都不是什么技术活）。对于那些验证架构工程师来讲更重要的是用软件方式对testbench debug，两种debug根本就不是一回事。

一直在潜水，本帖虽然是验证漫谈，但是rhythm1988通篇只做了3件事：抱怨国内的环境，重复10年一本老书的观点，最后又崇拜了一下洋人。
看到rhythm1988的团队成员居然看中文资料，我简直要喷饭了。我和同事都是中国人，但是我们写文档发工作mail都用英文，有时候需要用中文写文档反而写不出来。仔细看了rhythm1988的回帖，确实有领导风范，就是说你不行，你的层次不够，具体那不行就要靠自己的慧根了，真是牛人！记得当年打cs的时候，大家都讨论那种枪厉害，突然有人说真正的牛人就是用匕首也能杀人，你们的讨论层次太低，于是被大家无比崇拜，结果打起来却发现水平so so。所以大家得到一个结论，要想做牛人，绝对不能展现出自己的实力，要说些似是而非的话，最重要的是要掩饰自己的观点。比如大家在讨论肉车的时候，明明你非常赞同，但是你也要说：没有肉车只有肉人。语言只是工具，vmm只是应用，这样一说，别人就不好意思问你这方面的问题了，即便是你一窍不通别人也无法察觉，对你只有仰视。rhythm1988从业10多年了，应该是管理层了吧。这些人对技术细节并不了解，也不屑于了解，不是说这些人水平低，而是说在这个层次的人关心的是flow和宏观问题。但是这些问题不是engineer关心的，flow追求的终极目标就是同样的任务任何人做出来效果都一样，记住体制中是培养不出牛人的。
不过看到下面hover99的帖子倒是觉得有些新意，特别注册一个id来谈谈我的观点。本人是designer，也懂一点vmm，不过我们soc的验证环境还是verilog的。以我的经验来看，bug往往出现在你认为不会出现bug的地方，让designer自己验自己的design，总觉得不靠谱。其次，hover99所说的只改testcase不该testbench，我觉得过于理想化了，假设设计要求增加错误检测功能需要driver产生error injection，这个时候除了改testbench还有别的方法吗?

占个位置先！待续。
很不幸，本人就在小编所说的M公司，而且在最核心的部门和美国工程师合作了2年，至少在去年我们最先进的产品仍然是使用verilog来验证的。非常不幸，你对大公司的评价和对我个人的评价完全陷入了悖论。在M公司（小编说的纯洋鬼子）和以前的公司（小编说的土财主），都遇到这么一个问题，当我们试图用新的验证技术去替换旧的验证环境时，会发现有大量的test case需要大量的人力去移植，结果时间和人力上都无法满足，好的情况就是两套环境并存并持续若干个项目，最终转移到新的平台，有一个有趣的现象在两套环境并存的过程中，几乎所有以前抱怨过老环境的人都认为老环境还是可以接受的。验证的最终就是追求功能覆盖率，新老技术都能做到这一点，只不过新技术效率更高并且更不依赖于验证工程师的素质。结果就是在新老技术交换过程中，效率更低下。所谓大公司的包袱救治指的这个。
LZ:你看问题说具体了，就有讨论的空间了。你说的比较典型，OK！上面转换策略是你们具体执行的方式和碰到的问题，我提一个思路你看会不会好点?比如：你们的平台能否提前一到两年实现，并做好平台的测试工作呢（包括VIP）?团队的manager和leader能否深入产品去提前挖掘需求，做到一个提前量，也许抱怨的人就会少一些。
另外还有一个问题，即上面提到的大量的test case需要大量的人力去移植的说法。呵呵！上次有意没有点这个问题，看你这么执着，就说一说解决方案，非常遗憾的是，业界已经更新了大量test case的做法，具体的做法是少量的test case（少到多少有讲究）+自动更新随机种子+部分的定向测试的方式来完成覆盖率要求。
你仔细去看8楼的回答中，我压根就没有提所谓的大量test case的说法！你可以想象得到我看到这句话时的表情，应该说你在一个封闭的环境中，天空就那么大一点。
为了防止你吹毛求疵，我再把相关问题说透彻一些。
其实，我贯穿整个讨论一直在明确关于语言和验证工作的问题，只是没有显性的说出来。说了多少次了，开始就说牛人的做事情方式和思路，说了两个验证方法学的不存在优劣的问题，说了要把基础打扎实一些，其实都是在说这个问题，目的是希望看帖子的人自己能够有所悟！当你自己有悟的时候，才能够改变验证工作被动和地位不高的问题。
你没有悟出来吧，还把自己的一知半解给拿出来做理由，这就怪不得我下重手了。
我来解释一下最先进的产品仍然可以用VerilogHDL和VHDL来验证的理由吧。如果我们可以不怕麻烦的话呢，所有的问题都可以用C/C++，再源头就是汇编了，但很明显，有牛人用的不爽，干脆自己编一个出来，同时也造福象我等这样的平庸人士，VerilogHDL之类的就是这么出来的。
那好了，既然有牛人造出了Verilog，使C语言插上了时间性和并发性的翅膀，难道还有什么问题不可以用c加上verilog来解决呢?甚至更极端的，你们公司有大牛，干脆用c甚至汇编来解决问题，不是不可以哦！
所以说，方法学没有什么优劣的，既然systemverilog是半吊子的面向对象的方法，那么我VMM用CALLBACK，你OVM就没有资格来批评我，咱们都是半斤八两，有本事你OVM干脆搞个纯oop的硬件描述语言生态圈出来?这就是我为什么说没有优劣的原因。
不告诉你，是你整体还没有上这个台阶，贪多嚼不烂，后面居然成为攻击我不了解方法学的原因，彻底无语了。
最后说说M公司，不知道我说的“M”公司是不是你说的M公司，几年前听说M公司是唯一把核心业务放到中国来做的公司。我在多年（接近十年）前看看的一篇关于集成多子系统在单SOC芯片的论文，就是M公司的，文章应该是99年的DAC论文。记得看的时候是十一，没别的事，干脆仔细看看，应该承认“M”公司在新千年之前，就已经是业界领先了，想不到十年之后，还是如此而已，难怪没落得要私有化的程度，唉。


其实这种例子有的是，最典型的莫过于塞班，诺基亚算不算大公司?大家都知道塞班落伍了，但是提高技术甚至推到重来，诺基亚偏偏就是做不到。
LZ:这个问题我是外行，但尽量交流一下。其实类似的情况业界也有，新千年的时候是网络股火爆的时候，Intel花了60多亿美刀买了个做网络处理器的公司，Intel公司的技术实力不可以质疑吧，结果呢?一塌糊涂，最后公司好像不到7亿卖给了Marvell！
关于塞班的问题可能很复杂，但和Intel类似，根本上应该是高层在不熟悉的子领域中的策略有问题，一个正面的例子是Apple，其实我们看IPAD的硬件成本和售价，对比IMAC的成本和售价，就知道，在数据业务这个移动子领域中，商业模式发生了很大的变化。诺基亚的策略上没有苹果的策略合适，不是技术问题。
个人理解不应该拿来支持你的看法。
另外一个例子，synopsys的vip很多都是vera的，在大家看来太落后了，为什么还能存在?这是因为这些vip已经经过了大规模的验证，重写虽然可能提高效率甚至不用花费大量的时间开发，但是必须要重新花费大量的时间来验证vip本身的可靠性。所以这些vip从vera时代一直延续过vmm时代，最终到uvm终于无法适应了，只能重写。
LZ:这是你们自己的内部矛盾，按理我没有发言权。反证一下吧，但业界推出UVM来统一方法学，难道是推UVM的那帮人走路集体撞墙了，或者在集体梦游！业界大公司M明明发现VMM过渡不到UVM，还要硬推融合?
唉，都是我在给你们出主意，你们是什么公司啊?说得都有点不耐烦了！
有空请你们的leader多看看书和资料，去查查DAC2011的UVM主题，讲UVM中的tlm2的就是伯格龙老兄，synopsys公司的，实在不行请你们高层协调一下新思的资源，给你们制定一个转换路线。
路线大致说两句：vera是捐献给SV的，所以synopsys在VMM上特别用心（所有早一点推出来），从vera到vmm再到uvm，怎么可能走不通呢?UVM还要不要基于SV来开发了?
你说了这么多，除了证明你们的团队不思进取，我真看不出来还有什么内容！


所以说，技术上的革新都是被动的。革命在西方就是贬义词，大家更喜欢用进化，而进化本来就有被动适应的意思。
验证方法学只是一个手段，产品才是目的。对于pm来讲，最好是可以使用最简单的技术来完成任务。这就是工程和研究的区别！
LZ:请不要说一些似是而非的东西，我自认为想引导大家走向一个正确的职业道路，不希望象这种水平的来浑水摸鱼！
如果你的验证平台在设计freeze之后，每一周都能找出若干个bug，我想pm不会觉得你的工作有多出色而是对你的验证感到绝望。
LZ:很不好意思，pm是对你的工作感到绝望的，一个正规的验证过程的bug/时间曲线是个指数曲线，而不是你现在的状况！

我这里所说的验证可靠性，是指的是在流片之前pm有多大的信心来保证芯片回来是work的。
LZ:请不要越描越黑，我们是做技术的，说话要有依据。流片成功不是靠PM的信心，而靠科学地客观地设置一些流片条件来保证！合理而有效地设置这些条件，是PM应该因地制宜的或者坚定不移地执行的。回来能不能工作很大程度上依赖整个团队能否有效地执行PM设置的条件。
如果我的验证平台一个bug都没发现，但是我能保证所有的可能情况都测试过了，你能说这个验证平台不合格吗?
LZ:你还真会钻牛角尖！说句实话，帖子回到这基本上比较完整地了解了你的一个侧面。有一个感觉，你在验证原理和验证技术的学习方面没有形成系统观点，学习中思考量不够，特别是在基础理论上，可以预见你的知识体系相当零散，非常不幸的是，你用自己的臆想去填补了你知识体系中的空余部分，可惜非常遗憾的是，这些臆想绝大多数都是海市蜃楼！我对你的忠告在5年之内还绝对有效！
这样的问题我还是留给初学者思考吧，记住，这种问题在你学习验证理论的时候就应该解决，也就是说在你做学生的时候就应该解决了，可以看看这个问题问的方式，条件这么绝对，答案甚至不是选择题，你以为是本科生考试啊！
BTW:这个问题跟你们团队中的2个精通人士去讨论讨论，看看他们有什么看法吧！
小编认为test case是testbench的一部分（看来你不是这样认为！而我认为除了DUT/DUV外，都是testbench，下面有人说的十年前的老书第一张图就表达了这个意思，你没有看出来，说你基础知识不到位不为过吧，OK！我孤陋寡闻了，你要不把你的理论基础说说吧?原创还是借鉴），我觉得你并没有理解vmm或者ovm的精髓（理由呢?理由呢?一句话就打发了，情何以堪！），。如果仔细研究vmm或者ovm，你就会发现，vmm/ovm花了很大的努力去把二者分开（My God！你把VMM/OVM也算验证平台的一部分了吧！要不把操作系统也算进testbench去算了，怎么说操作系统也是软件哪！CPU就不算了，毕竟是硬件，上面开个玩笑，回去看看OVM的白皮书，有个层次图，以你的起点一定会得到你的结论）。小编说的大客户支持（CAE）里面的工程师是验证架构工程师，所谓验证架构就是开发testbench的人（不知道啊！我看干脆以后IC公司的BOSS给伯格龙他们发工资算了）。而且按照vmm或者ovm的理念，在testbench完成之后，需要改变的只是test case而不是testbench（你这个意见有没有和EDA的AE或者FAE交流过，如果是的话，把这个（些）AE和FAE的名字发给我，我们公司以后他们不用来了）。我们用oop技术去屏蔽验证平台的实现细节，只开放最顶层的部分给test case，就像操作系统向开发者提供api一样。我们把写test case的人看做是验证平台的用户。我们部门20多人精通验证的只有2个人，但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验。如果testbench和test case由同一个人完成，那么当他用1个月的时间写完testbench之后，又要花费3个月去建test case来验证。如果很快有第二版出来，那么他又不得不重复上面的工作，试想在这种情况下，验证工程师除了对他所验证的模块更熟悉之外，在验证方法学上有学到了什么?更可悲的是，当他对设计熟悉到一定程度的时候，很可能会把他熟悉的这部分交给他设计，然后又找一个新人给他做验证，如此循环。（你们组织的现状我可能需要花更长的时间去理解，感觉有几个问题：1）精通验证的人比例太少，我对团队成员的要求是所有人都通晓几个基础，但个人有所突出，有方法学源码精通的、有覆盖率精通的、有脚本精通的、还有其它方面，你们组织的形态很古怪，是历史原因还是人文原因?你是不是2人之一?2）简略解释一下platform、testbench和VIP的概念，假设testcase属于testbench，通过下面的解释，大家会知道为什么有这个属于关系，platform是基于语言和验证方法学而言，范围比后两者更广泛，testbench和VIP是在platform的基础上针对某个IC而言，但后两者有联系也又有区别，按照testbench的定义是完成DUV的输入和观察对应的输出（可选），那么testcase就是完成testbench工作的一个步骤，所以有这个归属关系，为什么说VIP和testbench有联系也有区别呢?我们说testbench一直没有说到RM，只有RM可以不属于testbench，讲到这里应该明白为什么platform的范围更广了吧！当然RM可以不存在，也可以很复杂，如果复杂到可以多个项目重用就快接近VIP了，当然这还不是一个完整意义上的VIP。VIP和testbench的这种我中有你，你中有我的特点决定了要复用，必须基于某个flatform来做，因为必须基于某个具体方法学和语言来做，现在不是十年前个人英雄的时代了，一个人可以从汇编一直做到界面，甚至硬件，基于平台来做可以做到事半功倍。3）现在可以讲讲OVM等等的意义了，方法学提供了一个使用语言的套路，具体讲应用方法学可以很快地搭建好testbench（这话不是我讲的是Mentor的人讲的！相关资料很好找，网上到处都是），使工程师可以尽快投入到RM的开发中，而RM的开发才是验证工程师需要重点投入的部分，如果是多项目的复用，那么RM的开发需要遵照VIP的方式来实现，这个过程当然需要精通验证的人来把握咯，呵呵，换做港台的讲法就是“拿捏”。最后我们来大致分析一下结合hover99的部门情况，只是我觉得很悲哀，有18个人在做可以简化、没有技术含量的工作，另外两个人基本上是神仙，包罗万象，无所不能是其次，还能身体力行地做到做完做好，证据是“我们部门20多人精通验证的只有2个人，但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验”，顺便明码一下，能不能把那两人的电话给我，我给业界的朋友们推荐推荐！中国IC界太需要这样的人才了！），。
实际情况是，相当一部分验证工程师在工作1，2年后会转为设计，还有一部分会专注于写test case，对他们来讲debug是一个重要能力（话说回来，写RTL和debug自己的RTL都不是什么技术活（如果你维持这种观点的话，对你的忠告也没有什么意义！））。对于那些验证架构工程师来讲更重要的是用软件方式对testbench debug，两种debug根本就不是一回事。
LZ:说句实话我不想回复这部分内容，但为了防止半瓶水害人，也为了防止有人借此来评价我不了解技术细节，算了！好事就做到底了。
本来想写在整段下面，后来发现错误太多，一句一句写算了！这里最后总结一下为什么你错误这么多吗?
因为你开始就错了，开始就把test case和testbench分开看，所以你后来看所以的后续资料都带了个有色眼镜，最惨绝人寰的是，你在错误的轨道中，还不断地用错误的思路来强化错误，诸位围观者不要以为这会负负得正，只能是技术地狱再往下一层。

很厌烦换马甲出来的行为，是谁我不猜了，但这是阴险小人的行径，只能让人鄙视你。
对于这个回帖，我只会毫不留情！
这里把底线划在这里，注册马甲进行攻击的，一律BS加鄙视！
有能耐你就真刀实枪地站出来讲，总想躲在阴暗的角落，不是有健康心理的人的行径。
下次有类似情况，先问侯你家人！

一直在潜水，本帖虽然是验证漫谈，但是rhythm1988通篇只做了3件事：抱怨国内的环境
（I服了you，你用“抱怨”这个词QJ了所有做验证的人，很遗憾的是，也许是这个工作QJ了你，而不是我们所有人。
我写这个帖子，是为了有志于做好验证工作，进而可以有尊严地做个工程师的人提供一个思路。
只有那些整天躲在阴暗角落、苟延残喘的人才会用抱怨这个词！）
，重复10年一本老书的观点
（ 这更好笑了，诸位这辈子学的书有几本小于十年的！或者你给大家指导一本新一些的验证基础的书，说说感想?敢不敢?）
，最后又崇拜了一下洋人。
（“崇拜洋人”，我还以为你是义和团呢?
自己从来都是得过且过，还妄想出来装B，装了还想高薪，天底下那有那么好的事情。
群众的眼睛是雪亮的，就你这点能耐，还敢站出来撒野！）
（我先问大家一个问题，所谓70%的工作量在验证上，有谁去认真统计或者找过资料来印证的，做过了的不妨举个手。这个提法大概就是97年提出来的，北电有位老兄在98年DAC，发表一篇论文是关于多芯片复杂协议系统的开发和验证的，其中说到了这个问题，起先他肯定也怀疑过，怎么办?就在项目中统计一下，所以文章中专门列了一个小节来说明统计了那些，结果是什么?说到这大家都可以猜的到结果。说这个往事的目的是希望大家对自己的职业生涯要严谨和认真，做个有自尊的工程师（人），不要信口开河，知道了一点，可以吹出一头大象来）
看到rhythm1988的团队成员居然看中文资料，我简直要喷饭了。我和同事都是中国人，但是我们写文档发工作mail都用英文，有时候需要用中文写文档反而写不出来。
（惭愧呀！惭愧！我们的团队只想站着当人，不想趴着当狗！只针对一个人！这话还能拿出来显摆，这不是阿Q吗！）
仔细看了rhythm1988的回帖，确实有领导风范，就是说你不行，你的层次不够，具体那不行就要靠自己的慧根了，真是牛人！记得当年打cs的时候，大家都讨论那种枪厉害，突然有人说真正的牛人就是用匕首也能杀人，你们的讨论层次太低，于是被大家无比崇拜，结果打起来却发现水平so so。所以大家得到一个结论，要想做牛人，绝对不能展现出自己的实力，要说些似是而非的话，最重要的是要掩饰自己的观点。比如大家在讨论肉车的时候，明明你非常赞同，但是你也要说：没有肉车只有肉人。
（多年前我也玩CS，后来玩不动了，主要是费时间，体力也更不上了，其实大家都知道CS最吸引人的地方是团队，上面的说法也只能忽悠一下子猪头三而言，明眼人那能上这当啊，这个道理就像是江湖骗术，从古到今都有，为什么还常盛不衰，道理很简单猪头三不是年年都有，而是天天都有！）
语言只是工具，vmm只是应用，这样一说，别人就不好意思问你这方面的问题了，即便是你一窍不通别人也无法察觉，对你只有仰视。rhythm1988从业10多年了，应该是管理层了吧。这些人对技术细节并不了解，也不屑于了解，不是说这些人水平低，而是说在这个层次的人关心的是flow和宏观问题。但是这些问题不是engineer关心的，flow追求的终极目标就是同样的任务任何人做出来效果都一样，记住体制中是培养不出牛人的。
（我一开始就说了我绝非牛人、高手！VMM/OVM可以很坦诚地和大家讲，我不是专家，专家是厂商的AE和FAE们。任何人有技术问题都可以和厂商联系，即使是没有厂商的学习者，比如：OVM可以上OVMworld去，是个开放论坛，其实Mentor和Cadence的那些专家特别喜欢回答问题，如果是有质量的问题，他们是绝对欢迎的，比如vi的做法就是先在OVM World中讨论出来，最后写到OVM COOKBOOK里去的。这就是心态开放的好处，三人行必有我师！当然问得都是文档和手册已经讲过的问题或者是一些初级问题，回答就不一定那么积极了，也许是让你再看看书或给个链接等）
（既然说到本人的工作内容，就八卦一下。本人不是管理层，那不是兴趣所向，管理的工作繁琐，管理者是我沟通来投钱和投人的，其它的事情我一切帮他搞定的人，到时候就收结果的人，兴趣所在，没办法！
你对管理者和管理工作的理解太肤浅了，幼稚并可笑，不要以为你跟过几个废物点心，就好象看穿了世事一样。
我诚意地奉劝看过本帖的人士，把管理者看成是女（男）朋友，不是对立面，想想你和女（男）朋友还有个互相支持和体谅呢，和管理者不妨也这样。
管理者有其缺点，一定也有优点，人都是这样。这就像是找朋友，如果你实在是容忍对方的缺点，就天涯何处无芳草吧！如果你是个大帅哥，富二代，还怕没有女朋友，工程师的工作是类似的。
最可发一笑的是井底之蛙，总是流着口水，在YY！）
不过看到下面hover99的帖子倒是觉得有些新意，特别注册一个id来谈谈我的观点。本人是designer，也懂一点vmm，不过我们soc的验证环境还是verilog的。以我的经验来看，bug往往出现在你认为不会出现bug的地方，让designer自己验自己的design，总觉得不靠谱。其次，hover99所说的只改testcase不该testbench，我觉得过于理想化了，假设设计要求增加错误检测功能需要driver产生error injection，这个时候除了改testbench还有别的方法吗?
（你这个马甲比hover99还差一些，error注入的问题，是要改testbench吗?有没有学过OOP，有没有学过设计模式?错误注入类总的思路采用工厂模式在testbench中调用的，还修改testbench?以你的经验来看，验证这两个字都不知道怎么写的，还来谈验证！
为了防止你还是无中生有，错误注入的问题可以多说两句，整个错误注入的策略是以工厂模式为基础，可能包括其它设计模式，动静结合的复合策略。如何实现好，可以算是一个验证平台实现的亮点！
这么基础的思路你都不了解，还敢说懂一点VMM，VMM的那本书很怀疑有没有认真看啊！
BTW:soc的验证环境是不是verilog或SV不重要，重要的是你们的人才是否能支撑达到验证的那些目的，如果你是Leader，很悬，具体原因看上面一个回复的内容）

看牛人争吵，很有新意。
不过error injection确实不需要改动testbench。

都是牛人啊！

我已经说了我是designer，在验证上面你怎么挖苦我都无所谓。要不是我们的团队需要做正规的verification，我才懒得注册id呢，没那个闲工夫。hover99，我已经把我的联系方式短消息给你了。如果有兴趣可以和我联系。
vmm除了generator之外有工厂模式吗?我知道error injection可以通过callback来实现，但是事先没有加callback，如何来实现error injection。
没想到对小编冷嘲热讽了一下，小编居然气急败坏到要问候我的全家。还好小编没啥权利，否则我恐怕还有灭门的危险。

还是讨论问题本身吧。
VMM需要callback来实现才能实现error injection，OVM和UVM用factory 可以实现。

1）不要以为本人在design上就没有资格批评你，本人的设计生涯只比验证要长，是单纯的时间跨度，不是夹杂的时间段哦！要不你也写个设计体会，让我也冷嘲热讽一次，也做一次小人?很不好意思本人是跨界发展！
2）下面回答begineer001的问题也顺便帮你解个疑惑，让你占个便宜，因为你的人格我很鄙夷！
3）小人以退为进的风格不是没见过，哦！你说过很忙的，估计也没时间写设计体会了，又是我多情了。

你已经到门口了，如果VMM是callback，而ovm是工厂，又没有人规定VMM只能在一个地方用工厂模式，那么你就把工厂套在VMM上面就行了,这就是平台的工作。
其实，VMM的错误注入就是工厂模式，callback只是实现手段而已，只是VMM的错误注入方式，包括OVM的工厂，我还嫌不够灵活，在目前的错误注入的基础上，已经对此进行了创新，在回马甲的帖子中已经写出来策略了，不具体讲，这是吃饭的家伙。已经指了路，有悟性的人只好自己去琢磨，抱歉！
BTW:
有个怀疑希望是错觉，hongjian77是不是你的马甲?因为你们都太关心错误注入的问题，而这个问题我说过了是平台的亮点部分，很考验设计平台人员的综合素质。
任何验证平台只要一天没有在错误注入上有突破，那永远是瘸腿的验证平台。
诸位有没有注意到几个方法学上，在错误注入上都没有说具体，老外也很鬼的，吃饭的家伙哦！

当然是不是马甲，都无所谓啦，我这个帖子是诺亚方舟，但也只给有缘人。

讨论还蛮激烈的，好像每个人都说的有道理呢，可能只是出发的角度不一样哩，还在慢慢的摸索验证，讨论了才能出新意，让自己看到工作中暂时无法看到的一面，不管怎样，都是为了提高工作效率，完善验证工作。
很早以前刚刚入行的时候是想着未来能有个验证公司，专门做大公司的外包验证，可是自己能力一直都不够哎，讨论归讨论，没有错的也没有对的，有的只是实践中出的真理，是驴子是马拉出来溜溜，希望在众多的高手中能有人干的多点，开个自己的专门验证公司，到时候自然也就牛B了。

小编果然很有经验！

算是开了眼界了，不过希望大家只留下争论，别的什么也别留下...
如果夹杂着人身攻击，就太不绅士了！

非常好，受教了

小菜鸟一个，小编的意思太深，一知半解，很牛，
看一楼的文章写得用来很多道德经的语句，
觉得小编还是挺有文学修养，佩服啊，
只是后面怎么有点掐架呢。
额 当然，非常感谢小编的贡献，
小菜鸟第一次见这种对验证的深入理解，
有点不知所措，
再次 感谢！

俺还是一初学者，是不是谁的马甲就不用我来解释了，最近刚刚看了一点VMM、OVM、UVM的资料，碰巧看到了关于error injection这个地方，所以才无意说了两句，请不要误会，呵呵！

支持啊！

realygc说得很委婉！
关于我的方式和态度问题，我这里最后罗嗦一下。
对于hover99，基于对他在验证上落后比较多的判断，抱着良药苦口利于病，忠言逆耳利于行的心态，用的醍醐灌顶的手段。
在我读书的年代，还有一些老教师是从苏联那个体系来的，学术态度和研究精神无可挑剔，以身做则，写论文就是一个标点符号错误，也会挑出来！我希望在和hover99的互动中，重点在研究心态上给他一些启示，顺便也给围观者一点帮助，即我们可以在具体技术上落后于人，我们一定不能永远在做事情的方式方法上落后于人。如果是这样的话，我们的工作就永远没有尊严可言！
我们是做自然科学领域，不是人文领域，在自然科学领域的做事情的方式方法，其实诸位在大学的校训上都有，各位凭良知自问一下，有没有做到?做到了多少?
如果在讨论中，对他和诸位有不到之处，请多包涵！
对于hongjian77之流的小人行径，我的态度基本上是零容忍，这类型的人在任何技术团队中，都是害群之马，永远都是一颗定时炸弹。这么说并不是讲小人，不可以没有技术水平，而是对于一个团队来讲，小人行为永远都是不合适的，这是两码事情，要分开看。小人可以玩权术、玩阴谋、沽名钓誉、可以当领导，但绝对不适合在任何一个技术团队中生存。
说到老庄，不外儒道释，西方是圣经，本人没有资格评论。
不过，各位如果有空去西藏，或者去过西藏的，有没有注意一个现象：很多佛都是有两个形态，在面对芸芸大众上，永远是慈眉善目的端庄之态，在面对恶魔时，体态相貌比恶魔有过而无不及，只有少数几位可以做到千面不变。
我自问还没有修行到那个程度，对于小人，请不要在我面前晃来晃去，否则我会比你还小人！
不要以为躲起来玩阴的，就可以了，跟我玩这套，你还嫩了写 。
再重申一遍，本帖谢绝小人进入！

我是一个晚辈，大牛们在专业领域的讨论，我插不上话 。
对于 rhythm1988 ，我非常佩服你的专业水平，觉得那是我需要很多年才能达到的。你现在应该在管理一个挺大的团队了吧，但是觉得你的火气有点大，不知道是不是因为恨铁不成钢的原因。
我是一个FPGA 的designer ，从事三年了，感觉以后的路子越来越窄了。想往ASIC靠，但是又不知道怎么走好。

我想前辈如果在学校的话，
一定是个收人尊敬的教授，
当然在业界也许可以做更多的实事，
非常感谢前辈的指教！
P.S. 我想除了小时候遇到这样的严师，
我已经快忘记这样令人尊敬的老师了。
祝小编可以为国内的IC事业做出伟大的事业，
我想每个国内IC人都有这样的梦想吧！