感觉最近验证的出镜率很高呀！

我在贵版叫嚣过多次。10年之内，国内ic，验证比设计还要重要，坑多钱多。

需求 新加坡IC验证····  5年以上的~  打打小广告~

去新加坡做验证，脑子进水了。放着国内大好河山不干，新加坡5年回来，人脉资源职位全没了。

验证能精通也很难
语言上要精通verilog, sv, c/c++, perl/python, tcl
知识方面：　ＣＰＵ体系架构，总线，lowpower, assertion, uvm, interface protocols, transaction modeling, memory protocals...
还有专业方面的知识
10年也学不完

验证难精通不在于语言，而在于要带着设计的思路去做验证。靠穷举法，靠跑随机来做验证，太平常了。精通的孩子，应该知道，这个模块，大概那几个点设计人员会犯错，那后有的放矢的写参考模型，写仿真矢量

不是的，要求至少5年以上工作经验的。 什么时候想回来都可以的。呵呵。 去拿个PR回来也可以的啊。

你当设计人员都是吃屎的，设计的时候一点都不考虑，全靠验证人员给自己找bug啊，我觉得验证就是个噱头，自己的设计自己最清楚哪里最有可能出问题

这个。。。
如果你在一个项目里面的有效代码量是十万行，凭啥保证你不出错？别人凭啥相信你不出错？

又不是说不需要验证
那人意思是验证考虑到的可能错的地方开发更了解了，要说资历一样的开发和验证，结果反而验证了解的细节多，我还真不信
我觉得验证最大价值是穷举各种corner，以另一种角度看待设计，再不成也是多个人多个角度，主要还是有些开发太懒了，只去自测最主流的用例，对于某些麻烦的特定条件，开发写代码会考虑，并不是不知道这里有个隐忧，但是往往嫌麻烦不会主动去测丢给验证

re，代码量上M了之后，设计人员自己都晕了。代码量上了10M之后，BUG完全数不清了

验证其实有同样的问题，设计的代码量上M的话验证的代码量也得上M把，验证里面同样有BUG,怎么验证验证呢？这是一个死循环，所以当前验证搞这么复杂完全没必要，simple is best。有句话可以形容当前的验证方法学：我们已经走得太远，却忘了当初为什么要出发。

你靠自己感觉挑出几个错误后，你能保证没
有其他错误吗？能保证所有功能点都正确了
吗？
验证最重视流程，feature一条条分解，各
种cross，corner都要保证被覆盖到。
直接用例覆盖各主要测试点。随机用例
+funcov覆盖验证目标

验证分两步，首先是写参考模型。是由一个和设计完全不一样的人，根据和设计完全不一样的思维方式和视角，用和设计完全不一样的语言，去实现和设计一模一样的模块。
其次，是写测试矢量。这一步，设计和验证人员互相讨论，一起写的。
测试矢量不会有bug，就一个输入激励而已。写非法的测试矢量也没啥，可以验证设计的鲁棒性。验证的bug只会发生在写参考模型中，发生bug也没啥。任何测试矢量，只要最终的结果参考模型和rtl设计不一致，都要debug。基本上是五五开。最令人不放心的是，参考模型和rtl发生相同的bug。

小公司就不这么搞  
做验证一定的去大公司 流程完备的
所以说验证的坑还是比设计的少    

验证方法学是帮助你快速搭出验证环境 用
的。。
验证环境不需要描述设计的细节。。只要描
述出激励时序，高级语言写出rm，在输出
端收数比对就可以了

哥。抬杠就没意思了。我的原义肯定不是强调肯定某一方面，然后完全忽略另外一个方面。我的本意是，好的验证人员可以更加贴近设计而已。

rm是什么  用什么实现的？
我遇到很多华为的员工  都特别喜欢强调这个rm

reference module
验证工程师，用面向对象语言写的

不一定是golden啦。也有bug的。只是用于和设计人员的rtl模块相比较用的。

财务自由的窝窝头现在就是在贡献余热了不要再等10年啊。

大哥
我感觉我们似乎同行，也是datacom
能介绍份工作吗

低端基带量大啊！我以前做的芯片一年才出10k的量。再卖白菜价，差旅费都回不来。

去sprd allwin rda啥的不都挺好的么 呵呵
以前做啥不重要吧，关键以后做得好不好

验证只是加速产品的上市的周期而已，验证人员现在正在成为设计公司的标准配备，别的
公司有，你的公司就必须有，有的是必要，有的是跟风，而且现在大量的公司也是拿了别
人的IP就用，整合时期验证人员的作用还是很多大的，设计人员，只是用经验来保证芯片
设计的可靠性和效率，可靠性太不可量化，从商业的角度讲，风险太大。说白了，资本的
钱用在验证上，得到的效果比用在多次流片和请高级设计人员的效率高，结果好，可靠性
高。等有一天有一个更高级的东西能做的更好，验证也会被淘汰，和验证有用没用本身没
啥关系。