Expand All

Introduction to MIPI I3C

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.

The official name is MIPI Alliance Improved Inter Integrated Circuit.

The main purpose of MIPI I3C is threefold:

  1. To standardize sensor communication,
  2. To reduce the number of physical pins used in sensor system integration, and
  3. To support low power, high speed, and other critical features that are currently covered by I²C and SPI.

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

I3C is currently in the early stages of adoption in products, and a few companies already offer I3C IP blocks. Silicon devices with I3C are likely to be available from some vendors by the end of 2017, with more coming throughout 2018.

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, requiring only decreased speed 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.

Yes, multi-Slave I3C chips are possible.

Yes, both I3C and I²C can share the same bus. See question above regarding I3C backward compatibility for details.

I3C has several modes, each with associated bitrate(s). The base raw bitrate is 12.5 Mbps, with 11 Mbps real data rate at 12.5MHz clock frequency. The maximum raw bitrate is 33.3 Mbps at 12.5 Mhz, with real data rate of 30 Mbps.

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 act as an initial current Master. Optionally, the bus can have multiple Secondary Master devices that initially act as Slaves. Any Secondary Master device can request to become the current Master. Once the current Master agrees, and transfers the current Master control 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 (dynamic addressing, timing control, etc.), and others. CCCs can be either broadcasted (sent to all devices on the bus), or directed at a specific device on the bus.

CCCs do not interfere with, and do not use up any of the message space of, normal Master-to -Slave communications. 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. The CCCs are used for standard operations like enabling/disabling events, managing I3C specific features and other bus operations. CCCs can be either broadcasted (sent to all the devices on the bus), or directed at specific devices on the bus. All CCCs (i.e., the command numbers) are allocated by MIPI Alliance, with some reserved for specific purposes that include MIPI Alliance enhancements and vendor 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 Specification

The MIPI I3C v1.0 Specification was made publicly available for download in December 2017. MIPI Alliance members have access and rights to the specification through their MIPI membership and member website. Non-members may download a copyright-only version of the specification by visiting the MIPI I3C page on the MIPI Alliance website: https://www.mipi.org/specifications/i3c-sensor-specification

I3C supports legacy I2C devices using Fast-mode (400KHz) and FastMode+ (1MHz) with the 50ns 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 pull-up resistor. With few exceptions, it is the responsibility of the I3C Master to provide 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 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 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 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 bus then it can detect this condition, since 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 expected to ACK the START with 7’h7E; the only exception would be if this device choosing to remain only as an I²C device, in which case, it would leave any 50ns 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 DA 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.

  • Bus Free condition is defined as a period occurring after a STOP and before a START and for a given duration (e.g., tCAS and tBUF timing).
  • Bus Available condition is defined as a Bus Free condition for at least tAVAL duration. A Slave may only issue a START request (e.g., for In-Band Interrupt or Master Handoff) after a bus available condition.
  • Bus Idle condition is defined to help ensure bus stability during hot-join events. This condition is defined as a period during which the Bus Available condition is sustained continuously for a duration of at least tIDLE.

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

An I3C Slave can issue the IBI in the following two ways:

  • Following a START (but not a Repeated START)
  • If no START is forthcoming within the bus available condition, then an I3C Slave can issue a START request by pulling the SDA line low. The I3C Master would then complete the START condition by pulling the SCL clock line low and taking over the SDA.

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 command), since an I²C master does not support the I3C protocol.

The I3C bus activity states provides 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 interval) 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

Yes. The I3C bus supports an optional time control mechanism. One 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 timestamp 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 of asynchronous time controls:

·   Async Mode 0: Basic 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 mode extends the basic mode by using some mutually identifiable bus events like, I3C START.

·   Async Mode 2: High precision 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, the mode uses both SDA transitions and SCL transitions as a timing reference.

