芯片级故障诊断基础：故障模型与核心概念
各位同学，今天我们聊聊芯片级故障诊断的根基——故障模型。说实话，这可能是整个课程里最“枯燥”但又最绕不开的部分。我做了十五年车规MCU，见过太多工程师一上来就追着看测试向量怎么生成，结果连最基本的故障模型都没搞明白。嗯，这就像盖楼不打地基，迟早要出问题。
咱们先想一个问题：芯片为什么会坏？
从物理层面看，可能是晶圆上的颗粒污染、光刻对准偏差、金属线断裂，甚至是封装时的热应力。但从测试的角度，我们得把这些物理缺陷抽象成“故障模型”。说白了，就是用数学语言描述“芯片哪里坏了、怎么坏的”。
一、经典故障模型：Stuck-at、Transition、Bridging
1. Stuck-at 故障（固定故障）
这是最经典的模型，也是我入行时学的第一个。它假设芯片内部某个节点（比如逻辑门的输出）永久性地固定在逻辑0或逻辑1上，不管输入怎么变，它都不动。
举个例子：一个两输入与非门，正常情况输入(1,1)输出0，输入(0,1)输出1。但如果输出端 stuck-at 0，那不管输入是什么，输出永远是0。
关键点：
- Stuck-at 0 (SA0) 和 Stuck-at 1 (SA1) 是最基本的两种
- 一个节点可能同时存在SA0和SA1，但通常我们只考虑单故障模型
- 覆盖率计算时，通常以“检测到的故障数/总故障数”来衡量
我个人习惯把Stuck-at模型当作“入门级”测试。车规芯片要求至少99%的Stuck-at覆盖率，但说实话，这远远不够。我在项目中遇到过一颗MCU，Stuck-at覆盖率做到了99.8%，结果上电后还是跑飞了——因为问题出在时序上，不是静态故障。
2. Transition 故障（跳变故障）
这个模型关注的是信号从0变1或从1变0时，能不能在规定时间内完成。说白了，就是检查芯片的“反应速度”。
为什么会这样？因为芯片内部有RC延迟，如果某个晶体管的驱动能力变弱，信号跳变就会变慢。慢到一定程度，下一个时钟沿来临时，数据还没稳定，就会采到错误值。
Transition故障分两种：
- Slow-to-Rise (STR)：从0变1太慢
- Slow-to-Fall (STF)：从1变0太慢
我记得有一次做车规MCU的ATE测试，发现某个IO口的输出在低温下总是出现毛刺。查了半天，原来是Transition故障——PMOS管在低温下迁移率下降，导致上升沿延迟超标。嗯，这种问题Stuck-at模型根本抓不到。
3. Bridging 故障（桥接故障）
这个模型模拟的是两条信号线之间意外短路。可能是金属桥接、多晶硅桥接，甚至是衬底漏电导致的“软桥接”。
Bridging故障比前两种复杂得多，因为它涉及两个节点之间的相互作用。比如：
- AND桥接：两个节点短路后，逻辑上相当于相与
- OR桥接：短路后相当于相或
- Dominant桥接：其中一个节点“主导”另一个
注意：Bridging故障的测试向量设计非常讲究。我曾经吃过亏——用自动生成的向量去测桥接，结果覆盖率虚高，实际流片回来一堆短路问题。后来我学乖了，必须结合版图布局，手动补充一些“相邻节点对”的测试。
二、故障覆盖率：你到底测了多少？
故障覆盖率，公式很简单：
故障覆盖率 = (检测到的故障数 / 总故障数) × 100%但这里有个坑：总故障数怎么算？
对于Stuck-at模型，通常每个节点算两个故障（SA0和SA1）。一个100万门的芯片，总故障数大约200万。但实际测试时，很多故障是“等价”的——测了一个就等于测了另一个。所以真正的“有效故障数”会少一些。
车规芯片的要求：
| 故障模型 | 最低覆盖率要求 | 我的建议 |
|---|---|---|
| Stuck-at | 99% | 尽量做到99.5%以上 |
| Transition | 95% | 关键路径必须100%覆盖 |
| Bridging | 90% | 根据版图密度调整 |
你想想看，覆盖率99%听起来很高，但200万个故障里还有2万个没测到。这2万个里只要有一个是致命故障，芯片上车后就会出问题。所以，我个人习惯把目标定得比标准高一点——给自己留点余量。
三、测试良率：不是越高越好
测试良率 = (通过测试的芯片数 / 总测试芯片数) × 100%
很多人觉得良率越高越好，其实不一定。良率太高可能说明你的测试向量太“松”，漏掉了不少故障。良率太低则说明工艺有问题，或者测试向量太“严”。
我见过一个案例：某MCU的测试良率高达99.5%，客户很满意。结果上车后，在高温环境下频繁死机。后来一查，是Transition故障没测到——因为测试向量只用了慢速时钟，而实际应用跑的是高速时钟。这就是典型的“测试良率虚高”。
避坑指南：我曾经犯过一个错误——为了赶项目进度，把测试良率从95%硬拉到98%。方法是放宽了时序裕量。结果呢？流片回来的芯片在客户那边大量退货。从那以后，我坚持一个原则：测试良率必须建立在真实的故障覆盖率之上，不能为了数字好看而牺牲测试质量。
四、DPPM：车规芯片的“生死线”
DPPM = Defective Parts Per Million，百万分之缺陷率。
公式：
DPPM = (失效芯片数 / 出货芯片总数) × 1,000,000车规芯片的DPPM要求有多严？
- 消费级：几百到几千DPPM
- 工业级：几十到几百DPPM
- 车规级：通常要求 < 10 DPPM，甚至 < 1 DPPM
1 DPPM意味着什么？你出货100万颗芯片，最多只能有1颗失效。这几乎是不可能完成的任务——因为测试本身就有误差，而且芯片在生命周期内还会老化。
所以，车规芯片的DPPM不是靠“测”出来的，而是靠“设计”和“工艺”共同保证的。测试只是最后一道防线。
我记得有一次，一颗MCU的DPPM从5降到了0.8，客户非常满意。但代价是什么？测试时间从2秒增加到了8秒，测试成本翻了两番。这就是车规芯片的残酷现实——性能和成本永远在博弈。
五、总结一下
今天讲的这几个概念，是芯片级故障诊断的基石：
- 故障模型：Stuck-at、Transition、Bridging，分别对应静态、时序、短路三类问题
- 故障覆盖率：别只看数字，要关注“没测到的那部分”
- 测试良率：真实比好看更重要
- DPPM：车规芯片的终极目标，但需要全流程努力
下一章，我会带大家深入ATE测试向量生成，讲讲怎么用工具自动生成向量，以及如何手动补充关键路径的测试。到时候我会分享一个我踩过的坑——自动生成的向量漏掉了一个关键故障，导致流片后返工。嗯，那真是血的教训。
今天就到这里。有问题随时交流。