自作RISC-V CPUのデバッグ手法

自作 RISC-V CPUの デバッグ手法 kanataso@kanapipopipo 第3回 自作CPUを語る会 2024/06/02

自作RISC-V CPU、どうやってデバッグしてます か

大前提 assertを書く テストを書く

基本 : riscv-tests RISC-VのCPU向けのテストセット 命令1つ1つに対してのテストが揃っている ・物理アドレス(p), 仮想アドレス(v)向けのテストがある

iverilog, verilator OSSのVerilogのシミュレータ verilatorは高速、でも制限あり どちらも変なバグがある(気がする)

GitHub Actionsでコミットごとにテストを実行

riscv-tests .tohostに結果が書き込まれる ・1なら成功 ・gpレジスタにも書き込まれている ↓ メモリステージで.tohostに書き込まれ るのを確認したら、書き込み内容を 見て$finish

riscv-tests ページング込みのテスト(-v-)が終わらない ・.tohostが仮想アドレスになっている ページングユニットを越した先で判定するべきだった

riscv-testsが落ちたらどうする？ vcdを見る？ → GTKWave 波形を見てもいいが、ちょっと面倒 →簡単なログを$displayで出力すると楽

$displayの問題点 always @(posedge clk) begin $display(“〜”); end が複数あると、displayされる順番がクロック毎に入れ替わったりする & $displayが増えると、目的のログを探すのが大変！ ・波形を見るのとそこまで変わらない気がしてくる

解決法 : $displayの形式を正規化して出力、処理 正規化したログを出力, 保存 → pythonで処理 → 見やすいログ！

見やすいログができた

Konataで見れるようにもできる 命令フェッチで命令にidを振っておくとKanata log formatに変換できる。

riscv-testsが落ちたら.... まず、Konataでどこでおかしくなったか確認 次に、おかしい部分をテキストログで確認 それでも分からなければ、vcdを確認 vcdだけよりもよくなった？

まだつらい 数十万~数千万命令実行後に何かがおかしくなっているかもしれない場合、 ・ログを出力するだけで遅くなる ・ログの容量がとても大きくなる ・そもそもpcの遷移が正しいのかを確認するのがつらい ・どこかでストールしてしまうが、いつストールし始めたか分からん →デバッグ速度が非常に遅くなる

ログを出力するだけで遅くなる n命令目, nクロック後からログを出力するオプションを作成すればOK ・ログを表示するかどうかの変数をpackageに用意する $dumpon, $dumpoff

pcの遷移が正しいのかを確認する spikeと比べればOK spike : riscv-software-src/riscv-isa-sim RISC-V公式のシミュレータ 実行したPCを出力する機能がある(トレース) →これと比べられるログを生成して、比べる

不審なストールを検知する nクロックの間、ずっと同じ命令を処理し続けているときに、 finishしてデバッグ用の情報を表示するオプションを作成 WFI (Wait For Interrupt)に注意 長いストールを表示するとKonataが重くなる

riscv-testsが落ちた, 変な挙動になったら.... おかしくなった場所がわからない場合、 ・spikeと比較 ・ストール検知 でおかしくなる場所を探る。

riscv-testsが落ちた, 変な挙動になったら.... おかしくなった場所がわかったので、 まず、Konataでどこでおかしくなったか確認 次に、おかしい部分をテキストログで確認 それでも分からなければ、vcdを確認

まだつらい！ 割り込み系のバグ ・ISSと割り込みのタイミングが変わるので、比較ができなくなる メモリのバグ ・たいへん ・メモリ操作を監視すると良いが、キャッシュにバグがあったらどうする

ChiselでSVをテスト BlackBoxを使う ただし、ポートにinterfaceとかstructが使えない