企业官网建设流程全解析

简介：这份PDF是Mentor Graphics官方发布的Tessent Scan与ATPG用户手册（软件版本2017.3），面向IC设计、验证及可测试性设计（DFT）工程师，系统讲解自动测试模式生成（ATPG）的完整流程与工具操作方法。手册从ATPG基本概念、故障模型、扫描链与设计规则检查讲起，逐步深入到Tessent Scan的扫描插入、测试模式生成、覆盖率分析和故障诊断，并配有命令参考、执行示例与常见问题说明，帮助读者掌握从网表输入到生成有效测试向量的全过程。内容组织按模块划分，目录完整，既可让DFT初学者建立体系化认知，也能作为日常工具调用的速查手册。压缩包内仅含1个PDF文件，整体大小约10.33MB，便于离线阅读或检索。目前已有686人学习下载，是IC测试领域值得收藏的官方参考资料。

1. 从一份 PDF 里读懂 ATPG 的底层逻辑：这份用户手册值不值得细读

ATPG（Automatic Test Pattern Generation，自动测试模式生成）是 IC 可测试性设计绕不开的一环，但很多人第一次接触时，都被覆盖率报告里那些 DT、PT、AU、RU 的缩写整懵了。真正的问题往往不在“向量不够多”，而在工具眼里你的扫描链和故障模型是否建对了。这份 2017.3 版 Tessent Scan 与 ATPG 用户手册，恰好把扫描结构、故障分类、模式生成、设计规则检查这几块讲透了。它适合三类人：刚切入 DFT 的数字 IC 工程师、被覆盖率卡住想搞清楚 UT 故障真实含义的验证工程师、要给某个内核加 wrapper 做隔离测试的架构师。注意，它讲的是流程和方法论，不是 GUI 点击教学，读它需要一点耐心。

2. 扫描链与故障模型：先弄懂工具眼里的 DFT 世界

ATPG 工具不会像人一样理解你的 RTL 功能，它只看 flatten 之后的网表和扫描结构。Tessent 手册前两章花了大量篇幅讲扫描单元、扫描链、时钟和 test procedure，这恰恰是新手最容易跳过的部分，也是后续所有覆盖率问题的根源。

2.1 扫描单元的分类：master、slave、shadow、copy、extra 各是什么角色

手册把扫描单元分成 master element、slave element、shadow element、copy element、extra element 五类。master 是主锁存器，比如边沿触发的 DFF 本身；slave 是从锁存器，常见于锁存器对组成的电平敏感单元；shadow element 指的是在扫描移位时被用作临时保存的冗余锁存器，它不参与功能路径；copy element 是逻辑等价的重复单元；extra element 是设计里多出来、打乱了扫描链预期结构的逻辑。

为什么要区分这些？因为 ATPG 在判断一个故障是否可测时，必须知道每个单元在 scan 模式下是透明、保持还是捕获状态。我见过不少团队直接把所有锁存器当 DFF 处理，结果 DRC 报出一大堆 clock 规则冲突，绕了一圈才发现是 shadow latch 没做标识。手册 3.1.4 到 3.1.7 讲的正是这些单元的判定依据，读的时候建议对照自己的网表打开一份 scan chain trace 报告，逐个核对单元分类。

2.2 扫描链、扫描组与 wrapper chain：嵌入式测试的关键结构

手册里定义了 scan chain、scan group、scan clock 三个层面。scan chain 是物理扫描路径本身；scan group 是把若干条链按测试需求打包，比如共享同一组 shift 信号的链归为一组；scan clock 则决定了 shift 和 capture 阶段的时钟行为。三者关系理顺了，才能正确写出 test procedure file 里的 load、unload、capture 时序。

wrapper chain 在 SoC 里做内核隔离时特别关键。当一个内核要被单独测试，而周围逻辑还在正常工作，wrapper 就负责把内核的输入输出隔离出来，让 ATPG 只关心内核内部故障。手册专门用了独立小节讲 wrapper chains 的插入和连接，并提醒 wrapper 的 shift 时序和内部扫描链时序如果不匹配，会导致 chip-level 仿真结果和 core-level 不一致。实操中，我一般会在 core-level 先把 wrapper DRC 跑干净，再进 chip-level 做整体插入，这样翻车概率小很多。

2.3 三类测试模式生成：随机、确定性、外部，分别解决什么问题

