Improving Inter Integrated Circuits - From Sensor Hubs to Platform Management Solutions

Pratap Neelashetty, Suresh Venkatachalam, Guruprasad T R (Synopsys India Private Ltd)

1- Abstract

Inter integrated circuits (I2C) is a multi-master, low-bandwidth, short distance, serial communication protocol. Because of its simplicity and flexibility, I2C and its derivatives are widely employed by control applications to manage sensors. I2C is also used extensively in platform based applications such as system management and power management solutions as described below:

• System Management Bus (SMBus) is an architecture developed based on the principles of I2C and is used as a control bus for system related tasks. SMBus is used to pass commands or messages to and from devices instead of tripping individual control lines.
• The Power Management Bus (PMBus) is developed as a protocol over SMBus and is used as a control bus for power management tasks in a system. The system uses PMBus to communicate between power converters and a system host. It makes intelligent control of the power converters possible.
• Intelligent Platform Management Interface (IPMI) is developed based on the principles of I2C to define a standardized message-based interface for platform management hardware. IPMI provides general system management functions such as automatic alerts, automatic system shutdown, restart etc.
• The Display Data channel (DDC) is yet another protocol developed based on I2C and is used for communication between Host and Display to enable display control functions.
• The Camera Command Interface (CCI) is command interface protocol for camera controllers that defines a communications protocol and physical layer interface based on I2C specification.

By examining these prevalent and proven solutions, it is clear that I2C along with application specific extensions is used as the primary communication protocol for several system architectures.

However, one of the underlying assumptions in these architectures is the relatively low volume of data flowing between devices. This is a drawback if we consider the integration of sensors into almost all electronic devices of today and applications built around them, advent of 3D graphics, and highly power aware devices. Another drawback that has become apparent to us during this study is the heterogeneous use of protocols such as SPI, UART along with I2C to create practical solutions.

The MIPI I3C is a new standard that retains the attributes of I2C while improving upon its capabilities and performance. It also provides a scalable interface architecture. The I3C Specification anticipates the needs of sensors and control interface solutions that embedded-system industry might need in the future. The provisions in I3C standard allow for heterogeneous solutions to be unified under a single protocol. The standardized Host Controller Interface as defined by the I3C standard also holds a great deal of promise in enabling easier adoption of I3C based Solutions. Because of these merits, I3C seems to emerge as a natural successor to I2C.

This paper attempts to redefine these existing system level solutions using I3C and examine the improvements it can bring over I2C based solutions. Furthermore, it presents a seamless and risk free migratory path to the industry from these I2C based architectures to I3C based architectures using proven Synopsys Solutions.

2- INTRODUCTION

I2C is a very popular bus protocol and is commonly used for communication between a master (or multiple masters) and single or multiple slave devices. It’s simplicity and low pin count (SCL and SDA), makes it a preferred protocol for control and low bandwidth data transfer applications.

I2C protocol is used in a wide range device that include a variety of household and consumer electronic devices such as Television, Washing Machine refrigerators etc. I2C is the preferred mode of communication between IR Sensors on Television, Audio Systems, DVD Players and their respective controllers. The informative LCD displays on these consumer electronic devices are again controlled by I2C. Communication with graphics adapter in display devices (monitors, television etc.) is managed by Display Data Channel circuitry which is essentially built on I2C. I2C is also extensively used in Memories and Microcontrollers. Most of these applications and system architectures have had to develop a protocol layer of their own on top of I2C to define a set of application specific command to extend the use of I2C protocol to suit the specific needs of the function being performed.

The most important application of I2C protocol is its rampant use in sensor based systems. Sensors have made their way practically into most electronic devices such as smart mobile devices, wearables, industrial control, automotive systems, smart home and healthcare equipment. The sensor world itself has been evolving from controlling discrete sensors to managing multiple sensors. The Sensor technology is beginning to closely mimic the ultimate sensing machine - the human being. At the heart of this technology is a microcontroller (a “brain”) that collates and fuses data collected from multiple sensors to derive a more holistic and meaningful interpretation of the collected data than what one would get by using the data from each discrete sensors in isolation. This is heading the direction of ‘Sensor Fusion’ where in the whole system is much greater than the sum of its individual parts.

