The market for electronic sensors is constantly expanding, with annual double-digit growth rates. The main factors driving this growth are the large number of sensors introduced in IoT devices, mobile devices (smartphones and tablets) and wearables. Unprecedented application scenarios are now possible thanks to the adoption of sensor fusion techniques, by which information acquired from multiple sensors is combined to obtain high-level aggregate information that cannot be obtained with single sensors. The interface most used to communicate with and control these sensors is the integrated circuit (I2C), whose specifications were introduced by Philips Semiconductor (now NXP) in 1982. Another popular interface is SPI. As for SPI, it requires four wires and has many different applications because there is no clearly defined standard. Moreover, SPI requires an additional chip identification line for each additional device in the bus, which increases the number of pins, wires and power consumption. The main advantages of this interface, which has become very popular in a short time, is that it requires only two signals (one for data and the other for the clock), the ability to connect multiple devices on the same bus, and the ability to support different transmission rates. However, the I2C interface has some important limitations, including the impossibility of slave devices connected to the bus to initiate communication, the need to use traction resistors (which causes an increase in energy absorption and a slow rise time), and a communication protocol that limits performance. Interacting with sensors today is a difficult challenge for designers, considering that there are many interfaces available in the market (I2C, SPI, UART, etc.) while it would be more convenient and easier to have one consistent and common protocol (a kind of universal interface) To connect with all kinds of sensors. In this article, we will see how an interface exists that can respond to these needs, combining the strengths of both I2C and SPI while adding new features: the I3C interface, and its official name is MIPI Alliance Enhanced Inter-Integrated Circuit. The goal of the I3C interface based on the original I2C standard, which maintains backward compatibility regarding it, the new I3C interface, standardized by the MIPI Alliance, adds significant additional enhancements and features, such as the multi-drop trigger mechanism. The main purpose of this innovative interface is to provide a common standard for managing the connection of different types of sensors while ensuring high performance, low power consumption and fewer interface pins. Figure 1 shows an application diagram of the interface, where we can immediately see: a communication bus consisting of only two lines (SDA and SCL), just as it does in conventional multi-speed I2C communication modes, allowing a maximum of 30.3 Mbps for data history in – Band interrupting and fast tethering mechanism Ability to connect multiple master nodes on the same bus Ability to connect both I3C and I2C slave devices (backward compatibility) Figure 1: I3C bus implementation diagram One of the new features introduced in I3C is the ability for each slave device Connected to the bus by generating an interrupt signal by exploiting the same SDA and CLK lines used for the communication protocol. In this respect, we are talking about “in-band” boycott (IBI), which means no additional lines or signals are required, with the consequent cost savings and simplification of communications. In a similar way, there is the possibility to manage command codes within a domain. Other notable features include 7-bit dynamic addressing, applicable to I3C devices only (static addressing for the legacy I2C interface is still preserved), multi-chip playback, and support for “hot plug” devices on the bus (Quick Join feature). The I3C interface also supports low-power operation and offers a significant increase in transmission data rates, which are two major factors that contribute greatly to the success of this protocol in embedded applications. I3C: Technical overview From an electrical point of view, the I3C interface has some similarities with the I2C standard (such as having only two lines, SDA and SCL) but also some important differences. First of all, the data signal (SDA) contains an open drain configuration (it can be implemented, for example, through an open collector output), which allows the slave devices to control the bus and send an interrupt. The clock signal (SCL) can alternatively be switched to a push-pull configuration, which allows the main device to generate a clock signal with a base frequency of 12.5 MHz. More precisely, I3C features four data transfer modes: 12.5 Mbps in SDR mode (default) and 25, 27.5 and 39.5 Mbps in HDR modes. With the exception of control bytes associated with each transaction, the actual achievable bit rates are, respectively, 11.1, 20, 23.5 and 33.3 Mbps. In Figure 2 on the left, we see a comparison between the power consumption (mJ / Mb) of I3C (in different operating modes) and the legacy I2C interface. Blue bar charts indicate 3.3-V bus supply voltage, red bar charts indicate 1.8-V supply voltage. On the right side of Fig.2, the raw bit rates that can be obtained with I3C and I2C are compared, respectively. Examining these diagrams shows how the new I3C interface is more energy efficient than the old I2C, even in I2C compliant mode, and supports effective transfer speeds of over 33 Mbps. Figure 2: A comparison between I3C and I2C in terms of power absorption and in-band interrupt data rate Thanks to the IBI feature, the I3C standard overcomes one of the classic limitations of legacy I2C interfaces, which is the impossibility of a dependent node automatically starting its transaction on board. To do this, both the legacy I2C and SPI interfaces require dedicated lines, thus increasing costs and wiring complexity. On the other hand, the in-band function allows each I3C subordinate to initiate a START transaction whenever it deems it necessary, provided the carrier is idle. For this purpose, if bus is available, the slave node pulls the SDA line low and waits for the current main to pull the SCL line low, to complete the START phase. By providing the slave’s clock signal on the SCL line, the master allows the latter to lead the SDA line with his own address. If more than one child tries to access the bus at one time, the arbitration circuit assigns priority to the slave with the lowest address. At this point, the master has three options: accept the slave’s request, send the ACK, and get the data bytes the slave sends. Rejecting the request from the slave, without disabling interrupts (passive NACK). The method can now retry the operation as soon as the bus is available. Reject the request from the slave by disabling interrupts and sending a NACK. The interrupt mechanism within range is used by the dependent devices to notify the master of an event or change of state. The ability to automatically transmit information through this mechanism allows I3C sensors to inform the master of significant differences in physical quantities acquired only when they undergo a major change (think, for example, in an accelerometer that detects a falling motion) and without the need for it. Dedicated interrupt lines as happens with traditional I2C and SPI interfaces. Quick Join feature This feature enables the I3C sensors to communicate with the bus after it is configured properly. In modern sensor-based applications, such as the multiple scenarios related to the Internet of Things, it is necessary to ensure not only high performance but also efficient operation that reduces energy consumption of the sensors (which are primarily battery powered). Thanks to the fast connect feature, the sensors can remain turned off (or in a low-power state) when not required and only connect to the bus during certain periods of data acquisition and transmission, which significantly reduces power consumption compared to an “always on” solution. A quick join request can only be executed by a child who has not yet been assigned a dynamic address. For this purpose, the slave uses a physical address reserved for this job; When a master receives a request with that address from a slave, he performs an action to assign a new dynamic address to the same slave. Equally important is the offline feature, which allows the child node to become inactive and then resume normal operation at a later time. There are two offline modes: the slave is completely inactive (equivalent to a power outage) and only returns active when certain external events occur; When this happens, the slave joins the bus for a dynamic new address. The slave is partially inactive, meaning that he continues to watch the bus to check if commands have been sent to it, such as resetting the slave, against which the slave wakes up and returns to work. Common Command Codes A very useful function is General Command Codes (CCC), which are commands that a teacher uses to communicate with all slaves connected to a vector (broadcast), or with specific slaves. CCC commands include standard operations such as enabling / disabling events, handling specific I3C bus functions (for example, dynamic addressing and timing control), or other bus operations. All codes related to CCC commands are determined by the MIPI Alliance and some values are reserved for future expansions. Figure 3: Dynamic Title Proficiency Request ENTDAA CCC Bus Modal Mastership This feature allows the high school master to submit an MR application when they intend to obtain the active lead role. If the application is accepted by the current master, the master is transferred from the latter to the secondary master. Communication Modes The I3C interface provides the user with different communication modes, which can be grouped as follows: Single data rate (SDR) is the legacy I2C message exchange compatible mode and provides data rate up to 12.5MHz High data rate (HDR) includes many modes Exchange of messages that are not I2C compliant. In both SDR and HDR playback modes, the SDA pin is used as two-way data signals. The second pin is used as a clock signal (SCL) in SDR and HDR-DDR modes or as a two-way data signal in HDR-TSL and HDR-TSP communication modes. SDR mode supports different types of messages, such as standard I2C messages, broadcast messages, and CCC messages, which allow the master to communicate with all devices on the bus and handle requests forwarded by slaves (for example, interruptions within range or default requests role the master). There are two main HDR modes: HDR-DDR (double data rate) and HDR-TSL / TSP (triple code), which provide bit rates higher than 33Mbps with absorption lower than the standard I2C rate in fast mode (400kHz) )). HDR-DDR can be used to communicate with MIPI I3C slaves, allowing legacy I2C devices to be connected on the same bus, which will ignore high-speed MIPI I3C HDR broadcasts. HDR-DDR mode uses the SCL signal as a clock, with the data bits synchronized on either side of the SCL. On the other hand, HDR-TSL / TSP mode allows for triple coding (i.e. three-digit basic codes) for MIPI I3C (TSP) and legacy I2C (TSL) systems. HDR-TSL uses both SCL and SDA as data lines, as at least one line must pass per period. Transition indicators are used to encode the transfer of binary to triple tokens to enable high-speed transmission at very low power. Figure 4: Introducing HDR Mode CCC Bus Modal Key differences with I2C (and SPI) Due to the use of push-pull (rather than open-pull) and strong pull signals, all I3C modes provide less power consumption per bit transfer than I2C. Moreover, I3C can save more power by using higher data rates (paired with deep sleep modes), IBI, and the ability of slaves to disable all internal clocks while still operating properly on the I3C bus. In old I2C, expanding the clock (where the slave keeps the clock low, and prevents it from working) often causes serious problems, including a stuck bus. This cannot happen on the I3C bus, only the master can drive the watch, and the slave performs all actions on the SDA for that watch, eliminating the risk of a hang. Also of note, the next revision of the I3C specification will include a resetting slave feature to reset unresponsive I3C slaves. I3C aims to fix that, as it only uses two wires and is well defined. .