The proliferation of sensors in mobile devices requires an increasing number of logic pins for sensor communication and control. In a typical application, multiple digital communication interfaces (e.g. SPI, I²C, UART, and others) are used along with supporting logic signals for interrupt and sleep functionalities. Top tier smartphones include 10 or more sensors, which are supported by 20 or more logic signals. This takes up a lot of “real estate” and requires many dedicated pins. The MIPI I3C interface is a new standard that improves on the features of the two-wire I²C, while maintaining backward compatibility. MIPI’s new interface aims to standardize sensor communications by reducing the number of physical pins used in sensor system integration, and it supports low-power, high-speed communications. We had an opportunity to speak with Ken Foust, who has been chairing the MIPI Alliance Sensor Working Group, and discussed the feedback from the sensors community to date, comparison to the other sensor interface standards, and next steps in the interface development roadmap.
MEMS Journal: The initial release of the I3C standardized sensor was a few weeks ago. What is the latest status?
Ken Foust: The MIPI Alliance formally released the MIPI I3C v1.0 specification on January 9, 2017, so developers can now use the interface to interconnect and manage sensors in embedded systems.
The release of MIPI I3C is a milestone because the specification unifies traditional sensor integration approaches to provide must-needed conveniences and system-level benefits for a broad range of applications. We expect its key uses to include sensor integration in smartphones, wearables, IoT devices, and automotive systems, but the specification is very versatile and can also be used to integrate sensors in medical instruments, industrial equipment, all-in-one computers, TV remotes and other products. MIPI I3C supports numerous types of sensor components and functions, from mechanical and motion sensors to transducers and actuators and to environmental, biometric and health sensors, among others. It can also be used as a power management and control interface in certain types of devices.
MEMS Journal: What is main motivation behind the I3C standard? Why is it needed?
Ken Foust: MIPI I3C was developed to solve design challenges caused by the proliferation of sensors in devices, especially in the smartphone market where as many as 10 sensors and 20 signals can be required in a handset. Smaller devices, such as smart watches, need multiple sensors as well. Further, integration requirements usually varied for each sensor and the interface market was fragmented, with I2C, SPI and UART among the many digital interfaces used by vendors. The fragmentation made it difficult to scale sensor deployments to yield design and performance efficiencies, increased development time, and ran up integration costs. Further, the available interfaces did not use power efficiently for communication with sensors, and this limited their potential uses and scalability.
MEMS Journal: What features were included in this I3C release?
Ken Foust: MIPI I3C is a chip-to-chip interface that can connect all sensors in a device to an application processor. It is implemented on a standard CMOS I/O using two wires, which drastically reduces device pin count and signal paths and facilitates incorporation of more sensors in a device. It achieves clock rates of 12.5 MHz and provides options for higher performance, high-data-rate modes.
MEMS Journal: How does the I3C standard match up against leading solutions such as I²C, SPI, or UART?
Ken Foust: MIPI I3C incorporates, consolidates and advances I2C, SPI and UART in a new approach for sensor integration. The solution is comprehensive and scalable and provides a superset of features and functionalities. MIPI I3C uses a fraction of the power while providing more than an order of magnitude the bandwidth compared to I2C.
Both I2C and SPI can interface with multiple sensors, but both approaches require out-of-band control signals to implement interrupt functionality, which increases pin count. Additionally, I2C is not practical for sending large amounts of batched data, which many smartphone applications require, and SPI has a high pin count and requires a dedicated chip select pin for each sensor.
MIPI I3C can replace both options with its two-wire interface. The specification accommodates multiple sensors on the same communication bus and eliminates the need for additional I/O pins by using in-band methods to issue interrupts or initiate sleep mode. MIPI I3C promotes always-on sensing at very low power and it enables sensors to batch data and transmit it quickly to minimize energy consumption and help preserve battery life.
Also, MIPI I3C provides synchronous and asynchronous time stamping modes to improve the accuracy of sensor-based applications over time and allow individual sensors, such as gyros and accelerometers, to work better together.
MEMS Journal: The I3C interface is compatible with I2C, but how does that work in practice? Can both I3C and I2C devices exist on the same communication bus?
Ken Foust: Yes, both devices can co-exist on a physical bus managed by an I3C Master device. The Master can operate that bus in compatible I3C transmission modes, or it could operate the bus purely in legacy mode as an I2C bus (in which case the system wouldn’t be able to take advantage of any I3C features).
The compatibility relies on a feature expected to be present in any legacy I2C device connected to the I3C bus, commonly referred to as a “spike filter” which filters out all the I3C-specific transmissions. I2C requires that compliant devices implement the 50ns filter for some of its modes, Fast-mode and Fast-mode plus, widely known as the most commonly implemented modes. (Also widely known is that some devices quietly skirt this feature.) Since all I3C traffic uses signaling that occurs in times shorter than 50 ns, legacy devices won’t know its happening.
MEMS Journal: Can you briefly describe the development process for the I3C standard?
Ken Foust: MIPI I3C was developed by the MIPI Alliance Sensor Working Group, which was formed in 2013. Its mission was to design a core technology that would give developers unprecedented potential to design new products, find broad market acceptance, and help companies cost-effectively meet their sensor integration needs.
From the outset, the organization wanted to ensure that MIPI I3C would find broad market acceptance and help companies across the mobile and sensor ecosystems cost-effectively meet their sensor integration needs. It developed MIPI I3C with input and collaboration of the sensor industry to ensure the specification would support as many use cases and sensor classifications as possible. The working group collaborated with the MEMS and Sensors Industry Group (MSIG) to survey both organizations’ members to assess sensor interface requirements and industry technology gaps that traditional sensor interfaces did not address.
Once the market needs were established, development of the interface was a communal effort. Multiple proposals were considered and technically evaluated, and the findings were used to craft a specification that satisfies a broad range of applications for smartphones and beyond.
MEMS Journal: How will the I3C standard be rolled out (e.g. design blocks from IP providers)?
Ken Foust: MIPI member companies will undertake this themselves, and several companies have already announced IP they hope to license to other companies.
MEMS Journal: What are your thoughts on the market adoption of the I3C standard?
Ken Foust: We are very enthusiastic and believe MIPI I3C will see near-term adoption, and as adoption continues over the longer term, pure I3C-bus implementations will become prevalent and eventually supplant the legacy buses. I3C has already driven new membership -- interest both inside and outside the mobile-centric industry is high, as we’ve seen through joint activities of MIPI and MSIG, in other forums, and through high participation in the MIPI Developer Conference held in September 2016.
MEMS Journal: Since the detailed I3C specification is only available to MIPI Alliance members, how can other non-members use this standard?
Ken Foust: To access the specification, someone needs to be an employee or eligible contractor (i.e., those having agreed to non-disclosure terms) of one of the MIPI Alliance’s member companies. Membership not only provides access to specifications, it includes a license to implement I3C as a benefit of membership.
MEMS Journal: What are the main shortcomings of the I3C standard?
Ken Foust: Focusing on backward compatibility was an exercise in compromise -- if we had abandoned that compatibility, a variety of interesting features would be possible. Discussion will continue inside the MIPI Alliance Sensor Working Group as the market evolves to ensure we have the right balance of innovation and legacy support over the long term.
MEMS Journal: What types of situations would I3C not be the best interface to use?
Ken Foust: MIPI I3C may not be the best interface for the following three scenarios: 1) when bandwidth requirements exceed the maximum available in MIPI I3C (~33 Mbit/s), 2) when extremely long interconnects are required (we expect companies will still use MIPI I3C in quite a few of these cases through the use of "repeaters" that create a long link out of a combination of shorter ones), and 3) MIPI I3C can support devices that seek to stream data within the bandwidth it offers, and system designers can be smart in creating a bus that won't unexpectedly steal that bandwidth from those streaming. but in general it is not an ideal fit for streaming use cases (e.g., audio, where MIPI SoundWire is usually a better fit, or capturing high-frame rate/hi-res video where MIPI CSI-2 is preferred).
MEMS Journal: Are there any features that have been left out of the current release that could be potential future upgrades?
Ken Foust: Yes, that discussion is actually occurring right now in the Sensor Working Group. As the group reaches agreement on the feature set, it will follow our normal process to propose and define the next release, something we expect to occur over the next few months, resulting in a plan for further development. The group will prioritize forward and backward compatibility as v1.0 adoption grows to limit disruptions in the market.
Some features previously discussed in public forums but deferred until after the release of v1.0 are likely candidates for an upgrade, such as peer-to-peer communication, if the group has confidence forward/backward compatibility will be maintained.
MEMS Journal: Who are the companies behind the development of the I3C standard and how have they been contributing?
Ken Foust: Companies participating in the working group represented a strong cross section of sensor, component and chipset manufacturers, software firms, and device manufacturers. These members include Advanced Micro Devices, Analogix Semiconductor, Cadence Design Systems, Google, Intel, Knowles Electronics, Lattice Semiconductor, MediaTek, NXP Semiconductor, Qualcomm, QuickLogic, Sony, STMicroelectronics, Synopsys, and others.
MEMS Journal: What is the level of interest so far for the I3C standard in the sensor community, system integrators, and OEMs?
Ken Foust: Interest is high, as indicated by a greater-than-normal pace of new member inquiries and activity, including some significant companies that have joined in the past couple of months. While we cannot point to particular companies’ activities and preempt their market launch activities, we do suggest reaching out to individual companies for responses.
*********************************************
This article is a part of MEMS Journal's ongoing market research project in the area of sensor hubs and sensor fusion architecture. If you would like to receive our comprehensive market research report on this topic, please contact Dr. Mike Pinelis at [email protected] for more information about rates and report contents.
Copyright 2017 MEMS Journal, Inc.
Comments