RocketChipの足回りを理解する(2. TileLinkについて)

2017/09/05 TileLink Specification Ver.1.7 Draftが公開されていたので、追記しています。

RISC-V実装のRocket-Chipでは、足回りのインタフェースとしてTileLinkというインタフェースを使っている。ところがこれ、どれだけ検索しても詳細が出てこない。TileLinkとは何なのだろう？

資料については、以下のページぐらいしか出てこない。これを読み解くしか、TileLinkの仕様を理解するのは不可能なようだ。

TileLink 0.3.3 Specification

2017/09/05 TileLink Specification Ver.1.7が公開されていた。以下から詳細資料を参照することができる。

www.sifive.com

また、以下の論文も参照されている。

• Manager-Client Pairing: A Framework for Implementing Coherence Hierarchies

http://tinker.cc.gatech.edu/pdfs/MICRO44_Jesse_Beu.pdf

TileLinkの接続イメージ

以下は上記解説サイトからの引用。

大まかにAXIなどのバスネットワークと変わらないと思っている。

(https://www.sifive.com/documentation/tilelink/tilelink-spec/ より引用)

さて、以下は解説文を少しずつ翻訳しながら理解していくことにする。

イントロダクション

TileLinkはオンチップメモリ階層内での特定のキャッシュコヒーレンシポリシを実装したキャッシュコヒーレンストランザクションのために設計されたプロトコルである。

TileLinkアーキテクチャ

TileLinkのレベル

TileLinkは大きく2つのレベルに分けられる。

• TL-UL (TileLink Uncached Lightweight) : シンプルなメモリ読み書き、バースト読み書きはサポートしない。
• TL-UH (TileLink Uncached Heavyweight) : TL-ULに加えて、いくつかのヒントオペレーション、アトミックオペレーションとバーストアクセスなどをサポートする。
• TL-C (TileLink Cached) : TL-UH に加えて、コヒーレントキャッシュのサポートを加えている。

(https://www.sifive.com/documentation/tilelink/tilelink-spec/ より引用)

エージェント

TileLinkはクライアント・マネージャアーキテクチャコヒーレンスプロトコル内に参加しているエージェントは、以下のどちらかである。

• クライアントがキャッシュブロックにリクエストを行う。
• マネージャがキャッシュブロックのパーミッションとデータの伝搬を監視する。

クライアントはキャッシュ、DMAエンジン、もしくはコヒーレントメモリドメインに参加している他のコンポーネントであり、実際にデータをローカルにコピーするかどうに関わらない。 マネージャはアウターレベルのキャッシュコントローラであり、ディレクトリ方式、もしくはバスののようなブロードきゃしゅとメディアである。 マルチレベルのメモリ階層では、特定のキャッシュコントローラはクライアント(階層内のさらに外側のキャッシュ)もしくはマネージャ(プロセッサにより近いキャッシュ)としての機能を持っている。

チャネル

TileLinkの持つ5つの独立したチャネルについて。 これらのチャネルは同一の物理リンクを利用してマルチプレクスをすることができる。 しかしデッドロックを防ぐためにチャネル間で優先度を定められており、これらを厳密に守ることが求められる。 チャネルにはメタデータとデータコンポーネントが含まれている。

• Channel-A : 特定のアドレス領域への操作リクエストを発行する。
• Channel-D : リクエスト元に対するデータの応答を返す。
• Channel-B (TL-C専用) : マスタエージェントによりキャッシュされているアドレスへのリクエストを送信する。キャッシュデータのライトバック操作のリクエストなど。
• Channel-C (TL-C専用) : Channe-Bのリクエストに対する応答データか書き込み応答を返す。
• Channel-E (TL-C専用) : キャッシュブラックなどのブロック転送の最終応答に使用される。

これらのチャネルはクライアントからマネージャ、マネージャからクライアントへと接続される。クライアントからクライアントへは接続されない。 パーミッションは「Finish >> Grant >> Release >> Probe >> Acquire」である。

トランザクションフロー

TileLinkにより管理されるキャッシュブロックには、2タイプのトランザクションが存在する。

タイプ1.

• クライアントがAcquireをマネージャに送信する
• マネージャは必要なProbeをクライアントに送信する。
• マネージャはリリースした全てのProbeに対するReleaseを待つ。
• マネージャは必要ならば後続のメモリにアクセスを行う。
• 必要なデータもしくはパーミッションを手に入れると、オリジナルのリクエストもとに対してGrantを送信する。
• Grantを受信すると、オリジナルのクライアントはマネージャに対してFinishを送信しトランザクションを完了する。

タイプ2.

• クライアントはマネージャに対してリリースを送信し、これが自発的な動作であることを指定する。
• マネージャは必要ならば後続のメモリに対して通信を行う。
• マネージャはGrantを利用して、トランザクションのAcknowledgeを通知する。

並列性

TileLinkha、特定のチャネルのP2P通信に対してオーダリングに対して規定は存在しない。 従って、システム上のエージェントが並列性を保持する必要がある。

• マネージャは既に別のクライアントによってインフライトである場合には(以降に議論するように、2つのトランザクションをどのようにマージするのか方法が分かっている場合を除く)リクエストを許可してはならない。
• クライアントがアウトスタンディングな自発的なトランザクションを持っているならば、ライトバックの完了をAcknowledgeするマネージャからのGrantを受信しないと、Probeリクエストに対するReleaseを返信することができない。

チャネル信号について

物理的なチャネルの詳細は定義しておらず、各チャネルでのトランザクションを伝えるための信号群を定義しておけばよい。

関連記事

• RocketChipの足回りを理解する(2. TileLinkについて)
• TileLinkの仕様まとめ (TL-UL)