Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 149000

Article: 149000
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: John McCaskill <jhmccaskill@gmail.com>
Date: Mon, 20 Sep 2010 09:05:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> I recently fixed a problem with one of my state machines, and I think
> that the cause could be a bug in Xilinx XST. Below is the code that
> produced the failure. The state-machine worked most of the time,
> though occasionally the 'phaseRamWE' signal would be stuck low, even
> though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> incrementing. =A0I fixed it by explicitly declaring the desired value of
> 'phaseRamWE' in every state. Notice that all states are defined so it
> should recover from any conditions introduced by asynchronous inputs.
>
> Have any of you seen similar behavior? Appears to be an XST bug to me.
>

<snip>

I only skimmed the code, but this bit jumped out at me:

            if (pipeFill =3D=3D 1'b1)                     // 'pipeFill' is
asynchronous to 'clk'

If pipeFill is really asynchronous to the clock that is running your
state machine,  using it without synchronizing it first is going to
cause you problems.  Probably not because of metastability, but
because of coherency problems. If pipeFill is changing near the clock
edge, some FFs will see the new value, and some the old.  This can
cause weird and flaky behaviour.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 149001
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Mon, 20 Sep 2010 09:09:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 11:00=A0am, Frank Buss <f...@frank-buss.de> wrote:
> Darol Klawetter wrote:
> > I recently fixed a problem with one of my state machines, and I think
> > that the cause could be a bug in Xilinx XST. Below is the code that
> > produced the failure. The state-machine worked most of the time,
> > though occasionally the 'phaseRamWE' signal would be stuck low, even
> > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > incrementing. =A0I fixed it by explicitly declaring the desired value o=
f
> > 'phaseRamWE' in every state. Notice that all states are defined so it
> > should recover from any conditions introduced by asynchronous inputs.
>
> > Have any of you seen similar behavior? Appears to be an XST bug to me.
>
> I have seen similar behaviour with Altera Quartus. It was the same proble=
m:
> asynchronous inputs changed the state machine and sometimes it hangs. I
> think it is possible that the state machine is internally implemented wit=
h
> some more bits and it is possible that it hangs, if there are some timing
> violations or meta stability conditions, because then there is an invalid
> state encoded and everything can happen with optimized gates. The fix was
> easy: Creating an input latch (or even two, if you are paranoid) for each
> asynchronous signal to make it synchronous.
>
> --
> Frank Buss,http://www.frank-buss.de
> piano and more:http://www.youtube.com/user/frankbuss

I thought the same thing, especially because XST often uses one-hot
encoding internally, and that introduces more state bits. Even though
I exhaustively defined all states, this may not be the case in the
post-synthesis result.

Article: 149002
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Mon, 20 Sep 2010 09:12:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> wrote:
>
> > I recently fixed a problem with one of my state machines, and I think
> > that the cause could be a bug in Xilinx XST. Below is the code that
> > produced the failure. The state-machine worked most of the time,
> > though occasionally the 'phaseRamWE' signal would be stuck low, even
> > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > incrementing. =A0I fixed it by explicitly declaring the desired value o=
f
> > 'phaseRamWE' in every state. Notice that all states are defined so it
> > should recover from any conditions introduced by asynchronous inputs.
>
> > Have any of you seen similar behavior? Appears to be an XST bug to me.
>
> <snip>
>
> I only skimmed the code, but this bit jumped out at me:
>
> =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 // 'pipeFill' is
> asynchronous to 'clk'
>
> If pipeFill is really asynchronous to the clock that is running your
> state machine, =A0using it without synchronizing it first is going to
> cause you problems. =A0Probably not because of metastability, but
> because of coherency problems. If pipeFill is changing near the clock
> edge, some FFs will see the new value, and some the old. =A0This can
> cause weird and flaky behaviour.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

Agreed, but the state machine should recover, right? All states are
defined.

Article: 149003
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Muzaffer Kal <kal@dspia.com>
Date: Mon, 20 Sep 2010 09:18:26 -0700
Links: << >>  << T >>  << A >>
On Mon, 20 Sep 2010 08:52:16 -0700 (PDT), Darol Klawetter
<darol.klawetter@l-3com.com> wrote:

>I recently fixed a problem with one of my state machines, and I think
>that the cause could be a bug in Xilinx XST. Below is the code that
>produced the failure. The state-machine worked most of the time,
>though occasionally the 'phaseRamWE' signal would be stuck low, even
>though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
>incrementing.  I fixed it by explicitly declaring the desired value of
>'phaseRamWE' in every state. Notice that all states are defined so it
>should recover from any conditions introduced by asynchronous inputs.
>
>Have any of you seen similar behavior? Appears to be an XST bug to me.

Try adding a (* safe_implementation = "yes" *)  to your state register
and see if that gets rid of the problem.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 149004
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Mon, 20 Sep 2010 09:26:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> wrote:
>
> > I recently fixed a problem with one of my state machines, and I think
> > that the cause could be a bug in Xilinx XST. Below is the code that
> > produced the failure. The state-machine worked most of the time,
> > though occasionally the 'phaseRamWE' signal would be stuck low, even
> > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > incrementing. =A0I fixed it by explicitly declaring the desired value o=
f
> > 'phaseRamWE' in every state. Notice that all states are defined so it
> > should recover from any conditions introduced by asynchronous inputs.
>
> > Have any of you seen similar behavior? Appears to be an XST bug to me.
>
> <snip>
>
> I only skimmed the code, but this bit jumped out at me:
>
> =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 // 'pipeFill' is
> asynchronous to 'clk'
>
> If pipeFill is really asynchronous to the clock that is running your
> state machine, =A0using it without synchronizing it first is going to
> cause you problems. =A0Probably not because of metastability, but
> because of coherency problems. If pipeFill is changing near the clock
> edge, some FFs will see the new value, and some the old. =A0This can
> cause weird and flaky behaviour.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

I think I just found the source of the problem, and it's not a bug in
XST. In state S1, if 'state' is updated while 'phaseRamWE'  is not,
then it would produce the symptoms I saw. Early on, I had considered
synchronizing pipeFill to the 'clk" domain, but I thought I would just
handle it in the robustness of the state machine - my mistake.

Article: 149005
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: John McCaskill <jhmccaskill@gmail.com>
Date: Mon, 20 Sep 2010 09:55:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 11:12=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
>
>
>
> > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> > wrote:
>
> > > I recently fixed a problem with one of my state machines, and I think
> > > that the cause could be a bug in Xilinx XST. Below is the code that
> > > produced the failure. The state-machine worked most of the time,
> > > though occasionally the 'phaseRamWE' signal would be stuck low, even
> > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > > incrementing. =A0I fixed it by explicitly declaring the desired value=
 of
> > > 'phaseRamWE' in every state. Notice that all states are defined so it
> > > should recover from any conditions introduced by asynchronous inputs.
>
> > > Have any of you seen similar behavior? Appears to be an XST bug to me=
.
>
> > <snip>
>
> > I only skimmed the code, but this bit jumped out at me:
>
> > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 // 'pipeFill' is
> > asynchronous to 'clk'
>
> > If pipeFill is really asynchronous to the clock that is running your
> > state machine, =A0using it without synchronizing it first is going to
> > cause you problems. =A0Probably not because of metastability, but
> > because of coherency problems. If pipeFill is changing near the clock
> > edge, some FFs will see the new value, and some the old. =A0This can
> > cause weird and flaky behaviour.
>
> > Regards,
>
> > John McCaskillwww.FasterTechnology.com
>
> Agreed, but the state machine should recover, right? All states are
> defined.

Hello Darol,

While you may have specified all the possible states for the width of
state variable that you used, unless you tell XST otherwise, it will
choose which ever encoding style that it feels is optimal. That is
usually a one hot encoding for a state machine the size of yours.  By
default, XST will assume that states that you do not explicitly have a
transition to are truly unreachable and will not worry about them, and
will ignore default or when others cases of your case statement.

You can change the default behavior. You can force the tools to use an
encoding of your choice, and you can use the safe state machine
constraint to cause the tools to be more conservative in their
assumptions about unreachable states. Doing that will come at a cost
that the tools will choose a different encoding that will probably be
slower and bigger.

I think that you are much better off to always synchronize an
asynchronous signal at the boundary of your design.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 149006
Subject: Re: Stack Exchange site for programmable logic and FPGA design
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 20 Sep 2010 10:23:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 19, 8:58=A0pm, "jt_eaton"
<z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> Is it my imagination of did all the spam on this newsgroup suddenly
> disappear?
> I checked google groups and the last piece I saw was dated 10 Aug. I was
> sure that there were some more recent stuff.
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

I think that there are a number of people using Google Groups that are
now reporting posts as SPAM.  In another thread someone has posted
that it takes about 40 total abuse reports from at least two different
IP addresses for the Google routines to punt a post.

So if everyone does a little community service and clicks the "Report
spam" link 5-10 times each time these show up they will disappear
quickly.  Sometimes I only get 2 or 3 clicks and the post is gone so I
know there are others out there doing the same.

Ed McGettigan
--
Xilinx Inc.

Article: 149007
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Mon, 20 Sep 2010 11:02:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 11:55=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Sep 20, 11:12=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> wrote:
>
>
>
> > On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
>
> > > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> > > wrote:
>
> > > > I recently fixed a problem with one of my state machines, and I thi=
nk
> > > > that the cause could be a bug in Xilinx XST. Below is the code that
> > > > produced the failure. The state-machine worked most of the time,
> > > > though occasionally the 'phaseRamWE' signal would be stuck low, eve=
n
> > > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > > > incrementing. =A0I fixed it by explicitly declaring the desired val=
ue of
> > > > 'phaseRamWE' in every state. Notice that all states are defined so =
it
> > > > should recover from any conditions introduced by asynchronous input=
s.
>
> > > > Have any of you seen similar behavior? Appears to be an XST bug to =
me.
>
> > > <snip>
>
> > > I only skimmed the code, but this bit jumped out at me:
>
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 // 'pipeFill' is
> > > asynchronous to 'clk'
>
> > > If pipeFill is really asynchronous to the clock that is running your
> > > state machine, =A0using it without synchronizing it first is going to
> > > cause you problems. =A0Probably not because of metastability, but
> > > because of coherency problems. If pipeFill is changing near the clock
> > > edge, some FFs will see the new value, and some the old. =A0This can
> > > cause weird and flaky behaviour.
>
> > > Regards,
>
> > > John McCaskillwww.FasterTechnology.com
>
> > Agreed, but the state machine should recover, right? All states are
> > defined.
>
> Hello Darol,
>
> While you may have specified all the possible states for the width of
> state variable that you used, unless you tell XST otherwise, it will
> choose which ever encoding style that it feels is optimal. That is
> usually a one hot encoding for a state machine the size of yours. =A0By
> default, XST will assume that states that you do not explicitly have a
> transition to are truly unreachable and will not worry about them, and
> will ignore default or when others cases of your case statement.
>
> You can change the default behavior. You can force the tools to use an
> encoding of your choice, and you can use the safe state machine
> constraint to cause the tools to be more conservative in their
> assumptions about unreachable states. Doing that will come at a cost
> that the tools will choose a different encoding that will probably be
> slower and bigger.
>
> I think that you are much better off to always synchronize an
> asynchronous signal at the boundary of your design.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

Thanks for the response, John. Yes, I realized that the Xilinx tools
could use different state encoding than that specified by the user,
but it seemed reasonable to assume that functionality would be matched
(wrong assumption). Anyway, you may have noticed, from a previous post
to this thread, that my problem was caused by my own error and was not
tool related.

I agree with your last paragraph. It's typically better to use a
couple of flops on an asynchronous control signal than trying to
handle it within the state machine (especially if the tool is going to
take encoding liberties).

Article: 149008
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 20 Sep 2010 13:47:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 2:02=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:

>
> I agree with your last paragraph. It's typically better to use a
> couple of flops on an asynchronous control signal than trying to
> handle it within the state machine (especially if the tool is going to
> take encoding liberties).- Hide quoted text -
>

The rule is that any time there is a logic path from an asynchronous
input to more than one device that samples the signal(s), you must
first synchronize the signal before feeding it into any logic path.

This condition occurs for any state machine with more than one state.

KJ

Article: 149009
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 20 Sep 2010 13:49:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
>
> I agree with your last paragraph. It's typically better to use a
> couple of flops on an asynchronous control signal than trying to
> handle it within the state machine (especially if the tool is going to
> take encoding liberties).- Hide quoted text -
>

The rule is that any time there is a logic path from an asynchronous
input to more than one device that samples the signal(s), you must
first synchronize the signal before feeding it into any logic path.

This condition occurs for any state machine with more than flip flop
used to implement the state.

KJ

Article: 149010
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Mon, 20 Sep 2010 14:01:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> > I agree with your last paragraph. It's typically better to use a
> > couple of flops on an asynchronous control signal than trying to
> > handle it within the state machine (especially if the tool is going to
> > take encoding liberties).- Hide quoted text -
>
> The rule is that any time there is a logic path from an asynchronous
> input to more than one device that samples the signal(s), you must
> first synchronize the signal before feeding it into any logic path.
>
> This condition occurs for any state machine with more than flip flop
> used to implement the state.
>
> KJ

I agree that this is a rule that should be generally followed, but
there are exceptions. For example, a gray-coded state machine is
sometimes used to tolerate an asynchronous control input. If timing is
violated on any of the flops, the machine will stay at the current
state or transition to the next state.

Article: 149011
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Gabor <gabor@alacron.com>
Date: Mon, 20 Sep 2010 14:09:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 5:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > I agree with your last paragraph. It's typically better to use a
> > > couple of flops on an asynchronous control signal than trying to
> > > handle it within the state machine (especially if the tool is going t=
o
> > > take encoding liberties).- Hide quoted text -
>
> > The rule is that any time there is a logic path from an asynchronous
> > input to more than one device that samples the signal(s), you must
> > first synchronize the signal before feeding it into any logic path.
>
> > This condition occurs for any state machine with more than flip flop
> > used to implement the state.
>
> > KJ
>
> I agree that this is a rule that should be generally followed, but
> there are exceptions. For example, a gray-coded state machine is
> sometimes used to tolerate an asynchronous control input. If timing is
> violated on any of the flops, the machine will stay at the current
> state or transition to the next state.

In practice, Gray code is not very useful for state machines that have
many
branch possibilities.  Remember that you need to make sure that any
possible transition only changes one state bit.  This is easy for any
linear or loop state logic like a counter, but most control logic
state
machines will have multiple-way branching from many of the states.
So unless you add intermediate states to prevent more than two-way
branching from any node you can still run into problems with
asynchronous inputs to the Gray coded machine.  The added states
would give the same delay as a synchronizer flop on the input signal.

Article: 149012
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: d_s_klein <d_s_klein@yahoo.com>
Date: Mon, 20 Sep 2010 14:31:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > I agree with your last paragraph. It's typically better to use a
> > > couple of flops on an asynchronous control signal than trying to
> > > handle it within the state machine (especially if the tool is going t=
o
> > > take encoding liberties).- Hide quoted text -
>
> > The rule is that any time there is a logic path from an asynchronous
> > input to more than one device that samples the signal(s), you must
> > first synchronize the signal before feeding it into any logic path.
>
> > This condition occurs for any state machine with more than flip flop
> > used to implement the state.
>
> > KJ
>
> I agree that this is a rule that should be generally followed, but
> there are exceptions. For example, a gray-coded state machine is
> sometimes used to tolerate an asynchronous control input. If timing is
> violated on any of the flops, the machine will stay at the current
> state or transition to the next state.

This is not a rule that "should be generally followed".  It is rule
that must ALWAYS be followed!

If a signal from a "foreign" clock domain is used in a conditional
inside a state machine, the state machine will fail (eventually).

This is NOT a metastability problem.  It is because the time to decode
the D inputs of the state bits is different for each D input, and if
the "foreign clock" signal is used in a conditional it will go to more
than one D input.  There is no way to ensure that the D inputs are all
valid at the same time, and when the clock happens while one is valid
and the other is not state machine gets corrupted.  This syndrome is
independent of the coding method of the state variable.

Synchronizing all inputs to a state machine to the state machines
clock will prevent that.

Not optional.  Sorry.

RK

Article: 149013
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Tue, 21 Sep 2010 00:14:17 +0200
Links: << >>  << T >>  << A >>
In comp.arch.fpga,
Gabor <gabor@alacron.com> wrote:
>
> In practice, Gray code is not very useful for state machines that have
> many
> branch possibilities.  Remember that you need to make sure that any
> possible transition only changes one state bit.  This is easy for any
> linear or loop state logic like a counter, but most control logic
> state
> machines will have multiple-way branching from many of the states.
> So unless you add intermediate states to prevent more than two-way
> branching from any node you can still run into problems with
> asynchronous inputs to the Gray coded machine.  The added states
> would give the same delay as a synchronizer flop on the input signal.

Did that many years ago for a CPLD design! Draw a big Karnaugh map,
try put in your states with the minimum possible dummy states and
only single bit changes. Great fun, better than cross-words. :-)

