After 35 years of I2C, I3C Improves Capability and Performance



Long overdue for MCU sensors, MIPI I3C aims at historical I2C and SPI applications, offering critical improvements for burgeoning IoT in the nick of time.

Like a well-loved and utterly worn out teddy bear, the Inter-Integrated Circuit (I2C or I2C) interface is still comfortingly useful if an MCU runs short on I/O when implementing a quick project. At times, general purpose input and output (GPIO) pins have been stretched due to an excess of new sensors that arrived well after I2C. I2C was introduced in 1982 by Philips (now NXP) as a means for MCUs to talk to I/O over a simple serial communications bus. Although it can theoretically connect up to 127 devices with 2 wires and ground, I2C is nowhere near an interface like USB; but that isn’t its purpose. I2C was simple to use, flexible, and became everyone’s backup plan to reduce pin count. Technology continued to evolve around I2C, with the result of using I2C “at your own risk,” with the occasional address collision as two devices claimed the same address on an I2C bus. Developers found workarounds but planned for extra time for troubleshooting on I2C when encountering an overloaded I2C bus, undisciplined I2C implementations, or chips that held the bus hostage with long sessions while masters waited for the I2C line to be released. Nevertheless, I2C has had a place for the past 35 years and is still in wide use today, although stretched to the limit and fraying around the edges.

Figure 1: The MIPI Alliance Mobile System Diagram demonstrates the complexity of mobile devices today. IoT and mobile devices have an abundance of sensors in common; the need for I3C in sensors is overdue. Source: MIPI Alliance.

Figure 1: The MIPI Alliance Mobile System Diagram demonstrates the complexity of mobile devices today. IoT and mobile devices have an abundance of sensors in common; the need for I3C in sensors is overdue. Source: MIPI Alliance.

Background
I3C stands for “Improved Inter-Integrated Circuits” (and is pronounced “Eye-three-See”). The I3C specification has been shepherded under the auspices of the MIPI Alliance. Founded in 2003, MIPI Alliance “offers a comprehensive portfolio of specifications to interface chipsets and peripherals in mobile-connected devices. The specifications can be applied to interconnect a full range of components—from the modem, antenna and application processor to the camera, display, sensors and other peripherals.”[i] The I3C specification is seen as a sensor interface for mobile, IoT, and automotive system designs.

Ken Foust, Sensor Technologist at Intel, has chaired the Sensor Working Group at MIPI Alliance since before they started I3C, and succinctly describes the effort to improve upon I2C without creating unnecessary complexity. “I3C unifies key attributes of I2C and SPI and is specially tuned to attributes commonly used for sensors. I3C improves on capability and performance while maintaining backward compatibility to I2C and its existing ecosystems,” says Foust. MIPI Alliance respects the immense installed base of I2C.

As for why I2C has survived so long, there’s much to be said in defense of simplicity. USB has become complicated, now in its 5th iteration (USB 1.0, 1.1, 2.0, 3.0 and 3.1) since USB’s plug-n-play beginning in 1996. The 24-pin USB-C connector is used to implement the latest iteration of the USB specifications (3.1, Alternate mode, and Power delivery specs). USB-C has already been “misinterpreted” by manufacturers that flood amazon.com with USB-C cables that don’t work well, or worse yet, can damage electronic devices. USB-C, in hoping to be all things to USB, Display-port, HDMI, and other communication protocols, has become overly complicated as rapidly evolving technology has pushed interfaces to the limit. There is no one-size-fits-all bus communication strategy that is also simple and easy to implement. Despite quirks, I2C is fairly easy to understand and implement, and there’s a huge amount of documentation on I2C that’s been developed over the years. I2C is to USB 3.1/USB-C as 8-bit is to 64-bit. You can do a lot with 8-bit and still understand what’s going on. At 64-bits or even 32-bits, the management of increasing capability also delivers increasing complexity and comes in layers like the OSI model.