ATPG 的流程不是一股脑生成向量，而是分三种策略。随机模式生成（random pattern test generation）直接对电路施加伪随机向量，主要用于 BIST 场景或快速评估电路的可测试性上限，它的特点是跑得快，但覆盖率很快就到天花板。确定性模式生成（deterministic pattern test generation）针对尚未被检测的故障做定向的敏感化和传播，覆盖率可以推到 98% 以上，但运行时间随故障数量增长明显。外部模式生成（external pattern test generation）则是把外部工具或 ATE 上已有的测试序列导入，按统一的 fault simulation 流程评估覆盖效果。

三者的选用顺序，我一般建议先跑一小批随机模式看 baseline，再用确定性模式补到目标覆盖率，最后把已有的功能向量转成故障仿真格式，看它们能不能顺手覆盖掉一部分难测故障。下表整理了三种模式的关键差异：

2.4 fault model 选型：stuck-at 只是起点

手册第 2 章把测试类型和故障模型的对应关系列得很清楚。stuck-at 模型对应静态 DC 测试，也是最常用的 baseline；transition 模型对应 at-speed 测试，需要在 capture 阶段用功能时钟沿去捕获跳变；path delay 模型针对关键路径的时序验证；IDDQ 模型靠测量静态电流识别异常，不依赖具体信号值；bridge 故障则要借助 UDFM（用户自定义故障模型）来建模。

选型策略上，不要一上来就全上。先用 stuck-at 把设计和流程跑通，看 DRC 是否干净、覆盖率基线是多少，再决定要不要加 transition。如果产品缺陷率要求高，或者工艺节点先进，transition 基本是必须的，但代价是向量数和测试时间都上去了。IDDQ 我一般放在最后，因为它对测试环境和电流阈值很敏感，很容易被浮空总线干扰，这部分后面避坑章节会细说。

3. 故障分类与报告解读：别被 UT 和 AU 淹没

覆盖率报告不是一个小数，而是一整套故障分类体系。手册里 Fault Classes 那一章定义了 Testable 和 Untestable 的完整层级，读懂了它，你才能从报告反推设计问题。

3.1 故障类层级：从 TE 到 DT、PT、UO

故障类分两大支：Testable（TE）和 Untestable（UT）。TE 表示工具认为这个故障在原理上有检测的可能，但实际仿真后还要细分。Detected（DT）表示至少被一条向量检测到；Possibly Detected（PT）表示只在部分 X 条件下可能检测到，无法完全确认；Undetected（UO）表示没被当前向量集覆盖到。UT 类下面还有子类，比如 ATPG untestable（AU）表示受扫描结构或时钟约束限制，工具试了但无法生成检测条件；redundant untestable（RU）表示故障对应的逻辑本身就是冗余的，比如某个门的输出永远固定。

很多工程师只盯总覆盖率，忽略了 DT 和 PT 的占比结构。PT 高往往意味着 X 态太多，或者 capture 窗口不够宽；AU 高说明设计里有大量时钟不可控、异步置位复位没处理干净的逻辑；RU 高则提示冗余逻辑太多，电路面积白花了。下表把常见类的工程含义列出来：

3.2 故障报告怎么读：先看分布，再定位模块

拿到一份故障报告，我习惯先看三类比例：DT 占总故障数的比例、AU 占未测故障的比例、RU 的绝对值。如果 AU 比例超过未测故障的一半，加向量基本没用，问题出在设计和扫描结构的可控性上；如果 RU 多，先评估能不能通过 RTL 优化消掉冗余逻辑；如果 PT 多，优先检查测试平台里 X 态的传递，尤其是跨时钟域的同步器。

还有个容易被忽略的点：故障折叠（fault collapsing）。手册里提到等价折叠和支配折叠，等价关系靠 learning 分析得出，支配关系能进一步压缩故障数量。折叠后的故障数量直接影响 ATPG 运行时间，所以跑长流程前建议先把折叠系数打开，观察压缩比是否合理。压缩比异常偏低，往往说明 learning 阶段没跑透，或者网表里有大量非标准单元。

3.3 用户自定义故障模型 UDFM 与 multiple detect

标准库之外的自定义故障，比如特定桥接、特定晶体管的 stuck-on 行为，可以用用户自定义故障模型（UDFM）描述。手册给出了 UDFM 文件格式的字段说明：故障点位、逻辑描述、使能条件、反相标志。建立 UDFM 的步骤是：先定义故障点位和逻辑表达式，再提交给工具做模式生成，最后把 UDFM 故障和标准故障合并统计覆盖率。因为 UDFM 故障没有库模型可依赖，文件格式的严谨性比内容本身更重要，我见过有人在逻辑表达式里漏了括号，导致整条故障链静默失效。

