Example Design - Example Design - XAPP1249

This application note provides an example UHD-SDI design. This design runs on the KC705 FPGA evaluation board. It requires a Fidus 12G-SDI FMC board connected to the HPC FMC connector of the KC705 board. The example design has a single UHD-SDI transmitter driven by a test pattern generator. It supports operation at SD-SDI, HD-SDI, 3G-SDI (levels A and B), 6G-SDI, and 12G-SDI. The UHD-SDI transmitter is controlled by a Vivado Analzyer VIO module. The example design also has a single UHD-SDI receiver which can operate in the same modes as the transmitter. The status of the UHD-SDI receiver is monitored by a Vivado Analyzer VIO module. The data streams, line numbers, and video timing signals output by the UHD-SDI receiver are captured by a Vivado Analyzer ILA module and can be inspected in the Vivado Analyzer tool. Figure 1 is a block diagram of the example design.

A pre-generated FPGA configuration bit file is provided which can be loaded onto a KC705 board. However, 12G-SDI operation requires a -3 speed grade Kintex 7 FPGA. Standard KC705 boards have -2 speed grade devices and the bit file (probably) does not work on them at 12G-SDI rates. The bit file should work at 6G-SDI rates and lower on KC705 boards with -2 speed grade devices. However, this is not guaranteed because the bit file was generated for -3 devices.

The MGTAVCC voltage rail must be set to 1.05V if 12G-SDI operation is required. This voltage level supports the other SDI lines rates, too. If the maximum line rate is 6G-SDI or slower, then -1 speed grade devices are sufficient and the MGTAVCC voltage rail can be set to the normal value of 1.00V. For more information, refer to Answer Record 64007.

All source code files for the example design are included. A Tcl script is provided that creates a Vivado project, add all of the source code files, and then implement the design and generate a bit file. The readme.txt file that accompanies the example design has instructions for using the Tcl script to generate the project.

This release was generated and tested with Vivado 2018.1. It does not work with earlier versions of Vivado. To control and monitor the example design, Vivado 2018.1 Analyzer is required.

This example design has limited support for 12G-SDI. Only one 12G-SDI line rate, either 11.88 Gb/s or 11.88/1.001 Gb/s, is available at a time. A DIP switch on the KC705 board determines whether the 12G-SDI line rate is 11.88 Gb/s or 11.88/1.001 Gb/s. This DIP switch controls the routing of the two reference clocks to the PLLs. When this DIP switch is closed, providing a High to the control logic, the QPLL is given the 148.35 MHz reference clock and the CPLL is given the 148.5 MHz reference clock. When the DIP switch is open, the reference clocks are reversed. So, if the DIP switch is closed, only the 11.88/1.001 Gb/s 12G-SDI line rate is supported. If the DIP switch is open, only the 11.88 Gb/s 12G-SDI line rate is supported.

The DIP switch should be set prior to configuring the FPGA. While the design continues to work if the DIP switch is changed while the FPGA is powered on and configured, the bouncing of the switch can cause issues, particularly for the RX section and proper operation is not guaranteed if the switch is changed dynamically.

The DIP switch that controls the reference clock routing is located in SW11, the GPIO DIP switch. There are four DIP switches in this device and the switch labeled 4 is the switch that controls the reference clock routing. When this switch is in the down position, it is closed and only the 11.88/1.001 Gb/s 12G-SDI line rate is supported. Down, in this case, is towards the LCD display on the KC705 board.

The transmitter is driven by a video pattern generator that can generate color bars or SDI pathological patterns in NTSC, PAL, 720p, 1080i, and 1080p formats at various frame rates. When the transmitter is configured in 3G-SDI level B mode, the example design operates the transmitter in 3G-SDI level B-DS (dual stream) mode. In this configuration, a 1080p 25 Hz, 29.97 Hz, or 30 Hz image is generated by the video pattern generator and two copies of the that image are aggregated together and carried by the 3G-SDI level B-DS transport.

When the transmitter is configured in 6G-SDI mode, a 1080p 25 Hz, 29.97 Hz, or 30 Hz image is generated by the video pattern generator and four copies of that image (each copy consisting of a Y data stream and a C data stream) are sent to the data stream 1 through 8 inputs of the transmitter. This emulates what occurs when subdividing a 3840 x 2160 25, 29.97, or 30 Hz progressive 4:2:2 YCbCr 10-bit image per ST 2081-10 mapping mode 1 for transport on a 6G-SDI interface. Because the image is a color bar pattern which is highly symmetrical, the resulting image after the four 1080p sub-images are reintegrated into a 2160p image is a correct 2160p 25 Hz, 29.97 Hz, or 30 Hz color bar image.

