ATPG覆盖率提升受阻：AU类型Fault激增的深度诊断与实战Debug

1. ATPG覆盖率与AU类型Fault的困扰最近在做一个ATPG项目时遇到了一个让人头疼的问题pattern生成过程中AUATPG Untestable类型的故障比例突然飙升导致最终的测试覆盖率卡在31.43%就上不去了。这种情况在芯片测试中相当常见但每次遇到都让人抓狂。就像你明明按照菜谱做菜却总是做不出想要的味道。ATPG覆盖率上不去通常意味着芯片中存在大量无法被测试向量覆盖的潜在缺陷。而AU类型的故障激增更是直接拉低了整体覆盖率。我遇到的情况是随着pattern数量的增加AU faults的占比从最初的几个百分点一路飙升到45.13%其中大部分还是无法分类的unclassified类型。更糟的是生成的221条pattern中有效率只有77.34%这意味着有近四分之一的pattern是无效的。2. 初步诊断从warning开始入手2.1 工具警告的蛛丝马迹项目一开始工具就给出了一个不容忽视的warningthe number of AU faults has increased by **% since the start of this ATPG。这种警告就像是汽车的故障灯提醒你系统出现了异常。我的经验是遇到这种警告一定要立即停下来检查而不是继续生成更多pattern。首先我使用report_faults命令查看AU.unclassified类型的故障点report_faults AU.unclassified这个命令会把所有AU类型的故障点列出来。在分析这些故障点时我通常会优先关注寄存器的D端因为这些位置的故障更容易追踪。就像医生看病要先看关键指标一样这些点是诊断问题的突破口。2.2 深入分析pattern有效性接下来我尝试用set_gate_report命令查看第一条pattern在电路中的配置情况set_gate_report pattern_index 0结果工具提示No internal scan test pattern exist。这显然不正常于是我加上更多选项再次尝试set_gate_report pattern_index 0 -internal -chain_test这次得到的警告更具体warning the selected pattern contains no capture cycle so cannot be simulated for report。这意味着我们保存的pattern竟然没有capture cycle这就像相机按了快门却没有打开镜头盖怎么可能拍到照片呢3. 深度调试追踪复位信号问题3.1 故障点的精确定位通过反复调试我注意到一个关键现象在展示fault_location及其前置电路的各端口状态时发现寄存器的复位端在pattern中被随意赋值的现象。这就像乐队指挥突然乱打拍子整个系统都乱套了。具体来说某些寄存器的复位信号在pattern中时高时低没有一个稳定的状态。这种情况会导致ATPG工具无法正确生成测试向量因为复位信号的不确定性会传播到整个电路。就像多米诺骨牌第一块没摆好后面的全都会倒。3.2 复位信号约束的解决方案找到问题根源后解决方法就相对明确了需要在ATPG阶段加入对复位信号的约束。我使用了以下命令set_static_dft_signal sync_set_reset_disable -value 1这个命令将sync_set_reset_disable信号固定为高电平确保复位信号不会被随意改变。就像给乐队指挥一个明确的节拍器让整个系统恢复秩序。4. 关键命令详解与实战技巧4.1 set_gate_report的深度使用set_gate_report是ATPG调试中最强大的工具之一但很多人只用了它最基本的功能。让我分享几个实战中特别有用的选项set_gate_report capture_procedure procedure_name这个选项可以报告受NCP(named capture procedure)中force和条件定义影响的每个门的值。特别适合debug那些无法检测特定fault或者预防总线竞争的情况。另一个实用选项是set_gate_report clock_cone pin_name它能展示指定引脚clock cone的数据。不过要注意这个选项只能在create_flat_model之后使用而且引脚必须是有效的时钟引脚否则会报错。4.2 故障状态解读指南在report_gate的输出中fault_status会显示各种故障状态代码这些代码就像医生的诊断书需要正确解读DS通过仿真检测到DI通过推导检测到PU可能检测到但不可测试PT可能检测到且可测试AUATPG不可测试这就是我们遇到的麻烦制造者UC未检测到且不受控UO未检测到且未被观察到UU由于阻塞而不可测试TI由于固定连接而不可测试RE冗余不可测试理解这些状态代码对快速定位问题至关重要。就像侦探破案每个线索都有其特定含义。5. 避免常见陷阱的经验分享在这个项目中我踩过一个典型的坑在脚本中write_pattern之后为了获得更准确的internal mode测试覆盖率我尝试将external mode下的fault list读入并与当前fault合并read_faults -mode ext_multi_transition -fault_type transition -merge结果导致内部测试向量没有被正确读入。解决方法是要么从头开始重新运行要么再次明确读入内部模式下的向量read_pattern -fault_type transition -mode internal_mode这个教训告诉我在混合不同测试模式时要格外小心就像不要把不同菜系的调料混用一样结果可能会很糟糕。6. 系统性的AU故障预防策略经过这次调试我总结出一套预防AU故障激增的系统性方法首先在项目开始阶段就要检查所有关键控制信号特别是复位信号的约束是否合理。这就像建筑的地基必须从一开始就打牢。其次要定期监控AU故障的增长趋势。如果发现异常增长应该立即暂停pattern生成而不是等到最后才处理。就像开车时发现油表异常应该立即检查而不是等到抛锚。最后建立一套标准化的debug流程从warning入手使用report_faults定位问题区域再用set_gate_report深入分析具体电路状态。这套方法在多个项目中都被证明是有效的。