芯片项目中，如果流片失败或有重大 缺陷（bug），能不能只问责于验证人员工作的不充分？

二维码

芯片项目中，如果流片失败或有重大 缺陷（bug），能不能只问责于验证人员工作的不充分？
原文地址：https://www.zhihu.com/question/33705929

卡卡

先上结论：不可以。
SoC设计流程非常复杂，bug源头可能出在RTL、 DFT、验证、 模拟电路等等，原因很多，流片更是由架构师——设计——验证——后端等，每个环节都有可能出现问题，很多流片失败后却找不到原因，怎么可能只问责验证人员呢？
一个材料转验证的菜鸟工程师来回答下流片失败的原因以及如何避免流片失败！！！
如不对，欢迎指正！！！
流片失败的原因无外乎这几种：
1.Design的版本拿错，这个问题比较要命，如果ROM版本拿错，基本芯片就废了。这种情况还真不少。
2. 流片的时候存在重大bug。如果说一款芯片流片出去完全没有bug是不可能的，大部分的bug都不会影响到芯片的主体功能和性能，可以通过软件的方式回避掉。但是有些bug是软件无法绕过去的，比如在电源管理的时候，芯片在进入低功耗状态后无法退出，这种属于重大失误，虽然芯片能点亮，但是无法使用。
3. PVT的情况没有考虑全，这对应是芯片流片前在不同工艺角下的timing violation没有清完，在某些温度和电压下芯片功能失常，大大降低了芯片的使用范围。
4. 数字芯片的模拟接口问题，比如PAD 的latch up问题导致内部过渡电流量使得芯片产生永久性破坏。
5. 功耗问题，如果芯片的功能达到要求，但是功耗太高，特别是物联网领域的芯片，这也将是灾难。
6. 安全问题，很多芯片会被用在安全要求非常高的领域，比如个人手机的芯片，个人电脑的芯片，服务器芯片等，如果出现硬件安全漏洞，软件也不能规避，那么这款芯片也算流片失败。
7. 芯片内部power连线的问题，这表现在芯片内部有短路电路，在芯片设计的时候，电源线没有好好检查，这种问题也是比较致命。
8. 芯片ESD没处理好，静电保护没处理好，芯片在某些情况下容易损坏，无法量产。
9. 生产制造的问题，一种是出现在新的生产线上，表现在良率比较低，生产成本很大。另外一种是材料有问题，比如某批次晶圆质量有问题，生产出来的芯片功耗和功能都出现问题，对于这种不算真正流片失败。
10. 封装的问题，这种就是芯片引线没有接好，导致芯片功能不正常，严格意义上也不算流片失败。
一直都说芯片流片是高风险的事情，这个风险有多高，笔者做了一次小小的调查，这个概率在18%左右。
而导致流片失败的原因，基本上遍布设计到制造的每个环节上，一个环节稍有不慎，一个芯片就会重头来过。无论你是芯片行业哪个岗位上的一员，对自己所要负责的环节和内容都要认真仔细的对待，这样才能把流片失败的概率降到最低，而不是只要验证人员在把关！
那么在流片前设计和验证人员都应该再重点检查什么呢？
1.设计

• 规格书完整性的检查，主要检查规格书是否将芯片的功能都记录下来，规格书中否有歧义。
  
• 寄存器的检查，在芯片应用中的寄存器是否都有实现，寄存器的名称和属性是否正确。
  
• clock和reset的检查，clock和reset是否都有接到对应的模块。
  
• 宏定义的检查，检查宏是否按照设计的要求进行定义。
  
• 芯片功能的检查，芯片是否已经实现规格书中所定义的所有功能
  
• 设计中TODO和FIXME等地方的检查。
  
• Lint语法检查，Lint语法检查在此非常重要。
  
• 面积的检查，综合后芯片的面积是否符合设计需求
  
• 芯片引脚检查，芯片的引脚数量及布局是否符合实际应用需求
  
• CDC的检查，CDC中报的问题是否都有修掉
  
• 安全功能的检查，安全功能的对抗措施是否都有实现
  
• 软件人员对寄存器，设计功能和记录的未解决bug的检查
  
• 
  2.验证需要check的点
  
• Testplan的检查，Testplan是否覆盖全部测试点，coverage group是否都包括了这些测试点。
  
• FPV的主要的assertion是不是都有被证明
  
• Regression 是不是都pass了
  
• 安全、error scenarios，power，performance，stresstest 是否都有测过
  
• Function coverage 是否收敛
  
• 设计的接口是否都有测试到。
  
• SOC中对应IP的验证test是否都有过
  
• Code coverage 是否收敛
  
• FPV中COI coverage是否收敛
  
• 安全功能的对抗措施是否都有测到
  
• 所有的bug是不是都有清掉，如果没有清掉原因有没有搞清楚
  
• XPropagation 分析是否有完成
  
• 所有TODO或者FIXME的地方是否都有清掉
  
• 相关compile或者simulation中warning的地方有没有检查一遍
  
• Gatelevel simulation有没有跑完，包括几个corner
  
• 带UPF/CPF的simulation是否都有跑过后端
  
• LEC/Formality是否有比过
  
• Timing 是否有收敛掉
  
• 芯片的动态功耗和静态功耗是否与设计的一致
  
• ESD，latchup和ERC等检查是否有过
  
• 最终的网表与最初的网表功能是否一致
  
• 电源域划分是否合理，功能模块摆放是否合理。
  

小编有话说：
大家都知道我是材料转验证的，很多乎友都问我咋转的，但我不咋看知乎回复很慢，在这里重申一次，我是报班转的，但是不打广告，若大家谁对IC有疑惑或者对行业不懂或者求推荐求指导，可以直接打开IC指导测试进行测试提问。

清风寡欲

先说结论，不能。
老哥也流过接近十几颗芯片。
有参与的，也有主要负责的。
老哥认为，第一要负责的人都是项目负责人。
这个很好理解，成功收益最大，失败必然要抗责任。
验证人员只要需要满足验证的signoff标准即可，功能覆盖率100%，代码覆盖率100%，状态机，分支，条件满足signoff 标准要求。失败和验证人员关系不大。
有同学会问: 这样验证流程怎么会出重大bug？
这是因为，当时定义的功能case是不是真正的所有的功能场景，错的，漏的验证场景都可能有。芯片是最难之一，就是回答关键的验证场景有哪些？如果没有把这些定义好。验证人员即使验证到100%，也解决不了问题。
关键验证场景 case 列表的确定：这个涉及芯片的核心，关键功能性能指标，可能需要整个芯片多个部件都协同工作。这个是designer, 验证leader, 验证人员，项目leader, 产品经理都要参与的事情，普通验证人员只需要按照case列表去写case, 保证case真pass。
关键场景验证，是一个系统工程，不是让验证人员一个人去搞定的。
而这个也是最容易出现bug的地方。
举例来说：你奉老板之命开发一个当今世界上最牛的终端ai芯片，里面cpu, ddr, 总线，ai处理器，mipi，wifi，网络全都有，处理性能要求达到世界第一，老板可以出去吹牛B。每个单独ip，验证人员都验证没问题。但是，你的核心应用是mipi采集来的图像，缓存到ddr中，通过ai处理器识别成潜在犯罪分子，然后把犯罪分子图像由cpu控制通过网络上传到警察叔叔那里。
看,所有部件的都参与上了，这就不是一个人的问题，需要场景的清楚定义的能力。这里包括
mipi速率和能力。
dma速率和能力。
总线的匹配。
ddr的速率。
ai处理器识别的速率和匹配。
cpu交互的效率。
网络处理的效率。
以及这些协同工作的能力。
假设一切都很完美，复杂场景让你搞定，性能天下第一，流片成功。
但是，芯片一用上，警察叔叔发现常常报假警，根本没法用。项目失败了，这算谁的问题？问题定位，发现芯片升温太快，125corner下ai处理器扛不住，误识别率很大。如果带风扇环境又不允许，风扇也是有寿命的。为了吹世界第一，搞芯片太大，太大功耗扛不住。所以流片失败不能怪验证，责任只能项目负责人来负责。
还是那句话，芯片是一个系统工程，风险点，关键点的识别是产品经理，项目leader的首要事情。小公司有时候这两个岗位还可能是一个人。
一将无能，流片失败，三军辛苦多年而无所得，更不能再推责任了，否则就更显无能了。
团结大家，总结经验，完善流程，提高能力，复盘复盘再复盘。而不是找背锅侠。
团队人心丧失，更别提什么战斗力了，大家都是甩锅高手，没人敢承担，团队也干不了什么事。
不是有句话吗？“败则拼死相救，胜则举杯同庆”。团队的意义就在此。
因此，老哥不应该会打板子到一个普通验证人员身上。

