MIPI’s Focus Widens

Ashraf Takla, president and CEO of Mixel, sat down with Semiconductor Engineering to talk about the evolution of MIPI, from mobile displays to automotive, chiplets, and how the standard is evolving to keep up with increasing data volumes.

SE: There has been a lot of activity around MIPI in automotive. What’s driving that?

Takla: One of the early use-cases for MIPI, after Mobile has been automotive, starting about 10 years ago. But it’s certainly reinvigorated now. There is more penetration into that market. In every segment that involves automotive, including infotainment, and mission-critical use-cases, it’s getting more challenging and more complicated. There are a lot more requirements.

SE: Haven’t there have been significant changes in MIPI, too?

Takla: Obviously I don’t speak for the MIPI Alliance and can only comment on things from Mixel’s perspective. One of the biggest things we’ve seen with MIPI PHYs is how the C-PHY took off. It’s becoming more popular. The D-PHY was the first MIPI PHY, and the subsequent one was the M-PHY, which was supposed to supersede the D-PHY. But C-PHY came along pretty much out of left field. No one expected it, and at the beginning nobody really wanted to support it because we did not expect it to increase the size of the pie. It was just slicing the pie into smaller slices. We were reluctant to support it at the beginning, too, but then we started to see some customers requesting it. We were the first IP company to have it silicon-proven. And in the last three years, a lot of our business has migrated to a C-PHY/D-PHY combo. There is also the A-PHY.

Fig. 1: Typical use of MIPI physical and protocol layer specifications within a hypothetical, generic IoT device with wireless connectivity. Source: MIPI Alliance

Fig. 2: MIPI Alliance specifications are used to interface chipsets and peripherals in mobile-connected devices. In the mobile industry, these are used in smartphones, tablets, laptops, and hybrid devices. Since it was founded in 2003, the Alliance has developed more than 50 specifications. Source: MIPI Alliance

SE: Because this started in the mobile industry, a lot of the chips using this technology are quite advanced, right?

Takla: Yes, we have been doing 5nm for a few years, and 3nm is next. That said, on the camera and display side the technology tends to be less advanced, currently at 22nm or higher.

SE: Do chiplets enter into this picture?

Takla: It’s certainly something that can be very beneficial and a very good fit for us. There are two tracks for chiplets. One is an IP company creating chiplet IP, compliant with one of the emerging chiplet interface standards such as UCIe. The other is converting a chip to chiplet. For the C-PHY/D-PHY combo, many companies acquire hundreds or thousands of these. Equipment companies, for example, need to test C-PHY but they don’t have an FPGA solution or some way to implement that on the tester side. So, they buy these chips for that purpose. We’re already selling our test chips at low-volume, and at the right time it makes sense to turn some of these into chiplets.

SE: What was the genesis of MIPI?

Takla: It started as a processor interface for the mobile phone. But quite a few years ago it became obvious that it’s being widely adopted beyond mobile, such as IoT, automotive, AR/VR/XR, industrial, medical, and others.

SE: How much of an issue is security for MIPI?

Takla: It is extremely important, depending on the use case. You don’t want your car to be hijacked remotely. There is a security committee within the MIPI Alliance focused on that. It was formed a few years ago and a lot of activities are taking place there. This is done at higher level on top of the PHY and controller. It’s an important piece of the ecosystem. On the PHY and the controller level we focus more on testability, including in-system testability and diagnostics. This also is something everybody’s trying to figure out within the chiplet context.

SE: There’s also a need for monitoring degradation between chiplets and any errors, as well as security. Where does MIPI fit into this?

Takla: Testability, diagnostics, and security are all important for automotive and chiplets. Of course, MIPI standards support error correction, depending on the use case. Those features enable monitoring degradation and errors at the appropriate level of the hierarchy.

SE: How much re-use is there with your IP?

