CCIX

そのような背景があって、2016年5月にCCIX Consortiumが設立された形だ。この設立直後に行われたXilinxの記者説明会でCCIXの概略が紹介されているが、まだこの段階ではあまり細かい話は出ていない。ただ、2018年のXDFのセッションでは色々細かな話が出てきて、概略はこれで理解できるかと思うが、もっと細かい資料がその後色々出てきたので、もう少し細かく紹介したい。

まずCCIXの実装であるが、PCI Expressの上にCache Coherency Protocolが載る形だ(Photo02)。ただPCIeそのままだと、Processor Memory Direct AccessもCache Coherencyもサポートされない(いやアプリケーション層でこれをサポートすれば可能だが、オーバーヘッドが大きすぎる)。そこでCCIXではPCIeのPHY層とDataLink層はそのまま流用(厳密には若干変更はある)し、その上にCCIXのProtocol Stackを載せる形になっている(Photo02)。

  • CCIX

    Photo02:その意味では、PCIeの上に載る、というよりはPCIeの下位層を流用している、という方が正確かもしれない

Cache CoherencyはProtocol Layerでサポートされる(Photo03)が、ここでの役割を今回はちゃんと書くと

  • Request Agent:システム内の異なるアドレスに対してRead/WriteのTransactionを行うが、この際にそのAccessしたアドレスをCache可能である。Request Agentは1つのCCIXシステム内に複数動作し、それぞれのAgentは処理機能(メモリやI/Oアクセスの機能)を1つ以上保持することが出来る。基本的にはRequest Agentがキャッシュの一貫性を保持するため、プログラマからは見えない。
  • Home Agent:CCIXで利用可能なメモリについて、CoherencyおよびMemory Accessの管理を行う。Cache Line内の状態を変更する必要がある場合、Home Agentから該当するRequest AgentにSnoop Transcationを送信することで、Coherencyを管理する。
  • Slave Agent:CCIXではAcceleratorや周辺機器などに搭載されているメモリを、システム側のメモリの一部として扱う事が出来る。この場合、Home Agentは自分自身のメモリ(つまりHost側のメモリ)しか管理しないため、Acceleratorなどに搭載されたローカルメモリを管理するのがSlave Agentである。Slave AgentはHome Agentとだけ、通信を行う。
  • Error Agent:Protocol Error Messageのハンドリングを行う。このError MessageはすべてのCCIXコンポーネントから送られる可能性がある。

といった具合である。

  • CCIX

    Photo03:このスライドも以前掲載したものである

ちなみにそのCCIX(というかProtocol Layer)でサポートされるCache Coherencyの状態がこちら(Photo04)。元々の発想が、ArmなどのSoCを利用しているベンダーの意向が強い事もあってか、AMBA CHIにかなり近い。

  • CCIX

    Photo04:Unique Dirty Partialがちょっと面白い

Cache Coherencyはそんな訳でCCIXのProtocol Layerで実装されるが、ではProcessor Memory Direct Accessは? というと、やはりPCI ExpressのATSを利用して実装される(Photo05)。このあたりはExoskeletonにちょっと似ている。ただExoskeletonは、コードの書き方にかなり制約があった(というか、OpenMPを使って何とかしようとしていたので、OpenMPを利用する必要があった)のに対し、CCIXではATCさえきちんと見ていれば、それ以上はあまり考えずにコードを書けるので、大分楽になったと言える。

  • CCIX

    Photo05:Host側のMMUのうち、各Acceleratorがアクセスする範囲はAccelerator側(のPCIe)のATC(Address Translation Cache)にコピーされる形

ところでこれ(Photo06)はXDFでも出てきたスライドであるが、問題はこれをどうルーティングするかである。

  • CCIX

    Photo06:まぁArmなどはSoC同士の接続に使うといったケースも想定しているため、単純なAcceleratorの接続だけでは不十分なのは明らかで、逆にこの辺はアプリケーション依存にしてしまっても問題ないと判断されたのかもしれない

これについてはArm TechConの際にCCIXのブースで聞いてきた。結論から言えば「CCIXにルーティングメカニズムは含まれない」のだそうである。だから、例えばCCIXのSwitchとか、CCIXを利用してのAcceleratorの相互接続などに関しては、SwitchなりAcceleratorなりがProtocol Layerのさらに上位層で自分で管理する、という形になるそうだ。

ついでにソフトウェアに関してもちょっと補足しておく。CCIXはDriverless Model(つまりAcceleratorのMemoryとProcessor Memoryが、アプリケーションから見ると等価にアクセスできるので、特にDriverが必要ない)を目指しているという話はこちらに書いた通りだが、OSカーネルに若干の追加が必要(Photo07)である。

このCCIX Extensionが最小限必要であり、これが利用できるとCCIXでNUMAが可能になる(Photo08)。

  • CCIX

    Photo08:もちろんNUMAでなくUMAにすることも可能

ただAcceleratorを使う場合には、単にMemoryのRead/Writeだけでは不十分(少なくとも同期を取るメカニズムが無いと、ProcessorがPollingでAcceleratorの状態を常に確認する必要があり、あまり賢明ではない)であり、そうした場合にはVF(Virtual Function)を利用する形になるとの話であった(Photo09)。

  • CCIX

    Photo09:Hypervisorの存在が前提になっているのがちょっと興味深いところ

それとPhoto07に出てきた"Discovery and initialization"と"RAS and error handling"の実装概念図がこちら(Photo10,11)。

  • CCIX

    Photo10:PCIeとCCIXが混載する事を前提に、それぞれのデバイスの発見と初期化をOS起動前(=UEFIの管理下の段階)で行わないといけない

  • CCIX

    Photo11:ACPIはCCIXの事を何も知らないという前提で、対応できるように工夫されているのが判る

ちなみにPhoto10はあくまで「1つの」CCIX Hostに複数のDevice/Acceleratorがぶら下がっている場合の話で、Photo06の様に1つのDevice/Acceleratorが複数のCCIXポートを持っている様なケースではまた話が変わってくる。

あと、SC17では25Gbps、SC18では56Gbpsのデモが行われた(Photo12)が、25Gpsはともかく(こちらは正式な仕様である)56Gbpsは単にTechnology Demoであって、PHYレベルの動作を行っただけという話であった。

  • CCIX

    Photo12:CCIX 2.0はターゲットが56GT/sec以上となっているが、別にこれは100G EthernetのPHYをそのまま使うという意味ではなく、100G Ethernet用PHYの技術を利用できる、という意味合いだそうだ

(次回は6月4日の掲載予定です)