Please help, Xilinx FIFO problem!

Antti wrote:
> website issues in "solving" state yes!
and which email address works ?

> Antti
yg
-- 
http://ygdes.com / http://yasep.org

On Jan 27, 4:24=A0pm, whygee <y...@yg.yg> wrote:
> Antti wrote:
> > problem fixed!
>
> yeah !!!
>
> > solution and explanation in the next Brain issue
> > (I will post short post also after the issue release)
>
> i'm eagerly waiting :-)
>
> did you solve your website and email issues ?
> how can one contact you ?
> are your "stamps" still available ?
>
> > Antti
>
> yg
>
> --http://ygdes.com/http://yasep.org

website issues in "solving" state yes!

first products using Silicon blue stamps are about to be delivered to
the customers
and we have small batch of the SB stamp modules ready as well

Antti

On Jan 27, 5:40=A0pm, whygee <y...@yg.yg> wrote:
> Antti wrote:
> > website issues in "solving" state yes!
>
> and which email address works ?
>
> > Antti
>
> yg
> --http://ygdes.com/http://yasep.org

Antti.Lukats@googlemail.com

always works :) thats why i use it as preffered :)
if i dont reply, please resend, in very rare cases the mails go to
spam
and I delete spam folder without reading (300+ spam mails per day)

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

On Jan 28, 11:38=A0am, jc <jcappe...@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

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.