Is I3C is struggling to maintain the lightweight persona of I2C? In an interview with Ken Foust at the recent IoT DevCon, concerns were laid to rest. As a working engineer, Foust’s technical skills are current, and he applies realism to the task of working group chair. When asked about the process of developing I3C, Foust reveals the practical nature of the MIPI Alliance in this aspect. “One thing with I3C is that we tried to be as light as possible and not heavy handed.” When prodded, Foust admits, “We’ve kept a baseline of I3C in check. It’s evolutionary, not revolutionary.”

Addressing Challenges Inherent to I2C
I2C is a low-cost multiple sensor solution with limitations in the face of today’s technology. I3C retains many of the benefits of I2C but will be able to operate in the context of modern sensors while maintaining backward compatibility to I2C and its ecosystem. Unifying some key attributes of SPI and I2C, I3C provides critical benefits in the commission of data management and transmission. Some smart sensors, in an effort to continuously gather data while sparing MCU power, collect data at the sensor and send the data only periodically, in rapidly emitted batches. I3C is better suited for these types of always-on, power-sipping sensors. I3C also permits prioritized, in-band interrupts that can notify the MCU using the standard 2-wire communication bus. Thus, when a sensor has critical data to send it does not have to wait for another chip to release the bus, accomplishing prioritization without using an additional, dedicated input pin into the MCU. Clock-stretching is not allowed, and I2C extended (10-bit) addresses are not used. I3C provides advanced power management features that can extend battery life, and implements high or low data rates without changing clock speeds. In fact, I3C provides faster data rates by running at clock speeds up to 12.5 MHz, versus the various modes of I2C at 400 kHz, 1 MHz, and 5 MHz (the latter being a unidirectional figure).

table1

Table 1: Comparison of I2C, I3C, and SPI.

Source: Introduction to the MIPI I3C Standardized Sensor Interface, MIPI.org

Security for I3C
I2C will still be around for decades, similar to the fact that 8-bit MCUs still have a place, but I3C is necessary in order to move on with something that is not as complicated as USB, but not as retro as UART or parallel ports, either. I3C is ideal for mobile and IoT; segments that hold many similarities. However, one of the questions mobile and IoT developers have about I3C is security. Foust responds, “Many people want to implement something that is simple, efficient; just a low-speed bridge physically connecting devices together. And if they want to build [security] on top of that they can. However, it’s really hard to standardize security overhead into these things, and you don’t want to inhibit I3C, or keep it from happening at all.”

Security is a concern for all developers, and I2C has none that is standardized. Peter Lefkin, Managing Director of MIPI Alliance, acknowledges that security is a fair concern, but I3C is just getting off the ground. “As a foundational first version of the [I3C] spec, it was important to create the framework and the platform, and to starting building from there.” The point is clear: security is important, but you have to start somewhere. In light of recent black hat incidents, security is on everyone’s mind. Lefkin went on to say, “We are definitely aware of concerns, as the discussion has definitely changed. The reality is that from the mobile sensor perspective, you do have to consider security. We are exploring how to go about it, and what that means for MIPI specifications and MIPI in general, not just I3C.” MIPI has a Birds of a Feather group to define embedded security considerations and invites security experts to join in the discussion. I3C cannot be everything to everyone (otherwise it would be USB), and I3C seems to be aiming at connecting sensors with less power while maintaining the simplicity of I2C. The improvement in performance, combined with the efficiency of I3C, is long overdue. Security is on the radar, however.

Maturity of I3C
In 2014, the MIPI Alliance Sensor Working Group set off to create the I3C sensor interface, starting with collaborating on a survey of MEMS Industry Group members to help identify the “pain points” experienced with I2C and SPI. By April of 2016, Synopsys delivered the industry’s first MIPI I3C compliant controller (as intellectual property) in the Synopsys Designware® MIPI I3C controller IP.[ii] Version 1.0 of the I3C specification was released in December of 2016 by the MIPI Alliance. At the March 2017 Plugfest, four companies tested four master I3C devices and six I3C slaves. Silvaco tested its Dual-Role Master, Advanced Slave core, and its Autonomous Slave core. According to Silvaco, it’s a “highly configurable core that allows customers to minimize unneeded logic” with advanced I3C features such as “hot-join dynamic address assignment.” It includes a slow clock option for ultra-low power consumption, among other features.”

 Figure 2: Plugfest June 2017 in Atlanta, Gerogia. Participants from different companies work together to test interoperability of their I3C devices. Credit: MIPI Alliance.

