3.1 Conventional System with Mixed Communication Bus

Figure 3-1 demonstrates a system with a host device having an I3C Controller capability. The I3C protocol is backward-compatible with I²C, allowing I²C client devices to co-exist in an I3C bus. I²C devices on an I3C bus can degrade the bus performance in several ways. Even though I3C supports higher data rates up to 12.5 MHz, the I3C Controller must fall back to lower speeds compatible with I²C to communicate with the I²C devices on the bus. This will lead to a significant reduction in the total data throughout the bus. To ignore the I3C traffic at higher clock speeds, 50 ns spike filters on the SDA and SCL pads must be included while adding the I²C devices to an I3C bus. If any I²C device is added without a spike filter, the I3C bus speed is limited to that of the slowest I²C client. The advanced bus management features of I3C, such as In-Band Interrupt, Dynamic address assignment, and Hot-Join capability, cannot be used with the I²C devices on an I3C bus, thereby limiting the efficiency of bus management and requiring additional handling by the I3C Controller. A mixed bus with I3C and I²C devices further increases the complexity of the bus management and software handling for the I3C Controller, as it needs to communicate with both devices.

In addition, if the host device wants to communicate with SPI/UART-based devices, it would need additional pins to configure the SPI bus and UART port, as shown in Figure 3-1. It must also support the SPI and UART protocols and manage these communication interfaces. The I²C/SPI-based client devices use external signals to send interrupts to the host device. Similarly, they are reset using external signals from the host, thereby increasing the number of pins on the host side. This complex system with mixed buses is simplified with a pure I3C bus and a bridge device having its own I²C /SPI/UART buses, as explained in the Upgraded System using the Multi-Protocol Translator section.