[dv/rstmgr] Apply different reset kinds where applicable

[matutem]

Most unit tests use the default apply_reset kind argument. The rstmgr unit has both AON and non-AON domain components, so the apply_reset distinction is important. One way to exercise it could be to call apply_reset with a randomized kind argument between rounds of various tests.

estimate 8

[sriyerg]

Please see example:

opentitan/hw/ip/rv_dm/dv/env/seq_lib/rv_dm_base_vseq.sv

Line 57 in 82278f9

if (kind inside {"HARD", "TRST"}) begin

For rv_dm I defined 3 different reset strings with the same goal as yours - be able to apply different kinds of resets randomly and verify expected behavior.

[andreaskurth]

Triaged for pwrmgr. Assigning to M2.5 with Priority:P2 Priority: medium because this would increase coverage around resets, which IMO is relevant.

[GregAC]

Triaged for rstmgr, agree with @andreaskurth

[GregAC]

Estimate range: 4 - 8

[andreaskurth]

Triaged for clkmgr (sorry this somehow slipped my filters), agreed on Priority:P2 Priority: medium

[msfschaffner]

Discussed with @matutem - this seems to be a coverage closure exercise that can be done after M2.5.
We have many TLT's that already stress the interconnected reset behaviors of the *mgr's.

[matutem]

I undated the issue to state it only applies to rstmgr, not clk or pwrmgr.

[matutem]

In rstmgr_reset_vseq we apply random resets, which include hard (aon) and regular resets, so this issue can be declared complete.