借瑞萨RA8系列MCU，聊聊Arm Helium技术

但两者的差别在于，Helium在设计理念上主要考虑对现有硬件的大化利用，用的矢量寄存器也少于Neon；Helium的某些操作会用上矢量寄存器和标量寄存器组中的寄存器；Helium支持的数据类型会更多；此外，Helium还支持诸如循环预测、通路预测（lane predication）、复杂数学和scatter-gather内存访问。

白皮书中列举了Helium新增的一些指令和特性。比如说交错（interleaving）和去交错（de-interleaving）load/store指令；支持证书和浮点矢量复杂值处理的指令；

还特别提到lane predication，对于矢量每条lane做条件执行支持的MVE特性——为了达成这项特性，需要专门的寄存器（名为VPR）来保持每条lane的条件；还有大整数支持，引入了大整数处理指令；以及低开销分支扩展，引入了低开销循环和额外的分支指令等。

Arm引入Helium的目标是期望用单颗处理器，取代过去部分开发者需要将专用DSP和Cortex-M处理器一起用的方案。这应该也是瑞萨所说填补市场空白的关键。因为这么做可以简化软件开发，也降低了芯片设计的复杂性和成本。另外Cortex-M处理器具备了高度通用性，执行某些通用非DSP负载还是比很多老的DSP更快。

应该说Helium技术，以及RA8这样的产品，在嵌入式领域就开发者角度来看是具备了相当吸引力的。

关键特性：beatwise

了解到这个程度还是不够的，我们更想搞清楚，Helium在更具体的处理器架构上有哪些变化。Arm工程师在Arm社区更新过系列文章专门谈Helium技术的，起始篇章就是，如果说要提升DSP和ML性能，为什么不直接给Cortex-M加个Neon？其关键还是在于具体实施方案上，Helium和Neon的差异。

要有出色的DSP数字信号处理性能，有相当一部分工作应该是喂足够的数据。所以Cortex-A处理器直接从数据cache里拉128bit Neon负载就会显得游刃有余。但Cortex-M不同，cache资源少，主存追求低延迟——将SRAM路径扩展到128bit对于很多系统而言首先就是不可接受的。另外，MAC指令所需的乘法器占用的芯片面积不小，要在面积敏感的Cortex-M处理器上做4x 32bit乘法器相当的不靠谱。

这些都决定了Helium的设计必须是对资源的物尽其用，把资源用在刀刃上，尤其存储、乘法之类的用了就要保证每周期执行的。像Cortex-M7的方案是，双发射矢量负载（矢量MAC）来确保资源占用；但Helium的目标是要在不同的性能水平上增加DSP性能，而不仅仅是面向M7这样的高端处理器。所以Arm想到了古早的一些技术。

上面这张图展示了VLDR矢量加载和VMLA矢量MAC指令执行序列要超过4个时钟周期，还要求通向存储128bit位宽的通路，4个MAC block，其中有俩一半时间还是闲置的。这张图中，每条128bit宽度的指令切成了4等分，MVE架构称其为beat。这些beats总是做32bit计算，可以是1 x32-bit MAC，也可以是4 x8bit MAC。

考虑到load和MAC执行单元是分开的，这些beats的执行过程其实是可以重叠的。在C, D beat执行VLDR的时候，A, B就可以执行VMLA。如此一来性能就能达到128bit数据通路处理器的水平，但却只需要一半的硬件资源。

基于这种叫做“beatwise”的执行概念，32bit数据路径的处理器，也能处理上述相同指令。Arm的说法是如此实现了单发射标量处理器的性能翻番（8个周期以8 x32bit值加载和执行MAC），却完全不需要考虑双发射标量指令的面积和功耗惩罚问题。MVE支持多每周期4个beat实施方案，在某些情况下这种beatwise的执行方式就类似于传统的SIMD。

不过beatwise执行也诞生了一些问题，比如说多个部分执行的指令同时进行，打断和错误处理就会很复杂；再比如如果一个指令跨beat，则仍然需要考虑空闲时间或者stall等待的问题；另外要确保执行上的重叠，对应的每条指令都应当操作128bit数据...这些挑战都需要在设计时做考量。具体的受限于篇幅，就不多做解释了。

但总的来说，这种beatwise执行方案，是MVE达成PPA平衡的基础。

配合beatwise的其他特性

有关Helium还有几个配套关键技术是值得一谈的。比如前面提到每条指令应当尽可能操作等长数据：DSP处理是需要面向不同的数据格式的。就像图像数据，一般是以交错的红、绿、蓝，外加alpha通道像素值做存储的。

为了对计算做矢量化，需要让所有的红色像素为一个矢量，所有绿色像素为另一个矢量等等…在Neon结构里，VLD4/VST4指令是用于执行这类转换的。还有像是VST2指令，用于交错立体声音频的左右两个通道。这类指令支持8-32bit的不同尺寸。

前面我们提到了MVE的beatwise执行，是让存储和ALU操作重叠进行。为了确保这种重叠，每条指令都应该操作128bit数据。此时VST4这样的指令store数据位数过多，会让ALU长时间处在空闲状态。

MVE的方案是将store再切分成块，与ALU操作达成平衡，每个块都仅存储128bit数据。512bit的store，也就是4-way交错，MVE有4条指令VST40, VST41, VST42, VST43。

不过这么做还是会带来一些问题：比如说这4条指令存储不同的通道，对8bit像素数据而言意味着每条指令可能存储了非连续的数据，这样的访问模式对于存储子系统而言会很悲剧。以及和其他矢量指令合作，寄存器堆port需要设定为访问行，而不是列等。Arm在blog文章里具体探讨了此类问题的解决方案。

此外，数据访问和存储也是Helium技术关注的重点之一。毕竟在beatwise大前提下，4-beat矢量架构需要考虑如何处理数据load为矢量及存储操作。所以要进行“连续load”操作，针对每个beat，从标量寄存器中指定的base地址开始，连续访问内存。无论目标数据类型如何，这都将有效利用总线带宽。

有关数据存取，Helium引入了所谓的size变化内存操作（size-changing memory operations）：数据可存储为面向每个beat的8, 16或32bit单次访问，基于置0或者符号扩展来达到预期的数据类型。而对于store，数据也可以缩减到预期的size。配套的load和store指令覆盖了比较丰富的寻址模式，特性方面涵盖pre或者post-incrementing和指针回写支持，在绝大部分情况下也就不需要进行单独的指针操作。

后设计上还考虑并行度瓶颈问题。Arm在blog中列举了内存复制代码的一个例子：具体是循环迭代次数递减，循环过程中，条件分支回到循环开头占到了指令的50%。许多小型Cortex-M处理器是没有分支预测器的，受制于分支惩罚，runtime开销实际上就超过了这50%。Helium也考量了对应的解决方案——和Armv8.1-M引入低开销循环和新增条件指令应该有关，相关因素在代码层面比较具体，包括各类方法的利弊，有兴趣的同学还是建议去读一读Arm的blog。

本文后再给出瑞萨就应用层面的一些信息。毕竟从芯片设计企业的角度，还是更能看出技术效果的。瑞萨在去年4月的两篇blog中，给出了有关Cortex-M85和Helium-MVE的阐释和实测。

瑞萨也认为Helium是用于替代低端到中端DSP核心的方案，“8个128bit矢量寄存器，针对不同的应用支持广泛的矢量数据类型”，“特性诸如重叠的pipeline，加强的分支预测，和循环优化，都为性能提升有助益”，“加强的存储访问指令和复杂值处理支持，令Helium成为Cortex-M85的强有力扩展。”

这段话基本也总结了我们整篇文章提到的有关Helium的关键特性。瑞萨在blog中列举了两个demo——这里我们谈其中的一个，进博会上瑞萨展示过：人物识别AI套件，基于RA8D1：展示的是检测摄像头拍到的人，据说检测距离能达到20米，支持180°摄像头，各种光线和环境下都没问题。

这个demo是瑞萨和PlumerAI合作完成的。演示基于TinyML模型——当时瑞萨的现场工作人员告诉我们，模型训练超过3200万张图片。要知道这个演示完全没有用到任何的加速器，单凭藉MCU完成。这就属于典型的低成本、低功耗AI解决方案了。

上面这张图是瑞萨给出Cortex-M85与其他Cortex-M核的性能比较，柱状图中的蓝色柱子表示用PlumerAI的推理引擎来跑，红色表示用TensorFlow Lite for Microcontrollers来跑。另外右边的两列CM85，分别表示启用Helium MVE和不用Helium MVE。M85相比M7，此处性能差距大有3.37倍。更快的推理速度，自然意味着CPU可以更早回到睡眠模式，实现总体的低能耗。

当然在嵌入式应用中，若有更高AI性能需求，王均峰也谈到还是可以用AI加速器配合MCU使用，瑞萨也提供AI SDK，其中有各种常见AI算法和工具。不过Helium技术，及RA8系列MCU的出现，的确还是为嵌入式应用提供了更多的可能性；也是现如今我们谈AI everywhere的实现组成部分之一。