·   Async Mode 3: Highest-precision triggerable mode that supports precise time triggering and measurement across multiple transducers applications like beam forming.

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 the SDR mode, along with suggested recovery methods. Similarly, a set of errors are defined for each of the HDR modes.

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.

Implementation: Ecosystem

The I3C specification is defined by the MIPI Sensor Working Group formed in 2013, an initiative by MIPI Alliance.

The MIPI Sensor Working Group includes 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. It is 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.

Implementation: As a System Designer

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:

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.

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 address assigned to I3C devices would not overlap the I2C static addresses, so they would not respond to any I3C address (even if they could see it).

The 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 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 Specification, a feature called In-Band-Hardware-Reset (IBHR) is under consideration 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, while others are optional and a given device will either support them or not, depending upon the device’s capabilities.

Implementation: As a Software Developer

Yes. The following MIPI Specifications are expected to help with SW development:

  • MIPI Specification for I3C Host Controller Interface (I3C HCI), v1.0 [MIPI02] (In development)

Creates a standard definition that allows a single OS driver (aka ‘in-box driver’) to support I3C hardware from several vendors, while also allowing vendor-specific extensions or improvements. The target audience of the HCI Specification is application processor host controllers; in particular, developers of host controller (i.e., I3C main Master) hardware, and developers of I3C host controller software.

  • MIPI Specification for Discovery and Configuration (DisCo), v1.0 [MIPI03]

Describes a standardized device discovery and configuration mechanism for interfaces based on MIPI Specifications, which can simplify component design and system integration. Also oriented to application processors.

  • MIPI DisCoSM Specification for I3CSM, v1.0 [MIPI04] (In development)

Allows operating system software to use ACPI (Advanced Configuration and Power Interface) structures to discover and configure the I3C host controller and attached devices in ACPI-compliant systems. Also oriented to application processors.

  • In addition, a MIPI Application Note for I3CSM [MIPI05] is being developed to help ASIC hardware developers, system designers, and others working in the more deeply embedded I3C devices.

Core I3C infrastructure is being added to the Linux Kernel via patchwork.kernel.org

Interoperability Workshops

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:

  • The vendors can get detailed information about how well their I3C implementations interoperate with other vendors’ implementation. Vendors can also compare their results with one another.
  • MIPI Alliance can generate an overall picture that shows the industry state-of-the-I3C-implementaion. For example, how many vendors have implemented I3C, and how many implementations pass or fail against one another.
  • The MIPI Sensor Work Group (SWG) gets better understanding about any major issues with the I3C Specification. The SWG can then leverage that learning by adding to this FAQ, the draft MIPI Application Note for I3C [MIPI05] (for system implementers), and the next revision of the I3C Specification. 

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.

Up and Coming

Many other MIPI Working Groups are in the process of leveraging the I3C specification. As of the writing of this FAQ, the list includes:

  • Camera WG: Camera Control Interface (CCI) chapter of the MIPI Specification for Camera Serial Interface 2 (CSI-2), v2.1 [MIPI06] (In development)
  • Display WG: Multiple MIPI Specifications for Touch interfaces (In development)
  • Debug WG: MIPI Specification for Debug for I3C [MIPI07] (In development)
  • RIO WG (Reduced I/O): MIPI Specification for Virtual GPIO Interface (VGISM) [MIPI08], reducing number of GPIOs used via I3C (In development)

Based on learning from the early implementations, I3C Interoperability Workshops, queries from adopters, and reviews by the Sensor WG, this FAQ represents clarifications, planned improvements that can be implemented by I3C v1.0 devices, and other hints about what’s coming next. 

Currently, the MIPI Sensor WG is working towards Version v1.1 of the I3C Specification, which is expected to add incremental new features while staying backwards compatible with v1.0. That is, v1.1 features which do not impact v1.0 devices will simply be available, whereas others will be enabled based on the capabilities of various Slaves on a v1.1 bus, just as is done with optional features in v1.0.