Takla: We add a lot of programmability and modularity into our IP. Everything is built like LEGOs. We call this a Legorithmic approach. That modularity is built into the methodology, schematic, layout, testability, and architecture. That’s what we do to make our blocks reusable. And then we build the IP itself to maximize our ability to sell it to many customers. The challenge is how to do this and still have better PPA. We have very wide coverage of the different nodes and foundries. From the customer perspective, it’s a balance between IP that is silicon-proven and IP that can be differentiated. In some cases, that requires some customization of the IP. But the key is to listen to your customers very intently and act upon that. In many cases, that leads to better-performing IP.

SE: Once IP is hardened into chiplets, can it still be re-used as easily?

Takla: First, it doesn’t make sense to have many chiplets that are similar to each other. Maybe you would have a transmitter CD-PHY as a chiplet, but you also can add programmability into it, such as how many lanes are needed. Is it CSI (camera serial interface) or DSI (display serial interface)? So just like it’s programmed into the IP, maybe you can build even more programmability on top of that. On one level, chiplets aren’t that different from the IP business. Everyone is trying to re-use IP and do things in a way that they don’t have to customize it as much, and for chiplets that will be even more important.

SE: A lot of the MIPI focus is on image sensors. What’s changing there?

Takla: Yes, MIPI is widely adopted wherever there is a camera or the display, and the camera is the bigger of the two. But that doesn’t necessarily mean all of our IP is connected to the sensor or inside the sensor or the display. In a lot of cases it’s inside the main processor or an auxiliary process, such as an ISP or geometrical processor. So there are many different things that sit between the display and the sensor that do different functions. Of course, the data rates needed to support the advanced cameras and displays keep going up, and the MIPI standards are always evolving to enable that.

SE: Does that make it easier to penetrate markets like automotive or other markets with stringent specifications?

Takla: As MIPI went beyond mobile, the standard has started to take into consideration other applications. So the error bit rates change because the environment is harsher, for example. Now, as IP is used in those more demanding applications, we have to worry about a whole lot more than that. The temperature levels are higher, and the failure rates need to be much lower than mobile applications. The product lifetime is much different, too. For a mobile phone it may be 3 years. For automotive, it may be 10 or 15 years. Companies that play in that market are very demanding, because if a chip gets recalled that’s a huge deal.

SE: So now do you have to start thinking about safety and resilience in your IP?

Takla: Absolutely. That’s what ISO 26262 is for. It’s a whole different domain that we had to learn. We needed to understand how that affects the hard macro of the PHY and the soft macro of the PHY. From a hard macro standpoint, it’s about testability, diagnostics, and in some cases redundancy. We have an automotive customer that a long time ago had very specific concerns about the testability features they want us to implement, and that resulted in a Mixel proprietary implementation that we patented. With a hard macro we are not doing scans. We are doing many types of loopbacks, and those kinds of things. On the RTL side, it’s different for different failure modes. There’s scan and redundancy. Our team had to undergo training and basically become qualified certified practitioners. It took us three years to become fully certified. And then, on top of that, you need to learn more and more about the customer-specific requirements. It’s a huge discipline, and we have experts for that.

SE: That sounds like a huge investment.

Takla: It is, but it’s also a huge investment for the whole ecosystem.

SE: One of the challenges facing the chip industry is the growing volume of data. How is that impacting you?

Takla: The introduction of the C-PHY was a result of that because you can achieve a higher data rate at the same symbol rate. And the standards is evolving to deal with that. There are always next generations of D-PHY, C-PHY, M-PHY, and A-PHY. So it’s constant evolution, and the MIPI Alliance has done a really good job of staying ahead of the curve. We don’t usually hear customers complaining about the latest standard not being fast enough. What we do hear is, ‘Are you supporting this latest standard?’

Fig. 3: C-PHY TX eye diagram. [1,2] Source: Mixel

SE: Is that all based on compression, or is it something else?

Takla: Compression comes into the picture on the display side, where you have a lot of redundancy. But the symbol rate also increases generation to generation, and on top of that, it’s how many bits you pack into a symbol.

References
[1] A symbol represents a transition between two wire states, according to the MIPI Alliance. The C-PHY uses a three-phase symbol with an embedded clock. More information can be found here.
[2] Demystifying MIPI C-PHY / D-PHY Subsystem. More information can be found here.