I3C (bus)

I3C bus

Type	Serial communication bus
Production history
Designer	MIPI Alliance Sensor Working Group
Designed	2016;8 years ago (2016)
Manufacturer	Intel Corporation; Lattice Semiconductor
Hot pluggable	Yes
Electrical
Signal	CMOS
Data
Data signal	Open-drain or Push/Pull
Width	2 wires [data + clock]
Bitrate	12.5  Mbit/s  (SDR, standard), 25  Mbit/s  (DDR), 33  Mbit/s  (ternary), legacy I²C rates 400  Kbits/s  (FM), 1  Mbit/s  (FM+)
Protocol	Serial, half-duplex

I3C, also known as SenseWire, ^{[1] [2]} is a specification ^[3] to enable communication between computer chips by defining the electrical connection between the chips and signaling patterns to be used. Short for "Improved Inter Integrated Circuit", ^[4] the standard defines the electrical connection between the chips to be a two wire, shared (multidrop), serial data bus, one wire (SCL) being used as a clock to define the sampling times, the other wire (SDA) being used as a data line whose voltage can be sampled. The standard defines a signalling protocol in which multiple chips can control communication and thereby act as the bus controller.

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 thereby combines the advantage of the simple, two wire I²C architecture with the higher communication speeds common to more complicated buses such as the Serial Peripheral Interface (SPI).

The I3C standard was developed as a collaborative effort between electronics and computer related companies under auspices of the Mobile Industry Processor Interface Alliance (MIPI Alliance). The I3C standard was first released to the public at the end of 2017, ^{[5] [6]} although access requires the disclosure of private information. Google and Intel have backed I3C as a sensor interface standard for Internet of things (IoT) devices. ^[7]

History

Goals of the MIPI Sensor Working Group effort were first announced in November 2014 at the MEMS Executive Congress in Scottsdale AZ. ^[8]

Electronic design automation tool vendors including Cadence, ^[9] Synopsys ^[10] and Silvaco ^[11] have released controller IP blocks and associated verification software for the implementation of the I3C bus in new integrated circuit designs.

In December 2016, Lattice Semiconductor integrated I3C support into its new FPGA known as an iCE40 UltraPlus. ^[12]

In 2017, Qualcomm announced the Snapdragon 845 mobile SOC with integrated I3C controller support. ^{[13] [ failed verification ]}

In December 2017, the I3C 1.0 specification was released for public review. ^{[7] [14]} At about the same time, a Linux kernel patch introducing support for I3C was proposed by Boris Brezillon. ^[15]

In 2021, DDR5 has introduced I3C.

In June 2022, Renesas Electronics introduced the first I3C Intelligent switch products. ^[16]

Goals

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. ^[17] The goals for this interface were based on a survey of MIPI member organizations and MEMS Industry Group (MIG) members. The results of this survey have been made public. ^[18]

I3C v1.0

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

• Two-pin interface that is a superset of the I²C standard. Legacy I²C target 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. ^[20]
• A standardized set of common command codes
• Command queue support
• Error Detection and Recovery (parity check in SDR mode and 5 bit CRC for HDR modes)
• Dynamic address assignment (DAA) for I3C targets, 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 50 ns
• Hot-join (some devices on the bus may be powered on/off during operation)
• Multi-controller operation with a well-defined protocol for hand-off between controllers

I3C Basic Specification

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. 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. None the less the default SDR mode at up to 12.5 Mbit/s is a major speed/capacity improvement over I²C. ^[21]

I3C v1.1

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

I3C v1.1.1

Published in June 2021, it has deprecated the terms "master/slave" and now uses the updated normative terms "controller/target." The technical definitions of such devices, and their roles on an I3C bus, remain unchanged.

Nomenclature

Signal pins

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 times, 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 controller during data transfers. (Clock stretching, ^[22] a rarely used ^[23] I²C feature, is not supported.) In transactions involving I²C target devices, this clock signal generally has a duty cycle of approximately 50%, but when communicating with known I3C targets, the bus controller 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 controller or target, but is driven at a rate determined by the controller'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 target, 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 controller hands SDA over to the target, it likewise does so on the falling edge of SCL. However, when an I3C target is handing back control of SDA to the controller (e.g. after acknowledging its address before a write), it releases SDA on the rising edge of SCL, and the controller is responsible for holding the received value (re-driving a copy of the target's bit) for the duration of SCL high. Because the controller 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.

