4. DRC结果分析与违例定位

DRC 跑完之后，真正决定签核效率的不是“有没有违例”，而是“能不能把违例读成设计问题”。Calibre 输出的 DRC 结果通常是一个 ASCII 结果库（RDB，Results Database），里面按规则、按单元、按坐标逐条记录违例。如果只盯着总数，几万条违例看起来毫无头绪；一旦按规则类型、区域、层次三个维度切开，往往能收敛到十几个根因。本节围绕 Results Browser、RVE（Results Viewing Environment）和 Bulk Verify 三类工具，讲清楚怎么从结果库走到真实设计问题。

一、先理解结果库的结构，再谈工具

Calibre DRC 的结果库不是一堆无序文本，它有明确的层级：最上层是规则检查项（Check），每个 Check 下挂若干违例（Violation），每条违例包含单元名（Cell）、坐标（Coordinate）、层次路径（Hierarchy Path）以及可选的版图截图和规则描述。RVE 读取 RDB 后，左侧树形结构就是“Check → Cell → Violation”的映射。理解这一点很关键：按规则分类对应 Check 层，按区域分类对应坐标层，按层次分类对应 Cell 与 Hierarchy Path 层。三种分类方式不是三套独立操作，而是同一棵结果树上的三种切法。

二、Results Browser：先做规则维度的收敛

Results Browser 是 Calibre 图形界面里查看结果的第一入口。打开结果库后，它会按 Check 名列出每一类规则的违例数量。分析的第一步不是逐条看，而是先看数量分布：如果某一类规则占了总违例的 70% 以上，它几乎一定是系统性问题，而不是零星错误。例如某次 40nm 项目 DRC 共 12,480 条违例，其中 M1.SPACE.1（金属一最小间距）占 6,900 条，VIA1.ENCLOSURE 占 3,100 条，其余规则合计不到 2,500 条。此时正确的做法是先处理这两类，而不是从数量最少的规则开始逐条修。

在 Results Browser 中点击某个 Check，可以进一步按 Cell 展开，看到该规则在哪些单元里集中出现。如果同一规则在同一个标准单元里出现上千次，说明问题出在单元本身或它的摆放环境，而不是每个实例都要单独修。这一步的产出应该是一张“规则—数量—集中单元”的清单，作为后续定位的输入。

三、RVE：从规则收敛到坐标与层次

RVE 是逐条定位违例的主工具。它把结果库和版图视图联动起来：在左侧选中一条违例，右侧版图会自动缩放并高亮到对应坐标，同时显示该违例的层次路径。RVE 里最值得用的几个能力是：

• 层次路径展开：一条违例可能出现在 TOP/u_core/u_alu/u_add/ADDFX1 这样的深层路径上。RVE 会显示完整路径，帮助你判断是单元内部问题还是顶层集成问题。如果同一违例在多个不同父单元下都出现，根因通常在叶子单元；如果只在某个特定父单元下出现，根因更可能在集成或摆放。
• 规则描述与参考图：每条 Check 都带规则说明和示意截图，RVE 可以直接调出，避免凭记忆猜规则含义。
• 违例标记与注释：可以对违例打 Waive（豁免）或加注释。Waive 必须谨慎，只用于确认是工具误报或已获批准的例外，且要记录理由和批准人，不能用来“消掉”真实问题。
• 与版图编辑器联动：从 RVE 可以直接跳转到 Virtuoso 或 Laker 等版图工具中的对应位置，方便直接修改。

实际操作中，建议在 RVE 里按“规则 + 单元”分组浏览，而不是按坐标顺序逐条翻。坐标顺序会把同一根因的违例打散，分组浏览才能看出模式。例如 VIA1.ENCLOSURE 的 3,100 条违例，如果集中在三个 SRAM 宏单元周围，那问题很可能是宏单元引脚与顶层金属的连接方式，而不是 3,100 个独立错误。

四、Bulk Verify：批量确认与回归

Bulk Verify 解决的是“改完之后怎么快速确认”的问题。它的典型用法有两种：一是对一批已判定为可豁免的违例做批量 Waive，生成豁免文件供后续 DRC 复用；二是对修改后的版图重新跑 DRC，只关注之前标记的违例是否消失、是否引入新违例。Bulk Verify 通常配合一个违例列表文件使用，格式类似：

// bulk_waive.txt 示例
CHECK M1.SPACE.1
CELL u_core/u_alu/u_add
COORD 125.340 88.760
REASON "标准单元内部固定图形，已由库组确认"
CHECK VIA1.ENCLOSURE
CELL u_sram_512x32
COORD 402.115 210.880
REASON "宏单元引脚连接，已获项目批准"

批量豁免之后，重新跑 DRC 时用 -waive 选项加载该文件，结果库中这些违例会被标记为 waived 而不计入有效违例数。这样回归时看到的数字才是真正需要关注的。需要注意的是，豁免文件必须纳入版本管理，每次流片签核前要复核一遍，避免历史豁免掩盖了新引入的问题。

五、按区域与层次分类的实操判断

规则维度收敛之后，区域和层次维度用来定位根因。区域分类的常用做法是在版图上按功能块划分窗口（例如 core、IO、PLL、SRAM 区），统计每个窗口内的违例密度。密度异常高的区域往往对应布局拥塞、电源网格过密或宏单元摆放不当。层次分类则看违例在层次树上的分布：如果违例集中在某个叶子单元，优先修单元；如果分散在多个叶子单元但都出现在与同一父单元的连接处，优先修集成。

一个实用的判断顺序是：先按规则看数量，再按单元看集中度，最后按坐标看是否成簇。成簇的违例通常共享同一个根因，例如同一段金属走线过窄、同一组通孔 enclosure 不足、同一处 well 间距不够。逐条修成簇违例是效率最低的做法。

六、从违例到设计问题的判断依据

工具只是手段，最终要回答的是“这条违例对应什么设计问题”。常见的对应关系有几类：间距类违例（SPACE、ENCLOSURE）通常对应走线过密、通孔 enclosure 不足或 DRC 规则理解偏差；宽度类违例（WIDTH）对应线宽不满足工艺最小要求；密度类违例（DENSITY）对应金属或 poly 密度不均匀，可能需要加 dummy；天线类违例（ANTENNA）对应长金属走线在刻蚀过程中积累电荷，需要跳层或加二极管。判断时要把违例坐标和版图实际图形对照，确认是真实违反还是工具误报。

最后，把本节的分析流程固化成可复用的检查清单：打开结果库后先看 Check 数量分布，标记占比最高的 2～3 类规则；对每类规则按 Cell 展开，找出集中单元；用 RVE 抽查集中单元中的违例，确认坐标和层次路径；判断是单元问题还是集成问题；修改后重新跑 DRC，用 Bulk Verify 确认目标违例消失且未引入新违例。这套流程不依赖具体项目，换一个工艺节点或换一个设计，只是规则名和数量阈值需要重新标定。