Please help, Xilinx FIFO problem!
in [FPGA]
|
Prev: simulation+configuration with Ethernet Lite MAC (xilinx)
Next: VHDL Manipulation and Generation Intrerface - vMAGIC 0.3.0 released
From: jc on 28 Jan 2010 04:38 Joining in kind of late here--It sounds like you may have a solution and that's great. But here is some food for thought in case you don't understand your failure mechanism yet. It is very interesting to me that the clocks are not derived from same source, but one is pseudo-multiple of the other (write clock is 2x faster than read). Just supposing here: Do you make an assumption that when empty flag goes inactive, you attempt to read multiple pieces of data from FIFO immediately, because the write side "bursts" multiple data on consecutive write clocks? I assume that your read bus is twice as wide as your write bus? If so, this could be a problem IFF read clock is a tiny bit more slower than 2x of write clock, due to variant PPM of respective oscillator frequencies. In other words, I would advise using some type of partial empty flag to *make sure* there is N amount of words in FIFO before reading those N words out. Expanding on this idea, can you (perhaps as a test) add a significant delay from empty flag going inactive before reading FIFO data just to decouple the read clock timing from the write clock timing, in case you are currently "racing" the read out with the write in. - John Cappello
From: Antti on 28 Jan 2010 05:00 On Jan 28, 11:38 am, jc <jcappe...(a)optimal-design.com> wrote: > Joining in kind of late here--It sounds like you may have a solution > and that's great. But here is some food for thought in case you don't > understand your failure mechanism yet. > > It is very interesting to me that the clocks are not derived from same > source, but one is pseudo-multiple of the other (write clock is 2x > faster than read). Just supposing here: Do you make an assumption that > when empty flag goes inactive, you attempt to read multiple pieces of > data from FIFO immediately, because the write side "bursts" multiple > data on consecutive write clocks? I assume that your read bus is twice > as wide as your write bus? > > If so, this could be a problem IFF read clock is a tiny bit more > slower than 2x of write clock, due to variant PPM of respective > oscillator frequencies. In other words, I would advise using some type > of partial empty flag to *make sure* there is N amount of words in > FIFO before reading those N words out. Expanding on this idea, can you > (perhaps as a test) add a significant delay from empty flag going > inactive before reading FIFO data just to decouple the read clock > timing from the write clock timing, in case you are currently "racing" > the read out with the write in. > > - John Cappello TEST setup: PC software that sends commands over GbE-fiber to master board, Master FPGA board sends a short packet SOP<8 byte>EOP into fiber Slave FPGA board receives the 8 byte I PUSHED a key with my hand, and there was never any overflow possible clocks: WR clock deriveved from oscillator on the MASTER via the fiber and MGT using the RECCLK from MGT RD clock derived from oscillator on the SLAVE so the clocks are almost "same" or almost 2X except the oscilator accuracy on master/slave boards. Antti
From: jc on 28 Jan 2010 11:33
I guess I am specifically asking about the precise timing of the reading of data from the FIFO. How soon does the read side attempt to read FIFO data after the empty flag goes low? I argue that doing this too quickly--say, allowing the FIFO empty flag to act as the read enable also--could cause the problems you are seeing if the 62.5M clock source frequency is at the higher end of the "+/- PPM" range while the 125M clock source frequency as at the lower end of its own PPM range. A safe way to do this would be to either add delay from the empty going inactive before reading the FIFO, or use some type of partial empty flag. This is just an idea and I don't claim that this has to be your problem. But I've seen this issue arise with ethernet systems where two boxes attempt to communicate using their own, embedded 125MHz clock source, but +/-200PPM, I believe. |