基于TPDF模型的老化感知硬件自测试覆盖率评估方法

1. 项目概述：为什么我们需要重新审视硬件自测试的覆盖率评估？

在汽车电子、轨道交通、航空航天这些安全至上的领域，硬件（HW）的可靠性不是“加分项”，而是“生命线”。随着芯片制程不断微缩，晶体管尺寸越来越小，时钟频率越来越高，一个无法回避的现实是：硬件会“老化”。这种老化不是宏观上的磨损，而是微观层面晶体管电学特性的缓慢漂移，最终表现为信号在芯片内部路径上传播的延迟不断增加。当延迟累积到超过时钟周期约束时，错误就发生了。

传统的硬件自测试，尤其是基于软件的自测试（SBST）或软件测试库（STL），在评估其有效性时，长期依赖一个简单但已显疲态的模型：固定型故障（Stuck-at）模型。这个模型假设某个电路节点永久性地“卡”在逻辑0或1。它简单、工具链成熟，覆盖率计算直观，但它有一个致命的缺陷：它完全无法刻画由老化引起的、分布式的、与时间相关的时序退化。用固定型故障模型来评估一个旨在检测老化故障的测试库，就像用尺子去称重量——工具本身就不对路。

因此，业界和学术界一直在寻找更真实的故障模型。过渡路径延迟故障（Transition Path Delay Fault, TPDF）模型应运而生。它不再关注单个节点的“静态”错误，而是关注信号在一条完整逻辑路径上传播的“动态”延迟。这完美契合了老化效应的本质——延迟是沿着路径上的多个门电路累积起来的。然而，TPDF模型的引入带来了新的挑战：路径数量爆炸（组合爆炸）、故障概率非均匀分布、路径间存在相关性。这使得我们无法再像对待固定型故障那样，简单地随机采样一部分故障进行模拟来估算覆盖率。

我过去参与过多个符合ISO 26262 ASIL-D等级的车规芯片项目，深感在安全论证中，提供基于真实物理失效机制的覆盖率证据有多么重要，又有多么困难。客户和审核方不再满足于一个漂亮的、但基于不真实假设的覆盖率数字。他们需要知道：“在你的芯片预期的15年生命周期内，考虑到实际的工作负载和温度波动，你的自测试软件到底能多大概率捕捉到由老化引发的时序错误？”

这正是本文要探讨的核心：一套完整的、模块化的、端到端的方法论，用于基于TPDF模型评估软件自测试的诊断覆盖率，并且全程融入老化感知（Aging-Aware）的考量。这不是一个纸上谈兵的学术构想，而是一个力求在现有电子设计自动化（EDA）工具链中落地实践的工程框架。接下来，我将拆解这个框架的每一个环节，分享其中的设计思路、实操细节以及我们趟过的“坑”。

2. 核心原理：从晶体管老化到系统失效的链条

要理解整个评估方法，必须首先厘清从最底层的物理效应到系统级可观测错误之间的完整链条。这有助于我们明白每个步骤存在的意义。

2.1 晶体管老化的微观机理

在先进制程（如45nm及以下）中，影响可靠性的主要老化机制包括：

• 负偏压温度不稳定性（NBTI）：主要影响PMOS晶体管。当栅极施加负电压（对于PMOS，即Vgs < 0）且温度较高时，硅-二氧化硅界面处的硅氢键断裂，产生界面态，导致阈值电压Vth绝对值升高，晶体管变“慢”。
• 热载流子注入（HCD）：主要影响NMOS晶体管。当晶体管开关时，高能载流子（电子）注入栅氧层，造成损伤，同样导致Vth升高和迁移率下降。
• 时间依赖介电击穿（TDDB）与电迁移（EM）：前者是栅氧层的长期击穿，后者是互连线金属原子的迁移，两者都会导致灾难性故障，但通常不在功能性延迟故障的常规建模范围内。

关键点在于：NBTI在晶体管输出稳定时被激活，而HCD在开关瞬态时被激活。这意味着，一条路径上各个门电路的老化程度，强烈依赖于该路径被“使用”的模式——信号是频繁翻转还是长期保持静态。这直接引出了“工作负载（Workload）”的重要性。

2.2 从老化到路径延迟：老化函数

为了量化老化影响，研究人员建立了老化函数。一个经典的模型（如Huard模型）将相对延迟退化表示为：Δd/d = S * (A(t))^n其中：

