MIPI I3C is a serial communication interface specification that improves upon the features, performance, and power use of I²C, while maintaining backward compatibility for most devices.
MIPI I3C Basic is technically identical to MIPI I3C, except with a reduced feature set and RAND-Z licensing.
The official name is MIPI Alliance Improved Inter Integrated Circuit.
The main purpose of MIPI I3C is threefold:
MIPI I3C’s purpose is now widening to cover many types of devices currently using I²C/SMbus, SPI, and UART.
MIPI I3C carries the advantages of I²C in simplicity, low pin count, easy board design, and multi-drop (vs. point to point), but provides the higher data rates, simpler pads, and lower power of SPI. I3C then adds higher throughput for a given frequency, in-band interrupts (from Slave to Master), dynamic addressing, advanced power management, and hot-join.
I3C has two signal lines: Data (SDA) and Clock (SCL).
No, I3C Masters control an active pull-up resistance on SDA, which they can enable and disable. This may be a board-level resistor controlled by a pin, or it may be internal to the Master.
I3C was initially intended for mobile applications as a single interface that can be used for all digitally interfaced sensors. However it is now intended for all mid-speed embedded and deeply embedded applications across sensors, actuators, power regulators, MCUs, FPGAs, etc. The interface is also useful for other applications, as it offers high-speed data transfer at very low power levels while allowing multi-drop, which is highly desirable for any embedded system.
While I²C has seen wide adoption over the years, it lacks some critical features – especially as mobile and mobile-influenced systems continue to integrate more and more sensors and other components. I²C limitations worth mentioning include: 7-bit fixed address (no virtual addressing), no in-band interrupt (requires additional wires/pins), limited data rate, and the ability of Slaves to stretch the clock (thus potentially hanging up the system, etc.). I3C aims both to fix these limitations and to add other enhancements.
The power consumption per bit transfer in all I3C modes is more efficient than I²C, due to the use of push-pull (vs. open-drain) and strong pull-up signaling.
Further, I3C can save considerable device power through higher data rates (because the device can be put back to sleep sooner), built-in configuration and control (without intruding on the main communication protocols), in-band interrupt (IBI) as a low-cost wake mechanism, and the ability for Slaves to shut down all internal clocks while still operating correctly on the I3C Bus.
Yes, a number of companies have released products which feature integrated I3C Master and I3C Slave support. Other companies offer IP blocks and associated verification software for adding I3C Bus support into various integrated circuit designs. Some companies also offer protocol analyzers and verification hardware to help analyze I3C Bus traffic for testing and development.
Since this document cannot provide a comprehensive list of such products, those who are interested in learning more about products that support or enable I3C should contact MIPI Alliance.
I3C offers dynamic address assignment, Slave-initiated communication, and significantly higher communication speeds than I²C.
Yes, most I²C Slave devices can be operated on an I3C Bus, as long as they have a 50 ns glitch filter and do not attempt to stall the clock. Such use will not degrade the speed of communications to I3C Slaves; it will require decreased speed only when communicating with the I²C Slaves.
I3C Slave Devices with a Static Address can operate as I2C Slaves on an I2C bus; optionally, they can also have a 50 ns spike filter.
The I3C Bus is limited to around a dozen devices.
Yes, multi-Slave I3C chips are possible.
Yes, both I3C and I²C can share the same bus. For details, see question above regarding I3C backward compatibility.
I3C has several Modes, each with associated bit rate(s). The base raw bitrate is 12.5 Mbps, with 11 Mbps real data rate at 12.5 MHz clock frequency (this is the only Mode supported in I3C v1.0 and I3C Basic v1.0). The maximum raw bitrate is 33.3 Mbps at 12.5 Mhz, with real data rate of 30 Mbps; this is achieved via HDR Modes that are currently only available in I3C v1.0.
Most traffic will use the 10 to 11 Mbps rate, while large messages can use one of the higher data rate Modes.
Yes, I3C Slaves can initiate communication. Communication conflicts are solved by Slave Address Arbitration.
Yes, I3C allows for multiple Masters on the same Bus. I3C has one Main Master that initially configures the Bus and acts as the initial Current Master. Optionally, the Bus can have one or more Secondary Master Devices that initially act as Slaves. Any Secondary Master Device can request to become the Current Master. Once the Current Master agrees to the request, and transfers Current Master control (‘Mastership’) to a given Secondary Master Device, then that Device becomes the Current Master.
The basic byte-based messaging schemes of I²C and SPI map easily onto I3C. Additionally, a set of common command codes (CCCs) has been defined for standard operations like enabling and disabling events, managing I3C‑specific features (e.g., Dynamic Addressing, Timing Control, etc.), and other functions. CCCs can be either Broadcasted (i.e., sent to all Devices on the I3C Bus), or else Directed at a particular Device on the I3C Bus.
CCCs do not interfere with, and do not consume any of the message space of, normal Master‑to‑Slave communications. That is, I3C provides a separate namespace for CCCs.
The CCCs are the commands that an I3C Master uses to communicate to some or all of the Slaves on the I3C Bus. The CCCs are sent to the I3C Broadcast address (which is 7’h7E) so as not to interfere with normal messages sent to a Slave. In other words, CCCs are separated from the standard “content protocol” used by normal messages, such as Private Write and Read transfers (in SDR Mode).
The CCCs are used for standard operations like enabling/disabling events, managing I3C‑specific features, and other Bus operations. CCCs can be either Broadcasted (i.e., sent to all Devices on the I3C Bus), or else Directed at specific Devices on the I3C Bus. All CCCs (i.e., the command numbers themselves) are allocated by MIPI Alliance, and some are reserved for specific purposes including MIPI Alliance enhancements and other extensions.
SPI requires four wires and has many different implementations because there is no clearly defined standard. In addition SPI requires one additional chip select (or enable) wire for each additional device on the bus, which quickly becomes cost-prohibitive in terms of number of pins and wires, and power. I3C aims to fix that, as it uses only two wires and is well defined.
I3C covers most of the speed range of SPI, but is not intended for the highest speed grades that really only work well with a point-to-point interface, such as for SPI Flash.
MIPI I3C v1.1 is an advancement of the MIPI I3C Specification that includes not only clarifying edits to make for a more easily‑implemented interface, but also new optional features that make I3C even more attractive to a broader set of use cases and industries.
The new features include:
Almost all new features of I3C v1.1 are optional.
However, it should be noted that:
MIPI recommends that Slaves consider support of improvement features (such as Flow control for HDR, and Group Addressing), as well as features they likely could use for their application.
The Directed form of the RSTDAA CCC is not supported in I3C v1.1.
The new features include:
Additionally, many clarifying edits have been made to the Specification, and the GETHDRCAPS CCC has been replaced with the GETCAPS CCC (which is required for I3C v1.1 Devices).
All I3C Slaves come up in I2C mode, as they do not yet possess a Dynamic Address. If they have an I2C static address, then they may operate on a legacy I2C bus, using that static address. I3C Slaves may also support an I2C 50 ns Spike filter for Fm and Fm+ modes, and they may support other I2C features that are not supported by I3C (such as Device ID). All I3C Masters will emit the first START,7’h7E slowly enough to be seen through an I2C Spike filter, allowing the I3C Slaves to disable the spike filter once they see the first START,7’h7E.
If the I3C Slave does not have an I2C‑type static address, then it will simply wait for the START,7’h7E from an I3C Master. Such a Slave would be of no value on a legacy I2C bus, as I2C relies on each slave having a static address.
Note that I3C Slaves should not use I2C Clock stretching unless they know with certainty that they are on a legacy I2C Bus. I3C Masters are never required to support I2C Clock stretching, so the I3C Slave must not use that facility unless it has reason to know it is safe to do so (i.e., that it is on a legacy I2C bus). (Note also that an I3C Master may choose to support I2C Clock stretching when communicating with a legacy I2C Slave, though that is outside of the scope of the I3C Specification.)
No. If an I3C Slave will be used only on I3C Buses that rely on the SETAASA CCC (which auto-sets the Slave’s Dynamic Address from its I2C Static Address) and/or the SETDASA CCC (where the Master sets the Slave’s Dynamic Address using a Direct CCC that references its I2C static address), then that Slave would never be asked to use DAA and could participate on the I3C Bus without implementing DAA. However, MIPI Alliance strongly recommends supporting the DAA (ENTDAA) approach as well, otherwise the Device will only ever be usable on that narrow subset of I3C Buses.
Once assigned an I3C Dynamic Address, an I3C Slave normally retains it until the Slave is de-powered. However, an I3C Slave will lose its I3C Dynamic Address through the RSTDAA Broadcast CCC, which resets all I3C Slaves back to their initial I2C state. The RSTDAA Broadcast CCC is not normally used; it would only be used to assign a new Dynamic Address.
An I3C Slave might also lose its Dynamic Address if the Device is reset: for example, pin-reset, full Slave Reset (starting with I3C v1.1), deepest-sleep (power down), etc. In the case of an I3C Device losing its Dynamic Address in non-standard ways, the Hot-Join mechanism is provided to allow the Slave to notify the Master of the event and receive a new Dynamic Address. In cases where the Master has deliberately caused the Slave to lose its Dynamic Address (e.g., by sending the RSTDAA CCC, or by causing a Slave reset), the I3C Master will start a new Dynamic Address Assignment process using the ENTDAA, SETDASA, or SETAASA CCC.
See also Offline Mode for I3C Slaves, where the Devices retain their Dynamic Addresses through a power‑down or deepest‑sleep cycle.
CCCs in I3C v1.1 are defined and marked differently than in I3C v1.0, in two important ways:
Note:
This last point means that if an I3C Device does not acknowledge a given CCC in a given HDR Mode, then the I3C Master can determine whether that CCC is only unsupported in that HDR Mode (vs. is not supported at all) by retrying that same CCC in SDR Mode.
The coding and framing details for CCCs have been changed or extended, in three important areas:
Example: An I3C Master might use the MLANE CCC (Section 5.1.9.3.30) to configure an I3C Slave Device to use a specific Multi-Lane configuration using a Direct SET CCC, followed by a Direct GET CCC to read back the active Multi-Lane configuration and confirm that it was selected for operation. Using both forms of Direct SET CCC and Direct GET CCC within the same SDR frame is considered a Direct SET/GET CCC.
Depending on the particular CCC, this Defining Byte can be used in several possible ways:
Example: When used with the MLANE CCC, a Defining Byte selects a sub‑command. One sub-command might be used to read the available Multi-Lane capabilities for an I3C Slave Device, as a Direct GET CCC; another sub-command might be used to either configure an I3C Slave Device to use a specific Multi-Lane configuration, or read back the same active Multi-Lane configuration, as either a Direct GET CCC or a Direct SET CCC. For this use case, each Defining Byte has a different purpose and a different, specific data format.
Example: A Defining Byte for the GETCAPS CCC (see Section 5.1.9.3.19) selects among several different capabilities areas, to read from an I3C Slave Device as a Direct GET CCC. For this use case, the Defining Byte may also indicate different formats for the data message returned by the I3C Slave Device.
For some new Direct CCCs defined in I3C v1.1, a Defining Byte is required.
Many Direct GET CCCs that allow optional Defining Bytes also have a method for indicating whether any additional Defining Bytes are supported. This support would be indicated in the data message returned by the Direct version of a particular CCC (which might be the same CCC) when sent without a Defining Byte. This allows an I3C Master to query an I3C Slave Device to determine whether this capability is supported. The particular CCCs that allow optional Defining Bytes are defined in version 1.1 of the I3C Specification (see Section 5.1.9.3). Additionally, for I3C Slave Devices that support such Direct CCCs and also support any optional Defining Bytes, a Defining Byte value of 0x00 generally results in the same behavior as when no Defining Byte is sent.
While Defining Byte support for such Direct GET CCCs is generally optional, certain Defining Byte values are required or strongly recommended for certain use cases, or when used in conjunction with other features or capabilities. Such Direct CCCs list these conditions or recommendations, in addition to any changes in the format of the data message that might be returned when a Defining Byte is used.
Example: In I3C v1.1, an I3C Master can use the GETSTATUS CCC (see Section 5.1.9.3.15) to determine the operational status of an I3C Slave Device. All I3C Slaves support the use of GETSTATUS without a Defining Byte. But if an I3C Slave also supports the GETSTATUS CCC with any optional Defining Bytes, then the I3C Master may also do either of the following things:
In general, the ranges of command codes that are defined for Vendor or Standards use in Table 16 in Section 5.1.9.3 (i.e., the main table that defines the I3C Common Command Codes) can be used by any implementer or any standards developing organization to define custom CCCs that extend I3C to accommodate new use cases. However, the definition of custom CCCs should be considered carefully, as the practical issues of implementation might lead to situations where interoperability could be affected, across multiple I3C Slave Devices that interpret the same command code differently.
For example, different implementers or standards groups might define a custom CCC using the same command code (i.e., byte value for the CCC) with different interpretations of the message format that their custom Slave Device should return, for a Direct GET CCC; or different expectations about how their custom Slave Device should act, for a Direct SET CCC; or different expectations about which Defining Bytes might be supported for this CCC, for their custom Slave Device. For these conflicting definitions, interoperability issues would certainly arise if the Master used this custom CCC on an I3C Bus that used custom Slave Devices from multiple implementers, or custom Slave Devices that conformed to different standards published by several such standards groups. The Master would not necessarily have knowledge of this situation until it detected protocol issues or encountered other errors.
To help alleviate this situation, I3C v1.1 adds a new SETBUSCON CCC (see Section 5.1.9.3.31) that allows the Master to set the Bus context. This CCC informs Slaves about which version of I3C is used on the Bus, and whether it is a standards-based Bus, and/or a Vendor-private Bus. This information allows the Slave to coordinate its interpretation of extended CCCs, as well as other uses of the Bus, to match the actual current Bus context. The SETBUSCON feature is fully optional, but provides a powerful way to align standards-group-based uses of I3C with coordinated private uses. To foster proper coordination, SETBUSCON Context Byte values are published on the MIPI Alliance public website
[MIPI11] , and may be assigned by request.MIPI Alliance strongly recommends that standards groups utilize the SETBUSCON CCC to prevent such interoperability issues, by requesting an assigned Context Byte for their particular usage, which might include a specific interpretation of any command codes that are defined for Vendor or Standards use. Additionally, such custom Slave Device implementations should not enable this custom interpretation by default, until they receive the SETBUSCON CCC with an assigned Context Byte from the I3C Master.
MIPI Alliance offers a similar recommendation to implementers seeking to define custom CCCs for private use in a custom Slave Device, by using similar logic in such a Slave implementation to not enable this custom interpretation by default, until receiving the SETBUSCON CCC with a suitable Context Byte from the I3C Master to explicitly enable a private interpretation.
For most use cases, custom CCCs (including the command codes that are defined for Vendor or Standards use, see Q1.31) should generally be used as configuration or control commands, sent from an I3C Master to one or more I3C Slave Devices. Using custom CCCs for larger data transfers is not recommended.
When considering the practical concerns of implementing support for custom CCCs in an I3C Slave, it is important to note that CCCs in I3C are generally used as shorter messages that are separated from the standard content protocol (i.e., Write and Read transfers in SDR Mode, or any HDR Modes) and are not intended to interfere with normal messages sent to a Slave (see Q1.20).
Additionally, since the Command Code and Defining Byte for CCCs are sent to the I3C Broadcast Address (i.e., 7’h7E) and rely on a special ‘modality’ that must be observed by all Slaves, handling for custom CCCs might need to be implemented differently within the Slave.
With these considerations in mind, implementers should consider using custom CCCs for special purposes, taking advantage of the CCC flows and their separation from the content protocol, to affect changes to the flow or meaning of transfers that are used in their content protocol. By contrast, transfers within their content protocol (such as Write or Read transfers in SDR Mode, or any HDR Modes) should be used for data‑intensive transactions. In most cases, custom CCCs should enable new mechanisms for configuring or controlling a Slave Device, while transfers in their content protocol should be used for data transfers between a Master and a Slave.
The following examples are provided as guidance for custom CCC definitions:
For other use cases that do not generally follow these guidelines, or use cases that rely on larger message lengths for data-intensive transactions, a content protocol that primarily uses standard transfer commands (i.e., not CCCs) is strongly recommended. Using custom CCCs for data-intensive transactions on the I3C Bus might cause implementation issues for various Slave Devices that are based on Peripheral logic and use “software” to handle the response for custom Direct GET CCCs. Additionally, using custom CCCs might introduce integration issues or other platform power concerns that might only appear on I3C Buses with other Slave Devices which would not have been fully optimized to ignore such custom CCCs, or with other Slave Devices that relied on different interpretations of custom CCCs and might not understand a particular use of SETBUSCON for the use case (as defined in Q1.31). For such situations, it might not be possible to predict these issues in advance, until full system integration testing is performed.
Note that higher-level use cases could use a mix of Write/Read transfers for the content protocol, along with custom CCCs for targeted configuration and control functions, which would take advantage of the strengths of CCCs as well as the ways in which CCCs are well-suited for effective changes to control, modes or operational parameters of an I3C Slave Device. For some specific aspects custom CCCs might be recommended, whereas other use cases involving multiple endpoints might be better served with Virtual Slave capabilities (see Q1.34 for more details) if such endpoints would need to be used simultaneously.
Implementers seeking more specific guidance or recommendations should contact the I3C WG within MIPI Alliance for assistance.
The Offline capability, which is now indicated in the Bus Control Register (BCR), allows a Slave to become inactive on the I3C Bus at some times, but then return to normal activity later.
There are two basic types of Offline‑capable Slave:
These Slaves can be awakened (i.e., can be re‑activated) by a Slave Reset or by the use of their Dynamic Address. They will take some time to become active on the Bus again, such as the RSTACT CCC recovery from Full Reset time. During the time that they are offline, and while awakening, they will not be responsive to the Master, nor will they record CCCs, nor will they necessarily retain state (e.g., the ENEC/DISEC CCCs), so the Master will have to wait for them to become active, and then might also need to configure them again. This is all by private contract (agreement).
See details in Section 5.1.10.2.5 for both I3C v1.0 (without Slave Reset) and I3C v1.1 (with Slave Reset).
Generally, a Virtual Slave is a function of a single physical Device that represents multiple I3C Slaves on the I3C Bus, such that the I3C Master can address each of those Slaves independently.
In the simplest form a Virtual Slave could be one of a set of several Slave Devices all integrated into the same physical package, sharing a common set of pins connecting them to an I3C Bus.
In a more advanced form, a Virtual Slave could act as one of several virtualized functions presented by a highly‑integrated Device that stores a different Dynamic Address for each function. Depending on the implementation, such virtualized functions might share configuration information, and might return the same values for some CCCs.
Examples could include Bridging or Routing Devices, as well as other types of Devices that expose multiple functions and use shared Peripheral logic. I3C v1.1 defines several new capabilities and features for such Virtual Slaves.
See the I3C v1.1 Specification at Section 5.1.9.3.19, and the System Integrators Application Note for I3C
[MIPI05] at Section 5.7.Yes. I3C v1.1 defines requirements, expectations, and configuration for Routing Devices, which enable the creation of multiple Routes across I3C Buses. A Routing Device enables more advanced Bus topologies and requires buffers or queues to handle transactions across each Route.
The Routing Device contains a Control Function, presented on the I3C Bus as a Virtual Slave. The Master configures the Routing Device by sending the SETROUTE CCC to the Control Function. Routes to other I3C Buses are treated as downstream targets, each of which generally has a Target Function which is also presented as a Virtual Slave with its own Dynamic Address. Transactions are sent to the Route’s Target Function via its Dynamic Address, and the Routing Device manages the communications on the downstream I3C Bus.
See the I3C v1.1 Specification at Section 5.1.9.3.20, and the System Integrators Application Note for I3C
[MIPI05] at Section 5.7.All three are special, in-band methods that allow the Slave to notify the Master of a new request or state, without having to wait for the Master to query or poll the Slave(s). The term ‘in-band’ refers to doing this via the I3C Bus wires/pins themselves, rather than using methods requiring extra wires/pins.
The system designer decides whether their system needs more than one Master on the Bus. To provide that flexibility MIPI I3C allows this, but also does not require it. Master handoff is a well defined and controlled mechanism in I3C; if used, it can be relied on.
For most use cases, a Secondary Master is not a required component for an I3C Bus. If your Main Master has all the capabilities and features that you need, and if your use of the I3C Bus wouldn’t benefit from having multiple Master-capable Devices, then you might not need a Secondary Master.
Examples where Secondary Masters are useful:
Note that Devices such as MCUs will usually be able to operate as fully-fledged Slaves, as fully-fledged Main Masters, and as Secondary Masters (i.e., Devices that come up as Slaves but can become Masters), depending solely on the particular needs of the given system. They can simply be configured for the Bus they are on by the firmware.
I3C supports legacy I2C devices using Fast-mode (Fm, 400 KHz) and FastMode+ (Fm+, 1 MHz) with the 50 ns spike filter, but not the other I2C modes, and not devices lacking the spike filter, or that stretch the clock.
Much of the activity on the I3C Bus is in push-pull mode (that is, with the pull-up resistor disabled) in order to achieve higher data rate. However for some Bus management activities, and for backwards compatibility with I2C, pull-up-resistor-based open-drain mode is enabled. For example: arbitration during Dynamic Address Assignment, and In-Band Interrupt. Also, the ACK/NACK during the 9th bit is done using a pull-up resistor. With few exceptions, it is the responsibility of the I3C Master to provide an open-drain class pull-up resistor when the Bus is in the open drain mode.
A high-keeper is used for Master-to-Slave and Slave-to-Master bus hand-off, as well as optionally when the Bus is idle. The high-keeper may be a passive weak pull-up resistor on the Bus, or an active weak pull-up or equivalent in the Master. The high-keeper only has to be strong enough to prevent system-leakage from pulling the Bus low. At the same time, the high-keeper has to be weak enough that a Slave with a normal IOL driver is able to pull the Bus line low within the minimum period.
During bus initialization, the I3C Master assigns a 7-bit Dynamic Address to each Device on the I3C Bus. For this to happen, each Slave device must have a 48-bit Provisional ID (that is, provisioned with its ID). The Provisional ID has multiple fields, including MIPI Manufacturer ID and a vendor-defined part number. The I3C Slave may also have a static address, which if the Master knows it, allows for faster assignment of the Dynamic Address.
The first part of the ID contains a unique manufacturer ID. Companies do not have to be MIPI Alliance members to be assigned a unique manufacturer ID.
The second part of the ID normally contains a part number (which is normally divided up into general and specific part info for that vendor), as well as possibly an instance number which allows for multiple instances of the same device on the same I3C Bus. The instance ID is usually fed from a pin-strap, or fuse(s), or non-volatile memory (NVM).
A random number may be used for the part number, although normally only for test mode, as set by the Master using the ENTTM (Enter Test Mode) CCC. When a Device that supports random values enters the test mode, the PID[31:0] bits are randomized. When the Master exits the test mode, the Devices reset bits PID[31:0] to their default value. The use of a random number allows for many instances of the same Device to be attached to a gang programmer/tester, relying on the random number to uniquely give each a Dynamic Address.
With most configurations, this is not possible; each Device will have its own manufacturer ID and part number, so no collisions are possible. If more than one instance of the same Device is used on the same I3C Bus, then each instance must have a separate instance ID; otherwise there would be a collision. Likewise, if any Device is using a random number for its part number, then multiple instances from that manufacturer could collide (i.e., could have the same random value that time).
If the Master knows the number of Devices on the I3C Bus, then it can detect this condition: the number of Dynamic Addresses assigned would be less than the number of Devices. Once detected, the I3C Master can take steps to resolve such collisions, for example by resetting DAA and restarting the process, or by declaring a system error after a set maximum number (e.g., 3) of such attempts fail.
All I3C Devices must be able to process Broadcast CCCs at any time, whether or not they have been assigned a Dynamic Address (DA). For example, an I3C Device may act as an I²C device before it gets its DA assigned. However, it is still expected to ACK the START with 7’h7E; the only exception would be if this Device chooses to remain as an I²C‑only device, in which case, it would leave any 50 ns spike filter enabled. For those Devices that do recognize START and address 7’h7E, those may see any CCC and not just ENTDAA (Enter DA Assignment) or SETDASA (Set Dynamic Address from Static Address). See the I3C Specification for the required CCCs. The Device can determine the effect of each CCC based on whether or not it has the Dynamic Address assigned (e.g., the RSTDAA CCC [Reset DA Address] will probably have no effect before the DA has been assigned).
In addition to open drain, pull-up and high-keeper, the I3C Bus has three distinct conditions under which the Bus is considered inactive: Bus Free, Bus Available, and Bus Idle.
For normal active I3C Slaves, yes. They should only drive the Bus for an In-Band Interrupt (IBI) when they have seen a STOP and the tBusAvailable time has elapsed (about 1 µs), and in response to a START (but not a Repeated START).
For Hot-Join devices, they do not know the Bus condition, so they wait until the bus is Idle, which means the SCL and SDA are both high for the tIDLE period (about 1 ms).
An I3C Slave can issue the IBI in the following two ways:
The I3C Bus protocol supports a mechanism for Slaves to join the I3C Bus after the Bus is already configured. This mechanism is called Hot-Join. The I3C Specification defines the conditions under which a Slave can do that, e.g., a Slave must wait for a Bus Idle condition.
Only if they have a way to turn off the Hot-Join feature. Hot-Join is not compatible with I2C masters, so Hot‑Join would have to be disabled for the Slave to be used on a legacy I2C bus. The disabling of the Hot‑Join feature should be done via some feature that is not part of the I3C protocol (i.e., not via the DISEC CCC), since an I2C master does not support the I3C protocol.
The I3C Bus Activity States provide a mechanism for the Master to inform the Slaves about the expected upcoming levels of activity or inactivity on the Bus, in order to help Slaves better manage their internal states (e.g., to save power).
The four activity states and their expected activity intervals are:
Note: This question does not apply to I3C Basic v1.0.
Yes. The I3C Bus supports an optional Timing Control mechanism with multiple timing modes. One timing mode is synchronous (from the synchronized timing reference) and four modes are asynchronous (Slave provides timestamp data). All I3C Masters are expected to support at least Async Mode 0.
There are four types (timing modes) of asynchronous time controls:
By default, there is no limit to the maximum message length. To reduce Bus availability latency across multiple Slaves, the I3C Bus allows negotiating for maximum message lengths between Master and Slave. Further, Read terminate is possible from the Master, to allow regaining control of the Bus under a long message.
Bridge Devices are expected to enable an I3C Bus to be bridged to other protocols, such as SPI, UART, etc. A CCC is defined to enable bridging Devices, where the Master knows in advance that certain Devices are bridges.
All I3C Slaves must be tolerant of the 12.5 MHz maximum frequency, and all Slaves must be able to manage those speeds for CCCs. But Slaves may limit the maximum effective data rate for private message – either write, read, or both.
Yes. A pair of Directed and Broadcast CCCs is available for the Master to enter/exit the test modes.
Yes, the I3C Bus has elaborate error detection and recovery methods. Seven Slave error types (S0 to S6) and three Master error types (M0 to M2) are defined for SDR Mode, along with suggested recovery methods. Similarly, a set of errors are defined for each of the HDR Modes.
Note: This question does not apply to I3C Basic v1.0.
The CRC transmission ends at bit 6 (counting down from 15), but bit 5 allows High-Z.
The STOP can be issued anywhere the Slave is not driving the SDA during SCL High. It may not be appropriate to do so in terms of completion of a message. But ACK and completed transaction do not belong together in I3C.
The Protocol Error Report on the GETSTATUS CCC is intended to report on errors that have no other way of being detected unless the Device reports them. It is intended to cover parity error, CRC error, and anything else that means that a message from the Master was lost and the Master has no way of knowing it.
The Protocol Error Report on the GETSTATUS CCC would not cover the case of S5 errors, as they are more related to an unsupported CCC or Defining Byte which is not a protocol error per se. It is also not intended for situations when the Slave NACKs, because the Master will know that an error occurred when the Slave NACKs and recovers it. Errors like S0, S3, S4, and S5 are detected by the Master when the Slave sends a NACK response, and are recovered by using the appropriate recovery methods; as a result, they do not need to be reported via the GETSTATUS CCC.
Due to confusion around the use of the words “illegally formatted” in I3C v1.0, it was critical in I3C v1.1 to more precisely define what errors are considered to be S5 Errors. The S5 Error covers only four cases of Errors, as follows.
The first two errors are Unsupported CCC and Unsupported Defining Byte, both of which are ignored by Slaves if not supported. The Slaves should wait for the appropriate exit condition in cases where these commands have an special exit condition.
The other two cases are when the master sends the Wrong RnW Bit for a Direct CCC command. This means that the Master sends a Dynamic Address and Read for a Direct Write CCC command, or vice versa. In these cases the Slaves send a NACK, notifying the Master that an error has occurred. The Master will then use the Retry and Escalation models.
Additional Data on CCC Payloads, and Additional Defining Bytes, are not error conditions. Slaves should ignore any additional unrecognized data bytes, per the I3C v1.1 Specification at Section 5.1.9.2.2.
These errors should be recovered by STOP. But vendors can choose to recover from these errors when seeing a Repeated START. Note that STOP is the second step of escalation after Repeated START recovery.
The RSTACT state will be cleared back to default upon either:
Although MIPI Alliance strongly recommends true support of Slave Reset, such that a Master can fully reset a Slave chip when needed, it is not required. Full Chip Reset allows replacement of the SRSTn trace that would normally be used to reset a Device.
The minimal reset is a reset of the I3C peripheral, at least to a level that will allow a ‘stuck’ I3C peripheral to start working again. How much of a reset that requires is up to the Slave Vendor; for example, it could be handled by an internal interrupt which would allow firmware/software in the Slave to handle the reset.
If the Slave does not receieve a RSTACT CCC before seeing the Slave Reset Pattern, then it uses the default action of Peripheral Reset (i.e., reset just the I3C block). If the Slave again receives no RSTACT CCC before seeing a Slave Reset, then it then escalates to a Full-Chip Reset. It therefore holds the state after any default Peripheral Reset, so as to activate the escalation. That state is cleared if the Slave sees either an RSTACT CCC, or a GETSTATUS CCC addressed to it.
The purpose of this mechanism is to fix a broken system or setup. Because the Slave Reset Pattern Detector logic is normally separated both from the I3C block and from other parts of the main system, it will continue to work even if the rest of the chip has become broken (e.g., clocks stopped, Bus locked up, etc.). This means that not seeing a RSTACT CCC would be a symptom of a large problem, so the Slave escalates in order to recover from such a broken condition. The Slave first performs a Peripheral Reset, in case the fault condition exists only in the I3C block itself.
Yes. The I3C Master must emit the first START, 7’h7E at Open-Drain speeds (usually I2C Fm+ speeds) so that I3C Slaves with I2C Spike Filters will be able to see the I3C Broadcast Address, and then as a result turn off the Spike Filter. If the Master knows that none of the I3C Slaves has a Spike Filter, then it may omit this. Similarly, if the Master knows that all of the I3C Slaves have accurate Spike Filters, then it may use the I3C 2.5 MHz open-drain speed (i.e., 200 ns Low, 200 ns High).
In I3C v1.1, Table 10 (I3C Open Draining Timing parameters) lists the tHigh symbol as having a maximum value of 41 ns, and then Note 4 says that “tHigh may be exceeded when the signals can be safely seen by I2C Slaves”. This means that a 41 ns tHigh will ensure that no legacy I2C Slave will see the SCL changes, and so will not interpret the START followed by the Address phase nor the ACK/NACK. The Master may use a much longer tHigh if there is no harm with a legacy I2C Slave on the I3C Bus seeing the clocks. For example, the legacy Slaves will see the STOP and then a START. It is acceptable for them to see the Address that follows (arbitrated or not), since none of those Addresses will match their own Address. However, as the tLow may well be 200 ns, this may present problems for any legacy I2C slaves not fast enough to correctly handle a 200 ns Low period.
This topic is extensively explained in the I3C v1.1 Specification at Section 5.1.9.3.18.
Yes. An I3C Slave is expected to monitor Broadcast CCCs; the special exception is for Hot-Join Slaves, as explained below.
The Slave should process all supported Broadcast CCCs, but it is required to process supported ones that affect Bus state. This includes the ENTHDRn CCCs (which turn the HDR Exit Detector on), as well as the ENEC and DISEC CCCs for whatever events the Slave supports (e.g., IBI).
As a practical matter the I3C Main Master will not generally use any CCCs other than Dynamic Address assignment while bringing up the I3C Bus, but it is allowed to use Bus state CCCs as needed.
For a Hot-Join Slave, this rule only applies once the Slave is safely on the I3C Bus and capable of starting a Hot-Join. So, as a general rule, the Slave will emit the Hot-Join request before the I3C Master is able to emit any Broadcast CCCs. However, after that, the Slave may see one or more Broadcast CCCs prior to being assigned a Dynamic Address.
Please see the I3C v1.1 Specification at Section 5.1.3.1.
At Section 5.1.9.2.3 the I3C v1.1 Specification states: “I3C mandates a single-retry model for Direct GET CCC Commands.” Based on this statement, adopters have a general notion that the Master is required to retry once for the Directed GET CCCs if the Slave NACKs for the first time. This may not be applicable for other “read” Directed CCCs (such as RSTACT, MLANE, vendor read, etc.) that are not defined for dedicated Read CCCs (i.e., CCCs that have names of the form GETxxx).
The I3C Specification is defined by the MIPI Alliance I3C Working Group (originally named the Sensor Working Group) which was formed in 2013. I3C Basic is defined by the MIPI Alliance I3C Basic Ad-Hoc Working Group which was formed in 2018.
Under the original name of “MIPI Sensor Working Group,” representatives from AMD, Broadcom, Cadence, IDT, Intel, InvenSense, Knowles, Lattice Semiconductor, MediaTek, Mentor Graphics, Nvidia, NXP, Qualcomm, QuickLogic, Sony, STMicroelectronics, Synopsys, VLSI Plus, and others created the MIPI I3C v1.0 and MIPI I3C Basic v1.0 Specifications. The WG was (and is still) chaired by Ken Foust of Intel, and vice-chaired by Satwant Singh of Lattice Semiconductor.
A few vendors have provided FPGA based design kits, including some low-cost FPGAs that might be good enough for smaller production runs.
Some vendors have started to offer Slave and/or Master IP cores for integration into ASIC devices and FPGAs, including a free-of-cost Slave IP available for prototyping and integration.
In 2019 the Sensor Working Group was renamed to “I3C Working Group”. Its member companies often change, but the following is a recent representation: Intel, Invensense, Lattice, NXP, Prodigy, Qualcomm, Robert Bosch, STMicroelectronics, Synopsys, and Sony.
The I3C Specification lists the maximum per-Device capacitance on SCL and SDA, but the goal is that most or all Devices will be well below that. Capacitance alone is not sufficient to determine maximum frequency on the I3C Bus (as with any Bus). It is important to consider maximum propagation length, effect of stubs, internal clock-to-data (tSCO) of the Slaves, as well as capacitive load.
The maximum wire length would be a function of speed, as all the reflections and Bus turnaround must complete within one cycle. Larger distances can be achieved at the lower speeds than at the higher ones. For example at 1 meter (between Master and Slave), the maximum effective speed is around 6 MHz for read, to allow for clock propagation time to Slave and SDA return time to Master.
Not directly, for a couple of reasons:
Long wire approaches are being evaluated for a future version of the I3C Specification.
No. The I3C CCCs are always preceded by I3C Broadcast Address, 7’h7E. Since the I2C specification reserves address 7’h7E, no legacy I2C Slave will match the I3C Broadcast Address, and thus would not respond to the I3C commands. Likewise, the Dynamic Addresses assigned to I3C Devices would not overlap the I2C static addresses, so an I2C device would not respond to any I3C address (even if it could see it).
I3C Slaves are only allowed to drive the Bus under certain situations. Besides during a read, and when ACKing their own address, they may also drive after a START (but not Repeated START). After a START, the I3C Bus reverts back to open-drain pull-up resistor mode; thus, the Slave that drives a low value (logic 0) would win.
Unlike I²C, there is no natural way to ‘hang’ the I3C Bus. In I²C, clock stretching (where the Slave holds the clock low, stopping it from operating) often causes serious problems with no fix: there’s simply no way to get the Slave’s attention if it has hung the Bus. By contrast, in I3C only the Master drives the clock, and so the Slave performs all actions on SDA relative to that clock, thereby eliminating the normal causes of such hangs.
Further, since I3C is designed to ensure that I3C Slaves can operate their back-end I3C peripheral off the SCL clock (vs. oversampling), problems elsewhere in the Slave will not translate into Bus hangs.
If a system implementer is highly concerned about a Slave accidently locking itself, then a separate hard‑reset line could be used. For the next revision of the I3C and I3C Basic Specifications, a feature called Slave Reset is being added to reset non-responsive I3C Slaves (i.e., if a Master emits a certain pattern that does not occur during regular communication, then the Devices on the Bus would treat it just like a hardwired reset line).
No. Some CCCs are mandatory, whereas others are optional and a given I3C Device will either support them or not, depending upon the Device’s capabilities.
Yes. The following MIPI Specifications are expected to help with software development:
In addition to these MIPI specifications, a supporting document is also available. The System Integrators Application Note for I3C v1.0 and I3C Basic v1.0, App Note v1.0 [MIPI105] has been developed to help ASIC hardware developers, system designers, and others working in the more deeply embedded I3C Devices. The I3C WG plans to develop an updated revision of this Application Note that will cover new features and capabilities included in I3C v1.1.
Yes. Core I3C infrastructure is being added to the Linux Kernel via patchwork.kernel.org.
It is a MIPI Alliance sponsored event where different vendors bring their I3C implementations and check interoperation with other vendors.
There are three major outputs from a MIPI I3C Interoperability Workshop:
MIPI arranges a particular I3C Interoperability Workshop event in response to requests from its membership.
In general, any MIPI Alliance members who have I3C hardware ready to interop can participate.
While this could change in future, the minimal requirements to date have been the availability of a board with an I3C Device that can connect to other Devices via the three wires SDA, SCL, and GND. It’s also useful to have software (e.g., running on a laptop connected to the board and I3C Device) to interactively view transmitted and received bus communications, but this might not be required for Slaves.
Currently there are solutions working at 3.3V and 1.8V.
Starting in 2020, MIPI Alliance plans to host interoperability workshops for I3C v1.1.
Many other MIPI Alliance Working Groups are in the process of leveraging the I3C Specification. As of the writing of this FAQ, the list includes:
Note: With the release of I3C v1.1, this question has been deprecated, but it is left here for reference. For example, see question below for what’s new in I3C v1.1.
Based on learning from the early implementations, I3C Interoperability Workshops, queries from adopters, and reviews by the I3C WG, this FAQ represents clarifications, planned improvements that can be implemented by I3C v1.0 Devices, and other hints about what’s coming next.
No, there are no pending updates at this time.
No, there are no pending errata at this time.
There are no immediate plans to revise I3C v1.1, however the MIPI I3C WG meets regularly and is considering proposals.
There are no new approved features, however the MIPI I3C WG is considering the following:
Note: This question does not apply to I3C Basic v1.0.
Yes. This is allowed such that the ODR (Output Data Rate) rate controls the In-Band Interrupt (IBI) rate, and the Async Mode timestamp on the IBI indicates how long ago the sample was collected.
Note: This question does not apply to I3C Basic v1.0.
Yes, the SETXTIME code of 0xFF may be used. This has been updated for I3C v1.1, please see question below.
Note: This question does not apply to I3C Basic v1.0 and I3C v1.1.
Newer versions of the I3C Specification define a new tIDLE minimum value of 200 µs, since that is sufficient for all valid uses. I3C v1.0 devices may choose to support that smaller delay now. I3C Basic v1.0 and I3C v1.0 already support a tIDLE minimum value of 200 µs.
Yes. An I3C Slave may watch for 60 µs with no SCL or SDA changes to make sure that the Bus is not in HDR Mode (and therefore must be in SDR Mode). After that, it is appropriate to wait for START (assumed to be Repeated START) or STOP.
The I3C Slave may choose to detect 100 µs without an SCL edge. If that happens, it can abandon the Read and release SDA to avoid a Bus hang when the Master restarts.
Note: This question does not apply to I3C Basic v1.0.
No. The tSCO (Clock to Data Turnaround delay time) is information provided by Slaves so that system designers can properly compute the maximum effective frequency for reads on the Bus. The tSCO number is meant to be used together with the line capacitance (trace length) and number of Slaves and stubs (if present).
However, I3C Slaves with tSCO delay greater than 12 ns must:
Note: This question does not apply to I3C Basic v1.0.
Only for Data. The Data bytes are sent the same way as in SDR Mode. The following figure shows how Data is transferred from memory to the I3C Data Line:
The Command and CRC Byte are each transferred as a packet instead:
Command (MSb to LSb):
· Preamble (2 bits)
· Command (8 bits)
· Slave address (7 bits)
· Reserved bit (1 bit)
CRC (MSb to LSb):
· Preamble (2 bits)
· Token (4 bits)
· CRC Byte (5 bits)
· Setup bits (2 bits)
Note: This question does not apply to I3C Basic v1.0.
No, there is an error in Figure 52 in the I3C v1.0 Specification. The beginning of the Restart/Exit Pattern should show SCL Low and SDA changing.
The Hot-Join mechanism allows the Master to first NACK, and then send the DISEC CCC to stop the Hot-Join. If the Master ACKs, that is interpreted as a promise that it will eventually send the ENTDAA CCC.
Yes. The SETXTIME CCC allows the code 8’hFF to be sent, and this turns off Timing. This can be used by v1.0 Slaves as well.
The I3C Slave should time out if it experiences more than 100 µs with no SCL, and abandon the read. It does not have to be precise, but since I3C’s minimum frequency is 10 KHz, anything longer than 100 µs means that the Master has failed to complete the Read, so the Slave should High-Z the SDA and abandon the Read.
Note that if the Slave is in legacy I2C mode, then it would not normally abandon the read, since there is no minimum frequency, and because 9 clocks by a Master will be enough to abort the Read (since the 9th bit of data is ACK/NACK).
In I3C v1.1, this time was reduced since no HDR Mode can exceed 100 µs due to the minimum frequency being 10 KHz. As a result, tIDLE is now 200 µs to provide an adequate timing margin.
Because the RSTDAA CCC should not be directed to just one Slave. If the Master needs to reassign a Slave address, then it can use the SETNEWDA CCC.
In I3C v1.1, use of this CCC is expanded to support Bridging Devices with Dynamic Addresses, enabling multiple Bridging Devices on the same I3C Bus. The context of this CCC is also redefined, such that a Bridging Device is now one of several types of Devices that expose or present Virtual Slaves. Bit[4] of the Bus Configuration Register (BCR) now indicates Virtual Slave capabilities.
For bridged Slaves that are enabled by a Bridging Device, I3C v1.1 clarifies the use of other CCCs (such as SETMRL) that address a bridged Slave. I3C v1.1 also clarifies that the SETBRGTGT CCC must be used to change the Dynamic Address of a bridged Slave (not the SETNEWDA CCC).
See the I3C v1.1 Specification at Sections 5.1.1.2.1, 5.1.9.3.17, and 5.1.9.3.19; and the System Integrators Application Note for I3C
[MIPI05] at Section 5.7.In I3C v1.1, tCASr’s minimum value is reduced to tCASmin/2 (whereas in I3C v1.0, it is tCASmin). This reduced duration might be a challenge for some Slaves. In order to prevent such situations, the Master of the Bus shall provide suitable timing, accommodating the slowest Devices on the Bus.
In the I3C v1.1 Specification, Table 111 “I3C Push-Pull Timing Parameters for SDR, ML, HDR-DDR, and HDR-BT Modes” includes a clarifying note:
9) Slaves with speed limitations inform the Master via the Bus Characteristics Register that the minimum may not be acceptable. As a result, if the given SCL HIGH period is 50 ns or greater, the Master needs to accommodate for Legacy I2C Devices that might see it.
The standard GETMXDS CCC itself was not changed in I3C v1.1, though the definition of tSCO was clarified. However, the GETMXDS CCC now supports a Defining Byte value that allows the return of other forms of information. With no Defining Byte (and with a Defining Byte with value 0), the GETMXDS CCC behaves exactly as the original GETMXDS CCC did in I3C v1.0.
A MIPI WG develops a Conformance Test Suite (CTS) document in order to improve the interoperability of products that implement a given MIPI interface Specification. The CTS defines a set of conformance or interoperability tests whereby a product can be tested against other implementations of the same Specification.
Yes. A CTS for I3C v1.0 is being drafted by the MIPI Alliance I3C WG [MIPI09].
The CTS tests are designed to determine whether a given product conforms to a subset of the requirements defined in the I3C Specification v1.0. The scope of this first version of the CTS is intentionally limited, in order to meet time-to-market requirements imposed by the rapid adoption of I3C in the marketplace, focusing on:
1. SDR-only Devices without optional I3C capabilities,
2. All Master and Slave Error Detection and Recovery methods, and
3. Basic HDR Enter/tolerance/Restart/Exit are in scope, but HDR-DDR is under consideration.
Considering the CTS a living document, the I3C WG plans to continue expanding the scope of the CTS through future revisions that eventually encompass all required and optional features of the I3C Specification.
The CTS tests are organized as Master device under test (DUT) and Slave DUT. Tests for each are presented in the order in which they appear in the I3C Specification, to simplify identification of pertinent detail between the two documents.
Interoperability Workshops will ultimately follow the tests identified in the I3C CTS, as it nears completion.
Each test in the I3C CTS will contain:
DC/AC parametric requirements will be embedded in each test, not split out into a separate PHY-related CTS or subsection.
The I3C WG is currently developing a CTS for I3C v1.1, for early 2020 release.
The parties that directly developed the MIPI I3C Basic specification have agreed to license all implementers on royalty free terms, as further described in the I3C Basic specification document [MIPI10] . Further, all implementers of the I3C Basic specification must commit to grant a reciprocal royalty free license to all other implementers if they wish to benefit from these royalty free license commitments. And, of course, MIPI itself does not charge royalties in connection with its specifications. MIPI’s intent is to create a robust royalty free environment for all implementers of I3C Basic. No set of IPR terms can comprehensively address all potential risks, however. The terms apply only to those parties that agree to them, for example, and the scope of application is limited to what is described in theterms. Implementers must ultimately make their own risk assessment.
MIPI’s regular IPR terms apply to the full MIPI I3C specification. MIPI’s terms require that members make licenses available only to other members, as described in the MIPI Membership Agreement and MIPI Bylaws. To benefit from the license commitments, a party must be a MIPI member.
For features that are included in MIPI I3C Basic, a MIPI member can implement under the regular IPR terms, or can opt to implement the feature under the I3C Basic framework. If a member opts in to the I3C Basic framework, then they must grant the reciprocal licenses required under that framework. MIPI Alliance members are not required to participate in the I3C Basic license framework, however. Features of I3C 1.x that are not included in I3C Basic are subject only to MIPI’s regular IPR terms.
Prior to the release of I3C Basic, MIPI had made certain versions of the full MIPI I3C specification available for public review, under “copyright only” terms – that is, MIPI published the specification, but noted that no rights to implement the specification were granted under any party’s patent rights. MIPI no longer publishes the full I3C specification publicly. A non-member is not granted any right to implement the full MIPI I3C 1.x specification, either by MIPI or any MIPI member.
I3C Basic is available to non-members, as described in question: How can the MIPI I3C v1.0 Specifications be obtained?.