RISC-Vにおける割り込み処理挿入の方法確認

RISC-Vにおける割り込みの挿入方法を、テストパタンを動かしながら確認している。 以下のテストパタンで、MIP(Machine Interrupt Pending)とMIE(Machine Interrupt Enable)を制御して割り込みを挿入するテストが行われている。

動作確認には、ChipyardのRocketChip環境を使用している。

$ chipyard/sims/verilator
$ make CONFIG=RocketConfig debug
$ ./simulator-chipyard-RocketConfig-debug +verbose -v rv64mi-p-illegal.vcd ${RISCV}/riscv64-unknown-elf/share/riscv-tests/isa/rv64mi-p-illegal 2>&1 | spike-dasm | tee rv64mi-p-illegal.rocket.log

C0:        564 [1] pc=[00000000800001b0] W[r 7=0000000a00000880][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[300023f3] csrr    t2, mstatus
C0:        567 [1] pc=[00000000800001b4] W[r 7=0000000000000800][1] R[r 7=0000000a00000880] R[r 5=0000000000001800] inst=[0053f3b3] and     t2, t2, t0
C0:        568 [1] pc=[00000000800001b8] W[r 0=0000000000000000][0] R[r 6=0000000000000800] R[r 7=0000000000000800] inst=[0c731e63] bne     t1, t2, pc + 220
C0:        569 [1] pc=[00000000800001bc] W[r 0=0000000000000080][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[34415073] csrwi   mip, 2
C0:        590 [1] pc=[00000000800001c0] W[r 0=0000000000000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[30415073] csrwi   mie, 2
C0:        595 [1] pc=[00000000800001c4] W[r 5=00000000800001c4][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000297] auipc   t0, 0x0
C0:        596 [1] pc=[00000000800001c8] W[r 5=0000000080000301][1] R[r 5=00000000800001c4] R[r 0=0000000000000000] inst=[13d28293] addi    t0, t0, 317
C0:        597 [1] pc=[00000000800001cc] W[r 8=0000000080000004][1] R[r 5=0000000080000301] R[r 0=0000000000000000] inst=[30529473] csrrw   s0, mtvec, t0
C0:        602 [1] pc=[00000000800001d0] W[r 5=0000000080000301][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[305022f3] csrr    t0, mtvec
C0:        605 [1] pc=[00000000800001d4] W[r 5=0000000000000001][1] R[r 5=0000000080000301] R[r 0=0000000000000000] inst=[0012f293] andi    t0, t0, 1
C0:        606 [1] pc=[00000000800001d8] W[r 0=0000000000000000][0] R[r 5=0000000000000001] R[r 0=0000000000000000] inst=[00028663] beqz    t0, pc + 12
C0:        607 [1] pc=[00000000800001dc] W[r 0=0000000a00000880][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[30046073] csrsi   mstatus, 8
C0:        612 [0] pc=[00000000800001e0] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[0000006f] j       pc + 0x0
C0:        617 [1] pc=[0000000080000304] W[r 0=0000000080000308][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[ee1ff06f] j       pc - 0x120
C0:        619 [1] pc=[00000000800001e4] W[r 0=0000000080000301][1] R[r 8=0000000080000004] R[r 0=0000000000000000] inst=[30541073] csrw    mtvec, s0
C0:        624 [1] pc=[00000000800001e8] W[r 0=0000000000000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[30315073] csrwi   mideleg, 2
C0:        629 [1] pc=[00000000800001ec] W[r 5=00000000800001ec][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000297] auipc   t0, 0x0
C0:        630 [1] pc=[00000000800001f0] W[r 5=0000000080000214][1] R[r 5=00000000800001ec] R[r 0=0000000000000000] inst=[02828293] addi    t0, t0, 40
C0:        631 [1] pc=[00000000800001f4] W[r 0=00000000800001e0][1] R[r 5=0000000080000214] R[r 0=0000000000000000] inst=[34129073] csrw    mepc, t0
C0:        632 [1] pc=[00000000800001f8] W[r 5=0000000000002000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[000022b7] lui     t0, 0x2
C0:        633 [1] pc=[00000000800001fc] W[r 5=0000000000001800][1] R[r 5=0000000000002000] R[r 0=0000000000000000] inst=[8002829b] addiw   t0, t0, -2048

MIP=2, MIE=2 を設定しているので、SSIP(Supervisor Software Interrupt Pending)とSSIE(Supervisor software Interrupt Enable)を設定し、mstatusの3ビット目を1に設定する、つまりmstatus.MIE=1とすることで割込みが挿入される。

mtvecは0x80000301が設定されているため、割り込みが発生するとそのあたりにジャンプするはずだが、Rocketのログでは0x80000304にジャンプしている。なんでだ？

もう一つ、MIPは自動的にOFFされるのかと思ったが、これは違うようだ。一度割り込みが入った後に自動的にどのように抑え込むかは、Rocket-Chipの実装を確認してみる必要がありそうだ。

自作RISC-V CPUコア実装(テストパタンデバッグ)

自作CPUのデバッグをチマチマ進めている。 TLBの問題についてはとりあえず置いておいて、テストパタンを動かしながら問題点を洗い出している。 とりあえず環境等の問題を洗い出して、基本的なケースは動くようなところまで直していった。 巨大なコンフィグレーションでのテストもある程度動作するようになってきたが、まだテストパタンのPASS率は低いまだだ。

	0b3bcc9 (2022/01/16)
rv32_big.log	89 / 109 (81.65%)
rv32_giant.log	40 / 109 (36.70%)
rv32_small.log	70 / 109 (64.22%)
rv32_standard.log	87 / 109 (79.82%)
rv32_tiny.log	92 / 109 (84.40%)
rv64_big.log	105 / 169 (62.13%)
rv64_giant.log	80 / 169 (47.34%)
rv64_small.log	87 / 169 (51.48%)
rv64_standard.log	88 / 169 (52.07%)
rv64_tiny.log	152 / 169 (89.94%)

テストパタンのPASS率の管理については、いろいろ考えている。毎日のリグレッション結果をどのようにして管理するのか？ 一つ考えられるのは、テストの結果を何等かのフォーマット(JSONやYAMLなど)で出力して毎日追加し、これも何らかのスクリプトを使ってグラフなどに変換するということが考えられる。 この辺を管理できる上手い方法は無いだろうか？

あとはGitHub Actionsの扱い方が未だに良く分かっていない。

Chipyardで32-bit版BOOMを生成するための調査 (4. RV32向けのF拡張限定BOOMのテスト実行)

前回RV32のF拡張限定のVerilogファイルを生成したので、これのテストを実行する方法を調査する。

msyksphinz.hatenablog.com

Chipyardのドキュメントによると、以下のようにすることでriscv-testsとriscv-benchmarksを実行することができる。

make CONFIG=MediumBoom32Config run-asm-tests run-bmark-tests

一応テストは動き始めた。以下のテストはPASSしたようだ。しかしrv32uf-p-faddが落ちた。fclassやfcmpなどはPASSしているのに不思議だなあ。

grep -e PASS -e FAIL *.out

rv32uc-p-rvc.out:*** PASSED *** Completed after 230133 cycles
rv32uf-p-fadd.out:simulator-chipyard-MediumBoom32Config: ../fesvr/elfloader.cc:29: std::map<std::__cxx11::basic_string<char>, long unsigned int> load_elf(const char*, memif_t*, reg_t*): Assertion `buf != MAP_FAILED' failed.
rv32uf-p-fclass.out:*** PASSED *** Completed after 17320 cycles
rv32uf-p-fcmp.out:*** PASSED *** Completed after 109512 cycles
rv32uf-p-fcvt.out:*** PASSED *** Completed after 93401 cycles
rv32uf-p-fcvt_w.out:*** PASSED *** Completed after 115940 cycles
rv32uf-p-ldst.out:*** PASSED *** Completed after 91097 cycles
rv32uf-p-move.out:*** PASSED *** Completed after 26376 cycles
rv32ui-p-add.out:*** PASSED *** Completed after 37690 cycles
rv32ui-p-addi.out:*** PASSED *** Completed after 24963 cycles
rv32ui-p-and.out:*** PASSED *** Completed after 36481 cycles
rv32ui-p-andi.out:*** PASSED *** Completed after 21164 cycles
rv32ui-p-auipc.out:*** PASSED *** Completed after 13395 cycles
rv32ui-p-beq.out:*** PASSED *** Completed after 26516 cycles
rv32ui-p-bge.out:*** PASSED *** Completed after 28937 cycles
rv32ui-p-bgeu.out:*** PASSED *** Completed after 28936 cycles
rv32ui-p-blt.out:*** PASSED *** Completed after 26516 cycles
rv32ui-p-bltu.out:*** PASSED *** Completed after 27765 cycles
rv32ui-p-bne.out:*** PASSED *** Completed after 26519 cycles
rv32ui-p-fence_i.out:*** PASSED *** Completed after 94804 cycles
rv32ui-p-jal.out:*** PASSED *** Completed after 13482 cycles
rv32ui-p-jalr.out:*** PASSED *** Completed after 17284 cycles
rv32ui-p-lb.out:*** PASSED *** Completed after 101284 cycles
rv32ui-p-lbu.out:*** PASSED *** Completed after 101284 cycles
rv32ui-p-lh.out:*** PASSED *** Completed after 102451 cycles
rv32ui-p-lhu.out:*** PASSED *** Completed after 102511 cycles
rv32ui-p-lui.out:*** PASSED *** Completed after 14738 cycles
rv32ui-p-lw.out:*** PASSED *** Completed after 102510 cycles
rv32ui-p-or.out:*** PASSED *** Completed after 36477 cycles
rv32ui-p-ori.out:*** PASSED *** Completed after 22335 cycles
rv32ui-p-sb.out:*** PASSED *** Completed after 110334 cycles
rv32ui-p-sh.out:*** PASSED *** Completed after 113086 cycles
rv32ui-p-simple.out:*** PASSED *** Completed after 12095 cycles
rv32ui-p-sll.out:*** PASSED *** Completed after 39110 cycles
rv32ui-p-slli.out:*** PASSED *** Completed after 24952 cycles
rv32ui-p-slt.out:*** PASSED *** Completed after 36444 cycles
rv32ui-p-slti.out:*** PASSED *** Completed after 24952 cycles
rv32ui-p-sra.out:*** PASSED *** Completed after 41516 cycles
rv32ui-p-srai.out:*** PASSED *** Completed after 26178 cycles
rv32ui-p-srl.out:*** PASSED *** Completed after 40321 cycles
rv32ui-p-srli.out:*** PASSED *** Completed after 26189 cycles
rv32ui-p-sub.out:*** PASSED *** Completed after 36456 cycles
rv32ui-p-sw.out:*** PASSED *** Completed after 113365 cycles
rv32ui-p-xor.out:*** PASSED *** Completed after 36480 cycles
rv32ui-p-xori.out:*** PASSED *** Completed after 22400 cycles

自作RISC-V CPUコア実装(テストパタンデバッグ)

自作CPUのデバッグをチマチマ進めている。 TLBの問題についてはとりあえず置いておいて、テストパタンを動かしながら問題点を洗い出している。 とりあえず環境等の問題を洗い出して、基本的なケースは動くようなところまで直していった。 RV32のテストケースについては、動くようになったかな？細かいケースの問題は直していないし、RASのパフォーマンスバグについてはまだ見ていない。まだ調整が必要だなあ。

riscv-isa-sim側のトレースの問題で、いろいろ突っかかるときがあった。 Spikeはstep()を実行すると1命令を実行するのが基本なのだが、時々そうでないときがある。特に例外を処理するときは例外を処理するだけで命令が進まないときがあって、そうするとRTL側との命令実行数が合わなくなってしまい、テストケースが失敗してしまう。

色々チェックして、どうやってSpikeの挙動とRTLの挙動を合わせようかと検討していたのだが、最終的にはSpikeのminstretを使うことにした。 minstretのカウンタが、step()実行後に前回のカウンタと変わっていなければもう一度実行するように変更した。これで結構いろんなパタンが通るようになった。 こんな感じ。

  p->step(1);

  auto instret  = p->get_state()->minstret;
  static reg_t prev_instret = 1;
  if (prev_instret == instret) {
    p->step(1);
  }
  prev_instret = instret;

rv32_tiny.log:PASS / TOTAL = 84 / 109
rv32_small.log:PASS / TOTAL = 68 / 109
rv32_standard.log:PASS / TOTAL = 70 / 109
rv32_big.log:PASS / TOTAL = 0 / 109
rv32_giant.log:PASS / TOTAL = 0 / 109

コアの構成を大きくしていくとやっぱりまだ動かない。デバッグ必要！

自作RISC-V CPUコア実装(テストパタンデバッグ)

自作CPUのデバッグをチマチマ進めている。 現在、1つのVerilogファイルから10個程度のコンフィグレーションを生成するようにしてリグレッションを走らせている。 TLBの挙動がおかしくなってしまったので、いろいろ見ているのだが、どうもVerilatorの問題を踏んでしまっているような気がしている。

structで定義した入出力ポートに対してTLBの探索結果を返しているのだが、以下の.missがどう頑張っても所望の動作をしてくれない。 念のため無料版のModelSimで走らせても挙動が違うため、どうもVerilatorのバグを踏んでいるような気がする？

 // ------------------
 // Response of TLB
 // ------------------
 assign o_tlb_resp.pf.ld        = (w_bad_va && w_cmd_read) || (|(w_pf_ld_array & w_is_hit));
 assign o_tlb_resp.pf.st        = (w_bad_va && w_cmd_write_perms) || (|(w_pf_st_array & w_is_hit));
 assign o_tlb_resp.pf.inst      = w_bad_va || (|(w_pf_inst_array & w_is_hit));
 assign o_tlb_resp.ae.ld        = |(w_ae_ld_array & w_is_hit);
 assign o_tlb_resp.ae.st        = |(w_ae_st_array & w_is_hit);
 assign o_tlb_resp.ae.inst      = |(~w_px_array   & w_is_hit);
 assign o_tlb_resp.ma.ld        = |(w_ma_ld_array & w_is_hit);
 assign o_tlb_resp.ma.st        = |(w_ma_st_array & w_is_hit);
 assign o_tlb_resp.ma.inst      = 1'b0;   // this is up to the pipeline to figure out
 assign o_tlb_resp.cacheable    = |(w_c_array & w_is_hit);
 assign o_tlb_resp.must_alloc   = |(w_must_alloc_array & w_is_hit);
 // && edge.manager.managers.forall(m => !m.supportsAcquireB || m.supportsHint).B;
 assign o_tlb_resp.prefetchable = |(w_prefetchable_array & w_is_hit);
 logic                            w_tlb_resp_miss;
 assign w_tlb_resp_miss = w_do_refill | w_tlb_miss;
 assign o_tlb_resp.miss         = w_tlb_resp_miss; /* || multiplehits */;
 assign o_tlb_resp.paddr        = {w_ppn, i_tlb_req.vaddr[11: 0]};

ちなみにこういうstructの記述はVerilatorによって以下のようなC++に変換されているようだ。 正気ですか？みたいなコードが出てきた。これ、どうやってデバッグしろって言うんだ... もう少し問題を簡潔にして絞り込んでいくしかないような気がしている。

    vlSelf->o_tlb_resp = (((QData)((IData)((((((((IData)(
                                                         (0U
                                                          !=
                                                          (((IData)(vlSelf->__PVT__w_cmd_read)
                                                             ?
                                                            (~
                                                             ((IData)(vlSelf->__PVT__w_r_array)
                                                              | (IData)(vlSelf->__PVT__w_ptw_ae_array)))
                                                             : 0U)
                                                           & (IData)(vlSelf->__PVT__w_is_hit))))
                                                 << 1U)
                                                | (0U
                                                   !=
                                                   (((IData)(vlSelf->__PVT__w_cmd_write_perms)
                                                      ?
                                                     (~
                                                      ((IData)(vlSelf->__PVT__w_w_array)
                                                       | (IData)(vlSelf->__PVT__w_ptw_ae_array)))
                                                      : 0U)
                                                    & (IData)(vlSelf->__PVT__w_is_hit))))
                                               << 0xaU)
                                              | ((((IData)(
                                                           (0U
                                                            !=
                                                            ((~
                                                              ((IData)(vlSelf->__PVT__w_x_array)
                                                               | (IData)(vlSelf->__PVT__w_ptw_ae_array)))
                                                             & (IData)(vlSelf->__PVT__w_is_hit))))
                                                   << 3U)
                                                  | (((IData)(
                                                              (0U
                                                               !=
                                                               (((IData)(vlSelf->__PVT__w_cmd_read)
                                                                  ?
                                                                 ((IData)(__PVT__w_ae_array)
                                                                  | (~ (IData)(vlSelf->__PVT__w_pr_array)))
                                                                  : 0U)
                                                                & (IData)(vlSelf->__PVT__w_is_hit))))
                                                      << 2U)
                                                     | (((IData)(
                                                                 (0U
                                                                  !=
                                                                  (((((IData)(vlSelf->__PVT__w_cmd_write_perms)

Chipyardで32-bit版BOOMを生成するための調査 (3. RV32向けにF拡張限定BOOＭを生成)

ちょっと気になったのだけれども、現在BOOMは32ビットモードでのFPUをサポートしていないらしい(アサーションが組まれている)。

じゃあ無理やりそれを外して動作する様にしたらどうなるか、ということでやってみる。つまり、以下のアサーションをコメントアウトして、 無理やりChiselでの生成に挑戦してみる。

diff --git a/src/main/scala/common/parameters.scala b/src/main/scala/common/parameters.scala
index 4f22b197..f0507bdb 100644
--- a/src/main/scala/common/parameters.scala
+++ b/src/main/scala/common/parameters.scala
@@ -176,7 +176,7 @@ trait HasBoomCoreParameters extends freechips.rocketchip.tile.HasCoreParameters

   val mulDivParams = boomParams.mulDiv.getOrElse(MulDivParams())
   // TODO: Allow RV32IF
-  require(!(xLen == 32 && usingFPU), "RV32 does not support fp")
+  // require(!(xLen == 32 && usingFPU), "RV32 does not support fp")

   //************************************
   // Pipelining

そうすると、まずはLSUの所で失敗してしまった。

[error] java.lang.IllegalArgumentException: requirement failed
[error]         ...
[error]         at boom.lsu.LSU.<init>(lsu.scala:882)
[error]         at boom.common.BoomTileModuleImp.$anonfun$lsu$2(tile.scala:160)
[error]         at chisel3.Module$.do_apply(Module.scala:54)
[error]         at boom.common.BoomTileModuleImp.$anonfun$lsu$1(tile.scala:160)
[error]         at chisel3.internal.plugin.package$.autoNameRecursively(package.scala:52)

対応するソースコード。

         "[lsu] Incoming store is overwriting a valid data entry")
     }
   }
   val will_fire_stdf_incoming = io.core.fp_stdata.fire()
   require (xLen >= fLen) // for correct SDQ size

   //-------------------------------------------------------------
   //-------------------------------------------------------------

あ、そういうことですか... もうこの時点でRV32に対してD拡張を突っ込めないような仕様になっているんだな。 これ、やろうと思えば修正できそうだけど、今回はそれが目的ではないのでもうコンフィグレーションの方を書き換えてしまう。

diff --git a/src/main/scala/common/config-mixins.scala b/src/main/scala/common/config-mixins.scala
index fc20726c..bdf20bdf 100644
--- a/src/main/scala/common/config-mixins.scala
+++ b/src/main/scala/common/config-mixins.scala
@@ -129,7 +129,7 @@ class WithNSmallBooms(n: Int = 1, overrideIdOffset: Option[Int] = None) extends
 /**
  * 2-wide BOOM.
  */
-class WithNMediumBooms(n: Int = 1, overrideIdOffset: Option[Int] = None) extends Config(
+class WithNMediumBooms(xlen: Int = 64, n: Int = 1, overrideIdOffset: Option[Int] = None) extends Config(
   new WithTAGELBPD ++ // Default to TAGE-L BPD
   new Config((site, here, up) => {
     case TilesLocated(InSubsystem) => {
@@ -154,7 +154,8 @@ class WithNMediumBooms(n: Int = 1, overrideIdOffset: Option[Int] = None) extends
               numFetchBufferEntries = 16,
               ftq = FtqParameters(nEntries=32),
               nPerfCounters = 6,
-              fpu = Some(freechips.rocketchip.tile.FPUParams(sfmaLatency=4, dfmaLatency=4, divSqrt=true))
+              usingFPU = false,
+              fpu = Some(freechips.rocketchip.tile.FPUParams(fLen = xlen, sfmaLatency=4, dfmaLatency=4, divSqrt=true))
             ),
             dcache = Some(
               DCacheParams(rowBits = site(SystemBusKey).beatBits, nSets=64, nWays=4, nMSHRs=2, nTLBWays=8)
@@ -169,7 +170,7 @@ class WithNMediumBooms(n: Int = 1, overrideIdOffset: Option[Int] = None) extends
       } ++ prev
     }
     case SystemBusKey => up(SystemBusKey, site).copy(beatBytes = 8)
-    case XLen => 64
+    case XLen => xlen
   })
 )

要点としては、fpuの生成オプションのところにfLen = xLenのオプションを突っ込み、RV32ではF拡張(単精度浮動小数点)しか生成しないように変更してみる。 これですべてのアサーションをクリアして、一応Verilogファイルの生成までは出来るようになった。

ちなみにusingFPUをFalseにしてみたが無視されてFPUが生成されている。なぜだ(というかBOOMではusingFPUは使わないのか？)。

Chipyardで32-bit版BOOMを生成するための調査 (2. コンフィグレーション調査)

メモ：Chipyard tag 1.5.0はMediumBoomConfigの生成に失敗する。master`ブランチを使った方が良い。

commit 02adf86b8261ca4b5baf35b3257e15cdbabd7f87 (HEAD, origin/master, origin/HEAD)
Author: Abraham Gonzalez <abe.j.gonza@gmail.com>
Date:   Thu Dec 2 09:25:51 2021 -0800

    Force FIRRTL 1.4.1 (#1053)

前回試行したコンフィグレーションはコンパイルに失敗してしまった。以下のアサーションが入っており上手く行かない。

• chipyard/generators/boom/src/main/scala/common/parameters.scala

   val mulDivParams = boomParams.mulDiv.getOrElse(MulDivParams())
   // TODO: Allow RV32IF
   require(!(xLen == 32 && usingFPU), "RV32 does not support fp")

別にFPUを使わなくてもいいんだけどな... 試しにusingFPUをOFFにしてみてもなぜか同じアサーションで失敗した。

/**
 * 2-wide BOOM.
 */
class WithNMediumBooms(xlen: Int = 64, n: Int = 1, overrideIdOffset: Option[Int] = None) extends Config(
  new WithTAGELBPD ++ // Default to TAGE-L BPD
  new Config((site, here, up) => {
    case TilesLocated(InSubsystem) => {
/* 中略 */
              nPerfCounters = 6,
              usingFPU = false,    // これを追加してみる
              fpu = Some(freechips.rocketchip.tile.FPUParams(sfmaLatency=4, dfmaLatency=4, divSqrt=true))
            ),
            dcache = Some(
              DCacheParams(rowBits = site(SystemBusKey).beatBits, nSets=64, nWays=4, nMSHRs=2, nTLBWays=8)

仕方がない。目的は32ビットの乗除算器のモジュールを手に入れることなのでBOOMから生成することはとりあえず諦めてRocketの32ビット版から取得しよう。以下のコマンドでVerilogを生成する。

make debug CONFIG=RV32RocketConfig

これで32ビット版のMulDivモジュールを取得できる。BOOMで生成した場合にはTagに関するポートが生成されていなかった。これはコンフィグレーションの違いで生成されているのだろうか。とりあえず32ビットと64ビットのモジュールの共存場合はこれらのポートをifdefで切り取ることにする。

• RV32RocketConfigで生成した32ビット版MulDiv

module MulDiv(
  input         clock,
  input         reset,
  output        io_req_ready,
  input         io_req_valid,
  input  [3:0]  io_req_bits_fn,
  input  [31:0] io_req_bits_in1,
  input  [31:0] io_req_bits_in2,
  input  [4:0]  io_req_bits_tag,
  input         io_kill,
  input         io_resp_ready,
  output        io_resp_valid,
  output [31:0] io_resp_bits_data,
  output [4:0]  io_resp_bits_tag
);

• MediumBoomConfigで生成した64ビット版MulDiv

module MulDiv(
  input         clock,
  input         reset,
  output        io_req_ready,
  input         io_req_valid,
  input  [3:0]  io_req_bits_fn,
  input         io_req_bits_dw,
  input  [63:0] io_req_bits_in1,
  input  [63:0] io_req_bits_in2,
  input         io_kill,
  input         io_resp_ready,
  output        io_resp_valid,
  output [63:0] io_resp_bits_data
);