The coding and framing details for CCCs have been changed or extended, in three important areas:

  1. Direct Write/Read Commands: In I3C v1.0, Direct CCCs were either Direct Read Commands (Direct GET CCC) or Direct Write Commands (Direct SET CCC). I3C v1.1 adds an additional Direct Write/Read Command (Direct SET/GET CCC) form: a Direct Write immediately followed by a Direct Read with the same Command Code; this form is used for alternatively writing to, and then reading data from, one or more specific I3C Slave Devices. The Direct Write/Read Command uses the Direct CCC framing model per Section 5.1.9.2.2.

Example: An I3C Master might use the MLANE CCC (Section 5.1.9.3.30) to configure an I3C Slave Device to use a specific Multi-Lane configuration using a Direct SET CCC, followed by a Direct GET CCC to read back the active Multi-Lane configuration and confirm that it was selected for operation.  Using both forms of Direct SET CCC and Direct GET CCC within the same SDR frame is considered a Direct SET/GET CCC.

  1. Defining Byte for Directed CCCs: In I3C v1.1, some Directed CCCs add support for a Defining Byte.
    1. In CCC framing for SDR Mode, the coding of the initial CCC is: S, 7’h7E, CCC_byte, Defining_Byte, Sr, Slave_Addr, ....

      For more framing details for SDR Mode, see Table 15 in Section 5.1.9.1.
    2. In CCC framing for HDR Modes, the Defining Byte is sent in the HDR-x CCC Header Block of type Indicator. This framing element is defined differently for each HDR Mode; for more framing details, see Table 53 in Section 5.2.1.2.1.

Depending on the particular CCC, this Defining Byte can be used in several possible ways:

  • It might define a register/code to set, either with or without additional per-Slave info
  • It might select a particular register/code to read, from among several available for that CCC
  • It might indicate one of several completely different sub-commands, each of which might be either required or optional, as needed for the particular CCC definition and use case.

Example: When used with the MLANE CCC, a Defining Byte selects a sub‑command. One sub-command might be used to read the available Multi-Lane capabilities for an I3C Slave Device, as a Direct GET CCC; another sub-command might be used to either configure an I3C Slave Device to use a specific Multi-Lane configuration, or read back the same active Multi-Lane configuration, as either a Direct GET CCC or a Direct SET CCC. For this use case, each Defining Byte has a different purpose and a different, specific data format.

Example: A Defining Byte for the GETCAPS CCC (see Section 5.1.9.3.19) selects among several different capabilities areas, to read from an I3C Slave Device as a Direct GET CCC. For this use case, the Defining Byte may also indicate different formats for the data message returned by the I3C Slave Device.

For some new Direct CCCs defined in I3C v1.1, a Defining Byte is required.

  1. New Optional Defining Bytes: In I3C v1.1, some CCCs that had no Defining Byte in I3C v1.0 now have optional Defining Bytes to extend their functionality and support other new behaviors. If the I3C Master sends the CCC without the Defining Byte then the original functionality or behavior occurs, but if the CCC is sent with the Defining Byte then the optional extended functionality or new behavior is accessed (see Section 5.1.9.2.2).

Many Direct GET CCCs that allow optional Defining Bytes also have a method for indicating whether any additional Defining Bytes are supported. This support would be indicated in the data message returned by the Direct version of a particular CCC (which might be the same CCC) when sent without a Defining Byte. This allows an I3C Master to query an I3C Slave Device to determine whether this capability is supported. The particular CCCs that allow optional Defining Bytes are defined in version 1.1 of the I3C Specification (see Section 5.1.9.3). Additionally, for I3C Slave Devices that support such Direct CCCs and also support any optional Defining Bytes, a Defining Byte value of 0x00 generally results in the same behavior as when no Defining Byte is sent.

While Defining Byte support for such Direct GET CCCs is generally optional, certain Defining Byte values are required or strongly recommended for certain use cases, or when used in conjunction with other features or capabilities. Such Direct CCCs list these conditions or recommendations, in addition to any changes in the format of the data message that might be returned when a Defining Byte is used.

Example: In I3C v1.1, an I3C Master can use the GETSTATUS CCC (see Section 5.1.9.3.15) to determine the operational status of an I3C Slave Device. All I3C Slaves support the use of GETSTATUS without a Defining Byte. But if an I3C Slave also supports the GETSTATUS CCC with any optional Defining Bytes, then the I3C Master may also do either of the following things:

  • Send the Direct GET GETSTATUS CCC with a Defining Byte of 0x00, to return the same data message as if no Defining Byte were used;
  • Send the Direct GET GETSTATUS CCC with any other Defining Byte value listed in Table 24. Any I3C Slave that supports that particular Defining Byte is required to ACK the CCC and return an appropriate data message for that Defining Byte (i.e., not the standard Slave Status). For example, if a Defining Byte value of 0x91 (“SECMST”) is supported, then using this Defining Byte would request the Slave to return alternate status information related to the Slave’s Secondary Master capabilities.
FAQ Type: 
I3C