OpenClaw 终于让我实现了长久以来的一个想法：串通基于全开源 EDA flow 的芯片设计流程。这其中涉及大量工具的安装和流程脚本的编写，原本需要耗费无数精力，但 OpenClaw 仅用一天时间就帮我搞定了整个流程。
🎯 设计目标
- 基于 PicoSoC 架构的增强版 RISC-V SoC
- 集成多种常用外设 (UART, GPIO, I2C, PWM, Timer, SPI)
- 适用于嵌入式控制和物联网应用
- 目标频率： 100 MHz
- 工艺节点： SkyWater 130nm (sky130hd)
📄 芯片SPEC
顶层规格
| 参数 |
规格 |
备注 |
| 处理器架构 |
RISC-V RV32IM |
32位整数+乘除法 |
| 指令集 |
RV32I + M + C |
基础整数+乘除+压缩 |
| 系统时钟 |
100MHz |
PLL从20MHz倍频 |
| 复位方式 |
异步复位，同步释放 |
低电平有效 |
| 工作电压 |
1.8V (数字) |
SkyWater 130nm |
| 工艺节点 |
130nm |
SkyWater开源PDK |
| 标准单元 |
sky130_fd_sc_hd |
高密度单元库 |
性能规格
| 指标 |
目标 |
实测/估计 |
| DMIPS/MHz |
>1.0 |
~1.2 (估计) |
| CoreMark/MHz |
>2.0 |
~2.5 (估计) |
| 功耗 |
<100mW |
待测量 |
| 门数 |
<500K |
381,865 |
| 面积 |
<10mm² |
- |
系统架构
（架构图由 OpenClaw 生成，仅供参考）
模块清单
| 模块名称 |
描述 |
来源 |
状态 |
| riscv_soc |
顶层模块 |
自定义 |
✅ |
| picorv32 |
RISC-V CPU 核心 |
开源 |
✅ |
| picosoc_mem |
片上 RAM |
开源 |
✅ |
| simpleuart |
UART 控制器 |
开源 |
✅ |
| spimemio |
SPI Flash 接口 |
开源 |
✅ |
| crg |
时钟复位生成 |
自定义 |
✅ |
| pll |
锁相环 |
自定义 |
✅ |
| gpio_apb |
GPIO 控制器 |
自定义 |
✅ |
| timer_apb |
定时器 |
自定义 |
✅ |
| i2c_apb |
I2C 控制器 |
自定义 |
✅ |
| pwm_apb |
PWM 控制器 |
自定义 |
✅ |
处理器规格
CPU 核心 (PicoRV32)
| 参数 |
规格 |
| 架构 |
RV32IMC (32位 RISC-V) |
| 指令集 |
RV32I + M (乘法) + C (压缩) |
| 流水线 |
单周期执行 |
| 寄存器 |
32个通用寄存器 |
| 乘法器 |
硬件乘法 (单周期) |
| 除法器 |
硬件除法 (多周期) |
| Barrel Shifter |
硬件移位器 |
| 压缩指令 |
支持 (RVC) |
| 中断 |
支持 32 个中断源 |
| 计数器 |
支持 (MCYCLE, MINSTRET) |
内存规格
片上 RAM
| 参数 |
规格 |
| 类型 |
SRAM (触发器实现) |
| 容量 |
16 KB (4096 × 32-bit) |
| 字宽 |
32-bit |
| 字节使能 |
4-bit (支持字节/半字/字访问) |
| 地址范围 |
0x0000_0000 - 0x0000_3FFF |
物理规格
工艺信息
| 参数 |
规格 |
| 工艺节点 |
SkyWater 130nm |
| 库类型 |
sky130hd (高密度) |
| 电压 |
1.8V (数字)， 3.3V (IO) |
| 温度 |
25°C (典型) |
物理规格
| 参数 |
数值 |
单位 |
| 芯片尺寸 |
3.14 × 3.14 |
mm |
| 芯片面积 |
9.86 |
mm² |
| 利用率 |
51 |
% |
| 标准单元数 |
381,865 |
个 |
| 触发器数 |
133,682 |
个 |
| 金属层数 |
5 |
层 (met1-met5) |
| 引脚数 |
54 |
个 |
| 主要单元类型 |
DFF, AOI, NAND, NOR, BUF |
- |
🔧 完整工具链
RTL 的开发和集成：根据指令下载开源 IP 或自研 IP。
安装工具：开源工具的安装由 OpenClaw 自己处理，我只在碰到问题时干预。
各种工具的 flow：OpenClaw 接收指令自动去写脚本，执行并纠错。
┌─────────────────────────────────────────────────────────────────────────────┐
│ RTL 设计阶段 (Design) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. 架构设计 │
│ ├── 规格定义 (Excel/Word) │
│ ├── 架构图 (Draw.io/Visio) │
│ └── 微架构文档 (Markdown) │
│ │
│ 2. RTL 编码 │
│ ├── 编辑器: Vim / VSCode │
│ ├── 语言: Verilog-2001 / SystemVerilog │
│ └── 版本控制: Git │
│ │
│ 3. Lint 检查 ⭐ 新增 │
│ ├── 工具: Verilator --lint-only │
│ ├── 工具: svlint │
│ └── 检查项: 语法/可综合性/命名规范/风格 │
│ │
│ 4. 代码审查 │
│ ├── 工具: GitHub/GitLab PR │
│ └── 检查项: 功能/时序/面积/功耗 │
└─────────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────────┐
│ 功能验证阶段 (Verification) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. 测试平台搭建 │
│ ├── 仿真器: Icarus Verilog │
│ ├── 波形查看: GTKWave │
│ └── 测试框架: cocotb (可选) │
│ │
│ 6. 单元测试 │
│ ├── 模块级测试 (Module Test) │
│ ├── 集成测试 (Integration Test) │
│ └── 系统测试 (System Test) │
│ │
│ 7. 回归测试 │
│ ├── 工具: Makefile自动化 │
│ └── 覆盖率: 代码覆盖率/功能覆盖率 │
│ │
│ 8. 形式验证 (Formal Verification) ⭐ 可选 │
│ ├── 工具: SymbiYosys │
│ └── 检查: 属性检查/等价性检查 │
└─────────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────────┐
│ 逻辑综合阶段 (Synthesis) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 9. RTL 综合 │
│ ├── 工具: Yosys │
│ ├── 库: sky130_fd_sc_hd │
│ └── 输出: 门级网表 (synth.v) │
│ │
│ 10. 逻辑优化 │
│ ├── 工具: ABC (集成在Yosys中) │
│ ├── 优化: 面积/时序/功耗 │
│ └── 输出: 优化后门级网表 │
│ │
│ 11. DFF 映射 │
│ ├── 工具: dfflibmap (Yosys) │
│ └── 映射: 标准单元DFF │
│ │
│ 12. 综合后仿真 ⭐ 新增 │
│ ├── 工具: Icarus Verilog + 标准单元库 │
│ └── 验证: 综合后网表功能正确性 │
└─────────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────────┐
│ 物理设计阶段 (Physical Design) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13. 导入设计 │
│ ├── 工具: OpenROAD (init) │
│ ├── 输入: 综合网表 + 约束文件(SDC) │
│ └── 输出: 初始数据库 (1_1_yosys.odb) │
│ │
│ 14. 布局 (Floorplan) │
│ ├── 工具: OpenROAD (floorplan) │
│ ├── 步骤: │
│ │ ├── 芯片尺寸定义 │
│ │ ├── IO引脚布局 │
│ │ ├── 宏单元布局 (如果有) │
│ │ └── 电源环规划 │
│ └── 输出: 2_floorplan.odb │
│ │
│ 15. 电源网络 (PDN) │
│ ├── 工具: OpenROAD (pdn) │
│ ├── 步骤: │
│ │ ├── 电源环生成 │
│ │ ├── 电源条带生成 │
│ │ └── 电源连接 │
│ └── 输出: 2_4_floorplan_pdn.odb │
│ │
│ 16. 放置 (Placement) │
│ ├── 工具: OpenROAD (place) │
│ ├── 步骤: │
│ │ ├── 全局放置 (Global Placement) │
│ │ ├── 详细放置 (Detailed Placement) │
│ │ ├── 时序优化 │
│ │ └── 拥塞优化 │
│ └── 输出: 3_place.odb │
│ │
│ 17. 时钟树综合 (CTS) │
│ ├── 工具: OpenROAD (cts) │
│ ├── 步骤: │
│ │ ├── 时钟树综合 │
│ │ ├── 时钟缓冲器插入 │
│ │ ├── 时钟网格生成 │
│ │ └── 时钟偏斜优化 │
│ └── 输出: 4_cts.odb │
│ │
│ 18. 布线 (Routing) │
│ ├── 工具: OpenROAD (route) │
│ ├── 步骤: │
│ │ ├── 全局布线 (Global Route) │
│ │ ├── 详细布线 (Detailed Route) │
│ │ ├── 布线优化 │
│ │ └── 天线修复 │
│ └── 输出: 5_route.odb， 6_final.odb │
│ │
│ 19. 寄生参数提取 (PEX) ⭐ 新增 │
│ ├── 工具: OpenROAD (rcx) 或 Magic │
│ ├── 输出: SPEF文件 │
│ └── 用途: 时序分析/功耗分析 │
└─────────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────────┐
│ 签核验证阶段 (Signoff) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 20. 静态时序分析 (STA) │
│ ├── 工具: OpenSTA (集成在OpenROAD中) │
│ ├── 输入: 最终网表 + SPEF + SDC │
│ ├── 检查: │
│ │ ├── 建立时间 (Setup) │
│ │ ├── 保持时间 (Hold) │
│ │ ├── 时钟偏斜 (Skew) │
│ │ └── 转换时间 (Transition) │
│ └── 输出: 时序报告 │
│ │
│ 21. 物理验证 (Physical Verification) │
│ ├── 21.1 DRC (设计规则检查) │
│ │ ├── 工具: Magic │
│ │ ├── 输入: GDS文件 │
│ │ ├── 检查: 间距/宽度/面积/密度等 │
│ │ └── 输出: DRC报告 │
│ │ │
│ ├── 21.2 LVS (版图vs原理图) │
│ │ ├── 工具: Netgen │
│ │ ├── 输入: GDS + 网表 │
│ │ ├── 步骤: │
│ │ │ ├── GDS提取网表 (Magic) │
│ │ │ └── 网表对比 (Netgen) │
│ │ └── 输出: LVS报告 │
│ │ │
│ └── 21.3 ERC (电气规则检查) ⭐ 新增 │
│ ├── 工具: Magic │
│ └── 检查: 开路/短路/浮空节点等 │
│ │
│ 22. 功耗分析 ⭐ 新增 │
│ ├── 工具: OpenROAD (power) │
│ ├── 输入: 最终网表 + 活动文件(VCD) │
│ └── 输出: 功耗报告 │
│ │
│ 23. 可靠性分析 ⭐ 新增 │
│ ├── 23.1 电迁移分析 (EM) │
│ │ └── 工具: OpenROAD │
│ ├── 23.2 压降分析 (IR Drop) │
│ │ └── 工具: OpenROAD │
│ └── 23.3 天线检查 │
│ └── 工具: Magic │
└─────────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────────┐
│ 流片准备阶段 (Tapeout) │
├─────────────────────────────────────────────────────────────────────────────┤
│ 24. GDS 生成 │
│ ├── 工具: OpenROAD 或 Magic │
│ ├── 输入: 最终布局数据库 │
│ └── 输出: 6_final.gds │
│ │
│ 25. 流片文档 │
│ ├── 25.1 设计文档 │
│ │ ├── 规格说明书 │
│ │ ├── 架构设计文档 │
│ │ └── 验证报告 │
│ ├── 25.2 物理文档 │
│ │ ├── 版图数据 (GDS) │
│ │ ├── LEF文件 │
│ │ └── 时序库 (LIB) │
│ └── 25.3 签核报告 │
│ ├── DRC报告 │
│ ├── LVS报告 │
│ └── STA报告 │
│ │
│ 26. 流片检查清单 (Tapeout Checklist) │
│ ├── ✅ 功能验证通过 │
│ ├── ✅ 时序收敛 │
│ ├── ✅ DRC清洁 │
│ ├── ✅ LVS通过 │
│ ├── ✅ 功耗满足规格 │
│ └── ✅ 文档完整 │
│ │
│ 27. 提交流片 (Tapeout) │
│ ├── 提交GDS到代工厂 │
│ ├── 提交文档到代工厂 │
│ └── 等待流片完成 │
└─────────────────────────────────────────────────────────────────────────────┘
项目的目录结构甚至相当规范， doc, rtl, tb, flow, sw, netlist 一应俱全。
riscv_soc/ # 项目根目录
│
├── 📂 rtl/ # RTL源代码
│ ├── riscv_soc_picosoc.v
│ ├── crg.v
│ └── ...
│
├── 📂 constraints/ # 时序约束
│ ├── constraint_final.sdc
│ └── constraint_obfuscated.sdc
│
├── 📂 ips/ # 第三方IP
│ ├── picorv32/ # RISC-V CPU
│ └── picosoc_integration/ # SoC集成
│
├── 📂 tb/ # Testbench
├── 📂 tests/ # 测试用例
├── 📂 software/ # 软件代码
│
├── 📂 synthesis/ # 综合结果
├── 📂 pr/ # 物理设计
│ ├── floorplan/
│ ├── placement/
│ ├── cts/
│ ├── routing/
│ └── final/
│
├── 📂 signoff/ # 签核检查
│ ├── drc/
│ ├── lvs/
│ └── erc/
│
├── 📂 docs/ # 文档
│ ├── reports/ # 分析报告
│ ├── images/ # 图片
│ └── specs/ # 规格书
│
├── 📂 scripts/ # 脚本工具
│ ├── synthesis/ # 综合脚本
│ ├── pr/ # 物理设计脚本
│ └── verification/ # 验证脚本
│
├── 📂 results/ # 设计结果
├── 📂 outputs/ # 最终输出(GDS)
│
├── 📂 tools/ # EDA工具配置
│ ├── openlane/
│ ├── orfs/
│ └── magic/
│
├── 📂 configs/ # 配置文件
│
└── 📄 README.md # 项目说明
✅ 验证报告
验证阶段自动搭建了测试平台，构造测试用例，所有测试均通过，并收集了覆盖率。我随便打开一个波形看了下，确实有模有样。
测试用例汇总
| 测试类别 |
用例数 |
通过 |
失败 |
| 基础功能测试 |
6 |
6 |
0 |
| 完整功能测试 |
4 |
4 |
0 |
| 覆盖率测试 |
13 |
13 |
0 |
| SPI Flash测试 |
4 |
4 |
0 |
| 总计 |
27 |
27 |
0 |
| 通过率 |
100% |
|
|
⏳代码覆盖率 (Code Coverage)
测量工具: Icarus Verilog + GTKWave
| 模块 |
当前覆盖率 |
目标 |
状态 |
| picorv32 |
78% |
90% |
⏳ 提升中 |
| picosoc_mem |
95% |
95% |
✅ 达标 |
| simpleuart |
85% |
90% |
⏳ 提升中 |
| gpio_apb |
90% |
90% |
✅ 达标 |
| timer_apb |
88% |
90% |
⏳ 提升中 |
| i2c_apb |
70% |
85% |
⏳ 提升中 |
| pwm_apb |
75% |
85% |
⏳ 提升中 |
| spimemio |
60% |
80% |
⏳ 提升中 |
| crg |
95% |
95% |
✅ 达标 |
总体覆盖率: 78% → 目标: 90%+
⏳功能覆盖率 (Functional Coverage)
测试平台: tb_riscv_soc_coverage.v
| 功能点 |
测试状态 |
覆盖率 |
| 复位测试 |
✅ 已测试 |
100% |
| 内存边界 |
✅ 已测试 |
90% |
| UART中断 |
✅ 已测试 |
95% |
| GPIO所有引脚 |
✅ 已测试 |
95% |
| Timer所有模式 |
✅ 已测试 |
85% |
| 所有中断源 |
✅ 已测试 |
90% |
| SPI Flash命令 |
✅ 已测试 |
80% |
| I2C事务 |
✅ 已测试 |
75% |
| PWM所有通道 |
✅ 已测试 |
85% |
| 非法指令 |
⏳ 占位 |
0% |
| 除零 |
⏳ 占位 |
0% |
| 栈溢出 |
⏳ 占位 |
0% |
| 外设组合 |
✅ 已测试 |
80% |
总体功能覆盖率: 72% → 目标: 90%+
📊 后端报告
本报告总结了 RISC-V SoC 项目的中后端工作当前状态，包括已完成和待完成的工作。
| 阶段 |
状态 |
完成度 |
关键指标 |
| 逻辑综合 |
✅ 完成 |
100% |
381,865门，133,682触发器 |
| 物理设计 |
✅ 完成 |
100% |
5mm²，51%利用率 |
| 时序分析 |
⚠️ 有条件 |
80% |
建立时间违例-1591ns |
| 签核验证 |
⏳ 进行中 |
60% |
Magic已安装，DRC待进行 |
| 整体进度 |
有条件通过 |
85% |
预计1-2周完成 |
1️⃣ 已完成工作
1.1 逻辑综合 (100% 完成)
| 任务 |
状态 |
输出 |
说明 |
| RTL读取 |
✅ |
- |
成功读取所有RTL文件 |
| 层次分析 |
✅ |
- |
完成模块层次分析 |
| 逻辑优化 |
✅ |
- |
ABC优化完成 |
| 技术映射 |
✅ |
- |
映射到sky130hd库 |
| DFF映射 |
✅ |
- |
触发器映射完成 |
| 网表输出 |
✅ |
49MB |
最终网表生成 |
关键数据:
- 标准单元： 381,865个
- 触发器： 133,682个
- 组合逻辑： 248,183个
1.2 物理设计 (100% 完成)
| 阶段 |
状态 |
数据库 |
说明 |
| 初始化 |
✅ |
1_1_yosys.odb (159M) |
读取网表完成 |
| 布局 |
✅ |
2_floorplan.odb (203M) |
芯片尺寸2237×2237μm |
| PDN |
✅ |
2_4_floorplan_pdn.odb (203M) |
电源网络完成 |
| 放置 |
✅ |
3_place.odb (203M) |
所有单元已放置 |
| CTS |
✅ |
4_cts.odb (203M) |
时钟树综合完成 |
| 布线 |
✅ |
5_route.odb (211M) |
所有网络已布线 |
| 最终 |
✅ |
6_final.odb (211M) |
物理设计完成 |
关键数据:
- 芯片面积： 9.86 mm²
- 实例面积： 4.93 mm²
- 利用率： 51%
- 金属层： 5层 (met1-met5)
2️⃣ 待完成工作
2.1 时序收敛 (优先级： 高)
| 任务 |
状态 |
问题 |
解决方案 |
| 约束修复 |
⏳ |
端口名不匹配 |
使用实际端口名 |
| 时序优化 |
⏳ |
建立时间违例 |
降频或优化约束 |
| 时序签核 |
⏳ |
待验证 |
修复后重新分析 |
2.2 DRC检查 (优先级： 高)
| 任务 |
状态 |
工具 |
说明 |
| DRC运行 |
⏳ |
Magic |
工具已安装，待执行 |
| DRC修复 |
⏳ |
Magic |
根据结果修复 |
| DRC签核 |
⏳ |
- |
清洁后通过 |
2.3 LVS检查 (优先级： 高)
| 任务 |
状态 |
工具 |
说明 |
| GDS提取 |
⏳ |
Magic |
从GDS提取SPICE网表 |
| LVS对比 |
⏳ |
Netgen |
对比版图和原理图 |
| LVS修复 |
⏳ |
- |
根据结果修复 |
2.4 功耗分析 (优先级： 中)
| 任务 |
状态 |
工具 |
说明 |
| 功耗估算 |
⏳ |
OpenROAD |
静态功耗分析 |
| 动态功耗 |
⏳ |
OpenROAD |
需要VCD文件 |
| IR Drop |
⏳ |
OpenROAD |
压降分析 |
| 电迁移 |
⏳ |
OpenROAD |
EM分析 |
从前端 RTL 到中后端物理设计，再到最终 GDS 生成，全程我一行代码都没写，只负责下达指令。当然，这个过程产出的初始质量肯定存在各种问题，需要用户不断提出需求、进行迭代优化。
🤔 对于OpenClaw的思考
关于当前这股 “OpenClaw 狂潮”，我也有一些自己的看法。
我采用的是本地电脑部署加购买 API token 的方式。现阶段直接烧 token 成本不低，如果不用它来做自动化工作，日常使用体验可能还不如直接调用各家大模型。
OpenClaw 的核心价值在于自动化。它可以部署多个智能体（Agent）来扮演不同角色，协作完成复杂任务。但需要注意的是，它的能力上限取决于背后大模型的能力，它本身并不会比原始模型更“聪明”。
它具备长时记忆功能，所有学习到的数据都保存在本地，这让我有机会把它培养成专属的“贾维斯”——一个不断学习我的使用习惯和需求，并随着基础模型升级而越来越强大的助手。
它可以 24 小时不间断工作。对于编程以及各种重复性、零碎、繁琐的工作场景，它完全能够胜任，并且未来的想象空间巨大。
当然，整个过程仍然需要人工干预和审核。不过，它对于个人生产力的提升是显著的，能够帮助我延伸技能边界。其能力很大程度上取决于我为它装备的技能（Skills）。
值得注意的是，芯片设计领域的三大 EDA 巨头（Synopsys, Cadence, Siemens EDA）都已经推出了各自的 AI 辅助设计工具。这意味着，芯片设计的方式和工作流程即将发生巨大的变化。
| 维度 |
Synopsys |
Cadence |
Siemens EDA |
| 旗舰平台 |
Synopsys.ai |
JedAI + ChipStack |
EDA AI System |
| AI层级 |
优化AI + 生成式AI |
优化AI + Agentic AI |
生成式AI + Agentic AI |
| 核心优势 |
流片数量最多，覆盖全流程 |
前端Agentic AI领先（ChipStack） |
数字孪生+多物理场集成 |
| 最新发布 |
Synopsys.ai Copilot |
ChipStack AI Super Agent (2026.03) |
Questa One Toolkit (2026.03) |
最后提一句，本篇文章大约 95% 的内容是由 OpenClaw 生成的。整个体验让我深刻感受到，结合像云栈社区这样的技术交流平台，与AI工具协同工作，将是未来开发者探索新领域的高效方式。
发表于 3 小时前
|
查看: 4|
回复: 0
