[csrng/dv] Tweak assertion control in csrng_intr_vseq #28455
Conversation
This commit addresses a rare dv failure that was caused by turning some assertions too early on again in csrng_intr_vseq. At the same time, the commit reduces the window in which assertions get disabled at all to the part of csrng_intr_vseq which tests the fatal_err interrupt. This is the only part that uses fault injection, thereby potentially triggering the assertions in question. Signed-off-by: Florian Glaser <[email protected]>
glaserf
requested review from
hcallahan-lowrisc
and removed request for
a team and
hcallahan-lowrisc
| `DV_ASSERT_CTRL_REQ("CmdStageFifoAsserts", 0) | ||
|
|
||
| // Test cs_fatal_err interrupt | ||
| test_cs_fatal_err(); |
There was a problem hiding this comment.
The fault-injecting test_cs_fatal_err() ends here, where previously the CsrngCmdStageGenbitsFifoPushExpected_A assertions were turned back on already, while the vseq waits for another 50 clock cycles below before disabling the CSRNG, thereby preventing the asserts in question.
During this time, data items in the FIFOs resulting from forced signals during fault injection could propagate through the data path, eventually arriving at the command stages and erroneously triggering CsrngCmdStageGenbitsFifoPushExpected_A assertions.
There was a problem hiding this comment.
This makes sense, and thanks for figuring out what was going on.
Definitely not urgent, but a nice follow-up might be to tweak the assertions we're disabling so that they pick up a new "unused_assertion_disable" signal and OR it in with the rst_ni argument to the macro. Then the virtual sequence can just set and clear the signal and doesn't need a list of the assertion names.
Absolutely, thanks for the suggestion! |
2 participants
This commit addresses a rare dv failure that was caused by turning some assertions too early on again in csrng_intr_vseq.
Prior to the change, stray data items, injected into the data path pipeline through forcing FIFO-
wvldsignals during fault injection, sometimes triggered theCsrngCmdStageGenbitsFifoPushExpected_Aassertions in the command stages several cycles aftertest_cs_fatal_err()was already completed but before the main vseq routine disabled the CSRNG again. This was happening becausetest_cs_fatal_err()takes care of disabling the assertions in question, but re-enables them upon returning to the 'main' vseq which then waits for another 50 clock cycles before fully disabling the CSRNG with a CSR/RAL access, thereby preventing any further assertion triggering.At the same time, the vseq disabled some asserts too early where this really wasn't necessary, as the sub-tests do nothing that would trigger any assertions. I therefore also moved disabling the assertions to a later point in the vseq.
For further details, please see my review comment.