期待のネット新技術
UALinkのレイヤー構造と、「Flit」単位の通信によるMemory Semantics
Scale-up Network（5）
2026年11月4日 06:00
引き続きScale-upの話。今回はUALinkをもう少し細かく見ていく。
前回も触れたが、UALinkは複数のSpecificationを既にリリースしている。前回は5つご紹介したが、これに加えてUALink 200G Data Link and Physical Layers 2.0 Specificationも公開になって、現状は6つのSpecificationがリリースされている状況だ。
この中で一番最初にリリースされたのが、UALink 200G 1.0 Specificationなので、まずはここから仕様の主要なポイントをPickupして紹介したい。
UALinkの目的は、「Acceleratorのローカルメモリ」をリモートから参照することである（図01）、もちろん、メモリではなくAccelerator同士の通信に使うことも可能ではあるが、基本はメモリ上のデータ交換を主眼としている。図02はPeer-to-Peerで、実際台数が少なければそれでも構わないのだが、UALinkは最大1024台のAcceleratorを相互接続可能としており、しかもAccelerator同士がどう接続されるか（というか、どう他のAcceleratorのメモリをアクセスするか）は当然ながらアプリケーションによって変わるので、UALinkの側で規定することはできない。
そこでM:Nの接続形態を許す形で、あとはAcceleratorとSwitchのインプリメント次第、という形にしている。一応上限はAcceleratorの数も、Switchのポート数も1024が上限となる形で、必然的に1個のAcceleratorから出るUALinkのポート数も1024が上限となるが、SwitchはともかくAcceleratorからこんなにUALinkのポートを出すのは物理的に無理であり、もっと少ないポート数に収まることになるだろう。要するにDirect ConnectedとSwitch Connectedという2種類の接続形態をサポートする形だ。
UALinkのStack構造が図03だ。Acceleratorの内部からUALink I/Fと接続する部分がUPLI（UALink Protocol Level Interface）となり、その下にTransport、Datalink、PHYの3つのLayerが重なる形になる。
ただ、このうちPHYに関しては、IEEE 802.3dj（この原稿の執筆時点ではDraft 3.3が出ているはずで、更にDraft 3.4を挟んで年内に標準化が完了する予定である。既にSA Ballotに入っているので、ここから大きくズレることはないだろう）の200G serialをサポートするという仕様になっている（厳密には少しだけ変更があるが、これは後述）。なのでUALinkをUALinkたらしめているのは、Transaction及びData Linkの2つのLayerということになる。
UPLI：5種類のRequestのみ動作するシンプルなInterface
まずはUPLIについて。つまりTransport Layerの上位層というかAcceleratorとのAPIであるが、これは非常にシンプルである（図04）。
Originatorは例えば「このアドレスのデータを転送せよ」とリクエストを出し、それに応じてCompleterがそのデータを送り出す、以上終わりである。Requestとして定義されているのはRead・Write・Atomic・UPLI Write Message・Vendor Defined Commandの5種類。Flow ControlはCreditベースで実装されており、もうNetworkというよりもRemote Memory Access的な扱いになっている。
それもあって、UALinkを他のNetworkと比較して論じる場合、Memory Semanticsという表現が使われることが非常に多い。実際に実装を考えた場合、メモリアドレスの一部が（それが動的か静的かはともかく）拡張され、そこにアクセスするとローカルのMemory ControllerではなくUALinkのUPLIを叩くというような実装が一番スムーズだし、実際Specificationもこうした使い方を想定しているように思われる（図05）。
ここでAcceleratorのCU（Compute Unit）はそれぞれのProcessのVA（Virtual Address）を利用して処理を行うが、ACC MMU（AcceleratorのMMU）で、これがPhysical Addressに変換される。この際にローカルのMemory ControllerはSPA（System Physical Address）、リモートはNPA（Network Physical Address）にそれぞれ割り当てられる格好だ。
NPAは下位42bitがメモリアドレス、上位10bitがAcceleratorの番号になっており、これが最大1024個までしかAcceleratorを接続できない理由となっている。話を戻すと、そんなわけで各CU上で動くProcessから見ると、ローカルもリモートも区別せずに使えるのがUALinkというわけだ。
Transaction Layer：データを64BytesのFlitにまとめる
さて、そのUPLIのI/Fの下に位置するのがTransaction Layerである。UPLIのAPIレベルではデータの長さなどはまちまちだが、これをTransaction Layerでは64BytesのFlitにする。ここで言うFlitはFlow Controlの方のFlitではなく、パケットの長さの単位の方である。
Flitは複数のリクエストやアドレス、データなどをまとめて64Bytes化し、またこれを元に戻す仕組みとなっている。ちなみに64BytesのFlit以外に、32BytesのHalf Flitも定義されている。また、データとかアドレスの指定はどうしようも無いが、コマンドに関しては圧縮／伸張の仕組みも入っており、Flit（これはTransaction LayerのFlitなのでTL Flitと称される）の利用効率向上が図られている。
Data Link Layer：TL Flitを約640BytesのFlitにまとめ、帯域を効率化する
その下にData Link Layerが来るわけだが（図07）、こちらでは64Bytes単位になっているTL Flitを「大体10個分」まとめ、640Bytes単位でのFlit（これをData Link FlitということでDL Flitと呼ぶ）にまとめている。
640Bytes単位というのは、帯域の効率化のためである。そもそも800GbpsのLinkの場合、640Bytesの転送に必要な時間は6.4nsでしかない。これでも十分短いわけだが、これを元のTL Flitのままにすると0.64nsまで短くなる。要するにデータ転送の時間が短すぎてむしろProtocol Overheadの方が大きくなりかねない。転送効率を上げるために、この位パケットサイズを大きくするのが効果的と判断したようだ。
もう1つ理由を挙げると、Physical LayerはIEEE 802.3djを利用するが、ここでRSはRS（544,514）を利用しており、これと640Bytesのパケットの相性が良いし、FlitのReplay（再送）の頻度も最小限に抑えられている、と説明されている。
ちなみに、厳密に言うと、このDL Flitは5つのSegment（SH0～4）に分けられ、SH0～2はそれぞれ128BytesだがSH3は124Bytes、SH4は120Bytesである。ではSH3とSH4の残りは？ という話だが、これはFlit Header（3Bytes）とCRC（4Bytes）、それとSH0～4にそれぞれSegment Header（1Byte）が入るので、データとしては628Bytesを占めている。先に「大体10個分」と書いたのは、厳密には10個に微妙に満たない（9.8個分）ためだが、この辺のAlignmentはData Link層で取るのでTransaction層にはきちんと64Bytesパケットの形で渡されることになる。
Physical Layer：IEEE 802.3djのPCSに接続しつつ、Latencyを削減
最後がPhysical Layerである。先に「IEEE 802.3djの200G serialをサポート」と書いたが、どこで接続されるのか？ というとPCSで接続される形になる（図08）。ただ、ここで幾つか変更があり、次の3つの要件が示されている。
- Alignment Markerの周波数はRSで決定され、通常のLane deskewやLane reorderとしての用途以外にFlitをRS（544,514）を使った680Byte CodewordにAlignmentするためにも利用される
- Latency削減のために、CodewordのInterleaveを削減する
- Decode/Encodeは行わず、PCSのI/Fは64b/66b encodeで利用される
ちなみに3.に関しては、外部にRS⇔PCS間のI/Fを公開しないのであれば、MDIの先の信号の挙動が同一（例えば、1つのCodewordに1つのDL Flitが含まれ、Alignment Markerを含むCodewordが規定通りとなっている）であれば、必ずしも64b/66bである必要はないとされている。またIEEE 802.3djは1レーンあたり200Gbpsの仕様であるが、Ethernetの場合はBackward Compatibleが保たれるのが普通である。その辺もあってか1レーンあたり100Gbpsの、つまりIEEE 802.3ck-2022で定められた仕様もサポートすることが必須となっている。
というあたりがUALink 200G 1.0の仕様の簡単なまとめとなる。Specificationの方には性能目標が示されていないが、White Paperによれば、Req-to-Resp RTT（Request to Response Round Trip Time）が1μs未満であることが目標とされている。実のところRS（514,544）を使った時点で、これの処理に100ns程度の時間が必要とされる（しかも送受信で両方）から、RTTが1μsというのはギリギリとは言わないまでも、それほど余裕のある数字ではなさそうである。
UALink 200G 2.0での変更と、PCIeを流用する「UALink 128G」
さて、ここまでの説明はUALink 200G 1.0をベースにしたが、冒頭で説明したように、もう2.0がリリースされた。ただ内容はECN（Engineering Change Notice）とECR（Engineering Change Request）の反映が殆どで、いわゆる機能変更とか機能追加は特に見当たらないようだ。
それともう1つ、UALink 128G Data Link and Physical Layers 1.0 Specificationがある。"Data Link and Physical Layers"と書いてある通り、UPLIやTransaction Layerに関しては変更がないので、Data Link以下のみの規定である。
こちら、TL Flitが64Bytesなのは同じだが、DL Flitは256Bytesになっている。この128Gの場合、物理層はPCI Express 6.4のPL（PHY Logical Layer）を流用する形になっており、またPCI ExpressのFlit Modeのみのサポートとなっている。レーン数は8本で、1x8/2x4/4x2の3種類の構成が選べるが、動的な変更はできない。転送速度は2.5GT/sec～128GT/secまでサポートされるが、128GT/sec以外に104GT/sec, 112GT/sec, 120GT/secでの動作も許すことになっている。128GT/secで8bitだから、転送速度は128GB/secになるというわけだ。
ちなみにUALink 128Gに関しては、ULSに関しての言及が一切ない。技術的には可能であろうが、そもそもPCIe Laneを使う時点でSwitchを挟まずにPeer-to-Peerで繋ぐのが暗黙の前提ということなのかもしれない（ユースケース的にもSwitchを挟むシーンが考えにくい、ということもあるが）。