From: Peter Alfke on
As I wrote, the problem is easy to solve for the synchronous case
(identical clocks) but difficult or impossible to solve for the
asynchronous case.
You wrote synchronous ???
Peter Alfke

On Nov 30, 12:44 am, "heinerl...(a)googlemail.com"
<heinerl...(a)googlemail.com> wrote:
> Hi Peter,
>
> we are using Virtex4 FX devices. The FIFO runs at 100 MHz and was
> generated with coregen 3.5. We just found out that there have been
> several modifications regarding the almost empty signal in coregen
> 4.2. We'll try that out first.
>
> Point is we NEED an almost empty signal at threshold == 1 which we can
> rely on 100%. If I understand you correctly this is not given with the
> Xilinx sync FIFOs so we would have to build our own, right?
>
> regards, Heiner
>
> On Nov 29, 5:35 pm, Peter Alfke <al...(a)sbcglobal.net> wrote:
>
> > On Nov 29, 3:46 am, "heinerl...(a)googlemail.com"
>
> > <heinerl...(a)googlemail.com> wrote:
> > > Hi,
>
> > > we are using an asynchronous FIFO to bridge two clock domains. Both
> > > domains have "the same" clock speed but different clock oscillators.
>
> > > We shift data phits in the FIFO which always form a data packet. In
> > > between a packet data is shifted in continously without a break.
> > > Breaks (no shift in) are only allowed in between packets.
> > > On the output side of the FIFO we need a steady data stream during a
> > > data packet. The packet may not be interrupted. As the input side may
> > > be slower we start shift-out data if at least two data phits are in
> > > the FIFO. As the 2 clocks have almost the same frequency this
> > > guarantees that we never have a buffer underflow.
>
> > > The problem we found is that the almost empty flag is only asserted if
> > > the FIFO is beeing emptied and not if it is beeing filled. So if the
> > > FIFO was empty and we get a shift in the almost empty is not asserted
> > > although we set the treshold to one. Is this a bug?
>
> > Which FPGA family, which type of FIFO controller, and also what clock
> > rate?
> > Peter Alfke, Xilinx Applications>
>
> > > We tried to solve that problem by generating a delay-empty signal at
> > > the output which guarantees that if the FIFO was emtpy and than
> > > receives a shift in we still wait another cycle so we get another
> > > shift in to avoid underflow.
>
> > > This solution however does not solve the problem if the FIFO exactly
> > > had one entry when starting to shift out a packet. In this case
> > > neither delayed-empty nor almost empty is asserted, hence we get an
> > > underflow.
>
> > > Why isn't the almost empty signal asserted every time there is a
> > > single packet in the FIFO? Ideas?

From: Peter Alfke on
On Nov 30, 12:44 am, "heinerl...(a)googlemail.com"
<heinerl...(a)googlemail.com> wrote:
> Hi Peter,
>
> we are using Virtex4 FX devices. The FIFO runs at 100 MHz and was
> generated with coregen 3.5. We just found out that there have been
> several modifications regarding the almost empty signal in coregen
> 4.2. We'll try that out first.
>
> Point is we NEED an almost empty signal at threshold == 1 which we can
> rely on 100%. If I understand you correctly this is not given with the
> Xilinx sync FIFOs so we would have to build our own, right?
>
> regards, Heiner
>
> On Nov 29, 5:35 pm, Peter Alfke <al...(a)sbcglobal.net> wrote:
>
> > On Nov 29, 3:46 am, "heinerl...(a)googlemail.com"
>
> > <heinerl...(a)googlemail.com> wrote:
> > > Hi,
>
> > > we are using an asynchronous FIFO to bridge two clock domains. Both
> > > domains have "the same" clock speed but different clock oscillators.
>
> > > We shift data phits in the FIFO which always form a data packet. In
> > > between a packet data is shifted in continously without a break.
> > > Breaks (no shift in) are only allowed in between packets.
> > > On the output side of the FIFO we need a steady data stream during a
> > > data packet. The packet may not be interrupted. As the input side may
> > > be slower we start shift-out data if at least two data phits are in
> > > the FIFO. As the 2 clocks have almost the same frequency this
> > > guarantees that we never have a buffer underflow.
>
> > > The problem we found is that the almost empty flag is only asserted if
> > > the FIFO is beeing emptied and not if it is beeing filled. So if the
> > > FIFO was empty and we get a shift in the almost empty is not asserted
> > > although we set the treshold to one. Is this a bug?
>
> > Which FPGA family, which type of FIFO controller, and also what clock
> > rate?
> > Peter Alfke, Xilinx Applications>
Heiner, if you have questions about asynchronous FIFOs, just send me
an e-mail.
English oder Deutsch. But I'll be on vacation starting next Tuesday.
Peter Alfke (peter(a)xilinx.com)

> > > We tried to solve that problem by generating a delay-empty signal at
> > > the output which guarantees that if the FIFO was emtpy and than
> > > receives a shift in we still wait another cycle so we get another
> > > shift in to avoid underflow.
>
> > > This solution however does not solve the problem if the FIFO exactly
> > > had one entry when starting to shift out a packet. In this case
> > > neither delayed-empty nor almost empty is asserted, hence we get an
> > > underflow.
>
> > > Why isn't the almost empty signal asserted every time there is a
> > > single packet in the FIFO? Ideas?

From: PatC on
Peter Alfke wrote:
> On Nov 29, 3:46 am, "heinerl...(a)googlemail.com"
>> The problem we found is that the almost empty flag is only asserted if
>> the FIFO is beeing emptied and not if it is beeing filled. So if the
>> FIFO was empty and we get a shift in the almost empty is not asserted
>> although we set the treshold to one. Is this a bug?

You could use the fifo read count and compare it to 1? The latency may
be higher, but it's guarantied there'll be a point there when it asserts.

HTH,
-P@
From: Peter Alfke on
On Dec 2, 8:53 pm, PatC <p...(a)patocarr.com> wrote:
> Peter Alfke wrote:
> > On Nov 29, 3:46 am, "heinerl...(a)googlemail.com"
> >> The problem we found is that the almost empty flag is only asserted if
> >> the FIFO is beeing emptied and not if it is beeing filled. So if the
> >> FIFO was empty and we get a shift in the almost empty is not asserted
> >> although we set the treshold to one. Is this a bug?
>
> You could use the fifo read count and compare it to 1? The latency may
> be higher, but it's guarantied there'll be a point there when it asserts.
>
> HTH,
> -P@

In an asynchronous FIFO, the flags must be synchronized to the
appropriate clock.
The leading edge of Almost Empty is normally generated by the read
clock, and it is the read side that usually worries about (Almost)
Empty. The trailing edge, however, is generated by the write clock,
and (for most purposes) needs re-synchronization to the read clock.
That re-synchronization needs an extra clock edge (or two) to avoid
metastable confusion.
The basic problem is the unknown phase relationship between the two
clocks. The edges can be far apart, but also very close to each other,
down to fractional picoseconds. But the controller has to provide
correct flag outputs. The actual reading and writing is trivial, as
long as the RAM is dual-ported.
Peter Alfke
From: heinerlitz on
HI

as stated we are using the FIFO in an Asynchronous way. The read and
write clock are both 200 MHz but are provided through 2 different
oscillators. We are using the almost empty signal onlyin the read
clock domain. We are currently implementing a single FF stage located
at the output side of the FIFO. If then the FIFO goes empty (and the
empty signal behaves correctly) we can be sure to have another datum
in the FF stage, equaling almost empty.

hope this helps..

regs, Heiner