FPGA high-end project: 6G-SDI video codec, providing engineering source code and technical support

FPGA high-end project: 6G-SDI video codec, providing engineering source code and technical support

1 Introduction

There are currently two solutions for Xilinx series FPGA to implement SDI video encoding and decoding:
one is to use dedicated encoding and decoding chips, such as the typical receiver GS2971 and transmitter GS2972. The advantage is simplicity. For example, the GS2971 receiver directly decodes SDI into parallel YCRCB. The GS2972 transmitter directly encodes the parallel YCRCB into SDI video. The disadvantage is that the cost is higher. You can search for the prices of GS2971 and GS2972 on Baidu. Another solution is to use FPGA to implement encoding and decoding, using the GTP/GTX/GTH/UltraScale GTH of FPGA. etc. resources to achieve deserialization. The advantage is that FPGA resources are reasonably utilized. The disadvantage is that the operation is more difficult and requires higher FPGA level. UltraScale GTH is suitable for FPGAs of the Xilinx UltraScale series, including Virtex UltraScale, Kintex UltraScale, Zynq® UltraScale, etc. Devices under the UltraScale series only have GTH. Compared with GTH, UltraScale GTH has a higher line rate, supports more protocol types, lower power consumption, and higher bandwidth; similarly, Xilinx also provides SDI video encoding and decoding. Dedicated IP, such as SMPTE UHD-SDI, which supports 3G-SDI, 6G-SDI, 12G-SDI and other video codecs;

This article uses Xilinx’s 7 series Kintex7–xc7k325tffg676-2 model FPGA to implement 6G-SDI video encoding and decoding; this design is divided into two parts: 6G-SDI video encoding and 6G-SDI video decoding, namely 6G-SDI video sending and receiving. Each part of the function is implemented in one project; the 6G-SDI video receiving process is: the input camera is a standard 6G-SDI camera, the development board has an onboard GV8601A chip, and the SDI video plays the role of equalizing EQ through GV8601A, which can also be understood as a single End-to-end conversion to differential; then call Xilinx official GTX GTXE2_CHANNEL primitive and GTXE2_COMMON primitive to deserialize SDI video, decode high-speed serial SDI video into parallel data, GTX selects QPLL clock; then call Xilinx official SMPTE UHD-SDI IP The core implements SDI video decoding. This IP only supports 3G-SDI and 6G-SDI codecs on Kintex7 devices. This design is configured in 6G-SDI mode. At this point, the 6G-SDI video decoding work is completed. The decoded video It is parallel TTL level data. The decoded data at this time is sent to the ILA for observation. It can also be used by the user for subsequent processing, such as caching, color conversion, scaling, image recognition, etc. This design does not process it and only retains the data. out, giving developers more space to use; the 6G-SDI video sending process is: the static color bar implemented in pure verilog is used as the video source, and then the official Xilinx SMPTE UHD-SDI IP core is called to implement SDI video encoding, which is implemented in the Kintex7 device Only supports 3G-SDI and 6G-SDI codecs. This design is configured in 6G-SDI mode. This process is the reverse process of the receiving process; then the GTXE2_CHANNEL primitive of Xilinx official GTX is called to serialize the SDI video, and the parallel SDI The video data is serialized into high-speed serial data, and GTX selects the CPLL clock. This process is the reverse process of the receiving process; then the video signal is sent to the onboard GV8500 chip. GV8500 plays the role of enhanced driver and can also be understood as differential conversion. Single-ended; I have an SDI to HDMI box in my hand, connect the output SDI video to the box, and then output the monitor to output the display; this solution provides a set of vivado2022.2 version of the FPGA project source code;

This blog describes in detail the design scheme of Xilinx's 7 series Kintex7–xc7k325tffg676-2 model FPGA to implement 6G-SDI video encoding and decoding. The engineering code can be comprehensively compiled and debugged on the board, and can be directly transplanted to the project. It is suitable for school students and graduate projects. Development is also suitable for on-the-job engineers to learn and improve, and can be applied to high-speed interfaces or image processing fields in medical, military and other industries;
it provides complete, run-through engineering source code and technical support;
the way to obtain engineering source code and technical support is in At the end of the article, please be patient and read to the end;

