企业官网建设流程全解析

1. 项目概述：为什么“DFT常见问题的解决方法（下）——高级问题”这个标题值得深挖

DFT，也就是可测试性设计（Design for Testability），不是芯片后端流程里一个可有可无的附加项，而是现代SoC流片前最后一道真正意义上的“质量守门员”。我干这行十二年，从0.18微米工艺的ASIC做到现在3nm节点的AI加速器，见过太多项目卡在ATPG（自动测试向量生成）阶段：明明RTL功能仿真全过，综合时序也收敛了，可一跑Tessent DFT或Synopsys DCXP，就报一堆“Scan Segment无法合并”、“Capture clock domain conflict”、“UDFM violation”这类错误。它们不像语法错误那样一眼能定位，而像电路板上一根虚焊的引脚——通电时偶尔工作，量产时批量失效。标题里这个“（下）”，恰恰说明它不是入门扫盲，而是直指那些让资深DFT工程师凌晨三点还在改SDC约束、反复重跑ATPG的硬骨头。关键词里的Scan Segment，是扫描链物理实现的核心单元；ATPG是验证DFT结构是否真正可用的终极手段；DCXP代表的是Synopsys这套工业级DFT流程的成熟度与复杂度；而Tessent DFT则暗示着用户很可能正面对的是Cadence生态下的多核、多电压域、带嵌入式存储器的复杂SoC。这些词堆在一起，指向的绝不是“怎么加扫描寄存器”这种基础操作，而是“当扫描链跨时钟域、跨电源域、跨IP边界时，如何让ATPG工具既生成高覆盖率向量，又不把后端布局布线搞崩溃”这种真实战场上的问题。如果你正在为流片前最后一次DFT signoff焦头烂额，或者刚接手一个遗留DFT架构需要紧急救火，那么这篇内容就是你该打印出来贴在显示器边上的实操手册——它不讲原理推导，只讲我亲手调通、客户量产验证过的解法。

2. 高级问题的底层逻辑：为什么基础DFT流程在这里会集体失灵

2.1 扫描链物理结构的“分段”本质与隐含陷阱

很多人把Scan Segment简单理解为“一段扫描链”，这是最危险的认知偏差。在Tessent或DCXP的实际flow中，一个Scan Segment是一个具有独立时钟控制、独立复位行为、独立测试使能信号、且物理上连续可布线的最小扫描链单元。它的划分不是由RTL代码决定的，而是由DFT插入工具根据综合后的网表、时钟树结构、电源域分布、以及用户指定的约束（如-max_scan_fanout,-max_scan_length）共同决策的。举个真实案例：某款车规MCU的CPU子系统，RTL里所有寄存器都用同一个scan_clk，但综合后发现，由于时钟树插入延迟，从clock root到最远寄存器的skew超过150ps。DCXP为了保证capture阶段的时序可靠性，会自动将这条长链切成两个Segment，每个Segment配一个局部buffer，用以平衡skew。结果呢？ATPG生成的向量在仿真时没问题，但送到ATE（自动测试设备）上一跑，第二个Segment的capture数据就错位了——因为ATE的pattern文件默认假设整条链是单一时钟沿触发，而DCXP切分后实际需要两个独立的capture脉冲。这个问题不会在DFT insertion阶段报错，只有等ATPG完成、做post-layout simulation时才暴露。所以，“Scan Segment无法合并”的根本原因，从来不是工具bug，而是物理实现约束与测试协议抽象层之间的语义鸿沟。你看到的报错，只是这个鸿沟在日志里投下的影子。

2.2 ATPG失败的三类“幽灵错误”及其根源

ATPG工具（无论是Tessent TestKompress还是DCXP的TestMAX）的报错信息，90%以上都属于“幽灵错误”——即错误描述本身不指向真正的硬件缺陷，而是暴露了DFT模型与实际硅片行为的不匹配。我把它们归为三类：

第一类是时钟域冲突（Clock Domain Conflict）。典型报错如"Capture clock domain 'clk_cpu' conflicts with 'clk_bus' in scan segment 'seg_cpu_0'"。新手会立刻去查SDC里有没有漏写set_clock_groups -asynchronous，但往往白忙一场。真相是：ATPG工具在建模时，会把每个Scan Segment的capture clock当作一个独立的、理想的、零抖动的源。而现实中，clk_cpu和clk_bus虽然异步，但它们的PLL参考晶振是同一个，存在微弱的相位耦合。当ATPG试图在clk_cpu的上升沿capture数据的同时，又要求clk_bus的下降沿驱动某个控制信号，这个微小的相位差就会被放大成setup/hold violation。解决方案不是改SDC，而是在DFT insertion阶段，对跨域控制信号插入专用的同步器（synchronizer）并显式声明其为“test-only synchronizer”，让ATPG知道这部分路径需要特殊处理。

第二类是UDFM（Unified Design for Manufacturability）违规。UDFM是Synopsys提出的一套面向良率提升的DFT规则集，比如要求所有扫描链的输入必须来自专用的test mux，而非直接连到functional logic的输出。报错"UDFM violation: scan_in pin 'u_dft/scan_in[5]' driven by functional logic 'u_top/u_cpu/alu_out'"看似是连接错误，实则是工具在提醒你：这个ALU输出信号，在test mode下如果直接驱动scan_in，一旦ALU内部发生软错误（soft error），就会污染整个扫描链的输入，导致ATPG无法区分是制造缺陷还是瞬态故障。正确做法是在ALU输出后插入一个test-only mux，其data0接ALU输出，data1接一个常数（如0），sel由test_mode控制。这样，ATPG就能确保scan_in的输入完全可控、可预测。

第三类是压缩解压失配（Compression Decompression Mismatch）。这是Tessent TestKompress最让人头疼的问题。报错"Decompressor output 'decomp_out[12]' does not match expected value during pattern simulation"，表面看是解压电路出错，但十次有九次是因为在RTL中对某个关键控制信号（如cache tag valid bit）做了功能性优化，比如用组合逻辑代替寄存器来节省面积，而DFT工具无法正确建模这种非时序路径。ATPG生成的向量假设该信号是寄存器输出，但硅片上它却是毛刺敏感的组合逻辑，结果在高速ATE上一跑就错。根治方法只有一条：对所有可能影响扫描链行为的关键控制信号，强制其在RTL中使用寄存器输出，并在DFT约束文件中用set_dft_signal -type ScanEnable -port u_dft/se_b明确标注其test mode行为。

2.3 DCXP与Tessent DFT的生态差异：选错工具链就是埋雷

很多团队在项目初期纠结“用Synopsys还是Cadence”，其实这不是技术选型，而是供应链风险评估。DCXP（Design Compiler with DFT）和Tessent DFT虽然都遵循IEEE 1149.1/1687标准，但在高级问题处理上，哲学完全不同。DCXP更“务实”，它的ATPG引擎（TestMAX）对时序违例、跨域问题容忍度更高，会自动生成大量“fixup pattern”来绕过问题，代价是pattern体积暴涨30%-50%，对ATE内存和测试时间都是压力。而Tessent TestKompress更“理想主义”，它要求DFT模型必须100%符合物理实现，否则直接报错退出，绝不妥协。这就导致一个现象：同一个网表，在DCXP里能跑出98%的stuck-at覆盖率，但在Tessent里卡在92%死活上不去。这不是工具优劣，而是设计哲学的碰撞。我们曾有个项目，客户坚持用Tessent，因为他们的ATE是Teradyne UltraFLEX，内存充足，但对pattern执行时间极其敏感。我们花了两周时间，不是改ATPG参数，而是回溯到综合阶段，把所有跨电源域的扫描链全部拆到同一个VDDA域内，重新做power-aware synthesis，最终Tessent一次通过，pattern体积比DCXP方案小40%，测试时间缩短22%。所以，“高级问题”的解决，往往始于对工具链特性的深刻理解，而不是对着报错日志盲目调参。

3. 核心问题的逐个击破：从报错日志到流片通过的实操路径

3.1 “Scan Segment无法合并”问题的七步诊断法

这个问题在多核SoC中高频出现，报错通常很模糊，如"Failed to merge scan segments due to incompatible attributes"。我总结了一套七步现场诊断法，每一步都对应一个可执行的命令或检查点，已在五个不同工艺节点的项目中验证有效：

第一步：确认Segment划分依据。运行DCXP命令report_scan_segments -hierarchy，重点看-max_scan_length和-max_scan_fanout这两个参数的实际生效值。很多项目在tcl脚本里写了set_max_scan_fanout 100，但后续又被set_max_fanout 50覆盖，导致Segment被过度切分。实测下来，对于16nm及以下工艺，-max_scan_fanout设为60-80是安全值，再高布线时容易出现hold violation。

第二步：检查时钟树一致性。用report_clock_tree导出所有scan-related clock的skew和latency，特别关注scan_capture_clk和scan_shift_clk。如果两者skew差超过0.3ns，就必须切分。这时不要硬扛，而是在DFT约束中显式指定set_scan_configuration -capture_clock_skew_threshold 0.3，让工具主动按此阈值切分，比让它自己猜要可靠得多。

第三步：排查复位域交叉。运行report_reset_domains，确认每个Segment内的所有寄存器是否共享同一个reset assertion level（active-high or active-low）。曾有个项目，CPU core的reset是高电平有效，而GPU core的是低电平有效，DCXP在合并时直接拒绝，因为无法用一个test reset信号同时控制两者。解决方案是为每个core添加一个test-only inverter，统一reset polarity，再用set_dft_signal -type Reset -active_state 1声明。

第四步：验证电源域隔离。用report_power_domains检查Segment内是否存在跨VDD/VSS的寄存器。跨域扫描链在物理实现上需要额外的level shifter，而ATPG工具默认不建模这些器件。必须在UPF（Unified Power Format）文件中，对所有跨域扫描链路径，添加add_power_state -state test -isolation_strategy always_on，告诉工具这部分路径在test mode下始终供电。

第五步：审查扫描使能（Scan Enable）网络。运行report_net -connections [get_nets -of_objects [get_pins -filter "is_scan_enable==true"]]，看SE信号的fanout是否超过1000。过高会导致SE信号skew过大，不同Segment的enable时间不一致。此时应插入两级buffer tree，并用set_dft_signal -type ScanEnable -port u_dft/se_b -max_fanout 500强制约束。

第六步：检查测试模式寄存器（Test Mode Registers）。有些IP（如DDR PHY）自带test mode register，其scan_in可能未被DFT工具识别。运行check_dft_rules -rule test_mode_register，若报错，需手动在DFT constraint file中用add_test_mode_register -name u_ddr_phy/tmr -scan_in tmr_si -scan_out tmr_so注册。

第七步：终极手段——强制合并与验证。如果以上六步都OK，但工具仍拒绝合并，可以尝试set_scan_merge_constraint -force_merge true，但这不是万能钥匙。必须紧接着运行verify_scan_chain -detailed，并用simulate_pattern -test_mode做全速仿真，确认合并后的链在capture和shift阶段的行为与拆分时完全一致。我试过三次，其中两次在仿真中发现了微妙的时序违例，幸亏没跳过这步。

提示：这七步不是线性流程，而是循环迭代。我习惯把每一步的命令和输出截图存到一个共享wiki里，团队成员都能看到历史记录，避免重复踩坑。

3.2 ATPG覆盖率卡在95%不上升的实战对策

