资深IC设计工程师谈IC验证【转】

本人从事IC这个行当超过十年，最开始的设计是用原理图方式做的，2006年后转向两个HDL语言
下面结合职业生涯 讲讲验证工作和技术等等问题。
如果你选择了验证，或者是被验证了，我个人觉得和所有的研发工程师一样，没有什么区别。用狄更斯的话就是，这是个最好的年代，也是个最坏的年代。关键还在自己，如果你自己没有设置上限，那还有什么可以限制你的呢？
最后说一些体会：
1）IC上所有的工作都是殊途同归，唯一限制你的只有你的眼界，把眼光放远一点；
2）做事情要踏实，贪多嚼不烂，学多，不如学精，等能力上了一个台阶后，其它基本上触类旁通了，就好像武打小说的任督二脉，没打通，什么都白搭；
3）把基础打扎实，多看看老外的书，深入体会一下老外的思路和想法，比如：把VMM之类的搞懂了，还得想想为什么？本来想讲讲学习路线图，不过这属于技术经验，只供BOSS使用，另外讲了对初学者没有好处，这是一个复杂的多方位的学习体系，必须由leader来领路；
4）IC这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
其它的再补充吧！

，从事的主要是通讯芯片的设计和验证工作，最近的一个完成的事情是建立一个团队并实现大规模复杂芯片的验证平台，用的主要技术 手段是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的大客户全球支持团队(好像是这个名字或者类似)，做的工作就是给业界大公司提供验证方面的支持。不继续扩展下去，点到为止。