RISC-VのOoOコアSonicBOOMのデザインを読み解いている。フロントエンドのパイプライン構成について読み解いていきたい。
SonicBOOMのフェッチ部については大まかに言って3ステージに分かれていると言って良い。
s0：プログラムカウンタから仮想アドレスを命令キャッシュに送り込む。命令キャッシュではそのプログラムカウンタでタグを検索する。その結果はs1ステージで返される。s1：仮想アドレスをTLBに流して検索する。TLBはその仮想プログラムアドレスから物理アドレスを検索する。物理アドレスがヒットすればそのステージのうちに命令キャッシュに渡す。- 物理アドレスがヒットすれば
s1ステージの内に命令キャッシュに送り込み、s1ステージで比較を行い命令キャッシュの物理タグと一致するかを確認する。
- 物理アドレスがヒットすれば
s2：s1ステージにより物理タグがヒットして物理アドレスが確定すれば、そのまま物理アドレスを引いて命令キャッシュを読む。その結果はs2ステージで読みだされる。
ICacheにTileLinkのマスターになりうるDiplomacyノードが生成されており、もしもヒットしなければそのままTileLinkで外部にリクエストが送出される。つまりs2ステージでTileLinkが駆動される。
一方でTLBがミスした場合はどうなるのか。これはDiplomacyを経由して直接渡されるのではなく、一度特殊なBundleを通じてデータキャッシュに対してアービトレーションを出す。これによりTLBへのアクセスはいったんデータキャッシュに格納されることになり、変換テーブル自体もデータキャッシュに置かれることになる。
TLBの概要
TLBは仮想アドレスから物理アドレスに変換する処理をバッファリングしておくためのもので、当該仮想アドレスをバッファ中に保持して入ればそれを活用し、そうでなければ外部にリクエストを出して取得する。TLBエントリの構成は以下のようになっている。
- TAGビット：
vpnのビットを格納している。 - Validビット：データビットに有効な値が入っているかどうかを示している。
- Dataビット：データビット。内訳はPTEの内容と同じ。
- Levelビット：変換のレベルを示している。
変換の方法については今後しっかり調べていくが、基本的に物理アドレスモード(VM=0)の時はそのままアドレスを返す。そうでないときはTLBのエントリーテーブルを検索している。
