FPGA開発日記

FPGAというより、コンピュータアーキテクチャかもね! カテゴリ別記事インデックス https://sites.google.com/site/fpgadevelopindex/

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

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

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

TileLink 0.3.3 Specification

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

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

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

TileLinkの接続イメージ

以下は上記解説サイトからの引用。この程度しかイラストが用意されていないんだよなあ。

f:id:msyksphinz:20170713020608p:plain

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

イントロダクション

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

TileLinkアーキテクチャ

エージェント

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

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

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

チャネル

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

  • Acquire: キャッシュブロックにアクセスする許可を得るためにトランザクションを開始する。キャッシュすること無しにデータを書き込むのにも利用される。
  • Probe: クライアントに対してキャッシュブロックを保持しているか問い合わせる、もしくはキャッシュブロックのパーミッションを取り消す。
  • Release: Probeの返信のAcknowledgementである。ダーティーデータに対するパーミッションをリリースする。データのライトバックを自発的に実行するのにも利用される。
  • Grant: リクエストもとに対して正常なデータもしくはパーミッションを渡し、キャッシュブロックにアクセスする。自発的なリリース処理のAcknowledgeにも利用される。
  • Finish: リクエストもとからの最終的なトランザクション完了に利用される。

これらのチャネルはクライアントからマネージャ、マネージャからクライアントへと接続される。クライアントからクライアントへは接続されない。 パーミッションは「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を返信することができない。

チャネル信号について

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