[dv] FSM transition coverage

Problem

These 2 types of transitions aren't easy to be covered in regular function tests as raised in #14028

• any state -> reset
• any state -> error in the sparse_state_fsm

any state -> reset

Approach 1

If we want to ensure that the FSM goes back to reset state when reset happens, RTL lint tool can check it. @msfschaffner has done some experiment - enable an AscentLint rule in the lint policy file and it can catch any FSM that doesn't have a reset. If we agree that FSM must always associate with a reset, we could enable Lint to check this.

On the DV side, VCS provides a way to exclude FSM transitions that can only happen on reset. This PR #14360 adds a build option and a configuration file to enable this capability. Since it only excludes FSM transitions that can only happen on reset, user still needs to test the transition to reset if it could be caused by other condition, which is good to test.

Once both Lint and DV flow is set up, block maintainer doesn't need to write any test to cover it.

(Need to enable this for Xcelium if we choose this approach.)

Approach 2

Scenario:

send a normal sequence -> in a parallel thread, after random delay (before the sequence completes) issue reset and kill the sequence -> read all CSRs to check -> restart another normal

We have a test - stress_all_with_rand_reset, which creates a parallel thread to issue reset at any time along with all sequences. It mimics a scenario - reset button is pushed any time when the chip is operating, and check it works again after reset.

But this test doesn't guarantee the reset happens at all the states. Some states may last only a few cycles, which would be extremely hard to hit. We may need to tune the timing of the reset, in order to hit all the transition, which could be really timing consuming but not a lot of reward.

Approach 3

Scenario:

forcing FSM to any state -> issue a reset -> start the regular sequence

This is much easier than approach 2, but seems like it doesn't cover more than the lint tool does. It essentially tests FSM must have a reset.

This requires each block maintainer to their own test.

any state -> error in the sparse_state_fsm

In the common sec_cm test, we only test idle -> error, but we run FPV to prove any state -> error unconditionally leads to a fatal alert.
Since any state can transition to error state, it's also very time consuming to cover all these transition in simulation. And FPV already tests that, so it could be safe to exclude these transitions manually. There is probably no automatic way to exclude them.

Start by reading the existing stress_all_with_rand_reset test, the common sec_cm test, and the FPV proof referenced in the issue, then review the coverage approach in #14360 and the lint-policy experiment. Done requires an agreed approach for reset and sparse_state_fsm error transitions, followed by the corresponding DV, lint, or exclusion changes and evidence that coverage is handled without redundant tests.