人工智能芯片不仅要具有计算能力，还取决于它是否可靠？

在初创企业和大型芯片厂商纷纷追求人工智能热的情况下，芯片的可靠性成为一个大问题，甚至对终端应用产生了很大的影响。随着自主驾驶安全标准的不断演变和ISO2148和UL4600的额外要求，确保人工智能芯片设计的可追溯性可能是缩短产品开发认证周期的捷径。

当我们谈论人工智能芯片时，我们不禁会想到TOPS、L4/L5自动驾驶、图像识别和处理算法等词。然而，在初创企业和大型芯片厂商纷纷追求人工智能热的情况下，ADUM5403CRWZ芯片的可靠性成为一个大问题，甚至对终端应用产生了很大的影响。

OEM不仅要对自动驾驶故障负责

经常关注汽车新闻的读者一定很清楚，近年来，自动/辅助驾驶造成的事故越来越多，原因多种多样，但很少追溯到芯片上。为了追求快速上市，一些汽车公司很可能只有AEC-Q100认证，而没有ISO26262等功能安全认证。在他们看来，这些标准太多了。“传统”对于产品的创新过程来说是多余的。

这在消费者眼中也是如此。我们对功能的感知是最直观的，只要故障的感知在接受范围内。这使得这类车厂能够以手机APP开发模式运行，实现快速迭代。速迭代。然而，这并不意味着功能安全可以被忽视，毕竟，当坏事落在他们自己的头上时，我们必须说出来。

在实现功能安全的过程中，从要求、架构、设计、编程到测试阶段，都有相应的确认和验证工作。然而，通过验证是一回事，可追溯性是另一回事。例如，设计变更可能违反芯片要求，最终导致实际性能不一致等问题，因此在功能安全开发、设计和认证过程中必须可追溯。

IP制造商Arteris提出了一叫HarmonyTrace的可追溯性方案，帮助芯片厂商更好地实现功能安全。HarmonyTrace在这些分散的流程系统之间创建了一个集成系统，以跟踪半导体产品寿命周期中的所有错误。一旦出现违反芯片要求的错误，系统会通知工程师需要检查这一变化，从而自动化车辆规则认证的审查流程。当然，芯片开发商使用的开发工具流是不同的，所以HarmonyTrace也为现有的主流EDA工具和认证流程提供了支持。

随着自主驾驶安全标准的不断演变和ISO2148和UL4600的额外要求，确保人工智能芯片设计的可追溯性可能是缩短产品开发认证周期的捷径。

可靠性第一

事实证明，云不仅需要自动驾驶领域，还需要可靠的人工智能计算芯片。从目前的云计算集群来看，多个节点为云服务提供了强大的计算能力，但正是由于如此复杂的架构，每个节点都可能成为整个系统的跟踪。

我们看到了很多这样的案例，甚至开始影响我们的生活。在热门搜索中，“某某应用崩溃”的消息不时出现。互联网公司经历了无数的服务器故障，他们正在努力定位故障的来源。其中，芯片不能脱离这种关系。

造成这些后果的芯片可靠性主要有三个问题，即早期故障（ELF）和正常设备运行下的随机故障，以及不可避免的设备老化。芯片有工作寿命，最后一个很难从设计中解决，最多延长寿命，前两个是当前云需要警惕的问题。

常见的早期失效有闸极氧化层失效、老化效果差、击穿软等。随机失效与运行环境有关，如温度过高、辐射过高等。

为了进一步保护人工智能芯片免受这些可靠性问题的影响，初创公司Ceremophic公布了自己开发的QS1芯片。这是一种基于5nm工艺的分层学习芯片，集成了2GHz自定义机器学习处理器、2GHz自定义FPU处理机器学习计算、基于ThreadArch的RISC-V处理器和ARMCortex-M55应用处理器，Ceremophic表示，后者主要用于元宇宙相关应用的视频处理。在接口方面，该芯片支持x16PCIE6.0/CXL3.0。

那么这个芯片的可靠性有哪些亮点呢？Ceremophic表示，对于早期失败，他们选择了高效的ASIC实现方法来使用抗ELF逻辑库，并在正确的逻辑单元组合下以最低的设计成本实现低ELF。

面对随机故障，ceremophic使用自己的多线程技术，使用两个多线程处理器操作相同的程序，一旦检测错误，将使用多个结果投票并纠正，然后程序执行将直接从检测错误开始，而不是未知的安全起点，消耗更多的功耗。

在传统的高可靠性设计中，高成本的解决方案，如冗余，就像需要在两个地方做同样的事情一样，增加了计算资源和功耗。不仅如此，解决方案还需要消耗更多的运行周期，这就是为什么云服务器在故障后无法快速恢复。