state machine dead problem

Lathi, the most common problem with state machines is an (or several) input signals that are not synchronous with the clock. When an asynchronous signal goes to several flip-flop inputs, it might arrive at one flip-flop before,and at another after the clock, so that what should be one input becomes two inputs, and the machine can get totally confused. Remedy: Never run an asynchronous input into more than one flip-flop. Best method: Pre-synchronize all asynchronous inputs before they reach the state machine. I am 95% sure that this is your problem.

When you use one-hot encoding for 8 states, you have 8 flip-flops, which might of course have 256 different states. They might accidentally get into one of the 248 illegal states... That's the remaining 4% You might also have a dirty clock (double edges, slow risetime etc) That's the last percent. Peter Alfke, Xilinx (from home)

Peter,

It's great to know that. I've never heard of this. Can you give me more information about the first case(links, examples)? I am thinking about adding a flip-flop to all input signals but shall I used a clock edge to synchronize them different from those flip-flops in the statemachine?

I do see asynchronous inputs to parallel flip flops on RTL schematic. Should StateCAD prevent this?

I use user defined encoding: The Xilinx tool gave me the following information: Optimizing FSM on signal with user encoding.

------------------- State | Encoding

------------------- s000 | 000 s001 | 001 s010 | 010 s011 | 011 s100 | 100 s101 | 101 s110 | 110 s111 | 111

-------------------

So I guess there shouldn't be other states. I also have a 'when others' line in the statemachine.

Is there any simple way to clean up the clock in Xilinx tool, such as a buffer?

Thanks a lot.

Wei

Peter Alfke wrote:

I have an article on my site called, appropriately enough, "Synchronizing FSM Inputs."

Bob Perlman Cambrian Design Works

Thank you all. I haven't tried it yet, but it must be the solution. Will let you know when the problem is fixed.

Lathi

Bob Perlman wrote:

One more thing... In the Xilinx tools there are two different constraints that control Finite State Machine encoding: FSM_ENCODING and SIGNAL_ENCODING

In my experience you need to set both of these to "user" in order to end up with user encoded logic after mapping. It may be worth checking if your translated design is really binary encoded and not forced to one-hot somewhere farther along the tool chain.

HTH, Gabor

Asynchronous signal sampling using two cascaded FFs to avoid metastability was always one of the first things my teachers tried to pound into students' minds in design classes... and as a lab tutor, I have seen several students scratching their heads for hours before reminding them of this.

A slightly more paranoid version of this would include glitch filtering as well - add some extra FFs and update the internal net only when all FFs match, hold the previous value otherwise.

BTW, make sure the first FF gets packed into IOBs since these are usually designed to reduce the likelyhood of metastability ever happening and settle faster in case they fail to prevent it. Regular FFs are designed for highest speed and smallest footprint, they might never settle when they go metastable.

What's the prop time from an input FF in an IOB to a nearby FF as compared to two FFs inside the logic that are near eachother?

Actually what you want is the fastest dff followed by the smallest delay to the next flop so a "regular" flop is probably better.

Any glitch filter should only depend on some function of the flipflops after the flipflops used for the synchronizer. If you involve the synchronizer FFs in the glitch filter, you have probably created a bypass path that may defeat much of your efforts to manage metastables within the synchronizer.

This is not the case. There is nothing about the IOB FFs that makes them inherently better at resolving metastables, and likewise, the main array FFs are certainly not some how worse. In fact the high speed of the FFs (in both the main array and the IOBs) is a characteristic that leads to the very good metastable recovery characteristics of current products.

There is some cleverness in the delay paths for the D and CLK pins of IOB input FFs that help in achieving close to 0.0 ns hold time, but this in no way helps or hinders the metastable charateristics of the IOB FF.

Philip Freidin

=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for