But agreed, wouldn't do that now (although, I might ...), and back
then it only worked if the machine was not too complex.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Most public domain software is free, at least at first glance.

Article: 149014
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Mon, 20 Sep 2010 19:04:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
> On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
> wrote:
>
>
>
>
>
> > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > > I agree with your last paragraph. It's typically better to use a
> > > > couple of flops on an asynchronous control signal than trying to
> > > > handle it within the state machine (especially if the tool is going=
 to
> > > > take encoding liberties).- Hide quoted text -
>
> > > The rule is that any time there is a logic path from an asynchronous
> > > input to more than one device that samples the signal(s), you must
> > > first synchronize the signal before feeding it into any logic path.
>
> > > This condition occurs for any state machine with more than flip flop
> > > used to implement the state.
>
> > > KJ
>
> > I agree that this is a rule that should be generally followed, but
> > there are exceptions. For example, a gray-coded state machine is
> > sometimes used to tolerate an asynchronous control input. If timing is
> > violated on any of the flops, the machine will stay at the current
> > state or transition to the next state.
>
> This is not a rule that "should be generally followed". =A0It is rule
> that must ALWAYS be followed!
>
> If a signal from a "foreign" clock domain is used in a conditional
> inside a state machine, the state machine will fail (eventually).
>
> This is NOT a metastability problem. =A0It is because the time to decode
> the D inputs of the state bits is different for each D input, and if
> the "foreign clock" signal is used in a conditional it will go to more
> than one D input. =A0There is no way to ensure that the D inputs are all
> valid at the same time, and when the clock happens while one is valid
> and the other is not state machine gets corrupted. =A0This syndrome is
> independent of the coding method of the state variable.
>
> Synchronizing all inputs to a state machine to the state machines
> clock will prevent that.
>
> Not optional. =A0Sorry.
>
> RK

