CoralNPU 源码级全景：窄前端、宽后端

CoralNPU 不是一颗芯片，而是一组以开放源码 IP 形式发布、可被集成进端侧 SoC 的 RISC-V 加速器核心。它面向的是始终在线的边缘 ML、DSP 和嵌入式控制负载，而不是云端训练 ☁️。

Overview 把它概括为“4-lane 超标量、模块化”，但真正定义它性格的，是下面这句话里的四个分区：

• • 指令取指与派发 🧭
• • 标量执行 ⚙️
• • 解耦的向量/矩阵加速后端 🚀
• • banked 内存子系统 🏦

这四个区域物理上彼此独立，而它们之间的同步方式——而不是某个执行单元的峰值数字——才是 CoralNPU 区别于通用 RISC-V 处理器的地方 🔑。

📚 目录

一、三个变体：同一套前端，逐级叠加后端
二、4-lane 前端：宽度有限，确定性优先
三、标量执行：够用就好
四、解耦向量后端：CQ、UQ、ROB 与乱序执行
五、VME：矩阵 tile、配置指令与 PE 阵列
六、LSU 与 banked 内存：统一出口，并发访问
七、同步模型：配置在标量核，完成靠轮询
八、边界与适用场景
九、结语：窄锚点，宽后端
十、License

图 1：CoralNPU 总体架构与三个变体的能力叠加关系。

解读：

• • 三个变体从 CoreMini 到 RvvCoreMini 再到 VmeCoreMini，前端完全共享，只叠加后端能力 🧱。
• • 标量前端是唯一同时连接 ALU、BRU、MLU、DVU、FPU、LSU、向量后端和矩阵引擎的派发中心 🎯。
• • 向量指令走“入队”路径进入 RVV 后端的 Command Queue，矩阵则走“CSR / 指令配置”路径 🛣️。
• • LSU 是标量、浮点、向量、矩阵/tile 内存操作的统一出口，因此内存派发口成为共享稀缺资源 🚦。
• • banked TCM 与外部 AXI4/TL-UL 总线挂在 LSU 之后，向量和矩阵的 load/store 都要经过这里 🏦。

🎛️ 一、三个变体：同一套前端，逐级叠加后端

CoralNPU 提供三个生产配置，它们共享完全相同的前端和同步模型，差异只在于后端能力 🧰。

CoreMini 是标量加浮点基线 🧮：

• • ISA 为 RV32IMF_Zba_Zbb_Zicsr_Zifencei_Zfbfmin。
• • 执行资源包括 4 个 ALU、4 个 BRU、1 个 MLU（2 周期流水，每周期 1 条）、1 个 DVU（多周期阻塞）、1 个 FloatCore、1 个 LSU。
• • 定位是控制面、标量数学、轻量 DSP、FP32/BF16 例程。
• • 它没有向量，也没有矩阵，LSU 只服务标量和浮点访问。

RvvCoreMini 在 CoreMini 之上加 RVV 1.0 🚀：

• • 向量参数为 VLEN=128，32 个向量寄存器（v0..v31），SEW 8/16/32，LMUL 1/8 到 8。
• • 解耦后端路径是 8 项 Command Queue、2 级向量解码器、16 项 Uop Queue、专用保留站、多 lane 向量功能单元。
• • 执行单元包括 2 个 VALU、2 个 VMUL/MAC、1 个 VDIV、2 个 VFALU、1 个 VFDIV、1 个 Permutation/Reduction。
• • 向量 ROB 有 16 项，保证精确异常、顺序退休、异步写回标量/浮点寄存器文件。
• • LSU 扩展支持 unit-stride、strided、ordered/unordered indexed、mask、fault-only-first 向量访问。
• • 它适合 SIMD DSP、计算机视觉、向量数学和音频处理 👁️🎵。

VmeCoreMini 在 RvvCoreMini 之上加实验性 VME / Zvt 🧊：

