Versalの概要は既報のとおりだが、この際にはAI Engineの詳細は一切明らかにされなかった。

また、基調講演の後で話を聞いたLiam Madden氏(EVP, Hardware and Systems Product Development)も「いや私もあまり技術的に深いことは判らないんだが、Static Schedulingだ」ということで、このあたりが謎のままであったのだが、基調講演にあわせて公開された同社のホワイトペーパーでこのあたりがもう少し明らかにされたので、この内容を基にご紹介したいと思う。

Hot Chipsでは"S/W Programmable Engine"とされていたユニットは、現在はAI Engineに名前が統一されている(Photo01)。

  • AIエンジンの概要

    Photo01:左がCortex-A72とCortex-R5のScalar Engine、中央下がFPGA Fabric、右がI/OとMemory/PCIe(/CCIX)で、中央上がS/W Programmable EngineことAI Engine Arrayである

といっても基本的には名前の変更だけで、構成そのものには違いはない。Array、としているものの実際はTile、と称したほうが正確な気がする(Photo02)。

  • AIエンジンの概要

    Photo02:Hot Chipの記事ではPathが双方向のものと単方向のものが混じっていて「？」だったが、こちらで見るとすでてのPathが双方向になっており、単にHotChipsでの説明が不正確だった(というか、関係ない要素を省いた)ものと思われる

構造図を見ると、厳密には2つのTileで一組になって、それが上下左右に敷き詰められている感じだ。

さてそのTileの内部がPhoto03となる。

  • AIエンジンの概要

    Photo03:Stall Handlerが別にあるのはPhoto05の説明にて。興味あるのは、Accumulator Stream FIFOが別に用意されていることで、これは複数のTileをつないでSIMD演算をStream的に流す事に対応しているものと思われる

32bitのScalar RISCエンジンとFixed/Floatの512bit SID Engine、Vector Register File、Load/Store Unitなどを組み合わせたProcessor Complexと、32KBのData MemoryからなるMemory Complexから構成される形だ。

この2つのComplexとAXIの2次元Meshが組み合わされているという、かなり重厚な構成である。気になるのはData Memoryがたったの32KBしかないことである。もちろんSIMDエンジンをフルに回してもCycleあたり512bit＝64Bytesだから、最大512回分(Y＝A×X＋B、でXとYを両方Data Memoryに格納すると仮定すると256回分)のデータを格納できることになるが、それにしても全体的にちょっと少ない感じは否めない。

まぁ、このTileが数十から数百集積されれば、AI Engine全体では数MBのサイズ(300個ほど集積すれば10MB近くにはなる)になるし、必要なら外部のDDR4とかFPGA Fabricの中のUltraRAMを利用する事もできるから、利用できるメモリ量はもっと多くなるのだが、Versalと同じようにAI推論専用として開発されたArm MLプロセッサはCompute Engineあたり1MBのSRAMを搭載することを考えるとちょっと不足気味に見える。

ちなみにInstruction Memoryの方は自身のProcessor Complex専用(ここに書き込みできるのはInstruction Fetch&Decode Unitのみ)となっている。

また、Fixed/Floatの512bit SIMDの動作がPhoto04だ。

  • AIエンジンの概要

    Photo04:8bit Real×8bit Real、それとSPFPの場合を除くと、出力は48bitないし80bitになっているあたりも面白い。普通のSIMDエンジンとはちょっと様相が異なっている。512bit SIMDとは掛かれているが、これはプログラマから見た場合の話であって、ハードウェア的な実装は16/32bitあたりのエンジンがN倍速動作しているのかもしれない

RealがFixed Pointを使った整数演算、ComplexがFixed Pointを使った小数点演算、SPFPがFloating Point側を使った浮動小数点演算となっている。1cycleで乗算と加算を可能にしているようで、この結果8it Realで128MACs/cycleというのは、乗算と加算を64回ずつ1cycleで行っているという話と考えられる。

またFixed Pointは1cycleで乗算も加算も完了するようだが、Floating Pointではデータ幅を考えれば32 MACs/cycleで処理できても不思議ではないが、これが8 MACs/cycleになっているというのは、スループットが4cycle必要という計算になる。もっともAIの推論に関して言えば32bitのFloating Pointの性能はそもそも不要であり、ここはパイプライン化さえされていれば、1cycleで処理が終わる必要は無く、むしろ回路規模を小さくまとめることでAI Engine Tileのエリアサイズを削減し、タイルの数を増やすことを優先した可能性もある。

ところで以前のVersalの記事に、AI Engineは1GHz超のVLIW/SIMD Vector Processor Coreだと説明があるが、その意味を示したのがPhoto05となる。

  • VLIWの命令セット

    Photo05:こうなってくると、Scalar Processorにどんな処理が入っているのかも気になるところ。フォーマットはVILWながら、普通のVLIWとはやや異なっている気もする

