Generic Dual Clock FIFO required

Guest
Hello,
I’m looking for Generic Dual Clock FIFO Verilog code.
The I/Os are:
data - input data
wrreq - write request
rdreq - read request
rdclk - read clock
wrclk - write clock
aclr - asynchronous clear
q - output data
rdfull - full flag synchronized to rdclk
rdempty - empty flag synchronized to rdclk
rdusedw - used words synchronized to rdclk
wrfull - full flag synchronized to wrclk
wrempty - empty flag synchronized to wrclk
wrusedw - used words synchronized to wrclk

The dual port RAM inputs are registered.
Any help?

Thank you
 
On Thu, 22 May 2008 07:19:40 -0700 (PDT), japonetz@gmail.com wrote:

I’m looking for Generic Dual Clock FIFO Verilog code.
Presumably you've already done the obvious:

- look at the FPGA toolsets' core generators -
they have ready-to-run dual clock FIFOs
- Google
- this rather interesting paper:
http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO2.pdf

Getting the current number of occupied slots,
in both clock domains, in a way that's totally
consistent with the full and empty flags, is
likely to be non-trivial :)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Dear Jonathan,
Thank you very much for your help.
The paper is very interesting indeed.
But it doesn't cover the "non-trivial" but crucial part of occupied
slots count in both clock domains.
Also, the RAM used there has no registered inputs.
The reason of this mess is that we are moving from FPGA to ASIC, and
we want to be as close to the source as possible.
Any help will be appreciated.

Thanks,
J
On 23 מאי, 10:45, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Thu, 22 May 2008 07:19:40 -0700 (PDT), japon...@gmail.com wrote:
I’m looking for Generic Dual Clock FIFO Verilog code.

Presumably you've already done the obvious:

- look at the FPGA toolsets' core generators -
  they have ready-to-run dual clock FIFOs
- Google
- this rather interesting paper:http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO2.pdf

Getting the current number of occupied slots,
in both clock domains, in a way that's totally
consistent with the full and empty flags, is
likely to be non-trivial :)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Sun, 25 May 2008 02:31:31 -0700 (PDT), japonetz@gmail.com wrote:

crucial part of occupied
slots count in both clock domains.
The traditional approach is to maintain an address pointer
using Gray coding in each clock domain. These addresses
can then be resynchronised into the other clock domain
with no fancy tricks, and a maximum error of 1 count.
Once you have both read and write address pointers
synch'd into a given clock domain, convert both to
binary and subtract; that gives you the population.
I confess I've never worked this through in detail myself -
I've always had access to the IP whenever I've needed it.
It's one of those things that's straightforward enough in
principle, but has many little wrinkles that need
great care in detailed implementation.

Also, the RAM used there has no registered inputs.
I don't really see why this affects things much -
doesn't it just pipeline everything by one clock?
You might need to introduce matching one-clock delays
into some of the control logic paths.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 

Welcome to EDABoard.com

Sponsor

Back
Top