RK,

You'll have to convince me that the rule "must ALWAYS" be followed,
independent of state encoding. It still seems to me that gray coding
could work - the machine either stays in the current state or
transitions to the next state because only one bit is transitioning.
If the input to this bit's register meets timing, then the machine
goes to the next state; if timing is not met, it either goes to the
next state or stays at the current one. The other bits are static.

Article: 149015
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 21 Sep 2010 02:27:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
Darol Klawetter <darol.klawetter@l-3com.com> wrote:
(snip, someone wrote)

>> > > This condition occurs for any state machine with more than flip flop
>> > > used to implement the state.
(snip)

>> This is not a rule that "should be generally followed".  It is rule
>> that must ALWAYS be followed!

>> If a signal from a "foreign" clock domain is used in a conditional
>> inside a state machine, the state machine will fail (eventually).
(snip)

>> Synchronizing all inputs to a state machine to the state machines
>> clock will prevent that.
(snip)
 
> You'll have to convince me that the rule "must ALWAYS" be followed,
> independent of state encoding. It still seems to me that gray coding
> could work - the machine either stays in the current state or
> transitions to the next state because only one bit is transitioning.
> If the input to this bit's register meets timing, then the machine
> goes to the next state; if timing is not met, it either goes to the
> next state or stays at the current one. The other bits are static.

