企业官网建设流程全解析

1. 为什么Scan Chain要“压缩”：一张测试时间账本算明白

芯片规模走到几百万门甚至上亿门之后，DFT（Design for Test）里最先被挑战的不是覆盖率，而是测试时间。我之前遇到一个项目，图形处理器的主核逻辑有将近两百万个触发器，按常规方案插成每条链1000个触发器的Scan Chain，频率跑50MHz，光迁移和捕获就得烧掉大把机台时间。原因一句话就能讲透：ATPG生成的每一个Pattern都要把所有测试向量串行灌进触发器，链越长、链数越少，单次移入的时间就越长，pattern数量一大，测试时间直接爆炸。

测试时间的粗略公式是这样算的：

T ≈ (L_max + 2) × P × T_clk

其中L_max是物理上最长的那条Scan Chain上触发器个数，P是ATPG生成的Pattern数量，T_clk是测试时钟周期。注意，这里和链数量基本无关，直接把链加多并不会线性缩短时间，因为每条链是并行的，但一条链的长度决定了每次移位的深度。所以你真正能压的是“最长链的深度”，而要同时保证测试质量，不能靠粗暴减少触发器数量。

压缩技术的思路就是在这里介入。它不是去掉触发器，而是在Scan Chain的“装入”和“观测”端加入压缩/解压逻辑，让芯片内部的实际扫描链可以切成大量短链，而外部测试引脚只保留少量通道。ATE在同样的测试时间内可以灌入更多数据，内部一次性移入/移出的有效数据量大幅提升。用行业里更常见的说法，Synopsys的解决方案叫EDT（Embedded Deterministic Test），也就是TetraMAX配合DFT Compiler来实现的那套压缩结构。

实测下来，典型压缩比为50:1到200:1不是吹的。同样两百万触发器的设计，普通Scan Chain需要三四百万个Pattern，压缩之后能压到几万个；单条物理链长度从1000缩到50，测试时间可以缩掉一到两个数量级。这也是为什么现在车规、AI芯片等大规模芯片基本都会上压缩，不是选项，而是刚需。

这篇文章我就完整走一遍从DFT Compiler插入带压缩的Scan Chain，再到TetraMAX生成测试向量并验证覆盖率的工作流。涉及的命令、配置项和报错都是我在真实项目里实际碰到的，照着做能少踩不少坑。

2. 第一步先对齐工具链：库文件与设计约束里的几个隐形雷

2.1 ATPG库和DFT库为什么要分家

DFT Compiler做综合和扫描链插入时，用的是综合库（一般叫target_library），但到了TetraMAX这一侧，跑DRC和生成Pattern时还需要一套专门的ATPG库。很多初次上手的人会在这一步直接卡住：网表综合过了，insert_dft也没报错，结果TetraMAX一跑run_drc就刷出一堆warning，甚至直接fail。

原因在于gedf库或者FastScan库的模型和综合库不一致，尤其对于锁存器、三态门、特殊IO单元，ATPG库必须对它们的测试行为建模。综合库可以只关心时序面积功能，而测试库必须要知道这个单元在测试模式下怎么控制、怎么观测。

所以第一步检查自己的库环境：

set TARGET_LIBRARY_FILES "/path/to/typical_core_tt1p2v25c.db" set ADDITIONAL_ATPG_LIBRARY_FILES "/path/to/atpg_core_lib.db"

DFT Compiler对这两个库是分开读的。有些工艺厂的库直接提供atpg模型，有些得自己在Library Compiler里重新compile，确保TetraMAX能认到。建议在写网表之前就确认你的综合环境能够加载ATPG库，否则后面跑TetraMAX DRV必然报“cell model not found”。

2.2 压缩逻辑需要的特殊库单元

带压缩的DFT设计里，库中必须有EDT相关的硬件单元——Channel In/Out逻辑、Decompressor、Compactor，以及负责片上Pattern生成的控制器。这些在Synopsys的方案里叫edt库单元。少数情况下工艺库里没有，需要从IP供应商那边单独拿。

没有这些单元，DFT Compiler在insert_dft时会提示缺少edt_clock、edt_update等pin定义，或者直接找不到edt库文件。这个时候你需要在set_dft_configuration里显式指定：

set_dft_configuration -edt_configuration ...

