MIPI I3C v1.1 – A Conversation with Ken Foust

Q: What makes the newly released MIPI I3C® v1.1 different from v1.0, and why is it important to developers?

I see Version 1.0 as setting a new baseline. We came together to make an interface that would dramatically simplify the integration of sensors and address many of the key pain points that all of us in the industry were dealing with when working with I²C and SPI interfaces. We think we accomplished that with v1.0—anywhere sensors are used, MIPI I3C belongs. Now v1.1 is the first update to build on that foundation.

One of our original goals in launching development of MIPI I3C was to provide an upgrade path that would allow implementers to take advantage of I3C wherever I²C and SPI were being used. Those interfaces were developed a long time ago and have proliferated into several industries and several types of devices for many different use cases. Although v1.0 set the stage, there remained features needed to ensure MIPI I3C’s suitability for the very broad range of industries and use cases—such as memory management, server control and manageability, “always-on” imaging, debug communications, touchscreen and sensor device command, and power management. So, with MIPI I3C v1.1 we now have this scalable, medium-speed utility and control bus that can connect peripherals to an application processor in everything from smartphones and wearables, to high-performance servers, automotive applications and more. Some of these applications weren’t even originally envisioned when we started creating MIPI I3C. This ongoing move beyond mobile and sensing was our focus in the development of v1.1.
 

Q: What are the new features that users will be most interested in?

By supporting v1.1’s new HDR-BT mode, which is an even more efficient double data rate transport, MIPI I3C can be operated over multiple lanes. So now, instead of topping out around 25 Mbps, you can get close to 100 Mbps just simply by adding additional lanes for the various supported data transport modes. If you want to get more speed, you don't need more advanced GPIOs (general purpose input/outputs), more advanced protocols or faster timing. Rather, you can double the speed by extending from two wires to three wires. The incumbent interfaces were not natively designed with any concept of this multi-lane use.

In addition to HDR-BT and multi-lane, there's another set of features—such as grouped addressing, enhanced error detection/recovery, slave reset, comprehensive flow control, outsider end transfer and new CCC (common command code) capabilities—that enable MIPI I3C to be used in new ways. It puts in place the mechanisms by which resiliency and reliability can be better taken into account for a MIPI I3C-based system.

Some of the pain points we're addressing in v1.1—such as a standardized reset capability and load control—represent a lot of the additional work that implementers historically have had to do to get I²C to function.

All of these options are backward compatible, too. For these reasons, we believe that MIPI I3C v1.1 adds the remaining features needed for I²C and SPI implementers to move to I3C.

Q: What are the market drivers for I²C and SPI implementers to make that switch with v1.1?

As previously mentioned, the first is simply the need for speed. By providing for extensible use of HDR modes and extra bus lanes to increase data rates to near 100 Mbps, we are delivering a dramatic rate bump and future-proofing the interface for rising speed requirements. And yet, it's still very simple to implement and very simple to use.

Other implementers may choose to move to MIPI I3C v1.1 because the I²C ecosystem is quite fragmented; no one really owns it, and it’s not formally “interop-ed.” You don't completely know that your I²C implementation will work with another I²C implementation. With MIPI I3C, you get a well-supported ecosystem that’s rooted in interoperability.

Q: What’s next for the working group?

Part of our responsibility is to ensure that MIPI I3C maintains a relevant feature set and scope, and we are already ramping up discussion around the next evolution of MIPI I3C. The working group will be looking at a range of new capabilities for the interface—longer reach, various improvements, automotive requirements, speed increases, new multi-lane uses, standardized connectors and other feature refinements, among them. Plus, as always, we will continue to reach out to industry partners and form liaisons to ensure the broad, ongoing relevance of MIPI I3C’s feature set and scope.

I invite companies to participate in what has become a vibrant and growing ecosystem through our interoperability workshops and development activities.

Q: What resources exist for developers and others who want to learn more about the I3C ecosystem?

A number of resources exist to support I3C v1.0, and FAQs, an Application Note, and a Conformance Test Suite (CTS), currently are being developed to include v1.1.

MIPI will host a webinar on 12 February 2020, at 8 am Pacific, to further explore the features and benefits of MIPI I3C v1.1 and provide an update on the I3C ecosystem. To register, please click here.

Ken Foust is a principal engineer at Intel Corporation, where he leads wired/wireless interconnect and sensing R&D initiatives within Intel Labs. In this capacity, he also works closely with standards bodies such as MIPI Alliance, for which he serves as the chair of the I3C Working Group. Ken has been recognized with the MIPI Alliance Distinguished Service Award and as a Sensors Expo Engineer of the Year, and he is a member of the MSIG Technical Advisory Committee and Hall of Fame.