ATPG覆盖率提升受阻：AU类型Fault激增的深度诊断与实战Debug
1. ATPG覆盖率与AU类型Fault的困扰
最近在做一个ATPG项目时，遇到了一个让人头疼的问题：pattern生成过程中，AU（ATPG Untestable）类型的故障比例突然飙升，导致最终的测试覆盖率卡在31.43%就上不去了。这种情况在芯片测试中相当常见，但每次遇到都让人抓狂。就像你明明按照菜谱做菜，却总是做不出想要的味道。
ATPG覆盖率上不去，通常意味着芯片中存在大量无法被测试向量覆盖的潜在缺陷。而AU类型的故障激增，更是直接拉低了整体覆盖率。我遇到的情况是，随着pattern数量的增加，AU faults的占比从最初的几个百分点一路飙升到45.13%，其中大部分还是无法分类的unclassified类型。更糟的是，生成的221条pattern中，有效率只有77.34%，这意味着有近四分之一的pattern是无效的。
2. 初步诊断：从warning开始入手
2.1 工具警告的蛛丝马迹
项目一开始，工具就给出了一个不容忽视的warning："the 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：可能检测到且可测试
- AU：ATPG不可测试（这就是我们遇到的麻烦制造者）
- 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深入分析具体电路状态。这套方法在多个项目中都被证明是有效的。