[chip,dv] Full chip rand_reset test needs improvement

[jdonjdon]

Description

Generic template for {block}_*_with_rand_reset replies on inface based reset function as in here

This works well with block level but in full chip, test needs more improvement to mimic real chip behavior. Currently apply_resets_concurrently() function drive por_n and all interface attached resets, which are inactive mostly. To provide more stress, apply_resets_concurrently() function needs to do followings.

• Stop driving interface attached reset (including por_n)
• Trigger reset event using pre-configured alert handler
• Keep AON clock alive

[jdonjdon]

cc: @matutem

[matutem]

To provide more context, the apply_reset task variants as it is make no sense for full chip. It would be much better to cause either POR, LC, or SYS resets via pins or other chip functionality, since all resets are driven internally, except for external reset. Continuing to use the current mechanism is just an invitation to hack upon a bad foundation. I think we may want to change apply_reset HARD by flipping external reset, lc reset could be accomplished by fatal error injection, and sys reset via rv_dm, for example.

[moidx]

Discussed in triaging meeting. Moving to M5 to get feedback from @matutem on next steps.

[matutem]

A change like this is inconsistent with keeping the tapeout branch very stable, so Earlgrey-PROD.M7 doesn't seem practical.