The I3C specification takes its name from, uses the same electrical connections as, and allows some backward compatibility with, the I²C bus, a de facto standard for inter-chip communication, widely used for low-speed peripherals and sensors in computer systems.
The I3C standard is designed to retain some backward compatibility with the I²C system, notably allowing designs where existing I²C devices can be connected to an I3C bus but still have the bus able to switch to a higher data rate for communication at higher speeds between compliant I3C devices.
The I3C standard was developed as a collaborative effort between electronics and computer-related companies under the auspices of the MIPI Alliance.
Google and Intel have backed I3C as a sensor interface standard for Internet of things (IoT) devices.
[7] Goals of the MIPI Sensor Working Group effort were first announced in November 2014 at the MEMS Executive Congress in Scottsdale AZ.
[16] SNIA's Enterprise and Data Center Standard Form Factor version 3.1 (January 2023) describes the use of I3C Basic in managing PCI Express devices.
[17] NVM Express 2.1 (August 2024) is reworded to allow the use of I3C, "to match the new conventions used by SNIA SFF TA's EDSFF and PCI-SIG specifications for I3C".
[18] Prior to public release of the specification, a substantial amount of general information about it was published in the form of slides from the 2016 MIPI DevCon.
I3C Basic allows royalty-free implementation of I3C, and is intended for organizations that may view MIPI membership as a barrier for adoption.
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.
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.
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.
The controller may drive SDA low (a repeated START condition) at this time to abort the read.
The compatible HDR modes use SCL high pulses of at most 45 ns so that I²C devices will ignore them.
HDR-DDR accompanies each 16-bit data word with a 2-bit preamble and a 2-bit odd parity postamble, making 20 bits.
The controller may drive SDA low during the second bit time (the falling edge of SCL) to request the read be aborted.
This has a preamble of 01, a fixed pattern of 1100 (other patterns are reserved for future use), then a 5-bit cyclic redundancy check on the full message (including the command/address word, but not the preamble or parity bits, or any part of the CRC word), and two "1" bits (the first driven, the second passively held high so the controller can take over).
This leaves the bus with both SCK and SDA high, after which the controller must generate an HDR restart or exit.
Although this limits the maximum time between SCL transitions to three trit times, that exceeds the 50 ns limit for legacy I²C devices, so HDR-TSP (ternary symbol, pure) mode may only be used on a bus without legacy I²C devices.
To permit buses including I²C devices (with a spike filter), the HDR-TSL (ternary symbol, legacy) mode must be used.
In ternary symbol mode, the controller finishes a read command by leaving the SDA and SCL lines high, after which the target drives both of them at whatever rate it wishes.
When it is done transmitting, the target hands the bus back to the controller as follows: Note that ternary data mode does not include a CRC.