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 core 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 core 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 32 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 following 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 designs.

Intel created the original technology, which is licensed by the Digital Content Protection LLC group. HDCP is a copy protection method where the audio/video stream is encrypted between the transmitter and the receiver, protecting it against illegal copying.

The HDCP features adheres to HDCP Specification version 1.3 and HDCP Specification version 2.3.

The HDCP 1.3 and HDCP 2.3 IPs perform all computation within the hardware core logic with no confidential values (such as private key and session key) being accessible from outside the encrypted IP.

This design example demonstrates the HDCP system in a repeater device where it accepts data, decrypts, then re-encrypts the data, and finally retransmits data. Repeaters have both DisplayPort inputs and outputs. It instantiates the FIFO buffers to perform a direct DisplayPort video stream pass-through between the DisplayPort sink and source. It may perform some signal processing, such as converting videos into a higher resolution format by replacing the FIFO buffers with the Video and Image Processing (VIP) Suite IP cores.

The following descriptions about the architecture of the design example correspond to the HDCP over DisplayPort design example block diagram.

1. The HDCP1x and HDCP2x are IPs that are available through the DisplayPort Intel^® FPGA IP parameter editor. When you configure the DisplayPort IP in the parameter editor, you can enable and include either HDCP1x or HDCP2x or both IPs as part of the subsystem. With both HDCP IPs enabled, the DisplayPort IP configures itself in the cascade topology where the HDCP2x and HDCP1x IPs are connected back-to-back.
   • The HDCP egress interface of the DisplayPort TX sends unencrypted audio video data.
   • The unencrypted data gets encrypted by the active HDCP block and sent back into the DisplayPort TX over the HDCP Ingress interface for transmission over the link.
   • The CPU subsystem as the authentication master controller ensures that only one of the HDCP TX IPs is active at any given time and the other one is passive.
   • Similarly, the HDCP RX also decrypts data received over the link from an external HDCP TX.
2. You need to program the HDCP IPs with Digital Content Protection (DCP) issued production keys. Load the following keys:

   Table 11.  DCP-issued Production Keys

   HDCP	TX/RX	Keys
   HDCP2x	TX	16 bytes: Global Constant (lc128)
   	RX	16 bytes (same as TX): Global Constant (lc128) 320 bytes: RSA Private Key (kprivrx) 522 bytes: RSA Public Key Certificate (certrx)
   HDCP1x	TX	5 bytes: TX Key Selection Vector (Aksv) 280 bytes: TX Private Device Keys (Akeys)
   	RX	5 bytes: RX Key Selection Vector (Bksv) 280 bytes: RX Private Device Keys (Bkeys)

   The design example implements the key memories as simple dual-port, dual-clock synchronous RAM. For small key size like HDCP2x TX, the IP implements the key memory using registers in regular logic.

   Note: Intel does not provide the HDCP production keys with the design example or Intel^® FPGA IPs under any circumstances. To use the HDCP IPs or the design example, you must become an HDCP adopter and acquire the production keys directly from the Digital Content Protection LLC (DCP).

   To run the design example, you either edit the key memory files at compile time to include the production keys or implement logic blocks to securely read the production keys from an external storage device and write them into the key memories at run time.

3. You can clock the cryptographic functions implemented in the HDCP2x IP with any frequency up to 200 MHz. The frequency of this clock determines how quickly the HDCP2x authentication operates. You can opt to share the 100 MHz clock used for Nios^® II processor but the authentication latency would be doubled compared to using a 200 MHz clock.
4. The values that must be exchanged between the HDCP TX and the HDCP RX are communicated over the DisplayPort AUX channel. The AUX controller is embedded within the DisplayPort IP.
5. The Nios^® II processor acts as the master in the authentication protocol and drives the control and status registers (Avalon-MM) of both the HDCP2x and HDCP1x TX IPs. The software drivers implements the authentication protocol state machine including certificate signature verification, master key exchange, locality check, session key exchange, pairing, link integrity check (HDCP1x), and authentication with repeaters, such as topology information propagation and stream management information propagation. The software drivers do not implement any of the cryptographic functions required by the authentication protocol. Instead, the HDCP IP hardware implements all the cryptographic functions ensuring no confidential values can be accessed.
6. In a DisplayPort application, the HDCP TX and HDCP RX IPs communicate the HDCP register values over the AUX channel. For a repeater application, the DisplayPort IP is configured in GPU mode where the HDCP registers in DPCD are defined in the embedded Nios^® II processor. The Nios^® II processor acts as an authentication master for the HDCP RX. The Nios^® II processor processes all HDCP register values received from the AUX controller in the DisplayPort sink before sending the values to the HDCP RX IP and vice versa.
7. In a true repeater demonstration where propagating topology information upstream is required, the Nios^® II processor drives the Repeater Message Port ( Avalon^® memory-mapped) of both HDCP2x and HDCP1x RX IPs. The Nios^® II processor clears the RX REPEATER bit to 0 when it detects the connected downstream device is not HDCP-capable or when no downstream device is connected. Without downstream connection, the RX system is now an end-point receiver, rather than a repeater. Conversely, the Nios^® II processor sets the RX REPEATER bit to 1 upon detecting the downstream device is HDCP-capable.

The Nios II software flowchart includes the HDCP authentication controls over DisplayPort application.

1. The VESA DisplayPort Standard v1.4 supports four link rates (1.62 Gbps, 2.7 Gbps, 5.4 Gbps and 8.1 Gbps). You can dynamically switch from one data rate to another. Transceiver reconfiguration is required to support dynamic link rate switching. The DisplayPort IP design example implements pre-calibration method to reduce the transceiver reconfiguration duration. Upon power-up or push button reset, the DisplayPort reconfiguration block initiates the transceiver reconfiguration to sweep across all supported link rates and all lane counts. After each data rate completes reconfiguration, each data rate recalibrates. After calibration for each data rate completes, the pre-defined calibrated registers will be stored according to the respective date rate. Refer to DisplayPort IP Design Example User Guide for more details.
2. When the precalibration step completes, the reconfiguration block is ready to start DisplayPort link training. Whenever the DisplayPort IP sends a new link rate request or hot-plug event, the reconfiguration block initiates reconfiguration to the transceiver. The reconfiguration flow includes retrieving the calibrated register offset value that corresponds to the link rate and reconfiguring the value to the transceiver. No recalibration is required. When reconfiguration completes, the transceiver is ready to receive the link rate and HDCP authentication can be initiated.
3. The Nios^® II software starts the HDCP activity by commanding the DisplayPort AUX controller to read RxCaps followed by Bcaps from external RX to detect if the downstream device is HDCP-capable, or otherwise:
   • If the returned HDCP_CAPABLE bit of RxCaps is 1, the downstream device is HDCP2x-capable.
   • If the returned HDCP_CAPABLE bit of Bcaps is 1, the downstream device is HDCP1x-capable.
   • If the returned HDCP_CAPABLE bits of both RxCaps and Bcaps are 0, the downstream device is either not HDCP-capable or inactive.
   • If the downstream device is previously not HDCP-capable or inactive but is currently HDCP-capable, the software sets the REPEATER bit of the repeater upstream (RX) to 1 to indicate the RX is now a repeater.
   • If the downstream device is previously HDCP-capable but is currently not HDCP-capable or inactive, the software sets the REPEATER bit of to 0 to indicate the RX is now an endpoint receiver.
4. The software initiates the HDCP2x authentication protocol that includes RX certificate signature verification, master key exchange, locality check, session key exchange, pairing, authentication with repeaters such as topology information propagation.
5. When in authenticated state, the Nios^® II software processes the CP_IRQ interrupts if there is any, and reads the RxStatus register from external RX. If the software detects the REAUTH_REQ bit is set, it initiates re-authentication and disables TX encryption.
6. When the downstream device is a repeater and the READY bit of the RxStatus register is set to 1, this usually indicates the downstream device topology has changed. So, the Nios II software commands the AUX controller to read the ReceiverID_List from downstream device and verify the list. If the list is valid and no topology error is detected, the software proceeds to the Content Stream Management module. Otherwise, it initiates re-authentication and disables TX encryption.
7. The Nios^® II software prepares the ReceiverID_List and RxInfo values and then writes to the Avalon-MM Repeater Message port of the repeater upstream (RX). The RX then propagates the list to external TX (upstream).
8. Authentication is complete at this point. The software enables TX encryption.
9. The software initiates the HDCP1x authentication protocol that includes key exchange and authentication with repeaters.
10. When the Nios^® II software encounters CP_IRQ interrupts, it performs link integrity check by reading and comparing Ri’ and Ri from external RX (downstream) and HDCP1x TX respectively. If the values do not match, this indicates loss of synchronization and the software initiates re-authentication and disables TX encryption.
11. If the downstream device is a repeater and the READY bit of the Bcaps register is set to 1, this usually indicates that the downstream device topology has changed. So, the Nios^® II software commands the AUX controller to read the KSV list value from the downstream device and verify the list. If the list is valid and no topology error is detected, the software prepares the KSV list and Bstatus value and writes to the Avalon-MM Repeater Message port of the repeater upstream (RX). The RX then propagates the list to external TX (upstream). Otherwise, it initiates re-authentication and disables TX encryption.

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 core 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 core 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 core 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 core 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 core 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 core 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 DP_TX_STATUS register to determine the cause of the interrupt. Writing to the DP_TX_STATUS register clears the pending interrupt event.

The IP core 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 core 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 core 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 core 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 core 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 25) 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 core 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 IP core 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 IP core internally calculates the Maud based on a fixed (8000h) to generate the Audio Timestamp packet. The IP core generates the Audio InfoFrame packet based on the information from the DisplayPort source audio registers: LFEBPL, CA, LSV, and DM_INH. The IP core 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 core 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 core.
• Main link clock (tx_ss_clk), which clocks data out of the IP core 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 core 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 core 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 core performs the following actions:

1. The IP core aligns the data stream and performs 8B/10B decoding.
2. The IP core deskews the data and then descrambles it.
3. The IP core 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 core 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 core outputs an AUX debugging stream so that you can inspect the activity on the AUX channel in real time.

The DisplayPort Intel^® FPGA IP IP core 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 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 core 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 core supports a standard stream interface that can drive an Avalon-ST FIFO component directly.

You can use the Avalon-MM 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-MM 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 core 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 core 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.