Helium

  • Arm Helium

    Photo01:なんでヘリウムなのかと思ったら、ちゃんと意味があってびっくり

Armの場合、Vector ExtensionとしてはNeonとSVE(Scalable Vector Extension)がすでに存在しており、特にNeonは広範に利用されているが、Heliumはこの「位置づけとしては」このNeonのCortex-M向けという形になる。「位置づけとしては」というのは、実装というかコンセプトの時点でNeonとはまったく異なったものになっているからだ。

まずHeliumの目的であるが、これまでCortex-M4とかM7などに提供されてきたDSP Extensionをさらに強化し、主要なDSPアプリケーションの性能を従来比4倍(プレスリリースでは5倍になっている)に、Machine Learning向けアプリケーションの性能を従来比15倍にするというものだ。

またHeliumそのものはFloating Point演算は搭載しておらず、対象はFixed Pointの8/16/32bitで、Neonにあった64bitはサポート外である。Floating PointはHeliumをFPUと組み合わせる事で可能になるが、この場合も対象はFP16とFP32で、FP64は未サポートである。

レジスタ構成もちょっと異なっている。Neonの場合は128bitレジスタ×16(A64以降は×32)の構成だが、Heliumでは128bitレジスタ×8の構成で、A32世代のNeonの半分ということになる。これを64bit×16あるいは32bit×32の構成としてアクセスすることも可能、というのはNeonと同じだ。この64bit×16ないし32bit×32の構成は、FPUからのアクセスとなり、HeliumのVector Instructionからは128bit幅という形になる。

さて、最大の違いは実行のスループットである。Heliumでは、128bit分の演算を基本2ないし4cycleで処理を行う模様だ。最大の理由は、メモリのスループットが制限されているためだ。Neonの場合、Cortex-Aコアは128bitのAXI I/FでInterconnectと接続され、その先のメモリコントローラもやはり128bit幅になっている上、大量のキャッシュ(L2ないしL3)を搭載できるから、1cycleで128bitの処理を行ってもメモリのスループットが問題になることは無い。

ところがCortex-Mの場合は64bitのAXIでInterconnectと接続され、またメモリそのものはSRAMで構成される代わりにバス幅は32bitという事が珍しくない。命令キャッシュは小容量搭載することもあるが、データキャッシュは普通搭載されない(その代わりTCMが利用される)というわけで、スループットはSRAMなりTCMの帯域に事実上合わせる事になる。これがCortex-M7クラスのハイエンドならば64bit幅も現実的だろうが、Cortex-M0～M3クラスだとまぁ32bitということになる。このあたりは、ArmのIPそのものでは決められず、ArmのIPを購入したMCUベンダーがどう構成するかで決まる事になる。

(次回は2月21日に掲載します)