Stuck with low FSM transition coverage

So from idle state, append vectors that touch what's presently
untouched? How else would you increase coverage?

If the simulator says there's a "path" why do you disbelieve it?

matrixofdynamism said:

Here is a sample output from my coverage report:

View attachment 179635

For this module of interest, the state machine transitions like shown below every time. It spends one clock in each state except the IDLE state. It waits in IDLE state until a control signal is asserted.

IDLE -> CALC_RAMP_DIST -> EVAL_SPEED_PROF -> CALC_RD_START_STEPS -> IDLE

What confused me is why does the tool expect a path from the middle two states (CALC_RAMP_DIST and EVAL_SPEED_PROF) into IDLE when none exists. I then used the -fsmverbose flag in QuestaSim and found out that a path exists to IDLE state from these when reset is applied. This because when reset is applied, the state machine always goes into the IDLE state, regardless of what state it was in when reset was applied. This brings me to my problem.

Why does the tool require coverage into idle state from the middle states when the only way to get there is to apply reset? Shouldn't these transitions be excluded since they will never occur under "normal" circumstances and only when the design is put into reset? This problem is plaguing the FSM transition coverage in all parts of the VHDL RTL code.

Click to expand...

if a reset takes the SM to IDLE from any state then probably the tool is indicating that, that ARC is not covered

There are a large number of state machines inside the design. For all of them there is a state (lets call it IDLE) that the state register is assign when reset signal is asserted. I have chosen one of the FSMs that is simple to explain the problem.

The state machine in the OP is designed to do this:
IDLE -> CALC_RAMP_DIST -> EVAL_SPEED_PROF -> CALC_RD_START_STEPS -> IDLE

It will only enter the IDLE state after the CALC_RD_START_STEPS state. However, reset can happen at any time and force the FSM to go into IDLE state from any other state. However, the point is that transition into IDLE because of reset from any state is not going to happen during normal operation. What I expect the coverage tool to do is to tell me if the above states and the mentioned transitions are exercised.

If I need to cover the path from *every* state into IDLE by applying reset for all the dozens of states, that is not practical since I cannot time the reset signal to be able to hit every state in every state machine to force it into IDLE state. But why should that be required when that is not the design does during its operation? I mean reset is not exceptional event, not ever part of normal device operation.

Do I add some sort of exception?

If your device is an ASIC or a fuse based FPGA, your device can power up in any random state, and then reset is applied taking the statemachine to idle. How do you assure that reset actually works? What if reset to one of your statemachines was connected incorrectly?

If your device is controlling anything safety related I would certainly expect to get transition coverage on all of these paths.

matrixofdynamism said:

If I need to cover the path from *every* state into IDLE by applying reset for all the dozens of states, that is not practical since I cannot time the reset signal to be able to hit every state in every state machine to force it into IDLE state. But why should that be required when that is not the design does during its operation? I mean reset is not exceptional event, not ever part of normal device operation.

Do I add some sort of exception?

Click to expand...

Never, never, never assume that "operation" will be forever "normal".

There's EMI, there's atmospheric neutrons (SEU) at high elevation,
there's bad sensor data, all kinds of things that a design-forward
(synthesized?) test vector set has no ideas about.

Many "state machines" including simple feedback counters can
synthesize with "hidden states" that do not exit the way you'd like.
You can have "blind loops" which circulate without exiting back to
normal sequence. You should challenge yourself regarding the
constructs you receive from your high level code, such as "well,
-what if- my /10 counter got kicked to states #B, #C, #D, #E, #F?".

It only takes one synthesized block with this kind of trap, to give
you a field failure problem that will wrap you around the axle
and go rock crawling.

It's also the case that blocks with this kind of construction, tend
to have untestable logic states, so don't dismiss such warnings
out of hand. It may be trying to tell you, as best it's able.