• Δd/d：相对延迟增加量。
• S：灵敏度参数，与门类型、老化机制和工艺技术相关。
• A(t)：激活函数，封装了时间t、工作负载（信号概率SP、翻转率等）、电压、温度等因素。
• n：加速因子，与工艺技术和老化机制相关。

例如，对于NBTI，A(t)可能与信号处于“应力”状态（对PMOS是低电平）的时间比例（信号概率）相关；对于HCD，则可能与翻转次数、边沿速率有关。

实操心得：选择或校准一个合适的老化函数是第一步，也是最容易产生误差的一步。在项目中，我们通常与芯片制造厂（Foundry）紧密合作，获取他们基于硅片测试数据校准的模型参数。如果缺乏厂商数据，使用公开文献中的模型（如针对45nm OSU FreePDK库的模型）是一个起点，但必须清楚其局限性，并在安全论证中予以说明。

2.3 TPDF模型：连接老化与功能错误的桥梁

固定型故障模型说：“这个点永远为0”。过渡延迟故障（TDF）模型说：“这个点从0变到1（或1变0）太慢了”。而过渡路径延迟故障（TPDF）模型则更进一步：“这一系列特定的0/1跳变，沿着这条特定的物理路径传播，整体太慢了，导致在捕获时钟沿，终点寄存器的值采样错误。”

一个TPDF故障由三个要素唯一定义：

1. 起点（Startpoint）：寄存器或原始输入。
2. 终点（Endpoint）：寄存器或原始输出。
3. 过渡序列（Transition Sequence）：从起点到终点，路径上每个门的输入引脚上要求的信号跳变方向（上升沿或下降沿）序列。

为什么TPDF更真实？考虑一个由10个门组成的路径。老化可能使每个门的延迟都增加一点点（比如1ps）。固定型故障模型完全无法描述这种情况。TDF模型只能描述“某个点”的慢跳变，但无法体现这10ps的累积效应。而TPDF模型精确地描述了“这10个门依次产生的延迟累积，最终导致路径总延迟超标”。它完美匹配了分布式老化的物理本质。

3. 方法论全景：三阶段工作流

我们的评估框架围绕三个核心阶段展开，形成一个完整闭环：

[老化场景与网表] -> [阶段一：失效路径选择] -> [失效路径集合] ^ | | v [覆盖率结果] <- [阶段三：覆盖率评估] <- [阶段二：故障注入] <- [软件测试库（STL）]

3.1 阶段一：老化感知的失效路径选择

目标是从海量的可能路径中，筛选出那些在预期老化场景下最有可能首先引发时序违例（即失效）的路径集合。这是整个方法成败的关键，直接决定了后续评估的针对性和效率。

3.1.1 时间零延迟分析

输入：CPU的门级网表、标准单元库的时序文件（Liberty文件）。工具：静态时序分析（STA）工具，如Synopsys PrimeTime或开源工具OpenSTA。过程：STA工具分析网表中所有路径在初始状态（time-zero）下的时序。它计算每条路径的建立时间、保持时间以及松弛时间（Slack）。松弛时间是时钟周期减去路径实际传播时间后的余量，初始为正。输出是一个标准延���格式（SDF）文件，记录了每个时序弧的延迟信息。注意：这里使用的是“最好情况”或“典型情况”的时序库，代表芯片出厂时的状态。

3.1.2 CPU使用率剖析

输入：CPU网表、目标工作负载（如一段自动驾驶的感知算法代码）。工具：门级仿真器（如Synopsys VCS、Cadence Xcelium）。过程：在门级仿真器上运行目标工作负载，监控网表中所有信号节点的活动。记录关键数据：

• 信号概率（SP）：信号为逻辑1的时间占比。这对NBTI建模至关重要。
• 翻转率（Toggle Rate）：信号单位时间内的跳变次数。这对HCD建模至关重要。输出：切换活动交换格式（SAIF）文件。这个文件将抽象的“工作负载”转化为每个晶体管/门电路具体的“压力”画像。

3.1.3 失效时间估计

这是核心的迭代过程。

1. 设定老化场景：确定老化函数及其参数（S, n, 电压，温度等）。这定义了一个具体的“老化故事”。
2. 老化延迟计算：结合时间零SDF和SAIF文件中的活动数据，使用老化函数计算在某个假想寿命时间t后，每个时序弧的新延迟d_aged = d_nominal + Δd(t)。
3. 生成老化后SDF：创建一个新的SDF文件，包含老化后的延迟值。
4. 重新执行STA：将老化后的SDF反标到网表，再次运行STA。
5. 判断是否失效：检查最坏路径的松弛时间。如果松弛时间变为负值（或接近零的某个阈值内），则认为在该老化时间t下，CPU已失效。记录此时的t为t_fail。
6. 迭代搜索：由于t_fail未知，通常采用二分查找法，迭代调整t，快速找到使临界路径松弛时间归零的寿命点。

避坑指南：这个过程计算量巨大。对于复杂CPU，一次STA可能需要数小时。迭代数十次来寻找t_fail是不可接受的。在实践中，我们采用“最坏路径追踪”和“增量STA”技术。不是每次迭代都进行全芯片STA，而是聚焦于上一轮识别出的最坏路径及其相邻路径，大幅提升效率。

3.1.4 候选失效路径提取与过滤

在得到t_fail后，使用老化后的SDF进行完整的STA分析，提取所有松弛时间为负的路径，形成“候选失效路径集”。

但并非所有时序违例的路径都能在实际操作中被触发。这里需要过滤掉伪路径（False Path）或不可敏化路径（Unsensitizable Path）。这些路径由于电路逻辑结构或输入序列的限制，在实际工作负载中根本不可能被遍历。对它们进行测试和评估没有意义。

我们的方法：采用基于仿真的路径过滤。我们为每条候选路径插入一个“路径检查器（Path Checker）”。这是一个轻量级的硬件监控电路（通常通过修改测试平台或插入断言实现），其核心是边沿检测器。当路径上规定的特定跳变序列按顺序发生时，检查器会输出一个脉冲。在门级仿真中运行真实工作负载，只有那些能触发路径检查器输出的路径，才被认为是“可敏化的”，被保留在最终的“失效路径集”中。

为什么不用ATPG工具？ATPG（自动测试向量生成）工具是筛选伪路径的利器，但它有两个问题：1) 它假设可以通过扫描链（Scan Chain）任意控制内部寄存器，而软件自测试只能通过CPU指令集（ISA）访问，可控性差很多；2) ATPG的路径选择基于“可测试性”，而非“老化失效概率”。我们的仿真方法虽然依赖于具体负载，但更贴近软件自测试的实际运行环境。

3.1.5 多老化场景探索

单一老化场景（一组固定的电压、温度、负载参数）得出的路径集可能不具有代表性。现实中，芯片的工作环境是变化的。因此，我们需要进行老化参数空间探索。

操作：将关键老化参数（如温度范围、电压波动、负载强度因子）在其可能的变化范围内离散化，形成一个多维网格。对网格中的每一个点（即一个老化场景），重复执行上述3.1.1至3.1.4的流程。最后，取所有场景下得到的失效路径集的并集，作为最终用于评估的“失效路径全集”。这确保了评估的鲁棒性，覆盖了多种可能的未来老化状态。

3.2 阶段二：TPDF故障注入的实现

有了失效路径集，下一步是评估软件测试库（STL）能否检测到这些路径上发生的TPDF故障。这就需要故障注入。

核心挑战：主流的商用故障注入工具（如Synopsys Z01X）对固定型故障支持良好，但对TPDF的原生支持有限，且通常价格昂贵。我们的目标是在标准的、零延迟（Zero-Delay）门级仿真环境中，低成本地模拟TPDF故障效应。

我们的方案：在测试平台中插入自定义的“故障注入器”逻辑。

3.2.1 故障注入器设计

故障注入器的核心目标是：当且仅当指定的TPDF路径被激活时，让路径终点的寄存器采样到错误的值（错过预期的跳变）。

实现方式是对终点寄存器的标准单元进行“包装”。我们创建一个包装模块，其内部实例化原来的寄存器，并增加一个fault_active控制信号。