When the transmitter is configured in 12G-SDI mode, a 1080p 50 Hz, 59.94 Hz, or 60 Hz image is generated by the video pattern generator and four copies of that image are sent to the data stream 1 through 8 inputs of the transmitter. This emulates what occurs when subdividing a 3840 x 2160 50, 59.94, or 60 Hz progressive 4:2:2 YCbCr 10-bit image per ST 2082-10 mapping mode 1 for transport on a 12G-SDI interface. The resulting image after the four 1080p subimages are reintegrated into a 2160p image is a correct 2160p 50 Hz, 59.94 Hz, or 60 Hz color bar image.

A MicroBlaze processor configures the SDI PHY parts on the Fidus FMC board. After FPGA configuration, the MicroBlaze determines the die revision of the Macom SDI cable equalizer, reclocker, and cable driver and configures those devices appropriately. After configuration is complete, the MicroBlaze asserts a signal named fmc_init_done. This signal is connected to the UHD-SDI wrapper's rx_refclk_stable and tx_refclk_stable input ports so that the GTX and PLL resets do not complete until after the FMC is initialized and the reference clocks from the FMC card are stable. The fmc_init_done signal also drives an LED on the KC705 board. This LED is GPIO LED 7 located in the top right corner of the KC705 board, above and to the left of the power switch. If this LED is on, the FMC initialization is complete.

Running the Demo

To run this demo at 12G-SDI rates, a KC705 board with -3 speed grade XC7K325T FPGA in a FFG900 package is required. Connect a Fidus 12G-SDI FMC board to the HPC FMC connector as shown in Figure 2. Connect a USB cable from a USB port on the PC to the JTAG USB connector on the KC705. Connect the power cable to the KC705 board.

The instructions given here assume that the TX0 SDI output of the FMC card is looped back via a cable to the RX0 SDI input of the FMC card. Please keep in mind that the quality of that cable is critical at 12G-SDI line rates, even if it is very short. A poor quality cable significantly degrades the signal at 12G-SDI rates and prevents the UHD-SDI RX from properly receiving the signal.

The demo can also be used with TX0 driving a SDI sink, such as a SDI waveform monitor and RX0 connected to a SDI source. The RX and TX are completely independent.

Select the reference clock configuration using the Demo Configuration DIP switch. This is switch 4 on the Quad DIP switch shown in Figure 2. As previously described, this switch selects which line rate the RX and TX operate in when running in 12G-SDI mode.

Power on the KC705 board.

Demo Status LED

• GPIO_LED_0: RX locked to SD-SDI mode
• GPIO_LED_1: RX locked to HD-SDI mode
• GPIO_LED_2: RX locked to 3G-SDI mode
• GPIO_LED_3: RX locked to 6G-SDI mode
• GPIO_LED_4: RX locked to 12G-SDI mode
• GPIO_LED_5: RX bitrate indicator
• GPIO_LED_6: RX change done indicator
• GPIO_LED_7: FMC initialization done

Open the Vivado tools 2018.1. In the Tcl Console, use the cd command to change the directory to the bit_files folder of the example design.

In the Tcl Console type: source bit_files.tcl. This is a Tcl script that opens a Vivado project called bit_files, opens the Vivado hardware manager, opens the target FPGA on the KC705 board, and programs the FPGA. The bit_files Vivado project is not a full project for the design. It only contains the setup information for the VIO and ILA modules used to control the demo. By using this project, you avoid having to configure how all of the I/O signals are displayed.

After the Tcl script terminates, the hardware manager is open and there are three debug windows selectable by tabs. These windows are:

• ILA- hw_ila_1: This is the RX ILA setup window.
• VIO- hw_vio_1: This is (usually) the TX VIO window
• VIO- hw_vio_2: This is (usually) the RX VIO window

The Vivado tools are not always consistent in which order the VIO modules are assigned, so it is possible for hw_vio_1 to be the RX VIO window and hw_vio_2 to be the TX VIO window.

Select the RX VIO window. Most of the signal names in the RX window start with rx0_. Not all of the signals are visible when you first open this VIO window. If your screen is large enough, you can pull down on the signal list resize control in the RX VIO window to make all of the signals visible as shown in the following figure.

When the TX is looped back to the RX, it is usually more convenient to be able to see the RX VIO and the TX VIO at the same time. One way to do this is to float both of these windows by clicking on the float control in the upper right hand corner of the RX VIO window and the TX VIO window and then arranging these two floating windows side-by-side.

The TX VIO window controls the UHD-SDI transmitter. It is used to set the SDI mode and line rate, video pattern, video format, and select other options. The TX VIO window is shown in the following figure. The order of the signals may differ from what is shown in the figure.

