I3C (bus)

I3C (also known as SenseWire) is a specification[1] to enable communication between computer chips by defining the electrical connection between the chips and signaling patterns to be used. 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 master.

I3C
Type Bus
Production history
Designer MIPI Alliance
Sensor Working Group
Designed 2016 (2016)
Manufacturer multiple
Hot pluggable true
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

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[2][3], 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.[4]

History

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

Electronic design automation tool vendors including Cadence,[6] Synopsys[7] and Silvaco[8] 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 has integrated I3C support into its new FPGA known as an iCE40 UltraPlus.[9]

In 2017, Qualcomm announced the Snapdragon 845 mobile SOC with integrated I3C master support.[10]

In December 2017, The I3C 1.0 specification was released for public review.[4][11] At about the same time, a Linux kernel patch introducing support for I3C was proposed by Boris Brezillon.[12]

In June 2020, Renesas Electronics introduced I3C products.[13]

Goals

Prior to public release of the specification, a substantial amount of general information about it has been published in the form of slides from the 2016 MIPI DevCon.[14] 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.[15]

I3C V1.0

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

  • Two-pin interface that is a superset of the I2C standard. Legacy I2C 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 I2C, 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 I2C 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 I2C legacy devices
  • I3C traffic is invisible for legacy I2C devices when equipped with I2C 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

I3C Basic Specification

After publishing 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 I2C.[18]

I3C V1.1

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

Nomenclature

Signal Pins

I3C uses two signal pins on referred to as SCL and SDA. In legacy and SDR modes, these signals are used in a way very similarly to I2C:

  • SCL is a conventional digital clock signal, driven with a push-pull output by the bus current master during data transfers. In transactions involving legacy slave devices, this clock signal generally has a duty cycle, of approximately 50%, but in transactions with known I3C slaves, the bus master may switch to a higher frequency by altering the duty cycle to one where the SCL high period is limited to no more than 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 I2C protocol, SDA is initially driven with open-drain outputs, which limits the transmission speed. For transactions involving a I3C slave, the SDA driver mode switches to push-pull after receiving some of the first bits in a packet, allowing substantial speed improvements. This medium-speed feature is called standard data rate (SDR) mode

Framing

All communications in I2C 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 his 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.

In I2C, the START symbol is usually generated by a bus master, but in I3C, even slave devices can 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, and hot-joins. After the start, the bus master 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 what device to service next. In both I2C and I3C, bus arbitration is done based on the device's address, where devices with the lowest address have higher priority. It is done with the SDA line in open-drain mode, which allows devices transmitting a binary 0 (low) to override devices signaling a binary 1. Contending devices monitor the SDA line while driving it in open-drain mode. If they detect a situation where SDA is low at a time their address required it to be high, they know they have lost the bus arbitration, and must cease their contention until the next frame begins.

Device classes

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

  • I3C Main Master
  • I3C Secondary Master
  • I3C Slave
  • I2C Slave (legacy devices)

High Data Rate (HDR) options

I3C Buses always initialize in SDR mode. To enter HDR mode, the I3C master issues an "Enter HDR" CCC Broadcast command which tells all I3C slaves that the bus is in HDR mode. I3C slaves which do not support HDR have told that to the master and can ignore that command. I3C slaves which do not support HDR need to have an "HDR exit" detector which informs when it is time to listen to the bus again.

HDR modes operate in either Double Data Rate (DDR) or Ternary Symbol modes. These modes can only be on buses under one of two limited configurations:

  • A Pure I3C Bus – no I2C devices on the bus
  • A Mixed Fast Bus – Where I2C devices on the bus are equipped with a 50 ns Spike Filter

There are three possible HDR modes:

  • HDR-DDR Double Data Rate – Data transfers on both clock edges, permitting throughput up to 20 Mbit/s (25 Mbit/s raw bit rate)
  • HDR-TSP Ternary Symbol for Pure Bus – Increases throughput by using both SDA and SCL wires for data. Not allowed on mixed I2C–I3C bus.
  • HDR-TSL Ternary Symbol for Legacy Bus – Permits buses including I2C devices (with a spike filter) to operate at higher speeds.

I2C features not supported in I3C
  • Pull-up resistors are provided by the I3C master. External pull-up resistors are no longer needed.
  • Clock Stretching – devices are expected to be fast enough to operate at bus speed. The I3C master is the sole clock source.
  • I2C 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. "MIPI I3C and I3C Basic". mipi.org.
  2. "MIPI Alliance opens access to its MIPI I3C Sensor Interface Specification".
  3. "MIPI Alliance releases MIPI I3C sensor-interface specification". www.evaluationengineering.com.
  4. "MIPI makes market push for I3C sensor interface". 14 December 2017.
  5. http://www.eetimes.com/document.asp?doc_id=1324598
  6. http://ip.cadence.com/uploads/1075/Cadence_Brochure_MIPI_I3C_Slave_Controller-pdf
  7. "VC Verification IP for MIPI I3C". www.synopsys.com.
  8. "MIPI I3C Family for Sensor and IoT Applications" (PDF). silvaco.com.
  9. "Lattice gives iCE40 more power, I/O and memory". 12 December 2016.
  10. "SDM845 Specs".
  11. "MIPI I3C". mipi.org.
  12. "LKML: Boris Brezillon: [PATCH v2 0/7] Add the I3C subsystem". lkml.org.
  13. "Renesas Introduces New I3C Bus Extension Products". 6 June 2020.
  14. Inc, MIPI Alliance. "MIPI I3C Sensor Sessions at MIPI DevCon2016". resources.mipi.org.
  15. http://mipi.org/sites/default/files/MIPI%20+%20MIG%20Member%20Sensor%20Interface%20Survey%20Results%20final.pdf
  16. MIPI Alliance (23 September 2016). "MIPI DevCon 2016: A Developer's Guide to MIPI I3C Implementation".
  17. MIPI Alliance (23 September 2016). "MIPI DevCon 2016: MIPI I3C High Data Rate Modes".
  18. Group, Ken Foust, Chair of the MIPI I3C Working Group and MIPI I3C Basic Ad Hoc Working. "MIPI Alliance Delivers New I3C Basic Specification". resources.mipi.org. Retrieved 2020-04-06.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.