降低芯片流片风险：七大策略揭秘

随着SOC芯片的规模和功能的不断急剧膨胀，SOC验证一般可以占到整个项目的60%以上，验证已成为了整个SOC芯片开发的瓶颈。芯片验证不充分，轻则重新投片，时间资本上损失惨重，重则资金耗尽，公司关张。芯片江湖的也有“七种武器”，这七种武器合理运用，可以最大限度确保芯片验证充分，降低芯片流片失败的风险。

一：UVM

UVM不是一种编程语言，UVM（Universal Verification Methodology）而是验证方法学；

UVM虽然不是一种语言，但是UVM是以systemverilog类和库的验证平台框架呈现的，因为在芯片验证领域非常流行，成为了一个事实上的验证平台标准；

正所谓：验证不识UVM，便称英雄也枉然；

贾老板成立一个AI芯片公司，研发一款AI芯片，于是请UVM大师指点如何保证芯片正确；

UVM大师说，我对你的芯片一无所知，不能告诉你芯片正确与否，但是，我可以验证A=B；通过众多验证向量验证芯片A和参考模型B，比较两者输出结果是否一致，如果一致，因此A=B；因此验证结论是：芯片A和参考模型B功能一致，芯片A是满足设计要求的，从而保证芯片正确；

贾老板直接就懵圈了，怎么还多出来一个B的事情；

（注释：A和B功能是一样，并不代表A和B相等，本文采用A=B，用公式来简化这个意思）；

贾老板说：像软件测试一样，有测试大纲，根据测试项一项一项测试看看功能对不对，UVM不是这样吗？

UVM大师：非也，引入了一个变量B，A和B的功能在各种激励下输出一致，来推断A=B；这个就是验证的方法学精髓之一；

A就是待测试芯片，也叫DUT（design under test），也就是设计工程师，绞尽脑汁，头发掉光，设计出来的芯片（或IP）；

B的就是参考模型，RM（reference model），参考模型，小名狗剩（Golden）；

看到这里，贾老板就有了第一个问题：参考模型B从何而来；

UVM大师说：贾老板问了这个问题，当然从贾老板而来；因果循环，皆有定数；

贾老板成立一个AI芯片公司，请了一个AI领域的大师，AI大师苦思冥想，悟道新算法，有效提升性能，降低存储代价，发表了CVPR（计算机视觉与模式识别的顶级会议），然后AI大师用python实现了这个算法；然后贾老板招了一批 IC设计工程师；把这个算法实现成了芯片（IP）；

UVM大师说，看，这个芯片（IP）就是 DUT，是A，而原来的AI大师的算法 python描述，就是reference model，是B;

UVM的工作就是来验证A=B；如果二者功能不一样，那说明A芯片设计错了，如果验证A=B，那么UVM大师就功德圆满了，那么芯片可以流片了；

现在这个流程是不是清晰多了；

算法大师设计了算法，设计工程师设计了芯片，UVM大师通过验证方法学（UVM）推断了两者一致，完美，可以流片了；

且慢，第二个问题：怎么来验证A=B

UVM提供了一种可移植的现成的架构可以同时将测试向量发给A和B，通过构造测试向量，同时发给A和B，然后收集A和B的输出，比较输出结果是否一致。如果比较结果一致，则验证成功；否则，验证失败；

如果是仅仅对于一个测试向量CASE1，A和B的输出结果一致，是没有办法说明A=B，只能说明：

       IF （CASE1）  A=B

所以，验证大师就需要设计N个测试向量，CASE1到CASE N

       IF（CASE1->CASE N）  A=B

这些测试向量（激励）的发送过程，就类似一个加特林机关q，然后发送不同类型的弹药给A（DUT）和B（RM），这些弹药可以是普通子 弹，也可以是榴弹，炮弹，导弹；

设计各种弹药，然后赋予了这些弹药各种特性，比如大小，火力，距离等等，每个都不同，但是这些弹药继承原来的弹药的特性，不用从头开发，简单，省事；

一方面这些弹药可以设置成为随机弹药，就是同一个弹药，但每次发射都不一样,弹药自身具有随机性，例如一个弹药可对随机任意初速度，每次发射，可以检查目标设备在任意初速度下，是不是都表现正常，同理也可以设置其他随机性；

另一方面也不能完全随机，毕竟完全随机的目的性太差，需要约束（constraint）这个弹药的随机性，例如打蚊子，就不需要炮弹；打航母，用手榴弹也不靠谱；不能是完全随机，通过约束随机性，可以增加弹药的目的性；

构造各种的弹药，看看A和B的反应是不是一致；如果一致，万事大吉；如果不一致，那就是有bug，则需要debug，看看究竟为什么A和B为什么不一致，反馈给设计者来修改原来的设计（DUT），直到两者一致；

现在，第三个问题来了，到底构造多少CASE才能说明A=B；

子曰：验证时间也有涯，而验证case也无涯，以有涯随无涯，殆已；

但是贾老板不管，他会直接问，大师虽然构造了这么多验证用例，但是这些验证用例就能说明A=B了吗，验证是没有尽头的；

UVM验证大师说：贾老板请看，AI算法大师已经描述了100个功能点，我已经按照这100个功能点设计了100个验证用例，全部比对都成功了，说明功能全覆盖；另外，芯片设计的每一行，每个状态机状态，每个分支，每个条件全都覆盖到了，说明再无补充测试CASE的必要了；

见贾老板似懂非懂，UVM大师解释道：UVM大师已经用加特林机q，已经对这个待测对象的上上下下，左左右右都攻击过一遍，炮弹，榴弹，手q弹，机q弹全部都用上了；现在A和B在这些攻击之下，表现都一样，则证明了A=B；

贾老板说，明白了，估计A和B都能死的透透的，没有补q的必要了；

（注:  功能覆盖率和代码覆盖率100%，并不是验证的终点；因为有些功能点不能被功能覆盖率所保证，例如也要考虑边界，异常，特殊检查等，本文不再展开；代码覆盖率的意义更多的是指导验证工程师在哪些方面增加case；）

有参考模型要比，没有参考模块就制造参考模型来比，没有检查比较的验证项就是一个哑弹（无效的case），不能起到作用，还有反作用，就是以为验证覆盖到了，实际上没有，实为UVM的大忌；

了解了UVM的思想，其实不局限于使用systemverilog来验证，只不过UVM的平台架构，各种库已经非常完善，通过移植这个架构，可以快速搭建符合每个芯片要求的验证平台；另外通过UVM平台也可以作为一个验证平台通路，外部可以通过其他的语言例如（python，C，C++）等等来设计弹药，然后UVM平台将A（待测对象）和B（参考模型）输出也可以通过UVM平台传递给其他的验证语言来比较，这样就UVM平台完全就是通路的角色，弹药（测试向量产生）和比对都可以用其他语言完成（如python等）。兵无常势，水无常形，得道思想，随心而用；

二：VIP

听了UVM大师的教导，贾老板公司的芯片验证工作，似乎走上了正轨，但是，在集成多个IP之后，这些高速的IP的验证面临很大的问题；

例如买的DDR，PCIe，MIPI，UFS，AXI接口或者AMBA总线等，这些设计不论是验证case还是参考模型，都非常复杂。远超一个初级设计公司所能接受从头开始验证工作量，一句话，按照现有的项目计划，根本搞不定。现在贾老板有两个选择，一个是团队慢慢摸索，逐步熟悉，那产品上市时间就不可控；另一个是掏钱再买VIP；

这个VIP可不是贾老板的在机场或者KTV的身份象征，而是专门用于验证的IP；做SOC不但需要买IP，还需要买VIP；贾老板真是觉得上了一条贼船，做芯片干什么都要花钱；

这些VIP直接都是原生的system verilog/UVM，内置了验证计划和覆盖率，以及一些测试套件，并且符合这些协议规范；所有的芯片标准外设，例如DDR、HBM、eMMC、UFS、AMBA、MIPI、SDIO，SAS、SATA，PCIe，USB。只有你想不到，没有VIP提供商做不到；

这个就类似于，贾老板在想进阶为侠客，买了一把屠龙刀（接口IP），同时还要买一本刀法十八式（VIP）；否则自己摸索熟悉这口宝刀的成本太高了；只要按照这个刀法十八式（VIP）全部跑下来，说明屠龙刀（IP）没有问题，可以去江湖上历练一番了；

VIP的钱不是白花的，可以起到事半功倍的效果，每个高速IP集成到整个SOC后，按照VIP的提供所有case跑一遍，说明两个事情，一，这个IP没有问题，二，IP的集成没有问题；快速高效，加快验证和收敛的速度；

标准的东西都有标准的做法，标准的接口都有符合相应标准的VIP；自己从头来验证，即不明智，也会空耗费时间。最大限度利用已有经验成果（IP和VIP），是芯片能够越做越复杂的基石；什么东西都从头开始做，特别类似标准接口的设计和验证，所有都是自研，陷入自我感动，偏离了芯片为了给客户创造价值的初衷；

三：软硬协同

贾老板让工程师开发一个当今世界上最牛的终端AI芯片，里面cpu, ddr, 总线，AI处理器，mipi，wifi网络全都有，处理性能要求达到世界第一，贾老板可以出去吹牛。

自研的AI处理器的验证是通过UVM证明了A=B，完美；

外设可以通过VIP，把VIP的流程跑一遍，没有问题，完美；

但是，这就够了吗？

这个事情就面临一个问题，这个大芯片SOC的参考模型在什么地方？还记得UVM所需要的那个B吗？谁又能来搞个参考模型B出来比对一下？不是任何情况下，都有一个完美的参考模型可以来比对；芯片核心应用场景是mipi采集来的图像，缓存到ddr中，通过ai处理器识别成潜在犯罪分子，然后把犯罪分子图像由cpu控制通过网络上传到后台。所有部件的都参与上了，这需要怎么验证？

所有这一切都需要软件和硬件配合才能实现场景的验证；

在复杂的SOC系统设计中，进行硬件设计验证、软件设计验证的同时，实现软硬件交互的设计与验证成为缩短设计周期，尽早完成系统设计的关键。通过CPU的软件以及AI处理器的软件和UVM平台配合，将整个设计流程通过软件实现，然后将软件跑在整个验证平台上；

软硬协同仿真，听起来起来非常高大上，实际的操作过程中，UVM平台就是搭建了一个软件的测试平台，UVM所作工作不多，一种通常做法是把软件的编译文件走后门下载进去（UVM也要走后门，backdoor，这是UVM术语，不用增加验证时间，直接将BIN文件写到RAM）；剩下就开始软件工程师的表演了；

这里的软件流程，可以是MCU一段编程，也可以是MPU的linux，甚至可以是andriod，不论复杂与否，这个软硬协同，除了UVM的平台，更有大量的软件编程工作；所以很多软件工程师，也可以参与SOC的芯片验证，就是这个道理；

软硬协同目的就是让软件开发人员提前进场，好比新设计一栋房子，家具软装在设计的时候就要安排好，提前摆一摆，别房子建完了，发现没有安装家具软装的空间，业主不买单，那设计者的麻烦就大了；

除此之外，软件开发人员的努力不是单单为验证芯片所准备的；这些软件，可以作为SDK提供给用户使用，也是芯片整个产品的一部分；软硬系统验证是一个矛盾的集合体，即是通过软件验证硬件，又是通过硬件验证软件；

1：通过软件验证硬件；

这个很好理解，软件工程师把业务场景进行编程，实现了mipi采集来的图像，缓存到ddr中，通过ai处理器识别成潜在犯罪分子，然后把犯罪分子图像由cpu控制通过网络上传到后台这一整套流程；这个测试过程过程的实现，说明硬件各个模块，在软件的调度下，能够正常按照预想的功能和性能在工作，这套流程正常工作，验证了SOC集成的总线连接正确，功能正确，性能满足，用户场景可全覆盖；

2：通过硬件验证软件

还是上述流程，如果采集，识别，发送的流程出了问题，很有可能是芯片设计错了，也有可能是软件出错了，如果软件错误，就需要修改软件达到最终的效果，软件也在这个过程中逐渐修改，迭代，不断成熟；那么就是通过硬件验证软件的过程；

备注：

a：AI 处理器IP层级通过参考模型来证明A=B的方法，更多具有黑盒测试特性；

b：SOC上的软硬协同验证更多具有白盒测试的特性，软件人员必须深刻了解各个模块的作用，机理从而才能开展整个场景的测试。

四：FPGA

如果说芯片设计者，考虑面积，功耗，频率等，那么芯片验证者其中一个重要点考虑就是验证时间；没有什么比产品的上市的时间不要delay，更能考验一个芯片设计公司能力了；

贾老板做AI芯片，这个AI芯片每个每个验证用例的时间30分钟，可以算完一张图片，一天能计算图片库中48张图片；待测试图片库中还有十万张图片，算了一下，全部验证完毕需要2000多天；如果用10台服务器并行，每台服务并行运行10个验证用例，那么还需要20天才能迭代一遍；

贾老板就非常着急，有什么办法可以快速迭代，市场可不等人，错过就被竞品占领了；

通过FPGA测试是一个高效的解决办法：将整个项目移植到FPGA上，然后在FPGA上模拟整个芯片运行状态，从而达到快速测试效果；这种大容量的FPGA非常贵，一般在几十万到上百万；规模也非常大，不过这么好用的东西，一般芯片设计公司都会买几块；

FPGA的频率根据关键路径的长短能够到实际运行频率为几十到上百Mhz；目前这个做验证的FPGA都被XILINX的大容量的FPGA所垄断；可以加速迭代，通过在FPGA运行，可以快速的发现问题，进行大数据量的测试；

贾老板终于下定决定，购买了这个FPGA验证平台之后，这十万张照片，几分钟就可以出结果了，非常的快；贾老板的芯片验证的效率大大提高，加快了大数据量的迭代；另外，FPGA可以作为原型，直接给贾老板演示，看到这个流片后的效果，贾老板心里觉得这个FPGA验证原型板卡没有白买，虽然还是有点贵，一辆卡宴没有了，但是钱没有白花；

同时在FPGA上，软件运行的效率会大大提高，也可以加速软件/固件的迭代过程，可以发现很多大数据量在仿真验证平台所不能发现的问题；

随之问题来了，FPGA验证发现芯片设计有个BUG，例如大数量识别图像时灵时不灵，到底是MIPI的问题，CPU的问题，AI处理器的问题，还是DDR存储的问题；在UVM仿真可能发现的几率较低，这么大数据量后才出错，仿真这么大数据量要好几天到几周；

FPGA发现问题容易，有时定位问题却很费劲，一个问题一周或者几周也不是不可能，迭代一次按照天计算，提高定位问题速率，加速收敛，是FPGA调试的一个难点。

五：“加速器”

加速器：重剑无锋，大巧不工；

FPGA就需要每次觉得哪些地方出问题，把信号加到嵌入式的逻辑分析仪来看波形。而加速器可以像仿真一样直接看到所有波形，不需要FPGA需要个波形那里重新编译，迭代一次就耗费一天；

例如贾老板游泳时，在泳池掉了戒指，FPGA调试需要每次憋气沉下一个地方，一个地方一个地方找，效率不高；但是加速器上就类似把泳池四周和底部全部装了摄像头，看看监控就能找到问题所在，可以提高问题收敛的速率；

加速器具备FPGA的速度，虽然稍微慢一点；又具备仿真的灵活性，可以看到所有信号的状态； 加速器可以大大提升迭代的周期，如果芯片太大，仿真速度太慢，例如云端的AI芯片，芯片规模很大，上百亿个晶体管，FPGA原型装下也很难，全部仿真起来非常慢；如果在UVM仿真环境下，加载一下andorid，仿真跑上，过七天再看，也来得及；加速器的频率大约是1Mhz-5Mhz左右，虽然速度比实际的FPGA要慢，但是在加速器里面引导Android跑起来，过了几十分钟，就引导完毕；

贾老板见状，失望的说，这算是什么加速器，慢的和蜗牛一样，我手机开机也就是十几秒而已；但是这个样的加速器，已经比仿真速度快100万倍了；仿真的单位都是us级别来仿真，仿真100us半个小时甚至更长时间过去了（根据芯片规模不同），现在可以算一下仿真的速度有多慢了；

目前加速器厂家只有三家，分别是：

mentor的Veloce；

synopsys的Zebu；

cadence 的Palladium；

加速器都比较贵，根据配置license不同，一般在几百万左右，需要专人来维护，买不起还还可以租用，通过VPN连上，费用根据使用的机时来算；其实开发小芯片基本上用不到加速器；开发大芯片（一亿门以上）的公司实力雄厚，也可以备一台；毕竟以贾老板这么雄厚的土豪，也不太舍得买一台。

六：形式验证

