第2章 Memory故障模型

Memory故障模型：静态故障、动态故障、耦合故障、地址译码故障

好，咱们今天聊聊Memory的故障模型。说实话，这部分内容我当年刚接触时也觉得有点抽象，但后来在实际项目中吃过亏，才真正理解了它的重要性。

你想想看，一颗芯片里动辄几十上百个Memory，每个都可能有各种奇奇怪怪的故障。如果不把这些故障模型搞清楚，那BIST算法设计就是空中楼阁。我个人习惯，先把故障分门别类，再针对性地设计测试方案。

静态故障，说白了就是存储单元卡死在某个状态了。比如一个bit位，你写0它读出来是0，写1它读出来还是0——这就是典型的 stuck-at-0 故障。

我在项目中遇到过一种情况：某款SRAM的某个字线驱动能力不足，导致整行单元都 stuck-at-1。当时查了好久，最后用March C-算法才抓出来。

静态故障主要分两类：

关键点：静态故障是最基础的故障模型，但也是最容易被忽略的。很多新手以为只要写1读1、写0读0就完事了，其实不然。

动态故障就有点意思了。它不是单元本身坏了，而是读写操作之间的时序关系出了问题。

我记得有一次调试一个高速SRAM，频率跑到1GHz以上时，某些地址的读数据偶尔会出错。静态测试全过，但动态测试就暴露了。后来发现是读使能信号的建立时间不够——这就是典型的动态故障。

常见的动态故障包括：

我的经验：动态故障往往和工艺角、温度、电压都有关系。做测试时，建议至少跑三个corner：slow-slow、fast-fast、typical。我曾经在slow-slow corner下抓到过动态故障，但在typical下完全正常。

耦合故障，嗯，这是最让人头疼的一类。它指的是一个单元的状态变化，影响了另一个单元的状态。

你想想看，Memory阵列里单元挨得那么近，寄生电容、串扰、电源噪声，都可能造成耦合。我见过最夸张的一个案例：某个地址写1，结果相邻的四个地址都跟着变成了1——这就是典型的耦合故障。

耦合故障分几种：

注意：耦合故障的检测非常依赖测试算法的顺序。比如March C-算法能检测大部分耦合故障，但如果你用错了顺序，可能漏掉。我建议做测试时，至少跑两个不同方向的March算法。

地址译码故障，说白了就是地址线出了问题。你访问地址A，结果实际访问的是地址B，或者同时访问了多个地址。

这类故障通常发生在地址译码器、字线驱动、位线选择这些地方。我遇到过最离谱的一次：地址线短路，导致两个地址被同时选中，写操作变成了对两个单元的写——数据完全乱套了。

地址译码故障的典型表现：

好了，故障模型讲完了，那怎么测呢？这里有个映射关系，我整理成了一张表：

核心原则：没有一种算法能覆盖所有故障。实际项目中，我通常会用March C-作为基础，再根据工艺和设计特点，补充一些针对性测试。

举个例子，我之前做的一个28nm的SRAM项目，工艺比较激进，动态故障风险高。我就在March C-的基础上，增加了写后立即读、读后立即写这些时序敏感的操作。结果还真抓到了几个动态故障。

嗯，这里要注意一点：测试算法的选择不是越复杂越好。算法越复杂，测试时间越长，面积开销也越大。你得在覆盖率和成本之间找平衡。

我个人习惯的做法是：先用March C-跑一遍，如果覆盖率达标，就不再加算法。如果发现某些故障漏检，再针对性地补充。这样既保证了质量，又控制了成本。

避坑指南：我曾经在一个项目里，为了追求100%覆盖率，堆了四个March算法。结果测试时间长了3倍，面积大了20%，最后发现March C-加上一个简单的地址扫描就够用了。所以，别过度设计。

好了，故障模型和算法映射就聊到这儿。下一章咱们会深入讲March算法的具体实现，包括状态机设计、地址生成、数据比较这些实战内容。到时候我会拿一个实际项目中的BIST控制器来拆解，保证干货满满。