如果库本身缺失，这个命令会直接告诉你EDT不可用。检查库文件路径，确认包含了edt相关的db文件，是排这个错的第一步。

2.3 约束文件里最容易被忽略的两个点

第一个是复位信号的处理。Scan链有压缩逻辑之后，测试模式的复位时序和功能模式不一定一致。DFT Compiler做DRC时会检查复位信号在移位过程中是否有效，如果复位一直拉着，链上的数据根本移不进去。所以测试模式下的复位信号必须能被DFT控制信号屏蔽掉，比较常见的做法是加测试复位控制（Test Reset）逻辑，或者让复位信号在Shift阶段无效化。

第二个是时钟域。压缩逻辑本身会引入一个新的时钟关系，EDT控制器的时钟来自edt_clock，和功能时钟之间需要明确约束。如果设计里有多个时钟域，就必须在DFT约束中定义好每个时钟的测试关系，否则插入后DRC会报Clock domain crossing相关问题。

经验是：在综合前就把set_dft_signal定义全，宁可多写几条，不要漏：

set_dft_signal -view existing_dft -type ScanClock -port [list clk1 clk2] -timing [list 45 55] set_dft_signal -view existing_dft -type ScanEnable -port scan_enable -active_state 1 set_dft_signal -view existing_dft -type Reset -port test_rst_n -active_state 0

这些设置看起来基础，但很多压缩配置失败最终都能溯源到时钟和复位定义不完整。

3. DFT Compiler里的压缩链配置：从dft_drc到insert_dft的完整操作

3.1 先跑不带压缩的DRC

很多工程师习惯直接写带压缩的约束然后一路insert_dft，结果报错一堆，不知道是压缩配置的问题还是设计本身的问题。这里我强烈建议：先把不带压缩的Scan Chain配置跑通DRC，再往上叠加压缩配置。分步排错能省很多时间。

不带压缩的配置参考：

set_scan_configuration -chain_count 20 -clock_mixing mix_clocks set_dft_configuration -fix_clock_enable true -fix_reset enable dft_drc

这一步通过之后，才能确认设计本身在扫描移位、时钟可控性、触发器捕获行为上是没问题的。如果这里就报MUX-4之类的DRC Violation，先解决掉再往下走。

3.2 压缩配置核心参数说明

带压缩时，需要在原本的Scan配置之上增加EDT的配置。最核心的几条命令：

set_scan_configuration -chain_count 100 -edt_channels 8 set_dft_configuration -edt_configuration -edt_clock_gating true dft_drc

这里有两个概念要分开理解：chain_count是插入多少条内部物理扫描链；edt_channels是提供多少条外部测试通道。两者相除得到压缩比。比如100条链、8个通道，理论压缩比是12.5:1。注意压缩比不要盲目拉高，通道太少，Decompressor的编码能力会受限，ATPG折叠率下降，最终pattern数量反而可能变大。

实测中比较稳妥的配比是让每条内部链的长度控制在50~100个触发器之间，通道数和ATE可用通道数匹配。如果ATE只能给8根测试引脚，那你设20个通道也没用，综合工具会自动做MUX复用或直接报引脚冲突。

配置完后，还要确认几个EDT专属设置：

set_edt_configuration -number_of_channels 8 -edt_clock_domain mixed set_edt_configuration -scan_segments 4

scan_segments是指每条物理链被分成的段数量，这个和Fault诊断的精度有关。段越多，诊断切分越细，但硬件开销也越大。一般不用刻意追求大数，4~8段足够应对大多数设计。

3.3 insert_dft后的自查清单

DFT Compiler插入完成后，先别急着写网表。在写netlist之前，在DC里按这个顺序自查：

• 看dft_drc的DRC Summary，确认无violation类别是Fatal的错误。
• 用report_scan_path查看链信息，确认chain_count和每段链长度落在预期范围。
• 用report_edt_channels查看EDT通道信息和Decompressor/Compactor是否成功例化。
• 检查scan_enable和edt_update这两个信号门控是否已插入，这是最常见的遗漏项。

这中间最常出现的情况是Drc全过，但report_scan_path发现链的数量和chain_count不一致。基本是set_scan_configuration的顺序在set_dft_signal之前执行，配置被后面的默认值覆盖了。TC脚本顺序不是小事，综合脚本的执行顺序直接影响最终DFT结构。