• • 矩阵状态是 16 个矩阵 tile 寄存器mt0..mt15，映射到 4 个 sub-tile block，每个 subtile 16 字节。
• • 矩阵配置使用专用 CSR 和指令 mtype、msetmtype、msetmtypei、msettn、msettm、msettk，配置 M/N/K 维度和数据类型 ⚙️。
• • 计算单元是并行 PE 阵列，执行外积和 GEMM，支持 INT8、FP32、BF16。
• • 辅助硬件包括矩阵累加器 zvt_acc 和硬件转置单元 zvt_mt。
• • mload/mstore 直接与 LSU 耦合，支持 2D 矩阵 tile 在 DTCM 与矩阵寄存器之间流式搬运 🔄。
• • VME 被明确标注为实验性、可选，指令编码、CSR 地址和 PE 阵列细节可能随版本变化 ⚠️。

三个变体的关键共同点只有一句：前端完全一致，同步模型完全一致。 向量和矩阵是“能力叠加”，标量核始终是那个取指、派发、配置、轮询的控制锚点 ⚓。

🧠 二、4-lane 前端：宽度有限，确定性优先

Overview 称前端为“4-lane superscalar”，流水线是 Fetch → Decode → Dispatch → Retirement Buffer 🔁。取指是 128-bit 无缓存，带 FetchReorderBuffer 和 InstructionBuffer；解码是 4 个并行解码器；退休是顺序的。

但 “4-lane”不等于“任意四条指令都能一起走” 🚦。

结构冒险把宽度压窄了：

4-lane 的实际含义是：ALU/BRU 可以填满四个槽，但乘法、除法、浮点、内存、向量命令都会因为单实例或有限队列而反压 🧱。

特殊指令独占槽 0 🔒：

• • CSR 指令（csrrw/csrrs/csrrc）和 fence/fence.i/wfi 这类影响核心状态的指令，通常被限制在派发槽 0。
• • 它们同时独占派发周期，不允许同周期派发其他指令。
• • 这不是性能优化，而是矩阵配置和状态轮询能够成为同步原语的基础。
• • CSR 写是一个控制流节点，不是可以随意混排的普通指令 🧭。
• • msetmtype、msettn、msettm、msettk 以及矩阵启动/状态查询，都依赖这种独占性来保证配置的原子性 ⚛️。

图 2：4-lane 派发槽与约束，槽 0 是特殊指令的唯一入口。

解读：

• • 四个派发槽并非等价，槽 0 是 CSR、fence、wfi、mret 等特殊指令的唯一入口 🔒。
• • 特殊指令在执行周期内阻止其他指令派发，构成控制流中的独占节点 ⚛️。
• • 顺序派发规则意味着 n 被阻塞时 n+4 也不会被考虑，控制流保持可预测 🧭。
• • Scoreboard 负责 RAW/WAW，结构冒险则来自 MLU、LSU 等单实例单元 🧱。
• • 矩阵配置 CSR 只能从槽 0 发出，因此它天然是一个原子配置点 🎯。

⚙️ 三、标量执行：够用就好

标量核没有被设计成高性能通用核。它的目标是足够快地执行控制流、地址计算、循环计数和状态轮询 🎯。

几个单实例约束值得记住：

• • MLU：四个 lane 都可以发乘法请求，但 MLU 只接受第一个有效请求，每周期最多一条，延迟 2 周期。
• • DVU：多周期阻塞，忙时反压派发 ⏳。
• • FPU：流水化，但每周期一条。
• • LSU：每周期一条内存指令 🚦。

这些约束会直接体现在逐 tile 控制代码里：乘法、地址计算、状态读取会竞争有限的执行资源。编译器能改成加法或移位的乘法，就应该避开 MLU ✂️。

标量浮点部分包含 FloatCore，支持 FP32 的 fadd、fsub、fmul、fmadd、fdiv、fsqrt、比较和转换，以及 Bfloat16 转换 fcvt.bf16.s / fcvt.s.bf16 🌊。这意味着三个变体都具备标量浮点能力，而不只是向量/矩阵变体。

一句话总结：标量核的性能目标不是“快”，而是“确定”。 它要足够快地驱动后端，同时让每条影响核心状态的指令都在确定的位置和顺序上执行 🧭。

🚀 四、解耦向量后端：CQ、UQ、ROB 与乱序执行

RVV 后端的流水线可以拆成四段：

1. 1. Command Queue（8 项） ：标量核把向量命令放入 CQ 后即可继续执行后续标量指令，不必逐条等待 🎯。
2. 2. 2 级向量解码器（DE1/DE2） ：把向量指令展开成微操作。
3. 3. Uop Queue（16 项） ：微操作在这里等待分发。
4. 4. 保留站加执行单元：按 RAW/WAW 重命名后，微操作进入专用保留站，再驱动 VALU、VMUL/MAC、VDIV、VFALU/VFDIV、Permutation/Reduction 单元。