2.1 Challenges with existing I2C based architectures

• Scalability

With the increase in the numbers of sensors that are employed by applications the number of number of logic pins used for sensor communication and control has increased in direct proportion. It requires application processors and/or sensor hubs to interact with these multitude of sensors. In a typical application as shown in Figure 1 , multiple digital communication interfaces are used along with supporting logic lines for dedicated interrupt and sleep signals.

Application Processor /Sensor Hub Acclerometer Gyroscope Magnetometer Finger Print Sensor Pressure I2C INT INT INT SPI UART

Figure 1 – Typical Application Processor or Sensor Hub System with various digital interfaces.

• Integration challenges with heterogeneous interfaces:

There is no consistent method to interface with sensors as the digital interfaces are fragmented with I2C, SPI and UART interfaces. This also causes considerable integration challenges. Further, the digital interfaces do not have the scalability and flexibility to support advanced sensors features such as batching (buffering sensor samples in sensor hardware and delivering them in a batches instead of delivering continuously), power management, and so on.

• Application specific extensions to I2C:

Furthermore, I2C bus is used as the underlying communication protocol for system architectures like SMBus, PMBus, IPMI and CCI. These architectures have defined their own extensions and modifications to physical layer interface of I2C protocol to build application specific control management systems. For Example:

• Address Resolution Protocol introduced in SMBus protocol which allows the devices to be “hot-plugged” and used immediately, without restarting the system. The devices are recognized automatically and assigned unique addresses. This advantage results in a plug-and-play user interface.
• Group command protocol introduced in PMBus specification is used to send commands to more than one device. This helps the Master to instruct all the targeted devices in one transfer.

MIPI I3C is the digital control and data communication interface. The purpose of developing MIPI I3C Interface is to standardize the sensor and control communication, reducing the number of physical pins and to support low-power, high speed interfaces which are lacking in the existing standard digital communication interfaces.

The rest of the paper is organized as follows:

• Section 2 presents an introduction to I3C interface
• Section 3 discusses how the existing solutions can be redefined to be more efficient by using provisions of MIPI I3C
• Section 4 concludes the paper by describing the Synopsys Solutions for MIPI I3C protocol.

3 MIPI I3C Interface

The MIPI I3C interface uses an I2C-like interface and supports multiple classes of devices including main master, secondary master, slave and I2C slave. The Dynamic Address Assignment is introduced in the physical layer, and the master can dynamically addresses to all MIPI I3C devices while supporting the static addresses of legacy I2C devices. This ensures backward compatibility between MIPI I3C and I2C.

MIPI I3C introduces the capabilities in the masters for request and handover of bus ownership between the masters in the system (a feature that is lacking in the I2C Protocol).

A set of common command codes (CCCs) has been defined for standard operations like enabling and disabling events, managing MIPI I3C specific features (dynamic addressing, timing control, and so on). These CCCs can be broadcasted (sent to all devices) or directed at a specific device on the bus. MIPI I3C Specification also allows for defining user specific common command codes based on the application needs.

A very useful feature allows MIPI I3C slaves to initiate in-band interrupts (which currently requires a dedicated signal line for both I2C and SPI devices). The in-band interrupt feature enables the slaves to interrupt the master whenever they require to communicate with the master.

The MIPI I3C interface provides several communication protocols including I2C-like single data rate (SDR) messaging mode (up to 12.5 Mbps), and high data rate (HDR) messaging modes (up to 33 Mbps). There are two main HDR modes, HDR-DDR (double data rate) and HDR-TSL/TSP (ternary symbol). These modes offer bit rates over 33 Mbps at a fraction of the per bit power of I2C (400 kHz, fast mode). Both SDR and HDR formats share a two-wire interface with a bi-directional data pin. The SDR format supports a mix of various message types like standard I2C messages, broadcast and CCC messages and slave initiated requests (for example, in-band interrupts or requests to assume the master role).

