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).
New ContributorHere is a photo of the scope screen, showing the state machine crash.
D0 is at the top with D7 at the bottom, so reads upside-down.
Each blip of D0 is where the state machine goes to state 00000001 to read a byte from the SRAM, and you can see the resulting chip select going to the SRAM.
You can see the unexpected 11000000 state, which is detected by the verilog default case and goes to a spedcial "ILLEGAL" value of 11111111, where it stays. This was added to allow debugging, and shouldn't be necessary if everything was working correctly.
There are some states which start 1100... No idea if this is a clue.
