MIPI I3C and I3C Basic Frequently Asked Questions

Yes, I3C Slaves can initiate communication. Communication conflicts are solved by Slave Address Arbitration.

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 I²C Slaves on an I²C bus; optionally, they can also have a 50 ns spike filter.

The official name is MIPI Alliance Improved Inter Integrated Circuit.

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.

Yes, multi-Slave I3C chips are possible.

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.

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.

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.

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.

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.

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.

• In-Band Interrupt (IBI): An IBI request is used by a Slave to notify the Master of a new state or event. If the Slave so indicates in the BCR, then an IBI may include one or more following data bytes. A Slave can only use IBI if it has indicated the intent to do in the BCR.
  If the Slave indicates it will send data with an IBI, then it is required to always send at least 1 byte, called the Mandatory Data Byte (MDB). Starting with I3C v1.1, the MDB is coded following certain rules. Any data after the MDB is a contract between Master and Slave.
• Hot-Join (HJ): An HJ request is used only by an I3C Slave that hasn’t yet been assigned a Dynamic Address and is attached or awakened on the I3C Bus after the Main Master has intialized it. HJ uses a fixed address reserved for this purpose only. The Master will recognize this fixed address and then initiate a new Dynamic Address Assignment procedure. Note that the HJ request cannot be used by a Slave until it has verified that the I3C Bus is in SDR Mode, as explained in the specification.
• Mastership Request (MR): A Secondary Master (including the Main Master, once it has given up initial Mastership) sends an MR when it wants to become Master of the I3C Bus. If the Current Master accepts the MR, then it will issue a GETACCMST CCC to hand control off to the requesting Secondary Master. It is also possible for the Current Master to initiate mastership handoff on its own, without any Slave initiating an MR, for example when a Seconary Master wants to return control.

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:

1. Debug controller, if present, would be a Secondary Master
2. A sensor hub or other offload device can be used to continue operating during periods when the Host processor is in deep sleep (i.e., to save power)
3. The system can switch between standalone use (such as IoT devices) and connected uses (perhaps a USB-to-I3C cable is attached to take over temporarily)

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.

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 I²C 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.

The coding and framing details for CCCs have been changed or extended, in three important areas:

1. Direct Write/Read Commands: In I3C v1.0, Direct CCCs were either Direct Read Commands (Direct GET CCC) or Direct Write Commands (Direct SET CCC). I3C v1.1 adds an additional Direct Write/Read Command (Direct SET/GET CCC) form: a Direct Write immediately followed by a Direct Read with the same Command Code; this form is used for alternatively writing to, and then reading data from, one or more specific I3C Slave Devices. The Direct Write/Read Command uses the Direct CCC framing model per Section 5.1.9.2.2.

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.

2. Defining Byte for Directed CCCs: In I3C v1.1, some Directed CCCs add support for a Defining Byte.
   
   1. In CCC framing for SDR Mode, the coding of the initial CCC is: S, 7’h7E, CCC_byte, Defining_Byte, Sr, Slave_Addr, ....
      
      For more framing details for SDR Mode, see Table 15 in Section 5.1.9.1.
   2. In CCC framing for HDR Modes, the Defining Byte is sent in the HDR-x CCC Header Block of type Indicator. This framing element is defined differently for each HDR Mode; for more framing details, see Table 53 in Section 5.2.1.2.1.

Depending on the particular CCC, this Defining Byte can be used in several possible ways:

• It might define a register/code to set, either with or without additional per-Slave info
• It might select a particular register/code to read, from among several available for that CCC
• It might indicate one of several completely different sub-commands, each of which might be either required or optional, as needed for the particular CCC definition and use case.

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.

3. New Optional Defining Bytes: In I3C v1.1, some CCCs that had no Defining Byte in I3C v1.0 now have optional Defining Bytes to extend their functionality and support other new behaviors. If the I3C Master sends the CCC without the Defining Byte then the original functionality or behavior occurs, but if the CCC is sent with the Defining Byte then the optional extended functionality or new behavior is accessed (see Section 5.1.9.2.2).

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:

• Send the Direct GET GETSTATUS CCC with a Defining Byte of 0x00, to return the same data message as if no Defining Byte were used;
• Send the Direct GET GETSTATUS CCC with any other Defining Byte value listed in Table 24. Any I3C Slave that supports that particular Defining Byte is required to ACK the CCC and return an appropriate data message for that Defining Byte (i.e., not the standard Slave Status). For example, if a Defining Byte value of 0x91 (“SECMST”) is supported, then using this Defining Byte would request the Slave to return alternate status information related to the Slave’s Secondary Master capabilities.

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:

• Configuration commands that switch between various supported formats of index or selection that might be used in a Write command, or the first phase of a two-phase Write+Read command
• Configuration commands that send a directed mode change to particular Slaves, or broadcast mode changes to all Slaves that support a particular capability or feature (if applicable)
  • Note that custom Broadcast CCCs (i.e., for Vendor or Standards use) should be used with caution, as these are received by all Slaves on the I3C Bus, and various Slaves might handle such CCCs differently (i.e., by not using a common interpretation; see Q1.31 for guidance).
