做DFT的人可能都经历过这样一个阶段项目快要流片了ATPG覆盖率还挂在92%上不去领导每周例会都问一句“覆盖率还能不能提”你一开始觉得是小case结果各种手段试了一圈真的就卡死了。这篇内容我尽量把DFT ATPG提升coverage这件事讲透——从架构、逻辑、ATPG生成、测试点插入到具体案例把那些能真正把coverage往上拉的方法论和细节全部摊开讲。文章不会只停留在“跑一下工具、看几眼报告”的层面而是会告诉你怎么判断瓶颈到底在哪、每一步操作背后的理由是什么以及我踩过的坑。1. 先从“覆盖率”这个数字说起你到底在追什么1.1 coverage的本质是风险度量不是KPI很多工程师把coverage当成一个必须达标的数字比如99%、99.5%好像达到了就万事大吉。但DFT的coverage本质上是一个风险度量它告诉你芯片里的逻辑故障有多少能被测试向量覆盖到、能在生产测试中被检测出来。剩下的未覆盖部分不是“不存在风险”而是“还没被证明是好的”。这个认知直接决定了你后续的操作思路。比如当你盯着报告里那1%的未覆盖故障时你要想的不是“怎么硬凑几个向量把它盖掉”而是“这部分逻辑为什么测不到、是不是存在设计问题、它在真实应用场景下会不会出问题”。我见过不少团队为了冲99%的覆盖率硬塞了一堆毫无区分度的测试向量结果测试时间翻倍silicon故障检出率却没有本质提升这就是把风险度量做成了KPI表演。1.2 先看懂报告test coverage、fault coverage和DC coverageATPG工具的报告里有几个容易混淆的指标指标定义实际意义Fault Coverage检测到的故障数 / 全部故障数含未测试故障最常用的报告指标Test Coverage检测到的故障数 / (全部故障数 - 未测试故障)剔除了不可测故障更能反映ATPG真实能力DC Fault Coverage动态电流IDDQ测试覆盖用于特定缺陷检测与逻辑覆盖率互补Statically Untestable静态不可测故障通常由冗余逻辑、约束条件造成我建议你重点关注Test Coverage而不是Fault Coverage因为Fault Coverage会把“不可测”的故障也拉进分母导致数字偏低。比如说你插了scan chain但某些异步逻辑没有做constraint报告显示一堆unobservable故障Fault Coverage就是99%可实际上你想知道的是、在正常的可测试条件下ATPG到底把多少真实故障打出来了。另外需要在报告里区分两类不可测stuck-at untestable和delay untestable。前者是逻辑冗余后者往往涉及时序路径上的约束两类问题的处理方式完全不同。1.3 不要把综合后的coverage当成最终结果还有一个常见误解用综合网表跑一次ATPG看到覆盖率差不多就收工了。实际flow里从综合网表、DFT插入网表到布局布线后的网表coverge会发生变化。尤其是走线延迟引入的真实时钟树、scan chain重排、时钟门控单元的插入都会影响最终的ATPG覆盖率。所以业内正常做法是综合阶段和DFT阶段各跑一些quick pattern做预检签核阶段的一定要用post-route网表、带真实的时钟树和约束来跑最终覆盖率。否则你在前端看到的百分比到了后端很可能会掉一截那时候再回头改DFT架构就非常被动了。2. 提升coverage的底层逻辑可控性与可观测性2.1 coverage本质受限于可控性和可观测性先打个比方。测试芯片逻辑故障就像警察在一个迷宫里找一个藏起来的人。scan chain给了你一个监控系统让你可以从入口把任意状态灌进去可控性也可以从出口把任意状态读出来可观测性。ATPG的所有算法本质上就是在解决这两个问题怎样才能把某个节点设置成目标值怎样才能把它的响应传出来。所以提升coverage永远是两条路一是提高可控性让更多逻辑节点能被设置成需要的状态二是提高可观测性让更多逻辑节点的响应能被捕获并传出来。很多人在ATPG层面折腾选项不如先检查一下设计里到底哪些节点“看不见、摸不着”。而这些节点通常就是覆盖率漏洞的核心来源。2.2 哪些逻辑天然影响可控性和可观测性根据我的经验常见的“漏洞点”包括黑盒black box逻辑比如某些模拟IP接口、未建模的第三方宏单元它们内部的故障测不到边界上的逻辑也容易因为无法控制/观察而成为未覆盖。Memory和BIST逻辑大容量SRAM通常用MBIST覆盖但memory周围的控制逻辑如果不做约束会拖累周边ATPG coverage。跨时钟域CDC逻辑同步器、脉冲同步等结构如果不做约束ATPG会报大量unstable或untestable故障。异步复位/置位逻辑扫描单元如果异步复位没有被properly处理复位树相关逻辑往往无法观测。多周期路径Multicycle Path和false path约束缺漏会让ATPG生成错误的时序假设导致transition fault覆盖率异常。在做任何coverage提升动作之前先把这些逻辑筛选出来搞清楚报告的uncoverage分布在哪里比盲目加pattern重要得多。2.3 coverage提升的三级火箭架构、逻辑、ATPG我习惯把coverage提升手段分为三级架构级、逻辑级、ATPG级。架构级决定了覆盖率的天花板比如你scan chain怎么接、时钟怎么处理、memory是不是用了BIST逻辑级是在设计里加测试点、修冗余逻辑ATPG级是调整故障模型、约束、向量生成策略。实际项目里大多数人只用了第三级也就是在ATPG工具里调参数结果天花板就在那里再怎么调也就那样。要做提升必须先审视前两级。3. 架构层面把覆盖率天花板抬高3.1 scan chain设计对coverage的影响有多大scan chain的插入方式直接决定了ATPG工具能把多少逻辑变成“可见”。我做过一个对比实验同样一个IP用默认的scan chain插入方式和经过优化的插入方式覆盖率相差1.5到2个百分点。这不是小数目尤其在项目要求99%的时候。核心原则是尽量让每一条scan chain的路径短而均衡避免把大量逻辑挂在一条超长链上否则不仅shift时间变长ATPG对这条链上的故障观察也会因为链上冲突而受到影响。另外scan chain的插入要尽量和RTL层次结构匹配。如果你把不同模块的逻辑混在一条链上物理上可能要跨越很长的走线ATPG依然能工作但后端的时序收敛会出问题最终可能导致不得不删掉部分chain段来修timingcoverage就掉了。3.2 时钟和复位架构必须先理顺coverage上不去很大一部分原因在时钟和复位约束上。ATPG跑起来工具需要知道每个时序单元在capture phase用什么时钟在shift phase用什么时钟时钟之间是否互斥。如果时钟关系没有在SDF文件中完整描述或者DFT约束没有明确写CTIClock Tree Isolation工具会产生大量的time-set冲突。比如一个设计里有多组时钟域ATPG默认会把不相关的时钟当作互相排斥exclusive来处理。如果你没有设置正确的clock grouping工具就无法在同一个pattern里把两个时钟域的数据同时捕获跨时钟域路径上的transition fault就会被标记为untestable。这类问题的典型特征是覆盖率报告里有很多“unable to justify”或“constraint”故障而你进到原理图里一看路径本身并不复杂。对异步复位的处理也类似。如果异步复位网络没有在DFT约束里做safe state设定ATPG会为了满足复位值的初始化而浪费大量pattern导致整体效率下降。我建议在DFT插入阶段就把所有异步复位强制为“scan mode下可控制”在功能模式下保持真实复位行为。这个方案稍微有点麻烦但对coverage的帮助非常明显。3.3 Memory和黑盒逻辑不要硬扫内嵌大量SRAM的设计如果不用MBIST而是硬靠ATPG去扫描每一颗存储单元coverage不仅低测试时间还很长。原因很简单SRAM的内部位线、字线、灵敏放大器不属于标准逻辑ATPG的stuck-at模型根本描述不了它们的真实缺陷。所以业内通行做法是memory用MBIST或者BIST controller覆盖ATPG只覆盖memory周边的glue logic。做这一步的收益通常能让整颗芯片的coverage从80%拉到95%。但要注意MBIST和ATPG之间要做隔离否则MBIST logic会引入大量不可控的DFT逻辑反过来拖累ATPG。我见过一个项目MBIST controller放在了scan chain内部没有做隔离结果ATPG跑出来一堆“shadow logic”故障覆盖率直接掉了4个点这种问题排查起来特别费时间。4. ATPG生成层面的调优把工具的极限逼出来4.1 故障模型不要只跑stuck-at提coverage不能只盯stuck-atSA一种故障模型。现代DFT sign-off通常要求三套覆盖率SA coverage、Transition Delay FaultTDFcoverage和Path Delay FaultPDFcoverage。TDF对高速时序缺陷更敏感但它的覆盖率通常比SA低5到10个百分点原因在于TDF需要对每个节点产生“上跳/下跳”两个事件对时序约束和低频路径特别敏感。如果你发现TDF coverage一直上不去先检查SDF时序信息是否完整。很多TDF故障被判定为untestable是因为工具的时序引擎发现目标路径上的时间太紧无法满足setup/hold条件。另一个典型原因是时钟混合策略问题。TDF测试需要在capture pulse上做精确控制多时钟域之间的交互处理不当会让工具选择保守策略把大量跨时钟域路径排除在外。4.2 动态压缩与pattern限制的平衡ATPG生成过程中工具会做动态压缩dynamic compaction想办法让一条pattern覆盖更多的故障。压缩率越高pattern越少测试时间越短但同时可能牺牲一些可测故障的覆盖。这里的核心矛盾是你既要coverage高又不想测试成本爆炸但测试成本在sign-off里是实打实的指标。我的建议是分两轮跑。第一轮用默认压缩快速看一下coverage在哪个水位第二轮针对覆盖率薄弱区域关掉或者降低压缩率生成专门的target pattern去补那些默认压缩丢失的故障。当然也可以打开工具提供的“fault group”或“fault list optimization”功能让工具优先处理那些对覆盖率影响最大的故障而不是无差别地压缩。4.3 ATPG选项和constraint的合理设置ATPG选项里面有几个对coverage影响很大的设置值得你逐个过一遍set_atpg -capture_phase相关设置决定TDF pattern的capture方式是launch from shift还是launch from capture不同方式对时序要求不同覆盖率结果也不同。set_atpg -abort_limitATPG对某个故障尝试的算法不收敛时会“abort”掉它。这个abort limit设得太小会过早放弃困难故障导致coverage低设得太大会让run time暴涨收益却不明显。通常从32开始试根据情况调整到64、128。set_atpg -max_backtrace后端回溯深度影响对困难故障的求解能力。set_dft -include_non_scan是否允许ATPG使用非扫描单元做约束。如果你不开启一些无扫面功能的锁存器会变成黑盒周边逻辑覆盖不上开启之后工具能更大范围地做状态推理但需要后端配合时序收敛。这些选项调整起来非常花时间一个合理的做法是建一个标准的option regression脚本在多个benchmark block上跑一遍对比而不是在某个模块上碰运气。4.4 多模式ATPGShift、Capture和Slow/Fast模式很多团队忽略了ATPG的模式组合。比如有的故障在slow shift阶段可测有的故障必须在fast capture阶段才能暴露而有的故障需要把芯片置于特定power模式或test模式才能被激活。合理设置多模式组合能把某些“方案性不可测”的故障变成可测。典型的例子是低功耗设计里的power gating。如果你在ATPG阶段只跑正常power模式那些处于常开域和可控关断域边界上的逻辑会有大量故障因为isolation cell处于disable状态而不可测。这时候搭配一个isolation测试模式或power-aware ATPG模式覆盖率能提升1%左右。这种收益在逻辑规模越大的设计上越明显。5. 测试点插入对待疑难故障的最终手段5.1 什么时候才应该上test pointTest point测试点是在设计里额外插入的DFT逻辑目的是提高某些特定节点的可控性或可观测性。它不是默认选项因为会带来面积、功耗和时序的开销。但当你发现coverage距离目标只差1到2个百分点而且瓶颈集中在少数几个fanout极高或深度很深的逻辑锥时test point就是性价比最高的手段。判断标准我一般看三个参数不可测故障数量、故障背后的根节点数量以及这些根节点是否集中在某些宏单元/硬核周围。如果不可测故障有几百个但分散在几千个节点上test point的效果就不明显如果几百个故障都汇聚在同一个控制信号上插一个观测点可能就解决一大半。5.2 Test Point的分类与选择策略Test point大体分三类可控性测试点Control Point把某个内部节点强制设置为0或1绕开上游复杂的逻辑锥。适合那些因为上游约束导致无法置位的节点。可观测性测试点Observe Point把某个内部节点的值连接到scan chain的观测端让ATPG可以直接观察它的故障。适合那些下游拥塞、故障无法传播到主输出的节点。混合测试点同时提供控制和观察能力面积开销更大但在某些场景效果最好。选择时考虑优先级先解决可控性还是可观测性取决于报告里fault的根因分类。如果故障大量报“unable to justify”说明可控性不足优先加control point如果报“fault not observed”说明传播路径断裂优先加observe point。另外test point不要太靠近时钟或异步控制端口否则容易在测试模式下引入毛刺风险ATPG跑出来的pattern在silicon上误触发。5.3 Test Point插入后的时序和面积影响Test point不是白给的。一个简单的control point由几个逻辑门组成但放在关键路径上可能让时序slack变差几十ps。面积方面比如一颗500万门的SoC通常加1000到2000个test point还不至于让后端太难过但如果为了冲99.9%的覆盖率而加太多封装面积和布线资源压力就会显现。在实际项目中我会按照覆盖率目标倒推允许的最大test point数量。比如当前覆盖率是97.5%目标是99%那说明有大约1.5个百分点的缺口。在一个200万故障的设计里这对应约3万个故障。根据经验一个控制点大概能救下几十到几百个故障一个观测点通常能救下几百个。按这个粗略估算大约需要200到300个测试点才可能补上缺口。这个量级通常不会对布局布线造成致命影响比较可控。5.4 工具如何自动推荐test point我常用的EDA工具例如Mentor Tessent、Synopsys DFTMAX都有自动test point插入功能。Tessent里叫“Test Point InsertionTPI”DFTMAX里也有类似流程比如“Test Point Auto-Insertion”。使用前先跑一遍完整ATPG生成coverage和fault report工具会基于uncoverage fault自动分析候选点并按预计覆盖率收益排序。你可以设定一个目标coverage工具会选出最少的test point组合。但我不建议全盘接受工具的推荐。工具选点往往偏乐观没有充分考虑物理布局。比较稳妥的做法是让工具推荐一批候选点你再按模块、时序裕量过滤一遍删掉那些位于关键路径上的点。这样既能保证覆盖率收益又不会给后端带来太多麻烦。6. 实战案例一个82%卡壳设计怎么折腾到99.1%6.1 项目背景和初始状态这个项目是一个中高复杂度的SoC包含MCU子系统、DSP子系统和大量的SRAM规模在千万门级别。最初的ATPG结果只有82%的stuck-at coverage离项目目标99%差得很远而且TDF coverage连75%都不到。由于项目已经到中后期RTL改动空间非常有限所以我只能在DFT架构和ATPG层面做文章。初始诊断阶段我把fault report按模块归类发现覆盖率最差的是DSP子系统中的两个部分一个是异步FIFO接口另一个是时钟门控阵列之后的组合逻辑。这两个区域贡献了将近一半的未覆盖故障。6.2 第一轮优化约束和时钟关系的修正第一轮我不急着加test point而是先清理约束。通过检查工具报出的类别我发现异步FIFO接口附近出现了大量“unstable”故障。原因在于FIFO两端时钟域不同步默认ATPG把两个时钟当成完全互斥导致很多跨域信号无法在同一个pattern内被驱动和捕获。解决办法是在DFT约束里定义一组虚拟异步时钟关系让工具在生成pattern时允许跨时钟域信号在满足一定条件的情况下被观察和比较。同时我把异步FIFO的内部存储单元设成“memory element”让ATPG不再试图把FIFO内部的每一位当作普通触发器来处理而是看作一个存储器。只这一步stuck-at coverage提升到了89%。6.3 第二轮优化时钟门控和ICG的透明化处理剩下的未覆盖故障相当一部分集中在时钟门控单元ICG附近。ATPG默认处理ICG时会把它当成一个普通门电路而ICG内部其实有latche和与门结构时序行为有时会给ATPG的自动推理带来困扰。处理方法是在DFT约束里把ICG设置为透明transparent让工具在shift和capture阶段都认为ICG是直接导通状态。配合在scan chain端加上必要的lockup latch避免shift期间ICG的时钟沿出现毛刺。这轮优化后stuck-at coverage从89%上升到96%TDF coverage也从75%提高到85%。6.4 第三轮优化Memory BIST隔离和测试点96%之后再往上走就是硬仗了。我把剩余未覆盖的故障拉出来逐个分析发现其中约60%是MBIST controller自身的逻辑。这部分逻辑在function mode下由BIST状态机控制ATPG的默认约束不知道BIST状态的合法取值导致大量故障被标记为不可测。解决方式是给MBIST controller加一组测试模式的约束让ATPG知道在scan test mode下BIST状态机可以被preload成任意合法状态从而把controller内部的逻辑变为可测。这一下又拉高了约1.2个百分点达到97.2%。但距离99%还差一点。此时我开始启用test point插入。工具自动推荐了400多个候选点我做了整理后保留了280个剔除了位于关键时序路径上的点。插入后重跑了综合、DFT和ATPGcoverage提升到了98.9%。最后再补了一轮transition pattern的专门优化以及让ATPG针对那些被abort的故障单独加大回溯深度最终stuck-at coverage稳定在99.1%TDF coverage在93%左右达到了项目的sign-off标准。7. 常见问题与排查技巧实录7.1 高频问题速查表现象可能的根因排查方法coverage卡在90%以下上不去大量黑盒/存储器直接挂在扫描链上检查black box设置确认memory是否有BIST报告里大面积unstable故障跨时钟域路径没有定义异步关系检查clock group设置补充异步约束transition coverage异常偏低SDF不完整或CAPTURE策略错误确认timing lib和SDF加载是否完整检查capture clock设置shift期间出现大量violationscan chain上lockup不足、时钟沿竞争检查ICG透明化处理和lockup插入情况coverage前一轮98%后一轮变97%综合或后端网表更新后约束未同步检查DFT constraint文件和timing lib的版本一致性abort故障数量特别多backtrace深度或abort limit设置过低适当调大abort limit结合regression对比效果7.2 工具报告里的“水分”识别ATPG报告里的coverage数字有时会掩盖真实问题。比如有些工具默认会把某些黑盒边界的故障从分母中剔除导致覆盖率“数学上”很高但实际测试能力不足。所以不能只看百分比还要同时看pattern数量、fault count、test coverage与fault coverage的差值。如果两者差距超过2个百分点说明有大量故障被认为是“不可测”的这些不可测故障才是你下一步要重点分析的。还有一种情况是工具为了满足某些过于严格的约束自动把大量故障标为“redundant”。这种标注背后可能是test mode下某个信号被强制为0导致一长串逻辑不可测。遇到这类问题就需要排查约束本身是否合理而不是接受工具的判断。比如某条power-down信号在测试模式下的取值未必非要和功能模式一致放宽之后覆盖率可能立刻上升。7.3 那些年我踩过的坑第一个坑为了追求覆盖率把ATPG的abort limit调得非常大结果跑了三天三夜没跑完而且覆盖率并没有提升多少。后来才意识到abort limit只是工具内部求解器的尝试上限真正让覆盖率上不去的是逻辑本身不可测而不是工具不够努力。所以现在我的做法是先用默认参数快速跑一遍再用工具诊断不可测故障的分布而不是盲目加运算时间。第二个坑在一颗有低功耗单元的设计上做ATPG忘了设置isolation cell的测试模式。结果覆盖率始终在85%徘徊报告里大量节点显示“not observable”。后来才发现那些隔离单元在测试模式下默认是关闭的隔断了信号通路。加上对应的约束之后覆盖率马上回升。这个坑尤其在带power domain的设计里容易遇到提醒项目里只要有level shifter、isolation cell和power switchDFT约束里一定要先定义它们的测试行为。第三个坑在跑TDF coverage时为了修timing把某些路径设成了false path结果ATPG自动把这些路径上的所有transition故障都当作不测。后来我用路径延迟分析工具看清楚这些“false path”在测试模式下其实是可以满足时序的于是把false path约束改为仅在功能模式有效。TDF coverage一下子提升了4个百分点。7.4 一个不太常见但很有用的技巧按fault类型拆分回归很多团队的回归只看一个总覆盖率问题数出来了再一股脑去debug。我后来养成一个习惯按故障类型、模块、时域把coverage拆开看比如单独看DSP子系统的stuck-at coverage和MCU子系统的TDF coverage。拆分之后很多瓶颈会浮出水面——有些模块卡在可控性不足有些模块卡在可观测性不足解决策略完全不同。另外每次改完约束或网表我都建议重新生成一次coverage report做对比。你可以用脚本自动解析报告里的Test Coverage和Uncollapsed Fault Count并生成环比趋势。这样能及时发现回归不用等下一步接手的同事来抱怨。根据我个人的实操经验DFT ATPG coverage的提升从来不是某一个技巧的胜利而是一个系统性的排查、优化循环。每一次把覆盖率往上拉一个点背后都是对设计约束、时钟架构、ATPG算法和物理实现的一次更深入理解。希望这篇内容能让你少走一些弯路至少在你下一次卡在99%门槛前能有一套可以按顺序操作的方法在手边。