For most use cases, custom CCCs (including the command codes that are defined for vendor or Standards use, see Q18.4, "What are Vendor / Standard Extension CCCs, who can use them, and how are they differentiated among different uses?") should generally be used as configuration or control commands, sent from an I3C Controller to one or more I3C Target 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 Target, 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 Target (see Q12.3, "What are CCCs (Common Command Codes) and why are they used?").
Additionally, since the Command Code and Defining Byte for CCCs are sent to the I3C Broadcast Address 7’h7E and rely on a special ‘modality’ that must be observed by all Targets, handling for custom CCCs might need to be implemented differently within the Target.
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 Target Device, while transfers in their content protocol should be used for data transfers between a Controller and a Target.
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 Targets, or broadcast mode changes to all Targets 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 Targets on the I3C Bus and various Targets might handle such CCCs differently (i.e., by not using a common interpretation; see Q18.4, "What are Vendor / Standard Extension CCCs, who can use them, and how are they differentiated among different uses?" for guidance).
- Control commands that switch between multiple endpoints within a Target, using a multiplex model that chooses how and where a standard Write transfer might be directed and processed, or where a Target 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, and this might present a limitation for the use case, and might restrict the modality for using such a Target.
- Special messages sent only to the Target 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 rely on software, versus implementations that handle 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 Target 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 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 Target 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 Target Devices which would not have been fully optimized to ignore such custom CCCs, or with other Target 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 Q18.4, "What are Vendor / Standard Extension CCCs, who can use them, and how are they differentiated among different uses?"). For such situations, it might not be possible to predict these issues in advance until full system integration testing is performed.
Note: Higher-level use cases could use a mix of Write/Read transfers for the content protocol, together with custom CCCs for targeted configuration and control functions. Such a protocol 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 Target Device. For some specific aspects custom CCCs might be recommended, whereas other use cases involving multiple simultaneous endpoints might be better served with Virtual Target capabilities (see Q20.2, "What is a Virtual Target?").
Implementers seeking more specific guidance or recommendations should contact the I3C WG within MIPI Alliance for assistance.