开源 RISC-V 最难的一关，是让别人跑出和你一样的结果|fpga|linux|risc|寄存器|开源ris|计数器

10 月 15 日，伯克利那套 RISC-V SoC 框架发了个新版本。Chipyard 1.15.0，作者 jimfangx，tag 打在 157dd69 上。

发布说明里排最前面的七条功能项，前三条分别是：BOOM 有了性能监控，FireSim 支持了两块新 FPGA 卡，Linux AArch64 宿主支持。

单看都不算炸。合起来看，指向同一件事：这套框架在补「别人能不能用」的基础设施。跑多快是另一回事，那是论文阶段就该解决的问题。

先说个容易被忽略的细节。上一个版本 1.14.0 是 6 月 22 日发的，那版说明里有句话，大意是 Chipyard 回到了每 3 到 4 个月一次的常规发布节奏。这一版隔了 3.8 个月。按节拍发版这件事本身，就是工程化的标志——论文项目不对下游承诺节奏。

我们判断一套开源硬件框架的成熟度，习惯看三个东西：能不能观测，能不能复现，能不能换环境。1.15.0 恰好三条各补了一块。

19 个事件不值钱，那张清单才值钱

BOOM v3 这版注册了 19 个性能事件，覆盖退休、分发、分支重定向、cache 与 TLB 活动、周期、分发停顿。配套三档现成配置：Small、DualSmall、Medium，从命名看是单核、双核和中等规模三档。

19 这个数量放在商用核面前不值一提。商用核的事件表长得多，而且每一代还在加。

真要看的是它怎么描述自己。新加的 PMU 是一个独立子模块，里面四样东西：每个 tile 一份事件注册表，一份 event-list schema，也就是描述事件清单的格式；一组计数器；一个 TileLink 寄存器接口。外面还配了 bare-metal 的 C 头文件和一个 platform-header 生成器。

「每个 tile 一份」这几个字有分量。一个 SoC 里可能同时躺着乱序的 BOOM、顺序的 Rocket、带向量的 tile，它们能测的事件各不相同。把清单挂在 tile 上，异构配置才描述得清楚；挂在整个 SoC 上，一换配置就得重写。

这套东西解决的是 RISC-V 一个老问题。特权规范把 mcycle 和 minstret 定死了，mhpmcounter 能挂哪些事件，规范交给实现方自己定。厂商各写各的编码，perf 就不知道这块核到底能测什么。所以 RISC-V 平台上跑 perf，长期停在「cycles 和 instructions 能用，其余看运气」的状态。Linux 内核从 6.2 才认下第一个 RISC-V PMU，到 6.8 也只加到四家。这是 2024 年初的进度。

Chipyard 选的路子，是把「能测什么」变成机器可读的清单，再让工具去消费它。schema 是资产，19 个事件只是第一批数据。以后加事件，改清单；换工具，读清单。

还有个技术选择值得记一笔：计数器走内存映射，不走 CSR。从 S 模式读这些计数器，要么陷入到更高级别，要么靠 mcounteren 放开直读，做高频采样时开销都不好看；映射进地址空间之后，读计数器就是一次内存读。代价是每个 tile 要占一段地址，好处是采样开销下来了。发布说明里写的是可选，说明两种都能配。

把这条链跑一遍，才知道它补的是哪一环

抽象说「可观测」没什么感觉。把 Chipyard 里的几个部件串起来，这条链是这样的。

先由 FireMarshal 造一个可引导的镜像。这版把里面的 Linux 内核升到 6.16，Buildroot 和 BusyBox 跟着新工具链重配，OpenSBI 的 payload 和设备树位置也修了。产出的镜像能被 FireSim 加载。

FireSim 拿到 RTL，生成 bitstream，烧进 FPGA。上电之后 Linux 起来，跑负载。到这一步，团队能看到「跑完了，用了多少秒」。

问题从这一步开始。秒数只能回答「快不快」，回答不了「为什么快」。要知道 IPC、要知道有多少次分支重定向、要知道 L1 miss 掉在哪，就得读计数器。而计数器要读得对，得先有三件事：核里真有这些计数器，固件把访问路径打开，工具知道能读哪些事件。

这三件事，正好对应这版补的三个位置。BOOM 加了计数器和事件注册；per-tile 的清单和 platform-header 生成器把「能读什么」交给上层；内存映射让读取不必每次陷入。少一环，perf 那边就只能看到一个黑洞。

这条链还有个细节值得留意。这版的修复项里有两条跟仿真一致性有关：把 SoC 展开后得到的 device map、自定义 CSR、寄存器宽度、PMP CSR 数量传给 Spike 协同仿真，同时把 Debug Module 从模拟设备表里排除。testchipip 里还有一条，协同仿真出现分歧时会把机器状态和陷入原因打出来。

说的是同一件事：RTL 和参考模型必须对得上，对不上要能定位。做核的人都知道，跑分不可信，多半是两边算的根本不是同一个东西。

两块卡，两个世界

FireSim 这版加了两块 FPGA 平台的构建配方和预编译单核 Rocket bitstream：芯启源的 MimicTurbo GT，和 AMD 的 Alveo V80。

把这两块卡放一起看，很有意思。

