Fullscreen HTML5Med Res (??MB)HTML4

The MIPI I3C Bus There is a brand-new serial bus on the block named I3C (Improved InterIntegrated Circuit). It is beginning to appear in mainstream parts; here’s what you need to know about it. By Andrew Levido R ight now, if you want to connect a peripheral like a sensor or an EEPROM to a microcontroller, you would probably use either the SPI (Serial Peripheral Interface) or I2C (Inter-Integrated Circuit) bus. These are tried and tested serial interfaces that date back to the 1980s. The new I3C standard was developed by the MIPI Alliance (www.mipi. org) and incorporates key attributes of the venerable I2C and SPI interfaces, as well as some interesting new features such as dynamic addressing, in-band interrupts, high data rate modes and 28 Silicon Chip hot-join capability. As the name suggests, I3C is closely aligned with I2C. In fact, I2C devices can even be used on an I3C bus. Like SPI and I2C, I3C uses a controller, typically a peripheral within a microcontroller, and one or more targets. Fig.1 shows a comparison between an I2C, SPI and I3C bus, each connecting a controller (master) with three targets (slaves) that can each interrupt the controller. With I2C, the targets are addressed via the bus, whilst SPI requires a separate chip select (CS) signal for each target. I2C uses bidirectional data transfer on the data line (SDA), while SPI requires two unidirectional lines (MISO and MOSI) for bidirectional communication. Both require separate interrupt lines if targets are to interrupt the processor asynchronously. I3C uses device addressing and bidirectional data transfers, just like I2C, but does not require dedicated interrupt signals, since targets can send interrupts to the controller via the bus. The best of both worlds Fig.1: compared with I2C and SPI, I3C requires fewer data lines for bidirectional communication with interrupt capability. Data throughput is similar to SPI, while addressing is managed over the bus. The I2C protocol uses open-drain drivers to achieve bidirectional signalling on the clock and data lines. High-to-low transitions are actively driven, but low-to-high transitions rely on pull-up resistors, so the signal rise time is limited by the resistor value and bus capacitance. The maximum data rate that can be achieved over I2C is therefore significantly lower than SPI, where the bus is actively driven high and low by push-pull drivers. For I2C, the maximum clock speed is typically 400kHz, or 1MHz with Fast mode+ drivers. There is a standard allowing speeds up to 3.4MHz, but it is not widely supported. The SPI interface does not have standard clock rates but can typically operate at a maximum clock speed of 10-20MHz. I3C uses drivers that can operate in open-drain mode when required, but they switch to push-pull mode whenever possible to maximise the data transfer rate. External pull-ups are not required – these are provided by the controller when necessary. Besides using open-drain drivers when communicating with legacy I2C devices, open-drain drivers are used whenever bus arbitration is required; we’ll cover that in more detail later. Australia's electronics magazine siliconchip.com.au Data transfers generally use the pushpull drivers. As a result, the I3C bus operates at a range of clock speeds. In pushpull mode, the maximum clock speed is 12.5MHz, while in open-drain mode, it is 2.5MHz. The clock speed drops to 400kHz (or 1MHz for Fm+) when communicating with legacy I2C devices. Address arbitration All communications on the I3C bus begin with the bus in the idle state, where the SDA and SCL lines are both high, and with open-drain drivers enabled. The start of a transaction is indicated by a start condition, a highto-low transition on SDA while SCL remains high. A transaction is terminated with a stop condition, a low-tohigh transition on SDA with SCL high. All other SDA transitions occur with SCL low. Repeated start conditions may be issued to allow multiple messages per transaction. A target address header follows each start or repeated start condition. If all this sounds familiar, that’s because, so far, this is identical to how I2C works. One key difference is that, with I3C, it is possible for targets to issue a start condition and/or to emit the address header under certain circumstances. On an I2C bus, only the controller can do that. This can happen when a target wishes to signal an interrupt to the controller, a device wants to ‘hot join’ the bus, or a target wishes to become the controller. It is therefore possible that two or more devices may try to write the address header to the bus at the same time. We need a mechanism to arbitrate this conflict. The open-drain nature of the bus during this phase provides a form of Fig.2: address arbitration occurs if two devices simultaneously attempt to write an address header to the bus. On the fourth clock cycle, device A’s zero overrules device B’s one; device B recognises this and gives up. Because zero-bits are asserted actively on the bus, while ones are passive, the device with the lowest address always wins arbitration. natural arbitration, ensuring that the device with the lowest address always ‘wins’. Consider the example shown in Fig.2. Here, devices A and B, with hexadecimal addresses 0x26 (binary 010 0110) and 0x29 (binary 010 1001), respectively, attempt to write their address headers (7-bit address + read/ write bit) to the bus. On the first clock cycle after the start condition, each emits a logic zero by pulling the bus down with their opendrain driver. Both A and B monitor the bus and check that its level matches the value they emitted. If so, they each continue to deliver the header. Both devices emit a logic one on the second clock cycle, and the passive pull-up pulls the bus high. Again, each device sees that the bus state is as expected and moves on to the next bit. This process continues until the 4th bit, when device A emits a zero and device B emits a one. The bus will be pulled low by device A’s open-drain driver, so device B will see a mismatch between the logic level it emitted and that which appeared on the bus. At this point, device B has ‘lost’ the arbitration and ceases to participate. Meanwhile, device A continues to place its address on the bus unopposed, and the transaction it initiated ensues. Under these circumstances, device B will likely reattempt to assert the header after the transaction concludes and the bus is idle once again. This type of arbitration is zero-­ dominant, so the device with the lowest address always wins. For this reason, most controller-initiated I3C transactions don’t begin with a target address header as they do in I2C. If they did, it would not be possible for the target with the highest address to win an arbitration. Fig.3: controller-initiated read or write transactions on the I3C bus look similar to their I2C counterparts. However, I3C transactions generally begin with the special address 0x7E, allowing targets to assert their addresses if necessary. Each data byte is followed by a T-bit rather than an ... ... acknowledge bit; it is a parity bit for writes and a continuation bit for reads. siliconchip.com.au Australia's electronics magazine October 2024  29 Instead, they generally begin with the special address 7E hexadecimal (111 1110 binary). This address is higher than any valid target address, so it is guaranteed to lose arbitration to any target, should there be a conflict. sending data bytes, depending on the value of the read/write bit. Because the sender is in pushpull mode, it is not possible for the receiving device to ACK each byte, as happens in I2C. Instead, the sending device sends a ‘T-bit’ on the 9th clock cycle. Single data rate transactions For writes, the T-bit sent by the conI3C supports several different trans- troller is a parity bit protecting the preaction types. Let’s first look at a sim- ceding byte. Odd parity is used; The ple example where an I3C controller parity bit is set or cleared such that the wishes to write to or read from a tar- total number of ones in the data and get, as illustrated at the top and centre the parity bit is odd. of Fig.3, respectively. In the case of reads, the target sets SDR transactions begin from the the T-bit to indicate that more bytes of idle state, with the controller issu- data will come. The last byte has its ing a start condition followed by an T-bit cleared. address header containing the special Fig.3 also shows a typical hybrid 7-bit address 0x7E and a write (zero) write-read that might be used to bit. All I3C targets will acknowledge address and then read a specific reg(ACK) this address by pulling SDA low ister in a target. The arbitrable 0x7E on the 9th clock cycle. header is written as before, followed The controller then emits a repeated by a repeated start condition and a start condition followed by a non-­ write of the register address to the tararbitrable address header containing get. Another repeated start condition the target’s dynamic address, along is then issued, followed by a read to with the read or write bit, depend- obtain the register value; in this case, ing on the desired data direction. a single byte. The target with a matching dynamic Apart from the T-bit replacing the address will acknowledge (ACK), and acknowledge bit, and the clock speed, any others will ignore the rest of the this is all very similar to I2C. transaction. Apart from this ACK, the whole In-band interrupts transaction following the repeated One elegant feature of I3C is the start is carried out in push-pull mode in-band interrupt (IBI) capability. A with a nominal 12.5MHz clock. The target may signal an interrupt by placcontroller or the target then begins ing its dynamic address (and the read/ write bit set to one) on the bus following a start condition. It may do this when the controller or another target initiates a start condition, or it may emit the start condition itself. Since a controller message generally begins with the 0x7E address, the interrupting target will win the arbitration. If two or more targets interrupt simultaneously, the lowest addressed one will win. Fig.4 shows the typical IBI process. The controller may accept the interrupt by ACKing the request as shown at the top or decline it by NACKing it as shown below that. If the controller accepts the interrupt, it reads in a “mandatory byte” (MDB) sent by the interrupting target with details of the interrupt source. The target may optionally send additional bytes of data, indicated by the value of the T-bit. Once finished, the controller terminates the transaction with a stop condition. If the controller denies the IBI request, the target may continue to try interrupting until the controller accepts. The controller may prevent a target from interrupting by sending a specific command to the target. Common command codes This introduces another feature of the I3C standard – the ability to send predefined common command codes (CCC) to targets. All targets must support a subset of CCCs, but others are Fig.4: a target may signal an In-band Interrupt (IBI) by asserting its address header after a start condition. The controller accepts or rejects the IBI request by ACKing or NACKing the address. If accepted, the controller reads a Mandatory Byte describing the interrupt reason; the target may send further data after that. Fig.5: common command codes (CCCs) allow the controller to put targets in defined states (eg, by turning IBI on or off) or to query the target (eg, to get device ... ... characteristics). Some CCCs are broadcast to all targets on the bus, while others are directed to one or more specific devices. 30 Silicon Chip Australia's electronics magazine siliconchip.com.au optional or only required when the target has specific features. All CCCs are one byte long, with those in the range 0x00 to 0x7F being broadcast codes that all devices will respond to, and those in the range 0x80 to 0xFF being direct codes intended for only a specific target. The standard defines many CCCs, a selection of which are included in Table 1. Fig.5 shows how broadcast or direct CCCs are used. Broadcast CCC transmissions begin with the special address 0x7E, followed by the command code and any associated data bytes. Direct CCCs begin the same way, with a 0x7E address followed by the CCC. This time, there may be a ‘defining byte’ associated with the CCC. A repeated start condition is then issued, followed by the dynamic address of the target to which the CCC is directed, plus a read/write bit. Additional targets may be addressed by issuing another repeated start condition and target address header. Dynamic addressing So far, we have referred to target addresses as though they are fixed, like I2C device addresses. In I3C, the controller must assign each target a 7-bit dynamic address before any directed transactions can occur. The target retains this address until it is reset or the target receives a Reset Dynamic Address Assignment (RSTDAA) CCC. Dynamic addressing has a couple of advantages over fixed addressing. Firstly, since lower addresses have higher arbitration priority, the controller can assign interrupt priorities by appropriate dynamic address choices. Secondly, it avoids conflicts between devices with identical static addresses, as occurs with I2C. That it can happen is unsurprising since there are only about 120 non-­ reserved 7-bit addresses and many thousands of unique devices. For example, the site https://i2cdevices. org/addresses suggests the address 0x44 is shared by no fewer than 19 devices, ranging from an IR temperature sensor to a high-side current monitor to a resistive touchscreen controller. Dynamic addressing avoids such overlaps. Table 1 – some of the more frequently used I3C Common Control Codes CCC Type ENEC Enable Events Command Broadcast Write 0x00 Direct Write 0x80 Enable Target events such as Hot-Join and In-Band Interrupt RSTDAA Reset Dynamic Address Assignment Broadcast Write 0x06 Direct Write 0x86 Discard current Dynamic Address and wait for new assignment ENTDAA Enter Dynamic Address Assignment Broadcast Write 0x07 Enter Controller initiation of Dynamic Address Assignment Procedure SETDASA Set Dynamic Address from Static Address Direct Write 0x87 Controller assigns a Dynamic Address to a Target with a known Static Address SETNEWDA Set New Dynamic Address Direct Write 0x88 Controller assigns new Dynamic Address to a Target SETMWL Set Maximum Write Length Broadcast Write 0x09 Direct Write 0x89 Controller sets maximum write length SETMRL Set Maximum Read Length Broadcast Write 0x0A Direct Write 0x8A Controller sets maximum read length and IBI payload size GETMWL Get Maximum Write Length Direct Read 0x8B Controller queries Target’s maximum possible write length SETBUSCON Set Bus Context Value Broadcast Write 0x0C Brief Description Controller specifies a higher-level protocol and/or I3C specification version GETMRL Get Maximum Read Length Direct Read 0x8C Controller queries Target’s maximum possible read length and IBI payload size GETPID Get Provisional ID Direct Read 0x8D Controller queries Target’s Provisional ID GETBCR Get Bus Characteristics Register Direct Read 0x8E Controller queries Target’s Bus Characteristics Register GETDCR Get Device Characteristics Register Direct Read 0x8F Controller queries Target’s Device Characteristics Register ENTHDR0 Enter HDR Mode 0 Broadcast Write 0x20 Controller has entered HDR-DDR Mode ENTHDR1 Enter HDR Mode 1 Broadcast Write 0x21 Controller has entered HDR-TSP Mode ENTHDR2 Enter HDR Mode 2 Broadcast Write 0x22 Controller has entered HDR-TSL Mode ENTHDR3 Enter HDR Mode 3 Broadcast Write 0x23 Controller has entered HDR-BT Mode RSTACT Target Reset Action Broadcast Write 0x2A Direct Write & Read 0x9A Controller configures and/or queries Target Reset action and timing GETSTATUS Get Device Status Direct Read 0x90 Controller queries Target’s operating status GETMXDS Direct Read 0x94 Controller queries Target’s maximum read/write data speeds and maximum read turnaround time Get Maximum Data Speed siliconchip.com.au Australia's electronics magazine October 2024  31 Fig.6: dynamic addresses can be assigned by two methods – from a static 7-bit address using the SETDASA CCC, or via the Dynamic Address Assignment process started by the ENTDAA CCC. The latter is preferred; in this case, bus arbitration is used to assign addresses to all devices in sequence. Fig.7: the Provisioned Identifier (PID) is a 48-bit value containing a manufacturer ID, a part ID, an Instance ID and a 12-bit device characteristic descriptor. On some parts, the Instance ID is programmable via pins or other means to allow multiple instances of the same device to be uniquely identified on the bus. There are two different options for assigning dynamic addresses. Some early devices do have a static 7-bit address, which is used to assign a dynamic address using the CCC “Set Dynamic Address from Static Address” (SETDASA), as shown at the top of Fig.6. The static address can’t be used for any other purpose. The controller starts the transaction in the usual way, sending the SETDASA CCC, followed by a restart, then the static address of the target with the read/write bit set. When the target ACKs the static address, the controller sends the dynamic address it wishes to assign. The controller can optionally set further dynamic addresses by repeating the process after issuing a repeated start condition. This approach does not really help with the problem of address duplication, so the preferred option is to assign dynamic addresses based on a 48-bit device identifier known as a ‘Provisioned ID’ (PID), the format of which is shown in Fig.7. The upper 15 bits of this are the manufacturer ID assigned by the MIPI Alliance. The next bit, #32, is usually zero, while the following 16 bits are the part identifier. Bits 12 through 15 32 Silicon Chip are an instance ID. These may be programmed by setting device pin(s) to specific levels, to allow the user to deploy multiple instances of the same device on the same bus. The process for assigning dynamic addresses to these targets relies on the same bus arbitration mechanism we saw earlier. The lower part of Fig.6 shows this in action. The CCC Enter Dynamic Addressing Assignment (ENTDASA) is sent, followed by a repeated start condition and another 0x7E address. Any targets on the bus that do not have a dynamic address assigned will ACK this and begin writing their 48-bit PID, followed by the contents of two 8-bit capability registers, BCA and DCA. This write is arbitrable, so only the device with the lowest PID will complete the process, at which time the controller sends the dynamic address it wishes to assign. If the device acknowledges, the dynamic address is considered assigned. A repeated start condition is issued, and the whole process is repeated for the remaining targets with unassigned dynamic addresses until none are left. At that point, the 0x7E address is passively NACKed, and the assignment process is terminated. Hot-Join mechanism Fig.8: the hot join process is similar to the IBI process, except that the joining device uses the special 0x02 address. If the controller ACKs the request, the target waits for a dynamic address to be assigned by the controller. A target may join an I3C bus once it is up and running (for example, by being plugged in or powered up). It does this using a mechanism similar to the In-Band Interrupt, shown in Fig.8. The hot-joining device emits an address header with the special high-priority address 0x02, guaranteeing it will be heard. The controller may accept the hotjoin request by ACKing it or reject it by NACKing it. If the request is accepted, the joining device waits for the controller to assign a dynamic address via Australia's electronics magazine siliconchip.com.au Fig.9: the I3C controller produces the SCL clock with a duty cycle such that the high period is 40ns or less. I2C devices are required to have a 50ns glitch filter on their SCL and SDA inputs, so the I3C clock should be invisible to them. Fig.10: the HDR exit and restart patterns; the exit pattern is always followed by a stop condition and returns the bus to the idle state. The restart pattern is analogous to the repeated start condition and delineates multiple messages within an HDR transaction. the ENTDAA CCC process described above. If the controller rejects the request, the joining device will likely continue to make requests unless the controller switches off hot-join requests via the DISEC CCC. Note that this process works if more than one device joins simultaneously – the 0x02 address will be emitted by all devices simultaneously, and they will all succeed in the arbitration. The controller ACK will put them all in a state awaiting dynamic address assignment, and the ENTDAA assignment process will assign them all addresses in order of their PIDs. I2C compatibility I mentioned before that I2C targets can co-exist with I3C targets on the same bus. It is important that these devices don’t react to I3C messages and potentially disrupt them. I3C uses a couple of mechanisms to reduce the chance of that happening. Firstly, the special address 0xFE in the header of I3C messages is a reserved address in I2C and should be ignored by all complying devices. On top of this, I3C takes advantage of the 50ns glitch filter that is required by the standard on the SDA and SCL pins of I2C devices. The duty cycle of the SCL signal is managed so that the clock high period is always less than or equal to 40ns, making the I3C clock ‘invisible’ to I2C targets. They should ignore any signal on their SDA line, because they don’t see any clock transitions on SCL. Fig.9 shows how this works. For the 12.5MHz push-pull clock, the high and low pulses are naturally 40ns long at a 50% duty cycle. The 2.5Mhz opendrain clock is emitted at a duty cycle of around 10%, leaving the high pulses 40ns long. This behaviour is only needed if there are legacy devices on the bus. Most controllers allow for a 50% duty cycle to be used on both clocks for ‘pure’ I3C buses. When communicating with I 2C devices, the SCL clock is reduced to 400kHz or 1MHz with a 50% duty cycle and transactions are carried out in open-drain mode with signalling conforming to the I2C standard. However, I3C does not support the I2C features of 10-bit addressing, clock stretching or multi-master operation, so be careful. High data rate modes So far, everything we have covered is occurring in ‘Single Data Rate’ (SDR) mode. The I3C protocol supports several higher data rate (HDR) modes. I am only going to cover the most common one of those in the interests of brevity. Regardless of the HDR mode chosen, the I3C bus is always initialised and configured in SDR mode. Only limited extra functionality is available in the HDR modes – you can’t assign dynamic addresses or receive in-band interrupts, for example. HDR modes are always entered from SDR mode by issuing the appropriate Enter HDR Mode X (ENTHDRx) CCC. Once entered, the HDR mode has a buswide effect until it is exited via an HDR exit pattern. Within an HDR mode transaction, multiple messages can be separated by HDR restart patterns, Fig.11: HDR-DDR transactions begin with an ENTHDR0 CCC, followed by a command and address word. Data is then sent one word at a time to or from the controller, depending on the command. The last data word is followed by a five-bit CRC and an exit or restart pattern. siliconchip.com.au Australia's electronics magazine October 2024  33 analogous to the repeated start condition in SDR mode. The HDR exit and restart patterns are shown in Fig.10. The exit pattern is defined as four consecutive falling edges on SDA while SCL is low. It is always followed by a stop condition. The restart pattern is defined as two successive toggles of SDA (fall, rise, fall, rise) followed by a rising edge on SCL. Fig.12 shows how the command, data and CRC words are constructed. The Command and CRC words begin with the same preamble but are distinguishable by context – the command word only ever comes immediately after entry to the HDR mode or a restart pattern, while the CRC only ever comes after a data word. Only a very limited range of CCCs are supported in HDR-DDR mode. HDR-DDR Other features The common HDR Double Data Rate (HDR-DDR) mode uses the same 12.5MHz clock as SDR mode but allows data bits to be sent on both rising and falling clock edges, effectively doubling the data throughput. Fig.11 shows how a typical HDRDDR transaction works. After sending the ENTHDR0 CCC in SDR mode, the bus switches to HDR-DDR mode. The controller then issues a command and address word indicating the data direction (read or write) and the intended target’s dynamic address, followed by one or more data words written by either the controller or the target, depending on the data direction. When all the data has been sent, the sender concludes with a five-bit CRC. The controller then emits a restart pattern if another DDR message is to be sent, or an exit pattern and stop condition if not. The basic unit of transmission (except for the CRC) is a 16-bit word with a two-bit preamble and two trailing parity bits, for a total of 20 bits. DDR mode can achieve an effective data throughput of 20Mbps, comparable with SPI (but with error checking). Faster HDR modes are possible, including some that allow for two or four data lanes and can achieve effective data rates of up to 96Mbps. However, not all modes are supported by all targets. In addition to those features described here, I3C offers some other interesting capabilities, including the ability to reset targets (individually or in groups) over the bus and to send synchronising ‘ticks’ to targets to coordinate timing. It supports group addressing, where a set of targets share a group address (alongside their individual dynamic addresses), so they can be sent messages simultaneously. It is also possible for one target to communicate directly with another via device-to-device tunnelling. There is a lot to this standard; it will be interesting to see what features receive support from chip vendors. Trying it out I have experimented with I3C over the last couple of weeks, using an NXP LPC865 microcontroller with an integrated I3C controller. For targets, I tried a Bosch BMI323 inertial measurement unit (IMU), an ST Microelectronics LPS22HH humidity sensor and a TDK ICM42688P motion sensor. I was able to test a lot of the SDR functionality, and it works as advertised, but the experience was not as smooth as it could have been. I think these rough edges are due to the relative immaturity of the standard. The device data sheets were a mixed bag regarding the thoroughness of their documentation of I3C features – I did have to resort to a bit of trial and error to get things going. The MCU toolchain and the I3C driver provided in the SDK worked fine for my purposes. Debugging the bus was a challenge, as my logic analysers do not currently have support for the I3C protocol. For this reason, I had to resort to printing out waveforms and marking ones and zeros by hand on a few occasions. I am sure that all of these points will improve as I3C becomes more common. Right now, I3C is available on only a limited number of devices, which are helpfully listed at https:// binho.io/blogs/i3c-reference/i3c-­ devices I believe this list will grow, given that the MIPI Alliance lists almost every silicon vendor as a member, and it has a pretty good track record of establishing standards. Over the next few years, I suspect we will see I3C becoming more and more popular. References Fig.12: data is transmitted on both clock edges in HDR-DDR mode. For data and command words, a two-bit preamble is followed by 16 data bits and two parity bits. The CRC word is slightly different and is always followed by a restart or exit pattern. 34 Silicon Chip Australia's electronics magazine I 2C-Bus Specification and User Manual (2021): NXP, siliconchip.au/ link/abtv I3C and I3C Basic specifications: MIPI, siliconchip.au/link/abgm ICM-42688-P: TDK, siliconchip.au/ link/abtw Bosch Sensortec BMI323 Inertial Measurement Unit (IMU): Bosch, siliconchip.au/link/abtx Arm Cortex-M0+ LPC86x 60MHz 32-Bit Microcontrollers (MCUs): NXP, siliconchip.au/link/abty STMicroelectronics LPS22HH High-Performance MEMS Nano Pressure Sensor: ST, siliconchip.au/link/ abtz SC siliconchip.com.au