"when" is not working

Type of issue: bug report

Impact: unknown

Other information

I use the chipyard v1.3.0, and change some code in the BOOM generator. As usual, the when condition will check the default value. But I find that one of my when blocks didn’t work. I havn’t assigned the default value, but it didnot report a error like “Reference io is not fully initialized”. My code:

for (i <- 0 until numReadPort){
    when(delogic.io.zeroDetectOut(i).resZero){
      io.wp(i).iresp.bits.data := 0.U
      io.wp(i).iresp.valid := io.rp(i).req.valid && !IsKilledByBranch(io.rp(i).brupdate, io.rp(i).req.bits.uop)
      io.wp(i).iresp.bits.uop := io.rp(i).req.bits.uop
      io.wp(i).iresp.bits.uop.br_mask := GetNewBrMask(io.rp(i).brupdate, io.rp(i).req.bits.uop)
    }
  }

I see the verilog it generated, and find it just like “when(delogic.io.zeroDetectOut(i).resZero)” was not exist. It does not use any mux. For example:

  assign io_wp_0_iresp_valid = io_rp_0_req_valid & _T_36; // @[MultiPortExeUnit.scala 84:28:chipyard.TestHarness.My6WideBoomConfig.fir@406003.6]

The _T_36 just equal to “!IsKilledByBranch(io.rp(i).brupdate, io.rp(i).req.bits.uop)” in Chisel.

If the current behavior is a bug, please provide the steps to reproduce the problem: I try some other simple conditions, but they worked well. Maybe it only show up in big projects.

[jackkoenig]

The issue is that your module (named MulExeUnit) extends MultiPortExeUnit (also your module) which extends BoomModule which extends rocket-chip’s CoreModule which extends Module but uses import Chisel._. Unfortunately, when using inheritance, it is the Module at the top of the inheritance tree that sets the behavior of whether or not signals are invalidated by default.

This is unfortunately intended behavior, ideally either rocket-chip would stop doing import Chisel._, or other projects would not inherit from its Modules.

Thinking about this more, we probably should have made the stricter connection semantics bind on definition of the signal (eg. val io = IO(...)) rather than the declaration of the module (which we can only do at the top of the inheritance hierarchy, ie. we can only associate information about which import is used where the extends Module code is located). This would be a hard thing to change as this point as it could potentially break a lot of otherwise working code, but it’s worth considering.

[lxu28973]

Yeah, this is the problem. Thank you veay much!