3、Ethos-U架构与特性：Ethos-U55/U65 NPU架构、内存层次、算子支持、与Cortex-M的协同工作方式

在TinyML语音唤醒模型的部署实践中，模型推理的实时性与能效比是两大核心指标。虽然Cortex-M系列处理器凭借其低功耗特性成为边缘设备的理想选择，但其有限的DSP（数字信号处理）算力在处理卷积神经网络（CNN）或Transformer等复杂模型时，往往面临延迟过高或内存带宽不足的瓶颈。Arm Ethos-U系列微神经网络处理单元（NPU）正是为解决这一矛盾而设计。本章将深入剖析Ethos-U55与Ethos-U65的硬件架构、内存层次、算子支持范围，并重点阐述其与Cortex-M主机处理器之间高效协同的工作机制，为后续在具体硬件上部署语音唤醒模型打下坚实的硬件认知基础。

上图清晰地展示了Ethos-U与Cortex-M在典型SoC中的协同拓扑。主机CPU（Cortex-M系列）与NPU并非简单的“主从”关系，而是一种基于任务划分的异构计算模式。CPU擅长逻辑控制、音频信号预处理（如MFCC特征提取）以及稀疏的标量运算；而NPU则针对卷积、全连接等密集的4D张量运算进行了硬件极致优化。理解这种分工，是后续进行算子映射与性能调优的前提。

3.1 核心原理：Ethos-U55与U65的架构差异及共性

Ethos-U55是Arm针对Cortex-M平台推出的首款微NPU，其设计目标是在极低功耗预算下（通常小于1mW/MHz）提供高达4.6 TOPS的算力（取决于配置）。而Ethos-U65则是U55的增强版，主要面向更高性能的Cortex-M85或Cortex-M55平台，支持更大的内存带宽和更高的MAC吞吐量。两者在架构上具有高度继承性，但在数据通路宽度和内存接口上存在显著差异。

在内存层次上，两者都遵循“内部SRAM优先，外部DDR兜底”的原则。NPU内部集成了一块紧耦合SRAM（TCM），用于存放输入特征图、权重和输出特征图。U55的TCM最大支持1MB，而U65通过AXI接口支持最高2MB的紧耦合内存。当模型超过内部SRAM容量时，NPU的DMA控制器会自动执行数据分块（Tiling）策略，将数据从外部Flash或PSRAM按需搬运至内部SRAM，这个过程对开发者透明，但会引入额外的延迟开销。

特性维度	Ethos-U55	Ethos-U65
目标主机核心	Cortex-M55 / M33 / M7	Cortex-M55 / M85
MAC 阵列规模	32 / 64 MACs	128 / 256 MACs
峰值算力 (INT8)	0.5 - 4 TOPS	4 - 32 TOPS
内部SRAM容量	最大 1 MB	最大 2 MB
外部内存接口	AXI 32-bit	AXI 64-bit (双通道)
典型应用场景	关键词唤醒、传感器分类	多关键词识别、小型语音命令

3.2 判断方法与操作流程：如何评估模型是否适合Ethos-U部署

并非所有神经网络都能在Ethos-U上高效运行。在项目初期，工程师需要快速判断现有语音唤醒模型（如DS-CNN、CRNN或小型Transformer）是否具备移植价值。判断的核心依据是算子支持列表与数据精度要求。

1. 算子兼容性检查：访问Arm官网查阅Ethos-U算子支持矩阵。当前版本主要支持：CONV2D、DEPTHWISE_CONV2D、FULLYCONNECTED、AVGPOOL、MAXPOOL、ADD、MUL、RELU、TANH等。若模型包含LSTM或GRU，则需要将其展开为矩阵乘法序列，或改用TC-ResNet等纯卷积结构。
2. 量化准备：Ethos-U原生支持INT8/INT16推理。模型必须经过量化感知训练（QAT）或后训练量化（PTQ）。对于语音唤醒模型，建议使用QAT以保证精度损失小于1%。
3. 内存占用估算：使用工具（如Vela编译器）在PC上模拟编译，查看生成的arena内存大小。若该值超过NPU内部SRAM的80%，则需考虑模型裁剪或深度可分离卷积替换。

