Ethos-U NPU架构概览：Ethos-U55/U65的硬件架构、计算单元、内存层次与协同工作方式
在TinyML模型的NPU延迟预算优化工作中，理解Ethos-U系列NPU的硬件架构是进行一切性能调优的前提。Ethos-U55与Ethos-U65是Arm针对Cortex-M和Cortex-A系列处理器推出的微神经网络处理器（microNPU），它们并非独立的计算芯片，而是作为Cortex-M/A主控CPU的协处理器，通过AXI总线与系统总线矩阵相连。本章将深入拆解这两款NPU的硬件架构、计算单元、内存层次以及与Cortex-M的协同工作机制，帮助你在后续的延迟预算分析中，能够准确判断瓶颈是来自MAC阵列利用率、数据搬运带宽，还是CPU与NPU的同步开销。
上图展示了Ethos-U系列NPU在嵌入式系统中的核心位置与数据流关系。从硬件视角看，NPU并非独立的主设备，而是受Cortex-M主控CPU支配的从设备。CPU负责加载模型权重、配置NPU寄存器、启动推理任务，而NPU则负责执行卷积、池化、全连接等计算密集型操作。理解这一主从关系，是后续进行延迟预算优化的基础——因为NPU的利用率高低，很大程度上取决于CPU能否及时“喂饱”它。
3.1 核心原理：Ethos-U55与U65的硬件架构差异
Ethos-U55与U65虽然同属Ethos-U系列，但设计目标与硬件资源存在显著差异。U55面向Cortex-M55/M85等微控制器，最大MAC阵列规模为128个MACs（乘累加单元），支持INT8、INT16和FP32（仅U55支持FP32推理，但效率较低）数据类型。U65则面向Cortex-A系列应用处理器，MAC阵列规模提升至256个MACs，且增加了对多NPU实例的支持（最多4个NPU核），并引入了对外部DRAM的访问能力。
| 特性 | Ethos-U55 | Ethos-U65 |
|---|---|---|
| 目标主控 | Cortex-M55/M85 | Cortex-A32/A35/A53/A55 |
| MAC阵列规模 | 32/64/128 MACs | 128/256 MACs（可多核） |
| 支持数据类型 | INT8/INT16/FP32 | INT8/INT16（FP32需转INT8） |
| 内存访问 | 仅SRAM（DTCM/内部SRAM） | SRAM + 外部DRAM |
| 典型频率 | 32-400 MHz | 400-1000 MHz |
| 典型算力 | 0.1-0.5 TOPS | 0.5-4 TOPS |
从延迟预算角度看，U55的瓶颈通常在于MAC阵列规模较小，导致大模型需要多次“切块”处理；而U65的瓶颈则更多出现在内存带宽上——虽然算力翻倍，但如果SRAM带宽不足，MAC阵列会因等待数据而空转。因此，在后续优化中，针对U55应优先考虑减少计算量（如量化、剪枝），针对U65则应优先优化数据布局与DMA传输效率。
3.2 计算单元：MAC阵列与专用硬件加速器
Ethos-U NPU的核心计算单元是MAC阵列，它由多个乘累加单元组成，能够在单个时钟周期内完成多次乘加运算。以U55的128 MACs配置为例，其内部包含128个8x8位乘法器与对应的累加器，支持INT8数据类型时，每个周期可完成128次乘加操作。除了MAC阵列外，NPU还集成了专用的激活函数单元（支持ReLU、Sigmoid、Tanh等）、池化单元（最大/平均池化）以及残差加法单元，这些硬件加速器减少了CPU的软件开销。
关键参数解读：MAC利用率是衡量NPU计算效率的核心指标。计算公式为：MAC利用率 = 实际有效MAC操作数 / (MAC阵列规模 × 时钟周期数)。在Vela编译器生成的命令流中，如果存在大量padding（填充）或stride（步长）不匹配的卷积，MAC利用率会显著下降。例如，一个3x3卷积在128 MACs阵列上，若输入通道数为64，则每个输出像素需要64次乘加，但MAC阵列宽度为128，导致一半的MAC单元空闲。
在实际操作中，Vela编译器会自动将卷积操作“切块”为MAC阵列宽度的整数倍。例如，对于输入通道为32的卷积，Vela会将其拆分为两次16通道的MAC操作，以充分利用128 MACs的宽度。这种切块策略直接影响延迟——切块次数越多，控制开销越大，延迟越高。因此，在设计模型时，应尽量使通道数接近MAC阵列宽度的整数倍（如U55的32/64/128，U65的64/128/256）。
3.3 内存层次：SRAM、Flash与外部DRAM的协同
Ethos-U NPU的内存层次设计遵循“就近原则”：权重和激活数据优先存放在SRAM中，以提供高带宽低延迟的访问。U55仅支持SRAM访问，其内部集成了KB级的权重缓冲（Weight Buffer）和激活缓冲（Activation Buffer），用于暂存当前计算所需的数据。U65则增加了对外部DRAM的支持，允许模型权重直接存储在DRAM中，通过AXI总线按需加载。
内存层次的优化要点在于数据复用。NPU在执行卷积时，会反复读取同一份权重数据用于多个输出通道的计算。如果权重能够完全驻留在SRAM中，则只需从Flash或DRAM加载一次；如果权重超过SRAM容量，则必须分块加载，导致额外的DMA传输延迟。Vela编译器通过“权重重排”技术，将权重按使用顺序重新排列，减少DMA传输次数。
// 内存带宽估算示例（U55 @ 200MHz, 128 MACs）
// 假设INT8卷积，输入特征图 32x32x64，权重 3x3x64x128
// 总MAC操作数 = 32*32*64*128*3*3 = 75,497,472
// 所需权重数据 = 3*3*64*128 = 73,728 bytes
// 若SRAM带宽为 32 bytes/cycle，则加载权重需 73,728/32 = 2,304 cycles
// 计算时间 = 75,497,472 / 128 = 589,824 cycles
// 权重加载时间占比 = 2,304 / (589,824 + 2,304) ≈ 0.39%上述估算表明，在理想情况下，权重加载时间占比极低。但实际中，如果SRAM容量不足导致权重分块加载，每次切换权重块都需要额外的DMA启动开销，延迟会显著增加。因此，在模型部署前，应使用Vela的--memory-mode选项检查SRAM使用情况，确保权重块大小与SRAM容量匹配。
3.4 与Cortex-M的协同工作方式：命令流与事件同步
Ethos-U NPU与Cortex-M的协同工作基于“命令流（Command Stream）”机制。CPU通过Vela编译器生成的二进制命令流文件，将NPU需要执行的每一层操作（卷积、池化、激活等）编码为命令。CPU只需将命令流基地址写入NPU的控制寄存器，NPU便会自动解析并执行，无需CPU逐指令干预。
- 初始化阶段：CPU将模型权重从Flash拷贝到SRAM（或配置U65的DRAM地址），并将命令流地址写入NPU的
BASEADDR寄存器。 - 启动阶段：CPU写入
START命令，NPU开始执行命令流。此时CPU可以进入休眠或执行其他任务。 - 完成通知：NPU执行完所有命令后，通过中断或事件（Event）通知CPU。CPU在中断服务程序中读取NPU状态寄存器，确认推理结果。
- 双缓冲流水：为隐藏DMA传输延迟，通常使用双缓冲技术——当NPU处理当前帧时，CPU预先加载下一帧的权重和输入数据。
实战经验：在Cortex-M55上使用Ethos-U55时，建议将NPU中断优先级设置为高于普通外设中断，但低于实时性要求最高的任务（如电机控制）。同时，利用__WFE（Wait For Event）指令让CPU在等待NPU完成时进入低功耗状态，可显著降低系统功耗。
协同工作的效率直接影响端到端延迟。如果CPU在NPU执行期间频繁访问总线（例如同时进行日志输出或传感器读取），会与NPU的DMA传输争抢总线带宽，导致NPU等待数据。因此，在延迟敏感的应用中，应使用DTCM（Data Tightly Coupled Memory）存放CPU的临时数据，避免与NPU共享SRAM带宽。
3.5 案例拆解：基于U55的人脸检测模型延迟分析
假设我们在一款基于Cortex-M55（400MHz）和Ethos-U55（128 MACs，200MHz）的MCU上部署一个人脸检测模型，模型结构为：输入96x96x3，经过3层3x3卷积（通道数分别为16、32、64），每层后接ReLU和2x2最大池化，最后通过全连接层输出2个类别（有人脸/无人脸）。
初始现象：实测端到端推理延迟为45ms，其中NPU计算时间仅占18ms，CPU相关开销（数据预处理、后处理、命令流加载）占27ms。进一步分析发现，CPU在每次推理前需要将输入图像从摄像头缓冲区拷贝到SRAM，耗时12ms；命令流加载耗时8ms；后处理（softmax）耗时7ms。
分析判断：NPU计算时间18ms，MAC利用率约为72%（理想情况下，总MAC操作数约1.2亿次，128 MACs @200MHz理论计算时间为4.7ms，实际18ms说明存在大量数据搬运等待）。通过Vela的--verbose输出发现，第一层卷积的输入通道为3，远小于MAC阵列宽度128，导致MAC利用率仅约2.3%。
优化操作：
- 将输入图像从RGB888转换为INT8格式，并直接写入SRAM中NPU可访问的地址，避免CPU逐像素拷贝（节省10ms）。
- 使用Vela的
--weight-estimation功能，将第一层卷积的输入通道从3填充（Pad）到32，使MAC利用率提升至25%（增加少量计算量，但大幅减少空转周期）。 - 将softmax后处理改为查表法，并利用NPU的激活函数单元完成（节省5ms）。
结果对比：优化后端到端延迟降至22ms，其中NPU计算时间降至14ms（MAC利用率提升至85%），CPU开销降至8ms。总延迟降低51%，满足实时性要求。
风险提示：对输入通道进行Padding会增加约10%的计算量，在MAC阵列已满负荷时可能适得其反。务必在优化前使用Vela的--report选项生成详细的层级延迟报告，确认瓶颈确实在MAC利用率而非内存带宽。
复盘经验：本案例揭示了TinyML延迟优化的核心原则——先看MAC利用率，再看内存带宽，最后看CPU同步开销。Ethos-U NPU的硬件架构决定了其擅长处理“大而规整”的卷积，对于通道数过小的层，应通过Padding或合并层来匹配MAC阵列宽度。同时，CPU与NPU的协同效率往往被忽视，实际项目中，CPU侧的图像预处理、数据拷贝时间可能远超NPU计算时间，必须通过DMA和双缓冲技术来隐藏这些开销。