[hmac,dv] Various assertions

[martin-velay]

Description

Here below is the list of potential assertions to be added to the DV

Note: is to be discussed

STATUS	NAME	DESCRIPTION (extracted from the spec)
TODO	Wipe secret key	The secret key could be wiped from several internal RTL registers such as secret key, internal state machine, or hash value. Internal values are replaced or XORed with the written value in WIPE_SECRET register.
M7 backlog	HMAC core block FIFO size	HMAC core contains a 32x32-bit size FIFO
M7 backlog	SHA-2 block FIFOs sizes	SHA-2 block contains two time a 8x64-bit size FIFOs (one for the hash and one for the digest)
Done in UVM	Message endianness swap	When CFG.endian_swap=1, input message is converted from little-endian to big-endian before feeding it to the SHA-2
Done in UVM	Digest endianness swap	When CFG.digest_swap=1, each digest output register is converted to big-endian byte order
M7 backlog	HMAC extra latency	HMAC should introduce a latency equals to 240 extra cycles
Done in UVM	Digest clear	DIGEST registers should be cleared when transition 1->0 on CFG.sha_en
Done in UVM	DIGEST registers write	DIGEST registers should be writable when CFG.sha_en=0, check also that they cannot be written when CFG.sha_en=1
Done in UVM	Message length	The received Message Length calculated by the HMAC should match with these registers value such as: message_length[63:0]={MSG_LENGTH_UPPER, MSG_LENGTH_LOWER}. In SHA-256 mode all 64 bits are used, but in SHA-384/512, upper 64 bits are zero padded and only {MSG_LENGTH_UPPER, MSG_LENGTH_LOWER} are actually checked.
TODO in UVM	MSG_LENGTH registers write	MSG_LENGTH registers should be writable only when CFG.sha_en=0, check also that they cannot be written when CFG.sha_en=1
M7 backlog	MSG_LENGTH_LOWER register LSBs	Message length granularity should be in bytes, and these registers express it in bits, so the 3 LSBs from MSG_LENGTH_LOWER should be always zeros
Done in UVM	INTR_STATE.fifo_empty register field	FIFO empty status interrupt

[andreaskurth]

@martin-velay: Also for this issue: V3 and M7?

[martin-velay]

@andreaskurth: yes we can move it

[martin-velay]

In the list above, some assertions are already covered by the DV, should be covered within the UVM env and some others are not really important. Here are the related issues:

• M7 backlog (no mandatory as not really important): https://github.com/lowRISC/opentitan/issues/24364
• For M7 but as UVM check instead of assertion: https://github.com/lowRISC/opentitan/issues/24363

Finally only one assertion would be best to have as part of M7: "Wipe secret key"