Does a 1-bit mux glitch if only one input is known to change at one time?

Hi,

Would wire 'a' in this case be glitch free if:

1) count[0] comes out of a flip flop.
2) I can garantee that 'count[0]' is stable when 'b' is changing (but
'count[0]' might be high or low). 
3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
glitch free as well.
4) 'b' is a fully asynchronous signal

wire a = b ? 1 : count[0];


I'm using a Spartan3 FPGA.

Thanks,
Diego	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

You still will need to make sure you meet setup and hold to avoid
glitches.

If the system allows it would be better to put ;b; into the same clock
domain. Running as fast a clock as you can can minimise this inducted
jitter of an edge. With careful design and keeping it simple you could
probably run a 200Mhz clock giving a jitter window of 5 nS by
synchronising 'b'.

John Adair
Enterpoint Ltd.

On 12 Dec, 15:52, "dlopez" <d...@designgame.ca> wrote:
> Hi,
>
> Would wire 'a' in this case be glitch free if:
>
> 1) count[0] comes out of a flip flop.
> 2) I can garantee that 'count[0]' is stable when 'b' is changing (but
> 'count[0]' might be high or low).
> 3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
> glitch free as well.
> 4) 'b' is a fully asynchronous signal
>
> wire a =3D b ? 1 : count[0];
>
> I'm using a Spartan3 FPGA.
>
> Thanks,
> Diego =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> This message was sent using the comp.arch.fpga web interface onhttp://www=
.FPGARelated.com

On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d@designgame.ca> wrote:

>Would wire 'a' in this case be glitch free if:
>
>1) count[0] comes out of a flip flop.
>2) I can garantee that 'count[0]' is stable when 'b' is changing (but
>'count[0]' might be high or low). 
>3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
>glitch free as well.
>4) 'b' is a fully asynchronous signal
>
>wire a = b ? 1 : count[0];
>
>I'm using a Spartan3 FPGA.

As John Adair hinted, the only truly safe way to do this is 
synchronously - which you've indicated is not possible.

There is no fundamental reason to assume that ANY combinational
logic will be glitch-free in a LUT-based FPGA.  In such FPGAs your
2-input OR gate (for that is what it is) will be implemented in
a LUT.  That means the LUT's address decoder will be changing
when either of the two inputs b,count[0] changes; and, in 
principle, all bets are off about glitches.  In practice the
LUTs seem very well behaved, and Xilinx experts may be able
to tell you how to do this in a way that's guaranteed glitch-free.
Personally, though, I wouldn't bet my life on it.  Find a solution
that doesn't depend on freedom from glitches at that level.
-- 
Jonathan Bromley

On Dec 12, 8:07=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d...@designgame.ca> wrote:
> >Would wire 'a' in this case be glitch free if:
>
> >1) count[0] comes out of a flip flop.
> >2) I can garantee that 'count[0]' is stable when 'b' is changing (but
> >'count[0]' might be high or low).
> >3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
> >glitch free as well.
> >4) 'b' is a fully asynchronous signal
>
> >wire a =3D b ? 1 : count[0];
>
> >I'm using a Spartan3 FPGA.
>
> As John Adair hinted, the only truly safe way to do this is
> synchronously - which you've indicated is not possible.
>
> There is no fundamental reason to assume that ANY combinational
> logic will be glitch-free in a LUT-based FPGA. =A0In such FPGAs your
> 2-input OR gate (for that is what it is) will be implemented in
> a LUT. =A0That means the LUT's address decoder will be changing
> when either of the two inputs b,count[0] changes; and, in
> principle, all bets are off about glitches. =A0In practice the
> LUTs seem very well behaved, and Xilinx experts may be able
> to tell you how to do this in a way that's guaranteed glitch-free.
> Personally, though, I wouldn't bet my life on it. =A0Find a solution
> that doesn't depend on freedom from glitches at that level.
> --
> Jonathan Bromley

I am almost sure Xilinx claims the LUT output is glitch-free
(under all conditions)

Antti

Jonathan Bromley <jonathan.bromley@mycompany.com> wrote:
> On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d@designgame.ca> wrote:
 
>>Would wire 'a' in this case be glitch free if:

>>1) count[0] comes out of a flip flop.
>>2) I can garantee that 'count[0]' is stable when 'b' is changing (but
>>'count[0]' might be high or low). 
>>3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
>>glitch free as well.
>>4) 'b' is a fully asynchronous signal

>>wire a = b ? 1 : count[0];

>>I'm using a Spartan3 FPGA.
 
> As John Adair hinted, the only truly safe way to do this is 
> synchronously - which you've indicated is not possible.

I think asking about glitches indicates the desire to not 
use synchronous logic.  While most people do, not everyone does.
 
> There is no fundamental reason to assume that ANY combinational
> logic will be glitch-free in a LUT-based FPGA.  In such FPGAs your
> 2-input OR gate (for that is what it is) will be implemented in
> a LUT.  That means the LUT's address decoder will be changing
> when either of the two inputs b,count[0] changes; and, in 
> principle, all bets are off about glitches.  

I will see what Xilinx says about this.  There are too many cases
in current designs where glitches like this would cause problems.
Now, changing two LUT inputs is likely to glitch if you can't
guarantee the intermediate states.  It might be, though, that the
decoders are implmented as two input MUX such that changing one
input won't glitch.  If you change more than one and the intermediate
states are consistent such that there is no glitch for any order
(which you likely can't predict) then it also shouldn't glitch.

All that really matters, though, is that any glitches are faster
than subsequent logic can see.  (Considering, for example, input
capacitance and drive strength.)

> In practice the
> LUTs seem very well behaved, and Xilinx experts may be able
> to tell you how to do this in a way that's guaranteed glitch-free.
> Personally, though, I wouldn't bet my life on it.  Find a solution
> that doesn't depend on freedom from glitches at that level.

-- glen

Alright I guess I should have posted what I was trying to do in the first
place...maybe the asynchronous way is just not the way to go.

I'm designing the interface with the FT2232H chip in Asynchronous Fifo
Mode. I want to maximize throughput. The timing diagram is on page26,
figure 4.5:

http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf

RXF: fully asynchronous input to FPGA
RD#: output from FPGA
D[7:0]: input to FPGA, needs to be grabbed when RD# goes high.

Now this has to be the most confusing timing diagram in the world, but
after hours of starring at it, I think I got it:

1)RXF goes low
2)FPGA drives RD# low...need to stay low 50ns
3)FPGA drives RD# high and grab the data.
4)RXF will stay low up to 25ns, then go high. It will stay high UP TO
67ns(but could be less). 
5)When RXF goes low again, we repeat this sequence.

What I'm struggling with is that when RXF goes low, the FPGA should bring
RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted
time that would reduce throughput.

Any ideas?
Thanks,
Diego

	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

On Dec 12, 11:12=A0am, "dlopez" <d...@designgame.ca> wrote:
> Alright I guess I should have posted what I was trying to do in the first
> place...maybe the asynchronous way is just not the way to go.
>
> I'm designing the interface with the FT2232H chip in Asynchronous Fifo
> Mode. I want to maximize throughput. The timing diagram is on page26,
> figure 4.5:
>
> http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf
>
> RXF: fully asynchronous input to FPGA
> RD#: output from FPGA
> D[7:0]: input to FPGA, needs to be grabbed when RD# goes high.
>
> Now this has to be the most confusing timing diagram in the world, but
> after hours of starring at it, I think I got it:
>
> 1)RXF goes low
> 2)FPGA drives RD# low...need to stay low 50ns
> 3)FPGA drives RD# high and grab the data.
> 4)RXF will stay low up to 25ns, then go high. It will stay high UP TO
> 67ns(but could be less).
> 5)When RXF goes low again, we repeat this sequence.
>
> What I'm struggling with is that when RXF goes low, the FPGA should bring
> RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted
> time that would reduce throughput.
>
> Any ideas?
> Thanks,
> Diego
>
> --------------------------------------- =A0 =A0 =A0 =A0
> This message was sent using the comp.arch.fpga web interface onhttp://www=
.FPGARelated.com

I have answered this particular question dozens of times while I was
working at Xilinx.
Today, I googled for "lut glitches" and here is what I found:

http://www.castalk.com/ftopic12373.html

In short:
changing a SINGLE lut input will NEVER generate a glitch.

Peter Alfke, quoting himself.

On Dec 12, 2:12=A0pm, "dlopez" <d...@designgame.ca> wrote:
> Alright I guess I should have posted what I was trying to do in the first
> place...maybe the asynchronous way is just not the way to go.
>

With FPGAs going synchronous design is usually the best...

> I'm designing the interface with the FT2232H chip in Asynchronous Fifo
> Mode. I want to maximize throughput. The timing diagram is on page26,
> figure 4.5:
>
> http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf
>

Yes, I see it...it immediately follows figure 4.4 and the description
on pages 24 and 25 of SYNCHRONOUS Fifo mode operation...

>
> What I'm struggling with is that when RXF goes low, the FPGA should bring
> RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted
> time that would reduce throughput.
>
> Any ideas?

In the end, asynchronous mode operation of the fifo will never be able
to come close to getting the throughput that you can get with
synchronous mode operation.

For this particular part, it looks like you can clock the fifo at 60
MHz for synchronous mode.  For async operation, the theoretical best
performance (and not actually achievable in any real design because it
assumes zero prop delay, PCB delay, setup or hold time) is a clock
period of T1 (=3D50 ns) + T2 (=3DT5 + T6 =3D 0 + 33 ns) for a total of 83
ns...5 times slower than synchronous mode...and not achievable
either.  In reality you'd probably be lucky to get the whole thing to
run with a 100 ns clock...6 times slower than synchronous mode.

You say you want to get the data 'as soon as possible', but that's not
a real requirement.  Do the analysis and figure out what sort of
performance you actually need.  Then you can decide whether the ~10
MHz operation of async mode operation is acceptable.  If not, then
you'll have to run the fifo synchronously.

Kevin Jennings

On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke
<alfke@sbcglobal.net> wrote:

>In short:
>changing a SINGLE lut input will NEVER generate a glitch.

Nice to know, and - thinking about the likely structures
for the guts of a LUT - perfectly reasonable.  Thanks.

However.... can all other manufacturers of LUT-based 
FPGAs make the same promise?  Again, *probably* yes; 
but would you bet your life/reputation/fortune on it?
-- 
Jonathan Bromley