dual clock fifo

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I wish to design a FIFO to tansfer data from a high speed clock
domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use
the cores available from any of the vendors.

Inputs =>
DataIn       // 16 bit data input that is latched in on the posedge of
clkHigh when Wen is high
Wen         // Write enable to strobe in the data into the register
Ren         // read enable strobe to let the reg know data was read
out of the DataOut register
clkHigh    // High speed clock for writing data in
clkLow    // low speed clock for reading data out

Outputs =>
DataOut    // 16 bit data out that is changed  to the next value (or
all low if nothing is yet stored inside) when Ren
                 goes low after toggling high based on the clkL
Full          // signal goes high when all input registers are filled
up.
Empty     // Goes high when nothing

How to decide on the depth of register DataOut to ensure that data is
not overwritten. The issue is that the FIFO has to have some high
speed storage capacity to allow for more data coming in then was
written out.

Any suggestions would be appreciated.






Re: dual clock fifo
Quoted text here. Click to load it

You need to know at what average and what burst rates you need to
design for, both filling and emptying the FIFO.  Without a limit on
the input fill rate, you need an infinite-sized FIFO.  So - figure out
your limits and design your FIFO based on max fill and min empty rate
conditions.  Otherwise, FIFOs *can* be straight-forward.  Synchronous
FIFOs are easier if the 320 MHz and 40 MHz domains are precisely
aligned but Gray code based FIFOs for asynchronous domains aren't too
much worse as long as you don't need to cut the delay for a new value
to the absolute minimum time possible; an extra clock of delay makes
things work beautifully.

- John_H

Re: dual clock fifo
Quoted text here. Click to load it

The FIFO is 16 bits wide and 8 words deep. The purpose of using this
FIFO is for synchronization between the 2 clock domains.

Re: dual clock fifo
Quoted text here. Click to load it

So if you know it's 8 words deep, what's the problem?  Is it that you
don't know how to design a FIFO from scratch since you don't want to
use a core?

Please specify if the domains are 100% synchronous or if they're
asynchronous.  If you can't guarantee phase alignment of the two
domains, consider it asynchronous.

Please verify that you want the empty flag on the read side and the
full on the write side.

Specify whether you're a VHDL or Verilog engineer.

What family and vendor is your FPGA?  Do you want to target a specific
memory type (such as CLB SelectRAM or M512 RAMs)?

You're no stranger to the board so this doesn't appear to be homework;
why avoid the cores?

- John_H

Re: dual clock fifo
Quoted text here. Click to load it
I am not sure if the design would change depending on whether the high
and low frequencies change.
Quoted text here. Click to load it
Asynchronous.
Yes
Verilog
I dont want the design to be specific to a particular chip.
Quoted text here. Click to load it
The cores are not getting simulated with Modelsim XE. And I would like
to design my own in either case.
Quoted text here. Click to load it


Re: dual clock fifo
<snip>
Quoted text here. Click to load it
<snip>

So why are you asking us? ;-)

Re: dual clock fifo
Quoted text here. Click to load it

If I was you, I really would use a vendor-supplied core. Xilinx and Altera
(and I suspect others) provide these free and they've been well tested in
many, many designs. The port names may differ between different vendors but
you can make the FIFO virtually vendor-agnostic by providing a trivial
wrapper to name the ports as you wish.



Re: dual clock fifo
Quoted text here. Click to load it

If for some (strange) reason you want to roll your own,
 you face three challenges around the FULL flag:
You must detect FULL fast enough, within a 3 ns period.
And you must release FULL in response to a read clock, without getting
into metastable problems.
And you must compare the two counters without decoding glitches.
All this is stuff the we core designers have solved already for you,
at much higher speed...
Peter Alfke, Xilinx

Re: dual clock fifo
HI,

I suggest u to once look into elastic buffers may be tht'll help
you...........

Re: dual clock fifo
Quoted text here. Click to load it

One reason would be to permit the use of generics. I often use fifos
and I try to use generics whenever possible in the rest of my designs
but unfortunately, coregen fifos are not compatible with generics. I
therefore end up having to create _several_ fifo ngc cores and this is
really a pain in the butt for a large design. We are seriously
considering rolling our own to ease design reuse with generics
(although we haven't yet because we understand that async fifos are
tricky to design, as proven by the V4 bug).

Can we hope to see generic coregen cores one day?

