Industrial standards allow companies to speed up and simplify product development, unify and document the processes and artifacts, provide a predictable level of solution quality, ensure compatibility with products and parts from different manufacturers, reduce the cost of production and operation, etc. Low-level exchange standards in computing are no exception. Common sense says it is not enough to put together a document to establish a standard. It needs to be introduced to as many development engineers, production workers, and operating personnel as possible.
This article is aimed at computer specialists, programmers who deal with lower-level data communication protocols in some way. Our assumption is that the reader is familiar with i2c terminology and would like to acquire a basic understanding of the fairly new i3c protocol, which is replacing the widely used i2c.
This is a review article, and it does not cover specific details, like error handling, bus master options (if there are several), setting interrupt priorities, and specific frame formats and timings on the bus. Please refer to the original standard text for these details. This article covers important aspects of a smooth transition from the good old i2c to the more modern i3c protocol, which apparently will become the main protocol of this kind for at least the next few years.
Application of i2c/i3c protocols
The applications of protocols like i2c/i3c are quite varied: sensors, displays, memory management devices, chips of other serial protocols, etc. In general, what these protocols do is connect many relatively low-speed devices in a standardized way within a single system.
Let’s use the seven-level OSI model to compare the i2c/i3c protocols. It can hardly be called a generally accepted approach, but the OSI model is well known to both hardware experts and programmers, so it will help us explain something new by relying on existing knowledge. From the i2c/i3c specifications, we know that documents regulate (according to the OSI classification) the following levels:
- Physical – levels, waveforms, and sequences of signals, physical requirements for communication lines
- Channel – order of interaction on the bus, frame format, and logical data exchange
- Network – addressing and routing of data
- Transport – controlling the speed and order of data transfer
i2c/i3c are low-level protocols, and they do not regulate anything that could be attributed to levels above “transport,” except for the definition of the so-called Common Command Codes (CCC), which can be attributed to the session level. In a particular application, the “session,” “presentation,” and “application” levels are determined by a specific solution using i2c/i3c (e.g., SMBus) and a specific implementation of the i2c/i3c software API.
Fig. 1. i3c and OSI
Despite the fact that the i2c specification practically equals i2c and SMBus, the SMBus protocol can be used in architectures built on other buses (e.g., PCI/PCIe). However, since we are not interested in the inaccuracies of the i2c specification wording, we will use the OSI classification to describe the new features of the i3c protocol and compare it with i2c.
Key differences between i3c and i2c
In general, i2c devices are fully compatible with i3c and can work together (with some limitations described in detail in the i3c standard) using a common bus. The i2c protocol can even be considered a subset of i3c. At the same time, i2c devices simply “do not notice” traffic at speeds higher than the i2c protocol is capable of, but there are differences that we will cover level by level.
Fig. 2. Typical system with i3c
Physical and channel levels
The i3c specification describes those levels in considerable detail. The differences between i2c and i3c at the physical and channel levels come down to the following:
- higher rate of exchange for i3c – up to 12.5–15 MHz;
Fig. 3. Rate comparison of i3c (in different modes) and i2c
- lower power consumption for i3c;
Fig. 4. Power consumption comparison of i3c (in various modes) and i2c
- greater energy efficiency (ratio of energy consumption to transmission speed) for i3c;
- differences in timings of sending START commands, address, 9th bit;
- ability to use both the push-pull mode of the output stages and the open collector mode for i3c, while in i2c circuits, as a rule, only an open collector is used;
- using a different frame format and timings for high-speed HDR modes in case of i3c;
- to achieve a high speed, i3c uses both lines (SDA, SCL) for data transfer.
Network level
At the network level, i3c uses the same address format and range as i2c. However, there are slightly more restrictions for free addresses, and some of them are service addresses. For example, 0x7E and 0x7F are broadcast addresses. A key feature of i3c innovations is a special dynamic addressing mechanism. In practice, this means that slave devices can change their address in the course of operation. Changing the address in i3c is also important, because the priority of the device on the bus depends on it, both for receiving/transmitting and for processing In-Band Interrupts (IBI) (see below). The system can implement various traffic prioritization schemes using addresses as a priority base.
Transport level
As stated above, the protocols have similar characteristics (* for speeds below HDR) at the lower levels, but starting from the transport level, the differences are revealed to a greater extent. Strictly speaking, these are not even “differences” but protocol “extensions.” i3c introduces new high-speed transmission modes and the following new options for the data transmission order: SDR (Single Data Rate), HDR (High Data Rate), HDR DDR (Double Data Rate), HDR TSP (Ternary Symbol for Pure Bus – ternary coding without support for i2c devices), and HDR TSL (Ternary Symbol Legacy-Inclusive-Bus – ternary coding with support for i2c devices on a shared bus). Moreover, the basic i3c specification, which this article refers to, does not include a description of these speed modes. It is noted that devices created according to this specification must distinguish between speed modes and obey the general rules for coexistence with faster devices on the same bus.
The master device on the bus can access both the i2c standard slaves and those that support i3c simultaneously, but each of them is accessed according to its own rules. Several master devices can be implemented on the bus, but only one of them can be the main master. The protocol determines the order of choice of the main master device. In addition, in the process of operation, the master device roles can change with the transfer of authority of the main master from one device to another.
The new protocol goes much further than i2c: it introduces its own bus and device control rules – CCC and IBI.
Let’s explore the communication between the master and slave devices in SDR mode. Jumping ahead a little, we note that each slave i3c device must have some minimal set of configuration registers:
- Bus Characteristics Register (BCR) – a bus performance register required for all i3c devices. Defines the role of the device and its capabilities on the bus;
- Device Characteristics Register (DCR) – device characteristics register, also required for all i3c-compatible devices. Describes the class and type of connected device (sensor, gyroscope, etc.).
Legacy Virtual Register (LVR) – virtual compatibility register for i2c devices. Each i2c device on the i3c bus must have such a register, but its implementation may be defined by a software driver so it is called virtual.
Single Data Rate – single speed mode (SDR) – the main protocol (mode) for exchanging data in i3c. It is based on the standard i2c protocol with some differences, usually at the physical level. From a software point of view, this is as follows:
- another interpretation of the 9th bit in the 9-bits data word (the so-called T-bit, “transition bit”), which is associated with different implementations of physical data exchange lines;
- extended interpretation of a “message”. In i3c, a message is all that is transmitted after a START (or re-START) command until the next re-START or STOP command;
- changes in the mechanism of reading/writing data. Unlike i2c, reading/writing data in i3c does not require confirmation after sending/receiving each byte by the slave.
The general format of an SDR message is as follows:
- After the START command, the address 0x7E (i3c broadcast address) is sent to all i3c slaves. They all recognize and accept this address, unlike i2c devices, for which this is a reserved address, and they do not respond to it at all.
- The START command is followed by the address of the slave device to which the message is addressed. This can be either a dynamic or a static address if the device does not support dynamic address assignment (in this case, the dynamic address can coincide with the static one). Each device recognizes (and responds) only its own address. The RnW bit in the address indicates the next step of transmission: read (from slave to master) or write (from master to slave).
- The slave then waits for either a repeated START or STOP, followed by either data or a CCC command.
It is unusual that after a repeated START, the host does not have to repeat the prologue using the broadcast address. It can set the address of another slave device on the bus and exchange with it (since all slave devices must respond to the broadcast address). However, the direction of exchange may vary. The process can be repeated many times until the host sends the STOP command. The fact that, when reading or writing a sufficiently large amount of data, the operation must be started from the beginning each time is considered an inconvenience. This is because, according to the specification, devices independently increase the counter of sent/received bytes (i.e., the protocol has no explicit positioning in the data array). This inconvenience, as a rule, is neutralized by higher-level protocols, such as SMBus.
Another innovation of i3c is the introduction of a checksum byte. This is important to ensure reliable data transfer, given the increased speed and length of messages without confirmation. Unfortunately, this feature was not included in the current public description of the basic i3c protocol.
Nevertheless, the i3c functions described in the public version of the protocol are sufficient to manufacture devices capable of working on the i3c bus in conjunction with devices that have proprietary extensions.
CCC commands
The MIPI i3c specification ensures that the CCC command format follows SDR protocol rules. Commands can be addressed to the following:
- all devices on the bus – using the CCC broadcast command: START, 0x7E, CCC command code, additional data (if any), repeated START or STOP;
- a specific device – using the directed command: START, 0x7E, CCC command code, repeated START, recipient address, additional data (if any), repeated START or STOP (or again 0x7E).
The direction of transmission is set in the same way as for the usual exchange of i2c/i3c – by the RnW bit in the address byte.
It is easy for slave devices to distinguish a broadcast command from an address command: address commands have a code exceeding 0x7F (0x80 onwards).
CCC commands break down into several groups, which relate to the following:
- obtaining the capabilities of the device, both slave and master;
- getting the status of the device;
- managing addressing;
- switching speed modes.
The description of some CCC commands is not yet included in the basic i3c specification; the protocol is still evolving, and some of its aspects are still being clarified. For example, the basic i3c specification does not cover issues related to devices that can operate in both i2c and i3c mode. This includes switching the bus from one mode to another and the ability to send CCC commands to i3c devices operating in i2c mode.
Let’s focus on a group of commands related to address assignment. There are several such commands: RSTDAA, ENTDAA, SETDASA, SETNEWDA, and SETAASA. Some of them can be both broadcast and address commands. Of course, such pairs have different codes and formats (e.g., with the subsequent byte of the target’s address and without it).
The easiest way to assign dynamic addresses to i3c slave devices is to force them to use existing static addresses as dynamic addresses. Moreover, this can be done with just one broadcast SETAASA command or for a specific device with the SETDASA command.
If you need to distribute the addresses on the i3c bus independently, the procedure is somewhat more complicated.
The ENTDAA broadcast command forces all i3c slave devices (if they do not already have a dynamic address assigned) to go into address assignment mode. Further, the master sends a repeated START and broadcast address 0x7E with the RnW bit raised. Each i3c device that does not yet have a dynamic address must acknowledge acceptance with an ACK and send its 48-bit, so-called “Provisional ID,” in a loop. In this case, the dynamic addressing arbitration process is activated, in which the device with a larger identifier wins the arbitration, and the master sends the address to it. After that, the device that received the dynamic address stops transmitting its “preliminary identifier” and exits the process. The next device wins the arbitration, and so on. The procedure always ends with STOP.
It is worth noting that before starting the assignment of dynamic addresses, the master device must be aware of how many slave devices it has on the bus. This can be done in different ways: polling the bus, getting the number of devices on the bus from the host (e.g., the OS driver), reading the value from its own memory, etc.
Another managing addressing command is SETNEWDA. It allows users to change one assigned dynamic address to another. For example, the sequence SETAASA, SETNEWDA avoids the implementation of the procedure related to ENTDAA in simple systems based on i3c.
The RSTDAA command resets the dynamic address assigned to one of the above-mentioned commands – either for all devices at once (broadcast version of RSTDAA) or individually with a reference to a specific dynamic address for reset.
We examined the most common cases of addressing control using CCC commands. In fact, there may be more cases because devices such as an i3c hub or i3c bridge can be present on the bus.
IBI
If you have not encountered IBI yet, i3c uses the so-called IBI (i.e., interrupts that do not use additional physical lines (e.g., Message Signaled Interrupts (MSI), sending message interrupts)), unlike the classical out-band, which requires a separate line and a separate port for implementation.
To issue an interrupt, the slave device waits for START (but not a repeated START so as not to interfere with the current exchange) or generates its own START command, which is followed by its own address with the RnW bit raised. The master device recognizes this state and reads the interrupt data from the device that caused the interrupt by regular reading. The specification covers only one byte of interrupt message data. In general, however, there can be more; the number can be set in one of the device registers. To eliminate possible competition on the bus, the master device uses the priority mode, which is not discussed here.
IBI can be used to submit error messages, slave device status notifications, or data alert signals. The specification does not limit the application of interrupts in any way.
Hot-plug function
Another new feature is the hot-plug for devices on the bus. The mechanism describes the procedure for all participants on the bus to identify and enable new devices into the exchange. This mechanism also provides a means of deep “hibernation” for i3c devices to save energy with subsequent “waking up” and reconnecting. The got-plug brings additional demands to devices at the physical level (the order of pulling SCL/SDA lines to a logical level, etc.). At the transport and session levels, the IBI mechanism is activated and the individual exchange procedure using CCC commands is defined.
For IBI, the reserved address 0x02 with the RnW bit raised is used. The slave device waits for the moment when the bus is available and sends an interrupt request with the specified address (this sequence is a request to assign a dynamic address). The master device responds with the CCC ENTDAA command. The connecting slave device sends its preliminary identifier, and then the procedure for assigning a dynamic address described above is repeated. On a separate note, the master must always assign the same address to the slaves.
The master has no way of determining if the slave has turned off or not, except by periodically polling the bus. It can do this, for example, by checking the status of devices with the CCC GETSTATUS command.
Widely known i3C extensions
i3c has the potential for expansion. Many companies are actively trying use cases for the products under development. A description of some of them is already publicly available. For example, i3c is used as a transport for SMBus. When organizing access to Serial Presence Detect (SPD, a mechanism used to identify and configure memory modules), the possibility of positioning (address setting) is added to the exchange, and each read/write operation is preceded by a submission of the required address to the slave. The SMBus specification provides a detailed description of such transactions.
The set of vendor-specific CCC commands in i3c expands the capabilities of the i3c protocol without any interference with the basics. For example, if reading or writing is constantly performed from the same address, you can introduce your own command and conduct a poll without spending bandwidth on a typical preliminary preamble.
What’s next?
On the one hand, it is hard to find a controller or a device that supports i3c nowadays. Therefore, if it is necessary to write an appropriate driver or even develop the hardware of one or more sensors, the use of a simulator will be of great help (e.g., Simics). With Simics, it will take about 3 weeks to develop an i3c controller model. Then, it can be used to run an unmodified binary driver, which might be included as part of the BIOS, bootloader, or OS.
On the other hand, if you are developing application software using various sensors, you should pay attention to the new i3c framework for Linux (3).
Both will allow you to start using the latest solutions immediately.
Fig. 5. Linux i3c framework structure
Sources:
- UM10204 I2C-bus specification and user manual Rev. 6 — 4 April 2014, User manual. Available here.
- MIPI Alliance, Specification for I3C Basic Improved Inter Integrated Circuit Version 1.0 – 19 July 2018, MIPI Board Adopted 8 October 2018. Available here.
- Web-site materials “Embedded Linux Wiki”. Available here.
- System Management Bus (SMBus) Specification Version 3.1 – 19 Mar 2018. Available here.