3.3 案例拆解：基于Ethos-U55的10关键词唤醒模型部署实战

本案例基于Arm Corstone-300 FPGA平台，目标是在Cortex-M55 + Ethos-U55（64 MAC配置）上部署一个10类别的语音唤醒模型（包含“Hi, Robot”、“Turn On”等）。模型结构为5层深度可分离卷积 + 全连接层，参数量约180KB，输入为40维MFCC特征（49帧）。

初始现象与目标：在纯Cortex-M55上运行，单次推理耗时约85ms，功耗约12mW。目标是将推理延迟降低至30ms以内，功耗降低至5mW以下。

关键输入数据与参数：

• 模型量化后权重大小：180KB（INT8）。
• 激活值内存峰值：约120KB（通过Vela分析得出）。
• NPU内部SRAM容量：384KB（该FPGA配置）。

分析判断过程：由于权重与激活值总和（300KB）小于384KB，模型可完全驻留在NPU内部SRAM中，无需外部DMA搬运，这为低延迟提供了基础。但Vela编译报告显示，第一层卷积的输入数据（MFCC特征）在内存中排列为[1, 49, 40, 1]，而NPU期望的NHWC布局要求通道维在最后，且需要4字节对齐。若直接搬运，会产生大量非对齐访问。

实际操作步骤：

1. 数据布局优化：在Cortex-M55上，将MFCC特征提取的输出缓冲区从int16_t数组改为int8_t数组，并手动填充至4字节对齐（即每行40个特征值填充至40字节）。
2. Vela编译参数调整：使用--arena-cache-size 393216（384KB）参数，强制Vela使用内部SRAM作为主存储区，避免生成外部内存访问代码。
3. 中断驱动推理：配置NPU完成中断（IRQ）。CPU在将输入数据写入NPU缓冲区后立即进入休眠（WFI指令），NPU完成推理后通过中断唤醒CPU读取结果。

结果对比：优化后，单次推理延迟降至22ms（提升约3.8倍），系统总功耗（CPU+NPU）降至4.8mW。其中，NPU推理功耗约2.1mW，CPU在休眠状态下的漏电功耗约0.3mW。

风险与代价：主要风险在于MFCC特征提取（运行在CPU上）耗时约15ms，成为了新的瓶颈。后续需考虑将MFCC部分计算也迁移至NPU（通过自定义算子）或使用硬件加速器。

3.4 常见误区与总结复盘：协同工作的关键细节

在项目实践中，工程师常陷入以下误区，导致性能不升反降。

• 误区一：将所有计算都扔给NPU。实际上，NPU不擅长处理RESHAPE、CONCAT等内存密集型操作。这些操作在NPU上执行时，会产生额外的DMA拷贝。正确做法是在CPU上完成这些轻量级操作，仅将卷积和全连接层映射至NPU。
• 误区二：忽略CPU与NPU的并行性。理想状态下，CPU在等待NPU推理时，应同时处理下一帧音频数据的MFCC提取。这需要双缓冲机制（Ping-Pong Buffer）。若采用同步调用，CPU将处于空转状态，浪费约40%的算力。
• 误区三：内存分配未考虑Cache一致性。虽然Cortex-M55没有数据缓存（D-Cache），但若使用Cortex-M85，其带有L1缓存。NPU通过AXI总线访问内存时，不会经过CPU的L1缓存。因此，CPU写入的输入数据必须执行SCB_CleanDCache_by_Addr操作，否则NPU可能读到脏数据。

总结复盘：Ethos-U的成功部署，核心在于“数据流管理”而非“计算管理”。NPU的计算吞吐量远超内存带宽，因此，如何让数据在正确的时间出现在正确的位置（SRAM），是性能优化的核心。建议开发者使用Arm提供的Vela性能分析器（Performance Advisor）输出详细的瓶颈报告，针对性地优化内存布局。此外，保持模型结构的“NPU友好性”（如避免使用stride=2的大卷积核，改用pooling下采样）能显著提升MAC阵列利用率。