[otbn,dv] Model a glitch on the STATUS register #24569
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a problem problem that was visible in the otbn_escalate test. It is caused by the design bug that is tracked in issue #23903. The one cycle glitch wouldn't be a big deal but we might be really unlucky and read the register at just the wrong time!
The change in sim.py changes otbnsim to correctly model the design's behaviour, with a whopping great TODO message that explains how to undo the change again.
However tracking down whether this fixes everything found that this doesn't completely fix the
otbn_escalate
test, which still occasionally fails! Delving into the problem carefully, you find that the model's status signal (represented asstatus_q
inotbn_core_model.sv
) normally changes at the same time as the register top'sstatus_qs
signal. This is reasonably sensible, and means the timing in the scoreboard matches things correctly if we read from STATUS. Unfortunately, the model's signal changes state a cycle earlier, at the same time asstatus_q
, for some status changes (in particular, the changes that you get when you start to lock after an RMA request). This means that there is another window where an unfortunately-timed register read will get the wrong value!Fixing this needs a bit of an overhaul of the logic in otbnsim. The simplest fix is probably to make it the modelled status signal change earlier and then to register the value and recreate
status_qs
inotbn_core_model.sv
.