This document describes the DisplayPort Intel^® FPGA IP, which provides support for next-generation video display interface technology. The Video Electronics Standards Association (VESA) defines the DisplayPort standard as an open digital communications interface for use in internal connections such as:

• Interfaces within a PC or monitor
• External display connections, including interfaces between a PC and monitor or projector, between a PC and TV, or between a device such as a DVD player and TV display

The DisplayPort Intel^® FPGA IP supports scalable Main Link with 1, 2, or 4 lanes, with 4 selectable data rates on each lane: 1.62 Gbps, 2.7 Gbps, 5.4 Gbps, and 8.1 Gbps.

Main Link transports video and audio streams with embedded clocking to decoupled pixel and audio clocks from the transmission clock. The IP transmits Main Link's data in scrambled ANSI 8B/10B format and includes redundancy in the data transmission for error detection. For secondary data, such as audio, the IP uses Solomon Reed coding for error detection.

The DisplayPort's AUX channel consists of an AC-coupled terminated differential pair. AUX channel uses Manchester II coding for its channel coding and provides a data rate of 1 Mbps. Each transaction takes less than 500 µs with a maximum burst data size of 16 bytes.

The following terms define device support levels for Intel FPGA IP cores:

• Advance support—the IP core is available for simulation and compilation for this device family. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
• Preliminary support—the IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution.
• Final support—the IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs.

The following table lists the link rate support offered by the DisplayPort Intel^® FPGA IP for each Intel FPGA family.

To enable the Adaptive Sync feature, refer to Table 29 and Video Interface (TX Video IM Enable = 1). For detailed implementation of the feature, refer to the DisplayPort SST Parallel Loopback with Adaptive Sync Support section in the respective DisplayPort Intel^® FPGA IP design example user guides.

Before releasing a publicly available version of the DisplayPort Intel^® FPGA IP, Intel runs a comprehensive verification suite in the current version of the Intel^® Quartus^® Prime software. These tests use standalone methods and the Platform Designer system integration tool to create the instance files. These files are tested in simulation and hardware to confirm functionality. Intel tests and verifies the DisplayPort Intel^® FPGA IP in hardware for different platforms and environments.

This chapter provides a general overview of the Intel FPGA IP design flow to help you quickly get started with the DisplayPort Intel^® FPGA IP. The IP is installed as part of the Intel^® Quartus^® Prime installation process. You can select and parameterize any Intel FPGA IP from the library. Intel provides an integrated parameter editor that allows you to customize the DisplayPort IP to support a wide variety of applications. The parameter editor guides you through the setting of parameter values and selection of optional ports.

The Intel^® Quartus^® Prime software installs IP cores in the following locations by default:

You can simulate your DisplayPort Intel^® FPGA IP variation using the simulation model that the Intel^® Quartus^® Prime software generates. The simulation model files are generated in vendor-specific subdirectories of your project directory. The DisplayPort Intel^® FPGA IP includes a simulation example.

The following sections teach you how to simulate the generated DisplayPort Intel^® FPGA IP variation with the generated simulation model.

You can use the Start Compilation command on the Processing menu in the Intel^® Quartus^® Prime software to compile your design. After successfully compiling your design, program the targeted Intel FPGA with the Programmer and verify the design in hardware.

The implementation of the DisplayPort Intel^® FPGA IP on hardware requires additional components specific to the targeted device.

For detailed information about the DisplayPort Intel^® FPGA IP design examples, refer to the respective design example user guides.

The HDCP over DisplayPort hardware design example helps you to evaluate the functionality of the HDCP feature and enables you to use the feature in your Intel^® Arria^® 10 and Intel^® Stratix^® 10 designs.

For detailed information about the HDCP over DisplayPort design examples, refer to the Intel^® Arria^® 10 and Intel^® Stratix^® 10 design example user guides.

This design performs a loop-through for a standard DisplayPort video stream. You connect a DisplayPort-enabled device—such as a graphics card with DisplayPort interface—to the Transceiver Native PHY RX, and the DisplayPort sink input. The DisplayPort sink decodes the port into a standard video stream and sends it to the clock recovery core. The clock recovery core synthesizes the original video pixel clock to be transmitted together with the received video data. You require the clock recovery feature to produce video without using a frame buffer. The clock recovery core then sends the video data to the DisplayPort source, and the Transceiver Native PHY TX. The DisplayPort source port of the daughter card transmits the image to a monitor.

The DisplayPort sink uses its internal state machine to negotiate link training upon power up. A Nios II embedded processor performs the source link management; software performs the link training management.

• The Bitec HSMC daughter card has inverted transceiver polarity. When creating your own sink (RX) design, use the Invert transceiver polarity option to enable or disable inverted polarity.
• The DisplayPort standard reverses the RX and TX transceiver channels to minimize noise for one- or two-lane applications. If you create your own design targeting the Bitec daughter card, ensure that the following signals share the same transceiver channel:
  • TX0 and RX3
  • TX1 and RX2
  • TX2 and RX1
  • TX3 and RX0

During operation, you can adjust the DisplayPort source resolution (graphics card) from the PC and observe the effect on the IP core. The Nios II software prints the source and sink AUX channel activity. Press a push-button to print the current TX and RX MSAs.

Refer to the assignments.tcl file for an example of how the channels are assigned in the hardware demonstration.

To synthesize the video pixel clock from the link clock, the clock recovery core gathers information about the current MSA and the currently used link rate from the DisplayPort sink.

The clock recovery core produces resynchronized video data together with the following clocks:

• Recovered video pixel clock
• Second clock with twice the recovered pixel clock frequency

The video output data is synchronous to the recovered video clock. You can use the second clock as a reference clock for the TX transceiver, which is optionally used to serialize the video output data.

The clock recovery core clocks the video data input gathered from the DisplayPort sink into a dual-clock FIFO at the received video clock speed. The core reads from the video data input using the recovered video clock.

• Video Timing Generator: This block uses the received MSA to create h-sync , v-sync, and data enable signals that are synchronized to the recovered video clock.
• Loop Controller: This block monitors the FIFO fill level and regulates its throughput by altering the original Mvid value read from the MSA. The block feeds the modified Mvid to the fPLL Controller, which calculates a set of parameters suitable for the fPLL Controller. This set of parameters provides the value to create a recovered video clock frequency corresponding to the new Mvid value. The calculated fPLL parameters are written by the fPLL Reconfiguration Avalon Master to the fPLL Reconfiguration Controller internal registers.
• Reconfiguration Controller: This block serializes the parameter values and writes them to the fPLL IP core.
• fPLL: Generates the recovered video clock and a second clock with twice the frequency.

When the PIXELS_PER_CLOCK parameter is greater than 1, all input pixels are supposed to be valid when you assert vidin_valid. The parameter only supports timings with horizontal active width divisible by 2 (PIXELS_PER_CLOCK = 2) or 4 (PIXELS_PER_CLOCK = 4).

The clock recovery core video output port produces pixel data with standard hsync, vsync, or de timing. All signals are synchronous to the reconstructed video clock rec_clk, unless mentioned otherwise. For designs using a TX transceiver, you can use rec_clk as its reference clock.

You can use rec_clk_x2 as a reference clock for transceivers that have reference clocks with frequencies lower than the minimum pixel clock frequency received. For example, the Video Graphics Array (VGA) 25-MHz resolution when the transceiver's minimum reference clock is 40 MHz.

The clock recovery core asserts reset_out when the remaining port signals are not valid. For example, during a recovered video resolution change when the rec_clk and rec_clk_x2 signals are not yet locked and stable. Intel recommends that you use reset_out to reset the downstream logic connected to the video output port.

During the hardware demonstration operation, you can adjust the DisplayPort source resolution (graphics card) from the PC and observe the effect on the IP core. The Nios II software prints the source and sink AUX channel activity. Press one of the push buttons to print the current TX and RX MSA.

The device’s Gigabit transceivers operate at 5.4, 2.7, and 1.62 Gbps, and require a 135-MHz single reference clock. When the link rate changes, the state machine only reconfigures the transceiver PLL settings.

The hardware demonstration requires the following hardware:

• Intel FPGA kit (includes USB cable to connect the board to your PC); the demonstration supports the following kits:
  • Stratix V GX FPGA Development Kit (5SGXEA7K2F40C2)
  • Arria V GX FPGA Starter Kit (5AGXFB3H4F40C5)
  • Cyclone V GT FPGA Development Kit (5CGTFD9E5F35C7)
• Bitec DisplayPort daughter card (HSMC revision 11 and later)
• PC with a DisplayPort output
• Monitor with a DisplayPort input
• Two DisplayPort cables
  • One cable connects from the graphics card to the FPGA development board
  • The other cable connects from the FPGA development board to the monitor

Copy the files using the command:

cp -r <IP root directory>/ altera / altera_dp / hw_demo /<device_board> <working directory>

where <device_board> is av_sk_4k for Arria V GX starter kit, cv for Cyclone V GT development kit, sv for Stratix V development kit, mst_av for Arria V MST design, and mst_sv for Stratix V MST design.

Your working directory should contain the files shown in the following tables.

For MST source instantiations, you need to create a user application at the top software layer to invoke the Link Layer level API functions of the btc_dptxll_syslib library.

The btc_dptxll_syslib library handles most of the Link Layer functionality. The library performs marginal SST operation, which in turn, becomes evident for MST operations. The btc_dptxll_syslib library uses the services provided by the btc_dptx_syslib library.

You can use the user application to perform MST discovery topology by invoking a single API function (btc_dptxll_mst_get_device_port()). In turn, the btc_dptxll_syslib library implements this functionality by invoking a number of btc_dptx_syslib MST messaging functions such as btc_dptx_mst_link_address_req(), btc_dptx_mst_enum_path_req(), and btc_dptx_mst_remote_i2c_rd_req().

The DisplayPort source consists of a DisplayPort encoder block, a transceiver management block, a controller interface block, and an HDCP interface block with an Avalon^® memory-mapped interface for connecting with an embedded controller such as a Nios^® II processor.

The source accepts a standard H-sync, V-sync, and data enable video stream for encoding. The IP latches and processes the video data, such as color reordering, before processing it using the txN_video_in input. N represents the stream number: tx_video_in (Stream 0), tx1_video_in (Stream 1), tx2_video_in (Stream 2), and tx3_video_in (Stream 3). Streams 1, 2, and 3 are only available when you turn on the Support MST parameter and specify the Max stream count parameter to 2, 3, or 4 streams respectively.

The video data width supports 6 to 16 bits per color (bpc) and is user selectable. If you set Pixel input mode to Dual or Quad, the video input can accept two or four pixels per clock, thereby extending the pixel clock rate capability.

The main link data path consists of the video packetizer, video geometry measurement, audio and secondary stream encoder, and training and link quality patterns generator.

The IP multiplexes data from these four paths and transmits it through a scrambler and an 8B/10B encoder. All the symbols, both those transmitted during video display period and those transmitted during video blanking period, are skewed by two Link symbol period between adjacent lanes.

The video packetizer path provides video data resampling and packetization.

The video packetizer path consists of the following steps:

1. The mixed-width DCFIFO crosses the video data from the video clock domain (txN_vid_clk) into the main link clock domain (tx_ss_clk) generated by the transceiver. This main clock can be 270, 202.5, 135, 81, 67.5, or 40.5 MHz, depending on the actual main link rate requested and the symbols per clock.
2. The pixel steer block aligns the video data so that the first active pixel of each video line occupies the least significant position.
3. The pixel packer block decimates the video data to the requested lane count (1, 2, or 4).
4. The pixel gearbox block resamples the video data according to the specified color depth. You can optimize the gearbox by implementing fewer color depths. For example, you can reduce the resources required to implement the system by supporting only the maximum color depths you need instead of the complete set of color depths specified in the VESA DisplayPort Standard.
5. The DisplayPort Intel^® FPGA IP packetizes the resampled data. The VESA DisplayPort Standard requires data to be sent in a transfer unit (TU), which can be 32 to 64 link symbols long. To reduce complexity, the DisplayPort source uses a fixed 64-symbol TU. The specification also requires that the video data be evenly distributed within the TUs composing a full active video line. A throttle function distributes the data and regulates it to ensure that the TUs leaving the IP are evenly packed. The pixel packetizer punctuates the outgoing video stream with the correct packet comma codes, such as blank end (BE), fill start (FS), and fill end (FE). Internally, the pixel packetizer uses a symbol and a TU counter to ensure that it respects the TU boundaries.
6. The blank start generator determines when to send the blank start (BS) comma codes with their corresponding video data packets. This block operates in enhanced or standard framing mode.

The video geometry measurement path determines the video geometry (such as HTOTAL, VTOTAL, and VHEIGHT) required for the DisplayPort main stream attributes (MSA), which are sent once every vertical blanking interval.

The MSA generator provides the MSA packet framed with secondary start (SS) and secondary end (SE) comma codes based on the requested lane count. The multiplexer then combines the packetized data from the video packetizer path and the MSA data into a single stream.

The audio encoder generates the Audio InfoFrame, Audio Timestamp, and Audio Sample packets from the incoming audio sample data stream. The secondary stream scheduler arbitrates the data flow among the Audio InfoFrame, Audio Timestamp, and Audio Sample packets and the incoming secondary stream packet into a single secondary stream in a round robin method.

Based on the requested lane count, the secondary stream encoder packetizes and inserts the secondary stream packets into the combined packetized video and MSA data.

The secondary stream encoder path consists of the following steps:

1. The secondary stream encoder determines the valid windows of opportunity during vertical and horizontal blanking regions for secondary stream packets.
2. The secondary stream encoder derives the parity byte and performs nibble interleaving for enhancing error-correcting capability.
3. The encoder packetizes the secondary stream packets with SS and SE.
4. The encoder inserts the secondary stream packets into the merged video and MSA data.

The IP multiplexes the packetized data, MSA data, and blank generator data into a single stream.

The combined data goes through a scrambler and an 8B/10B encoder, and is available as a 20-bit double-rate or a 40-bit quad-rate DisplayPort encoded video port. The 20- or 40-bit port connects directly to the Intel FPGA high-speed output transceiver.

During training periods, the source can send the DisplayPort clock recovery and symbol lock test patterns (training pattern 1, training pattern 2, and training pattern 3, respectively), upon receiving the request from downstream DisplayPort sink.

Only the Symbol Error measurement pattern and HBR2 Compliance EYE pattern require both scrambling and 8B/10B encoding. The PBRS7 pattern and Custom 80-bit pattern do not require scrambling or 8B/10B encoding. Training patterns 1, 2, and 3, and D10.2 test pattern require only 8B/10B encoding.

The controller controls the main link data path and the sideband channel.

The AUX controller interface works with a simple serial-port-type peripheral that operates in a polled mode. It captures all bytes sent from and received by the AUX channel, which is useful for debugging. The IP clocks the AUX controller using a 16 MHz clock input (aux_clk).

The DisplayPort Intel^® FPGA IP is compliant with eDP version 1.3. eDP is based on the VESA DisplayPort Standard. It has the same electrical interface and can share the same video port on the controller. The DisplayPort source IP supports:

• Full (normal) link training—default
• Fast link training—mandatory eDP feature

The Nios^® II processor typically drives the HDCP 1.3 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port (tx_csr interface) using Avalon^® memory-mapped interface.

The HDCP specifications requires the HDCP 1.3 TX core to be programmed with the DCP-issued production keys – Device Private Keys (Akeys) and Key Selection Vector (Aksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (tx_hdcp interface). The on-chip memory must store the key data in the arrangement in the table below.

When authenticating with the HDCP 1.3 repeater device, the HDCP 1.3 TX core must perform the second part of the authentication protocol. This second part corresponds to the computation of the SHA-1 hash digest for all downstream device KSVs which are written to the registers in Control and Status Register Layer using the Control and Status Port (Avalon-MM).

The Video Stream and Secondary Data layer receives audio and video content over its Video and Secondary Data Input Port, and performs the encryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort TX core to determine when to encrypt frames.

You can use the HDCP 1.3 registers to perform authentication. The HDCP 1.3 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of AUTH_CMD must be in one-hot format that only one bit can be set at a time.

The Nios^® II processor typically drives the HDCP 2.3 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port (tx_csr interface) using Avalon^® memory-mapped interface.

The HDCP specifications requires the HDCP 2.3 TX core to be programmed with the DCP-issued production key – Global Constant (lc128). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (tx_hdcp interface). The on-chip memory must store the key data in the arrangement in the table below.

The Video Stream and Secondary Data Layer receives audio and video content over its Video and Secondary Data Input port, and performs the encryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort TX core to determine when to encrypt frames.

You can use the HDCP 2.3 registers to perform authentication. The HDCP 2.3 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of CRYPTO_CMD must be in one-hot encoding format that only one bit can be set at a time.

The following tables list the source’s port interfaces. Your instantiation contains only the interfaces that you have enabled.

The controller interface allows you to control the source from an external or on-chip controller, such as the Nios II processor.

The controller can control the DisplayPort link parameters and the AUX channel controller.

The AUX channel controller interface works with a simple serial-port-type peripheral that operates in a polled mode. Because the DisplayPort AUX protocol is a master-slave interface, the DisplayPort source (the master) starts a transaction by sending a request and then waits for a reply from the attached sink.

The controller interface includes a single interrupt source. The interrupt notifies the controller of an HPD signal state change. Your system can interrogate the DPTX_TX_STATUS register to determine the cause of the interrupt. Writing to the DPTX_TX_STATUS register clears the pending interrupt event.

The IP has three ports that control the serial data across the AUX channel:

• Data input (tx_aux_in)
• Data output (tx_aux_out)
• Output enable (tx_aux_oe). The output enable port controls the direction of data across the bidirectional link.

These ports are clocked by the source’s 16 MHz clock (aux_clk).

The source’s AUX controller captures all bytes sent from and received by the AUX channel, which is useful for debugging. The IP provides a standard stream interface that you can use to drive an Avalon-ST FIFO component directly.

The core sends video to be encoded through the txN_video_in or txN_video_in_im interface, depending on whether or not you turn on the TX Video IM Enable parameter.

You specify the data input width through the Maximum video input color depth parameter. The same input port transfers RGB and YCbCr data in 4:4:4, 4:2:2, or 4:2:0 color format. Data is most-significant bit aligned.

If you set Pixel input mode to Dual or Quad, the IP sends two or four pixels in parallel, respectively. To support video resolutions with horizontal active, front porch, or back porch of a length not divisible by 2 or 4, the data enable, horizontal sync, and vertical sync signals are widened.

The following figure shows the pixel data order from the least significant bits to the most significant bits.

The txN_video_in_im ports replace the txN_video_in ports when you turn on the TX Video IM Enable parameter. The txN_video_in_im ports (N = 0 to 3) transmit video data when either the horizontal/vertical syncs or the exact pixel clock is not available. The streams need synchronization pulses at the start and end of active lines and active frames.

The timing diagram below illustrates the behavior of the ports when TX_PIXELS_PER_CLOCK = 4, TX_VIDEO_BPC = 10, and line length = 16 pixels.

• You specify the data input width through the Maximum video input color depth parameter. The core uses the same output port to transfer both RGB and YCbCr data in either 4:4:4, 4:2:2, or 4:2:0 color format.
• The data organization and pixel ordering of the txN_im_data ports are identical to the ones of the txN_vid_data signals.
• When you configure the Pixel input mode parameter to Dual or Quad, the IP sends two or four pixels in parallel respectively.
• The txN_im_valid signal is widened to support video horizontal resolutions not divisible by two or four. For example, if TX_PIXELS_PER_CLOCK = 2, txN_im_valid[0] must assert when pixel N belongs to active video and txN_im_valid[1] must assert when pixel N+1 belongs to active video.
• For interlaced video, the core samples txN_im_field when txN_im_sof asserts. When txN_im_field asserts, it marks txN_im_data as belonging to the top field.
• The frequency of the txN_im_clk signal must be equal to or higher than the frequency of the maximum video pixel clock to be transmitted divided by the pixel input mode.
• Not all clock cycles need to contain valid (active) pixel data; only those indicated by the assertion of txN_im_valid.
• The txN_video_in_im ports support the Adaptive Sync feature.

The GPU MSA registers for the remaining MSA parameters are Read/Write and you can set the value for these parameters:

• HTOTAL and VTOTAL
• HSP and HSW
• HSTART and VSTART

The transceiver or Native PHY IP core instance is no longer instantiated within the DisplayPort Intel^® FPGA IP.

The DisplayPort Intel^® FPGA IP uses a soft 8B/10B encoder. This interface provides TX encoded video data (tx_parallel_data) in either dual symbol (20-bit) or quad symbol (40-bit) mode and drives the digital reset (tx_digitalreset), analog reset (tx_analogreset), and PLL powerdown signals (tx_pll_powerdown) of the transceiver.

You can reconfigure the transceiver to accept single reference clock. The single reference clock is a 135 MHz clock for all bit rates: RBR, HBR, HBR2, and HBR3.

During run-time, you can reconfigure the transceiver to operate in either one of the bit rates by changing TX PLL divide ratio.

When the IP makes a request, the tx_reconfig_req port goes high. The user logic asserts tx_reconfig_ack and then reconfigures the transceiver. During reconfiguration, the user logic holds tx_reconfig_busy high. The user logic drives it low when reconfiguration completes.

The tx_analog_reconfig interface uses the tx_vod and tx_emp transceiver management control ports. You must map these ports for the device you are using. To change these values, the core drives tx_analog_reconfig_req high. Then, the user logic sets tx_analog_reconfig_ack high to acknowledge and drives tx_analog_reconfig_busy high during reconfiguration. When reconfiguration completes, the user logic drives tx_analog_reconfig_busy low.

The core calculates the associated parity bytes. The secondary stream interface uses the start-of-packet (SOP) and end-of-packet (EOP) to determine if the current input is a header or payload.

The ready latency is 1 clock cycle for the payload sub-packets. When core is ready, it sends the header forward. When the header is forwarded, the 16-byte payload (DB0 … DB15 and DB16 … DB31) must be available and the core must assert its associated valid signal on the next clock cycle when the output ready signal is high. The valid signal must remain low until the ready signal is high.

The core supports only 16-byte and 32-byte payloads. Payloads that contain only the first 16 data bytes can assert the EOP on the second valid pulse to terminate the packet sequence. The core clocks in the data to the secondary stream interface through tx_ss_clk. tx_ss_clk is at the same phase and frequency as the main link lane 0 clock.

You can also use the secondary stream data packet to transport HDR metadata. CTA-861-G specification defines the HDR InfoFrame packet information as Packet Type, Version, data packets, and so on. The HDR metadata must follow InfoFrame SDP version 1.3 format defined in the VESA DisplayPort Standard version 1.4a.

For example, if the CTA-861-G specification-defined HDR InfoFrame type is 0x07, the VESA DisplayPort Standard version 1.4a-defined SDP InfoFrame Header Byte 1 as secondary-data packet type is 80h + Non-audio InfoFrame type value. The Header Byte 1 (HB1 in Figure 20) must be written to 87h.

The audio encoder is upstream of the secondary stream encoder. It generates the Audio InfoFrame, Audio Timestamp, and Audio Sample packets from the incoming audio sample data stream. Then, it sends the three packet types to the secondary stream encoder before they are transmitted to the downstream sink device.

The IP requires a txN_audio_valid signal for designs in which the txN_audio_clk signal is higher than the actual sample clock. The txN_audio_valid signal qualifies the audio data on the txN_audio_lpcm_data input. If txN_audio_clk is the actual sample clock, you can tie the txN_audio_valid signal to 1.

The figure and table below illustrate the audio sample data bits and bit field definitions, respectively.

When you configure the DisplayPort Intel^® FPGA IP for 2 or 8 channels, you can transmit any number of audio channels fewer than or equal to the number of channels you selected.

The DisplayPort Intel^® FPGA IP internally calculates the Maud based on a fixed (8000h) to generate the Audio Timestamp packet. The IP generates the Audio InfoFrame packet based on the information from the DisplayPort source audio registers: LFEBPL, CA, LSV, and DM_INH. The IP continues transmitting the Audio Timestamp, Audio InfoFrame, and Audio Sample packets even when the main video stream is no longer transmitting. When there is no video stream, the IP transmits an Audio Sample packet after each BS symbol, and transmits an Audio Timestamp and Audio InfoFrame once after every 512^th BS symbol set.

The source automatically generates the Audio InfoFrame and fills it with only information about the number of channels used.

Use the audio channel status to provide any information about the audio stream needed by downstream devices.

The source uses the following clocks:

• Local pixel clock (txN_vid_clk), which clocks video data into the IP.
• Main link clock (tx_ss_clk), which clocks data out of the IP and into the high-speed serial output (HSSI) components. The main link clock is the output of the CMU PLL clock. You can supply the CMU PLL with the single reference clock (135 MHz). You can use other frequencies by changing the CMU PLL divider ratios and/or reconfiguring the transceiver. The 20- or 40- bit data fed to the HSSI is synchronized to a single HSSI[0] clock. If you select the dual symbol mode, this clock is equal to the link rate divided by 20 (270, 135, or 81 MHz). If you select the quad symbol mode, this clock is equal to the link rate divided by 40 (202.5, 135, 67.5, or 40.5 MHz). The core supports only asynchronous local pixel clock and main link clock.
• 16 MHz clock (aux_clk), which the IP requires to encode or decode the AUX channel.
• A separate clock (clk) clocks the Avalon-MM interface.
• txN_audio_clk for the audio interface.

The DisplayPort sink consists of a DisplayPort decoder block, a transceiver management block, a controller interface block, and an HDCP interface block with an Avalon^® memory-mapped interface for connecting with an embedded controller such as the Nios II processor.

The device transceiver sends 20-bit (dual symbol) or 40-bit (quad symbol) parallel DisplayPort data to the sink. Each data lane is clocked in to the IP by its own respective clock output from the transceiver. Inside the sink, the four independent clock domains are synchronized to the lane 0 clock. Then, the IP performs the following actions:

1. The IP aligns the data stream and performs 8B/10B decoding.
2. The IP deskews the data and then descrambles it.
3. The IP splits the unscrambled data stream into parallel paths.
   1. The SS decoder block performs secondary stream decoding, which the core transfers into the rx_ss_clk domain through a DCFIFO.
   2. The main data path extracts all pixel data from the incoming stream. Then, the gearbox block resamples the pixel data into the current bit-per-pixel data width. Next, the IP core crosses the pixel data into the rxN_vid_clk domain through a DCFIFO. Finally, the IP steers the data into a single, dual, or quad pixel data stream.
   3. MSA decode path.
   4. Video decode path.

You configure the sink to output the video data as a proprietary data stream. You specify the output pixel data width at 6, 8, 10, 12, or 16 bpc. This format can interface with downstream Video and Image Processing (VIP) Suite components.

The AUX controller can operate in an autonomous mode in which the sink controls all AUX channel activity without an external embedded controller. The IP outputs an AUX debugging stream so that you can inspect the activity on the AUX channel in real time.

The DisplayPort Intel^® FPGA IP is compliant with eDP version 1.3. eDP is based on the VESA DisplayPort Standard. It has the same electrical interface and can share the same video port on the controller. The DisplayPort sink supports:

• Full (normal) link training—default
• Fast link training—mandatory eDP feature
• Black video—mandatory eDP feature

The DisplayPort sink capability registers are implemented in the IP and support limited features.

The HDCP 1.3 RX core is fully autonomous. For DisplayPort application, the HDCP transmitter and the HDCP receiver communicates the HDCP register values over the AUX channel. Turn on the Enable GPU control parameter and use a Nios^® II processor to drive the HDCP 1.3 RX core through the HDCP Register Port ( Avalon^® memory-mapped interface). The HDCP Register Port is not exposed and will be automatically driven when you enable the Support HDCP 1.3 parameter.

The HDCP specifications requires the HDCP 1.3 RX core to be programmed with the DCP-issued production key – Device Private Keys (Bkeys) and Key Selection Vector (Bksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (rx_hdcp interface). The on-chip memory must store the key data in the arrangement shown in the table below.

The Video Stream and Secondary Data Layer receives audio and video content over its Video and Secondary Data Input Port, and performs the decryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort IP to determine when to decrypt frames.

To implement the HDCP 1.3 RX core as a repeater upstream interface, the IP must propagate certain information such as KSV list and Bstatus to the upstream transmitter and to be used for SHA-1 hash digest. The repeater downstream interface (TX) must provide this information through the Repeater Message Port (rx_rpt_msg interface) using the Avalon^® memory-mapped interface. You can use the same clock source to drive the clocking for the HDCP Register Port (or the controller interface of the DisplayPort Intel^® FPGA IP) and Repeater Message Port.

The mapping for the RX registers defined in the following table is equivalent to the address space for HDCP 1.3 receiver defined in the HDCP specification.

The HDCP 2.3 RX core is fully autonomous. For DisplayPort application, the HDCP transmitter and the HDCP receiver communicates the HDCP register values over the AUX channel. Turn on the Enable GPU control parameter and use a Nios^® II processor to drive the HDCP 2.3 RX core through the HDCP Register Port ( Avalon^® memory-mapped interface). The HDCP Register Port is not exposed and will be automatically driven when you enable the Support HDCP 2.3 parameter.

The HDCP specifications requires the HDCP 2.3 RX core to be programmed with the DCP-issued production key – Global Constant (lc128), RSA private key (kprivrx) and RSA Public Key Certificate (certrx). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (rx_hdcp interface). The on-chip memory must store the key data in the arrangement shown in the table below.

The Video Stream and Secondary Data Layer receives audio and video content over its Video and Secondary Data Input Port, and performs the decryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort IP to determine when to decrypt frames.

To implement the HDCP 2.3 RX core as a repeater upstream interface, the IP must propagate certain information such as ReceiverID List and RxInfo to the upstream transmitter and to be used for HMAC computation. The repeater downstream interface (TX) must provide this information using the Repeater Message Port (rx_rpt_msg interface) using the Avalon^® memory-mapped interface. You can use the same clock source to drive the clocking for the HDCP Register Port (or the controller interface of the DisplayPort Intel^® FPGA IP) and Repeater Message Port.

The mapping for the RX registers and RX Repeater registers are defined in the following tables.

The following tables summarize the sink’s interfaces. Your instantiation contains only the interfaces that you have enabled.

The controller interface allows you to control the sink from an external or on-chip controller, such as the Nios II processor for debugging. The controller interface is an Avalon-MM slave that also allows access to the sink’s internal status registers.

The sink asserts the rx_mgmt_irq port when issuing an interrupt to the controller.

The IP has three ports to control the serial data across the AUX channel:

• Data input (rx_aux_in)
• Data output (rx_aux_out)
• Output enable (rx_aux_oe). The output enable port controls the direction of data across the bidirectional link.

A state machine decodes the incoming AUX channel’s Manchester encoded data using the 16 MHz clock. The message parsing drives the state machine input directly. The state machine performs all lane training and EDID link-layer services.

The sink’s AUX interface also generates appropriate HPD IRQ events. These events occur if the sink’s main link decoder detects a signal loss.

The sink core uses the rx_cable_detect signal to detect when a source (upstream) device is physically connected and the rx_pwr_detect signal to detect when a source device is powered. The sink core keeps the rx_hpd signal deasserted if both the rx_cable_detect and rx_pwr_detect signals are not asserted.

The AUX controller lets you capture all bytes sent from and received by the AUX channel, which is useful for debugging. The IP supports a standard stream interface that can drive an Avalon^® streaming FIFO component directly.

You can use the Avalon^® memory-mapped EDID interface to access an on-chip memory region containing the sink’s EDID data. The AUX sink controller reads and writes to this memory region according to traffic on the AUX channel.

The Avalon^® memory-mapped interface uses an 8-bit address with an 8-bit data bus. The interface assumes a read latency of 1.

Refer to the VESA Enhanced Extended Display Identification Data Implementation Guide for more information.

The sink provides link level data for debugging and configuring external components using the rx_lane_count port.

This interface provides access to the post-scrambler DisplayPort data, which is useful for low-level debugging source equipment. The 8-bit symbols received are organized as shown in the following table, where n increases with time (at each main link clock cycle, by 2 for dual-symbol mode or by 4 for quad-symbol mode).

When data is received, data is produced on lane 0, lanes 0 and 1, or on all four lanes according to how many lanes are currently used and link trained on the main link. The IP provides the data output immediately after the data passes through the descrambler and features all control symbols, data, and original timing. As data is always valid at each and every clock cycle, the rxN_stream_valid signal remains asserted.

This interface (rxN_video_out) allows access to the video data as a non-Avalon-ST stream. You can use this stream to interface with an external pixel clock recovery function. The stream provides synchronization pulses at the start and end of active lines, and at the start and end of active frames.

The rxN_vid_overflow signal is always valid, regardless of the logical state of rxN_vid_valid. rxN_vid_overflow is asserted for at least one clock cycle when the sink core internal video data FIFO runs into an overflow condition. This condition can occur when the rxN_vid_clk frequency is too low to transport the received video data successfully.

Specify the maximum data color depth in the DisplayPort parameter editor. The same output port transfers both RGB and YCbCr data in 4:4:4, 4:2:2, or 4:2:0 color format. Data is most-significant bit aligned and formatted for 4:4:4.

If you set Pixel output mode to Dual or Quad, the IP produces two or four pixels in parallel, respectively. To support video resolutions with horizontal active, front and pack porches with lengths that are not divisible by two or four, rxN_vid_valid is widened. For example, for two pixels per clock, rxN_vid_valid[0] is asserted when pixel N belongs to active video and rxN_vid_valid[1] is asserted when pixel n + 1 belongs to active video.

The following figure shows the pixel data order from the least significant bits to the most significant bits.

The rxN_video_out interface may interface with a clocked video input (CVI). CVI accepts the following video signals with a separate synchronization mode: datavalid, de, h_sync, v_sync, f, locked, and data.

The DisplayPort rxN_video_out interface has the following signals: rxN_vid_valid, rxN_vid_sol, rxN_vid_eol, rxN_vid_sof, rxN_vid_eof, rxN_vid_locked, and rxN_vid_data.

always @ (posedge clk_video) 
begin 
	rx_vid_h_sync <= rx_vid_eol; 	
	rx_vid_v_sync <= rx_vid_eof; 
end 

The transceiver or Native PHY IP core instance is no longer instantiated within the DisplayPort Intel^® FPGA IP. The DisplayPort Intel^® FPGA IP uses a soft 8B/10B decoder. This interface receives RX transceiver recovered data (rx_parallel_data) in either dual symbol (20-bit) or quad symbol (40-bit) mode, and drives the digital reset (rx_digitalreset), analog reset (rx_analogreset), and controls the CDR circuitry locking mode.

You can reconfigure the transceiver to accept a single reference clock of 135 MHz for all bit rates: RBR, HBR, HBR2, and HBR3.

During run-time, you can reconfigure the transceiver to operate in either one of the bit rate by changing RX CDR PLLs divider ratio.

When the IP makes a request, the rx_reconfig_req port goes high. The user logic asserts rx_reconfig_ack, and then reconfigures the transceiver. During reconfiguration, the user logic holds rx_reconfig_busy high. The user logic drives it low when reconfiguration completes.

The secondary streams data can be received through the rxN_ss interfaces. The interfaces do not allow for back-pressure and assume the downstream logic can handle complete packets. The rxN_ss interface does not distinguish between the types of packets it receives.

The format of the rxN_ss interface output corresponds to four 15-nibble code words as specified by the VESA DisplayPort Standard version 1.2a, Section 2.2.6.3. These 15-nibble code words are typically supplied to the downstream Reed-Solomon decoder. The format differs for both header and payload, as shown in the following figure.

The following figure shows a typical secondary stream packet with the four byte header (HB0, HB1, HB2, and HB3) and 32-byte payload (DB0, ..., DB31). Each symbol has an associated parity nibble (PB0, ..., PB11). Downstream logic uses start-of-packet and end-of-packet to determine if the current input is a header or payload symbol.

Data is clocked out of the rxN_ss port using the rx_ss_clk signal. This signal is the same phase and frequency as the main link lane 0 clock.

The audio interfaces are downstream from the secondary stream decoder. They extract and decode the Audio InfoFrame packets, Audio Timestamp packets, and Audio Sample data.

The Audio Timestamp packet payload contains M and N values, which the sink uses to recover the source’s audio sample clock. The rxN_audio port uses the values to generate the rxN_audio_valid signal according to sample audio data. Data is clocked out using the rx_ss_clk signal. The rx_ss_clk signal comes from the rx parallel clock from the RX transceiver. This clock runs at link data rate/20 for dual symbol mode and link data rate/40 for quad symbol mode.

The sink generates the rxN_audio_valid signal using the M and N values, and asserts it at the current audio sample clock rate. The rxN_audio_mute signal indicates whether audio data is present on the DisplayPort interface.

The captured Audio InfoFrame is available on the audio port. The 5-byte port corresponds to the 5 bytes used in the Audio InfoFrame (refer to CEA-861-D). The Audio InfoFrame describes the type of audio content.

The rxN_msa_conduit ports allow designs access to the MSA and VB-ID parameters on a top-level port. The following table shows the 217-bit port bundle assignments. The prefixes msa and vbid denote parameters from the MSA and Vertical Blank ID (VB-ID) packets, respectively.

The sink asserts bit msa_valid when all msa_ signals are valid and deasserts during MSA update. The sink assigns the MSA parameters to zero when it is not receiving valid video data.

The sink asserts the msa_lock bit when the MSA fields have been correctly formatted for the last 15 video frames. Because msa_lock changes state only when msa_valid = 1, you can use its rising edge to strobe new MSA values following an idle video period; for example, when the source changes video resolution. You can use its deasserted state to invalidate received video data.

The sink asserts bit vbid_strobe for one clock cycle when it detects the VB-ID and all vbid_ signals are valid to be read.