Experience has shown that most of the issues that occur when implementing
SDI interfaces with AMD transceivers are related to
clocking and with incorrect use of the transceivers. The SMPTE UHD-SDI core is very robust
and when the transceiver is properly connected to the SMPTE UHD-SDI core and the clocks are
connected correctly, the SMPTE UHD-SDI core almost always works as designed. The first thing
to check when a SMPTE UHD-SDI receiver or transmitter is not working is that the associated
clock from transceiver is running at the correct speed. For HD-SDI the receive and transmit
clocks that are connected, usually through a BUFG, to the rx_clk and
tx_clk ports of the SMPTE UHD-SDI core should have a frequency of either
74.25 MHz or 74.1758 MHz, depending on which HD-SDI bit rate is being received or
transmitted. For 3G-SDI and 6G-SDI, these clocks should have a frequency of 148.5 MHz or
148.35 MHz, again depending on which bit rate is being received or transmitted. For 12G-SDI,
these clocks should have a frequency of 297 MHz or 296.7 MHz. For SD-SDI, the
rx_clk frequency can be either 148.5 MHz or 148.35 MHz, depending on the
frequency of the reference clock used by the RX section of the transceiver. Also for SD-SDI
TX, the tx_clk must always be 148.5 MHz, never 148.35 MHz.
If the clocks are halted or running at incorrect frequencies, then there is probably a problem with the transceiver or the reference clocks to the transceiver. Perhaps the PMA PLLs did not get properly reset after the reference clocks became stable. Using Vivado Analyzer to manually assert various resets on the transceiver can help to determine if there is a problem with a reset signal not getting asserted or not being asserted at the right time. Also check that the resets to the transceiver are not being asserted all of the time and preventing the transceiver from operating properly.
Another issue that occurs commonly is that the clock driving
tx_clk port of the SMPTE UHD-SDI core and the TXUSRCLK
and TXUSRCLK2 ports of the transceiver is not frequency locked to the
reference clock used by the TX portion of the transceiver. This problem is avoided if the
TXOUTCLK of the transceiver is the clock driving tx_clk,
TXUSRCLK, and TXUSRCLK2. But, if another clock is used
to drive these clock inputs, then this clock must be frequency locked to
TXOUTCLK and the reference clock driving the TX section of the
transceiver. If these clocks are not frequency locked, then the TXBUFFER in
the transceiver quickly under or overflows, causing corruption of the serial bit stream
generated by the transceiver. AMD transceivers have a
status port that can be monitored to determine if the TXBUFFER is under or
overflowing. On the 7 series
transceiver, the TXBUFFER under/overflow signal is bit 1 of the
TXBUFSTATUS port. If this signal ever becomes asserted High, then the
TXBUFFER has under or overflowed.
The loopback mechanism built into AMD transceivers is a very useful debugging tool. This mechanism allows you to loop the TX portion of the transceiver back to the RX portion, internally to the transceiver. Thus, if you have a working SDI transmitter, you can use that to test that the SDI receiver is working. Or if you have a working SDI receiver, you can use that to test that the SDI transmitter is working correctly.
Another useful technique used to determine if the data stream going into
the TXIN port of the transceiver from the TX section of the SMPTE UHD-SDI core is a valid
SDI data stream involves connecting the data stream that goes from the transceiver TXDATA
port to therx_data_in port of the RX section of the SMPTE UHD-SDI core and
then monitor the status and video output ports of the RX section of the core using the Vivado Analyzer. If the RX section of the core locks to the
data stream and produces correct video and status signals on its output, then the data
stream going into the TX section of the transceiver is correct. Note that to verify SD-SDI
with this technique, the appropriate device-specific SDI wrapper should be used instead of
just the SMPTE UHD-SDI core or the extra SDI receiver used to monitor the
TXDATA data stream.