SignalTap II fails to acquire events

[Altera_Forum]

Hello, 

 I'm using SignalTap II to debug and verify my Cyclone V SOC design. On the signal list there's an enumerated type VHDL FSM with 10 states. The FSM moves consecutively from one state to the other in a circular round robin fashion (there's no jumping between states).  I set the trigger on continuous acquisition for one of the states. The acquisition level is '1' (high). The condition gets triggered once in every 10 clocks and the waveform is shown on the screen.  However, if I leave the system on for enough time (hours) the triggering stops occurring automatically. When I assert a manual trigger and view the waveform - non of the 10 states is active. As if the FSM moved to a state not from the valid list of states.  Notes: 1. The design has no timing violations. 2. The clock that controls the FSM is also used to trigger SignalTap II.  3. The FSM is written in a single clocked process. 4. The "when others" clause isn't used.  What can be the cause?

[Altera_Forum]

I think you sort of answered your own question. Since you're not using WHEN OTHERS, you may be getting into an unknown state for some reason. I don't know what's going on in each state, but you should pretty much always use WHEN OTHERS at the end of your state transition process and enable the "Safe State Machine" assignment in the Assignment Editor. What type of state encoding are you using? The default is one-hot, which can easily get into an unknown state if something is amiss.

[Altera_Forum]

I didn't change the default. So it's one hot... 

I assumed Quartus implements a "safe FSM" even when no explicitly asked to do so (as long as it identify's it as an FSM - which it does in this case).  Also,  If no timing violations exist, what can cause such a thing to happen ?

[Altera_Forum]

--- Quote Start ---  I assumed Quartus implements a "safe FSM" even when no explicitly asked to do so (as long as it identify's it as an FSM - which it does in this case).  --- Quote End ---   Safe state machine is only implemented if explicitly specified.    --- Quote Start ---  If no timing violations exist, what can cause such a thing to happen?   --- Quote End ---   There must be some kind of timing violation, e.g. a FSM input condition depending on an external asynchronous signal or an unstable design clock with glitches.  My general rule is that a state machine which can get stuck in an illegal state because it's not unconditionally reset periodically should be implemented using safe enconding scheme. Even if your design is completely safe, there might be still electrical interferences affecting the clock source.

[Altera_Forum]

Doesn't the "others" statement make the FSM safe ? 

What extras does the tool add if you explicitly specify the "safe state machine" option ?

[Altera_Forum]

No, WHEN OTHERS only works for explicitly defined states, so it would only work if you were using a binary encoding scheme and had a power of 2 number of states. 

 The "Safe State Machine" assignment adds the extra logic required to cover all possibilities.

[Altera_Forum]

--- Quote Start ---  Doesn't the "others" statement make the FSM safe ?  --- Quote End ---   It does not because it's only considered in synthesis if it covers a defined state. Safe encoding adds a reset to initial state for any illegal (undefined) state.  As sstrell mentioned, enforcing a full case binary encoding would be the other option. But it blocks synthesis from optimizing the state machine logic.

[Altera_Forum]

I am a bit sceptical about safe state machines concept. A good design should not enter undefined state. If it does due a glitch then any logic may go wrong and not just that of state machine. 

So exiting from wrong state will be futile if other logic fails. We must first trust our logic or we can't design. For critical applications yes it is mandatory to recover from a fault and that requires considerable care in design and testing. That is some areas of aerospace, medical devices etc. where self recovery of logic is crucial. In other cases we are used to apply reset or power cycle or even bang on the box.