I3C Explained for I2C Designers: What Changes and Why

If you already know I2C, the easiest way to understand I3C is not as a completely new bus. It keeps the same basic idea—a controller talks to addressed devices over SCL and SDA—but removes several compromises that accumulated around I2C: slow resistor-driven edges, fixed-address collisions, separate interrupt wires, and no standard way to discover or manage devices.

The result looks familiar on the schematic and often feels familiar in application code, but the bus behaves differently underneath. I3C changes the electrical signalling for speed, adds a discovery and management layer, and gives targets a standard way to ask for attention. This article walks through those differences from an I2C designer's point of view.

Start with the I2C mental model

With I2C, firmware already knows which device should be at each static 7-bit address. The controller generates START, sends the address and read/write direction, waits for an ACK, transfers bytes, and finishes with STOP. A sensor register map is defined by the sensor vendor, not by I2C itself. If the sensor needs immediate attention, it normally toggles a separate GPIO interrupt line.

I3C preserves much of that model. Ordinary device-specific communication still uses addressed read and write transfers, called Private Transfers. A temperature sensor or IMU can still expose a vendor-defined register map, and the application can still perform the familiar pattern of writing a register address and reading data back. I3C does not standardise every device's registers.

The biggest difference: how a logic high is driven

On a conventional I2C bus, devices actively pull SCL or SDA low but do not drive them high. A pull-up resistor charges the bus capacitance back toward logic high. This open-drain arrangement makes wired arbitration simple and safe, but the rising edge is an RC curve. More devices, longer traces, connector capacitance, or a weaker pull-up all make that edge slower. A stronger pull-up improves rise time but increases low-state current.

I3C still uses open-drain behaviour where multiple devices may need to arbitrate, but it switches to push-pull signalling for most high-speed communication. The controller actively drives SCL, and the bus can actively drive SDA high or low during appropriate transfer phases. The line no longer has to wait for a pull-up resistor on every rising data edge. That electrical change is the main reason I3C SDR can run at a 12.5 MHz clock while retaining two shared signals.^{[1], [3]}

What I3C improves over I2C—and why

1. Higher throughput

Most I2C systems run at 100 or 400 kbit/s. Fast-mode Plus reaches 1 Mbit/s, and the less commonly used High-speed mode reaches 3.4 Mbit/s under tighter rules. I3C SDR uses a clock up to 12.5 MHz and provides about 11.1 Mbit/s of typical data throughput. Optional HDR modes can go faster, but SDR is already the important practical jump for register access, FIFO reads, firmware downloads, and sensor batching.^[1]

Why it matters: a controller can empty several sensor FIFOs quickly, reduce bus occupancy, and return devices to sleep sooner. It also gives a shared two-wire bus enough bandwidth for workloads that would otherwise move to SPI.

2. In-band interrupts instead of separate GPIOs

I2C defines controller-initiated transfers; it does not define a general interrupt mechanism. A sensor that has data ready therefore needs a separate interrupt wire, or the controller must poll it repeatedly. In I3C, a target can issue an In-Band Interrupt (IBI) on the shared bus. The controller decides whether to accept it, and the target may include a small status payload.

Why it matters: ten sensors no longer imply ten interrupt routes. The design saves pins, level shifters, PCB traces, and polling traffic while preserving low-latency event handling.

3. Dynamic addresses and device discovery

I2C addresses are fixed by the device, selected with one or two strap pins, or changed through a vendor register. Two identical sensors with the same unchangeable address need a multiplexer, separate buses, or a power-up sequencing trick. I3C targets identify themselves during Dynamic Address Assignment (DAA) using a 48-bit Provisional ID plus capability registers. The controller then assigns each target a working 7-bit address.^[3]

Why it matters: multiple identical devices can share one bus without address straps, and software gains a standard discovery step instead of assuming that the schematic and reality always match.

4. Common bus-management commands

I2C defines byte transport but almost no common management behaviour. Reset, identification, interrupt configuration, and capability discovery are vendor-specific. I3C adds Common Command Codes (CCCs) for operations such as address assignment, capability queries, event enable/disable, reset handling, and bus-mode control.

Why it matters: the controller can manage the bus using standard operations even though each target's application registers remain vendor-specific.

5. Hot-Join

An I2C device appearing after boot is just an electrical fact that system software must somehow anticipate. An I3C target can make a standard Hot-Join request, allowing the controller to run address assignment for the new device at a controlled time.

Why it matters: replaceable modules and power-gated peripherals can announce their presence without a dedicated detect wire. Hot-Join support is optional, so both the controller and system architecture must explicitly support it.

6. Lower energy per useful transfer

I3C's push-pull phases avoid repeatedly charging the bus only through pull-up resistors, and the higher data rate shortens the active transaction. The target can often return to sleep sooner. That does not guarantee lower total system power—the result still depends on capacitance, I/O voltage, traffic, and device implementation—but it improves the underlying trade-off.^[4]

I2C and I3C side by side

What changes in firmware?

An I2C driver can often start transferring immediately because the board description supplies a static address. An I3C controller has an initialisation phase:

1. Describe any legacy I2C devices and reserve their static addresses.
2. Initialise the I3C controller and perform Dynamic Address Assignment.
3. Read target identity and capability information.
4. Enable the IBIs and optional features the application will use.
5. Perform ordinary Private Transfers to device-specific registers and FIFOs.

After that setup, much of the steady-state application logic still looks recognisable: address a target, write configuration, read status or FIFO data, and react to an event. The meaningful additions are discovery, standard management, and asynchronous target requests.

Where can you find I3C today?

Sensor hubs and MEMS devices

This is the original use case. An active example is ST's LSM6DSO six-axis IMU, which offers SPI, I2C, and MIPI I3C interfaces. I3C is useful when several accelerometers, gyroscopes, pressure sensors, microphones, or environmental sensors share a bus and need low-latency event reporting without a forest of interrupt wires.^[5]

Microcontrollers and application processors

I3C controllers are now built into mainstream embedded devices. ST documents controller support across STM32H5, STM32H7R/S, STM32U3, STM32N6, and STM32C5 families; Renesas includes it in devices such as RA4E2 and RA6E2. Support is also appearing in PC chipsets and application processors, although the exact role, number of buses, HDR modes, DMA, and IBI handling vary by part.^{[6], [4]}

DDR5 memory modules and server management

I3C has quietly become part of the DDR5 management ecosystem. SPD hubs, temperature sensors, PMIC management, bus multiplexers, and BMC connections use I3C Basic-derived sideband buses. Renesas' active SPD5118 combines an I2C/I3C interface, SPD EEPROM hub, and optional temperature sensor; TI's TMP139 is an I3C Basic temperature sensor aimed at DDR5 DIMMs.^{[7], [8]}

FPGAs and programmable SoCs

For FPGA designers, I3C can appear in three places: a hard peripheral inside a processor subsystem, soft controller or target IP in the FPGA fabric, or the sideband interface attached to a DDR5 memory controller. AMD offers AXI I3C IP in Vivado, Lattice supplies controller IP for multiple FPGA families, Microchip lists an I3C target core, and Agilex 5 SoC devices include hard I3C controllers in the HPS. This makes I3C relevant both as an endpoint implemented in RTL and as a host-managed board interface.^{[9], [10], [11], [12]}

Can I keep existing I2C devices on the bus?

Often yes. An I3C controller can run a mixed bus containing I3C targets and compatible legacy I2C targets. The controller uses I2C-style open-drain transfers when talking to an I2C device and I3C signalling when talking to an I3C target. This is the migration path that makes I3C attractive: a design does not necessarily need to replace every sensor at once.

There are limits. I2C devices do not participate in Dynamic Address Assignment, so firmware must still declare them and reserve their addresses. Legacy devices with unsuitable spike filters, clock stretching, or electrical behaviour can restrict the bus. Every I2C transaction also runs at the legacy device's rate, so one slow target can consume a disproportionate amount of bus time.^[3]

What should you check before adopting it?

• Feature matrix: Confirm controller and target support for SDR, IBIs, Hot-Join, the required CCCs, target reset, and any HDR mode you intend to use. "I3C compatible" is not a complete feature description.
• I/O voltage: I3C is common at low I/O voltages. Verify absolute maximum ratings and whether level translation is permitted for the modes you need.
• Pull-ups and electrical model: The bus uses both open-drain and push-pull phases. Follow the controller vendor's guidance for pull-ups, capacitance, trace topology, series damping, and mixed-bus devices.
• Software stack: Linux has an I3C subsystem and controller/target driver APIs, but target drivers and platform integration are less universal than I2C. On an MCU, inspect HAL support, DMA behaviour, IBI queues, error recovery, and diagnostic visibility.^[3]
• Test equipment: Confirm that your oscilloscope, protocol analyser, exerciser, and production test flow can decode dynamic addressing, CCCs, IBIs, and the modes you enable.
• Bus ownership and recovery: Define who performs DAA, how addresses are restored after reset, how Hot-Join is handled, and what happens after a target or controller resets mid-transaction.

The bottom line

For an I2C designer, the essential change is simple: I3C preserves the two-wire, addressed-device model but removes the passive pull-up from most high-speed signalling and adds the management features that I2C never defined. That is why it can be faster, discover devices, assign addresses, receive interrupts on the bus, and handle late-arriving targets.

I2C remains the right choice when 100 or 400 kbit/s is enough, parts are inexpensive and plentiful, and static addresses plus GPIO interrupts are not a problem. I3C becomes valuable when the bus is crowded, several identical targets must coexist, interrupt pins are scarce, sensor FIFOs are growing, or the system needs discovery and controlled device management. SPI still makes sense for very high-rate or deterministic point-to-point streaming, but I3C covers much of the space between classic I2C simplicity and SPI's pin cost.

References

1. MIPI Alliance — I3C and I3C Basic specification overview and current versions.
2. MIPI Alliance — I3C and I3C Basic frequently asked questions.
3. Linux kernel documentation — I3C protocol.
4. Renesas — How I3C improves sensor applications.
5. STMicroelectronics — LSM6DSO 6-axis IMU.
6. STMicroelectronics AN5879 — Introduction to I3C for STM32 MCUs.
7. Renesas — SPD5118 DDR5 SPD hub.
8. Texas Instruments — Thermal sensing with the I3C TMP139.
9. AMD — AXI I3C bus interface IP.
10. Lattice Semiconductor — I3C Controller IP user guide.
11. Microchip — I3C target IP core.
12. Intel — I3C controller support in SoC FPGA families.

Related Articles

Related article Image Sensor Subsampling: Binning, Skipping, and ROI A practical guide to image sensor subsampling modes (binning, skipping, ROI) and the FPGA timing details that decide whether they work in an embedded vision system.

Related article HyperRAM Memory: Introduction and Comparison A comprehensive introduction to HyperRAM technology and how it compares to traditional SRAM and DDR memory for low-pin-count FPGA designs.