Logic Glitches in Spartan-3?

On May 23, 6:34=A0pm, Rob Gaddi <rga...@technologyhighland.invalid>
wrote:
> I've got a 24-input AND gate that I'd like to avoid having add another
> register delay to before I toss it across a clock boundary.
>
> =A0 =A0 =A0 =A0 all_done <=3D and_reduce(done);
>
> If I just do it, AND it all together without a flop on the output, does
> anyone know whether I'll get transition glitches (an output of 1 when
> not all inputs are 1)?
>
> I seem to remember something about individual LUTs being glitch-free,
> and the synthesizer has to compose my giant AND out of either a LUT
> tree or a mess o' LUTs "wire-and" driving a carry chain, =A0Offhand, it
> seems like neither structure should glitch. =A0"Try it and see" doesn't
> work; testing all 2^24 combinations and trying to determine whether I
> get a glitch would be a beast of an effort.
>
> Anyone know offhand?
>
> --
> Rob Gaddi, Highland Technology --www.highlandtechnology.com
> Email address domain is currently out of order. =A0See above to fix.

Unless you can guarantee that no more than one of the done bits
changes at any one time, you WILL get glitches sooner or later, and
sooner or later they will line up with the (async) receiveing clock,
and you will have bad data transferred, if you simply leave it up to
the synthesis tool to implement the LUT/Carry structure.

If you force the synthesis tool to implement a specific AND structure,
you may be able to avoid glitches based on how the done bits
collectively behave. For example, if you are only concerned with the
leading edge of all_done, and the done bits monotonically transition
from 0 to 1 (never go back to zero until you don't care), you can
probably get some structure to work reliably.

If you don't have time for an additional clock cycle in the source
domain, do you have time for a half-cycle (register all_done on the
opposite edge of the source clock)?

Depending on the relative clock frequencies and your latency
requirements, you may have time to "filter" the all_done signal in the
destination clock domain, and thus reject glitches.

There are probably many ways to do this, but the conventional approach
of registering all_done in the source domain prior to sampling in the
destination domain is the easiest by far to verify.

Andy

glen herrmannsfeldt wrote:


> 
> It seems to me that a tree of glitch-free LUTs is glitch-free,
> but see what others say.
It seems to me that routing delays will make this not work.
Yes, for exactly one input changing state at a time, your statement
MIGHT still be true, but for multiple inputs changing state at
the same time, such as one input going high while one other
goes low, the propagation of these signals through the routing
will certainly cause glitches.

Now, maybe there is some simplification possible depending on
how this is used.  If the normal state is all inputs false,
and occasionally a few inputs are true, then this might never glitch.
If the normal state is 23 inputs true, and the pattern of which ones
are true changes, then I would expect glitches are possible.

Jon

On Thu, 24 May 2012 14:24:53 +0000 (UTC)
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> 
> Given that it is an AND of done bits, in the usual case each
> one transitions from 0 to 1 until all are 1. 
> 

That's exactly right, and I feel silly for not having mentioned it out
front.  The assertion of all_done, shifted onto a different clock
domain, is what goes back around and asynchronously
clears all of the individual done flags.

All of you stop wincing; I know exactly how bad that sounds and I
swear to god there are reasons it had to be this way.

So the only possible modes of operation are:
  all_done is low, and all I want is for it to never erroneously
  transition high until all 24 done flags come up.  Once it's up it
  stays up.

  all_done has been high, causing a 20 ns asynchronous clear pulse to
  hit all the done flags, dropping them all.  In this case, all_done
  should drop once and only once as the various path skews from the
  pulse to the clear to the AND gate structure all work themselves out.

The reason I'm concerned about glitches is, because all_done is sampled
asynchronously to it's originating clock, a glitch could happen to get
captured, with some unknown but small probability.  The reason I can't
just test it out is the same: given that if a glitch exists there's
only a small probability of capturing it, I might test a given
sequence 10,000 times without catching a glitch that I would have seen
on the 10,001st.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
> On Thu, 24 May 2012 14:24:53 +0000 (UTC)

(snip, I wrote) 
>> Given that it is an AND of done bits, in the usual case each
>> one transitions from 0 to 1 until all are 1. 

> That's exactly right, and I feel silly for not having mentioned 
> it out front.  The assertion of all_done, shifted onto a different 
> clock domain, is what goes back around and asynchronously
> clears all of the individual done flags.

You mean a register between all_done and when it goes back around?
I would call it asynchronous if there wasn't a register there.

> All of you stop wincing; I know exactly how bad that sounds and I
> swear to god there are reasons it had to be this way.

If there is a zero hold time register (And even if not, the 0
signal won't make it back fast enough to cause problems.)
then that is fine. If there is no register around the loop,
then it takes somewhat more analysis.

> So the only possible modes of operation are:
>  all_done is low, and all I want is for it to never erroneously
>  transition high until all 24 done flags come up.  Once it's up it
>  stays up.

You don't say about any possibly glitches on inputs to the AND.

>  all_done has been high, causing a 20 ns asynchronous clear pulse to
>  hit all the done flags, dropping them all.  In this case, all_done
>  should drop once and only once as the various path skews from the
>  pulse to the clear to the AND gate structure all work themselves out.

The only way you could know the pulse was 20ns is coming from a FF
clocked at 50MHz, so I will assume that. In that case, you only have
to worry about glitches that last longer than 20ns. That is, after
all_done has been latched, could it glitch low 20ns later. The AND
gate shouldn't do that itself, but if its inputs can, that could
still be a problem. But 20ns is pretty long, so you should be able
to prove that can't happen. 

> The reason I'm concerned about glitches is, because all_done is sampled
> asynchronously to it's originating clock, a glitch could happen to get
> captured, with some unknown but small probability.  The reason I can't
> just test it out is the same: given that if a glitch exists there's
> only a small probability of capturing it, I might test a given
> sequence 10,000 times without catching a glitch that I would have seen
> on the 10,001st.

There is another problem not discussed yet: metastability.
Metastability is completely separate from race conditions, but
people sometimes get the two confused. You need to separately 
show that metatability isn't a problem. 

I am still not sure where the registers are, so I won't try to
say more about metastability.

Also, if there is no register around the loop (which seems 
unlikely mentioning clock domains) then it takes different
treatment.

-- glen

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

>I've got a 24-input AND gate that I'd like to avoid having add another
>register delay to before I toss it across a clock boundary.
>
>	all_done <= and_reduce(done);
>
>If I just do it, AND it all together without a flop on the output, does
>anyone know whether I'll get transition glitches (an output of 1 when
>not all inputs are 1)?
>
>I seem to remember something about individual LUTs being glitch-free,
>and the synthesizer has to compose my giant AND out of either a LUT
>tree or a mess o' LUTs "wire-and" driving a carry chain,  Offhand, it
>seems like neither structure should glitch.  "Try it and see" doesn't
>work; testing all 2^24 combinations and trying to determine whether I
>get a glitch would be a beast of an effort.
>
>Anyone know offhand?

You'll get glitches for sure due to different routing delays between
the LUTs themselves and the input signals.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On Friday, May 25, 2012 7:13:51 AM UTC+12, Rob Gaddi wrote:
> The reason I'm concerned about glitches is, because all_done is sampled
> asynchronously to it's originating clock, a glitch could happen to get
> captured, with some unknown but small probability.  The reason I can't
> just test it out is the same: given that if a glitch exists there's
> only a small probability of capturing it, I might test a given
> sequence 10,000 times without catching a glitch that I would have seen
> on the 10,001st.

 Since this seems to be a slow handshake, and you do not expect it to spin at 50MHz, but you do want to avoid another register in the 'go' pathway, why not design your state handshake, so single-pulse glitches are tolerated/ignored ?

>On Thu, 24 May 2012 14:24:53 +0000 (UTC)
>glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> 
>> Given that it is an AND of done bits, in the usual case each
>> one transitions from 0 to 1 until all are 1. 
>> 
>
>That's exactly right, and I feel silly for not having mentioned it out
>front.  The assertion of all_done, shifted onto a different clock
>domain, is what goes back around and asynchronously
>clears all of the individual done flags.
>
>All of you stop wincing; I know exactly how bad that sounds and I
>swear to god there are reasons it had to be this way.
>
>So the only possible modes of operation are:
>  all_done is low, and all I want is for it to never erroneously
>  transition high until all 24 done flags come up.  Once it's up it
>  stays up.
>
>  all_done has been high, causing a 20 ns asynchronous clear pulse to
>  hit all the done flags, dropping them all.  In this case, all_done
>  should drop once and only once as the various path skews from the
>  pulse to the clear to the AND gate structure all work themselves out.
>
>The reason I'm concerned about glitches is, because all_done is sampled
>asynchronously to it's originating clock, a glitch could happen to get
>captured, with some unknown but small probability.  The reason I can't
>just test it out is the same: given that if a glitch exists there's
>only a small probability of capturing it, I might test a given
>sequence 10,000 times without catching a glitch that I would have seen
>on the 10,001st.
>
>-- 
>Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>Email address domain is currently out of order.  See above to fix.
>

Perhaps a silly question, but why can you not register 'all_done'?

For extra safety, don't assert 'clear_dones' until 2 or 3 successive
highs.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com