The first three items at the top of the TX VIO window indicate the status of the last GTX TX initialization or dynamic change sequence. If the last sequence completed normally, the tx_change_done indicator is green. If the last sequence failed, the tx_change_fail indicator is red and the change failure code value indicates the cause of the failure as shown in Table 2.

The tx_mode_async value specifies the SDI mode and the tx_m toggle button selects between integer frame rates and fractional frame rates if appropriate for the selected SDI mode as shown in the following table. The tx_m toggle button has no affect in SD-SDI and 12G-SDI modes. In SD-SDI, the only legal rate is 270 Mb/s. And, in 12G-SDI mode, the TX bit rate is controlled by the demo configuration DIP switch.

When tx_mode_async is set to 3, the transmitter is configured for 3G-SDI level B-DS operation. However, a value of 3 is illegal on the UHD-SDI wrapper's tx_mode_in port. The demo code uses tx_mode_asyncof 3 to indicate that the transmitter should run in 3G-SDI level B-DS mode. But, the logic changes this value to 2 on the tx_mode_in port of the UHD-SDI wrapper. On the UHD-SDI wrapper input, 3G-SDI level A or level B is selected by the tx_mux_pattern input port.

Immediately after the FPGA is programmed, the VIO windows do not necessarily represent the current status of the signals shown in the VIO window. This is particularly noticeable with the tx_mode_async and tx_m controls. The tx_mode_async and tx_m controls are displayed in the VIO window with whatever their previous value was. However, the actual tx_mode_async and tx_m signal values are returned to their default values in the FPGA. The default value of tx_mode_async is 0, selecting HD-SDI mode. And the default value of tx_m is 0, selecting 1.485 Gb/s line rate. The values in either VIO window can be updated by right clicking on the desired VIO module in the list of debug modules in the Hardware window (usually located in the upper left corner of the Hardware manager window) and selecting Refresh Input and Output Values for VIO Core. Whenever you have the situation where the TX is transmitting HD-SDI but the tx_mode_async is set to some other SDI mode, the TX VIO has not been refreshed with the latest values.

The ST 2081-1 (6G-SDI electrical standard) and ST 2082-1 (12G-SDI electrical standard) documents mandate a feature called sync bit insertion, sometimes known as run length mitigation or anti pothole. The feature breaks up the long runs of 1s or 0s into the SDI encoder during EAV, SAV, ADF sequences. Some early 6G-SDI and 12G-SDI implementations do not support this feature and are not able to receive a signal that was transmitted with this feature. The tx_sync_bit_async toggle button enables and disables sync bit insertion in the transmitter.

The TX VIO provides two reset buttons for the transmitter. The tx_full_reset button resets the CPLL, GTX TX, and UHD-SDI TX data path. The tx_reset button resets the GTX TX and the UHD-SDI TX data path, but not the CPLL. When demo is on loopback, an rx0_manual_gtrxreset must be performed after a tx_full_reset to resume normal operation. This is because TX and RX are using the same PLL when both are in the same video format hence performing a tx_full_reset affects the RX operation. The tx_txen control is not active in this demo.

The tx_pat_sel_async value selects the video pattern generated by the video pattern generator driving the SDI TX. In SD-SDI mode, two test patterns are available:

• 0 and 2 = SMPTE EG-1 color bars
• 1and 3 = SMPTE pathological checkfield

In all other SDI modes, three test patterns are available:

• 0 = SMPTE RP 219 color bars
• 1 and 3 = SDI pathological checkfield
• 2 = 75% color bars

The pathological pattern produces the correct pathological checkfield pattern only in SD-SDI, HD-SDI, and 3G-SDI level A modes. The tx_fmt_sel_async control selects the video format generated by the video pattern generator as shown in the following table. Blank entries in the table are not supported, although the test pattern generator defaults to a legal pattern if unsupported combination is chosen.

The RX VIO window shows the status of the UHD-SDI RX as shown in the following figure. The order of the signals may be slightly different than shown in the figure.

The QPLL lock indicator is green if the QPLL is locked to its reference clock. If this indicator is red, the QPLL is not locked, indicating a problem with the reference clock from the Fidus 12G-SDIFMC board.

The rx0_active_streams value indicates the number of active streams being received. This value is encoded as follows:

• 0 = 1 stream
• 1 = 2 streams
• 2 = 4 streams
• 3 = 8 streams
• 4 = 16 streams

The rx0_bit_rate indicator is 0 if an integer frame rate SDI signal is received and 1 if a fractional frame rate SDI signal is received.