结果写回 32×128-bit 向量寄存器文件，16 项向量 ROB 保证精确异常和顺序退休，并支持异步写回标量和浮点寄存器文件 🧮。

这里的关键对比是：前端窄而顺序，后端宽而乱序。 解耦让标量核不必等待向量完成，但 ROB 的退休仍然是顺序的，异常仍然是精确的 ⚖️。

图 3：RVV 向量后端从 Command Queue 到 ROB 的解耦流水线。

解读：

• • 标量核只负责把向量命令放入 8 项 Command Queue，后续由向量后端独立消化 🎯。
• • 2 级解码器把向量指令展开成微操作，进入 16 项 Uop Queue。
• • 微操作按 RAW/WAW 重命名后分发到多个专用保留站，实现乱序调度 🔀。
• • 执行单元包括 VALU、VMUL/MAC、VDIV、VFALU/VFDIV 和 Perm/Red，覆盖整数、浮点和排列归约 🧮。
• • 结果写回 32×128-bit 向量寄存器文件，再由 16 项 ROB 保证顺序退休和精确异常 🛡️。
• • ROB 支持异步写回标量/浮点寄存器文件，但退休顺序不因此改变 ⚖️。

🧊 五、VME：矩阵 tile、配置指令与 PE 阵列

VME 的编程模型比“纯 CSR 配置”更结构化 🧱：

• • 用 mset* 指令和矩阵 CSR 配置 M/N/K 和数据类型 ⚙️。
• • 用 mload/mstore 在 DTCM 与 mt0..mt15 之间搬 tile 🔄。
• • 用 PE 阵列执行 INT8/FP32/BF16 的外积和 GEMM 💪。
• • zvt_acc 负责累加，zvt_mt 负责硬件转置 🔁。

它仍然依赖标量核编排循环和配置，启动后的执行是异步的。Overview 没有承诺硬件自动跟踪“矩阵完成到向量读取”的依赖，因此同步仍然需要软件显式确认 🔍。

注意：VME 是实验性、可选实现。 它的指令编码、CSR 地址和 PE 阵列细节可能随版本变化；生产使用需要确认具体构建和编译栈支持 ⚠️。

🏦 六、LSU 与 banked 内存：统一出口，并发访问

LSU 的定位是标量、浮点、向量、矩阵/tile 内存操作的统一出口 🚪。向量 load/store 经过 LSU，mload/mstore 也经过 LSU，标量和浮点更不用说。

代价是：每周期只有一条内存指令能派发 🚦。编译器必须尽量合并访问、使用连续或 unit-stride 模式 📦。

内存侧是 banked TCM 🏦：

• • ITCM 和 DTCM 都是 4 个 32-bit bank。
• • 默认配置 8 KB ITCM / 32 KB DTCM，Highmem 可到 1 MB / 1 MB。
• • DTCM 带本地交叉开关，支持标量 LSU、向量内存单元、矩阵引擎和外部 DMA/host 端口的并发访问而不产生 bank 冲突 🔀。

这是向量和矩阵能够同时从 DTCM 取数的物理基础 🧱。

图 4：banked TCM 与交叉开关，标量、向量、矩阵和 host/DMA 共享内存目标。

解读：

• • 128-bit IBus 负责无缓存取指，128-bit DBus 承载标量、向量、矩阵的 LSU 访问 🚪。
• • Host/DMA 通过 AXI4 或 TL-UL slave 端口访问 ITCM、DTCM 和 CSR 🌐。
• • 本地交叉开关负责优先级仲裁，把不同发起者的请求路由到对应目标 🚦。
• • ITCM 和 DTCM 都是 4 个 32-bit bank，DTCM 带本地交叉开关，支持并发访问 🔀。
• • 外部 AXI4/TL-UL master 用于 DDR 和系统总线，取指在 PC 超出 ITCM 时也会回退到这里 🗺️。

🔐 七、同步模型：配置在标量核，完成靠轮询

CoralNPU 的同步可以概括为三条 📜。

第一，启动方式不同，但都由标量核发起 🚀：

