1. 从设计到硅片为什么Scan DFT和ATPG是芯片良率的守门人一颗芯片从RTL代码到最终封装出厂中间要经历无数道关卡而可测性设计DFT就是其中最关键的一道保险。很多刚入行的朋友会觉得DFT就是后端流程里一个“跑跑工具”的环节但实际上Scan DFT和ATPG直接决定了这颗芯片能不能被高效、低成本地筛出制造缺陷。我见过太多项目因为DFT架构没规划好导致测试向量膨胀、测试时间翻倍最后量产成本压不下来甚至芯片流片回来发现覆盖率死活上不去只能改版。这篇文章的核心就是要把从网表到测试向量这条链路彻底讲透。我会围绕Scan DFT的基本原理、ATPG的完整流程以及Cadence Modus工具的实际操作来展开。无论你是刚接触DFT的验证工程师还是想补全后端知识的数字IC设计者或者是在项目中需要和测试团队对接的架构师这篇内容都能帮你建立起一套可落地的认知框架。我不会只讲概念而是会把每一步的“为什么这么做”和“踩过的坑”都摊开来说让你看完就能在自己的项目里复现。先给一个最直观的类比Scan DFT就像给芯片内部密密麻麻的触发器装上了一排“后门”。正常工作时这些触发器按功能逻辑连接测试模式下它们被串成一条或多条移位寄存器链外部测试机可以通过少量引脚把成千上万个内部节点“推”进特定状态再把结果“拉”出来比对。而ATPG就是那个自动生成“推什么、拉什么”的算法引擎它根据网表结构和故障模型算出一组最精简的输入激励和期望输出这就是测试向量。没有Scan DFTATPG只能针对少量外部引脚做功能测试覆盖率极低有了Scan DFTATPG才能深入芯片内部把制造过程中可能出现的固定故障Stuck-at、转换延迟故障Transition Delay等逐一揪出来。所以这两者是绑定的Scan是硬件基础ATPG是软件算法网表是输入测试向量是输出。整条链路走通芯片的良率筛选才有保障。2. Scan DFT架构设计从功能触发器到扫描链的改造逻辑2.1 扫描链的基本原理与替换规则Scan DFT的核心操作是把设计中的普通D触发器替换成扫描触发器Scan Flip-Flop。这种触发器多了一个扫描输入SI端口和一个扫描使能SE端口。当SE为0时触发器工作在功能模式D端数据正常打入当SE为1时触发器忽略D端直接从SI端接收数据并且所有扫描触发器通过Q到SI的连线串成一条链。这个替换过程通常由综合工具或DFT插入工具自动完成但有几个关键点必须人工干预。第一时钟域处理不同时钟域的触发器不能混在同一条扫描链里否则移位时会出现时序违例。第二锁存器处理设计中如果存在锁存器要么用扫描使能信号旁路掉要么单独处理否则会阻断扫描链。第三三态总线测试模式下必须确保总线不会发生冲突通常需要插入额外的控制逻辑。我个人的经验是在RTL阶段就要开始规划Scan DFT。比如在顶层模块预留scan_enable、scan_mode等测试端口在时钟生成模块里加入测试时钟多路选择器。如果等到网表阶段再改工作量会成倍增加而且容易引入功能bug。2.2 扫描链数量与长度的权衡扫描链的数量不是随便定的。链数太少每条链太长移位周期数就会很大测试时间拉长链数太多又会占用额外的芯片引脚和布线资源。一个常用的估算公式是测试时间 ≈ (扫描链长度 × 向量数量) / 测试时钟频率假设设计中有10万个扫描触发器如果只做1条链长度就是10万每条向量需要10万个移位周期。如果做100条链每条长度1000移位周期直接降到1000。但100条链需要100个扫描输入/输出引脚对引脚资源紧张的设计来说不现实。实际项目中我会根据可用测试引脚数和测试时间预算来折中。通常每条链的长度控制在几千到一万个触发器之间。另外链平衡很重要如果各条链长度差异太大测试时间由最长的那条决定短链的资源就浪费了。Cadence Modus在插入扫描链时支持自动平衡但需要设置合理的链数范围。2.3 网表准备从OrCAD导出到DFT插入这里插一句关于网表的实操。很多做板级设计的同事习惯用OrCAD导出网表但芯片内部的DFT网表是另一回事。芯片网表通常是综合后的门级Verilog网表包含标准单元和宏单元。如果你拿到的网表里还有未展开的RTL模块ATPG工具是无法处理的。在跑ATPG之前必须确保网表满足以下条件所有触发器已替换为扫描触发器或已标记为扫描单元扫描链已插入并连接正确测试时钟、扫描使能、扫描模式等信号已连接到顶层端口黑盒Black Box和未建模模块已正确处理通常需要设置set_dont_touch或提供简化模型。我踩过的一个坑是网表里某个IP核没有提供DFT模型导致ATPG工具把它当成黑盒故障覆盖率直接掉了一大截。后来只能手动给这个IP加旁路逻辑或者要求IP供应商提供带扫描的版本。所以网表检查这一步绝对不能省。3. ATPG流程全解析从故障模型到测试向量的生成3.1 故障模型的选择与覆盖率目标ATPG不是盲目生成向量它需要先定义“什么是故障”。最基础的是固定故障Stuck-at Fault即假设某个节点被永久拉高或拉低。这个模型虽然简单但能覆盖大部分制造缺陷所以是必选项。进阶的还有转换延迟故障Transition Delay Fault用于检测电路中的时序问题需要至少两个向量一个初始化一个触发来激活。覆盖率目标通常由项目要求决定。消费类芯片可能要求Stuck-at覆盖率95%以上汽车电子或高可靠性领域则要求98%甚至99%以上并且还要加测Transition故障。这里有个误区覆盖率不是越高越好因为最后几个百分点的覆盖率往往需要大量向量测试成本急剧上升。我一般会先跑一遍基础ATPG看看覆盖率瓶颈在哪里再决定是否加测试点Test Point来提升。3.2 ATPG工具的核心步骤以Cadence Modus为例一个完整的ATPG流程大致分为以下几步读入网表与库文件包括标准单元库、宏单元库、IO库等。库文件里必须包含每个单元的故障模型信息否则工具无法计算。设置测试协议定义扫描链的时序包括扫描时钟、移位时钟、捕获时钟、扫描使能信号的时序关系。这一步非常关键时序设错会导致向量在仿真时失败。构建故障列表工具会根据网表自动生成所有可能的故障点但通常会先做故障折叠Fault Collapsing把等效故障合并减少计算量。运行ATPG引擎工具使用D算法、PODEM或FAN等算法为每个故障寻找激励和传播路径。这个过程是计算密集型的大型设计可能需要数小时甚至数天。生成测试向量输出向量文件通常是STIL或WGL格式包含每个周期的输入激励和期望输出。向量验证用仿真器对向量进行验证确保没有时序违例和未知态X态传播。3.3 测试协议设置中的关键参数测试协议里最容易出错的是时钟定义。Scan DFT通常需要至少两个时钟移位时钟Shift Clock和捕获时钟Capture Clock。移位时钟频率一般较低因为要保证扫描链稳定移位捕获时钟则接近功能时钟频率用于在最后一个移位周期后捕获组合逻辑的结果。在Modus中我通常这样设置# 定义移位时钟 add_clock -name shift_clk -period 100 -waveform {0 50} [get_ports scan_clk] # 定义捕获时钟 add_clock -name capture_clk -period 10 -waveform {0 5} [get_ports func_clk] # 设置扫描使能时序 set_scan_enable -name scan_en -active high -setup 2 -hold 1这里的-setup和-hold是扫描使能信号相对于时钟沿的建立和保持时间必须根据实际时序约束来设。设得太紧向量仿真会报时序违例设得太松又可能掩盖真实问题。4. Cadence Modus实战从网表到向量的完整操作记录4.1 环境准备与工具启动Modus通常集成在Cadence的Digital Design环境中可以单独启动也可以在Genus综合后直接调用。我习惯用脚本方式跑方便复现和调试。首先准备一个工作目录把网表、库文件、时序约束都放进去。启动Modus的命令很简单modus -batch -f run_atpg.tclrun_atpg.tcl就是我们的主控脚本。下面我会把关键步骤拆开讲。4.2 读入设计与库文件# 设置搜索路径 set search_path [list . ./libs ./netlist] # 读入标准单元库 read_lib -format liberty ./libs/standard_cells.lib # 读入宏单元库 read_lib -format liberty ./libs/sram.lib # 读入门级网表 read_netlist -format verilog ./netlist/top_scan.v # 设置顶层模块 set_top top这里有个细节Liberty文件里必须包含test_cell或scan_cell的定义否则Modus不认识扫描触发器。如果库文件是第三方提供的最好先确认一下DFT相关属性是否完整。4.3 构建扫描链与测试协议如果网表里已经插好了扫描链可以直接用read_scan_chain读入链定义文件。如果是手动插入的需要提供链的端口映射# 读入扫描链定义 read_scan_chain ./scan/scan_chain.def # 设置测试协议 set_test_protocol -name my_protocol { shift_clock shift_clk capture_clock capture_clk scan_enable scan_en shift_edge rising capture_edge rising }扫描链定义文件通常由DFT插入工具生成包含每条链的输入输出端口和触发器顺序。如果顺序错了向量仿真时数据会错位覆盖率直接归零。4.4 运行ATPG并生成向量# 设置故障模型 set_fault_model -stuck_at # 设置覆盖率目标 set_coverage_target -stuck_at 98 # 运行ATPG run_atpg -effort high # 输出向量 write_vectors -format stil ./vectors/top.stil # 输出覆盖率报告 report_coverage -stuck_at ./reports/coverage.rpt-effort high会让工具花更多时间寻找难测故障的激励通常能提升1-2个百分点的覆盖率但运行时间可能翻倍。如果时间紧张可以先用medium跑一版看看瓶颈在哪里。4.5 向量验证与调试生成向量后必须用仿真器验证。Modus自带仿真引擎也可以导出到VCS或Xcelium# 运行内建仿真 run_simulation -vectors ./vectors/top.stil -netlist ./netlist/top_scan.v # 检查仿真结果 report_simulation -summary如果仿真失败常见原因有时序设置错误、扫描链顺序不对、X态传播导致输出未知。我一般会先检查仿真日志里的第一个失败周期定位到具体是哪条链、哪个触发器出了问题。5. 常见问题与排查技巧实录5.1 覆盖率上不去的五大原因问题现象可能原因排查方法解决方案Stuck-at覆盖率低于90%存在大量黑盒或未建模模块检查网表是否有unresolved模块提供简化模型或加旁路逻辑覆盖率卡在95%左右难测故障集中在特定区域用report_faults -not_detected查看插入测试点或调整ATPG effort向量仿真大量失败测试协议时序错误检查时钟相位和扫描使能时序重新校准setup/hold参数扫描链移位出错链顺序与定义文件不一致对比网表连接和def文件重新生成链定义或手动修正运行时间过长故障列表太大或算法效率低检查是否做了故障折叠启用-fault_collapsing选项5.2 独家避坑技巧技巧一先跑小规模测试。在完整设计上跑ATPG之前先拿一个子模块练手确认流程和脚本没问题。我见过有人直接在全芯片上跑结果跑了8小时才发现库文件读错了白白浪费一天。技巧二保存中间状态。Modus支持save_session和restore_session。如果ATPG跑了很久中途需要调整参数可以先保存会话改完再恢复不用从头再来。技巧三关注X态传播。X态是覆盖率杀手。在ATPG之前用set_x_handling设置合理的X态处理策略比如把未初始化寄存器当作0或1处理或者用-x_analysis先分析X态来源。技巧四向量压缩。生成的向量往往有很多冗余可以用compress_vectors命令做压缩通常能减少30%-50%的向量数量直接降低测试成本。技巧五和测试工程师对齐。ATPG输出的向量最终要交给测试机台不同机台支持的格式可能不同。提前确认好是STIL、WGL还是VCD格式避免最后格式转换出问题。6. 从向量到硅片测试向量的交付与量产衔接6.1 向量格式与测试机台适配ATPG生成的向量通常以STILStandard Test Interface Language格式交付这是一种IEEE标准被大多数测试机台支持。但实际量产中测试工程师可能需要转换成特定机台的格式比如Advantest的VEC或Teradyne的ATP。转换过程中最容易丢失的是时序信息所以交付时一定要附带完整的时序定义文件。我一般会打包以下内容给测试团队STIL向量文件测试协议描述时钟、使能、时序覆盖率报告仿真通过日志扫描链定义文件6.2 量产测试中的向量优化实验室验证通过的向量到了量产阶段可能还需要优化。比如测试时间太长会影响产能这时候可以考虑向量裁剪去掉冗余向量只保留能覆盖唯一故障的最小集合并行测试如果机台支持多site测试可以同时测多颗芯片动态测试根据芯片温度、电压调整测试条件但会增加测试复杂度。我经历过一个项目初期向量数量是12万条测试时间每颗芯片要3秒。后来通过向量压缩和并行测试降到4万条测试时间降到0.8秒量产成本直接降了六成。所以ATPG不是跑完就完事向量优化是持续的过程。6.3 良率分析与反馈测试向量跑出来的结果不仅仅是“ pass/fail ”还能反哺设计。如果某类故障频繁出现说明制造工艺或设计本身有薄弱环节。比如某个模块的Transition故障特别多可能是布线延迟太大某个区域的Stuck-at故障集中可能是掩模或刻蚀问题。把这些数据反馈给设计和工艺团队才能真正形成闭环。我个人在实际操作中的体会是DFT工程师不能只盯着覆盖率数字要理解每个故障背后的物理意义。有时候覆盖率99%但漏掉了一个关键路径的故障芯片到了客户手里才出问题代价就太大了。所以ATPG的终点不是向量文件而是芯片在真实应用中的可靠性。最后再分享一个小技巧如果你用的是Cadence Modus可以开启-verbose模式它会打印每个故障的求解过程。虽然日志会很大但在调试难测故障时非常有用。我通常会把日志重定向到文件然后用grep搜索特定故障点比在工具界面里翻快得多。