• Control commands that switch between multiple endpoints within a Slave, using a multiplex model that chooses how and where a standard Write transfer might be directed and processed, or from where a Slave might source the data message for a Read transfer
  • In this case, the custom CCC acts as a command to the multiplexor logic.
  • However, such a multiplex model means that only one endpoint at a time can be selected for active use, which might present a limitation for the use case, and might restrict the modality for using such a Slave.
• Special messages sent only to the Slave hardware (i.e., the Peripheral logic) whereas the data‑intensive transfers in the standard content protocol might be implemented via software or other agents that connect to the Peripheral logic, and would not need to see such special messages
  • In this case, the Peripheral logic would be expected to offer a quick response due to CCC framing, so a shorter CCC message would offer rapid response due to the expectations based on capabilities in Peripheral logic, versus waiting for software or other agents to respond, which might lead to delays.
  • By contrast, an implementation that used Peripheral logic with software to respond to Direct GET CCCs might not be capable of successfully responding to the first such attempt, and would rely on ideal timing conditions to successfully respond to subsequent attempts.
  • Note that this might only apply to implementations that relied on software, versus implementations that handled custom CCCs natively (i.e., entirely within hardware).
• Commands that change modes to initialize new functions or enable a new modality, which might change the interpretation of standard transfers for the content protocol (e.g., firmware download, key exchange)
  • For example, a custom CCC might act as a method for entering or exiting the modality in which the standard transfers are applied to a new purpose (such as transferring new firmware contents or key data). Upon exiting the modality, the new function of the Slave would be applied based on the data transferred during the modality, and the standard content protocol would be used for subsequent operations with the new function.

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:

1. A Slave that is fully inactive on the I3C Bus (e.g., is powered off) and only becomes active again as the result of some external event. Such a Slave will then Hot‑Join to get a new Dynamic Address.
2. A Slave that is inactive on the I3C Bus, but where some portion of the Slave is monitoring the Bus either for Slave Reset, or for the use of its Dynamic Address. The Slave may be mostly powered‑off, or in deepest sleep, but the monitoring portion retains the Slave’s Dynamic Address.

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

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 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 I²C masters, so Hot‑Join would have to be disabled for the Slave to be used on a legacy I²C 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 I²C 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:

• Activity State 0: Normal activity
• Activity State 1: Expect quiet for at least 100 µs
• Activity State 2: Expect quiet for at least 2 ms
• Activity State 3: Expect quiet for at least 50 ms

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.

• Synchronous: The Master emits a periodic time sync that allows Slaves to set their sampling time relative to this sync. This may be used in conjunction with one of the Asynchronous modes.
• Asynchronous: The Slaves apply their own timestamps to the data at the time they acquire samples, permitting the Master to time-correlate samples received from multiple different Slaves or sensors.

There are four types (timing modes) of asynchronous time controls:

• Async Mode 0: Basic timing mode that assumes that a Slave has access to a reasonably accurate and stable clock source to drive the time stamping – at least accurate for the duration of the time it has to measure (i.e., from event to IBI). A set of counters, in conjunction with IBI, are used to communicate time stamping information to the Master.
• Async Mode 1: Advanced timing mode extends the Basic mode by using some mutually identifiable bus events, like I3C START.
• Async Mode 2: High‑precision timing mode that uses SCL falling edges (for SDR and HDR-DDR modes) as a common timing reference for Master and Slave. A burst oscillator is used to interpolate the time between a detected event and next SCL falling edge. For HDR-TSL and HDR-TSP modes, this timing mode uses both SDA transitions and SCL transitions as timing references.
• Async Mode 3: Highest-precision triggerable timing mode that supports precise time triggering and measurement across multiple transducers applications like beam forming.

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).

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.

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.

Yes. The I3C Master must emit the first START, 7’h7E at Open-Drain speeds (usually I²C Fm+ speeds) so that I3C Slaves with I²C 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).

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.

A few vendors have provided FPGA based design kits, including some low-cost FPGAs that might be good enough for smaller production runs.

Not directly, for a couple of reasons:

1. The I3C Bus works with push-pull modes (in addition to the open drain for some transfers), and
2. Much higher speeds. Most such devices are quite limited in speed, because of the lag effect of changing states on SCL and SDA due to both series-resistance and assumptions about open-drain.

Long wire approaches are being evaluated for a future version of the I3C Specification.

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.

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.

In general, any MIPI Alliance members who have I3C hardware ready to interop can participate.

Starting in 2020, MIPI Alliance plans to host interoperability workshops for I3C v1.1.

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.

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.

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.

Note: This question does not apply to I3C Basic v1.0.

No. The t_SCO (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 t_SCO 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 t_SCO delay greater than 12 ns must:

• Set the Limitation bit in the Bus Characteristics Register (BCR) to 1’b1,
• Set the Clock-to-Data Turnaround field of the maxRD Byte to 3’b111, and
• Communicate the t_SCO value to the Master by private agreement (i.e., product datasheet). 
• I3C Basic v1.0 already clarifies this.

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 standard GETMXDS CCC itself was not changed in I3C v1.1, though the definition of t_SCO 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.

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 I²C 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).

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.

The I3C WG is currently developing a CTS for I3C v1.1, for early 2020 release.

Yes. A CTS for I3C v1.0 is being drafted by the MIPI Alliance I3C WG [MIPI09].