Two near-identicial clocks?

[Eric]

Hello! I have an app where I have byte-wide data coming in at 125 MHz,
and a system clock running at 125 Mhz, but they're not driven by the
same source (alas). Thus, the source clock could be slightly faster
or slightly slower than the internal system clock. Is there a standard
way of dealing with these sorts of clock-async issues that doesn't
involve an asynchronous FIFO?


I would just use one of the standard FIFOs discussed in the xilinx app
notes and save myself some time and headache, but I read something at
free-ip (http://www.free-ip.com/ramlib/fifo.html) suggesting that the
implementation in the app-notes was patented, and thus even a
reimplementation of their approach wouldn't be allowed in an
open-source hardware project.

So, I was hoping there might be some non-FIFO implementation that
might work Are there any classical approaches to this?
...Eric

 

[Peter Alfke]

If you have to cope with frequency differences ( not just unknown phase
), then a FIFO is your only choice. And you have to have a strategy for
FIFO overflow/underflow, which will inevitably happen.

A Xilinx patent should never be a hindrance to implement such a FIFO in
a Xilinx device. Obviously.

Using a dual-ported RAM for a FIFO is straightforward. The trickery is
in the implementation of FULL and EMPTY signals ( or also ALMOST FULL
and ALMOST EMPTY ).

Peter Alfke (invented the first integrated circuit FIFO, the Fairchild
3341, in 1971)
==================
Eric wrote:

Hello! I have an app where I have byte-wide data coming in at 125 MHz,
and a system clock running at 125 Mhz, but they're not driven by the
same source (alas). Thus, the source clock could be slightly faster
or slightly slower than the internal system clock. Is there a standard
way of dealing with these sorts of clock-async issues that doesn't
involve an asynchronous FIFO?

I would just use one of the standard FIFOs discussed in the xilinx app
notes and save myself some time and headache, but I read something at
free-ip (http://www.free-ip.com/ramlib/fifo.html) suggesting that the
implementation in the app-notes was patented, and thus even a
reimplementation of their approach wouldn't be allowed in an
open-source hardware project.

So, I was hoping there might be some non-FIFO implementation that
might work Are there any classical approaches to this?
...Eric

 

[Erik Spaenig]

Hi,

Mario Trams wrote:

Alternatively you might remove data at the receiver at a rate always
(guaranteed) higher than the source rate. There you need a trivial
FiFo with a depth of 1 (i.e. just a register).

the FiFo-depth of 1 is only enough if the read-speed the double (or faster)
when the write speed. If you have only a littel bit more than you need a
FiFo-depth of 2 or 3 (se the double/tribble-buffering on videoprojektors that
translate 50Hz input-framrate (europa-PAL) into 60Hz LCD-framerate).

@Eric :
how long is an incomming datapacket an how long the delay (for addressing and
others) between the datapackets ??
how big is the diferenz between the clocks ?? (more than 1%)
if you have both answers you can calculate the needet FiFo-depth (+1 for savety)

in my projekt i use 3 buffers(registers) with its own statemaschine in serias
for this problem, if you are interisted on my code then mailto:vikinger@uni.de

Regards,
Erik

--
sorry for my terible english, my favorit language is assembler

 

[Mario Trams]

Erik Spaenig wrote:

Hi,

Mario Trams wrote:
Alternatively you might remove data at the receiver at a rate always
(guaranteed) higher than the source rate. There you need a trivial
FiFo with a depth of 1 (i.e. just a register).

the FiFo-depth of 1 is only enough if the read-speed the double (or
faster) when the write speed. If you have only a littel bit more than you
need a FiFo-depth of 2 or 3 (se the double/tribble-buffering on
videoprojektors that translate 50Hz input-framrate (europa-PAL) into 60Hz
LCD-framerate).

Ok, I agree that a depth of 2 is desired due to practical issues.

Thanks,
Mario