4. DRC规则调试与错误分析
DRC（Design Rule Check）签核的难点往往不在“跑不跑得通”，而在于拿到一份动辄数万条的结果数据库后，如何快速判断哪些是真实违规、哪些是工具误报、哪些是规则本身写错导致的漏报。本节以 Pegasus 为工具背景，围绕“读结果—定位图形—分类排序—排查误报漏报”这条主线，结合一个实际案例展开。
一、先理解 DRC 结果数据库的结构
Pegasus 运行 DRC 后，默认会生成一个结果数据库（results database），常见形式是 ASCII 的 .sum 汇总文件加一个逐条记录的 .db 或 .rpt 文件，也可通过 -db 选项输出为可被图形界面加载的格式。每条违规记录通常包含以下字段：
- 规则名（rule name）：如
M1.SPACE.1、VIA.ENCLOSURE.2，直接对应规则文件中的检查项。 - 违规类型（check type）：间距（space）、宽度（width）、包围（enclosure）、密度（density）、天线（antenna）等。
- 坐标（bbox / polygon）：违规图形的边界框或实际多边形顶点，是定位的关键。
- 层号（layer）：如 M1、M2、VIA1、POLY。
- 严重级别（severity）：部分流程会区分 error / warning。
理解这些字段后，才能用命令行做聚合统计。例如按规则名统计违规数量：
# 统计各规则违规条数，按数量降序
grep -E "^RULE" drc.rpt | awk '{print $2}' | sort | uniq -c | sort -nr
# 提取某条规则的所有坐标，便于批量定位
grep "M1.SPACE.1" drc.rpt | awk '{print $4, $5, $6, $7}' > m1_space1_coords.txt这一步的价值在于：把“几万条错误”压缩成“十几类问题”，后续调试才有优先级可言。
二、用图形界面定位违规图形
Pegasus 提供图形化结果查看器（如 Pegasus Results Viewer 或与 Virtuoso 集成的 DRC 结果浏览器）。加载结果数据库后，界面通常分为三层：左侧规则树、中间版图视图、右侧违规详情。操作要点如下：
- 在规则树中勾选某条规则，版图视图会高亮所有该规则的违规位置，通常用红色或橙色标记。
- 双击某条记录，视图自动缩放到对应坐标，并显示违规多边形的实际形状。
- 结合层显示开关，只打开相关层（如仅 M1 和 VIA1），避免被无关图形干扰。
- 对疑似误报的记录，可叠加显示规则要求的“最小间距参考线”，判断实际间距是否真的小于规则值。
图形界面的优势是直观，但面对上万条记录时效率有限。因此实际工程中常用“命令行筛选 + 图形界面精查”的组合：先用命令行把可疑规则缩小到几十条，再逐条在界面中确认。
三、错误分类与优先级排序
拿到违规清单后，建议按以下维度分类：
| 分类维度 | 典型示例 | 处理优先级 |
|---|---|---|
| 规则类型 | 间距、宽度、包围、密度 | 间距/包围优先，密度可后置 |
| 所在层 | M1、M2、VIA、POLY | 底层金属和通孔优先 |
| 是否可自动修复 | 可通过 ECO 或脚本修复 | 可自动修复的先批量处理 |
| 是否误报 | 规则边界条件、工具版本差异 | 确认后直接 waive |
优先级排序的核心原则是：先处理会影响后续流程的硬违规，再处理可 waive 的软违规。例如 M1 间距违规可能导致短路，必须优先；而某些密度违规在最终填充后可能自动消失，可放到最后。
四、常见误报与漏报的排查方法
误报（false positive）常见原因有三类：
- 规则边界条件写错：例如规则要求“间距 ≥ 0.1μm”，但脚本中用了
<而非<=，导致恰好等于 0.1μm 的图形被误判。排查方法是查看规则文件中的比较运算符，并用一个已知合规的测试图形验证。 - 层映射错误：规则文件中的层号与版图实际层号不一致，导致检查了错误的图形。排查方法是核对
layer map文件，并在图形界面中确认高亮图形是否属于预期层。 - 工具版本差异：不同版本 Pegasus 对同一规则的解释可能不同。排查方法是查看工具 release note，或用同一份版图在两个版本下跑对比。
漏报（false negative）更危险，因为会导致流片失败。常见原因包括：
- 规则未启用：规则文件中某条检查被注释掉或条件判断跳过。排查方法是检查规则文件的
if条件，确认所有必要规则都已执行。 - 图形被忽略：某些图形因属性或层级被工具跳过。排查方法是在图形界面中手动测量该处间距，与规则值对比。
- 结果数据库截断：当违规数量超过工具默认上限时，部分记录可能被丢弃。排查方法是查看
.sum文件中的总数与.rpt中实际记录数是否一致。
.sum 中的总违规数与 .rpt 行数是否匹配，再开始逐条分析。这一步能提前发现漏报风险。五、一个实际案例的调试过程
假设某 28nm 项目 DRC 报告显示 M1.SPACE.1 有 320 条违规。按以下步骤处理：
- 用命令行统计，发现其中 280 条集中在同一坐标区域，疑似同一处图形阵列。
- 在图形界面中加载该区域，发现是一组标准单元边界处的 M1 走线，实际间距为 0.098μm，规则要求 0.1μm，确实违规。
- 进一步检查规则文件，发现该规则未排除标准单元内部图形，导致单元边界处的合法图形被误判。修改规则，增加
NOT INSIDE STD_CELL条件后重新运行，违规数降至 40 条。 - 剩余 40 条经图形界面确认，其中 35 条为真实间距违规，通过调整走线修复；5 条为工具对斜边图形的近似计算误差，经与 foundry 确认后可 waive。
这个案例说明：先分类、再定位、后修复，比逐条盲目修改效率高得多。规则本身的调试往往比修版图更能减少违规数量。
最后强调一点：DRC 调试不是一次性动作，而是一个“运行—分类—定位—修正—重跑”的闭环。每次重跑后，应对比违规数量的变化趋势，确认修改是否真正收敛。如果某条规则反复出现且数量不降，往往说明规则本身或版图设计存在系统性问题，需要回到规则文件或设计约束层面排查，而不是继续逐条修图形。