CXL (Compute Express Link) その8 - Flit・Slot

私はメモリデバイスの不揮発性メモリ制御やホストIFなどを扱うソフト屋です。
仕事でCXL(Compute Express Link)まわりの技術に関わっています。
CXL技術に関連するメモ書きを残していこうと思います。
ホストのCPUとOS/Applicationまわりの経験・知識共に乏しいので、親切な方は教えて下さると幸いです。
また、間違い、アドバイス、その他、ご意見やご要望ありましたらお気軽にどうぞ。


#1. Flit・Slotとコマンド・レスポンス
以前の記事「CXLその6」でCXLで扱われるFlit・Slotについて、「CXLその7」でCXL.memで使用されるコマンド・レスポンスに触れました。

Flit・Slotに収められたコマンド・レスポンスの例を下図に示します。下図は、ホストCPUから、Type3のCXLデバイスへ送信されるProtocol Flitの例を示しています。
![Flit_example.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2292852/9fe6a55f-676f-68d2-590f-8d87434ba95d.png)
例で示したProtocol FlitのSlotは以下の構成(フォーマット)です。

- Slot0
Flit Header + CXL.mem Request (データの読み出し要求等)

- Slot1
CXL.mem Request + CXL.cache Data Header

- Slot2
CXL.mem Request with Data　(データの書き込み要求等)　+ CXL.cache Response

- Slot3
CXL.mem/CXL.cache Data Chunk (書き込むデータのうちの16B)

Slot1とSlot2には、「CXL.cache Data Header」と「CXL.cache Response」の含まれていますが、Type3のデバイスで使用されないため図中の「Valid」には無効であることを示す"0b"が入ることになります。

Slot3のData Chunkには16Bのデータが含まれています。64Bの書き込みでは、残りの48Bは、以降のFlit内の3つのSlotが使用され送られます。

Slotに収められるコマンド・レスポンスのフォーマットは、CXLの仕様書で規定されています。

#2. Slotのデータフォーマット
Slotに収められるコマンド・レスポンスのフォーマットを下表に示します。
![FlitFormat.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2292852/0ffa3a46-5ec3-441b-07d0-f8b439142304.png)
左側の表はホストCPUからデバイスへ転送されるProtocol Flit内のSlotのフォーマット、右側の表はデバイスからホストCPUへ転送されるProtocol Flit内のSlotのフォーマットを示しています。
H*はFlit Headerが含まれるSlot0のフォーマット、G*はSlot1-Slot3のフォーマットです。

表中の赤字で表記した箇所は、Type3のCXLデバイスに適用されるSlotのフォーマットです。

H6は、CXL2.0から仕様化されたホストCPUとCXLデバイス間で転送されるデータのセキュリティ機能(データの暗号化 + 完全性確認)で使用されるフォーマットです。CXLのセキュリティ機能については、その内に書いていこうと思います。

「1.Flit・Slotとコマンド・レスポンス」で例示したFlitは、ホストCPUからデバイスへ転送されるProtocol Flitなので、左側の表のフォーマットを使っています。
Slot0はH5、Slot1はG4、Slot2はG5、Slot3はG0が対応しています。

#3. Flit Header
Protocol Flitの先頭には、Header Flitがついています。
Flit Headerのフォーマットを下図に示します。
![FlitHeader.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2292852/79bc6ded-aa96-ed8f-be8c-bb1a903897a1.png)
Flit Headerのパラメータを下表に示します。

| Field | Bits | 概要 |
|:--|--:|:--|
| Type | 1 | Flitの種類を示す。<br>0b: Protocol Flit<br>1b: Control Flit   |
| Ak | 1 | Acknowledgement。8 Flitが正常に受信されたことを示す。 |
| BE | 1 | Byte Enable。Data Chunkで送信するデータのうち、有効なデータをバイト単位で通知するための情報を追加して送信することをしめす。  |
| Sz | 1 | Size。送信するデータサイズが32Bであることを示す。<br>※64Bのデータ転送の場合は計4つのSlotをData Chunkとして使用されるが、32Bの場合は計2つのSlotをData Chunkとして使用される。 |
| Slot0 | 3 | Slot0が、いずれのSlot Formatであるかを示す。 |
| Slot1 | 3 | Slot1が、いずれのSlot Formatであるかを示す。 |
| Slot2 | 3 | Slot2が、いずれのSlot Formatであるかを示す。 |
| Slot3 | 3 | Slot3が、いずれのSlot Formatであるかを示す。 |
| Response Credit | 4 | No Data Responseの受信バッファの空き状況を通知する。  |
| Request Credit | 4 | Responseの受信バッファの空き状況を通知する。 |
| Data Credit | 4 | Data Response/Request with Dataの受信バッファの空き状況を通知する。 |

CXL.memのコマンド・リクエストの送信で使用されるのはProtocol FlitであるためType=1となります。Control Flitの説明については、追々書こうと思います。

Acknowledgmentは、8 Flit単位で返されます。Flitの送信側は、Retry Bufferを持ち、Ackが返されるまで、送信済みのFlitを保持することになります。

BEはData Chunkで送信するデータに対して、有効なデータと無効なデータを区別することを示すためのByte Enableを追加で送信することを示します。BE=0の場合は、Data Chunkで送信するデータが有効であることを示します。
CXL2.0の仕様では、読み書きの単位は基本的に64Bですが、64Bよりも小さいデータを扱いたい場合は、BEとSzを使用することになっています。ただ、顧客等の会話を聞くと、BEとSzを使うことは稀なケースだろうということではあります。
Slot0-Slot3で、Flit内のそれぞれのSlotのFormatを示します。

Creditは、Flit送信側が自身の持つ受信バッファの空き状況を通知するためのパラメータです。
ホストCPUとデバイスが持つ受信バッファを下図に示します。
![RxBuffer.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2292852/e21ccc60-1f53-d241-4ad9-7b0f1312b5f2.png)
例えば、ホストCPU側がFlitを送った場合、Flit内で図中の「No Data Response Rx Buffer」と「Data Response Rx Buffer」の空き状況を通知することになります。

空き状況を通知する単位は「Credit」で、Bufferで受け付けられるコマンドの数、もしくはレスポンスの数です。

---
正月休みが間に入ったので前回の記事の投稿から時間が空いてしまいましたが、引き続きCXLに関して記事の投稿をしていきたいと思っています。