Tessent ATPG深度调试：从AU/UC/UO分类到覆盖率提升实战

1. Tessent ATPG调试的核心挑战第一次接触Tessent ATPG报告时看到满屏的AU/UC/UO分类故障代码我的反应和大多数新手工程师一样——头皮发麻。这些看似简单的三字母组合背后隐藏着芯片测试覆盖率难以提升的真正瓶颈。在实际项目中我们常遇到这样的情况一个复杂SoC模块的ATPG覆盖率卡在85%死活上不去而项目要求是95%以上。这时候就需要像老中医把脉一样通过AUATPG Untestable、UCUncontrolled、UOUnobserved这三类故障的分类诊断找到测试覆盖率的病灶所在。理解这三类故障的本质差异非常关键。AU就像被上了锁的门ATPG工具根本没法生成测试patternUC类似于失控的方向盘工具无法将故障点驱动到所需逻辑值UO则像是被遮挡的摄像头虽然故障被激活但无法传播到观测点。去年我在处理一个7nm GPU芯片项目时就遇到过由于时钟门控设计不当导致大批量故障被归类为UC的典型案例。通过tessent_visualizer可视化工具我们最终发现是scan_enable信号与时钟门控TE端存在冲突。2. 覆盖率诊断的黄金组合命令2.1 统计报告三板斧我习惯把report_statistics命令作为调试的起点。这个命令输出的不只是冷冰冰的百分比数字更重要的是各类故障的分布比例。举个例子report_statistics -fault_class_summary可能会显示AU: 8.2% | UC: 4.5% | UO: 2.3% | Detected: 85%当AU占比异常高时往往意味着设计存在过度约束而UC突增则可能暗示时钟控制问题。上周帮客户调试的一个案例中我们发现UC比例突然从3%飙升到12%最终定位到是新增的power gating模块没有正确设置测试模式约束。analyze_fault命令是我的手术刀可以精准解剖单个故障点。比如分析一个锁存器的控制问题analyze_fault /top/alu/reg128/Q -stuck_at 0 -display这个命令会展示从PI到该寄存器的所有控制路径用红色标注断点位置。有次在28nm物联网芯片项目里就是通过这个命令发现时钟树上的一个与门在测试模式下被错误地约束为常闭状态。2.2 可视化分析技巧Tessent Visualizer的图层过滤功能是我的秘密武器。通过设置Show Only UC Faults过滤器可以快速定位故障聚集区域。最近在分析一个AI加速器芯片时我们就用这个方法发现了一个未建模的存储器黑盒周围环绕着大量AU故障像孤岛一样明显。对于复杂的时钟网络我必用report_clock和analyze_control_signals组合拳report_clock -all analyze_control_signals -type clock_gating这两个命令曾经帮我揪出一个隐蔽的问题——某个时钟门控单元的TE端居然接到了功能模式的使能信号上导致测试模式下时钟信号完全失效。3. AU故障的深度破解之道3.1 约束分析与解绑AU故障最常见的元凶就是过度约束。我有个血的教训曾经有次为了快速收敛时序在SDC里大量使用了set_case_analysis约束结果ATPG覆盖率直接掉了15个百分点。现在我会先用report_input_constraints检查所有活动约束report_input_constraints -active -verbose特别注意那些将信号固定为常数的C类型约束。有个取巧的办法是把非关键的C约束改为CT类型使用replace_constraints命令这样既保持约束效果又不影响覆盖率统计。上个月在汽车MCU项目里通过这个方法我们就挽回了3%的覆盖率。对于黑盒导致的AU故障我的应对策略是add_primary_inputs [get_pins blackbox/A] add_primary_outputs [get_pins blackbox/Z]这相当于给黑盒开了观察窗。记得有次处理一个加密模块通过这种方法成功将周边区域的AU故障转化为了可检测故障。3.2 时序深度与扫描链优化未被替换的普通触发器是AU故障的另一大来源。我常用的检查命令是report_dft -non_scan_flops曾经在某个通信芯片中发现了令人啼笑皆非的情况——设计团队为了省面积把配置寄存器的扫描链给优化掉了。通过set_dft_insertion命令重新插入扫描链后该模块的AU故障直接清零。对于时序深度不足导致的AU我的经验值是set_atpg -depth 32这个值需要根据设计规模谨慎调整。太浅会导致故障无法传播太深又会大幅增加pattern数量。在5nm工艺节点上我一般从24开始试探性调整。4. UC/UO故障的精准打击方案4.1 控制信号完整路径分析UC故障的核心是控制路径断裂。我常用的诊断流程是用report_faults筛选典型UC故障report_faults -class UC -limit 10选择代表性故障进行深度分析analyze_fault /top/dsp/multiplier/coeff_reg[3]/D -stuck_at 1在Visualizer中追踪信号驱动路径去年在某个网络处理器项目中通过这个方法发现时钟分频器的测试使能信号被错误地接到了电源域隔离信号上导致整个DSP模块的控制路径全部失效。4.2 观测路径增强技巧对于UO故障report_test_stimulus命令是我的首选report_test_stimulus -fault /top/ram_ctrl/state_machine/next_state[1] -stuck_at 0这个命令会显示故障传播路径上所有关键节点的值。有次在分析DDR控制器时发现观测路径被一个未初始化的扫描链截断通过set_simulation -initialize all解决了问题。对于频繁出现的aborted faults我会set_atpg -abort_limit 100 report_aborted_faults -verbose适当提高尝试次数可以挽救部分故障但要注意pattern数量的爆炸增长。我的经验是控制在原始值的3倍以内。5. 实战中的覆盖率提升策略5.1 分模块渐进式优化我从不建议一开始就全面铺开调试。更有效的方法是用report_statistics -by_module找出最差的3个模块集中火力解决这些模块的AU问题接着处理UC问题最后清理UO故障上周在服务器芯片项目中采用这个策略后仅优化了前两大模块就将整体覆盖率从82%提升到了89%效率提升了3倍。5.2 约束动态调整技术高级技巧是使用条件约束add_input_constraints test_mode -C1 add_input_constraints func_mode -CT0 when test_mode0这样既能保证功能模式下的约束需求又不影响测试模式下的可控性。在混合信号芯片调试中这个方法帮我解决了模拟模块接口的约束冲突问题。5.3 时钟门控的黄金法则关于时钟门控我总结了一条铁律TE端必须且只能连接scan_enable或其衍生信号。违反这条规则的案例我见过不下十次。正确的连接方式应该是set_clock_gating -test_enable scan_enable [get_cells clk_gate*]在最近的一个RISC-V项目中通过修正这个连接关系单次ATPG运行就提升了7%的覆盖率。