前两篇文章分享了 SoC 设计里用 Skill 替我干体力活。但 Skill 执行还得我手动提指令，多少有点不过瘾。能不能只给一句话需求，让 AI 自己调用 Skill、把剩下的活全干完，人工只做最后审查和验收？于是硅农 Agent 应运而生——不只单 Agent，而是多 Agent 集群。我把它命名为硅农 Agent 集群，SiliconPeasant Crew，简称 silicon-crew 🚀
🤔 什么是 silicon-crew？
RTL 设计是一个高度流程化的工作：先写规格书，再写 RTL，再搭验证环境跑仿真，最后做逻辑综合检查时序。每一个环节都需要不同的专业知识和工具链。
silicon-crew 的核心理念是：把 RTL 设计的四个阶段交给四个专门的 AI Agent 来做 🤖⚡
| 阶段 |
Agent |
职责 |
产物 |
| 📄 Doc |
soc-doc-engineer |
写设计规格、接口定义、验证计划 |
design_spec.md, interface_spec.md, verification_plan.md |
| 💻 RTL |
soc-rtl-designer |
写 Verilog RTL、Lint 检查、SDC 约束 |
uart.v, uart.sdc |
| 🧪 Verif |
soc-verification-engineer |
写 Testbench、功能仿真 |
tb_uart.v, 仿真报告 |
| ⚡ Syn |
soc-synthesis-engineer |
逻辑综合、时序分析、面积报告 |
netlist.v, timing.rpt, area.rpt |
一个主 Agent 👑 负责协调：接收用户需求、派发任务、检查产物、更新状态。主 Agent 自己不写 RTL，只指挥专业 Agent 干活。
🏗️ silicon-crew 架构设计
🤖 Agent 集群框架
silicon-crew 基于 Claude Code Agent 框架，由 Agent 定义、强制规则、MCP 工具链、状态机和质量门禁五层组成。
silicon-crew 支持主 Agent + subagent 的协作模型：
┌─────────────────────────────────────────┐
│ Main Thread (主 Agent) 👑 │
│ • 接收用户输入 │
│ • 规划任务、选择 subagent │
│ • 检查结果、更新状态 │
└────────────┬────────────────────────────┘
│ spawn 🚀
▼
┌─────────────────────────────────────────┐
│ Subagent A (独立 Claude 实例) 🤖 │
│ • 独立的上下文窗口 │
│ • 独立的 tool 权限 │
│ • 执行完成后返回结果 │
└─────────────────────────────────────────┘
│ spawn (并行) 🚀🚀
▼
┌─────────────────────────────────────────┐
│ Subagent B (独立 Claude 实例) 🤖 │
│ • 与 Subagent A 并行运行 │
│ • 互不干扰，同时写不同文件 │
└─────────────────────────────────────────┘
关键特性：
| 特性 |
说明 |
| 🧠 独立上下文 |
每个 subagent 有独立的对话历史，不会污染主 Agent |
| ⚡ 并行执行 |
多个 subagent 可以同时运行（如 verif 和 syn 并行） |
| 🔐 工具权限隔离 |
subagent 的权限由主 Agent 控制，可限制可用工具 |
| 🌿 worktree 隔离 |
可选在独立 git worktree 中运行，避免文件冲突 |
| 💬 自然语言调度 |
主 Agent 用自然语言 prompt 向 subagent 派任务 |
🔄 4 阶段流水线设计
Verif 和 Syn 也可并行 ⚡
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
| 📄 |───→| 💻 |───→| 🧪 |───→| ⚡ |
| Doc | | RTL | | Verif | | Syn |
└─────────┘ └─────────┘ └─────────┘ └─────────┘
📜 强制规则：5 条铁律
规则文件放在 rules/ 目录，通过 Claude Code 的 SessionStart Hook 在每个会话开始时自动注入到主 Agent 上下文中。这意味着：每个新会话的第一条消息，主 Agent 已经知道所有规则
| 规则文件 |
核心内容 |
01_swarm_flow.md |
主 Agent 必须 spawn subagent，禁止自己写 RTL；RTL done 后 verif/syn 必须并行 |
02_toolchain.md |
EDA 操作必须走 Makefile 或 MCP 工具，禁止直接调用 verilator/iverilog/yosys |
03_exceptions.md |
std_cell/ 可跳过 doc 阶段；bug 修复 <20 行可跳过 doc |
04_coding_style.md |
Verilog-2005、异步低有效复位、严禁 latch 推断、参数 UPPER_SNAKE_CASE |
05_pipeline_state.md |
每个模块必须有 pipeline_state.json，每阶段完成后必须 update_state.py |
🔧 MCP 工具链
首发版本预装四个 Skill 🛠️
soc-build — 项目脚手架与 EDA 执行 🏗️
soc-integrate — 顶层集成与端口管理 🔌
cr-tree-diag-gen — 时钟/复位树图 🌳
crg-req-to-design — CRG 需求转换（下篇预告即将发布 🔔）
📊 Pipeline State：单一事实来源
每个模块根目录下有一个 pipeline_state.json 📄，是唯一可信的状态源 🎯。
{
"ip": "uart",
"modules": {
"uart": {
"pipeline": {
"doc": { "status": "done", "artifacts": [...], "check_results": [...] },
"rtl": { "status": "done", "artifacts": [...], "check_results": [...] },
"verif": { "status": "done", "artifacts": [...], "check_results": [...] },
"syn": { "status": "done", "artifacts": [...], "check_results": [...] }
},
"next_actions": []
}
}
}
状态流转 🔄：
pending ➡️ in_progress ➡️ done
⬇️
fail ❌ (阻塞整个流水线)
每个 subagent 完成后必须调用 update_state.py 更新状态，主 Agent 在 spawn 下一个 agent 前必须调用 query_state.py 查询状态。这是协作的“心跳信号”——没有 state 更新，就没有协作。
🛡️ 质量门禁：4 道检查
📄 Doc 完成 ──→ check_doc_completeness.py ──→ PASS? ✅
│
💻 RTL 完成 ──→ check_rtl_quality.py ──→ PASS? ✅ (lint 0 warn 0 error)
│
🧪 Verif 完成 ──→ check_sim_pass.py ──→ PASS? ✅ (0 ERROR 0 MISMATCH)
│
⚡ Syn 完成 ──→ check_timing.py ──→ PASS? ✅ (WNS >= 0)
任何一道门检查失败，该阶段标记为 fail，流水线暂停，主 Agent 向用户报告失败原因和修复建议。正常情况每个 subagent 会在自己的 loop 里修复所有问题后退出。
📁 目录结构规范
<ip_name>/
├── Makefile # IP 级 Makefile (lint/comp/sim/syn) 📝
├── README.md
├── pipeline_state.json # 状态机 📊
├── de/ # Design Engineering (数字实现) 💻
│ ├── rtl/ # 可综合 RTL
│ │ ├── <module>.v
│ │ └── filelist.f # $SOC 路径前缀
│ ├── syn/ # 综合产物 ⚡
│ │ ├── <module>_netlist.v
│ │ ├── timing.rpt
│ │ ├── area.rpt
│ │ └── synth.log
│ └── run/ # Lint 中间文件 🧹
├── dv/ # Design Verification 🧪
│ ├── tb/
│ │ └── tb_<module>.v
│ └── sim/ # 仿真产物 (gitignored) 🚫
│ ├── sim.out
│ ├── wave.vcd
│ └── tb_<module>.log
└── docs/
└── <module>/
├── design_spec.md
├── interface_spec.md
└── verification_plan.md
这个目录结构不是建议，而是强制规范。所有 Agent 的 prompt 中都写明了这个布局，产物必须落在正确的目录。
🚀 怎么用：从一句话到 UART IP
好吧，第二大段的说明其实是写给你的 AI 看的 🤖，你可以不用看，你只需要知道怎么用 💡。来看下一个简单 IP 的执行过程。
用户只用说：
“在 digital 目录下新建一个 uart IP 目录，设计一个 uart 模块”
4 个 Agent 协作后，产出了完整的可交付 IP 📦。
📄 Phase 1：Doc — 规格文档自动生成
主 Agent 的第一步决策 🎯：uart 不是标准单元，不能跳过文档阶段。会先找用户确认规格说明。先 spawn doc-engineer 🤖。
Design a practical UART IP with:
- 8-bit data transmission (8N1 format)
- Configurable baud rate via clock divider
- TX with ready/valid handshake
- RX with 16x oversampling and framing error detection
- 100MHz system clock support
Deliverables:
1. docs/uart/design_spec.md
2. docs/uart/interface_spec.md
3. docs/uart/verification_plan.md
Doc Agent 返回（耗时 5.7 分钟 ⏱️）：
Files created:
- docs/uart/design_spec.md (332 lines)
- docs/uart/interface_spec.md (175 lines)
- docs/uart/regmap.md (占位)
- docs/uart/verification_plan.md (242 lines)
check_doc_completeness: PASS ✅
四份文档涵盖了 📚：
- design_spec：顶层框图、TX/RX 状态机、波特率分频表、时序图
- interface_spec：16 个端口的完整定义、ready/valid 握手协议、复位行为
- verification_plan：23 个功能点、14 个测试用例、覆盖率目标
💻 Phase 2：RTL — 代码实现
主 Agent 的决策 🎯：doc 完成，标记状态为 done，立即启动 RTL 阶段。
spawn rtl-designer 🤖：
RTL Designer 内部执行 🔧：
# 1. 读取规格文档 📖
cat docs/uart/design_spec.md
cat docs/uart/interface_spec.md
# 2. 编写 RTL (293 行) 📝
cat > de/rtl/uart.v << 'EOF'
module uart (
input wire clk,
input wire rst_n,
... // 16 个端口
);
// RX 2-stage synchronizer
// Baud rate generator (sample_tick + baud_tick)
// TX 4-state FSM
// RX 5-state FSM with 16x oversampling
endmodule
EOF
# 3. 写 SDC 📐
cat > de/syn/uart.sdc << 'EOF'
create_clock -period 10.0 [get_ports clk]
set_false_path -from [get_ports rst_n]
EOF
# 4. Lint 检查 🔍
make lint RTL_TOP=uart
# verilator --lint-only -Wall ...
# 0 warnings, 0 errors ✅
RTL 返回（耗时 1.9 分钟 ⏱️）：
RTL phase complete ✅
Files: uart.v (293 lines), uart.sdc, filelist.f
Lint: verilator -Wall 0 warn 0 error
Quality: passed 🎯
🧪⚡ Phase 3+4：并行 Verif + Syn
关键决策 🎯：RTL 完成后，验证和综合没有依赖关系，必须并行启动。
主 Agent 同时 spawn 两个 Agent 🤖🤖：
Agent A (verif-engineer) ──→ 写 TB + 仿真 🧪
↑ ↓
└──────── 并行 ⚡ ────────┘
↑ ↓
Agent B (syn-engineer) ──→ Yosys 综合 ⚙️
🧪 Verif Agent 执行记录
Prompt 要求覆盖 15 个测试场景 🎯，包括回环测试、毛刺过滤、全数据遍历等。
内部执行 🔧：
# 1. 写 837 行 testbench 📝
cat > dv/tb/tb_uart.v << 'EOF'
module tb_uart;
// DUT 实例化
// Clock/Reset 生成
// uart_send() task — 在 rx_in 上产生 8N1 串行波形
// uart_expect() task — 监控 tx_out 解析 8N1
// 20 个测试用例...
endmodule
EOF
# 2. 编译 🔨
make comp TOP_MODULE=tb_uart
# iverilog -g2012 -s tb_uart -o dv/sim/sim.out ...
# [COMP] 编译成功 ✅
# 3. 仿真 🧪
make sim TOP_MODULE=tb_uart
# cd dv/sim && vvp sim.out
# ...
# Test summary: PASS=85 ERROR=0
# RESULT: ALL TESTS PASS ✅
Verif 返回（耗时 17.8 分钟 ⏱️）：
20 tests, 85 checks, ALL PASS ✅, 0 ERROR, 0 MISMATCH
覆盖场景 🎯：
- 单字节收发、回环测试、LSB first
- 5 种波特率精度验证
- tx_ready 握手、tx_done 单周期脉冲
- rx_frame_err 帧错误检测
- 背靠背连续收发
- 全数据值 0x00~0xFF 遍历
- 毛刺过滤（窄脉冲不触发接收）
- 复位验证
⚙️ Syn Agent 执行记录
内部执行 🔧：
# 综合 ⚙️
make syn RTL_TOP=uart
# yosys syn.ys
# read_verilog ...
# hierarchy -check -top uart
# proc; flatten; opt; fsm; opt; memory; opt; techmap; opt
# write_verilog uart_netlist.v
# stat
Yosys stat 输出 📊：
=== uart ===
Number of wires: 251
Number of wire bits: 722
Number of cells: 618
$_AND_ 152
$_DFF_PN0_ 69 (FF with async rst)
$_DFF_PN1_ 7 (FF with async rst+set)
$_MUX_ 190
$_NOT_ 37
$_OR_ 98
$_XOR_ 65
WNS: +3.50 ns ← 时序满足 ✅
TNS: 0.00 ns
Failing endpoints: 0
Syn 返回（耗时 2.5 分钟 ⏱️）：
Synthesis PASSED ✅
- 618 cells, 76 Flip-Flops, 0 Latches
- WNS = +3.50 ns @ 100MHz (TIMING MET 🎯)
- Estimated area: ~1,267 GE (~152 um² @ 28nm)
- No errors, no unintended latches
📊 成果数据
| 类别 |
文件 |
行数 |
说明 |
| 📄 规格 |
design_spec.md |
332 |
功能规格、状态机、时序图 |
| 📄 规格 |
interface_spec.md |
175 |
端口定义、协议、复位行为 |
| 📄 规格 |
verification_plan.md |
242 |
23 个功能点、14 个测试用例 |
| 💻 RTL |
uart.v |
293 |
全双工 8N1 UART |
| 🧪 TB |
tb_uart.v |
837 |
20 个测试、自检 scoreboard |
| 📐 约束 |
uart.sdc |
20 |
100MHz 时钟、输入输出延迟 |
| ⚙️ 网表 |
uart_netlist.v |
- |
Yosys generic 网表 |
| 📊 报告 |
synthesis_report.md |
- |
618 cells, 76 FF, WNS +3.50ns |
| 📊 报告 |
timing.rpt |
- |
时序分析报告 |
| 📊 报告 |
area.rpt |
- |
面积分析报告 |
🤖 Agent 调用统计（UART 案例）
| Agent |
调用次数 |
平均耗时 |
产出 |
| 📄 soc-doc-engineer |
1 |
5.7 min |
4 份文档 (749 行) |
| 💻 soc-rtl-designer |
1 |
1.9 min |
RTL + SDC (313 行) |
| 🧪 soc-verification-engineer |
1 |
17.8 min |
TB + 仿真 (837 行, 85 PASS) |
| ⚙️ soc-synthesis-engineer |
1 |
2.5 min |
网表 + 报告 (618 cells) |
| 👑 主 Agent |
5+ |
- |
状态管理、协调、检查 |
整个运行过程 25.4 分钟，说效率提高 1000%，一点都不夸张 🚀
📦 安装体验
1️⃣ 第一步：下载
项目已开源到 GitHub 上，并附带 vibe_soc 参考项目环境。
2️⃣ 第二步：安装
把 GitHub 链接发给你的 Claude Code 🤖，让它给你下载安装，目前仅支持 Claude Code。
💡 小贴士：用 Claude Code + 国产 API（如 DeepSeek、Kimi Code），无需登录
silicon-agents 是基于 Claude Code marketplace，装载所有以「智能体协作」方式驱动 SoC / IC 前端工程的智能体集群 🚀
依赖工具 🛠️
verilator — lintiverilog + vvp — 仿真yosys — 综合python3 ≥ 3.9 — MCP server 与 quality check 脚本
全开源 EDA 工具，Linux 🐧、Windows 🪟、MacOS 🍎 都支持
3️⃣ 第三步：使用
下载的 vibe_soc 参考项目环境，在项目根目录里面启动 Claude，会自动加载所有的 agent 和 skill 🤖。
⚠️ 如果 Claude 打开有报错 plugin/skill/mcp 加载失败，优先让 Claude 自行解决 🔧
用户只用说：
“在 digital 目录下新建一个 xxx IP 目录，设计一个 xxx 模块”
欢迎大家使用，有什么问题和优化建议，可以在 GitHub 上给我提 issue。
🎯 人生苦短，快用 Agent
以前是，人生苦短，快用 Python 🐍
现在是，人生苦短，快用 Agent 🤖
写代码这事儿，生产力现在发展了三个阶段：
第一阶段：古法编程 传统手写代码，一个人对着电脑啪啪敲键盘
第二阶段：Vibe Coding 用自然语言描述意图，让 AI 生成、修改和调试代码，人只负责把控方向和审阅结果，不再逐行手写代码
第三阶段：Agentic Coding 人只设定目标和验收标准，多个 AI Agent 自主拆解任务、分工编码、测试迭代
到 Agentic Coding，每个工程师都能有几个芯片“AI 员工”。搞了 Agent 集群之后，token 消耗确实增加了，生产力极大提升。
发表于 2 小时前
|
查看: 3|
回复: 0
