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 ContributorTypically any inputs that are not fully synchronous to the state machine clock must go thru a dual-rank synchronizer (google) so that the output signal will be stable in the state machine clock domain. Just requires a couple of registers per async signal.
migry_techThank you once again @ak6dn for replying to my original post, as you correctly identified the cause of the my problem.
I have re-coded by re-synchronising the key inputs from the CPU clock domain onto the 50MHz clock domain, using the technique you describe above.
Ironically I am well aware of this solution to re-sync signals crossing clock domains due to the issue of metastability, but failed to understand that I needed to use this for the inputs from other clock domains for this particular state machine.
The new code is working perfectly and video is clean with no corruptions. I now see a perfect EMUTOS desktop!
This is another lesson hard learned, which hopefully means I won't make that mistake again.
It also explains why every code change (or even using SignalTap) sometimes caused the circuit to "work" better.
Reminds me about my 3rd year Uni project, where my tape reader TTL circuit was failing (that dates me!). My professor pointed to the long thin red and black power wires and pointed out the issue of voltage drop. Short thicker wires solved the problem. I have always had that lesson in the back of my mind when wiring up any power supply wires since then!
best regards...
--migry
