为什么都不愿意做ic验证?

青草

为什么都不愿意做ic验证?
原文地址：https://www.zhihu.com/question/584146661

感恩由您

关于“愿不愿从事IC验证”，说说个人的所见所闻、所思所想
客观的说，IC验证要做得非常“愿意”，就几种可能
（1）公司给的薪酬比较高
（2）工作强度适中，既能满足工作需要，又可以照顾好家庭
（3）在公司内上升到一定的职级且能力达到良好的水准，在平台搭建、问题发现、和IC设计问题沟通时游刃有余。
反观“不愿意IC验证”，期望离开这个方向的，其原因非常多元。罗列一些主要原因：
（1）相比于IC设计，IC验证的起步门槛要低很多，当然真正做好IC验证也非常困难。 正因为IC验证门槛低，前几年的IC热，很多非IC相关专业：比如物理、自动化、机电、嵌入式、材料等等专业的候选人规模性进入IC验证，由于专业的落差和候选人的学习能力等等的差异，出现了其中部分人员不能胜任或知识积累断层，导致的心理落差。
（2）IC验证不同于IC设计，在编程语言、平台搭建等等上要求没有那么苛刻。而正因为这个不苛刻，使得IC验证的从业人员在能力提升上明显要慢，而且能力积累的继承性要差。
（3）IC验证的主要任务是发现bug。真正芯片代码的编写和bug修改都由IC设计人员完成，从成就感的角度考量，IC验证远比IC设计人员低。
（4）IC验证人员有时还得“背锅”。一颗芯片没有bug，几乎是不太现实的，而一旦流片后，调试过程有些bug可以通过变通的方法解决，有些则无法规避，甚至直接导致流片失败。此时第一时间回溯的对象：就是验证过程中为什么没有发现？
（5）IC验证会出现比较多的重复性工作。项目开发的过程是个不断完善和迭代的过程，而IC验证可能要对同一个DUT，进行N多轮验证，过程中不免发生很多重复性工作，每个人都期望“尝鲜”，但IC验证有时会有那种被捆绑的感觉。
（6）大部分IC公司，公司领导层对设计人员的重视程度要高于验证，甚至有点职业“鄙视链”的感觉。
等等所有这些都可能导致验证人员“不想干了”。
个人从事过多个不同岗位，时间都比较长，其实每个岗位都有其困难或者让人烦躁的一面，IC验证要做到开头描述的那样也完全可行，关键是舍得付出且过程中注重积累。当然到一定的阶段，也可以切换到IC设计或者系统架构的赛道，但这个过程需要做很多很多的铺垫。
至于如何做好IC验证、IC设计和SoC架构设计，怎样才有底气说出“AI的DSA设计已死”，如何才能分析高通/联发科“SoC 1+3+4〞？在后面的答复中会分步讲解。
职场和岗位相关的更多信息，也可以参见我主页置顶文章。
个人经验和认知的总结，欢迎点赞，收藏 ，关注@主任工程师。如有不同见解或疑问，可以评论区或者私信讨论

大力水手

验证转设计，DV，DE都做过。我就是不愿意做验证了，转的设计。不愿意做验证的原因就是不知道怎么做。
人人都知道，验证的目的是，加速design收敛，保证design质量。但无论怎么做，自己也无法说服自己到底有没有保证design的质量。
实际工作中，验证leader觉得需要测什么，就测什么。DE想看点什么，就给他跑下什么。
还有一个件事，就是验证里的花活太多，造假太多。什么声东击西，瞒天过海，空城计，抛玉引砖，浑水摸鱼。走为上计。真正做DV的肯定有体会。

感恩由您

不知道这个陈述是由谁发起的？芯片设计行业从业者？外行？

先不论事实是不是这样。

以我目前组的人员分布数据来说话，人员不含括北美印度等其他global team，仅看当前所在地区。

我们在做一个高速串行接口ip，ip包含数字和模拟。数字设计工程师6人，模拟工程师有10人。数字验证工程师26人。其中验证团队包含正式员工和外包，外包9人。

对于还没有入行的学生，除了本身在读书期间发现了做数字或者模拟设计的兴趣，以及由公司团队人员构成所造成的群聚效应，大部分首选还是会考虑验证。

科班学生通过早期对芯片领域的学习深入，会诞生对模拟比对数字更好奇的群体；国外所在的几个芯片设计大外企，对于在海外找工作人脉内推加持非常重这一特性会决定一个小组成员某个国籍或者相近文化扎堆现象。