Disclaimer

This project and its source code include both parts written by myself and parts obtained from public channels on the Internet (including CSDN, Xilinx official website, Altera official website, etc.). If you feel offended, please send a private message to criticize and educate; based on this, this project The project and its source code are limited to readers or fans for personal study and research, and are prohibited from being used for commercial purposes. If legal issues arise due to commercial use by readers or fans themselves, this blog and the blogger have nothing to do with it, so please use it with caution. . .

2. Recommendation of relevant solutions

The GT high-speed interface solution I already have here

My homepage has a FPGA GT high-speed interface column. This column has video transmission routines and PCIE transmission routines for GT resources such as GTP, GTX, GTH, GTY, etc. GTP is based on the A7 series FPGA development board, and GTX is based on the K7 or ZYNQ series. FPGA development board is built, GTH is built based on KU or V7 series FPGA development board, GTY is built based on KU+ series FPGA development board; the following is the column address:
click to go directly

My current SDI codec solution

My blog homepage has an SDI video column, which is full of FPGA codec SDI engineering source code and blog introduction; there are SDI codecs based on GS2971/GS2972, and SDI codecs based on GTP/GTX resources; column address link: Click to go directly

3. Design ideas and framework

This article uses Xilinx’s 7 series Kintex7–xc7k325tffg676-2 model FPGA to implement 6G-SDI video encoding and decoding; this design is divided into two parts: 6G-SDI video encoding and 6G-SDI video decoding, namely 6G-SDI video sending and receiving. Each part of the function is implemented in one project; the 6G-SDI video receiving process is: the input camera is a standard 6G-SDI camera, the development board has an onboard GV8601A chip, and the SDI video plays the role of equalizing EQ through GV8601A, which can also be understood as a single End-to-end conversion to differential; then call Xilinx official GTX GTXE2_CHANNEL primitive and GTXE2_COMMON primitive to deserialize SDI video, decode high-speed serial SDI video into parallel data, GTX selects QPLL clock; then call Xilinx official SMPTE UHD-SDI IP The core implements SDI video decoding. This IP only supports 3G-SDI and 6G-SDI codecs on Kintex7 devices. This design is configured in 6G-SDI mode. At this point, the 6G-SDI video decoding work is completed. The decoded video It is parallel TTL level data. The decoded data at this time is sent to the ILA for observation. It can also be used by the user for subsequent processing, such as caching, color conversion, scaling, image recognition, etc. This design does not process it and only retains the data. out, giving developers more space to use; the 6G-SDI video sending process is: the static color bar implemented in pure verilog is used as the video source, and then the official Xilinx SMPTE UHD-SDI IP core is called to implement SDI video encoding, which is implemented in the Kintex7 device Only supports 3G-SDI and 6G-SDI codecs. This design is configured in 6G-SDI mode. This process is the reverse process of the receiving process; then the GTXE2_CHANNEL primitive of Xilinx official GTX is called to serialize the SDI video, and the parallel SDI The video data is serialized into high-speed serial data, and GTX selects the CPLL clock. This process is the reverse process of the receiving process; then the video signal is sent to the onboard GV8500 chip. GV8500 plays the role of enhanced driver and can also be understood as differential conversion. Single-ended; I have an SDI to HDMI box in my hand, connect the output SDI video to the box, and then output the monitor to output the display; this solution provides a set of vivado2022.2 version of the FPGA project source code;

Design block diagram

This design refers to Xilinx official design documents. The official reference design block diagram is as follows:

The detailed design plan block diagram of this project is as follows:

GV8601A balanced EQ

The 6G-SDI video reception process is as follows: the input camera is a standard 6G-SDI camera, and the development board is equipped with a GV8601A chip. The SDI video passes through the GV8601A to equalize EQ, which can also be understood as single-ended conversion to differential; a screenshot of the schematic diagram is as follows :

GTX clock requirements

