-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[sw, otbn] Align OTBNsim with the latest MAI RTL implementation #30623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,7 +7,7 @@ | |
| from .constants import ErrBits, LcTx, Status, read_lc_tx_t | ||
| from .decode import EmptyInsn | ||
| from .isa import OTBNInsn | ||
| from .state import OTBNState, FsmState | ||
| from .state import OTBNState, FsmState, WIPE_CYCLES | ||
| from .stats import ExecutionStats | ||
| from .trace import Trace | ||
|
|
||
|
|
@@ -433,6 +433,10 @@ def _step_wiping(self, verbose: bool) -> StepRes: | |
| was_wiping = self.state.wipe_cycles > 0 | ||
| if was_wiping: | ||
| self.state.wipe_cycles -= 1 | ||
| # Step the URND Bivium every wipe cycle, matching the RTL where prim_trivium | ||
| # runs continuously. This keeps the Bivium in sync with the RTL so that the | ||
| # MAI's cnt bits captured in on_sec_wipe_zero_step() match in_cnt_load_val_q. | ||
| self.state.wsrs.URND.step() | ||
|
|
||
| is_good = not self.state.lock_after_wipe | ||
| locking = self.state.rma_req == LcTx.ON or not is_good | ||
|
|
@@ -469,6 +473,29 @@ def _step_wiping(self, verbose: bool) -> StepRes: | |
| else: | ||
| self._delayed_insn_cnt_zero(1) | ||
|
|
||
| if self.state.wipe_cycles == WIPE_CYCLES - 97: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This magic number is prone to errors if WIPE_CYCLES ever changes. And I think this error is hard to catch. Can we solve this in a different way?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we just check for
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The wipe_cycles are counting down. So I wrote it this way such that if |
||
| # Corresponds to the RTL cycle where sec_wipe_mai_i (= sec_wipe_zero_o) | ||
| # fires, which is when the FSM enters OtbnStartStopSecureWipeAllZero after | ||
| # completing the three register-overwriting phases: | ||
| # | ||
| # OtbnStartStopSecureWipeWdrUrnd: 33 cycles (32 WDRs + 1 ACC timing) | ||
| # OtbnStartStopSecureWipeAccModBaseUrnd: 32 cycles (ACC, MOD, base regs) | ||
| # OtbnStartStopSecureWipeExtIsprsUrnd: 32 cycles (MAI ISPRs + reserved) | ||
| # = 97 URND-advancing cycles total | ||
| # | ||
| # The URND value seen by the MAI at that moment is not the raw prim_trivium | ||
| # output but the registered copy one cycle behind it (otbn_rnd.sv: | ||
| # urnd_data_q <= key_o, registered each posedge). So in_cnt_load_val_q | ||
| # captures the Bivium output from step 97, not step 98. | ||
| # | ||
| # In the ISS, _WIPE_CYCLES = 100 and wipe_cycles decrements once per step, so | ||
| # after 97 steps wipe_cycles = 3. At that point _next_value holds the step-97 | ||
| # Bivium output, matching what the RTL latches into in_cnt_load_val_q. | ||
| final_wipe_round_cnt = (self.state.wipe_rounds_done == | ||
| (self.state.wipe_rounds_to_do - 1)) | ||
| if final_wipe_round_cnt: | ||
| self.state.mai.on_sec_wipe_zero_step() | ||
|
|
||
| if self.state.wipe_cycles == 1: | ||
| # This is the penultimate clock cycle of a wipe round. We want to | ||
| # model the behaviour that we expect "at the end of a wipe round". | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a raw value? Does this model the operation value before the validity check is done?
I'm not sure yet but I think previously the simulator did raise a MAI_ERROR as soon as an invalid operation value was written to the CSR. The hardware however only raises the error when an execution is started with an invalid operation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes because there's values that don't map to any operation. The raw bits are needed to check for invalid operations.