Transmitter

The DP transmitter (DPTX) consists of two main layers: the policy maker (PM) and link layer (LNK). The policy maker is responsible for communication with the downstream DP sink device, training the link, and controlling the link layer.
The DPTX diagram is shown in Figure 1.

Figure 1: DPTX architecture (click on the image to enlarge it)

Architecture

The policy maker sits on the system clock. Everything below the clock domain boundary runs on the link clock. Video enters on the left, is mapped onto the lanes and dressed with the attributes and packets the standard asks for, and leaves as link data for the FPGA serdes. Link control drives every stage of the layer; the clock detectors only measure the incoming clocks and report what they find back to the policy maker.

• Policy makerprt_dp_pm_top

  A RISC-V core with its own ROM and RAM, running the firmware that owns the protocol: the AUX channel, hot plug detect, capability exchange and link training. It talks to the application processor through a mailbox, and to the link layer through a message bus across the clock domain boundary.

• Link controlprt_dptx_ctl

  Holds the link state the policy maker has set — line rate, lane count, transport mode — and drives the stages of the link layer accordingly.

• Videoprt_dptx_vid

  Takes the native video in, buffers it across into the link clock and maps the pixels onto the active lanes. The video FIFO absorbs the difference between the pixel rate and what the link can carry.

• MSAprt_dptx_msa

  Inserts the main stream attributes: the timing and format description the sink needs in order to reconstruct the picture.

• SDPprt_dptx_sdp

  Inserts the secondary data packets that carry audio and meta data, taken from the secondary packet interface. Calculates the parity bytes of the packets. Built in only when the SDP parameter is enabled.

• MSTprt_dptx_mst

  Splits the link into time slots so that more than one video stream can share it. Built in only when the MST parameter is enabled; in single stream mode the datapath passes straight through.

• Scramblerprt_dptx_scrm

  Scrambles the symbols on each lane, as the DisplayPort specification requires.

• Trainingprt_dptx_trn

  Replaces the data with the training pattern sequences while the link is being brought up, under control of the policy maker, and hands the lanes back to normal traffic once training passes.

• Skewprt_dptx_skew

  Applies the inter-lane skew the specification prescribes before the symbols go to the serdes.

Video Interface

The DPTX has a native video interface and supports 2 or 4 pixels per clock. The video interface signals listed in the signal table have the prefix VID0_ and are high active. The second stream (VID1_) is only used with MST. All the pixels of a clock come in on one data bus, VID0_DAT_IN, of 3 * P_PPC * P_BPC bits. Each pixel takes 3 * P_BPC bits, with green / Y in the lowest bits, then blue / Cb and then red / Cr: per pixel {R / Cr, B / Cb, G / Y}. Pixel 0 is in the lowest bits of the bus. YCbCr 4:4:4 has the same mapping as RGB. The DPTX only takes the video signals in on clocks where the clock enable VID0_CKE_IN is high. Tie it high when the video clock is exactly the pixel clock divided by the pixels per clock; drive it from a clock enable DCO when the video clock runs faster. The video clock (VID0_CLK_IN) runs at the pixel clock divided by the pixels per clock (2 or 4). For example with video resolution 1080p60 the pixel clock is 148.5 MHz. In 2 pixels per clock configuration the video clock runs at 74.25 MHz. It has a frequency of 37.125 MHz in 4 pixels per clock. The video clock must be stable and is generated by a PLL. The DPTX can support any video timing as long as the horizontal video timing is dividable by the number of pixels per clock (2 or 4). Figure 2 shows the video timing. Each data word (D0 to Dn) carries P_PPC pixels; how the pixels are mapped within a word is shown in figures 3 and 4.

Figure 2: Video timing (click on the image to enlarge it)

Video mapping

The video data input VID0_DAT_IN is 3 * P_PPC * P_BPC bits wide and carries per pixel {R / Cr, B / Cb, G / Y}, with green / Y in the lowest bits. Pixel 0 is the first pixel of the group and sits in the lowest bits of the bus. The IP-core supports RGB 4:4:4 and YCbCr 4:4:4. Both share the same bit layout: Cr takes the place of red, Y the place of green and Cb the place of blue. With 8 bits per component in a core built for 10 bits per component (P_BPC = 10), the components are MSB-aligned in each 10-bit field and the 2 lowest bits are unused. The second stream (VID1_DAT_IN, MST only) has the same mapping.

Figure 3: Video mapping - 2 pixels per clock (click on the image to enlarge it)

Figure 4: Video mapping - 4 pixels per clock (click on the image to enlarge it)

Video clocking

The transmitter can support any video resolution. The table lists the video clocks for SD/HD video resolutions. The video clock is generated by the user.

Secondary Data Packet Interface

The secondary data packet interface is only available when the parameter P_SDP is set. The interface signals have the prefix SDP_ and are high active. The interface runs on its own clock (SDP_CLK_IN), the DPTX takes care of the clock domain crossing to the link clock. Two packet lengths are supported, as defined in the DisplayPort specification. A long packet has 48 bytes: a 4-byte header (HB0 to HB3), a 32-byte payload (DB0 to DB31) and 12 parity bytes (PB0 to PB11), in twelve 32-bit words. A short packet has 28 bytes: a 4-byte header, a 16-byte payload (DB0 to DB15) and 8 parity bytes (PB0 to PB7), in the first seven words of the table below. The short packet is used for example by the Audio_Stream SDP with two audio channels. Other packet lengths are not supported. The DPTX reserves the blanking time of a long packet for every packet. SDP_SOP_IN marks the first word and SDP_EOP_IN the last word of the packet. A word is only taken in when SDP_VLD_IN is high. Start a packet only when SDP_RDY_OUT is high. The DPTX calculates the parity bytes (PB0 to PB11, Reed-Solomon RS(15,13)) of the header and the payload. The parity words of the packet (words 1, 6 and 11) are ignored and can be set to zero. The DPTX inserts the packets in the horizontal and vertical blanking periods, maps the packet onto the active lanes (1, 2 or 4) and adds the SS and SE control symbols. The host processor can also send a packet once with the API function prt_dptx_sdp_send (for example HDR or custom metadata, see the driver page). The DPTX inserts this packet between the packets of the SDP interface: after the running packet SDP_RDY_OUT is cleared, and when the interface is quiet for 16 clocks the processor packet is taken in. A packet must start no more than 15 clocks after SDP_RDY_OUT is cleared. The DPTX holds two processor packets; prt_dptx_sdp_is_rdy tells when there is room for a new packet. Audio packets are sent through the SDP interface. Figure 5 shows the transfer of a long packet and Figure 6 the transfer of a short packet. The grey parity words are ignored by the DPTX. A short packet ends with word 6 (SDP_EOP_IN high).

Figure 5: Secondary data packet timing - long packet (48 bytes) (click on the image to enlarge it)

Figure 6: Secondary data packet timing - short packet (28 bytes) (click on the image to enlarge it)

Link Interface

The link interface connects the DPTX to the FPGA serdes. The link interface signals are prefixed with LNK_. The link clock (LNK_CLK_IN) is generated by the FPGA serdes and its frequency depends on the actual link rate. The link data (LNK_DAT_OUT) is directly routed to the FPGA serdes. See the DP reference design for the mapping.

Link Clocking

The link clock for the various link rates are shown in the table below. The link clock is generated by the FPGA serdes.