第二章：DRC规则文件解析

各位工程师朋友，今天我们来聊聊DRC规则文件。说实话，我刚入行那会儿，看到动辄几万行的规则文件，头都大了。但后来我发现，只要掌握了规则文件的格式和结构，这东西其实没那么可怕。

2.1 规则文件格式：SVRF vs TCL

目前主流的DRC规则文件格式有两种：SVRF和TCL。我个人的习惯是，先搞清楚你用的工具支持哪种格式，再深入细节。

特性	SVRF	TCL
全称	Standard Verification Rule Format	Tool Command Language
代表工具	Calibre	ICV、PVS
语法风格	声明式，类似硬件描述	脚本式，可编程性强
学习曲线	较平缓	较陡峭

SVRF 是Calibre的看家本领。它的语法很直观，你写出来的规则几乎就是自然语言。比如检查线宽，直接写 WIDTH M1 < 0.18 就完事了。我在项目中遇到过很多新手，看到SVRF的语法都觉得亲切。

TCL 则更灵活。它本质上是一种脚本语言，你可以写循环、条件判断、甚至自定义函数。但代价是，代码量会大一些。我记得有一次，我用TCL写了一个复杂的密度检查规则，整整写了200行。如果用SVRF，可能50行就搞定了。

核心观点： 选哪种格式，取决于你的需求和工具链。如果你只是做常规的DRC检查，SVRF足够了。如果你需要高度定制化的检查，TCL是更好的选择。

2.2 规则语句结构

不管是SVRF还是TCL，规则语句都有固定的结构。说白了，就是「检查什么 + 怎么检查 + 报什么错」。

我们来看一个典型的SVRF规则语句：

// 检查M1层的最小线宽
M1 {
    @ 最小线宽检查
    WIDTH M1 < 0.18 {
        @ 报错信息
        M1_WIDTH_ERROR = 1
    }
}

这个结构很清晰：

层定义：M1 { ... } 指定检查对象
检查条件：WIDTH M1 < 0.18 定义规则
报错输出：M1_WIDTH_ERROR = 1 标记错误

你想想看，这就像写一个if语句。条件成立，就执行报错。我在项目中见过有人把规则写得特别复杂，一个规则里嵌套了七八个条件。嗯，这里要注意，规则越简单，调试越容易。

个人技巧： 我建议每个规则只做一件事。比如线宽检查就只检查线宽，间距检查就只检查间距。这样后期维护起来，你不会想骂自己。

2.3 层次化规则定义

真正的DRC规则文件，动辄上万行。如果全部写在一个层级里，那简直是灾难。层次化规则定义，就是解决这个问题的。

层次化的核心思想是：把规则按功能分组，再按层级调用。我画了一张图，帮你理解这个逻辑：

在实际项目中，层次化规则定义通常这样写：

// 顶层文件：top.drc
// 调用各功能组
INCLUDE "metal_rules.drc"
INCLUDE "poly_rules.drc"
INCLUDE "contact_rules.drc"

// 金属层规则组：metal_rules.drc
M1_RULES {
    @ M1层规则
    WIDTH M1 < 0.18 { M1_WIDTH_ERROR = 1 }
    SPACE M1 < 0.20 { M1_SPACE_ERROR = 1 }
}

M2_RULES {
    @ M2层规则
    WIDTH M2 < 0.20 { M2_WIDTH_ERROR = 1 }
    SPACE M2 < 0.22 { M2_SPACE_ERROR = 1 }
}

这样做的好处很明显：

模块化：每个文件只负责一类规则
可复用：同样的规则组可以在不同项目中复用
易调试：出错了，直接定位到对应文件

避坑指南： 我曾经在一个项目中，把所有规则都写在一个文件里，结果有3万行。后来要改一个M2的间距规则，我找了整整两个小时。从那以后，我再也不这么干了。记住：规则文件一定要分层，每层只做一件事。

2.4 规则文件中的变量与参数

好的规则文件，一定会用变量和参数。为什么？因为工艺参数会变。你今天用0.18μm，明天可能用0.13μm。如果规则里写死了数值，改起来要命。

我习惯在规则文件开头定义参数：

// 工艺参数定义
DEFINE M1_MIN_WIDTH 0.18
DEFINE M1_MIN_SPACE 0.20
DEFINE M2_MIN_WIDTH 0.20
DEFINE M2_MIN_SPACE 0.22

// 使用参数
M1 {
    WIDTH M1 < M1_MIN_WIDTH { M1_WIDTH_ERROR = 1 }
    SPACE M1 < M1_MIN_SPACE { M1_SPACE_ERROR = 1 }
}

这样，当工艺节点变化时，你只需要改顶部的参数定义。规则体完全不用动。你想想看，这能省多少事？

我的习惯： 参数命名要有规律。比如 M1_MIN_WIDTH，一看就知道是M1层的最小线宽。千万别用 A1、B2 这种名字，三个月后你自己都看不懂。

2.5 规则文件的调试技巧

写规则不难，调试规则才是真功夫。我分享几个实用技巧：

分段调试：不要一次性跑所有规则。先跑一层，确认没问题了再加下一层。
用测试结构：我习惯先画一个简单的测试版图，包含各种极端情况。规则写完后，先用这个测试版图跑一遍。
看日志文件：DRC工具会生成详细的日志。里面会告诉你每条规则检查了多少个图形，报了多少个错。如果某个规则报了0个错，但你应该知道那里有错，那就要检查规则本身了。
对比运行：改规则前后，用同一个版图跑两次，对比结果。这样能快速发现改动带来的影响。

我记得有一次，我写了一个复杂的密度检查规则，怎么跑都不报错。后来发现，是我把层名写错了。嗯，这种低级错误，谁都会犯。关键是调试方法要对。

好了，关于DRC规则文件的解析，今天就聊到这里。规则文件格式、语句结构、层次化定义，这三个点你掌握了，基本就能看懂大部分DRC规则文件了。剩下的，就是多写、多练、多踩坑。

最后说一句： 规则文件是你的朋友，不是敌人。把它整理好、注释好、分层好，它会帮你省下大把时间。

可可精品资料库

📚 课程目录

第二章：DRC规则文件解析

2.1 规则文件格式：SVRF vs TCL

2.2 规则语句结构

2.3 层次化规则定义

2.4 规则文件中的变量与参数

2.5 规则文件的调试技巧