要するにScalar 2命令、Fixed PointないしFloatingのSIMDエンジン命令、それとLoad×2、Store×1の6命令がVLIW構成となっている形だ。

Photo03のInstruction Fetch&Decode UnitにはこのVLIW命令が渡され、これがデコード後にそれぞれのユニットに渡され、処理が並行して行われる形になる。

Madden氏が「Static Schedulingだ」としたのは、Scalar RISC UnitもSIMD Vecto UnitもLoad/Store UnitもすべてIn-Orderの処理(32bit Scalar RISCが2-way In-Orderなのか、それとも1-way In-Order×2なのかは不明だが、おそらくは2-way In-Orderだろうと思われる)で、VILW命令によって実行スケジュールが決まる形になっている(個々のEngineの中でスケジューリングなどは行わない)事を指していると思われる。

Stall HandlerがScalar RISC UnitあるいはVector Unitと別に設けられているのも当然で、ここはVLIW命令に対するStallのHandlingが必要となるためだ。要するにPhoto03の緑色の部分全体で1つのVILWプロセッサを構成しており、その中にSIMD Vector Engineも含まれている、という格好である。

次にこれらをつなぐインターコネクトであるが、これは上下(North-South)と左右(West-East)の2本のAXIのラインがあり、この交点にクロスバーが配され、さらにこのクロスバーにAXI-MM(Memory Mapper)がつながり、このMemory Mapper経由でProcessor/Memory Complexとつながる形になる(Photo06)。

  • インターコネクトの概要

    Photo06:North/South/West/Eastはそれぞれが隣接するインターコネクトとのポートとなる模様。遅延を入れるためにFIFOが用意されている、というのがとてもFPGA的である

興味深いのは、このクロスバーの構成とかPort Mapperは静的に構成されることだ。つまり動作に応じてマッピングや構成を変えることは原則想定していない。これは非常にFPGA的な発想であって、それぞれのAI Engine Tileはプログラムがロードされるとずっと同じ処理をひたすら繰り返し、そのEngine Tile間の接続もロード時に構成が決まるという動き方を想定している様だ。そういう意味では、Verilog VHDLを使わずにC/C++で記述できる&LUTよりも機能は一杯あるものの、使い方は限りなくFPGA Fabricに近い構成になっていると考えるのが正解だろう。

そのFPGA Fabricとの接続方法がPhoto07だ。

  • FPGA Fabricとの接続方法

    Photo07:PL(Programmable Logic)はFPGA Fabricとの接続だが、それとは別にCortex-A72/Cortex-R5やDDR4/HBM、I/Oなどとの接続用にNoCとのI/Fも用意されている

Hot ChipsではCDC(Clock Domain Crossing)ユニットを介してつながると説明されていたが、実際にはPLとNoCの2種類のI/Fに対してAXI-S Switch経由でつながる格好となっている。

こうしたAI Engineを搭載する理由についてXilinxは

  • 同じプロセスノードでAI Engineと同じ機能をFPGA Fabricで実装した場合に比べ、3～8倍の面積の節約になる
  • 同様に消費電力を半減できる

と説明している。もちろん、これをAI Engineではなく、ハードIPとして提供する事も不可能ではないのだろうが、プログラマビリティを考えるとC/C++で記述できることが重要だ、と判断したようだ。だから、VILWフォーマットで、しかもFixed Schedulingというややエキセントリックな実装になっている訳だが、これはこれで理解できる。

このAI Engineの実装例として、100MHzで5chのLTE20のワイヤレスソリューションを実装した例がPhoto08である。一部の処理はCortex-A72とかFPGA Fabricで行うが、ほとんどの処理はAI Engineで実行できるとしており、この結果がHot Chipsにて提示された「効率98%」になったのだろうと思われる。

  • AIエンジンの概要

    Photo08:Filtering処理のほとんどをVector Engine(おそらくFixed Point側)で処理していると思われる。こうしたストリーム的な処理をさせるには、確かにAI Engineの構成は最適である

AI Engineと名前は付けられているが、例えばArm MLプロセッサなどとは根本的に発想が異なる、アクセラレータというよりはFPGA Fabricの要素の一部と考えたほうが早いような、非常に独特な構成になっているのが判る。ただこれを使いこなすには、単にVILWのコンパイラがあるだけだとちょっと厳しい感じである。また、当然FPGA FabricとかCortex-A/Rプロセッサとの連携も必要になるわけで、このあたりがどういう開発環境でカバーされるのか、非常に興味があるところだ。