[hmac,dv] Allow reset w/o CSR accesses complete

[martin-velay]

• This PR is a temporary fix to allow the reset to complete without waiting for complete CSR accesses. This is done by setting the flag can_reset_with_csr_accesses to 1 in the env_cfg file. Ideally, this should go away once the a better reset approach will be in place via a reset agent.
• The approach here is to try to exit ASAP from all the tasks to skip the CSR accesses.

[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.

[martin-velay]

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.

@rswarbrick, this fix is not linked to the "outstanding access" issue. The error seen here was something like: UVM_ERROR @ 540230991 ps: (hmac_scoreboard.sv:534) [uvm_test_top.env.scoreboard] Check failed item.d_data == csr.get_mirrored_value() (4 [0x4] vs 0 [0x0]) intr_state. Now this error is gone, but as you said maybe this will cause some "outstanding access". But I am not going to mix it with this PR.

[rswarbrick]

Sorry: what I mean is that the processes in the fork will start CSR operations. If a reset happens to appear in the intervening time then the wait will complete in reset_thread and the disable fork will kill a sequence that's doing a TL access. This will cause things to come unstuck in rather confusing ways, which is why cip_base_vseq (without my flag) tries quite hard to avoid issuing the reset and killing the sequence when there is any TL operation in flight.

My proposed solution is a way to "complete the operation quickly". A lame temporary approach would be something like a delay just after the wait, which would let any pending CSR operation abort... (It's a bit lame though! I'm not keen! :-D)

[marcelocarvalhoLowRisc]

I think this is a similar issue we had faced in the GPIO, during some rnd_reset_stress_all test.
#25657