📚 课程目录第3章 Arm Ethos-U架构概览

3、Arm Ethos-U架构概览：Ethos-U55与U65的硬件架构、计算单元、内存层次与关键性能指标

在TinyML的实际部署中，模型能否高效运行不仅取决于算法本身的复杂度，更取决于底层硬件加速器是否与算子的数据流特征相匹配。Arm Ethos-U系列NPU（Neural Processing Unit）是专为Cortex-M与Cortex-A系列处理器设计的嵌入式推理加速器，其设计哲学并非追求极致的峰值TOPS，而是在有限的功耗与面积预算内，最大化“有效算力利用率”。本章将深入拆解Ethos-U55与Ethos-U65的硬件微架构、计算单元分工、内存层次结构以及决定实际性能的关键指标，帮助你在部署前建立对硬件行为的准确预期。

3.1 硬件架构定位与设计哲学

Ethos-U55与Ethos-U65并非通用的GPU或DSP，而是专用深度神经网络加速器。其核心设计目标是在极低的功耗预算（通常小于1W）下，以确定性的延迟完成CNN（卷积神经网络）的推理。两者最大的区别在于系统集成位置：U55通过AHB或AXI总线与Cortex-M33/M55等MCU级处理器相连，而U65则面向Cortex-A55/A75等应用处理器，支持虚拟内存和更大的地址空间。从微架构看，U55的MAC阵列为8x8x16（即每个周期执行128次乘累加），而U65将MAC阵列翻倍至16x8x16（256 MACs/cycle）。这一差异直接决定了U65在处理更大通道数（如256通道以上的特征图）时，计算吞吐量是U55的两倍。

  关键认知：Ethos-U系列不执行控制流（如if/else）或复杂的数据索引操作，它只负责“规则”的卷积、池化、全连接和激活函数。所有非规则操作（如Reshape、拼接、自定义算子）必须由CPU（Cortex-M/A）完成，或通过Vela编译器将其转换为NPU可执行的“命令流”。因此，模型能否被完整编译到NPU上，取决于算子是否被Vela支持，而非NPU本身的计算能力。

3.2 计算单元深度拆解：MAC阵列与专用引擎

Ethos-U系列的计算核心由三个主要单元构成：MAC（乘累加）阵列、激活/池化引擎和权重解压引擎。MAC阵列采用脉动阵列（Systolic Array）设计，数据在阵列中逐周期流动，避免了频繁的寄存器读写。每个MAC单元支持INT8和INT16两种精度，其中INT8是TinyML的主力精度，INT16用于高动态范围场景（如音频）。激活引擎紧耦合在MAC阵列之后，支持ReLU、LeakyReLU、Sigmoid、Tanh以及最大/平均池化，这些操作在NPU内部以流水线方式完成，不产生额外的内存访问。权重解压引擎是Ethos-U系列的特色——它支持两种压缩格式：权重剪枝稀疏性（跳过零值权重）和权重编码压缩（类似查表法），这可以显著减少从SRAM到MAC阵列的带宽压力。

计算单元	Ethos-U55	Ethos-U65	功能说明
MAC阵列规模	8x8x16 (128 MACs)	16x8x16 (256 MACs)	每周期执行的乘累加次数
支持精度	INT8 / INT16	INT8 / INT16	INT16吞吐量减半
激活函数	ReLU, LeakyReLU, Sigmoid, Tanh	同左	硬件直接实现，无额外延迟
池化支持	MaxPool, AvgPool	同左	支持2x2/3x3等常见核
权重压缩	支持稀疏跳过+编码压缩	支持稀疏跳过+编码压缩	压缩率通常为2x-4x

3.3 内存层次与数据流策略

Ethos-U系列的内存层次极为精简，没有多级Cache，而是采用显式管理的SRAM。NPU通过AXI接口直接访问片内SRAM（通常为512KB至数MB），所有输入特征图、权重和输出特征图都必须驻留在SRAM中才能被计算单元读取。这一设计带来了两个关键推论：第一，模型的总权重大小必须小于SRAM容量，否则无法完整部署；第二，数据搬运（DMA）的效率决定了实际性能的上限。Vela编译器在编译时会将模型划分为多个“Region”，每个Region包含一组算子，并计算每个Region所需的SRAM空间。如果权重超过SRAM容量，Vela会插入“权重重载”操作，即从Flash或外部DDR重新加载权重，这会导致性能急剧下降。

实战经验：在部署MobileNetV2（约3.4MB权重）到仅有512KB SRAM的Ethos-U55上时，Vela会强制将模型切分为多个Region。此时，推理延迟的瓶颈不再是MAC计算，而是Flash读取权重的带宽。建议使用--arena-cache-size参数调整SRAM分配策略，并优先考虑将模型量化到INT8以减小权重体积。

3.4 关键性能指标与计算效率评估

评估Ethos-U系列性能时，不能只看TOPS（每秒万亿次操作），而应关注以下三个核心指标：MAC利用率（MAC Utilization）、内存带宽利用率和端到端延迟。MAC利用率是指实际执行的MAC周期数与理论峰值MAC周期数的比值。由于卷积运算的Padding、Stride以及特征图尺寸不匹配，MAC阵列往往无法100%满载。例如，一个3x3卷积在8x8阵列上运行时，如果输入通道数为16，则阵列可以完全利用；但如果输入通道数为24，则会有8个MAC单元空闲。Vela编译器会通过算子融合和重排来最大化利用率，但最终效果取决于模型结构。

# 使用Vela编译器查看性能估算
vela --accelerator-config=ethos-u55-256 my_model.tflite
# 输出中关注:
# Total MACs: 12.3M
# MAC utilization: 78.5%
# Estimated cycles: 1.2M
# SRAM used: 480KB / 512KB

内存带宽利用率则反映了数据搬运与计算的重叠程度。Ethos-U系列支持双缓冲（Double Buffering），即当MAC阵列计算当前数据块时，DMA引擎同时预取下一块数据。如果模型层与层之间数据依赖性强（如逐元素相加的ResNet结构），则可能无法充分重叠，导致计算单元等待数据。此时，算子融合（如将Conv+ReLU+Add融合为一个算子）是提升带宽利用率的最有效手段。

3.5 案例拆解：基于Ethos-U55的语音唤醒词识别部署

假设我们需要在一个电池供电的智能传感器节点上部署一个关键词识别（KWS）模型，硬件平台为Cortex-M55 + Ethos-U55（256 MACs配置，512KB SRAM）。模型为DS-CNN（Depthwise Separable CNN），输入为49x10的MFCC特征图，模型大小约180KB（INT8量化后）。

初始现象：使用Vela默认配置编译后，推理延迟为8.2ms，但功耗测试显示平均电流为12mA，超出预算（目标<8mA）。分析Vela报告发现，MAC利用率仅为62%，且SRAM使用量达到498KB，几乎占满。

分析判断：DS-CNN中的深度可分离卷积（Depthwise Conv）在Ethos-U55上效率较低，因为Depthwise卷积的输入通道数通常等于输出通道数（如64通道），而MAC阵列的宽度为8，导致64通道需要8个周期才能完成一次滑窗计算，阵列利用率只有50%。此外，模型中的Reshape操作被放置在NPU外部执行，导致CPU与NPU之间产生额外的数据拷贝。

实际操作步骤：

在Vela编译命令中添加--optimise-for-latency，让编译器尝试更激进地融合算子。
手动修改TFLite模型，将Reshape操作替换为Conv 1x1（保持通道数不变），使其能被NPU原生支持。
将SRAM分配策略从--arena-cache-size=400KB调整为--arena-cache-size=350KB，强制Vela更频繁地重载权重，但换取更大的激活缓冲区，减少数据搬运冲突。

结果对比：调整后，MAC利用率提升至81%，推理延迟降至5.9ms，平均电流降至7.2mA。代价是Flash读取次数增加了约15%，但Flash读取功耗远低于NPU计算功耗，因此整体能效显著改善。

风险提示：强制减小SRAM缓存可能导致某些层的数据溢出到Flash，如果Flash读取带宽不足（如使用QSPI Flash而非并行NOR Flash），反而会恶化延迟。务必在修改后重新测量端到端延迟和功耗，而非仅依赖Vela的估算值。

3.6 常见误区与设计总结

误区一：认为TOPS越高性能越好。实际上，Ethos-U55的0.5 TOPS（INT8）在运行3x3卷积时可能比某些1 TOPS的DSP更快，因为其数据流设计更匹配CNN模式。
误区二：忽略权重重载开销。当模型权重超过SRAM容量时，性能会断崖式下降。建议在模型设计阶段就考虑硬件约束，例如将3x3卷积替换为1x1卷积以减少参数量。
误区三：所有算子都期望NPU加速。对于Element-wise操作（如Add、Mul）和简单的Permute，CPU（Cortex-M55的Helium DSP指令）可能比NPU更快，因为NPU需要额外的命令解析和DMA设置开销。