95%是个魔咒。从90%到95%可能只要调几个参数，但从95%到98%往往需要重构DFT架构。这里分享三个我在客户现场亲手落地的对策，不是理论，是已经签过流片合同的方案：

对策一：针对“untestable”路径的“外科手术式”修复。ATPG报告里总有一批"untestable due to combinational loop"或"untestable due to asynchronous set/reset"的路径。别急着加set_dft_signal -type AsynchronousSet，先用report_faults -untested -hierarchy定位到具体模块。我们曾在一个AES加密IP里发现，其S-box查找表的地址生成逻辑包含一个反馈环，ATPG认为无法控制。分析RTL后发现，这个环只在functional mode下工作，test mode下完全旁路。于是我们在DFT insertion前，在RTL中添加了一个test-only bypass mux，当test_mode=1时，直接将地址设为固定值（如0x00），并用set_dft_signal -type Bypass -port u_aes/byp_en声明。结果，这一模块的覆盖率从0%飙升到99.8%，整体覆盖率提升1.2%。

对策二：利用“don't care”逻辑压缩测试向量空间。很多覆盖率瓶颈源于某些控制信号的组合状态在functional mode下永远不会出现，但ATPG必须为所有2^N种组合生成向量。例如，一个DMA控制器有8个channel enable信号，但实际使用中最多只同时enable 4个。我们可以在ATPG配置中，用set_dont_care_condition -signal u_dma/en[7:0] -condition "popcount(u_dma/en) > 4 == 0"告诉工具，当enable位数大于4时，其输出为don't care。DCXP的TestMAX支持这种高级条件，实测可减少15%-20%的pattern数量，同时提升对剩余可测路径的激励强度。

对策三：分阶段ATPG与“热插拔”式向量集成。对于超大SoC（>50M gates），一次性ATPG不仅慢，而且容易因局部问题拖垮全局。我们采用分阶段策略：先对CPU、GPU、Memory Subsystem等大模块单独运行ATPG，生成高覆盖率向量；然后对interconnect（NoC）和peripheral模块单独运行；最后，用DCXP的merge_patterns命令，将各模块向量按test mode sequence拼接。关键技巧在于：在每个模块的ATPG配置中，用set_test_mode_sequence -mode_name cpu_test -sequence {cpu_se=1, gpu_se=0, mem_se=0}明确定义其专属test mode，避免向量间串扰。这个方案让我们在一个7nm AI chip项目中，将ATPG runtime从120小时压缩到28小时，且最终覆盖率稳定在98.7%。

3.3 DCXP中UDFM Violation的“零容忍”修复清单

UDFM不是可选项，是Synopsys流片signoff的硬性门槛。报错"UDFM violation: scan cell 'u_dft/sff_123' has non-dedicated clock"意味着这个扫描寄存器的clock pin没有接到专用的scan_clk，而是连到了functional clock上。修复它，不能靠“打补丁”，而要建立一套“零容忍”清单，贯穿整个DFT flow：

清单第一条：时钟网络的“纯净化”。在综合阶段，必须用create_clock -name scan_clk -period 10 [get_ports scan_clk]创建独立的scan clock，并在set_dft_signal -type ScanClock中绑定。更重要的是，在SDC中，对所有functional clock，必须添加set_clock_groups -asynchronous -group [get_clocks clk_func] -group [get_clocks scan_clk]，彻底切断工具对functional clock用于scan的任何联想。我见过太多项目，因为漏了这行SDC，DCXP在insertion时偷偷把functional clock当成了scan clock的source。

清单第二条：复位网络的“双轨制”。所有扫描寄存器的reset pin，必须由专用的test reset信号驱动。不能复用functional reset。正确做法是：在顶层添加一个test_rst_nport，用set_dft_signal -type Reset -active_state 0 -port test_rst_n声明；然后在DFT insertion时，用-reset_control test_rst_n参数强制所有scan cell使用它。如果IP已有functional reset，就在IP wrapper里加一个test-only mux，data0接functional reset，data1接test_rst_n，sel由test_mode控制。

