MIPI-DSI LCD with Zynq
01 - Introduction
MIPI-DSI is the 'latest' standard of mobile display, with highest bandwidth and low power consumption, it was quickly adopted by nearly every hardware vendors. Recently I discovered some really cheap DSI display modules, and decided to drive them the hard way by using a Zynq-7000 SoC.
02 - Protocol Specifications
The MIPI Alliance has kept their little secrets for years, exclusive to their organization members. The documentation provided by Xilinx and LCD manufacturers, however, gave me some basic clue of the specification of these mysterious standards.
D-PHY
MIPI D-PHY is the standard way which link layer protocols such as CSI-2 or DSI communicate with peripherals. A typical D-PHY transmitter or receiver has the following parts:
- PPI interface
- High Speed (HS) mode transmitter or receiver
- Low Power (LP) mode transmitter or receiver
The PPI interface is used to communicate with controllers, which provides control and data interface for the phy layer, known as the protocol side. The D-PHY also has one clock lane and one or more data lanes, each lane has a pair of HS and LP transmitters and/or receivers, which provide data and clock signals. Data lane 0 also has the capability of bus turn-around for bi-directional communication.
The figure above describes the structure of the functionality of D-PHY, note the difference between HS and LP electric characteristics. HS transceivers use an differential IO standard called SLVS400, standardized by JEDEC many years ago, while LP transceivers use single-ended 1.2V LVCMOS drivers.
During initialization, all lanes are in LP stop mode, to make life easier, they provided a state-code system to describe the different lane states, listed below:
To enter High-Speed Data Transmission (HSDT) mode, the following steps are required:
- Enter High-Speed Clock Mode (HSCM)
- Follow the HS request sequence to enter HSDT mode.
MIPI-DSI
The MIPI-DSI works on top of the D-PHY, provides the command and video interfaces to the host processor. There are two modes defined by the DSI specification, and panel manufacturers can select either or both modes to support.
- Command Mode
- Video Mode
DSI host communicate with panel with a packet based format, transmitted either on HS or LP mode, some packet types only support one mode. DSI packet has two formats, either the short packet (SPa) or the long packet (LPa), depending the length of the DS I command and parameters. Short packets can contain fixed two bytes of payload, and long packets can have maximum of 65536 bytes of payload. When multiple lanes are used, data is distributed as bytes to all data lanes. An example of a HSDT transfer are shown below, captured by DSLogic, with the lowest 40MHz clock...
In HSDT mode, the data samples on each change of the clock lane(DDR clock), with LSBit shifting out first. The type of the packet is determined by the first byte of the packet, called Data Identification (DI). DI also has a Virtual Channel (VC) field, making lane sharing possible with maximum of 4 devices. However, display modules are only support VC 0. The last byte is a ECC byte calculated from the first 3 bytes. For example, the above packet has DI value 0x05, as a DCS short write command. The second packet is a special packet called End of Transmission Packet (EoTp), indicates the end of current transmission.
DCS
In DSI command mode, the host communicates with the peripheral by using different commands, including Display Command Set (DCS). If you have experience playing with some LCD or OLED display modules, you will find out that no matter which interface are used, some initialization sequence must be written to the module before it can function normally. These sequence contain the necessary drive voltage and clock settings, the type of the panel, the internal memory layout and many other parameters. For 4-line SPI or DBI(8080/6800 MCU interface) interfaces, commands are written by using a special signal called D/CX, which indicates the data currently being transmitted is a command or data. On MIPI-DSI, this is replaced with a command called DCS. Vendor specific command can be wrapped inside DCS packets, so the panel initialization process can be carried out by host.
Video Mode
Apart from traditional command based operations, DSI specification also has a Video Mode. In video mode, the host manage the display timing by sending out a stream of packets containing synchronization information and image data, then the display can retrive HSync/VSync/Blanking signal from these packets just like DPI(RGB panel interface) does. Video mode is capable of high bandwidth and smooth video, while some controllers without internal graphics RAM only supports this mode.
03 - The Hardware
As mentioned above, MIPI D-PHY needs two IO standards working on the same lane, in order to achieve the AC characteristics by FPGA only, we needs some sort of emulation. Luckily, Xilinx provided with an AppNote describing a low-cost way of emulating D-PHY by using FPGA IO and resistors (XAPP894).
This design utilizing four IOs, two for LP mode and one diff pair for HS mode. the resistor network is designed to shift LVCMOS18 to 1.2V standard for LP mode and shift HSTL_1_18 to SLVS400 for HS mode.
The board I planned to use is a Zynq-7020 board produced by QMTech, with the shunt resistors removed, external VCCO power can be provided by 2.54mm headers (Not every Zynq board has that) . I implemented the transmitter on a PCB, with power supplies for IOBANK and LCD, as well as the most common RaspberryPi compatible FPC socket. The impedance requirement for D-PHY is 100Ω differential and 50Ω single ended.
04 - Block Design
I planned to use the MIPI-DSI subsystem provided by Xilinx for free in Vivado 2020.2, So the standard video pipeline looks like the following.
The key components of the design are:
- AXI Video Framebuffer Read
- MIPI-DSI Tx Subsystem
As this LCD controller (NovaTek NT35516) does not support command in HSDT mode, since Xilinx IP does not support Low Power Data Transmission (LPDT) either, I had to add an AXI GPIO and some glue logic to take over the bus for my bit-bang LPDT implementation.
05 - Software
The software part is quite routine, initialize a framebuffer in DDR, configure AXI framebuffer read IP to read from it and send the pixels through AXI Stream to MIPI DSI subsystem. Also, I implemented a bit-bang LPDT driver for the initialization process.
After everything wired up and initialization code ran, I could see some garbage data on the screen, which proven the setup works. I also wrote some bitmap by using xsct
command line tool to the framebuffer, the results are as follows.
mwr -bin -file ${BITMAP_FILE}.bin 0x${FRAMEBUFFER_ADDR} ${WORDCOUNT}
This LCD I used is a AUO panel with NT35516 controller, with resolution of 960x540@8bpp. The timing for video mode requires more elaborated calculation, as described by the MIPI DSI Tx subsystem documentation (PG238).
The timing information I used:
- Lane rate: 500Mb/s x2
- HActive: 540 * 3(24bits), VActive: 960, frame rate 60Hz
After calculation described by the documentation, the final timing looks like:
XDsi_VideoTiming timing = {
.HActive = 540 * 3,
.HFrontPorch = 83,
.HBackPorch = 360,
.HSyncWidth = 7,
.VActive = 960,
.VFrontPorch = 15,
.VBackPorch = 15,
.VSyncWidth = 10,
.BLLPBurst = 0,
};
06 - Misc
- After probing around with my oscilloscope, I found that the signal integrity is heavily influenced by my probe.
- LP mode requires 50-75ns period, however my 200ns bit-bang IO works just fine.
- Some controller manufacturers will have HSDT capable commands listed in the datasheets, however NovaTek is not one of them. It created lots of confusion during debugging.
- RaspberryPi DSI display is a joke, they used DPI panel with DSI-DPI bridge, no initialization required.
07 - References
Software code repository: