Inside every modern electronic device, there is a protocol running, and most people have never even heard of it. This protocol does it all. It moves data between chips; it keeps the sensors talking to the processors. It has been doing all those things reliably since 1982.
That protocol is the I2C. However, after more than four long decades of faithful service, the I2C is finally running into a wall.
Now, we don’t mean that the I2C is suddenly a bad protocol. It is a genuinely elegant piece of engineering, a simple two-wire bus that lets chips communicate without a lot of overhead or complexity. Philips Semiconductors designed it, and it spread everywhere: consumer electronics, industrial systems, medical devices, you name it.
Back in the early 1980s, the I2C was built for small data volumes in a world where speed was a nice-to-have, not a hard requirement. Nobody designing I2C in 1982 was thinking about a smartwatch packed with a dozen sensors, or a server managing DDR5 memory over a management bus, or an SSD reporting its health over a sideband interface. Devices now are a lot different from what the I2C was created for.
And so, I2C is gradually being replaced by I3C, a smarter, faster, and more sophisticated upgrade that feels both familiar and completely new at the same time.
​
Where I2C Started to Struggle
Before we get into what I3C is, let’s first understand what made it necessary in the first place. Over time with I2C, three pain points kept coming up over and over again, across different teams and design problems:
1. Speed
I2C tops out at around 1MHz in standard fast-plus mode. That was perfectly fine for simple sensor reads in the early days. However, modern systems need to move a lot more data, a lot faster.
Engineers started reaching for SPI whenever they needed real throughput, which meant running two different bus types on the same board. This added to the complexity and cost, meaning more things could go wrong.
2. Interrupts
In I2C, there is no built-in way for a target device to tap the controller on the shoulder and say “hey, I have something to report.” You need a dedicated GPIO line for each device that needs to raise an interrupt.
On a smartphone with fifteen sensors, that’s fifteen extra GPIO pins. And this can cost die area, board space, and eventually, money.
3. Addressing
I2C uses static addresses, hardwired at design time or set with physical pins. In large, complex systems, running out of address space or dealing with address conflicts is a well-known and deeply frustrating headache.
Back in 1982, when I2C was created, these issues weren’t dealbreakers. They became an issue as the industry kept pushing for faster, smaller, lower-power everything.
What is the I3C Protocol?
In the simplest terms, I3C is the third evolution of the I2C-style serial interface.
As designs grew more complex through the 2000s and 2010s, the limitations of I2C began to show in slower speeds, pin-count constraints, and the lack of a native interrupt mechanism. This made it increasingly difficult to keep up with modern hardware demands.
The MIPI Alliance (Mobile Industry Processor Interface) looked at this problem and did something smart: instead of designing a completely new bus and scrapping everything I2C had built over four decades, they built I3C as an evolution.
The I3C protocol takes the best of what I2C offered: its simplicity, its two-wire interface, its broad compatibility, and layers in the speed and intelligence that modern systems actually need.
I3C keeps the same two-wire physical interface as I2C: SDA (data) and SCL (clock). If you already have an I2C bus, I3C can live on it alongside your existing I2C devices. The silicon speaks the same physical language, and your legacy hardware doesn’t become obsolete overnight.
However, everything that happens on top of the two wires is different.
The Features of I3C That Matter
1. Speed
I3C’s Single Data Rate (SDR) mode tops out at 12.5MHz, more than twelve times faster than standard I2C. And that’s before you get into High Data Rate modes:
- HDR-DDR (Double Data Rate): encodes data on both edges of the clock. This effectively doubles throughput.
- HDR-TSL and HDR-TSP (Ternary Symbol modes): push throughput further using three-level signalling.
Earlier, applications were forced into SPI for the speed. Now, I3C just consolidates onto a single bus. Â
2. Dynamic Address Assignment (DAA)
Remember the addressing headache? On the I3C bus, devices don’t ship with fixed, pre-loaded addresses anymore. Instead, they get addresses assigned at runtime through a process called DAA. Here’s how it works:
- The controller issues an ENTDAA command to the bus.
- Each device responds with its Provisional ID. This is a unique identifier that includes manufacturer information assigned by MIPI.
- The device with the lowest Provisional ID value wins priority and gets assigned a dynamic address first.
- This repeats until all devices on the bus have addresses.
What this means for you is that there are no address conflicts at design time. You don’t need physical pins to configure addresses. As a result, you have cleaner, more scalable designs.
3. In-Band Interrupts (IBI)
In I2C, if a target needs to raise an interrupt, you need a dedicated GPIO line for it.
In I3C, a target device can pull the SDA line low during a bus idle condition to signal the controller. This means you don’t need an extra wire or an extra pin on the processor.
If you work with a smartphone with fifteen sensors, I3C helps you save fifteen GPIO, which translates directly into die area, board space, and cost.
4. Hot-Join
Now that addresses are assigned dynamically on the I3C, a device that wasn’t present when the bus initialised can join later and get a dynamic address assigned on the fly.
For systems where components are added after power-up, or where power sequencing means not everything comes up at once, this is genuinely useful.
​
I3C Is Everywhere Now, Not Just in Phones
When I3C was first introduced, the primary use case was sensor integration in smartphones and wearables. That remains a major application. But the protocol has spread much further:
| Domain | How I3C Is Used |
| Mobile & IoT | Sensor hub communication, replacing I2C for accelerometers, gyroscopes, and environmental sensors |
| Automotive | Low-power, deterministic sensor communication |
| Data Center | MCTP transport layer, carrying NVMe-MI, SPDM, and PLDM management protocols |
| Storage (SSD) | Sideband interface between SSDs and host systems via NVMe-MI |
| Memory (DDR5) | PMIC communication as defined in the JEDEC DDR5 specification |
| CXL | Sideband signaling for one of the most talked-about data center interconnects today |
I3C started as a sensor bus. It has become the connective tissue of next-generation system management across nearly every major hardware category.
​
Not Just Faster I2C
It’s tempting to describe I3C as “faster I2C,” but that undersells what it actually is. The MIPI Alliance set out to build a single interface that could replace three different bus types:
- I2C for simplicity and backward compatibility
- SPI for speed
- GPIO + UART-style signalling for interrupt handling
I3C achieves all three, on two wires, with legacy compatibility intact. Boards that previously needed multiple bus types can be simplified, and systems constrained by pin counts get room to breathe. Engineers designing for the next generation of hardware get a protocol that was actually built for the complexity they’re dealing with.
​
Where This Leaves Engineers
I3C is no longer a protocol on the horizon. It’s in production silicon, in shipping products, and in the design specs of next-generation hardware across mobile, automotive, servers, and storage. The work of validating, testing, and debugging I3C implementations is happening right now, at scale.
That’s exactly what Prodigy Technovations built the PGY-I3C-EX-PD for, giving design and test engineers the ability to generate I3C traffic, emulate controllers and targets, inject errors, run conformance tests, and decode protocol packets at the level of detail that real validation work demands.
Ready to see what serious I3C protocol testing looks like? Explore Prodigy’s I3C tools here.