Patrick




Re: dual clock fifo
Quoted text here. Click to load it

Google for lpm_fifo_dc and then ask Xilinx why they don't support EIA
standard LPM 220 components.

KJ

Re: dual clock fifo
Quoted text here. Click to load it

Very interesting, thank you. My understanding is that source code was
available a while ago (edif.org) but this doesn't seem to be the case
anymore. Any idea where I could find some source code?

Patrick

Re: dual clock fifo
Quoted text here. Click to load it

Altera (Sim model and synthesis)
Synplicity (synthesis only)
Lattice (synthesis only)
ISE (synthesis only, .TDF files)

And that's the rub when it comes to LPM, you can't always get
simulation models from the various synthesis vendors even though they
'support' it.  The resourceful designer though might see that using
the same interface that LPM uses (i.e. generics and signals) would
make for a good starting point for making their own...while grumbling
to the suppliers about their lack of sim support for a standard that
they 'support'...while they try to claim that 'their' fifo interface
is somehow superior to some others....even though it's not, their
implementation of a fifo might be better, but the interface TO the
fifo is not.

The other reality is that by making you jump through hoops with their
various wizards that purport to 'help' they lock you into their stuff
just a bit.

KJ

Re: dual clock fifo
Quoted text here. Click to load it

I found the source code that was available at edif.org through
archive.org:
http://web.archive.org/web/20031204114425/http://www.edif.org/lpmweb/more/vhdl.htm

It looks like complete source code, I'm not sure what additionnal
support I would need from vendors. It seems to me that I could just
use lpm_fifo_dc from 220model.vhd. Am I missing something?

Patrick



Re: dual clock fifo

Quoted text here. Click to load it
http://web.archive.org/web/20031204114425/http://www.edif.org/lpmweb/more/vhdl.htm

The internet never forgets ;)

Quoted text here. Click to load it

The code is synthesizable as is,
but I would at least clean up the
non-standard libraries and the
odd-ball string generics.

    -- Mike Treseler

ps: here's a first cut:
http://home.comcast.net/~mike_treseler/sync_fifo.vhd



Re: dual clock fifo
Quoted text here. Click to load it

Thank you everyone for your valuable help.

Re: dual clock fifo
Quoted text here. Click to load it

Peter,

Would it be valid to say that if the user doesn't need a(n almost)
full flag on the read side or an (almost) empty flag on the write side
that a FIFO design would be pretty relaxed?

It's often preferred to have flags act as fast as possible in the
"other" clock domain such that adding an extra clock cycle or more in
the read domain after a write or vice-versa isn't an acceptable
solution.  I've been able to have my systems work well without this
stressful need.

Or is there more of a nuance that I haven't yet understood?

I appreciate your guidance,
- John_H

Re: dual clock fifo
Quoted text here. Click to load it

Hi John,the problem we faced when designing a generic core (in my case
a "hard" FIFO), is that it has to be universal: run at 550 MHz, stop
on FULL and EMPTY, have fully programmable ALMOST flags. That requires
both binary and Gray counters, and very fast decoders, plus some
metastable protection.

A more limited design is obviously simpler.
No programmable ALMOST flags 3D% no need for binary counters.
"Only 320 MHz" 3D% ever so slightly relaxed timing.
But with no ALMOST flags, the write or read must be stopped in one
clock cycle !
Most users (have to and will) accept an extra delay in the release of
FULL or EMPTY, as a protection against metastability confusion.
The depth of a FIFO is irrelevant, as long as it is deep enough.
Dual-ported RAMs are a great help for the designer.
You can imagine that (after the Virtex-4 FIFO experience) we tested
the hell out of the Virtex-5 hard FIFO. We ran it for weeks with two
asynchronous clocks of several hundred MHz, just dancing around EMPTY.
No error in E14 "going empty" operations... It's a solid design.
Peter Alfke, Xilinx

Re: dual clock fifo

(snip)

Quoted text here. Click to load it

I would think that if you had almost full and almost empty
delayed by a cycle or two that would work well.  With
full and empty you tend to want them without delay.

-- glen


Re: dual clock fifo
Quoted text here. Click to load it

More precisely: FULL and EMPTY must go active "without delay", but the
process of going inactive crosses between the clock domains, and
usually involves an extra clock delay to protect against metastable
confusion.
Peter Alfke

Site Timeline