极客工场

Appearance

共 3,416 字预计阅读约 11 分钟

OpenLANE 项目配置 JSON 模板：config.json 常用键逐项说明与改参示范 ​

更新时间：2026-11-05。模板卡，属于 芯片设计入门系列。在 OpenLANE 里新建一个设计，本质上就是写一份 config.json：flow.tcl -design <目录> 之后的四十多个步骤读什么源文件、按什么时钟约束、芯片做多密、最后跑不跑 DRC/LVS，全部由这一个文件决定。这份 OpenLANE 项目配置 JSON 模板里的每个键值都来自一次在 sky130A 上真实跑通到 signoff 的成功 run，不是照着官方文档拼出来的示意值。OpenLANE 整体能做什么、不能做什么，先读 OpenLANE 适合做正式 ASIC 项目吗 建立边界认知，本篇只管「配置文件怎么写」。

首屏答案：最小可用的 config.json 有十三个键，分四组——设计身份与源码（DESIGN_NAME/VERILOG_FILES）、时钟约束（CLOCK_PORT/CLOCK_PERIOD）、版图与密度（FP_SIZING/FP_CORE_UTIL/PL_TARGET_DENSITY 等）、签核开关（RUN_MAGIC_DRC/RUN_LVS 及对应 QUIT 开关）。本文模板配一个 12 位时钟使能计数器 small_counter 实测：综合 62 个单元、面积 609.33 μm²，Magic DRC 0 违例、LVS 94 nets 对 94 nets clean、天线违例 0，42 步全过并打印 [SUCCESS]: Flow complete.。

本文要回答的问题 ​

  • 一份能跑通完整 RTL→GDS 流程的 config.json 至少要写哪些键？
  • FP_CORE_UTIL 是百分数，为什么 PL_TARGET_DENSITY 却是 0.5 这样的小数？两者各管哪一步？
  • VERILOG_FILES 的 dir:: 前缀是什么意思，多文件怎么列？
  • 键名拼错、取值越界时 OpenLANE 会不会在启动时报错？真实后果是什么？
  • 想把芯片做密一点或时钟做快一点，改哪几个键、一次改多少？

一、名称与使用场景 ​

config.json 是 OpenLANE 1.x（2023.07.19）设计目录的入口配置：flow.tcl -design <目录> 启动后，流程在该目录下找 config.json（或 config.tcl），把每个 JSON 键 set 成同名环境变量，后续四十多个步骤的 Tcl 脚本再从环境里取值。文件缺失会直接退出，报错路径见 No design configuration found 速查；文件存在但键名拼错则不会在启动期拦截，这个坑后面逐键讲解时会点名。

适用场景是 sky130A 工艺下的中小数字核：单时钟、Verilog 源码一到数个、目标是一键出一份过 DRC/LVS 的 GDS。下面这张概念卡把十三个键按「谁在读它」分成四组，读图抓住一条主线——前两组决定综合什么、按什么约束综合，后两组决定芯片摆多密、收尾拿什么指标判合格。

config.json 十三键分四组：从源码身份到 signoff 开关

四组颜色各有语义：蓝是输入侧的身份信息，紫是约束侧的逻辑设定，橙是物理实现阶段真正动手的参数，绿是收尾判合格的开关。改配置时先想「我要影响的是哪个阶段」，再去对应组里找键，比按字母顺序盲查快得多。

二、完整可复制 config.json 模板 ​

下面就是模板本体，取值全部来自我班一次跑通到 signoff 的 baseline run（设计为 12 位计数器 small_counter，完整实录见第五节课）。把它放进设计目录、按自己的模块名和端口改前四个键即可用：

