前阵子一颗MCU项目回片ATPG跑出来的Stuck-At覆盖率98.7%看着挺漂亮结果量产测试掉进良率泥潭——现场应用端反复报读写异常拆了几颗芯片回来做failure analysis定位到的失效点居然是一根很普通的地址线延迟故障。当时所有人都盯着那根线的版图看了半天最后想起做DFT的同事提过一句话“Stuck-At再高也只管稳态故障Transition Delay覆盖了多少你查过没有”这篇文章就把这件事彻底讲透。围绕芯片测试里最常用的两类DFT故障模型——Stuck-At和Transition Delay结合我这些年做DFT插入、ATPG约束、量产测试程序bring-up的实际经验把模型的行为本质、覆盖率陷阱、扫描链配置和量产权衡一次聊完。适合正在做数字IC DFT的工程师、芯片验证和测试工程师也适合刚入行想搞清楚“覆盖率数字到底怎么来的”的同学。1. Stuck-At与Transition Delay拆开来看这两类故障的行为本质1.1 Stuck-At模型没那么简单芯片测试里说的Stuck-At故障模型简称SA模型抽象出来就两句话一根信号线要么被固定拉在逻辑0要么被固定拉在逻辑1。对应SA0和SA1两类故障。但真正往物理实现里想这个抽象其实覆盖了一大类真实缺陷——金属线断裂、金属与电源或地短路、晶体管的栅氧击穿导致节点无法正常充放电、甚至某些接触孔工艺偏差最后在逻辑行为上都表现为“不管输入怎么翻输出都钉死在某个电平”。我常见很多人问Stuck-At是不是太粗糙了粗糙但便宜。它只需要一个测试向量就能激活并观察故障对测试时钟频率没有要求慢速测试时也能稳定工作。所以时至今日SA覆盖率依然是晶圆测试和封装测试的“基本面”。大部分成熟工艺下数字逻辑的SA测试覆盖率会设定在97%以上汽车电子和工控类的项目甚至会要求到99%以上。但SA模型的局限也在“稳态”两个字上。它假设故障一旦发生逻辑电平就是错的。可现实中更常见的情况是电平在慢速时钟下能建立到正确值一旦时钟频率提上去信号根本来不及翻转到位——这在SA模型里是完全不敏感的。也正因为这样高SA覆盖率并不能回答“这颗芯片在最高工作频率下能不能稳定跑起来”的问题。1.2 Transition Delay测的是“翻转迟到”Transition Delay故障模型一般叫TD模型补的正是SA的盲区。它不关心节点最终停在0还是1而关心节点从0翻到1、或者从1翻到0的这个过程是否太慢。具体拆成slow-to-rise和slow-to-fall两类故障本质上是把“延迟超标”当作一种故障来对待。TD故障测试和SA有个关键区别必须用两个测试向量。第一个向量把节点初始化到起点状态第二个向量让它发生一次翻转然后在紧跟着的高速捕获时钟沿上观察是否被正确锁存。如果节点翻转速度慢到没能在捕获沿前稳定下来逻辑就会采到错误值测试就判定为fail。实际操作中TD测试的时钟波形设计通常有两种方式项目launch-off-captureLOClaunch-off-shiftLOS启动翻转方式最后一个shift沿先初始化再通过捕获时钟的第一拍launch翻转扫描链移位过程中最后一个shift沿直接launch对扫描使能信号要求相对宽松需要先退出shift模式再进捕获模式扫描使能翻转时间充裕严格扫描使能必须在很短时间内从shift切换到capture时序收敛难对时序路径的覆盖覆盖的是逻辑路径上的真实时序和功能模式接近启动沿从扫描链的FF直接发出覆盖部分路径但与真实功能时序有偏差测试向量的生成复杂度较低ATPG工具更容易处理较高对物理实现和DFT约束的要求更严我在实际项目里LOC用得更多因为它对后端实现友好也更容易满足ATE上的时序要求。LOS虽然覆盖率效率高一些但对扫描使能信号的建立时间要求特别苛刻一旦后端时序收敛不好反而会在ATE上批量误判这坑后面会细说。1.3 为什么很多量产失效只有TD模型才能捞出来回到开头那颗MCU。地址线延迟故障为什么SA覆盖率98.7%都没拦住因为地址线在慢速测试频率下比如10MHz它的RC延迟只有几纳秒远小于100ns的周期逻辑结果完全正确。等到系统跑到几十甚至上百MHz时地址线上的延迟打到了半个周期以上建立时间违例读取数据就错位了。这类问题在功能测试里偶尔能撞上但你没法保证功能激励恰好踩中那根最慢的路径。TD模型的作用就是用结构化的方式把电路中所有关键节点的翻转行为都测一遍。实际跑TD覆盖率的时候通常不会像SA那样冲到99%。因为TD模型对时序路径和约束非常敏感很多false path、multicycle path、异步信号如果不做例外处理会出现大规模的假故障。一个经验值消费电子类芯片TD覆盖率做到85%以上算比较健康关键模块再单独加约束做收敛。但这不代表剩下的15%不重要而是要把有限的pattern预算花在最容易出问题的逻辑上比如跨时钟域的同步器、时钟门控单元、复位释放路径。2. 覆盖率数字的水分100%Stuck-At背后藏着的失效场景2.1 冗余故障怎么把覆盖率“注水”ATPG工具跑完后报一个99.5%的SA覆盖率看着确实让人放心。但我第一次用SPICE级失效注入去核对覆盖率意义的时候发现了一个很微妙的问题覆盖率公式里的分母不是“芯片上所有可能物理失效”而是“ATPG工具分析出的可检测故障列表”。这两者之间的差就是冗余故障。所谓冗余故障指的是电路中某些节点即使被固定成0或1也不会在任意主输出或扫描触发器上体现出来。这里面有两类情况一类是设计里确实存在逻辑冗余比如某些保护电路、双模冗余投票逻辑某个支路挂了系统仍然能工作另一类是约束导致的伪冗余工具在指定约束下分析认为这故障不可测但约束一旦放开故障可能又变成可测的了。这带来一个直接的坑如果项目团队只看工具报告的覆盖率不去检查“不可测故障列表”里到底有哪些合理、哪些是约束误伤就可能出现两种情况——要么覆盖率被冗余故障虚高看着99%其实有效覆盖没那么高要么覆盖率被约束误伤的故障拖低怎么加pattern都上不去。正确做法是在项目早期就建立故障分级列表把工具标注的untestable故障分门别类review一遍尤其要盯紧约束误伤的部分。2.2 X态传播是覆盖率失真的头号敌人如果说冗余故障是“分母注水”那X态传播就是“把一个本应测到的故障变成测试噪声”。芯片里总有这么几个角落上电时未初始化的寄存器和RAM、三态总线在驱动使能之前的浮空状态、外部IP的未知输出。如果你不做处理这些X态会沿着组合逻辑一路传播把路径上所有故障观测点都污染了。ATPG工具为了保险只能把受X态影响区域内的故障标记为“可能不可测”覆盖率自然就掉下来了。更麻烦的是即使覆盖率数字没掉X态导致的pattern仿真结果不收敛工具生成出来的pattern在ATE上跑的时候结果可能是随机fail良率莫名其妙往下掉。处理X态的拳头手段有三个X态阻断单元在上电或进入测试模式时强制把高风险节点钳位到确定值X态传播友好逻辑设计阶段就避免让三态总线直接驱动观测逻辑ATPG工具层面的X态掩蔽设置让工具自动生成掩蔽表。我在工具端配置X态处理时一般会做一轮“X传播仿真”把pattern灌进去看仿真结果里有没有X态冒头。这一步不值钱但能省掉后面大批量回片测试时的排障时间。2.3 等价故障塌缩与重汇聚扇出模型重叠造成的高估刚开始学DFT的人有个直觉——故障数量越多覆盖率越真实。但恰恰相反ATPG工具在跑故障模拟前会先做故障塌缩把大量“行为等价”的故障合并成一个代表故障。比如一个与非门的输出接地和该输出驱动的下一级输入接地从原始输出观测到的效果完全一样它们就是等价故障。塌缩之后故障列表大幅度缩小运行时间大幅减少这本身是好事。需要警惕的是重汇聚扇出结构下的故障重叠。某个逻辑锥里的两条路径从同一个起点分开走一圈后在某个观测点重新汇聚那么路径上的故障在故障模拟时可能被“重复”激活和观测导致覆盖率统计偏乐观。打个比方三个人从同一个门出发走不同的房间最后又回到同一个出口你站在出口数人头会以为来了三个人其实源头只有一个人。工程上处理这个问题靠的是故障模拟工具的精确概率统计但我们作为使用者要记住覆盖率不是一个绝对真实值而是一个相对参考值。同一条扫描链、同一套约束条件下覆盖率从90%涨到95%是有效提升但换了不同约束条件后两个覆盖率数字之间不一定有可比性。所以我在项目里会固定一套“黄金约束文件”只在统一前提下比较覆盖率变化。3. ATPG与扫描链配置里的实战陷阱3.1 shared bus DFT共享总线上扫描链的三态竞争与管理这几年做多核芯片和AI加速器一个绕不开的DFT架构就是shared bus DFT。传统扫描链是一根chain一根chain直接连到芯片管脚上可一旦内核数量多起来测试引脚就成了稀缺资源。shared bus的做法是把多条扫描链通过一组共享总线和测试访问机制TAM连接起来测试数据在总线上分时复用。好处显而易见引脚大幅节省。但坑也相当典型。最危险的是三态竞争两个内核的扫描链在同一时刻都想驱动共享总线总线就会被两个驱动源同时拉结果是未知逻辑、大电流和热失效风险。仿真阶段经常发现不了这类问题因为仿真激励恰好没构造出两个驱动源同时使能的时序一旦硅片回来ATE上跑高速pattern瞬间电流就可能让某个电源域崩掉。我的经验是shared bus DFT的验证清单里必须有这几项确认每条扫描链的片选信号只在对应时隙有效检查总线隔离单元在非使能状态下确实输出高阻或钳位而不是维持上一次数据在故障模拟层面针对总线仲裁逻辑本身插入专门的SA和TD测试pattern最后在ATE bring-up阶段第一次跑全速pattern时把电源电流监测打开如果电流曲线明显异常先怀疑总线驱动冲突。3.2 电源域约束漏了pattern会在芯片上白跑低功耗设计现在是标配多电压域、电源关断、电压降级都是常态。DFT如果没跟着做好隔离和钳制ATPG工具往往会拿一个关断掉的电源域里的寄存器生成pattern或者在PDNPower Down模式下搜索一条不存在时序的路径。这类问题的典型表现是DVT仿真的pattern全部通过芯片回片后一跑到某个power sequence步骤测试结果就乱来。我给过不止一个项目补做UPF/CPF约束。需要检查的约束包括每个电源域的电源状态定义是否完整隔离单元isolation cell在关断模式下输出钳制信号是否已预置电平转换单元level shifter的时序约束有没有被STA覆盖扫描链是否跨过了常开和关断域的边界如果跨了关断域的扫描单元必须有专门的test mode电源策略。说实话这部分内容不会直接改变故障模型的覆盖率公式但它几乎决定了pattern的“可信度”。覆盖率再高如果测试环境本身不稳定相当于在一把歪尺子上做精密测量越准越离谱。3.3 launch-off-capture的两个时钟陷阱LOC模式虽然对大多数项目是友好选项但用起来不是零成本。两个地方最容易出问题。第一个是扫描使能信号scan_enable的时序。LOC模式下扫描使能需要先释放shift模式进入功能时钟的第一拍和捕获沿之间留出足够的建立时间。如果scan_enable走的是普通信号路径而不是专门做了时钟树插入的测试信号它的树延迟很可能在高速捕获时钟下变成新的违例来源。实际项目里我会要求后端在scan_enable上加专门的延迟匹配约束而不只是跟普通数据路径一样处理。第二个是跨时钟域路径的例外处理。LOC模式下的捕获时钟如果是自由运行的那么两个异步时钟域之间的路径在测试时也可能被当成真实路径去测延迟。不加例外的话ATPG工具会生成大量针对跨时钟域长路径的TD pattern。这些路径在功能上是false path测试它们只会浪费时间、增加pattern数量还容易产生假fail。解决办法是在SDC文件里把这类路径设置成false_path同时把这些例外同步给ATPG工具。但要小心别一刀切——如果某些跨时钟域路径是设计里的真实握手路径你又把它们都设成了false_path那真正的时序故障就被忽略掉了。这块需要DFT人员和验证人员一起review例外清单。4. 从Pattern到量产测试成本、DPPM与良率的三方拉扯4.1 pattern数量和覆盖率曲线的边际收益判断每个pattern在ATE上跑都是有成本的。越长的测试时间意味着每小时通过更多芯片的低产能上限这是直接折算成钱的。而且pattern数量多测试程序加载时间长测试头切换和pattern retargeting消耗的时间也会上升。看覆盖率- pattern数量曲线的时候大多数人会盯着覆盖率从90%到95%这段因为增长很快。真正需要冷静的是95%以上的部分从95%到96%可能只要加500个pattern从98%到99%可能得再加5000个。边际收益差了一个数量级。SA覆盖率目标通常需要的pattern规模变化适用场景90%~95%基准消费电子快速测试、低成本方案95%~97%基准的1.5~2倍常规消费/工控MCU97%~99%基准的3~5倍汽车电子、高可靠性应用99%以上指数级增长特定安全标准强制要求所以我在项目里很少盲目追高覆盖率。我会先和系统工程师确认DPPM目标再反推覆盖率和pattern预算。很多时候95%到97%的差距可以通过优化约束、改善扫描链平衡来填补而不是无脑加pattern。4.2 PVT对Transition Delay结果的反直觉影响TD测试的结果和芯片实际工作的电压、温度、频率强相关。同一颗芯片在1.1V、25℃测试可能通过在0.95V、85℃测试就可能fail。这不是玄学是CMOS工艺的PVT特性电压高、温度低的时候晶体管开关速度快电压低、温度高的时候延迟变大。量产测试通常在标称电压下做但为了让TD测试有足够的可靠性余量有些项目会把TD测试的捕获电压往下调一档。这个决定很微妙——电压太低良率损失夸大会把大量塔尖芯片误杀电压太高又可能放过真故障。我在一个电源管理芯片项目上就做过对比捕获电压从1.0V降到0.9VTD fail率瞬间从0.3%涨到2.1%。这里面有真故障也有大量margin不足的“边缘芯片”。处理这一类问题的常用手段是shmoo测试在ATE上扫描电压和频率两个维度画出芯片的通过/失败二维边界图。从shmoo图上能直观看出TD fail的分布是集中在某个电压-频率角落还是散布在全局。集中角落的多半是测试条件本身过严散布全局的可能是工艺或设计问题。4.3 量产测试程序bring-up的翻车现场量产测试程序第一次在我手上跑起来的时候最让人血压飙升的永远是仿真全部通过ATE上一跑fail率奇高。这时候第一反应通常应该是怀疑pattern但真正有经验的工程师会先查tester环境。我总结过一套四步定位法基本能覆盖大部分翻车场景。第一步跑同一个pattern的仿真检查ATE上的timing set是否和仿真一致这一步能排除pattern本身和测试时序不匹配的问题。第二步拿已知良品芯片跑一遍完整测试程序如果良品也fail说明环境配置有问题比如电平阈值设错、驱动强度不够、时序校准窗口没对准。第三步看fail分布是否集中在某几个测试项上如果是重点检查这几个测试项对应的时钟端口供电或时钟树配置。第四步最后才考虑是不是芯片本身的问题这时候才需要拉生产批次信息、晶圆Map数据做关联分析。这套流程看起来朴素但能避免一个常见误区一上来就把问题定性为“芯片坏了”然后拉着设计团队查三天电路最后发现是ATE上的差分时钟端口极性接反了。5. DFT计算智能体与shared bus DFT的现代演进5.1 EDA工具里的“DFT计算智能体”究竟在算什么最近这两三年各家EDA工具都在推“计算智能体”这个概念DFT领域也不例外。这些智能体不是科幻意义上的AI更准确的说法是把大量自动化分析和优化逻辑封装起来在ATPG和诊断流程里做决策。比如在pattern生成过程中智能体可以根据当前的覆盖率上升速率自动决定是继续生成pattern还是切换到故障诊断模式在良率fail时它能把log文件里的fail信息映射到具体扫描单元直接在版图层面标出可疑时钟区域。我在工具链里实际感受到的最大变化是以前我需要手工分析哪个模块的TD覆盖率拖了后腿、再手动写约束去改善现在工具能在第一轮运行后直接给出建议——某条路径的延迟余量不足建议把该区域标记为false path或者建议在某个IP的入口处加X态阻断单元。这确实省掉了大量重复劳动。但要注意智能体的判断能力完全取决于喂给它的约束和IP行为模型。如果SDC里没定义清楚的时钟关系智能体再聪明也会生成一批实际上没法用或误判率高的pattern。所以我不赞成“用了智能体就可以放松约束”的说法恰恰相反约束质量决定了自动化的上限。5.2 AI芯片测试中的shared bus DFT场景回到AI芯片这个热门方向。多核NPU、片上网络、大量SRAM和近存计算单元这些结构让测试需求变得非常特殊。一方面内核数量和IP规模大了测试引脚非常紧张另一方面AI芯片的高功耗密度意味着全速测试时的电源完整性风险很大不能所有内核同时全速扫描。shared bus DFT在这里反而成了刚需通过共享总线分时访问各个计算核的扫描链每次只让一小部分模块进入全速测试模式控制同时翻转规模。对AI芯片的测试工程师来说shared bus DFT再接上计算智能体一个很实用的场景是自动诊断当某个计算核的pattern在ATE上fail时系统可以通过总线上附带的诊断寄存器把fail扫描单元的信息读出来再由智能体自动定位到具体的写数据通路、读数据通路或者运算单元。我做过一次NPU项目的fail诊断AI辅助直接把可疑范围从几百个宏单元缩小到十几个再结合版图去看半小时内就定位到了某个SRAM的外围敏感放大器。这类项目的共享总线上还有其他要注意的点比如总线位宽和扫描数据路劲的匹配、分时调度逻辑的故障覆盖、以及跨die和跨模块的总线隔离。dft通用性上共享总线方案比独立扫描链方案复杂但在多核时代收益非常明显。5.3 故障模型不会消失只会换座次有些人会问做内建自测试BIST、存内计算、甚至用系统级功能测试直接替代结构化DFT故障模型是不是该进历史垃圾堆了我的看法是短期内不会。MBIST定位RAM单元失效很有效但它只能测存储阵列系统级功能测试覆盖的是真实应用场景可对“某根时钟门控信号延迟变大”这类细微而致命的缺陷功能激励的命中率非常低。结构化DFT的故障模型提供的是一套可计算、可统计、可诊断的统一框架它在可测试性设计里的位置很难被替代。未来更可能出现的是混合策略复杂芯片沿用SA和TD模型做结构性覆盖BIST补充存储类故障覆盖功能测试做最终验收再由计算智能体统一分析所有测试数据自动给出失效根因和良率优化建议。故障模型依然是整个链条的地基只是上面建的房子越来越多。最后说句实在话DFT故障模型的选型和覆盖率目标本质上是工程权衡不是拍脑袋填数字。我见过太多项目在早期没把测试策略定清楚等到流片回来才手忙脚乱补pattern、调约束结果测试时间翻倍、良率反而更低。如果你想从这篇文章带点什么走我建议把这几件事记到项目checklist里明确SA和TD两类覆盖率的目标值提前Review不可测故障清单把shared bus DFT的总线竞争验证做扎实ATPG约束一定要和STA约束保持同步。芯片测试这个行当做得越好越无声不好好做就只好等流片回来听天由命了。