FSM stops working

First immediate thought - Is your input signal synchronous to your clock or guaranteed to meet setup and hold of your flip-flops. If not your state machine could be entering an unexpected state and staying there. You look like you are hard encoding the state values and this fairly unlikely to affect you unless your synthesis has added bits to state machine or has done a replication of bits. In which case the bits that you are monitoring may not be what the machine is operating on.

Second thought - You have registered both next state and current state transactions. Most people only do the current state with next state as an asynchronous process. What you have done isn't wrong but you need to think that the values that you are working on are 2 clocks old and you need to take account of that. It is all to easy to lose track of where you are and what should happen. A good simulation is recommendation either as matchbox paper sketch or better with a proper simulator.

John Adair Enterpoint Ltd. - Home of PCI Development Boards.

I think, even with this double registering of states the FSM shouldnt hang in state "00". it will be good if you have a reset signal to start your fsm in a known state. the present code dosent have an initial state for the fsm. And also remove your clock event in your second process and make it sensitive only to state.

The clock might stop running. How did you know that the state is stuck at "00"?

Jim

of

is

Although your code is written as a binary-encoded state machine, if you use Xilinx XST you'll find that the tools will convert it into one-hot. If you're using Xilinx ISE, look for a line like:

Optimizing FSM on signal with one-hot encoding.

in your synthesis report. If this is the case, then I would agree that most likely you're running into a synchronizing issue causing the state machine to go "zero-hot". The logic that indicates your current state is encoded from the one-hot outputs and probably defaults to zero if no states are hot.

One thing that can tell if this is really the case is to change your state "00" to something nonzero (be sure to initialize the machine to this state at config time). Then if the machine goes "zero-hot" your encoded output will still indicate state "00" which is obviously wrong.

There are ways to force the synthesis tools to keep your state encoding if you prefer. In XST you need to be careful because the tools will er-encode to one-hot even if your preference for synthesis is "user defined." You need to check the constraints guide on how to work around this.

Good luck,

Gabor

Welp I ended up implementing a process that uses explicit if/elsi statements to cover all cases and it appears to be working. Onl thing I could think of is that Xilinx's synthesis tool was doin something odd that made it go into a random state, even though al states should have been covered. Not sure if I really like th solution, but if it works I guess I'll take it

Thanks for the ideas everyone

-Jess

I'm using a Nallatech development board that allows access through PC to the chip. I'm outputting the value of the state machine to register that is read by a C program running on the host computer. This is how I know it is stuck in the "00" state. I originally had reset state in the process, but took it out when I hit the "lets tr some random stuff" phase of trying to find out what was happenin with the design. I'll try removing the clocking from the secon process, but I know the clock is still running as other parts of th design that are clocked are still firing away. My other though today is to try to do it a bit bassackwards by removing it from "process" and try doing each part explicitly, shouldn't matter bu maybe the synthesis tool is doing somthing odd and I can get it to d it another way

Thanks for the comments to far

-Jess

Howdy Jesse,

While the synthesis tool may have been doing something "odd" (where odd means something *you* weren't expecting), I suspect that chances are very slim that it was doing anything that was wrong or illegal. More than likely, it implemented the circuit in a way you didn't envision.

Were you using the GBUF for your clock? Was DIN synchronized to CLK before feeding into the state machine?

Have fun,

Marc