验证漫谈

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这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
其它的再补充吧！

hi_johnson

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

mohaigufan123

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

mickey1999

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

gaurson

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

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 发表于 2011-7-2 17:22

                               
登录/注册后可看大图

本来也想写一篇关于验证的文章，没想到被楼主抢先了。
其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。
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公司的支持，所以我认为验证服务还是有市场的。

puyuwei

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

qingyou28

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

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根本就不是一回事。