For most use cases, custom CCCs (including the command codes that are defined for Vendor or Standards use, see Q1.31) should generally be used as configuration or control commands, sent from an I3C Master to one or more I3C Slave Devices. Using custom CCCs for larger data transfers is not recommended.
When considering the practical concerns of implementing support for custom CCCs in an I3C Slave, it is important to note that CCCs in I3C are generally used as shorter messages that are separated from the standard content protocol (i.e., Write and Read transfers in SDR Mode, or any HDR Modes) and are not intended to interfere with normal messages sent to a Slave (see Q1.20).
Additionally, since the Command Code and Defining Byte for CCCs are sent to the I3C Broadcast Address (i.e., 7’h7E) and rely on a special ‘modality’ that must be observed by all Slaves, handling for custom CCCs might need to be implemented differently within the Slave.
With these considerations in mind, implementers should consider using custom CCCs for special purposes, taking advantage of the CCC flows and their separation from the content protocol, to affect changes to the flow or meaning of transfers that are used in their content protocol. By contrast, transfers within their content protocol (such as Write or Read transfers in SDR Mode, or any HDR Modes) should be used for data‑intensive transactions. In most cases, custom CCCs should enable new mechanisms for configuring or controlling a Slave Device, while transfers in their content protocol should be used for data transfers between a Master and a Slave.
The following examples are provided as guidance for custom CCC definitions:
- Configuration commands that switch between various supported formats of index or selection that might be used in a Write command, or the first phase of a two-phase Write+Read command
- Configuration commands that send a directed mode change to particular Slaves, or broadcast mode changes to all Slaves that support a particular capability or feature (if applicable)
- Note that custom Broadcast CCCs (i.e., for Vendor or Standards use) should be used with caution, as these are received by all Slaves on the I3C Bus, and various Slaves might handle such CCCs differently (i.e., by not using a common interpretation; see Q1.31 for guidance).
- Control commands that switch between multiple endpoints within a Slave, using a multiplex model that chooses how and where a standard Write transfer might be directed and processed, or from where a Slave might source the data message for a Read transfer
- In this case, the custom CCC acts as a command to the multiplexor logic.
- However, such a multiplex model means that only one endpoint at a time can be selected for active use, which might present a limitation for the use case, and might restrict the modality for using such a Slave.
- Special messages sent only to the Slave hardware (i.e., the Peripheral logic) whereas the data‑intensive transfers in the standard content protocol might be implemented via software or other agents that connect to the Peripheral logic, and would not need to see such special messages
- In this case, the Peripheral logic would be expected to offer a quick response due to CCC framing, so a shorter CCC message would offer rapid response due to the expectations based on capabilities in Peripheral logic, versus waiting for software or other agents to respond, which might lead to delays.
- By contrast, an implementation that used Peripheral logic with software to respond to Direct GET CCCs might not be capable of successfully responding to the first such attempt, and would rely on ideal timing conditions to successfully respond to subsequent attempts.
- Note that this might only apply to implementations that relied on software, versus implementations that handled custom CCCs natively (i.e., entirely within hardware).
- Commands that change modes to initialize new functions or enable a new modality, which might change the interpretation of standard transfers for the content protocol (e.g., firmware download, key exchange)
- For example, a custom CCC might act as a method for entering or exiting the modality in which the standard transfers are applied to a new purpose (such as transferring new firmware contents or key data). Upon exiting the modality, the new function of the Slave would be applied based on the data transferred during the modality, and the standard content protocol would be used for subsequent operations with the new function.
For other use cases that do not generally follow these guidelines, or use cases that rely on larger message lengths for data-intensive transactions, a content protocol that primarily uses standard transfer commands (i.e., not CCCs) is strongly recommended. Using custom CCCs for data-intensive transactions on the I3C Bus might cause implementation issues for various Slave Devices that are based on Peripheral logic and use “software” to handle the response for custom Direct GET CCCs. Additionally, using custom CCCs might introduce integration issues or other platform power concerns that might only appear on I3C Buses with other Slave Devices which would not have been fully optimized to ignore such custom CCCs, or with other Slave Devices that relied on different interpretations of custom CCCs and might not understand a particular use of SETBUSCON for the use case (as defined in Q1.31). For such situations, it might not be possible to predict these issues in advance, until full system integration testing is performed.
Note that higher-level use cases could use a mix of Write/Read transfers for the content protocol, along with custom CCCs for targeted configuration and control functions, which would take advantage of the strengths of CCCs as well as the ways in which CCCs are well-suited for effective changes to control, modes or operational parameters of an I3C Slave Device. For some specific aspects custom CCCs might be recommended, whereas other use cases involving multiple endpoints might be better served with Virtual Slave capabilities (see Q1.34 for more details) if such endpoints would need to be used simultaneously.
Implementers seeking more specific guidance or recommendations should contact the I3C WG within MIPI Alliance for assistance.