• • 向量：指令入队 CQ，后端异步消费。
• • 矩阵：mset* 指令/CSR 配置加启动，PE 阵列异步执行。
• • 两种后端都不需要标量核逐周期托管，但启动动作都来自标量核的指令流 🎯。

第二，完成状态靠软件轮询，不靠硬件自动跟踪 🔄：

• • Scoreboard 跟踪的是寄存器层面的 RAW/WAW。
• • 它不跟踪“矩阵 PE 阵列何时完成”这种跨引擎状态。
• • 向量 ROB 保证向量退休顺序，但不保证“矩阵结果何时可被向量读取”。
• • 因此逐 tile 的正确序列是：配置矩阵 → 启动 → 轮询矩阵状态/完成位 → 发射向量 load 🎯。

第三，普通 FENCE 不承担数据同步职责 🚧：

• • CoralNPU 在硬件上保证总内存序。
• • 普通 FENCE 在派发时被识别为 NOP，立即退休。
• • FENCE.I 用于取指同步和排空在途 store，不是数据同步工具。
• • 不要用普通 FENCE 去等待矩阵完成，完成判断只能来自状态轮询 ⚠️。

图 5：逐 tile 同步时序，矩阵启动、轮询完成、再发射向量 load。

解读：

• • 矩阵配置和启动由标量核从槽 0 发出，独占派发周期，保证配置原子性 🔒。
• • 矩阵引擎在启动后异步执行 GEMM，并通过 mstore 把结果写回 DTCM 🧮。
• • 标量核在轮询循环中读取矩阵状态，直到完成位被置起 🔄。
• • 完成确认后，标量核才派发 RVV load，向量后端从 CQ 取指并访问 LSU 🚀。
• • 向量后端乱序执行，但 ROB 保证顺序退休，并异步写回标量/浮点寄存器 ⚖️。
• • 整个流程中普通 FENCE 不参与等待，完成判断完全依赖状态轮询 🚧。

🚧 八、边界与适用场景

适合的负载 ✅：

• • 静态形状、配置可静态化、计算靠循环摊薄的场景。
• • MobileNet 风格卷积、紧凑生成模型、始终在线的视觉/音频推理。
• • 在 CoreMini 上做控制面，在 RvvCoreMini 上做 SIMD DSP/视觉/音频，在 VmeCoreMini 上做 CNN/GEMM/attention 🧠。

不适合的负载 ❌：

• • 每 tile 需要海量动态配置的算法，CSR 和 mset* 的独占派发开销会成为瓶颈 🚦。
• • 动态形状，TCM 静态布局和矩阵 M/N/K 配置不擅长运行时变化 📐。
• • 需要低延迟中断驱动细粒度同步的场景，当前模型以轮询为主 🔄。
• • 需要多通道高并发 DMA 的高吞吐流，DMA 实现是单通道链表描述符、单 outstanding 事务 🚧。

这些不是实现缺陷，而是“用静态性和确定性换能效”的前提被打破后的必然结果。 🎯

🏁 九、结语：窄锚点，宽后端

CoralNPU 的核心设计选择可以压缩成一句话：

让标量前端保持窄而确定，让向量和矩阵后端保持宽而异步，用 CSR 写、状态轮询和集中式 LSU 把两者粘成一条正确的流水线。 🛣️

三个变体共享同一套 4-lane 顺序前端和同一套同步模型，只在后端逐级叠加 RVV 和 VME 能力 🧱。它的性能来自后端的乱序执行和PE 阵列密度；它的正确性来自标量核的显式配置与轮询，以及 LSU 的集中排序 🔐。

理解这一点，比记住 VLEN=128 或 16 个 mt 寄存器更重要 🎯。

📄 十、License

CoralNPU 的软件和 RTL 以 Apache License 2.0 发布 📜。

• • 免版税：使用 Coral NPU 架构或软件，不需要向 Google 支付许可费或权利金 💰。
• • 商业可用：任何公司或开发者都可以基于 Coral NPU 构建和销售商业产品 🏢。
• • 第三方 IP 例外：如果 SoC 厂商将 Coral NPU 与其他专有授权组件（例如特定 CPU 核或内存 fabric）集成，那些第三方组件仍然受其各自许可条款约束 ⚠️。

简而言之：核心 IP 本身是 Apache 2.0、免版税、可商用的；需要单独付费的是你自己选用的第三方组件。 🎯