极客工场

Appearance

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

OpenLANE -from/-to 断点续跑报错：老教程参数失效与 interactive 状态恢复速查 ​

更新时间：2026-11-05。报错排查篇，属于 EDA 报错排查系列。网上大量 OpenLane 1.x 老教程还在写 flow.tcl -design xxx -from floorplan 这类断点续跑命令，照着敲只会得到一行 -from and -to are no longer supported.。这不是你环境装坏了，而是参数本身在 2023.07 版本被整体移除。本篇用同一台机器上跑出的四个对照场景，讲清新版本「分步跑」的状态到底存在哪里、跳步为什么会读出一张空网表，以及重跑一个已存在 tag 时该怎么处理。

首屏答案：OpenLane 2023.07.19 已经没有跨命令续跑开关，-from/-to 一敲就报错；分步执行的唯一合法姿势是在同一个 -interactive 会话进程内按顺序发 run_synthesis、run_floorplan 等命令，流程状态只活在这个进程的内存里，会话退出即失效。新开一个会话、换新 tag 直接跑中间步骤，会因为没有上游产物而报 cannot read file 0；对已存在的 tag 重新启动流程，则必须换一个新 tag 或加 -overwrite。

本文要回答的问题 ​

  • -from and -to are no longer supported. 是环境问题还是版本变更？老教程的命令怎么改写？
  • 新版 OpenLane 1.x 想只跑 floorplan 之后的几个步骤，正确操作是什么？
  • 为什么新 tag 下直接 run_floorplan 会报 Reading netlist '0' / cannot read file 0？
  • A run for ... with tag 'r1' already exists 除了 -overwrite 还有别的处置吗？
  • 修复后复跑，log 里出现什么才算分步流程真正接上了？

一、报错原文与现象 ​

四个场景用同一份 12 位计数器设计（small_counter）在同一容器内依次复现，原始记录是一条完整 log。先看最常见的 CASE A：照着老教程加 -from floorplan，banner 打完直接退出，连一个 STEP 都不会进。

CASE A：-from floorplan 被拒，2023.07 起 -from/-to 不再支持

这张卡只有一行有效信息但分量很重：[ERROR]: -from and -to are no longer supported.。注意它没有 traceback、没有后续步骤，说明拒绝发生在参数解析阶段，流程根本没启动——配置文件、PDK、RTL 全都还没被读取，所以不要顺着这个报错去查设计内容。配置内容类报错的长相完全不同，可对照姊妹篇 OpenLANE config 键名无效速查。

既然老参数没了，自然会想到用交互模式手动跳到 floorplan。CASE B 就是这个直觉操作的下场：新开一个会话、换新 tag ghost，不跑综合直接发 run_floorplan。

CASE B：新 tag 直接 run_floorplan，openroad 读不到综合网表

读这段输出抓住爆点三行：Reading netlist '0'…、cannot read file 0.、child process exited abnormally。floorplan 脚本要读综合产出的网表文件，而新 tag 的 run 目录下从未跑过 synthesis，网表变量是空的，Tcl 把空值拼成了文件名 0，openroad 自然打不开。前面的 LEF 解析（13 个工艺层、441 个库单元）全部正常，恰好证明 PDK 与环境没问题，缺的只是上游步骤产物。PDK 类报错的判别见 PDK sky130A not found 速查。

第三个场景发生在重跑时：tag r1 已经有一次成功的综合记录，第二个交互会话带着同名 tag 启动，prep 阶段立刻拦截。

CASE C：同 tag 再开会话未加 -overwrite，prep 拒绝覆盖旧 run

报错把两条出路都写在原文里了：Pass the -overwrite option to overwrite it or use a different tag。traceback 指向 prep 过程第 285 行——交互模式启动时会自动执行一次 prep 建立 run 目录，目录已存在又没拿到覆盖许可，就只能中止。这是防误删保护，不是故障。

最后是正确用法的完整对照（CASE D）：一个交互会话内先发 run_synthesis，成功后再发 run_floorplan，STEP 1 到 STEP 6 一气呵成。

CASE D：同一 interactive 会话按序执行，STEP 1 到 6 全部通过

这张卡是全篇的「及格样本」：STEP 1 Synthesis、STEP 2 STA、STEP 3 Initial Floorplanning、STEP 4 IO Placement、STEP 5 Tap/Decap、STEP 6 PDN 顺序出现，floorplan 还给出了实际尺寸 width 38.64 and height 38.08。中间那条 core area 太小的 WARNING 只影响电源网格缩放，不是错误。四个场景的分叉关系浓缩在下面这张概念卡里。

断点续跑四场景：一个被移除的参数与三条新规则

卡上四色对应四个动作面：红区认掉已失效的旧参数，蓝区理解新版状态模型，橙区识别跳步与重名两类新报错，绿区照着做并核对过关信号。

二、工具与版本 ​

本次复现全部在 OpenLane 官方 Docker 镜像内完成，版本与 log 头部记录一致：

项实测值
OpenLane 版本2023.07.19（镜像内 commit d054702b）
Docker 镜像efabless/openlane:d054702
PDK / 标准单元库sky130A / sky130_fd_sc_hd
触发方式flow.tcl -interactive 管道注入 run_* 命令；对照 CASE A 用非交互模式
设计small_counter，12 位时钟使能计数器

版本信息在这个主题里是决定性的：-from/-to 的移除发生在 2023.07 这条版本线上，更早的镜像（如 2022 年的 rc 版）里这些参数仍然存在且行为不同。排查前先执行 docker run --rm efabless/openlane:<tag> bash -c 'cat /openlane/docker_build_version.txt 2>/dev/null || echo d054702b' 或直接看 banner 的 commit 号确认版本，别让老教程和新镜像跨版本对打。镜像与 PDK 版本不匹配的另一类坑见 docker tag 不匹配速查。

三、根本原因：被移除的开关与进程内状态 ​

把四个场景的分叉画成一张流程图，红是报错、蓝是入口与排查视角、绿是正确路径。

eda/ts-openlane-resume-from-tag.md D2 示意图

读这张图抓住一条主线：状态的载体从「命令行参数 + 磁盘 tag」变成了「interactive 进程内存」。旧模型里 -from floorplan 的语义是让新流程从磁盘上已有 tag 的中间产物接着跑；新模型认为这种隐式恢复容易产生「产物版本对不上」的脏 run，干脆砍掉参数，把分步能力收进一个长生命周期的 Tcl 进程——run_synthesis 跑完后网表句柄、配置数组、当前步骤号都留在进程内存里，run_floorplan 直接消费这些内存对象，不依赖重新加载磁盘状态。CASE B 的 cannot read file 0 正是反证：新进程里没人做过综合，网表变量从未被赋值，空值被 Tcl 当成文件名 0。

CASE C 的重名保护是同一设计哲学的另一面：run 目录 runs/<tag>/ 是本次运行全部产物的唯一落点，静默覆盖会让上一轮结果无法追溯，所以 prep 强制要求显式表态——要么 -overwrite 自认覆盖，要么换 tag 保留历史。设计目录与配置文件本身的排查见 No design configuration found 速查。

四、排查清单 ​

按报错原文对号入座，三分钟内可以收敛到处置动作：

看到的报错判定处置
-from and -to are no longer supported.用了 2023.07 已移除的参数删掉 -from/-to，改 -interactive 会话内分步
cannot read file 0 / Reading netlist '0'会话内缺上游步骤产物回到第一个步骤按序重发 run_synthesis 等命令
tag 'xxx' already existsrun 目录重名保护换新 -tag 重跑，或加 -overwrite 明确覆盖
交互会话里命令拼错（如 run_floorplan 写成 run_floor_plan）Tcl 报 invalid command用 help 列出当前会话可用的 run_* 命令名

两个容易走的弯路。其一，不要试图通过「先手工把别的 tag 的 results 目录拷进新 tag」绕过 CASE B——进程内状态不是磁盘文件能补的，复制来的网表即使骗过文件检查，配置快照与阶段编号也对不上，后续步骤会以更隐蔽的方式失败。其二，-overwrite 会整体清掉旧 run 目录，需要留对照结果时优先换新 tag（如 r2、r3），tag 名本身就是免费的实验台账。

五、修复代码与复跑确认 ​

正确用法就是 CASE D 的命令：用管道把分步命令按顺序喂进同一个 interactive 会话，进程不重启，状态自然连续。

bash
printf "run_synthesis\nrun_floorplan\nexit\n" | \
  ./flow.tcl -design /designs/lab -tag r2 -interactive

需要更长的分步链（比如跑到布线再单独迭代）时，把命令依次追加进 printf 即可，顺序必须与流程阶段一致：run_synthesis → run_floorplan → run_placement → run_cts → run_routing，任何一步都不能在前置步骤缺席时单独发。复跑 log 的过关片段如下：

exp-log
[STEP 1]
[INFO]: Running Synthesis (log: ../designs/lab/runs/r2/logs/synthesis/1-synthesis.log)...
[STEP 2]
[INFO]: Running Single-Corner Static Timing Analysis (log: .../2-sta.log)...
[STEP 3]
[INFO]: Running Initial Floorplanning (log: .../3-initial_fp.log)...
[INFO]: Floorplanned with width 38.64 and height 38.08.
[STEP 6]
[INFO]: Generating PDN (log: ../designs/lab/runs/r2/logs/floorplan/6-pdn.log)...

过关信号有两个：一是 STEP 编号从 1 开始连续推进、没有回跳或重号，二是所有 log 路径都指向同一个 run 目录 runs/r2/——说明产物落在同一次会话的台账里。若要重跑这个 tag，命令改为 ./flow.tcl -design /designs/lab -tag r2 -interactive -overwrite，或者把 r2 换成 r3 保留对照。

实验环境 ​

  • 机器/系统：云主机 / Ubuntu 22.04（OpenLane 官方 Docker 镜像内运行）
  • 工具版本：OpenLane 2023.07.19 / sky130A（docker efabless/openlane:d054702），标准单元库 sky130_fd_sc_hd
  • 日期：2026-11-04
  • 完整命令：./flow.tcl -design /designs/lab -tag x -from floorplan（CASE A，旧参数复现）；printf "run_floorplan\nexit\n" | ./flow.tcl -design /designs/lab -tag ghost -interactive（CASE B，新 tag 跳步）；同 tag r1 第二次启动交互会话且不加 -overwrite（CASE C）；printf "run_synthesis\nrun_floorplan\nexit\n" | ./flow.tcl -design /designs/lab -tag r2 -interactive（CASE D，正确用法跑通 STEP 1 到 6）

代码获取 ​

复现用 RTL（12 位时钟使能计数器 small_counter）、配置文件与四场景对照运行脚本在公开仓 https://github.com/derekzhuo/geek-doc.cn/tree/main/experiments/openlane-resume-from-tag。按目录内 README 把设计目录挂进 OpenLane 容器，执行 ./run.sh 即可依次重现「旧参数被拒、跳步读空网表、tag 重名拦截、同会话按序跑通」四个场景。

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

本篇是 EDA 报错排查系列 中 OpenLane 流程控制簇的一员，管的是「命令与会话状态」这一层：配置文件缺失见 No design configuration found 速查，配置键名拼错见 OpenLANE config 键名无效速查，镜像与 PDK 环境问题见 docker tag 不匹配速查 与 PDK sky130A not found 速查。五者共享同一条排查主线：先按报错原文判定问题落在哪一层，再动手改命令或配置，而不是凭感觉重跑。

总结 ​

OpenLANE -from/-to 断点续跑报错的本质是版本变更而非环境故障：2023.07 起 -from/-to 被整体移除，分步运行的状态载体改为 -interactive 进程内存，必须在同一会话内按 run_synthesis → run_floorplan 的顺序执行；跨会话跳步会因上游产物缺失报 cannot read file 0，重名 tag 会被 prep 拦截，处置只有换新 tag 或显式 -overwrite；复跑看到 STEP 编号连续推进、log 路径指向同一个 run 目录，即说明状态接续成功。