[otbn,sim] Extend the OTBN simulator with the KMAC interface#30386
[otbn,sim] Extend the OTBN simulator with the KMAC interface#30386etterli wants to merge 3 commits into
Conversation
8d696cb to
118baff
Compare
|
A rudimentary adaption of the ML-DSA XOF driver works in the simulator with this new KMAC interface. Let me know how you wanna proceed once this is getting ready to be merged. |
andrea-caforio
left a comment
There was a problem hiding this comment.
The good news is, it functions correctly and the ML-DSA runs without problems. But I'm not sure if this kind of complexity is really needed (see comment below).
| # applies to SHA3. SHA3 used as a XOF is non standard but the HWIP does not | ||
| # forbid it and just keeps squeezing until DONE. | ||
| if self._app_mode == _Mode.SHA3: | ||
| # TODO: pycryptodome only provides the fixed length SHA3 digest, so we |
There was a problem hiding this comment.
The KMAC block allows this, non-standard SHA3 digest? What is the application for this?
There was a problem hiding this comment.
Yes it does. I have no clue why. I just tried to match the simulator as good as possible. But I think the best option is to disable this in the KMAC itself.
| self._csrs.KMAC_STATUS.hw_set_rsp_valid(rsp_valid_d) | ||
|
|
||
| # Advance the FSM model | ||
| self._state = state_d |
There was a problem hiding this comment.
I'm wondering if the emulation of the RTL behavioural model is appropriate for Python code? Doesn't it make the implementation more complicated? If you compare it to the previous implementation (which mostly doesn't use this technique), it is much more complicated even though the actual adjustments I had to make in the ML-DSA driver were rather minimal.
There was a problem hiding this comment.
This needs cleanup, I agree. It stems from an initial implementation where I modeled the actual KMAC interface such that later the UVM framework can 'easily' inject the responses coming from the KMAC DV agent. But this is now postponed, so I think the simulator should be simplified.
|
I have now cleaned up the simulator. |
15f51ae to
ec290b6
Compare
| # Create a tuple key using the Enums | ||
| class _Mode(IntEnum): | ||
| SHA3 = 0 | ||
| SHAKE = 1 |
There was a problem hiding this comment.
Is this intended that the SHAKE enum is now 1 when it was 2 before? Same for CSHAKE.
There was a problem hiding this comment.
Yes because previously it used the encodings how Ibex SW writes to the configuration register. But the app interface uses a different encoding. See
opentitan/hw/ip/kmac/rtl/kmac_pkg.sv
Lines 200 to 206 in 5fd609c
thommythomaso
left a comment
There was a problem hiding this comment.
Thanks @etterli. I had one question regarding the enum values.
andrea-caforio
left a comment
There was a problem hiding this comment.
Very nice. @etterli This is much cleaner now and easier to parse.
This extends the OTBN simulator by the KMAC interface. The KMAC interface is only supported for standalone simulator use. It is not yet possible to do a RTL co-simulation. Signed-off-by: Pascal Etterli <pascal.etterli@lowrisc.org>
Signed-off-by: Andrea Caforio <andrea.caforio@lowrisc.org>
It also removes an obsolete OTBN-KMAC interface test. Signed-off-by: Andrea Caforio <andrea.caforio@lowrisc.org>
nasahlpa
left a comment
There was a problem hiding this comment.
Thanks Pascal.
I mostly had a look into the adaptions in the OTBN snippets. It would be good if somebody with more OTBN simulator experience could have a look into that part as well - maybe @h-filali or @thommythomaso?
This is a first draft of the OTBNSim KMAC interface implementation.
Only the last commit is relevant. Others are from: