极客工场

Appearance

共 2,047 字预计阅读约 7 分钟

No design configuration found (config.json/config.tcl)：OpenLane 找不到设计配置速查 ​

更新时间：2026-10-25。FAQ 速查页，属于开源 EDA 排错系列。按 OpenLane 首次跑通流程 自建第一个设计目录，敲下 flow.tcl -design <你的目录>，流程秒退——OpenLane 在你给的目录里没找到它要的配置文件。这篇讲清它到底在找什么、按什么顺序找，以及修好后要在 log 里看到什么。

答案块（赶时间先看这里）

  • 报错原文：[ERROR]: No design configuration (config.json/config.tcl) found in /designs/empty_design.
  • 环境：Ubuntu 22.04，OpenLane 官方 Docker 镜像，自建设计目录
  • 根因：三选一——-design 指错路径（含宿主机/容器路径没翻译对）、配置文件名写错（大小写/扩展名）、配置文件存在但缺 DESIGN_NAME 等必需键
  • 修复：对照「路径解析链」逐段核对，先 ls 确认容器视角下目录内容，再补配置文件
  • 验证：log 开头出现 [INFO]: Using configuration in '<目录>/config.json'... 即配置关已通过

本文要回答的问题 ​

  • OpenLane 在 -design 目录里到底找哪几样东西？config.json 和 config.tcl 什么关系？
  • 宿主机路径和容器内 /designs/xxx 是怎么对应上的？-v 挂载写错会怎样？
  • config.json 里哪些键是必需的？文件名大小写敏感吗？
  • 修复后跑通时，log 开头的「过关信号」长什么样？

一、报错原文与现象 ​

典型触发路径：新建了一个设计目录、RTL 还没拷进去（或者 -design 参数手滑指到了隔壁目录），跑 flow.tcl，OpenLane banner 打完就退出：

空设计目录实录：config.json/config.tcl 双双缺席，prep 阶段直接退出

这张实录有三处值得盯。第一，报错原文把话说得很全：No design configuration (config.json/config.tcl) found in /designs/empty_design.——它在这一层找的东西只有两样，-design 目录下的 config.json 或 config.tcl，一个都不在就报这个错，并把目录名原样告诉你。第二，traceback 显示抛出点是 prep 过程的第 123 行：prep 是 OpenLane 每次跑流程的准备阶段，配置探测是其中最靠前的动作之一，所以这类错误永远发生在 STEP 1 综合之前、启动几秒内。第三，注意这次 PDK 是正常导出的——banner 之后没有 PDK Root 的 INFO 行就直接报错，说明配置探测排在 PDK 校验打印之前；如果 PDK 侧也有问题，两类报错可能交替出现，PDK 根因的排查见姊妹篇 PDK sky130A not found 速查。

二、根因：-design 路径的三段解析链 ​

flow.tcl -design 后面跟的是容器内路径，不是你终端里的宿主机路径。中间隔着一道 docker run -v 挂载翻译：

eda/ts-openlane-no-config-json.md D2 示意图

颜色按角色分：蓝是你要核对的两端路径与挂载动作，灰是容器内的中性视角，橙是 OpenLane 的探测关卡，红是报错。读法一句话：-design 参数只在「容器内视角」这一环生效，宿主机路径全靠 -v 翻译。所以排查第一招永远是在容器视角下看一眼：

bash
docker run --rm -v /宿主机/设计目录:/designs/empty_design \
  efabless/openlane:<tag> ls -la /designs/empty_design

ls 出来是空的，而宿主机明明有文件——挂载源路径写错了；ls 报 No such file or directory——挂载映射整个没生效。先用这条命令把「路径问题」和「配置内容问题」切开，能省一半排查时间；确认目录内容后再回头看报错原文里的目录名是否就是这一个，两处对上才算闭环。

三、配置层三类错因对照清单 ​

路径对了、真正走到配置探测层之后，报错来历收敛为三种：

场景判别方法处置
目录里没有配置文件容器视角 ls 无 config.json/config.tcl从 OpenLane 自带设计（如 designs/spm）拷一份改，或按下方速查卡手写
文件名写错有 config.js、Config.json、config.TCL 之类改为全小写、完整扩展名；Linux 文件名大小写敏感
文件在但缺必需键log 过了配置关，后面报变量未定义补 DESIGN_NAME、VERILOG_FILES、CLOCK_PORT、CLOCK_PERIOD

两个文件都在时 config.json 优先（新格式），config.tcl 是旧格式兜底，日常只维护一份即可——两份并存还各自改，迟早出现「改了不生效」的灵异问题。第三类最隐蔽：文件存在、格式合法，OpenLane 也打印了 Using configuration in ...，但跑到综合才发现 DESIGN_NAME 没设、顶层模块对不上。判别特征是报错位置后移——不再是启动即退，而是某个 STEP 中途炸。配置文件宁缺勿滥：先只写必需键跑通最小流程，再逐项加约束，每加一项复跑一次，出问题能立刻定位到刚加的那一行。

四、修复示例：指回含 config.json 的目录，一次跑通 ​

把 -design 换回真正有 config.json 的 small_counter 目录复跑，log 开头立刻换了一副面孔：

exp-log
[INFO]: Using configuration in '../designs/small_counter/config.json'...
[INFO]: PDK Root: /home/ubuntu/.volare
[INFO]: Process Design Kit: sky130A
[INFO]: Standard Cell Library: sky130_fd_sc_hd
[INFO]: Optimization Standard Cell Library: sky130_fd_sc_hd
[INFO]: Run Directory: /designs/small_counter/runs/c7_fix
[INFO]: Saving runtime environment...
[INFO]: Preparing LEF files for the nom corner...
[INFO]: Preparing LEF files for the min corner...
[INFO]: Preparing LEF files for the max corner...
[INFO]: Running linter (Verilator) (log: ../designs/small_counter/runs/c7_fix/logs/synthesis/linter.log)...
[INFO]: 0 errors found by linter
[INFO]: 0 warnings found by linter
[STEP 1]
[INFO]: Running Synthesis (log: ../designs/small_counter/runs/c7_fix/logs/synthesis/1-synthesis.log)...
[STEP 2]
[INFO]: Running Single-Corner Static Timing Analysis (log: ../designs/small_counter/runs/c7_fix/logs/synthesis/2-sta.log)...
[STEP 3]
[INFO]: Running Initial Floorplanning (log: ../designs/small_counter/runs/c7_fix/logs/floorplan/3-initial_fp.log)...

这段实录的读法：第一行 Using configuration in ... 就是配置关的过关章——它告诉你 OpenLane 读的是哪个文件，路径与预期不符时这里也会第一个露馅。随后 PDK Root、标准库、Run Directory 三行把运行上下文钉死，linter 0 errors / 0 warnings 之后进入 STEP 1 综合，流程一路穿过布局布线、时钟树、寄生提取，直抵 signoff 阶段的 STA 与 IR drop 分析（完整记录见实验环境一节的修复日志）。修复前后唯一的差别，就是 -design 参数从空目录指回了含 config.json 的目录。

OpenLane 设计配置速查：一个目录两个文件四个键

速查卡按语义分四色：红区是缺一即报错的文件层，蓝区是文件里必须出现的四个键，橙区是高频踩坑的错名形式，绿区是修好后要在 log 里核对的确认信号。日常建议：新设计从 OpenLane 仓库自带设计拷骨架（自带 config.json 与 src/ 目录），改 DESIGN_NAME 与 VERILOG_FILES 两个键就能跑，比从零手写少踩八成的坑；要加时钟约束、管脚约束时，也是以这份骨架为底往上叠，不要平地起楼。

五、验证与防复发 ​

修复后按顺序确认三件事：

bash
docker run --rm -v /宿主机/设计目录:/designs/xxx efabless/openlane:<tag> ls /designs/xxx   # 容器视角目录内容对
grep -E 'DESIGN_NAME|VERILOG_FILES' config.json   # 必需键都在
# 复跑 flow.tcl，log 前 10 行应出现 Using configuration in 与 PDK Root 两行 INFO

防复发两条纪律：一是团队内固化设计目录模板（config.json + src/ + README），新设计一律 cp -r 模板再改，杜绝手写文件名；二是跑 flow.tcl 前先跑容器内 ls 那条一条命令的预检，把挂载/路径错误挡在流程启动之前。PDK 侧的环境预检（PDK_ROOT 与挂载对齐）同理，见 PDK sky130A not found 速查。

实验环境 ​

  • 机器/系统：云主机 / Ubuntu 22.04（eda-golden-v1 镜像）
  • 工具版本：OpenLane d054702b（efabless/openlane 镜像），volare 管理 sky130A
  • 日期：2026-10-25
  • 完整命令：docker run --rm -v /tmp/errlog-evidence/src/empty_design:/designs/empty_design ... ./flow.tcl -design /designs/empty_design -tag c7_err -overwrite（空目录复现报错）；docker run --rm -v /tmp/eda-golden/labs/openlane-small:/designs/small_counter ... ./flow.tcl -design /designs/small_counter -tag c7_fix -overwrite（指回含 config.json 的目录后跑通至 signoff）

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

本篇是开源 EDA 排错簇中「设计配置/路径」节点的 FAQ 页，上承 OpenLane 首次跑通流程（自建设计目录的标准结构），与 PDK sky130A not found（启动阶段另一道高发门禁）互为姊妹篇——两者共享「报错原文里的路径就是第一线索」这一核心认知；商用工具侧同类「文件找不到」排查见 Design Compiler path not found。

一句话总结 ​

No design configuration found (config.json/config.tcl) 的本质是 OpenLane 在 prep 阶段于 -design 的容器内路径下找不到 config.json 与 config.tcl 中任何一个：排查先按「宿主机目录 → -v 挂载 → 容器内路径」三段链用容器内 ls 切开路径问题，再按「文件缺失 / 文件名错 / 缺 DESIGN_NAME 等必需键」三类收敛；修复后 log 第一行 Using configuration in ... 加随后的 PDK Root、Run Directory 就是过关信号，流程随即进入 STEP 1 综合直抵 signoff。