MIPI I3C Sensor Interface is a Faster, Better, Backward Compatible Update to I2C Protocol
I2C (Inter-Integrated Circuit) is one of the most commonly used serial bus for interfacing sensors and other chips, and use two signals (Clock and Data) to control up to 128 chips thanks to its 7-bi address scheme [Update: That’s the theory, as in practice it’s limited to a dozen devices max. due to capacitive load, see comments]. After announcing it was working of a new I3C standard in 2014, the MIPI Alliance has now formally introduced the MIPI I3C (Improved Inter Integrated Circuit) Standardized Sensor Interface, a backward compatible update to I2C with lower power consumption, and higher bitrate allowing it to be used for applications typically relying on SPI too.
I3C offers four data transfer modes that, on maximum base clock of 12.5MHz, provide a raw bitrate of 12.5 Mbps in the baseline SDR default mode, and 25, 27.5 and 39.5 Mbps, respectively in the HDR modes. After excluding transaction control bytes, the effective data bitrates achieved are 11.1,20, 23.5 and 33.3 Mbps.
MIPI I3C vs I2C Energy Consumption and Bitrate – Click to Enlarge
The MIPI Alliance has also provided a table comparing I3C, I2C, and SPI features, advantages and disadvantages.
Parameter
MIPI I3C
I2C
SPI
Number of Lines
2-wire
2-wire (plus separate wires for each required interrupt signal)
4-wire (plus separate wires for each required interrupt signal)
Effective Data Bitrate
33.3 Mbps max at 12.5 MHz
(Typically: 10.6 Mbps at 12 MHz SDR)
3 Mbps max at 3.4 MHz (Hs)
0.8 Mbps max at 1 MHz (Fm+)
0.35 Mbps max at 400 KHz (Fm)
Approx. 60 Mbps max at 60 MHz for conventional implementations (Typically: 10 Mbps at 10 MHz)
Advantages
Only two signal lines
Legacy I2C devices co-exist on the same bus (with some limitations)
Dynamic addressing and supports
static addressing for legacy I2C
devices
I2C-like data rate messaging (SDR)
Optional high data rate messaging
modes (HDR)
Multi-drop capability and dynamic
addressing avoids collisions
Multi-master capability
In-band Interrupt support
Hot-join support
A clear master ownership and
handover mechanism is defined
In-band integrated commands
(CCC) support
Only two signal lines
Flexible data transmission rates
Each device on the bus is
independently addressable
Devices have a simple master/slave relationship
Simple implementation
Widely adopted in sensor
applications and beyond
Supports multi-master and multi-drop capability features
Full duplex communication
Push-pull drivers
Good signal integrity and high speed below 20MHz (higher speed are challenging)
Higher throughput than I2C and SMBus
Not limited to 8-bit words
Arbitrary choice of message size, content and purpose
Simple hardware interfacing
Lower power than I2C
No arbitration or associated failure modes
Slaves use the master’s clock
Slaves do not need a unique address
Not limited by a standard to any maximum clock speed (can vary between SPI devices)
Disadvantages
Only 7-bits are available for device addressing
Slower than SPI (i.e. 20Mbps)
New standard, adoption needs to be proven
Limited number of devices on a
bus to around a dozen devices
Only 7-bits (or 10-bits) are available for static device addressing
Limited communication speed rates and many devices do not support the higher speeds
Slaves can hang the bus; will require
system restart
Slower devices can delay the
operation of faster speed devices
Uses more power than SPI
Limited number of devices on a bus
to around a dozen devices
No clear master ownership and
handover mechanism.
Requires separate support signals for
interrupts
Need more pins than I2C/MIPI I3C
Need dedicated pin per slave for
slave select (SS)
No in-band addressing
No slave hardware flow control
No hardware slave acknowledgment
Supports only one master device
No error-checking protocol is
defined
No formal standard, validating
conformance is not possible
SPI does not support hot swapping
Requires separate support signals
for interrupts
You’ll find more technical details by downloading MIPI I3C specifications and/or whitepaper (free email registration required). Note that only MIPI member can have access to the complete specifications.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
10 Replies to “MIPI I3C Sensor Interface is a Faster, Better, Backward Compatible Update to I2C Protocol”
Only full members can have full access to the spec? So much for hoping for wide adoption.
If the spec isn’t readily available, then individual manufacturers will tweak it for their products–said another way, they’ll violate the spec in ways that suit their needs. Their users won’t know and will build products and invest in using standard breaking parts. This will reduce their ability to use other conforming (or non-conforming in different ways) parts. And then we’ll end up with another mess of a standard. Why does this start to sound like an xkcd comic? 🙁
Something a little bit confusing. In the comparison section at the bottom it says that one limitation of I3C is it still has 7 bit addressing like I2C. It then goes on to say that a single I3C bus could only support “to around a dozen devices”.
If you can only support a dozen devices then it doesn’t really matter if you still have 7 bit addressing. You certainly won’t need any more than that.
@Dennis
Assuming the 7 bit addressing limitation is the same as with I2C, the problem that manufacturers of I3C chips only have 7 bits of addressing to choose from. What this means is that consumers of these chips will still run the possibility of having conflicting addresses on their bus. i.e. a Flash chip and accelerometer that have the same address cannot exist on the same bus together.
PCB designers will still have to ensure their devices are unique and with only 128 possible addresses for the entire world, there is a high likely hood that 2 devices you choose might conflict for your PCB.
@Sean
I understand what you are saying but my experience is that many devices have the ability to change addresses (either through addressing pins or writing to a register a new address). The worst case is to put the conflicting devices behind a mux.
@Sean @Dennis
Hi – Melanie from MIPI Alliance here. I wanted to alleviate any concerns related to 7-bit addressing by sharing that the working group included Dynamic Addressing.
Regarding access to the specification, MIPI Alliance membership starts at $4,000/year on a sliding scale. Learn more here: http://mipi.org/join-mipi
@Melanie
That is good to know. Thanks for the update. With dynamic addressing I would say the 7 bit addressing in the “disadvantaged” column isn’t all that much of a disadvantage.
@Melanie
Dear sir,
I saw on “MIPI_i3C_specification_V1-0.pdf” chapter “4.2.2 I3C slave device” that claims “An I3C Bus supports up to 11 I3C Slave Devices, though the maximum number of Devices will depend on trace length, capacitive load per Device, …”
Does that means only 11 slave devices to work simultaneously on one given I3C bus? I think is too few maybe not enough for quick developing smartphones, can you share you opinion? thanks.
MIPI I3C specifications are now open to all on MIPI website linked above.
However, I can see see different member specifications and public specifications.
@cnxsoftware. Several previous comments have raised questions about the first paragraph where it says I3C can “…control up to 128 chips thanks to its 7-bi address scheme”. While the article is generally very good, those comments are correct in considering this a misleading lead. With a capacitive load on the bus of 50 pF, and each device contributing between 5-10 pF, the practical limit on chips on a bus will be between 5 and 10 (probably lower due to trace capacitance.) This isn’t called out explicitly in the spec, but is a natural consequence of the specified maximum values for Cb and Ci.
I3C offers four data transfer modes that, on maximum base clock of 12.5MHz, provide a raw bitrate of 12.5 Mbps in the baseline SDR default mode, and 25, 27.5 and 39.5 Mbps, respectively in the HDR modes. After excluding transaction control bytes, the effective data bitrates achieved are 11.1,20, 23.5 and 33.3 Mbps.
Only full members can have full access to the spec? So much for hoping for wide adoption.
If the spec isn’t readily available, then individual manufacturers will tweak it for their products–said another way, they’ll violate the spec in ways that suit their needs. Their users won’t know and will build products and invest in using standard breaking parts. This will reduce their ability to use other conforming (or non-conforming in different ways) parts. And then we’ll end up with another mess of a standard. Why does this start to sound like an xkcd comic? 🙁
Something a little bit confusing. In the comparison section at the bottom it says that one limitation of I3C is it still has 7 bit addressing like I2C. It then goes on to say that a single I3C bus could only support “to around a dozen devices”.
If you can only support a dozen devices then it doesn’t really matter if you still have 7 bit addressing. You certainly won’t need any more than that.
@Dennis
Assuming the 7 bit addressing limitation is the same as with I2C, the problem that manufacturers of I3C chips only have 7 bits of addressing to choose from. What this means is that consumers of these chips will still run the possibility of having conflicting addresses on their bus. i.e. a Flash chip and accelerometer that have the same address cannot exist on the same bus together.
PCB designers will still have to ensure their devices are unique and with only 128 possible addresses for the entire world, there is a high likely hood that 2 devices you choose might conflict for your PCB.
@Sean
I understand what you are saying but my experience is that many devices have the ability to change addresses (either through addressing pins or writing to a register a new address). The worst case is to put the conflicting devices behind a mux.
@Sean
@Dennis
Hi – Melanie from MIPI Alliance here. I wanted to alleviate any concerns related to 7-bit addressing by sharing that the working group included Dynamic Addressing.
Regarding access to the specification, MIPI Alliance membership starts at $4,000/year on a sliding scale. Learn more here: http://mipi.org/join-mipi
@Melanie
That is good to know. Thanks for the update. With dynamic addressing I would say the 7 bit addressing in the “disadvantaged” column isn’t all that much of a disadvantage.
@Melanie
Dear sir,
I saw on “MIPI_i3C_specification_V1-0.pdf” chapter “4.2.2 I3C slave device” that claims “An I3C Bus supports up to 11 I3C Slave Devices, though the maximum number of Devices will depend on trace length, capacitive load per Device, …”
Does that means only 11 slave devices to work simultaneously on one given I3C bus? I think is too few maybe not enough for quick developing smartphones, can you share you opinion? thanks.
MIPI I3C specifications are now open to all on MIPI website linked above.
However, I can see see different member specifications and public specifications.
MIPI I3C subsystem added to the Linux kernel by Free Electrons: https://lkml.org/lkml/2017/12/14/406
@cnxsoftware. Several previous comments have raised questions about the first paragraph where it says I3C can “…control up to 128 chips thanks to its 7-bi address scheme”. While the article is generally very good, those comments are correct in considering this a misleading lead. With a capacitive load on the bus of 50 pF, and each device contributing between 5-10 pF, the practical limit on chips on a bus will be between 5 and 10 (probably lower due to trace capacitance.) This isn’t called out explicitly in the spec, but is a natural consequence of the specified maximum values for Cb and Ci.