3. 制造规则问题诊断的数据准备
在 Calibre 版图制造规则诊断中，绝大多数“规则明明写对了却报错”或“该报的错没报”的问题，根源并不在规则语句本身，而在于输入数据之间的依赖关系被破坏。一次完整的 DRC 运行，本质上是把五类输入按固定依赖顺序装配成一个可执行的检查环境：版图数据（GDS/OASIS）、层映射（Layer Map）、规则文件（Rule File）、工艺文件（Process/Technology File）以及运行选项（Runset Options）。任何一类输入与其它输入不一致，都会在结果层表现为误报（False Error）或漏报（Missing Error）。
先建立依赖关系的整体认识。版图数据只提供“几何图形 + 层号/数据类型号”这一层信息，它本身不知道哪一层是 Poly、哪一层是 Contact。层映射负责把版图里的 (layer, datatype) 二元组翻译成规则文件能识别的逻辑层名。规则文件用逻辑层名书写检查语句，例如“Poly 与 Contact 的最小间距”。工艺文件则提供规则文件引用的工艺参数，如最小线宽、最小间距、各层厚度与电阻值。运行选项决定用哪个规则文件、哪个层映射、哪个工艺文件、以什么模式（flat/hierarchical）运行。这五者的关系可以用下面的依赖图表示。
从图中可以看到，层映射是版图数据与规则文件之间的“翻译层”，工艺文件是规则文件的“参数供给层”，运行选项则是整个装配过程的“调度层”。诊断输入不一致，就是沿着这些箭头逐一核对。
一、层映射不一致：最常见的误报来源
层映射文件通常以 layer_map 语句书写，格式为 layer_map = <layer> <datatype> <logical_name>。假设版图数据中 Poly 层实际是 layer 5 datatype 0，而层映射文件里写成了 layer 5 datatype 1，那么规则文件里所有引用 Poly 的检查都会作用在空层上。结果是：本该报出的 Poly 间距违规全部漏报，而某些依赖 Poly 存在的检查可能因为空层产生异常几何而误报。
排查方法很直接：用 calibre -drc -hier -layer_map layer.map 加载后，在日志中搜索 Layer map 段落，确认每个逻辑层名对应的实际 (layer, datatype) 与版图数据一致。更可靠的做法是先用 calibre -drc -hier -dump_layers 导出实际层号清单，再与层映射文件逐行比对。常见错误包括：datatype 写错、逻辑层名拼写不一致、同一逻辑层被映射到多个物理层、以及层映射文件里缺少规则文件引用的某个逻辑层。
二、规则文件与工艺文件的参数脱节
规则文件中的检查语句通常引用工艺文件里的变量，例如 @poly_min_width、@contact_min_space。如果工艺文件被替换成另一个工艺节点的版本，而规则文件没有同步更新变量名或变量值，就会出现两种后果：变量名不存在时 Calibre 直接报语法错误；变量名存在但数值不匹配时，检查阈值被悄悄改变，导致误报或漏报。例如工艺文件里 @poly_min_width = 0.18，而规则文件按 0.13 工艺编写，实际检查就会用 0.18 去卡 0.13 的版图，产生大量误报。
排查时应在规则文件开头找到 #include 或 INCLUDE 语句，确认它引用的工艺文件路径和版本号。然后在 Calibre 日志中搜索 Variable 或 @ 开头的变量赋值记录，核对关键阈值是否与当前工艺节点一致。一个实用的做法是把工艺文件中的变量清单导出成表格，与规则文件中所有 @ 引用做交叉比对，确保没有“引用了但未定义”或“定义了但值不对”的项。
三、运行选项导致的加载错位
运行选项中最容易出问题的是文件路径和运行模式。如果 runset 中 -layer_map 指向了旧项目的层映射文件，而版图数据来自新项目，层映射就会整体错位。同样，-hier 与 -flat 的选择会影响层次化单元的展开方式，某些在 flat 模式下能报出的跨单元违规，在 hier 模式下可能因为单元边界处理不同而漏报。此外，-turbo 模式对某些复杂规则的支持有限，若规则文件里使用了 turbo 不支持的语句，Calibre 可能跳过该检查而不报错，造成漏报。
排查运行选项时，应先在日志开头确认实际生效的选项列表，而不是只看 runset 文件里写了什么。Calibre 会在日志中回显最终解析后的命令行参数。重点核对：-layer_map 路径、-rule 路径、-hier/-flat 模式、以及是否有 -turbo 与规则文件不兼容的警告。如果日志中出现 Warning: Rule ... not supported in turbo mode，就说明该规则被跳过了，必须切换模式重新运行。
四、输入一致性检查清单
把上述排查点整理成一份可执行的检查清单，每次诊断前按顺序过一遍，可以大幅减少因输入不一致导致的误报与漏报。
| 检查项 | 核对内容 | 不一致的典型后果 |
|---|---|---|
| 版图数据 vs 层映射 | 每个逻辑层对应的 (layer, datatype) 是否与 GDS/OASIS 实际层号一致 | 空层检查 → 漏报；异常几何 → 误报 |
| 层映射 vs 规则文件 | 规则文件引用的逻辑层名是否都在层映射中有定义 | 未定义层名 → 语法错误或跳过检查 |
| 规则文件 vs 工艺文件 | 规则中所有 @变量是否在工艺文件中定义，数值是否匹配当前工艺节点 | 阈值偏移 → 误报或漏报 |
| 运行选项 vs 实际文件 | -layer_map、-rule、-hier/-flat、-turbo 是否与当前项目匹配 | 加载旧文件 → 整体错位；模式不兼容 → 跳过检查 |
| 日志回显 vs runset 文件 | 日志中实际生效的选项是否与 runset 中书写的一致 | 路径被覆盖或变量被重定义 → 隐性不一致 |
Reading layer map、Reading rule file、Reading process file 三个关键行，确认每个文件的实际加载路径和版本。如果某个文件没有被加载，日志中不会出现对应行，这本身就是输入缺失的信号。
CALIBRE_LAYER_MAP）也可能影响加载结果。排查时必须以日志回显为准。
总结来说，输入数据不一致导致的误报与漏报，几乎都可以沿着“版图数据 → 层映射 → 规则文件 ← 工艺文件，运行选项控制全部”这条依赖链定位。诊断时先确认日志中实际加载了哪些文件、以什么模式加载，再逐层核对层号、逻辑层名、变量值和运行模式。把这份检查清单固化为每次 DRC 诊断前的标准动作，就能把大量“规则问题”还原为“输入问题”，从而快速排除误报与漏报。