The new MIPI I3C Host Controller Interface (MIPI I3C HCI℠) v1.1 specification was recently released to MIPI Alliance members as well as nonmembers, with new functionality that facilitates broader use of the MIPI I3C® interface and helps developers and the open source community integrate the latest I3C-based peripheral components into their designs.
In this blog post, we recap the benefits of the I3C interface, explain how the HCI specification helps developers and provide an overview of the updates in this latest version.
MIPI I3C supported by MIPI I3C HCI
The MIPI I3C HCI specification, introduced in 2018, was created to enable easier implementation of the scalable, low-power, medium-speed, two-wire MIPI I3C utility and control bus interface. As the successor to the widely adopted I2C interface, MIPI I3C and MIPI I3C Basic℠ (the publicly available subset version) are used for connecting peripheral devices to application processors. I3C HCI standardizes the interface that operating systems use to access I3C devices and capabilities, enabling the development of common software driver implementations for core I3C interface capabilities, while still allowing vendor-specific innovation. Both the I3C and I3C HCI specifications support backward compatibility with the legacy I2C interface.
MIPI I3C HCI delivers crucially needed efficiency for designers of smartphones, computers, automotive systems, Internet of Things (IoT) devices and other applications that leverage the I3C interface. The specification eliminates the need for device developers to create and maintain product-specific I3C drivers. Instead, operating-system vendors, developers and distributors can offer generic I3C drivers that are portable across hardware platforms, freeing designers to focus their efforts on developing applications rather than interfaces.
Version 1.1 aligns the HCI specification with the latest I3C advances by enhancing existing features and adding new capabilities, making I3C even more accessible to developers with even less effort. Like the original version of the specification, I3C HCI v1.1 is publicly available and can be downloaded from the MIPI Alliance website.
I3C System Overview
New capabilities and enhancements
The addition of group addressing and the enabling of defining bytes for common command codes (CCCs) are two key new features defined in I3C HCI v1.1.
The group-addressing feature enables developers to assign a multicast-type address to multiple peripheral I3C devices, as opposed to requiring one-to-one mapping of addresses to device types. This is especially useful for processes such as firmware updates, in which a controller is sending the same firmware to multiple devices at once.
By enabling defining bytes on the CCCs, I3C HCI v1.1 supports greater flexibility for developers to create additional CCCs, or augment the existing CCCs defined in MIPI I3C, which enable basic control over the operation of a target I3C device or functions on the bus itself.
I3C HCI v1.1 also introduces general improvements to operations in direct memory access (DMA) mode. This operating mode relies on a system bus that provides DMA capability and internal DMA engines to enable autonomous host controller-initiated memory access requests to drive transactions without a direct software involvement. Scatter gather for ring pointer, flow control, programmable input/output (PIO)/DMA mode indicator and ring full indication are among the added features that work together to contribute to advanced performance in DMA mode.
Other enhancements in I3C HCI v1.1 include:
- Introduction of command flows for the target reset pattern, such as the RSTACT CCC for various configurable target reset actions
- Support for assigning all static addresses as dynamic addresses via the SETAASA CCC
- Support for several new procedures for recovering the I3C bus after a controller reset or from a target device with a stuck serial data (SDA) line
- Improvements to transmit/receive (TX/RX) thresholds in PIO mode
- Support for “short” read-type transfers from I3C target devices (such as when response data can be shorter than requested data) to enable new I3C content protocols supporting variable-length private read transfers
- Support for detecting and reporting conditions of I3C bus stall or timeout in cases where a sequence of multiple transfer commands in continuous framing is interrupted and the I3C controller is forced to drive a STOP condition before the last transfer command
Improved clarity and readability
Development of I3C HCI v1.1 also included addressing known errata, improving clarity and resolving ambiguities. Many of these improvements were driven by feedback from implementers of I3C HCI v1.0 and reflect the ever-broadening I3C ecosystem. For instance, flow steps were added or better documented; theories of operation were expanded; and, in some cases, register and data-structure definitions were enhanced.
More inclusive, accurate terms
MIPI I3C HCI v1.1 also is notable in that it is at the industry vanguard of a movement toward more inclusive and, in fact, more accurate terminology. For example, “controller” and “target” have replaced “master” and “slave.”
Though the HCI specification is the first to be adopted with the revised language, the terminology is being updated in all MIPI specifications under active development. These changes not only replace terms that have hurtful historic connotations, they also more correctly represent the functions of technical devices.
I3C HCI driver for Linux
To further support implementers of I3C, MIPI also recently commissioned the development of an I3C HCI driver for Linux, which has been available in the Linux upstream source distribution since the release of version 5.11 earlier this year.
What’s coming next
The next release of MIPI I3C HCI, which is already in development and anticipated to be completed later this year, will include necessary changes based on key use cases and implementer feedback. The MIPI Software Working Group is always open to new perspectives, and encourages input by contacting software@mipi.org.
Rob Gough is a principal engineer and platform software architect with Intel Corporation. He has worked with standards development organizations for the last 15-plus years and has been an active member of the MIPI Software Working Group since its formation in 2014. He was appointed to the chair role of the group in March 2016.
Matthew Schnoor is a debug architect with Intel Corporation. He has more than two decades of experience in various Intel business groups and is a member of the MIPI Debug Working Group, where he has primarily focused on software development, silicon validation and system debug architecture. He has enabled MIPI I3C to support MIPI Debug for I3C, and currently works across and within several MIPI working groups to help advance the MIPI I3C ecosystem.