芯片测试这个话题说大很大说小也小。你要是刚入行或者正被DFTDesign 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故障测试时间压缩到毫秒级。这就是模型化的意义。而且ATPGAutomatic 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。这样你的测试向量就是“A1, B1”预期输出是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报告。你至少要会看这几个指标指标含义我的关注点Fault Coverage检测到的故障数 / 总故障数这是你最常对外汇报的数Test Coverage检测到的故障数 / (总故障数 - 未检测故障数)比Fault Coverage更能反映ATPG的真实水平Untestable Faults由于电路结构本身导致无法测试的故障这块是要做RTL修改或加测试点的依据我见过一个项目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.1ns1GHz时钟下就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-CaptureLOC是先通过移位链把初始状态装进扫描触发器然后给一个捕获时钟脉冲。第一个捕获沿作为launch沿让组合逻辑的信号开始翻转第二个捕获沿作为capture沿采样翻转后的结果。这个方式是模拟真实芯片功能时序场景的更贴近实际但问题在于capture时钟的间隔这一段工具需要做完整的时序分析和约束否则容易cover不准。Launch-on-ShiftLOS是让信号翻转发生在shift过程中用最后一个移位时钟沿作为launch沿紧接着的capture沿采样。这样对时序的可控性更强故障覆盖率通常比LOC高但代价是可能会测到一些非功能路径上的时序问题容易产生误报over-test对设计的要求也更严格。我实际项目里见过很多新工程师一上来就用LOC跑出90%多的Transition覆盖率就以为没问题了。但换了LOS之后会发现覆盖率高出一截同时也会带出一堆在LOC下“测不到”但实际上确实存在的slow path。所以理想做法是两条路都跑然后对比结果。3.3 OCC与时钟控制Transition测试不能踩的雷做Transition Delay测试有个绕不开的模块叫OCCOn-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-AtTransition Delay故障本质节点固定为0或1节点翻转速度慢测试需要单沿测试双沿测试launch和capture测试时钟通常低速即可需要高速捕获时钟向量长度较短通常是SA的两倍以上覆盖率指标追求98%以上追求90%以上已是优秀典型缺陷金属桥接、开路、短路工艺波动、关键路径延迟超限主要风险覆盖率虚高但总体偏低容易over-test这张表里我最想强调的其实是最后一行。“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不用开波形就能猜到问题出在哪个模块、哪条路径上那你才算是真正出师了。