ハードウェアの気になるあれこれスマートフォン用の表示で見るハードウェアの気になるあれこれ技術的に興味のあることを調べて書いてくブログ。SCR1スポンサーリンク昨日の記事の結びで以下のように書いた。いうことはecall命令がうまく処理されていないことになるが、そもそもecall命令って何??な状態なので次回はecall命令の中身を把握するところからやっていきたい。www.tech-diningyo.infoということでecall命令の確認を行い、その後にaddi.Sがどのように最終アドレスである0xf4に辿り着くのかを確認していく。ecall命令addi.Sのテストの終わり方addi.Sにおけるecall発行後の動作dumpファイルを使ってアドレスも確認ecall命令callとつくくらいなので、サブルーチンへのジャンプ的な動作だとは思っているのだけど、改めて確認しておこう。ecall命令の説明はISAの3.2に説明が記載されている。others.とりあえずざっくり言うと"現在のモードから見た特権モードに遷移して例外を発生させる"になりそう。他にも探してみたらmsyksphinzさんのFPGA開発日記にもエントリがあった。msyksphinz.hatenablog.com自作されているISSの実装に関してのエントリで、修正された部分のコードが載せられている↓。break;}上記はMachineモードの処理だがMCAUSEレジスタへ要因のライト動作モードをPrivMachineへjmp_addr=0x1c0にセットとなっている。ここで出てくるjmp_addr=0x1c0は初期状態におけるMachineモードのハンドラのベクタアドレスなので例外発生させた後ハンドラにジャンプという動作で良さそう。前項のecall命令の動作を踏まえてaddi.Sの処理がどのように終了まで実行されるのかを確認していく。前項で書いたとおり、ecallを発行すると例外テーブルに飛ぶはず、ということがわかった。従って前回記載したaddi命令のPASS/FAIL判定(以下のコード)のあとは、例外テーブルにジャンプすることになる。*/とうことでriscv-testsをSCR1の環境で実行した場合の例外ハンドラのコードをチェックしていこう。上記を見るとここでの処理はmcauseレジスタをリードして、その中身に応じて各種処理をしていく、、という感じになる。先ほどecall命令の動作を確認した際に、msyksphinzさんのエントリから引用させてもらった内容にもあったように、mcauseレジスタにはなぜ例外が発生したかの要因が入っていて、SCR1の場合はMachineモードのみサポートのため、テストの最後に実行されたecall命令が正常に動作すれば以下の部分が実行されることになる。\dumpファイルを使ってアドレスも確認これをELFファイルから生成したdumpファイル上でもう一度見てみよう。以下がdumpファイルから必要な部分を抜粋したコードになる。noptrap_vector直後からの処理を追っていくと以下のようになるはずだ。以前のエントリで書いたがこの0xf4はSCR1のシミュレーション環境における内側のforeverループの終了条件である。break;ということで以前に、以下のように書いたとおりの動きをするのが正しいことになる。本来なら、この0x4acのecall命令を経て、命令読み出しアドレスがSCR1_EXIT_ADDR=0xF8に到達しなければならないのだが、今のVivadoシミュレーション上はそうなっていないためシミュレーションが正常に終了しないことがわかった。このコメントを書いた際にはecall命令の動作を特にきちんと把握もせず、0xf4のアドレスから逆に辿っていただけであった。そのため、SCR1の内部で追うべき点が絞りきれていない状況であったが、今回の確認を経てSCR1のecall命令発行時の動作がVivadoシミュレータ上でどのように処理されているかに焦点をおいて解析をかけていけば良さそう。続きは次のエントリにて。シミュレーション環境の疑問点の確認(1)前回のSCR1ネタ最後に以下のように書いた。技書博2にChisel本を出してきました月別アーカイブはてなブログをはじめよう!diningyo-kpuku-jougekiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。