Figure 2: Plugfest June 2017 in Atlanta, Gerogia. Participants from different companies work together to test interoperability of their I3C devices. Credit: MIPI Alliance.

The first Plugfest participants included engineers from BitifEye Digital Test Solutions GmbH, Intel Corporation, Kionix, Inc., A ROHM Group Company, Lattice Semiconductor Corp., NXP Semiconductors, Qualcomm Incorporated, Silvaco, Inc., STMicroelectronics, Synopsys, Inc. and Tektronix, Inc. The I3C ecosystem is taking shape with some serious test and measurement equipment. “There’s test equipment and protocol analyzers. Tektronix was there with its latest oscilloscopes running the latest software, looking at I3C with the coding and analysis just like if you were working with I2C or SPI. BitifEye was there as well,” Foust states. BitifEye started in 2005 and has roots that reach back to Hewlett-Packard’s test and measurement division. BitifEye claims expertise in digital bus standards and can provide full, automated conformance test products for PCI Express®, Serial ATA, USB, HDMI®, MHL, DisplayPort, and many more.[iii] BitifEye, like Tektronix, is investing resources in I3C.

The Future of I3C
I3C clearly has momentum. Foust states, “We do have a plan to finish [the specification version] 1.1 in early 2018. First and foremost, we will be looking at how to better clarify the spec based on lessons learned from the plugfests throughout 2017. What’s interesting is that you get differing but direct interpretations of the spec, and you’re thinking, ‘We should’ve been a little clearer at this point because we have two people who took it a completely different way.’ And so, we will be working all of those points.”

The practical nature of the working group is expressed in how they approach serving their community. As Foust points out, “We’ve explored several optional capabilities that we might as well standardize on now so that someone else doesn’t build them on their own, on top of the basic I3C standard. And if it’s a superset of the baseline, which includes options that could become kind of a de facto standard, then we will look at that, as well.”  Indeed, if companies working with I3C develop a superset on the baseline standard to I3C, it could fragment nascent I3C technology. The working group has to maintain openness with participants and encourage a level of transparency at plugfests and member meetings to keep the standard from forking or forming a de facto standard that could alienate members. The formation of I3C is still young and not in danger of a coup by any means, however, it’s good to note that the chair of the Sensor Working Group is pragmatic and approachable about the developing standard.

The I3C plugfests have proven successful. Foust states that at the first Plugfest there was at least one adopter level company that showed up with apparent advanced progress. “Adopter level” means they did not have early access to the spec as contributors had. Nevertheless, they showed up well-prepared. Hezi Saar, Sr. Product Marketing Manager for Synopsys, made an observation that speaks to the progress of I3C. “Typically contributors know what they need to do to start early, [and] can take some risk in implementation. However, adopters can access the spec when it’s published and only then can they start development. So, we witnessed an early adopter in a short timeframe, having seen the spec in December 2016, and attending the first Plugfest the following March, demonstrate capabilities and how well they could interoperate. This really talks to the simplicity of implementing I3C.”

Indeed, I3C looks like it has a promising future as an evolved hybrid of I2C /SPI. After 35 years, it’s about time.


[i] “MIPI Alliance Specifications.” Specifications Overview. MIPI Alliance, Dec. 2016. Web. 26 June 2017.

[ii]Synopsys Delivers Industry’s First MIPI I3C IP for Sensor Connectivity Targeting IoT and Automotive Applications.” Synopsys. PRNewswire, 26 Apr. 2016. Web. 30 June 2017.

[iii] “Bitifeye.com.” BitifEye Digital Test Solutions. N.p., n.d. Web. 26 June 2017. <http://www.bitifeye.com/>.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: