[prim_sha2_pad, hmac] Don't allow skipping the padding after stopping a hash operation

[vogelpi]

Description

During coverage closure for V2S, @martin-velay and @gdessouky noted that there are some uncovered FSM transitions inside prim_sha2_pad:

• StLenHi -> StFifoReceive
• StLenLo -> StFifoReceive
• StPad00 -> StFifoReceive
• StPad80 -> StFifoReceive

An inspection of the RTL reveals that these transtions can be covered by something like the following sequence:

1. Trigger and message and make prim_sha2_pad go into any the StPad80 / StPad00 / StLenHi / StLenLo states. As a result of this cfg_block will assert and any future reg_hash_start / reg_hash_continue won't be forwarded to prim_sha2_pad.
2. Trigger a reg_hash_stop. This will make cfg_block go low again in the next clock cycle.
3. In the next clock cycle, trigger again a reg_hash_start / reg_hash_continue. This will trigger the uncovered transition.

The problematic thing with this is that after Step 2, the design should finish the hashing and then append the padding. By triggering another reg_hash_start or reg_hash_continue, software can cause the hardware to abort the padding and restart the hashing. This is not intended behavior, but software is also not expected to start another operation directly after stopping one. Instead, software is expected to wait for the hmac_done interrupt or to poll the status register to wait for the hashing and padding to finish before triggering further operations as outlined in the HMAC programmer's guide .

@andreaskurth and I concluded that this is NOT a terrible bug for Earlgrey-PROD and we will exclude the missing / buggy transitions from FSM coverage. But we should still fix this in a future release. The FSM should only be able to go back into the StFifoReceive state after finishing the padding.

[vogelpi]

For more details, please refer to this comment.

[vogelpi]

PR #25590 which removes these undesirable FSM transitions has been merged into master now and I am thus closing this issue.

PR #25696 will remove the corresponding coverage exclusions on master. We have been doing these changes for the D3/V3 sign offs.

For earlgrey_1.0.0 the RTL and also the coverage exclusions remain untouched. If the design is operated according to the programmer's guide, there is no issue. As previously stated, triggering these previously uncovered FSM transitions is tricky if not impossible by software as it requires multiple commands to be triggered back-to-back without a single bubble cycle in between. It's extremely unrealistic to trigger this.