清单第三条：扫描使能（SE）的“单点注入”。UDFM要求SE信号必须从顶层单一端口注入，不能在模块内部生成。因此，在DFT constraint file中，必须用set_dft_signal -type ScanEnable -port u_top/se_b明确定义顶层SE port，并在所有子模块的DFT insertion命令中，用-scan_enable_port se_b参数强制继承。任何在子模块内部用assign se = ...生成SE的行为，都是UDFM violation的温床。

清单第四条：扫描链IO的“隔离墙”。扫描链的scan_in和scan_out必须是dedicated IO，不能与functional IO复用。这意味着，在top-level port list中，必须显式定义scan_in[0:1023]和scan_out[0:1023]，并在DFT insertion时，用-scan_in_port scan_in -scan_out_port scan_out绑定。如果项目为了节省pad count想复用，UDFM检查必挂。唯一的变通方案是：在pad ring外加一个test-only IO buffer，其input接functional IO，output接scan chain，用set_dft_signal -type ScanIn -port u_padring/test_si_buf/in声明，但这会增加测试时间，需权衡。

清单第五条：压缩解压器的“认证”。如果用了TestKompress或DCXP的TestMAX Compression，UDFM会检查decompressor和compressor的LFSR多项式是否匹配、bit-width是否对齐。必须在compression configuration file中，用set_compression_parameters -decompressor_lfsr_polynomial 0x100000000000000000000000000000001 -compressor_lfsr_polynomial 0x100000000000000000000000000000001显式指定，并用verify_compression -full验证。我们曾因LFSR polynomial少写了一个0，导致UDFM检查失败，debug了三天。

注意：这份清单不是一次性任务，而是DFT flow中的checklist。我要求团队在每次DFT run前，必须对照清单逐项打钩，漏一项，run就暂停。UDFM不是bug，是设计纪律的试金石。

4. 真实战场复盘：一个7nm AI加速器DFT Signoff的48小时攻坚

4.1 问题爆发：流片前72小时的“红色警报”

那是去年冬天，客户发来一封标着“URGENT”的邮件：“7nm AI加速器，DCXP TestMAX ATPG coverage stuck at 94.2%，UDFM check failed on 37个点，Scan Segment merge failed for GPU subsystem。流片窗口只剩72小时，请求远程支持。” 我连上客户服务器，第一眼看到的是ATPG log里密密麻麻的"untestable due to asynchronous clock domain crossing"，以及UDFM report里触目惊心的红色"VIOLATION"。GPU subsystem有4个core，每个core有自己的clock domain和power domain，DCXP默认把它们切成16个Segment，但ATPG要求至少合并成4个（每个core一个）才能满足pattern memory限制。

4.2 诊断与决策：放弃“修”而选择“重构”

常规思路是调ATPG参数、加set_dft_signal约束。但我看了report_clock_tree和report_power_domains后，立刻否定了这条路。GPU的4个core clock，skew最大达0.42ns，远超DCXP默认的0.3ns阈值；而且它们的VDDA域是物理分离的，中间隔着一个large analog block，无法插入level shifter。硬要合并，只会让后端布局布线崩溃。我的决策是：不修ATPG，而重构DFT架构——把GPU的4个core的scan chain，全部迁移到一个统一的、由PLL生成的gpu_test_clk下，并为其分配独立的VDDA power domain。这听起来像推倒重来，但实际只需三步：1）在顶层RTL中添加gpu_test_clkport和gpu_vdda_testpower domain；2）修改UPF，为GPU subsystem添加add_power_state -state test -voltage 0.8；3）在DCXP tcl中，用set_scan_configuration -scan_clock gpu_test_clk -power_domain gpu_vdda_test重定义。

4.3 实施与验证：48小时内的关键操作