In the following section, we will examine how some of the features currently used by legacy implementations can be made more efficient by transitioning to MIPI I3C.

4 Improving Inter-Integrated circuits

In this section we have made an attempt to examine existing derivative solutions of I2C, redefine them wherever possible to use provisions of I3C protocol to achieve equivalent functionality with greater efficiency. The study will conclusively demonstrate that adoption of I3C in such systems will not only address the challenges of the legacy solutions as out lined before but also improves the over performance in terms of bandwidth, power and makes a strong case for wider adoption due to standardized interface for software drivers.

4.1 Dynamic Address Resolution and Hot-Join in SMBus

Dynamic Address Resolution (ARP) is a concept introduced in the SMBus that allows the bus devices to be “hot-plugged” and used immediately, without restarting the system.

A limitation in the I2C is the limited 7-bit address space. With all the different types of devices available, we are running out of address space that can be assigned to device categories. Also, to be able to have several identical instances of the same device on the bus I2C controller implementations allow the user to set few address bits to obtain unique address for these identical instances. This use model further reduces the available address space and also creates a potential problem of conflicting address wherein two different device types having the same address. The standard method to resolve address conflicts is splitting a bus into several segments and enabling one segment at a time under software control. This segmentation requires additional hardware and complicates the application firmware. The lack of an enumeration function makes it more involved to bring up an I2C system comprising of slaves from different vendors. SMBus has defined ‘Address Resolution Protocol’ to address the challenges outlined above such that devices are recognized automatically and assigned unique addresses. This mimics Plug-and-Play capability.

This mechanism requires SMBus Master to generate a minimum of four transfers to assign dynamic address to a slave. The Master will issue ‘Prepare to ARP’ as an initiator to prepare the slave for the address assignment procedure followed by ‘Reset Device’ command to reset dynamic address if already assigned. The Master will then issue ‘Get UDID’ command to receive the Unique identifier value from the device which is used for assigning the dynamic address in the following and final ‘Assign address’ command. The SMBus Master repeats the outlined steps for every slave in the system to make sure all slaves have non conflicting addresses.

Figure 2: SMBus ARP Commands

Since ARP is built using I2C messaging primitives, it is not the most efficient way of handling address assignment. For example: The sequence of four consecutive commands that constitute ARP requires 445ms at the highest speed (1MHz) possible in SMBus to assign address to one slave. Once assigned, there is no easy mechanism to re-assign the dynamic address without performing address assignment procedure all over again for all slaves.

In contrast, I3C defines a set of commands to manage different scenarios under which address assignment can happen. The mechanism for Dynamic Address Assignment outlined by I3C protocol effectively achieves what is achieved by the four step ARP mechanism of SMBus by a single Dynamic Address Assignment procedure. A single transfer is sufficient for assigning dynamic address to multiple devices. Our analysis indicates that this can bring about an improvement of 99 %(over the 445ms of SMBus Protocol) in assigning a dynamic address. The I3C protocol also includes a command to assign dynamic address to devices that have a static address. This procedure consumes fewer cycles than Dynamic Address Assignment procedure. I3C also supports a command to Set New Dynamic Address directly to devices that already have a dynamic address without having to participate in Dynamic Address Assignment procedure all over again.

Figure 3: Dynamic Address Assignment in I3C

Another aspect of SMBus that deserves attention is the mechanism by which a device Hot-joins into the system. SMBus requires a separate side band (‘SMBALERT’) from all such Hot-Join aspiring slaves to notify the host when it attempts to Hot-Join. This adds to the hardware complexity and is not a very scalable solution. Devices that do not have the sideband signal implemented are expected to join as a Master and then issue ‘Host-notify’ protocol to the Host to announce its intent to join the system as a slave. The Host will in turn assign the dynamic address to the device through ARP. The reduced complexity of not having a sideband implementation is compensated by increased complexity in having to support the Master role of operation by Slaves.

