做DFT这个方向，Scan Chain的插入和ATPG向量生成是绕不开的基本功。尤其是带压缩功能的扫描链，设计上多花一点心思，测试阶段就能省下大量存储空间和测试机台时间。我最近在一个MCU级设计上从零把整套流程跑了一遍，从DFT Compiler做压缩扫描链插入、生成SPF协议，到TetraMAX读网表、跑DRC、出压缩向量，中间踩了不少坑，也把很多容易忽略的细节理清楚了。这篇文章把整个流程拆开讲，包含完整的脚本、参数选择的思路、常见报错的排查方向，给正在做DFT集成或者准备接手Scan Chain任务的朋友一个可以直接照着操作的版本。
这套流程适合已经会做DC综合、但对DFT Compiler压缩模式还不太熟的人；哪怕你之前没怎么碰过DFT，只要有时序约束的基础，跟着顺序走一遍也能把流程跑通。压缩原理我会尽量用大白话解释，命令背后的"为什么"也会一并说清楚，尽量做到看完就能在工作里上手。
1. 整体设计与思路拆解
1.1 压缩Scan Chain到底解决了什么问题
先说场景。一个中等规模的SoC，内部触发器可能几十万个。如果不做DFT结构，测试只能靠功能向量，覆盖率低，开发周期还长。做Scan Chain能把所有触发器串成移位寄存器链，让测试机台通过少数端口把激励灌进去、把响应搬出来比对。但芯片规模一大，扫描链长度和数量跟着膨胀，测试数据量和测试时间呈直线上升。
测试机台是按小时计费的，存储深度是有限资源。当设计从几十万门涨到几百万门，测试成本可能相差一个数量级。压缩功能就是为这个痛点设计的。它的核心思路是：芯片内部维护几十上百条扫描链，外部只保留少量测试通道（channel），输入侧用解压缩逻辑（decompressor）把少量通道数据广播到内部所有扫描链，输出侧用压缩器（compressor）把庞大的内部响应压回少量外部通道。这就是常说的EDT结构。从用户视角看，等效于用很小的外部端口撬动内部很宽的扫描架构，测试数据量和测试时间都能大幅下降。
1.2 工具链分工：DFT Compiler负责搭结构，TetraMAX负责出向量
在整个流程里，Synopsys的两款工具各管一段。DFT Compiler（也就是综合工具DC里的DFT模块）在综合阶段帮你做三件事：第一，把普通触发器替换或者配对成带扫描功能的单元；第二，把这些扫描单元串成扫描链；第三，启用压缩模式时自动插入EDT逻辑，也就是解压缩器、压缩器和相关控制逻辑。做完之后输出两个关键产物：扫描后的网表和SPF协议文件。
SPF不是可有可无的配置说明。SPF里记录了扫描链的时钟关系、复位关系、每条扫描链的起点终点、链长、测试模式信号的状态，甚至包括时钟和复位的时序约束。TetraMAX拿到SPF以后，先根据协议重建测试时序关系，做DRC检查，然后选故障模型、生成能覆盖大部分物理故障的测试向量。简单说，DFT Compiler是搭台的，TetraMAX是唱戏的，SPF就是两者之间传递的剧本。剧本出错，戏一定唱不对。
1.3 压缩方案选型：压缩比、通道数、覆盖率怎么权衡
压缩不是白送的。外部通道数越少，测试引脚和机台资源越省，但代价也直接。第一，解压缩器和压缩器的逻辑面积会增加；第二，ATPG运行时间和向量数量可能变多；第三，可测试性约束更严，DRC阶段容易暴露出很多时钟和复位问题。
选型时建议先定一个小目标：能干净跑通、覆盖率做到99%以上，再去追求高压缩比。通道数和内部扫描链数量的比值决定了等效压缩比，比如外部4个通道、内部32条链，等效压缩比大约是8倍。中小规模设计从8:1或16:1入手比较稳妥，先保证DFT DRC干净，覆盖率达标，再考虑更大压缩比。压缩结构对时钟和复位的要求更高，所有参与压缩扫描的触发器，时钟树必须可控、复位必须可控，否则EDT逻辑在ATPG时特别容易失控，表面现象就是DRC乱报、覆盖率上不去。
2. 核心细节解析与实操要点
2.1 端口定义：ScanClock、ScanEnable、TestMode一个都不能少
在写DFT配置脚本之前，脑子里要先有一张端口清单。Scan Clock是扫描时钟，负责移位和捕获；Scan Enable是扫描使能，区分移位阶段和捕获阶段；Test Mode用来把设计切到测试模式，隔离功能时钟和复位路径；必要时还要声明Reset，让ATPG知道哪些复位是可控制的。
很多初次跑DFT的人容易漏掉Test Mode声明。没有Test Mode，工具会把功能逻辑里的各种端口都当测试路径来分析，DRC会报出一堆时钟和复位冲突，排查起来非常痛苦。所以我习惯先写一份端口声明清单，对照RTL端口逐个确认，再开始写DFT配置。
以我常用的方式为例：
set_dft_signal -view existing_port -port clk -type ScanClock -active_state 1 set_dft_signal -view existing_port -port resetn -type Reset -active_state 0 set_dft_signal -view existing_port -port test_mode -type TestMode -active_state 1 set_dft_signal -view existing_port -port scan_enable -type ScanEnable -active_state 1-active_state指定了信号的有效电平，必须和RTL一致。resetn是低有效，所以写成0；test_mode和scan_enable都是高有效，写成1。声明错了，后续ATPG出来的时序全是错的，仿真一跑就挂。
2.2 压缩模式配置：从普通Scan到EDT只有一步
普通Scan Chain通常把外部扫描端口声明成ScanDataIn和ScanDataOut。打开压缩功能后，DFT Compiler会引入EDT结构，外部端口需要按压缩通道来声明。我这里启用压缩的核心配置是：
set_dft_configuration -scan_compression enable set_dft_signal -view spec -port scan_in -type CompressedDataIn set_dft_signal -view spec -port scan_out -type CompressedDataOut set_scan_compression_configuration -channel_width 4 set_scan_configuration -chain_count 32 -clock_mixing mix_clocks这里有几个值得细看的点。-channel_width 4定义了外部压缩通道数，也就是芯片上用于测试数据进出的一组端口；-chain_count 32定义了内部扫描链数量。外部4个通道、内部32条链，等效压缩比就是8倍。-clock_mixing mix_clocks允许不同时钟域的触发器混在一条链上，能提高扫描链利用率，但对后端时钟树和DFT DRC要求更高。如果设计里时钟域很复杂，前期可以先保守一点，用一个时钟域一条链的方式先跑通。
不同版本的DC对压缩命令的命名细节略有差异，跑之前先查一下help set_scan_compression_configuration确认参数名，这一步能省很多查报错的时间。
2.3 dft_drc检查到底在看什么
配置写完、create_test_protocol生成协议后，第一道关卡是dft_drc。不要急着insert_dft，DRC没过就去插链，后面改起来成本极高。
dft_drc主要检查三类内容。第一，时钟的可控性，每个触发器在移位和捕获模式下能不能被扫描时钟正确驱动，时钟门控、分频时钟、多时钟域都可能造成不满足。第二，复位的可控性，异步复位在测试模式下能不能被测试机台控制，如果复位不受控，扫描移位时触发器状态全乱。第三，扫描结构的准备情况，比如有没有不适合插入扫描的单元、是否存在锁存器或者三态总线问题。
实际跑的过程中，DRC报错不是只看摘要，要打开完整报告看每一条违反规则的信息，定位到具体的时钟网络、复位网络和单元实例。很多时候一个时钟门控单元导致几十个触发器报错，修掉一个源头，一批报错就消失了。
2.4 TetraMAX里的故障模型与向量生成设置
TetraMAX进入ATPG阶段之前，要先理解故障模型。用得最多的是stuck-at模型，也就是固定故障模型，假设某个节点永久固定为0或固定为1。现在很多设计还会追加transition模型，覆盖跳变延时故障，但首先把stuck-at跑干净比较现实。
向量生成阶段的关键参数是run_atpg -auto_compression。这个选项会让工具在尽量保证故障覆盖率的前提下压缩向量数量，减少测试时间。跑完以后用report_faults -summary看故障覆盖率，用write_patterns导出测试向量。这里的压缩和RTL里的scan压缩是两回事，一个是ATPG层面的向量压缩，一个是结构层面的EDT压缩，两者叠加才是完整的测试成本优化。
3. 实操过程与核心环节实现
3.1 准备阶段：RTL端口在规划期就要想清楚
在写DC脚本之前，RTL里最好已经有完整的DFT端口规划。我的习惯是在模块顶层预留一组测试端口：test_mode、scan_enable、scan_in、scan_out，必要时加上scan_clk。不要等综合阶段再发明端口，那样要么改RTL重跑综合，要么在DC里硬加端口，反而容易出错。
RTL里还需要注意几点。第一，test_mode信号要参与时钟和复位的逻辑，比如测试模式下拉掉功能复位、旁路掉门控时钟，这些工作放在RTL或者综合约束里做都可以，但要保证DFT阶段可控。第二，内部三态总线尽量在测试模式下固定，否则DRC会报三态冲突。第三，跨时钟域路径在测试模式下最好处于稳定状态，否则ATPG阶段会产生意想不到的不确定值。
3.2 DC完整脚本：从读RTL到insert_dft一气呵成
这里给一份我实际跑过的精简版脚本框架，关键参数已经做了脱敏和简化处理，但结构可以直接复用：
set target_library "fun_core.db io_hv.db" set link_library "* $target_library" set design_name "core_top" set RTL_FILES "/proj/rtl/core_top.v /proj/rtl/axi_lite.v /proj/rtl/uart.v" set CLK_PERIOD 2.0 read_file -format verilog $RTL_FILES current_design $design_name link # 功能时钟约束 create_clock -period $CLK_PERIOD -name clk [get_ports clk] set_clock_uncertainty 0.2 [get_clocks clk] set_dont_touch [get_ports resetn] true # DFT信号声明 set_dft_signal -view existing_port -port clk -type ScanClock -active_state 1 set_dft_signal -view existing_port -port resetn -type Reset -active_state 0 set_dft_signal -view existing_port -port test_mode -type TestMode -active_state 1 set_dft_signal -view existing_port -port scan_enable -type ScanEnable -active_state 1 set_dft_signal -view existing_port -port scan_in -type ScanDataIn set_dft_signal -view existing_port -port scan_out -type ScanDataOut # 压缩模式配置 set_dft_configuration -scan_compression enable set_dft_signal -view spec -port scan_in -type CompressedDataIn set_dft_signal -view spec -port scan_out -type CompressedDataOut set_scan_compression_configuration -channel_width 4 set_scan_configuration -chain_count 32 -clock_mixing mix_clocks # 测试协议与插入扫描链 create_test_protocol dft_drc insert_dft # 输出 write_test_protocol -output core_top.spf write -f verilog -hierarchy -output core_top_scan.v注意一个细节：我在普通Scan声明里先写了ScanDataIn/ScanDataOut，压缩开启后又用CompressedDataIn/CompressedDataOut重新声明了同一个端口。这么做在DC里是允许的，后面的声明会覆盖前面的类型，最终以压缩通道方式处理。如果你一开始就确定用压缩，直接只写压缩类型更清爽。
3.3 SPF协议和扫描网表的检查
脚本跑完以后，先别急着开TetraMAX，先检查两个产物。第一，打开 core_top_scan.v 看顶层端口，扫描端口是否存在、方向是否正确，EDT逻辑有没有被例化进去。第二，打开 core_top.spf，重点看信号定义段，确认test_mode、scan_enable、scan_clk和channel的对应关系。
SPF里一眼能看出的问题通常有两类。一类是端口缺失，比如scan_in在SPF里找不到对应端口，多半是端口类型声明没生效。另一类是时钟关系混乱，比如多个扫描时钟的相位关系写错，这时候要往回检查create_test_protocol之前有没有把功能时钟声明完整。SPF本身不用手改，有问题一定要回到DC脚本重新生成。
3.4 TetraMAX完整脚本：读网表、跑DRC、出向量
TetraMAX这一侧流程比较固定，我习惯的脚本如下：
read_netlist core_top_scan.v run_build_model core_top run_drc core_top.spf set_faults -model stuck_at add_faults -all run_atpg -auto_compression report_faults -summary report_coverage write_patterns core_top_pattern.v -format verilog -replacerun_build_model的顶层名要和current_design一致，否则TetraMAX会找不到模型。run_drc读入SPF后，工具会重建测试时序，这一步会提示存在多少条扫描链、多少个通道，如果这里显示的通道数和设计预期不一致，大概率是DC侧压缩配置没生效。
跑完以后，重点看report_faults -summary里的覆盖率数字和未检测故障数量。如果覆盖率离预期差太远，不要直接加向量，先回到DRC阶段看是否存在大量未检测故障，再一层层找原因。
3.5 向量仿真验证：最后一道保险
TetraMAX生成的向量不是直接上机的，还需要在仿真环境里跑一遍。最常用的办法是把生成的verilog格式pattern和扫描网表一起放到VCS里仿真。TetraMAX可以额外生成testbench，文件里包含测试激励和期望响应，仿真通过后基本可以确定向量可用。
我一般会做两层验证。第一层是快速仿真，只跑前几条pattern，确认scan链能正常移位、捕获能产生预期响应。第二层是完整仿真，跑全部pattern，这一步耗时较长，但能发现继电器、三态总线和跨时钟域路径在真实时序下才暴露的问题。第一次做压缩流程时，完整仿真很容易挂，原因多半是复位声明不对或者时钟关系没约束完整，位置往往能往前推到DC的DFT配置，而不在TetraMAX本身。
4. 常见问题与排查技巧实录
4.1 DFT DRC阶段的高频报错
把实际项目中遇到比较多的DFT DRC问题整理成了下面这张表，排查方向比错误码本身更重要。
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 时钟不可控报错一大片 | 门控时钟没绕过，或者ScanClock声明缺失 | 检查时钟网络中的ICG单元，在测试模式下强制旁路；确认DFT信号里声明了扫描时钟 |
| 复位不可控 | 异步复位网络没有在测试模式下固定 | 用test_mode控制复位输入，或者在DFT配置里声明Reset信号的可控性 |
| 扫描链不完整 | 部分触发器被优化掉，或者被排除在扫描单元之外 | 查看综合后的单元类型，检查是否有dont_touch或size_only导致扫描单元替换失败 |
| 三态总线冲突 | 测试模式下多个驱动使能同时有效 | 在DFT配置或RTL测试模式逻辑中固定三态控制信号 |
| 锁存器报错 | 设计里存在未受控锁存器 | 确认锁存器是否必要，必要时在配置中声明为不可扫描或加测试旁路 |
我遇到过最典型的一个项目，DFT DRC报告几百条时钟错误，根因是一个ICG单元挂在某个功能时钟门上，测试模式下时钟门没有被旁路。在DFT配置里把这条路径的测试时钟强制绕过之后，报错数量从几百条降到零。所以大批量报错出现时，先找公共根源，比一条条看有效得多。
4.2 TetraMAX DRC与ATPG阶段报错
TetraMAX侧的问题更多集中在协议和时序上。比较常见的是扫描链长度和SPF描述不一致，或者某些扫描单元在网表里找不到对应连接。遇到这类问题，先重新生成SPF和网表，确认两者来自同一次insert_dft，不要混用不同版本的产物。
另一个高频坑是shift阶段保持时间违例。TetraMAX的DRC会在移位阶段检查时钟关系，如果SPF里扫描时钟的相位关系不对，或者时钟树偏差过大，会报出移位时序问题。这时候不用急着改TetraMAX配置，先回到DC检查扫描时钟是否经过门控、是否有多余的延迟单元，再从源头修。
ATPG阶段如果出现向量数量异常多或者覆盖率停止增长，可以试一下run_atpg -auto_compression -capture_cycles 2这类参数调整，或者给工具加大-abort_limit。不过这类调参属于锦上添花，前提是DRC必须干净。
4.3 压缩模式特有的坑：覆盖率低、通道数不对、EDT逻辑异常
开启压缩以后，问题往往比普通Scan Chain更隐蔽。最典型的是覆盖率突然掉下来。我曾经遇到一个设计，普通Scan模式下覆盖率能做到99%，打开压缩后掉到90%以下。排查下来发现是解压缩器本身引入了额外逻辑，部分内部节点无法被ATPG有效激励，导致故障检测率下降。这种情况要看具体报出的未检测故障集中在哪些逻辑，如果是EDT控制器周边，可以尝试调整-channel_width，给ATPG更多控制自由度。
通道数不对也很常见。DC端配了4个通道，TetraMAX里却只识别出1个，多半是端口类型声明没有完全覆盖，或者-view spec的spec端口和已有端口冲突。检查方法很简单：看网表里scan_in到底是直接连到扫描链还是先经过解压缩器，如果直接连到扫描链，说明压缩配置没生效。
EDT逻辑本身异常的情况也有。比如解压缩器里的某个寄存器没被正确复位，导致ATPG时内部状态不可预测，DRC阶段就会报出一连串与EDT相关的错误。解决方向是确保EDT逻辑的复位信号和主复位在测试模式下都可控，必要时在配置里单独指定EDT复位通道。
4.4 排查问题的一条实用路线
踩了这么多坑，我总结出一条比较高效的排查路线：先确认SPF和网表来自同一次insert_dft，再确认DFT信号声明和RTL端口一一对应，然后看DRC报告的公共根源，最后才动ATPG参数。顺序不能反，很多人在TetraMAX里反复调参，最后发现是DC侧端口类型写错了。
如果DRC报错实在看不明白，可以查工具生成的violation report，里面会列出具体违反的规则名和实例路径。结合log里的错误编号去查命令行参考手册，比对着英文报错猜要快得多。另外，项目的DFT log文件建议保留整个流程的完整输出，尤其是dft_drc和insert_dft之间的每一段提示，很多问题翻log就能定位。
最后再分享一个我的个人习惯：第一次做压缩流程时，先用最小模块跑通，不要一上来就怼整个SoC。最小模块跑通后，再逐级加复杂度，这样每次遇到问题都能快速锁定引入源头。等完整流程走通、覆盖率达标、仿真验证通过，再铺开到全芯片，整个过程的心理压力会小很多。
