I am working with a simple state machine with 4 states. The state machine is properly detected by Altera's state machine optimizer, and the state diagram it produces is correct. When I probe this state machine with Signaltap, I find that it's entering an illegal state (all 4 state signals are low). Signaltap image is attached, triggered when all states == 0. This is an intermittent problem that does not occur every time. This state machine does have asynchronous inputs (transmit_req), but they are all synchronized with code similar to that below. always @(posedge Clk, negedge Rst_) if (~Rst_) safe_transmit_req <= 2'b0; else begin safe_transmit_req <= transmit_req; safe_transmit_req <= safe_transmit_req; end The transition that is failing is conditional on ~safe_transmit_req[1]. It leaves the state, but instead of going to the correct state (st_fabric_Idle), it enters some unknown state. st_fabric_Ack: begin fabric_transmit_ack = 1'b1; if (~safe_fabric_transmit_req) begin sm_tx_fabric_next = st_fabric_Idle; end The resets aren't shown but, even if it was getting reset, it should transition to the idle state. Does anyone see any glaring errors that would cause it to enter an illegal state?

Do you have timing violations for recovery or removal? TimeQuest runs those analyses by default. You have to request them with the Classic Timing Analyzer.

Thanks for the reply; I'm using the Classic timing analyzer, so I'll rerun it and post the results.

The smallest slack time in the Recovery sections is 0.466 ns, the smallest in Removal is 1.292 ns - positive, so passing.

What is the timing relationship between the FSM clock and async inputs? Is it possible that one of the async inputs is a pulse shorter than 1 FSM clock period? If so then it may not be correctly registered by your retime logic Just a thought.

I assume the state machine uses the same clock that synchronizes the asynchronous inputs, so recovery and removal analysis should have caught any timing problem for these signals if they are asynchronous to the state machine (as opposed to just asynchronous to Clk coming into the FPGA). And I wonder now if I got the wrong idea and those "asynchronous inputs" are actually synchronous to the state machine. If they're not in the always block sensitivity list for the state machine registers, then they should be covered by setup and hold analysis rather than recovery and removal analysis. Maybe someone will have another idea.

State machine transitioning into illegal state

14 Replies

Altera_Forum
Honored Contributor
17 years ago
Do you have timing violations for recovery or removal? TimeQuest runs those analyses by default. You have to request them with the Classic Timing Analyzer.
Altera_Forum
Honored Contributor
17 years ago
Thanks for the reply; I'm using the Classic timing analyzer, so I'll rerun it and post the results.
Altera_Forum
Honored Contributor
17 years ago
The smallest slack time in the Recovery sections is 0.466 ns, the smallest in Removal is 1.292 ns - positive, so passing.
Altera_Forum
Honored Contributor
17 years ago
What is the timing relationship between the FSM clock and async inputs?

Is it possible that one of the async inputs is a pulse shorter than 1 FSM clock period?
If so then it may not be correctly registered by your retime logic

Just a thought.
Altera_Forum
Honored Contributor
17 years ago
I assume the state machine uses the same clock that synchronizes the asynchronous inputs, so recovery and removal analysis should have caught any timing problem for these signals if they are asynchronous to the state machine (as opposed to just asynchronous to Clk coming into the FPGA). And I wonder now if I got the wrong idea and those "asynchronous inputs" are actually synchronous to the state machine. If they're not in the always block sensitivity list for the state machine registers, then they should be covered by setup and hold analysis rather than recovery and removal analysis.

Maybe someone will have another idea.
Altera_Forum
Honored Contributor
17 years ago
The "asynchronous" inputs are actually from another state machine inside the FPGA running on a different clock domain. The clocks are nominally the same frequency, but because they come from external sources this is not guaranteed. I wanted to avoid the exact situation you described, so I put in a request/ack system between the two. The initiating FSM raises a Req signal and waits for the receiving FSM to raise the Ack signal. When the initiating FSM sees the Ack, it lowers the Req signal. When the receiving system sees the Req go low, it lowers the Ack. When the initiating system sees the Ack go low, it continues on and is allowed to initiate a new Req. I also double registered the signals between the two as described above to prevent metastability, but this might be overkill. The delay caused by these registers causes the Req/Ack signals to be held longer than necessary.

Req __------______ Ack ______------__

In the Signaltap I posted previously, you can see the high request line, the raising of the Ack, the request subsequently falling (gated through safe_fabric_transmit_req[1:0]), and the receiving FSM transitioning based on the request line going low (this is where it fails the state change). The Ack goes low as it should, but that is probably just because that signal is based on being in the Ack state, and we have moved into some bad state.

I'll look into how I generate this Req signal in the other FSM, and see if I'm doing something that might cause glitching or some other funny business.
Altera_Forum
Honored Contributor
17 years ago
--- Quote Start ---
I assume the state machine uses the same clock that synchronizes the asynchronous inputs, so recovery and removal analysis should have caught any timing problem for these signals if they are asynchronous to the state machine (as opposed to just asynchronous to Clk coming into the FPGA).
--- Quote End ---

The safe_fabric_transmit_req[1:0] inputs are registered with the same clock as the FSM reading these signals.

--- Quote Start ---
If they're not in the always block sensitivity list for the state machine registers, then they should be covered by setup and hold analysis rather than recovery and removal analysis.
--- Quote End ---

The registered signals (I believe this makes them synchronous now) are in fact in the sensitivity list (the state machine transition and output logic is in an always @ * block)

I am not clear what purpose the recovery and removal analysis plays in this - I'll read up and maybe it will give me some ideas.
Altera_Forum
Honored Contributor
17 years ago
I was talking about the sensitivity list for the registers, not the one for the combinational logic in the always @ * block. The sensitivity list for the registers should have only the clock and signals that drive the "asynchronous" inputs to the physical registers (clear, load, etc.--what's available I think varies by device family). If you use one of the register's asynchronous inputs, the timing on that input is covered by recovery and removal, which are similar to setup and hold respectively for the truly synchronous inputs like D and clock enable.

I would expect the only asynchronous input to the state machine registers to be a reset that is itself synchronized to the clock. That is what recovery and removal analysis is typically used for. Positive slack ensures that all registers creating the state code see the reset deassert in the same clock cycle, so they all leave the reset state in the same clock cycle. If more than one state bit can toggle at the exit from the reset state, recovery and removal analysis is critical to make sure the correct combination of bits toggles.
Altera_Forum
Honored Contributor
17 years ago
I see - you are correct, the sensitivity list for all state machines and registers is
always @(posedge Clk, negedge Rst_)

Do you know what would be required to prevent glitches in the state machine outputs? Would forcing the state machine into 1-hot or Gray encoding guarantee this?
Altera_Forum
Honored Contributor
17 years ago
Register the state machine outputs if you can. You might need to assert them one state early to compensate for the additional latency of the output registers.

If the state machine outputs are combinational, they will not glitch if their logic has at most one input toggling at a time. If the state code bits are the only inputs to the logic for state machine outputs, then Gray encoding will avoid glitches. 1-hot will have 2 bits toggling at each state change, which can cause a glitch on any LUT fed by both of those bits.

Forum Discussion

State machine transitioning into illegal state

14 Replies

Recent Discussions

Invalid license key (inconsistent authentication code)

Regarding the issue of UFM not starting

ram retiming

Reset Release IP for Agilex needs Stratix 10 device files installed!

Licensing ‘Know-How’ Guide