The I3C Bus protocol supports a mechanism for Slaves to join the I3C Bus after the Bus is already configured. This mechanism is called Hot-Join. The I3C Specification defines the conditions under which a Slave can do that, e.g., a Slave must wait for a Bus Idle condition.
An I3C Slave can issue the IBI in the following two ways:
- Following a START (but not a Repeated START)
- If no START is forthcoming within the Bus Available condition, then an I3C Slave can issue a START request by pulling the SDA line Low. The I3C Master would then complete the START condition by pulling the SCL clock line Low and taking over the SDA.
For normal active I3C Slaves, yes. They should only drive the Bus for an In-Band Interrupt (IBI) when they have seen a STOP and the tBusAvailable time has elapsed (about 1 µs), and in response to a START (but not a Repeated START).
For Hot-Join devices, they do not know the Bus condition, so they wait until the bus is Idle, which means the SCL and SDA are both high for the tIDLE period (about 1 ms).
In addition to open drain, pull-up and high-keeper, the I3C Bus has three distinct conditions under which the Bus is considered inactive: Bus Free, Bus Available, and Bus Idle.
All I3C Devices must be able to process Broadcast CCCs at any time, whether or not they have been assigned a Dynamic Address (DA). For example, an I3C Device may act as an I²C device before it gets its DA assigned. However, it is still expected to ACK the START with 7’h7E; the only exception would be if this Device chooses to remain as an I²C‑only device, in which case, it would leave any 50 ns spike filter enabled.
With most configurations, this is not possible; each Device will have its own manufacturer ID and part number, so no collisions are possible. If more than one instance of the same Device is used on the same I3C Bus, then each instance must have a separate instance ID; otherwise there would be a collision. Likewise, if any Device is using a random number for its part number, then multiple instances from that manufacturer could collide (i.e., could have the same random value that time).
The first part of the ID contains a unique manufacturer ID. Companies do not have to be MIPI Alliance members to be assigned a unique manufacturer ID.
The second part of the ID normally contains a part number (which is normally divided up into general and specific part info for that vendor), as well as possibly an instance number which allows for multiple instances of the same device on the same I3C Bus. The instance ID is usually fed from a pin-strap, or fuse(s), or non-volatile memory (NVM).
During bus initialization, the I3C Master assigns a 7-bit Dynamic Address to each Device on the I3C Bus. For this to happen, each Slave device must have a 48-bit Provisional ID (that is, provisioned with its ID). The Provisional ID has multiple fields, including MIPI Manufacturer ID and a vendor-defined part number. The I3C Slave may also have a static address, which if the Master knows it, allows for faster assignment of the Dynamic Address.
A high-keeper is used for Master-to-Slave and Slave-to-Master bus hand-off, as well as optionally when the Bus is idle. The high-keeper may be a passive weak pull-up resistor on the Bus, or an active weak pull-up or equivalent in the Master. The high-keeper only has to be strong enough to prevent system-leakage from pulling the Bus low. At the same time, the high-keeper has to be weak enough that a Slave with a normal IOL driver is able to pull the Bus line low within the minimum period.
Much of the activity on the I3C Bus is in push-pull mode (that is, with the pull-up resistor disabled) in order to achieve higher data rate. However for some Bus management activities, and for backwards compatibility with I2C, pull-up-resistor-based open-drain mode is enabled. For example: arbitration during Dynamic Address Assignment, and In-Band Interrupt. Also, the ACK/NACK during the 9th bit is done using a pull-up resistor.