multiple detect 则是针对同一故障要求被检测多次的选项。它不是为了对付建模错误，而是提高随机缺陷的检测概率，因为某些物理缺陷只在特定条件下表现，多检测几次能显著降低漏检率。手册里建议 multiple detect 的次数设置在 2 到 5 之间，次数再高，向量数增长不划算。Bridge coverage estimate 则是用桥接故障分布模型估算当前向量集对桥接缺陷的覆盖水平，在做先进工艺节点时值得跑一次。

4. 把手册读进 dofile：一套可抄作业的 ATPG 主流程

手册最终要落到你能跑起来的脚本上。下面这套流程基于手册章节顺序整理，命令保留了通用风格，实际使用时以你手里版本的命令名为准。

4.1 环境初始化与模型读入

ATPG 跑的第一步不是生成模式，而是把网表、库和设计约束喂进去。常见的做法是写一个 setup dofile，统一完成读库、读网表、指定顶层和设置时钟端口。

# setup.tcl —— 环境初始化（命令名以手册对应版本为准） read_netlist ./data/top_scan.vg set_current_design top read_library ./lib/std_cells.tlib -technology add_clocks CK -port CK -period 10.0 add_clocks SCK -port SCK -period 20.0 -shift add_scan_chains chain0 -input SI0 -output SO0 \ -cells {u_ff0/u_ff1/u_ff2 ...}

逻辑说明：read_library 指定标准单元库的时序和仿真模型，add_clocks 把功能时钟和扫描时钟分开声明，shift 属性标记扫描移位时钟。add_scan_chains 则是把扫描链的物理路径告诉工具，cells 列表可以由 DFT 插入工具生成后导回。参数说明：period 设为 10 表示功能时钟周期 10ns；shift 时钟单独设 20ns，是给 shift 阶段留足裕量，防止仿真时出现竞争。

4.2 DRC 与 learning：先跑规则再谈覆盖率

网表读完后，一定先做设计规则检查（DRC），再做 learning，再进行模式生成。跳过 DRC 直接跑 ATPG，是新手最容易犯的错。程序化规则（procedure rules）和通用规则（general rules）是两类，程序化规则主要检查 test procedure 里的 load/unload/capture 时序是否和扫描链结构匹配。

# drc_learning.tcl —— 规则检查与学习分析 set_current_design top check_design_rules -general -verbose check_design_rules -procedure -verbose run_learning -effort high run_drc -mode scan report_design_rules -summary

逻辑说明：check_design_rules 先做静态检查，确认拓扑和时序声明没有硬伤；run_learning 计算等价关系、隐含关系、禁止关系和支配关系，用于后续故障折叠；run_drc 则把扫描相关的结构规则跑一遍。参数说明：-effort high 会拉长 learning 时间但能显著压缩故障数量；report_design_rules 输出的 summary 要重点看 fatal 和 error 数量，warning 可以先放着但别忽略。

DRC 结果里有一类 bus mutual exclusivity 分析，专门检查总线驱动是否有互斥约束，避免多个驱动同时使能。这个分析和 IDDQ 测试关系很大，浮空总线在 IDDQ 下会表现为异常电流。手册建议跑完 DRC 后单独看一眼总线的 mutual exclusivity 报告，确认每个总线在 capture 阶段只有一个驱动有效。

4.3 故障建模与模式生成：覆盖率是结果不是目标

DRC 干净后，进入故障建模和模式生成阶段。故障建模的关键参数是 fault model 选择和折叠开关。折叠默认打开，工具会基于 learning 结果合并等价故障和支配故障。模式生成的核心参数是目标故障集合和最大模式数。

# atpg_run.tcl —— 故障建模与模式生成 set_current_design top add_faults -model stuck_at -collapse on report_faults -summary create_patterns -deterministic -max_patterns 5000 \ -target_faults all -output patterns.stil run_simulation -patterns patterns.stil -verbose report_coverage -detail

逻辑说明：add_faults 按 stuck-at 模型把网表里所有可测故障加载进来，-collapse on 开启折叠；create_patterns 跑确定性模式生成，把未测故障逐一作为目标；run_simulation 对生成的模式做故障仿真，确认最终覆盖状态；report_coverage 输出按模块、按故障类的细化报告。参数说明：-max_patterns 5000 是上限保护，防止工具在低可测性设计上无限循环；-target_faults all 表示对所有未测故障生成模式，也可以指定为某个子集来节省时间。