While not finalized yet, the following features are under consideration:

  • Grouped addressing
  • Additional Slave error detection/recovery
  • CCC support in HDR-DDR/TSP
  • HDR-DDR end write
  • HDR-TSP end transfer
  • Clock-to-Data refinement
  • Timing Control disable
  • New minimum tIDLE
  • In-Band Hardware Reset (IBHR)
  • Multi-Lane, for speed
  • HDR-DDR-end CRC

Clarification/Disambiguation and Allowances for v1.0

Yes. This is allowed such that the ODR (Output Data Rate) rate controls the IBI rate, and the Async Mode timestamp on the IBI indicates how long ago the sample was collected.

Yes, the SETXTIME code of 0xFF may be used. The MIPI Sensor WG plans to officially define this in I3C v1.1, but I3C v1.0 devices can support it now.

In I3C v1.1 the MIPI Sensor WG plans to officially 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. 

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.

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:

  • 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 tSCO value to the Master by private agreement (i.e., product datasheet).

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)

No, there is an error in Figure 52. 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.

Conformance Testing

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 Sensor 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 Sensor 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, phasing in with the Bangalore Interoperability Workshop (October 2017). 

Each test in the I3C CTS will contain:

  • A clear purpose
  • References
  • Resource requirements
  • Tracked last technical modification
  • Discussion
  • All test case detail (i.e., setup, procedure, results, problems).

DC/AC parametric requirements will be embedded in each test, not split out into a separate PHY-related CTS or subsection.

Legal & Intellectual Property Related Questions

MIPI Alliance does not and will not charge royalties, and we are not currently aware (as of the date of this FAQ) of any MIPI member or any third party that has asserted that it is owed royalties for implementations of I3C. We cannot guarantee that someone will not make this sort of assertion in the future, however.

Under the current MIPI Alliance IPR terms, MIPI members are obligated to grant certain licenses only to other MIPI members for implementations of MIPI Specifications. The IPR terms do not impose an obligation for members to grant patent licenses to non-members. And of course, non-members have not agreed to MIPI's membership terms and thus not bound by any obligations to grant licenses that are described there.

MIPI is making the entire I3C Specification and related supporting documentation available, in order to support implementations of the Specification. Implementers assume all risks associated with implementation, however, and must make their own risk assessment. Implementers who are not members of MIPI are not beneficiaries of the patent license obligations detailed in the MIPI membership terms, and thus face a different patent risk situation than do MIPI members. We encourage implementers to carefully assess patent-related (and all other) risks applicable to their particular circumstances, and make their decisions accordingly. Some implementers may decide there is little risk, others may decide that they have managed any risk via other means (e.g. bilateral license agreements), others may decide to join MIPI as a risk mitigation strategy, or choose some other path – in all cases, this is a judgment call that is solely the responsibility of the implementer. Most technology implementations involve similar risk assessments.

MIPI’s IPR terms are a hybrid: roughly, MIPI members are required to grant royalty-free licenses to other members for certain patents for “Mobile Terminal” implementations, and RAND – “reasonable and non-discriminatory” (but potentially royalty-bearing) – licenses for other implementations. RAND does not mean that royalties are automatically required – it only means that if an obligated party has an applicable patent, they generally cannot withhold a license (normally a right of a patent owner), but rather must grant a license on reasonable terms. A large majority of standards and industry specifications in the information and communications technology industry are governed by RAND obligations, and controversies rarely arise – although there are some high-profile exceptions. Generally, RAND is a common and effective framework for specification licensing. We believe our members see value in the RAND obligations associated with non-Mobile Terminal implementations.

The history of I2C and patents is complicated, but, yes, in recent years we understand that core I2C functionality has been implementable royalty free. Changing or supplementing long-established IPR terms is challenging for any standards setting organization, however, and there are limits to what can be accomplished given that some potential stakeholders are non-members. We are hopeful that making the I3C Specification publicly available without charge is a positive step forward.