Framing

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 controller 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 controller, but in I3C, even target 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-controller support, and hot-joins. After the start, the bus controller restarts the clock by driving SCL, and begins the bus arbitration process.

Ninth bit

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 targets, message bytes after the first use the 9th bit as an odd parity bit on writes, and an end-of-data flag on reads.

Writes may be terminated only by the controller.

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

Bus arbitration

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 controllers, but they are not symmetrical; one is the current controller and responsible for generating the clock. Other devices sending a message on the bus (in-band interrupts or secondary controllers 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 controller and another device are simultaneously communicating with each other.
• I3C, like I²C, allows multiple messages per transaction separated with "repeated START" symbols. Arbitration is per-transaction, so these subsequent messages are never subject to arbitration.
• Most I3C controller transactions begin with the reserved address 0x7E(1111110₂). As this has a lower priority than any I3C device, once it has passed arbitration, the controller knows that no other device is contending for the bus.
• As a special case, if I3C devices are assigned low addresses (I3C supports dynamic, controller-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 controller 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 controller 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 controller wins arbitration: it may send a repeated start, followed by a retry which will be successful.

Common command codes

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 targets, but may be used to simplify I3C arbitration. As described above, this prefix may speed up arbitration (if the controller supports the optimization of switching to push-pull mid-byte), and it simplifies the controller 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 targets. They may be followed by additional, command-specific parameters. Command codes 0x80–0xFE are direct commands addressed to individual targets. These are followed by a series of repeated STARTs and writes or reads to specific targets.

While a direct command is in effect, per-target writes or reads convey command-specific parameters. This operation is in lieu of target's normal response to an I3C message. One direct command may be followed by multiple per-target 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 targets or broadcast to all. Commands to get parameters from a target (for example the GETHDRCAP command to ask a device which high-data-rate modes it supports) only exist in direct form.

Device classes

On an I3C bus in its default (SDR) mode, four different classes of devices can be supported:

• I3C Main Controller
• I3C Secondary Controller
• I3C Target
• I²C Target (legacy devices)

High Data Rate (HDR) options

Each I3C bus transaction begins in SDR mode, but the I3C controller may issue an "Enter HDR" CCC broadcast command which tells all I3C targets that the transaction will continue in a specified HDR mode. I3C targets which do not support HDR may then ignore bus traffic until they see a specific "HDR exit" sequence which informs them it is time to listen to the bus again. (One of the I2C Common Command Codes lets the controller ask a target which HDR modes it supports. This is an 8-bit mask, allowing additional HDR modes to be added in future.)

Some HDR modes are also compatible with I²C devices if the I²C devices have a 50 ns spike filter on the SCL line; that is, they will ignore a high level on the SCL line which lasts less than 50 ns. This is required by the I²C specification, but not universally implemented, and not all implementations ignore frequently repeated spikes, ^[24] so I3C HDR compatibility must be verified. The compatible HDR modes use SCL high pulses of at most 45 ns so that I²C devices will ignore them.

HDR mode is entered before addressing any particular target; the target address and command is itself sent at high data rate. An HDR message is terminated by one of two sequences, which are not used by any HDR mode:

• An HDR restart consists of two (or more) falling edges of SDA, followed by a rising edge, while SCL is held low. Finally, a rising edge of SCL (while SDA is high) completes the restart sequence. Targets then listen for a new address and command at the current (high) data rate.
• AN HDR exit consists of four (or more) falling edges of SDA, while SCL is held low. Finally, a rising edge of SCL (while SDA is held low), completes the HDR exit sequence. After this, targets listen for SDR messages. Commonly this is followed by a rising edge of SDA while SCL is high (an SDR STOP symbol) to release the bus.

Although an HDR restart need only be recognized by targets which support that HDR mode, so could be redesigned in some future HDR mode, HDR exit must be recognized by all I3C targets, even SDR-only ones, so they can properly ignore HDR messages.

HDR modes send data in 16-bit words, always transmitting an even number of bytes. Each word is followed by two parity bits, which are interleaved: the first applies to the odd-numbered bits, and the second applies to the even-numbered bits.

Once in HDR mode, a controller sends a series of messages, each beginning with a command and address word, separated by HDR restarts, and ending with an HDR exit.

An HDR command and address word consists of 16 bits:

• A Read/Write direction bit. Like I²C, a 1 (high) value indicates a read.
• A 7-bit command code. This is something not present in I²C. There are 128 write commands and 128 read commands, although command codes 32–127 are reserved for vendor definition and will not be standardized.
• A 7-bit target address.
• 1 extra bit used only in HDR-DDR read commands.

HDR-DDR (double data rate) mode

The HDR-DDR mode uses double data rate signalling on the SDA line with a 12.5 MHz clock to achieve a 25 Mbit/s raw data rate (20 Mbit/s effective). This requires changing the SDA line while SCK is high, a violation of the I²C protocol, but as the high-going pulse is only 40 ns long, I²C devices will ignore it and thus not notice the violation.

HDR-DDR accompanies each 16-bit data word with a 2-bit preamble and a 2-bit odd parity postamble, making 20 bits. Each word starts with a rising edge on SCK. The preamble has three possible states:

• 01: Command word (before data) or CRC word (after data) follows.
• 10: First data word follows. Abort by controller if seen subsequently.
• 11: Subsequent data word follows. NACK by target if seen initially.

If a controller sees a preamble of "11" immediately after a command, that indicates that no target is responding and is treated the same as a NACK in SDR mode. To ensure the SDA line will be seen high if no target responds, the extra bit in the command and address word is set so that the final parity bit sent by the controller is 1.

For subsequent words during read operations (from target to controller), the target drives the first preamble bit high, but releases the bus (allowing the pull-up resistors to maintain SDA high) for the second bit. The controller may drive SDA low during the second bit time (the falling edge of SCL) to request the read be aborted.

If not aborted, a message is terminated with a 13-bit CRC word. 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.

HDR Ternary symbol modes

The HDR-TSP and HDR-TSL modes use one of three symbols as ternary digits (trits):

0. A transition of both SDA and SCL (received within 12.8 ns of each other),
1. A transition of SCL only, or
2. A transition of SDA only.

Two bytes plus two even parity bits (18 bits total) are broken into six 3-bit triplets, and each triplet is encoded as two trits. (The 3 bits are taken msbit-first to produce a value from 0–7, which is then converted to two trits using the numeric values in the list above, and sent most significant trit first.) Sent at 25 Mtrit/s, this achieves a 33.3 Mbit/s effective data rate.

The trit pair 22 consisting of two transitions of SDA only is not used to encode data, and is instead used to encode the HDR restart and HDR exit sequences which terminate a message. 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. This maintains I²C compatibility by trit stuffing: after any rising edge on SCL, if the following trit is not 0, a 1 trit (transition on SCL only) is inserted by the sender, and ignored by the receiver. This ensures that SCL is never high for more than one trit time, but at the cost of transmitting 2.67 trits per 3 bits of payload, a 25 Mbit/s effective data rate (assuming random data).

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. There is no provision for the controller to interrupt the read operation; if the controller does not trust the target to stop on time, it must choose a different transmission mode. When it is done transmitting, the target hands the bus back to the controller as follows:

• The target sets SDA high and SCL low. If the bus was not already in this state, the transition will be interpreted by the controller as a trit, but it will be ignored as is it not part of a 12-trit group.
• The target toggles SDA three times (trit 2), leaving both SDA and SCL low, then releases (ceases to drive) the bus within one trit time (half clock cycle)
• As soon as the controller sees the third SDA-only edge, it takes over driving SDA and SCL low. After at least one trit time (half clock cycle), it then drives SDA high, and continues to complete either an HDR restart (by driving SCL high) or an HDR exit (by toggling SDA three more times, then driving SCL high), as it wishes.

Note that ternary data mode does not include a CRC.

I²C features not supported in I3C

• Pull-up resistors are provided by the I3C controller. External pull-up resistors are no longer needed.
• Clock Stretching – devices are expected to be fast enough to operate at bus speed. The I3C controller is the sole clock source.
• I²C Extended (10-bit) Addresses. All devices on an I3C bus are addressed by a 7-bit address. Native I3C devices have a unique 48-bit address which is used only during dynamic address assignments.

References

1. Cole, Bernard (2014-11-05). "MIPI nears ratification on SenseWire/I3C enhancement of I2C/SPI". News. embedded.com. Archived from the original on 2024-03-22. Retrieved 2024-03-22.
2. Johnson, R. Colin (2014-12-11). "MEMS/Sensor Interface I3C Rocks". Industrial Control Designline. EE Times . Archived from the original on 2024-03-22. Retrieved 2024-03-22.
3. "MIPI I3C and I3C Basic". mipi.org. 2017-01-06.
4. "I3C and I3C Basic Frequently Asked Questions | MIPI". www.mipi.org. Retrieved 2022-08-29.
5. "MIPI Alliance opens access to its MIPI I3C Sensor Interface Specification". 2017-12-14.
6. "MIPI Alliance releases MIPI I3C sensor-interface specification". www.evaluationengineering.com.
7. "MIPI makes market push for I3C sensor interface". 2017-12-14.
8. "MEMS/Sensor Interface I3C Rocks". 2014-11-12.
9. "IP | Cadence" . Retrieved 2023-08-11.
10. "VC Verification IP for MIPI I3C". www.synopsys.com.
11. "MIPI I3C Family for Sensor and IoT Applications" (PDF). silvaco.com. Archived from the original (PDF) on 2019-08-30. Retrieved 2019-08-30.
12. "Lattice gives iCE40 more power, I/O and memory". 2016-12-12.
13. "Qualcomm SDM845 SoC | Integrated LTE Application Processor based on Snapdragon 845 | Qualcomm". www.qualcomm.com. Retrieved 2023-08-11.
14. "MIPI I3C". mipi.org. 2017-01-06.
15. "LKML: Boris Brezillon: [PATCH v2 0/7] Add the I3C subsystem". lkml.org.
16. "Renesas Unveils Industry's First I3C Intelligent Switch Family for Next Generation Server, Storage and Communications Systems | Renesas". www.renesas.com. Retrieved 2023-08-11.
17. "MIPI I3C Sensor Sessions at MIPI DevCon2016". resources.mipi.org. MIPI Alliance Inc.
18. http://mipi.org/sites/default/files/MIPI%20+%20MIG%20Member%20Sensor%20Interface%20Survey%20Results%20final.pdf ^{[ dead link ]}
19. "MIPI DevCon 2016: A Developer's Guide to MIPI I3C Implementation". YouTube . MIPI Alliance. 2016-09-23.
20. "MIPI DevCon 2016: MIPI I3C High Data Rate Modes". MIPI Alliance. 2016-09-23.
21. Foust, Ken. "MIPI Alliance Delivers New I3C Basic Specification". resources.mipi.org. Retrieved 2020-04-06.
22. Nelson, Carter (2024-04-01). "Working with I2C Devices: Clock Stretching". Adafruit Industries.
23. "3.1.9 Clock Stretching". I²C-bus specification (PDF) (User Manual). Revision 7.0. NXP Semiconductors. 2021-10-01. p. 12. Archived (PDF) from the original on 2022-10-06. Clock stretching is optional and in fact, most target devices do not include an SCL driver so they are unable to stretch the clock.
24. "8-Kbit serial I²C bus EEPROM data sheet" (PDF). STMicroelectronics. July 2022. p. 23,24. DocID 023924 Rev 7. Archived (PDF) from the original on 2024-08-03. Retrieved 2024-10-01. Pulse width ignored (input filter on SCL and SDA) - single glitch: 100 ns max

Further reading

• "I2C vs I3C Protocol: Differences and Similarities". eVision Systems. Retrieved 2024-10-01.

External links

• I3C specification - MIPI
• I3C Specification v1.0 - Direct PDF link