For a gray code state machine, and only one unsynchronized input,
maybe it can work.  Assuming that there are more than two
states, you have to ask about the interaction with other inputs,
and the possible state transitions.  If it is already going
from state 1 to state 3, and the unsynchronized input goes from
state 1 to state 0, then it seems possible that you might end
up in state 2.  

So, for each synchronous state transition, you have to figure
out what transition occurs if the unsynchronized input changes
just before or just after the clock.   For more than one,
you have to figure out the transition for all combinations of
inputs changing just before or just after the clock, even
if there is supposed to be an order.

I suppose if you do that, then I believe that it can work.

-- glen

Article: 149016
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: John McCaskill <jhmccaskill@gmail.com>
Date: Mon, 20 Sep 2010 19:28:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 9:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
>
>
>
> > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
> > wrote:
>
> > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > > > I agree with your last paragraph. It's typically better to use a
> > > > > couple of flops on an asynchronous control signal than trying to
> > > > > handle it within the state machine (especially if the tool is goi=
ng to
> > > > > take encoding liberties).- Hide quoted text -
>
> > > > The rule is that any time there is a logic path from an asynchronou=
s
> > > > input to more than one device that samples the signal(s), you must
> > > > first synchronize the signal before feeding it into any logic path.
>
> > > > This condition occurs for any state machine with more than flip flo=
p
> > > > used to implement the state.
>
> > > > KJ
>
> > > I agree that this is a rule that should be generally followed, but
> > > there are exceptions. For example, a gray-coded state machine is
> > > sometimes used to tolerate an asynchronous control input. If timing i=
s
> > > violated on any of the flops, the machine will stay at the current
> > > state or transition to the next state.
>
> > This is not a rule that "should be generally followed". =A0It is rule
> > that must ALWAYS be followed!
>
> > If a signal from a "foreign" clock domain is used in a conditional
> > inside a state machine, the state machine will fail (eventually).
>
> > This is NOT a metastability problem. =A0It is because the time to decod=
e
> > the D inputs of the state bits is different for each D input, and if
> > the "foreign clock" signal is used in a conditional it will go to more
> > than one D input. =A0There is no way to ensure that the D inputs are al=
l
> > valid at the same time, and when the clock happens while one is valid
> > and the other is not state machine gets corrupted. =A0This syndrome is
> > independent of the coding method of the state variable.
>
> > Synchronizing all inputs to a state machine to the state machines
> > clock will prevent that.
>
> > Not optional. =A0Sorry.
>
> > RK
>
> RK,
>
> You'll have to convince me that the rule "must ALWAYS" be followed,
> independent of state encoding. It still seems to me that gray coding
> could work - the machine either stays in the current state or
> transitions to the next state because only one bit is transitioning.
> If the input to this bit's register meets timing, then the machine
> goes to the next state; if timing is not met, it either goes to the
> next state or stays at the current one. The other bits are static.

Must always is too strong. Your Gray coding example is valid and deals
with the issue of coherency, since only one FF changes state based on
the asynchronous signal.  It does not address the issue of
metastability, but that is becoming much less of an issue because of
how fast the FFs have become.  There have been post by either Austin
or Peter that they have a problem even trying to make it happen so
that they can measure it.

What I would say is that unless you have a very good reason not to,
you want to just use a synchronizing circuit before you do anything
else with an asynchronous signal.  The cost is usually low, and the
consequences of doing it another way and getting it wrong are high.  I
have debugged this sort of problem before, and it is a painful
process.  FPGAs and their tools assume that you are using synchronous
techniques, and can work against you if you deviate from that path.
They can take your carefully coded Gray state machine and change it to
one hot if you don't have the proper constraints, or they might
replicate state registers if they have a high enough fan out and you
did not turn off that option.

Regards,

John McCaskill
www.FasterTechnology.com


Article: 149017
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Peter Alfke <alfke@sbcglobal.net>
Date: Mon, 20 Sep 2010 19:38:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 7:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
>
>
>
>
>
> > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
> > wrote:
>
> > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > > > I agree with your last paragraph. It's typically better to use a
> > > > > couple of flops on an asynchronous control signal than trying to
> > > > > handle it within the state machine (especially if the tool is goi=
ng to
> > > > > take encoding liberties).- Hide quoted text -
>
> > > > The rule is that any time there is a logic path from an asynchronou=
s
> > > > input to more than one device that samples the signal(s), you must
> > > > first synchronize the signal before feeding it into any logic path.
>
> > > > This condition occurs for any state machine with more than flip flo=
p
> > > > used to implement the state.
>
> > > > KJ
>
> > > I agree that this is a rule that should be generally followed, but
> > > there are exceptions. For example, a gray-coded state machine is
> > > sometimes used to tolerate an asynchronous control input. If timing i=
s
> > > violated on any of the flops, the machine will stay at the current
> > > state or transition to the next state.
>
> > This is not a rule that "should be generally followed". =A0It is rule
> > that must ALWAYS be followed!
>
> > If a signal from a "foreign" clock domain is used in a conditional
> > inside a state machine, the state machine will fail (eventually).
>
> > This is NOT a metastability problem. =A0It is because the time to decod=
e
> > the D inputs of the state bits is different for each D input, and if
> > the "foreign clock" signal is used in a conditional it will go to more
> > than one D input. =A0There is no way to ensure that the D inputs are al=
l
> > valid at the same time, and when the clock happens while one is valid
> > and the other is not state machine gets corrupted. =A0This syndrome is
> > independent of the coding method of the state variable.
>
> > Synchronizing all inputs to a state machine to the state machines
> > clock will prevent that.
>
> > Not optional. =A0Sorry.
>
> > RK
>
> RK,
>
> You'll have to convince me that the rule "must ALWAYS" be followed,
> independent of state encoding. It still seems to me that gray coding
> could work - the machine either stays in the current state or
> transitions to the next state because only one bit is transitioning.
> If the input to this bit's register meets timing, then the machine
> goes to the next state; if timing is not met, it either goes to the
> next state or stays at the current one. The other bits are static.

