-
Notifications
You must be signed in to change notification settings - Fork 20
Conversation
[does not compile yet]
still doesn't compile, and access_size.word depending on machine width and being the same as access_size.four in case of 32bit causes trouble
StateMachineMMIO.compile_ext_call_correct, but the files that need to satisfy the new assumptions of StateMachineSemantics still don't work
of StateMachineSemantics, everything compiles again
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.
Looking good to me. So the HMAC state machine you have doesn't include initial key set? I think thats fine, but the hardware state will not initially be initialised with the key value.
Are the bedrock changes local changes to support 8/16 bits? Do you think you will upstream them?
So far I've only modeled the SHA mode of HMAC, which does not need any keys (this is one reason I opened #840).
bedrock2 and its compiler don't know anything about MMIO -- they are more general, and work for any kind of external calls, so there's nothing to upstream into bedrock2 or the compiler, unless we think that the |
Ah ok, I presume the HMAC mode would be used in siliconcreator/ROM for verification but I haven't checked. |
All MMIO-related definitions are generalized to take a
nat
which has to be 1, 2, or 4 and indicates the number of bytes to be read or written.@blaxill can I ask you for a review? The most interesting file for you I guess is
HmacSemantics.v
: It defines the state machine against which I will prove the bedrock2 driver code, and I might soon bug you to prove some Cava code against it, so it would be good to agree on whether that file makes sense 😉Another interesting part is
StateMachineSemantics.parameters.ok
, which contains properties that should be true for any state machine describing a hardware module.