dual clock fifo

of

he clkL

illed

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

e of

ter

ead

or

the clkL

filled

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

dge of

ister

read

(or

on the clkL

re filled

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

sedge of

egister

as read

ue (or

d on the clkL

are filled

ut

ous

xt -

I am not sure if the design would change depending on whether the high and low frequencies change.

Asynchronous.

Yes

Verilog

I dont want the design to be specific to a particular chip.

The cores are not getting simulated with Modelsim XE. And I would like to design my own in either case.

So why are you asking us? ;-)

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.

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

HI,

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

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

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

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

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

KJ

(snip)

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

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

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

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

I found the source code that was available at edif.org through archive.org:

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

The internet never forgets ;)

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:

Thank you everyone for your valuable help.