Using 7 Series GTX Transceivers for SDI Interfaces - Using 7 Series GTX Transceivers for SDI Interfaces - XAPP1249

This section describes the details of implementation UHD-SDI interfaces using GTX transceivers in 7 series devices (AMD Kintex™ 7 and AMD Virtex™ 7 FPGAs, and AMD Zynq™ 7000 SoCs). The information in this section is intended to supplement, not replace, the information in 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476). This information highlights features of the GTX transceivers that are of particular importance for UHD-SDI applications.

There are several clocks required in applications using GTX transceivers. The SDI protocol does not allow for clock correction by adding and removing extra data in the data stream. Therefore, careful attention is required regarding how these clocks are generated and used in the application. GTX transceivers require reference clocks to operate. The reference clocks are used by phase-locked loops (PLLs) in the GTX transceiver Quad to generate serial clocks for the receiver and transmitter sections of each transceiver. As described in more detail in GTX Transceiver Reference Clocks and PLLs, the serial bit rate of the GTX transmitter is an integer multiple of the reference clock frequency it is using. Furthermore, the data rate of the video provided to the input of the UHD-SDI transmitter datapath must also exactly match (or be a specific multiple of) the frequency of the reference clock used by the GTX transmitter. Consequently, a UHD-SDI application must generate the transmitter reference clock so that it is frequency-locked exactly with the data rate of the video stream being transmitted.

The GTX transmitter outputs a clock on its txoutclk port at a frequency that is exactly equal to the word rate of the data that must enter the txdata port of the GTX transmitter. The txoutclk is generated in the GTX transmitter by dividing the serial clock from the PLL down to the word rate. In most applications, the txoutclk from the GTX transmitter is buffered by a global (BUFG) clock buffer and then used to clock the UHD-SDI transmitter datapath and the txusrclk and txusrclk2 clock inputs of the GTX transmitter. It is possible to use a clock other than one derived directly from txoutclk as the clock source for the UHD-SDI transmitter datapath and the txusrclk and txusrclk2 ports of the GTX transmitter. A shallow TX buffer in the GTX transmitter does allow for phase differences between the data entering the txdata port and the internal clock of the GTX transmitter. However, any frequency difference between the incoming data and the internal clock frequency of the GTX transmitter (as represented by txoutclk) quickly causes the TX buffer to underflow or overflow, resulting in errors in the serial bitstream generated by the GTX transmitter. Consequently, the data rate of the data stream entering the txdata port of the GTX transmitter (as represented by the frequency of the txusrclk and txusrclk2 clocks) and the internal data rate of the GTX transmitter (as set by the transmitter reference clock and represented by the frequency of txoutclk) must match exactly.

The GTX receiver reference clock, however, does not need an exact relationship with the line rate of the incoming SDI signal. This is because the clock and data recovery (CDR) unit in the GTX receiver can receive lines rates that are up to ±1250 ppm away from the nominal bit rate as set by the reference clock frequency in all modes except 12G-SDI. In 12G-SDI mode, the line rate of the 12G-SDI signal must be within ±200 ppm of the nominal line rate as set by the reference clock frequency. This allows the receiver reference clock to be generated by a local oscillator that has no exact frequency relationship to the incoming SDI signal. The GTX receiver generates a recovered clock that is frequency-locked to the incoming SDI bit rate. This clock is output on the rxoutclk port of the GTX transceiver. As is described in more detail later in this application note, rxoutclk is a true recovered clock when receiving any SDI signal except SD-SDI. Typically, rxoutclk is buffered by a global clock buffer and then applied to the rxusrclk and rxusrclk2 ports of the GTX receiver and used as the clock for the UHD-SDI receiver datapath.

One additional clock is required for SDI applications. This is a free-running, fixed-frequency clock that is used as the clock for the dynamic reconfiguration port (DRP) of the GTX transceiver. This same clock is also usually supplied to the control module in the SDI wrapper where it is used for timing purposes. Xilinx recommends that the frequency of this clock be at least 10 MHz. The maximum frequency of this clock is limited by the maximum allowed DRP clock frequency of the GTX transceiver, which is speed grade dependent. The frequency of this clock does not require any specific relationship relative to other clocks or data rates of the SDI application. This clock must not change frequencies when the SDI mode changes. It must remain running at the same nominal frequency at all times. It also must never stop while the SDI application is active. This clock can be used for all SDI interfaces in the device.

The frequency of the rxoutclk and txoutclk depend on the SDI mode and the width of the GTX transceiver's rxdata and txdata ports. This relationship is fixed by the architecture of the GTX transceiver. The RX and the TX both use clock enables to throttle the data stream transfer data rate because, in some cases, the data rate on the data streams is less than the frequency of the clock. The following table shows the relationships between SDI mode, number of active data streams, rxdata/txdata port widths, rxoutclk/txoutclk frequencies, and clock enable cadences. The clock enable cadences are given in number of clocks between assertions of the clock enable over two data word cycles where 1/1 means that the clock enable is asserted every clock cycle, 2/2 indicates assertion every other clock cycle (50% duty cycle), 4/4 indicates assertion every fourth clock cycle (25% duty cycle), and 5/6 indicates that the clock enable alternates between assertion every 5 or 6 clock cycles, to average once every 5.5 clock cycles (one instance of 5 clock cycles between High pulses on the clock enabled followed by one instance of 6 clock cycles between High pulses on the clock enable, with this pattern repeating).