FPGA開発日記

カテゴリ別記事インデックス https://msyksphinz.github.io/github_pages , English Version https://fpgadevdiary.hatenadiary.com/

RISC-VのアウトオブオーダプロセッサSonicBOOM (BOOMv3)の論文を読む

SonicBOOMというのはBOOM(Berkeley Out-of-Order Machine)の第3世代で、なぜSonicという名前を付けたのか謎だが、IPCを向上させるための技術が詰め込まれている。

carrv.github.io

  • SonicBOOM: The 3rd Generation Berkeley Out-of-Order Machine

https://carrv.github.io/2020/papers/CARRV2020_paper_15_Zhao.pdf

アーキテクチャの改良が行われており、

  • 実行パスの改善
  • 命令フェッチユニットの再実装(TAGE分岐ユニットの増強)
  • 1サイクル当たり複数のロードストア命令を発行できるように改良

これにより、SPEC CPUベンチマークにより過去のBOOMと比較して2倍のIPCを達成し、Coremarkスコアは6.2を達成することができた。

概要

SonicBOOMの構成を以下に示す。4命令フェッチ・8命令発行が可能な構成となっている。

f:id:msyksphinz:20200606113104p:plain
SonicBOOMのパイプライン。図は論文より抜粋。

パイプラインの構成。BOOMv1/BOOMv2/BOOMv3のパイプラインの進化。

まず、フロントエンドに分岐予測器が増強されている。TAGE・RASを追加しているところを見ると、Maxionの実装をフィードバックさせているようにも見える。バックエンドのパイプラインが増強されているように見えるのは、RoCCが付いているから。ただしRoCCはあまり使わないので大勢に影響はない。

f:id:msyksphinz:20200606113146p:plain
BOOMv1-v3のパイプラインの歴史。図は本論文より抜粋。

簡単にBOOMの歴史について纏められているので紹介すると、

  • BOOM v1:単純なアウトオブオーダプロセッサ。シンプルなパイプラインで当時はRVC命令が使用できなかった。IPC重視でMIPS R10kの構成に非常に似ている。
  • BOOM v2:BOOM v2はv1に比べて物理デザインのフローを改良すべく、クリティカルパスの削減を行っている。この中でレジスタの構成方法を改良し、レジスタアクセスのクリティカルパスを削減している。
  • BOOM v3:マイクロアーキテクチャの改良が行われている。

SonicBOOMの改良点についてより詳細に見ていくことにする。

命令フェッチ

  • C拡張命令(つまり2バイト命令)のサポート。これはRocketでもすでに行われていることなので驚くにあたらない。むしろ遅いくらい。
  • 分岐予測器の実装。フェッチユニット内の分岐予測器を実装し直し、分岐予測器はICacheにマッチするようにバンク化されている。さらにTAGEを実装することで分岐予測の精度を向上させている。さらにRASを実装することで関数から復帰する際の分岐予測ミスを削減している。
  • 分岐予測解決メカニズムの改善。BOOMv2では1サイクルに1つの分岐命令しか解決することができていなかったが、複数の分岐解決ユニットを持つことで改善を行っている。

実行ユニット

実行ユニットではRoCC(Rocket Custom Coprocessor)のサポートが行われ散る。さらにSFB(Short Forward Branch)に対する最適化が実装されている。

SFBというのはShort Forward Branchというらしいのだが、データに依存して基本ブロックをジャンプするような短い分岐シーケンスのことを言うらしい。RISC-VではConditional Moveが存在しないのでいちいち比較してはジャンプするしか対処方法が無いのだが、ここでは"set-flag"と"conditional-execute"のマイクロ命令を用意したとしている。

もう少し読み進めると、分岐命令を"set-flag"命令に置き換え、比較の結果によってリネームするレジスタファイルを置き換えるらしい。そして"conditional-execute"によりその命令を実行するか、単純にオリジナルの物理レジスタから書き込み先のレジスタに置き換えるだけの動作にするかを決定する。例が載っている。

f:id:msyksphinz:20200606113230p:plain
Short Forward Branchの適用例。図は本論文から抜粋。

ループを使って最大値とそのインデックスを見つけだすルーチンだが、アセンブリに変換すると単純に中央のアセンブリコードのようなシーケンスになる。条件が成立しない(最大値を見つけた)と値の更新のためのmv命令が実行され、そうでなければskipまでジャンプして次の命令シーケンスの実行が行われる。

これを分解し、bge命令をset.ge命令に置き換えることで仮想的にフラグを設定する。フラグが有効である場合はp.mv命令を実行し、そうでないp.mv命令は実行されない。しかしこれの条件判定はどのようにするんだろう?たとえばどこからどこまでがp.の適用対象範囲なのだ?

ロードストアユニット

f:id:msyksphinz:20200606113305p:plain
SonicBOOMのロードストアユニットの概要。本論文より抜粋。

これまでのRocketのL1キャッシュは1リクエストしか受け付けることができなかったので制約があった。そこで複数リクエストを受け付けることができるように改良を行ったというのが今回のBOOMv3だ。

  • L1データキャッシュのデュアルポート化

L1データキャッシュをデュアルポート化し、2つのバンクを用意した。各バンクは1R1WのSRAMで構成されている。2R1Wの実装も考えたが物理的な実装に問題がありシンプルな方を選んだらしい。ロードストアユニットをデュアル発行できるようにするため、ロードアドレスとストアアドレスのCAMを複製してTLBをデュアルポートにした。

  • L1の性能向上

SonicBOOMではL1データキャッシュのミスが発生すると即座にL2にリフィルのリクエストを発行する。リフィルデータはラインフィルバッファに送られるため、キャッシュのeviction(既存のキャッシュの書き出し)と同時にキャッシュのリフィルが行われている。SonicBOOMのノンブロッキングL1データキャッシュには複数のステートマシンが実装されており、キャッシュフィルとevictionが同時に動くようになっている。

性能

性能評価については以下の構成で行っている。

  • FinFETのプロセスを使い1GHzで合成している。また、AWS F1インスタンスを用いてシミュレーションを行い性能を測定している。
  • SPECの性能。全体的に引けを取らないが、全体的にSkylakeと比較して劣る。Amazon Gravitonとは良い勝負かな?
f:id:msyksphinz:20200606113340p:plain
SonicBOOMとSkylake、GravitonでのSPEC性能比較。図は本論文より抜粋。
  • Coremarkの性能。かなり高い性能を達成できたとしている。XuanTie 910の方が上か。。。
f:id:msyksphinz:20200606113406p:plain
SonicBOOMと他社CPUコアでのCoremark/MHz値の比較。図は本論文より抜粋。

今後の課題

  • ベクトル命令の実装
  • 命令・データプリフェッチの実装