Xilinxが7nm製品の詳細の一部をHot Chips 30で公開

2018年3月、Xilinxは7nmプロセスを用いて製造予定の新世代製品である「Project Everest」について、そのさわりだけを公開したが、2018年8月19日~21日に掛けて開催された「Hot Chips 30」(https://news.mynavi.jp/article/20180605-641780/)でこのProject Everestの詳細の一端が公開されたので、それを元に、読み解いていきたい。

ちなみにHot Chips 30での発表者はJuanjo Noguera博士であるが、博士の肩書は自身のLinkedInのProfileなどを見るとSenior Staff Research Engineer, Research Labsであるが、XilinxのリリースによればEngineering director, Xilinx Architecture Groupとなっている。

Project Everestの概要

さてProject Everest、実際には「ACAP(Adaptive Compute Acceleration Platform)」という名称で説明されているが、その概略については以前の記事を参照していただければと思う。

ただこの時点では、「HW/SWプログラマブルエンジン"の中身がまったく説明されなかった。まずその概略であるが、構成は先に書いた通りFPGAファブリックとProgrammable Engine、Processor Subsystem(+メモリ)、それとI/Oということになる。ただこのACAP、Machine Learningで20倍、5G基地局で4倍の性能を現行製品に比べて発揮し、しかも消費電力は40%低いとする(Photo01)。この概略図をもう少しブレークダウンしたのがこちら(Photo02)。S/W Programmable Engineとは実際には複数のSW Processor Elementの集合体だと判る 

  • 16nm製品との性能比較

    Photo01:これだけ見るとPSがI/Oと直結していないとか、いつの間にかH/Wの文言が消えてただのS/W Programmable Engineになっているとか色々不思議なところはあるが、高レベルの概略図ゆえの話であろう。ちなみに比較は現行の16nmプロセスを使ったVirtex UltraScale+あるいはZynq UltraScale+ MPSoCとなっている (出典:このレポートの図は、特に断りがないものについてはHot Chips 30における同社の発表資料のコピー)

  • Everestのブロックダイアグラム

    Photo02:ちなみに説明の中では、すべてのブロックがすべてのACAP製品に搭載されているわけではなく、またSW PEもScaleする(つまり6個というのは単なる説明の都合)という話であった。また現時点ではProcessing SystemのOn Chip Memoryの詳細は不明。TCMの類だろうか?

Everestがターゲットとする機械学習と5G

さて、このSW Programmable EngineはDomain Specificだとされるわけだが、そのDomainとして何を考えているのか? 1つ目がMachine Learningである(Photo03)。Machine Learningの計算量の多さは、主に膨大な層のNetworkに対するConvolutionとPooling、Non-Linearityに起因するもので、これを専用プロセッサで処理することで負荷を大幅に軽減できるとする。

  • データセンターのトレンド

    Photo03:さまざまなアプリケーションへのMachine Learningが検討されているが、精度を高めるためには計算量の増加は避けて通れない

  • 機械学習に求められるヘテロジニアス

    Photo04:要するにMLというかDNNの処理(と、一部アプリケーション)を全部、S/W Programmable Engineにオフロードさせようという発想である

もう1つのDomainが5Gである(Photo05)。単にデータレートだけではなくLatency低減や高速ハンドオーバー、1つの基地局の収容する端末数などすべてが4Gから大幅な拡張を施されており、難易度は4Gの際の100倍に達する、とされる(Photo05)。

  • 5Gの技術要求トレンド

    Photo05:一番厄介なのは、いまだに標準規格が進化し続けている("5G still evolving standard")事だろうか。だからFixed Functionとして実装できないことになる。これはMLというかDNNでも同じ話となる

ではこれをどうインプリメントできるのか? というのがPhoto06。DPD(Digital Pre-Distortion)のUpdateはプロセッサ側で処理するとして、DPDそのものとCPRIへのI/F(DUC:Digital Upling Conversion)をS/W Programmable Engineで、Digital RadioとADC/DACのAMS(Analog Mixed Signal)をI/Oでそれぞれ分散させるという形だ。ちなみに現行のUltraScale+ MPSoCを使って同じブロックを構成した例がPhoto07で、AMSがI/O Blockなのは同じとして、DPDはSoft I/Pの形でFPGAファブリックで実装されている。これをオフロードする形だ。

  • alt属性はこちら

    Photo06:これは上り方向の回路で、実際には下り方向むけにDDCを搭載したブロックが別に必要になる筈だが、このあたりは説明のために省いたと思われる

  • DPD SWの動作原理

    Photo07:実際にはCPU #1がDPD SWを動かしており、ここでDPD Updateの計算などが行われるものと思われる (この資料の出典は[「コチラ」]

Processor Elementの内部を読み解く

さて、それではそのS/W Programmable Engineを構成するProcessor Elementの内部はどんな形なのか? というのがこちら(Photo08)である。

  • タイルベースのVector Processorのマルチコア構成を採用

    Photo08:タイルベースのVector Processorのマルチコアという、ある意味Special Processorでは基本の様な構成。各PEは通信と計算を同時に行える、という話だった

何というか良くありがちな構成ではあるのだが、面白いのはInterconnectを構成するRouterとは別に、Processor Elementそのものが相互接続されているという形はちょっと面白い。この直結がLocal Interconnect、Router経由がGlobal Interconnectと考えると、このあたりはFPGAの基本構成をそのまま踏襲している感じもある(Photo09)。

  • Everestのタイルベースアーキテクチャ

    Photo09:ただ赤はBi-Directional Signalingなのに、緑はUni Directional Singnalingというのが気になる部分

これを利用して、Simple PipelineやGraph、Multicastingなどさまざまな接続形態が可能とされる(Photo10)。FPGA Fabricとの接続は、途中にCDC(Clock-Domain Crossing)というユニットを介することで可能であり(Photo11)、また外部のAcceleratorあるいはオンチップメモリへの接続も可能だそうだ(Photo12)。

  • データ移動の概要

    Photo10:Feedback(戻る方向)のPathも同様に組めるのかは不明。またいわゆるBroadcasting(すべてのPEへのMulticast)が可能なのかも不明。Router経由でならBroadcastが可能な気はするが

  • デバイスへの搭載イメージ

    Photo11:CDDはいわばMailboxみたいなイメージになるのではないかと思われる。FPGA FabricとS/W Programmable Engineの間は、最大でTB/secの帯域が確保されるそうである

  • プログラマブルロジックの構築方法

    Photo12:そのPL AcceleratorはFPGA Fabric側で構築することになるとか。Custom On-chip Memoryの方は、Photo02でいうところのOCMに加えてFPGA Fabric側のBRAM/URAMも利用できるようだ

さて、肝心のVector Processorがどんなものか? という説明は今回はなし。またPhoto08でいうところのML Vector Extensions/5G Wireless Vector Extensionsについても説明はない。とりあえず説明の中では、キャッシュは持たないという話であり、Local MemoryがTCMのような形で動作するのだと思われる。

また複数のサイズのFloating Pointをサポートする(Fixed Pointではない)という話ではあったが、それ以上の話は公開されなかった。その代わりといっては何だが、開発環境についての説明があった。基本的にPSとS/W Processor Engine、FPGA Fabricの3つをまとめて高レベルのC/C++で記述する事も可能だし、そこからもう一段下の、直接S/W Processor Engineに対してのプログラミングも可能とされる(Photo13)。また統合開発環境とライブラリ、ランタイムが提供されるとのことである(Photo14)。

  • Everestのプログラミング環境

    Photo13:はっきりとは確認できなかったが、おそらくS/W Programmable Engineを直接触る場合もC/C++でのプログラミングになる模様。ちなみにVector Compilerが提供されるのか? という質問に対して「そうではなく、別の方法を考えている」という返事があった

  • Everest向けのソフトウェア開発環境の概要

    Photo14:もちろんこれはS/W Programmable Engineに対してという話で、Processor Subsystem(やFPGA Fabric)向けにはそれぞれ別のToolchainやLibrary、Runtimeが提供されることになるだろう

また、特にMachine Learningについては既存のフレームワークをシームレスにサポートする、としている(Photo15)。このライブラリ類を利用した場合、MLや5Gなどで高い性能を実現できる、という話であった(Photo16 )

  • EverestだけでなくUltraScale+製品も同様にサポート

    Photo15:EverestだけでなくUltraScale+製品も同様にサポートするというあたり、ML Compilerの中で何かしらをやっているのだと思われる。サポートするフレームワークが全部で幾つあるのか、などは今回は公表されなかった

  • カーネルレベルのパフォーマンス

    Photo16:ML ConvolutionsとFFTはML Library(というか、BLAS)を利用した場合、DPDはWireless 4G/5G Libraryを利用した場合の結果であろう

現時点での説明はこの程度で、一番肝心な部分が抜けている感もあるが、1つ推察すると3月の説明で内部接続がNoC(Network on Chip)になっていたのは、おそらくS/W Programmable EngineのPE同士の事を指しているのではないかと思われる。ただそうだとしても、まだ全貌は見えていないというところだ。Photo01の一番下にあるように、この製品は今年後半にTape Outという話で、早ければ来年の6月位にはFirst SiliconのαSamplingが始まるだろう。

なお、Xilinxは2018年10月にプライベートカンファレンス「XDF(Xilinx Developer Forum)」をサンノゼ・北京・フランクフルトで開催予定である。ここでもう少し細かい話が出てくることを期待したい。