前言硬件 demo 如果只能在 testbench 里改输入，系统感会很弱。CoolDA 这类 SoC 仿真更进一步：让 CPU 启动一个精简 shell，用户或脚本通过 shell 触发 runtime，runtime 再驱动 NPU。 这样 Verilator 就不只是“跑 RTL”，而是变成一个可交互的系统实验环境。 交互链路整个交互链路可以写成： 123456789host termin

前言硬件核只会做 4x4，但用户想算的矩阵可能是 8x8、16x16，甚至更大。解决方法不是让 CPU 直接操作每一个寄存器细节，而是分两层： BSP：把寄存器表包装成薄函数； runtime：把大任务拆成 4x4 tile，并调度硬件核反复执行。 BSP：越薄越好BSP 的职责是硬件寄存器访问。它应该非常薄。 最底层是 MMIO helper： 1234567891011static in

前言CPU 眼里的 NPU，不是一堆乘法器，而是一组寄存器。只要寄存器契约设计清楚，软件就能驱动硬件；只要契约设计混乱，硬件再能算也很难用。 这一篇拆 CoolDA 的 APB NPU：寄存器怎么排，A/B 数据怎么打包，start/busy/done 如何工作，4x4 乘法核如何完成计算。 APB 外设的基本形状一个 APB 外设大致会接收这些信号： 123456

前言单独写一个 NPU 矩阵乘法模块，只能说明硬件会算。真正有系统意义的问题是：CPU 怎么使用它？ CoolDA 这类 SoC demo 要讲的就是这条路径： 1234567用户命令 -> 操作系统 shell -> runtime -> BSP 驱动 -> APB 总线 -> NPU 寄存器 -> 4x4 INT8 矩阵乘法核 这篇先建立系统视

前言RTL 设计最怕“看起来能跑”。一个 NPU 小 demo 如果只做一次端到端输出，很难定位问题。真正稳妥的方式是分层验证： 12345单 PE -> PE Array -> Control Unit -> NPU Top -> 算子链 每一层都锁住一部分语义，最终整机才可信。 第一层：单 PE 验证单 PE 要验证的不是“能不能输出一个数”，而是乘加合约是

前言PE Array 负责算，Unified Buffer 负责存，但 NPU 还缺一个“指挥系统”。这个系统就是 Control Unit。 Control Unit 不做乘法，却决定： 什么时候接收命令； 什么时候从 buffer 读数据； 什么时候启动 PE Array； 什么时候做激活和池化； 什么时候把结果输出。 32 位命令格式一个最小 NPU 可以使用 32 位命令： 123

前言NPU 的性能瓶颈经常不是“算不动”，而是“喂不饱”。PE Array 可以很大，但如果每一拍都在等数据，面积再多也只是摆设。 Unified Buffer 是 NPU 里的片上数据仓库。它的价值不只是“存一些数”，而是定义数据本地性：哪些数据已经在片上，哪些结果可以原地处理，哪些数据需要输出到外部。 为什么片上 buffer 很重要矩阵乘法中，同一个 A 元素会参与多个输出，同一个 B 元

前言NPU 的核心计算单元叫 PE，也就是 Processing Element。一个 PE 并不神秘，它做的事情通常就是一次乘加： 1y_out = y_in + a * b 难点不在单个 PE，而在怎样组织成阵列。矩阵乘法的每个输出都需要沿着 K 维累加，如果让每个 PE 自己去取完整数据，带宽会爆炸；如果让数据按规律流过阵列，同一份 A、B 数据就能被多个 PE 复用。 单个 PE 的完

前言NPU 最容易被一句话讲浅：它是用来做神经网络推理的矩阵乘法加速器。这句话没有错，但它省略了真正有工程价值的部分。 一个 NPU 不只是“能乘矩阵”。它要解决四个问题： 神经网络中的计算怎样变成规则的乘加。 数据怎样进入片上缓冲并被重复使用。 大量 PE 怎样同时工作而不是等数据。 主机怎样用命令驱动 LOAD -> MATMUL -> ACT -> POOL ->

前言前面几篇已经把链路铺完整：LLVM 后端能发，MC 层能编码，模拟器能作为 reference model，AM/BSP 能承载裸机程序，RTL 评测也有了控制变量。现在可以讨论结果，但仍然要保持克制。 更准确的总结是： 123RISC-VI 在当前同源双发射 RTL 功能模型中，通常能减少动态提交数和部分短依赖，但也会暴露三源读端口、load-use 和分支预测口径上的真实代价。