According to the hardware design requirements recommended by Xilinx, GTX requires two differential clocks, one 148.5M and one 148.351M. The latter can be obtained through the 148.5M differential crystal oscillator matching resistor;

GTX call and control

Then call the GTXE2_CHANNEL primitive and GTXE2_COMMON primitive of Xilinx official GTX to deserialize and serialize the SDI video. It is deserialized when receiving and serialized when sending. The high-speed serial SDI video is decoded into parallel data. GTX selects the QPLL clock. ; The screenshot of the code location is as follows:

It should be noted that the GTX IP core is not directly instantiated here, but its GTXE2_CHANNEL and GTXE2_COMMON primitives are directly called. This requires developers to have a high level of proficiency in GTX. Here, the primitives are called directly. The purpose is to facilitate configuration and reset, because the GTX we designed supports the deserialization and serialization of HD-SDI, 3G-SDI and 6G-SDI. The line rate of each input is different, so we need to control the GTX in different input states. Line rate switching. After line rate switching, GTX internal state machine logic and reset need to be changed to make GTX work stably after shifting. GTX shifting and configuration must strictly follow the official data manual timing, so there is a special GTX shifting configuration in the code. Module; the code contains the GTXE2_CHANNEL and GTXE2_COMMON primitives, which correspond to the corresponding structures in the GTX official documentation. GTXE2_CHANNEL is responsible for specific deserialization and serialization, and the GTXE2_COMMON primitive is responsible for QPLL clock configuration. Both can be configured through the GTX variable speed configuration module. DRP performs dynamic configuration;

SMPTE UHD-SDI

Then call Xilinx's official SMPTE UHD-SDI IP core to implement SDI video encoding and decoding, which is decoding for receiving and encoding for sending. This IP only supports 3G-SDI and 6G-SDI encoding and decoding on Kintex7 devices. The design configuration is 6G-SDI mode; the screenshot of the code location is as follows: The

IP configuration is as follows:

SMPTE UHD-SDI IP is simple to call, but relatively complex to use, with many user interfaces. Please refer to the official data manual for details and the interface relationship. Only simple ones are done here. Interpretation, as follows:
According to the official manual, the SMPTE UHD-SDI data transmission and reception architecture is as follows:

SMPTE UHD-SDI receive

The block diagram of the SMPTE UHD-SDI receiver is as follows:

The data from the serial transceiver RX enters the SMPTE UHD-SDI receiver through the rx_data_in port. For SD, HD and 3G modes, 20 bits per clock cycle; for 6G and 12G modes, each 40 bits per clock cycle. In SD mode, the 20-bit data on rx_data_in is transferred to the DRU (data recovery unit), and the DRU recovers the 10-bit data from the 11 times oversampled data. The data is descrambled by the SDI descrambler and then word aligned by the SDI framer. Then there is the synchronization bit recovery function. This feature restores 3FF and 000 values ​​modified by the transmitter to reduce run length in 6G and 12G-SDI modes. These three modules run at full rx_clk speed and process 40, 20 or 10 bits of data per clock cycle depending on the SDI mode. Data enters the stream demux, which determines how many data streams are interleaved and then separates each data stream on a separate data path, supporting up to 16 data streams. Each data stream enters a processing unit, which performs CRC error checking, line number capture and ST 352 packet capture. It is also possible to extract video timing from the stream demux
and generate rx_eav, rx_sav and rx_trs timing signals. These timing signals are detected by the SDI mode and used by the transport detection module.

SMPTE UHD-SDI send

The block diagram of the SMPTE UHD-SDI transmitter is as follows:

