HeliumではBeat(32bit単位の塊:128bitレジスタは、なので4つのBeatから構成される)を毎cycleあたり「最大4つ」まで処理可能になっている。

  • Heliumのレジスタ構成

    Photo02:レジスタ構成

「最大」というのは実装のオプションがおそらく複数用意されるためだろう。Cortex-M7クラスのMCU IPであれば4つの32bit MACを実装可能だが、Cortex-M3/M4クラスだとせいぜい2つ、Cortex-M0クラスだと1つが手一杯と思われるためだ。ここでMACが2つの場合と1つの場合でどう実行されるのか？ という図がこちら(Photo03、04)。

  • Arm Helium

    Photo03:もっともこれを実行するためにはMACユニットだけでなく64bit分のMemory Busも必要になる訳で、実際の実装としてはTCMだけ64bit幅にしておき、SRAMは32bit幅という使い方かなという気もする

  • Arm Helium

    Photo04:この実装が一番多い気がするのだが、これだとCortex-M4のDSP Extensionと理論性能は同じである。ただCortex-M0～M3やCortex-M23にはDSP Extensionが無かったから、もしローエンド製品からこれが利用できれば随分性能の底上げになりそうな気がする

VLDRがVector Load、VMLAがVector MACの意味であるが、32bit MACを2つ搭載していればPhoto03の様に1cycleあたり2Beat単位での処理が可能で、かつVLDRとVMLAをオーバーラップさせて実行することで切れ目なくVLDRとVMLAを実行できる。

これが1つしかMACユニットが無い場合、Photo04の様に1cycleあたり1 Beatでの実行となるが、やはりVLDRとVMLAをオーバーラップさせることで効率よく処理が行えるという訳だ。ここでHeliumの由来であるが、Photo03のケース(つまりCortex-M3/M4レンジのMCU)では、従来比で2倍のデータパス(メモリバス)で4倍の性能を実現できるから、ということで、原子番号が2、原子量が4のHeliumがブランド名になったそうだ(*1)。

(*1)：従来ではVector LoadとVector MACに相当する命令をOverlapして実行できなかったため、Load→Executeを2サイクルごとに繰り返す形になるわけで、これに比べるとPhoto03は4倍の処理性能、という訳だ。

実際にはここでサイズ変更(例えば16bit演算の結果を32bitにして格納する)とかの問題もあるし、また128bitのレジスタの内容を通常のレジスタにコピーする際のLatency(物理的にVector Unit内のVector Registerと通常のRegister Fileの場所が離れているから、単純なコピーは時間と消費電力の無駄になる)などの問題もあり、こうした事に対する工夫も用意されている。ちなみにHeliumというかMVEでは150以上(*2)のScalarおよびVector命令が新たに追加されることになる。

(*2)：Reference Manualによれば、Vectorで始まる命令はVADDからVSUBまで189個あるが、中にはVSUBみたいに3種類(Vector Fixed Point、Vector Floating Point、Floating Point)定義されているものもあるので、こうした重複を抜くと150あまりになる。

この中にはInterleave/De-Interleave Load/StoreやVector Gather Load/Vector Scatter Store、Integer/Floatの変換、Lane Predicting、Big Integerなども含まれている。ArmとしてはこのHeliumを、オーディオ処理とか音声認識、通信、静止画のイメージ処理(さすがに動画は無理だと分かっている様だ)などさまざまな分野に応用可能としている。

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