It is more basic than that:
When the asynchronous input drives the D of asingle flip-flop, there
can be no problem. The flip-flop either changes or does not.
When, however the asynchronous input drives the D of more than one
flip-flop, then inevitably there will come the moment where one gets
set and the other one gets reset. Usually, this is a disaster, and can
and should be avoided by synchronizing all data inputs.
There might be special designs that can tolerate this ambiguity, but
the best practice is to synchronize.

I have been preaching this for over 40 years, but there are always new
designers who fall into the old trap...
Peter Alfke

Article: 149018
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Peter Alfke <alfke@sbcglobal.net>
Date: Mon, 20 Sep 2010 22:15:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 7:38=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On Sep 20, 7:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
> wrote:
>
>
>
>
>
> > On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
>
> > > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
> > > wrote:
>
> > > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > > > > I agree with your last paragraph. It's typically better to use =
a
> > > > > > couple of flops on an asynchronous control signal than trying t=
o
> > > > > > handle it within the state machine (especially if the tool is g=
oing to
> > > > > > take encoding liberties).- Hide quoted text -
>
> > > > > The rule is that any time there is a logic path from an asynchron=
ous
> > > > > input to more than one device that samples the signal(s), you mus=
t
> > > > > first synchronize the signal before feeding it into any logic pat=
h.
>
> > > > > This condition occurs for any state machine with more than flip f=
lop
> > > > > used to implement the state.
>
> > > > > KJ
>
> > > > I agree that this is a rule that should be generally followed, but
> > > > there are exceptions. For example, a gray-coded state machine is
> > > > sometimes used to tolerate an asynchronous control input. If timing=
 is
> > > > violated on any of the flops, the machine will stay at the current
> > > > state or transition to the next state.
>
> > > This is not a rule that "should be generally followed". =A0It is rule
> > > that must ALWAYS be followed!
>
> > > If a signal from a "foreign" clock domain is used in a conditional
> > > inside a state machine, the state machine will fail (eventually).
>
> > > This is NOT a metastability problem. =A0It is because the time to dec=
ode
> > > the D inputs of the state bits is different for each D input, and if
> > > the "foreign clock" signal is used in a conditional it will go to mor=
e
> > > than one D input. =A0There is no way to ensure that the D inputs are =
all
> > > valid at the same time, and when the clock happens while one is valid
> > > and the other is not state machine gets corrupted. =A0This syndrome i=
s
> > > independent of the coding method of the state variable.
>
> > > Synchronizing all inputs to a state machine to the state machines
> > > clock will prevent that.
>
> > > Not optional. =A0Sorry.
>
> > > RK
>
> > RK,
>
> > You'll have to convince me that the rule "must ALWAYS" be followed,
> > independent of state encoding. It still seems to me that gray coding
> > could work - the machine either stays in the current state or
> > transitions to the next state because only one bit is transitioning.
> > If the input to this bit's register meets timing, then the machine
> > goes to the next state; if timing is not met, it either goes to the
> > next state or stays at the current one. The other bits are static.
>
> It is more basic than that:
> When the asynchronous input drives the D of asingle flip-flop, there
> can be no problem. The flip-flop either changes or does not.
> When, however the asynchronous input drives the D of more than one
> flip-flop, then inevitably there will come the moment where one gets
> set and the other one gets reset. Usually, this is a disaster, and can
> and should be avoided by synchronizing all data inputs.
> There might be special designs that can tolerate this ambiguity, but
> the best practice is to synchronize.
>
> I have been preaching this for over 40 years, but there are always new
> designers who fall into the old trap...
> Peter Alfke

