MIPI in the Car – Transport From Sensors to Compute

I’ve written on and off about sensors, ML inference of the output of those sensors and the application of both in modern cars. Neither ADAS nor autonomous/semi-autonomous driving would be possible without these. But until now I have never covered the transport between sensors and the compute that safely turns what they produce into clear images and accurate object detection. Mixel and Rambus recently gave a talk on that transport, MIPI, at MIPI DevCon. Useful, since I had previously assumed that the data somehow magicked its way from the sensor to the compute. The example focused particularly on imaging subsystems, in this talk featuring the camera-serial interface (MIPI CSI-2) from Rambus and the physical interface (MIPI C-PHY and MIPI D-PHY) from Mixel.

MIPI CSI-2 and PHY transmit and receive blocks

MIPI CSI-2 is the function which defines a serial interface between a camera on one end and an ISP on the other end. Pixels stream in one side and eventually stream out the other side, so the interface needs a transmit function and a receive function. Because these functions must be able to connect any camera (or more than one camera) to any ISP, they need a lot of flexibility. One example is bandwidth matching between the sensor and the ultimate consumer, allowing for a continuous streaming flow for example.

Between the CSI-2 transmit and receive functions, D-PHY (or C-PHY) handle the physical communication. D-PHY uses differential signaling while C-PHY uses a clever differential technique looking pairwise at a trio of signals, together with encoding. Complex stuff but apparently supports a higher data rate than D-PHY.

Safety in the PHY

Back in more familiar territory for me, these IPs are designed for automotive applications, making safety a critical objective. Both the PHY and controller must meet the ISO 26262 FMEDA requirements for the appropriate ASIL level. In addition, safety critical automotive applications require in-system testability for the MIPI PHY. I’m seeing similar in-system testability requirements becoming more common at ASIL-C/D levels for other PHYs, so this is not a surprise. The Mixel MIPI PHY supports full-speed and in-system loopback testing for the universal configuration (Tx+Rx) as well as with their own implementations for area optimized transmit only and receive only configurations called TX+ and RX+.

Mixel also noted additional testing required for automotive IP: stress testing, HTOL and reliability tests (e.g. aging). These, together with meeting the ISO 26262 standard DFMEA and FMEDA. Ensuring the overall reliability of the IP,  essential for car safety over a 15+ year service life.

Safety in the CSI-2 controller

To meet ASIL-B fault coverage requirements Rambus’s CSI-2 Controller Core with Built-In-Self-Test (BIST). BIST mechanisms are used here together with familiar safety mitigation techniques: ECC, CRC, parity. It is interesting to note that the BIST here is at the IP level, not at the system level. I have seen the same principle for in-system testing in the NoC. In both cases, the argument is that function level BIST is better than system level for multiple reasons. It can go deeper and provide more confidence in safety coverage. It is also available even if system-level BIST is not provided, offering central feedback if the system becomes non-operational.

In safety mitigation techniques, the CSI-2 controller provides parity protection on pixels and pixel buffers. Also ECC for the protocol header and CRC for packet data. These add redundancy for data formatting, packing logic, critical state machines and other critical blocks. Packet ordering is checked, and order errors are flagged. One other interesting check I have seen coming up more in safety critical applications is a watchdog timer. This is to detect frozen or excessively delayed operations. All emphasizing that at high ASIL levels, safety mitigation is no longer just about the basic methods. Designers are adding more active and complex tests and mitigations to rise to ASIL-C/D.

This talk can be found HERE and is a good introduction to the topic.

If you would like to learn more information about Mixel and their MIPI offering, visit their website here or learn about their MIPI D-PHY IP here.

Also Read:

A MIPI CSI-2/MIPI D-PHY Solution for AI Edge Devices

FD-SOI Offers Refreshing Performance and Flexibility for Mobile Applications

New Processor Helps Move Inference to the Edge