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

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

损坏的执行错误，也称为静默数据错误，不能在测试中完全隔离—即使是在系统级测试中—因为它们只在特定条件下发生。为了整理出产生错误的环境条件，工程师需要soc内部的数据，理想情况下，这些数据是有时间戳的，这样他们就可以追踪到失败的代码行。但这种带有时间戳的数据还无法获得，而且还需要时间来提供这种功能。与此同时，在大型数据中心内部，解决这个问题的压力越来越大——尤其是在遇到这些问题的超大规模企业中。

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

例如，谷歌的工程师指出，“对低级库的一个无伤大亚的改变”开始为大规模数据分析管道提供错误的答案。他们继续写道，“深入调查发现，这些指令的故障是由于制造缺陷造成的，在某种程度上，只有通过将这些指令的结果与预期结果进行检查才能发现;这些是“无声的”执行错误，或cee。”[1]

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

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

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

每个随机出现的制造缺陷只对应特定的计算和数据输入。SDE的低重复性表明环境条件起着一定作用。由于SDE的特殊性，发现这些硬件缺陷极具挑战性。它需要长期一致的努力，谷歌将其描述为“许多工程师-几十年”。

业内专家得出结论，故障核心内部的数据可以提供洞察，并有可能改善芯片制造过程中的筛选程序。特别是在先进的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]

检测确实至关重要，但如果没有诊断信息，就很难改进制造筛选解决方案或采用弹性设计解决方案进行适当响应。

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

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

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

失败的条件有时是违反直觉的。例如，考虑时钟频率。

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

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

最近，一位业内人士分享说，他们对5nm HPC rma的分析确定，当在较低的时钟频率下执行时，大多数这些芯片都未能通过标准生产的高速扫描测试。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在现场检测潜在缺陷和过早老化
SDE可能需要几个月的时间才能在岩心中显现出来。这导致人们猜测，在这段时间内，互连路径或晶体管已经降级。然而，需要非常具体的数据和指令来触发SDE故障，这也可能需要几个月的时间。如果没有更多的数据，一些sde是由于可靠性原因造成的证据仍然不确定。

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

然而，对于数据中心近24/7的运行，以及soc上MOS设备的缩小，工程师们想知道早期磨损是否至少是部分原因。这可能是由于一个边缘缺陷，或者晶体管的开关频率比工程师模拟的更频繁。

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

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

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

了解这些影响的原因对设备的生命周期很重要，但它们不能解决无声数据错误的问题。at的CTO Andrzej Strojwas说:“发现老化问题并不能帮助解决测试中遗漏的随机缺陷。PDF的解决方案。“现在，在非常特定的位置，事情可能会发生，因为它在一开始就受到了损害，因为有随机缺陷，缩小了互连路径。”

英特尔的Lerner表示，虽然可靠性工程师与生产测试工程团队合作，在制造测试的零时间筛选早期生命故障，即潜在缺陷，但更好的筛选可能在一定程度上有所帮助。但他们不会捕获所有的东西。

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

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

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

许多公司提供模上监控器，专门测量与损耗相关的晶体管特性。通常与功能电路分离，设计人员可以将这些监控器在空间上分布在大型芯片上。在现场，对它们的测量进行周期性的测井可以提供关于老化变化的纵向数据。

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

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

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

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

参考文献

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

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

为什么隐性数据错误如此难以发现
数据中心cpu上的IC缺陷会导致计算错误。