Interestingly, these connectivity requirements are almost the same as those seen in the most ubiquitous mobile platform – the smartphone. In a smartphone, you have similar interactions between cameras and display, audio, microphone, and gyroscopic, magnetic and light functions, and applications requiring touch or voice-activated inputs. The MIPI specifications that define these interfaces efficiently for smartphones work equally well in the interfaces developed to support these systems in automobiles. And they are being deployed today.

Let’s dive deeper into ADAS and see how MIPI specifications are applied.  Driver-assist systems are developed to automate, adapt, and enhance vehicle systems for safety and to help the driver drive better. Figure 1 shows a “field of view” representation of ADAS-type monitoring. These systems make up a kind of sensor “shield” around a car providing alerts to the driver or triggering safeguards that take over control of the vehicle to avoid hazards.

As seen in Figure 1, there are a growing number of sensor-based systems using a variety of sensing technologies. Some of these systems do not transfer large amounts of data; they are sensor detect and alert type transfers of minimal data. However, other systems are capturing large amounts of data in order to handle the transfers efficiently. For example, a camera assist system used for lane detection or traffic sign recognition creates a dense data stream that needs to be transmitted from the camera to a processor for analysis and to a display for viewing. In systems like these, the MIPI Camera Serial Interface (CSI^SM) provides a protocol framework to pass data from the camera to the processor. The actual transmission is accomplished by using another MIPI specification, MIPI D-PHY^SM, which is a physical layer transceiver specification. Using MIPI D-PHY means that the interface will operate at the lowest power and deploy at a minimal cost. MIPI Alliance develops specifications with flexible architectural definitions, recognizing that targeted implementations are necessary to realize an optimal combination of physical pins and transfer rates.

Figure 2 is one example of a targeted implementation; a simplified diagram of the camera-to-processor connection. The camera sub-assembly has the camera sensor and supporting circuitry for image capture and for organizing the image data for transmission using a D-PHY Tx macro. The camera image is serialized and sent across to an Image Signal Processing sub-assembly containing the supporting circuitry for receiving the data – a D-PHY Rx macro. The physical connection between the Tx and Rx side is made using a MIPI interface. NXP designed such a system using the MIPI CSI-2^SM specification and a D-PHY hard macro provided by Mixel.

NXP Utilizing Mixel’s MIPI D-PHY

The NXP design that utilizes the MIPI interface is called the S32V234, as shown in Figure 3 (see upper left-hand corner). The S32V is an ADAS solution for vision, sensor fusion and surround view applications. It features a quad-core ARM^® Cortex®-A53 processor, the NXP APEX^™ Image Cognition Processor, Vivante GC3000 Processing Unit, and an advanced memory bus system architecture. The system is designed to interface with a variety of image sensors, like the Sony IMX224. That sensor has a MIPI CSI-2 interface for linking the sensor to a system-level chip like the SV32. The MIPI CSI-2 interfaces have a maximum output data rate of 1.5 Gbps/lane, and the number of output channels can be selected from 1ch, 2ch or 4ch (lanes).

A key part of this system is the transfer of the raw image data to the SV32 built-in image signal processor (ISP) with low or zero latency. The raw data is the processed efficiently using an advanced high-performance SRAM system that compliments the tradition DDR memory management making the image processing in real time. The raw data transfer from the Camera to the S32V is accomplished via a MIPI CSI-2, D-PHY interface and received by the Rx D-PHY hard macro. The data is serialized and transferred at a high speed to allow flicker free processing.

Mixel’s MIPI D-PHY in the NXP Product

Mixel provided the D-PHY IP Rx⁺ hard macro for the NXP design. This macro is optimized as a receive-side custom implementation that efficiently fronts the CSI-2 interface in the system-level chip—the S32V. It’s noteworthy that the MIPI D-PHY specification defines a universal form of the D-PHY with symmetrical Tx and Rx capabilities. In Mixel’s implementation, the receive side is targeted and the lanes are optimized to align with the major transfer direction from the camera to the S32V. The block diagram of the Mixel D-PHY Rx⁺ is shown in Figure 4. A key feature in the Rx⁺ is the area optimized Tx side. Adding a minimally invasive Tx adds loopback support and eases the set up required in a post silicon production test. Not only do you get performance and power, but silicon testability as a result of this special implementation.

Mixel’s D-PHY Rx⁺ follows the MIPI D-PHY specification but adds this important custom option. Note that the MIPI Alliance defines its specifications to allow optimizations during implementation. In this way, customers and vendors can work within the pinlimit constraints and data rate transfer requirements of the system, optimizing for power and efficiency, and in this case, also testability.

Safety and Reliability

Certainly, operational reliability and robustness are fundamental to the parts used in automobiles. Because ADAS features are mission critical for making us safer as we drive, safety standards are essential. But even non-critical systems must operate reliably across a wide, and often severe, range of environmental conditions. Suppliers to the auto industry, and the suppliers to those suppliers, must meet standards like AEC-Q100, which establishes common electrical component qualification requirements for ICs, IEC 61508, intended to be a basic functional safety standard applicable to all kinds of industries, and ISO 26262, which establishes standards for functional safety of electrical and/or electronic systems in production automobiles. In this case, Mixel, as a supplier of IP to NXP, designs its MIPI IP with reliability and robust operation from the start, and then does the extra work to make sure the IP meets these standards. For example, Mixel’s D-PHY meets the AEC-Q100 Grade 0 specification. Validating the design requires extensive use of statistical simulations incorporating aging effects and temperature variation. Mixel varies the critical parameters in a normal distribution running simulations so each device variance is accounted for.  The design target is to perform within a six sigma range. Such simulations require careful planning such that the performance becomes predictable within the expected tolerances of the D-PHY‘s operating environment. The performance is further validated with extensive testing and characterization done, both by Mixel, and by NXP. The extra effort results in reliable and safe system operation.

Using MIPI in Radar, Lidar, and Beyond

As suppliers move to extend ADAS in the direction of autonomous driving, MIPI specifications will continue to evolve and deploy where they fit.

Radar (millimeter wave radio) and Lidar (light) sensor subsystems also require the transfer of large amounts of data. These systems can use MIPI interfaces to transmit data from the Analog Front End connected to ADC/Baseband and signal processing components or directly to the system-level fusion processing systems where appropriate action can be initiated. In applications like adaptive cruise control, the MIPI CSI-2 interface fits perfectly to connect the RF front end to the radar processor (for example, the NXP S32R27, which uses Mixel MIPI D-PHY to connect to NXP RF front end devices like the MR3003). Here, continuous burst transmissions need to be analyzed, to detect objects and judge vehicle-to-vehicle relative speeds, and ultimately to adjust the throttle. These are high bandwidth data transfers with multiple arrays of analog to digital converters (ADCs) to support data collected from long and short-range transmissions. Whether the sensors use sight or light, MIPI interfaces continue to be deployed inside the automobile sensor modules supporting these critical data transfers.

MIPI member companies like NXP and Mixel continue to deploy MIPI specification interfaces, both in system-level designs and as IP. Other MIPI member companies are deploying these interfaces where they fit in automobiles and other systems as well. This is taking place anywhere that can benefit from interfaces defined for efficiency and performance. The flexibility that the MIPI Alliance has built into their specification definitions allows vendors and customers to develop interfaces optimized to each application. This “perfect fit” of application requirement to interface architecture is serving the emerging auto industry in much the same way that it has served and continues to serve the mobile smartphone market. The auto industry continues to enhance the systems that will make a car operate more like a mobile device.  We are moving closer to enjoying fast, safe, informative and entertaining driving, free of stress. Our cars have more systems that need MIPI Alliance’s performance and power optimized interfaces. The MIPI Alliance and its member companies continue to deploy the systems interfaces that will transform your car into an autonomous mobile device for the benefit of us all.

To learn more about Mixel’s silicon-proven IP, please visit mixel.com/ip-cores or Mixel’s contact page.