企业官网建设流程全解析

芯片测试这个话题，说大很大，说小也小。你要是刚入行，或者正被DFT（Design for Test，可测试性设计）的测试向量搞得焦头烂额，那你大概率绕不开这两个名字：Stuck-At和Transition Delay。我当年第一次流片回来，测试机台上刷出几百个fail的芯片，就是被这两个老朋友折腾得够呛。这篇博文不聊虚的，就讲讲我在实际项目里怎么跟这两种故障模型打交道，从原理到实操，再到那些文档里不会写、但你真的会踩进去的坑。

这篇内容的受众也很明确：正在做数字芯片的DFT工程师、测试工程师，以及刚接手可测试性设计的新人。如果你是做后端或者架构的，也可以看看，毕竟DFT做不好，你的芯片可能连测试这一关都过不去，更别提量产良率。

1. 故障模型是什么，为什么DFT离不开它

说到故障模型，你先忘掉那些花里胡哨的PPT概念。模型的本质，就是对物理缺陷的一种简化和抽象。芯片制造出来之后，晶圆上可能因为工艺偏差、金属桥接、氧化层击穿、接触孔失效等一堆原因产生各种各样的物理缺陷。你不可能每种缺陷都单独去测，那样测试成本会直接爆炸。所以DFT工程师做的事，就是把物理缺陷归类，映射成有限的几种“电气行为”模型，然后针对模型去生成测试向量。

1.1 从物理缺陷到逻辑故障：一次金属桥接的比喻

你可以想象一条马路上有两根并排的电线，如果其中一根因为施工断掉了，那信号就传不过去，这个就是“开路”，在逻辑上会表现为某个节点固定在某一个电平，这就是Stuck-At故障模型要抓的东西。如果两根电线之间不小心搭上了一根铁丝，信号可能互相干扰，逻辑值就可能被错误地拉到高或拉低，这也是Stuck-At的范畴，看起来还是“固定为某个值”。

但是如果情况换一下，不是断掉，而是电线之间出现了一个很细微的漏电通道，信号传过去需要的时间变长了，那么芯片的工作频率一高，这个信号就来不及稳定，最终在下一个时钟沿到来时被采到了错误的值。这种情况逻辑上并不是“固定”，而是“太慢”，这就是Transition Delay故障模型的核心。

搞懂这个区别很重要。Stuck-At管的是静态的“短路/开路”问题，而Transition Delay管的是动态的“变慢了”的问题。对应的测试方法也完全不一样，一个是测组合逻辑的定值，一个必须靠两个时钟沿来“推”一下信号翻转。

1.2 为什么模型化能拯救测试成本

这里说一个实际数字给你感受一下。一颗中等规模SoC，假设有1000万个等价逻辑门，如果逐点去测物理缺陷，你需要的测试向量数量可能是天文数字，测试时间按小时算，量产根本没人受得了。但通过故障模型，你只需要生成几百条到几千条测试向量，覆盖掉95%以上的Stuck-At故障，测试时间压缩到毫秒级。这就是模型化的意义。

而且，ATPG（Automatic Test Pattern Generation，自动测试向量生成）工具也是基于故障模型的。你要是不给工具一个明确的故障集合，工具根本不知道要测什么。所以，理解故障模型，不仅是理解测试本身，更是理解工具产出的每个coverage数字、每条pattern到底在干嘛。

2. Stuck-At故障模型实战：最基础也最容易被忽视

Stuck-At是DFT领域最老牌的故障模型，也是我做任何项目时第一个要看的指标。很多人觉得Stuck-At简单，覆盖率刷到98%、99%就觉得万事大吉了。但实际操作里，恰恰是这些基础的东西，最容易因为一些想当然的细节翻车。

2.1 Stuck-At故障是怎么产生的：三个基本概念先搞懂

Stuck-At模型假设电路中的某一个逻辑节点，固定为逻辑0或者逻辑1，无论输入怎么变都不变。所以一个节点对应两个故障：SA0（固定为0）和SA1（固定为1）。

要测出这个故障，需要满足两个条件：先把这个节点的“期望值”反着设，再把它“推”到输出端能观察到的地方。这个在DFT里叫可控性和可观测性。可控性是指你能通过输入端给这个节点赋值，可观测性是指你能在输出端看到它的变化。

我举个例子。假设有一个与门，输入是A和B，输出是Z。如果Z节点被Stuck-At 0了，你就要把A和B都设成1，这样正常时Z应该是1，但因为有故障，Z实际是0。这样你的测试向量就是“A=1, B=1”，预期输出是1，实际读到0，那就抓到了故障。这个看似简单的道理，在实际电路里会因为多级组合逻辑、扇出、反馈回路变得极其复杂，ATPG的D算法、PODEM算法全都是围绕怎么高效搜索可控和可观测路径展开的。

