---
title: "What is I3C, and how does it differ from I2C?"
topic: "I3C vs I2C"
answer: "I3C is MIPI’s faster successor to I2C, on the same two wires. Its chips drive both lines up and down instead of waiting on pull-up resistors, so a 12-byte sensor read takes 13.1 µs and 28.2 nJ, against 344 µs and 203 nJ on I2C at 400 kHz. It also hands out addresses and carries interrupts over the bus, so the extra pins an I2C board needs go away."
url: "https://nearfieldnotes.com/notes/i3c-vs-i2c/"
site: "Near Field Notes"
author: "Michael Walker"
note: 24
family: "Signal integrity"
published: "2026-11-07"
revised: "2026-11-07"
revision: 1
video: "https://nearfieldnotes.com/videos/i3c-vs-i2c/"
---

Note 24 · [Signal integrity](https://nearfieldnotes.com/families/si/) · Rev 1 · [Watch the video · 2:27](https://nearfieldnotes.com/videos/i3c-vs-i2c/)

I3C vs I2C

# What is I3C, and how does it differ from I2C?

**Short answer:** I3C is MIPI’s faster successor to I2C, on the same two wires. Its chips drive both lines up and down instead of waiting on pull-up resistors, so a 12-byte sensor read takes 13.1 µs and 28.2 nJ, against 344 µs and 203 nJ on I2C at 400 kHz. It also hands out addresses and carries interrupts over the bus, so the extra pins an I2C board needs go away.

The figure runs one read on three buses at once, to one time scale. I3C is done before I2C at 400 kHz has sent its first byte.

**Note 24’s opening figure: One read, three buses.** 12 data bytes from an IMU

![Note 24’s opening figure: One read, three buses](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-opening.png)

*What the figure shows:* Figure: the same 12-byte read from a sensor on three buses, drawn to one time scale from 0 to 344 microseconds. I2C at 400 kHz takes 344 µs and 203 nJ. I2C at 1 MHz takes 138 µs and 198 nJ. I3C at 12.5 MHz takes 13.1 µs and 28.2 nJ, a sliver at the left.

**Key**

- Data bytes
- Address and register

Each bar is one read at 1.8 V on 50 pF lines. It sends the address, the register, the address again and 12 data bytes. At rest all three are done. I3C at 12.5 MHz takes 13.1 µs, and I2C takes 138 µs at 1 MHz and 344 µs at 400 kHz.

**The numbers**

*One read: START, the address, register 0x1F, a repeated START, the address again and 12 data bytes, then STOP and the bus-free time after it.*

| Bus | Read takes | Energy | How SCL goes high |
|---|---|---|---|
| I2C, 400 kHz | 344 µs | 203 nJ | 7.08 kΩ pull-up |
| I2C, 1 MHz | 138 µs | 198 nJ | 2.83 kΩ pull-up |
| I3C, 12.5 MHz | 13.1 µs | 28.2 nJ | driven both ways |

## Seven sensors on one board

*16 pins, or 2*

This board has a controller and seven sensors. Two are IMUs, and the others are a magnetometer, a barometer, and light, humidity and temperature sensors. Wired the usual way, the four fast ones share SPI and get a chip-select line each. The slow three share I2C.

Every sensor also has its own interrupt line, to say when it has new data. That takes 16 of the controller’s pins. On I3C all seven share two wires, and the interrupts come over them too.

**Fig. 24: The same board, wired two ways.**

![Fig. 24: The same board, wired two ways](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24.png)

*What the figure shows:* Figure 24: the same board twice, with a controller and seven sensors. They are two IMUs, a magnetometer, a barometer, and light, humidity and temperature sensors. In the first, the four fast sensors sit on SPI with a chip select each, the slow three on I2C, and every sensor has its own interrupt line, 16 controller pins in all. In the second, all seven share one I3C bus on 2 pins.

The parts sit in the same places both times. The lit copper is the sensors’ signal lines, and the rest is power and ground.

**The numbers**

| Lines | Pins | Wired the usual way | On I3C |
|---|---|---|---|
| I2C | 2 | SCL and SDA, to light, humidity and temperature | SCL and SDA, to all seven |
| SPI | 3 | SCLK, MOSI and MISO, to the IMUs, magnetometer and barometer | None |
| Chip selects | 4 | One for each SPI sensor | None |
| Interrupts | 7 | One for each sensor | None, they come over the bus |
| Total | 16 |  | 2 |

I2C, Philips’ bus from 1982, has two wires. SCL carries the clock and SDA the data. On both, a chip can only pull the line low. A resistor, the pull-up, brings it back up, so any chip can hold a line down and no two chips ever fight.

I3C keeps the two wires but drives them both ways. A chip pulls the line up as hard as it pulls it down. The pull-up stays only for the moments when two chips may talk at once.

**Fig. 24b: Two ways to drive a line.**

![Fig. 24b: Two ways to drive a line](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24b.png)

*What the figure shows:* Figure 24b: two schematics of one bus line. On I2C, a resistor Rp pulls the line up to the 1.8 V supply and the chip's n-channel FET can only pull it low. The line's capacitance Cb charges through Rp. On I3C, a p-channel FET drives the line high and an n-channel FET drives it low, so Cb charges through the FET.

One chip’s output on one line. Cb is everything the line has to charge: its copper and every chip’s pin on it.

## The pull-up sets the pace

*One rise on 50 pF*

On I2C a line goes high only as fast as its pull-up can charge it. UM10204, NXP’s I2C spec, times that [rise](https://nearfieldnotes.com/glossary/#g-rise-time) from 30% to 70% of the supply:

`t_r = 0.8473 R_p C_b`

where t_r: rise time, 30% to 70% of the supply (s); R_p: pull-up resistance (Ω); C_b: bus capacitance, one line (F).

`300 ns = 0.8473 × 7.08 kΩ × 50 pF`

At 400 kHz the spec allows a 300 ns rise, so on a 50 pF line the pull-up can be at most 7.08 kΩ. Fast-mode Plus, at 1 MHz, allows 120 ns and 2.83 kΩ. A stronger pull-up rises faster, but it burns power whenever a chip holds the line low:

`P = (V^2)/R_p`

where P: power the pull-up burns while a line is low (W); V: supply voltage (V); R_p: pull-up resistance (Ω).

`0.46 mW = ((1.8 V)^2)/(7.08 kΩ)`

That is 0.59 nJ in each 1.3 µs low half of a 400 kHz clock, against 0.16 nJ to charge the line back up.

**Fig. 24c: One clock edge.**

![Fig. 24c: One clock edge](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24c.png)

*What the figure shows:* Figure 24c: SCL's voltage for 450 ns after the line is let go. I2C at 400 kHz, through 7.08 kΩ, rises 30 to 70 percent in 302 ns. I2C at 1 MHz, through 2.83 kΩ, in 122 ns. I3C, driven, in 2.3 ns, and its clock rises 6 times before the 400 kHz line reads as high.

SCL for 450 ns after the line is let go. Each I2C pull-up is the weakest its speed allows. In the 434 ns the 400 kHz line takes to read as high, I3C’s clock rises 6 times.

**The numbers**

*On 50 pF at 1.8 V.*

| Bus | Pull-up | Rise, 30 to 70% |
|---|---|---|
| I2C, 400 kHz | 7.08 kΩ | 302 ns |
| I2C, 1 MHz | 2.83 kΩ | 122 ns |
| I3C, 12.5 MHz | none, driven | 2.3 ns |

## Why MIPI made I3C

*2013 to 2016*

MIPI, the alliance whose camera links [Note 14](https://nearfieldnotes.com/notes/phy-link/) looks at, lists I2C’s limits in its I3C FAQ. Its addresses are fixed at 7 bits, and an interrupt needs an extra wire. Its data rate is limited. Clock stretching lets one chip hang the bus. SPI needs three shared wires and a select line for every chip.

MIPI formed a Sensor Working Group in 2013. It wanted fewer pins, one standard way to talk to sensors, and one bus for the jobs of both I2C and SPI. In a 2022 talk, MIPI projected more than 20 sensors per device on average.

I3C stands for Improved Inter Integrated Circuit. Version 1.0 was adopted on 31 December 2016, and I3C Basic, a subset anyone can download, followed in 2018.

**Fig. 24d: Two buses’ dates.**

![Fig. 24d: Two buses’ dates](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24d.png)

*What the figure shows:* Figure 24d: dates for the two buses. 1982, I2C: Philips’ first I2C release. 2007, I2C: Version 3 adds 1 MHz Fast-mode Plus. 2013, I3C: MIPI forms its Sensor Working Group. 2016, I3C: I3C 1.0 adopted, 31 December. 2018, I3C: I3C Basic, the public subset. 2020, I3C: JEDEC’s DDR5 sideband, on I3C Basic. 2021, I2C: NXP’s spec says controller and target. 2025, I3C: I3C 1.2 and I3C Basic 1.2.

From NXP’s UM10204, MIPI’s FAQ and press releases, and JEDEC.

**The numbers**

| Year | Bus | What happened |
|---|---|---|
| 1982 | I2C | Philips’ first I2C release |
| 2007 | I2C | Version 3 adds 1 MHz Fast-mode Plus |
| 2013 | I3C | MIPI forms its Sensor Working Group |
| 2016 | I3C | I3C 1.0 adopted, 31 December |
| 2018 | I3C | I3C Basic, the public subset |
| 2020 | I3C | JEDEC’s DDR5 sideband, on I3C Basic |
| 2021 | I2C | NXP’s spec says controller and target |
| 2025 | I3C | I3C 1.2 and I3C Basic 1.2 |

## How I3C runs at 12.5 MHz

*Driven both ways*

I3C’s plain mode, SDR, runs its clock at 12.5 MHz. Most of each read is driven both ways. Open drain comes back only where more than one chip may answer.

**Fig. 24e: The I3C read, up close.**

![Fig. 24e: The I3C read, up close](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24e.png)

*What the figure shows:* Figure 24e: the first 4.6 microseconds of the I3C read, SCL and SDA. After START the address goes out in open drain: SCL low 200 ns and high 40 ns for each bit, SDA rising slowly through its pull-up. The target's acknowledge is open drain too. From the register byte on, both lines are driven both ways, 40 ns low and 40 ns high, 12.5 MHz.

The read’s first 4.6 µs. The bars above mark the address, the register and the first data byte. Once the address is through, SDA no longer waits on its pull-up.

**The numbers**

| Part of the read | SDA | SCL low | SCL high |
|---|---|---|---|
| Address after START | Open drain | 200 ns | 40 ns |
| Acknowledge | Open drain | 200 ns | 40 ns |
| Register, address after repeated START, data | Push-pull | 40 ns | 40 ns |

SDR

### Open drain only where chips may collide

**Field marks.** After START, the address goes out in open drain, so a sensor that wants to interrupt can join in, as in Fig. 24g. The acknowledge is open drain too. Everything after is push-pull, 40 ns low and 40 ns high. A ninth bit, T, ends each byte. On a write it is parity, and on a read a flag that says whether more data follows.

**Look-alike.** I2C’s High-speed mode. UM10204 has a 3.4 MHz mode too, but there the controller only speeds up SCL’s rise with a current source, and SDA stays open drain.

**Range.** SDR carries about 11 Mbit/s of data, and MIPI’s FAQ expects most traffic to use it. HDR modes go further. Double data rate runs at 25 Mbit/s raw, and Bulk Transport at up to 100 Mbit/s over four lanes. Full I3C alone adds ternary modes at 33.3 Mbit/s.

**Habitat.** Every I3C chip. Bosch’s BMI323, for one, does SDR alone.

## Less energy per read

*203 nJ, 198 nJ and 28.2 nJ*

The same read draws 203 nJ from the 1.8 V supply on I2C at 400 kHz, and 28.2 nJ on I3C, 7.2 times less. On I3C most of it goes into charging the lines. A driven line takes this much from the supply each time it rises:

`E = C_b V^2`

where E: energy from the supply to raise a line once (J); C_b: bus capacitance, one line (F); V: supply voltage (V).

`162 pJ = 50 pF × (1.8 V)^2`

SCL rises 137 times in the read, so the clock alone takes 22.2 nJ of the 28.2 nJ.

**Fig. 24f: Energy for one read.**

![Fig. 24f: Energy for one read](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24f.png)

*What the figure shows:* Figure 24f: energy drawn from the 1.8 V supply for one 12-byte read. I2C, 400 kHz: 203 nJ. I2C, 1 MHz: 198 nJ. I3C held to 1 MHz: 37.9 nJ. I3C, 12.5 MHz: 28.2 nJ.

From the 1.8 V supply, for the same 12-byte read on each bus.

**The numbers**

*With 30 random 12-byte payloads in place of the IMU’s: 182 nJ to 204 nJ at 400 kHz, 177 nJ to 198 nJ at 1 MHz, 29.1 nJ to 31.2 nJ on I3C.*

| Bus | Energy | Time |
|---|---|---|
| I2C, 400 kHz | 203 nJ | 344 µs |
| I2C, 1 MHz | 198 nJ | 138 µs |
| I3C held to 1 MHz | 37.9 nJ | 137 µs |
| I3C, 12.5 MHz | 28.2 nJ | 13.1 µs |

Energy

### Pull-ups burn power while a line is low

**Field marks.** On I2C a pull-up draws current the whole time a chip holds its line low: 0.46 mW at 400 kHz. Over a clock’s low half that is 0.59 nJ, more than three times the 0.16 nJ it takes to raise the line.

**Look-alike.** A faster I2C clock saving energy. At 1 MHz the read takes 198 nJ, close to the 203 nJ at 400 kHz. The pull-up has to be 2.5 times stronger for the quicker rise, so each 0.5 µs low half still costs 0.57 nJ.

**Range.** The data moves the totals a little. With 30 random payloads, I2C at 400 kHz took 182 nJ to 204 nJ and I3C 29.1 nJ to 31.2 nJ. MIPI’s own 2022 figure is 4.3 times less energy than I2C at 1 MHz, for 1 kB.

**Habitat.** Battery devices that read sensors often. At one read a second, I2C at 400 kHz uses 0.20 µW, so the saving counts only when reads are many.

## Interrupts on the bus

*The lower address wins*

On I2C, a sensor with new data raises its own interrupt line. On I3C it asks on SDA instead, an in-band interrupt, and the address it then sends decides who goes first.

**Fig. 24g: Two sensors ask at once.**

![Fig. 24g: Two sensors ask at once](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24g.png)

*What the figure shows:* Figure 24g: two sensors ask for an interrupt at once. One pulls SDA low while the bus is idle, the controller starts the clock, and both send their address in open drain, bit by bit from the left. IMU 1 at 0x09 sends 0001001, the magnetometer at 0x0A sends 0001010. At bit 6 IMU 1 sends 0 and the magnetometer 1. The line reads 0, so the magnetometer stops. IMU 1's address is acknowledged.

IMU 1 at 0x09 and the magnetometer at 0x0A both want the bus. On each bit, a 0 from either chip pulls SDA low.

**The numbers**

| Bit | IMU 1, 0x09 | Mag, 0x0A | SDA reads |
|---|---|---|---|
| 1 | 0 | 0 | 0 |
| 2 | 0 | 0 | 0 |
| 3 | 0 | 0 | 0 |
| 4 | 1 | 1 | 1 |
| 5 | 0 | 0 | 0 |
| 6 | 0 | 1 | 0 |
| 7 | 1 | out | 1 |

In-band interrupt

### A 0 beats a 1

**Field marks.** While the bus is idle, a sensor pulls SDA low. The controller starts the clock, and every sensor that wants the bus sends its own address in open drain. A sensor that sends a 1 but sees a 0 has lost, and stops. Here the magnetometer drops out at bit 6, and IMU 1’s address is acknowledged.

**Look-alike.** I2C’s arbitration. It works the same way on the same wired line, but on I2C only controllers take part.

**Range.** The lowest address always wins, so the controller sets each sensor’s priority when it hands out addresses. MIPI’s FAQ warns that a busy low address can starve the rest. An interrupt can carry data: DMTF’s MCTP binding marks a waiting packet with the byte 0xAE.

**Habitat.** In place of the seven interrupt lines in Fig. 24. The two sensors here could be any two on that board.

## Addresses handed out

*48-bit IDs, lowest first*

An I2C chip’s address is set when it is made, apart from a pin or two. An I3C controller gives each chip an address of its choosing when the bus starts up.

**Fig. 24h: Where the address comes from.**

![Fig. 24h: Where the address comes from](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24h.png)

*What the figure shows:* Figure 24h: where each address comes from. On I2C, two of the same IMU take 0x68 and 0x69: the address is 1101000 with its last bit set by the AD0 pin. On I3C each chip has a 48-bit ID: 15 bits for the maker, one flag bit, 16 for the part, 4 for the instance and 12 more. Two identical IMUs match in every field but the instance, set to 0 and 1, so the first bit that differs is there.

Above, two ICM-42688-P IMUs on I2C. Below, two of any one part on I3C: their IDs match until the instance field.

**The numbers**

*The 48-bit ID’s fields when the flag bit is 0, as Linux’s i3c/device.h reads them.*

| Field | Bits | Width |
|---|---|---|
| Maker | 47 to 33 | 15 |
| Random flag | 32 | 1 |
| Part | 31 to 16 | 16 |
| Instance | 15 to 12 | 4 |
| Extra | 11 to 0 | 12 |

Dynamic address

### Two of one part still need a pin

**Field marks.** On I2C, TDK’s ICM-42688-P answers at 1101000 or 1101001, picked by its AD0 pin, so two can share a bus. A third needs a bus of its own or a switch chip, such as NXP’s PCA9546A. On I3C the controller sends ENTDAA, and every chip sends its 48-bit ID in open drain. The lowest ID wins and gets the next address, and the rest go again.

**Look-alike.** I3C ending address clashes. Two identical parts send identical IDs and collide, so MIPI’s FAQ says they need different instance bits, from a pin, a fuse or memory. The board in Fig. 24 keeps a strap on each IMU for that.

**Range.** Linux’s I3C code keeps 0x00 to 0x07, the broadcast address 0x7E and the seven addresses one bit away from it, which leaves 112 to give out. SETDASA and SETAASA skip the contest by turning a chip’s fixed address into its dynamic one.

**Habitat.** Any bus with two of one sensor. DDR5 modules use SETAASA rather than ENTDAA.

## Old I2C chips on the bus

*Too quick to see*

An I3C bus can keep I2C chips on it. They miss the I3C traffic because their own input filters throw it away.

**Fig. 24i: A 50 ns filter on I3C’s clock.**

![Fig. 24i: A 50 ns filter on I3C’s clock](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24i.png)

*What the figure shows:* Figure 24i: 400 ns of the I3C read's clock, during the first data byte, and what a 50 ns spike filter passes. SCL is high for 40 ns at a time, shorter than the filter's 50 ns, so the filter's output stays low. Over the whole read SCL rises 137 times and the filter's output rises 1 time, at the STOP.

400 ns of the read’s clock, in the first data byte. Each high pulse lasts 40 ns, under the filter’s 50 ns.

**The numbers**

|  | On the bus | After the filter |
|---|---|---|
| SCL rising edges in the read | 137 | 1 |
| SCL high, push-pull | 40 ns | not seen |

Legacy I2C targets

### The clock is too quick to see

**Field marks.** UM10204 makes Fast-mode and Fast-mode Plus chips ignore spikes shorter than 50 ns. I3C’s clock is high for 40 ns, so of the read’s 137 rising clock edges the filter passes one. An I2C chip sees a START, a clock held low for 12.5 µs, then a STOP, and never hears its address.

**Look-alike.** Any I2C chip joining in. MIPI’s FAQ allows only Fast-mode and Fast-mode Plus targets with the 50 ns filter and no clock stretching, and no I2C controllers at all.

**Range.** One I2C chip without the filter sets the pace for all. Microchip’s PIC18-Q20 manual says the bus speed is set by the slowest such target. Held to 1 MHz, the same I3C read takes 137 µs and 37.9 nJ: no faster than I2C at 1 MHz, but at a fifth of its energy.

**Habitat.** Mixed buses, where older sensors stay on the I3C wires. Standard-mode parts, at 100 kHz, aren’t required to filter at all.

## Where I3C is used

*Memory, servers, sensors*

DDR5 memory modules carry a sideband bus that JEDEC built on I3C Basic. It links the SPD hub, which describes the module and reads its temperature, to the power chip and temperature sensors, and it keeps I3C’s full 12.5 MHz. Rambus’s SPD5118 hub runs at up to 1 MHz on I2C and 12.5 MHz on I3C Basic. Linux reads these hubs over I3C from version 7.3.

In servers, DMTF’s MCTP binding carries management packets over I3C, and OCP’s DC-SCM 2.2 module runs its management ports as I2C or I3C. Microcontrollers such as ST’s STM32H5 and Microchip’s PIC18-Q20 have I3C ports, and sensors such as TDK’s ICM-42688-P and Bosch’s BMI323 speak it at 12.5 MHz.

**Fig. 24j: A DDR5 module’s sideband.**

![Fig. 24j: A DDR5 module’s sideband](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-24j.png)

*What the figure shows:* Figure 24j: the middle of a DDR5 memory module, rendered: the SPD hub, a small chip that holds the module's description and a temperature sensor, beside the power chip and its inductors and capacitors.

The middle of a DDR5 module, between its memory chips.

## Why I2C isn’t gone

*The catches*

I3C hasn’t replaced I2C. Fewer chips speak it, and fewer tools read it. Saleae’s Logic 2 decodes it only through a paid plugin from another company, and sigrok’s open decoders have none.

A mixed bus runs only as fast as its slowest unfiltered I2C chip allows, and two copies of one part still need a pin or a fuse to tell them apart. For a sensor read once a second, I2C is fine: at 400 kHz the read keeps the bus busy 0.03% of the time.

**Figure: Side by side.**

Fig. 24k

|  | I2C | I3C |
|---|---|---|
| Wires | SCL and SDA | SCL and SDA |
| Clock | 100 kHz, 400 kHz or 1 MHz | 12.5 MHz in SDR |
| Lines go high | Through a pull-up | Driven, open drain only to arbitrate and acknowledge |
| Addresses | Fixed 7-bit, a pin or two to change | Handed out by the controller |
| Interrupts | A line for each chip | Over SDA, lowest address first |
| 12-byte read | 344 µs, 203 nJ at 400 kHz | 13.1 µs, 28.2 nJ |
| Shares its bus with | Any I2C chip | I2C targets with a 50 ns filter |
| Saleae Logic 2 | Built in | Paid plugin |

The read’s times and energies are Fig. 24f’s. The rest is from UM10204, MIPI’s FAQ and Saleae’s list of decoders.

## Which bus for your sensors?

*From the controller out*

The key starts at the controller, because a bus can only be I3C if its controller is.

Key to sensor buses

### I2C, I3C, or I3C held to I2C speed?

1. 1a The controller has no I3C port, or no sensor speaks I3C I2C, at the speed every chip allows
2. 1b The controller and some sensors speak I3C Go to 2
3. 2a An I2C chip on the bus has no 50 ns filter Go to 3
4. 2b Every I2C chip on the bus filters, or there are none Go to 4
5. 3a A spare pin pair can give that chip its own bus I3C, with the old chip on I2C beside it
6. 3b It has to share I3C held to I2C speed
7. 4a Reads are rare and pins are spare Either: I2C has more tools
8. 4b Reads are frequent, sensors many, or pins short I3C at 12.5 MHz

An I2C chip that stretches the clock can’t share an I3C bus at all, by MIPI’s FAQ. It needs a bus of its own, as in 3a.

## Time a read yourself

*Four buses, 1 to 48 bytes*

Pick a bus and how many data bytes one read carries. Both charts show all four buses, with the one you pick drawn bold, and both scales are logarithmic. Where two lines lie on top of each other, those two buses take the same.

**Note 24’s explorer: Read time and energy.**

![Note 24’s explorer: Read time and energy](https://nearfieldnotes.com/notes/i3c-vs-i2c/fig-explore.png)

*What the figure shows:* Read time and energy per read against the number of data bytes, 1 to 48, for I2C at 400 kHz and 1 MHz and I3C at 12.5 MHz and held to 1 MHz, on log scales. The chosen bus is drawn bold, with a dot at the chosen size.

**Key**

- I2C, 400 kHz
- I2C, 1 MHz
- I3C, 12.5 MHz
- I3C held to 1 MHz

Each read is the register address, a repeated START and the data, as in the opening figure, which is the 12-byte read here.

**The numbers**

*Time and energy for one read.*

| Data bytes | I2C, 400 kHz | I2C, 1 MHz | I3C, 12.5 MHz | I3C held to 1 MHz |
|---|---|---|---|---|
| 1 | 96.9 µs, 57.5 nJ | 38.8 µs, 56.0 nJ | 5.22 µs, 9.88 nJ | 37.7 µs, 18.1 nJ |
| 2 | 119 µs, 72.4 nJ | 47.8 µs, 70.6 nJ | 5.94 µs, 11.8 nJ | 46.7 µs, 20.2 nJ |
| 4 | 164 µs, 90.7 nJ | 65.8 µs, 88.3 nJ | 7.38 µs, 15.1 nJ | 64.7 µs, 23.5 nJ |
| 6 | 209 µs, 122 nJ | 83.8 µs, 118 nJ | 8.82 µs, 18.6 nJ | 82.7 µs, 27.4 nJ |
| 12 | 344 µs, 203 nJ | 138 µs, 198 nJ | 13.1 µs, 28.2 nJ | 137 µs, 37.9 nJ |
| 24 | 614 µs, 366 nJ | 246 µs, 357 nJ | 21.8 µs, 48.0 nJ | 245 µs, 59.5 nJ |
| 48 | 1,154 µs, 692 nJ | 462 µs, 674 nJ | 39.1 µs, 87.6 nJ | 461 µs, 103 nJ |

#### Conditions

- **Method:** Circuit simulation in ngspice of one controller and one target on two lines, energy from the 1.8 V supply.
- **Lines:** Each line 50 pF, driven through 50 Ω switches.
- **I2C:** The weakest pull-up each speed allows on 50 pF: 7.08 kΩ at 400 kHz, 2.83 kΩ at 1 MHz. Clock low and setup times at the spec’s minimums.
- **I3C:** SCL driven both ways, 40 ns low and 40 ns high. SDA open drain through 2.2 kΩ for the address after START and the acknowledges, 200 ns low and 40 ns high, with a 100 kΩ keeper.
- **The read:** Address 0x68, register 0x1F, a repeated START and 12 data bytes, an IMU’s accelerometer and gyro sample. Each time runs from START to the end of the bus-free time after STOP.
- **Interrupt:** Two targets at 0x09 and 0x0A, both open drain on the same SDA.
- **Filter:** A digital 50 ns filter on the simulated SCL, switching only after a level has held 50 ns.
- **Renders:** Blender, one board built for the picture with every trace routed, and a DDR5 module.

The board’s parts and traces are drawn for the picture, not taken from a product.

#### Limits

- The I3C Basic spec itself sits behind a download form and wasn’t read. Its timings here come from MIPI’s FAQ and from ST’s and Microchip’s manuals.
- Real chips add their own pin capacitance and drivers, which move every number here.
- MIPI’s 4.3 times is for 1 kB against I2C at 1 MHz. The 7.2 times here is for 12 bytes against 400 kHz.
- No public source here names a phone that ships with I3C.
- HDR modes weren’t simulated.

#### Files

- sim/bus.py The 12-byte read on I2C and I3C
- sim/extra.py The interrupt, the 50 ns filter and I3C at 1 MHz
- sim/bus_random.py The read with 30 random payloads
- sim/site.py Reads of 1 to 48 bytes, and each read’s energy as it goes
- render/board.py The board in Fig. 24
- render/dimm.py The DDR5 module in Fig. 24j
- render/site.py Both on a white ground
- refs/research.md The research notes behind the sources

#### Sources

- [NXP UM10204, I2C-bus specification and user manual, rev. 7.0, October 2021](https://www.nxp.com/docs/en/user-guide/UM10204.pdf)
- [MIPI Alliance, FAQ for MIPI I3C v1.2 and I3C Basic v1.2, public edition, 2025](https://www.mipi.org/hubfs/I3C-Resources/MIPI-I3C-v1-2-FAQs-public-edition.pdf)
- [MIPI Alliance, Achieving Optimal Energy and Power Efficiency with MIPI I3C, webinar, 3 May 2022](https://www.mipi.org/hubfs/MIPI-Webinar-Achieving-Optimal-Energy-and-Power-Efficiency-with-MIPI-I3C-2022-05-03.pdf)
- [MIPI Alliance, MIPI Releases I3C Basic, 11 December 2018](https://www.mipi.org/press-releases/mipi-releases-i3c-basic-interface-specification)
- [MIPI Alliance, New Version of I3C Basic Boosts Speed and Flexibility, 21 September 2021](https://www.mipi.org/press-releases/new-version-of-i3c-basic-boosts-speed-and-flexibility)
- [MIPI Alliance, I3C Basic v1.2, 6 August 2025](https://www.mipi.org/press-releases/mipi-releases-i3c-basic-v1-2-utility-and-control-bus-interface-for-mobile-iot-data-center-applications)
- [JEDEC, JESD403-1 Module Sideband Bus, October 2020, reprinted](https://design-reuse.com/news/48826/jedec-module-sideband-bus.html)
- [Rambus SPD5118 DDR5 SPD hub](https://www.rambus.com/memory-interface-chips/ddr5-dimm-chipset/ddr5-spd-hub-with-internal-temperature-sensor/)
- [Renesas, DDR5 modules and SETAASA, 13 October 2021](https://www.renesas.com/en/blogs/new-entry-line-ra-family-ra2e2-mcu-group-ddr5-dimm-led-control-application)
- [Linux, hwmon: spd5118: Add I3C support, July 2026](https://github.com/torvalds/linux/commit/9cd3db0cda4741befa6de8af94eb371b9ec6d057)
- [DMTF DSP0233, MCTP I3C Transport Binding, 1.0.1](https://www.dmtf.org/sites/default/files/standards/documents/DSP0233_1.0.1.pdf)
- [OCP, DC-SCM 2.2, version 1.0](https://www.opencompute.org/documents/ocp-dc-scm-rev2-2-ver1-0-pdf)
- [ST, STM32H5 HAL driver, I3C](https://github.com/STMicroelectronics/stm32h5xx-hal-driver/blob/main/Src/stm32h5xx_util_i3c.c)
- [Microchip PIC18-Q20 data sheet, I3C target, §37.2.2.1](https://onlinedocs.microchip.com/oxy/GUID-20DC4AC0-78C3-43D4-B405-15D8B752B254-en-US-5/GUID-63907B0C-198D-4027-9499-6306765348D1.html)
- [TDK ICM-42688-P datasheet, DS-000347: I2C address and host interface speeds](https://invensense.tdk.com/download-resource/ds-000347-icm-42688-p-datasheet)
- [Bosch BMI323 datasheet: 12.5 MHz I3C, SDR only](https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi323-ds000.pdf)
- [Linux, i3c/device.h: the ID’s fields](https://github.com/torvalds/linux/blob/master/include/linux/i3c/device.h)
- [Linux, i3c/master.c: reserved addresses](https://github.com/torvalds/linux/blob/master/drivers/i3c/master.c)
- [Saleae, supported protocols in Logic 2](https://www.saleae.com/support/protocol-analyzers/supported-protocols/supported-protocols)
- [sigrok, protocol decoders](https://sigrok.org/wiki/Protocol_decoders)

What should the next note be? [Ask for one](https://nearfieldnotes.com/#ask-for-a-note)

---

Source: https://nearfieldnotes.com/notes/i3c-vs-i2c/

Cite as: Michael Walker, “I3C vs I2C”, Near Field Notes, Note 24, Rev 1, 7 Nov 2026. https://nearfieldnotes.com/notes/i3c-vs-i2c/

Figures: free to reuse under CC BY 4.0 (https://nearfieldnotes.com/license/). Each one's image is linked under its name. Credit Michael Walker, Near Field Notes, and link the figure: this address plus #fig- and its number, like https://nearfieldnotes.com/notes/i3c-vs-i2c/#fig-24.