FSM: a state gets latched

[Altera_Forum]

Hi, 

i am running a state machine. Simulation shows everything is OK. Real life implementation is showing otherwise. I keep track of the states using on board LEDS showing the current FSM state. The problem is that at a certain point (couldn't figure out if there is a specific sequence except that its not from the WAIT STATE), the FSM transfer to the INIT STATE and gets stuck there until i do a POWER reset, which is weird by itself because there is no such transition possible, as i made sure that the reset_L signal is not LOW. and gets stuck at that state, even though that even if such a transfer should happen, an immediate transfer to WAIT state should happen but doesn't.   I cant find the reason and the solution, please help... THE CODE IS ATTACHED

[Altera_Forum]

Seems pretty obvious that reset is being asserted somehow. I would focus on that. And don't just look at the external reset signal. Feed the internal rst_L_sys signal out to a test point and look at it. 

 Is it possible that the FPGA configuration is being cleared, possibly due to a POR reset? Depending upon how your LEDs are being driven you may not be able to tell the difference between the SM sitting in the INIT state vs. the FPGA not configured.

[Altera_Forum]

--- Quote Start ---  Seems pretty obvious that reset is being asserted somehow. I would focus on that. And don't just look at the external reset signal. Feed the internal rst_L_sys signal out to a test point and look at it.  Is it possible that the FPGA configuration is being cleared, possibly due to a POR reset? Depending upon how your LEDs are being driven you may not be able to tell the difference between the SM sitting in the INIT state vs. the FPGA not configured.  --- Quote End ---   Its not an external reset, which is suppose to come from my microcontroller, , i made sure of that. I dont think its a POR bacause i am outputting another led, a test led that is blinking at the rate of the arbiter that you can find in the file i uploaded, the first always block... So the FPGA is "alive" and keeps working, but the state machine, for whatever reason, is being thrown to INIT, and latches there.

[Altera_Forum]

So when your state machine transitions to the INIT state when you get stuck, what is the immediate prior sequence of state(s). IE, where does it come from? 

 Your INIT state is encoded as state '0', so if your code loads the state register, or clears the state register, you will get to state INIT.  Do you have a simulation test bench that you are using to validate your design prior to loading into the FPGA? If you don't, you should. Write one right now.  I NEVER load a design into hardware without validating it first in a testbench. You can spend hours and hours debugging in hardware what is obvious from a testbench failure.

[Altera_Forum]

I do have a testbanch and i did run a simulation. 

Didn't see this behavior... Though i didn't spend a lot of time to simulate every possible situation.. My system is driven by en external trigger.  At the moment i still havent found a specific sequence that leads to the latch, though i know 3 things for sure: 1. The system can stay forever at WAIT state. No problem there. 2. The system can work great for a couple of sequence and then gets stuck, or gets stuck imidiatly at the first trigger. 3. When in INIT state, the FPGA keeps working, beside the state machine...  Really strange... I am open to any sugestion, really anything

[Altera_Forum]

Did you monitor all state variable bits, e.g. with SignalTap? Do you see exactly INIT state, or an illegal combination of state variable bits in stucked state? 

 Assuming the FSM is synthesized using the default one state hot style, there's basically a possibility to get stuck in an unrecoverable illegal state, particularly if the input signals like TRIG violate timing requirements.  You may try to enforce safe state machine encoding by a synthesis attribute (review Quartus software manual how to apply it). To avoid timing violations of FSM input signals, use synchronizers.

[Altera_Forum]

The external trigger is asynchronous but i use an edge detector to start the FSM, so as far as the FSM's concern, the trigger is synchronized. 

 I see a latch on a full state, INIT state and not some unrecignized state. But maybe the synthesizer is changing my binary style i will try to look into that.

[Altera_Forum]

--- Quote Start ---  so as far as the FSM's concern, the trigger is synchronized.  --- Quote End ---   No, the positive transition of TRIG[0] is directly evaluated by the state machine logic without previous synchronization. trig_risedge_SI is generated in combinational logic. If the transition coincides with the active clock edge, delay skew can cause an inconsistent state variable result.   --- Quote Start ---   But maybe the synthesizer is changing my binary style i will try to look into that.   --- Quote End ---   It surely does, unless you specify an encoding by synthesis attributes. Review Quartus software manual about FSM coding styles.  I can't say if the sketched problem is actually causing the observed FSM failure. But it surely can and is a "popular" fault when designing synchronous logic processing asynchronous input signals.

[Altera_Forum]

Sorry, i am not sure i fully understand why the FSM "see" an asynchronous signal and if so how can i fix it.I also cant comprehend what series of events can cause an undesired state... 

I would gladly recieve any feedback from you, so i can improve my understanding and my design.  As i see it, the FSM is driven only by a rising edge detection, which is sampled by the clock wich serves the FSM module... The first always block is not related to the FSM itself and could be easilly be placed outside the module.

[Altera_Forum]

You can tell Quartus to build safe state machines. Go into Assignments -> Settings -> Compiler Settings -> Advanced Settings (Synthesis) and set "Safe State Machine" to On. This should prevent the state machine from staying stuck in an illegal state. This could be a useful experiment but obviously you need to understand why you're getting into the illegal state to begin with. 

 Good luck.

[Altera_Forum]

Ok, so a quick update, i changed synthesis preferences to not interfere with my FSM, things look better. 

I still need to understand why things went wrong...

[Altera_Forum]

I returned to the one hot style, bacause i wanted to get to the bottom of things. 

The problem were the asynchronous signals. I buffered the through a couple of FF, now all seem OK. Thanks everyone, you helped me a lot.

[Altera_Forum]

Reducing logic a bit, you see that many FSM transition conditions include TRIG[0] as direct input, e.g. 

case (state) WAIT: if (TRIG & !trig_SI_old) state <= WAIT_2_X; WAIT_2_X: if(!TRIG) state <= WAIT;   Each of this conditions involves a data path to two state FFs, one to be set and one to be reset if the condition occurs. Flipping TRIG[0] in coincidence with the active clock edge (during the forbidden setup and hold window) can cause either both FFs set or both FFs reset, depending on clock skew and logic delays. The latter case has a good chance to act as illegal stuck state.  Adding synchronizer FFs for TRIG[0] makes all state FFs see a consistent input condition. Safe state machine encoding causes detection of any illegal state and reset to INIT.

[Altera_Forum]

So the FPGA is "alive" and keeps working, but the state machine, for whatever reason, is being thrown to INIT, and latches there.