[rv_dm] Access to debug ROM space hangs when HW debug en is not set

[sriyerg]

Associated logic in hw/ip/rv_dm/rtl/rv_dm.sv:

  logic rom_en;
  assign rom_en = (lc_hw_debug_en[EnRom] == lc_ctrl_pkg::On);

rom_en is wired up to gnt_i of the tl_adapter_sram. When lc_hw_debug_en is not set, the access to ROM hangs the bus since the gnt_i never gets asserted.

Seems benign, but should this be handled more gracefully as a bus error?

[msfschaffner]

This is related to other LC-gated TL-UL interfaces, like the one in OTP_CTRL, see #11296.

@tjaychen should we in general handle these more gracefully and return a bus error in all these cases?

CC @zi-v

[tjaychen]

yeah looking back on this, it would be better to have this be more graceful.
We do have the reset crash dump mechanism to let us know roughly where things hung, but that's not really a nice software experience.

As you guys pointed out, probably best to remove rom_en from the grant line.

[msfschaffner]

Ok I'll look into that. Might be worth making a tlul_lc_gate component for this, since it can be reused accross IPs (maybe even sram_ctrl?).

[tjaychen]

Ok I'll look into that. Might be worth making a tlul_lc_gate component for this, since it can be reused accross IPs (maybe even sram_ctrl?).

would this cause more churn on those blocks though? they've already reached v2s right?
I guess what i'm trying to say is that it would be nice to have a better experience, but this doesn't seem like a deal breaker to me at this moment in time.

[msfschaffner]

Yeah that is right - we should probably not touch sram_ctrl at this point.
The situation is a bit different for sram_ctrl anyways, since that one only clamps down when escalating, and not during normal behavior.

As for rv_dm, DV has not progressed to V2 yet and we will have to do a vendor-in anyways due to some missing features that just have been merged (see #11095). So changing it there is probably fine.

For otp_ctrl it depends on how we decide on @zi-v's hardening request here #11296. However, it should be a relatively localized change.

[tjaychen]

yeah for otp_ctrl i guess i'm not sure how much you guys have tested the test access interface already.
Because Ziv's enhancement hardening request I think does not change DV modeling behavior, but switching from a hang -> explicit error does. You guys will be able to judge better than I can there.

[msfschaffner]

Indeed, the hardening part should not functionally change anything.

As for the error behavior, I'll check with @cindychip what the impact would be.

[cindychip]

Should be easy to handle on OTP DV. Thanks Michael for checking.

[sriyerg]

IM good with fixing RV_DM design as well.

[msfschaffner]

This should now be fixed.

@sriyerg can you close this bug once this has been verified?

[msfschaffner]

@sriyerg can this bug be closed?

[sriyerg]

I have not verified the fix yet. Please close it if you like though.

[tjaychen]

changing assignee for now since only verification remains at the moment.

[msfschaffner]

Closing this for now. Please reopen the bug if the issue still persists.