第3章 DRC工具入门
做物理验证这么多年，我始终觉得DRC工具就像芯片设计的“质检员”。你画好了版图，它帮你一条条过规则。今天咱们就聊聊市面上最主流的三个工具——Calibre、ICV、Assura，以及DRC到底怎么跑、报告怎么看。
3.1 主流DRC工具：Calibre、ICV、Assura
先说Calibre，这是Siemens EDA（原Mentor）的产品。我在项目中用得最多的就是它。为什么？因为它的规则集最全，而且在大规模芯片上跑得飞快。很多代工厂的官方DRC deck都是优先支持Calibre。我个人习惯把Calibre当作“金标准”——其他工具报的错，最后往往还要用Calibre再确认一遍。
ICV（IC Validator）是Synopsys家的。如果你用Synopsys的流程（比如ICC2），那ICV集成起来非常顺。我记得有个项目用ICV做incremental DRC，只改了几个标准单元，跑一圈只要几十秒，迭代效率很高。
Assura是Cadence的老牌工具，现在虽然被PVS逐渐取代，但很多老工艺节点上依然在用。Assura的交互式debug很直观，可以直接在Virtuoso版图里高亮错误。不过说实话，对于7nm以下的先进工艺，Assura有点吃力，我建议优先考虑Calibre或ICV。
如果你在成熟工艺（180nm ~ 28nm），三个工具都能用，看公司flow和代工厂支持。先进工艺（16nm以下）我强烈推荐Calibre，它的multi-threading和层次化处理更成熟。
3.2 DRC运行流程
DRC跑起来其实就四步，但每一步都有坑。我拆开来说。
- 准备规则文件（DRC deck）——代工厂给的是 .drc 或 .rul 文件。里面定义了成百上千条规则。注意：不同工具语法不同，不能混用。
- 版图数据输入——通常是GDSII或OASIS格式。我遇到过好几次因为GDS版本太老导致工具报“读不进去”，后来统一用OASIS，省心很多。
- 运行检查——工具会逐条比对规则。这里有个关键参数：
PERC或RUN_SET，用来选择检查模式（比如全芯片还是模块级）。 - 结果输出——生成DRC报告（文本/ASCII）和错误标记（如 .db 或 .ascii 格式）。
下面是一个典型的Calibre运行脚本片段（简化版）：
// Calibre DRC runscript example
LAYOUT PATH "top.gds"
LAYOUT PRIMARY "TOP"
DRC RESULTS DATABASE "top.drc.db"
DRC SUMMARY REPORT "top.drc.summary"
INCLUDE "foundry_rule.drc"
DRC RUN你想想看，如果忘了指定 LAYOUT PRIMARY，工具可能把整个GDS当成一个cell，报一堆莫名其妙的错。嗯，我刚开始就犯过这种低级错误。
3.3 如何看懂DRC报告
报告是DRC的“判决书”。很多人一打开报告看到几千行就头大。别慌，我教你抓重点。
一份标准的DRC报告通常包含这几块：
| 报告章节 | 内容 | 关注点 |
|---|---|---|
| Header | 工具版本、规则文件、运行时间 | 确认用的是正确的deck |
| Summary | 总错误数、每种规则违例数量 | 看TOP 3违例类型 |
| Detail | 每个错误的坐标、层次、违反的规则 | 定位具体位置 |
| Statistics | 运行时间、内存、层次化信息 | 判断是否异常 |
举个例子，报告里出现 M1.S.1 (M1 minimum spacing) Violations: 47。这表示M1最小间距违例有47处。我会先看坐标，如果集中在某个区域，大概率是那个模块的布线出了问题。
用Calibre RVE（结果查看环境）打开 .db 文件，可以直接在版图上点错误。我曾经花了一下午手动查报告坐标，后来发现RVE一键高亮……真香。
不要只看错误数量！有时候一个违例在报告里被重复计数（比如层次化展开后），实际物理位置只有几处。一定要结合版图确认。
最后说说报告里的“严重等级”。有些工具会把违例分成 Error（必须修）和 Warning（建议修）。但我的经验是：所有Warning最好都过一遍。我曾经因为忽略一个“M1 antenna warning”，流片回来芯片天线效应导致漏电……嗯，从那以后我再也不敢跳过任何Warning了。