The rx0_change_done indicator is green if the last initialization, reset, or dynamic SDI mode change completed successfully. If the sequence failed, rx0_change_fail is red and rx0_change_fail_code indicates the reason for the error as shown in Table 2.

The rx0_crc_error_indicator captures any occurrence of a CRC error in any active data stream. As soon as a single CRC error is seen, this indicator turns red. It stays red until cleared by clicking on the rx0_clr_errs button. In SD-SDI mode, per field EDH errors are captured by the rx0_crc_error indicator rather than per line CRC errors. The rx0_err_count value indicates the number of lines that contain a CRC error for all modes except SD-SDI and, in SD-SDI mode, the number of fields with an EDH error. The error counter saturates at 65535. The error counter is cleared by clicking the rx0_clr_errs button.

When receiving a 3G-SDI signal, the rx0_level_b indicator is green if the signal is level B and gray if it is level A.

The rx0_mode_SD, rx0_mode_HD, rx0_mode_3G, rx0_mode_6G, and rx0_mode_12G indicators show the SDI mode of the incoming signal. The indicator matching the mode of the SDI input signal is green. If none of the indicators are green, the receiver is not locked to the input SDI signal.

The rx0_mode_locked indicator is green if the UHD-SDI RX is receiving good data from the GTX RX.

There are four 32-bit values that display user data captured from ST 352 packets. Each ST 352 value also has a corresponding valid indicator which is green if ST 352 packets are being received for that channel. The order of the ST 352 user data byte in the 32-bit field is: {byte 4, byte 3, byte 2, and byte 1}. The value shown in rx0_st352_0 is from ST 352 packets received on data stream 1. The value shown in rx0_st352_1 is from ST 352 packets received on data stream 3, except in 3G-SDI level A mode when it shows ST 352 packets received on data stream 2. The value shown in rx0_st352_2 is from ST 352 packets received on data stream 5. The value shown in rx0_st352_3 is from ST 352 packets received on data stream 7.

The UHD-SDI RX has a transport format detector. This detector examines the timing of the SDI video transport and determines the format, frame rate, and scan mode (progress or interlaced) of the transport. This transport format is not necessarily the same as the picture format. For example, a 1080p 50 Hz 4:2:2 10b image carried by 3G-SDI level B actually uses a 1080i 50 Hz transport structure - the transport is interlaced but the picture is progressive. The rx0_t_locked indicator is green if the transport detector has identified the transport format. The rx0_t_family value indicates the format of the transport as listed in Table 1. The rx0_t_rate value indicates the frame rate (and always the frame rate even for interlaced transports) as listed in Table 2. The rx0_t_scan is 0 for an interlaced transport and 1 for a progressive transport.

The RX VIO window provides two reset buttons for the receiver. The rx0_manual_full_reset button resets the QPLL, GTX RX, and UHD-SDI RX data path. The rx0_manual_gtxreset button resets the GTX RX and the UHD-SDI RX data path, but not the QPLL. When demo is on loopback, a tx_reset must be performed after an rx0_manual_full_reset to resume normal operation. This is because TX and RX are using the same PLL when both are in the same video format hence performing an rx0_manual_full_reset affects the TX operation.

The ILA window captures the data streams, line numbers, and video timing signals output by the UHD-SDI receiver. Immediately after the hardware manager is opened, connected to the target, and the FPGA is programmed, there is one window for the ILA. This window is shown in the following figure and controls the setup of the ILA.

By default, the RX ILA is set up to trigger on the last word of an EAV sequence. The ILA captures 20 samples before the trigger. The RX ILA is also set up to only capture samples when the rx0_ce clock enable is High. This allows about two lines of 1080-line video to be captured by the ILA. If you want to see how the clock enables work, the rx0_ce compare value in the Basic Capture Setup window can be changed to X, or the Capture mode can be changed to ALWAYS.

To capture data using the ILA, click on the trigger button, the button that looks like this:

After the ILA has captured the video and transferred it to Vivado Analyzer, a new tab appears in Vivado Analyzer named hw_ila_data_1.wcfg. The content of this new tab appears something like the waveform captured in the following figure.

This window shows the three video timing signals, rx0_eav, rx0_sav, and rx0_trs. It shows the data captured from the eight data streams output by the RX. One line number is shown for each pair of data streams. Thus, rx0_line_0 is the line number for data streams 1 and 2, and rx0_line_1 is the line number for data streams 3 and 4, and so on.

The rx0_crc_err vector contains one CRC error bit for each of the eight data streams with bit 0 corresponding to data stream 1 and bit 7 corresponding to data stream 8. Also shown is the clock enable, rx0_ce. If the capture mode is set so that data words are only captured when rx0_ce is High, rx0_ce always appears to be High in the captured data.