通过避免超速和欠速测试来限度地减少良率影响

在用于汽车 SoC 的纳米技术中，硅上的大多数缺陷都是由于时序问题造成的。因此，汽车设计中的全速覆盖要求非常严格。为了满足这些要求，工程师们付出了很多努力来获得更高的实速覆盖率。主要挑战是以尽可能低的成本以高产量获得所需质量的硅。在本文中，我们讨论了与实时测试中的过度测试和测试不足相关的问题，这些问题可能会导致良率问题。我们将提供一些有助于克服这些问题的建议。

全速测试的主要目的是检测硅在其工作频率下可能发生的任何时序故障。要测试的重要部分是生成可控时钟脉冲的逻辑，该时钟脉冲的频率与功能操作所需的频率相同。提供受控时钟脉冲的方法是通过输入焊盘从测试器 (ATE) 提供，因为这将降低复杂性并限度地减少需要在设计中构建的额外测试逻辑。

然而，这种方案会有频率限制，因为焊盘通常不能支持非常高频率的时钟。因此，片上锁相环 (PLL) 和振荡器用于提供时钟脉冲。然而，不能直接使用这些的自由运行时钟，因为首先我们必须以低频（移位频率）通过扫描链移位矢量，以功能频率捕获，然后以移位频率清除数据。我们需要可控脉冲，同时以功能频率捕获，这可以通过使用斩波逻辑来实现。图 1显示了具有全速时钟的典型时钟架构。

图 1： 具有全速时钟的典型时钟架构

对于任何 SoC，STA（静态时序分析）签核对于验证时序性能是不可或缺的。时序签核确保硅将以所需的功能频率运行。同样的逻辑也适用于全速测试。必须对全速模式和功能模式一起完成 STA 签核，因为时钟路径在全速模式下可能不同，并且添加的测试控制逻辑也需要定时。在正常功能模式下不需要斩波逻辑，因此我们还需要满足斩波逻辑的时序要求。

理想情况下，如果时钟的变化是在公共路径中完成的，那么在全速模式下关闭时序应该不是问题，例如在时钟路径的开始处，以便启动和捕获触发器的变化是共同的，因此不会影响设计的设置和保持时序。测试控制逻辑一般工作在低频或静态，因此不难满足时序要求。

典型的 SoC 时钟方案 

然而，现代 Soc 设计并不那么简单。高性能和低泄漏要求导致设计在单个 SoC 中具有各种时钟源，例如 PLL、振荡器、时钟分频器等。根据架构，可能有许多 IO 接口在外部时钟上运行几个 MHz，例如 SPI、JTAG、I2C 等。因此，SoC 的不同部分可以以不同的频率运行。

这就是事情变得复杂的地方。前面讨论的用于全速时钟的时钟解决方案（斩波逻辑）对于以不同频率运行的复杂芯片来说是不够的。在全速测试中，这些复杂性会引发称为测试不足和测试过度的问题，从而导致需要进行测试。

与功能模式下的运行频率相比，在全速模式下以更高的频率测试逻辑时会发生过度测试。参考图 2，如果在全速模式下向看门狗和 RTC 等任何低频模块提供 pll_clock，就会发生过度测试。采用这种方法的一个关键原因是测试时钟路径的简单性，因为这种方法只需要对功能逻辑进行的更改。在我们的示例中，我们只需要通过扫描时钟绕过所有分频时钟/RC osc 时钟/外部时钟，而扫描时钟又将由 pll 时钟控制。

图 2： 存储器和闪存在分频 PLL 时钟上运行，而平台在实际 pll_clock 下工作。内部 RC 振荡器为 RTC（实时计数器）和看门狗定时器等块提供时钟，这些块需要非常慢的时钟频率。像显示大师这样的积木既有IPS接口又有摄像头接口。IPS 接口通常以系统频率工作，而摄像头逻辑以外部提供的较慢频率时钟工作。SPI 和 JTAG 等 IO 接口在几 MHz 下工作。因此，SOC 的整体配置需要多个模块在多个频率下工作。

当在全速模式下以低于预期操作频率的频率测试任何逻辑时，就会发生测试不足。这种情况通常存在于无法提供与功能模式相同频率的测试时钟时，但同时由于较大的数据路径延迟或技术限制而无法以高频率关闭设计。在这种情况下，我们被迫提供较低频率的时钟。

因此，有必要以与功能频率完全相同的频率测试硅的缺陷。任何偏差都会导致过度测试或测试不足的问题：

• 当功能逻辑旨在以较低的频率工作时，关闭较高频率的设计以进行全速测试将影响整体设计的面积和功率。在时序关键设计的情况下，实时测试工具将使用高驱动强度单元，甚至可能需要低 Vt 单元来满足这些频率目标。

