4. DRC结果格式：结果数据库与ASCII报告的关键字段解析
DRC（Design Rule Check）运行完成后，工具会输出两种主流格式的结果文件：二进制结果数据库（DRC DB）和可读ASCII报告。理解这两种格式的结构与关键字段，是进行高效结果分析、规则优化与性能调优的基础。
4.1 DRC结果数据库（DRC DB）
DRC DB是EDA工具（如Calibre、ICV、PVS）生成的二进制文件，用于存储完整的几何检查结果、层次化违例信息及调试数据。其核心优势在于支持图形化浏览、逐条违例定位和交互式调试。
4.1.1 数据库结构层次
关键概念： DRC DB采用“检查项→违例组→违例实例→几何图元”的四层树状结构，便于按规则、按区域、按违例类型进行分级检索。
4.1.2 关键字段含义
在DRC DB中，每条违例记录包含以下核心字段，用于唯一定位违例并指导修复：
| 字段名称 | 数据类型 | 含义说明 | 示例值 |
|---|---|---|---|
| Check Name | String | 触发违例的DRC规则名称，对应规则文件中的检查项 | M1.S.1 |
| Violation ID | Integer | 全局唯一违例编号，用于索引和排序 | 102345 |
| Cell / Instance Path | String | 违例所在层次化实例路径，从顶层到叶子单元 | TOP/CPU_CORE/ALU_0 |
| Layer | String | 违例涉及的物理层名称（如金属层、通孔层） | M1 (Metal 1) |
| Coordinate | (X, Y) | 违例中心点或边界框的坐标（单位：nm/μm） | (12500, 34000) |
| Net Name | String | 违例涉及的信号网络名称（若可提取） | VDD / CLK_MAIN |
| Severity | Enum | 违例严重等级：Fatal / Error / Warning | Error |
| Measured Value | Float | 实际测量值（如间距、宽度、面积） | 0.045 μm |
| Required Value | Float | 规则要求的最小/最大值 | 0.050 μm |
实用技巧： 在Calibre RVE中，通过“Violation ID”和“Instance Path”可以快速跳转到版图对应位置；利用“Measured Value”与“Required Value”的差值，可快速判断违例严重程度，优先修复差值较大的违例。
4.2 ASCII报告格式
ASCII报告是纯文本格式的DRC结果摘要，通常包含违例统计、规则汇总和简要坐标信息。虽然不支持图形化交互，但因其轻量、可脚本化处理的特性，在批量回归测试、自动化报告生成和CI/CD流程中广泛使用。
4.2.1 典型ASCII报告结构
一份标准的DRC ASCII报告通常由以下五个部分组成：
- 头部信息：工具名称、版本、运行日期、设计名称、规则文件路径。
- 规则汇总表：列出所有被检查的规则名称、检查次数、违例总数。
- 违例详情列表：每条违例的规则名、坐标、层次路径、测量值。
- 违例统计摘要：按规则、按单元、按层分组的违例数量统计。
- 运行资源统计：CPU时间、内存峰值、总运行时间。
4.2.2 关键字段解析
以下是一个典型的ASCII报告片段及其字段说明：
----------------------------------------------------------------------
DRC Summary Report - Calibre v2023.3
Design: chip_top.gds
Rule Deck: 28nm_metal_drc.rul
Date: 2025-03-21 14:32:05
----------------------------------------------------------------------
Rule Name | #Checks | #Violations | Severity
--------------------+---------+-------------+---------
M1.S.1 (Min Space) | 125000 | 342 | Error
M1.W.1 (Min Width) | 98000 | 15 | Error
V0.E.2 (Min Encl) | 45000 | 89 | Warning
M2.S.1 (Min Space) | 112000 | 210 | Error
----------------------------------------------------------------------
Violation Details:
Rule: M1.S.1 | ID: 102345 | Cell: CPU_CORE/ALU_0
Layer: M1 | Coord: (12500, 34000) | Net: VDD
Measured: 0.045 um | Required: >= 0.050 um | Delta: -0.005 um
----------------------------------------------------------------------
Rule: M1.W.1 | ID: 102346 | Cell: CPU_CORE/REG_FILE
Layer: M1 | Coord: (45200, 67800) | Net: CLK
Measured: 0.048 um | Required: >= 0.050 um | Delta: -0.002 um
----------------------------------------------------------------------
Summary by Cell:
Cell Name | #Violations
--------------------+------------
CPU_CORE/ALU_0 | 120
CPU_CORE/REG_FILE | 85
MEM_CTRL | 67
----------------------------------------------------------------------
Resource Usage:
CPU Time: 2456.3 sec | Peak Memory: 8.2 GB | Total Runtime: 3120.5 sec
----------------------------------------------------------------------4.2.3 关键字段对照表
| ASCII字段 | 对应DB字段 | 解析要点 |
|---|---|---|
| Rule Name | Check Name | 规则名称通常包含层名和检查类型（如S=Space, W=Width, E=Enclosure） |
| #Violations | — | 该规则的总违例数，用于评估规则严重性 |
| Coord | Coordinate | 版图坐标，单位通常为数据库单位（如1单位=1nm） |
| Measured / Required | Measured Value / Required Value | Delta = Measured - Required，负值表示违例 |
| Cell | Cell / Instance Path | 层次化路径，用于定位违例所在的子模块 |
| Severity | Severity | Fatal/Error/Warning，决定是否阻断流片 |
4.3 两种格式的对比与选型建议
| 对比维度 | DRC DB（二进制数据库） | ASCII Report（文本报告） |
|---|---|---|
| 文件大小 | 较大（包含完整几何数据） | 较小（仅文本摘要） |
| 可读性 | 需专用工具（RVE/ICV Workbench） | 任何文本编辑器均可查看 |
| 交互调试 | 支持图形化定位、高亮、测量 | 不支持 |
| 脚本处理 | 需API解析（如Calibre PERL/Python API） | 可直接用grep/awk/sed/Python解析 |
| 适用场景 | 详细调试、版图修复、团队协作 | 批量回归、CI/CD、快速统计、邮件通知 |
常见误区： 不要仅依赖ASCII报告中的违例数量来判断规则是否“干净”。ASCII报告可能因报告截断（如max_violations_per_check限制）而遗漏部分违例。在最终签核（Sign-off）前，必须使用DRC DB进行完整验证。
4.4 从ASCII报告到DB的快速转换
在实际项目中，经常需要将ASCII报告中的关键信息映射回DRC DB进行详细调试。以下是一个典型的转换流程：
实战建议： 在CI/CD流程中，建议同时输出ASCII报告（用于快速统计和邮件通知）和DRC DB（用于失败时的详细调试）。通过脚本解析ASCII报告中的“Delta”字段，自动筛选出Delta值大于阈值的违例，生成高优先级修复列表，可显著提升调试效率。