Design and Implementation of DisplayPort Based on FPGA

At the Co nsumer Electro nics Show in January, several of the industry's leading flat-panel TV and display technology companies announced HD 3D TVs and stunning 4K x 2K LCD monitors to enable users The amount of data that needs to be exchanged between TVs, monitors, and other electronic devices in the home, in the car, or on mobile devices has increased dramatically to unprecedented levels. On these latest TVs, sports fans can rejoice with the many outstanding features, such as the 176-degree ultra-wide vision, the ultra-high contrast ratio of 1,200:1, and the brightness of 450 nits - enough to make the darkest cave pass Transparent and bright.

However, for designers who develop these TVs or the electronics that connect to them, all of these latest features mean very high bandwidth. For example, a 4-channel 4Kx2K HDTV with 8 megapixels (a digital cinema effect for the home) requires four times the bandwidth required for current top-of-the-line TVs and monitors in an ideal state of operation, which means in a set-top box. There is huge data throughput between HDTV and HDTV.

This need for higher bandwidth is not solely from the consumer market, for MRI and CT scanning, command and control, daisy chain display, bulletin board and DNA 3D rendering, aircraft, weather and anatomy. Display needs, broadcast equipment, digital display, research and medical markets are also increasing the bandwidth requirements.

In order to control the cost and help meet this bandwidth demand, the Video Electro nics Standards Association introduced DisplayPort to the market in 2007, and then actively cooperated with partners to optimize DisplayPort. . Today, VESA DisplayPort 1.1a has been able to support up to 4 channels in a single cable with a data rate of up to 2.7 Gbps per channel, while DisplayPort 1.2 doubles the supported data rate to 5.4 Gbps ( Sufficient to support 3,840 x 2,400 pixels (60Hz) in a single-monitor application, or 1,920x1,200 pixels in 2 display applications, or 3D display (120Hz) at 2,560x 1,600 pixels). DisplayPort supports two embedded displays simultaneously, such as laptop monitors, as well as video “source” devices (set-top boxes, DVD players, PC graphics cards, and laptops) and stand-alone display devices (known in HDMI and DisplayPort standard documentation). Box-to-box connection between "sink" devices.

Figure 1 TED Spartan-6 FPGA Consumer Video Kit

