MIPI DSI TX Controller - MIPI DSI TX Controller - 3.0 English - PG238

The MIPI DSI TX Controller core consists of multiple layers defined in the MIPI DSI TX 2.0 specification, such as the lane management layer, low-level protocol, and pixel-to-byte conversion.

The DSI TX Controller core receives a stream of image data through an input stream interface. Based on the targeted display peripheral supported resolution and timing requirements, the controller must be programmed with the required timing values. The controller then generates packets fulfilling the required video timing markers based on different video transmit mode sequences. In addition, the core supports sending short command packets during BLLP periods of video frames and also supports sending long or short command packets when configured in the command mode. Sub-block details of the MIPI DSI TX Controller are shown in the following figure.

The features of this core include:

• 1 to 4 Lanes D-PHY support with a data rate of 2500 Mb/s per lane and 1 to 3 Lanes C-PHY support with a data rate of 1000 Ms/s. Allows more bandwidth than that provided by one lane. If you are trying to avoid high clock rates, the subsystem can expand the data path to multiple lanes and obtain approximately linear increases in peak bus bandwidth.
• Generates PPI transfers towards D-PHY/C-PHY with continuous clock.
• ECC and CRC calculation based on the algorithm specified in DSI Specification: The correct interpretation of the data identifier and word count values is vital to the packet structure. ECC is calculated over the packet header.

  To detect possible errors in transmission, a checksum is calculated over each data packet. The checksum is realized as a 16-bit CRC. The generator polynomial is x16+x12+x5+x0.

• Command Queue, data queue, and command generation logic for non-video packets: To send non-video packets to display peripheral, a command queue is implemented to store the required command packets to be sent (For example, Color mode on-off, Shutdown peripheral command, and so on). When in video mode, the controller finds enough time-slot available during the video blanking periods, these short commands are sent over the DSI link. When in command mode, the controller sends only the commands long/short programmed through the register. Video data is not sent in this mode.
• All three video modes supported (Non-burst with sync pulses, Non-burst with sync events, Burst mode)
• Pixel to byte Conversion: The input video stream is expected to be compliant with AXI4-Stream Video IP and System Design Guide (UG934) recommendations. Based on data type, the incoming pixel stream is converted to byte stream to match with the DSI requirements detailed in sec 8.8 of the MIPI Alliance Standard for DSI specification.

  RGB component ordering, packed, unpacked mechanisms differ between AXI4-Stream Video IP and System Design Guide (UG934) and DSI Specification. Refer to AXI4-Stream Video IP and System Design Guide (UG934) and DSI specifications for better understanding on component ordering, packed, unpacked styles, and so on.

  The following figures illustrate the incoming pixel stream ordering on an AXI4-Stream Video interface for different data types and pixels per clock combinations.

  Figure 2. Single Pixel RGB888
  

  

  
  
  Figure 3. Dual Pixels RGB888
  

  

  
  
  Figure 4. Quad Pixels RGB888
  

  

  
  
  Figure 5. Single Pixel RGB666 (Loosely, Packed)
  

  

  
  
  Figure 6. Dual Pixels RGB666 (Loosely, Packed)
  

  

  
  
  Figure 7. Quad Pixels RGB666 (Loosely, Packed)
  

  

  
  
  Figure 8. Single Pixel RGB565
  

  

  
  
  Figure 9. Dual Pixels RGB565
  

  

  
  
  Figure 10. Quad Pixels RGB565
  

  

  
  
  Figure 11. Single Pixel Compressed
  

  

  
  
  Figure 12. Dual Pixel Compressed
  

  

  
  
  Figure 13. Quad Pixel Compressed
  

  

  
  
• Register programmable EoTp generation support.
• Interrupt generation to indicate detection of underrun condition during pixel transfer and unsupported data types detected in the command queue.
• One horizontal scanline of active pixels is transferred as one single DSI packet.
• All mandatory uncompressed pixel formats 16 bpp (RGB565), 18 bpp (RGB666 packed), 18 bpp (RGB666 loosely packed), and 24 bpp (RGB888) are supported.
• Data types Packed 16-bit YUV 422, and Packed 20-bit YUV 422 are supported for UltraScale+ and Versal devices.
• Core accepts compressed data type from GUI selection, where you are expected to pump in the compressed data. Core passes those streams of data without any conversion.

Escape Mode

• ULPS uses the clock + all data lanes; LPDT uses data lane 0 only.
• For ULPS, there is no individual lane control, all lanes go to ULPS once ULPS is enabled.
• ULPS entry occurs immediately once ulps_mode is enabled from register and controller will reset the internal image data FIFOs. So, when switching to Video mode after ULPS exit, controller starts with new frame as it is discarded the old frame in ULPS mode.
• Escape mode LPDT data cannot go in Blanking time(LP).
• Trigger codes are not supported, that is, txtriggeresc[3:0].
• LPDT transaction & DCS Command Data transaction are mutually exclusive and both use "Command Queue FIFO/ Data FIFO" to store input written through Command Queue Packet Register and Data FIFO Register for processing.
• CMD_or_LPDT_mode_control bit in Protocol configuration is used to switch between DCS command mode and LPDT modes. Refer Case 5: Switching the core between Video/LPDT Mode for programming sequence.
• LPDT data input written through register interface via Command Queue Register for short packet and long packet header, Data FIFO Register for long packet payload.
• The maximum payload supported for LPDT is 251 bytes.