2.2 ATPG生成Stuck-At向量的过程：一次路径敏化的实操记忆

我最早学ATPG的时候，总觉得工具是黑盒，跑一下就出来向量了。后来自己手算过一个小电路，才真正理解什么叫路径敏化（Path Sensitization）。

路径敏化的意思，就是你选一条从故障点到输出端的通路，路径上所有其他输入都要设置为不影响故障传播的值。比如你要测一个与非门输出端的SA0，这个与非门有两个输入A和B。你要让输出为1时才满足抓SA0的条件，所以A和B里至少一个要为0。然后把这个输出信号作为后面一级逻辑的输入，你需要确保后面那级逻辑对这一路的信号“不屏蔽”，比如后面接的是一个或门，另一个输入必须为0，才能让故障信号穿过去。

真实ATPG工具做的是更聪明的算法，但本质离不开可控和可观测。所以你在做DFT的时候，凡是遇到不可测的故障，先别急着怪工具。大概率是电路里某个节点的可控性或可观测性被破坏了。比如三态门总线，一端drive不强，或者一个高扇出的信号被钳制，都会导致Stuck-At覆盖率卡住。

2.3 Stuck-At覆盖率到底看哪个数：别被报告骗了

跑完Stuck-At，工具会给你一个详细的coverage报告。你至少要会看这几个指标：

我见过一个项目，Stuck-At Fault Coverage报的是97%，乍一看挺高，但Test Coverage只有88%，因为那9%的差距全是untestable fault。这说明电路里有很多节点没法控制或没法观察。这个时候你要做的不是硬调ATPG参数，而是回去跟设计沟通，在RTL里加测试点（Test Point），比如在关键时刻加一个可控的MUX，或者把一个信号拉出来做观测。这是DFT工程师最有价值的产出之一。

2.4 实操心得：Stuck-At覆盖率卡在95%上不去？先查这三处

Stuck-At覆盖率卡在95%上不去？先查这三处。第一，检查你memory的BIST有没有正确接入。如果memory是黑盒，ATPG默认是进不去的，这部分故障挪到BIST去cover，如果BIST没做或者隔离逻辑不对，覆盖率直接就少一大块。第二，查一下时钟和异步复位网络的fault。这些节点往往扇出巨大，而且直接驱动时序单元，ATPG默认对它们的传播限制很多，覆盖率好看不了，一般通过专门的测试模式或约束来处理。第三，查跨时钟域的信号。CDC信号如果用不好，工具会把它设为nontestable，但实际上这些信号完全可以通过特殊方式测到，关键是约束要写对。

这几个点是我每次项目debug必看的几个方向。别一开始就怀疑工具配置有问题，大部分覆盖率上不去都是设计结构的问题。

3. Transition Delay故障模型：抓时序问题的核心武器

Stuck-At解决的是“坏了”的问题，但很多芯片的问题是“慢了”。比如一个跑1GHz的CPU，某条路径组合逻辑延迟是0.9ns，刚好能过。但工艺一波动，延迟变成了1.1ns，1GHz时钟下就setup违例了，芯片就跑挂了。这种问题用Stuck-At测不出来，你必须让信号在测试模式下真的翻转一次，然后看翻转沿能不能在预期时间内到达捕获点，这就是Transition Delay测试。

3.1 Transition Delay故障的实质：不是断路，是慢了一拍

Transition Delay模型假设的是，某条路径上的信号从0到1或者从1到0的跳变，花了比正常情况更长的时间。对应到故障模型上，就是Slow-to-Rise（慢上升，原来的0变1变慢了）和Slow-to-Fall（慢下降，原来的1变0变慢了）。

这两种故障分别对应一个节点上的两个方向的跳变。所以你可以这么记：一个节点上，Stuck-At会有SA0和SA1两个故障，而Transition Delay会有Slow-to-Rise和Slow-to-Fall两个故障，但每个故障的测试都至少需要一个“初始化”向量和一个“启动”向量。

这也就是为什么Transition Delay的测试向量长度通常是Stuck-At的两倍以上。Stuck-At的每个测试只需要一个时钟周期来稳定逻辑，而Transition Delay测试需要先让电路进入一个初始状态，再在下一个时钟沿让信号发生跳变，然后在捕获沿去采样最终结果。

3.2 Transition测试的两种方式：Launch-on-Capture和Launch-on-Shift

在真正的ATPG里，生成Transition Delay测试向量有两种主要的launch方式，这个选择直接影响你能测到什么样的时序路径。

Launch-on-Capture（LOC）是先通过移位链把初始状态装进扫描触发器，然后给一个捕获时钟脉冲。第一个捕获沿作为launch沿，让组合逻辑的信号开始翻转，第二个捕获沿作为capture沿，采样翻转后的结果。这个方式是模拟真实芯片功能时序场景的，更贴近实际，但问题在于capture时钟的间隔这一段，工具需要做完整的时序分析和约束，否则容易cover不准。

Launch-on-Shift（LOS）是让信号翻转发生在shift过程中，用最后一个移位时钟沿作为launch沿，紧接着的capture沿采样。这样对时序的可控性更强，故障覆盖率通常比LOC高，但代价是可能会测到一些非功能路径上的时序问题，容易产生误报（over-test），对设计的要求也更严格。

我实际项目里见过很多新工程师一上来就用LOC跑出90%多的Transition覆盖率，就以为没问题了。但换了LOS之后会发现覆盖率高出一截，同时也会带出一堆在LOC下“测不到”但实际上确实存在的slow path。所以理想做法是两条路都跑，然后对比结果。

3.3 OCC与时钟控制：Transition测试不能踩的雷

做Transition Delay测试，有个绕不开的模块叫OCC（On-Chip Clock Controller，片上时钟控制器）。它的作用是在测试模式下，把测试时钟从低速的shift时钟切换到高速的capture时钟。为什么需要这个切换？因为测试机台提供的时钟频率一般不高，通常几十兆赫兹，而你要测的芯片工作在几百兆甚至上GHz。你要是用低频时钟测Transition Delay，所有的Slow-to-Rise故障全都测不出来，因为信号有足够的时间翻转。

OCC通过PLL（锁相环）提供高速时钟，在capture阶段选择PLL时钟作为时钟源，而在shift阶段又切回测试机台的低速时钟。这个切换要保证在launch沿和capture沿之间没有任何毛刺，否则整个测试结果都不可信。

实际操作中，OCC的配置简直是一个debug泥潭。我踩过最大的坑是OCC的切换时序没配好，导致同一个pattern在低温下测试能过，高温下就全fail。后来定位到是PLL的lock时间不够，在测试频率切换后，PLL还没稳定就开始capture了。这类问题排查起来极其耗时，所以我的建议是：在做Transition Delay之前，先把OCC的仿真时序检查做透，确认launch沿、capture沿、时钟门控信号的相对关系都符合时序要求，再开始大规模跑向量。

4. Stuck-At与Transition Delay在项目里的联合实战

很多人觉得这两个模型是独立的，实际上在真实项目里，它们是一套组合拳。你既要用Stuck-At覆盖静态缺陷，又要用Transition Delay覆盖时序缺陷。更关键的是，它们对物理缺陷的覆盖范围是有重叠和互补的。

4.1 两种故障模型的核心差异对比

我整理了一张表，你可以在做项目规划时直接参考。

这张表里我最想强调的其实是最后一行。“Stuck-At覆盖率虚高但总体偏低”这句话，我解释一下。Stuck-At故障数量多，工具容易cover，所以数字看起来很高。但是如果你只依赖Stuck-At，很多时序问题（比如金属厚度偏差导致的路径延迟增加）是完全测不出来的。反过来，Transition Delay因为对时序敏感，一些并不影响芯片正常工作的路径（比如测试模式下的非功能路径）也会被报fail，这就是over-test，导致良率被误杀。

4.2 实际项目中是两条腿走路：先从shared bus DFT说起

有一个词叫shared bus DFT，是在热词里看到的，其实在很多总线架构的芯片里非常常见。当你有一条总线被多个模块共享时，DFT的最大难点不是故障模型选谁，而是可控性和可观测性的分配。比如总线上的某个bits驱动能力弱，某个模块在测试模式下没被选中，它的输出还悬在总线上，就会造成三态冲突，Stuck-At测出来一堆假故障，Transition Delay测出来一堆假时序违例。

处理shared bus DFT的核心思路是加隔离逻辑：在总线和共享模块之间插入隔离单元（Isolation Cell），测试模式下把不参与当前测试的模块全部强制成固定值，避免总线冲突。这个操作对Stuck-At和Transition Delay是通用的，但Transition Delay还要额外注意隔离单元的时序，因为它在capture模式下也是一个关键路径上的节点，隔离不干净会直接拉低覆盖率。

4.3 项目里的测试策略选择：先用Stuck-At垫底，再用Transition Delay查漏

我一般的做法是这样：芯片流片回来之后，第一轮先跑Stuck-At测试，先把静态缺陷筛掉一半以上。跑完之后如果还有fail的芯片，再看fail集中在哪些模块。如果某个模块Stuck-At覆盖率很高但fail率也很高，那就非常怀疑是时序问题，紧接着对这个模块单独跑Transition Delay，定位到具体是哪条路径慢了。

如果一开始就全量跑Transition Delay，一旦芯片fail率很高，你根本分不清是DFT逻辑本身的问题，还是真正的时序缺陷。先用Stuck-At把DFT逻辑的正确性验证一遍，再上Transition Delay，问题定位会清晰得多。这算是我踩过几次坑之后沉淀下来的方法论。

