It's a funny old world sometimes. The MIPI (Mobile Industry Processor Interface) was formed by a consortium of companies in 2003. The goal of MIPI (mipi.org) is to define a suite of interfaces for use in mobile and consumer products, where these interfaces reduce cost, complexity, power consumption, and EMI while increasing bandwidth and performance. These are all great targets to be sure, which is why the use of MIPI interfaces is expanding way beyond the mobile space. These interfaces are currently appearing all over the place.
Actually, this is probably a good time to take a step back and note that the term MIPI covers a lot of things -- it's like saying Ethernet without offering any further qualification. We really need to go a level deeper. The point is that MIPI covers a wide range of standards, including BIF (a sophisticated battery interface), RFFE (designed primarily for the control of RF front-end components), and SLIMbus (targeted at replacing digital audio buses including PCM and I2S, and control buses such as I2C, SPI, and UART).
MIPI Interfaces in a Mobile Platform
The two MIPI standards of interest to us here are the Camera Serial Interface (CSI) and the Display Serial Interface (DSI). The latest versions of these interfaces -- CSI-2 and DSI -- share a common PHY (physical interface) known as the D-PHY, which has been designed so as to offer high speed with low power consumption and low EMI.
When you think about all of the products today that employ cameras and display screens, industrial control systems, vending machines, home appliances -- the list goes on -- it's easy to see why having standard interfaces is so attractive to system designers. Fifteen years ago, the PC was the dominant architecture, so everyone was using PC-based components and subsystems to reduce costs and increase reliability. Today, smartphones and tablets represent the dominant architecture -- an architecture that employs the CSI-2 and DSI interfaces -- which explains why components and subsystems using these interfaces are finding their way into a vast array of application areas and products.
The problem is that we are still in transition. Some components and subsystems support the CSI-2 and DSI interfaces, while others still use alternative standards. This explains today's announcement from Lattice Semiconductor about a new suite of FPGA-based reference designs for MIPI DSI and CSI-2 (transmit and receive), which will help designers overcome the challenges of integrating camera and display capabilities in their systems.
Let's consider some example applications. One obvious scenario is where the designer wishes to use an application processor (Snapdragon, OMAP, Tegra, etc.) that supports the DSI display interface, but the application in question requires a larger display, such as a 7:1 LVDS display (certain applications might require two 7:1 interfaces, each running at 77.5MHz). In such a case, a Lattice MachXO2 FPGA, for example, could be used to implement a DSI to LVDS (i.e., DSI RX) bridge:
DSI to LVDS bridge.
An alternative scenario might involve an embedded processor that generates an RGB/LVDS output, but the designer wishes to employ a DSI-enabled display device. In this case, a Lattice MachXO2 FPGA could be used to implement an RGB/LVDS to DSI bridge:
RGB/LVDS to DSI bridge.
In the case of camera applications, consider a dual image sensor scenario used to implement picture-in-picture processing or 3D stereoscopic imaging for gesture recognition. Today's high-end ultrabooks don’t support CSI-2 interfaces, but they do support USB-3.0. Once again, a Lattice MachXO2 FPGA could be used to implement a bridging function:
Dual CSI-2 bridge.
Now, I really appreciate it when someone makes things simple for me. Many people say that I'm a simple man, which I choose to take as a complement. I really like the fact that the folks at Lattice have set up four special webpages to cover the CSI-2 TX, CSI-2 RX, DSI TX, and DSI RX use cases as follows:
The really interesting thing here is that each CSI-2 and DSI interface supports a variety of configurations (number of data lanes required, number of bits per pixel, etc.). Thus, in order to make things easy for the designer, each of the above pages features a start here button, which allows you to select the desired configuration:
It seems to me that the folks at Lattice are currently announcing something new and exciting every week. I can’t wait to see what they unveil next…