default statement in case

If i put this statement (state_nxt = state at the very top of the always_comb, the default statement in 'case' is not required for it to not synthesize into a latch. Is this correct? Would you still put the default statement for simulation purposes and why?

Correct in general. Though you show two different things in your example: defaulting to state versus idle.

stanford said:

If i put this statement (state_nxt = state at the very top of the always_comb, the default statement in 'case' is not required for it to not synthesize into a latch. Is this correct? Would you still put the default statement for simulation purposes and why?

Code:

always_comb begin
state_nxt = state;
  case (state)
    .....
    ...
    // default: state_nxt = IDLE;
  endcase
end

Click to expand...

I have seen people have different opinion on this matter. Some say it increases readability. Some say they HAVE to use because of internal company coding styles.

The default case branch is there to prevent your FSM from locking up unto an unspecified state. In simulation, this can happen when X's get into your state variable. For synthesis, you want your FSM hardware designed so that it always moves from an unspecified state to a specified state. You don't want some random glitch locking up your FSM.

dave_59 said:

The default case branch is there to prevent your FSM from locking up unto an unspecified state. In simulation, this can happen when X's get into your state variable. For synthesis, you want your FSM hardware designed so that it always moves from an unspecified state to a specified state. You don't want some random glitch locking up your FSM.

Click to expand...

^
This becomes very important for synthesis when you have an FSM that does not have a power of 2 number of states. FSMs with 2, 4, 8, 16 etc defined states will never lock up due to entering an invalid state. It may lock up for other reasons (e.g. waiting for a signal that never happens due to jumping to the wrong state).

Synthesis optimization without enabling things like safe state-machines or similar options, may end up optimizing your 5 state FSM to let the last three states just cycle around between those three states with no way, other than a reset, to recover back into one of the 5 valid states.

The best thing to do is experiment with your synthesis tool and determine how if at all default is handled by the tool and what optimizations to an FSM it does for invalid states.

From what I've seen they don't all behave the same, which is why I typically add any invalid states to my FSM and just make them all go back to the IDLE state, I'd rather have less optimization than have an FSM that locks up. Now consider how many invalid states there are in a one-hot FSM and it will make one cringe. Another recent thread about code to detect that only a single bit is set becomes quite useful for detecting a one-hot FSM error with multi-hot bits or a no-hot bit detection.

ads-ee said:

This becomes very important for synthesis when you have an FSM that does not have a power of 2 number of states. FSMs with 2, 4, 8, 16 etc defined states will never lock up due to entering an invalid state.

Click to expand...

This is only true if you do the state encoding explicitly (and not as one-hot).
If you let the synthesis tool select the FSM coding, I think it is impossible to write generic source code to guarantee a safe behavior for the synthesized circuit. Modern tools will probably ignore the default case for unreachable states. You need to give it a "safe" directive/attribute or disable the automatic FSM detection/generation and code everything explicitly.
The "safe" directive/attribute is not default for the synthesis tools since it consumes a lot more gates.

There are some examples in the attached documents (they are old but should still be relevant).

- - - Updated - - -

Edit:
I replaced "LUTs" with "gates", because I now see that this is the "ASIC" section.

I would be cautious to conclude that explicit state encoding can prevent a FSM from being locked in illegal states. This might underestimate the tool's intelligence in optimizing seemingly unused logic and changing the state encoding on it's own. Better use safe encoding option, provided to compensate excessive intelligence.