Note: This question does not apply to I3C Basic v1.0.

In I3C v1.1, the Data Transfer Codings for Multi-Lane in SDR Mode (SDR-ML) define the Header Byte to contain supplementary information to be sent on SDA[1] (i.e., the first Additional Data Lane) when Multi-Lane is enabled for SDR Mode. This supplementary information includes the inverse of the Address, since the Header Byte was defined to include the I3C Address Header and was intended to be received and understood by existing I3C Targets that did not necessarily support SDR-ML.

Upon review, the I3C WG realized that this method would cause implementation challenges during an Arbitrable Address Header (i.e., after a START) if the I3C Controller were required to echo any changes it saw on SDA[0] (i.e., to track changes that an I3C Target might drive during Address Arbitration) when emitting the inverse on SDA[1]. The I3C v1.1.1 specification address these issues by changing the definition of the Header Byte for SDR-ML to only require the I3C Controller to send this supplementary information on SDA[1] for the Header Byte (i.e., an Address Header) after a Repeated START. When sending the Header Byte after a START, the I3C Controller is now required to keep SDA[1] and any other Data Lanes in a High-Z state, rather than driving this supplementary information.

In SDR Mode, CCCs are always sent in 1-Lane mode, allowing all I3C Targets to track the Command Code and Defining Byte (if any) in the CCC Framing. This rule places limitations on the use of SDR-ML:

  1. If SDR-ML is used, then the Targets should not rely on supplementary information on SDA[1] for the Header Byte (i.e., the Address Header); the supplemental information should be treated as optional, because 1-Lane Targets (i.e., Targets that might not support SDR-ML) must track CCC framing and flow elements but can only see SDA[0].
  2. Transfers after a Repeated START that comprise Broadcast CCCs (i.e., transfers addressed to 7’h7E) must also be sent only in SDR 1-Lane mode. As a result, SDR-ML cannot be used for Broadcast CCCs in SDR Mode.
  3. Transfers after a Repeated START that comprise CCC flow elements (e.g., Direct CCC segments addressed to a specific Target or Group) must only be sent in SDR 1-Lane mode. As a result, SDR-ML also cannot be used for Direct CCCs in SDR Mode.

Conditions #2 and #3 above are especially relevant because both Broadcast CCCs and Direct CCCs may be mixed in among Private Write/Read transfers in continuous SDR Mode framing (i.e., without intervening STOP Conditions). In such cases the Controller should not send the supplementary information during the Address Header, and Targets supporting SDR-ML are required not to depend on it, because they will know that the Controller is sending a CCC. Furthermore, the Controller must not use SDR-ML data byte encoding for CCCs (both Broadcast and Direct) because some Targets on the I3C Bus might not understand the encoding.

FAQ Type: