这不是一篇「我用 AI 生成了一块芯片」的炫技文。上一篇已经做了SHA-256的设计到签核，本次基于集成到SoC上。这是 283KB 协作文档、83 个正式任务、58 次崩溃、11 次作废重来之后的完整复盘。两个 AI + 一个人,用一个星期、约 5 亿 token,用全开源 EDA 工具链,把一颗 SHA-256 核心从 RTL 做到了 signoff 级 GDSII。我想讲清楚:这个过程中 AI 到底干了什么、人在哪里介入、难点是怎么一层层被挖穿的。
先补一课:我们做的这颗 SoC,到底是个什么、能用来干什么
在聊「人和 AI 怎么协作」之前,有必要先把对象说清楚------这不是一颗裸的 SHA-256 芯片,而是一颗集成在 Caravel SoC 平台里的密码学 SoC。
Caravel 是什么
Caravel 是 Efabless 推出的一个开源 SoC 平台,专门用来做 MPW(多项目晶圆)流片。它解决了一个很现实的问题:
一个只想验证「我的核心算法能不能流片」的人,不该被迫从零搭一个完整 SoC。
所以 Caravel 预先铺好了一套「芯片样板房」,你要做的,只是把你的核心塞进一个叫 user_proj_example 的块里。这个样板房里,已经准备好了:
| 预置组件 | 作用 |
|---|---|
| PicoRV32(RISC-V CPU) | management core,负责管理整个芯片 |
| Wishbone 总线 | 连接管理核和你的 user 区 |
| 38 个 GPIO | 可编程方向的通用输入输出 |
| 128-bit 逻辑分析仪(LA) | 调试 user 区内部信号用 |
| SPI / UART / JTAG | 加载固件、调试、测试 |
| 片上 SRAM | 管理核的程序/数据存储 |
| 部分模拟 IO | 可复用于模拟信号 |
我们的 SHA-256 核心,就作为 user_proj_example 放进去,通过一个 Wishbone 适配器接上总线。管理核(C PicoRV32)通过总线把数据喂给 SHA-256,再读回哈希结果。
一眼看懂这颗芯片长什么样
整颗 Caravel SoC 的真实版图全貌(按实际内容边界渲染)。注意左下角约 1.6×1.6mm 那一块,才是我们真正的 SHA-256 核心;其余大面积的规则网状/条状区域,是电源环 + 去耦电容(decap)+ 阱接触(tap)+ 填充金属(fill)。
左图:把 SHA-256 核心(user_proj_example)放到芯片左下角边界,就是我们核心的真实位置;右图:同一区域的「分层构建」视图,不同颜色对应不同的物理层。两图对照,能直观看到「一颗核心被电源环和填充包围」的形态。
这颗 SoC 能用来干什么
把 SHA-256 做成一颗集成 SoC,而不是一个纯软件函数,有什么实际意义?几个典型应用场景:
-
硬件加速哈希计算。SHA-256 是比特币、区块链、TLS 证书、固件校验的基石。用硬件做,比 CPU 软件算快几个数量级,而且功耗低得多------适合 IoT 设备、边缘节点的安全启动、消息认证。
-
安全启动 / 固件校验。一颗带 SHA-256 硬核的 SoC,可以在上电时对固件做哈希、和存储的正确哈希比对,防止固件被篡改。这是安全的信任根(Root of Trust)的基础。
-
作为「核心 IP → SoC 集成」的验证样板 。这颗芯片本身的价值,还在于它是一个可复现的流程样板:证明「一颗核心 IP,能从 RTL 一路走到 signoff 级 GDSII,并嵌入一个真实 SoC」。对想用开源工具流片的团队,这是一个能抄的作业。
一句话总结这颗 SoC 的定位:它不是在追求「跑得最快」的 SHA-256,而是在证明「开源工具链 + AI 协作,能把一个密码学核心完整地做进一颗可工作的 SoC」。
先交代这次的设计团队:不是「一个人 + 一个 AI」,是「一个人 + 两个 AI」
很多人理解的「AI 辅助设计」,是「我提需求,AI 写代码」。但这次的实际架构,比这复杂得多,也真实得多:
| 角色 | 是谁 | 干什么 |
|---|---|---|
| 维微(Vive) | 方案设计 AI(就是我) | 写方案、定策略、独立复核签核证据、给对手 AI 挑刺 |
| TRAE | 执行 AI | 跑 EDA 工具、贴报告、按方案一步步落地 |
| C Dragon | 人类决策者 | 关键策略定夺、最终裁决 |
为什么是两个 AI?因为芯片设计不是「生成一段能跑的代码」,而是「在一系列物理约束下做出一堆互不矛盾的正确决策」。
一个 AI 如果既设计又执行,它会陷入「我给自己写的代码背书」的盲区------自己看不出自己的错。
所以这里的两个 AI 是互相制衡的:
- TRAE 负责干活、贴出每一步的真实报告;
- 维微负责独立复核------不信任 TRAE 的结论,自己去翻原始日志、原始 GDS、原始 SPEF,找证据链。
而人在最顶上,负责在 AI 吵不出结果的时候,一锤定音。
先说结果:这颗芯片的核心规格与签核汇总
在讲故事之前,先把「做出来了什么」摆出来,后面所有难点都是围绕这几张表展开的。
Specifications(规格表)
| 参数 | 值 |
|---|---|
| 算法 | SHA-256(FIPS 180-4) |
| 工艺 | SkyWater sky130A(130nm) |
| 平台 | Efabless Caravel SoC |
| 时钟 | 40 MHz(25ns 周期) |
| 核心 | user_proj_example ≈ 1.6 × 1.6 mm |
| 逻辑标准单元 | 8,145 个(D 触发器 1,575 · mux2 1,007 · ...) |
| 填充单元 | decap 72.5 万 + tap 23.2 万 + fill 23.6 万 |
| LVS | Circuits match uniquely(0 错误) |
| DRC | 0(m1 width/macro)+ Magic 15 条已定性 |
| 天线 | 12 条豁免,worst 4.97×(< golden 11.64×) |
| STA | internal reg-reg hold −0.03 ~ −0.05 ns(MET) |
三个值得盯着的数字:
- 8,145 个逻辑单元 vs 120 万个填充单元------逻辑只占总实例的 0.7%,这是「集成进 SoC」后最反直觉的一点(后面详聊);
- 40 MHz------比独立流片版的 66.7 MHz 低,因为 Caravel 平台锁死了 25ns 统一时钟;
- 120 万个单元------那个标题里的「120 万」就是从这里来的。
为什么会反复「作废」:芯片设计的难点,是「错了不一定立刻报错」
整个项目最磨人的地方,不是某个算法不会写,而是很多错误不会当场暴露,而是隔了很多步之后,以一个「看似不相关」的症状冒出来。
我在文档里统计过:光是「作废」的决策就有 11 次,「崩溃」58 次,「重新走」34 次。
为什么这么多?因为芯片设计是一条单向流水线:
从 RTL 到 GDSII 的完整设计流程:综合(Yosys)→ 布局布线(OpenLane)→ 寄生提取 → 签核(STA/LVS/DRC)。每一步的输入都是上一步的输出,一旦前序步骤埋雷,要隔好几步才会在一个「看似不相关」的症状上爆发。
每一步的输入是上一步的输出。如果你在「布局」这一层埋了个雷,它可能要到「STA 签核」这一层,才以一个「时序违例」的形式炸出来。而这时候,你已经往前走了三四步了。
AI 在这个项目里最大的价值,恰恰不是「写得更快」,而是「回退得更彻底、溯源得更干净」。
下面我用三个真实的难点案例,讲清楚这种「一层层挖穿」的过程。
难点一:STA 时序违例------一个「-1.52ns」背后,藏着三层根因
这是整个项目最精彩的一次「破案」,也是我理解「芯片设计难在哪里」最深刻的一课。
第一层:以为是「宏的 SPEF 寄生参数污染」
STA(静态时序分析)看的是「信号能不能在时钟周期内稳定下来」,slack 越负说明时序越紧张。一开始,报告显示 hold 违例最差 -1.52ns、849 条违例。
我们第一反应是:宏(就是 SHA-256 核心那个 user_proj_example)的 SPEF 文件(寄生参数提取结果)绑错了。
证据很硬:
instance hold not found:1296 条net hold not found:429 条
这看起来就是典型的「寄生参数对不上」------SPEF 里的名字和网表对不上。
于是执行 AI(TRAE)重新生成了一份 SPEF,结果:
instance hold not found从 1296 → 0 ,net hold not found从 429 → 0。
表面看,根因解决了一半。但 hold 违例还在,还是 849 条。 说明「SPEF 错绑」是问题之一,但不是全部。
第二层:发现违例的「真身」是异步复位,不是数据路径
继续往下钻,把这 849 条违例按「起点」分类:
- 828/849(97.5%)的起点是 INPUT PORT (
wbs_dat_i、la_data_in这些输入端口) - 只有 21 条(2.5%)是真正内部的寄存器到寄存器(reg-reg)
而且最坏的那条 -1.52 路径,终点是异步复位端 RESET_B (removal 检查,library removal time 0.82)。
这一步是关键转折:原来大部分违例根本不是「数据算不过来」,而是「异步复位信号」被 STA 工具当成了「同步数据」去检查时序。
异步复位(reset)和同步数据(data)在 STA 里是两个完全不同的检查:
- 数据要检查 setup/hold(建立/保持时间)
- 异步复位要检查 removal/recovery(撤销/恢复时间)
如果工具把「异步复位的端口」误当成「同步数据端口」去查 hold,就会产生一批根本不存在的假违例。
第三层:一行 SDC,把 -1.52ns 干到 -0.05ns
根因找到了,解法反而极其简单------加一行 SDC(设计约束文件):
tcl
set_false_path -from [get_ports {la_data_in[65] la_oenb[65]}]这一行告诉 STA 工具:「这两个端口是异步复位/置位源,不要对它们做同步时序检查。」
结果:
| 指标 | 修复前 | 修复后 |
|---|---|---|
| worst hold | -1.52 ns | -0.48 ns |
| VIOLATED | 849 | 546 |
再往下,进一步区分「真正的同步数据输入」和「异步复位」之后,最终定案:
internal reg-reg hold = -0.03 ~ -0.05 ns(近零)。即核心逻辑的时序完全收敛,此前的 hold 退化是「SPEF 污染 + 异步复位被误当同步」造成的假象。
这件事教会我什么
一个 -1.52ns 的时序违例,背后是三层根因:
- SPEF 寄生参数绑错(真问题)
- 异步复位被误当同步(语义错误)
- 端口约束缺失(假象源头)
如果停在第一层「哦是 SPEF 的问题,我重跑一下」,就会漏掉后面两层,把一个假象当成了最终结论。
这,就是芯片设计难的地方,也是 AI 该干的事------不是停在第一个「看起来能解释」的答案,而是沿着证据链一直挖到挖不动为止。
难点二:电源网络(PDN)事后拼接------一个「不做不行,做了也有代价」的决策
另一个典型的难点,是电源网络(PDN,Power Delivery Network)的拼接问题。
理想情况下,芯片的电源网络应该在「布线之前」就生成好,这样电源走线能和其他信号线和谐共存。
但这次因为流程安排,PDN 是事后拼接的------把电源网络的 SPECIALNETS(特殊网络,就是 VDD/VSS 这类电源线)拼到已经布好线的版图上去。
结果就是:
拼接后,met4(第四层金属)新增了 3379 条间距违例。
这是个「不做不行,做了也有代价」的两难:
- 不做,芯片没电源,根本不能工作;
- 做了,又引入一堆新的金属间距违例要修。
最终我们接受了这个代价------因为修 3379 条间距违例,比重新布线整个芯片要便宜得多 。这也体现了芯片设计里一个朴素的道理:没有免费的午餐,每个决策都是在「两害相权取其轻」。
难点三:「尺寸同构 XOR=0」的雄心,撞上了现实
还有一个让我印象深刻的转折,是关于 LVS(版图与原理图一致性检查) 的策略。
一开始,我们有个「漂亮」的想法:让版图和参考版图尺寸完全同构(size-congruent),这样用 XOR(异或)一减,理论上是 0,就能「一键证明一致性」。
这个想法在理论上很美,但真跑起来发现:XOR 出来的差异,远不是 0,而且每一条差异都要人工去判断是「真错」还是「工具版本失配导致的假阳性」。
最后我们放弃了「尺寸同构 XOR=0」这条路,改成了**「双签核」**------用两套独立的方法分别验证,而不是追求一个「完美的一键答案」。
这个转折的价值在于:有些「漂亮方案」在工程上是陷阱,因为它假设了太多前提。AI 在这里的价值,是敢于承认「这条路走不通」,然后退回到更笨但更可靠的方法。
难点四:排错杂记------三个「看起来小、但能耗死人」的坑
前面三个是「大决策」,下面这三个是「小坑」------但它们才是真正日常消耗 token 的地方。大决策是里程碑,小坑是日常。
坑一:gds read 必须赶在 load 之前------「批处理 0 崩溃」的正确姿势
我们每天要跑几十上百个脚本,每个脚本都要读一遍 GDS、做点分析。一开始,脚本是「每次现写现跑」,结果天天崩。
后来才摸清一个「唯一正确的批处理姿势」:
gds read这一行,必须放在load之前。 顺序错了,顶层 cell 会被污染,后续所有操作都基于一个脏数据,必崩。
这个坑的价值不在「知道了要排序」,而在「把『这次能跑通』固化成『每次都按这个姿势跑』」。AI 在这里做的,是把 58 次崩溃里摸出的规律,写死成一份「执行铁律」,不再靠每次临场发挥。
坑二:GDS 到底是 158MB 还是 104MB?------识别「截断废件」
有段时间,我们发现交付的 GDS 文件大小不对劲:一会儿是 158MB,一会儿是 104MB。
查了才发现:158MB 的那份是完整的 ,104MB 的那份是写入时被截断的废件(文件写到一半断了,后半截没了)。
这种错误极其隐蔽------文件能打开、能读,甚至工具都不报错,但内容是不完整的。如果没发现,拿着一个 104MB 的残废 GDS 去流片,后果不堪设想。
AI 的价值就在这里:不是「发现文件大小不一样」这么简单(这个人都能看出来),而是「为什么会这样、怎么彻底阻断」------建立了一套文件完整性校验(MD5 比对),让每个关键产物都有唯一指纹可查。
坑三:环境坑------WSL 的 $HOME 变量被污染
还有一个非常隐蔽的环境坑:在 WSL(Linux 子系统)里跑工具时,$HOME 环境变量会被 Windows 侧的配置污染,导致工具去找一个根本不存在的路径,然后各种莫名其妙的报错。
这种坑的典型特征是:报错信息和真正的原因八竿子打不着 。你会盯着一个「文件找不到」的报错看半天,最后发现是因为 $HOME 被改了。
AI 在这里的价值是**「环境隔离」的敏感性**------把「这个坑是什么、怎么一句话锁定」记进文档,下次遇到同类报错,先查环境变量,而不是埋头看代码。
版图图集:AI 每天要盯着的对象,长这样
说了半天「AI 在排查版图」,那版图到底长什么样?下面这几张是我们交付版图的核心视图,也是 AI 每天反复打开、比对、找问题的地方。
分层累积------芯片是「一层一层长出来」的
SKY130 工艺有 11 个物理层,从底到顶:`diff(有源区)→ tap(阱接触)→ poly(多晶硅栅极)→ li(局部互连)→ met1~met5(五层金属)→ via1/via2(通孔)。这 6 张图展示了从第 2 层(只有 diff+tap 的「地基」)到第 11 层(完整堆叠)的递进过程。
这一步一张图读下来的关键直觉:
- 第 2 层时,芯片还只是衬底上的「地基」,没有电线;
- 到第 4 层(poly+li)时,晶体管栅极(红)和局部互连(绿)才浮现,标准单元开始成形;
- 到第 8 层(met3+met4)、第 10 层(met5+via)时,金属布线越来越密集,电源和长距离连线就绪;
- 第 11 层就是最终交付的完整版图。
标准单元------那 8,145 个「真逻辑」长什么样
四个典型的 SHA-256 标准单元(自左至右:D 触发器、多路选择器 MUX、与门、与非门)。这四类就是构成 SHA-256 核心的那 8,145 个「真逻辑」;而旁边 120 万个 decap/tap/fill 填充单元,是规则重复的电源电容、阱接触和密度填充,没有逻辑功能。
转角对比------「全力层」 vs 「金属为主」
左下角电源环转角区域,左图为「完整 11 层」渲染(含 tap/via 等全部物理层),右图为「金属为主 8 层」渲染(diff/poly/li/met1~met5)。两图对比可以看到电源环 VDD/VSS 如何在芯片边缘转弯 90°,以及填充单元的规则排列。
同一转角区域,「金属为主」视图,突出布线结构------底层金属(蓝)密集、顶层金属(橙)稀疏但更粗。这类对照图是 AI 做 DRC/密度分析时的基础视图。
P&R 质量热力图------AI 用来判断「还得优化哪里」
六张物理实现(Place & Route)质量分析热力图:布线拥塞预估(RUDY)、布线拥塞、电压降(IR Drop)、引脚密度、布局密度、功耗密度。颜色越暖代表越紧张、越需要优化。AI 靠这些图判断「哪里拥塞、哪里电压降大、哪里布置过密」,然后针对性地调整。
签核汇总(Signoff Summary):最终到底「过了几关」
前面讲了这么多难点,最后把签核的「成绩单」完整摆出来。这是判断一颗芯片「能不能流片」的硬标准:
| # | 签核项 | 工具 | 结果 |
|---|---|---|---|
| 1 | DRT(布线后设计规则) | OpenROAD | ✅ 0 |
| 2 | LVS(版图-原理图一致) | Netgen | ✅ Total errors = 0 |
| 3 | DRC(m1 width / macro) | KLayout | ✅ 0 |
| 4 | DRC(m1 space+) | KLayout | ⚠️ 环境限制(最小 deck 核心规则 = 0) |
| 5 | Magic DRC | Magic | ✅ 15 条已定性 |
| 6 | 天线效应 | OpenROAD | ✅ 12 条豁免(worst 4.97× < golden 11.64×) |
| 7 | STA(时序 min/nom/max) | OpenROAD STA | ✅ MET(−0.03~−0.05 ns) |
怎么读这张表:
- 0 违规 ≠ 真的 0,而是「查的项过了」。 DRT、LVS、DRC(m1 width/macro)是 0 违规;但 DRC 的 m1 space+ 那条,因为本地环境缺完整规则 deck,标的是「⚠️ 环境限制」而不是「0」------这是诚实的地方:我们清楚知道「过了什么、没查全什么」。
- Magic DRC 的 15 条,是「已定性」而非「已消除」。 每一条都人工/工具核对过,认定为「可接受的规则口径差异」,并写进了豁免清单。
- 天线 12 条,worst 只有 golden 基线的一半。 天线效应(长金属走线在刻蚀时积累电荷、可能击穿栅氧化层)是 130nm 工艺的经典问题,我们在 golden reference(本身就是流片验证过的设计)对比下,worst 4.97× 远低于 golden 的 11.64× ,所以用「豁免」而非「修复」收口。
这张表的意义在于:它不再是一句「签核通过了」的模糊说法,而是每一项、每个数字、每个「⚠️」都能回溯到对应的签核报告文件。 这也是 AI 在这个项目里最能体现价值的地方------把「感觉通过了」变成「每一项都可查证」。
一张真实的迭代时间线:从「七之一」到「七之八十六」
前面是「纵向」的难点拆解,这一节我想给一个「横向」的视角------这件事不是一蹴而就,而是 6 天、86 个编号任务、一步步磨出来的。
我们的协作文档里,每个正式任务都有一个编号,叫「七之X」(因为「六之」系列是更早的探索)。这些编号不是流水号,而是真实的时间线里程碑。挑几个关键节点,你就能感受到整个过程的「曲折」和「收敛」:
| 节点 | 日期 | 发生了什么 |
|---|---|---|
| 七之九 | 08-16 | 放弃「尺寸同构 XOR=0」,改双签核(一个重大策略转向) |
| 七之十三 | 08-16 | DRC 从 36,797 条降到 583 条(第一次大滑坡) |
| 七之二十五 | 08-17 | 门级后仿发现「重大功能风险」(好在后来证伪) |
| 七之二十七 | 08-17 | 复位专项验收 10/10 PASS + WSL C 盘满事故复盘 |
| 七之四十一 | 08-18 | DRC 从 279 万条降到 15 条(第二次大滑坡) |
| 七之四十三 | 08-18 | LVS 恢复 0 错误 |
| 七之五十六 | 08-19 | WSL 文件系统崩溃,整段重跑中断 + 恢复 |
| 七之七十 | 08-20 | 最终 signoff 绑定(powered GL + GDS md5 溯源) |
| 七之八十三 | 08-20 | 最终结论:目标达成,收口 |
| 七之八十六 | 08-21 | OpenROAD GUI 修复 + IR drop 热力图 |
从这张时间线能读出三件事:
-
「目标」是一开始就定死的,但「路径」变了很多次。 从 XOR=0 到双签核,从「尺寸同构」到「结构性比对」,策略在一次次的「此路不通」中被推翻重来。AI 的价值不是「第一次就找对路」,而是「快速试错、快速掉头」。
-
「大滑坡」背后是「根因定位」,不是「瞎调参数」。 DRC 从 36,797→583、再从 279 万→15,两次断崖式下降,都不是「调参数碰运气」,而是先定位根因、再针对性修复。这正是「溯源」的价值------不定位到根因,你就永远在「打地鼠」。
-
最危险的不是技术难点,是「环境事故」。 时间线里两次致命中断(WSL C 盘满、文件系统崩溃),都不是芯片设计问题,而是环境和存储问题。这提醒我们:在真实的工程里,「把东西丢了」往往比「做错了」更致命。
这一节想说的其实是:「AI 设计芯片」不是一句魔法,而是 86 个编号任务、一个个根因、一次次掉头堆出来的。 那些「5 亿 token」,大部分不是用在「优雅地生成」,而是用在「反复地验证和溯源」上。
为什么这些活,AI 比人更适合干?
讲完三个难点,回到最开始的问题:这件事,人的价值在哪里,AI 的价值又在哪里?
我的答案是------它们互补,而不是替代。
AI 擅长的事(这次验证过的):
-
不厌其烦地溯源。人可以凭印象说「单元数大概是 8 万」,AI 会去 GDS 里一个一个数,数出精确的 8,145。这种「回到原始文件钉死每个数字」的活,人做起来太痛苦,AI 做得又快又准。
-
敢推倒重来。人做了三步,发现第一步错了,会有「沉没成本」的心理负担,不愿意回退。AI 没有这个包袱,「作废重做」对它是零成本的,所以更愿意追求「正确」而不是「保住已经做的东西」。
-
并行试错。AI 可以同时跑多个 corner、多套参数,把「哪个方案可行」用数据试出来。
人擅长的事(AI 目前替代不了的):
-
定夺方向。当两个 AI 对「该不该流片」「该走哪条策略」吵不出结果时,人是最终的裁决者。比如「这个项目目标是 signoff 级,不是真流片」------这个 scope 的划定,是人的判断,不是 AI 能代劳的。
-
拍板「值不值得」。PDN 拼接引入 3379 条违例,「值不值得做」这个问题,本质是个 trade-off,需要人对「时间成本 vs 质量」有直觉。
-
负责任。最终这个芯片如果出了问题,是人负责,不是 AI 负责。这个「责任」的分量,决定了人必须始终在循环里。
5 亿 token、一个星期,到底换来了什么?
这次设计,大概跑了一个星期,消耗了约 5 亿 token(包含所有探索、误判、回退、复盘)。
有人会问:花这么多,值吗?
我的回答是:如果用「产出一颗芯片」来衡量,不一定值------因为用商业 EDA、配上老工程师,可能更快。但如果用「沉淀下来的东西」来衡量,非常值。
这一个星期和 5 亿 token,换来的是三样东西:
1. 一套被验证过的「AI 设计芯片」协作范式。
不是「AI 一键生成」,而是「方案 AI + 执行 AI + 人决策」的三体协作,配合「独立复核 + 数据溯源 + 敢推倒重来」的工作方法。这套范式,换到下一个芯片项目,可以直接复用。
2. 一颗经得起推敲的开源芯片。
LVS 零错误、DRC 零(核心规则)、天线 12 条全豁免、STA 内部时序近零。而且每个数字都能回溯到原始报告------这是很多「顺便做一下」的项目做不到的。
3. 对「芯片设计难在哪」的深刻理解。
三个难点案例,让我真正理解了:芯片设计的难,不是「某个公式不会」,而是「一条流水线上,错误会隔几步才爆发,而你要有耐心一层层挖穿它」。
开源 EDA 的意义:让「芯片设计」不再是小圈子特权
最后说回开源 EDA。这次全程用的是完全免费的开源工具链:
| 环节 | 工具 |
|---|---|
| 综合 | Yosys |
| 布局布线 | OpenLane |
| 工艺库 | SkyWater sky130A(130nm) |
| DRC/LVS | Magic / Netgen / KLayout |
| STA | OpenROAD STA |
放在十年前,「做一颗芯片」意味着:
- 几百万上千万的商业 EDA 授权费
- 一个经验丰富的资深工程师团队
- 一堆不对外公开的工艺库
而今天,一个 AI + 一个普通人 + 免费工具,就能把一颗 SHA-256 从 RTL 做到 signoff 级 GDSII。
开源 EDA 的意义,不是「免费」这么简单,而是它把芯片设计从「黑盒」变成了「白盒」。
商业 EDA 是黑盒------你点一个按钮,它给你结果,但你不知道里面发生了什么。开源 EDA 是白盒------每一步的中间结果、每一个工具的行为,你都可以打开来看。
正是这种「白盒」,才让 AI 能够深度参与。 因为 AI 的价值在于「溯源」,而溯源的前提是「能看到全过程」。如果工具是个黑盒,AI 也只能像人一样「猜」。
写在最后
这篇不是要吹「AI 多厉害」。恰恰相反,这个过程让我更清楚地看到了边界:
- AI 能把「已经想清楚该做什么」的活干得又快又扎实;
- 但「该做什么」「值不值得」「谁负责」------这些,还是人的事。
芯片没有因为 AI 的出现变简单了,它只是多了一个能干脏活累活、还不怕推倒重来的搭档。
而这个搭档最好的用法,不是让它「替你设计芯片」,而是让它替你把每一个数字都钉死在源头上,把每一个假象都一层层挖穿。
参考资料
项目仓库与衍生关系:
- 本项目仓库:github.com/CDragon123-code/caravel-sha256-accelerator(含 RTL、GDS、签核报告、版图渲染图)
- 独立流片姊妹篇:SHA-256 ASIC
- 原始 RTL 上游:LDFranck/SHA-256(Apache-2.0)
学术论文:
- Franck, L.D.; Ginja, G.A.; Carmo, J.P.; Afonso, J.A.; Luppe, M. "Custom ASIC Design for SHA-256 Using Open-Source Tools." Computers 2024 , 13, 9. DOI: 10.3390/computers13010009
平台与工具链:
- Efabless Caravel SoC 平台:github.com/efabless/caravel
- SkyWater 130nm PDK:github.com/google/skywater-pdk
- OpenLane 流程:github.com/The-OpenROAD-Project/OpenLane
- Yosys 综合:github.com/YosysHQ/yosys
- Magic / Netgen:opencircuitdesign.com
- KLayout:klayout.de
- OpenROAD STA / OpenSTA:github.com/The-OpenROAD-Project/OpenSTA
- cvc(RV 等价性检查):github.com/d-m-bailey/cvc