比如当前项目数字验证manager是越南人，则我身边几乎都是越南人；模拟团队大都是中国人或会说华语的local，则本地大学出来实习的讲普通话的学生基本都做模拟。

芯片验证工作的这几年没有听说过不想做验证想换方向的同事，对于偶尔听到的吐槽诸如芯片流片成功功臣在设计，流片失败首找验证或者在简历中设计人员可以自豪的说设计了多少产品问世但验证只能提找了多少bug 等之类的话，听听就过去了。

有时常常会自拟芯片验证工程师为程序员，除了本身的语法环境跟软件非常相似之外，还有一个重要的因素在于心境。对于验证，对于软件工程师，阅读生产资料文档，调试环境，环境迭代再调试，找问题，debug，大部分时间其实都是没有正反馈的，真正让验证工程师开心的一刻可能只有仿真顺利执行并且出现以下结果的时刻：



但其实在获得这个结果的过程中，正是发现自己的时候。在知道自己愿意以及能够调用身边多少资源去解决问题，以及体现的耐心，问题专研深度等方面，自己未来适合走的路线就确定了，Project Manager或Technical Track亦或Manager Track。

从验证未来的出路广度来说，这不应该成为不愿意做验证的原因。对于极少数权衡到不断拔高上限比如做到外企Fellow中设计或者验证比例的这部分，其自我努力因素占比已经少于公司机遇以及运气了。

附上一张昨天下午，由公司资深人力进行的One-One Career Coaching：

检验医师

入行ic验证12年了，在压力小轻松稳定的研究所工作过，也在工作节奏快的ic外企工作过，那么我来说下这些年我对于验证的感受，以及为什么大家都不愿意做ic验证？
1、首先验证工作刚入门的UVM就足以打蒙一批人；在校喜欢学习设计思想，工作中第一次接触验证思想；针对于一个小问题小bug,新人花费半个月时候还没处理好也是常有的事；

2、验证工作成就感相对于低；项目成功是前后端设计牛逼，项目失败是验证水，这么简单的问题都发现不了？

3、科研成果少；前端设计发表各种专利、论文等科研成；但是功能验证这方面基本上很少很少很少，参考性了胜于无！

4、工作迭代次数多，有时候会觉得枯燥且繁琐；设计需求修改导致验证大改；设计bug导致验证大改；验证自己的bug导致验证大改；说到底验证工作就是不停的debug，不是正在debug，就是准备debug；
五天一大改，3天一小改；工作中需要进行大量的测试和调试，同时可能需要花费数周或数月的时间才算完成任务，难免在这其中会产生一些负面情绪：觉得无聊且枯燥！
无数次迭代回归，回归，回归，回归挂了，查问题，改环境，回归，回归，回归，回归挂了，循环。重复工作无进展。

5、屁事多：要随机、要自动check、要各种覆盖率、要各种文档，但是最终却不会体现在产品中。

6、发展上限/天花板低；应该大家都听过或见过总架构师、总设计师，但是你什么时候听过总验证师呢？

队长是我

从业四年左右的验证工程师，说一下为什么我现在不喜欢做验证了。
简单来说，就一句话，验证存在的意义是找到BUG，越快找到全部的BUG越好。
作为一名验证工程师，你所做的一切，如果不能帮助这个目标，都是没有意义的。在这个过程中，你可能想到了一些很fancy的办法实现环境，但是如果这些对找到全部的BUG没有帮助，那跟最差最差的环境没有区别，都是花拳绣腿。而BUG在哪却是随机的，设计的一个简单笔误可能需要极其复杂的用例才能发现，简单粗暴的环境说不定也能发现所有的BUG，精心设计的环境说不定也会漏掉BUG。就我目前的体验来看，技术对验证没这么重要。一个证据就是，我几乎没遇到过知道system verilog的interface class这个特性的人，在实际工程中使用多继承与interface class的人更少，而这是system verilog2012的特性…
所以，从我目前的经历来看，如果你不太关心工作内容，更在意职业发展，验证天花板绝对不比设计/算法差，但是如果你是一个成就感驱动的人，希望自己的思考自己的想法产生价值，可能做几年验证之后会觉得迷茫。
希望能遇到更有经验的工程师为我解惑，也希望大家一起探讨想法。