module dff_wrapped ( input wire clk, input wire rst_n, input wire d, // 原始数据输入 input wire fault_active, // 故障激活信号 output reg q // 寄存器输出 ); reg d_ff; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin d_ff <= 1‘b0; q <= 1’b0; end else begin d_ff <= d; // 正常采样 // 如果故障激活，则输出保持前一个状态（模拟跳变错过） // 否则输出新采样的值 q <= fault_active ? q : d_ff; end end endmodule

当fault_active为高时，寄存器输出q保持原值，相当于错过了当前时钟沿本应捕获的新值d_ff，完美模拟了因路径延迟过大导致的采样错误。

3.2.2 完整的故障注入测试平台

如何生成fault_active信号？它应该是两个信号的逻辑与：

1. path_trigger：来自3.1.4中提到的路径检查器。只有当指定的跳变序列沿目标路径发生时，此信号才在对应时钟周期内拉高。
2. fault_enable：全局故障使能信号。用于在仿真中控制是否注入故障，方便对比正常和故障情况。

因此，对于每一条需要注入的TPDF路径，测试平台中都需要实例化一个对应的路径检查器和一个包装后的寄存器（故障注入器）。path_trigger信号连接检查器输出，fault_enable可作为测试平台的配置参数。

仿真流程：

1. 黄金仿真：设置fault_enable=0，运行工作负载，记录所有关键寄存器的输出波形作为黄金参考。
2. 故障仿真：设置fault_enable=1，针对某条TPDF路径，运行相同工作负载。当该路径被激活时，fault_active生效，终点寄存器值出错。
3. 结果对比：比较故障仿真输出与黄金参考。如果软件测试库（STL）中的检测机制（如检查计算结果、运行冗余校验等）能捕获到这个错误并触发错误标志（如写特定状态寄存器、产生中断），则认为该TPDF故障被检测到。

实操心得：自动生成这个包含数百甚至数千���路径检查器和故障注入器的测试平台是工程关键。我们开发了Python脚本，读取失效路径集（通常从STA工具报告或自定义格式文件中解析），自动生成对应的Verilog检查器模块和顶层测试平台连接代码。这保证了流程的可扩展性。

3.3 阶段三：诊断覆盖率的评估与解读

这是最终产出结果的阶段。我们需要一个能反映TPDF模型和老化的覆盖率指标。

3.3.1 重新定义覆盖率

传统固定型故障的覆盖率是：C = (检测到的故障数) / (总故障数)。这个定义在TPDF模型下不再适用，因为：

• 故障（路径）不是独立的。
• 故障的发生概率（路径失效概率）不是均匀的。
• 我们关注的是“系统因老化失效”这一事件被检测到的概率。

我们借鉴了安全工程中的概念，将覆盖率分解为两部分：

• 失效模式覆盖率：给定某种失效模式（这里是“特定TPDF路径失效”），错误检测机制能发现它的概率。这通过阶段二的故障注入实验来估计。
• 假设覆盖率：当系统发生失效时，该失效是由我们所考虑的失效模式（TPDF）引起的概率。这衡量了我们所选故障模型（TPDF）对现实世界失效机制的贴合程度。

总覆盖率可近似为两者的乘积。TPDF模型相比固定型故障模型，其假设覆盖率被认为显著更高，因为它更贴近物理实际。

3.3.2 基于老化场景的覆盖率计算

我们的评估不是对单一路径进行“是/否”检测，而是放在老化场景的背景下。

1. 路径失效概率：对于失效路径全集中的每条路径P_i，其失效概率Prob(Fail_Pi)可以估算为：P_i出现在所有模拟老化场景的失效路径集中的次数 / 总老化场景数。这来自于阶段一的多场景探索。
2. 场景检测能力：对于一个特定的老化场景s，它对应一个失效路径子集FPS(s)。我们运行故障注入实验，检查STL能否检测到该子集中至少一条路径失效（因为一条路径失效就可能导致系统错误）。如果能，则记该场景被覆盖。
3. 整体覆盖率：最终的诊断覆盖率可以计算为：C = (被覆盖的老化场景数量) / (总的老化场景数量)。

这个指标更具实际意义。它回答的问题是：“在芯片生命周期内可能遇到的各种老化条件下，我的自测试软件能覆盖其中多大比例的情况？”

3.3.3 结果分析与报告

输出不应只是一个数字。一份完整的评估报告应包括：

• 失效路径分析：列出最关键（出现频率最高）的失效路径，及其所属的功能模块（如ALU、浮点单元、取指单元）。这为STL的优化提供了直接指导。
• 场景覆盖矩阵：以表格形式展示不同电压、温度、负载组合下（即不同老化场景）的覆盖情况，识别STL的薄弱工作点。
• 检测延迟分布：对于检测到的故障，统计从故障发生到错误被软件标志出来的时钟周期数。这对于评估系统的容错时间窗口至关重要。

4. 实战案例：基于RISC-V Rocket Core的评估

为了验证方法论，我们选择了一个开源RISC-V CPU核——Rocket Core，采用45nm OSU FreePDK标准单元库进行综合。

4.1 实验设置

4.2 执行过程与关键发现

1. 路径选择结果：对dhrystone负载在81个老化场景下进行分析，初始候选失效路径有数千条。经过基于仿真的路径过滤后，最终失效路径集缩小到约120条。这些路径高度集中在少数几个关键时序模块，如数据访存单元和分支预测器的前向路径。
2. 故障注入：我们为该CPU开发了一个简单的SBST库，包含算术逻辑单元（ALU）测试、寄存器文件March测试和指令缓存一致性检查。使用自动生成的测试平台，对120条路径逐一注入TPDF故障。
3. 覆盖率结果：在81个老化场景中，有73个场景的失效路径集中，至少有一条路径的故障能被我们的SBST库检测到。因此，场景覆盖率为90.1%。
4. 与固定型故障对比：我们对同一CPU和SBST库运行了传统的固定型故障注入。固定型故障覆盖率高达98.5%。这巨大的差距（98.5% vs 90.1%）正是模型保真度的体现。固定型故障模型高估了检测能力，因为它没有模拟那些更隐蔽、由分布式延迟累积引发的时序错误。

4.3 遇到的挑战与解决方案

• 挑战一：仿真速度。门级仿真加入大量路径检查器后速度极慢。解决方案：采用混合仿真策略。首先用更快的RTL仿真或指令集仿真器（ISS）快速运行工作负载，记录下触发关键路径的指令序列和时间窗口。然后在门级仿真中，只加载这一小段“关键激励”进行精细的故障注入和观察。这能将仿真时间从数天减少到数小时。
• 挑战二：路径检查器面积开销。在真实的芯片设计中，我们不可能在硅上插入这些监控电路。解决方案：路径检查器仅用于评估阶段的仿真测试平台，不在最终产品中实现。我们的方法是一种评估方法论，而非设计实现。
• 挑战三：老化模型的不确定性。模型参数（如加速因子n）的微小变化可能导致t_fail预测差异巨大。解决方案：进行敏感性分析。在报告中不仅给出一个覆盖率数字，同时给出关键参数（如温度、电压）在一定范围内波动时，覆盖率的置信区间。这比一个孤立的数字更有说服力。

5. 总结与展望

这套基于TPDF模型和老化感知的软件自测试覆盖率评估方法，其价值在于将芯片可靠性评估从“静态的、理想化的”层面，推进到了“动态的、贴近物理现实的”层面。它迫使安全工程师和测试开发者去思考一些根本问题：我的芯片会在什么条件下老化？老化了会怎样出错？我的测试真的能抓到这些错误吗？

我个人在实际操作中的体会是，这个过程最大的收获往往不是那个最终的覆盖率百分比，而是在执行路径筛选和故障注入时，对CPU微架构脆弱点的深刻理解。你会发现，某些看似复杂的运算单元反而不是最脆弱的，而一些负责控制信号传递的简单路径，由于负载活跃度高，更容易因老化而失效。这种洞察对于设计更有针对性的、低开销的在线自测试程序至关重要。

目前，这套方法更适用于设计后期或芯片回片后的深度验证阶段。未来的工作方向很明确：一是向前端延伸，与商业EDA工具链（如Synopsys、Cadence）更深度集成，实现一键化流程；二是向更先进工艺扩展，研究FinFET、GAAFET等新器件的老化模型如何融入本框架；三是反馈于设计，利用失效路径分析结果，指导下一代SBST库和甚至CPU微架构的协同设计，打造天生更具老化韧性的安全关键系统。

最后，一个务实的建议：在项目初期，如果资源有限，可以不必对全芯片运行���此详尽的分析。而是聚焦于最核心的安全机制路径，例如锁步（Lockstep）双核的比较器路径、安全岛的关键控制路径等。对这些“皇冠上的明珠”进行TPDF级别的覆盖率评估，能以较小的代价，极大提升整体安全论证的可信度。毕竟，在安全领域，深度往往比广度更重要。