• 即使设计的时序以更高的频率收敛，以功耗和面积为代价，我们在良率计算中也可能会不必要地悲观。在全速测试期间可能会出现不切实际的良率下降。例如，在具有两个时钟域（domain1 @ 120MHz 和 domain2 @ 80MHz）的设计中，我们将整个设计的时序关闭在 120MHz 平坦处以简化全速模式下的时钟架构。这两个域的所有 ATPG 模式生成都将在 120MHz 时发生。由于工艺可变性，在硅上，domain1 在 120MHz 下工作正常，但 domain2 仅在 110MHz 下工作，因此所有管芯都将被视为有缺陷的部件。尽管该芯片足以满足功能要求，但基于全速模式故障，我们会将芯片宣布为故障芯片，这会降低我们的产量。

• 在测试不足的情况下，全速模式不能保证芯片实际工作在预期频率。由于坏芯片可以通过全速测试，所以原先的全速测试过滤掉坏芯片的目的就落空了。在这种情况下，我们在收益率计算中会过于乐观。

了解了缺点后，我们将重点关注在任何 SoC 中存在过度测试和测试不足的原因：

时钟架构的简单性 

鉴于功能模式下的时钟源如此之多，简单的方法是在全速模式下提供少量可控测试时钟。

图 3： 简单和简单的测试时钟解决方案是将 PLL 时钟与外部时钟复用，即使对于全速模式也是如此，这是一种过度测试的情况。

让我们以 DSPI 模块为例。该 IP 在 2 个时钟上工作，一个 15 MHz 的外部时钟和一个用于内部逻辑的 120MHz 功能 PLL 时钟。如图3所示，简单和简单的测试时钟解决方案是将 PLL 时钟与外部时钟复用，即使对于全速模式也是如此，这是一种过度测试的情况。

纳米设计中的分频器 

对于时钟分频器，原始源时钟用于所有测试模式，并与分频时钟复用，如下图 4所示。

图 4： 原始源时钟用于所有测试模式，并与分频时钟复用。

这是设计中的常见场景，我们有很多分频器，但我们不能在全速测试中使用它们，因为这些分频器在测试期间不可控（相位确定）。因此，简化全速测试的简单方法是在测试模式下提供一个不分频的时钟，这会导致过度测试。

多周期路径等时序异常 

在设计中，当信号传播在功能操作期间需要多于单周期时钟时，会使用多周期路径、伪路径、分析等形式的各种时序异常。这些异常在at-中有效速度模式，因此也应以 SDC（标准设计约束文件）的形式适当地移植到全速模式。然而，当前的 ATPG 工具在理解其中一些约束方面存在局限性，尤其是多循环路径。当通过 SDC 文件进行解析时，它会忽略多周期路径并且不会为此创建任何模式。例如，如果我们有一个从一个寄存器到另一个寄存器的 2 的多周期，它将简单地屏蔽任何检查这两个寄存器之间捕获的模式。

所以这意味着所有多周期路径都没有在全速测试中进行测试，导致测试不足。另一方面，如果这些异常未成为 SDC 文件的一部分，则时序检查将在单个时钟周期内发生，而从功能上讲，该路径将在两个时钟周期内工作，这是过度测试的典型情况。总的来说，这是一个大问题，因为通常我们在任何复杂的设计中都会遇到很多多周期异常，如果我们采用传统方法，这可能会导致过度测试或测试不足。

实时测试 

到目前为止，我们已经看到过度测试和测试不足都是不可取的，因此我们需要一种方法来确保在不影响设计 QOR 的情况下实现实时测试的实际好处。这个想法是，由于实时测试，设计上不应有任何显着的面积/功率开销，但同时我们应该确保在预期的功能频率下检查实时测试设计，而不是高于或低于该频率。

这里列出了一些指南/技术，以确保以正确的方式完成全速测试：

• 在 func 模式下识别设计中的不同频域。这是重要的一步，因为您越早确定频域，就越能了解全速测试要求。对时钟架构的全面分析有助于定义的全速时钟。例如，在开始一个项目时，通常不会过多强调外部 IO 接口频率目标，这会在以后影响为这些接口定义全速时钟策略。

• 定义全速模式时序约束以及功能模式约束生成。全速模式下的任何时序关键路径都可以在设计周期开始时解决。在早期阶段进行更改总是比较容易。

• 关键解决方案之一是识别测试不足和测试过度的情况，因为很多时候这些问题会在终 STA 运行期间突然出现，甚至在满足时序时甚至不会被注意到。使用某种脚本，可以比较功能模式和全速模式下所有寄存器的频率。将寄存器分为三类：在两种模式下具有相同频率的触发器——可以使用；触发器在全速模式下的频率低于功能模式下的频率——测试中的情况；触发器在全速模式下的频率高于功能模式下的频率——过度测试的情况。

