I3C (bus)


I3C, also known as SenseWire, is a specification 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, the standard defines the electrical connection between the chips to be a two wire, shared, serial data bus, one wire being used as a clock to define the sampling times, the other wire being used as a data line whose voltage can be sampled. The standard defines a signaling 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 electronic devices. 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 higher pin count buses such as the Serial Peripheral Interface.
The I3C standard was developed as a collaborative effort between electronics and computer-related companies under the auspices of the MIPI Alliance. The I3C standard was first released to the public at the end of 2017, although access requires the disclosure of private information. Google and Intel have backed I3C as a sensor interface standard for Internet of things devices.

History

Goals of the MIPI Sensor Working Group effort were first announced in November 2014 at the MEMS Executive Congress in Scottsdale, Arizona, United States.
Electronic design automation tool vendors including Cadence, Synopsys and Silvaco 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.
In 2017, Qualcomm announced the Snapdragon 845 mobile SOC with integrated I3C controller support.
In December 2017, the I3C 1.0 specification was released for public review.
At about the same time, a Linux kernel patch introducing support for I3C was proposed by Boris Brezillon.
In 2021, DDR5 adopted I3C for its serial presence detect functions.
In June 2022, Renesas Electronics introduced the first I3C Intelligent switch products.
SNIA's Enterprise and Data Center Standard Form Factor version 3.1 describes the use of I3C Basic in managing PCI Express devices. NVM Express 2.1 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".

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

I3C v1.0

The initial I3C design sought to improve over I²C in the following ways:
  • 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
  • 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.
  • Single data rate throughput between 10 and using CMOS I/O levels.
  • High data rate modes permitting multiple bits per clock cycle. These support throughput comparable to SPI while requiring only a fraction of I²C Fast Mode power.
  • A standardized set of common command codes
  • Command queue support
  • Error Detection and Recovery
  • Dynamic address assignment 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
  • 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 modes like DDR. None the less the default SDR mode at up to is a major speed/capacity improvement over I²C.

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 and SDA. 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. 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 single data rate 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, it releases SDA on the rising edge of SCL, and the controller is responsible for holding the received value 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.
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.

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 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 on SDA while transmitting a high, 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. 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 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. 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, 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 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.