用 OpenROAD 验证设计的 PPA（功耗、面积、性能）指标

本文将以 OpenROAD-flow-scripts（ORFS）为主线，讲清楚每一步"看什么指标、用什么命令、怎么判断是否达标"，最后用一个 RISC-V CPU 核（以 Ibex / PicoRV32 为例）串起来。

---

一、总体思路

OpenROAD 是"设计 → 指标报告"的闭环工具：

RTL + 约束(SDC) + 工艺库(LEF/Liberty)
        │
        ▼
综合(Yosys) → 布局规划 → 布局 → CTS → 布线
        │
        ▼
每阶段输出报告：时序(WNS/TNS)、面积(利用率)、功耗、DRC、天线、IR Drop
        │
        ▼
和规格书（spec）对比 → 达标？收敛

关键原则：指标要在每一步之后检查，而不是只等最终结果。后阶段出的问题往往根源在前面（比如布线后时序崩了，根因可能是布局利用率设太高）。

---

二、各项指标的验证方法

1. 时序（Timing / 性能）

这是最核心的一项。验证手段：

• 约束定义 ：所有时序要求写在 SDC 里（时钟周期、输入输出延迟、多周期路径等）。OpenROAD 只认 SDC，"我想要的频率"必须变成 create_clock。
• 静态时序分析（STA）：OpenROAD 内置 OpenSTA，每条路径做 setup/hold 检查。

# 在 OpenROAD 交互界面或 tcl 脚本中
read_sdc constraint.sdc
report_worst_slack          # 最差裕量
report_wns                  # WNS（Worst Negative Slack）
report_tns                  # TNS（总负裕量）
report_checks -path_delay max   # setup 检查
report_checks -path_delay min   # hold 检查

达标标准：WNS ≥ 0 且 TNS = 0。WNS 为负说明最慢路径没满足时钟周期------要么降频率目标，要么优化（调整布局、加流水线、换单元尺寸）。

注意布线后还有带寄生参数的 signoff 级检查（estimate_parasitics -global_routing 或布线后基于 SPEF 的分析），以及噪声/信号完整性检查 check_slew / check_max_capacitance。

2. 面积（Area）

report_design_area           # 报告裸芯片面积
report_utilization           # 单元利用率

需要看两个层面：

指标	含义	判定
单元总面积	所有标准单元面积之和	对比目标工艺下同类型设计是否离谱
核利用率（utilization）	单元面积 / core 面积	太低浪费硅面积，太高（一般 > 70~80%）布线拥塞、时序难收敛
Die 面积	DIE_AREA 约束的矩形	必须满足封装/产品规格

面积不是"越大/越小越好"，而是 die size 固定约束下，利用率处于可布线、可收敛的区间。

3. 功耗（Power）

report_power                 # 输出 total / switching / leakage 功耗
report_power -instances [get_cells U_ALU]

几个关键点：

• 功耗报告需要 开关活动率 数据才准确。默认 OpenROAD 用固定翻转率估算；要精确，需从仿真导出 .vcd/.saif 文件，配合 read_saif 读入后再 report_power。
• 静态（漏电流）功耗来自 Liberty 库的 leakage_power，动态功耗取决于时钟频率和活动率------所以功耗和时序目标强耦合。
• IR Drop（电压降）分析用 OpenROAD 的 PDNSim（psm），基于电源网格和寄生参数检查供电网络是否满足压降预算（一般要求 IR drop < 电源的 5%~10%）。

4. 其他必查项

项目	命令/输出	达标标准
DRC（布线设计规则）	布线报告、OpenROAD / KLayout DRC	0 违规
LVS	最终导出 GDS + 网表，用外部工具比对	通过
天线效应（Antenna）	天线报告	0 违规
拥塞（Congestion）	全局布线后的 overflow 报告	overflow 为 0 或接近 0
最大转换/扇出/电容	check_slew、check_fanout、check_max_capacitance	无违规

---

三、CPU 实例：以 PicoRV32 / Ibex @ sky130 为例

假设目标：一个 32 位 RISC-V CPU 核，工艺 SkyWater 130nm，规格书要求：

• 频率 ≥ 50 MHz（周期 ≤ 20 ns）
• 核面积 ≤ 0.5 mm²
• 功耗 ≤ 50 mW
• 可流片（0 DRC、通过 LVS）

步骤 1：写约束（先明确"要求"长什么样）

constraint.sdc：

create_clock [get_ports clk] -name core_clk -period 20.0
set_clock_uncertainty 0.5 [get_clocks core_clk]
set_input_delay  4.0 -clock core_clk [all_inputs]
set_output_delay 4.0 -clock core_clk [all_outputs]

config.mk（ORFS 项目配置）：

export DESIGN_NICKNAME = picorv32
export DESIGN_NAME     = picorv32
export PLATFORM        = sky130hd
export VERILOG_FILES   = $(sort $(wildcard ./designs/src/picorv32/*.v))
export SDC_FILE        = ./designs/sky130hd/picorv32/constraint.sdc
export CORE_UTILIZATION = 45          # 初设 45% 利用率
export PLACE_DENSITY_LB_ADDON = 0.2
export CLOCK_PERIOD    = 20.0

步骤 2：跑流程，每阶段看报告

cd OpenROAD-flow-scripts/flow
make
make gui_final   # 打开 GUI 可视化检查

流程结束后，ORFS 把所有指标汇总在 logs/<platform>/<design>/ 下的报告和 metadata 文件 里（老版本叫 metadata.json，新版为各阶段 *_final.rpt + metadata 汇总），重点看：

Area:      单元总面积、die 面积
WNS/TNS:   布线后 setup 裕量
Power:     total/switching/leakage
DRC:       布线违规数
Antenna:   天线违规数

步骤 3：逐项判定

目标	实际报告（示例）	判定	不达标时的动作
≥ 50 MHz	布线后 WNS = +0.8 ns	✅ 达标（还有余量，可以试着把周期改到 18 ns 冲一下）	若 WNS < 0：查 report_checks 找关键路径，若 ALU 级联太长 → 改 RTL 加流水；若线延迟大 → 调布局策略
≤ 0.5 mm²	die 0.42 mm²，利用率 45%	✅ 但利用率偏低，可把 CORE_UTILIZATION 提到 55% 缩小 die 面积	若布线拥塞（overflow > 0）：降低利用率
≤ 50 mW	report_power: total 38 mW	✅ 达标	若超标：降频、换低功耗库（HD vs HDL）、时钟门控（RTL 层面）
0 DRC	0 violations	✅	有违规用 gui 定位坐标逐个排查
LVS	magic/netgen 比对通过	✅	通常报 pin 不匹配，检查导出的网表

步骤 4：交互式深入分析（发现不达标时）

make gui_final

在 GUI 中：

• 高亮关键路径：report_checks -path_delay max 选中最差路径，时序图 + 版图上可视化整条路径的物理位置------很多时序问题肉眼可见（比如两个模块被放得很远）。
• 查看功耗密度图、拥塞热图（Routing Congestion map），定位热点区域。

步骤 5：精确功耗闭环（可选但推荐）

# RTL 级仿真跑真实 workload，导出 vcd
iverilog -o sim tb.v cpu.v && vvp sim   # 生成 dump.vcd
# 在 ORFS 中
make SIMULATION_VCD=tb.vcd    # 或手动：

read_saif -scope tb/uut activity.saif
report_power   # 现在是基于真实开关活动的功耗

---

四、实用建议

1. 从 ORFS 现成的 CPU 示例学起 ：OpenROAD-flow-scripts/flow/designs/ 目录下自带 ibex、swerv（SweRV EH1 RISC-V 核）等在 sky130hd / nangate45 / asap7 上的完整配置，直接 make DESIGN_CONFIG=./designs/sky130hd/ibex/config.mk 就能跑通并看到全部报告，是最佳学习样本。
2. 自动回归判定 ：ORFS 有 util/clean-logs.py 和 CI 机制，可设定各指标的 golden 值（如 WNS 不得低于某值、DRC 为 0），实现"指标回归自动报警"------工业界日常收敛就是这么做的。
3. 迭代顺序的经验：先保证能布线（利用率别太高）→ 再收敛时序 → 最后压面积（提高利用率缩小 die）。功耗最后评估，因为它依赖最终的频率和活动率。
4. 多个 corner：signoff 级验证要在 SS/TT/FF 工艺角分别跑 STA 和功耗，最坏情况（slow corner 查 setup、fast corner 查 hold）都过才算真达标。

总结：在 OpenROAD 里，"是否满足要求" =（把要求写成 SDC/配置约束 + 每阶段读 WNS/TNS、利用率、report_power、DRC 报告 + 与 spec 对比），CPU 项目用 ORFS 自带的 ibex/swerv 示例跑一次完整流程，就能把这整套验证方法过一遍。

2. 学习资料

webaddr

我来搜索一下当前基于 OpenROAD 的开源设计项目情况，确保信息准确。

Ibex / PicoRV32 确实是 OpenROAD 生态里的经典参考设计

Ibex 是 OpenROAD-flow-scripts（ORFS）官方设计套件里的核心 benchmark 之一，甚至 OpenROAD 在 MICRO 2022 的官方教程就是以"用 OpenROAD 实现 Ibex RISC-V 核"为主线的教学案例。学术界大量基于 OpenROAD 的论文（如布线预测、ML 辅助物理设计）也都用 IBEX 作为标准测试设计，横跨 NanGate45、SKY130、ASAP7 甚至商业 12nm 节点。PicoRV32 则是 OpenLane/Efabless MPW 生态里的常客（上一轮的示例）。

下面按"开源数据的完整程度"分类，推荐可学习的项目。

---

一、ORFS 官方设计套件（数据最全、首选）

仓库：OpenROAD-flow-scripts/flow/designs/

这是唯一做到"设计 + 约束 + 期望指标（golden）+ 判定规则"全部开源的地方。每个设计的目录里有：

designs/sky130hd/ibex/
├── config.mk               # 完整流程配置（利用率、密度等）
├── constraint.sdc          # 时序约束
├── metadata-base-ok.json   # "及格线"指标：WNS/TNS、面积、功耗、DRC 数
├── rules.json              # CI 判定规则（每项指标的容差）
└── autotuner.json          # 自动调参搜索空间

学习价值 ：metadata-base-ok.json 就是上一轮讨论的"达标判定"的真实工业案例------OpenROAD 自己的 CI 就是拿这些值做回归判定的，且 CI 测试集还包含 80+ 个来自 SkyWater 流片班车的真实流片设计。

值得看的 CPU 类设计：

设计	工艺节点	特点
ibex	sky130hd / nangate45 / asap7	入门首选，无宏单元，规模适中
swerv_wrapper	nangate45 等	Western Digital 的 SweRV EH1，含 28 个 SRAM 宏，学习宏布局
bp_fe / bp_be	nangate45	BlackParrot 处理器前端/后端，含宏
ariane136	nangate45	ETH 的 64 位 Ariane 核，规模较大
riscv32i / coyote	sky130hd / 商业节点	小型到中型 RISC-V 设计

学这些的正确姿势：跑完流程后把你的 logs/reports 与 metadata-base-ok.json 逐项 diff，理解为什么官方把 WNS 容差设成那个值。

二、Tiny Tapeout（"流片验证"数据最全）

网址：tinytapeout.com

最大特点：所有参赛设计强制开源 （RTL、GDS、OpenLane 配置全部公开），且有大量实测硅片数据------官网维护了"silicon proven"清单，标注每个设计经过几轮实测确认工作正常。其中 CPU/SoC 类亮点：

• TinyQV ------ 众包 RISC-V SoC，多轮硅验证通过
• KianV uLinux SoC ------ 能跑 Linux 的 RISC-V，多次流片成功
• DJ8 8-bit CPU、Lipsi（号称世界最小处理器）、Zilog Z80 等

想研究"设计验证数据"与"实测结果"的对应关系（比如某设计 STA 裕量多少、实测能跑多快），这是最独特的资源------大多数项目还附带作者的实测博客。

三、Caravel + Open MPW 班车项目（SoC 级集成）

• efabless/caravel：Efabless 的标准 SoC harness，管理自己的用户项目区。其 GitHub 组织下有 100+ 个公开 Verilog 仓库，全部通过 OpenLane（基于 OpenROAD）流片。
• Google/Efabless/SkyWater 的 OpenMPW 班车已流片数千个设计，从 RI5CY、AES 核到 MEMS 控制器。每个项目仓库包含完整 GDS、最终报告（时序、面积、DRC/LVS 结果），是"RTL→流片→回测"全链路开源数据的富矿。

四、OpenFASoC（模拟/混合信号方向）

密歇根大学主导的全自动模拟电路生成器 项目，基于 OpenROAD + Xyce。包含温度传感器、数字 LDO、DC-DC 转换器、PLL、SAR ADC 等生成器，已多次流片成功。特别有价值的是它公开了设计指标与后仿真的对照数据，例如 SAR ADC：面积 0.04 mm²，功耗 6.72 µW（原理图级）→ 11.2 µW（PEX 后仿真），ENOB 7.86 → 7.75------这正是"设计指标 vs 实际验证数据"教学意义最强的材料。

五、学术大核项目

• BlackParrot：开源 64 位 RISC-V 多核处理器，曾用 OpenROAD 的 RTL-MP 做 12nm 物理设计，达到高频小面积。其 bp_fe/bp_be 就是 ORFS 官方设计。
• SweRV EH1 / EL2（CHIPS Alliance）：工业级 RISC-V 核，ORFS 中的 swerv_wrapper 是学"含大量 SRAM 宏的 CPU 布局"的最佳样本。

---

推荐学习路径

1. 起步 ：跑通 ORFS 的 sky130hd/ibex，对照 metadata-base-ok.json 学会读每项指标（上一轮讲的方法在这里直接实操）
2. 进阶 ：swerv_wrapper 或 bp_be，学习宏单元摆放、PDN 设计、多层时钟树
3. 对标实测：挑一个 Tiny Tapeout 的 silicon-proven CPU（如 KianV），对比它的 OpenLane 报告与作者实测数据
4. 拓展 ：OpenFASoC 学混合信号；改 rules.json 体验 CI 式指标回归

3.跑通 ORFS 的 sky130hd/ibex 完整指南

webaddr

环境要求：Linux（官方支持 Ubuntu 20.04/22.04、RockyLinux 9、Debian 11；Windows 请用 WSL2 + X Server），ibex 在 8 核 / 16GB 内存机器上全流程约需 8 分钟。

---

第一步：安装环境（三选一）

方案 A：Docker（官方推荐，最省心）

git clone --recursive https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts
cd OpenROAD-flow-scripts

# 拉取预构建镜像（自带 OpenROAD/Yosys/KLayout 全部依赖）
docker pull openroad/orfs:latest

# 后续所有 make 命令都在 Docker 容器内执行

更新环境时只需 docker pull openroad/orfs:latest 重新拉取。

方案 B：预编译二进制（不想编译源码时）

# 1. 自行安装 KLayout >= 0.28.8 和 Yosys >= 0.58
# 2. 从 Precision Innovations 的 GitHub releases 下载对应发行版的 .deb 包：
sudo apt install ./openroad_2.0_amd64-ubuntu22.04.deb

# 3. 克隆 ORFS（非递归即可）
git clone https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git
cd OpenROAD-flow-scripts
export OPENROAD_EXE=$(command -v openroad)
export YOSYS_EXE=$(command -v yosys)

方案 C：本地源码编译（想改工具源码时）

git clone --recursive https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts
cd OpenROAD-flow-scripts

sudo ./setup.sh                # 自动安装全部依赖（需 sudo）
./build_openroad.sh --local    # 本地编译，约需 0.5~2 小时

# 验证安装
source ./env.sh
yosys -help
openroad -help

注意 --recursive 必不可少（子模块包含 OpenROAD 工具源码），漏了就 git submodule update --init --recursive 补上。

---

第二步：先用默认 gcd 设计自检

make 的默认设计是 nangate45/gcd，先跑它验证环境没问题：

source ./env.sh      # Docker 方式可跳过
cd flow
make                 # 跑 gcd，几分钟完成
make gui_final       # 能弹出 GUI 看版图 = 环境 OK

第三步：跑 sky130hd/ibex 主流程

cd flow
make DESIGN_CONFIG=./designs/sky130hd/ibex/config.mk

整条流水线自动执行：综合(Yosys) → 布局规划 → IO/宏摆放 → PDN 电源网格 → 全局/详细布局 → CTS → 全局布线 → 详细布线 → GDS 导出。

ibex 在该配置下的设计目标：Die 约 798×800 µm，时钟周期 17.4 ns。

中断恢复：流程可从断点续跑；若文件损坏报错，按阶段清理重跑：

make clean_synth      # 只清综合
make clean_route      # 只清布线
make clean_all        # 全清重来

---

第四步：检查结果（上一轮讲的指标在这里落地）

1. 看日志定位阶段

ls logs/sky130hd/ibex/base/
# 1_1_yosys.log  2_1_floorplan.log  3_1_place_gp.log
# 4_1_cts.log    5_1_grt.log        5_2_route.log  6_report.log ...

任何阶段失败，先看对应日志的 [ERROR] 行。

2. GUI 可视化 + 指标查询

make DESIGN_CONFIG=./designs/sky130hd/ibex/config.mk gui_final

⚠️ 常见坑 ：gui_final 也必须带 DESIGN_CONFIG，否则它默认去加载 nangate45/gcd，会报 No rule to make target 'gui_6_final.odb'。

GUI 的 Tcl 命令窗口里：

report_design_area          # 面积，ibex 约 191262 µm²、30% 利用率
report_wns; report_tns      # 时序裕量
report_power                # 功耗

界面上可以直接看：拥塞热图、时钟树、关键路径高亮。

3. 对照官方 golden 值（核心学习点）

# 汇总本次所有指标
make DESIGN_CONFIG=./designs/sky130hd/ibex/config.mk metadata

# 与官方及格线对比
cat designs/sky130hd/ibex/metadata-base-ok.json
cat designs/sky130hd/ibex/rules.json

metadata-base-ok.json 里是官方的期望 WNS/TNS、面积、DRC 数；rules.json 定义了每项指标的容差------这就是 CI 判定"设计是否达标"的完整机制。

4. 最终产物

flow/results/sky130hd/ibex/base/6_final.gds    # 版图
flow/results/sky130hd/ibex/base/6_final.v      # 门级网表
flow/results/sky130hd/ibex/base/6_final.spef   # 寄生参数

---

第五步：做参数探索实验（可选，进阶）

改 designs/sky130hd/ibex/config.mk 做对照实验，体会"配置 → 指标"的因果链：

export CORE_UTILIZATION = 30        # 提高/降低利用率，看面积 vs 拥塞
export ABC_AREA = 1                 # 综合阶段面积优先（默认是速度优先）

改完 make clean_synth && make DESIGN_CONFIG=... 重跑，对比两次的 metadata 输出。这正是 ORFS 官方教程推荐的 PPA 探索方法；想全自动调参可以看同目录的 autotuner.json + AutoTuner 框架。

---

常见问题速查

现象	原因 / 解决
make gui_final 报 no rule to make target	没传 DESIGN_CONFIG，带上同一份 config 重试
远程服务器打不开 GUI	SSH 加 -Y 参数开启 X11 转发
布线阶段 DRC 违规多	降低 CORE_UTILIZATION 或 PLACE_DENSITY 重跑
子模块为空导致 build 失败	git submodule update --init --recursive
想换工艺节点	DESIGN_CONFIG=./designs/nangate45/ibex/config.mk 或 asap7/ibex，命令格式完全一致

4. 一键构建

这里把整套流程整理成一份 bash 脚本，支持 Docker 和本地编译两种模式。

脚本已通过语法检查。内容要点：

• 两种模式 ：docker（推荐，拉取预构建镜像，免编译）或 local（本地源码编译，支持 --skip-build 跳过安装）
• 四个阶段全自动 ：克隆仓库 → gcd 自检 → ibex 主流程 → 提取指标并与官方 metadata-base-ok.json / rules.json 对比，输出中文报告摘要
• Docker 模式下自动处理 ：容器内执行 make、挂载工作目录、X11 转发（保证 gui_final 可用）
• 健壮性 ：set -euo pipefail 严格模式、仓库已存在时跳过克隆、每一步有彩色日志提示

使用方式：

chmod +x ORFS_ibex流程.sh
./ORFS_ibex流程.sh docker     # 推荐
# 或
./ORFS_ibex流程.sh local      # 本地编译（0.5~2 小时）

跑完后查看 ~/openroad_ws/ibex_报告摘要.txt，里面有本次指标与官方 golden 值的完整对照。

ORFS_ibex_procedure.sh

#!/usr/bin/env bash
# =============================================================================
# ORFS sky130hd/ibex 全流程自动化脚本
#
# 功能：安装 OpenROAD-flow-scripts 环境 → gcd 自检 → 跑 sky130hd/ibex →
#       汇总指标并与官方 golden 值（metadata-base-ok.json）对比
#
# 用法：
#   chmod +x ORFS_ibex_procedure.sh
#   ./ORFS_ibex_procedure.sh docker        # Docker 模式（推荐，环境干净）
#   ./ORFS_ibex_procedure.sh local         # 本地源码编译模式（耗时 0.5~2 小时）
#   ./ORFS_ibex_procedure.sh local --skip-build   # 已装好的环境，直接跑流程
#
# 环境要求：Linux (Ubuntu 20.04/22.04 或 RockyLinux 9 等)，>= 16GB 内存
# =============================================================================

set -euo pipefail

# --------------------------- 可配置参数 --------------------------------------
MODE="${1:-}"                      # docker | local
EXTRA_ARG="${2:-}"                 # --skip-build（仅 local 模式）

WORK_DIR="${WORK_DIR:-$HOME/openroad_ws}"         # 工作目录
ORFS_DIR="${WORK_DIR}/OpenROAD-flow-scripts"
DOCKER_IMAGE="openroad/orfs:latest"

PLATFORM="sky130hd"
DESIGN="ibex"
DESIGN_CONFIG="./designs/${PLATFORM}/${DESIGN}/config.mk"

GOLDEN_FILE="designs/${PLATFORM}/${DESIGN}/metadata-base-ok.json"
RULES_FILE="designs/${PLATFORM}/${DESIGN}/rules.json"
REPORT_OUT="${WORK_DIR}/ibex_报告摘要.txt"

# --------------------------- 日志辅助 ----------------------------------------
log()  { echo -e "\033[1;32m[STEP]\033[0m $*"; }
warn() { echo -e "\033[1;33m[WARN]\033[0m $*"; }
err()  { echo -e "\033[1;31m[ERROR]\033[0m $*" >&2; }

usage() {
    grep '^#' "$0" | head -20
    exit 1
}

[[ -z "$MODE" || ( "$MODE" != "docker" && "$MODE" != "local" ) ]] && usage

# --------------------------- Docker 模式下 make 包装 --------------------------
# Docker 模式下，所有 make 命令通过容器执行，挂载工作目录
run_make() {
    if [[ "$MODE" == "docker" ]]; then
        docker run --rm \
            -u "$(id -u):$(id -g)" \
            -e DISPLAY="${DISPLAY:-:0}" \
            -v /tmp/.X11-unix:/tmp/.X11-unix \
            -v "${ORFS_DIR}:/OpenROAD-flow-scripts" \
            -w /OpenROAD-flow-scripts/flow \
            --network host \
            "${DOCKER_IMAGE}" make "$@"
    else
        (cd "${ORFS_DIR}/flow" && make "$@")
    fi
}

# =============================================================================
# 阶段 0：准备环境
# =============================================================================
log "阶段 0/4：克隆 OpenROAD-flow-scripts 到 ${ORFS_DIR}"
mkdir -p "${WORK_DIR}"

if [[ ! -d "${ORFS_DIR}/.git" ]]; then
    if [[ "$MODE" == "local" ]]; then
        # 本地编译需要子模块（OpenROAD 工具源码）
        git clone --recursive https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts "${ORFS_DIR}"
    else
        git clone https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts "${ORFS_DIR}"
    fi
else
    log "仓库已存在，跳过克隆（如需更新可手动 git pull）"
fi

# ---- Docker 模式：拉镜像 ----
if [[ "$MODE" == "docker" ]]; then
    log "拉取预构建镜像 ${DOCKER_IMAGE}（含 OpenROAD/Yosys/KLayout 全部依赖）"
    docker pull "${DOCKER_IMAGE}"
fi

# ---- 本地模式：安装依赖并编译 ----
if [[ "$MODE" == "local" ]]; then
    if [[ "$EXTRA_ARG" == "--skip-build" ]]; then
        log "检测到 --skip-build，跳过依赖安装与编译"
    else
        log "安装系统依赖（需要 sudo 权限）"
        sudo "${ORFS_DIR}/setup.sh"

        log "本地编译 OpenROAD（约 0.5~2 小时，请耐心等待）"
        (cd "${ORFS_DIR}" && ./build_openroad.sh --local)
    fi

    log "加载环境变量并验证工具链"
    source "${ORFS_DIR}/env.sh"
    yosys -V
    openroad -version
fi

# =============================================================================
# 阶段 1：gcd 自检（默认设计 nangate45/gcd，验证环境可用）
# =============================================================================
log "阶段 1/4：运行默认设计 gcd 自检环境"
run_make gcd
log "gcd 自检通过，环境正常"

# =============================================================================
# 阶段 2：跑 sky130hd/ibex 主流程
# =============================================================================
log "阶段 2/4：运行 ${PLATFORM}/${DESIGN} 主流程（综合→布局→CTS→布线→GDS）"
run_make DESIGN_CONFIG="${DESIGN_CONFIG}"
log "主流程完成"

# =============================================================================
# 阶段 3：生成指标汇总并与官方 golden 值对比
# =============================================================================
log "阶段 3/4：汇总指标并与官方 golden 值对比"
run_make DESIGN_CONFIG="${DESIGN_CONFIG}" metadata

{
    echo "============================================================"
    echo " ORFS ${PLATFORM}/${DESIGN} 运行报告"
    echo " 生成时间：$(date '+%Y-%m-%d %H:%M:%S')"
    echo "============================================================"
    echo
    echo "----- 1. 日志文件位置（按流程阶段） -----"
    ls -1 "${ORFS_DIR}/flow/logs/${PLATFORM}/${DESIGN}/base/" 2>/dev/null || true
    echo
    echo "----- 2. 最终产物 -----"
    ls -1 "${ORFS_DIR}/flow/results/${PLATFORM}/${DESIGN}/base/" 2>/dev/null || true
    echo
    echo "----- 3. 本次运行关键指标（从最终报告提取） -----"
    FINAL_RPT="${ORFS_DIR}/flow/reports/${PLATFORM}/${DESIGN}/base/6_report.rpt"
    if [[ -f "${FINAL_RPT}" ]]; then
        grep -E "Chip area|Core area|utilization|tns |wns " "${FINAL_RPT}" | head -30 || true
    else
        echo "(未找到 6_report.rpt，可运行 make DESIGN_CONFIG=${DESIGN_CONFIG} gui_final 后在 GUI 中执行 report_design_area / report_wns / report_power)"
    fi
    echo
    echo "----- 4. 官方 golden 值（metadata-base-ok.json） -----"
    cat "${ORFS_DIR}/${GOLDEN_FILE}" 2>/dev/null || echo "(未找到 golden 文件)"
    echo
    echo "----- 5. CI 判定规则（rules.json：各指标容差） -----"
    cat "${ORFS_DIR}/${RULES_FILE}" 2>/dev/null || echo "(未找到 rules 文件)"
    echo
    echo "============================================================"
    echo " 判定方法："
    echo "  - WNS >= 0 且 TNS = 0  → 时序达标"
    echo "  - DRC violations = 0   → 布线达标"
    echo "  - 实际指标与 golden 值偏差在 rules.json 容差内 → 全流程达标"
    echo "============================================================"
} | tee "${REPORT_OUT}"

# =============================================================================
# 阶段 4：收尾提示
# =============================================================================
log "阶段 4/4：全部完成！"
cat <<EOF

  报告摘要已保存：${REPORT_OUT}
  版图 GDS：      ${ORFS_DIR}/flow/results/${PLATFORM}/${DESIGN}/base/6_final.gds

  后续可以手动执行的进阶操作：
  ----------------------------------------------
  # 打开 GUI 查看版图（注意必须带 DESIGN_CONFIG！）
  cd ${ORFS_DIR}/flow
  make DESIGN_CONFIG=${DESIGN_CONFIG} gui_final

  # GUI 的 Tcl 命令窗口中可交互查询指标：
  #   report_design_area     # 面积
  #   report_wns; report_tns # 时序
  #   report_power           # 功耗

  # 参数对照实验（修改利用率后重跑）：
  #   vim ${ORFS_DIR}/${GOLDEN_FILE%/*}/config.mk   # 改 CORE_UTILIZATION
  #   make clean_all && make DESIGN_CONFIG=${DESIGN_CONFIG}

  # 换工艺节点（命令格式相同）：
  #   make DESIGN_CONFIG=./designs/nangate45/ibex/config.mk
  #   make DESIGN_CONFIG=./designs/asap7/ibex/config.mk
  ----------------------------------------------
EOF