📚 课程目录第2章 Calibre运行环境与目录规划

2. Calibre运行环境与目录规划

Calibre 物理验证并不是“装好软件就能跑”的独立工具，它依赖一整套运行环境：Linux 操作系统与 Shell 环境、License 服务、工艺库（PDK）与规则文件（Rule Deck）、以及项目级的目录与版本管理。环境规划得好，后续跑 DRC/LVS 时问题大多集中在版图和规则本身；规划得差，则会把大量时间消耗在“找不到文件、License 抢不到、版本对不上”这类非设计问题上。本节围绕这四件事展开，并给出可直接落地的目录结构与配置示例。

一、Linux 环境准备

Calibre 主流运行在 64 位 Linux 上，常见发行版为 RHEL/CentOS 7.x、Rocky Linux 8/9 等。核心要求是：足够的 CPU 核数与内存（DRC/LVS 支持多线程与分布式）、稳定的共享存储（NFS 或并行文件系统）、以及正确的 Shell 与工具链。Calibre 的启动脚本依赖 csh/tcsh 或 bash，建议统一使用 bash 并在登录脚本中集中管理环境变量。

典型的环境变量包括：MGC_HOME 指向 Calibre 安装根目录，PATH 追加 $MGC_HOME/bin，MGC_LICENSE_FILE 或 LM_LICENSE_FILE 指向 License 服务器。示例：

export MGC_HOME=/eda/mentor/calibre/2023.4
export PATH=$MGC_HOME/bin:$PATH
export MGC_LICENSE_FILE=27020@lic-eda-01
export CALIBRE_TMPDIR=/scratch/$USER/calibre_tmp

其中 CALIBRE_TMPDIR 常被忽略，但非常关键：Calibre 运行时会生成大量临时文件，若默认落在 /tmp 或用户 home，容易撑爆分区或拖慢速度。建议指向本地高速盘或独立 scratch 分区，并按用户隔离。此外，多线程运行需设置 MGC_NUM_CPUS 或通过 -turbo 参数控制，避免单用户占满全部核数影响他人。

二、License 配置

Calibre 使用 FlexLM 授权。服务器端运行 lmgrd 与 mgcld，客户端通过 MGC_LICENSE_FILE 指向端口与主机。配置要点有三：一是 License 文件中的 SERVER 行主机名必须与服务器实际主机名一致，否则会报 “Invalid host”；二是防火墙需放行对应端口（如 27020）；三是区分功能特性（feature），例如 calibre_drc、calibre_lvs、calibre_pex 是不同 feature，抢不到对应 feature 时任务会直接失败。

排查 License 问题最常用的命令是 lmstat：

lmstat -a -c 27020@lic-eda-01
# 查看 calibre_drc 的已用/总数
lmstat -f calibre_drc -c 27020@lic-eda-01

若显示 “Users of calibre_drc: (Total of 20 licenses issued; Total of 20 in use)”，说明已满，需要排队或申请扩容。建议在项目脚本中加入 License 检查与重试逻辑，而不是让任务直接崩溃。

三、工艺库与规则文件目录结构

PDK 与 Rule Deck 是物理验证的“输入标准”。PDK 通常包含器件模型、版图 PCell、层定义（layer map）、以及 DRC/LVS 规则文件。规则文件往往按工艺节点、版本、金属层数组织。推荐采用“只读共享 + 项目引用”的结构，避免每个项目复制一份导致版本混乱：

/eda/pdk/
  /tsmc28/
    /hpc_1p9m/
      /1.3a/            # PDK 版本
        techfile.tf
        layermap.txt
        /calibre/
          drc/  lvs/  pex/
/eda/rule_deck/
  /tsmc28_hpc/
    /drc_1.3a_20240115/
    /lvs_1.3a_20240115/

项目侧只保存“指向哪个版本”的配置，而不是文件本体。这样 PDK 升级时只需改一处引用，所有项目可统一切换或按需锁定。

四、项目级与版本化管理策略

建议每个项目建立独立工作区，内部按 run、scripts、results、logs 划分。每次验证生成一个带时间戳或流水号的 run 目录，规则文件版本、Calibre 版本、输入 GDS 版本都记录在 run 的配置文件中，保证结果可追溯、可复现。版本管理上，脚本与配置纳入 Git；GDS、结果库等大文件用版本号或数据管理系统管理，不直接进 Git。

五、可执行的 run 配置示例

把上述策略落成一个可复用的 run 配置，是本节最实用的交付物。下面给出一个 run.cfg 示例，字段只保留物理验证真正需要的版本与路径信息：

# run.cfg —— 单次 Calibre DRC 运行的环境与版本锁定
RUN_ID      = 20240612_drc_v3
CALIBRE_VER = 2023.4
PDK_ROOT    = /eda/pdk/tsmc28/hpc_1p9m/1.3a
DECK_DRC    = /eda/rule_deck/tsmc28_hpc/drc_1.3a_20240115
GDS_IN      = /proj/chipA/gds/chipA_top_v3.gds
TOP_CELL    = chipA_top
LAYER_MAP   = $PDK_ROOT/layermap.txt
TMPDIR      = /scratch/$USER/calibre_tmp
NUM_CPUS    = 8
LICENSE     = 27020@lic-eda-01

运行时由脚本读取该配置并拼出命令，例如：

calibre -drc -hier -turbo $NUM_CPUS \
  -dp $TMPDIR \
  $DECK_DRC/drc.cal \
  -gds $GDS_IN -top $TOP_CELL \
  -layer_map $LAYER_MAP \
  2>&1 | tee logs/$RUN_ID.drc.log

判断运行是否成功，先看日志末尾是否出现 “Total Results = 0” 或具体违例数，再看是否生成 drc.results 与 summary 报告。若日志中出现 “Unable to checkout license” 或 “Cannot open rule file”，则分别回到 License 与路径引用两处排查，而不是盲目重跑。

建议把 run.cfg 与调用脚本一起纳入 Git，每次运行提交一次；GDS 与结果库用版本号命名并归档到数据管理系统。这样任何一个历史 run 都能凭 RUN_ID 还原出当时的 Calibre 版本、PDK 版本、Rule Deck 版本与输入 GDS，实现真正的可复现验证。

总结来看，Calibre 运行环境规划的核心是“分离”：环境变量与 License 属于平台层，PDK 与 Rule Deck 属于只读共享层，项目工作区属于可写层，三者通过引用而非复制连接。目录结构一旦稳定，后续所有 DRC/LVS/PEX 任务都只是在这套骨架上生成新的 run 目录，版本管理与问题定位都会变得清晰可控。