3. 物理验证入门：DRC规则文件解析、常见DRC错误类型、DRC运行与调试
物理验证，说白了就是给芯片设计做「体检」。你画了那么多版图，到底能不能拿去流片？DRC（Design Rule Check）就是第一道关卡。我见过不少新手，画版图时天马行空，结果一跑DRC，满屏都是红色错误标记——那种感觉，嗯，挺崩溃的。
但别怕。DRC其实有规律可循。今天我就带你把它拆开揉碎了讲清楚。
3.1 DRC规则文件长什么样？
DRC规则文件，通常以 .drc 或 .rul 结尾。它本质上是一堆「几何约束条件」。比如：
- 最小线宽不能小于0.18μm
- 两根金属线之间的间距不能小于0.2μm
- 有源区必须被多晶硅完全覆盖
这些规则不是随便写的。它们来自晶圆厂的实际工艺能力。我记得有一次，一个0.13μm的项目，代工厂给的规则文件有3000多行。我当时心想：这得看到什么时候？
后来我学乖了。看规则文件，不用逐行读。你只需要抓住几个关键部分：
| 规则类别 | 典型规则名 | 含义 |
|---|---|---|
| 宽度规则 | WIDTH M1 >= 0.18 | 金属1最小宽度0.18μm |
| 间距规则 | SPACE M1 M1 >= 0.20 | 金属1之间最小间距0.20μm |
| 包围规则 | ENCLOSURE CONT M1 >= 0.05 | 接触孔被金属1包围至少0.05μm |
| 密度规则 | DENSITY M1 >= 0.30 | 金属1的图形密度不低于30% |
规则文件里还有一层叫「派生层」。比如 GATE = POLY AND ACTIVE，意思是栅极层由多晶硅和有源区重叠产生。这些派生层在DRC检查中非常关键。
MINIMUM 和 SPACE 这两个关键词。它们几乎覆盖了80%的常见错误。
3.2 常见DRC错误类型
DRC错误五花八门，但归纳起来就几大类。我按「出镜率」排个序：
3.2.1 最小宽度违规
这是最常见的。你画了一条细线，比工艺允许的最小值还窄。为什么会这样？有时候是手抖画歪了，有时候是自动布线器没设好规则。
典型报错： M1 width 0.15um < 0.18um
3.2.2 间距违规
两根线靠太近了。我在一个项目中遇到过，两条金属线间距差了0.01μm。就这0.01μm，流片回来直接短路。教训深刻啊。
典型报错： M1-M1 space 0.18um < 0.20um
3.2.3 包围/覆盖违规
比如接触孔（CONT）没有被上层金属完全包住。这种错误在手动修改版图时特别容易引入。你挪了一下金属线，忘了检查接触孔是否还在里面。
典型报错： CONT enclosure by M1 0.03um < 0.05um
3.2.4 密度违规
这个比较隐蔽。芯片上某个区域的金属密度太高或太低，会影响化学机械抛光（CMP）的均匀性。代工厂会要求你在空白区域加「dummy metal」。
典型报错： M1 density 22% < 30%
3.2.5 天线效应违规
长金属线在刻蚀时会像天线一样收集电荷，可能击穿栅氧化层。这个在深亚微米工艺下特别要小心。
典型报错： ANTENNA ratio 1200 > 1000
3.3 DRC运行与调试
好了，规则文件看懂了，错误类型也知道了。接下来就是真刀真枪地跑DRC。
3.3.1 运行DRC的基本流程
我用的是Calibre，但其他工具（如ICV、Assura）流程大同小异。大致分三步：
- 准备输入文件： GDSII版图文件 + DRC规则文件
- 设置运行参数： 选择检查层次、输出格式（通常选ASCII或GDS）
- 执行并查看结果： 运行命令，打开结果数据库
一个典型的Calibre DRC运行命令长这样：
calibre -drc -hier -turbo 4 my_design.drc
其中 -turbo 4 表示用4个核并行跑。我建议你根据服务器配置来设，别贪多。有一次我设了16个核，结果内存爆了，跑了12小时白跑。
3.3.2 调试DRC错误的技巧
DRC跑完，你会得到一个错误列表。少则几十，多则成千上万。怎么下手？
第一步：按错误类型分组。 别一个一个看。先看哪种错误最多。通常80%的错误集中在20%的类型上。先解决那20%。
第二步：从顶层往下查。 有些错误是「连锁反应」。比如你修好了一个间距错误，可能连带解决了周围10个错误。
第三步：用工具定位。 在版图编辑器里，高亮显示错误位置。我习惯把错误标记设为红色，一眼就能看到。
避坑指南： 我曾经遇到过一个项目，DRC报了5000多个错误。团队慌了，准备一个个修。我拦住了他们。先查了规则文件，发现有一个规则是「可忽略」的——那是代工厂的冗余规则，实际不会影响流片。去掉那个规则后，错误数降到了200个。所以，拿到错误列表，先确认规则是否全部适用。
3.3.3 常见调试场景
我总结了几种典型场景，你可能会遇到：
- 场景一： 错误集中在某个模块。那大概率是那个模块的版图画错了。直接找那个模块的设计者。
- 场景二： 错误沿着某条线连续出现。可能是那条线本身有问题，也可能是周围环境导致的。放大看看。
- 场景三： 错误在芯片边缘。这通常是「切割道」或「封裝」相关的问题。需要和代工厂确认。
嗯，调试DRC其实是个「体力活」加「脑力活」。体力活是指你要反复放大、缩小、修改。脑力活是指你要判断哪些错误是「真错」，哪些是「假错」。
举个例子：有时候两条线间距不够，但中间有虚拟填充（dummy）隔开了。工具可能没识别到dummy，报了假错。这时候你需要手动确认，或者调整规则文件里的「排除层」设置。
3.4 知识体系总览
下面这张图，是我自己整理的DRC知识框架。你可以把它当作「地图」，随时回来对照。
DRC这件事，说白了就是「熟能生巧」。你跑得多了，自然知道哪些错误是「纸老虎」，哪些是「真老虎」。我刚开始带团队时，有个新人跑DRC，看到错误就慌。我告诉他：先喝口水，再打开错误列表。慢慢来，不着急。
嗯，今天就聊到这儿。记住一句话：DRC不是来为难你的，它是来保护你的。它帮你把问题留在流片前，而不是流片后。