3. Calibre运行环境与配置管理

Calibre 在后端物理验证流程中并不是一个“双击即用”的独立工具，它高度依赖运行环境变量、工艺库路径、规则文件（Rule File）以及版本控制策略。一个项目能否在本地顺利跑通、能否在 CI 上稳定复现，往往取决于这些配置是否被正确管理。本节围绕环境变量设置、工艺库与规则文件路径管理、版本控制策略、多项目配置隔离与复用方法四个层面展开，目标是让读者能够搭建一套可复现、可切换、可维护的 Calibre 运行环境。

一、环境变量：Calibre 的“启动开关”

Calibre 启动时会读取一组环境变量，用于定位可执行文件、许可证、工艺库和临时目录。最核心的几个变量如下：

• MGC_HOME：Calibre 安装根目录，例如 /opt/mentor/calibre/2023.4。所有二进制、库和默认规则模板都从这里派生。
• PATH：必须包含 $MGC_HOME/bin，否则 calibre、calibre -drc、calibre -lvs 等命令无法直接调用。
• LM_LICENSE_FILE 或 MGLS_LICENSE_FILE：指向许可证服务器，例如 27000@lic-server。许可证不可用时，Calibre 会在启动阶段直接报错退出。
• CALIBRE_TMPDIR：临时工作目录。DRC/LVS 运行过程中会产生大量中间文件，建议指向本地高速盘而非网络盘。
• CALIBRE_REALTIME：控制实时结果显示，CI 环境中通常设为 0 以避免图形依赖。

这些变量不应散落在个人 shell 配置中，而应集中写入项目级环境脚本。例如：

# env/calibre_env.sh
export MGC_HOME=/opt/mentor/calibre/2023.4
export PATH=$MGC_HOME/bin:$PATH
export LM_LICENSE_FILE=27000@lic-server
export CALIBRE_TMPDIR=/scratch/$USER/calibre_tmp
export CALIBRE_REALTIME=0

在 CI 中，该脚本由流水线在运行 Calibre 前 source 一次，确保本地与服务器环境一致。判断环境是否就绪，可以执行 calibre -v 查看版本，并用 which calibre 确认路径指向预期安装目录。

二、工艺库与规则文件路径管理

Calibre 的 DRC/LVS 运行依赖两类外部资源：工艺库（PDK）和规则文件。工艺库通常包含器件模型、层定义、GDS 参考单元等；规则文件则描述设计规则检查、版图与原理图一致性检查的具体命令。路径管理的关键是“不写死绝对路径”，而是通过变量拼接。

推荐做法是定义 PDK_ROOT 和 RULE_ROOT 两个变量，规则文件内部通过 $PDK_ROOT 引用工艺库。例如在规则文件头部：

# rule/calibre_drc.rule
LAYOUT PATH "$PDK_ROOT/tech/lef/tech.lef"
LAYOUT PRIMARY "top"
SOURCE PATH "$PDK_ROOT/models/device.scs"

这样同一份规则文件可以在不同项目、不同工艺节点间复用，只需切换 PDK_ROOT 的指向。路径管理还要注意三点：一是规则文件与 PDK 版本必须匹配，版本错配会导致层号错位或器件识别失败；二是路径中避免空格和中文，Calibre 对特殊字符处理并不友好；三是所有路径在 CI 中应使用绝对路径，避免因工作目录变化导致找不到文件。

三、版本控制策略

Calibre 配置的版本控制对象包括：环境脚本、规则文件、PDK 引用清单、运行脚本和结果归档策略。规则文件本身是文本，适合纳入 Git 管理；PDK 通常体积大且受 license 限制，不建议直接入库，而是记录版本号和校验值。

一个实用的策略是“配置入库、PDK 入清单”。在项目仓库中维护 config/pdk_version.yaml，记录 PDK 名称、版本、路径和 MD5。CI 在运行前校验实际 PDK 路径的 MD5 是否与清单一致，不一致则终止并提示。规则文件的修改必须走 Git 提交，提交信息中注明影响的检查类型（DRC/LVS/ANT/DFM）。对于 Calibre 版本，也应在环境脚本中固定 MGC_HOME，避免不同节点因版本漂移导致结果不可比。

四、多项目配置隔离与复用

当团队同时维护多个项目时，配置管理面临两难：完全隔离会导致重复维护，完全共用又容易互相污染。推荐采用“公共基线 + 项目覆盖”的分层结构：

• 公共基线层：存放 Calibre 环境脚本、通用运行框架、结果解析脚本，所有项目共享。
• 工艺层：按工艺节点划分，存放 PDK 引用清单和基础规则文件。
• 项目层：只存放项目特有的规则开关、顶层单元名、排除列表和运行参数。

运行时通过 source 顺序实现覆盖：先加载公共基线，再加载工艺层，最后加载项目层。项目层可以覆盖变量，但不修改上层文件。这样既保证了复用，又实现了隔离。判断隔离是否成功，可以检查同一规则文件在两个项目下运行时，LAYOUT PRIMARY 和 SOURCE PATH 是否分别指向各自项目，且互不影响。

五、配置检查清单与常见问题

在正式运行 Calibre 前，建议按以下清单逐项确认：

常见问题中，最典型的是“本地能跑、CI 跑不通”。多数情况是 CI 环境缺少 source 环境脚本，或 CALIBRE_TMPDIR 指向了不存在的路径。另一个高频问题是规则文件使用了相对路径，在 CI 中工作目录变化后找不到 PDK。解决方法是统一使用绝对路径，并在运行脚本开头打印关键变量值，便于日志排查。