5. 芯片测试中的常见问题与Debug实战

不管Stuck-At还是Transition Delay，跑起来之后总会遇到各种各样的坑。这里我挑几个最典型的、也是最耗费时间的debug场景来分享。

5.1 场景一：Stuck-At覆盖率98%，但是芯片fail率反而更高了

遇到这种问题，第一反应不是去怀疑覆盖率，而是去怀疑测试向量本身有没有过度约束。我遇到过一种情况，ATPG为了cover一个极难测的fault，用了非常长的扫描链配置，结果扫描链里某个触发器因为DFT时钟树的问题，在capture阶段出现setup违例，导致预期输出全部错乱，芯片被误杀。

你对比一下fail chip的fail pattern是不是集中在某几条特定的低覆盖率向量上，如果是，优先检查这几条向量的扫描链配置，尤其是时钟端的约束。很多时候覆盖率数字好看，不代表每条向量都“干净”。

5.2 场景二：Transition Delay覆盖率很低，但Stuck-At很高

这个基本是OCC或者时序约束没配置好。很多项目第一次做Transition Delay，覆盖率出来只有50%多，不奇怪。最有可能是capture时钟的PLL频率设得太高，或者时序约束文件里没有正确指定launch和capture clock的相互关系。

你可以先用一个低速的capture时钟跑一遍，如果覆盖率明显上去，说明是时序约束问题。再反过来把频率逐步升高，找到覆盖率和误杀率的平衡点。这个“频率扫描”的过程非常关键，也是我调试时序问题时的拿手好戏。

5.3 场景三：ATPG跑出大量untestable故障

这个前面提过，大概率是设计结构问题。但我再补充一个不太容易被发现的点：异步复位信号上如果没有加DFT约束，ATPG会把相关时序单元的复位端的所有fault都打成untestable。因为工具认为复位是不可预知的，故障无法控制。

我的建议是，在综合阶段就做DFT约束审查。把异步复位统一做异步复位同步释放处理，并且给复位网络单独建立test mode的约束，确保复位路径在shift和capture阶段是可控的。这个建议我每次review项目都会说一遍，真的能省下后面很多debug的时间。

6. 一些工具配置和流程层面的建议

最后聊聊工具和流程层面的心得。市面上主流DFT工具无非就是Tessent、DFTMAX、TetraMAX这些，各家在故障模型的支持上都有差异，但核心流程是一致的。

第一步，综合前先定义好DFT接口。哪些pin是test mode使能，哪些是扫描使能，哪些是OCC的时钟控制。这些在RTL阶段就要规划好，等网表出来了再想改，成本要高很多。

第二步，做DRC检查。不管是哪家工具，跑ATPG之前都会做DFT rule check。你要认真看Error和Warning。我见过有些项目为了赶进度，DRC有几百条Warning就直接往后跑了，结果测试向量在机台上跑fail率超高，回头再查全是DRC问题。

第三步，约束先行。Stuck-At和Transition Delay的约束有不少差异点，尤其是时钟。Transition Delay必须明确指定sdc或者专门的test constraint，把launch clock、capture clock、OCC的enable信号的关系定义清楚。

第四步，看log和报告要比看summary更细。工具summary可能只显示一个coverage数字，但log里每个fault group的分类、untestable fault的原因代码，才是真正能指导你debug的信息。

第五步，养成做fault simulation的习惯。ATPG产生的pattern在形式上是正确的，但它是否真的能抓到故障，最好做一次带时序的fault simulation验证。这一步虽然耗时，但对于良率敏感的产品，价值是巨大的。

我自己的习惯是，主流程跑完之后，会专门留一天时间来复查关键模块的fault report，确保没有任何遗漏的低覆盖率模块。这种“扫雷式”的审查，能提前发现很多潜在的量产风险。

7. 最后的实战心得

这些东西都是我一个个坑踩出来的。芯片测试这个行当，最怕的就是迷信工具输出。覆盖率数字再漂亮，都不如你深入理解了一个故障的行为模式。Stuck-At和Transition Delay，本质上是你和芯片缺陷对话的两种语言，掌握好它们，你就能在DFT调试、良率分析、甚至RTL质量评估上，都比别人多看出好几层东西。

我个人实际项目里的体会是，新入门的朋友不要一上来就追求100%覆盖率，那是神仙才能做到的事。先把Stuck-At做到95%以上，Transition Delay在80%-85%以上，然后回头去抠那剩下的几个百分点，每一个都是你对电路理解加深的一个台阶。等你哪天看到一条fault report，不用开波形就能猜到问题出在哪个模块、哪条路径上，那你才算是真正出师了。