I3C protocol supports In-band Interrupts Messaging to allow Slaves to interrupt Master without requiring a nonstandard sideband implementation. When the device joins system dynamically and requires a dynamic address, the device generates a Hot-Join request through In-band Interrupt message and master will perform Dynamic Address Assignment procedure to assign the dynamic address for the newly joined device.

The inbuilt provisions of I3C protocol provides for better and efficient alternatives to ARP and Hot-Join of SMBus and obviates the need for sideband implementation and reduces the overhead of Master functionality having to be available in the slave just to be able to Hot-Join.

4.2 Bus Management Procedure in SMBus/PMBus

System Management Bus (SMBus) is an architecture developed based on the principles of I2C and is used as a control bus for system related tasks. To achieve this SMBus defines 9 kinds of messaging structures to transfer and receive the control information. These range from ‘Quick Command ‘(which is used to simply turn a device function on or off) to ‘Process Call’ (which is used to send a word to the device and read a word of data in return).

The Power Management Bus (PMBus) is developed as a protocol over SMBus and is used as a control bus for power management tasks in a system. Additionally, PMBus defines ‘Group Command’ primitives to send commands to more than one device.

However, I2C itself lacks flexible Broadcast and Directed Messaging primitives, consequently SMBus and PMBus protocols lack the support required from underlying I2C to efficiently define Broadcast Commands for transmitting commands to multiple devices and Directed Commands for transmitting/receiving information from multiple devices one at a time.

The Broadcast and Directed Common Command codes are natively defined in I3C protocol and hence I3C provides a ready to use solution in the form of a Single I3C transfer to replace complex Bus Management primitives defined by SMBus/PMBus protocols. The Master issues the Broadcast command with the command code and data. All slaves will listen to broadcast command and decide to act upon it based on the Broadcast Command issued. Direct Write/Read Commands on the other hand are directed to one or more specific I3C Slaves. The Directed command in I3C protocol is much more efficient than the Group addressing protocol in PMBus in the sense that the Command Code is issued only once regardless of the number of Slaves being addressed. Furthermore, from a scalability perspective Vendor Specific Command in I3C render themselves as the perfect vehicle to build application specific extensions.

Figure 4: Bus Management Protocols in SMBus and PMBus

4.3 Interrupts

I2C and SPI are typically used to support multiple sensors, but they both have drawbacks for sensor interconnections. Neither of them have a method to notify the master about a change in their state or to initiate a data transfer from the sensor to the master. These notifications are currently being performed by additional logic using general purpose input and output (GPIO) signals. A fallout of this mechanism is that Slaves cannot be easily re-deployed in newer systems without porting the Slave specific ‘interrupt handling’ capability of the Master over to the new system.

MIPI I3C has the potential to replace both I2C and SPI with a more power efficient two-wire interface. The in-band interrupts mechanism of MIPI I3C interface eliminates or reduces the need for external GPIOs. By being able to interrupt the Master based on sensor functionality I3C slaves can potentially operate in a more ‘Sensor Aware’ manner and reduce the overhead of polling and servicing interrupts from the Master. This translates to reduced complexity of Master implementation and reduction in power consumption.

Figure 5: I2C System with external sideband GPIO signals

Figure 6: I3C System with In-band Interrupt Support

The slave initiates an interrupt via an in-band message. The payload of the message may be utilized to specify slave specific information/action to be performed by the Master or interrupt data. Introduction of in-band interrupts in a multi-drop environment enables sensors to be pro-active in it their interaction with the Master rather than having to depend on Master to poll and service them. Polling mechanism burdens a Master with the responsibility to having to service interrupts from any slave, this makes the implementation inflexible. In band interrupts are broadcast messages to which can be serviced by ‘any’ Master capable of doing so. The slaves can also be agnostic of the Master servicing the interrupt. This allows for a more flexible implementation that does not call for a tight coupling between the Master and Slave w.r.t interrupt handling that existed in legacy systems. Thus the use of in-band interrupts results in a simpler and scalable implementation.

4.4 Bus Ownership Request and Handover

