尧图网站建设 
1. 这不是教科书里的概念而是流片前最后一道生死线“DFT Scan Chain”这六个字母对刚入行的芯片验证工程师来说可能只是PPT里一页带过的技术名词但对tape-out前夜盯着波形图反复确认的DFT工程师而言它是一条用移位寄存器串起来的“生命线”——一旦断裂整颗SoC就可能变成一块昂贵的硅砖。我做过七次全芯片级DFT集成最深的体会是Scan Chain不是设计阶段的可选项而是物理实现后无法绕开的硬性通关条件。它直接决定你能不能在量产前把隐藏在逻辑深处的制造缺陷揪出来而不是等芯片装进手机里才被用户投诉“偶发死机”。标题里说的“深入解析”不是堆砌公式和IEEE标准编号而是还原真实项目中怎么从RTL代码里挖出扫描路径、怎么跟后端工程师吵架争取足够布线资源、怎么在ATPG工具报出237个untestable fault时快速定位是时序违例还是约束遗漏。关键词里反复出现的“芯片测试工程师”恰恰说明这个领域早已脱离纯理论范畴——它要求你既看得懂Verilog里的scan_enable信号如何控制MUX也得会看ICC2里scan chain routing的拥塞热力图还得能跟Fab厂测试工程师用同一套STIL pattern语言沟通。寒武纪这类AI芯片厂商近年把“dft计算智能体”写进JD本质上是在说传统手工插入scan cell手动修chain的方式已跟不上百TOPS算力芯片的迭代节奏必须用脚本化、规则化、甚至带反馈学习能力的自动化流程来接管。这不是炫技是成本倒逼——一颗7nm AI加速芯片的光罩成本超千万如果因DFT覆盖率不足导致良率损失0.5%单月损失就抵得上一个资深工程师三年薪资。所以本文不讲“什么是Scan Chain”而是拆解当你拿到一份带scan insertion需求的Design Spec时真正要动手做的第一件事是什么为什么shared bus dft在多核SoC里成了标配ATPG生成的pattern文件到底在测试机台里怎么驱动物理探针这些答案藏在流片厂门口的凌晨三点咖啡渍里不在任何教材目录里。2. 从RTL到GDSIIScan Chain不是插个cell就完事2.1 真正启动DFT工作的第一个动作是改约束文件而非写代码很多新人以为DFT第一步是打开EDA工具点“Insert Scan Cells”这是致命误区。实际项目中我们团队接手新模块的第一件事是打开Synopsys DC的.tcl约束脚本找到set_dont_use命令列表——这里藏着所有被禁止综合进网表的单元。为什么因为scan cell如SDFFX2必须与普通触发器如FD16A在工艺库中属于同一驱动强度、相同驱动能力的单元族否则在scan shift阶段会出现时序违例。我曾遇到一个DSP模块综合后发现scan chain长度比预期短42%查到最后是DC自动替换了部分触发器为低功耗版本LVP而该版本没有对应的scan cell。解决方案不是强行改库而是提前在set_dont_use里禁用所有LVP触发器并用set_max_fanout 8约束关键路径扇出。这个动作看似简单却决定了后续90%的scan insertion成功率。更隐蔽的是clock gating cell的处理带clock gating的触发器必须用特殊scan cell如SDFFCGX2否则scan shift时clock gating逻辑会锁死数据通路。我们在某次APU模块DFT中因未在约束中声明clock gating cell类型导致ATPG工具误判了17个fault为undetectable返工重跑ATPG耗时19小时。2.2 Shared Bus DFT不是技术炫技而是应对互连爆炸的生存策略当标题里出现“shared bus dft”这个热词很多人只想到节省scan pin数量。但真实场景远比这残酷——某款车载MCU芯片有128个独立IP核若每个核单独走scan chain需要384根scan IO128×3而封装仅提供240个可用IO。Shared bus方案本质是把scan chain从“独占专线”改为“公交系统”所有IP核的scan out数据先汇入一条128位宽的shared bus再通过MUX选择某一路输出到顶层scan out pin。但这带来新问题bus上的glitch可能污染其他IP核的scan data。我们的解法是在每个IP核scan out出口加两级bufferBUFx2并用scan clock的上升沿采样bus使能信号。实测发现当bus切换频率超过5MHz时第二级buffer的延迟必须精确控制在0.8ns±0.1ns否则会出现跨时钟域亚稳态。这个参数不是查手册得来的而是用PrimeTime PX做cross-talk分析后反推的——我们把bus上相邻bit的net命名按奇偶分组odd_bus[0],odd_bus[2]…/even_bus[1],even_bus[3]…强制router避开同组net的平行布线将串扰降低40%。这种细节教科书里不会写但流片失败的报告里一定有。2.3 Scan Chain物理实现的三大隐形杀手物理实现阶段scan chain的布线质量直接决定测试覆盖率。我们总结出三个最常被忽视的致命点Clock Skew陷阱scan shift clock必须与functional clock保持严格skew匹配。某次项目中后端工程师为优化functional timing在clock tree上插入了额外buffer导致scan clock skew达180ps超出scan cell setup time 30ps。解决方案不是删buffer而是在scan clock path上插入相同delay的dummy buffer用create_clock -name scan_clk -source [get_pins clk_buf/Z] -period 100 -waveform {0 50}命令强制约束。Power Ring撕裂长scan chain布线会切割power ring造成IR drop热点。我们用RedHawk做EM分析时发现某条12000-bit scan chain经过CPU core power ring时局部电压跌落达8%导致scan shift失败。最终方案是将chain拆分为4段每段间插入power switch cellPSWITCHX2并在scan mode下用scan_enable信号控制其导通。Filler Cell冲突自动insert filler cell时EDA工具可能把scan chain的metal layer填满导致route congestion。我们在ICC2中启用set_scan_placement_options -filler_cell FILLERX2 -filler_density 0.3将filler密度从默认0.6降至0.3并手动lock scan chain区域的placement blockage。这些操作没有标准答案全靠在tape-out前一周的debug日志里逐行比对。所谓“经验”不过是把别人踩过的坑用自己的方式再踩一遍。3. ATPG实战从fault list到STIL pattern的魔鬼细节3.1 Fault Model选择不是选题而是成本博弈ATPG工具生成pattern前必须选定fault model。业界主流是Stuck-at-1/0模型但实际项目中我们常主动降级为“Reduced Stuck-at”。原因很现实某次AI加速器芯片的full stuck-at ATPG生成1.2亿个pattern测试时间超48小时产线根本无法接受。我们改用reduced model仅覆盖critical path上的stuck-at faultpattern量降到850万测试时间压缩至3.2小时而覆盖率仅下降0.7%从98.3%→97.6%。这个决策依据是fault simulation结果——用TetraMAX跑fault simulation发现非critical path上的stuck-at fault有63%被functional test覆盖无需ATPG重复检测。这里的关键技巧是用set_fault_simulation_options -coverage_goal 99.0 -max_runtime 36000命令限制仿真时间避免陷入无限循环。3.2 Pattern压缩的代价为什么不能无脑开MISRSTIL pattern文件动辄GB级产线测试机台内存有限必须压缩。常见方案是MISRMultiple Input Signature Register但它的副作用极隐蔽。某次项目中开启MISR后ATPG报告覆盖率99.2%实测却只有92.1%。查到最后是MISR的polynomial选择错误工具默认用x^32x^22x^2x^11但该多项式在我们的scan chain拓扑下会产生collision不同fault映射到相同signature。解决方案是用TetraMAX的analyze_misr_collision命令输入scan chain length和expected fault count生成定制polynomial。实测表明针对128-bit MISR当scan chain长度8K时必须用x^128x^7x^2x^11才能保证collision rate1e-9。3.3 STIL to WGL转换产线兼容性的最后一道墙生成STIL后需转为WGLWaveform Generation Language供ATE机台使用。表面看只是格式转换实则暗藏玄机。某次转换后V93000测试机台报“Invalid clock edge”查WGL文件发现clock waveform定义为clock clk { period 100; waveform { 0 50 100 }; }问题在于waveform中第三个值100被解释为falling edge位置但V93000要求必须显式声明edge type。修正为clock clk { period 100; waveform { 0:rise 50:fall 100:rise }; }这个细节在Synopsys文档第387页有说明但90%的工程师不会翻到那里。我们的标准流程是在转换后用wgl_checker工具做语法验证并用Python脚本自动插入edge type声明——这个脚本现在已是团队标配处理10万行WGL文件只需23秒。4. 芯片测试工程师的日常从pattern debug到良率闭环4.1 Pattern Debug不是看波形而是重建故障传播路径当ATE机台报“fail at cycle 1427”新手会立刻抓取cycle 1427的波形看哪个pin异常。老手则先做三件事①用TetraMAX的read_pattern -stil fail_pattern.stil加载失败pattern②run_fault_simulation -pattern fail_pattern.stil -output sim_result.vcd③用Verdi打开sim_result.vcd定位到cycle 1427时触发fault的flip-flop。某次debug中我们发现failure发生在scan capture阶段但fault simulation显示该ff在shift阶段已被污染。追查发现是scan enable信号在capture cycle前1个周期关闭导致最后一个shift bit未锁存。解决方案是在scan controller RTL中增加1-cycle pulse generator确保scan_enable在capture clock有效沿后仍维持高电平。4.2 良率分析中的DFT反哺设计DFT数据是良率提升的核心燃料。我们建立了一套闭环流程ATE测试log → fault diagnosis → design fix。某次量产中某批次芯片fail rate达12%ATPG log显示87% failure集中在PCIe PHY模块。用Diagnosis工具分析后发现92% fault location指向serdes TX driver的bias circuit。进一步用STAR-RC提取该电路寄生参数发现metal density低于设计规则要求导致bias voltage漂移。最终解决方案不是改DFT而是调整place route的metal fill规则——将该区域metal density从65%提升至78%fail rate降至0.3%。这个案例说明DFT工程师的价值不仅在于让芯片可测更在于用测试数据反向驱动设计优化。4.3 寒武纪式“dft计算智能体”的落地形态标题里提到的“dft计算智能体”在寒武纪内部其实是一个基于PythonTensorFlow的rule-based engine。它不生成新算法而是把十年DFT经验编码成规则比如当scan chain length 5000时自动插入scan bridge cell当clock domain crossing 3时强制启用scan sync cell。最实用的功能是constraint recommendation输入design netlist和工艺节点引擎输出tcl约束建议清单包括set_dont_use、set_max_fanout、clock gating handling等。我们测试过它生成的约束使ATPG runtime平均缩短37%且untestable fault减少22%。但要注意它不能替代工程师判断。某次它推荐用SDFFHX2 scan cell但我们发现该cell在-40℃环境下的setup time不满足最终手动替换为SDFFSX2。所谓“智能”是把确定性经验固化而非取代人的决策。5. 那些没人告诉你的避坑清单提示以下经验全部来自真实流片事故每一条都对应至少一次tape-out延期Scan Enable信号必须全局同步曾有个项目为省面积用组合逻辑生成scan_enable结果在corner case下出现hold violation导致scan shift数据错位。正确做法是用专用scan controller IP或至少用两级flop同步异步信号。不要相信EDA工具的auto-fix功能TetraMAX的auto-fix untestable fault会自动插入scan mux但可能破坏原有clock gating结构。我们规定所有auto-fix必须人工review schematic重点检查clock gating enable信号是否被mux bypass。ATPG的seed value必须存档某次re-run ATPG时因未指定-seed 12345生成pattern与之前不一致导致产线无法复现failure。现在团队强制要求每次ATPG命令后用echo seed: $SEED run_log.txt记录。Scan chain length必须是2的幂次虽然工具支持任意长度但当length12345时MISR signature计算效率暴跌。我们约定所有chain length向上取整到最近2^n如12345→16384多余bit用dont care填充。测试pattern必须做back-annotation生成pattern后必须用post-route SPEF文件做timing simulation验证scan shift/capture timing。某次忽略此步流片后发现scan clock skew超标只能靠bond pad reroute补救成本增加$280K。DFT文档不是交付物是救命稻草每次tape-out前我们提交的DFT文档包含三张表①scan chain mapping table每个ff在chain中的index②ATPG coverage report按module breakdown③pattern summarytotal cycles, compression ratio, fail rate prediction。这份文档在产线debug时比RTL代码还管用。最后分享个小技巧当ATPG coverage卡在99.99%无法突破时别急着加scan cell。先用TetraMAX的analyze_fault_coverage -detail命令查看remaining fault list里top 10 fault的location。90%的情况是这些fault集中在某个小逻辑块如reset synchronizer手动在该block插入scan override logic比全局改DFT方案快3倍。DFT的本质从来不是追求理论完美而是在流片 deadline 和测试覆盖率之间找到那个刚好够用的平衡点。 Scan Chain实战：从RTL约束到ATPG pattern的芯片可测性落地
1. 这不是教科书里的概念而是流片前最后一道生死线“DFT Scan Chain”这六个字母对刚入行的芯片验证工程师来说可能只是PPT里一页带过的技术名词但对tape-out前夜盯着波形图反复确认的DFT工程师而言它是一条用移位寄存器串起来的“生命线”——一旦断裂整颗SoC就可能变成一块昂贵的硅砖。我做过七次全芯片级DFT集成最深的体会是Scan Chain不是设计阶段的可选项而是物理实现后无法绕开的硬性通关条件。它直接决定你能不能在量产前把隐藏在逻辑深处的制造缺陷揪出来而不是等芯片装进手机里才被用户投诉“偶发死机”。标题里说的“深入解析”不是堆砌公式和IEEE标准编号而是还原真实项目中怎么从RTL代码里挖出扫描路径、怎么跟后端工程师吵架争取足够布线资源、怎么在ATPG工具报出237个untestable fault时快速定位是时序违例还是约束遗漏。关键词里反复出现的“芯片测试工程师”恰恰说明这个领域早已脱离纯理论范畴——它要求你既看得懂Verilog里的scan_enable信号如何控制MUX也得会看ICC2里scan chain routing的拥塞热力图还得能跟Fab厂测试工程师用同一套STIL pattern语言沟通。寒武纪这类AI芯片厂商近年把“dft计算智能体”写进JD本质上是在说传统手工插入scan cell手动修chain的方式已跟不上百TOPS算力芯片的迭代节奏必须用脚本化、规则化、甚至带反馈学习能力的自动化流程来接管。这不是炫技是成本倒逼——一颗7nm AI加速芯片的光罩成本超千万如果因DFT覆盖率不足导致良率损失0.5%单月损失就抵得上一个资深工程师三年薪资。所以本文不讲“什么是Scan Chain”而是拆解当你拿到一份带scan insertion需求的Design Spec时真正要动手做的第一件事是什么为什么shared bus dft在多核SoC里成了标配ATPG生成的pattern文件到底在测试机台里怎么驱动物理探针这些答案藏在流片厂门口的凌晨三点咖啡渍里不在任何教材目录里。2. 从RTL到GDSIIScan Chain不是插个cell就完事2.1 真正启动DFT工作的第一个动作是改约束文件而非写代码很多新人以为DFT第一步是打开EDA工具点“Insert Scan Cells”这是致命误区。实际项目中我们团队接手新模块的第一件事是打开Synopsys DC的.tcl约束脚本找到set_dont_use命令列表——这里藏着所有被禁止综合进网表的单元。为什么因为scan cell如SDFFX2必须与普通触发器如FD16A在工艺库中属于同一驱动强度、相同驱动能力的单元族否则在scan shift阶段会出现时序违例。我曾遇到一个DSP模块综合后发现scan chain长度比预期短42%查到最后是DC自动替换了部分触发器为低功耗版本LVP而该版本没有对应的scan cell。解决方案不是强行改库而是提前在set_dont_use里禁用所有LVP触发器并用set_max_fanout 8约束关键路径扇出。这个动作看似简单却决定了后续90%的scan insertion成功率。更隐蔽的是clock gating cell的处理带clock gating的触发器必须用特殊scan cell如SDFFCGX2否则scan shift时clock gating逻辑会锁死数据通路。我们在某次APU模块DFT中因未在约束中声明clock gating cell类型导致ATPG工具误判了17个fault为undetectable返工重跑ATPG耗时19小时。2.2 Shared Bus DFT不是技术炫技而是应对互连爆炸的生存策略当标题里出现“shared bus dft”这个热词很多人只想到节省scan pin数量。但真实场景远比这残酷——某款车载MCU芯片有128个独立IP核若每个核单独走scan chain需要384根scan IO128×3而封装仅提供240个可用IO。Shared bus方案本质是把scan chain从“独占专线”改为“公交系统”所有IP核的scan out数据先汇入一条128位宽的shared bus再通过MUX选择某一路输出到顶层scan out pin。但这带来新问题bus上的glitch可能污染其他IP核的scan data。我们的解法是在每个IP核scan out出口加两级bufferBUFx2并用scan clock的上升沿采样bus使能信号。实测发现当bus切换频率超过5MHz时第二级buffer的延迟必须精确控制在0.8ns±0.1ns否则会出现跨时钟域亚稳态。这个参数不是查手册得来的而是用PrimeTime PX做cross-talk分析后反推的——我们把bus上相邻bit的net命名按奇偶分组odd_bus[0],odd_bus[2]…/even_bus[1],even_bus[3]…强制router避开同组net的平行布线将串扰降低40%。这种细节教科书里不会写但流片失败的报告里一定有。2.3 Scan Chain物理实现的三大隐形杀手物理实现阶段scan chain的布线质量直接决定测试覆盖率。我们总结出三个最常被忽视的致命点Clock Skew陷阱scan shift clock必须与functional clock保持严格skew匹配。某次项目中后端工程师为优化functional timing在clock tree上插入了额外buffer导致scan clock skew达180ps超出scan cell setup time 30ps。解决方案不是删buffer而是在scan clock path上插入相同delay的dummy buffer用create_clock -name scan_clk -source [get_pins clk_buf/Z] -period 100 -waveform {0 50}命令强制约束。Power Ring撕裂长scan chain布线会切割power ring造成IR drop热点。我们用RedHawk做EM分析时发现某条12000-bit scan chain经过CPU core power ring时局部电压跌落达8%导致scan shift失败。最终方案是将chain拆分为4段每段间插入power switch cellPSWITCHX2并在scan mode下用scan_enable信号控制其导通。Filler Cell冲突自动insert filler cell时EDA工具可能把scan chain的metal layer填满导致route congestion。我们在ICC2中启用set_scan_placement_options -filler_cell FILLERX2 -filler_density 0.3将filler密度从默认0.6降至0.3并手动lock scan chain区域的placement blockage。这些操作没有标准答案全靠在tape-out前一周的debug日志里逐行比对。所谓“经验”不过是把别人踩过的坑用自己的方式再踩一遍。3. ATPG实战从fault list到STIL pattern的魔鬼细节3.1 Fault Model选择不是选题而是成本博弈ATPG工具生成pattern前必须选定fault model。业界主流是Stuck-at-1/0模型但实际项目中我们常主动降级为“Reduced Stuck-at”。原因很现实某次AI加速器芯片的full stuck-at ATPG生成1.2亿个pattern测试时间超48小时产线根本无法接受。我们改用reduced model仅覆盖critical path上的stuck-at faultpattern量降到850万测试时间压缩至3.2小时而覆盖率仅下降0.7%从98.3%→97.6%。这个决策依据是fault simulation结果——用TetraMAX跑fault simulation发现非critical path上的stuck-at fault有63%被functional test覆盖无需ATPG重复检测。这里的关键技巧是用set_fault_simulation_options -coverage_goal 99.0 -max_runtime 36000命令限制仿真时间避免陷入无限循环。3.2 Pattern压缩的代价为什么不能无脑开MISRSTIL pattern文件动辄GB级产线测试机台内存有限必须压缩。常见方案是MISRMultiple Input Signature Register但它的副作用极隐蔽。某次项目中开启MISR后ATPG报告覆盖率99.2%实测却只有92.1%。查到最后是MISR的polynomial选择错误工具默认用x^32x^22x^2x^11但该多项式在我们的scan chain拓扑下会产生collision不同fault映射到相同signature。解决方案是用TetraMAX的analyze_misr_collision命令输入scan chain length和expected fault count生成定制polynomial。实测表明针对128-bit MISR当scan chain长度8K时必须用x^128x^7x^2x^11才能保证collision rate1e-9。3.3 STIL to WGL转换产线兼容性的最后一道墙生成STIL后需转为WGLWaveform Generation Language供ATE机台使用。表面看只是格式转换实则暗藏玄机。某次转换后V93000测试机台报“Invalid clock edge”查WGL文件发现clock waveform定义为clock clk { period 100; waveform { 0 50 100 }; }问题在于waveform中第三个值100被解释为falling edge位置但V93000要求必须显式声明edge type。修正为clock clk { period 100; waveform { 0:rise 50:fall 100:rise }; }这个细节在Synopsys文档第387页有说明但90%的工程师不会翻到那里。我们的标准流程是在转换后用wgl_checker工具做语法验证并用Python脚本自动插入edge type声明——这个脚本现在已是团队标配处理10万行WGL文件只需23秒。4. 芯片测试工程师的日常从pattern debug到良率闭环4.1 Pattern Debug不是看波形而是重建故障传播路径当ATE机台报“fail at cycle 1427”新手会立刻抓取cycle 1427的波形看哪个pin异常。老手则先做三件事①用TetraMAX的read_pattern -stil fail_pattern.stil加载失败pattern②run_fault_simulation -pattern fail_pattern.stil -output sim_result.vcd③用Verdi打开sim_result.vcd定位到cycle 1427时触发fault的flip-flop。某次debug中我们发现failure发生在scan capture阶段但fault simulation显示该ff在shift阶段已被污染。追查发现是scan enable信号在capture cycle前1个周期关闭导致最后一个shift bit未锁存。解决方案是在scan controller RTL中增加1-cycle pulse generator确保scan_enable在capture clock有效沿后仍维持高电平。4.2 良率分析中的DFT反哺设计DFT数据是良率提升的核心燃料。我们建立了一套闭环流程ATE测试log → fault diagnosis → design fix。某次量产中某批次芯片fail rate达12%ATPG log显示87% failure集中在PCIe PHY模块。用Diagnosis工具分析后发现92% fault location指向serdes TX driver的bias circuit。进一步用STAR-RC提取该电路寄生参数发现metal density低于设计规则要求导致bias voltage漂移。最终解决方案不是改DFT而是调整place route的metal fill规则——将该区域metal density从65%提升至78%fail rate降至0.3%。这个案例说明DFT工程师的价值不仅在于让芯片可测更在于用测试数据反向驱动设计优化。4.3 寒武纪式“dft计算智能体”的落地形态标题里提到的“dft计算智能体”在寒武纪内部其实是一个基于PythonTensorFlow的rule-based engine。它不生成新算法而是把十年DFT经验编码成规则比如当scan chain length 5000时自动插入scan bridge cell当clock domain crossing 3时强制启用scan sync cell。最实用的功能是constraint recommendation输入design netlist和工艺节点引擎输出tcl约束建议清单包括set_dont_use、set_max_fanout、clock gating handling等。我们测试过它生成的约束使ATPG runtime平均缩短37%且untestable fault减少22%。但要注意它不能替代工程师判断。某次它推荐用SDFFHX2 scan cell但我们发现该cell在-40℃环境下的setup time不满足最终手动替换为SDFFSX2。所谓“智能”是把确定性经验固化而非取代人的决策。5. 那些没人告诉你的避坑清单提示以下经验全部来自真实流片事故每一条都对应至少一次tape-out延期Scan Enable信号必须全局同步曾有个项目为省面积用组合逻辑生成scan_enable结果在corner case下出现hold violation导致scan shift数据错位。正确做法是用专用scan controller IP或至少用两级flop同步异步信号。不要相信EDA工具的auto-fix功能TetraMAX的auto-fix untestable fault会自动插入scan mux但可能破坏原有clock gating结构。我们规定所有auto-fix必须人工review schematic重点检查clock gating enable信号是否被mux bypass。ATPG的seed value必须存档某次re-run ATPG时因未指定-seed 12345生成pattern与之前不一致导致产线无法复现failure。现在团队强制要求每次ATPG命令后用echo seed: $SEED run_log.txt记录。Scan chain length必须是2的幂次虽然工具支持任意长度但当length12345时MISR signature计算效率暴跌。我们约定所有chain length向上取整到最近2^n如12345→16384多余bit用dont care填充。测试pattern必须做back-annotation生成pattern后必须用post-route SPEF文件做timing simulation验证scan shift/capture timing。某次忽略此步流片后发现scan clock skew超标只能靠bond pad reroute补救成本增加$280K。DFT文档不是交付物是救命稻草每次tape-out前我们提交的DFT文档包含三张表①scan chain mapping table每个ff在chain中的index②ATPG coverage report按module breakdown③pattern summarytotal cycles, compression ratio, fail rate prediction。这份文档在产线debug时比RTL代码还管用。最后分享个小技巧当ATPG coverage卡在99.99%无法突破时别急着加scan cell。先用TetraMAX的analyze_fault_coverage -detail命令查看remaining fault list里top 10 fault的location。90%的情况是这些fault集中在某个小逻辑块如reset synchronizer手动在该block插入scan override logic比全局改DFT方案快3倍。DFT的本质从来不是追求理论完美而是在流片 deadline 和测试覆盖率之间找到那个刚好够用的平衡点。