第二章：测试基础理论——故障模型、覆盖率、ATPG与故障仿真
各位同学，欢迎来到测试理论的核心章节。说实话，很多工程师做了好几年设计，对测试的理解还停留在“跑个ATPG看看覆盖率”的阶段。但真正遇到芯片回来fail的时候，才知道基础不牢有多痛苦。今天我就带大家把这几个硬骨头啃下来。
2.1 故障模型：芯片为什么会坏？
芯片制造不是完美的。晶圆上的灰尘、光刻的偏差、金属线的断裂……这些物理缺陷最终会表现为逻辑错误。我们做DFT的人，就是要用数学模型去描述这些物理缺陷。这就是故障模型。
2.1.1 Stuck-at 故障模型
这是最经典的模型，也是我入行时学的第一个模型。说白了，就是假设某个节点永远固定在逻辑0或逻辑1，不管你怎么驱动它。
- Stuck-at-0 (SA0)：节点被强制拉到地，永远输出0
- Stuck-at-1 (SA1)：节点被强制拉到电源，永远输出1
举个例子，一个两输入与非门，如果输出端SA0了，那不管输入是什么，输出永远是0。我在项目中遇到过一种情况：芯片在ATE测试时发现某个寄存器总是读不到正确值，追查下来是扫描链上的一个缓冲器SA1了。嗯，这种问题在早期工艺节点很常见。
关键点：Stuck-at模型假设故障是永久性的。一个节点要么SA0，要么SA1，不会同时存在。对于CMOS电路，单个节点的Stuck-at故障数 = 2 × 节点数。
2.1.2 Transition 故障模型
随着工艺进步，芯片速度越来越快。Stuck-at模型只能检测静态故障，但芯片在高速运行时，信号翻转可能来不及完成。这就是Transition故障模型要解决的问题。
Transition故障关注的是信号从0→1或1→0的跳变过程。如果跳变太慢，在采样时刻还没完成，就会出错。
- Slow-to-Rise (STR)：上升沿太慢
- Slow-to-Fall (STF)：下降沿太慢
我记得有一次做28nm芯片的at-speed测试，Stuck-at覆盖率做到了99%，但Transition覆盖率只有85%。结果流片回来，芯片在低频下完全正常，一跑到目标频率就随机出错。后来加了Transition测试向量，才把问题抓出来。你想想看，如果只做Stuck-at测试，这种问题根本发现不了。
个人经验：对于先进工艺（28nm以下），我建议Transition测试的覆盖率目标至少定在90%以上。低于这个数，流片风险会显著增加。
2.1.3 Bridging 故障模型
Bridging故障，说白了就是两根不该连在一起的线短路了。在深亚微米工艺中，金属线间距越来越小，桥接故障的发生概率越来越高。
桥接故障有两种主要类型：
- AND桥接：两个节点短路后，逻辑表现为线与（如果一方为0，另一方也被拉低）
- OR桥接：两个节点短路后，逻辑表现为线或（如果一方为1，另一方也被拉高）
我曾经处理过一个案例：芯片在ATE测试时，某个模块的功耗异常高。排查了几个月，最后发现是两条相邻的电源线之间发生了桥接。这种故障用传统的Stuck-at模型根本测不出来，必须用专门的Bridging测试向量。
注意：Bridging故障的测试向量数量通常比Stuck-at多一个数量级。在实际项目中，我们一般只对关键路径和敏感区域做Bridging测试，全芯片做的话测试时间会爆炸。
2.2 测试覆盖率：你到底测了多少？
覆盖率是衡量测试质量的核心指标。但很多人只盯着一个数字看，这是不对的。我见过不少团队，Stuck-at覆盖率做到99%就沾沾自喜，结果芯片回来一堆问题。为什么？因为覆盖率有很多种，每种反映的问题不同。
| 覆盖率类型 | 含义 | 典型目标 |
|---|---|---|
| Stuck-at覆盖率 | 检测到的Stuck-at故障数 / 总故障数 | ≥98% |
| Transition覆盖率 | 检测到的Transition故障数 / 总故障数 | ≥90% |
| 桥接覆盖率 | 检测到的桥接故障数 / 总桥接故障数 | ≥85% |
| 动态覆盖率 | 实际翻转的节点数 / 总节点数 | ≥95% |
这里我要强调一点：覆盖率不是越高越好。为什么？因为覆盖率从95%做到99%，测试向量数量可能要翻10倍。而测试时间直接关系到芯片成本。我个人的习惯是：先定一个合理的覆盖率目标，然后针对未覆盖的区域做定向分析，而不是盲目地加向量。
核心原则：覆盖率是手段，不是目的。我们的目标是确保芯片在真实场景下能正常工作。有时候，覆盖率99%的芯片可能比98%的芯片更容易出问题——如果那1%恰好是关键路径的话。
2.3 ATPG基本原理：自动生成测试向量
ATPG，全称Automatic Test Pattern Generation。说白了，就是让工具自动生成测试向量，用来检测芯片中的故障。手动写测试向量？那是不可能的，一个百万门的芯片，手动写向量写到下辈子都写不完。
ATPG的核心思想很简单：
- 故障激活：让故障节点产生一个与正常值不同的信号
- 故障传播：把这个差异信号传播到某个可观测的输出端
举个例子，检测一个与非门输出端的SA0故障：
- 激活：让两个输入都是1，这样正常输出应该是0，但SA0故障下输出还是0——不对，这样激活不了。正确的做法是让输入为(1,0)或(0,1)，正常输出为1，故障下输出为0，这样差异就出来了。
- 传播：把这个差异信号通过后续逻辑传到输出端
ATPG工具用的算法主要有两种：
- D算法：基于布尔差分的穷举搜索，适合小规模电路
- FAN算法：改进的D算法，通过扇出分析和回溯剪枝，效率更高
我记得刚入行时，导师让我手动推导一个简单电路的ATPG向量。我花了整整一天才搞定一个20门的电路。后来用工具跑，0.1秒就出来了。嗯，从那以后我就再也不敢小看工具了。
实用技巧：ATPG工具生成的向量通常包含大量冗余。在实际项目中，我会先用工具跑一个快速模式，看看哪些故障覆盖不到，然后手动调整约束条件。这样比直接跑全量ATPG节省至少50%的时间。
2.4 故障仿真：验证你的测试向量
ATPG生成了向量，但你怎么知道这些向量真的能检测到故障？答案就是故障仿真。故障仿真的本质是：在电路中注入故障，然后用测试向量去跑，看看能不能把故障抓出来。
故障仿真的流程大致如下：
- 故障列表生成：从网表中提取所有可能的故障点
- 故障注入：在仿真模型中修改某个节点的逻辑值
- 仿真运行：用测试向量驱动电路，观察输出
- 结果比对：比较故障电路和正常电路的输出，如果不同，说明该故障被检测到了
这里有个坑：故障仿真非常耗时。一个百万门的芯片，全故障仿真可能要跑好几天。我见过一个团队，为了追求完美，跑了整整一周的故障仿真，结果发现覆盖率只提升了0.5%。
避坑指南：我曾经犯过一个错误——在故障仿真时没有考虑时序。结果仿真通过，但实际芯片在ATE上就是过不了。后来发现，有些故障在静态仿真下能检测到，但在动态时序下根本激活不了。所以，对于Transition故障，一定要用时序仿真。
故障仿真的输出通常是一个覆盖率报告，格式如下：
Fault Coverage Report
---------------------
Total faults: 1,234,567
Detected faults: 1,210,000
Undetected faults: 24,567
Coverage: 98.01%
Breakdown by fault type:
Stuck-at-0: 98.5%
Stuck-at-1: 97.8%
Transition STR: 91.2%
Transition STF: 90.5%看到这个报告，我会重点关注Undetected faults。如果这些故障集中在某个模块，我会去检查那个模块的测试结构是不是有问题。如果分布很均匀，那可能是测试向量不够，需要加一些定向向量。
2.5 小结：这些理论怎么用在实际项目中？
好了，理论讲完了。但我知道你们最关心的是：这些东西在实际项目中怎么用？我给大家总结几条实战经验：
- 故障模型的选择：对于成熟工艺（65nm以上），Stuck-at模型基本够用。对于先进工艺，一定要加上Transition和Bridging模型。
- 覆盖率目标的设定：不要盲目追求100%。我一般设定Stuck-at 98%、Transition 90%、Bridging 85%作为基线，然后根据芯片的用途调整。比如车规芯片，要求会更高。
- ATPG和故障仿真的配合：先用ATPG生成向量，然后用故障仿真验证。如果覆盖率不达标，分析未覆盖的故障，手动添加定向向量。
- 测试时间的权衡：测试向量越多，覆盖率越高，但测试时间也越长。在量产中，测试时间直接换算成成本。我一般会在设计阶段就评估测试时间，确保不超过ATE的预算。
下一章，我们会进入DFT设计的核心——扫描链设计。到时候我会详细讲怎么把扫描链插入到你的设计中，以及怎么处理那些让人头疼的时序问题。咱们下章见。