How to tolerate the different clock ppm

[jasonkee111]

Hi

Can someone explain on how to compensate the different clock ppm(different crystal) in a design? Is there any recommended article?

Thanks

 

[TrickyDicky]

Use a FIFO to cross the clock boundary.

 

[wsong0210]

there is no way to compensate as clocks from two crystals are from two different sources with two different frequency, even if they claim to have the same frequency.
FIFO is useful when a huge amount of data need go across two clock domains.
You can also use 2-FF synchronizers to deliver single bit control signals between clock domains.

 

[jasonkee111]

there is no way to compensate as clocks from two crystals are from two different sources with two different frequency, even if they claim to have the same frequency.
FIFO is useful when a huge amount of data need go across two clock domains.
You can also use 2-FF synchronizers to deliver single bit control signals between clock domains.

Are you sure that there is no way to compensate the different ppm? It is because i came across the rate matcher in the altera transceiver is able to compensate the different ppm.

 

[wsong0210]

I suppose the transceiver is only available for IO. What we are talking is about different clocks inside the design. If you are asking about receiving a signal from another chip, which is driven by another clock, it is totally another question.

 

[permute]

serial links have always been designed for this. for example, RS232 which is oversampled. High speed serial links can make use of clock control characters -- patterns in the data that mean nothing, but can be ignored or duplicated as needed to move the rx fifo away from empty (symbol duplicated) or full (symbol removed).

the clock-data-recovery process also generates a clock. this might be used as well. I'm not sure this clock can be used for the TX clock as it might have excessive jitter.

 

[mrflibble]

Can you give a more complete discription of the problem? There's tons of answers to your nice generic question.

Here's one: use a pll. Here's another: use a fifo. Here's yet still another: use an ovenized XO, and do a feedback loop to set temp. Oh oh oh, or use a serdes. All of which could be applicable or not to ... what was your exact problem again? You have 2 different oscillators somewhere somehow connected some way. And then ... ?

Kindly provide detail.

 

[jasonkee111]

wsong0210

I suppose the transceiver is only available for IO. What we are talking is about different clocks inside the design. If you are asking about receiving a signal from another chip, which is driven by another clock, it is totally another question.

What is the different between in different clock inside the design and receiving a signal from another chip, which is driven by another clock?

permute,

...High speed serial links can make use of clock control characters -- patterns in the data that mean nothing, but can be ignored or duplicated as needed to move the rx fifo away from empty (symbol duplicated) or full (symbol removed).

How can insert or remove symbol help to eliminate the ppm difference?

mrflibble,

Can you give a more complete discription of the problem?

i am trying to design a simple high speed serial interface which enables the communication between 2 FPGAs.


Hi all,

Is there any article, book or journal that talk about what to considerate in high speed serial interface design or concept of it?

Thanks

 

[permute]

See Xilinx's GTP/GTX guides for the Virtex5, Virtex6, and Spartan6 FPGAs. These describe Xilinx's implementation as well as the general theory behind high speed links.

the clock chars are either added twice to a fifo (to increase the number of elements in the fifo quickly), or are not added to a fifo (to prevent an increase in the number of elements). when the fifo read rate is approximately the same as the write rate, this will tend to keep the fifo half-full/half-empty. The maximum PPM difference determines an open-loop slip rate. along with the fifo size, this sets the frequency at which clock corrections must be applied (or they may be applied more often). For packetized systems, the clock correction might be done before the header or after the footer of a packet.

Alternatively, for ad-hoc protocols, you might have a protocol where each side echos any clock character it sees (as long as at least N cycles pass between clock corrections). This would be a potentially lower overhead, closed-loop method.

And finally, you can schedule clock-correct characters during idle periods.