查找数据中心的硬件相关错误

半导体行业正在迫切地寻求设计、监控和测试策略，以帮助识别和消除可能导致灾难性错误的硬件缺陷。

损坏的执行错误，也称为静默数据错误，不能在测试中完全隔离——即使使用系统级测试——因为它们只在特定条件下发生。为了找出产生错误的环境条件，工程师需要soc内部的数据，这些数据最好是带有时间戳的，这样他们就可以追溯到出错的代码行。但这种带有时间戳的数据目前还不可用，提供这种功能还需要时间。与此同时，解决这个问题的压力在大型数据中心内部不断增加，尤其是在遇到这些问题的超大规模数据中心中。

数据中心计算错误谷歌和元工程师们在2021年报告说，他们对一个意想不到的原因表示担忧——制造缺陷水平高达1000 DPPM。具体到多核SoC中的单核，这些硬件缺陷在数据中心运营和制造测试过程中很难隔离。事实上，sde可能几个月都不会被检测到，因为精确的输入和当地环境条件(温度、噪声、电压、时钟频率)尚未应用。

例如，谷歌的工程师指出，“对底层库的无害更改”开始对大规模数据分析管道给出错误的答案。他们接着写道:“更深入的调查显示，这些指令的故障是由于制造缺陷造成的，而这种故障只能通过将这些指令的结果与预期结果进行对比来检测;这些是“无声的”执行错误，或cee。”[1]

然而，数据中心运营商可以量化对其运营的影响，例如数据中心的运营可靠性和可用性。谷歌将cee的计算影响按风险的递增顺序列出如下:

• 通过自检、异常或分段错误几乎立即检测到的错误答案，这可能允许自动重试。
• 机器检查，这更具有破坏性。
• 错误的答案被检测到，但只有在重试计算为时已晚。
• 错误的答案永远不会被发现。

正如b谷歌和Meta工程团队在2002年指出的那样，所有四种可能性都影响了数据中心的运营。[1,2]前两个问题虽然麻烦，但可能是可以解决的。后两个是不可恢复的，因为错误的计算被传递给了后续的代码段，这最终会破坏系统操作。

每个随机发生的制造缺陷只映射到特定的计算和数据输入。SDE的低重复性表明了环境条件的影响。由于SDE的特殊性，找到这些硬件缺陷是极具挑战性的。这需要长期的共同努力，b谷歌将其描述为“几十年的工程师”。

业内专家得出结论，故障核心内部的数据可以提供洞察力，并有可能改善芯片制造过程中的筛选程序。特别是在先进的CMOS工艺节点上，用于数据中心应用的soc更容易受到系统运行条件与制造微型器件、互连和通孔的挑战之间的相互作用的影响。

“在高层次上，SDE问题本质上是非常微妙的，”该公司营销和业务发展副总裁史蒂夫•帕特拉斯(Steve Pateras)表示Synopsys对此。“它们不是硬毛病。所以更严格的测试并不一定能解决这个问题。我不认为这些是你可以在测试环境中找到的东西，因为它涉及到更多的模式。你会发现这是一系列环境条件的结果，无论是系统所处的环境，还是在系统上产生压力的某种计算处理水平。在我看来，我们需要超越测试和DFT的东西——超越制造测试的东西。”

其他人也同意。“SDE问题空间的增长速度超过了我们解决它的能力。它们不容易在硬件层面追踪，并设法通过堆栈传播到应用程序层面——要么崩溃，要么中断系统运行，”英特尔产品营销总监沃尔特·艾布拉姆森(Walter Abramsohn)说proteanTecs。“我们需要新的遥测源，可以在现场监控这些设备，并在SDE发生之前预测发出信号。在维护IT基础设施时，必须考虑到老化和退化。这是我们能够可靠地扩展计算资源的唯一方法。”

遥测源是片上电路监视器，提供有关环境条件、电路性能甚至特定功能块操作的内部数据。这些数据可能是有洞察力的，这是硅生命周期管理(SLM)基础设施的一个前提。想要获得电路和功能性能的纵向数据的工程师必须将从制造测试到首次系统上电，一直到使用寿命结束的芯片上监视器数据联系起来。

根据高层观察，相邻核心中的工作负载可能会影响SDE的可重复性。由于复杂SoC在显示SDE之前需要很长时间，一些人猜测加速老化导致的退化是潜在原因。然而，如果没有更多与实际系统工作负载数据和设备降级跟踪相关的内部数据，这些原因纯粹是猜测。

你不知道你不知道什么
Meta和谷歌工程团队报告的一致之处在于，他们缺乏关于故障发生时电路中发生了什么的额外数据。

