4、扫描设计规则检查：DFT规则、违例类型、修复方法

扫描设计规则检查（DRC，Design Rule Check）是DFT流程中承上启下的关键环节。它位于RTL设计完成、综合网表生成之后，以及扫描插入（Scan Insertion）与ATPG（自动测试向量生成）之前。其核心目的是验证设计是否满足扫描测试的基本结构要求，确保后续生成的测试向量能够有效控制内部触发器并观测其状态。如果跳过或轻视这一环节，ATPG阶段将产生大量低故障覆盖率或不可用的向量，甚至导致测试芯片无法在ATE（自动测试设备）上正常工作。本章将系统阐述DFT规则检查的底层原理、典型违例类型、工程修复方法，并结合实际案例进行深度拆解。

上图展示了DFT DRC检查的完整工程链路。从输入网表与约束开始，经过规则引擎解析，输出三类结果：结构违例（必须修复）、警告（建议修复）、信息（提示性）。下方进一步将检查分为内部规则（针对扫描单元本身）与外部规则（针对扫描链与周边逻辑的交互）。在实际项目中，DFT工程师需要结合综合工具（如Design Compiler）与DFT工具（如Tessent DFTAdvisor、DFTMAX）的报告，逐条分析违例的根因，并制定修复策略。

4.1 核心原理：DFT规则检查的底层逻辑

DFT规则检查的本质是验证设计是否满足可控性（Controllability）与可观测性（Observability）两大基本属性。可控性要求测试激励能够将扫描单元（通常是触发器）置为任意期望状态；可观测性要求测试响应能够被传输到芯片输出引脚或压缩逻辑中。扫描设计通过将触发器串联成移位寄存器链（Scan Chain）来实现这两点，但前提是链上的每个环节都不能存在阻断或干扰。

从实现层面看，DFT DRC主要检查以下四类底层关系：

• 时钟关系：所有扫描触发器必须由可控的、同源的时钟沿驱动。若存在门控时钟（ICG）或分频时钟，必须确保在测试模式下时钟能够被旁路或统一控制。
• 异步信号关系：触发器的置位/复位端（Set/Reset）必须由测试模式信号（如Test Mode）控制，避免在移位过程中产生意外复位或置位，导致扫描链数据被破坏。
• 数据路径关系：扫描输入（Scan In）到扫描输出（Scan Out）之间的组合逻辑路径不能过长，且不能包含锁存器、三态门或双向端口等非扫描友好单元。
• 跨时钟域（CDC）路径：不同时钟域之间的数据传输必须经过同步器或测试隔离逻辑，否则在捕获（Capture）阶段会产生亚稳态，导致测试结果不确定。

DFT工具通常内置数百条规则，分为硬规则（Hard Rule）和软规则（Soft Rule）。硬规则违反将直接导致ATPG失败或测试覆盖率严重下降，例如“触发器时钟引脚连接到了组合逻辑输出”；软规则违反可能仅影响测试覆盖率或测试时间，例如“存在未约束的时钟门控单元”。理解规则的分类有助于工程师确定修复优先级。

4.2 判断方法：DFT DRC的检查流程与违例类型

DFT DRC的检查流程通常分为三个步骤：规则设置（Rule Setup）、违例报告（Violation Report）、分级处理（Triage）。在工程实践中，我们通常使用Tessent或DFTMAX工具执行以下命令序列：

# 以Tessent DFTAdvisor为例
read_netlist ./top_netlist.v
read_cell_library ./techlib/tsmc28hpc.db
read_constraints ./constraints/top_dft_constraints.stil
set_dft_signal -view existing_dft -port test_mode -type TestMode -active 1
set_dft_signal -view existing_dft -port scan_enable -type ScanEnable -active 1
set_dft_signal -view existing_dft -port scan_in -type ScanDataIn
set_dft_signal -view existing_dft -port scan_out -type ScanDataOut
dft_drc -verbose
report_dft_drc -violations -output dft_drc_report.txt

执行后，工具会生成详细的违例报告。根据严重程度，违例通常分为以下类型：

违例类别	典型规则编号	严重级别	典型描述
时钟违例	DFT_CLK-001	硬违例	触发器时钟引脚由组合逻辑驱动，而非时钟端口或PLL输出
异步控制违例	DFT_RST-003	硬违例	异步复位端直接连接到非测试控制信号，移位时可能被意外触发
锁存器违例	DFT_LAT-001	硬违例	设计中存在电平敏感锁存器，无法直接纳入扫描链
三态/双向违例	DFT_TRI-002	警告	三态总线在测试模式下可能产生总线竞争
CDC违例	DFT_CDC-005	警告	跨时钟域路径未使用同步器，捕获阶段存在亚稳态风险
时钟门控违例	DFT_ICG-001	警告	门控时钟单元在测试模式下未被旁路，可能导致时钟沿丢失

在分级处理阶段，工程师需要结合设计功能与测试约束，判断每个违例是否真正影响测试质量。例如，一个“三态总线警告”如果仅存在于静态配置寄存器中，且测试向量不会同时使能两个驱动器，则可以豁免；但“时钟违例”通常必须修复，否则扫描链无法正常工作。

4.3 案例拆解：一个真实SoC芯片的DFT DRC修复过程

某款用于物联网的SoC芯片，采用28nm工艺，包含约200万门逻辑、4个时钟域（CPU主频500MHz、外设总线100MHz、低速外设32kHz、USB 48MHz），设计中有约15,000个触发器。在首次执行DFT DRC时，工具报告了37个硬违例和112个警告。以下是其中三个典型问题的分析与修复过程。

问题1：门控时钟导致的时钟沿丢失（DFT_ICG-001）

初始现象：报告显示CPU子系统中约200个触发器由门控时钟驱动，该门控时钟由功能信号（如模块使能信号）控制。在扫描移位模式下，如果使能信号为低，时钟沿无法到达触发器，扫描链数据无法更新。

分析判断：这些门控时钟单元（ICG）是低功耗设计的一部分，但在测试模式下必须被旁路。我们检查了综合脚本，发现未在DFT约束中声明测试模式下的时钟旁路逻辑。

实际操作：在RTL中增加了测试模式旁路MUX，将ICG的时钟输出在测试模式下强制连接到全局扫描时钟。修改后重新综合，并再次运行DFT DRC，该违例消除。

问题2：异步复位信号不可控（DFT_RST-003）

初始现象：外设总线域中的一组寄存器使用异步复位，复位信号来自一个外部引脚，但该引脚在测试模式下未被约束为固定电平。

分析判断：在扫描移位过程中，外部引脚可能受到ATE（自动测试设备）的干扰产生毛刺，导致触发器被意外复位，扫描数据丢失。

实际操作：在DFT约束文件中，将外部复位引脚在测试模式下强制置为无效电平（高电平），并添加了复位同步器。同时，在扫描链插入时，将这些触发器的复位端连接到测试复位信号（Test Reset），确保移位期间复位无效。

问题3：跨时钟域路径未隔离（DFT_CDC-005）

初始现象：CPU域与USB域之间存在一条异步FIFO路径，工具报告该路径在捕获阶段可能产生亚稳态。

分析判断：虽然功能设计中使用了异步FIFO，但在测试模式下，两个时钟域同时捕获数据时，FIFO的空/满标志可能处于不确定状态，导致测试响应不稳定。

实际操作：在FIFO的输出端增加了测试隔离寄存器（Test Isolation Register），在测试模式下将FIFO输出旁路为固定值，避免亚稳态传播。同时，在ATPG约束中设置了false_path，将跨时钟域路径排除在捕获分析之外。

结果对比：修复后，DFT DRC硬违例从37个降至0个，警告从112个降至23个（剩余警告均为可豁免的软规则）。ATPG故障覆盖率从修复前的82.3%提升至97.1%，测试向量数量减少了约15%，因为不再需要额外的测试点来补偿不可控逻辑。

风险与代价：修复过程中增加了约0.5%的面积开销（测试旁路MUX和隔离寄存器），并增加了约2%的功耗（测试模式下的额外翻转）。但换来了测试时间的缩短和覆盖率的提升，整体收益显著。

4.4 常见误区与总结复盘

在DFT DRC检查与修复过程中，工程师常陷入以下误区：

• 误区一：将所有警告都视为必须修复。实际上，部分警告（如三态总线警告）在特定测试模式下不会产生实际冲突，可以通过ATPG约束豁免。盲目修复会增加面积和功耗开销。
• 误区二：忽略时钟门控的测试旁路。许多低功耗设计大量使用ICG，但DFT工程师在早期未与后端工程师沟通，导致测试模式下时钟树无法统一控制，后期修复成本极高。
• 误区三：将DFT DRC视为一次性任务。实际上，每次综合、每次ECO（工程变更单）后都需要重新运行DFT DRC，确保新引入的逻辑不破坏扫描结构。
• 误区四：不关注DFT约束文件的完整性。例如，未声明Test Mode信号、Scan Enable信号或Scan Clock的时序关系，导致工具无法正确识别测试模式。

总结而言，DFT DRC是扫描测试质量的守门员。一个干净、无违例的DFT DRC报告，是后续扫描插入、ATPG和ATE测试顺利进行的先决条件。建议团队建立以下最佳实践：

1. 在RTL freeze前进行DFT规则预检查，提前发现结构性问题。
2. 维护一份详细的DFT约束文件（如STIL或CTL），并纳入版本管理。
3. 每次综合后自动运行DFT DRC，并将违例报告纳入CI（持续集成）流程。
4. 建立违例修复知识库，记录常见违例的根因与修复方案，提升团队效率。