Well, and then there is the rare case of metastability, where even a
single flip-flop driven with an asynchronous D input, can change its Q
output asynchronously, perhaps moving up and down within a few ns.
Peter Alfke

Article: 149019
Subject: Re: Cant launch ModelSim from Xilin ISE 12.1
From: "HT-Lab" <hans64@ht-lab.com>
Date: Tue, 21 Sep 2010 09:01:44 +0100
Links: << >>  << T >>  << A >>
Not sure if it helps but Mentor's Supportnet newsletter had this today:

Problems running ModelSim from Xilinx ISE

Symptoms

You have more than one simulator loaded, or have replaced an existing one with 
another.
The Xilinx compiled libraries are not valid for the simulation. The default 
information in the modelsim.ini file are not correct.

Causes

The Xilinx project accesses ModelSim from 3 different places, and if they don't 
all point to the same install problems can arise.

Solution

Check that the following all point to the same install:

1) Environment path (check that only one path points to the modelsim 
executables), remove all others. You should have one valid path (Xilinx uses it 
to create the default modelsim.ini file using "vmap -c".
2) Xilinx top Menu: Edit --> Preferences -- ISE General -- Integrated Tools --  
Model Tech Simulator: Example: <Drive>:\<install_dir>\win32pe\modelsim.exe
3) Window "View": M Simuilation; highlight the device in the Hierarchy window. 
Expand Design Utilities and Right Mouse Button 'Compile HDL Simulation 
Libraries' and select 'Process Properties': fill in the GUI as needed.


Hans
www.ht-lab.com

"muhammad_umer" <muhammad_umer@n_o_s_p_a_m.n_o_s_p_a_m.comsats.edu.pk> wrote in 
message news:9qCdnQs3T8C0igrRnZ2dnUVZ_jednZ2d@giganews.com...
> Hi,
> I am developing a design using xilinx ISE 12.1. I have selected ModelSim
> 6.5 SE for simulations. When i run behavioral simulation following error
> comes:
>
>
> ----------------------------------------------------------------------------
> * udo file already exist (pie_tb.udo). It will not be re-generated.
> * creating main do file (pie_tb.fdo) for Behavioral Simulation...
>    > executing 'D:/modeltech_6.5/win32/vsim.exe -version' to get the
> mti_se version...
>    > Modelsim version is 6.5
> * determining pre-compiled simulation library path information...
>   > using mapping file set by MODELSIM env (D:\modeltech_6.5)...
>
> ERROR: Unable to read the "D:\modeltech_6.5" file.
> Reason: couldn't open "D:\modeltech_6.5": permission denied
>
> INFO: Simulation process aborted!
> ----------------------------------------------------------------------------
>
> any one can please help me and tell me why this problem arise. I am using
> administrator account and i also give full rights to modelsim folder. Also
> my integrated tools option is set correctly point towards modelsim exe
> file.
> please guide me how to remove this error.
> Thanks in advance
>
> --------------------------------------- 
> Posted through http://www.FPGARelated.com
> 



Article: 149020
Subject: CLB relative RLOC constraint in Virtex 4?
From: Carl Ingemarsson <carl.ingemarsson@gmail.com>
Date: Tue, 21 Sep 2010 03:07:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi everyone!

I've been trying to constraint a carry chain in my Virtex 4 design to
be placed so that the least significant part of it is in the upper
part of a CLB. By doing this I would have a little more "near" sites
for the lower significant input registers. I want to run ny design
fairy fast and the carry chain is critical. If it's relevant I am
using Xilinx software.

I've managed to do this with fixed location constraints from
PlanAhead, but I would want to use RLOC (and BEL) constraints in my
vhdl source instead since my component is instantiated several times.

I've only been able to use RLOC constraints for this Virtex 4 design
with XY coordinates. Is it somehow possible to have CLB relative RLOC
constraints with Virtex 4? Or is their any other nice solution to my
problem?

Article: 149021
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Jeff Cunningham <jcc@sover.net>
Date: Tue, 21 Sep 2010 10:18:01 -0400
Links: << >>  << T >>  << A >>
Here's another reason to NEVER NEVER NEVER feed asynchronous signals to 
a state machine: Sometimes the back end tools in the default settings 
will replicate flip flops to make routing easier. For instance if there 
is a gray code counter bit that goes to many places, the router could 
split it into two equivalent bits that go to half as many places each.

I have been burned by this before on input deglitching flip flops, where 
the tool replaced it with two parallel deglitching flip flops, which is 
obviously not much of a deglitcher.

There are tool directives to prevent this from happening, but I like to 
do the two deglitchers in series trick so that the first deglitcher will 
only have one load, so it can't be split.

-Jeff


Article: 149022
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Tue, 21 Sep 2010 08:16:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
Concise summary of this thread:

While it's possible to build a state machine that safely handles
asynchronous inputs, there's seldom any justification for it. Failure
to synchronize inputs invites trouble and violates decades of solid
design practice.


