1. 为什么IC设计新人一上来就卡在Scan链上——从“能仿真”到“能测试”的认知断层刚做完第一个RTL模块波形跑得漂亮时序收敛了综合报告绿油油的你兴冲冲地把代码交给后端同事结果对方回了一句“DFT没加没法做量产测试先回去加Scan链吧。”——那一刻你可能连Scan链长什么样都没见过。这不是个例。我带过的二十多个应届IC设计工程师里超过80%在入职前三个月都经历过这个“顿挫时刻”他们能熟练写Verilog、会用VCS跑UVM验证、甚至能调通简单的FPGA原型但一提到Tessent、ATPG、Scan Insertion眼神立刻飘忽下意识打开浏览器搜“tessent安装包”或“rtl中assign的作用”仿佛这是另一个星球的语言。问题出在哪根本不在工具本身而在于教学与工业实践之间的巨大鸿沟。大学课程讲组合逻辑、时序分析、状态机但几乎不提“芯片出厂后怎么确保它没在运输途中被静电打坏”开源EDA教程教你怎么用Yosys综合却没人告诉你综合后的网表必须预留Test Access PortTAP引脚你写的assign a b c;在功能上完全正确但它在DFT视角下是“不可控、不可观测”的黑洞——因为b和c的驱动源如果没被Scan链捕获ATPG生成的测试向量就永远无法驱动它们到特定值也无法观测a的输出是否异常。这就是DFTDesign for Testability存在的底层逻辑它不是给芯片“加功能”而是给芯片“加耳朵和嘴巴”。Scan链就是那条贯穿整个芯片的“神经通路”让测试工程师能在芯片封装完成、焊接到PCB之前像医生用听诊器一样逐级注入激励、捕获响应精准定位到某一个晶体管级的短路或开路故障。没有它一颗价值百万的SoC流片回来可能只因某个IO pad上的ESD保护二极管轻微漏电就整颗报废而你连故障点在哪都不知道。所以这篇指南不叫“Tessent操作手册”而叫“给IC设计新人的入门指南”。它不假设你会用Tcl写脚本也不要求你背熟IEEE 1149.1标准而是从你最熟悉的RTL环境出发手把手带你走完一条真实流片项目中必经的路径从你写的那一行always (posedge clk) q d;开始到最终生成一份能烧进ATEAutomatic Test Equipment机台的STIL测试向量文件结束。过程中你会明白为什么assign语句要慎用、为什么reset信号必须同步化、为什么scan_enable不能直接连到内部寄存器的load端——这些不是教条而是血泪教训换来的工程直觉。提示本文所有操作步骤均基于Tessent 2022.03版本当前主流流片厂标配命令和流程与2021.09、2023.06高度兼容。Ubuntu 20.04/22.04系统可直接复现无需额外配置环境变量——这点和网上搜到的“tessent安装包”教程有本质区别工业级DFT工具从不提供单机版安装包它必须集成在完整的Cadence/Synopsys数字前端流程中这也是新人最容易踩的第一个坑。2. RTL阶段就该埋下的三颗“DFT种子”——那些综合前必须确认的设计规范很多新人以为DFT是综合之后才开始的工作等Synopsys DC吐出网表再丢给Tessent去“自动插入Scan链”。结果往往是Tessent报错退出提示“uncontrollable logic”或“unobservable point”然后你盯着几百行报错日志发呆最后不得不回溯修改RTL。这不仅浪费三天时间更可能打乱整个项目schedule。真相是Scan链能否成功插入70%的成败取决于RTL编码阶段。就像盖楼前的地基勘探你不能指望施工队在混凝土浇筑后才发现地下有溶洞。以下是我在三个28nm IoT芯片项目中总结出的、必须在RTL交付前由设计负责人签字确认的三项铁律2.1 所有寄存器必须具备“双模”能力功能模式 Scan模式这是Scan链的物理基础。一个标准的Scan触发器Scan Flip-Flop, SFF内部结构如下图所示文字描述--------------------- | MUX (2:1) | | sel: scan_enable | | i0: d (functional) | | i1: si (scan_in) | | o: internal_q | ------------------ | ----------v-------- | D-Flip-Flop | | clk: clock | | rst: async_reset? | | q: internal_q | ------------------ | ----------v-------- | MUX (2:1) | | sel: scan_enable | | i0: q (functional) | | i1: internal_q | | o: so (scan_out) | ---------------------关键点在于scan_enable信号必须能无条件控制MUX的选择。这意味着禁止将scan_enable与其他信号做逻辑运算后再驱动MUX。例如以下代码是灾难性的// ❌ 危险Tessent无法识别此逻辑为标准SFF assign se_ctrl scan_enable (mode 2b10); always (posedge clk or negedge rst_n) begin if (!rst_n) q 1b0; else if (se_ctrl) q si; // 这里se_ctrl不是原始scan_enable else q d; endTessent的Insertion引擎只会匹配if (scan_enable)或assign se scan_enable;这类直连模式。一旦中间插入任何逻辑它就会放弃对该寄存器的Scan改造将其标记为“black box”导致后续ATPG覆盖率暴跌。必须为每个寄存器显式声明scan_enable输入端口。即使你的模块顶层没有scan_enable信号也必须在模块接口中预留并在实例化时接1b0功能模式下禁用。这是为了保证层次化DFT的可扩展性。我曾遇到一个项目因为顶层忘了加scan_enable端口导致子模块的Scan链无法向上汇聚最后不得不推翻重做整个顶层连接。2.2 异步复位必须“同步化释放”且复位值需可配置异步复位rst_n是RTL中最常见的“DFT杀手”。原因很简单当scan_enable1时Scan链进入移位模式此时若rst_n突然变低整个Scan链的状态会被强制清零导致正在移入的测试向量丢失ATPG生成的向量全部失效。解决方案是“同步复位释放”Synchronous Release of Asynchronous Reset// ✅ 推荐两级同步器 可配置复位值 module sync_rst #( parameter RST_VAL 1b1 ) ( input logic clk, input logic rst_n_async, output logic rst_n_sync ); logic rst_sync_1, rst_sync_2; // 异步复位采样 always (posedge clk or negedge rst_n_async) begin if (!rst_n_async) begin rst_sync_1 1b0; rst_sync_2 1b0; end else begin rst_sync_1 1b1; rst_sync_2 rst_sync_1; end end assign rst_n_sync rst_sync_2; endmodule更重要的是复位值必须可配置。ATPG需要在不同测试阶段设置不同的初始状态。例如在“Stuck-at-0”测试中你希望所有寄存器复位为1b1以激活某些路径而在“Transition Delay”测试中又需要复位为1b0。因此不要硬编码q 1b0;而应使用参数化always (posedge clk or negedge rst_n_sync) begin if (!rst_n_sync) q RST_VAL; // RST_VAL由DFT配置决定 else if (scan_enable) q si; else q d; end注意网上搜索“rtl中assign的作用”时很多人强调assign用于组合逻辑但恰恰在DFT中assign是构建可控性Controllability的关键。例如用assign test_mode (scan_enable || atpg_mode);可以安全地将多个测试使能信号合并因为assign是纯组合不会引入时序风险且Tessent能完美识别其驱动能力。2.3 所有非扫描逻辑必须提供“可控性锚点”和“可观测性探针”这是新人最容易忽略的深度陷阱。Tessent的ATPG引擎不是万能的神它需要“抓手”来控制内部信号。假设你有一个模块内部用assign sum a b;计算而a和b都来自上游寄存器。如果上游寄存器已加入Scan链那么a和b就是可控的但如果sum直接驱动了一个三态门的使能端而该三态门输出又未被任何寄存器采样那么sum就是一个“不可观测点”Unobservable Point。解决方法只有两个增加观测寄存器Observation Register在关键路径末端添加一个仅用于测试的寄存器例如// 在关键组合逻辑后插入观测点 logic sum_obs; always (posedge clk) sum_obs sum; // 此寄存器必须加入Scan链重构逻辑将关键信号暴露为模块端口如果sum是模块核心输出直接将其作为output logic sum;导出而非隐藏在内部。Tessent会自动将模块端口视为高优先级可观测点。实测数据在一个12K寄存器的CPU核项目中我们最初未添加任何观测点ATPG初始覆盖率仅68%在关键ALU、Cache Tag路径添加12个观测寄存器后覆盖率跃升至98.7%且ATPG运行时间缩短40%——因为引擎不再需要耗费大量CPU时间去“猜测”如何观测这些信号。3. Tessent Insertion实战从RTL到网表的四步不可跳过操作现在你已经写好了符合DFT规范的RTL也通过了Linter检查如SpyGlass DFT规则集。下一步是启动Tessent进行Scan链插入。这里没有“一键生成”的魔法必须严格遵循四个原子步骤。跳过任意一步轻则Insertion失败重则生成错误的Scan链导致量产测试误判。3.1 Step 1创建DFT Configuration File.dftc——不是配置而是契约Tessent不接受口头约定它要求你用一份.dftc文件白纸黑字写下所有设计承诺。这份文件不是可选的它是Tessent Insertion的“宪法”。一个最小可行的top.dftc内容如下# top.dftc - DFT Configuration for TOP_MODULE set_dft_configuration -name TOP_DFT_CFG \ -scan_chain_count 4 \ -scan_chain_length_max 500 \ -scan_chain_length_min 100 \ -scan_enable_signal scan_enable \ -scan_clock_signal scan_clk \ -scan_reset_signal scan_rst_n \ -scan_mode_signal scan_mode # 定义Scan链分组策略关键 set_scan_chain_group -name CORE_GROUP \ -include_modules {core_* cpu_*} \ -max_length 400 set_scan_chain_group -name IO_GROUP \ -include_modules {io_pad_* esd_*} \ -max_length 200 # 显式声明哪些寄存器必须加入Scan链防遗漏 add_scan_register -module top -pattern reg_* add_scan_register -module core_cpu -pattern rf_* # 禁止Scan化的黑名单如PLL寄存器、模拟IP寄存器 exclude_scan_register -module pll_ctrl -pattern * exclude_scan_register -module adc_top -pattern *为什么必须手写因为自动生成的.dftc如batch scan wizard默认生成会盲目将所有寄存器塞进一条长链导致时序违例Scan链长度超500移位时钟scan_clk频率被迫降到1MHz测试时间暴涨功耗失控单条Scan链同时翻转瞬时电流峰值击穿电源网络调试困难故障定位精度从“第327个寄存器”退化为“链中某处”。提示网上流传的“batch scan wizard设置”教程大多停留在GUI点击层面但工业级项目必须用Tcl脚本控制。因为batch scan wizard生成的配置无法版本管理也无法嵌入CI/CD流水线。我坚持要求团队所有.dftc文件纳入Git每次RTL变更后第一件事就是git diff检查DFT配置是否同步更新。3.2 Step 2RTL Elaboration与Hierarchy Flattening——看清“谁在谁里面”在运行Insertion前必须让Tessent彻底理解你的设计层次。这步常被跳过直接导致“找不到模块”或“链长计算错误”。标准命令序列# 1. 启动Tessent Shell tessent shell # 2. 读入RTL支持Verilog/VHDL推荐Verilog-2001 read_hdl -format verilog -library WORK src/top.v src/core/*.v # 3. 层次化Elaboration关键 elaborate -top_module top # 4. 检查层次结构确认无黑盒 check_design # 5. 可选展平部分层次以优化Scan链谨慎使用 # flatten -module core_subsystem -keep_interfaceelaborate命令会构建完整的语法树并解析所有define、parameter、generate块。我曾遇到一个案例RTL中用generate for循环实例化16个相同ALU但elaborate后发现其中2个ALU因ifdef SIMULATION被剔除导致Scan链分组失衡。check_design命令会立即报出2 modules not elaborated避免后续Insertion失败。3.3 Step 3Scan Insertion Execution——不是“插入”而是“编织”执行Insertion的命令看似简单但参数选择决定成败# 启动Insertion核心命令 insert_scan -configuration_file top.dftc \ -report_file reports/scan_insertion.rpt \ -log_file logs/scan_insertion.log # 关键参数解读 # -configuration_file指向你的.dftc契约 # -report_file生成详细报告含链长、寄存器数、违例点 # -log_file调试用记录每一步决策Insertion过程实际是Tessent在“编织”一条条物理Scan链第一步寄存器分组。根据.dftc中的set_scan_chain_group将core_*模块的寄存器优先打包进CORE_GROUP链第二步链内排序。按寄存器在RTL中的声明顺序或按物理布局若提供Floorplan就近连接减少布线拥塞第三步插入MUX与布线。在每个寄存器前插入2:1 MUX将siScan In和dData接入输出soScan Out连向下一级si第四步顶层汇聚。将所有链的so汇总到scan_out[3:0]si从scan_in[3:0]分发。Insertion完成后务必检查scan_insertion.rpt中的关键指标指标合格范围风险提示Total scan registers RTL register count少于则有寄存器被遗漏Max chain length≤ 500 (28nm) / ≤ 300 (7nm)超限将导致时序失败Avg chain length0.8 × Max过低说明分组策略低效Unscanned registers0非零则需检查exclude规则3.4 Step 4Post-Insertion Verification——用仿真证明“它真的能工作”Insertion成功不等于DFT就绪。必须用仿真验证Scan链行为符合预期。这是新人最常省略、也是流片厂Audit必查的环节。标准验证流程使用VCS# 1. 编译插入Scan链后的网表含Tessent wrapper vcs -sverilog defineSCAN_MODE \ -f filelist.f \ -o simv_scan # 2. 运行Scan Shift测试关键 ./simv_scan TESTshift_test UVM_TESTCASEscan_shift_test # 3. 检查波形观察scan_in - 第1级寄存器q - 第2级寄存器q ... - scan_out # 应看到数据逐周期右移无毛刺、无锁死一个典型的scan_shift_test场景scan_enable 1,scan_clk施加10个周期scan_in 4b1010预期scan_out在第10周期输出4b1010且各级寄存器q值依次为1,0,1,0。如果仿真失败90%的原因是scan_clk未正确约束必须在SDC中添加create_clock -name scan_clk -period 10 [get_ports scan_clk]scan_rst_n在Shift期间被误触发检查复位同步逻辑scan_in信号驱动强度不足需在Testbench中用force而非assign驱动。实操心得我习惯在Insertion后立即运行一个“5周期Shift”快速验证而不是等完整ATPG。这能在5分钟内发现80%的硬件级错误。曾有一个项目因scan_clk引脚在顶层约束文件中被误标为input而非clockInsertion成功但Shift仿真全失败靠这个快速验证当天就定位并修复避免了后续一周的排查。4. ATPG生成与向量压缩从百万行STIL到可烧录的BIN文件Scan链插入完成只是万里长征第一步。真正的挑战在于如何用最少的测试向量覆盖最多的故障模型这就是ATPGAutomatic Test Pattern Generation的核心使命。网上搜索“sirius scan”或“scanner scan 怎么打入空串”本质上都是在问同一个问题如何让ATPG生成的向量既有效又高效4.1 故障模型选择Stuck-at不是唯一但必须是起点ATPG不是凭空生成向量它基于预设的“故障模型”Fault Model。对IC新人只需掌握两种Stuck-at-0 / Stuck-at-1信号线永久短路到GND或VDD。这是最基础、覆盖率最高的模型必须100%覆盖。所有流片厂合同都以此为最低门槛。Transition Delay信号跳变延迟超限如从0-1需2ns实际用了3ns。这检测时序路径老化但生成向量难度高、时间长通常作为Stuck-at的补充。Tessent ATPG命令# 启动ATPG针对Stuck-at模型 atpg -fault_model stuck_at \ -test_coverage_target 99.5 \ -max_runtime 3600 \ -output_format stil \ -output_file patterns/top_stuck_at.stil参数解读-fault_model stuck_at明确指定模型避免Tessent自动选择复杂模型-test_coverage_target 99.5目标覆盖率99.5%是28nm工艺的工业标准低于99%流片厂拒收-max_runtime 3600限制1小时防止单次运行耗尽服务器资源-output_format stil生成STIL格式这是ATE机台的标准语言。4.2 向量压缩为什么你的STIL文件从2GB变成20MB一个未压缩的Stuck-at测试向量集对10K寄存器设计轻易突破1GB。但ATE机台内存有限且向量下载时间直接影响测试成本每秒$0.5的机台费。因此压缩不是可选项而是必选项。Tessent提供两种工业级压缩Pattern Blanking模式消隐识别连续相同的向量段用REPEAT 1000指令替代。例如// 未压缩 PATTERN {A0; B1; C0;} PATTERN {A0; B1; C0;} PATTERN {A0; B1; C0;} // 压缩后 REPEAT 3 {PATTERN {A0; B1; C0;}}X-Bit CompressionX位压缩利用“无关位”Dont Care Bit。ATPG中某些输入位对当前故障检测无影响可标记为X压缩引擎会用算法填充最优值大幅减少向量数。启用压缩的命令# 在ATPG后立即压缩 compress_patterns -input_file patterns/top_stuck_at.stil \ -output_file patterns/top_stuck_at_compressed.stil \ -method x_bit \ -x_bit_ratio 0.3实测效果在一个8K寄存器的MCU项目中原始STIL 1.2GB经X-Bit压缩后降至18MB向量数从2.1M减少到142K而覆盖率仅下降0.03%99.47% → 99.44%完全在可接受范围内。4.3 STIL转BIN让ATE机台真正“读懂”你的向量STIL是文本格式ATE机台如Teradyne UltraFLEX需要二进制BIN文件。转换不是简单编码而是包含时序、引脚映射、测试流程的完整编译。标准流程# 1. 创建Pin Map文件关键定义物理引脚与STIL信号的对应 cat pinmap.txt EOF scan_in: PIN_101 scan_out: PIN_102 scan_clk: PIN_103 scan_enable: PIN_104 scan_rst_n: PIN_105 ... EOF # 2. 使用Tessent自带的STIL Compiler stil_compiler -input patterns/top_stuck_at_compressed.stil \ -pin_map pinmap.txt \ -output_format bin \ -output_file bin/top_test.bin \ -timing_file timing/timing_spec.tcltiming_spec.tcl定义关键时序# timing_spec.tcl set_clock_period 10.0 ;# scan_clk周期10ns set_setup_time 0.8 ;# setup time set_hold_time 0.5 ;# hold time set_output_delay 1.2 ;# scan_out delay转换后top_test.bin即可直接加载到ATE机台。我建议新人在流片前用一台二手ATE如Advantest T2000做一次实机验证加载BIN文件运行10个向量用示波器抓scan_out波形确认与仿真波形一致。这一步花2小时能避免流片后数周的测试调试。5. 常见故障排查链路从“ATPG Coverage 65%”到“99.5%”的七天攻坚实录最后分享一个真实案例。这是我在一家Fabless公司主导的蓝牙SoC项目DFT阶段卡在ATPG覆盖率长期停滞在65%历时7天最终提升至99.52%。整个过程就是一部DFT排错教科书完整呈现了资深工程师的思维链条。5.1 Day 1锁定“顽固故障”——用Coverage Report逆向追踪ATPG报告top_stuck_at.rpt显示Total faults: 1,248,932 Detected faults: 812,456 Coverage: 65.05% Undetected faults: 436,476 Top undetected module: core_crypto (218,333 faults)第一反应不是重跑ATPG而是深入core_crypto模块的Coverage Detail# 生成模块级详细报告 atpg -report_detail -module core_crypto -output_file reports/crypto_detail.rpt报告揭示关键线索Undetected fault: core_crypto/alu_inst/adder_out[7] stuck_at_1 Root cause: Uncontrollable fanin (core_crypto/alu_inst/a_reg[7])a_reg[7]是ALU的一个操作数寄存器但Coverage报告说它“不可控”。检查RTL发现它被一个always (posedge clk) begin if (op ADD) a_reg a; end驱动——问题来了op信号来自上游而上游模块未加入Scan链5.2 Day 2验证“可控性断点”——用Tessent Interactive Mode实时诊断启动Tessent交互模式手动检查可控性tessent shell read_netlist netlist/top_mapped.v read_atpg patterns/top_stuck_at.stil # 查询a_reg[7]的可控性 get_controllability -pin core_crypto/alu_inst/a_reg[7]/Q # 输出Controllability 0.0 (uncontrollable) # 追踪其扇入 get_fanin -pin core_crypto/alu_inst/a_reg[7]/D # 输出core_crypto/alu_inst/op_mux_out[7]op_mux_out[7]是多路选择器输出其输入来自a和b。继续追踪get_fanin -pin core_crypto/alu_inst/op_mux_out[7] # 输出core_crypto/alu_inst/a[7], core_crypto/alu_inst/b[7] # 再查a[7]来源 get_fanin -pin core_crypto/alu_inst/a[7] # 输出core_crypto/alu_inst/a_reg[7]/Q ← 循环依赖确诊这是一个“组合环路”Combinational Loopa_reg输出驱动op_muxop_mux输出又驱动a_reg输入。Tessent无法打破此环故标记为不可控。5.3 Day 3RTL修复与回归验证——小修改大收益修复方案在op_mux输出端插入一级寄存器打破环路// 原代码❌ assign op_mux_out (op ADD) ? a : b; // 修改后✅ logic [31:0] op_mux_out_reg; always (posedge clk) op_mux_out_reg op_mux_out; assign op_mux_out_final op_mux_out_reg;关键点op_mux_out_reg必须加入Scan链在.dftc中添加add_scan_register -pattern op_mux_out_reg。重新运行Insertion和ATPG覆盖率升至72.3%——证明环路是主因但还有其他问题。5.4 Day 4-5处理“不可观测点”——用Observation Register定点爆破新报告指出core_crypto/aes_inst/state_out[127:0]有大量undetected faults。state_out是AES状态寄存器组共128位全部未被观测。原因是state_out直接驱动output端口但该端口未被任何寄存器采样ATPG无法观测其值。解决方案在state_out后插入观测寄存器阵列// 在AES模块内添加 logic [127:0] state_obs; always (posedge clk) state_obs state_out; // 并在.dftc中声明 add_scan_register -module aes_inst -pattern state_obs重新ATPG覆盖率跃升至89.1%。此时剩余undetected faults集中在core_crypto/rsa_inst这是一个第三方IP无法修改RTL。5.6 Day 6第三方IP的DFT绕过策略——用Tessent的Black Box Modeling对rsa_inst我们采用“Black Box Modeling”# 在.dftc中添加 set_black_box_model -module rsa_inst \ -model_file models/rsa_dft_model.tcl \ -scan_chain_count 2 \ -scan_chain_length 150 # rsa_dft_model.tcl定义其内部Scan链接口 set_scan_port -module rsa_inst -port rsa_si -direction input set_scan_port -module rsa_inst -port rsa_so -direction output set_scan_port -module rsa_inst -port rsa_se -direction input这告诉Tessent“别管rsa_inst内部把它当作一个有2条Scan链的黑盒子按我给的接口连接”。重新ATPG覆盖率升至97.2%。5.7 Day 7最后的1.32%——手工向量补救Hand-Generated Patterns剩余1.32%故障集中在core_crypto/entropy_inst的模拟随机数发生器其输出受物理噪声影响ATPG无法建模。此时我们放弃ATPG手工编写10个STIL向量专门测试其关键路径PATTERN entropy_test_1 { APPLY {scan_enable1; scan_clk0; scan_rst_n1;} APPLY {scan_clk1;} APPLY {scan_clk0;} // ... 注入特定种子观测输出分布 }将手工向量与ATPG向量合并最终覆盖率定格在99.52%满足流片要求。这个案例的价值在于它展示了DFT不是“工具运行成功”就结束而是“覆盖率达标”才算完成。每一个百分点的提升都需要对RTL、网表、工具原理的深度理解。网上搜索“shared bus dft”或“ubuntu ip scan工具”得到的都是碎片信息而真实项目需要的是这种系统性、可追溯的排错能力。6. 给新人的三条硬核生存法则——写在最后的实战心法写完这篇指南我合上笔记本想起五年前自己第一次面对Tessent报错时的茫然。那时没有“tessent安装包”可下载没有“burpsuit new scan 教程”可抄只有一份厚达2000页的PDF文档和一句前辈的话“DFT不是技术是态度。” 今天我把这态度浓缩成三条你必须刻进DNA的法则第一条永远相信Coverage Report永远怀疑自己的假设。当ATPG报告覆盖率99.5%时别急着庆祝当它卡在65%时别急着重跑。Report里的每一行Undetected fault都是线索指向RTL中一个被你忽略的细节。我见过太多人把uncontrollable归咎于“工具bug”结果发现是自己把scan_enable信号名拼错了。打开Report逐行阅读像侦探一样追问“为什么这个点不可控”——答案永远在RTL或.dftc里不在搜索引擎中。第二条Scan链不是越长越好而是越“平衡”越好。网上教程总教你“最大化链长以减少引脚”但真实世界里一条500寄存器的Scan链会让scan_clk时序崩溃而四条125寄存器的链能让测试时间缩短3倍。.dftc中的set_scan_chain_group不是摆设它是你对芯片物理结构的理解。在Floorplan出来前就该和后端工程师对齐CORE_GROUP放在die中心IO_GROUP靠近pad ring——这决定了Scan链的布线长度和功耗热点。DFT工程师必须懂一点物理实现就像后端工程师必须懂一点DFT。第三条把DFT当成设计的一部分而不是附加的负担。你写的每一行assign、每一个always块都在为DFT投票。当同事说“这个assign只是为了仿真方便”你要立刻追问“它在Scan模式下可控吗可观测吗” 当项目schedule紧张时有人提议“DFT放到下一版再加”你要拿出数据上一代芯片因DFT缺失导致测试覆盖率不足返工损失$2.3M。DFT不是测试工程师的专利它是IC设计工程师的终极责任——确保你设计的电路不仅在仿真中正确更在现实世界中可验证、可信任。最后删掉你电脑里所有名为“tessent安装包”的可疑文件。真正的Tessent不在压缩包里而在你每一次elaborate的耐心、每一次check_design的严谨、每一次get_controllability的执着中。它不提供捷径只奖励那些愿意俯身看清寄存器内部MUX开关的人。