MIPI DSI is a high-speed interface that is used in applications such as smart phones, tablets, smart watches, and other embedded display applications. The Mobile Industry Processor Interface Alliance (MIPI) developed a serial communication protocol known as the Display Serial Interface or DSI. Other display interfaces such as RGB and parallel require a higher number of pins to support high resolution and refresh rates. The MIPI display serial interface requires fewer pin connections while maintaining the same level of performance.
MIPI DSI displays have the advantage of high-level graphics at a reduced complexity of signal routing, PCB design, and hardware costs. The MIPI interface uses low voltage differential signaling to transmit data at high frequencies up to 1Gb/s. The communication is done through low voltage signaling which has the benefit of low power operation. The MIPI DSI protocol allows designers to incorporate high speed, low power, and low EMI displays through a sleek, efficient interface.
The MIPI DSI interface can operate at very low power to preserve battery life. These display’s also produce very low electromagnetic interference because the signaling is done through equal positive and negative data and clock lanes. This interface can also be operated at a wide range rate of data transmission to further reduce interference on peripheral devices.
This makes MIPI a popular choice in the display industry because it supports high resolutions and color depths without increasing the number of required data lines. Display applications benefit from the ease of connection which reduces system complexity and total expense. This resource will review the MIPI DSI communication protocol, including the common terms and considerations for operation.
Interface and Packet Levels
There are two levels of MIPI communication which are separated into the interface level and packet level. Low level communication is done on the interface level. High level communication is done on the packet level. Both levels can be operated at high-speed mode and low power mode.
The interface level is used to indicate the display’s power and speed settings. The modes that are available are low power, ultra-low power, and high speed. The mode is used to indicate the start and end of packet level data. The mode used is dependent on the architecture and capabilities of the host processor and application of the display.
The interface level is comprised of different states that drive the data differentially for both high speed mode and low power mode. The states that the interface can switch to is dependent on the current state. The next state is then indicated by driving the positive and negative data lanes high or low as specified by the state codes. The state codes are defined in the table below for the high speed and low power modes.
The interface level is determined by the application and the capabilities of the host processor. This level will specify the start and stop positions of the data, the characteristics of the clock, and available functions of the interface.
Packet level communication is used when sending image data to the display in short (4 bytes) or long (6 to 65,541 byte) packets. Both long and short packets are used to specify packet size, packet data and error correction. Short packets can be sent for commands that do not require data. Longer packets can be used to send commands with multiple bytes of data and image data.
The commands indicate display operation and functions executed by the embedded display IC. The commands range from memory control, gamma correction, pixel formatting and porch control. The system commands and functions are similar to other display interface commands and are chosen based on the display’s intended application.
Packet Level: Short and Long Packets
The packets are sent in a specific sequence to indicate packet size and error correction codes. The interface level low power stop state is used to begin and end the packet data. The data ID includes information like if the packet is long or short. The word count for the long data will indicate how many bytes of data will follow. The check sum and error correction bytes are specified by the controller for specific functions.
The data is sent in bytes with the exception of the word count and the checksum which are sent as two bytes. The long packets are typically used to send display data and the short packets are used to specify command registers. The first byte is the data identifier byte that includes two bits for the virtual channel identifier. The MIPI DSI can command up to four peripherals using this virtual channel ID.
Packet Level: Error Correction
Video and Command Modes
There are two operating modes for sending data to the display for the MIPI DSI protocol. The communication can also be categorized into two modes: Command and Video. The command mode is used for sending commands into established display registers. The video mode is used to send a continuous stream of data to the display. Each mode can use short and long packet types. Command mode can be operated at high speed and low power where video mode can only operate in high-speed mode.
A factor in choosing which mode to operate the MIPI DSI display can be dependent on the location of the frame buffer. Displays that do not contain internal memory for the image data will have to operate in video mode. Certain displays provide RAM for the frame buffer and the image can be written to and read using specific commands. Command mode can be used for displays that have access to frame buffer memory to display images.
Command mode is what is typically seen with interfaces such as SPI, 8080/6800 parallel MCU, and I2C display controllers. It can use short and long packets to write and read from the display. It is more common to use short packets when in command mode because the display registers require one or two bytes of data. The commands are a standard set of controls defined by the MIPI Alliance and can be found in the display controller data sheet.
Video mode is when data is sent as a real time pixel stream. This mode relies on the host processor to provide a constant stream of image data that is continuously refreshed. Video mode can be used when the frame buffer is not provided by the display controller. A frame buffer is not required to operate in this mode because the image data is not stored.
Video Mode: Packet Structure of Pixel Data RGB-565
Packet level communication in video mode is sent as a constant stream of pixels in a specific sequence. The data is sent to the display in real time and is not stored by the display controller. The packet data is sent similarly to command mode but can only operate in the high-speed interface level.
The data sent to the display in this mode can be framed by sync events. The sync events specify the start and end of a sync, similar to the RGB interface, to represent the active area of pixel data. The sync events are sent in short packets which indicate the location and porch lengths. The sync events can replace the low power interface level events that traditionally start and end packet data. This prevents the need of switching between low power and high-speed interface levels for every sync event.
The sync events are sent in the high-speed interface level and contain critical timing information. They indicate the active area of the display and are followed by the RGB pixel stream of display data. The pixel stream of image data is sent at a long packet in the high-speed interface level. The pixel stream can be sent in different formats: RGB-565, RGB-666, RGB-888
The video mode must be continuously refreshed because the image is not stored in any memory location. This means that the controller frequency must be high enough to support a refresh rate of 60Hz or the display will lose its image.
Video Mode: Burst Mode vs Non-Burst Mode
The video mode can be broken down into two methods of sending packet data: burst mode and non-burst mode. In burst mode, the pixel data is compressed to reserve time for the interface level to return to low power. The non-burst modes transmit the pixel data in a stream controlled by sync pulses or sync events. A sync pulse non-burst mode will require the definition of display pulse widths. The sync event non-burst mode does not require the pulse widths and only uses one sync.
The total packet transmitted in video mode consists of synchronization control signals and the pixel data. If there is no RAM provided by the display, video mode will be used, and a continuous stream of the packets should be enabled. The processor will have to provide the stream of data continuously.
Operating the display in video mode requires the packets to be sent in a constant stream using the high-speed interface level. This interface level increases power consumption of the system. The video mode makes it possible to communicate with display’s that do not contain an internal frame buffer memory. The host processor will have to be able to communicate at the high-speed data transmission rate and as a result require more power to operate in the high-speed mode.
External memory can be used to store the frame buffer remotely from the display. This method presents similar timing and power constraints. The frame buffer must be continually refreshed to avoid flickering and loss of image. This means that the processor will have to fetch the data from the external buffer and transmit this information to the display at a transmission rate that is fast enough to meet the framerate requirements. This increases power consumption of the system, system memory and display controller.
Displays that do not contain an internal framebuffer memory location are often less expensive. This shifts the responsibility to the controller to provide either the memory or clock speeds. There are two options available when internal RAM is not provided by the display. The host processor can provide display memory if there is enough to support the high-level graphics. The other option is to use the video mode where the image data is streamed and not stored. The constraint of this option is the higher bandwidth, power consumption and calculating the synchronization events.
Buyers and others who are developing systems that incorporate FocusLCDs products (collectively, “Designers”) understand and agree that Designers remain responsible for using their independent analysis, evaluation and judgment in designing their applications and that Designers have full and exclusive responsibility to assure the safety of Designers' applications and compliance of their applications (and of all FocusLCDs products used in or for Designers’ applications) with all applicable regulations, laws and other applicable requirements.
Designer represents that, with respect to their applications, Designer has all the necessary expertise to create and implement safeguards that:
(1) anticipate dangerous consequences of failures
(2) monitor failures and their consequences, and
(3) lessen the likelihood of failures that might cause harm and take appropriate actions.
Designer agrees that prior to using or distributing any applications that include FocusLCDs products, Designer will thoroughly test such applications and the functionality of such FocusLCDs products as used in such applications.