Article: 149023
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Andy <jonesandy@comcast.net>
Date: Tue, 21 Sep 2010 08:39:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
Back when we used PALs with only 4 or 8 registers (16R4 & 16R8 PALs),
separately synchronizing an input to a state machine was not always an
option from a resource point of view.

As has been said above, there are methods* of making a state machine
tolerant of asynchronous inputs. But these methods are exceedingly
difficult to verify and/or review, especially when compared to the use
of an explicit synchronizer. Furthermore, these methods are often
thwarted by optimizations that are commonplace in FPGA synthesis
tools. Finally, given the abundance of registers in FPGAs, there is
very rarely an acceptable excuse to not use an explicit synchronizer.

* the rules for these methods are:

1. All transitions of the state machine in response to an asyncrhonous
reset, including any registered outputs, must result in the
possibility of only one bit changing.

1A. A state may have conditional destinations of itself and an
adjacent (on a K-map) state

1B. A state may have two separate destination states that are adjacent
to each other, but then staying in the current state is not allowed.

1C. A state may change a single-bit registered output based on the
async input, but it cannot also transition out of that state at the
same time. An old trick to effectively "re-use" a synchronizing
register was to set a flag while in the state based on the async
input, then transition out of the state based on the flag a clock
later. The same flag could be used in multiple states, for multiple
different async inputs.

The hoops we jumped through to get things done in 8 flops or less...

Andy

Article: 149024
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: d_s_klein <d_s_klein@yahoo.com>
Date: Tue, 21 Sep 2010 09:19:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 7:28=A0pm, John McCaskill <jhmccask...@gmail.com> wrote:
> On Sep 20, 9:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
> wrote:
>
>
>
> > On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
>
> > > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com>
> > > wrote:
>
> > > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > > > > I agree with your last paragraph. It's typically better to use =
a
> > > > > > couple of flops on an asynchronous control signal than trying t=
o
> > > > > > handle it within the state machine (especially if the tool is g=
oing to
> > > > > > take encoding liberties).- Hide quoted text -
>
> > > > > The rule is that any time there is a logic path from an asynchron=
ous
> > > > > input to more than one device that samples the signal(s), you mus=
t
> > > > > first synchronize the signal before feeding it into any logic pat=
h.
>
> > > > > This condition occurs for any state machine with more than flip f=
lop
> > > > > used to implement the state.
>
> > > > > KJ
>
> > > > I agree that this is a rule that should be generally followed, but
> > > > there are exceptions. For example, a gray-coded state machine is
> > > > sometimes used to tolerate an asynchronous control input. If timing=
 is
> > > > violated on any of the flops, the machine will stay at the current
> > > > state or transition to the next state.
>
> > > This is not a rule that "should be generally followed". =A0It is rule
> > > that must ALWAYS be followed!
>
> > > If a signal from a "foreign" clock domain is used in a conditional
> > > inside a state machine, the state machine will fail (eventually).
>
> > > This is NOT a metastability problem. =A0It is because the time to dec=
ode
> > > the D inputs of the state bits is different for each D input, and if
> > > the "foreign clock" signal is used in a conditional it will go to mor=
e
> > > than one D input. =A0There is no way to ensure that the D inputs are =
all
> > > valid at the same time, and when the clock happens while one is valid
> > > and the other is not state machine gets corrupted. =A0This syndrome i=
s
> > > independent of the coding method of the state variable.
>
> > > Synchronizing all inputs to a state machine to the state machines
> > > clock will prevent that.
>
> > > Not optional. =A0Sorry.
>
> > > RK
>
> > RK,
>
> > You'll have to convince me that the rule "must ALWAYS" be followed,
> > independent of state encoding. It still seems to me that gray coding
> > could work - the machine either stays in the current state or
> > transitions to the next state because only one bit is transitioning.
> > If the input to this bit's register meets timing, then the machine
> > goes to the next state; if timing is not met, it either goes to the
> > next state or stays at the current one. The other bits are static.
>
> Must always is too strong. Your Gray coding example is valid and deals
> with the issue of coherency, since only one FF changes state based on
> the asynchronous signal. =A0It does not address the issue of
> metastability, but that is becoming much less of an issue because of
> how fast the FFs have become. =A0There have been post by either Austin
> or Peter that they have a problem even trying to make it happen so
> that they can measure it.
>
> What I would say is that unless you have a very good reason not to,
> you want to just use a synchronizing circuit before you do anything
> else with an asynchronous signal. =A0The cost is usually low, and the
> consequences of doing it another way and getting it wrong are high. =A0I
> have debugged this sort of problem before, and it is a painful
> process. =A0FPGAs and their tools assume that you are using synchronous
> techniques, and can work against you if you deviate from that path.
> They can take your carefully coded Gray state machine and change it to
> one hot if you don't have the proper constraints, or they might
> replicate state registers if they have a high enough fan out and you
> did not turn off that option.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

If, and only if your gray code is implemented with a gray counter.

Otherwise, it's just another state coding, and the idea that only one
bit changes at a time is false.

RK.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search