验证漫谈
From_eetop
LZ：rhythm1988
为了增加可信度，先八卦一下本人的经历，本人从事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这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
==========================================
hover99
本来也想写一篇关于验证的文章，没想到被楼主抢先了。
其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。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公司的支持，所以我认为验证服务还是有市场的。
==========================================
rhythm1988 回复 hover99
1. 本来也想写一篇关于验证的文章，没想到被楼主抢先了。
其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。
LZ：有一个理论叫冰山理论，也许你看见的和听说的，只是水面上的部分，可能水下的部分更多。
一般老外的工程师都相当严谨，没有把握的东西一般不拿出来show。
2. ic公司关心的是产品，工程师反而没有太多精力去搞什么方法学，即便搞出来也会受到项目组的抵制（假如现有的平台已经成功流片了多个产品，你会推翻它再搞一套新的吗）。
LZ：很多公司都是死在这种思路上，具体讲，中层没有动力去更新自己，导致支持不了高层的策略，公司慢慢地就落伍了。这种温水煮青蛙的例子太多了。
举个例子：5、6年前的soc项目，现在可能只是一个subsystem，如果是你做验证怎么办？以不变应万变？
没有精力去搞？项目组也抵制？能不能PM给我那些公司?以后听说谁去那个公司要小心。
你说的情况只存在于老的项目中，项目处于维护状态，才停滞下来。BOSS也不会投入在已经不需要大量投入的项目。
3. 验证的目的是保证产品在多大程度上是可靠的，而不是找到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.
4. 另外，本人认为验证工程师水平比较低的原因大部分验证工程师将大部分的时间花在建test case上，结果大致大部分人认为验证是一个技术含量比较低的工作，有一两年经验马上转去做设计。
LZ：test case是testbench的一部分，花时间构筑test case无可厚非，但将此作为验证工程师水平比较低的理由，就有点不靠谱了！
不能因为也许是你的环境是这样，就认为是这样的逻辑关系。
给你一个忠告：有机会就找个好的团队，正规地培养一下。
5. 如果把debug能力作为验证工程师的重要素质，那么培养验证工程师的方向完全错了。
LZ：debug能力是整个IC行业，乃至整个IT行业的基本而且重要的能力，相比较起来，会不会验证或者什么方法学都没有那么重要！简单地讲，靠debug能力可以吃一辈子饭，其它的技术可就不一定了。
6. 个人认为验证方法学主要解决三个问题，复用；testbench和test case的分离；testbench的鲁棒性。第一个问题（不仅包括项目之间的横向复用更包括自底向上的垂直复用）没啥好说的，无非就是节省工作量。第二个问题的本质就是分工，建test case的工程师需要对产品本身有更深入的了解，甚至就是设计工程师。第三个问题最关键，高效率的工作写testbench和设计基本上同步进行，这样就会导致写testbench的时候，设计是不确定的，极端情况是你的验证工作已经完成，这个时候设计突然改动了，这个时候就能体现出一个高水平的验证工程师的价值。
LZ：相信上面这段内容是你思考的结果，不过很可惜只得皮毛，另外还有一些偏差，限于篇幅原因，不展开讲。
等你上了一个台阶的话，自己再来看你的理解。从整个描述讲，贵公司在整个开发流程上还有相当多的漏洞或者不足。
7. 所以从这一点上看，OVM比VMM1.1先进一代（VMM1.2基本上和OVM没啥区别），OVM比VMM晚了2年，技术上先进也是合理的。
LZ：没有必要纠结这个问题，有一句话，批判的武器不如武器的批判，OVM有历史继承性，并不是晚的原因，技术上也没有先进性，所谓先进与否要从基础原理上看，比如：OOP等等。
最后，所谓中文译本基本上都是学生翻译的，而且很多术语根本就没有翻译标准。最好的参考资料就是英文的ref guide。当年夏老师那本verilog还是公认的有水平。
LZ:所谓水平要分层次，语言是拿来用的，XIA老师的verilog后来是人手一本了，仿佛当年谭校长的c语言，可是语言之外还有很多东西。作为一部介绍Verilog的教材够了，所以我说至多水平不够高，呵呵。。。
==========================================
hover99
很不幸，本人就在楼主所说的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根本就不是一回事。
================================================
hongjian77
一直在潜水，本帖虽然是验证漫谈，但是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还有别的方法吗？
=====================================================
rhythm1988
回复 hover99
很不幸，本人就在楼主所说的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分开看，所以你后来看所以的后续资料都带了个有色眼镜，最惨绝人寰的是，你在错误的轨道中，还不断地用错误的思路来强化错误，诸位围观者不要以为这会负负得正，只能是技术地狱再往下一层。
回复 hongjian77
很厌烦换马甲出来的行为，是谁我不猜了，但这是阴险小人的行径，只能让人鄙视你。
对于这个回帖，我只会毫不留情！
这里把底线划在这里，注册马甲进行攻击的，一律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，很悬，具体原因看上面一个回复的内容）
=============================
对于hover99，基于对他在验证上落后比较多的判断，抱着良药苦口利于病，忠言逆耳利于行的心态，用的醍醐灌顶的手段。
在我读书的年代，还有一些老教师是从苏联那个体系来的，学术态度和研究精神无可挑剔，以身做则，写论文就是一个标点符号错误，也会挑出来！我希望在和hover99的互动中，重点在研究心态上给他一些启示，顺便也给围观者一点帮助，即我们可以在具体技术上落后于人，我们一定不能永远在做事情的方式方法上落后于人。如果是这样的话，我们的工作就永远没有尊严可言！
我们是做自然科学领域，不是人文领域，在自然科学领域的做事情的方式方法，其实诸位在大学的校训上都有，各位凭良知自问一下，有没有做到？做到了多少？
如果在讨论中，对他和诸位有不到之处，请多包涵！
对于hongjian77之流的小人行径，我的态度基本上是零容忍，这类型的人在任何技术团队中，都是害群之马，永远都是一颗定时炸弹。这么说并不是讲小人，不可以没有技术水平，而是对于一个团队来讲，小人行为永远都是不合适的，这是两码事情，要分开看。小人可以玩权术、玩阴谋、沽名钓誉、可以当领导，但绝对不适合在任何一个技术团队中生存。
==========================================
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
回复 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的原则，其它的都是技术手段。现在提出来给你参考。
最后，忍不住在回帖中又写了点！还有一些你对我的猜测，只能由你了。
================================
Loglong
好久没来论坛, 终于第一次看到了一篇有营养的验证文章, 说什么也要回复.
向楼主学习, 也八卦一下经历, 只有让别人了解自己的背景, 很多话才能说清楚. 我毕业4年, 全职接触IC6年, 设计验证都做过, 但主要还是做验证, 在假洋鬼子和纯洋鬼子的公司都呆过, 现使用specman+e...好了, 很多人知道了....
首先感谢楼主无私的分享, 从回复中的谢谢就看出楼主对我们新人的帮助了. 再次谢谢楼主!!!
当然我也不是只进不出, 下面谈谈我不太明白的地方或者我看了楼主的帖子后提高的地方, 算是读书笔记, 帮助像我一样还不能完全理解楼主的人, 应该很多吧. :-)
1. 翻译的问题. 这个我有体会, 本科时使用XIA老师的书, 没看明白他想说什么.后来一直坚持看英文原版的书, 突然有一天, 看了一下XIA老师的书, 发现如果你看完了英文版的话, 去看中文版没问题. 但是你先看的中文版, 能不能理解就要靠你的悟性了, 因为一个专业名字一翻译, 就有了很多专业名字, 你要确保你理解了这个词的背后啥意思才行啊.而且这是一个外国人主导的行业, 和他们使用一样的语言有助于今后讨论问题的时候减少歧义, 当然现在的中文翻译越来越多, 也越来越规范, 只要大家说的是一个东西, 说什么话我觉得不关键. 但是为了更好的理解作者的意思, 我建议用作者的语言阅读, 就像你用英语读唐诗, 你确定你知道他要说什么吗?
2. 验证的现状由于我经历太少, 没啥好讨论的.
3. 验证的技术, 我觉得方法学和语言都是相通的, 都是对一些验证方法的不同实现, 无所谓谁好谁坏, 看你用什么顺手吧. 以前我觉得OOP好, 结构清晰, 巨不适应E的AOP方法, 但现在用习惯了, 觉得各有优劣, 有灵活性就要牺牲一些可读性.
1）IC上所有的工作都是殊途同归，唯一限制你的只有你的眼界，把眼光放远一点；
--- 很认同, 我觉得要花更多的时间去了解设计, 和设计的应用(application).
2）做事情要踏实，贪多嚼不烂，学多，不如学精，等能力上了一个台阶后，其它基本上触类旁通了，就好像武打小说的任督二脉，没打通，什么都白搭； --- 在突破, 发现验证要做好, 真的是博大精深啊, 起码像我这样非软件背景的, 对C++等都只是略知皮毛, 还有很长的路要走.
3）把基础打扎实，多看看老外的书，深入体会一下老外的思路和想法，比如：把VMM之类的搞懂了，还得想想为什么？本来想讲讲学习路线图，不过这属于技术经验，只供BOSS使用，另外讲了对初学者没有好处，这是一个复杂的多方位的学习体系，必须由leader来领路； --- 这样行不行: SystemVerilog for verification -> A Practical Guide to adoping UVM -> The C++ Programming Language -> 用C++作为testbench, 用SV作为BFM搭建平台, 和UVM或者eRM比较孰优孰劣.
4）IC这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
--- 看来我事倍功半了. :-)
回复 hover99,
我觉得我们的经历比较相似, 所以你说的话我理解了, 但是我对C和VMM的水平明显不如你, 以后请多指教. 呵呵.
本来也想写一篇关于验证的文章，没想到被楼主抢先了。
--- 你也可以开贴啊, 就像验证, 没有说我写了这个case了, 就不能其他人来cross cover.
其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。ic公司关心的是产品，工程师反而没有太多精力去搞什么方法学，即便搞出来也会受到项目组的抵制（假如现有的平台已经成功流片了多个产品，你会推翻它再搞一套新的吗）。
--- 大公司的技术确实保守, 但是是居于已有项目的保守, 他没必要说设计不变, 且成功流片了, 再采用新的验证方法来再验证一遍吧, 我们公司也想从e转到VMM或者UVM, 但是对已有项目可能不太现实, 因为很多VIP都稳定了. 但是不能说大公司没有实力去采用新的验证方法, 像IBM, 我用过他们的后端的一些工具, 其实挺强大的, 也是现在市面上没有的. 而我们公司是设计公司, 核心技术也是设计上, 验证就采用了Cadence的标准流程, 我觉得Cadence的验证水平很高啊.
验证的目的是保证产品在多大程度上是可靠的，而不是找到bug。另外，本人认为验证工程师水平比较低的原因大部分验证工程师将大部分的时间花在建test case上，结果大致大部分人认为验证是一个技术含量比较低的工作，有一两年经验马上转去做设计。如果把debug能力作为验证工程师的重要素质，那么培养验证工程师的方向完全错了。
--- 我觉得验证的目的就是找BUG. 你想说的是不是验证水平和项目中找到bug的数量不成正比?
个人认为验证方法学主要解决三个问题，复用；testbench和test case的分离；testbench的鲁棒性。第一个问题（不仅包括项目之间的横向复用更包括自底向上的垂直复用）没啥好说的，无非就是节省工作量。第二个问题的本质就是分工，建test case的工程师需要对产品本身有更深入的了解，甚至就是设计工程师。第三个问题最关键，高效率的工作写testbench和设计基本上同步进行，这样就会导致写testbench的时候，设计是不确定的，极端情况是你的验证工作已经完成，这个时候设计突然改动了，这个时候就能体现出一个高水平的验证工程师的价值。所以从这一点上看，OVM比VMM1.1先进一代（VMM1.2基本上和OVM没啥区别），OVM比VMM晚了2年，技术上先进也是合理的。
--- 很同意你的观点, 也说明我俩水平差不多哈:-), 或者说我们都是Synopsis和Cadence的受害者, 因为他们就是这样教我们的.
回复hongjian77
专业论坛和一般论坛还是有区别的, 因为这里都是学历比较高的, 最受不了别人的冷嘲热讽, 你是我老板也不行. 别人用中文, 像海思, 像很多本土公司, 是为了交流方便, 你一下得出那么多结论来, 说明你是一个很好的工程师(联想丰富), 但是还不会尊重别人, 或者说自视过高.
假设设计要求增加错误检测功能需要driver产生error injection，这个时候除了改testbench还有别的方法吗？
--- 在specman+e的AOP环境中, 你可以在case中扩展(extend)出一个新的类型, 然后发下去, 我觉得specman最灵活的地方就在这了, 哪里都可以随意的修改源代码, 但是就是太乱了, 不熟悉架构的人, 完全不知道哪里drive的. 如果一些checker报错了, 可以在case中把这些checker关掉, 或者把checker从error改成warning, 再在case结束时使用关键字匹配看看这些checker是不是报过warning出来.
--- 在OOP的环境中, 例如UVM的书上, 使用factory, 但是factory换的东西比较多, 如果在class中预留一些callback, 那么就很容易实现AOP的对于代码的增加和修改, 我对UVM仅停留在实习阶段, 对VMM一窍不通, 所以错了不要怪我.
我现在觉得eRM/UVM/VMM这些方法学都很好, 都能用constraint random + functional coverage来保证验证的可靠性, 使用virtual sequencer, signal map等来保证reuse, 且把验证的人分成testbench developer和testcase writer对工作进行细分, 让我感觉很不错啊, 但是好像很多本土公司都喜欢采用C++/C/SC作为验证平台, 使用SV/Verilog作为BFM(bus function model), 是不是因为license要花钱的原因? 还是希望把技术掌握在自己手里? 我列了几点不理解的地方, 希望懂得人给我介绍一下:
1. 用C能实现random, 但是其random能像specman那么强大吗? 就是如果A random 到了一个值, B根据这个A的random范围再random, 当然要实现肯定是可以的, 但是如果环境是verilog, 然后通过DPI去调C的话, 是不是调用太多次C之后导致速度下降. 能给我详细介绍下C+SV平台的random激励产生过程吗?
2. Coverage在那一层实现? 应该要在transaction level吧, 那就是C里面了, 怎么实现的?
3. 像ncsim和vcs都对其支持的语言做了优化, 例如specman+ncsim就比specman+vcs快很多, 而且使用方便, 不知道C+ncsim或C+vcs, 只用DPI接口调用函数会不会导致仿真速度下降? 一般跑一个SOC subsystem的block level的测试平台速度怎么样? (我也不知道怎么衡量啊....)
============================================
rhythm1988
写点东西讨论讨论前面的几个问题：
1）关于验证的目的的问题，迄今为止只有一个目的“设计是否满足了spec”，既不是可靠性，也不是bug，从《writing testbenches》第一个版本迄今，没有任何一本书修改了这个概念。
如果哪位知道这个目的修改了，记得通知我学习学习。
关于这个目的可以稍微多讲一点，可靠性就有点不着边际了，找bug呢有点靠谱，但要分清楚bug是手段，不是目的，手段和目的混淆了，团队容易舍本逐末，这个应该不难理解。
2）36#的spec修改问题
首先，理论上spec的修改应该有版本的概念，当然实际上没有那么严格，spec的修改的确是常事，这是现实情况，不扩展讲团队怎么解决这个问题，但也不能忘了写spec是一个有艺术的活，做个类比吧，基本上就是孙悟空给唐僧画的圈圈。
其次，我们聚焦在验证团队如何应对spec的修改，spec都修改了，testbench没有道理不修改（modify），其实我很想从讲各种书上看到说不用modify这样的字眼，不过很遗憾，暂时没有！
再次，既然testbench的修改是不可以避免的，那也不是随心所欲，业界引入OOP等等，有一个目的是使修改量最少，当然不是单纯针对spec的演进问题。
最后，如何使修改量最少呢？使用方法学是个很好的手段，但更基本的是OOP的五大原则，特别是OCP原则（请各位有兴趣去看《敏捷软件开发》的相关章节，有详细的解释），具体的方法在《设计模式》这本书里面。
结论：针对多变的spec的验证场景，基于OOP的原则，合理搭配设计模式，把修改合理开放出来。
没有更多的东西！进一步的内容在你自己的实践中。
3）关于callback的问题（最后一次谈关于方法学先进与否的问题）
单纯地说callback不好或者好，不先进或者先进，那是藐视业界专家们的智慧，可以设想在是否使用callback的问题上，一定有个非常激烈的讨论，这是可以想象的。
callback破坏了类的内聚性，把修改交给了一个函数去实现（请不要和重写等等混淆了），可以说是OOP的大忌，但带来了灵活性，鱼和熊掌，怎么办？
这时候就有“专家”的作用，依据软件的规模，应用场景，包括其它限制条件，来决定是否使用。即使我用VMM的方法学，也可以绕过callback不使用，而达到callback的所有目的，这个权衡就需要“专家”，不是EDA的专家，而是验证团队中的专家。
而“专家”不能说拍脑袋说用就用，而是指定一个完整的使用策略，制定使用规则，把相关的不利因素限制在最小范围之内。
4）关于学习路线问题
依据业界的惯例，前十年都是基础工程师阶段，十年级别的出来做presentation，都基本不够格，二十年的都要好好地介绍一下自己的简历才可以。
所以，像我们这种人还要什么路线，什么都可以，找一个团队，随便什么语言都先好好吃个三五年，比如SV的communication机制，你学了三种，再想想为什么是这三种，其他的进程和线程通讯机制为什么不放进来，由点及面，这东西多了去了。
技术这条道路没有“九还丹”什么的，吃了就直接打通任督二脉，百毒不侵什么的。当然这么说并不是没有什么加速的手段，比如：良好的团队氛围，专家型领导的指导等等，但这些都是次要的，辅助的，这些只是让人少走弯路，为了做事情的方便（一般而言，走了弯路也不是坏事！）
关键还是在于自己，“知行合一”！
总而言之：
我和各位不在同一个环境中，我对各位的自身条件，团队情况，历史条件等等等等客观因素无从了解，说句实话也没有条件和义务去了解，所以我没有办法就具体问题来讨论，只能虚头八脑地讲喽！希望大家能理解！
 |
LZ：rhythm1988
为了增加可信度，先八卦一下本人的经历，本人从事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这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
==========================================
hover99
本来也想写一篇关于验证的文章，没想到被楼主抢先了。
其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。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公司的支持，所以我认为验证服务还是有市场的。
==========================================
rhythm1988 回复 hover99
1. 本来也想写一篇关于验证的文章，没想到被楼主抢先了。
其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。
LZ：有一个理论叫冰山理论，也许你看见的和听说的，只是水面上的部分，可能水下的部分更多。
一般老外的工程师都相当严谨，没有把握的东西一般不拿出来show。
2. ic公司关心的是产品，工程师反而没有太多精力去搞什么方法学，即便搞出来也会受到项目组的抵制（假如现有的平台已经成功流片了多个产品，你会推翻它再搞一套新的吗）。
LZ：很多公司都是死在这种思路上，具体讲，中层没有动力去更新自己，导致支持不了高层的策略，公司慢慢地就落伍了。这种温水煮青蛙的例子太多了。
举个例子：5、6年前的soc项目，现在可能只是一个subsystem，如果是你做验证怎么办？以不变应万变？
没有精力去搞？项目组也抵制？能不能PM给我那些公司?以后听说谁去那个公司要小心。
你说的情况只存在于老的项目中，项目处于维护状态，才停滞下来。BOSS也不会投入在已经不需要大量投入的项目。
3. 验证的目的是保证产品在多大程度上是可靠的，而不是找到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.
4. 另外，本人认为验证工程师水平比较低的原因大部分验证工程师将大部分的时间花在建test case上，结果大致大部分人认为验证是一个技术含量比较低的工作，有一两年经验马上转去做设计。
LZ：test case是testbench的一部分，花时间构筑test case无可厚非，但将此作为验证工程师水平比较低的理由，就有点不靠谱了！
不能因为也许是你的环境是这样，就认为是这样的逻辑关系。
给你一个忠告：有机会就找个好的团队，正规地培养一下。
5. 如果把debug能力作为验证工程师的重要素质，那么培养验证工程师的方向完全错了。
LZ：debug能力是整个IC行业，乃至整个IT行业的基本而且重要的能力，相比较起来，会不会验证或者什么方法学都没有那么重要！简单地讲，靠debug能力可以吃一辈子饭，其它的技术可就不一定了。
6. 个人认为验证方法学主要解决三个问题，复用；testbench和test case的分离；testbench的鲁棒性。第一个问题（不仅包括项目之间的横向复用更包括自底向上的垂直复用）没啥好说的，无非就是节省工作量。第二个问题的本质就是分工，建test case的工程师需要对产品本身有更深入的了解，甚至就是设计工程师。第三个问题最关键，高效率的工作写testbench和设计基本上同步进行，这样就会导致写testbench的时候，设计是不确定的，极端情况是你的验证工作已经完成，这个时候设计突然改动了，这个时候就能体现出一个高水平的验证工程师的价值。
LZ：相信上面这段内容是你思考的结果，不过很可惜只得皮毛，另外还有一些偏差，限于篇幅原因，不展开讲。
等你上了一个台阶的话，自己再来看你的理解。从整个描述讲，贵公司在整个开发流程上还有相当多的漏洞或者不足。
7. 所以从这一点上看，OVM比VMM1.1先进一代（VMM1.2基本上和OVM没啥区别），OVM比VMM晚了2年，技术上先进也是合理的。
LZ：没有必要纠结这个问题，有一句话，批判的武器不如武器的批判，OVM有历史继承性，并不是晚的原因，技术上也没有先进性，所谓先进与否要从基础原理上看，比如：OOP等等。
最后，所谓中文译本基本上都是学生翻译的，而且很多术语根本就没有翻译标准。最好的参考资料就是英文的ref guide。当年夏老师那本verilog还是公认的有水平。
LZ:所谓水平要分层次，语言是拿来用的，XIA老师的verilog后来是人手一本了，仿佛当年谭校长的c语言，可是语言之外还有很多东西。作为一部介绍Verilog的教材够了，所以我说至多水平不够高，呵呵。。。
==========================================
hover99
很不幸，本人就在楼主所说的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根本就不是一回事。
================================================
hongjian77
一直在潜水，本帖虽然是验证漫谈，但是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还有别的方法吗？
=====================================================
rhythm1988
回复 hover99
很不幸，本人就在楼主所说的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分开看，所以你后来看所以的后续资料都带了个有色眼镜，最惨绝人寰的是，你在错误的轨道中，还不断地用错误的思路来强化错误，诸位围观者不要以为这会负负得正，只能是技术地狱再往下一层。
回复 hongjian77
很厌烦换马甲出来的行为，是谁我不猜了，但这是阴险小人的行径，只能让人鄙视你。
对于这个回帖，我只会毫不留情！
这里把底线划在这里，注册马甲进行攻击的，一律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，很悬，具体原因看上面一个回复的内容）
=============================
对于hover99，基于对他在验证上落后比较多的判断，抱着良药苦口利于病，忠言逆耳利于行的心态，用的醍醐灌顶的手段。
在我读书的年代，还有一些老教师是从苏联那个体系来的，学术态度和研究精神无可挑剔，以身做则，写论文就是一个标点符号错误，也会挑出来！我希望在和hover99的互动中，重点在研究心态上给他一些启示，顺便也给围观者一点帮助，即我们可以在具体技术上落后于人，我们一定不能永远在做事情的方式方法上落后于人。如果是这样的话，我们的工作就永远没有尊严可言！
我们是做自然科学领域，不是人文领域，在自然科学领域的做事情的方式方法，其实诸位在大学的校训上都有，各位凭良知自问一下，有没有做到？做到了多少？
如果在讨论中，对他和诸位有不到之处，请多包涵！
对于hongjian77之流的小人行径，我的态度基本上是零容忍，这类型的人在任何技术团队中，都是害群之马，永远都是一颗定时炸弹。这么说并不是讲小人，不可以没有技术水平，而是对于一个团队来讲，小人行为永远都是不合适的，这是两码事情，要分开看。小人可以玩权术、玩阴谋、沽名钓誉、可以当领导，但绝对不适合在任何一个技术团队中生存。
==========================================
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
回复 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的原则，其它的都是技术手段。现在提出来给你参考。
最后，忍不住在回帖中又写了点！还有一些你对我的猜测，只能由你了。
================================
Loglong
好久没来论坛, 终于第一次看到了一篇有营养的验证文章, 说什么也要回复.
向楼主学习, 也八卦一下经历, 只有让别人了解自己的背景, 很多话才能说清楚. 我毕业4年, 全职接触IC6年, 设计验证都做过, 但主要还是做验证, 在假洋鬼子和纯洋鬼子的公司都呆过, 现使用specman+e...好了, 很多人知道了....
首先感谢楼主无私的分享, 从回复中的谢谢就看出楼主对我们新人的帮助了. 再次谢谢楼主!!!
当然我也不是只进不出, 下面谈谈我不太明白的地方或者我看了楼主的帖子后提高的地方, 算是读书笔记, 帮助像我一样还不能完全理解楼主的人, 应该很多吧. :-)
1. 翻译的问题. 这个我有体会, 本科时使用XIA老师的书, 没看明白他想说什么.后来一直坚持看英文原版的书, 突然有一天, 看了一下XIA老师的书, 发现如果你看完了英文版的话, 去看中文版没问题. 但是你先看的中文版, 能不能理解就要靠你的悟性了, 因为一个专业名字一翻译, 就有了很多专业名字, 你要确保你理解了这个词的背后啥意思才行啊.而且这是一个外国人主导的行业, 和他们使用一样的语言有助于今后讨论问题的时候减少歧义, 当然现在的中文翻译越来越多, 也越来越规范, 只要大家说的是一个东西, 说什么话我觉得不关键. 但是为了更好的理解作者的意思, 我建议用作者的语言阅读, 就像你用英语读唐诗, 你确定你知道他要说什么吗?
2. 验证的现状由于我经历太少, 没啥好讨论的.
3. 验证的技术, 我觉得方法学和语言都是相通的, 都是对一些验证方法的不同实现, 无所谓谁好谁坏, 看你用什么顺手吧. 以前我觉得OOP好, 结构清晰, 巨不适应E的AOP方法, 但现在用习惯了, 觉得各有优劣, 有灵活性就要牺牲一些可读性.
1）IC上所有的工作都是殊途同归，唯一限制你的只有你的眼界，把眼光放远一点；
--- 很认同, 我觉得要花更多的时间去了解设计, 和设计的应用(application).
2）做事情要踏实，贪多嚼不烂，学多，不如学精，等能力上了一个台阶后，其它基本上触类旁通了，就好像武打小说的任督二脉，没打通，什么都白搭； --- 在突破, 发现验证要做好, 真的是博大精深啊, 起码像我这样非软件背景的, 对C++等都只是略知皮毛, 还有很长的路要走.
3）把基础打扎实，多看看老外的书，深入体会一下老外的思路和想法，比如：把VMM之类的搞懂了，还得想想为什么？本来想讲讲学习路线图，不过这属于技术经验，只供BOSS使用，另外讲了对初学者没有好处，这是一个复杂的多方位的学习体系，必须由leader来领路； --- 这样行不行: SystemVerilog for verification -> A Practical Guide to adoping UVM -> The C++ Programming Language -> 用C++作为testbench, 用SV作为BFM搭建平台, 和UVM或者eRM比较孰优孰劣.
4）IC这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
--- 看来我事倍功半了. :-)
回复 hover99,
我觉得我们的经历比较相似, 所以你说的话我理解了, 但是我对C和VMM的水平明显不如你, 以后请多指教. 呵呵.
本来也想写一篇关于验证的文章，没想到被楼主抢先了。
--- 你也可以开贴啊, 就像验证, 没有说我写了这个case了, 就不能其他人来cross cover.
其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。ic公司关心的是产品，工程师反而没有太多精力去搞什么方法学，即便搞出来也会受到项目组的抵制（假如现有的平台已经成功流片了多个产品，你会推翻它再搞一套新的吗）。
--- 大公司的技术确实保守, 但是是居于已有项目的保守, 他没必要说设计不变, 且成功流片了, 再采用新的验证方法来再验证一遍吧, 我们公司也想从e转到VMM或者UVM, 但是对已有项目可能不太现实, 因为很多VIP都稳定了. 但是不能说大公司没有实力去采用新的验证方法, 像IBM, 我用过他们的后端的一些工具, 其实挺强大的, 也是现在市面上没有的. 而我们公司是设计公司, 核心技术也是设计上, 验证就采用了Cadence的标准流程, 我觉得Cadence的验证水平很高啊.
验证的目的是保证产品在多大程度上是可靠的，而不是找到bug。另外，本人认为验证工程师水平比较低的原因大部分验证工程师将大部分的时间花在建test case上，结果大致大部分人认为验证是一个技术含量比较低的工作，有一两年经验马上转去做设计。如果把debug能力作为验证工程师的重要素质，那么培养验证工程师的方向完全错了。
--- 我觉得验证的目的就是找BUG. 你想说的是不是验证水平和项目中找到bug的数量不成正比?
个人认为验证方法学主要解决三个问题，复用；testbench和test case的分离；testbench的鲁棒性。第一个问题（不仅包括项目之间的横向复用更包括自底向上的垂直复用）没啥好说的，无非就是节省工作量。第二个问题的本质就是分工，建test case的工程师需要对产品本身有更深入的了解，甚至就是设计工程师。第三个问题最关键，高效率的工作写testbench和设计基本上同步进行，这样就会导致写testbench的时候，设计是不确定的，极端情况是你的验证工作已经完成，这个时候设计突然改动了，这个时候就能体现出一个高水平的验证工程师的价值。所以从这一点上看，OVM比VMM1.1先进一代（VMM1.2基本上和OVM没啥区别），OVM比VMM晚了2年，技术上先进也是合理的。
--- 很同意你的观点, 也说明我俩水平差不多哈:-), 或者说我们都是Synopsis和Cadence的受害者, 因为他们就是这样教我们的.
回复hongjian77
专业论坛和一般论坛还是有区别的, 因为这里都是学历比较高的, 最受不了别人的冷嘲热讽, 你是我老板也不行. 别人用中文, 像海思, 像很多本土公司, 是为了交流方便, 你一下得出那么多结论来, 说明你是一个很好的工程师(联想丰富), 但是还不会尊重别人, 或者说自视过高.
假设设计要求增加错误检测功能需要driver产生error injection，这个时候除了改testbench还有别的方法吗？
--- 在specman+e的AOP环境中, 你可以在case中扩展(extend)出一个新的类型, 然后发下去, 我觉得specman最灵活的地方就在这了, 哪里都可以随意的修改源代码, 但是就是太乱了, 不熟悉架构的人, 完全不知道哪里drive的. 如果一些checker报错了, 可以在case中把这些checker关掉, 或者把checker从error改成warning, 再在case结束时使用关键字匹配看看这些checker是不是报过warning出来.
--- 在OOP的环境中, 例如UVM的书上, 使用factory, 但是factory换的东西比较多, 如果在class中预留一些callback, 那么就很容易实现AOP的对于代码的增加和修改, 我对UVM仅停留在实习阶段, 对VMM一窍不通, 所以错了不要怪我.
我现在觉得eRM/UVM/VMM这些方法学都很好, 都能用constraint random + functional coverage来保证验证的可靠性, 使用virtual sequencer, signal map等来保证reuse, 且把验证的人分成testbench developer和testcase writer对工作进行细分, 让我感觉很不错啊, 但是好像很多本土公司都喜欢采用C++/C/SC作为验证平台, 使用SV/Verilog作为BFM(bus function model), 是不是因为license要花钱的原因? 还是希望把技术掌握在自己手里? 我列了几点不理解的地方, 希望懂得人给我介绍一下:
1. 用C能实现random, 但是其random能像specman那么强大吗? 就是如果A random 到了一个值, B根据这个A的random范围再random, 当然要实现肯定是可以的, 但是如果环境是verilog, 然后通过DPI去调C的话, 是不是调用太多次C之后导致速度下降. 能给我详细介绍下C+SV平台的random激励产生过程吗?
2. Coverage在那一层实现? 应该要在transaction level吧, 那就是C里面了, 怎么实现的?
3. 像ncsim和vcs都对其支持的语言做了优化, 例如specman+ncsim就比specman+vcs快很多, 而且使用方便, 不知道C+ncsim或C+vcs, 只用DPI接口调用函数会不会导致仿真速度下降? 一般跑一个SOC subsystem的block level的测试平台速度怎么样? (我也不知道怎么衡量啊....)
============================================
rhythm1988
写点东西讨论讨论前面的几个问题：
1）关于验证的目的的问题，迄今为止只有一个目的“设计是否满足了spec”，既不是可靠性，也不是bug，从《writing testbenches》第一个版本迄今，没有任何一本书修改了这个概念。
如果哪位知道这个目的修改了，记得通知我学习学习。
关于这个目的可以稍微多讲一点，可靠性就有点不着边际了，找bug呢有点靠谱，但要分清楚bug是手段，不是目的，手段和目的混淆了，团队容易舍本逐末，这个应该不难理解。
2）36#的spec修改问题
首先，理论上spec的修改应该有版本的概念，当然实际上没有那么严格，spec的修改的确是常事，这是现实情况，不扩展讲团队怎么解决这个问题，但也不能忘了写spec是一个有艺术的活，做个类比吧，基本上就是孙悟空给唐僧画的圈圈。
其次，我们聚焦在验证团队如何应对spec的修改，spec都修改了，testbench没有道理不修改（modify），其实我很想从讲各种书上看到说不用modify这样的字眼，不过很遗憾，暂时没有！
再次，既然testbench的修改是不可以避免的，那也不是随心所欲，业界引入OOP等等，有一个目的是使修改量最少，当然不是单纯针对spec的演进问题。
最后，如何使修改量最少呢？使用方法学是个很好的手段，但更基本的是OOP的五大原则，特别是OCP原则（请各位有兴趣去看《敏捷软件开发》的相关章节，有详细的解释），具体的方法在《设计模式》这本书里面。
结论：针对多变的spec的验证场景，基于OOP的原则，合理搭配设计模式，把修改合理开放出来。
没有更多的东西！进一步的内容在你自己的实践中。
3）关于callback的问题（最后一次谈关于方法学先进与否的问题）
单纯地说callback不好或者好，不先进或者先进，那是藐视业界专家们的智慧，可以设想在是否使用callback的问题上，一定有个非常激烈的讨论，这是可以想象的。
callback破坏了类的内聚性，把修改交给了一个函数去实现（请不要和重写等等混淆了），可以说是OOP的大忌，但带来了灵活性，鱼和熊掌，怎么办？
这时候就有“专家”的作用，依据软件的规模，应用场景，包括其它限制条件，来决定是否使用。即使我用VMM的方法学，也可以绕过callback不使用，而达到callback的所有目的，这个权衡就需要“专家”，不是EDA的专家，而是验证团队中的专家。
而“专家”不能说拍脑袋说用就用，而是指定一个完整的使用策略，制定使用规则，把相关的不利因素限制在最小范围之内。
4）关于学习路线问题
依据业界的惯例，前十年都是基础工程师阶段，十年级别的出来做presentation，都基本不够格，二十年的都要好好地介绍一下自己的简历才可以。
所以，像我们这种人还要什么路线，什么都可以，找一个团队，随便什么语言都先好好吃个三五年，比如SV的communication机制，你学了三种，再想想为什么是这三种，其他的进程和线程通讯机制为什么不放进来，由点及面，这东西多了去了。
技术这条道路没有“九还丹”什么的，吃了就直接打通任督二脉，百毒不侵什么的。当然这么说并不是没有什么加速的手段，比如：良好的团队氛围，专家型领导的指导等等，但这些都是次要的，辅助的，这些只是让人少走弯路，为了做事情的方便（一般而言，走了弯路也不是坏事！）
关键还是在于自己，“知行合一”！
总而言之：
我和各位不在同一个环境中，我对各位的自身条件，团队情况，历史条件等等等等客观因素无从了解，说句实话也没有条件和义务去了解，所以我没有办法就具体问题来讨论，只能虚头八脑地讲喽！希望大家能理解！
-
越狱小猪头 赞了这篇日记 2016-10-21 01:09:21
