Enter the Improved Inter-Integrated Circuit (I3C), a next-generation chip-to-chip interconnect capable of supporting not only mobile devices, but Internet of Things (IoT), wearables, and automotive sensor subsystems as well. Below, Foust explains.

What can you tell us about the history of the I3C interface specification?

FOUST: I3C by now goes back more than a few years. If you were to rewind three or four years, there were several companies that were dealing with some of the same pain points when it came to adding sensors to mobile handset. One of those issues really stemmed from the proliferation of sensors.

At that time I was at a startup MEMS company trying to convince people that things like accelerometers, gyroscopes, and magnetometers were going to unlock a whole lot of potential for consumer devices. The iPhone, with its wide touch screen that needed auto rotation and various input types for gaming, which sensors allowed, opened up opportunities but also created a lot of problems. Quickly we went from very few sensors in phones to today when a phone could have up to ten sensors. You can have accelerometers, magnetometers, gyroscopes, ambient light sensors, proximity, pressure, temperature, humidity, infrared, RGB sensors – there are so many sensors that connecting them up to an applications processor or the primary compute was becoming expensive. No longer could the I2C bus – at least a single iteration of it – handle all of the sensors. You had to have multiple instances of the I2C bus, which created more GPIO demand. All of the sensors were getting smarter so that you could configure them to sit in a low power state, look at their data, and interrupt by transitioning a dedicated pin from low to high, for example, when something occurred. But if you had 10 sensors, that’s 10 GPIO pins.

Since the sensor subsystem in these handsets was getting expensive, several of us got together and put down all of our gripes with respect to I2C, SPI, and UART, whether we were sensor vendors or people making reference designs based on various processors. We put all of these gripes and our wishes out on the table and then spent a good year discussing them, turning it into a problem statement with a proposed solution.

With I3C, we now have a lasting, low-speed interface that is derived from requirements for sensors, but will find home anywhere that I2C, SPI, and in many instances, UART, have been found.

How are IoT and embedded developers going to benefit from I3C?

FOUST: What people will like about I3C are things like the dynamic address allocation procedures, where we standardized a lightweight, simple way to discover, enumerate, and assign addresses to devices.

In something like I2C, where you have fixed addresses, there’s a chance that there could be conflicts. You don’t have that with I3C. Where SPI is considered fast for a low-speed interface, each SPI device requires a dedicated chip select (CS) line to address it. You don’t have to do that with I3C. We implemented an in-band interrupt capability that lets you take all of those out-of-band dedicated GPIOs that allow sensors to interrupt the host and lets each of them simply do it over the two wires of I3C, reducing cost.

Then we looked at things like power. I2C is open drain, so every time you make a 0, you’re fighting a pull-up resistor and it’s rather slow, with 400 kHz or 1 MHz being the popular speeds. This means that applications processors have to stay up for a long time as they unload FIFO buffers full of data. With I3C we ramped up the clock and added support for push/pull capability so we’re not fighting the pull-up resistors, which allows applications processors to get data from the sensors faster.

In addition to a faster single data rate operation, we added the concept of high data rate modes – double data rate and ternary symbol transcoding – which can optionally be supported. With these high data rate modes, for the same amount of energy that you spend clocking at 12.5 MHz, you can double or nearly triple the effective throughput, so your millijoules per bit energy starts to drop as you adopt those modes.

The interface is also fast enough that it has optional timing control built in so there are ways for the host to synchronize sensor data collection in time, which can be important for sensors or applications that are time of flight-based, for example. You wouldn’t do that natively with legacy interfaces like I2C or SPI.

These are all features that can lend themselves to not only sensors in handsets, but all of these other areas where low speed interfaces are used, both for chip-to-chip connectivity as well as other applications or industries like wearables, IoT, automotive, etc.

Is any complexity associated with programming an I3C interface?

FOUST: Your basic I3C looks a lot like I2C, except with defined areas where you drive the clock with push/pull, and use a little bit of logic to do in-band interrupt.

From a slave side we really wanted to limit logic complexity and gate count, so we set a target of less than 2000 gates for a slave-side implementation because, in our opinion, we want this interface to be appropriate for extremely inexpensive sensors or ICs – single-cent-type things. We really tried to push complexity to the host side if there was going to be complexity.

It does remain backwards compatibility with I2C, correct?

FOUST: Something from the early days of our charter was to maintain backwards compatibility as best as we can. What we found in our analysis was that not all I2C devices are created the same, and not all of them follow exactly the published I2C specification, but where you do have those compatible devices, yes. That mostly revolves around whether they correctly implemented the 50 nanoseconds spike filter. If they did not, there are ways for the bus to continue to function, there’s just a degradation in performance due to the existence of that device. For instance, you have to talk to the device at the speed of the device, and the bus has to run at that speed.

However, we found that’s not the majority of I2C devices, and that the majority were implemented correctly. So coexistence? Yes. Compatibility? Yes. We anticipate host controllers out there that are I2C/I3C host controllers and slave devices that are I2C/I3C devices. Legacy I2C devices can coexist, and in the spec we point out things in legacy devices that may be impacting performance and how to adjust how the bus operates in the event that that happens.

Do you see I3C completely replacing the lower-speed interconnects in certain segments?

FOUST: If you look at MIPI’s broad influence in mobile, for instance, that’s where it has the best chance of happening. However, in certain segments, there are some things about I2C and SPI and UART that are very favorable. Using them in mobile was a hindrance, but in some applications they can be advantageous. For instance, I2C is very slow and requires very strong drivers, so its power hungry. But in doing that it can drive very long lines – longer lines than we would ever consider a mobile interface driving. Do we necessarily view I3C as an interface that would be routed through, around, and all over a tube television like I2C was developed for? Probably not. I think I2C is still going to be the interface for that, but that’s not what I3C was developed for.

What’s next for MIPI and I3C?

FOUST: When we came up with the charter for our working group, we knew that the world was changing a bit. We’d seen things like IoT and drones and AR/VR and autonomous vehicles coming, and anticipated that those industries would continue to drive future capabilities into I3C. We’ll continue to work on I3C and keep it relevant in those segments.

All the major IP providers in the world have this IP available for people to start synthesizing into their designs, so I have pretty high confidence that by the end of this year, we will see devices that support I3C out there.

MIPI Alliance

Mipi.org

@MIPI_Alliance

LinkedIn: www.linkedin.com/groups/1829351/profile

YouTube: www.youtube.com/user/MIPIAlliance