Why does I3C allow more than one Master on the I3C Bus? What can a Secondary Master do that the Main Master can’t?

The system designer decides whether their system needs more than one Master on the Bus. To provide that flexibility MIPI I3C allows this, but also does not require it. Master handoff is a well defined and controlled mechanism in I3C; if used, it can be relied on.

For most use cases, a Secondary Master is not a required component for an I3C Bus. If your Main Master has all the capabilities and features that you need, and if your use of the I3C Bus wouldn’t benefit from having multiple Master-capable Devices, then you might not need a Secondary Master.

How are the following similar and/or different: In-Band Interrupt, Hot-Join, and Mastership Request (IBI / HJ / MR)?

All three are special, in-band methods that allow the Slave to notify the Master of a new request or state, without having to wait for the Master to query or poll the Slave(s). The term ‘in-band’ refers to doing this via the I3C Bus wires/pins themselves, rather than using methods requiring extra wires/pins.

What is a Virtual Slave?

Generally, a Virtual Slave is a function of a single physical Device that represents multiple I3C Slaves on the I3C Bus, such that the I3C Master can address each of those Slaves independently.

In the simplest form a Virtual Slave could be one of a set of several Slave Devices all integrated into the same physical package, sharing a common set of pins connecting them to an I3C Bus.

What are “Vendor / Standard Extension” CCCs, who can use them, and how are they differentiated among different uses?

In general, the ranges of command codes that are defined for Vendor or Standards use in Table 16 in Section (i.e., the main table that defines the I3C Common Command Codes) can be used by any implementer or any standards developing organization to define custom CCCs that extend I3C to accommodate new use cases. However, the definition of custom CCCs should be considered carefully, as the practical issues of implementation might lead to situations where interoperability could be affected, across multiple I3C Slave Devices that interpret the same command code differently.

How can an I3C Slave lose its I3C Dynamic Address, and how does it become an I2C Slave again?

Once assigned an I3C Dynamic Address, an I3C Slave normally retains it until the Slave is de-powered. However, an I3C Slave will lose its I3C Dynamic Address through the RSTDAA Broadcast CCC, which resets all I3C Slaves back to their initial I2C state. The RSTDAA Broadcast CCC is not normally used; it would only be used to assign a new Dynamic Address.