一个关于验证的好帖
在水木看到一个讨论现在设计和验证的前途问题。还是有不少有意思的帖子。选了一些我觉得比较有意思的贴过来。顺便说说我对验证的一些看法。
搞这行也有３年了，从一开始入门时的模快极RTL设计，写模块的testcase,在到写系统的testcase,那时候没觉得验证有多么的难。后来在一些比较小的项目里负责整个测试环节。搭建系统的测试环境。包括写testbench，写自动化测试脚本，也写testcase.工作了一年多发现做验证还是很有技术含量的。写一个好的testbench,要对整个待测系统有很系统的了解才行。必须阅读大量的系统级的文档。去想对策怎么去设计发送和接受模块来更快，更方便的来验证。而且为了加速系统极测试，有时候要用到emulator，这就要求testbench是可综合的。这几乎就是和RTL设计没什么两样。只不过设计要求没有那么高而已。通常频率，功耗，面积什么的没什么要求。现在直接在硬件上仿真和调试的手段还不够。不过我想在未来应该会好的多。。我现在只搞过一些比较简单的测试系统，貌似一个人还能应付过来。对一些大型项目，做这么一个系统是非常复杂的。难度不比做设计要简单。随着验证手段在日新月异的更新，面向对象这样的软件手段都被引入。以后对验证工程师的要求越来越多。既要有软件背景，又要精通硬件。这不是一件容易的事情。而且验证工程师一般对整个系统有更深刻的了解。我的好几个项目经理都是验证出身。看似前途也不错的
我也同意一个优秀的验证工程师可以比较容易的转向做RTL设计，因为验证工程师一样也在做这些。现在很多地方的验证还是比较初级。就象我现在再做的那样。一个设计工程师完全也可以改行验证。但以后一个专业的RTL设计人员要转验证就会难一些。未来的验证越来越软件化。而且我并不看好RTL设计的前途。随着比如Matlab的system Generator, Mentor的CatapultC这种可以从纯软件语言快速生成RTL的软件或者语言的普及和成熟。加上大量IP的使用。纯RTL编程的空间越来越小。系统设计和系统验证会成为工作里的重点. 系统设计是真正大牛要做的。我等弱人只会越帮越乱。还是做做验证吧。哈哈。
再套用一个网友的结论 系统架构》系统验证 》RTL模快设计.
现在好多国内公司都是重设计轻验证，是和现在国内的现实有关的。大量靠风投的钱开的公司，目的只有一个，尽快的做出样品，招揽客户，向投资人交待。如果一个成熟的公司，还是验证还是要多于做设计的。毕竟验证是ASIC的大头。现在FPGA受规模的限制，验证不是必须的。不过随着FPGA设计规模的越来越大，系统验证也是不可少的。小系统靠硬件调试加一些简单的simulation还可以搞定。大系统不进行系统的仿真是不行的。。
说了这么多好话，再说说坏话，不是所有的验证的工程师都有机会来设计testbench,建立测试环境。更多的也在写testcase,然后看波形，找错误来源。不得不说，这个确实比较的无聊。。
**************************************************************************************
发信人: saharawalker (hildren), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 00:19:58 2008), 站内
越简单的设计,verification越是不重要，也非常没有技术含量。
反之，越复杂的设计，verification越是关键，大公司大项目，verification与design
人数的比例是1~2:1.
要做好验证，不懂设计能做好验证？还有各种 高级验证语言验证方法，脚本等等。
技术面要比设计宽的多。大公司招验证工程师通常要三年以上工作经验的。设计的一二年的
都行。
当然，如果只是跑跑别人写好的用例，testbench别人搭好，有问题叫设计的人来定位，
这确实简单，但这也敢叫验证？有人要才怪。
发信人: frankrick (garfield), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 03:07:46 2008), 站内
呵呵，你确信自己做的是验证而不是测试？搭Testbench（包括Behavior/Golden Model）和写Testcase根本就不是一个级别的概念，而且现在还需要理解和掌握一定的验证方法学。或许你可以说一下你使用的什么验证语言和验证方法学。
BTW，目前在湾区有工作经验的验证工程师的薪水比RTL工程师的要稍微高一些。
发信人: ICP (啊。。。。。。。), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 11:52:35 2008), 站内
问题在于国内的现状是：能做出来就不错了。
还管它正确不正确。。只要面上能过就是成功了
因为量产的很少。。
所以与其把钱花在Verification上，不如花在请
专家评审吃饭上。哼。。
而且验证最最郁闷的是，你跟一帮不懂的人解释他
听不进去。出现一点问题就认为你不会做验证，它
认为只要验证过就是100%正确的。否则验证就没用
而它自己写的Verilog就很优秀。。
以前做verification的时候
通常都是先做一遍functional coverage
再做code coverage
functional coverage通常比较主观
code coverage更客观
做code coverage的时候往往能找到很多想不到的bug
只做functional coverage的话，如何保证质量呢？
说难听点，少写几个functional coverage 的 item，就能提高效率了。。。
【 在 frankrick (garfield) 的大作中提到: 】
: faint，现在都是functional coverage的年代了，拿code coverage来评价验证效果的做法早就已经落伍了。与functional coverage相关的问题是：1.如何定义完整的功能集；2.如何给各个功能点定义权值/优先级；3.如何在有限时间之内尽可能提高覆盖率。
发信人: lshj98115 (pipi), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 16:52:28 2008), 站内
现在国内比较大的ic公司对verification也都普遍很重视了，待遇方面也不比design低啊。而且的确是越复杂越大的项目verification在里面承担的任务就越重。而且verification也的确不能直接等同于simulation。而且就算是simulation也有很多很多值得做的东西。
不过在刚刚成立的小公司里，design的确比verification更来的重要，毕竟在能不能实现都无法保障的情况下，谈复杂的verification实在是早了点。
发信人: xaoyao (玄之又玄), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 19:38:58 2008), 站内
话不能这么说 越是高难度的芯片才越体现design的实力
verification针对的是functionality
design针对的是performance
functionality是起码的条件
performance是体现差别的地方
同样的spec 有人design的频率高面积小 有人的频率低面积大
这才是芯片的核心竞争力
而一些根本不考虑performance的小芯片小模块
谁都会design的 自然也没什么重要性了
发信人: No6 (No6), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 20:14:17 2008), 站内
嗯
我觉得难度design < verication < architecture
发信人: richardleo (...), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 22:54:31 2008), 站内
还是没看出来怎么无聊,呵呵
e还是有e很多的优势的,不然不会还有那么多人推崇他的.即使语言将来发展不如意,市场被sv所吞噬,我相信很多其中的思想还是可以相通,或者被sv吸收的.
----------
关于验证的一些想法,我想到什么写什么,可能逻辑上不是很清晰.
先推荐一个blog,http://www.coolverification.com/,我订阅的里面觉得写得还挺好玩的一个.
一些简洁的想法: 1.做验证要肯琢磨. 2.做验证要focus,不要觉得rtl design就多高深,老想去读人家rtl code,总想着先"忍辱负重"做做验证,有机会转设计. 3.做验证最好知识面能够广一些,肯了解不同的东西,包括硬件设计的思想(rtl coding基本的一些想法,计算机体系结构--暂且放在硬件这边),软件的很多东西(OOP,AOP,firmware,design pattern ...).当然目的是为验证服务,千万别舍本逐末:)
啰哩罗嗦的东西:
以前似乎是coolverification上面说的,验证来说 1.人都一位 2.然后是方法学 3.再才是验证语言. 对此我很赞同.
想真做好验证本身所需要的了解的知识面应当是越宽越好,不仅仅是写写testcase,做做模块的验证(当然最初的时候可能是会这样,但是我相信一直做肯定是能够有机会接触许多有趣的东西的),而应当能够自己琢磨,慢慢对芯片整体的结构/应用也有所了解,有所把握.
国内确实很多人,尤其是很多小公司觉得做验证很低端,很初级, 甚至有猎头聊起来和我说现在做验证的都去做设计了. 但是,我个人觉得做验证将越来越类似于软件开发的工作,如果真有心在这个上面做将来肯定还是会有不错的前景的.(大家都跑去折腾rtl design,你在这里专注于验证,这也算是片蓝海了).
相对于较小的设计,土方法还是好方法都可以达到目的. 但是对于flow,应用复杂一些的芯片,较土的验证环境/方法在一个项目长期发展中必然是会暴露出很多问题. 我觉得可能国内很多公司现在都是在拼命地赶项目,因此在验证这一环节的认识更多的只是赶紧保证功能正确可以进行下面的工作.而忽略了验证整体的重用(反正以后可以再写),扩展(想到要加什么的时候再大改吧),效率(多跑些random seed,simulation也可以)等. 我觉得如果真是打算长期做几代产品的话,验证好坏的重要性会更加体现出来.
rtl design也一样,仅仅是按照别人给的spec自己写写,做做实现,不去琢磨琢磨,想想怎样才能做得更好又有什么不同呢? 当然或许是因为至少做的东西要达到一定的spec要求,会迫使rtl设计人员去想这些东西,使人从中能够获得多一些的成就感吧.
发信人: lshj98115 (pipi), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Sun Jul 6 23:39:21 2008), 站内
我来更正一下吧
-------------------
1.分工：
标准的流程，Verification和Design是分开的，Verification的职责就是找出问题，至于问题怎么来的，对不起，和你没关系。Designer自己做的Verification不包含在内。
lshj98115: 我觉得做verification的人不但要找出问题，还应该定位问题，当然也要去看问题是怎么来的。做verification的都应该知道，发现了一个bug，就意味着在这个bug周边很可能还有其他问题，如果不知道问题如何来的，如何发现这些周边的问题。
2.资质：
你能找出问题还能定位问题，解决问题，那你就是总工或者CTO的料了，只不过心情好了来做做Verification而已，说白了，你想怎么玩都可以。想做 Design做Design，想做Architecture做Architecture，想做Verification做Verification，想做 Application做Application，你可以直接给我们开班授课了，不属于我们讨论的层次
lshj98115: 一个好的工程师本来就应该 找出问题--》定位问题--》解决问题，我想整个工程中所有的问题都是按照这个流程来解决的，不达到这个要求就不是一个优秀的工程师。总不能只有总工和cto才是优秀工程师吧。
。
3.重要性
Verification是很重要，我也这样说，但只是对公司重要，对你个人来说，如果你一直从事这个工种的话，我只能说，确实是没啥前途。
lshj98115: 为什么做design就比做verification有前途？如果你觉得做verification没有前途，只能说明你对verification理解的太片面了
4.灵活性
如果做Design不高兴了，可以转过去做Verification，难度不大，当然人家一般都不愿意；但我从没有见过Verificaiton出身的转去做Design的，也许是我孤陋寡闻了。
做过Verification的，别人会对你的技术资质表示怀疑，这也是在跳槽中会遇到的最大问题。对于不想做Verification而离开原公司，别人也会表示理解，并认为这个理由是足够充分的。
lshj98115: 我觉得做verification的转design不见得难，反而是做design的转去做verification可能不容易，做 verification需要有很深厚的软件功力，做design的天天和rtl打交道，反而软件功力普遍差一些。
5.技术含量
Testcase编过一点，比Verificaiton稍微有趣一点点，但只是为了降低自己的工作强度而已，对公司来说无所谓，只要你能完成你的工作就行，怎么做的，人家不Care。
Testcase和Testbench具有通用性，可以直接Transfer或者编一次后重复使用，对Verification来说，无穷无尽的测试任务才是日常工作，也许你是金字塔塔尖上的人物，能天天编Testcase，那我只能恭喜你了。
lshj98115: 看到这里我觉得你的确对verification理解的太太太片面了，我到觉得你理解的verification有些类似于qa的工作了。
对刚出校门的学生来说，做Verification不是太好的选择，这样就把你的道路限制住了，在技术上的发展几乎是不可能的，换句话说，你几乎没有在某个方向做到expert的机会（除了Verification的方向）。如果做了两年技术，突然想起做做Verification，这倒是可以的，因为如果你发现自己对Verification没有兴趣，你还有自身多年的积累，你有选择的能力。
6.工资
大的外企都是一样的， Verification和Design没有区别。外企决定工资的是文凭，工作年限，英语，Teamwork等等。对一般员工，Verificaiton 和Design都不过是螺丝钉而已，缺了哪个都不行，或者说再牛的人也可以缺，人家也没想着让你独当一面。
如果你想让自己发展的更好的话，在工作中培养自己独当一面的能力，寻找对自己能力锻炼更大的岗位应该是必要的。
7.成就感
在上天看来，比尔盖茨和一只蚂蚁没有区别，所以我们的比较只限于IT民工内部，要不然别人会跳出来说，两只乌鸦还有必要比较谁更白一点吗？
自己亲手做出一样产品（当然也不是完全自己的创意）和一天到晚围着别人的东西转圈，感觉当然是不一样的。
8.总结
再次声明，以上讨论都是关于技术和技术路线的，如果你的目标是做Sales或者Manager，不论Design和Verification都只是一个跳板，那上面的讨论对你都没有意义。
如果你同时拿到小公司做Design和Verification的Offer，建议你去做Design。
如果你同时拿到大公司做Design和Verification的Offer，建议你去做Design。
如果你同时拿到大公司做Verifcation和小公司做Design的Offer，那我就不建议了，看你自己的选择。这个问题更像高考时好学校的差专业和差一点的学校的好专业之间的选择（仅指很俗意义上的好坏，比如说就业啊，挣钱啊等等，不包括个人兴趣）。有的人更看中好学校这个平台，有的人更看重好专业的前途。
不论你的选择是什么，如果你不打算转行的话，都应该努力的在本专业积累，做好了都会很不错。
做Verification也可以做到很牛，只是机会要少一点，付出要多一点而已。
发信人: frankrick (garfield), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Mon Jul 7 04:04:28 2008), 站内
faint，说得好？他连testcase和testbench的区别都没有搞清楚....
目前Testbench搭建在某种程度上比RTL代码编写还要困难一些。一方面先进的验证语言（例如SV和SC）大多基于OOP技术，编写思路十分软件化 ——这对于硬件工程师而言相对有些痛苦；另一方面验证工程师必须熟悉硬件电路，而且必须充分理解spec，甚至要比RTL工程师还要了解才行。验证工程师所面对的验证方法学也比传统的RTL编写技巧要复杂一些——这根本不存在什么技术垄断问题，因为这些东西都是公开的。当然，验证和RTL工作中的 Architecture部分都是需要一定专业素质的，个人认为这确实是体现技术含量的地方。
Testcase不过是Testbench调用的一些测试用例而已，与Testbench搭建就不是一个级别的概念。
发信人: jlqsczw2007 (jlqsczw_2007), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Mon Jul 7 07:01:46 2008), 站内
说的不错。
个人觉得对于design来说，其实architecture最重要，需要懂系统和算法的大牛来做
如果设计的足够合理并且细化的很好，
那么rtl其实根本不用动脑子，照着coding就行了，那么这就是简单劳动。
如果architecture做的不好，那么就得靠做rtl的自己去设计，并且去优化，
这样的劳动其实多半属于吃力不讨好，既浪费时间，而且还取决于个人水平。
就和盖房子一样，建筑师图纸画的不好，那么泥瓦匠只能从他的层次来尽可能做好，但是不会对整个房子有质的影响。
verification我觉得还是先把验证法法学学好再说，就想软件里的design patterns一样，还是非常重要的。
发信人: dighole (zz), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Tue Jul 8 00:30:02 2008), 站内
其实有时候你的职业规划是受环境影响的，我同意你的关于验证的一些观点，
但当你在国内公司就业的时候，特别是对于大部分没有title的普通engineer来说，每天必须疲于应付某个leader分配下来的无穷无尽的 testcase工作，又怎么有机会去思考methodolody的问题？更别说去实践了。在特定的环境下，同样的工作强度下，国内公司大部分还是做 design需要动脑筋的时候多一些，当然你也可以说做verification也需要动脑筋，但当你动的脑筋没地方用，或者用了没人看得到的时候是很难坚持下去的。
未来的规划难道不是取决于现在所能做的事情？如果这几年在国内公司做验证就是被忽略的状况有怎么有机会成长去达到自己的未来职业规划目的？
发信人: frankrick (garfield), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Tue Jul 8 02:04:15 2008), 站内
这个讨论就事论事，我从来没觉得自己是牛人，我只是认为你在不熟悉验证工作的情况下，就轻易下结论否定这份工作（国内）是不合适的，或者说这样做可能会误导其他的网友。
关于验证工作的技术细节，就轮不到我来总结描述了，比较好的参考资料有：
《Advanced Verification Methodolog Cookbook》和《SystemVerilog for Verification》。其中，前者是Mentor公司的Mark Glasser主笔的（此人亲自参与了AVM验证方法学的创建工作），内容描述得浅显易懂结构清晰，可以让大家对AVM这个验证方法学有一个明确的认识，而且该书特意在第三章给硬件工程师介绍了软件编程中的OOP技术（很多人在接触SystemVerilog或System C的时候比较头疼的地方）；后者是Synopsis公司的Chris Spear主笔的——这位大牛我就不用介绍了，该书有很多SystemVerilog的实例，有助于大家快速掌握SystemVerilog这个语言。
关于验证工作的行业发展，我个人观点是：
1. 随着芯片复杂度的提升、流片成本的增加以及产品上市速度的加快，验证工作变得愈发复杂愈发重要，传统的基于仿真、波形检查以及直接测试例的手段已经无法满足功能验证的需要，目前行业的发展趋势是采用Functional Coverage，Constrained Random，Event-Driven Verification等等技术手段来进行RTL级的验证，而验证结果大部分是以transcript的形式输出——除非进行RTL Debug，否则不需要人工观察波形，从而在某种程度上实现验证自动化。此外在行为级验证方面，大家正在逐步接受并采用System C来进行验证——其工作即可以直接演进为RTL级设计，又可以作为Golden Model嵌入到RTL级验证的Testbench中。
2. 当前的验证工作已经吸收了大量的软件编程思想（例如OOP技术），非常强调编写环境/模型、可重用性/可继承性等等概念，甚至有人认为验证工作已经开始软件化。对于硬件工程师而言，快速掌握和接受这些东西可能有些困难，不过其实也没有那么痛苦。以我们这个团队为例（除我以外其他的工程师都是EE出身），在经过强化训练和学习之后，大家都能够在三～四个星期之内掌握新的验证方法学——延伸说一下，无论是AVM还是VMM，二者都是不错的验证方法学；前者从一开始就立足于开源，而后者在工具支持方面（例如功能、灵活性等）比较强。
3. 当验证更多地强调Functional Coverage之后，在验证规划初期对于设计中的Function Point/Feature的定义就变得十分的重要。前面的讨论中有人提出这一步是非常主观的操作——没错，就是这样，所以才强调它的重要性。目前大家的做法是尽可能地将spec及design中的Function Point罗列完整，从而定义出验证工作所需要覆盖的验证范围。以往的验证思路是枚举出大量的独立的Directed Testcase，以及Corner Testcase，这已经不适应于现在的验证环境了。根据业界的经验，在Constrained Random的支持下，通过随机方式能够发现的bug，肯定要比通过工程师绞尽脑汁想出来的Corner Testcase所发现的bug要多。换句话说，把Function Point总结完整，要比把所有的Corner Testcase列举完整要容易得多。
....
最后谈一下个人发展，目前我所了解到的行情是：在北美地区，已经开始出现验证工程师的待遇高于设计工程师的情况（当然都是有经验的）；在国内的外企甚至是本土大公司，验证工程师与RTL工程师的待遇大致上也是相差不多；对于其它的国内公司，由于他们的RTL和验证职位在很多时候并不是严格地区分开，因此不好评论二者在待遇上的差别。BTW，类似于仅仅编写testcase的职位严格来讲算不上是验证工程师，或许叫“测试例工程师”比较合适。
发信人: lshj98115 (pipi), 信区: METech
标 题: Re: 有哪些外企干活比较有技术含量？
发信站: 水木社区 (Tue Jul 8 15:38:33 2008), 站内
大家觉得testbench比testcase深是因为testbench比testcase有更强的通用性，觉得做testbench换家公司技术背景容易被认可，这个就象design与verification似的，以数字项目为例，大部分公司都是写rtl的，做design的总能找到可以发挥技术的地方，而verification就比较专一些。可是对方法学、语言以及工具的理解应该是不以所验证模块而有多大区别的。
我觉得做testcase一样是一件很有挑战性的工作，要把一个设计验证完善需要在testcase上下很大很大的力气，而且可以建立起对被测设计非常好的理解，就算以后跳槽你的理解也一定对新东家有很多可以借鉴的地方。
TAG:
