4、扫描链设计规则检查（DRC）：DRC工具介绍、常见DRC违例、DRC报告解读
扫描链设计规则检查，简称DRC。说白了，就是给扫描链做一次全面体检。
我刚开始做DFT那会儿，觉得只要把扫描链连上就行。结果呢？流片回来，测试机台一跑，一堆链子就是不通。后来我才明白，DRC这步省不得。你想想看，几百万个触发器串在一起，中间任何一个节点出问题，整条链就废了。
4.1 DRC工具介绍
市面上主流的DRC工具，我接触过这么几款：
| 工具名称 | 厂商 | 特点 |
|---|---|---|
| Tessent Shell | Mentor (Siemens) | 业界标杆，规则库最全，我主力用它 |
| Synopsys DFTMAX | Synopsys | 集成度高，跟DC配合好 |
| Cadence Modus | Cadence | 新秀，速度不错 |
我个人习惯用Tessent。为什么？因为它的DRC规则覆盖最细，连一些犄角旮旯的违例都能揪出来。不过话说回来，工具只是工具，关键还是看你怎么解读报告。
4.2 常见DRC违例类型
这些年我见过的DRC违例，少说也有上百种。但真正高频出现的，其实就那么几类。我给大家梳理一下：
4.2.1 时钟域违例（Clock Domain Violation）
这是最常见的一种。扫描链上的触发器，必须用同一个时钟沿来捕获数据。如果混用了不同时钟域，或者用了上升沿和下降沿混搭，DRC就会报错。
4.2.2 扫描使能违例（Scan Enable Violation）
扫描使能信号SE，必须能同时控制所有扫描触发器。如果某个触发器的SE端被其他逻辑干扰了，或者SE路径上有组合逻辑，DRC就会报错。
// 错误示例：SE路径上有组合逻辑
assign scan_en_gated = scan_en & some_control;
dff U1 (.CK(clk), .SE(scan_en_gated), .D(data), .Q(q));
// 正确做法：SE必须直连
dff U1 (.CK(clk), .SE(scan_en), .D(data), .Q(q));
4.2.3 锁存器违例（Latch Violation）
锁存器在扫描链里是个麻烦精。因为它对电平敏感，不是边沿触发。DRC工具一般会报"Latch in scan chain"的警告。
嗯，这里要注意：不是所有锁存器都不能用。有些特殊的锁存器，比如带扫描输入的，是可以的。但大部分情况下，我建议直接避开锁存器。
4.2.4 三态违例（Tristate Violation）
扫描链上的节点，不能出现高阻态Z。如果某个触发器输出接了三态门，而且三态门在扫描模式下可能被关闭，那DRC就会报错。
4.2.5 异步复位违例（Async Reset Violation）
触发器的异步复位端，在扫描模式下必须保持无效状态。如果复位信号在扫描过程中被意外触发，整条链的数据就全丢了。
DRC工具会检查复位信号是否在扫描模式下被正确钳位。如果没钳位，就会报"Async reset not disabled during scan"。
4.3 DRC报告解读
拿到一份DRC报告，别急着从头看到尾。我教你一个方法：
- 先看总览：报告开头会告诉你总共有多少违例，分几类。
- 再看严重等级：Error必须修，Warning可以酌情处理。
- 最后看具体违例：每个违例会告诉你位置、类型、原因。
举个例子，Tessent的DRC报告长这样：
# DRC Report Summary
# Total Violations: 127
# Errors: 23
# Warnings: 104
# Violation #1 [ERROR] - Clock Domain Violation
# Location: scan_chain_1, cell U_FF_123
# Details: Clock pin connected to clk_ungated, expected clk_gated
# Severity: High
# Violation #2 [WARNING] - Latch in Scan Path
# Location: scan_chain_3, cell U_LATCH_45
# Details: Latch detected in scan data path
# Severity: Medium
你看这个报告，23个Error必须全部清零。104个Warning，我会挑那些跟时序、功耗相关的修掉，其他的可以跟设计人员商量着来。
4.4 实战经验总结
做了这么多年DFT，我总结了几条DRC的黄金法则：
- 早跑早发现：不要等到综合完了再跑DRC。RTL阶段就可以跑初步检查。
- 逐级清零：先修Error，再修Warning。别混着来，容易乱。
- 跟设计人员沟通：有些违例其实是设计上的问题，需要前端配合改RTL。
- 保留历史记录：每次DRC报告我都存档。万一后面出问题，可以回溯对比。
我记得有一次，一个项目DRC报了200多个违例。团队里新人慌了，说这得修到什么时候。我说别急，先分类。结果一分类发现，其实就3种类型。每种类型找到根因，批量修复，两天就搞定了。
所以啊，DRC不可怕。可怕的是你不会看报告，不会找规律。掌握了方法，它就是纸老虎。