state machine dead problem

I am having a very stange problem with my state machine. The state
machine turns dead after some uncertain time(20min ~ 2 days) and all
outputs of the statemachine are 0. All other logics in the chips work
properly at the same time. The state machine is very simple, only with
8 states. I tried with StateCAD and programming manually with VHDL and
they behave the same. Anybody know what's possibly the problem? I have
been working on this for a week and really cannot find a way out.
Thanks.

Lathi.Tan@gmail.com wrote:
> I am having a very stange problem with my state machine. The state
> machine turns dead after some uncertain time(20min ~ 2 days) and all
> outputs of the statemachine are 0. All other logics in the chips work
> properly at the same time. The state machine is very simple, only with
> 8 states. I tried with StateCAD and programming manually with VHDL and
> they behave the same. Anybody know what's possibly the problem? I have
> been working on this for a week and really cannot find a way out.
> Thanks.
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 <XLXI_5/XLXI_126/CurrState> on signal <CurrState[1:3]>
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:
> Lathi.Tan@gmail.com wrote:
> > I am having a very stange problem with my state machine. The state
> > machine turns dead after some uncertain time(20min ~ 2 days) and all
> > outputs of the statemachine are 0. All other logics in the chips work
> > properly at the same time. The state machine is very simple, only with
> > 8 states. I tried with StateCAD and programming manually with VHDL and
> > they behave the same. Anybody know what's possibly the problem? I have
> > been working on this for a week and really cannot find a way out.
> > Thanks.
> 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)

On 25 Sep 2006 19:23:08 -0700, Lathi.Tan@gmail.com wrote:

>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 have an article on my site called, appropriately enough,
"Synchronizing FSM Inputs."

http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

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:
> On 25 Sep 2006 19:23:08 -0700, Lathi.Tan@gmail.com wrote:
>
> >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 have an article on my site called, appropriately enough,
> "Synchronizing FSM Inputs."
>
> http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html
> 
> Bob Perlman
> Cambrian Design Works
> http://www.cambriandesign.com

Lathi.Tan@gmail.com wrote:
> 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

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

Lathi.Tan@gmail.com wrote:
> 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

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.

-- 
Daniel Sauvageau
moc.xortam@egavuasd
Matrox Graphics Inc.
1155 St-Regis, Dorval, Qc, Canada
514-822-6000

>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?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

On Fri, 29 Sep 2006 16:07:08 -0400, "Daniel S."
<digitalmastrmind_no_spam@hotmail.com> wrote:
>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.

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

On Fri, 29 Sep 2006 16:07:08 -0400, "Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote:
>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.

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.

>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.

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
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG