--- Quote Start ---
The code for the FSM (with the addition of the "default:" in all case statements) as suggested by jacobjones should work.
--- Quote End ---
As far as I see, no default state is yet implemented for state2. Generally, without forcing safe state machine synthesis, you shouldn't make assumptions about behaviour in illegal states. Also, as long as you don't specify an explicite FSM processing, one state hot is the default coding style for any state machine recognized by the compiler. This implies additional possible illegal states outside the expected binary state variable number range. Safe state machine or explicite state encoding is the only way to avoid this issue.
Furthermore, I realized that the FSM code in the original post isn't representing a full design, because it hasn't any output. Thus I wonder, if any details of the real design, omitted in the post, may cause the discussed problem. To be sure about, I would like to see a full design that still reproduces the issue.
P.S.: Regarding the RESET discussion, I agree that driving the SELF_RESET logic from a different clock basically causes an asynchronous reset, that may cause a FSM to change to an illegal state at worst case. Thus the reset should be better synchronized to the FSM CLK by usual means. But this issue can't explain a FSM failure after correct initial startup.
Honored Contributor