第1-8小时：RTL与UPF改造。我和客户RTL工程师视频会议，一起在GPU wrapper里添加test clock mux和power domain switch。关键细节：mux的sel信号必须是test_mode && gpu_test_en，避免functional mode下误触发；power domain switch的control logic必须用scan-safe latch，防止test mode下产生glitch。UPF修改后，用check_upf -verbose跑了三遍，确保没有floating power state。

第9-24小时：DFT insertion与初步验证。用新约束跑DCXP DFT insertion。report_scan_segments显示GPU now has only 4 segments, one per core。接着跑verify_scan_chain -detailed，发现两个core的scan_out fanout超标。解决方案：在每个core的scan_out后，手动插入一个2-to-1 mux，data0接原scan_out，data1接一个tie-off，sel由gpu_core_sel[1:0]控制，这样可以把4个core的scan_out mux成一个总线，fanout瞬间降到安全范围。这个手动插入，是DCXP auto-insertion做不到的，必须人肉。

第25-40小时：ATPG与pattern仿真。跑TestMAX ATPG，coverage first jump to 96.1%，但仍有"untestable due to combinational loop"。定位到GPU的texture cache tag array，其valid bit生成逻辑有feedback。按对策一，添加test-only bypass mux，coverage升至97.8%。最后，用simulate_pattern -test_mode -vector_file gpu_test.v做全速仿真，波形完美，capture data与expected完全一致。

第41-48小时：UDFM与Signoff。跑check_udfm -full，37个violation全部消失。最后一步，用report_test_coverage -hierarchy生成最终报告，97.8% coverage，0 UDFM violation，0 Scan Segment merge error。凌晨4点，我给客户发了邮件：“GPU DFT signoff passed。请安排final DRC/LVS。”

4.4 教训与心得：高级问题的本质是“设计权衡”的显化

这次48小时攻坚，让我再次确认：DFT高级问题，从来不是工具用得不够熟，而是在功能设计、物理实现、测试需求三者之间，没有做好显式的、可验证的设计权衡。客户最初的RTL，追求极致的functional performance，把GPU clock做得尽可能独立，这没错；但没预留test mode下的统一时钟和电源接口。我们的重构，不是推翻功能设计，而是为test mode“开一扇窗”。这扇窗的成本，是增加了2个pad（gpu_test_clk和gpu_vdda_test），以及约0.005mm²的area overhead，换来的是流片成功和百万颗芯片的测试良率。所以，下次当你看到“Scan Segment无法合并”时，别急着骂DCXP，先问问自己：这个“无法合并”，是不是在提醒你，功能架构里，缺了一扇为测试而开的窗？

5. 常见问题与避坑指南：那些文档里不会写的血泪经验

5.1 “ATPG生成的向量在仿真中通过，但在ATE上失败”的十大原因

这个问题堪称DFT界的“薛定谔的猫”——你永远不知道它什么时候会跳出来。根据我经手的37个流片项目，整理出最常发生的十大原因，按发生频率排序，并给出可立即执行的检查命令：

实操心得：每次拿到ATE failure log，我第一件事不是看failure site，而是运行report_clock_tree -skew和report_power_analysis -scenario test_mode。80%的“仿真通过、ATE失败”问题，根源都在这两份报告里。别迷信ATPG参数，要信硅片的物理定律。

5.2 “DFT flow中哪些步骤绝对不能自动化”的三条铁律

自动化是双刃剑。在DFT flow中，有些步骤如果交给脚本全自动跑，轻则coverage掉点，重则流片失败。我立下三条铁律，团队新人入职第一周必须背熟：

铁律一：Scan Segment的合并与拆分，必须人工决策，禁止auto-merge。DCXP的auto_merge_scan_segments命令，看起来很美，但它只看fanout和length，完全无视clock skew、power domain、以及IP vendor的特殊要求（如某些SerDes IP要求scan chain必须在特定clock domain内）。我见过最惨的案例：auto-merge把CPU和DDR PHY的scan chain强行合并，结果ATPG生成的向量在DDR PHY的training sequence中，误触发了calibration logic，导致ATE上直接fail。正确做法是：先用report_scan_segments -hierarchy看初始划分，再结合report_clock_tree和report_power_domains，画一张物理拓扑图，人工圈出可以合并的Segment组，然后用set_scan_merge_constraint -segment_list {seg_cpu_0 seg_cpu_1} -merge true显式指定。

铁律二：ATPG的fault exclusion list，必须逐条审核，禁止bulk exclude。ATPG工具会自动生成一个excluded_faults.list，里面列着所有“untestable” fault。很多工程师图省事，直接read_fault_exclusion excluded_faults.list。这是自杀行为。因为这里面混着两类fault：一类是真·untestable（如asynchronous reset path），另一类是“testable but tool missed it due to bad constraint”。我要求团队，对每一条exclusion，必须运行report_faults -fault <fault_id> -detailed，看它到底在哪条path上，再结合RTL代码，判断是否真的不可测。我们曾在一个项目中，发现ATPG把一个critical timing path上的fault标为untestable，原因是SDC里漏了set_false_path。加上后，coverage提升了0.3%。

铁律三：UDFM check的report，必须人工解读，禁止一键pass。check_udfm -full会生成一个巨大的HTML report，里面有成百上千个“PASS”和几个“VIOLATION”。新手会只盯着VIOLATION，而忽略PASS里的warning。比如，"PASS: scan cell clock is dedicated"下面可能跟着一行小字"WARNING: clock net 'clk_func' drives 3 other non-scan cells"。这个warning意味着，虽然这个cell的clock是dedicated，但clock net本身还连着functional logic，IR drop和noise会传导过来。必须人工检查这个net的fanout和driver strength，必要时插入buffer隔离。UDFM不是红绿灯，而是一份需要逐字阅读的体检报告。

5.3 新手最容易踩的五个“伪高级”陷阱

有些问题，看起来很高大上，像是高级问题，实则是基础功没练扎实。我帮新人避过最多的五个“伪高级”陷阱：

陷阱一：“Scan Enable信号用组合逻辑生成”。为了“节省一个寄存器”，有人在RTL里写assign se_b = ~test_mode & ~func_mode;。这在仿真里没问题，但硅片上，test_mode和func_mode的切换会产生glitch，导致scan chain部分寄存器被意外enable。正确做法：SE信号必须是寄存器输出，且该寄存器的clock和reset必须是dedicated test clock and reset。这是DFT的铁律，没有例外。

陷阱二：“在DFT insertion后，手动修改scan chain的连接”。看到report_scan_chain里某个cell的scan_in连错了，就直接在netlist里connect。这是灾难。DCXP的ATPG引擎，是基于DFT insertion时生成的dft_model工作的，你手动改netlist，dft_model就失效了，ATPG生成的向量完全不可信。正确做法：所有scan chain的修改，必须回到DFT constraint file，用set_scan_cell或add_scan_cell等命令，在insertion前就定义好。

陷阱三：“把ATPG coverage当成唯一KPI”。Coverage 98%很美，但如果那2%的untestable faults，全集中在boot ROM的ECC decoder里，那这颗芯片就是废品。必须结合fault simulation，看untestable faults的location和criticality。用report_faults -untested -hierarchy -weight，按模块权重排序，优先解决high-weight模块的untestable faults。

陷阱四：“忽略test mode下的power analysis”。只做functional mode的power analysis，认为test mode只是短暂的，不用care。错。test mode下，scan shift电流是functional的10倍以上，局部IR drop会导致scan cell失效。必须在UPF中，为test mode定义完整的power state，并运行report_power_analysis -scenario test_mode。

陷阱五：“用functional simulation的testbench跑DFT verification”。functional testbench里，test_mode信号是随机toggle的，而DFT