降低芯片流片失败风险的"七种武器"
长生剑、孔雀翎、碧玉刀、多情环、离别钩、霸王枪、拳头,七种非同一般的江湖武器,件件精妙绝伦。古龙大师把这七件武器在融化进儿女情仇,出神入化,闻名江湖,演绎了一曲曲荡气回肠的故事。
随着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
这些测试向量(激励)的发送过程,就类似一个加特林机关枪,然后发送不同类型的弹药给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大师已经用加特林机枪,已经对这个待测对象的上上下下,左左右右都攻击过一遍,炮弹,榴弹,手枪弹,机枪弹全部都用上了;现在A和B在这些攻击之下,表现都一样,则证明了A=B;
贾老板说,明白了,估计A和B都能死的透透的,没有补枪的必要了;
(注: 功能覆盖率和代码覆盖率100%,并不是验证的终点;因为有些功能点不能被功能覆盖率所保证,例如也要考虑边界,异常,特殊检查等,本文不再展开;代码覆盖率的意义更多的是指导验证工程师在哪些方面增加case;)
有参考模型要比,没有参考模块就制造参考模型来比,没有检查比较的验证项就是一个哑弹(无效的case),不能起到作用,还有反作用,就是以为验证覆盖到了,实际上没有,实为UVM的大忌;
了解了UVM的思想,其实不局限于使用systemverilog来验证,只不过UVM的平台架构,各种库已经非常完善,通过移植这个架构,可以快速搭建符合每个芯片要求的验证平台;另外通过UVM平台也可以作为一个验证平台通路,外部可以通过其他的语言例如(python,C,C++)等等来设计弹药,然后UVM平台将A(待测对象)和B(参考模型)输出也可以通过UVM平台传递给其他的验证语言来比较,这样就UVM平台完全就是通路的角色,弹药(测试向量产生)和比对都可以用其他语言完成(如python等)。兵无常势,水无常形,得道思想,随心而用;
二:VIP
例如买的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%消除;”阵而后战,兵法之常,运用之妙,存乎一心“。芯片研发本身是一个实践的科学,只有把这些武器和实际中遇到的问题结合起来,迭代上升,在实践中完善,梳理,沉淀这些“武器”运用和流程,才是最终才能是真正解决问题之道;
往期阅读:
欢迎关注