1. ATPG 是什么？

ATPG = Automatic Test Pattern Generation。Scan Chain 搭好了"高速公路"，ATPG 负责生成跑在这条路上的"测试车辆"——即施加给芯片的测试向量，用于检测制造缺陷。

一个类比：你有栋大楼（芯片），每层都有防火传感器（扫描触发器）。Scan Chain 把所有传感器串成一条线通到一楼控制室，ATPG 则自动设计"放烟测试方案"——在哪个房间放、期待哪个房间报警。故障诊断就是报警失败后，定位问题出在传感器坏了、线路断了、还是烟没飘到。

2. 为什么需要 ATPG？

制造缺陷客观存在：

缺陷类型	原因	占比
桥接	金属线短路	~40%
开路	断线/通孔失效	~30%
氧化物缺陷	栅氧化层击穿	~15%
杂质颗粒	工艺环境引入	~15%

十万触发器的芯片，手动写测试向量不可行。ATPG 自动完成，让工程师从"写向量"变成"分析结果"。

3. 故障模型

Stuck-At

• SA0：节点永远为 0
• SA1：节点永远为 1

正常 AND: A=1,B=1 → Y=1
A 端 SA0:  A=0(卡死),B=1 → Y=0（即使 A 本应为 1）

Transition Delay

• Slow-to-Rise：0→1 跳变慢于预期
• Slow-to-Fall：1→0 跳变慢于预期
• 需要两个向量：初始设置初始状态 + 启动触发跳变，下一拍捕获

Path Delay

路径累积延迟超时钟周期，不针对单节点，针对整条路径。

Bridge

相邻金属线短路，表现为线与/线或行为。

4. Cadence Genus ATPG 实战流程

4.1 Genus 自动生成的 ATPG 脚本

完成 DFT（scan insertion）后，Genus 会自动在输出目录生成 ATPG 脚本。位置：

results/<design>/
├── <design>_scan.v.gz          # 带 scan 的综合网表
├── <design>_scan.stil          # scan 协议文件（STIL 格式）
└── atpg/
    ├── <design>_atpg.tcl       # 自动生成的 ATPG 主脚本 ← 核心
    ├── <design>_patterns.stil  # 输出 pattern（STIL）
    ├── <design>_patterns.v     # 输出 pattern（Verilog）
    └── <design>_atpg.log       # 运行日志

自动生成的脚本大致如下（以 Genus 实际输出格式为准）：

# ============================================================
# Auto-generated by Genus Synthesis (ATPGenu)
# Design: XXX   Top: XXX   Date: 2026-05-19
# ============================================================

# ---- Read Design ----
read_design -netlist results/XXX/XXX_scan.v.gz
read_library lib/tcbn180mv3.lib

# ---- Build Model ----
build_model -top XXX -clock CLK
add_reset RSTB

# ---- Set Fault Model ----
set_faults -model stuck_at

# ---- Create Test Protocol ----
create_test_protocol \
  -clock CLK   {posedge} \
  -reset RSTB  {negedge} \
  -scan_enable SE

# ---- DRC ----
run_drc

# ---- ATPG ----
run_atpg -auto \
  -coverage_target 95 \
  -max_patterns 2000

# ---- Reports ----
report_summary
report_test_coverage

# ---- Output ----
write_patterns -format stil -o results/XXX/atpg/XXX_patterns.stil
write_patterns -format verilog -o results/XXX/atpg/XXX_patterns.v

这个脚本可以直接运行。只要综合 + DFT 流程正确，Genus 输出的是"一键执行"脚本。但不同阶段需要跑 ATPG 时，脚本里的路径和配置需要调整。

---

4.2 场景一：综合后网表跑 ATPG（最直接）

输入：Genus DFT 输出的 XXX_scan.v.gz

操作：自动生成的脚本基本不用改，确认以下路径正确后直接运行：

# 只需要确认这3个路径
read_design -netlist   results/XXX/XXX_scan.v.gz    # 综合后 DFT 网表
read_library           lib/tcbn180mv3.lib            # 综合库
write_patterns  -stil  results/XXX/atpg/XXX_patterns.stil

运行方式：

genus -f results/XXX/atpg/XXX_atpg.tcl -log atpg_run.log

预期输出：stuck-at 覆盖率通常 > 95%，transition > 85%。

