[dv/clkmgr] Test different rst_io* and rst_root_io*

[matutem]

Description

clkmgr has rst_io_ni, rst_io_div2_ni, and rst_io_div4_ni. Similarly it has three rst_root_io*. The testbench hooks them all to the same interface.

We should hook these to different interfaces and create simple tests that send different stimuli to each in order to verify they behave as expected.

This seems like a low priority test since the functional differences between them are pretty simple.

[andreaskurth]

We should check whether rstmgr releases all of those at the same time -- if it does, we can defer this to future release

[matutem]

They are by rstmgr released at slightly different times. All the corresponding clocks must be running, and the parent reset is sync'ed to the corresponding clock, so they are off by a 0 through 3 cycles of the 96 MHz io clock.

• The parent reset of the rst_por_* resets is rst_por_aon_n[DomainAonSel]
• The parent reset of all rst_lc_* resets is rst_lc_src_n[DomainAonSel]

The rstmgr rst_por_* resets are named rst_root_* in clkmgr:

• rst_root_io_n resets both clock dividers, so the divided clocks are pretty much in-phase
• each rst_root_* starts/stops some derived clock and drive the clock status outputs to pwrmgr
  • pwrmgr waits for all clock status' to be up for a specific state transition, so their arrival time is not important
  • the chip is quiescent while any rst_root is active, since it is coming out of POR

The rstmgr rst_lc_* resets are named rst_* in clkmgr:

• they control the corresponding clock measurement counters and corresponding CSRs
  • clock measurement is intrinsically tied to a specific clock, and it is not important if they start counting at slightly different times
• they control the clocking group enables for alert handler
  • these control the outgoing pings, and pings are sent after some number of cycles from when they are enabled and can be considered asynchronous

It seems the small number of cycles between when these resets toggle will not present any issues. I would be comfortable deferring this to a future release, in case some of the rstmgr behavior changes, or there is additional logic driven by these resets.

[andreaskurth]

triaged to backlog according to the arguments by @matutem and as we're separately verifying CDC and RDC