“在我参加的一个关于这个主题的研讨会上，我听了一位谷歌工程师解释他们的分析，”新思科技(Synopsys)杰出建筑师亚当·克伦(Adam Cron)说。“我问他们是否有任何硅生命周期管理数据来配合‘发行时间’。答案是:他们没有这样的数据。也许是温度太高的问题。他们甚至不知道。Meta工程师说他们甚至没有逻辑BiST可以应用。我不是说逻辑BiST是一个解决方案。但至少它让你感觉到，本来可以通过测试的东西，实际上仍然通过了系统。”

谷歌的工程师进一步证实了他们对内部数据的需求，“我们对CEE影响的理解主要是经验主义的。我们观察到的形式是，“这段代码在内核上计算错误(或崩溃)。“我们可以控制哪些代码在哪些内核上运行，我们还可以部分控制操作条件(频率、电压、温度)。由此，我们可以识别出一些汞核。但是，由于我们对底层硬件的详细了解有限，并且无法访问芯片制造商可用的硬件支持测试结构，因此我们无法推断出根本原因。”[1]

检测确实是至关重要的，但如果没有诊断信息，就无法改进生产筛选解决方案，也无法采取适当的弹性设计解决方案。

“要做的一个非常重要的区别是首先发现系统中的这些问题，但更重要的是诊断它们。新思科技的帕特拉斯说。“这就是硅生命周期管理的作用所在，因为现在如果你正在监测所有各种环境条件，PVT，路径延迟，并且你定期这样做，你可以看到当特定故障发生时系统中发生了什么。然后你得到的数据可以帮助你根据诸如故障时是否有温度峰值或电压峰值等信息进行诊断。”

换句话说，内部收集的数据需要加上时间戳，以便将其与60行代码的执行联系起来。

了解改善筛查的条件
为了充分了解现场发生的情况，需要有关设计裕度、环境条件和故障时或故障附近的功能级操作的模具数据。然后，这些数据可以指导制造屏幕以及未来电路和架构设计的选择。

失败的条件有时是违反直觉的。以时钟频率为例。

谷歌的工程师在他们的论文中指出:“温度、频率和电压都起作用，但它们的影响各不相同:例如，一些汞核心的CEE速率对频率非常敏感，而另一些则不然。”动态频率和电压缩放(DFVS)导致频率和电压以复杂的方式密切相关，这是频率有时较低(令人惊讶)的几个原因之一。增加失败率。”

较低频率的故障率增加与其他人的观察结果相对应。在2014年的一篇论文中，英特尔工程师写道，一些cpu (22nm和14nm)在较低的频率下会出现故障。

最近，一位业内人士分享了他们对5nm高性能计算rma的分析，发现大多数芯片在较低时钟频率下执行时，无法通过标准生产速度扫描测试。

这些观察结果指出了时钟频率和功能路径延迟裕度之间的复杂关系。在存在缺陷、特定温度、电压条件和较低时钟频率的情况下，特定的计算可能产生错误的答案。这种情况表明，在dfvs约束的信封之外改变时钟频率可以减轻故障行为。

该公司首席测试策略师戴夫•阿姆斯特朗(Dave Armstrong)表示:“这些产品的时钟可调和可控程度要高得多。美国效果显著。“其中一个可能给我们提供线索的问题是，‘一个设计中有多少个vco ?“从我最近的经验来看，有多个时间域。在时域和这些时域上的噪声触发点之间有跟踪。这个区域可以让我们进行一些调整，以提供更多的利润。同样，根据我们所看到的SDE系统级数据，可能会出现某些触发因素。”

事实上，如果没有关于硬件和内部芯片数据的额外知识，很难破译触发器。

系统运行期间的芯片监控数据
设备的电气和热环境在ATE和最终客户的系统之间是不同的。在20世纪90年代中期，为了响应客户的反馈，CPU供应商开始使用系统级测试(SLT)作为额外的屏幕。

“可能导致SDE的故障主要分为三大类——测试逃逸、测试时不存在但在部件进入现场后就会显现的潜在故障，以及由于磨损或损坏而在现场发生的故障，”ibm系统级测试系统架构师Peter Reichert说Teradyne。SLT测试可以帮助处理测试转义，因为它比传统测试提供了两个优势。第一个优点是，功能测试是发现路径延迟故障的好方法，可能是最好的方法。第二个优点是SLT测试插入的低成本，允许在合理的成本下进行更长的测试时间，从而提供更大的故障覆盖率。”

几乎所有关于sde的经验证据都指向与路径延迟相关的故障。功能测试已经成为工程师在ATE和SLT的测试内容库的一部分。使用较长的测试时间，系统级测试可以覆盖更多的功能路径。但是，在大约1小时的制造测试时间内，完全不可能复制超大规模数据中心运营商执行的系统工作负载。因此，测试所有可能失败路径的替代方法是测量现场的路径延迟裕度。

路径延迟监视器测量信号路径和锁存器时钟之间的时序关系。这样的测量可以识别导致SDE的异常行为。

“路径延迟监视器本身是一个非常小的IP。所以在一个典型的设计中，你可以有数百甚至数千个这样的芯片分布在一个骰子上，”Synopsys的解决方案架构师Firooz Massoudi说。“它们都通过扫描链连接到中央控制器。监视器连接到实际的功能路径，特别是关键路径。它在不同温度和电压条件下连续监测这些路径上可用的时间裕度。此外，您还可以设置触发器，即阈值。因此，如果单个路径的边界低于阈值，监视器将向中央控制器发送信号。将其与电压和温度监测器以及环形振荡器相结合，可以在任何时候全面了解硅的位置。当监视器检测到故障时，你就有了一个硅数据的概要，这真的有助于分析正在发生的事情。”

目前，监视器和相关的嵌入式分析通过中央控制器连接在一起，可以在制造测试和现场使用期间进行观察。这些数据可以与芯片上的BiST结合使用。

“内置自测(BiST)和嵌入式分析结构很重要，因为它们为获得更复杂的芯片功能视图提供了机会，”Tessent嵌入式分析产品经理Richard Oxland说西门子EDA。“在系统层面，它们提供的数据可用于构建正常系统运行的签名。您可以在运行时配置片上监视器来测量什么是重要的，并使用设备自身的处理能力来构建签名——这是一个基于边缘的用例。你可以把数据从芯片中提取出来，对一组芯片的行为进行基于云的分析。”

事实上，反馈基于云的分析来改进制造测试是一个新兴的应用。

Advantest美国技术与战略副总裁Keith Schaub表示:“当与芯片设计中的嵌入式传感器(由多个合作伙伴提供的IP)结合使用时，Advantest Cloud Solutions (ACS)可以为静默数据损坏(SDC)问题的根本原因分析提供全面的见解。”“嵌入式传感器可以在设备的整个测试生命周期以及现场使用过程中收集和监测整个芯片区域的健康数据。然后，这些数据可以在云中融合在一起并进行分析，以检测和隔离SDC的来源。此外，这种基于云的服务可用于自动生成测试模式或屏幕，这可以进一步帮助主动识别和解决SDC问题。由于能够在设备的整个生命周期内收集、集成和分析来自多个来源的数据，工程师们大大提高了他们的理解，从而以持续和主动的方式解决SDC问题。”

来自制造遥测数据的船队行为已经被使用。虽然现在可以在现场收集数据，但遥测数据与系统故障无关。Meta和谷歌观察到特定计算中发生的SDE故障。要将遥测数据与发生数小时/数天/数周后检测到的系统故障联系起来，需要两样东西——遥测数据的时间戳，以及数据中心操作员记录的遥测数据，以便在检测到sde时启用相关性。

一些公司正在朝着这种SLM能力努力。“目前，这还没有实现，但这是我们将要实现的功能之一——特别是在测量数据发送到控制器时添加时间戳来监控，”Synopsys的Massoudi说。

如前所述，有多个内置监视器可以为SDE故障添加上下文。它们在大型soc中的实现需要以系统的方式进行，同时处理管理它们生成的数据的可行性。Oxland说:“当涉及到SDEs时，单靠测试是不够的。”“我们需要一种次要方法，其中包括另外五个要素:

• 一些先验知识表现在sde的“系统性能”参数可以测量，因为我们需要仪器芯片来检测;
• 法医数据记录，包括多个数据源，因为我们检测到的任何异常都需要归因于芯片或软件故障;
• 使用BiST和嵌入式分析的基线数据自动检测异常
• 自动触发详细的取证数据转储，因为我们不想筛选无法管理的数据量，而且
• 能够在部署环境中对DFT结构运行测试模式，因为一旦检测到SDE，我们需要一种经济有效的方法来定位原因。”

检测现场潜在缺陷和早衰
在内核中显示SDE可能需要几个月的时间。这导致猜测互连路径或晶体管在那段时间已经退化。然而，触发SDE故障需要非常具体的数据和指令，而SDE故障也可能需要数月才能发生。如果没有额外的数据，一些sde是由于可靠性原因造成的证据仍然是不确定的。

IC供应商知道什么?“我们判断，SDE对可靠性或内在退化的风险很低，”英特尔首席产品质量工程师戴维•勒纳(David Lerner)表示。“这是由于我们的生产前鉴定方法，该方法描述了所有磨损和退化模式，以确保每个零件在零件的使用寿命内都有足够的余量。”