Some chip manufacturers have introduced off-the-shelf standard transmitters and receivers for these applications, and Xilinx has introduced a flexible programmable VESA called Xilinx LogiCORETM DisplayPort v1.1 (v1.2 will be available in IDS 12.1) DisplayPort v.1.1a solution. This IP is readily available to Xilinx customers, but it is recommended that you understand other background information related to some of the key features of the standard, such as Policy Maker, and how to use our upcoming XAPP "Using MicroBlazeTM" before designing the user. The implementation of the DisplayPort Source PolicyMaker Control System Reference Design for Embedded Systems is done on the Spartan-6 Consumer Video Kit from Tokyo Electronic Equipment (TED) (http://).

Policy Maker - Key Differences

For the display market, the DisplayPort protocol marks a major change in connectivity technology. This transformation is no less important than upgrading from a parallel PCI bus to serial PCI Express in the Intel-dominant PC market. In the display market, VESA leads the successful upgrade from VGA, DVI and HDMI to high-speed serial through DisplayPort. Transceiver, packet-based layer architecture protocol. Unlike parallel protocols, serial packet protocols require an extra layer of complexity in implementing and maintaining connections or links. In the VESA DisplayPort 1.1a specification, control functions are divided into l ink Policy Maker and Stream Policy Maker.l ink Policy Maker manageable links and are responsible for maintaining link synchronization. Its tasks include discovering links, initializing and maintaining links. Stream Policy Maker manages transport initialization and controls the sequence of actions through the underlying hardware to maintain synchronization streams.

The above elements of Policy Maker need to be determined based on the specific implementation and can be configured in the operating system, software drivers, firmware, or FPGA logic. To simplify use, many commercial DisplayPort ICs hide the ink and Stream PolicyMaker from the designer. If the user's display requirements match the set's DisplayPort ASSP, then the price and ease of use are indisputable. However, designers who want to differentiate their products from the competition tend to adopt FPGAs.

Figure 2 DisplayPort Source Policy Maker Controller System Reference Design and LogiCORE source high-level structure

Source Policy Maker Reference Design

The DisplayPort Source Policy Maker control system reference design uses the MicroBlaze embedded system to implement features similar to the commercial package DisplayPort chip, with the added benefit of source code customization. By using the application manual of the Source Policy Maker Controller System Reference Design, users can start the design work without having to know the Policy Maker in detail, simply connect the sample design.

In addition to the source code design described above, DisplayPort's transport (Tx) or source-side cores are also provided with additional sample designs for implementing finite state machine (FSM) controllers.

The DisplayPort Tx FSM controller example design (its top file name is dport_tx_fsm_cntrl) comes with a DisplayPort LogiCORE source design example. This simple proof-of-concept design includes an RTL-based finite state machine to implement a simple Policy Maker that demonstrates the correct startup process. Compared to other example designs, the dport_tx_fsm_cntrl design paradigm has the advantage of significantly reducing simulation time.

The Source Policy Maker control system reference design uses the MicroBlaze embedded system XAPP, which is due to be released in late May. The top ISE project name is “dport_source_ref_design.xise” (you can visit http:// Ipcenter/EF-DI-DISPLAYPORT.htm Quickly found). This design allows users to modify the source code of the Source Policy Maker Controller to suit their needs. In addition, it works with DisplayPort LogicCORE v1.2 (IDS12.1) and the Spartan-6 TED Consumer Video Kit.

Both of the above example designs include basic procedures for implementing kernel setup and link and flow maintenance. Please note that the TED Spartan-6 Consumer Video Kit does not offer a DisplayPort cable.

Functional Overview

Policy Maker is used for both source and sink/video specifications, but in DisplayPortLogiCORE, Xilinx implemented them differentially. The Policy Maker feature on the sink (receive) side is much simpler than the Policy Maker feature on the source (send) side. Xilinx LogiCORE implements most of the console Policy Maker functionality within LogiCORE. The RTL-based sink controller provides the functionality of the rest. Because the source Policy Maker is much more complex, it can be provided in a source code reference design.

Let's take a closer look at the source Policy Maker, which enables designers to maximize functional flexibility and implementation flexibility. The top-level sample design includes two examples of advanced components of the kernel: XAPP implements the DisplayPort Source Policy Maker control system reference design using the MicroBlaze embedded system; and the DisplayPort kernel source (send) design. Xilinx divides the implementation of the kernel into atomic link functions, called the main link, the secondary channel (Seco ndary Channel), and the AUX channel protocol. The primary link enables delivery of the primary video stream. The secondary channel integrates the delivery of audio information into the primary link during the blanking period. Xilinx will provide a secondary channel in the kernel released in the future. At the same time, the AUX channel establishes a dedicated source for the sink communication channel (see Figure 2).

Xilinx has added line buffers to the user data interface, enabling users to easily implement sample designs in FPGAs (see Figures 2, 3, and 4). The Policy Maker and Device Co ntroller in Figure 3 are both part of the Stern design example provided by CORE GeneratorTM.

MicroBlaze processor plays a central role

Xilinx's Source Policy Maker Controller works with the core so that its functionality is largely the same as the ASSP DisplayPort source device. We recommend that you use the MicroBlaze embedded or external processor to properly initialize and maintain the link. The pre-configured version of the Policy Maker Reference Design included with XAPP is implemented in the MicroBlaze processor within the FPGA to help users immediately convert the design into hardware. The reference design for official delivery will include source code that the designer can modify.

The "logic" portion of the Source Policy Maker Controller design sits on top of the MicroBlaze processor and uses I2C commands to control the core. The controller can be implemented outside the FPGA (ie, implemented in an external processor).

Designers can modify the XAPP design using the Xilinx Embedded Hardware Design Suite that supports Xilinx Platform Studio (EDK) or the Xilinx Embedded Software Design Kit with the SDK. Typically, FPGA designers use EDK while software developers use the SDK.

The EDK stream generates an intermediate network file (NGC) that you can integrate into the project-level ISE project before implementing the design. The NGC file contains the MicroBlaze code that forms part of the BRAM initialization.

If the user has modified the software, the EDK stream will usually take a long time. However, once the user has generated a list of networks, they no longer need an EDK or SDK. The SDK stream modifies the FPGA bitstream, so only the MicroBlaze code content in the BRAM needs to be updated. The SDK stream provides faster conversion times for software modifications, but in this case, the user must use the SDK once per bitstream. The XAPP white paper on this topic covers how to use Xilinx FPGA embedded software. The development kit runs a detailed description of the design.

The Getting Started Guide covers a wealth of information, including ordering and licensing, simulation, system-wide hardware evaluation, and technical support. In addition, it includes script files that users can use to generate sample designs, and instructions on how to use the sample testbench to simulate with the sample pattern generator.

Users can use this design with the full or evaluation version of the Xilinx DisplayPort LogiCORE and DisplayPort FPGA Mezzanine Card downloaded from the TED Spartan-6 FPGA Consumer Video Kit.

The source Policy Maker contains a state machine that can be connected to the processor interface via the AMBA?APB port or the 32-bit PLBv46 bus with the AMBA to PLB bridge. Xilinx stores a user-modifiable instruction set in BlockRAM. The C++ code that Xilinx uses to train the link is not only compiled with the GNU C++ compiler, but also on the soft MicroBlaze processor implemented inside the FPGA using the Xilinx EDK PlatformStudio processor design suite. A comprehensive test. The reference design includes the complete Xilinx SDK project. The sample test bench can connect a 135MHz clock to the VID clock and a 100MHz clock to the APB clock. Xilinx checks that all inputs are connected correctly. In addition, the top-level module also provides a reset function.

Extended display recognition

A particularly important feature of DisplayPort is the ability to identify the hands-on class in the Summer 2010 issue of VESA's enhanced display: the FPGA 101 Data (EDID) structure interfaces with different devices. EDID is not new. In fact, designers have been using various video interfaces to read the EDI device's sink device parameters for many years to interface with the device. However, these early EDID and related interface technologies typically did not include advanced configurable communication channels. Today, with DisplayPort, VESA adds intelligence to the system, enabling functional coordination between the source (such as a set-top box, DVD player or PC graphics card) and sink devices (such as display monitors), as well as optimizing communication. parameter. DisplayPort v1.1a can coordinate variables including channel number (1, 2 or 4), data rate per channel (1.62 or 2.7Gbps), voltage swing (0.2, 0.6, 0.8, 1.2 V), 4 levels of channel pre- The emphasis and link clock spread down.

The sample sink design generated by the CORE Generator and provided with LogiCORE provides a sample EDID (see Figure 3) to meet the reading needs of the EDID source device to ensure the best visual experience for the user.

Figure 3 DisplayPort Receive Advanced Block Diagram

The sink example design implements the EDID data structure in the BRAM inside the FPGA. The source code for DisplayPort implements the I2C protocol through the AUX channel. Figure 3 and Figure 4 show block diagrams of the DisplayPort sink connected to the source. The l ink and Stream Policy Maker are part of the sink kernel, but the source l inkPolicy Maker has higher complexity and will be provided as source code with the reference design. EDID interfaces with the receiving sink through the I2C interface.

The I2C protocol is well suited for connections to EDID data structures and is often used for this type of application. The I2C controller is responsible for locating and managing the data found in the EDID and transferring the data to the sink core via the serial interface and the I2C interface protocol (via the AUX channel). In working mode, the user does not need to know if the EDID is being accessed. The user can monitor the contents of the ROM by detecting the I2C bus. In debug mode, the user can modify the I2C controller to cover the 3-bit content provided by the EDID ROM. The I2C provides control signals that provide an I2C master interface when connected to the appropriate open collector output.

The sink contains a data structure named "DisplayPort Configuration Data (DPCD)", which can store configuration data and be used as a communication mailbox that can be read and written by both the sink and the source. The source side typically uses DPCD content across the AUX channel (see Figure 3 and Figure 4).

Policy Maker Link Training

The process of establishing communication on the DisplayPort link is called "link training." During the link training process, the kernel will focus on minimizing errors while optimizing link speed and power consumption. If there is a problem with the data transfer, the kernel will automatically repeat the link training to adapt to changing conditions. Communication between the source and sink packets takes place via a bidirectional half-duplex 1Mbps AUX channel. Video and audio data are transmitted over the primary link channel (1, 2, or 4), which is a high-speed gigabit-level transceiver channel from the source to the sink.

The link training of the kernel is performed in two steps: clock recovery, channel equalization, symbol lock, and inter-channel alignment. In step one, the receiver's PLL locks to the incoming signal and restores the link clock. In step two, the system optimizes channel equalization and inter-channel alignment.

The following is a typical working sequence for PolicyMakers at the source and sink:

1. Tx l ink Policy Maker monitors hot plug detection and sends a notification to Stream Source Policy Maker if a hot plug is detected. Stream Source Policy Maker reads the sink EDID through the AUC channel;

2. Tx l ink Policy Maker reads DisplayPort configuration data from the sink through the AUX channel. According to the function configuration of the source and the sink, it can write the configuration parameters for the link configuration field of the sink DPCD, and start the link training by writing to the "TRAINING_PATTERN_SET" byte of the sink DPCD, and then the training mode. Send for initialization;

3. The Tx ink Policy Maker controls the clock recovery sequence by adjusting the voltage swing and adjusting the bit rate as necessary based on feedback from the Rx ink Policy Maker. Once the kernel completes the clock recovery, the link training enters the channel equalization phase. At this stage, if Rx l inkPolicy Maker is called, the pre-emphasis is adjusted. In addition, the receiver will also complete the symbol lock and alignment between the channels at this stage;

4. Once the kernel is trained through the link (that is, the system completes bit lock and symbol lock), it will be prompted in the DPCD. Tx l ink PolicyMaker reports the training status to the Tx Stream Policy Maker to enable simultaneous streaming of stream attribute data.

Additional features of Policy Maker

In addition to participating in link training, Tx ink policy Maker can also monitor sink event notifications using IRQ HPD signals from the receiver and check the link status field of the DPCD for the cause of the outage. If the Tx ink policy Maker detects that the link is lost, it must retrain the link. If the receiver calls, it can also reconfigure the link to increase or decrease the number of primary link channels.

In addition, the ink policy Maker can also determine the order in which multiple AUX request transactions are processed, since each transaction ends before another transaction begins. Since the reply from the sink can be NACK or DEFER, Policy Maker must decide on the follow-up work for both cases. AUX transaction processing is limited to 16 bytes of data, so Policy Maker must divide large transactions into multiple transactions that do not exceed 16 bytes.

Because DisplayPort is able to negotiate and optimize link settings, it can achieve optimal results under ever-changing conditions. l ink and Stream Policy Maker are process control functions that enable modern high-speed video and audio transmission. The Xilinx Source Policy Maker Controller System Reference Design with MicroBlaze Embedded System is designed to help you get the most out of these new features and bring feature-rich display products to market. Xilinx DisplayPort LogiCORE provides a highly flexible source and sink solution with sample EDID and source code that can be downloaded into the TED Spartan-6 consumer video kit. An evaluation version of this IP is available for free.