I3C (bus)

The initial I3C design sought to improve over I²C in the following ways:[16]

• Two-pin interface that is a superset of the I²C standard. Legacy I²C slave devices can be connected to the newer bus.
• Low-power and space efficient design intended for mobile devices (smartphones and IoT devices.)
• In-band interrupts over the serial bus rather than requiring separate pins. In I²C, interrupts from peripheral devices typically require an additional non-shared pin per package.
• Standard Data Rate (SDR) throughput between 10 and 12.5 Mbit/s using CMOS I/O levels.
• High Data Rate (HDR) modes permitting multiple bits per clock cycle. These support throughput comparable to SPI while requiring only a fraction of I²C Fast Mode power.[17]
• A standardized set of common command codes
• Command queue support
• Error Detection and Recovery (parity check in SDR mode and 5bit CRC for HDR modes)
• Dynamic address assignment (DAA) for I3C slaves, while still supporting static addresses for I²C legacy devices
• I3C traffic is invisible for legacy I²C devices when equipped with I²C spike filters, achieved by SCl HIGH times of less than 50ns
• Hot-join (some devices on the bus may be powered on/off during operation)
• Multi-master operation with a well-defined protocol for hand-off between masters

After making the I3C 1.0 standard publicly accessible, the organization subsequently published the I3C Basic specification, a subset intended to be implementable by non-member organizations under a RAND-Z licence. The basic version includes many of the protocol innovations in I3C 1.0, but lacks some of the potentially more difficult-to-implement ones such as the optional high data rate (HDR) modes like DDR. None the less the default SDR mode at up to 12.5 Mbit/s is a major speed/capacity improvement over I²C.[18]

Published in December of 2019, this specification is only available to MIPI members.

I3C uses same two signal pins as I²C, referred to as SCL (serial clock) and SDA (serial data). The primary difference is that I²C operates them as open-drain outputs at all time, so its speed is limited by the resultant slow signal rise time. I3C uses open-drain mode when necessary for compatibility, but switches to push-pull outputs whenever possible, and includes protocol changes to make it possible more often than in I²C.

• SCL is a conventional digital clock signal, driven with a push-pull output by the current bus current master during data transfers. (Clock stretching, a rarely used I²C feature, is not supported.) In transactions involving I²C slave devices, this clock signal generally has a duty cycle, of approximately 50%, but when communicating with known I3C slaves, the bus master may switch to a higher frequency and/or alter the duty cycle so the SCL high period is limited to at most 40 ns.
• SDA carries the serial data stream, which may be driven by either master or slave, but is driven at a rate determined by the master's SCL signal. For compatibility with the I²C protocol, each transaction begins with SDA operating as an open-drain output, which limits the transmission speed. For messages addressed to an I3C slave, the SDA driver mode switches to push-pull after the first few bits in the transaction, allowing the clock to be further increased up to 12.5 MHz. This medium-speed feature is called standard data rate (SDR) mode.

Generally, SDA is changed just after the falling edge of SCL, and the resultant value is received on the following rising edge. When the master hands SDA over to the slave, it likewise does so on the falling edge of SCL. However, when the slave is handing back control of SDA to the master (e.g. after acknowledging its address before a write), it releases SDA on the rising edge of SCL, and the master is responsible for holding the received value for the duration of SCL high. (Because the master drives SCL, it will see the rising edge first, so there will be a brief period of overlap when both are driving SDA, but as they are both driving the same value, no bus contention occurs.)

All communications in I²C and I3C requires framing for synchronization. Within a frame, changes on the SDA line should always occur while SCL is in the low state, so that SDA can be considered stable on the low-to-high transition of SCL. Violations of this general rule are used for framing (at least in legacy and standard data rate modes).

Between data frames, the bus master holds SCL high, in effect stopping the clock, and SDA drivers are in a high-impedance state, permitting a pull-up resistor to float it to high. A high-to-low transition of SDA while SCL is high is known as a START symbol, and signals the beginning a new data frame. A low-to-high transition on SDA while SCL is high is the STOP symbol, ending a data frame.

A START without a preceding STOP, called a "repeated START", may be used to end one message and begin another within a single bus transaction.

In I²C, the START symbol is usually generated by a bus master, but in I3C, even slave devices may pull SDA low to indicate they want to start a frame. This is used to implement some advanced I3C features, such as in-band interrupts, multi-master support, and hot-joins. After the start, the bus master restarts the clock by driving SCL, and begins the bus arbitration process.

Like I²C, I3C uses 9 clock cycles to send each 8-bit byte. However, the 9th cycle is used differently. I²C uses the last cycle for an acknowledgement sent in the opposite direction to the first 8 bits. I3C operates the same way for the first (address) byte of each message, and for I²C-compatible messages, but when communicating with I3C slaves, message bytes after the first use the 9th bit is an odd parity bit on writes, and an end-of-data flag on reads.

Writes may be terminated only by the master.

Either the master or the slave may terminate a read. The slave sets SDA low to indicate that no more data is available; the master responds by taking over SDA and generating a STOP or repeated START. To allow a read to continue, the slave drives SDA high while SCL is low before the 9th bit, but lets SDA float (open-drain) while SCL is high. The master may drive SDA low (a repeated START condition) at this time to abort the read.

At the start of a frame, several devices may contend for use of the bus, and the bus arbitration process serves to select which device obtains control of the SDA line. In both I²C and I3C, bus arbitration is done with the SDA line in open-drain mode, which allows devices transmitting a binary 0 (low) to override devices transmitting a binary 1. Contending devices monitor the SDA line while driving it in open-drain mode. Whenever a device detects a low condition (0 bit) on SDA while transmitting a high (1 bit), it has lost arbitration and must cease contending until the next transaction begins.

Each transaction begins with the target address, and the implementation gives priority to lower-numbered target addresses. The difference is that I²C has no limit on how long arbitration can last (in the rare but legal situation of several devices contending to send a message to the same device, the contention will not be detected until after the address byte). I3C, however, guarantees that arbitration will be complete no later than the end of the first byte. This allows push-pull drivers and faster clock rates to be used the great majority of the time.

This is done in several ways:

• I3C supports multiple masters, but they are not symmetrical; one is the current master and responsible for generating the clock. Other devices sending a message on the bus (in-band interrupts or secondary masters wishing use of the bus) must arbitrate using their own address before sending any other data. Thus, no two legal bus messages share the same first byte except if the master and another device are simultaneously communicating with each other.
• I3C, like I²C, allows multiple messages per transaction separated with "repeared START" symbols. Arbitration is per-transaction, so these subsequent messages are never subject to arbitration.
• Most I3C master transactions begin with the reserved address 0x7E(1111110₂). As this has a lower priority than any I3C device, once it has passed arbitration, the master knows that no other device is contending for the bus.
• As a special case, if I3C devices are assigned low addresses (I3C supports dynamic, master-controlled address assignment), then as soon as the 0x7E address has won arbitration for enough leading bits to distinguish it from any assigned address, the master knows that arbitration is complete and it may switch to push-pull operation on SDA. If all assigned addresses are less than 0x40, this is after the first bit. If all addresses are less than 0x60, this is after the second bit, and so on.
• In the case described above wherein the current master begins a transaction with the address of a device which is itself contending for use of the bus, both will transmit their address bytes successfully. However, each will expect the other to acknowledge the address (by pulling SDA low) for the following acknowledge bit. Consequently, neither will, and both will observe the lack of acknowledgement. In this case, the message is not sent, but the master wins arbitration: it may send a repeated start, followed by a retry which will be successful.

A write addressed to the reserved address 0x7E is used to perform a number of special operations in I3C. All I3C devices must receive and interpret writes to this address in addition to their individual addresses.

First of all, a write consisting of just the address byte and no data bytes has no effect on I3C slaves, but may be used to simplify I3C arbitration. As described above, this prefix may speed up arbitration (if the master supports the optimization of switching to push-pull mid-byte), and it simplifies the master by avoiding a slightly tricky arbitration case.

If the write is followed by a data byte, the byte encodes a "common command code", a standardized I3C operation. Command codes 0–0x7F are broadcast commands addressed to all I3C slaves. They may be followed by additional, command-specific parameters. Command codes 0x80–0xFE are direct commands addressed to individual slaves. These are followed by a series of repeated STARTs and writes or reads to specific slaves.

While a direct command is in effect, per-slave writes or reads convey command-specific parameters. This operation is in lieu of slave's normal response to an I3C message. One direct command may be followed by multiple per-slave messages, each preceded by a repeated START. This special mode ends at the end of the transaction (STOP symbol) or the next message addressed to 0x7E.

Some command codes exist in both broadcast and direct forms. For example, the commands to enable or disable in-band interrupts may be sent to individual slaves or broadcast to all. Commands to get parameters from a slave (for example the GETHDRCAP command to ask a device which high-data-rate modes it supports) only exist in direct form.