如果项目进入后端设计后期，芯片前面验证出现一个BUG，如果后端这个时候已经不允许重新综合了，因为重新综合就会使后端返工，比如DFT链都插完毕了，那么再重新综合网表，可能所有寄存器数量都不一致了（每次综合的网表基本上很难保持一致），很多工作后端布局布线（PR）都已经差不多了，要是重新综合网表，那么后端PR工程师和DFT工程师就要疯掉了，好多工作要重新再来，少则几周，多则一个月；大芯片尤其是这样，小规模的芯片还好一点，这个时候需要做网表的修改（ECO）；

这个时候，如何保证网表的ECO修改是正确的，形式验证就派上了用场；如果没有形式验证，这个时候要是重新把ECO网表作为DUT加到仿真平台中，那么仿真就会奇慢无比，很难把ECO之后的网表验证充分；

形式验证（Formal Verification）主要来对比ECO之后的网表和修改后的RTL是不是等价，如果等价，那么修改后的RTL直接回归就可以了，虽然做了化简，回归也是非常的耗时；

形式验证还有很多其他的作用，例如在综合时，保证代码和综合后网表一致；在ECO时，保证综合网表，DFT网表，PR网表三个网表，和修改后的RTL都一致；

形式验证，如同乾坤大挪移，本来是A（网表）被修改了，需要验证A，现在通过形式验证A（网表）和B（代码）等价，现在只需要验证B（代码）就可以了；B（代码）的验证难度明显降低了，提升了验证的效率，比直接来做网表的仿真速度要快一个数量级；  

七：流程规范

流浪地球的作者，中国科幻作家刘慈欣在所著《三体2：黑暗森林》中有两种人，面壁者和破壁者；面壁者要打败三体人对地球的图谋，设计了一系列的反击计划；而破壁者调动一切资源利用智子监视面壁者的一举一动，通过分析每一个面壁者公开和秘密的行为，破解他们真实的战略意图。每一位面壁者都有一位针对他的破壁人；面壁者和破壁者如同芯片的设计者和验证者；三体中的破壁人是没有什么规范的，但是作为芯片的验证还是要有很多规范来约束。

没有验证规范，验证质量就会参差不齐，而芯片的质量取决于木桶的短板；而验证规范又依赖人的执行；一个完整的验证规范不论是模块验证规范（模块级），集成验证规范（SOC级），FPGA的测试等等都包含下面几类；

1：验证计划：功能点分解，包括场景，功能，性能，异常，边界等等，每个点check的策略；

2:  验证执行：构造验证case, debug，问题迭代的流程等等；

3：验证输出：验证报告输出及评审等等；

4：验证管理：验证分割，buglist，bug review，回归测试等等；

芯片越来越复杂，同时芯片的团队越来越大，面临的挑战也是逐渐增大；由于产品有上市的时间窗口，验证的进展都是在有限的资源下求解的过程，不是一个无线资源下疯狂攻击；

1：复杂度：芯片的规模越来越复杂度，亿门/几十亿/上百亿门的芯片也不罕见，芯片设计是人类这个物种最复杂的设计之一，例如苹果的处理器M1内部有160亿个晶体管。这还仅仅是硬件的规模复杂度，还不包括上面所跑的软件；上面所运行的软件也是越来越复杂，CPU的软件，GPU的软件，NPU的软件等等；可能需要多个软件，多种编程语言系统才能整体运行起来；

2：沟通：设计人员和验证人员之间的虽然可以通过文档，电路图，会议等各种方式交流；但是很难完全同步二者之间理解。如同三体中面壁人和破壁人一样，找到面壁人的BUG难度不大，关键是如何找到所有的BUG，100%的BUG，因为即使留下一个，也可能对芯片造成很大的影响；芯片团队变大，成员的沟通成本也非常的大，还会有很多管理上的问题，而沟通不畅就会导致很多的信息丢失。

“听过很多大道理，却依然过不好这一生”；

即使把这些“武器”都用上，芯片就能没有问题了吗？肯定是不够；从产品定义，设计，验证，后端，流片，封装，测试，每个环节都可能引入风险；这些“武器”只是能降低风险一些手段，但是远不能100%消除；”阵而后战，兵法之常，运用之妙，存乎一心“。芯片研发本身是一个实践的科学，只有把这些武器和实际中遇到的问题结合起来，迭代上升，在实践中完善，梳理，沉淀这些“武器”运用和流程，才是最终才能是真正解决问题之道。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删