The arbitration and clock synchronization mechanisms of I2C supports the Multi-master system where multiple masters can transmit or receive the data from slaves simultaneously. Two or more masters can begin transmitting on a free bus at the same time and there must be a method for deciding which Master takes control of the bus and complete its transmission. This is done by clock synchronization and arbitration. The Arbitration feature stays in effect for the entire duration of the transfer until the last bit. This results in the Competing master not knowing whether or not the transfer Succeeded until the last bit. Should an arbitration loss occur during advanced stages of a long data transfer, the Master that loses must re-transmit all of the data. This mechanism is not very efficient.

Mechanisms for handoff of the Master role from one Device to another Device are well defined by I3C protocol. The Non-current master generates Master Request whenever it requires ownership of the bus and get it from the current master. The Current Master can also handover the Mastership to the Non-current master whenever it requires to go to low power state. Thus I3C allows for only one Master to have control of the I3C Bus at any given point of time. This ensures that there cannot be arbitration loss beyond the Address Phase. The protocol itself eliminates the possibility of arbitration loss because of multiple masters transmitting at the same time like in I2C.

4.5 Batching

SPI requires four communication lines and is used where large amounts of data needs to be transferred, such as clearing data in batches from FIFO buffers. To its disadvantage, SPI lacks a clearly defined standard that has resulted in many different implementations. Always-on sensors and sensor hubs are constantly accumulating sensor data even while the main application processor/sensor hub is idle (that is, low-power mode or deep sleep). Accumulated sensor data is commonly organized in batches and needs to be periodically transmitted between sensors and sensor hubs/application processor to minimize power consumption.

The industry has favored SPI for high-speed transmission of batched sensor data, but SPI is more complex and has higher pin count than I2C.

The I3C protocol supports higher-speed transfers compared to I2C with the same two wire interface. There are two main HDR modes, HDR-DDR (double data rate) and HDR-TSL/TSP (ternary symbol). These HDR modes support speeds of upto 33Mbps at a fraction of the per bit power of I2C (400 kHz, fast mode). The increased speeds of operation of I3C allows I3C based implementations to replace SPI based legacy systems due to its ability to evacuate accumulated data quickly in batches.

4.6 Power Consumption

Increased speed of operation of MIPI I3C interface has resulted in significant reduction of per bit power consumption. The bar charts in Figure 6 compare the energy consumption (per bit) of the various MIPI I3C modes with I2C (left) and the corresponding data rates (right). These numbers conclusively demonstrate that I3C is a more power efficient interface as compared to I2C.

Figure 7: Energy Consumption and Raw Data Rate: I3C vs. I2C (figure courtesy from https://www.synopsys.com/dw/doc.php/wp/mipi_i3c_wp.pdf )

5. Conclusion

The MIPI I3C sensor interface has the potential to provide a low risk transition path for integrated system architectures and sensor based systems to move out of heterogeneous legacy implementations and embrace newer technology to be able to handle the needs of today. MIPI I3C has evolved by imbibing the combined advantages of I2C and SPI and has addressed the shortcomings of these protocols by adding new features such as in-band interrupts, common command codes, dynamic addressing and advanced power management. It also maintains backward compatibility with I2C. These translate to lower cost, lower power and better scalability compared to I2C, SPI, UART and other digital interfaces. The rich feature set of MIPI I3C holds great promise and it is already evident from its adoption by non-sensor applications such as touch interface, always-on and low resolution cameras. MIPI I3C could truly be a universal standard for the sensors and control interfaces.

The DesignWare MIPI I3C Controller IP from Synopsys supports the complete I3C feature set, device roles (Main Master, Secondary Master, I3C Slave and I2C), and includes all data rates up to 33 Mbps, and 32-bit ARM® AMBA® Advanced Peripheral Bus (APB) slave interface. The whole gamut of DesignWare MIPI I3C Controller’s features, including the register set which is modeled after the evolving Host Controller Register Specification makes it the ideal choice for a smooth migration from I2C based systems and also for its adoption into I3C based designs.

If you wish to download a copy of this white paper, click here