From: Mark Curry on
In article <aef37803-9ae0-41e9-84ae-c50aaa4f40f9(a)7g2000prh.googlegroups.com>,
d_s_klein <d_s_klein(a)yahoo.com> wrote:
>On Jun 30, 10:19�pm, firefox3107 <firefox3...(a)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....


From: maxascent on
I have also designed async fifos with success. There is quite a lot of good
info 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 so
limiting when designing memories.

Jon

---------------------------------------
Posted through http://www.FPGARelated.com
From: firefox3107 on
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.
From: Gabor on
On Jul 2, 5:32 am, firefox3107 <firefox3...(a)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
From: Peter Alfke on
On Jul 2, 6:37 am, Gabor <ga...(a)alacron.com> wrote:
> On Jul 2, 5:32 am, firefox3107 <firefox3...(a)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

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.