然而，由于数据中心几乎全天候运行，而且soc上的MOS器件不断缩小，工程师们想知道，早期损耗是否至少是部分原因。这可能是由于一个边缘缺陷，或者晶体管的开关频率超过了工程师所模拟的可靠性。

半导体可靠性工程师使用的经典浴缸曲线显示了典型的三个阶段:寿命早期故障、寿命期间故障和寿命结束故障。

图1:半导体器件浴缸曲线。来源:有限元分析软件

但其他因素可能加速这些故障，导致沿互连电阻增加或晶体管开关时间下降，这反过来又会导致路径延迟增加。由于电迁移和缺陷的结合，互连变薄会随着时间的推移增加电阻。可靠性工程师使用各种压力测试来沉淀故障。失效机制均与氧化物降解有关，如热载流子注入(人机交互)、负偏置温度不稳定性(NBTI)，以及随时间变化的介电击穿(TDDB)。

了解这些影响的原因对于设备的生命周期很重要，但它们不能解决无声数据错误的问题。“发现老化问题无助于解决测试中遗漏的随机缺陷，”该公司首席技术官安德烈•斯特罗吉瓦斯(Andrzej Strojwas)表示PDF的解决方案。“现在，在非常特定的位置，事情可能会发生，因为它一开始就受到了随机缺陷的影响，这些缺陷缩小了互连路径。”

英特尔的勒纳表示，虽然可靠性工程师与生产测试工程团队合作，在制造测试的零阶段筛选早期故障(即潜在缺陷)，但更好的筛选可能在一定程度上有所帮助。但它们不会捕获所有的猎物。

“有一小部分潜在缺陷可以通过制造压力和筛选来加速。这一比例可能通过增加测试覆盖率和施加更大的压力而增加，”勒纳说。“然而，也存在局限性，并且可能导致SDE的潜在缺陷无法通过制造来消除，因此需要现场缓解。”

如果没有有关部件使用情况的现场数据，就很难确定Meta和谷歌几个月后才出现的故障是由于老化还是具有适合特定执行的环境条件造成的。可靠性问题引发了人们对使用监测器检测老化特定机制的兴趣。

“硅老化是一个巨大的挑战，”proteanTecs的艾布拉姆森说。“我们看到越来越多的证据表明，老化在该领域的影响更快、更广泛，导致性能问题和SDCs。确定这些问题的根本原因的能力取决于定位老化更快的地方和原因的能力。我们需要能够测量它，并创建一个数据库，帮助我们确定机制，然后研究模式，以确定大多数问题的来源。”

许多公司提供片内监视器，专门测量与损耗相关的晶体管特性。通常与功能电路分离，设计人员可以将这些显示器空间分布在大型芯片上。在野外，定期记录他们的测量结果可以提供有关老化变化的纵向数据。

“我们有一个老化传感器，可以测量所有晶体管的可靠性机制(例如NBTI, HCI)，”PDF Solutions的Strojwas说。“这是一个50 x 50微米的小电路，我们可以把它放在芯片里。它有自己的电压调节器，所以我们可以对传感器做一个局部应力，与电路的其余部分分开。当设备在现场运行时，您可以将电压从0.7增加到1.2到1.5伏，以进行加速测量。如果在老化方面发生了任何事情，这些传感器将提供非常精确的信息。”

结论
虽然所有这些关于sde加速机制的见解都很有用，但是仍然需要一个与错误系统行为相对应的时间戳。

超大规模厂商报告的CPU sde / cee提高了工程团队对内部设备数据价值的兴趣。正如proteanTecs的艾布拉姆森总结的那样，“SDC是一种症状，而不是原因。迫切需要的是了解根本原因，但这需要在目前尚不清楚的领域有更多的能见度。”

需要进行一些更改。SoC设计工程团队需要智能嵌入片内监视器，以提供对路径时序裕度、本地电压和温度条件以及老化的洞察。其次，数据记录基础设施需要到位，以实现与本地化分析的连接，以及与制造测试人员、数据中心系统和云平台的外部连接。最后，工程师绝对需要时间戳故障和遥测数据，以准确地进行诊断。

参考文献

1. H. Hochschild等人，”不算数的核心，“第18届操作系统(HotOS)热点话题研讨会”，2021。
2. D. Dixit等人，”大规模的无声数据损坏， 2021年2月。
3. 瑞恩，等等。”过程缺陷趋势和战略测试差距，国际测试会议，2014。

有关的故事
筛选静默数据错误
使用有针对性的电气测试和100%检查可以发现更多的sde，但不是全部。

为什么静默数据错误如此难以发现
数据中心cpu的微小IC缺陷会导致计算错误。