MimicTurbo GT 基于 UltraScale+ VU19P，单卡最多 4800 万 ASIC 门，16 lane PCIe，64 个 GTY 收发器。芯启源是一家做 EDA 硬件验证的芯片公司，研发中心分布在南京、上海、硅谷等地。这张卡 2021 年底出样品，后来在 AMD-Xilinx 官网也上过。芯启源自己的公开资料说，开芯院在二代香山「南湖」的研发里用这张卡部署过双核硬件原型，把 OpenSBI 和 Linux 跑起来了。这是厂商口径，我们照引，边界留着。

Alveo V80 是另一个物种。Versal HBM 器件，260 万 LUT，32GB HBM2e，820 GB/s，190W，官方价 9,495 美元。

一边是插在桌边工作站里的国产原型验证卡，一边是带 HBM 的商用加速卡，用法和目标都不一样。FireSim 把两个都收了。

这件事的分量在哪？FireSim 过去很长一段时间，最现实的落地方式是在 AWS 上租 FPGA。云端省事，但设计要出机房。对做处理器核的团队，RTL 出不出门，很多时候不由技术决定。

本地卡支持一旦补齐，「能不能在自己机房里做 FPGA 加速仿真」这个问题就有了答案。补的还是国产卡，这一条对国内团队比多支持一块 Alveo 更实际。

顺带说一句，这版还加了 Genesys 2 和 ZCU104 的 FPGA 原型支持，FPGA Shells 里补了 Nexys Video。这几块都是几百到几千美元的教学与原型板，跟上面两块加速卡不在一个量级。两条线一起走，云端、实验室、机房三个场景才算都有东西。

把 x86 从流程里拿掉

第三条最短，只有一句话：初步支持 Linux AArch64 宿主，CIRCT 从源码构建，在 ARM Neoverse N1 上测过。

一句话，后面拖着整条工具链。这版把 riscv-tools 从 1.0.6 升到 1.0.10，工具链迁到 GCC 16，标量和向量的 Linux multilib 安装分开，宿主侧 GCC/G++ 的要求提到 GCC 15 系列。新增两套 linux-aarch64 的锁文件，一套完整版，一套精简版。

商业 EDA 的世界里，宿主机是道硬门槛。综合、P&R、硬件仿真，几十年长在 x86-64 Linux 上，ARM 宿主不能说完全不能跑，是没人给你保证。做芯片的人换台机器，先得确认工具链站不站得住。

开源这条线这次走到了前面。Chisel、FIRRTL、CIRCT、Verilator、FireSim 这一串，理论上都不绑指令集，实践中却长期默认 x86。现在 ARM 宿主能跑通，意味着一个全 ARM 机房的团队，不必为了跑开源流程单独备一批 x86 机器。

边界也得说清楚：初步支持，只测了 Neoverse N1，没覆盖全流程。

方向倒是明确的。同一版里还有两件事跟它同向：CI 重组后跑在 GitHub runners 上，以及每日 Docker 镜像构建。三个动作凑在一起，指向的词是「可复现」——换一台机器、换一个城市、换一个人，跑出来是同一个结果。

可复现这件事，做过的都知道难在哪。写 CI 脚本不难。难的是锁住那一堆看不见的变量：Conda 的 glibc sysroot、CIRCT 有没有预编译包、Vivado 是哪个版本、Spike 和 DUT 的寄存器宽度对不对得上。这版修的就是这些。

这类问题靠一个人、一个脚本兜不住。更实在的做法，是把工具版本、流程步骤和验证记录放进同一条可复核的链路，让每一次重跑都有据可查。

修 bug 比加功能更能说明问题

数一下条目分布：新增 7 条，变更 5 条，修复 9 条。

修 bug 的数量超过加功能，这在开源硬件项目里是个信号。

看修的是什么。Saturn 向量单元这版修了 vsmul 在 SEW=64 的饱和边界，起因是 Scala 整数溢出，导致裁剪错误和虚假的 vxsat；修了页拆分之后 store-segment buffer 的推进，不修会跳字段、会让 store 路径出现活锁；修了四条移位与旋转指令的无符号立即数处理；修了三条乘法指令的标量操作数截断。全是贴着规范抠边界。

这类活没人愿意干。可一个核能不能被信，恰恰由它决定。

另一堆是环境。宿主 glibc 版本在 Conda 上没有对应 sysroot 时，安装配置直接失败；Conda 解依赖失败会把已有 lockfile 弄坏；新版宿主 GCC 编不过 VCS 生成的 C 代码。

这些 bug 有个共同点：只有真的有人在各种机器上跑，才会暴露。论文阶段的代码不用考虑「我这台机器 glibc 是 2.39，但 Conda 只发到 2.38」。

三层判断，和一道许可证的坎

回到开头那三条：可观测、可复现、可移植。

这三层能直接拿去评别的开源硬件项目。看一个 RISC-V 核或者一套 SoC 框架能不能被外部团队用起来，问三个问题。

一，性能能不能说清楚。有没有事件清单，perf 认不认，能不能采样，还是只能计数。

二，环境能不能重建。工具链版本有没有锁，CI 在谁的机器上跑，有没有镜像，别人拿到一个 commit 能不能复现你的数字。

三，能不能换环境。换宿主架构行不行，换 FPGA 卡行不行，走云还是走本地行不行。

三问答完，一个项目是「能演示」还是「能被采用」，基本就分出来了。这套标准不依赖具体项目，看到下一个开源核发布，照样能用。

对国内做自研核的团队，第一问尤其扎人。核出来了，perf 一挂，能看到的只有 cycles 和 instructions，后面所有优化都成了盲调。有了事件清单，优化才有依据；跑分只是副产品。

最后说一处容易忽略的边界：SPEC CPU 2026。