Prev: Altera LP6 Logic Programming Card - Supplier
Next: XUPV5-LX110T, DDR2, and EDK (10.1 to be precise)
From: John Adair on 12 Dec 2009 12:55
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...(a)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 = b ? 1 : count[0];
>
> I'm using a Spartan3 FPGA.
>
> Thanks,
> Diego      
>
> ---------------------------------------        
> This message was sent using the comp.arch.fpga web interface onhttp://www..FPGARelated.com

From: Antti on 12 Dec 2009 13:28
On Dec 12, 8:07 pm, Jonathan Bromley <jonathan.brom...(a)MYCOMPANY.com>
wrote:
> On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d...(a)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

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

Antti



From: Peter Alfke on 12 Dec 2009 14:26
On Dec 12, 11:12 am, "dlopez" <d...(a)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
>
> ---------------------------------------        
> 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.
From: KJ on 12 Dec 2009 14:57
On Dec 12, 2:12 pm, "dlopez" <d...(a)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 (=50 ns) + T2 (=T5 + T6 = 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
From: KJ on 12 Dec 2009 20:06
On Dec 12, 3:46 pm, "dlopez" <d...(a)designgame.ca> wrote:
> However, there are two things to consider:
> 1)the sync fifo is more like 25MB/s sustained (it bursts out at 60, but in
> the end you get 25).

That's because the part runs out of data (read) or can't send it out
fast enough (write). The effective throughput is limited by how well
the USB engine and whatever is on the other end can transfer data, not
because of some inherent issue with the synchronous interface.

> 2)the async FIFO has TWO channels, at say 10MB/s. So overall it might be a
> bit less, but the fact that the two channels run in parallel GREATLY
> simplify my system since I can separate control and streaming data.
>

OK, but then if you have a justification for why you''re willing to
sacrifice performance you shouldn't worry too much about limiting it a
bit more by your choice of data connection.

> Now I'm REALLY struggling to get the state machine with 3 states to run at
> more than 100MHZ!!!

Using the synchronous protocol you'd only need to run at 60 MHz.

Good luck, sounds challenging and that always makes life interesting.

Kevin Jennings
 |  Next  |  Last
Pages: 1 2 3
Prev: Altera LP6 Logic Programming Card - Supplier
Next: XUPV5-LX110T, DDR2, and EDK (10.1 to be precise)