当我们谈及AI芯片,脑海中不免都会想起TOPS、L4/L5自动驾驶、图像识别和处理算法等词。但在初创企业、芯片大厂纷纷追逐“AI热“的情况下,芯片的可靠性成了一个大问题,甚至对终端应用也有较大的影响。
自动驾驶故障,不止OEM要担责
经常关注汽车新闻的读者想必都很清楚,近年来因为自动/辅助驾驶引发的事故越来越多,起因多种多样,但很少会将其追溯到芯片上。有的车企为了追求快速上市,其AI芯片很可能只有AEC-Q100认证,而没有ISO 26262这样的功能安全认证,在他们看来这些标准太过
“传统”了,对于产品的创新流程来说有些多余了。
这在消费者眼里也是如此,我们对功能的感知是最为直观的,而对故障的感知只要在接受范围来就好。这就使得此类车厂可以以一种“手机APP”开发式的模式运作,实现快速迭代。然而,这并不代表功能安全可以被忽视,毕竟当坏事落在自己头上时,总得要个说法吧。
在实现功能安全的过程中,从提出要求、架构、设计、编程到测试阶段,都有对应的确认与验证工作,然而通过验证是一回事,能否实现追溯就是另一回事了。比如设计上的改动可能会违背芯片要求等等,最终导致实际性能不符等问题,所以在功能安全开发设计和认证的过程中,必须要做到可追溯。
IP厂商Arteris提出了一个追溯方案名为Harmony Trace,帮助芯片厂商更好地实现功能安全。Harmony Trace在这些分散的流程系统之间创造了一层整合系统,用于追踪半导体产品寿命周期中的所有失误。一旦违反芯片要求的错误出现,这套系统就会通知工程师这项改动需要进行检查,从而自动化车规认证的审查流程。当然了,芯片开发厂商所用的开发工具流都是不尽相同的,所以Harmony Trace也提供了对现有主流EDA工具、认证流程的支持。
在自动驾驶安全标准继续演进,ISO 21448和UL4600等标准提出的额外要求下,在AI芯片设计中保证可追溯性或许是缩短产品开发认证周期的一条捷径。
可靠性第一
事实证明,不止自动驾驶领域,云端同样需要可靠的AI计算芯片。我们从现在的云端计算集群来看,多个节点为云服务提供了强大的计算能力,但正是因为这般复杂的架构,每一个节点都有可能成为整个系统的阿喀琉斯之踵。
这样的案例我们也见多了,甚至开始影响到我们的生活,热搜上时不时就会冒出“某某应用崩了”的消息,互联网公司经受的服务器故障可谓数不胜数,而且苦于定位故障来源,这其中,芯片也脱离不了干系。
造成这些后果的芯片可靠性问题主要有三种,早期失效(ELF)和正常设备运行下的随机失效,还有不可避免的设备老化。芯片都是有着工作寿命的,所以最后一项难以从设计上解决,最多尽可能延长其寿命,而前面两者才是当下云端需要提防的问题。
常见的早期失效有闸极氧化层失效、老化效果不好和软击穿等,随机失效很多与运行环境有关,比如温度过高、辐射过高等等。
为了进一步让AI芯片免受这些可靠性问题的影响,初创公司Ceremophic公布了自己研发的QS1芯片。这是一款基于5nm工艺的分层学习芯片,集成了2GHz自定义机器学习处理器、2GHz的自定义FPU处理机器学习计算,还有一个基于ThreadArch的RISC-V处理器和ARM Cortex-M55应用处理器,Ceremophic称后者主要用于元宇宙相关应用的视频处理。在接口方面,该芯片支持到x16 PCIe6.0/CXL 3.0。
那么这款芯片在可靠性上的亮点又有哪些呢?Ceremophic称对于早期失效而言,他们选用了高效的ASIC实现方式来使用抗ELF的逻辑库,在正确的逻辑单元组合下以最小的设计开销做到低ELF。
而在面对随机失效上,Ceremophic用到了自己的多线程技术,利用两个多线程处理器运行同一程序,一旦检测到错误,就会利用多个结果来做出表决,并进行修正,接着程序执行会直接从检测到错误发生的地方开始运行,而不是一个未知的安全起始点,消耗更多的功耗。
在传统的高可靠性设计中,往往都得采用高成本的解决方案,比如冗余,就像是需要在两个地方做同一件事,带来计算资源和功耗的双重增加。不仅如此,解决方式也需要消耗更多的运行周期,这也是为何云端服务器出现故障后,不能快速恢复的原因。
-
芯片
+关注
关注
454文章
50430浏览量
421896 -
AI
+关注
关注
87文章
30172浏览量
268439 -
AI芯片
+关注
关注
17文章
1860浏览量
34912
发布评论请先 登录
相关推荐
评论