网表输出命令：

write -format verilog -hierarchy -output output/top_dft.v write_test_model -format verilog -output output/top_dft_test_model.v

注意write_test_model这一步很重要，TetraMAX读的是test model，不是直接读功能网表（虽然也能读，但test model能自动识别扫描链结构，省掉大量重复配置）。

4. TetraMAX侧该干什么：SSN模型配置与覆盖率验证

4.1 从Netlist到ATPG的初始化流程

TetraMAX的工作流核心是把DFT Compiler产出的设计模型转换成ATPG可用的格式并生成Pattern。初始化命令如下：

set_context dft -f top_dft_test_model.v read_netlist top_dft_test_model.v run_build_model top_dft_test_model add_clocks 0 clk1 -shift 10 -capture 20 add_clocks 0 clk2 -shift 10 -capture 20 add_clocks 0 edt_update_clock -shift 10 run_drc

这里add_clocks里的-shift和-capture定义的是测试时钟的沿位置，TetraMAX靠这个来理解扫描移位和捕获时序。如果和DC里timing设置不一致，会在ATPG阶段出现时序违反或捕获不到数据的状态。

run_drc这一步极其关键，TetraMAX会基于test model重新确认扫描链、EDT连接和DRC规则。它和DC里的dft_drc不是一回事，侧重点不同，DC侧重结构正确性，TetraMAX侧重ATPG能在该结构上产生合法测试向量。

4.2 压缩模式下的SSN模型

对于带EDT压缩的设计，TetraMAX需要额外读取一个模型来描述压缩逻辑——SSN（Scan Synthesis Netlist）模型。这个模型通常在DFT Compiler综合时通过以下方式输出：

write_edt_ssn_model -format verilog -output output/top_edt_ssn.v

在TetraMAX里这样加载：

set_build -model ssn read_netlist top_edt_ssn.v run_build_model top_edt_ssn

这里有个常见误区：认为test model里已经包含EDT了，不需要单独加载SSN。实际不是，test model描述的是扫描链和芯片逻辑的连接关系，而SSN描述的是Decompressor/Compactor内部结构。只有两者配合，TetraMAX才能正确进行Pattern扩展和合并。

加载完成后再执行：

set_pattern -compression on set_dofile atpg_settings.dofile run_atpg -auto -coverage

set_pattern -compression on是开启ATPG层面的Pattern压缩，和DFT结构层面的EDT压缩是两码事，但很多人会混淆。结构压缩减少的是移入时间，ATPG压缩减少的是Pattern数量，两者可以叠加，也是最终测试时间和测试数据量双降的关键。

4.3 覆盖率不是越高越好：合理目标的判断

跑完ATPG后看coverage summary，通常会有一个理想数据：fault coverage和test coverage。记住一点，压缩模式下100%覆盖率很少能达到，这和未压缩模式不同，因为Compactor在压缩观测响应时存在一定的X态屏蔽和混淆效应。

我一般会在项目早期定一个覆盖率基线：核心逻辑98%以上，全局90%以上可接受。如果低于这个，不要急着加pattern，先检查是不是X态传播问题——未初始化的存储单元、黑盒RAM的输出、跨时钟域的路径，都会成为X源，直接被Compactor放大成覆盖率下降。

用这条命令查X态来源：

report_xprop -detail

TetraMAX会列出所有传播X的路径，逐个看是合理的设计问题还是DFT约束遗漏。最常见的是Black Box没有加约束，RAM输出直接透传到扫描链上。解决方式是在DFT Compiler阶段对RAM输出加遮罩，或者TetraMAX里用add_black_box配合X态屏蔽。

5. 那些年我踩过的报错：从DRC Fatal到EDT Chaos全排查链路

5.1 DFT Compiler阶段：DRC报错对照表

DFT Compiler的DRC信息量很大，但真正需要第一时间处理的是Fatal级别的错误。下表是我实际项目里高频出现的几类，每条后面附解决方向：

注意，这些报错在未压缩模式下不出现，加上压缩之后一下子蹦出来，多半是压缩逻辑需要更严格的扫描端口可控制性，设计里原有的测试MUX在这一层被暴露了。

5.2 TetraMAX阶段：EDT通道错乱的排查实例

有一次我在TetraMAX里跑run_drc，看到一组奇怪的报错，大意是EDT channel_data线连接出现fanout到多个Decompressor输入。这种错如果设计本身是DFT Compiler插的，理论上不该出现，但我的情况是手改过网表。

排查步骤：

1. 先在TetraMAX里执行report_edt查看EDT信号连接关系，确认每个channel连接到的Decompressor引脚。
2. 再回到DC里检查是否在插入后有ECO（Engineering Change Order）操作，ECO经常破坏EDT布线。
3. 确认无ECO后，定位到网表中具体的channel信号名，沿着net查fanout，看是否被复用。

最终查出来是我的脚本里对edt_update信号做了一处clock gating改动，导致EDT控制时序错位。这个错在DC的DRC阶段不会爆，因为结构是合法的，但到了TetraMAX内部连线分析时就被抓出来了。

这类问题没有捷径，唯一的排查方法论是：保持DFT网表和最终交付网表之间可追溯。最好在综合目录里保留每一版网表的历史记录，出事才能快速diff。我后来养成的习惯就是在insert_dft后立刻跑一次TetraMAX的run_drc，哪怕只加载test model，也能提前发现绝大部分结构问题，而不用等到全流程结束后再回头查。

5.3 X态导致的覆盖率失真排查

再记录一个高频问题：ATPG报告覆盖率明明很高（比如99%），但TetraMAX在生成Pattern时报告大量X states，最终拿到ATE上跑的pattern数量却远超预期。根源通常是EDT Compactor的X态抑制能力有限，X源越多，需要额外插入的固定向量越多。

排查链路：

• report_patterns -summary查看每个Pattern包含的固定位数量。
• report_xprop查看X态传播路径。
• 如果X来自未初始化的RAM，考虑给RAM加BIST或输出遮罩。
• 如果X来自跨时钟域路径，考虑在测试模式关闭相关路径，或加测试专用同步器。

这类问题的难点在于它不会让流程直接失败，而是悄悄拉低测试效率。我见过有项目因为X态问题导致Pattern数量膨胀30%以上，测试时间多烧了几百秒，这在量产成本里是很刺眼的数字。

5.4 Lockup Latch缺失：压缩模式下的特定问题

最后提一个压缩设计特有的Lockup Latch问题。压缩模式下内部链很短，时钟偏斜的影响会被放大，因为链两端直接连到Decompressor和Compactor的时钟树分叉点，偏斜补偿依赖却常常被疏漏。

DFT Compiler在插入压缩逻辑后一般会自动插Lockup Latch，但它默认只处理同一个时钟域的相邻链，跨时钟域混合链的情形需要你手动确认。配置：

set_scan_configuration -lockup_type latch

如果报错显示Lockup violation across clock domains，不要直接按字面意思去删链，要先确认是否真的需要混合时钟链。能分开尽量分开，混合链每多一条，ATPG生成和时序收敛的复杂度都会上升，这也是压缩设计中性能优化的一个隐形方向。

6. 关于“反馈环”的个人经验：压缩结构的仿真验证技巧

环境配置、命令、报错都搞清楚了，还有一个容易被跳过的环节是仿真验证。很多工程师在TetraMAX出了Pattern之后就以为万事大吉，但压缩结构的验证比普通Scan Chain多一层风险——如果Decompressor约束留了缝隙，芯片内部Pattern会自相矛盾，造成捕获数据完全无效。

我会在TetraMAX生成Pattern之后，把最终Pattern落到仿真级做一轮验证：

write_patterns output/top_pattern.wgl -format wgl -replace_singles -compress

再配合test bench模拟Shift、Capture过程，重点检查：

• 移位阶段所有scan_enable的时序是否满足。
• EDT的update信号上升沿能否在capture窗口前稳定。
• Compactor输出端的响应能否完全和TetraMAX仿真的预期值对上。

这一步如果等流片后才去发现，直接就是一次base metal的教训。压缩技术确实能帮芯片厂把测试成本打下来，但代价是设计验证链多出不少环节。每多一环，都需要你像拼积木一样确认严丝合缝。

从DFT Compiler到TetraMAX这条流程，压缩配置只是其中一段。完整跑通之后你会发现，真正考验人的不是命令本身，而是库、约束、结构、时序、仿真这些模块之间的耦合。一次跑通是运气，能稳定复现才是能力。希望上面这些经验能帮你少走点弯路。