json
{
  "DESIGN_NAME": "small_counter",
  "VERILOG_FILES": "dir::src/small_counter.v",
  "CLOCK_PORT": "clk",
  "CLOCK_PERIOD": 20,
  "FP_SIZING": "relative",
  "FP_CORE_UTIL": 40,
  "PL_TARGET_DENSITY": 0.5,
  "FP_PDN_SKIPTRIM": true,
  "SYNTH_STRATEGY": "AREA 0",
  "RUN_MAGIC_DRC": true,
  "RUN_LVS": true,
  "QUIT_ON_MAGIC_DRC": true,
  "QUIT_ON_LVS_ERROR": true
}

配套的设计目录结构很简单：config.json 在设计根，RTL 放在 src/ 子目录，flow 产物统一落到 runs/<tag>/，与 RTL 工程目录规范 的分层思路一致。注意 JSON 不允许注释，也不允许尾随逗号——想记备注写在单独的 README 里，不要往键值对后面加 //。

三、逐键讲解 ​

先给一张速查表，再对容易踩坑的键展开讲。

键含义合法取值改错的典型后果
DESIGN_NAME顶层模块名，也是产物命名前缀与 Verilog module 名完全一致的字符串综合找不到顶层，STEP 1 即失败
VERILOG_FILESVerilog 源文件清单dir:: 相对路径，多文件用空格分隔或写成 JSON 数组拼错键名则 Step 0 报 no such variable
CLOCK_PORT时钟端口名RTL 里真实存在的 input 端口找不到时钟，STA 无约束、CTS 无时钟树
CLOCK_PERIOD时钟周期，单位纳秒正数，20 即 50 MHz过小则 setup 违例，flow 末尾报 timing violation
FP_SIZING版图尺寸模式relative（按利用率算）/ absolute（给死尺寸）写成别的字符串，floorplan 步骤拒绝
FP_CORE_UTIL核心区目标利用率0–100 的百分数，常用 30–50与密度键混淆写成 0.4，芯片被放大十倍
PL_TARGET_DENSITY全局布局目标密度闭区间 0–1 的小数，常用 0.5–0.55写 1.5 在 STEP 7 触发 GPL-0135
FP_PDN_SKIPTRIM跳过电源网格裁剪true / false小芯片不置 true，可能出现电源网格告警
SYNTH_STRATEGYYosys/ABC 综合策略AREA 0、DELAY 0 等内置名拼错策略名，综合步骤报未知策略
RUN_MAGIC_DRC是否跑 Magic DRCtrue / false关掉则没有 DRC 报告，signoff 缺一项
RUN_LVS是否跑 Netgen LVStrue / false关掉则没有版图网表一致性结论
QUIT_ON_MAGIC_DRCDRC 有违例是否中止 flowtrue / falsefalse 时带病跑完，容易误以为成功
QUIT_ON_LVS_ERRORLVS 出错是否中止 flowtrue / false同上，错误被吞进日志

DESIGN_NAME 与 VERILOG_FILES。前者必须和 RTL 里的 module small_counter 一字不差，大小写敏感；后者的 dir:: 前缀告诉 OpenLANE「后面的路径相对设计目录解析」，多个文件可以写成 "dir::src/a.v dir::src/b.v" 或 JSON 数组。这里有个真实的静默陷阱：OpenLane 1.x 加载 config.json 时只做 JSON 语法解析、不校验键名，把 VERILOG_FILES 拼成 VERILOG_FIELS 不会在启动期报任何警告，错键被透传成环境变量，直到 Step 0 的 lint 读不到 ::env(VERILOG_FILES) 才抛 no such variable，完整链路见 OpenLANE config 键名无效排查。

CLOCK_PORT 与 CLOCK_PERIOD。clk 必须是 RTL 端口清单里真实存在的时钟；周期以纳秒计，20 ns 对应 50 MHz。这个值同时喂给综合期的 STA 和后端的 CTS——压到 10 ns 等于要求 100 MHz，小计数器也许仍能收敛，但日志末尾的 setup 检查会明确给出违例结论，那时要回头放宽周期或改 RTL，而不是无视报告。

FP_SIZING、FP_CORE_UTIL 与 PL_TARGET_DENSITY。这三个键是全篇最容易混的地方。FP_SIZING: "relative" 表示芯片尺寸不写死，由 floorplan 按利用率自动算；FP_CORE_UTIL: 40 是百分数，意思是「核心区里单元占 40%，剩下 60% 留给布线和余量」，本次 run 据此算出 38.64 μm × 38.08 μm 的版图。PL_TARGET_DENSITY 则是 0–1 的比例、不是百分数，0.5 与 40% 是同一个量级的两种表达，分别被 floorplan 和 global placement 两个步骤读取。把它写成 1.5 不会在加载期被拦，债务一直记到 STEP 7 才由 OpenROAD 抛出 GPL-0135 Target density must be in [0, 1]，实测对照见 PL_TARGET_DENSITY 密度报错排查。而合法但激进的高密度（0.9 以上）会把压力转给布线器，典型下场是 STEP 17 的 GRT-0119 拥塞失败，见 FastRoute 布线拥塞失败实录。

FP_PDN_SKIPTRIM 与 SYNTH_STRATEGY。小芯片核心区太小时，默认电源网格会被裁剪缩放，日志里留下 power grid will be scaled down 的警告；置 FP_PDN_SKIPTRIM: true 是这类小设计的惯例写法。SYNTH_STRATEGY: "AREA 0" 让 Yosys/ABC 以面积优先，本次综合结果 62 个单元、609.33 μm²；追频率时换 DELAY 0，代价通常是面积变大。

四个签核开关。RUN_MAGIC_DRC/RUN_LVS 决定 STEP 40、39 跑不跑，两个 QUIT_ON_* 决定查出问题是中止还是带病继续。教学实验也建议全开且保持 QUIT 为 true——让流程在第一个物理违例处停下来，比在一份「成功」的 GDS 里事后翻日志找错误可靠得多。

四、使用注意事项与改参示范 ​

改参一次只动一个键，并换 tag 留痕。flow.tcl -tag baseline 的 tag 会成为 runs/ 下的目录名，改参时换成 -tag util50、-tag clk10ns，配合 -overwrite 重跑，新旧两套报告并存，对比 reports/metrics.csv 就能量化每次改动的收益。一次改三个键，最后时序不过时无法归因是哪一个。

示范一：把芯片做密一点。基线 FP_CORE_UTIL: 40、PL_TARGET_DENSITY: 0.5。第一步只把利用率提到 50、密度同步到 0.55，重跑确认 DRC/LVS 仍 clean；确认没问题再试探 60 / 0.6。越过 0.7 之后布线拥塞风险显著上升，出现 GRT-0119 就回退一档，不要硬冲。

bash
# 改参后的复跑方式：新 tag 保留基线结果
./flow.tcl -design /designs/lab -tag util50 -overwrite

示范二：把时钟从 50 MHz 提到 100 MHz。只改 CLOCK_PERIOD: 10，其余键不动。跑完先看日志收尾的 setup/hold 两行结论，再看 reports/synthesis/2-sta.log 的最坏路径裕量；若违例，优先在 RTL 上拆流水，而不是靠继续堆利用率给布局器腾地方——密度和时序是两个独立旋钮，不要混用。

JSON 语法的两个低级坑。一是字符串别忘了双引号，true 这类布尔值反而不要加引号；二是最后一个键后面不能留逗号。这两类错误会在配置加载期直接解析失败，和前面说的「键名拼错静默透传」是两种失败模式，正好构成 config.json 的两道坎：语法错活不过加载，语义错潜伏到具体步骤。

五、成功验证：一次跑到 signoff 的完整实录 ​

模板的价值要由完整 run 背书。同一份 config.json 在 OpenLane 2023.07.19 / sky130A 容器里跑完整 42 步，先看收尾的可制造性报告——DRC、LVS、天线三项是 signoff 的硬指标：

signoff 三项硬指标：DRC 0、LVS 94 nets clean、天线 0

读这段终端实录抓三个数：Magic DRC Summary 下 Total Magic DRC violations is 0，说明版图没有设计规则违例；LVS Summary 左右两边都是 94 个 nets 并打印 Design is LVS clean.，说明版图网表与综合网表逐条对得上；Antenna Summary 的 pin 与 net 违例都是 0，长金属线的天线效应也已由插入的二极管兜住。三项全零，才具备谈 GDS 流片的前提。

再看 flow 尾部，STEP 40 DRC、STEP 41 天线检查、STEP 42 ERC 依次跑完，最后由 OpenLANE 自己打印成功标记：

42 步全过：无 slew/fanout/cap 违例，Flow complete

这一段里 no max slew, max fanout or max capacitance violations、no hold violations、no setup violations 三行与 [SUCCESS]: Flow complete. 构成完整的合格判据：物理违例、保持时间、建立时间三个维度同时干净。日志尾部另有几条 WARNING——电源网格缩放、tap/fill 单元在 STA 中被黑盒处理、VSRC_LOC_FILES 未定义导致 IR drop 分析不精确——它们不阻断 flow，且都是小设计的已知噪声，与 ERROR 有本质区别。综合侧的面积数字同样可溯：Yosys 统计 62 个 sky130_fd_sc_hd 单元、模块面积 609.3344 μm²，与 AREA 0 策略的预期一致。

实验环境 ​

  • 机器/系统：云主机 / Ubuntu 22.04（docker 运行 OpenLANE 容器）
  • 工具版本：OpenLane 2023.07.19（镜像 efabless/openlane:d054702，commit d054702b）；PDK sky130A / 标准单元库 sky130_fd_sc_hd（volare 管理）
  • 日期：2026-11-04
  • 完整命令：./flow.tcl -design /designs/lab -tag baseline -overwrite（容器内执行，设计目录挂载为 /designs/lab，完整 flow 共 42 步）

代码获取 ​

可直接复制的 config.json、run.sh 与 small_counter 源码在公开仓 https://github.com/derekzhuo/geek-doc.cn/tree/main/experiments/tpl-openlane-config-json。按目录内 README 把设计目录挂进 OpenLANE 容器，执行 ./flow.tcl -design /designs/lab -tag baseline -overwrite，约 7 分钟即可复现 42 步全过、DRC/LVS/antenna 三项为零的完整 run。

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

本篇是模板卡：向上承接 OpenLANE 适合做正式 ASIC 项目吗 的能力边界讨论，回答「这条流水线值得跑」之后的「第一份配置怎么写」；横向与 仿真工程 Makefile 通用模板 构成「仿真构建」与「ASIC 实现」两份可复制骨架。逐键讲解中点名的三个真实报错各自有排查专页：键名拼错看 config 键名无效，密度越界看 PL_TARGET_DENSITY 与 GPL-0135，配置文件整体缺失看 No design configuration found，高密度引发的布线失败看 FastRoute 拥塞实录。

总结 ​

这份 OpenLANE 项目配置 JSON 模板的骨架是四组十三个键：DESIGN_NAME/VERILOG_FILES 定义综合对象，CLOCK_PORT/CLOCK_PERIOD 定义时序约束，FP_SIZING/FP_CORE_UTIL/PL_TARGET_DENSITY 用「百分数加比例」两个旋钮控制版图疏密，四个签核开关保证 DRC/LVS 违例即中止。记住两条最疼的教训：OpenLANE 不校验键名，拼错只会静默潜伏到具体步骤；密度键量纲不同，FP_CORE_UTIL 写 40、PL_TARGET_DENSITY 写 0.5，写反或越界都会在流程后半程连本带利地还回来。改参一次只动一个键、换 tag 留痕，拿 metrics.csv 做前后对比，就是这套模板最稳的用法。