告别「肉身搬运工」：我做了一个 SoC 设计 Skill，把自己从重复劳动里“替代”了出来。
SoC Build 是一套 SoC 前端 RTL 自动化构建工具集。它通过自然语言交互，完成 SoC 项目初始化、模块集成、CRG 生成、PINMUX 生成等工作。更关键的是，它提供 MCP Server，让 AI 助手可以直接调用 Skill 内部集成的所有工具——任何支持 MCP 协议的 AI 客户端（如 Kimi Code、Claude Code、Cursor 等）都能使用。同时它也提供 SKILL.md 方式，让 AI 自己生成 CLI 命令，OpenClaw 等客户端亦可接入。
一、项目脚手架
场景1：初始化 SoC 项目
用户输入："帮我初始化一个 soc 项目"
执行：根据项目名称和输出路径，生成标准化 SoC 目录结构。
输出：项目骨架，目录结构如下：
<project_name>/
├── Makefile # 项目顶层入口
├── README.md
├── chip/ # RTL 设计源码
│ ├── core/ # 子模块（目录结构与 IP 一致）
│ │ ├── de/rtl # RTL 源码 + filelist.mk
│ │ ├── de/run # lint / 综合输出
│ │ ├── dv/tb # Testbench
│ │ ├── dv/sim # 仿真输出
│ │ └── Makefile # 模块级 Makefile
│ ├── bus/ # 同上
│ ├── periph/ # 同上
│ ├── interconnect/ # 同上
│ ├── lib/ # 同上
│ └── top/ # 芯片级顶层（也是芯片级仿真入口）
│ ├── de/rtl/{top}.v # 顶层 RTL（含示例逻辑）
│ ├── de/rtl/filelist.mk # 模块依赖管理
│ └── Makefile
├── ip/ # IP 目录
│ ├── digital/ # 自研 IP
│ │ └── template_ip/ # IP 模板（可独立仿真）
│ └── third_party/ # 第三方 IP
├── doc/ # 文档
│ ├── arch/
│ └── spec/
└── scripts/ # 公共脚本
├── setup.sh # 环境初始化
└── common.mk # 公共仿真编译规则
设计原则：
- 每个子模块（core/bus/periph/interconnect/lib/top）和 IP 的目录结构完全一致
- 设计（
de/）和验证（dv/）分离
- 整个项目统一开发环境配置
新增IP目录
用户输入："帮我添加一个third_party IP目录uart"
执行：新增 ip 模块
输出：在third_party目录下生成与项目统一的uart ip目录结构。支持新增IP模块（chip、digital、third_party）目录。
二、编译与Lint
场景2：模块编译与Lint
用户输入："编译这个模块" / "做 lint 检查"
执行：在模块目录下执行 Makefile 目标。
cd chip/top # 或 ip/digital/xxx
cd de && make comp # 编译（de/ 下默认顶层为 RTL 模块）
cd dv && make comp # 编译（dv/ 下默认顶层为 tb）
make lint # lint检查
支持仿真器：Verilator、Iverilog（暂时只支持开源EDA，添加方便）
场景3：filelist依赖管理
用户输入："这个模块依赖了 core，怎么加到 filelist"
执行：在子模块的 de/rtl/filelist.mk 中声明依赖，父模块 Makefile 启用依赖传递。
# chip/top/de/rtl/filelist.mk
include $(PROJECT_ROOT)/chip/core/de/rtl/filelist.mk
父模块 Makefile 中取消注释：
include $(RTL_PATH)/filelist.mk
make comp 时 dut.f 会自动按依赖顺序展开所有子模块的 RTL，并标注 // -f ... 来源。filelist.mk 在注册到 MODULE_FILELISTS 时会自动去重，避免同一模块被重复添加。
soc-build 中有三种 filelist，分别服务于不同场景：
1. filelist.f — 模块级 RTL 文件列表
生成方式：make flist
位置：chip/<module>/de/rtl/filelist.f 或 ip/<category>/<ip>/de/rtl/filelist.f
内容：自动扫描 de/rtl/ 目录下所有 .v / .sv 文件
# Auto-generated filelist: filelist.f
$SOC/chip/core/de/rtl/core.v
作用：作为本模块的 RTL 文件清单，被 filelist.mk 引用。
2. dut.f — 仿真编译文件列表（RTL + TB）
生成方式：make comp 时自动生成（依赖 flist）
位置：dv/sim/dut.f（IP）或 chip/top/dv/sim/dut.f（chip top）
内容：通过 filelist.mk 依赖链汇总所有子模块的 RTL，加上 testbench 文件（后续会优化将环境与dut filelist分开）
// -f /path/to/core/rtl/filelist.f
$SOC/chip/core/de/rtl/core.v
// -f /path/to/top/rtl/filelist.f
$SOC/chip/top/de/rtl/soc_top.v
$SOC/chip/top/de/rtl/top.v
$SOC/chip/top/dv/tb/tb_top.sv
3. rtl.f — Lint 检查文件列表（纯 RTL，不含 TB）
生成方式：make lint 时自动生成
位置：de/run/rtl.f
内容：只包含 RTL 文件，不含 testbench
// -f /path/to/core/rtl/filelist.f
$SOC/chip/core/de/rtl/core.v
// -f /path/to/top/rtl/filelist.f
$SOC/chip/top/de/rtl/soc_top.v
- 过滤掉
dv/tb/ 下的 testbench 文件
- 用于 lint 检查、综合等flow（不需要 TB 参与）
三、顶层集成
场景4：提取模块端口
用户输入："提取这个模块的端口" / "看看这个模块有什么接口"
执行：解析指定 Verilog 文件，提取模块参数和端口信息。
输出：模块的参数列表、端口方向、位宽、名称。
场景5：生成实例化代码
用户输入："帮我生成这个模块的实例化代码"
执行：根据模块端口信息，生成标准化的实例化代码。
输出：对齐格式的 .port(signal) 实例化代码，含位宽标注。
场景6：集成模块到顶层
用户输入：
- "把这几个模块集成到顶层"
- "生成 soc 顶层"
- "把这些 verilog 文件集成一下"
执行：解析所有子模块端口，按智能连接规则生成顶层模块。
输出：
- 顶层 RTL 文件（含端口声明、内部 wire、模块实例化）
- 集成配置文件（记录模块路径、端口快照、连接关系）
- Review 表格（CSV 格式，供人工审阅）
智能连接规则：
- 同名 input 端口 → 共享为顶层 input
- output + input 混合 → 内部 wire（output 驱动 input）
- output + output → 各自独立，加模块前缀区分
场景7：端口变更追踪
用户输入：
- "对比下这个模块端口有没有变"
- "检查端口是否符合规范"
执行：保存端口快照，与当前端口对比，检测新增、删除、修改。
输出：变更报告（新增列表、删除列表、修改列表）。
场景8：刷新顶层（子模块更新后）
用户输入：
- "子模块端口变了，更新下顶层"
- "刷新 soc_top"
- "重新生成顶层"
执行：读取已有集成配置，重新提取子模块端口，检测变更并重新生成顶层。
输出：更新后的顶层 RTL，实例化注释含变更标记。
变更标记：
[NEW] — 新增端口[MOD] — 方向/位宽修改[DEL] — 已删除端口（实例化末尾保留注释）
场景9：保留手动修改的连线
用户输入：
- "我手动改了顶层，帮我同步到配置"
- "提取当前顶层的连接关系"
执行：从手动修改后的顶层文件中提取实例化连接关系，同步回配置文件，再重新生成顶层。
输出：保留手动连线的最新顶层 RTL。
四、RTL 自动生成
场景10：生成 CRG
用户输入：
- "帮我生成 CRG"
- "生成时钟复位模块"
- "从 Excel 生成 Verilog"
执行：解析 Excel 配置文件，生成时钟和复位模块。
输出：
<name>_clk_gen.v — 时钟生成<name>_rst_gen.v — 复位生成<name>_crg_top.v — CRG 顶层<name>_crg.yml / <name>_crg_regfile.v — 寄存器描述与 RTL.sdc — clk tree约束文件
场景11：生成 IO/PINMUX
用户输入："生成 IO pad" / "生成 pinmux"
执行：解析 IO 配置，生成 pad 和 pin-mux 相关模块。支持 DFT、DS/ST/SL/MSC/PS/HE/PE 等高级 pad 控制，自动生成寄存器文件和 SDC 约束。
输出：
io_top_top.v / io_top_top_model.v — 顶层集成io_top_ring.v — IO Ringio_top_pin_mux.v / io_top_pin_mux_model.v — Pin MuxIO_TOP.yml / IO_TOP_apb_regfile.v — 寄存器描述与 RTLio_top.sdc — SDC 约束
场景12：生成寄存器 RTL
统一的项目寄存器flow管理
用户输入："从 YML 生成寄存器文件" / "帮我生成 apb regfile"
执行：解析 YAML 寄存器描述，生成 APB/AHB 接口的 Verilog regfile。
用法：
protocol — apb | ahb- Demo 文件：
scripts/yml2reg/demo_reg.yml
输出：<NAME>_<PROTOCOL>_regfile.v
场景13：从 Excel 生成寄存器 RTL
可读性更高，更易于用户填写的寄存器表格
用户输入："从 Excel 生成寄存器" / "excel 转 yml"
执行：解析 Excel 寄存器描述，自动生成 YAML 和 Verilog regfile。
输出：<NAME>.yml、<NAME>_apb_regfile.v、<name>_reg_inst.v
场景14：生成 Memory Map
用户输入："生成地址映射" / "memory map"
执行：解析 Excel memorymap sheet，生成地址映射 YML。
输出：<project_name>_ASIC.yml（含各 address block 的 name/offset/size/子模块 yml file）
场景15：生成 Memory Wrapper
用户输入："生成 memwrap" / "memory wrapper"
执行：生成 memory wrapper 模块
芯片 Vibe Coding
这套 Skill 全部采用 Vibe Coding 的方式编写。也就是说，用自然语言描述需求，0 手动编码，由 AI 生成代码；再让 AI 自己看报错信息自动修复。整个过程里，我只需要关注 AI 的进展，在它跑偏时拉回来就行。主要使用的客户端是国产的 Kimi Code。
SoC Build Skill 的最终目标，就是实现 SoC 设计工作的 Vibe Coding：0 手动编码，100% 自然语言驱动。
它并不是一把能解决所有问题的“银弹”，聚焦的是“重复劳动”和“规范统一”这两件事。架构设计、时序分析、低功耗策略——这些仍然需要工程师的专业判断。SoC Build 真正的价值在于对抗 AI 幻觉，保证每一次指令、每一次运行输出的内容都是确定的，这才符合芯片设计的基本要求。它要做的是将工程师在某些局部环节的工作效率提高 1000%。
让工程师回归工程师，让工具回归工具。
本文介绍的是第一个版本已加入的功能，后续还会有更多完善和细化的能力加入。Skill 本身暂时未发布，但你可以通过下面的链接查看生成的初始化项目展示，后续进展也会持续在 云栈社区 更新。
发表于 昨天 22:24
|
查看: 2|
回复: 0
