AI芯片的可靠性对终端应用有何影响

电子发烧友网报道(文/周凯扬)当我们谈及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 PCIe 6.0/CXL 3.0。

那么这款芯片在可靠性上的亮点又有哪些呢?Ceremophic称对于早期失效而言，他们选用了高效的ASIC实现方式来使用抗ELF的逻辑库，在正确的逻辑单元组合下以最小的设计开销做到低ELF。

而在面对随机失效上，Ceremophic用到了自己的多线程技术，利用两个多线程处理器运行同一程序，一旦检测到错误，就会利用多个结果来做出表决，并进行修正，接着程序执行会直接从检测到错误发生的地方开始运行，而不是一个未知的安全起始点，消耗更多的功耗。

在传统的高可靠性设计中，往往都得采用高成本的解决方案，比如冗余，就像是需要在两个地方做同一件事，带来计算资源和功耗的双重增加。不仅如此，解决方式也需要消耗更多的运行周期，这也是为何云端服务器出现故障后，不能快速恢复的原因。

原文标题：AI芯片不只拼算力，还得看可不可靠

文章出处：【微信公众号：电子发烧友网】欢迎添加关注!文章转载请注明出处。

审核编辑：汤梓红