FPGA開発日記 カテゴリ別インデックス

RISC-VにおけるRVWMOの仕様について読み直す

• 1. RVWMOの概要 (24/02/01)
• 2. 構文依存性の定義 (24/02/02)
• 3. Preserved Program Order / Memory Model Axioms (24/02/04)
• RISC-V仕様書 : Appendix A. RVWMO Explanatory Material, Version 0.1 (24/02/05)
• RISC-V仕様書 : Appendix A. RVWMO Explanatory Material, Version 0.1 (24/02/06)
• RISC-V仕様書 : Appendix A. RVWMO Explanatory Material, Version 0.1 (24/02/07)
• RISC-V仕様書 : Appendix A. RVWMO Explanatory Material, Version 0.1 (24/02/09)
• RISC-V仕様書 : Appendix A. RVWMO Explanatory Material, Version 0.1 (24/02/10)
• RISC-V仕様書 : Appendix A. RVWMO Explanatory Material, Version 0.1 (24/02/12)
• RISC-V仕様書 : Appendix A. RVWMO Explanatory Material, Version 0.1 (24/02/13)

自作CPUのVIPTキャッシュポリシ導入検討 (2. 実装について)

自作CPUのキャッシュについて，VIPTを導入して実装を開始した． データキャッシュについては，VIPTとPIPTの両方をサポートする必要があり(LSUパイプラインはVIPT，それ以外のポートはPIPT)，そのあたりの詳細を詰めている．

とりあえずPIPTのままで維持していいポートはそのままで，LSUのアクセスポートのみをVIPTに置き換えている．

VIPTでは、キャッシュのインデックス・アクセスのためには仮想アドレスを用い、タグ比較には物理アドレスを使用する。 例えば、512ビット(=64B)で4-wayを持つキャッシュにおいて、32KBの容量を用意したい場合、キャッシュのライン数は以下のようになるだろう。

インデックス

仮想アドレスのうち、下位の64B分(6ビット)はキャッシュライン内のため省略する。すると上位の128インデックス分(7ビット)がキャッシュ・インデックス・アクセスのために使用される。

ところが、仮想アドレスが物理アドレスに変換されると、一致しているのはアドレスのページ内ビット(12ビット分)のみであり、上記の例だと一番上の12ビット目は仮想アドレスと物理アドレスで異なる可能性がある。

この一番上のビットをColor Bitと名付け、以降ではこれを引き回していくことになる。

オープンソースの波形ビューワSurferを試す2

msyksphinz.hatenablog.com

時間が空いたが，このリポジトリを見に行ってみるとwellenがアップデートされており，何もしなくてもVerilatorの出力したSystem Verilogが読めるようになっていた．

ちょっと使っていてまだ判明していないのは，

• ビットの展開：バスのビット展開ができない？
• 時間方向にタグが打てない：タグを打って事象の記録をつけるのが便利なので，これはあったほうがいい．
• 検索：条件を付けた，波形の検索ができるといい

というあたりがまだ足りないので，自分で追加してみるか... Issueを立てたほうがいいのかもしれないが，その辺がアップデートされればかなり良くなる気がしている．

自作CPUのVIPTキャッシュポリシ導入検討

現在の自作CPUは，キャッシュのポリシとしてPIPTを採用している． PIPTというのは，Physically Index, Physically Taggedのことで，物理アドレスを使用してキャッシュのインデックスを参照し，物理アドレスを使用したタグの比較を行う．

これのメリットは，LSU内のデータパスを，

• PIPT : レジスタアクセス → アドレス計算 → 物理アドレスへ変換 → キャッシュアクセス

というのを，VIPTは

• VIPT : レジスタアクセス → アドレス計算 → 物理アドレスへ変換
• VIPT : アドレス計算 → キャッシュアクセス → 物理タグの比較

とすることで，LSU内のクリティカルパスを削減することができる．

で，単純にデータキャッシュのポートを全部このように変えればよいわけではなくて，一部はVIPT，一部はPIPTで作る必要があるように思う．

• LSUパイプラインからのアクセス：VIPT
• スヌープ用のポート：PIPT
• PTW用のポート：PIPT
• MSHRからの読み込みポート：PIPT
• Store Bufferからの読み込みポート：PIPT

とする必要があると思う．PIPTを用意しなければならない場所は結構あって，かついくつかのポートはマージできそうな気がしているので，この辺の調整をしていけばいいのだと思う．

LiteXのBIOSソフトウェアを独自に構築する方法調査 (7. キャッシュ容量変更試行)

前回の続き、自作CPUがFPGA上で動作したので一安心。

波形を見た感じだと、ちょっとコンフィグレーションを間違ってキャッシュがめちゃめちゃ少なくて、バスへの負荷がかかっているような気がしている。 もう少しキャッシュの容量を増やしてみる。

まあ、今のところデータキャッシュにRAMB36とRAMB18なのだが、18kbitなのだとしたらちょっと計算と合わないな？

+------------------------------------------------------------------------------------------+------------------------------------------------+------------+------------+---------+------+-------+--------+--------+--------------+
|                                         Instance                                         |                     Module                     | Total LUTs | Logic LUTs | LUTRAMs | SRLs |  FFs  | RAMB36 | RAMB18 | DSP48 Blocks |
+------------------------------------------------------------------------------------------+------------------------------------------------+------------+------------+---------+------+-------+--------+--------+--------------+
|           u_scariv_dcache                                                                |                                  scariv_dcache |       3133 |       3133 |       0 |    0 |   808 |     16 |     16 |            0 |

LiteXのBIOSソフトウェアを独自に構築する方法調査 (6. バスをAXIに変える)

前回の続き、自作CPUがFPGA上で動作したので一安心。 とりあえず次の試行として、LiteXのSoC周りがWishboneをベースに作ってあるので、AXIに変えてみる。 AXIに変えるためには、とりあえずコマンドラインで以下のようにオプションを変えればいいらしい。

python3 -m litex_boards.targets.digilent_nexys_video --cpu-type=mycpu --build --output-dir mycpu_fpga_axi --sys-clk-freq 30e6 \
     --bus-standard axi --bus-data-width 64

とりあえず、SRAMのビット幅がデフォルトの32から倍の64ビットになっている。

reg           main_basesoc_mmio_a2w_b_valid = 1'd0;
reg   [127:0] main_basesoc_mmio_a2w_r_payload_data = 128'd0;
reg     [1:0] main_basesoc_mmio_a2w_r_payload_resp = 2'd0;
reg           main_basesoc_mmio_a2w_r_ready = 1'd0;
reg           main_basesoc_mmio_a2w_r_valid = 1'd0;
reg   [127:0] main_basesoc_mmio_a2w_w_payload_data = 128'd0;
reg    [15:0] main_basesoc_mmio_a2w_w_payload_strb = 16'd0;
reg           main_basesoc_mmio_a2w_w_ready = 1'd0;
reg           main_basesoc_mmio_a2w_w_valid = 1'd0;
reg           main_basesoc_mmio_axi_ar_first = 1'd0;
wire          main_basesoc_mmio_axi_ar_last;
reg           main_basesoc_mmio_axi_ar_param_dest = 1'd0;

ただし、変換のパスについては、アウトスタンディング数があまり大きくないのか？性能の面では少し疑問が残るね。 もうちょっと内部を詳細に見ていく必要がありそう。

LiteXのBIOSソフトウェアを独自に構築する方法調査 (5. FPGAでの動作確認)

前回の続き。結局LiteXのFPGA環境を丸ごとVerilatorにもってきて波形を取った。 やはり波形のデバッグは楽だ。実行が停止してしまうのもちゃんと再現できた。

msyksphinz.hatenablog.com

小さなバグだったが、やはり本番FPGA環境をちゃんとシミュレーションできるのは楽だ。 ストールの要因も波形ですぐに特定できた。

修正後のRTLシミュレーションでの正常動作確認、FPGAでの正常動作も確認した。 自作Out-of-Order CPUが、LiteXのプラットフォームでブートしたぞ！

シリアル出力、キーボード入力も問題ない。

litex> ident
Ident: LiteX SoC on Nexys Video 2024-05-02 14:12:00
litex> 

とりあえず正常動作まで確認したので、あとはクリティカルパスの改善と、ベンチマークの動作確認だな。 あとLinuxとかも検討しなきゃ。