为什么这时候跑？

• 快速验证 DFT 插入是否正确
• 发现覆盖率问题尽早修（加 test point、调 chain）
• 给测试工程师提供 pattern 做早期验证

---

4.3 场景二：PNR 后网表跑 ATPG（最关键的签核检查）

为什么 PNR 后还要跑 ATPG？

• 综合网表是理想的 —— PNR 会插入物理单元（filler、decap、tap）、修正时序（buffer insertion）、重命名部分 cell
• 物理单元可能打断 scan chain，导致某些 chain 开路或短路
• cell 重命名后，pattern 里的 pin 路径必须匹配新名字
• 某些 transition fault 只有加上了物理单元后的真实延迟才能检测到

输入：Innovus 输出的 XXX_final.v

需要修改的内容：

# ============================================================
# Post-PNR ATPG — 从自动生成脚本修改而来
# 改动点用 ★ 标注
# ============================================================

# ★ 1. 换网表：从综合网表 → PNR 网表
read_design -netlist output/XXX_final.v

# ★ 2. 库要补充物理单元库
#    否则 ATPG 不认识 filler/decap 这些物理 cell
read_library lib/tcbn180mv3.lib
read_library lib/tcbn180mv3_physical.lib

# ★ 3. Top 名可能变了：Innovus 可能改过设计名或 flatten 了
#    用 report_design 检查后再指定
build_model -top XXX_FINAL -clock CLK
add_reset RSTB

# ★ 4. STIL 协议文件也要换
#    如果 PNR 后 scan chain 有调整（reorder 或 remap），要重新提取 STIL
#    可以在 Innovus 里重新导出：
#    innovus> write_stil -output output/XXX_final.stil
read_stil output/XXX_final.stil

# ---- Fault Model ----
set_faults -model stuck_at

# ★ 5. 排除物理单元（filler/decap/tap 不参与 ATPG）
set_faults -exclude_cells {FILL* DECAP* TAP*}

# ---- ATPG ----
run_atpg -auto -coverage_target 95 -max_patterns 3000

# ---- 对比报告 ----
# PNR 后的覆盖率通常比综合后低 1~3 个百分点
# 原因：物理单元的冗余路径引入了不可测故障
report_summary
report_test_coverage

# ---- 输出 ----
write_patterns -format stil     -o output/atpg/XXX_pnr_patterns.stil
write_patterns -format verilog  -o output/atpg/XXX_pnr_patterns.v

PNR 后覆盖率下降的常见原因：

原因	现象	处理
filler cell 打断 chain	chain 开路，大量 fault 不可测	PNR 时检查 scan chain connectivity
物理单元引入冗余逻辑	覆盖率掉 1~2%	排除物理单元后重跑
cell 重命名	网表 pin 名与 STIL 不匹配	重新提取 STIL
时钟树综合后插入的 buffer	transition fault 测不到	确认 clock gate 是否正确建模

---

4.4 场景三：ECO 后增量 ATPG

背景：芯片已经流片回来发现 bug，做 metal ECO。只需要改了几根金属层的连线。

原则：不要重新生成全部 pattern —— 只需要增量覆盖 ECO 区域。

# ============================================================
# ECO ATPG — 增量模式
# ============================================================

read_design -netlist output/XXX_eco.v
read_library lib/tcbn180mv3.lib

build_model -top XXX

set_faults -model stuck_at

# ★ 关键：只对 ECO 修改过的区域生成本次新 pattern
#    指定 ECO 影响范围（被修改的标准单元）
add_faults -region {U_ECO1 U_ECO2 U_ECO3}

# ★ 保留已有的 pattern（pre-PNR 生成的）
read_patterns results/XXX/atpg/XXX_patterns.stil

# 运行 ATPG，只补新 fault
run_atpg -incremental -coverage_target 95

# 输出：原 pattern + 新增 pattern
write_patterns -format stil -o output/atpg/XXX_eco_patterns.stil

ECO ATPG 的关键原则：

• 保留修片前已验证通过的 pattern（减少测试机复测时间）
• 只追加 ECO 影响区域的新 pattern
• 跑 transition fault 检查 ECO 路径的时序裕量

---

4.5 三个场景的输入/输出对比