SMPTE UHD-SDI can support up to 16 SDI data streams. The data stream first passes through the ST 352 insert module. The ST 352 payload ID packet can be selectively inserted and output from the ST 352 insert module. The data flow is called tx_ds1_st352_out to tx_ds16_st352_out. Outputting these streams allows users to insert auxiliary data after the ST 352 data packet. The rest of the transmitter can directly use the stream output by the ST 352 packet insertion module, or it can use the 16 tx_ds1_anc_in to tx_ds16_anc_in data streams. Note that if tx_dsn_anc_in streams are used, they must be full SDI streams, not just ancillary data. Normally, only ST 352 packets are inserted into the Y data stream of each Y/C data stream pair. In 3G-SDI level A mode-only mode, both data stream 1 and data stream 2 must insert ST 352 messages. Then each pair of Y/C data streams passes through a data stream processing module, which can perform line number insertion and CRC generation and insertion. After stream processing, the data streams are MUX-interleaved to form 40-, 20-, or 10-bit wide multiplexed SDI data streams. The multiplexed data stream is then scrambled by the SDI scrambler. Finally, the data is output on the tx_txdata port to the corresponding serial transceiver.

6G-SDI receive data processing

At this point, the 6G-SDI video decoding work is completed. The decoded video is parallel TTL level data. The decoded data at this time is sent to the ILA for observation, and can also be used by the user for subsequent processing, such as caching and color conversion. , scaling, image recognition, etc., this design does not process it, only leaves the data out, giving developers more space to use; developers can observe the correctness of SDI received data through ILA, and on this basis can do subsequent processing;

Send data color bar

The sending data color bar is implemented by pure verilog and is a static color bar. It is used as the data source for 6G-SDI video transmission. The screenshot of the code location is as follows:

GV8500 enhanced driver

After the transmission process goes through static color bar generation, SMPTE UHD-SDI encoding, and GTX serialization, the video signal is sent to the onboard GV8500 chip. GV8500 plays the role of enhanced driver and can also be understood as differential to single-ended conversion; schematic part Screenshot below:

6G-SDI video send output

The 6G-SDI video transmission path, after enhanced driving by GV8500, connects the SDI to HDMI box through the onboard BNC connector, connects the output SDI video to the box, and then outputs the monitor to output the display;

4. Detailed explanation of vivado project

Development board FPGA model: Xilinx's 7 series Kintex7-xc7k325tffg676-2;
Development environment: Vivado2022.2;
Input: 6G-SDI camera, no processing after decoding;
Output: Static color bar video is output after 6G-SDI encoding;
Application ：FPGA high-end project: 6G-SDI video encoding and decoding The
project code structure is as follows:

The resource consumption and power consumption are estimated as follows:

5. Project transplantation instructions

Vivado version inconsistency handling

1: If your vivado version is consistent with the vivado version of this project, open the project directly;
2: If your vivado version is lower than the vivado version of this project, you need to open the project and click File –> Save As; but this method does not It is not safe. The safest way is to upgrade your vivado version to the vivado version of this project or a higher version;

3: If your vivado version is higher than the vivado version of this project, the solution is as follows:

After opening the project, you will find that the IP has been It is locked, as follows:

At this time, the IP needs to be upgraded, and the operation is as follows:

FPGA model inconsistency handling

If your FPGA model is inconsistent with mine, you need to change the FPGA model. The operation is as follows:



After changing the FPGA model, you also need to upgrade the IP. The method of upgrading the IP has been described previously;

Other considerations

1: Since the DDR of each board is not necessarily exactly the same, the MIG IP needs to be configured according to your own schematic. You can even directly delete the MIG of my original project and re-add the IP and reconfigure it;
2: According to your own To modify the pin constraints of the schematic diagram, just modify it in the xdc file;
3: When transplanting pure FPGA to Zynq, you need to add the zynq soft core to the project;

6. Board debugging, verification and demonstration

Preparation

FPGA development board;
6G-SDI camera;
BNC to SMA coaxial cable;
SDI to HDMI box;
HDMI display;

Output static presentation

At the receiving end, the ILA waveform after decoding of the 6G-SDI video input is as follows:

At the transmitting end, the 6G-SDI static color bar video output is as follows:

7. Benefits: Obtaining engineering codes

Bonus: Acquisition of engineering code.
The code is too large and cannot be sent by email. It will be sent via a certain network disk link.
The information acquisition method is: private, or the V business card at the end of the article.
The network disk information is as follows: