极客工场

Appearance

共 2,569 字预计阅读约 9 分钟

Calibre 模块/单元找不到：Cannot open include file 速查 ​

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。Calibre 做 DRC/LVS/PEX 时说的「模块/单元找不到」和数字仿真器完全不是一套机制：它不读 filelist，也没有 +incdir+，它按 SVRF rule deck 里的 INCLUDE 指令找规则文件，按 runset 里的 LAYOUT PRIMARY/SOURCE PRIMARY 找顶层 cell，LVS 再按名字把版图器件与源网表/PDK 库对上。接新工艺、换 PDK 版本、从 Windows 共享目录搬工程后，这类报错最先冒出来。Calibre 验证流程全貌见 Calibre 物理验证实操，rule deck 内部结构见 Calibre SVRF rule deck 解剖，本篇只做报错收敛。

本文要回答的问题 ​

  • Calibre transcript 里的 Cannot open include file 断在哪一层，怎么修？
  • GDS 里明明有顶层，为什么 LVS 说 layout cell 找不到？
  • LVS 报告里器件 cell「not found in source」是网表错还是 PDK 库没喂对？
  • PEX 阶段报 model file 缺失和 DRC 阶段的 include 失败是不是一回事？
  • 大小写、路径空格这类低级问题在 Calibre 下长什么样？

一、报错原文与典型现象 ​

Calibre 的报错分四段冒出来，先认出每段的典型形态，再决定查哪里。以下是常见 transcript（.drc.results/.lvs.report/pex_*._x.log）里的典型文案，工程名已占位：

1. rule deck 的 INCLUDE 失败（DRC/LVS/PEX 一启动就断，最靠前）：

text
***** ERROR: Cannot open include file "$PDK_DIR/calibre/common/stack.svrf".
***** ERROR: [INCLUDE] cannot open include file /opt/pdk/Calibre/drcRules.svrf

2. 版图顶层 cell 名与 runset 指定的 PRIMARY 不一致：

text
Warning: LAYOUT PRIMARY "TOP_CHIP" does not match the top cell "top_chip" in layout.
Error: Layout cell "TOP_CHIP" was not found in the layout database.

3. LVS 网表里引用的器件 cell 在源侧库里找不到：

text
Error: Instance "u_core/u_pll" references cell "PLL300M" which was not found in source.

这类信息也常以汇总形式出现在 .lvs.report 的器件/单元对照清单里（未识别器件、source 与 layout 两侧对不上的 cell），口径见 LVS 器件识别与抽取。

4. PEX 模型或 corner include 文件缺失：

text
***** ERROR: Could not open model file "/opt/pdk/models/spectre/rc_typical.s"
***** ERROR: PEX model include file not found: corner_tt.inc

一句话根因：Calibre 按「字符串路径」和「字符串名字」办事——rule deck 展开时按文件系统真实路径找 include，读 GDS/OASIS 时按库里真实 cell 名找顶层，LVS 按网表里的器件名找 PDK 库定义，PEX 按 runset 找模型文件。四个阶段共用同一条病根：你给的名字和磁盘/数据库里真实存在的名字对不上，而不是某个文件没加进编译列表。

二、排查决策树 ​

下面这张决策树按 Calibre 的启动顺序分叉：先确认 deck 能否展开，再确认顶层 cell 能否对上，最后才查器件库与模型，任何一条命中就在那一层修，不要跳着改 runset。

eda/ts-calibre-module-not-found.md D2 示意图

读这张图抓住「先后」二字：第①层不过，后面所有检查都无意义——deck 根本没展开完，Calibre 用到的规则集是残的；第②层管顶层入口，PRIMARY 写错时版图读进来一个空层次或错层次；第③层才进入器件与寄生参数语义。三个蓝色判定节点对应三类报错原文，绿色收敛节点是统一的复验动作。

三、原因速查表 ​

报错现象可能原因处置
Cannot open include file，路径里带 $PDK_DIR 原样字样环境变量没 export，SVRF 里变量未展开shell 里 echo $PDK_DIR 验证后再启动 calibre
include 的是相对路径，换目录启动就失败相对路径基准是启动目录而非 deck 所在目录runset/启动脚本里先 cd 固定工作目录，或改绝对路径
报 MGC_HOME/CALIBRE_HOME 相关文件找不到Calibre 环境脚本未 source，安装根失效source 对应 setup 脚本，which calibre 核对
Layout cell was not found in databaseGDS 顶层真实名与 LAYOUT PRIMARY 大小写/拼写不符用 strmclip/版图工具查真实 top cell，改 PRIMARY
LVS 报某器件 cell not found in source源网表漏 include、PDK 器件库路径缺失或版本不对补 SOURCE PATH/include，核对 PDK 版本与 LVS 开关
PEX Could not open model file模型库未安装或 runset 指向旧工艺角目录安装模型包，改 PEX model 相关路径变量
手工跑能过，脚本/nohup 跑就找不到非交互 shell 不加载 .bashrc，环境变量缺失启动脚本显式 source PDK 环境，不依赖登录环境
路径含空格或中文目录SVRF/runset 中未加引号，路径被截断路径整体加双引号，规范上不在工程路径放空格

四、逐条排查展开 ​

第一步：验证环境变量在「启动 calibre 的那个 shell」里真的有值。 这是占比最高的一类。SVRF deck 里常见 INCLUDE "$PDK_DIR/calibre/common/stack.svrf" 写法，变量不展开时，报错路径里能看到字面的 $PDK_DIR，这是一眼判据：

bash
echo "$MGC_HOME / $CALIBRE_HOME / $PDK_DIR"
ls -l "$PDK_DIR/calibre/common/stack.svrf"

交互终端里有值、回归脚本里没有，几乎都是非交互 shell 不加载环境文件。修法是在批处理脚本开头显式 source 厂商/PDK 提供的 setup 脚本，而不是假设调度系统继承了你桌面的环境。顺带用 ls -l 证明文件真实存在且当前用户可读——挂载点没起来、权限不对，报错文案一模一样。

第二步：核对 INCLUDE 的相对路径基准。 SVRF 的相对 include 以 calibre 进程的当前工作目录解析，不是以 rule deck 文件所在目录解析。同一个 deck，在工程根启动能过、换个目录就 cannot open，就是这个原因。团队纪律：启动命令前固定 cd 到工程 run 目录（见 Calibre 物理验证实操 的 run 目录组织），PDK 提供的公共 deck 段尽量用 $PDK_DIR 绝对锚定。

第三步：让 PRIMARY 与 GDS/OASIS 真实顶层名逐字符对齐。 runset 里的关键四行是 LAYOUT PATH/LAYOUT PRIMARY 与 SOURCE PATH/SOURCE PRIMARY。流片交接时 GDS 顶层被改名（top_chip 变 TOP_CHIP、或带了版本后缀 top_chip_final）是常态，而 runset 没人同步。用 strmclip 或在版图工具里列出库中真实 cell 名，按磁盘上的名字改 PRIMARY，别反过来去改 GDS。GDS/OASIS 数据交接背景见 GDS 与 OASIS 格式差异，层次对不上的延伸问题见 LVS 层次不一致调试。

第四步：LVS 器件 cell 找不到，先分「网表侧」还是「库侧」。 报错名是你自己的模块（如 PLL300M），多半是源网表导出时漏了该模块、或 SOURCE PATH 没把对应网表片段包全；报错名是 PDK 器件（工艺厂的 mos/res/cap 单元），则是 PDK 的器件识别文件、device library 路径或 LVS 开关与当前 deck 版本不配套。判据很硬：在源网表文件里 grep 报错的 cell 名，grep 得到走路径问题，grep 不到回数字设计侧补网表。器件识别机制本身见 LVS 器件识别与抽取。

第五步：PEX model missing 单独看。 PEX 在 DRC/LVS 之后才读晶体管级模型与 corner 文件（Spectre/HSPICE 模型、corner_*.inc 一类 include），它依赖的是 PDK 模型包，而不是 rule deck 包。常见情形是装了 DRC/LVS 的 deck 却没装模型库，或 runset 里工艺角路径还指向上一版 PDK。对照工艺厂安装清单确认模型目录存在，改 runset 中模型路径后只重跑 PEX 阶段验证。PEX 全流程见 模拟版图 PEX 与后仿。

第六步：大小写与路径空格。 Linux 文件系统大小写敏感：GDS 内 cell 为 nand2、runset 写 NAND2，Windows 上的共享盘能混过去，Linux 服务器直接报找不到。路径含空格时未加引号的字符串会在空格处截断，报错路径明显短一截。处置是路径加双引号、并把工程统一放在无空格纯英文目录下——这条规范在团队层面固化，比逐次救火便宜。

五、预防与纪律 ​

  • 环境自检前置：回归脚本第一段固定打印 MGC_HOME/CALIBRE_HOME/PDK_DIR 并 ls 关键 deck 与模型文件，任一失败立即退出，不把环境问题带进几百行 transcript。
  • runset 随工程版本走：LAYOUT PRIMARY/SOURCE PRIMARY 与顶层改名放在同一个变更里评审，GDS 改名不改 runset 是交接事故的固定形态。
  • PDK 升级整包换：deck、器件识别文件、PEX 模型按工艺厂声明的配套版本一起切，不混目录引用新旧两套。
  • 报错原文先存档：把首次失败的完整 transcript 留存，改一处重跑一次；cannot open 一族的报错行本身就带路径，原文即证据，别凭记忆转述。
  • 干净目录复验：修完删掉本轮 run 目录重跑一次完整 calibre -drc/-lvs/-pex，确认 transcript 里 0 Error 再往下走，避免增量产物掩盖问题。

这一篇在知识体系里的位置 ​

本篇是 EDA 排错速查簇的一员，总入口见 开源 EDA 报错排错中心；上游是 Calibre 物理验证实操 与 Calibre SVRF rule deck 解剖，综合侧同类「按名字找定义」问题的对照阅读见 Design Compiler 模块找不到速查；器件识别与层次问题分别延伸到 LVS 器件识别与抽取 和 LVS 层次不一致调试。

一句话总结 ​

Calibre 的「模块/单元找不到」本质是字符串对不上：deck 展开时按真实文件路径找 INCLUDE（先查 MGC_HOME/PDK_DIR 与相对路径基准），读版图时按真实 cell 名对 LAYOUT/SOURCE PRIMARY，LVS 按器件名查源网表与 PDK 库，PEX 另查模型包；按「deck → 顶层 → 器件 → 模型」的启动顺序分段收敛，配合环境自检前置、runset 随改名同步、干净目录复验三条纪律，这类报错基本不会跨轮次残留。