08-11-2017 05:31 AM
How to Snyc one 7 Series Transceiver to another 7 series Transceiver?
I am working with 12G SDI video Reciver which gives 4 3G-SDI video ouput running in one Transeiver bank(in my case Bank 115 of kintex xc7k325tffg900-3) . Now I want to foreward/transport this 3G-SDI video to another Transceiver bank(in my case Bank 117 of kintex xc7k325tffg900-3).
The problem is sync failed time to time and I have error in 3G-SDI video output time to time.
I would like to know is there any way to sync one transceiver to another?
08-11-2017 07:16 AM
I think to synchronize (align) two tranceiver you have to use the same clock and get rid of the tranceiver FIFO (Tx buffer off).
Hope this helps,
08-15-2017 06:44 PM - edited 08-17-2017 08:11 AM
This is actually a really tough problem.
SDI requires each frame to be identical in terms of the number of blanking pixels and blanking lines. In other words, your serial data rate must be the exact multiple of the pixel rate.
So, when you receive a stream, you work with it at the recovered clock rate - this is effectively synchronized to the clock rate of the transmitting device.
To send the data forward and not accumulate some long term drift, you must transmit the data forward at exactly the bit rate of the incoming stream.
However, for a high speed transceiver, the bit rate of the transmitter is derived from the REFCLK - this is the high stability clock that is used for the transceiver.
So, to lock a SDI-TX to the SDI-RX you would have to lock the REFCLK of the transmitter to the recovered clock of the receiver. This can't be done for a couple of reasons:
- REFCLK is an external pin to the transceiver - you cannot access it from inside the FPGA
- (in some architectures there is a test mode to allow internal connections to REFCLK, but it is not to be used for user designs).
- the recovered clock from a GT RX has far too much jitter to be used as a reference clock for the GT...
So, there are a couple of solutions.
The first (and most common) is to use some kind of external clock component to generate REFCLK - this can be an external PLL with extremely good jitter rejection that can "clean up" the recovered clock enough to be used as REFCLK (EDIT: the internal MMCMs or PLLs are not sufficient for this task), or a VCXO that uses information generated by the FPGA to lock to the recovered clock's bit rate.
The other solution is to use something called PICXO. In a nutshell, the GT still uses the REFCLK for the transmitter, but uses a mechanism within the GT through the dynamic reconfiguration port (DRP) to continually adjust the phase of the output datastream. By continually adjusting the phase, you can tweak the outgoing frequency to match the incoming frequency (after all if you change the phase by a constant amount every unit of time, you are changing the frequency).
The PICXO solution does not necessarily work in all situations - there is an upper limit to how much frequency it can compensate for, and, presumably, adds some jitter to the outgoing data stream.
Information on the PICXO can be found in this application note (and forwarding an SDI input to an output is one of the example applications of this solution).
08-16-2017 10:03 PM
Thanks Avrum for the very detailed and very good answer.
I would like to add a few points:
The main advantages over an external VCXO:
It is Free!
You can change the gain (G1/G2) on the fly, meaning you can change the frequency response/lock time/jitter rejection on the fly.
hope this helps.
If there are questions about the PICXO/FRACXO, then make sure your post contains the "PICXO" keyword. I will try my best to answer.