opentitan
opentitan copied to clipboard
[dv/csr_utils] Fix handling of reset for rstmgr alert_info_ctrl
Description
When attempting to enable read checks for alert_info_ctrl in the rstmgr scoreboard we get a mismatch soon after a reset. On reset only bit zero of alert_info_ctrl should be cleared, but apparently the full CSR was.
Notice the rstmgr cpu_info_ctrl is similar, in that only the lowest bit is cleared on reset, and we have no problem doing read checks for it.
To diagnose this, enable read checks for this CSR in rstmgr_scoreboard and run a few iterations of the smoke test.
As @cindychip pointed out, the CIP infra resets every CSR, but in some blocks not all CSRs get the same reset. Unfortunately this is done in the dv_base_scoreboard's reset, so it would be hard to override it, since all actions of cip_base_scoreboard would also need to get overriden. Alternatively, dv_base_scoreboard could have a separate virtual function to just reset the ral models, which could be overriden by IP code.
I think this is too much to swallow at this point, and I would definitely move it to M2.5 Backlog. Opinions?
More details: both *info_ctrl CSRs have an index field, reset by POR, and an enable bit, cleared on any hardware reset. So their reset behavior is even more nuanced. There is sufficient unit tests dealing with this functionality, so it seems okay to postpone this until after 2.5.
Moved to M2.5.Backlog based on @matutem's feedback.
CC @msfschaffner
An update: there is a number of rstmgr CSRs that are reset only by POR, including alert and cpu_info_ctrl. It turns out all fields in these CSR are reset by POR, contrary to the previous comments. In any case, the behavior of these CSRs is adequately tested at the chip level, so there is no reason to think this is covering some block level bug.
There is an underlying problem in the underlying CIP and DV layers regarding reset: the CSRs have no information about which reset they are sensitive to, so upon reset all CSRs are cleared, and these POR-only CSRs will end up diverging from the actual hardware behavior.
I think the best approach will be to capture these CSR values before reset, and write the captured values back to the CSRs after reset. This can be done for V3 or M5.