Clock domain crossing (again)

With a 50 MHz reference clock and adequate setup/hold times, you should be able to do the entire design in that domain and never use the 2 MHz clock as a true clock inside the FPGA. First, all signals will need to be clocked through two FFs to minimize metastability. Unfortunately this adds a 50 MHz clock period of jitter to any relative measurement. With a 25:1 clock rate difference this should not be too much of a concern, but keep it in mind as you perform a timing analysis.

Once all signals are sampled into the chip's clock domain you can do a simple edge detection on the incoming 2.048 MHz clock signal to generate a single 50 MHz clock wide, 2.048 MHz enable signal. This will be delayed or the data will be delayed by 50 MHz clock intervals to put your sampling point in the center of your data setup and hold period if it is at all critical.

After that you just use the 2.048 MHz enable signal to gate the handling of the data.

The task isn't that clear, but a 2.048MHz clock makes me suspect there is a serial data stream clocked at 2.048MHz that then is to be retimed onto a 50MHz clock. In this case, there are a number of solutions, but a more definitive statement is required. 2.048MHz is, of course, a very common clock in PCM type applications as used in voice processing.

I *think* the OP is asking how to retime (maintaining the framing) a serial data stream from one clock domain to another.

Cheers

PeteS

That was exactly what I assumed. Regardless, my approach will do the job in any case. This is what we did in a telecom application I worked on where the data rate varied over a wide range from T1 to OC48, but the clock rate remained the same. We maintained an internal bus width at 32 bits but used a clock enable to allow a very wide range of data rates. Of course the input data and clock were synchronized in just the way I described above. If the serial data is being shifted into an

8 or 32 bit register you just gate the 2.048 MHz enable pulse to only allow every Nth pulse through to produce a 2.048/N MHz enable signal.

This approach is very common and not at all hard to understand.

I agree, it is the simplest and most straightforward approach and is likely what the original post is trying to accomplish. With the 25:1 difference in clock speed anything else would be overkill.

KJ

Could'nt agree more! One clock is all you need.

Anyone who have seen a UART with 3 clocks (system, bps, bps*16) raise your hand!

-Burns

I'd question whether ALL input signals need synchronisation FFs into the

50MHz domain. The 2.048MHz clock does, indeed. However, assuming the input data already had adequate setup time from the 2.048MHz clock, it will be safe to sample it against the synchronised (hence, delayed) version of that clock.

Excellent replies, thank you all so much. Let me clear up the application, my apologies for being vague.

As you may have guessed, it's telecom/PCM/T1/E1 application. There's a TX and an RX stream... the TX stream (w.r.t. to the T1 interface - TX = data flowing from the FPGA to the line-side) has a 2.048M clock and a TSD signal, and RX has the same clock and a RSD signal into the FPGA.

What I would like to do is for the RX side, take the incoming RSD stream, and translate it to 1-bit wide 50M pulses. So I would end up with 2 new signals, a 'bit' signal and another 'rsd' signal - the bit signal pulses high for 1-bit in 50M domain when data is avaialble on the 'rsd' line, in 50M. TX works similarly.

I hope this clarifies the applciation.

I really like the initial method suggested - just using 50M to sample the the 2.048M clock and do edge detection on it. It seems very simple. ..

Actually, I forgot to clarify > PeteS wrote:

snipped-for-privacy@gmail.com wrote: ...

I am no expert, but my guess is that if you are generating one clock from the other, things are much easier. And the 1/25 ratio gives you more than enough time to adjust the setup/hold times if you have problems with those.

On the other hand, if you had two independent clocks, the clock error & jitter might have forced you to use an asynchronous FIFO.

-Burns