长长的路

匿名讲个真事。

有次流片回来测试，某个引脚有问题，一上电就漏电，几分钟之内就是一缕青烟，板子带芯片一起烧了。追查发现，该io的esd diode画版图的时候居然少画一层layer，产生了错误的器件。（io和esd的版图和design rule是特别难搞的事，做过的都知道）
调查结果大约是这样，模拟工程师要求版图工程师画成某样，版图工程师发现去掉那层layer之后drc检查就过了，然后跑去问负责design rule的CAD，这样可以吗？CAD说，可以。于是就凭这句转述，一路review都通过。芯片回来大家傻眼。
事后扯皮，该CAD不承认说过可以。老板问，空口无凭，有邮件证明CAD同意了吗？没有。于是黑锅就要模拟和版图工程师背。
处理结果是：
模拟设计经理：降级为工程师，过几个月公司裁员被开
模拟工程师：过几个月同一拨被开
版图工程师：无责，但之后转岗了
CAD：无责

同花顺

一个原NV的同事提到台积电的时候咬牙切齿。问其原因，他说台积电因为很奇葩的原因让他们tapeout失败过一次。
某年，NV要搞一个新的芯片，让台积电tapeout和生产。正好遇上台积电要工艺升级之类，那条流水线要暂停4个月。NV就说行啊，在暂停之前还有一个多月，把这个基本好了的先tapeout一下，至少这段时间我们能先看看性能什么的。等2个月后，NV芯片设计的老板告诉员工tapeout失败，they dropped it。
大家开始问，为啥好好要放弃呢，我们设计不好就说嘛，放弃什么放弃。老板说，不是放弃，是drop。
其实，已经有样品做好了，按照流程，应该放手推车上推到仓库。当时生产线离仓库10米，手推车放在20米外。工人就说，没事我拿过去就行，就那么两步路。
嗯，就那么两步路，他摔倒了，"they dropped it"。。。
就这样tapeout失败。

长长的路

当然不会。每次tapeout完都会有一个会议，所有人都要做检讨，从RTL团队，到FW团队，到验证团队，到后端。都要做报告，大意就是我是个傻逼，I know nothing，我有罪，我要怎样做到更好，flow上哪里出了问题，coding违反了什么原则。开这个会不是为了整人，而是为了搞清楚哪些错误其实是方法流程上可以避免的。纯粹的design错误反而不会特意深究，一般这种会都很热闹，因为平时很难有机会看到各种牛人/同事/老大做检讨。
当然，RTL designer始终是要被追问的，bug原因要搞得一清二楚，不可能只怪验证团队。还有，不存在问责。就算有天大的bug，也不会有人责备你，如果有，那说明该换公司了。
————————分割线——————————
很明显很多人不清楚IC公司的流片过程。
每次tapeout之前都会有几次试流片，只做少量样品，样品测过了才会大规模量产，但是样品通常都有bug，如果FW能够patch就最好，不能patch就会修ECO，再做下一版，如果ECO搞不定，就重新RTL再来一遍。没有任何一个半导体公司tapeout之前敢说这就是最后一版，这一版肯定没有问题，即便intel也有delay的时候。所以只要敢量产，就不可能有天大的bug，有也不是designer的错误，因为之前的大量测试已经保证了基本功能必然work，只可能在某些corner case下有问题。
就算不小心还是出了错，芯片废了，公司能怎么办？开了RTL designer吗，降工资吗？不可能。RTL Designer在IC公司地位都很高，你开了他，降他工资，员工分分钟找下一家，但是他负责的module没人管就是大事了，新员工需要几个月才能完全接手，能改代码还需要更久。一般RTL Designer都不会在项目一半的时候离职，因为对项目打击太大。
出bug对IC公司是常有的事，IC本就是高风险行业，流片失败也是常见，连这都处理不了，还要追究员工个人责任，谁还敢负责coding？这种公司只能说是傻逼。