一旦确定了这些情况，就应该进行彻底的分析，并探索所有架构的可能性，以提供与功能模式下频率完全相同的时钟。

为了解决时序异常，解决方案在于通过以较低频率进行测试，将多周期路径转换为单周期路径。这个概念很简单。假设一个设计工作在 200MHz，并且有几个 2 的多周期路径。用 2 的多周期在 200MHz 时对这些路径进行定时相当于在单个周期中以 100MHz 测试这些路径。在全速测试中，分两次测试逻辑。在遍中，将提供 200MHz 的捕获时钟来测试所有单周期路径，并将屏蔽所有多周期路径。在第二遍中，将提供 100MHz 的捕获时钟以仅测试所有多周期路径。相同的概念可以应用于更高的多周期。

分多次进行at-speed testing也会在很大程度上解决over-testing/under-testing的问题。正如我们上面所讨论的，有时不可能同时为所有域提供的频率时钟，但我们可以通过在每次传递中以多个频率配置捕获时钟来做到这一点。通常，在我们将 pll 用作系统时钟的设计中，我们可以灵活地将 pll 配置为某些离散频率。

可以使用相同的多次测试方法来解决与分频器相关的过度测试问题。不同之处在于，在多周期路径的情况下，触发器可以被屏蔽，但在分频器的情况下，我们需要分频时钟的可控性，以便时钟可以在扫描模式下被门控。

图 5： 当系统时钟为 200Mhz 时，在通道 1 的全速测试期间，时钟门控逻辑会将时钟门控到在 100Mhz 下正常运行的域（通过除以 2 逻辑）。

如图 5所示，在系统时钟为 200Mhz 的第 1 轮全速测试期间，时钟门控逻辑会将时钟门控到在 100Mhz 下正常运行的域（通过除以 2 逻辑）。但在第 2 轮中，当系统时钟设置为 100Mhz 时，时钟门控单元的使能将被驱动为逻辑 1。这将确保逻辑现在以 100Mhz 的预期频率进行测试。

使用上述指南，应该可以解决大多数与过度测试和测试不足相关的问题。但万一被迫在测试不足和过度测试之间做出选择，决定取决于 SoC 的应用。汽车设计中，人身安全是首要考虑因素，应该选择安全的过度测试方法，而在功耗大的设计，例如在网络和无线领域，需要进行测试。即使对于这些情况，也应尽一切努力确保与所需频率的偏差尽可能小。

让我们举一个具有多个频率时钟的设计示例，这将有助于理解这个概念：

假设一个设计在 240MHz 上工作，我们有一个 2、3、4 等的多周期用于各种路径。还有一些接口工作在 10MHz 和 60MHz 的外部时钟上。为避免任何类型的过度测试或测试不足，请在全速模式下多次通过测试。在 240、120、80、60MHz 下配置 PLL，并以实际功能速度测试所有逻辑。

• 第一遍：@240MHz - 所有单周期路径（掩码 100MHz 和 60MHz 接口，其余 SDC 是标准的）
• 第二遍：@120MHz – 多周期 2 的路径（从 SDC 中删除多周期 2 异常）+ 100MHz 接口逻辑（过度测试化）
• 第三遍：@80MHz – 多周期为 3 的路径（删除 2 和 3 的所有多周期异常）
• 第四遍：@60MHz – 4条路径+60mhz接口逻辑的多周期路径（去除所有多周期异常）

结论 

随着 SoC 的功能变得越来越复杂以及技术向更低的节点转移，良好的成品率被证明是任何设计公司的一个重要关注点。收益率直接影响损益方程式，需要认真努力解决低收益率的原因。实速测试是衡量硅质量的重要标准，因此我们应该以高覆盖率为目标。但同时，我们应该只在适当的时钟频率下运行我们的实速模式，因为在错误的时钟频率下测试会导致问题过度测试或测试不足。这两种情况（测试不足和测试过度）既不利于设计 QOR，也不利于良率估算。

测试时钟应该与功能时钟同等重要，并且应该努力为不同的域提供相同频率的时钟，因为它们在功能域中被计时。同时，应该对多周期路径给予相当大的关注，因为它们通常构成任何设计中时序路径的重要组成部分。At-speed testing in multiple pass是解决多周期路径at-speed testing的方法。Multipass测试方法也可以用来解决其他过度测试和under-testing的情况。因此，总而言之，使用上述建议和方法，我们可以实现更准确的全速覆盖，这反过来将确保我们在不影响设计 QOR 的情况下将良率下降问题降至。