Lock a clock to a 8B10B data stream?

[Altera_Forum]

Hi there, 

 I am trying to find a way to synchronize a chain of equipments but don't want to use a dedicated clock network.  If I use the transrecivers in Arria II GX to implement GIGE protocol, can I use the clock recovered from the CDR in receiver channel as the reference clock for the CMU PLL in the transmitter channel?  Or, is there a way to lock a local high speed clock to an incoming 8B10B data stream from upstream, and then use this local clock to send out 8B10B data stream to downstream?  From the handbook of Arria 2 GX it seems that the recovered clock (from Rx CDR) is not accessible for FPGA fabric or CMU PLLs. Am I understanding this correct?  Any comment would be greatly appreciated!  Thanks, Hua

[Altera_Forum]

As far as I understand, is rx_clkout the slow clock from receiver CDR PLL. But it's not accessible when using the rate matcher. This restriction is common to all Altera GX receiver designs due to the internal clock architecture. 

 Apart from the question, if the CDR clock output is accessible, I doubt, if it's suited as a TX reference clock by it's jitter specification.

[Altera_Forum]

You are correct. The recovered CDR clock cannot be used as the reference clock for a TX PLL. The reason for this is jitter performance. What you can do is provide an external clock of the same frequency. You can then use a phase-frequency detector to adjust your external clock to match the CDR clock. One example of this is found in Altera's SDI video reference design which you can find under the IP of your Quartus installation. I believe 9.0 and 9.1 even have a version for Arria II GX. 

 Jake

[Altera_Forum]

Thank you all for your reply! 

 If I understand this correctly:   1. When the receiver channel is configured for SDI mode, the rate match fifo is turned off and it provides the recovered clock as rx_clkout, from which we can use a PFD IP to control a external VCXO to lock the local clock onto the incoming data stream.   2. This is not feasible when the receiver channel is configured for GIGE mode because the rate match fifo is turned on.  3. Can I connect the 1.25Gbps 8B10B incoming data stream to two transreceiver blocks, one of them configurated as SDI, coupled with PFD and VCXO to generate a low jitter reference clock for the other transreceiver block configurated as GIGE? Are there anything I should be concerned? (I guess the extra power and signal integrity are among them but it seems to be feasible)  4. Any preferred way of doing this than the solution above?  Warmest regards! Hua

[Altera_Forum]

To ask a possibly ignorant question: What's the purpose of "looping back" the received signal clock? It must be expected to result in worse jitter performance, even with a high quality external PLL.

[Altera_Forum]

I merely referred you to the SDI example to illustrate the use of a PFD to lock on external clock to a CDR clock. I did not mean to insinuate that you use a transceiver in SDI mode (even the SDI example doesn't use the transceiver in SDI mode). 

 The principle remains, you need to find some way to lock the external clock to the CDR clock. I have absolutely no experience with GIGE. From what you're saying it sounds like you don't really get a CDR clock from the receiver. Is that true?  If so, it seems to me what you'll have to do is actually derive a timing signal from the data rate. This is similar to the way we lock the reference clock in the video world. We use the horizontal sync signal (basically the line rate of the video) and we lock the reference clock using that information. It's very low frequency (about 33.5kHz) compared to the actual clock rate (148.5MHz).  Jake

[Altera_Forum]

--- Quote Start ---  To ask a possibly ignorant question: What's the purpose of "looping back" the received signal clock? It must be expected to result in worse jitter performance, even with a high quality external PLL.  --- Quote End ---    I didn't mean to "loop back" the clock to the upstream. The network is a chain of equipments. The receiver receives 8B10B data stream from the upstream, (hopefully) sync itself up and pass the data stream down the line with the transimitter. The objective is to sync all the equipments with clock info embedded in the 8B10B data stream.

[Altera_Forum]

--- Quote Start ---  I merely referred you to the SDI example to illustrate the use of a PFD to lock on external clock to a CDR clock. I did not mean to insinuate that you use a transceiver in SDI mode (even the SDI example doesn't use the transceiver in SDI mode).  The principle remains, you need to find some way to lock the external clock to the CDR clock. I have absolutely no experience with GIGE. From what you're saying it sounds like you don't really get a CDR clock from the receiver. Is that true?  If so, it seems to me what you'll have to do is actually derive a timing signal from the data rate. This is similar to the way we lock the reference clock in the video world. We use the horizontal sync signal (basically the line rate of the video) and we lock the reference clock using that information. It's very low frequency (about 33.5kHz) compared to the actual clock rate (148.5MHz).  Jake  --- Quote End ---    Hi Jake,  Yes, the GIGE mode won't provide CDR clock.   When you are talking about deriving a timing signal, are you saying that you have a embedded timming code/packet in your data stream and is send out in a frequency of 33.5KHz? Our frequency is even lower (500Hz-1KHz), but the peak to peak jitter needs to be less than +-10us along the whole line.  Thanks, Hua

[Altera_Forum]

Considering a typical crystal clock accuracy of 100 ppm, you won't necessarily need a PLL to achieve this specification. With 500 Hz sync rate, the timing error would be below 200 ns.

[Altera_Forum]

You don't necessarily need a dedicated timing signal to recover the clock signal. My understanding is that the GIGE protocol requires constant transmission of the alignment character. This means that data is constantly being sent. The receiver apparently inserts or removes "skip" characters but it lets you know when it does such a thing.  

 You could create your own timing signal once every 2000 received characters (would be 62.5kHz I believe). You likewise create a pulse that occurs once every 2000 clocks based on the reference clock. Then you basically need to adjust the reference clock to keep these two 62.5kHz signals locked (minimize the error between them). If your worst case difference between the two clocks were 100ppm, you would have a worst case error of 16ns (I think I did that right).  You can choose something of lower frequency as well but it must be consistent and remember the lower the frequency of the timing signal, the less accurately you'll be able to lock your reference clock to it (you'll have more wander). Basically between periods of timing signals you are guessing what needs to be done to adjust the reference clock (up, down, hold). I typically use a PID control loop for this.  Are you using a VCXO for your reference clock?  Jake

[Altera_Forum]

Another question (again my ignorance of GIGE). Is it really necessary to lock the clocks? I could see two other alternatives: 

 1 - Are you allowed to transmit NULL or "skip" characters in the middle of a packet or is it only allowed between packets. If you are allowed to transmit NULL characters, then I don't see where it's necessary to lock the clocks at all. If your reference clock is faster than the received data, you just transmit NULL characters between valid characters. If your clock is slower than the received data, you need a large enough FIFO to buffer the data. The size of the buffer depends on your packet length, the estimated difference between the clocks, and this of course assumes some inter-packet gap.  2 - Can you just buffer entire packets and retransmit them? Depending on the packet length and the gap between packets, this seems like the easiest solution.  Jake

[Altera_Forum]

Thanks again for all your replies. I think I may have found a viable solution for the problem.  

 Have a great weekend! Hua