FSM goes into invalid state after reset...

I have a design that is a one hot FSM. Sometime the FSM was locked up invalid state after reset. But I had set the default state. Does anyone have any idea on how this could happen ?


My design is as follows,

------------------------------------------------- always @(posedge clk or negedge rst_n) begin if (!rst_n) cur_state

Reply to
Loading thread data ...

Some Synthesis programs just ignore what you write in the "default", if you don't set the attribute of the state machine as "safe".

If you go to the Synplify webpage you can find a good app notes talking about this kind of problem. A solution to your problem could be:

1) your FSM shoule be "safe" 2) instead of :

write something like:

always @(*) beign case (cur_state) IDLE: next_state = ST1; . . STn : next_state = IDLE; . default: next_state = IDLE; endcase end

I hope this help. Happy new year. Francesco

akun wrote:

Reply to

This could be due to your reset signal not meeting setup and hold when it is released. A lot of designs don't see this because they are binary(only under certain conditions e.g. "000" -> "001"), grey or one-hot encoded and effectively only one flip-flop is affected directly after reset is released. There encoding is such that they stay in the state or go to the next legal state.

Remedy - make your reset signal a synchronous exit from active state or make your encoding tolerant of not meeting setup and hold. The former can be done by creating a flip-flop that has a asynchronous input reset signal putting to active state and making exit dependent on a clock edge condition.

John Adair Enterpoint Ltd. - Home of Raggedsone1. The Low Cost Spartan-3 Development Board.

formatting link

Reply to
John Adair

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.