[hmac,dv] Kill S&R process when reset is asserted

[martin-velay]

• there was a mismatch on hmac_err intr_state between the RTL and the DV environment. The DV environment was not taking into account the reset signal to stop the S&R process. This was causing the DV environment to skip an hmac_err. Now, sar_skip_ctxt signal is zeroed and the S&R process is stopped when the reset signal is asserted.
• linked to : [hmac,dv] intr_state TB issue #24691

[rswarbrick]

Hmm, I'm not sure that's quite going to work. I think that e.g. sar_stop_and_continue calls csr_spinwait. What happens if a reset appears when we're half-way through the call?

I think the fix is probably to make it so that each of the sar_* functions exit early if they see a reset, then exit early after they have completed.

[martin-velay]

Hmm, I'm not sure that's quite going to work. I think that e.g. sar_stop_and_continue calls csr_spinwait. What happens if a reset appears when we're half-way through the call?

I think the fix is probably to make it so that each of the sar_* functions exit early if they see a reset, then exit early after they have completed.

@rswarbrick
If I am not wrong, the disable fork will kill all the descendants, which means all the sub-tasks/functions initiated by one of these process. Is it clearing your doubt?

[rswarbrick]

I think that will run into the original problem that caused all of this "outstanding access" tracking in the first place. The problem is that killing a sequence in the middle of a CSR operation leaves things in an inconsistent state.