Hey,

I found an amazing async fifo concept on the xilinx homepage.
It looks that the latency to share data between clock domains is
reduced to one cycle.
But I'm asking if the setup + hold times are always met. I admit that
setting the empty flag is correct but what about releasing, which is
caused by write clock, thus asynchrous?

Sorry, I have forgotten to add the link:
http://www.xilinx.com/support/documentation/application_notes/xapp175.pdf

firefox3107 <f...@gmail.com> wrote:
 
> I found an amazing async fifo concept on the xilinx homepage.
> It looks that the latency to share data between clock domains is
> reduced to one cycle.
> But I'm asking if the setup + hold times are always met. I admit that
> setting the empty flag is correct but what about releasing, which is
> caused by write clock, thus asynchrous?

Not being an expert in FIFO design, as I understand it in any
asynchronous system you have to assume that setup+hold won't always
be met.  In crossing clock domains, either the signal will come
before the clock (and the operation will be performed) or it will
come after (and not be performed).  If it comes after the clock,
then the operation is performed on the next clock cycle.

For FIFOs that is sometimes done by passing a Gray counter output
across the clock domain, in which case either the old or new value
is received on the other side.  Those are the only choices.

-- glen

I'm concerned about metastability and oscillation
and in this
application note the flags are not synchronized with 2 flipflops in
the new clock domain.
So I'm asking if this FIFO design is reliable?

On Jun 30, 10:19=A0pm, firefox3107
<firefox3...@gmail.com> wrote:
> I'm concerned about metastability and oscillation and in this
> application note the flags are not synchronized with 2 flipflops in
> the new clock domain.
> So I'm asking if this FIFO design is reliable?

I have been told by several people (Xilinx FAEs and Xilinx Users) that
the only reliable 2-clock FIFOs are the one created by coregen.

My understanding is that there is some magic (RPMs?) in the macro that
"just work".

My guess is that if you really choose to use this XAPP, you get to
verify it yourself (and re-verify it every time the placement
changes).

RK

In article
<a...@7g2000prh.googlegroups.com>,
d_s_klein  <d...@yahoo.com> wrote:
>On Jun 30, 10:19 pm, firefox3107 <firefox3...@gmail.com> wrote:
>> I'm concerned about metastability and oscillation and in this
>> application note the flags are not synchronized with 2 flipflops in
>> the new clock domain.
>> So I'm asking if this FIFO design is reliable?
>
>I have been told by several people (Xilinx FAEs and Xilinx Users) that
>the only reliable 2-clock FIFOs are the one created by coregen.
>
>My understanding is that there is some magic (RPMs?) in the macro that
>"just work".
>
>My guess is that if you really choose to use this XAPP, you get to
>verify it yourself (and re-verify it every time the placement
>changes).

Not true at all.  If designer's couldn't design cross clock domain
logic on an FPGA there'd be a lot less successful FPGAs :). 
The principal elements of fifo design are well known - there's just tricky
cases to watch out for.

We've designed our own fifo's for generations of FPGAs (from 
multiple vendors).  You don't need "magic" RPMs nor reverification 
of every placement (other than normal STA checks).

Now to the OP - metastability is hardly an issue at these
technologies.  Rather just wise cross clock domain design
techniques.  Does Xilinx use good techniques in their FIFOs?
I can't answer that - I don't use their FIFOs, nor know the
design.  But they're said to be used in millions of parts....

I have also designed async fifos with success.
There is quite a lot of goodinfo out there about them you just need to dig and put it together.Personally I hate using Coregen unless I really have to as it is solimiting when designing memories.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

It seems that everyone has it own point of view
that reliabilty
concerns. :(

I wanna add my design to opencores, so it should be technology
independent.

On Jul 2, 5:32=A0am, firefox3107
<firefox3...@gmail.com> wrote:
> It seems that everyone has it own point of view that reliabilty
> concerns. :(
>
> I wanna add my design to opencores, so it should be technology
> independent.

One clock latency for an empty flag is not easy to achieve.  The
standard method uses binary address counters followed by binary
to Gray code conversion.  This then needs to be registered in
the original clock domain to avoid glitches at the comparator
interface.  To get lower latency you would need to build synchronous
Gray code counters, which takes a bit more logic.  The additional
combinatorial latency for generating large Gray counters can
then reduce the maximum operating frequency of the FIFO.

Regards,
Gabor

On Jul 2, 6:37=A0am, Gabor
<ga...@alacron.com> wrote:
> On Jul 2, 5:32=A0am, firefox3107 <firefox3...@gmail.com> wrote:
>
> > It seems that everyone has it own point of view that reliabilty
> > concerns. :(
>
> > I wanna add my design to opencores, so it should be technology
> > independent.
>
> One clock latency for an empty flag is not easy to achieve. =A0The
> standard method uses binary address counters followed by binary
> to Gray code conversion. =A0This then needs to be registered in
> the original clock domain to avoid glitches at the comparator
> interface. =A0To get lower latency you would need to build synchronous
> Gray code counters, which takes a bit more logic. =A0The additional
> combinatorial latency for generating large Gray counters can
> then reduce the maximum operating frequency of the FIFO.
>
> Regards,
> Gabor

Please allow me to make some comments.
I have been involved in FIFO design since 1970, starting with the
Fairchild 3341, and ending with the industry-first hard-coded FPGA
FIFO designs at Xilinx.

Given true-dual-ported BlockRAMs with independent addressing,
clocking, and control, most of a FIFO design seems to be trivial and
obvious. The devil is in the generation of the control flags Full and
Empty. These flags must be fast and also reliable, i.e. glitch-free.
(The designs are symmetrical, so I will only cover Empty.)
The flags are driven by an identity comparison of the two addresses,
therefore it is wise to use Gray codes. It may also be desirable to
have binary addresses available for arithmetic calculations (almost
empty, Dipstick etc). The simplest solution is to count binary, but
synchronously convert to Gray, so that the two results appear
simultaneously at their respective flip-flop outputs.
That means there is no latency or speed penalty whatsoever for the
conversion. It just costs one extra flip-flop+gate per bit, negligible
in a custom design.
The onset of Empty is caused by the read clock, and is thus naturally
synchronous to the Read side of the design.
The trailing edge of Empty is, however, caused by the write clock.
Without careful synchronization, Empty would have a non-synchronous
trailing edge, which would inevitably lead to malfunction, sooner or
later.
Most of the sometimes acrimonious debates about safe design center
around the synchronization of the trailing edge,and how to avoid
metastability problems. Nobody should bemoan the fact that this
synchronizer consumes time, that Empty thus has a tendency to linger
on for, say, a clock period or even two. That delay does not really
sacrifice performance. (Any delay of the leading edge of Empty would
of course directly affect performance).
We tested the Xilinx hard-coded design by writing at 200 MHz and
asynchronously reading at approx. 500 MHz, so that the Empty flag was
exercised 200 million times per second, and we monitored the address
counters. There was not a single error in a week of testing (10 exp 14
operations) with a forever changing sub-femtosecond timing granularity
between the two clocks. So much about reliability and metastabilty.
(Yes, the Virtex 4 version has a separate unrelated subtle problem,
solved with a well-documented work-around)

Hope this helps somebody.
Peter Alfke, formerly Xilinx Applications.