覆盖率结果出来以后，别急着改参数再跑一轮，先看 fault class 分布。AU 高的设计，加 max_patterns 没有意义；RU 高的设计，去改 RTL；PT 高的设计，检查测试平台。这个判断顺序，能帮你省下大量无意义的重复跑批。

5. ATPG 实战避坑：五个我真实踩过的坑

跑 ATPG 流程第二年，我发现自己大部分时间不是在调算法，而是在排错。下面这五条坑，每条都对应手册里的某一小节，也对应一段真实翻车的血泪经验。

5.1 时钟互斥规则冲突：capture 阶段两个时钟同时有效

现象：DRC 报出 clock not mutually exclusive，工具拒绝继续生成模式。原因：test procedure 文件里 capture 窗口定义得太宽，把两个本来不该同时有效的时钟都包了进去。解决：回到 test procedure，把 capture 的 pulse 位置收窄，并把时钟分组重新声明。从那以后我每次改 procedure 文件，都会先单独跑一遍 procedure DRC 再进主流程。

5.2 覆盖率卡在 85% 不动：加向量是无效努力

现象：加了两万条模式，覆盖率只涨了 0.2%。原因：未测故障里 AU 占了八成，这些故障和向量多少没关系，是扫描结构或约束导致的不可测。解决：先 report_faults -class AU 按模块做分布统计，定位到具体模块后查时钟可控性和异步复位逻辑。通常加几个测试点就能把 AU 拉回可测范围。

5.3 IDDQ 批量异常：浮空总线是头号嫌疑

现象：IDDQ 模式下大量单元电流超标，把正常芯片也误判成坏片。原因：总线在捕获阶段多驱动同时使能，形成浮空和竞争，静态电流异常。解决：按手册建议做 bus mutual exclusivity 分析，把有问题的总线加入互斥约束，再单独跑 IDDQ 向量。不要试图用提高电流阈值来压掉误判，那是掩盖问题。

5.4 shadow element 识别失败：core-level 和 chip-level 结果不一致

现象：同样的内核，core-level ATPG 覆盖率 97%，chip-level 集成后降到 91%。原因：wrapper 插入时 shadow latch 没有被正确识别，wrapper 的隔离时序和内核内部时钟错位，导致部分捕获路径失效。解决：先确认 core-level 的 shadow 识别报告，再进 chip-level 插入。两个层级的 shadow 单元名单必须完全一致，差一个都会影响结果。

5.5 浏览器打开 PDF 目录链接失效

现象：从网页端打开这份用户手册，点目录章节跳转没反应。原因：手册正式说明过，在浏览器里查看 PDF 会导致部分链接无法使用。解决：下载后用本地阅读器打开，目录跳转就正常了。这个坑和 ATPG 本身无关，但卡住时很影响心情，先解决工具问题再看手册，效率更高。

6. 把故障报告变成设计改进清单：一个收尾技巧

读完整本手册，我学到的最值钱的东西不是某条命令，而是把故障报告当设计诊断工具用。覆盖率数字只是结果，真正有价值的是故障类分布。我现在的做法是，每次 ATPG 跑完后，绝不只看总覆盖率，而是强制自己先做一次按模块聚合的故障类统计，把 AU 和 RU 最多的五个模块列出来，直接作为下一版设计的改进清单。

# 按层级模块统计 AU 故障数量（示意） grep -E "AU" fault_report.txt | awk -F'/' '{print $2}' | sort | uniq -c | sort -rn | head -5

这个命令的作用是把故障报告里 AU 类故障按模块名的第二级路径聚合，找出不可测故障最集中的区域。顺着这份清单去查代码，大概率能发现常量门、不可控的时钟门控，或者冗余的组合逻辑。推进到第三个项目时，我对自己团队的要求是：AU 模块清单必须在 RTL freeze 之前清掉一半，否则不签字。

从那以后，我每次启动一个项目的 ATPG 工作，都强制自己把这条命令的输出存下来，和上一版做对比。覆盖率提升了但 AU 没变，说明只是向量加得多；AU 明显下降了，才是设计真的变好了。这个方法帮我少开了很多无效会议，也让我在评审会上有数据可讲。希望帮到你。

本文还有配套的精品资源，点击获取