阶段	输入网表	库	ATPG 目标	典型覆盖率
综合后 DFT	XXX_scan.v.gz	综合库	验证 DFT 正确性	SA > 98%
PNR 后	XXX_final.v	综合库 + 物理库	签核检查	SA > 95%（比上阶段低 1~3%）
ECO 后	XXX_eco.v	综合库	增量覆盖 ECO 区域	保持原有 + ECO region > 95%

4.6 实用技巧

技巧 1：检查 Scan Chain 完整性

# ATPG 前先跑 DRC
run_drc
# 查看 chain 状态
report_scan_chains > scan_chain_check.rpt

技巧 2：从 Innovus 重新提取 STIL

# Innovus shell 中
write_stil -output output/XXX_final.stil
# 含 scan chain 定义、时钟波形、IO 时序

技巧 3：对比 pre/post PNR 的 fault list

# 综合后：输出 fault list 存底
report_faults -all -o pre_pnr_faults.rpt

# PNR 后：输出新的 fault list
report_faults -all -o post_pnr_faults.rpt

# 用 diff 对比新增的不可测故障
# → 如果大量集中在时钟/复位树，说明 PNR 插入了影响 scan 的 buffer

技巧 4：管理 cell 重命名

# Innovus 可能给 cell 加后缀如 _dup、_L1
# 写一个 name mapping 文件供 ATPG 使用
# genus> 
read_name_mapping innovus_name_map.txt

5. ATPG 算法简述

D-Algorithm (1966) → PODEM (1981) → FAN (1983) → SOCRATES (1988) → 现代商用 ATPG

核心三步：

1. 故障激活（Activation）：让故障点值与正常相反（测 SA0 → 让该点正常为 1）
2. 故障传播（Propagation）：把差异传送到某个可观测的 scan flip-flop
3. 确定化（Justification）：反向确定所有其他信号保证传播路径成立

商用 ATPG 引擎（Genus ATPGenu）实际策略：

• 先用随机 pattern 快速覆盖 ~80% 的 fault
• 再用确定式算法（PODEM-like）覆盖剩余难测 fault
• 最后用 fault simulation 去重验证

6. 其他工具 ATPG 参考

Synopsys TetraMAX

read_netlist -format verilog output/XXX_scan.v
run_build_model XXX
run_atpg -auto_compression
write_patterns XXX_pattern.stil -format stil

Mentor Tessent

set_context atpg
add_faults -all
run_atpg -auto
write_patterns XXX_pattern.stil -format stil

核心概念相通，只是命令风格不同。

7. 虚拟项目复盘

背景

XXX 多节锂电池保护芯片，180nm，85k 等效门，2 条 Scan Chain，约 12k 扫描触发器。

问题 1：综合后 ATPG 覆盖率仅 78%

排查工具：Genus ATPGenu 的 report_faults -untestable。

发现大量冗余故障集中在保护比较器的"先比较再锁存"结构 —— 锁存器后节点在 scan mode 不可控。

修复：在锁存器后插入 test point（观测寄存器），覆盖率 78% → 96.3%。

问题 2：PNR 后网表跑 ATPG 覆盖率骤降

综合后 96.3% → PNR 后 82%。

分析：Innovus 插入了 3,000+ filler cell，其中部分打断了 scan chain 的物理连接。但真正的原因是 —— PNR 后的 STIL 协议文件没有重新提取，用的还是综合阶段的老协议。

修复：在 Innovus 中重新 write_stil，替换 ATPG 脚本中的 STIL 文件。覆盖率回到 95.4%。

问题 3：测试机台 pattern 内存不足

预-PNR 生成的 pattern 8,500 条，测试机限 3,000 条。

修复：

• 开启 Genus 的 set_compression -mode xcompact
• 把 chain 从 2 条增加到 8 条
• 限制 -max_patterns 3000

结果：pattern 缩到 2,400 条，覆盖率 96.1%。

复盘总结

问题	根因	修复	教训
覆盖率 78%	锁存器结构不可测	插入 test point	DFT 规划阶段跑 testability analysis
PNR 后覆盖率骤降	STIL 未更新	从 Innovus 重新提取	PNR 后必须更新 STIL
Pattern 超限	chain 少 + 无压缩	增加 chain + 开 compression	chain 数在芯片规划阶段确定
低温测试失败	地址译码路径 transition 差	ECO + 约束补充	ATPG + STA 交叉验证关键路径