Forum Discussion
New ContributorState machine crashes (Cyclone II) - no idea why. How do I debug?
State machines usually crash because they entered into an illegal, undocumented state.
This can happen when an input signal that is sampled is either asynchronous, or poorly synchronized.
The signal goes to two separate parts of the state machine transition logic, and is interpreted as a H in one part, and a L in the other.
This can then cause a transition to an illegal state.
You don't show enough of your code to know how this might apply in your case. The module header, and how all input signals are generated, is necessary to know.
Quartus will on occasion re-encode the state machine in another form (usually one-hot) where each defined state is implemented as being encoded with just one state bit set. You need to look in your report files to see if this was done (or not). Doing this can be disabled by user control.
As you mention synchronous clock timing can also be a cause, but Quartus should be able to tell you which paths did not meet your 50MHz timing (if any).
Regular ContributorState machines usually crash because they entered into an illegal, undocumented state.
This can happen when an input signal that is sampled is either asynchronous, or poorly synchronized.
The signal goes to two separate parts of the state machine transition logic, and is interpreted as a H in one part, and a L in the other.
This can then cause a transition to an illegal state.
You don't show enough of your code to know how this might apply in your case. The module header, and how all input signals are generated, is necessary to know.
Quartus will on occasion re-encode the state machine in another form (usually one-hot) where each defined state is implemented as being encoded with just one state bit set. You need to look in your report files to see if this was done (or not). Doing this can be disabled by user control.
As you mention synchronous clock timing can also be a cause, but Quartus should be able to tell you which paths did not meet your 50MHz timing (if any).
migry_techDear @ak6dn, thank you. I think that a penny might have dropped.
> The signal goes to two separate parts of the state machine transition logic, and is interpreted as a H in one part, and a L in the other.
Bingo!
There are indeed inputs from other clock domains going into this state machine. Although in this case the state machine is only swapping between IDLE and PIXELREAD, the state transition could still be affected (corrupted) by other inputs to the state machine. I forget that each path (from all inputs) to each (of the 8) state flop comes from different logic cones, and a transition (e.g. CPU write -> SRAM write request) near the 50MHz clock edge could reach some state flops in time, and not others! This also explains that when I changed the localparam STATE values (sparsely coded) the crashing behaviour changes, sometimes becoming more stable sometimes not.
I am certainly aware of *some* of the issues that can arise from signals crossing clock domains, but clearly I have much more to learn. I need to cerfully review all asynchronous inputs to the state machine and try to understand how I can make their re-sampling safe.
Thank you! Many thanks for taking the time to reply! You have given me hope! 😀
BTW I was really concerned about glitches on the core power supply, but when I scoped (and used a short gnd connection) the trace was very clean where the state machine crashed.
--migry
