做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是低有效所以写成0test_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_dftDRC没过就去插链后面改起来成本极高。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。最小模块跑通后再逐级加复杂度这样每次遇到问题都能快速锁定引入源头。等完整流程走通、覆盖率达标、仿真验证通过再铺开到全芯片整个过程的心理压力会小很多。
DFT压缩扫描链插入与ATPG向量生成全流程详解
做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是低有效所以写成0test_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_dftDRC没过就去插链后面改起来成本极高。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。最小模块跑通后再逐级加复杂度这样每次遇到问题都能快速锁定引入源头。等完整流程走通、覆盖率达标、仿真验证通过再铺开到全芯片整个过程的心理压力会小很多。