Frequently Asked Questions

The parties that directly developed the MIPI I3C Basic specification have agreed to license all implementers on royalty free terms, as further described in the I3C Basic specification document [MIPI08]. Further, all implementers of the I3C Basic specification must commit to grant a reciprocal royalty free license to all other implementers if they wish to benefit from these royalty free license commitments. And, of course, MIPI itself does not charge royalties in connection with its specifications. MIPI’s intent is to create a robust royalty free environment for all implementers of I3C Basic.

No set of IPR terms can comprehensively address all potential risks, however. The terms apply only to those parties that agree to them, for example, and the scope of application is limited to what is described in the terms. Implementers must ultimately make their own risk assessment.

Yes, Targets can initiate communication using In-Band Interrupt requests. Communication conflicts are solved by Target Address Arbitration.

The basic byte-based messaging schemes used in I²C and SPI map easily onto I3C. Additionally, a set of Common Command Codes (CCCs) has been defined for standard operations like enabling and disabling events, managing I3C-specific features (e.g., Dynamic Addressing, Timing Control), and other functions. CCCs are either Broadcasted (i.e., sent to all Devices on the I3C Bus), or else Directed to a particular Device on the I3C Bus (i.e., by Address).

CCCs do not interfere with, and do not consume any of the message space of, normal Controller-to-Target communications. That is, I3C provides a separate namespace for CCCs.

• For I3C v1.1.1 and earlier: see Table 16 in Section 5.1.9.3 for the main table of CCCs.
• For I3C v1.2 and later: see Table 16 in Section 4.3.7.3 for the main table of CCCs.

CCCs are the commands that an I3C Controller uses to communicate to some or all of the Targets on the I3C Bus. The CCCs are sent to the I3C Broadcast address (which is 7’h7E) so as not to interfere with normal messages sent to a Target. In other words, CCCs are separated from the standard “content protocol” used by normal messages, such as Private Write and Read transfers (in SDR Mode).

The CCCs are used for standard operations like enabling/disabling events, managing I3C-specific features, and other Bus operations. CCCs can be either Broadcasted (i.e., sent to all Devices on the I3C Bus), or else Directed to specific Devices on the I3C Bus (i.e., by Address). All CCC command number values are allocated by MIPI Alliance, and some values are reserved for specific purposes including MIPI Alliance enhancements and other extensions. See the Common Command Codes (CCCs) section for the question, "What are Vendor / Standard Extension CCCs, who can use them, and how are they differentiated among different uses?").

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

• In-Band Interrupt (IBI): A Target uses an IBI Request to notify the Controller of a new state or event. If the Target so indicates in the BCR, then an IBI may include one or more following data bytes. A Target can only use IBI if it has indicated the intent to do in its BCR.
  If the Target indicates it will send data with an IBI, then it is required to always send at least 1 byte, called the Mandatory Data Byte (MDB). Starting with I3C v1.1, the MDB is coded following certain rules. Any optional data bytes after the MDB iswill be a contract between Controller and Target. After sending the last data byte, the Target is required to use the T-Bit mechanism to end the IBI data payload.
  
• Hot-Join (HJ): A Hot-Join Request is used only by a Target that hasn’t yet been assigned a Dynamic Address and is attached or awakened on the I3C Bus after the Primary Controller has initialized it. The Hot-Join Request uses a fixed address which is reserved for this purpose only. The Controller will recognize this fixed address and then initiate a new Dynamic Address Assignment procedure. However, a Target cannot use the Hot-Join Request before verifying that the I3C Bus is in SDR Mode. No data bytes are sent after the address of a Hot-Join Request.
• Controller Role Request (CRR): A Secondary Controller (including the Primary Controller, once it has given up the Controller Role) sends a CRR when it wants to become Controller of the I3C Bus. If the Active Controller accepts the CRR, then it will issue a GETACCCR CCC to pass the Controller Role to the requesting Secondary Controller. It is also possible for the Active Controller to initiate handoff on its own without any Target initiating an CRR, for example when a Secondary Controller wants to return control. No data bytes are sent after the address of a Controller Role Request.

No. If an I3C Target will only be used on I3C Buses that rely on the SETAASA CCC (a Broadcast CCC that auto-sets the Target’s Dynamic Address from its I2C Static Address) and/or the SETDASA CCC (a Direct CCC where the Controller sets the Target’s Dynamic Address using a Direct CCC that references the Target’s I2C Static Address), then that Target will never be asked to use the ENTDAA CCC. In such a case, the Target could participate on the I3C Bus despite not implementing ENTDAA CCC support.

A Target may choose to implement support for either or both of the SETAASA and SETDASA CCCs.

Since both of these CCCs rely on the Controller knowing that Target’s I2C Static Address (and perhaps the Static Addresses of all other Targets as well), these methods can save time for certain use cases, although they do impose some implementation requirements on the system designer.

Nonetheless, MIPI Alliance strongly recommends supporting the ENTDAA CCC, otherwise the Device will only ever be usable on that narrow subset of I3C Buses.

I3C supports Legacy I2C Target devices using Fast-mode (Fm, 400 KHz) and FastMode+ (Fm+, 1 MHz) with the 50 ns spike filter, but not the other I2C modes, and not I2C devices lacking the spike filter, or I2C devices that stretch the clock.

Normally, once a Target is assigned a Dynamic Address, it will be retained until the Target is de-powered. However, a Target will lose its Dynamic Address (and all optional Group Addresses that might be assigned) as a result of the RSTDAA Broadcast CCC, since this resets all Targets back to their initial state. After RSTDAA, Targets that can also operate on a Legacy I²C Bus (per Q15.2 would behave as I²C Targets.

Note:

• The RSTDAA Broadcast CCC is used to reset all Dynamic Addresses, typically before assigning new Dynamic Addresses to Targets, or to return Targets to their initial state.
• The RSTGRPA CCC can also be used to reset some or all assigned Group Addresses, without resetting Dynamic Addresses.
• For I3C v1.1.1 and earlier:
• • See Section 5.1.2.1.1 for requirements on I3C Devices that initially act as Legacy I²C Targets.
• For I3C v1.2 and later:
• • See Section 4.3.2.1.1 for requirements on I3C Devices that initially act as Legacy I²C Targets.

A Target could also lose its Dynamic Address under other circumstances, for example:

• The Device is reset by an out-of-band method, such as a pin-reset
• Optional: The Device is reset by a Peripheral reset (starting with I3C v1.1) which can be invoked two different ways:
  • RSTACT CCC with Defining Byte 0x01, followed by Target Reset Pattern, or
  • A Target Reset Pattern without any preceding RSTACT CCC
    Note: Implementers may determine whether a Target will reset its Dynamic Address on a Peripheral Reset. This behavior is not required, but is recommended for most use cases.

• The Device is reset by a full Target Reset (starting with I3C v1.1) which can be invoked two different ways:
  • RSTACT CCC with Defining Byte 0x02, followed by Target Reset Pattern, or
  • Two consecutive Target Reset Patterns

• The Device goes into deepest-sleep (i.e., power down)

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.11 for Target Reset, including the Target Reset Pattern and the use of the RSTACT CCC to configure the reset action.

For I3C v1.2 and later:

• See Section 4.3.9 for Target Reset, including the Target Reset Pattern and the use of the RSTACT CCC to configure the reset action.

In the case of an I3C Device losing its Dynamic Address in non-standard ways, the Hot-Join mechanism allows the Target to notify the Controller of the event and receive a new Dynamic Address. In cases where the Controller has deliberately caused the Target to lose its Dynamic Address (e.g., by sending the RSTDAA CCC, or by using a Target Reset), the Controller will start a new Dynamic Address Assignment process using the ENTDAA, SETDASA, or SETAASA CCCs.

Note:

• See also Q16.9 for CCCs that can change a currently assigned Dynamic Address.
• See also Q16.11 for information about Group Addresses.
• See also Q20.1 for Offline Mode for I3C Targets, where the Devices retain their Dynamic Addresses through a power-down or deepest-sleep cycle.

After Bus initialization, the I3C Controller uses the Dynamic Address Assignment procedure to assign a 7-bit Dynamic Address to each Device on the I3C Bus. For this to happen, each Target device must have a 48-bit Provisioned ID (that is, each Target is provisioned with its ID). The Provisioned ID has multiple fields, including MIPI Manufacturer ID and a vendor-defined part number.

Since the Provisioned ID is required for the Dynamic Address Assignment process with the ENTDAA CCC, every Target Device must have a unique Provisioned ID on the I3C Bus that does not collide with the Provisioned ID of any other Targets.

Note: The Target may also have a Static Address. If the Controller knows this Static Address, then the Dynamic Address can be assigned faster.

The first part of the PID contains a unique Manufacturer ID. Companies need not be MIPI Alliance members to be assigned a unique Manufacturer ID.

The second part of the PID normally contains a part number (which is normally divided up into general and specific part info for that vendor), as well as possibly an instance number which allows for multiple instances of the same device on the same I3C Bus. The instance ID is usually fed from a pin-strap, fuse(s), or non- volatile memory (NVM).

A random number may be used for the part number, although normally only for test mode, as set by the Controller using the ENTTM (Enter Test Mode) CCC. When a Device that supports random values enters the test mode, the PID[31:0] bits are randomized. When the Controller exits the test mode, the Devices reset bits PID[31:0] to their default value.

Note: The use of a random number in the PID allows for many instances of the same Device to be attached to a gang programmer/tester, relying on the random number to uniquely give each a Dynamic Address. However, the random number should not be used for typical I3C applications where I3C Devices must be uniquely identified, especially by higher-level software that runs on the Application Host that is driving the I3C Controller.

With most configurations this is not possible, because each Device will have its own Manufacturer ID and a unique part number; as a result, no collisions are possible. But if more than one instance of the same Device (product) is used on a given I3C Bus, then each such instance must have a separate instance ID; otherwise there would be a collision. Likewise, if any Device is using a random number for its part number (i.e., in the PID), then multiple instances from that manufacturer could collide (i.e., could have the same random value that time).

If the Controller knows the number of Devices on the I3C Bus, then it can detect this condition: the number of Dynamic Addresses assigned would be less than the expected number of Devices. If that is detected, then the Controller can take steps to resolve such collisions, for example by resetting all Dynamic Addresses with the RSTDAA CCC and restarting the process, or by declaring a system error after a set maximum number (e.g., 3) of such attempts fail.

The implementer may decide how many Group Addresses can be assigned to a Target that supports Group Addressing (which is optional). Such a Target will support a minimum of 1 assigned Group Address, and there is no defined maximum. The Target will also use the GETCAP2 byte (returned by the GETCAPS Format 1 CCC) to indicate how many Group Addresses it can support.

Note: If a Target has been assigned the maximum number of Group Addresses that it can support, then it will NACK the SETGRPA CCC, since it cannot be assigned any more Group Addresses.

For I3C v1.1.1 and earlier:

• See Section 5.1.9.3.19 for the definition of the GETCAP2 byte in the GETCAPS CCC.

For I3C v1.2 and later:

• See Section 5.4 for the definition of the GETCAP2 byte in the GETCAPS CCC.
  
  

Typically, an I3C Device that supports Group Addressing can be assigned to one or more Group Addresses, but has the same Target configuration and state as any other Target (i.e., its role does not change). In effect, this Target gains the ability to receive I3C transfers that are addressed (i.e., targeted) to the Group Addresses to which it might be currently assigned, but the same configuration or state applies to the entire Target, equally for its assigned Dynamic Address as well as any and all assigned Group Addresses.

For some configuration changes, the Controller may use certain Direct CCCs to configure a Target, either individually (i.e., by sending the Direct Write or Direct SET CCC to its Dynamic Address) or in a multicast manner (i.e., by sending the Direct SET CCC to the assigned Group Address). When used as a multicast, the Direct CCC is received by all Targets that are assigned to that Group, and all such Targets apply the same configuration change (if that CCC is supported), exactly as though each Target had received the same Direct CCC addressed to its Dynamic Address. No other internal state is required, and no difference in behavior is expected, when such Direct CCCs are sent to a commonly-assigned Group Address vs. each individual Dynamic Address.

For other configuration changes, specifically for Multi-Lane configuration changes (if the Target supports Multi-Lane transfers and separate Group Address configurations for Multi-Lane transfers), a Direct CCC sent to a Group Address is a special configuration operation, and the Target must store this configuration differently than it would for the equivalent Direct CCC sent to its Dynamic Address. The MLANE CCC is a special case requiring different handling, where the Group Address must be treated specially (i.e., differently than the MLANE CCC sent to a Dynamic Address).

Other Direct CCCs are defined in a different way, and the Target must treat Group Addresses specially. Certain Direct CCCs should never be sent to a Group Address.

Note: Section 5.1.4.4 in v1.1 of the I3C specification has a technical inaccuracy when it states that the SETGRPA CCC “assigns and unassigns a Group Address” to I3C Devices. In fact, the SETGRPA CCC only assigns a Group Address, it does not unassign a Group Address. This misstatement has been corrected in v1.1.1 of the I3C specification. The RSTGRPA CCC can be used to unassign some or all Group Addresses (see Q16.11) and the RSTDAA CCC can be used to unassign the Dynamic Address as well as all Group Addresses (see Q16.2 and Q16.9).

For I3C v1.1.1 and earlier:

• See Section 5.1.9.4 for the defined behaviors of sending Direct CCCs to Group Addresses vs. Dynamic Addresses;
• See Section 5.3.1.1 for ML device configuration; and
• See Section 5.1.2.1.3 for general requirements of Targets that support Group Addresses.

For I3C v1.2 and later:

• See Section 4.3.7.4 for the defined behaviors of sending Direct CCCs to Group Addresses vs. Dynamic Addresses;
• See Section 6.7.3.1 for ML device configuration; and
• See Section 4.3.2.1.3 for general requirements of Targets that support Group Addresses.

A Target’s currently assigned Dynamic Address can only be changed if the Controller sends the SETNEWDA Direct CCC (if supported) or the RSTDAA Broadcast CCC. No other CCCs will change a currently assigned Dynamic Address. This applies regardless of how the Dynamic Address was originally assigned (i.e., either via ENTDAA, SETDASA, or SETAASA).

If the Target also supports the optional SETDASA or SETAASA CCCs, then these only assign the Dynamic Address if it was not already assigned:

1. The Target will only respond to (i.e., will only ACK) and act on the SETDASA CCC sent to its Static Address if the Target did not already have an assigned Dynamic Address at that time. If a Dynamic Address was already assigned, then the SETDASA CCC has no effect.
2. The Target will only act on the SETAASA Broadcast CCC sent to the I3C Bus if it did not already have an assigned Dynamic Address at that time. However, the Target must still provide ACK (as with any Broadcast CCC) but the SETAASA CCC will have no effect.

Additionally, a Target that already has an assigned Dynamic Address will not respond to the ENTDAA CCC, regardless of how the Dynamic Address was originally assigned (see above).

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.4 for general requirements of assigning Dynamic Addresses to Targets; and
• See Section 5.1.9.3.4 for the specific behaviors and requirements of the ENTDAA CCC.

For I3C v1.2 and later:

• See Section 4.3.4 for general requirements of assigning Dynamic Addresses to Targets; and
• See Section 4.3.7.3.4 for the specific behaviors and requirements of the ENTDAA CCC.
  
  

No. When using the SETDASA and/or SETNEWDA CCCs, the Controller must send the CCC data payload containing the new Dynamic Address in Bits[7:1] and a padding value of 1'b0 in Bit[0], followed by valid parity in the T-Bit. If the Controller sends an incorrect padding value of 1'b1 in Bit[0], then this is an incorrect use of the CCC and will be treated as a protocol error (see Q23.6). The same applies if the Controller sends the SETGRPA CCC with an incorrect padding value of 1'b1 in Bit[0]. The Target must not apply the new Address if the framing is incorrect or if the parity in the T-Bit is invalid, even if the Target already provided ACK to the CCC.

Any of the actions listed in Q16.2 that will cause the Target to lose its assigned Dynamic Address will also

cause the Target to lose its assigned Group Addresses.

Additionally, the Controller can send the RSTGRPA CCC, which can be sent as either a Broadcast CCC (i.e., to all Targets) or a Direct CCC (i.e., either to a specific Dynamic Address or to a specific Group Address). However, the RSTGRPA CCC will not cause a Target to lose its assigned Dynamic Address.

Note: The RSTGRPA Direct CCC can be sent either to a Dynamic Address (i.e., to tell a single Target to leave all Groups by clearing all of its assigned Group Addresses), or to a Group Address (i.e., to tell all Targets in that Group to leave the Group by clearing that assigned Group Address). However, there is no way to use the RSTGRPA Direct CCC to tell a single Target to leave a specific Group based on its Group Address.

While the definition of In-Band Interrupts has not changed in I3C v1.1.1, some of the details of the Pending Read Notification contract have been clarified. A Target may only queue one active Pending Read Notification (i.e., a single message that will be read with either an SDR Private Read, or an HDR Generic Read) at a time; and it may now send another IBI if the I3C Controller  has not followed up to read the enqueued data for the Pending Read Notification:

• This IBI may be a reminder, using the same Mandatory Data Byte value that was sent earlier (i.e., it cannot be another MDB value that is also used for Pending Read Notifications).
  
  • If so, then it is forbidden to use it to indicate that additional Pending Read Notifications are waiting (i.e., that they are active and are enqueued after this notification), and the Controller is not obligated to keep count of these IBIs.
• Alternatively, this IBI may also indicate an error code or some other condition (i.e., due to delayed read).
  
  • However, the Target must still keep the data available to read, if it can.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.6.2.2 for the definition of the Pending Read Notification contract between Controllers and Targets.

For I3C v1.2 and later:

• See Section 4.3.6.2.2 for the definition of the Pending Read Notification contract between Controllers and Targets.

I3C Controller Devices that comply with the MIPI I3C Host Controller Interface specification (e.g., I3C HCI v1.2 [MIPI12]) can easily support Pending Read Notifications. MIPI I3C HCI already defines a standard feature known as “Auto-Command” that conforms to the Pending Read Notification contract and enables (in SDR Mode) automatic initiation of Private Reads or (in supported HDR Modes) Generic Reads in hardware, without software intervention, based on matching MDB values in IBIs received from Targets.

Implementers of other I3C Controllers could choose to offer support for Pending Read Notifications as a feature in hardware and/or firmware, with varying degrees of configurability. In situations where hardware or firmware support is not feasible, a Controller and its Host could also support this in software, provided that the Host’s software upholds all the expectations in the Pending Read Notification contract. However, this may require the Controller to pause or cancel any previously enqueued Read transfers for that Target, if it receives such an IBI with matching MDB value to signal a Pending Read Notification, as this would oblige the Controller or its Host to initiate a separate Read transfer (i.e., SDR Private Read or HDR Generic Read) that is expected for this particular IBI. Additionally, the Host would typically expect that the Pending Read Notification IBI would be associated with the subsequent Read transfer, and not some other Read transfer (i.e., due to incorrect association). For this reason, MIPI Alliance recommends that Controllers should support the Pending Read feature in hardware and/or firmware.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.6.2.2 for the definition of the Pending Read Notification contract between Controllers and Targets.

For I3C v1.2 and later:

• See Section 4.3.6.2.2 for the definition of the Pending Read Notification contract between Controllers and Targets.

The I3C Bus protocol supports a mechanism for Targets to join the I3C Bus after the Bus is already configured. This mechanism is called Hot-Join. The I3C specification defines the conditions under which a Target can do this, e.g., a Target must wait for a Bus Idle condition.

Note: If a Target supports the Hot-Join mechanism, then it must also support the ENTDAA CCC.

For I3C v1.1.1 and earlier:

• See Section 5.1.5 for the definition of Hot-Join, including the Hot-Join Request.

For I3C v1.2 and later:

• See Section 4.3.5 for the definition of Hot-Join, including the Hot-Join Request.

Yes. Targets are expected to monitor Broadcast CCCs; the special exception is for Hot-Join Targets, as explained below.

Under most circumstances the Target should process all supported Broadcast CCCs, however the Target is specifically required to process supported Broadcast CCCs that affect Bus state. This includes the ENTHDRn  CCCs (which turn the HDR Exit Pattern detector on), as well as the ENEC and DISEC CCCs for whatever events the Target supports (e.g., IBI).

Note: As a practical matter, the I3C Primary Controller will not generally use any CCCs other than Dynamic Address assignment while bringing up the I3C Bus. However, it is allowed to use Bus state CCCs as  needed.

For a Hot-Join Target (i.e., a Target that needs to emit a Hot-Join Request to receive a Dynamic Address), this rule only applies once the Target is safely on the I3C Bus and eligible to emit a Hot-Join Request. Such a Target might also join the Bus without knowing the current state, so in order to know that a Broadcast CCC is being sent it needs to see a period of inactivity followed by a valid START with the Broadcast Address. I3C v1.1.1 and I3C Basic v1.1.1 clarify these rules for Hot-Join eligibility; see also the In-Band Interrupt and Hot-Join section for the question, "What has changed regarding Hot-Join in I3C v1.1.1?" In such cases, a Target that has not yet seen a START and has also not become eligible to emit the Hot-Join Request might need to wait for a Bus Available Condition before it can see a START; or a Bus Idle Condition before it would be eligible to pull SDA Low to initiate a START to emit its own Hot-Join Request (i.e., using the standard method).

So, as a general rule, the Target will emit the Hot-Join Request before the Controller is able to emit any Broadcast CCCs. However, after that the Target may see one or more Broadcast CCCs prior to being assigned a Dynamic Address.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.3.2 for the Bus Condition timing, including Bus Available Condition and Bus Idle Condition.

For I3C v1.2 and later:

• See Section 4.3.3.2 for the Bus Condition timing, including Bus Available Condition and Bus Idle Condition.

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

In I3C v1.0, a Target was required to wait 1 ms (i.e., the tIDLE minimum value) before it could send a Hot-Join Request. Newer versions of the I3C specification define a new tIDLE minimum value of 200 µs, since  that is sufficient for all valid uses. I3C v1.0 devices may choose to support that smaller delay now. I3C Basic v1.0 and I3C v1.0 already support a tIDLE minimum value of 200 µs.

Note: The new tIDLE minimum value of 200 µs is safe, as SCL at High in HDR Mode cannot exceed 100 µs (i.e., assuming a typical duty cycle) since the minimum I3C Bus frequency is 10 KHz.

Yes, but only if such Targets have a way to turn the Hot-Join feature off, or if a passive Hot-Join is supported. See the question below, "Can an I3C Target support Hot-Join when used on an I3C Bus, and still function correctly on a Legacy I2C Bus?"

Hot-Join Requests are not compatible with Legacy I2C controllers, so Hot-Join would have to be disabled for  the Target to be used on a Legacy I2C bus. The disabling of the Hot-Join feature should be done via some feature that is not part of the I3C protocol (i.e., not via the DISEC CCC), since an I2C controller does not support the I3C protocol.

Yes, but only if it supports a passive Hot-Join method. If the Target does not support passive Hot-Join, then see Q17.6.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.5.3 for the definition of Passive Hot-Join.

For I3C v1.2 and later:

• See Section 4.3.5.3 for the definition of Passive Hot-Join.

Before initiating the Hot-Join Request, a Target that supports passive Hot-Join must first ensure that it is actually on an I3C Bus. This can be done by waiting for a recognizable end of an SDR Frame that ends with a STOP. The key difference is that in order to determine that this is actually an I3C Bus, the Target must first see an SDR Frame addressed to the Broadcast Address (7'h7E / W). Following this, the Target could either pull SDA Low to drive a START condition, or wait to see a START that another I3C Device initiates, before emitting the Hot-Join Request (i.e., arbitrating the special Hot-Join Address 7'h02 into the Arbitrable Address Header following the START).

Note:

• A passive Hot-Joining Target needs to see an SDR Frame that is addressed to the Broadcast Address in order to determine that the Bus is in SDR Mode. Without this knowledge, such a Target might see Bus activity in HDR Modes and misinterpret it as STARTs and STOPs. Alternatively, a passive Hot-Joining Target could wait for the HDR Exit Pattern because it clearly indicates a return to SDR Mode.
• The detection of an SDR Frame that is addressed to the Broadcast Address is critical because a passive Hot-Joining Target might not engage its timer or oscillator (i.e., to check for Bus Idle or Bus Available condition) until it determines that it is on an I3C Bus and that the Bus is in SDR Mode. Without this detection, such a Target will not know whether it is safe to emit the Hot-Join Request.

If the Target determines that it is indeed on an I3C Bus in this manner, then it must observe the standard behaviors of a Target that has not yet received a Dynamic Address. The Target must acknowledge the Broadcast Address (7'h7E), which means that it is required to understand and process all required CCCs, including ENEC and DISEC. If such a Target follows the strict passive Hot-Join requirements that are defined in I3C v1.2 and earlier, then it would not be eligible to respond to the ENTDAA CCC before it has emitted the Hot-Join Request at least once. However, if such a Target follows the relaxed passive Hot-Join requirements, then it would be eligible to respond to the ENTDAA CCC even if it has not yet emitted the Hot-Join Request, since the START / 7'h7E is a clear indication of an I3C Bus. Once the Target sees the ENTDAA CCC and has been assigned a Dynamic Address by the Active Controller, the Target is not required to send the Hot-Join Request. The relaxed passive Hot-Join requirements will be defined in the upcoming Errata for I3C v1.2, and in subsequent versions of the I3C specification.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.2.1 for the defined behaviors of a Target that has not yet received a Dynamic Address.

For I3C v1.2 and later:

• See Section 4.3.2.1 for the defined behaviors of a Target that has not yet received a Dynamic Address.
• If the Target follows the relaxed passive Hot-Join requirements but does not receive a Dynamic Address (i.e., from the ENTDAA, SETDASA, or SETAASA CCCs), then such a Target must still send the Hot-Join Request (i.e., after it determines that it is indeed on an I3C Bus) to inform the Active Controller that it is waiting for a Dynamic Address. 

A Target that supports both standard and passive Hot-Join methods is free to either (A) Initiate a START, wait for the appropriate time (i.e., Bus Idle condition), emit the Hot-Join Request, and then pull SDA Low like a standard Hot-Joining Device; or (B) Wait for a START that another I3C Device emits (i.e., after waiting for Bus Idle condition).

If such a Target (see Q17.7) is present during Bus initialization, then the first START with the Broadcast Address using slower timing (see Q24.1) will cause the Target to turn off its I2C Spike Filter and know that it is indeed on an I3C Bus. Once this happens, the Target will know that it is safe to use a passive Hot-Join method.

However, if such a Target was not present during Bus initialization and arrives later, then it will not see the first START with the Broadcast Address using slower timing. Even if the Controller sends CCCs using typical I3C SDR timing, the new Target’s I2C Spike Filter will still be enabled, and this will prevent the Target from seeing the Broadcast Address and knowing that it is on an I3C Bus. To resolve this situation, it is up to the Controller to send another START with the Broadcast Address using slower timing, which will cause this new Target to turn off its I2C Spike Filter and know that it is indeed on an I3C Bus. If system designers know that there will be some Targets that will join the Bus at a later time (i.e., after Bus initialization), then they should configure the Controller to do this periodically (i.e., send a START with the Broadcast Address using slower timing) after Bus initialization as a proactive measure. This will ensure that a late-arriving Target will eventually know when it is safe to use a passive Hot-Join method.

Yes, the reserved Hot-Join Address (7'h02) is safe to use even if multiple Targets all simultaneously attempt to emit a Hot-Join Request. If multiple Targets do join the I3C Bus and all become eligible to emit the Hot- Join Request at the same time, then they would be expected (and allowed) to all emit the Hot-Join Request at the same time. Since a Hot-Join Request is a special form of the In-Band Interrupt Request with no data payload (i.e., no Mandatory Data Byte), multiple Targets may all emit this request at the same time, provided that they are all eligible to do so.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.5 for the definition of Hot-Join, including the Hot-Join Request.

For I3C v1.2 and later:

• See Section 4.3.5 for the definition of Hot-Join, including the Hot-Join Request.

Example: As one Target pulls SDA Low to initiate the START Request and drive the 7'h02 Hot-Join Address into the Arbitrable Address Header, and the other eligible Targets see this activity while they are eligible, they would also emit the same Hot-Join Address and behave accordingly. This could be useful if one  such Target supported the standard Hot-Join method and waited for the Bus Available condition, while another Target only supported a passive Hot-Join method but was waiting for another I3C Device to initiate a START Request.

Upon receiving the Hot-Join Request and responding with ACK, the Controller sends the ENTDAA CCC to signal its intent to start the Dynamic Address Assignment procedure and  assign Dynamic Addresses to all Targets that have not yet received one. Since the Dynamic Address Assignment procedure inherently supports detection of multiple Targets and uses Arbitration to select one Target at a time (i.e., for each iteration of assignment), the Controller should continue the Dynamic Address Assignment procedure so it can catch all eligible Targets that emitted the Hot-Join Request  together (as well as any that might have previously emitted the Hot-Join Request).

Note: All Targets do still need to have a unique Provisioned ID; see Q16.3 for more information.

For I3C v1.1.1 and earlier

• See Section 5.1.4.2 for the definition of the Dynamic Address Assignment procedure.

For I3C v1.2 and later:

• See Section 4.3.4.2 for the definition of the Dynamic Address Assignment Procedure.

See Q17.11 for more information about Hot-Join Requests and the specification clarifications that are new for I3C v1.1.1.

After the NACK is preferred, but after the ACK is also acceptable.

The Hot-Join mechanism allows the Controller to first NACK, and then send the DISEC CCC with the DISHJ  bit set to disable subsequent Hot-Join Requests. If the Controller ACKs the Hot-Join Request, then that is interpreted as a promise that the Controller will eventually send the ENTDAA CCC to assign a Dynamic Address to the Target(s) that emitted the Hot-Join Request.

If the Controller were to send a subsequent DISEC CCC with the DISHJ bit set, then that would cancel this promise, but it would also leave the Target(s) with no Dynamic Address.

Note: If any additional Targets joined the Bus after the DISEC CCC was sent, then they would not have seen the DISEC CCC, and as a result would likely send their own Hot-Join Requests.

See the question below, "What has changed regarding Hot-Join in I3C v1.1.1?" for additional clarifications and updates in I3C v1.1.1 and I3C Basic v1.1.1.

In the I3C v1.0, I3C Basic v1.0, and I3C v1.1 specifications, the requirements for Hot-Join were not clearly defined and the Annex C Hot-Join FSM diagram did not illustrate all of the possible intended flows.

The I3C WG received implementer feedback on these points, and in I3C v1.1.1 clarified the normative requirements for a Hot-Joining Device. The WG also added a new definition of the Hot-Join procedure which  is now defined separately from the Target requirements. In addition, the Annex C Hot-Join FSM diagram now informatively illustrates a typical flow, rather than being presented as a representation of all possible Hot-Join Request flows.

To summarize the Hot-Join changes:

• A Hot-Joining Device that has not yet raised the Hot-Join Request (i.e., an In-Band Interrupt to the Reserved I3C Address of 7'h02 with Write) does not follow the standard behaviors of a Target that has not yet received a Dynamic Address with the following exceptions:
  
  • If the Target supports a Passive Hot-Join method and will be using that method instead of the standard Hot-Join Request (which usually requires the I3C Bus to go idle long enough to satisfy the Bus Idle Condition), then it must verify that the bus it is on is on an I3C Bus by watching for an SDR Frame. Q17.7 provides more clarity on the requirements for Targets that support passive Hot-Join.
• The Controller may choose to either ACK or NACK the Hot-Join Request, and may then send the ENTDAA CCC afterwards:
  
  • This may happen either immediately (i.e., after the next Repeated START), or later (i.e., after a prolonged period). The ENTDAA CCC might not be in the same SDR Frame, since the Controller may choose to send this after a STOP, followed by a delay (i.e., Bus Free Condition or longer) and then a START. Optionally, the Controller may initiate other transfers and/or CCCs between the ACK/NACK and the ENTDAA CCC.
  • In short, any valid actions are allowed between the ACK/NACK and ENTDAA CCC, and the Target should still respond to the ENTDAA CCC appropriately. If the Target knows that it needs a Dynamic Address and it has already raised the Hot-Join Request, then it should be ready to respond to the ENTDAA CCC when the Controller starts the Dynamic Address Assignment procedure.
  • If the Controller provided an ACK to the Hot-Join Request, then any Targets that raised the Hot-Join Request must remember that an ACK was provided, cease raising Hot-Join Requests, and remain ready to participate in a subsequent ENTDAA CCC (which the Controller should send at a later time). The Target should not send a subsequent Hot-Join Request if the Controller is slow to start the ENTDAA procedure.
  • Although providing an ACK for a Hot-Join Request is a typical flow, providing a NACK is also acceptable. The Target should remain ready to respond to the ENTDAA CCC in either case, even if the Target receives a NACK or is told by the Controller to stop sending Hot-Join Requests (i.e., using the DISEC CCC with the DISHJ bit set).
  • Note that the Controller may choose to send the DISEC CCC with the DISHJ bit set, after either providing an ACK or a NACK to a Hot-Join Request (see the question above).
• Any Targets that have already raised a Hot-Join Request are required to also respond to other required CCCs the standard behaviors for a Target that has not yet received a Dynamic Address:
  
  • Such Targets must acknowledge the Broadcast Address (7’h7E). This means they are required to understand and process all required CCCs, including ENEC and DISEC. (Targets that support passive Hot-Join methods are already required to do this, once they successfully determine that they are indeed on an I3C Bus; see Q17.7).
  • After either providing ACK or NACK in response to the Hot-Join Request, the Controller may send (and such Targets are required to properly receive) the DISEC CCC with the DISHJ bit set. The Controller doing so is required to prevent any Targets that raised a Hot-Join Request and received a NACK from subsequently attempting to raise a Hot-Join Request.
  • Subsequently, the Controller may send (and such Targets are required to properly receive) the ENEC CCC with the ENHJ bit set, to effectively re-enable Hot-Join Requests on the I3C Bus. Any eligible Targets that receive this ENEC CCC and that previously received the DISEC CCC with the DISHJ bit set may choose to re-send the Hot-Join Request if these Targets both (1) are capable of doing so, and (2) had originally emitted a Hot-Join Request, and (3) have not yet received a Dynamic Address.
  • If the Active Controller is a Secondary Controller Device that is not capable of processing Hot-Join or Dynamic Address Assignment, or one that wishes to defer processing to a more capable Controller (i.e., to the Primary Controller), then it may choose to disable Hot-Join on the I3C Bus by sending the DISEC CCC with the DISHJ bit set. It may then pass the Controller Role to any other Controller-capable Device, including but not limited to the Primary Controller.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.5.3 for the definition of Passive Hot-Join; and
• See Section 5.1.2.1 for the defined behaviors of a Target that has not yet received a Dynamic Address.

For I3C v1.2 and later:

• See Section 4.3.5.3 for the definition of Passive Hot-Join; and
• See Section 4.3.2.1 for the defined behaviors of a Target that has not yet received a Dynamic Address.
  
  

The I3C Specification does not place restrictions on what types of IBIs can be sent by a Target, or for what purpose. Implementers may choose to define their own IBI notifications for various events or causes that are generated within the Target. If the Bus Configuration Register (BCR) Bit 2 has a value of 1'b1, then the Target uses the Mandatory Data Byte (MDB) and optional additional bytes to describe the specific cause or generating event that induced the interrupt.

Note: The requirements above, and those in the I3C Specification, apply generally to all Targets. However, Targets might also comply with another MIPI specification that defines a particular I3C content protocol, and that content protocol might have additional specific requirements relating to IBIs. For example, the MIPI Specification for Debug Over I3C [MIPI15] defines requirements for certain types of IBIs that can be sent, along with specific MDB values defined for the debug use cases.

If IBI Requests are enabled (see Q18.20), then the Target raises an IBI Request by arbitrating its Dynamic Address into the next arbitrated Address Header after a START. The Target may also pull SDA to Low to drive a START condition when it is appropriate to do so, i.e., after seeing the Bus Available Condition (which is defined as the Bus Free Condition sustained for at least tAVAL, or 1 μs). However, Targets are not required to raise new IBI Requests at the maximum possible rate.

Note: By default, IBI Requests are enabled if a Target has an assigned Dynamic Address.

• For I3C v1.1.1 and earlier: See Section 5.1.6.2 for the definition of the IBI Request.
• For I3C v1.2 and later: See Section 4.3.6.2 for the definition of the IBI Request.

When the Controller acknowledges each IBI Request, the Controller reads the data bytes of the IBI payload, then uses the MDB and optional additional data bytes to determine the nature of the interrupt from the Target. If the MDB indicates that the interrupt is a Pending Read Notification (see Q17.2), then the Controller is obligated to initiate a Private Read transfer to that Target after receiving that interrupt, in order to read the associated data payload.

Targets may optionally have an internal queue of pending interrupts, and raise IBI Requests for these enqueued interrupts in any implementation-defined order. Typically this is determined by either the specific interrupt cause priority level, or by the order in which interrupts were enqueued (see Q18.21).

In order to manage contention on I3C Buses with multiple Targets, implementers may choose to support an IBI-rate-limiting mechanism within the Target, which limits how frequently IBI Requests will be attempted. Implementers may also choose to support a Target-driven credit counting mechanism, where the Controller periodically sends credits to each Target (e.g., using a custom CCC or Vendor / Standard Extension CCC) and the Target internally determines whether it can attempt an IBI Request, based on the number of remaining credits or other factors. These can also be combined with Controller-driven mechanisms (see Q17.13).

If an I3C Bus has multiple Targets, then the Target with the lowest Dynamic Address will naturally get highest priority during an IBI Request, as the lowest Dynamic Address will win arbitration in the Address Header. However, in many circumstances this could starve other Targets of the opportunity to send IBI Requests. The Controller can mitigate this situation to an extent, by using the DISEC Direct CCC to temporarily pause IBI Requests from a specific Target, thereby giving other Targets the opportunity to win arbitration. However, the Controller should eventually tell such paused Targets to resume IBI Requests (i.e., by using the ENEC Direct CCC) when it is appropriate to do so.

I3C Controller Devices that comply with the MIPI I3C Host Controller interface specification (i.e., I3C HCI v1.2 [MIPI12]) can also use an optional Controller-driven IBI credit counting mechanism to send the ENEC/DISEC Direct CCCs automatically, based on the number of credits remaining for each Target (see the I3C HCI specification at Section 6.9.5).

The Controller may also re-balance the priority by changing the assigned Dynamic Address of some (or all) Targets, using the SETNEWDA CCC (see Q16.9).

Yes. Targets that support IBIs with a data payload (as indicated by BCR Bit[2] having a value of 1'b1) will have the following behaviors:

• Send at least one data byte (i.e., the Mandatory Data Byte) that describes the meaning or purpose of the IBI;
• Optionally send additional data bytes after the Mandatory Data Byte, to provide additional information about this IBI;
• Use the T-Bit to correctly indicate whether the IBI data payload has additional data bytes or not;
• After each data byte, if the T-Bit was initially set to 1, monitor SDA to determine whether the Controller is pulling SDA to 1'b0 to terminate the IBI data payload (which may happen before the last intended data byte), in the same manner as an I3C Private Read transfer;
• Limit the number of IBI data payload bytes to the maximum IBI payload size (i.e., either a supported maximum size configured by the SETMRL CCC; or the default maximum size, if a configuration has not been set) and end the IBI data payload after either the maximum size or the last intended data byte, whichever comes first; and
• End the IBI data payload after the last data byte, using the T-Bit mechanism (i.e., drive SDA to 1'b0 to indicate the end of the IBI), in the same manner as ending an I3C Private Read transfer.

Targets are not required to (and should typically not) send padding bytes after the last data byte. If the intended IBI data payload size is shorter than the configured maximum IBI payload size, then the Target should drive the T-Bit to 1'b0 after the last data byte to indicate the end of the IBI payload.

Note: These requirements were already defined in previous versions of the I3C Specification, but have been clarified in version 1.2 of the I3C Specification.

In general, Targets are expected to observe the value sent with the SETMRL CCC. Since the SETMRL CCC configures the maximum read length for Private Read transfers and IBI data payloads, using different byte fields. Specifically, the first 2 bytes configure the maximum length of Private Read transfers, and the optional third byte configures the maximum length of IBI payloads.

However, under certain circumstances, the value sent with the SETMRL CCC (i.e., in the third byte) might be smaller than the actual minimum IBI data payload size, especially if the Target has also been configured to use a supported Timing Control mode. Recall that when a Timing Control mode is enabled, the Target will send the Timing Control event data before it sends any other (optional) IBI data payload bytes. This Timing Control event data could be up to 4 bytes in length, depending on the specific Timing Control mode. If the Controller also sends the SETMRL CCC to limit the maximum IBI data payload length to 2 bytes, then this will obviously be an invalid configuration, since it would mean that the Target must truncate the Timing Control event data with every IBI.

While Targets are expected to use the configuration provided with the SETMRL CCC, Controllers are also expected to not configure Targets to truncate the Timing Control event data, as described above. This is a situation that could be avoided if the Controller understood that Timing Control was enabled, and sent the SETMRL CCC with valid values only. See Q18.18 for additional context.

Generally, a Target that does not have the ability to use the T-Bit to signal the end of the IBI data payload (i.e., to pull SDA to Low after the last intended data byte) is not fully compliant with the I3C Specification (see Q17.14). Such Targets should only be used with Controllers that can work around this limitation, i.e., by terminating IBI data payload transfers when a certain maximum size is reached. Implementers of such Targets should clearly explain this limitation in appropriate documentation (e.g., a product datasheet or user guide) to ensure that system designers understand this limitation and can configure the Controller to automatically terminate IBI data payload transfers at the appropriate time.

Note: Implementers should avoid designing I3C Devices with such limitations. Using the T-Bit to signal the end of an IBI data payload is fundamentally the same as using the T-Bit to signal the end of a Private Read data payload, meaning that there should be no technical hindrances to following the I3C specification requirements for ending transfers after the last intended data byte.

The consequence of using a Target that cannot use the T-Bit to signal the end of the IBI data payload is that Controllers will not be able to know when the intended last data byte is sent. If the Controller does not handle this situation specially (as listed above), then this is likely to cause a runaway read which will block subsequent I3C transfers. Specifically, if the Target releases SDA after the last data byte and does not drive a T-Bit of 1'b0, then the Bus High-Keeper will eventually pull SDA to High, and this will likely be interpreted as a T-Bit of 1'b1; therefore, the Controller will believe that the Target has more data bytes to send. After this, since the Controller is not aware of this limitation in the Target, it will continue trying to read invalid data (i.e., repeated data bytes of 0xFF, since SDA is High) and the Host will not be able to distinguish the actual end of meaningful data in the IBI data payload (i.e., to determine whether repeated data bytes of 0xFF are valid).

This could continue until either (A) the Controller runs out of space in its IBI queue/FIFO for IBI data payload bytes and encounters an error; or (B) the Host determines that the Controller is not responding to new requests to send I3C transfers, and must use a recovery procedure to forcibly end the transfer and return to normal I3C transactions. This usually requires resetting the Controller and then determining the state of the Bus with a recovery procedure.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.1.10.2.7 for the Controller recovery procedure.

For I3C v1.2 and later:

• See Section 4.3.8.2.7 for the Controller recovery procedure.

It should be obvious to implementers and system designers that these situations should be avoided whenever possible.

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

The CRC Word is sent in 6 full clock cycles, which includes the Preamble bits and the token for the CRC Word (i.e., 4'hC). The CRC transmission ends at bit 6 (counting down from bit 15), but SDA is allowed to be High-Z at bit 5 (i.e., at the falling edge of the 6th clock cycle). After this, the Controller drives either the HDR Restart Pattern or the HDR Exit Pattern.

Note: If early transfer termination is supported and enabled, then the sender will either send or not send the CRC Word after a terminated transfer, as per prior configuration with the ENDXFER CCC (see Q18.16, Q19.4, Q19.5, and Q19.7). Special rules apply for HDR-DDR-ML transfers (see Q19.8).

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

Per Q21.3 and Q21.4, the Controller manages its Pull-Ups to allow for ACK/NACK as well as Bus Turnaround. The Controller sends the HDR-DDR Command Word with SDA in Active drive (i.e., Push-Pull mode) for the Command Word until the last Parity bit (i.e., PA0), which is initially driven High. Before the falling edge of C10 cycle, the Controller prepares for the Target to respond by disabling Push-Pull mode and engaging an appropriate Pull-Up to keep SDA at High. After the rising edge of the next C1 cycle (i.e., after the PRE1 bit in the Preamble), the addressed and properly configured Target can either:

• Accept the DDR Write or Read command by pulling SDA to Low, or
• Ignore the DDR Write or Read command by leaving SDA at High

Note: This scheme is similar to SDR Mode’s ACK/NACK scheme for the Address Header, where SDA is “Parked” at High and the Target can pull SDA to Low to acknowledge the transaction. A Target is not allowed to use this mechanism to ignore (i.e., to NACK) a Write command unless the Controller had previously used the ENDXFER CCC to enable ACK/NACK; see Q19.3. By contrast, a Target is always allowed to ignore (i.e., to NACK) a Read command (i.e., no configuration is needed).

The Controller should use the appropriate Pull-Up to enable Bus Turnaround or acceptance by the Target. For most use cases, the Open Drain class Pull-Up is recommended; however, the High-Keeper could also be used, based on system design factors. In either case, the Target must be able to pull SDA to Low before the falling edge of the C1 cycle.

Note:

• For I3C v1.1.1 and earlier: See Section 5.1.3.1 for the Bus High-Keeper requirements.
• For I3C v1.2 and later: See Section 4.3.3.1 for the Bus High-Keeper requirements.

Note that the next C1 cycle is the start of the first HDR-DDR Data Word (if the Target accepts the transfer) and the PRE1 bit (i.e., the rising edge of the C1 cycle) is always 1'b1. Using this scheme, the Target’s response determines the Preamble bits:

• Bits 2'b10 indicate a Target ACK (i.e., accepting the DDR Write or Read) which starts the first HDR-DDR Data Word; or
• Bits 2'b11 indicate a Target NACK (i.e., ignoring the DDR Write or Read). The Controller then drives the HDR Restart Pattern or HDR Exit Pattern.

Note: If the Controller is compliant with v1.0 of the I3C Specification, then it will not support the Write NACK behavior and will typically drive both Preamble bits after a Write command, which does not provide any opportunity for the Target to NACK.

• For I3C v1.1.1 and earlier: See Section 5.2.2 for the HDR-DDR preamble bit definitions.
• For I3C v1.2 and later: See Section 6.2.3.1 for the HDR-DDR preamble bit definitions.

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

In I3C v1.0, HDR-DDR Mode did not define a flow control mechanism for a Target to actively deny (i.e., to NACK) a DDR Write Command. This meant that Targets had to accept a DDR Write Command that they did not support (i.e., if the provided value of the HDR Command Byte was not supported), and the Controller would send the Data Words regardless. In such a situation, the Controller would proceed with the DDR Write and the Target would drop all the Data Words (i.e., would take no action).

Starting with I3C v1.1, HDR-DDR Mode allows the Controller to configure a Target to either accept the DDR Write Command and drop the data (as before), or else use an ACK/NACK mechanism similar to SDR Mode (see Q19.2). If the Target is configured to enable the ACK/NACK mechanism, then the Controller detects when the Target ignores the Write Command and simply starts driving either the HDR Restart Pattern or the HDR Exit Pattern.

All Targets that comply with I3C v1.1 or later are required to support this ACK/NACK mechanism, as well as the method of configuration from the Controller. This ACK/NACK mechanism is disabled by default. Configuration is accomplished by using the ENDXFER CCC. See also Q18.16.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.2.2.3.1 for the definition of the HDR-DDR Write Ignore procedure;
• See Section 5.1.9.3.25 for the definition of the ENDXFER CCC; and
• See the flow control figure HDR-DDR Preamble Bits State Diagram in Section 5.2.2 for Target NACK behaviors.

For I3C v1.2 and later:

• See Section 6.2.3.4.1 for the definition of the HDR-DDR Write Ignore procedure;
• See Section 4.3.7.3.22 for the definition of the ENDXFER CCC; and
• See the flow control figure HDR-DDR Preamble Bits State Diagram in Section 6.2.3 for Target NACK behaviors.

The flow control diagram shows how the suitably configured Target can provide NACK for a DDR Write Command, by providing a 1'b1 during the second preamble bit (i.e., before the first Data Word). In effect, Preamble value 2'b11 means that the Target has provided a NACK to the Controller; if the Controller sees this, then it must drive either the HDR Restart Pattern or the HDR Exit Pattern. By contrast, Preamble value 2'b10 means that the Target has pulled SDA Low and accepted the DDR Write Command (i.e., has provided ACK). The ACK and NACK procedures are defined as part of the HDR-DDR flow control elements. The Controller must also ensure that the Target’s response is received: this typically requires the Controller to use a suitable delay in order to achieve proper set-up timing on the SDA line.

Note:

If the Controller does not configure the Target to use the ACK/NACK capability for DDR Write Commands, then (A) the Target drops the Data Words for any DDR Write Commands that it does not support; and (B) the Controller always drives Preamble value 2’b10 for the first Data Word, since it knows that the Target will accept any DDR Write Commands that it does not support, even if the Target drops the data.

If the Controller is compliant with v1.0 of the I3C Specification, then the Controller will not know about the flow control mechanism, even if some (or all) Targets are compliant with v1.1+ of the I3C Specification and would therefore support the flow control mechanism. In this case, the default Target behavior is compatible with a v1.0-compliant Controller, i.e., the Target would ignore the Data Words for any DDR Write Commands that it does not support, and the Controller would not see a situation where the preamble bits were 2'b11 (i.e., a Target NACK which it would likely not understand).

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

In I3C v1.0, HDR-DDR Mode defined a transfer termination procedure that the Controller can use to end an HDR-DDR read transfer before the Target has finished sending all intended Data Words. The Controller is allowed to terminate the read transfer without any prior configuration of the Target. If the Controller terminated the read transfer, then the Target would not send the CRC Word, and the Controller would then hold SCL at Low so it could start driving either the HDR Restart Pattern or the HDR Exit Pattern.

Starting with I3C v1.1, HDR-DDR Mode allows the Target to conditionally send the CRC Word after the Controller terminates the read transfer. Targets that comply with I3C v1.1 or later may choose to support this capability, as well as the method of configuration from the Controller. If supported, then sending the CRC Word is disabled by default. Targets that support sending the CRC Word will also use Bit[7] of the GETCAP2 byte (returned by the GETCAPS Format 1 CCC) to indicate this support. Configuration is accomplished by using the ENDXFER CCC. See also Q18.16.

Note:

For I3C v1.1.1 and earlier:

• See Section 5.2.2.3.5 for the definition of the HDR-DDR read transfer termination procedure;
• See Section 5.1.9.3.25 for the definition of the ENDXFER CCC; and
• See the flow control figure HDR-DDR Preamble Bits State Diagram in Section 5.2.2.

For I3C v1.2 and later:

• See Section 6.2.3.4.5 for the definition of the HDR-DDR read transfer termination procedure;
• See Section 4.3.7.3.22 for the definition of the ENDXFER CCC; and
• See the flow control figure HDR-DDR Preamble Bits State Diagram in Section 6.2.3.2.

The flow control diagram shows how the Controller can terminate a DDR read transfer, by providing a 1'b0 during the second Preamble bit (i.e., at the start of the next intended Data Word). In effect, Preamble value 2'b10 means that the Controller has told the Target to stop sending Data Words and terminate the read transfer; if the Target sees this, then it will respond accordingly based on prior configuration with the ENDXFER CCC:

• If the Target was not configured to send the CRC Word after read transfer termination (which is the default state), then the Target will simply wait for the Controller to start driving either the HDR Restart Pattern or the HDR Exit Pattern.
• If the Target was configured to send the CRC Word after read transfer termination, then the Target will wait for the Controller to drive 4'hC (i.e., the token for the CRC Word) in the next 2 SCL cycles, and then the Target will take control of SDA for subsequent SCL cycles to drive the 5-bit CRC-5 checksum of the data bytes that were sent. The CRC Word will effectively start with Preamble value 2'b10, which is not the same as a typical CRC Word that starts with Preamble value 2'b01. After this, the Controller will hold SCL at Low and then take control of SDA to start driving either the HDR Restart Pattern or the HDR Exit Pattern.

Note:

If the Controller does not configure the Target to send the CRC Word for terminated DDR read transfers, then (A) the Target will not try to drive the CRC Word after it sees a terminated transfer; and (B) the Controller will always drive either the HDR Restart Pattern or the HDR Exit Pattern after it terminates the transfer, since it knows that the Target will not try to send the CRC Word.

If the Controller is compliant with v1.0 of the I3C Specification, then the Controller will never drive 4'hC to start the CRC Word after it terminates a DDR Read transfer, even if some newer Targets might support this behavior. In this case, the default Target behavior is compatible with a v1.0- compliant Controller, i.e., the Target will not try to send the CRC Word when it sees a terminated read transfer, since the v1.0-compliant Controller would not have configured it to do so.

In I3C v1.0, HDR-DDR Mode did not define a write transfer termination procedure, i.e., there is no way for a v1.0-compliant Target to end an HDR-DDR write transfer before the Controller has finished sending all intended Data Words.

Starting with I3C v1.1, HDR-DDR Mode also allows the Target to terminate a write transfer, and the Controller can conditionally send the CRC Word after the last Data Word, as long as the Controller configures this in advance. Targets that comply with I3C v1.1 or later may choose to support this capability, as well as the method of configuration from the Controller. If supported, then write transfer termination is disabled by default. Targets that support write transfer termination will also use Bit[6] of the GETCAP2 byte (returned by the GETCAPS Format 1 CCC) to indicate this support. Configuration is accomplished by using the ENDXFER CCC. See also Q18.16 and Q19.6.

Note:

If the Target does support HDR-DDR write transfer termination, then it should also support receiving the CRC Word after a terminated write transfer. These capabilities can be enabled independently, but should generally both be enabled together if write transfer termination is enabled.

For I3C v1.1.1 and earlier:

• See Section 5.2.2.3.6 for the definition of the HDR-DDR write transfer termination procedure;
• See Section 5.1.9.3.25 for the definition of the ENDXFER CCC; and
• See the flow control figure HDR-DDR Preamble Bits State Diagram in Section 5.2.2.

For I3C v1.2 and later:

• See Section 6.2.3.4.6 for the definition of the HDR-DDR write transfer termination procedure;
• See Section 4.3.7.3.22 for the definition of the ENDXFER CCC; and
• See the flow control figure HDR-DDR Preamble Bits State Diagram in Section 6.2.3.2.

The flow control diagram shows how the Target can terminate an HDR-DDR write transfer, by providing a 1'b0 during the second Preamble bit (i.e., at the start of the next intended Data Word). In effect, Preamble value 2'b10 means that the Target has told the Controller to stop sending Data Words and terminate the write transfer; if the Controller sees this, then it will respond accordingly based on prior configuration with the ENDXFER CCC:

• If the Target was not configured to expect the CRC Word after write transfer termination (which is the default state), then the Target will simply wait for the Controller to start driving either the HDR Restart Pattern or the HDR Exit Pattern.
• If the Target was configured to expect the CRC Word after write transfer termination, then the Controller will drive the CRC Word, including the 5-bit CRC-5 checksum of the data bytes that were sent. The CRC Word will effectively start with Preamble value 2'b10, which is not the same as a typical CRC Word that starts with Preamble value 2'b01. After this, the Controller will hold SCL at Low and then start driving either the HDR Restart Pattern or the HDR Exit Pattern.

Note:

If the Controller does not configure the Target to expect the CRC Word for terminated DDR write transfers, then (A) the Controller will not try to drive the CRC Word after it sees a terminated transfer; and (B) the Controller will always drive either the HDR Restart Pattern or the HDR Exit Pattern after it terminates the transfer.

If the Controller is compliant with v1.0 of the I3C Specification, then the Controller will not support write transfer termination, therefore it will also not be able to send the CRC Word after it sees write transfer termination, even if some Targets might support this behavior. In this case, the default Controller behavior is compatible with a v1.0-compliant Target, as well as a v1.1+-compliant Target that was not configured to expect the CRC Word after write transfer termination.

Yes. The capability and configuration for enabling HDR-DDR write abort (i.e., early transfer termination; see Q19.5) is independent from the capability and configuration of sending the CRC Word after early transfer termination. However, enabling the CRC Word on transfer termination is a configuration that applies to both HDR-DDR write transfers (i.e., the Target should expect the Controller to send the CRC Word after the Target terminates a write transfer) and HDR-DDR read transfers (i.e., the Target must send the CRC Word after the Controller terminates a read transfer).

In this case, the Controller should see that the Target provides a value of 1'b0 in Bit[7] of the GETCAP2 byte (returned by the GETCAPS Format 1 CCC), and therefore the Controller should not try to use the ENDXFER CCC to configure that Target to enable sending the CRC Word (i.e., for any terminated HDR-DDR read transfers). Since this configuration will also apply to terminated HDR-DDR write transfers, the Controller should not send the CRC Word after early termination of the HDR-DDR write transfer.

If the Controller did configure such a Target to enable HDR-DDR write transfer termination, and subsequently did send the CRC Word after this Target terminated the write transfer early (i.e., when the Target was not configured to expect this), then this is incorrect behavior by the Controller. The Target should simply ignore the CRC Word and wait for either the HDR Restart Pattern or the HDR Exit Pattern. For most situations, MIPI Alliance recommends that Targets that support HDR-DDR write abort should also support sending the CRC Word after early transfer termination.

Yes, as long as the Target provides 1'b1 in Bit[7] of the GETCAP2 byte (returned by the GETCAPS Format 1 CCC); this indicates that the Target can send the CRC Word if an HDR read transfer is terminated. In this case, the ENDXFER configuration to send the CRC Word after early transfer termination (i.e., Bits[7:6] set to 2'b01) will only apply to situations where the Controller terminates the HDR-DDR read transfer.

Since such a Target cannot terminate the HDR-DDR write transfer, the ENDXFER configuration (i.e., Bits[7:6]) will not be relevant for HDR-DDR write transfers. Additionally, since the HDR-DDR write transfer will never be terminated early by this Target, the Controller will send the CRC Word after the last Data Word, and the Target will use the CRC-5 checksum to verify the received data.

Note: This question does not apply to I3C Basic.

If the Target supports HDR-DDR-ML and is configured to use Multi-Lane transfers in HDR-DDR Mode, then the same early transfer termination configuration (i.e., with the ENDXFER CCC; see Q18.16) will also apply for Multi-Lane transfers in HDR-DDR Mode. If early transfer termination is allowed, then the receiver can terminate the transfer at the start of any Data Block where the first Preamble bit (PRE1) on SDA[0] is 1'b1, in the same manner as Single-Lane transfers:

• For HDR-DDR-ML read transfers: Early transfer termination is always allowed (see Q19.4).
  • For Coding 1: The Controller may terminate the read transfer during the Preamble of any Data Block, including the Padded Last Data Block.
  • For Coding 2: The Controller may terminate the read transfer during the Preamble of any Data Block, including the Truncated Last Data Block.
    • Termination is always possible because the Controller will not know in advance whether the next Data Block from the Target is a Complete Data Block or a Truncated Data Block.
• For HDR-DDR-ML write transfers: Early transfer termination is only allowed if the Target supports HDR-DDR write transfer termination, and if this capability this was previously enabled with the ENDXFER CCC (see Q19.5). If so, then:
  • For Coding 1: The Target may terminate the write transfer during the Preamble of any Data Block, including the Padded Last Data Block.
  • For Coding 2: The Target may terminate the write transfer during the Preamble of any Data Block that is not the Truncated Last Data Block.
    • If the final Data Block for this write transfer is a Truncated Last Data Block, then the Controller will drive the PRE1 bit to 1'b0. When the Target sees this, it knows that termination is not possible and also not necessary, since the write transfer would already end with the Truncated Last Data Block, which contains the last Data Word(s) as well as the CRC-5 checksum.

After the HDR-DDR-ML transfer is terminated early, the sender will conditionally send the CRC Word using the appropriate format for the current Multi-Lane Mode and Data Transfer Coding, if it was previously configured to do so (i.e., with the ENDXFER CCC). However, if the HDR-DDR-ML transfer was not terminated early, then the sender will conditionally send the CRC-5 checksum per the current Data Transfer Coding:

• For Coding 1: The CRC Word is always sent.
• For Coding 2: If the final Data Block was a Complete Data Block, then the CRC Word is always sent. However, if the final Data Block was a Truncated Last Data Block, then CRC Word is never sent, since the CRC-5 checksum was already included in the Truncated Last Data Block.

Note: Special exceptions apply to CCC transactions in HDR-DDR-ML when using Coding 2.

• • For I3C v1.1.1 and earlier, see Section 5.3.2.2.1.
  • For I3C v1.2 and later, see Section 6.7.3.5.1.1.
    
    

Yes, the data bytes are required. The I3C Specification does not always state this clearly in all sections that describe the use of various Defining Bytes that are used as sub-commands for the ENDXFER CCC. However, the data bytes are required for both the Broadcast form and the Direct form of the ENDXFER CCC.

For example, when configuring flow control for Targets that support HDR-DDR Mode:

• If the Controller wishes to send the ENDXFER CCC with Defining Byte 0xAA (i.e., the subcommand to apply the new flow control configuration), then it may use either a Broadcast CCC or a Direct CCC to send this sub-command.
  • If this is sent as a Broadcast CCC, then the Controller includes a data byte with the value of 0xAA, which will be received and processed by all Targets that support the ENDXFER CCC.
  • If this is sent as a Direct CCC, then the Controller includes a data byte with the value of 0xAA, which will be received by the addressed Target (if it accepts the ENDXFER CCC).
• In either case, the affected Target(s) will check this data byte value to confirm that the subcommand was sent correctly, before applying the new configuration for HDR-DDR Mode (which would have been sent previously using the ENDXFER CCC with Defining Byte 0xF7). If the data byte is not present in the CCC payload, or if the value is incorrect, then the affected Target(s) should not apply the new configuration.

Note: The Controller should always use the Direct GET form of the ENDXFER CCC to verify that the configuration has been received and applied correctly by each Target, even if the Controller used the Broadcast form of the ENDXFER CCC to send or apply the configuration. However, Targets that are compliant with v1.0 of the I3C Specification will not understand the ENDXFER CCC, and the Controller should never assume that such Targets will apply any configuration changes as the result of seeing the Broadcast form of the ENDXFER CCC.

For I3C v1.1.1 and earlier: See Table 51 in Section 5.1.9.3.25 for the data byte definitions.

For I3C v1.2 and later: See Table 36 in Section 4.3.7.3.22 for the data byte definitions.

Note: This question does not apply to I3C Basic.

With the release of I3C v1.2 this question has been deprecated; it is retained here for reference.

In I3C v1.1 and earlier, the flow for transitioning from ENTHDRx CCCs into HDR Modes was not fully defined. Starting with I3C v1.1.1, the Specification fully defines the flow for transitioning from such CCCs into the first transfer in an HDR Mode, as well as the corresponding flow transitions from the HDR Restart Pattern to the next HDR transfer in the same HDR Mode.

Note:

• For I3C v1.1.1 and earlier: See Section 5.2.1.3 for the transition into HDR Mode transfers.
• For I3C v1.2 and later: See Section 6.1.3 for the transition into HDR Mode transfers.

Note: This question does not apply to I3C Basic.

With the release of I3C v1.2 this question has been deprecated; it is retained here for reference.

In addition to the changes regarding ENDXFER and HDR-Ternary Flow Control (see Q18.17), I3C v1.1.1 now includes:

• Clarifications on the use of Group Addresses for Direct CCC Read/Write segments in HDRTernary Modes.
• Configuration advisories regarding use of common HDR-Ternary Flow Control with CCCs, especially when sending Direct CCCs to Group Addresses.
• Clarification to the Option 2 End of CCC Procedure, which is now similar to starting a new CCC: all Targets must acknowledge the Write Command to the Broadcast Address before the Controller sends an HDR Restart Pattern to end the CCC modality and return to generic HDR-Ternary Read/Write commands.

Note: With the release of I3C v1.2 this question has been deprecated; it is retained here for reference.

In addition to the Multi-Lane changes for HDR-BT Mode (see Q18.26), the I3C specification now adds:

• Definitions on how to compute the Parity bits within the HDR-BT Header Block
• Definitions and examples for the CRC-16 and CRC-32 polynomials as used for HDR-BT CRC Block checksums
• Clarifications on how the HDR-BT CRC checksum values are calculated based on the data for each HDR-BT transfer
• Correction of an error in the figure showing Direct CCC flows in HDR-BT Mode
• Clarifications on the use of Group Addresses for Direct CCC Read/Write segments in HDR-BT Mode
• Correction of a specification error concerning the use of HDR-BT CRC Blocks in CCC Flows in HDR-BT Mode
• Clarifications to the Transition_Verify byte within the HDR-BT CRC Block; Bits[4:2] are now redefined as always zero
• New figures showing the Single-Lane format for all HDR-BT Mode structured protocol elements
• Corrections to the Dual-Lane and Quad-Lane figures for the HDR-BT Mode structured protocol elements, to resolve inconsistencies with the normative text and to show proper SDA Lane bit packing (i.e., the Transition, Transition_Control, and Transition_Verify bytes)
• Detailed explanation of the Data Block Delay mechanism (formerly called the Stall [delay] mechanism), which allows a Target to delay sending the next HDR-BT Data Block until it has collected enough data bytes (see Q19.14)
• Better explanations of HDR-BT flow control details, including diagrams of example HDR-BT transfers with different actions at the flow control points (i.e., the various Transition bytes)

Note:

• For I3C v1.1.1 and earlier: See Section 5.2.4 for the HDR-BT framing definitions, including all requirements and figures.
• For I3C v1.2 and later: See Section 6.4.3 for the HDR-BT framing definitions, including all requirements and figures.

Note: With the release of I3C v1.2 this question has been deprecated; it is retained here for reference.

Yes. In the I3C v1.1 specification, Figure 164 CRC Block for Dual Lane and Quad Lane (i.e., the HDRBT CRC Block) presented the Dual Lane encoding of the CRC Block inaccurately, specifically in the Transition_Verify byte:

• For HDR-BT Read transfers where the Target provides the clock, the figure incorrectly indicated the “handoff” point (where the Controller resumes driving SCL) as the C12 falling edge, i.e., the very end of the Transition_Verify byte for Dual Lane. The text of specification Section 5.2.4.2. and Section 5.2.4.3.3, by contrast, correctly defines the “handoff” point for Dual-Lane as the second half-clock of the Transition_Verify byte, i.e., the C11 falling edge.
• Figure 164 also incorrectly showed that the SDA[0] Lane could optionally be High after the “Park1, High-Z” on the C11\ clock cycle (i.e., Bits 4 and 6). The specification text, by contrast, correctly defines Bits[7:2] of the Transition_Verify byte as reserved, and requires them to be set to 0. In I3C v1.1.1, the specification text now defines Bits[4:2] as always 0, with Bits[7:5] still reserved for future definition by the MIPI I3C WG.

In both points above the v1.1 specification normative text was correct, and the Dual Lane HDR-BT CRC Block in Figure 164 was incorrect. The “handoff” point is indeed at the C11 falling edge, not the C12 falling edge. The I3C v1.1.1 specification clarifies these details and corrects the figure. Additionally, SDA[0] must be driven Low for Bit 4, even if the receiver does not drive SDA[0] Low and inform the transmitter that the CRC did not match after the “Park1, High-Z” (i.e., for the C11 falling edge).

Note: For a Read transfer where the Target was providing clock, the “handoff” is required to occur before the transmitter (i.e., the Target providing Read data) completes transmission of the Transition_Verify byte. In this case, the Target must then follow the Controller’s clock, since the Controller would drive SCL after the falling edge of C11.

Figure 1 below shows a corrected version of the relevant details for the Dual Lane HDR-BT CRC Block, focusing on the Transition_Verify byte. The figure includes a portion of Figure 175 from the I3C v1.1.1 specification (see Section 5.2.4.6), highlighting the changes and clarifications.

Note:

The I3C v1.1.1 specification provides clarifications and improves the descriptions of the requirements for handling the Transition_Verify byte at the end of the CRC Block, for all defined Multi-Lane configurations, including cases where the receiver fails to acknowledge the transfer. In general, the Controller must control SDA[0] and any other SDA[1:3] data Lanes (per the Lane configuration) due to the updated definition of the bit fields in the Transition_Verify byte.

For I3C v1.2 and later: See Section 6.4.3.6 for the most current versions of all figures and diagrams for HDR-BT Mode structured protocol elements, including the CRC Block.

This mechanism allows a Target to delay sending a complete HDR-BT Data Block during an HDR-BT Read transfer, for situations where the Target or its inner system was unable to fully prepare enough data bytes to fill a Data Block as part of the Read transfer in HDR-BT Mode.

In I3C v1.1, the HDR-BT Data Block Delay mechanism was called the “Stall (delay) mechanism” and was not fully defined. Additionally, the name “Stall (delay)” was too easily confused with other I3C defined behaviors in which SCL clock stalling is permitted (i.e., stalling by the Controller is allowed, but never stalling by a Target). The confusion occurred because this HDR-BT mechanism is fundamentally different from SDR Mode SCL clock stalling, and I3C did not define SCL clock stalling in HDR-BT Mode.

Starting with v1.1.1, the I3C specification addresses this confusion by renaming the mechanism to more accurately reflect its definition, and by adding clearer, more complete normative details. In addition, the name of parameter “tBT_STALL” was changed to “tBT_DBD”.

During an HDR-BT Read transfer, the Data Block Delay mechanism allows the Target to transmit either:

• A valid Data Block, which is not intended to be the last such Data Block, if the Target has a full 32 bytes of data to transmit; or
• A single Delay byte, indicating that the Target is not yet ready to transmit a Data Block and that the Controller should therefore continue the Read if it wishes to receive more data.

This Delay byte differs from a valid Transition_Control byte (i.e., the first byte of an HDR-BT Data Block). The Target may defer sending a Data Block (i.e., by sending a Delay byte up to a maximum of 1024 times) at any point of a Read transfer, before it must terminate the Read transfer. The Controller also has the opportunity either to continue waiting (i.e., receiving more Delay bytes until the Target has enough data), or to terminate the Read transfer at its discretion.

This mechanism does not allow the Target to delay sending either the CRC Block or the Last Data Block (e.g., one that might have “ragged” data).

The Controller determines whether the addressed Target may use the Data Byte Delay mechanism. The Controller indicates this in the Control byte of the HDR-BT Header Block that starts each HDR-BT Read transfer.

• If the Target supports this mechanism and chooses to use it for this transfer, then the Target may use the mechanism if needed.
• If the Target does not support this mechanism, or if the I3C Controller has indicated that the Data Byte Delay is not permitted, then the Target must not use this mechanism, in case it encountered a situation where it was unable to fully prepare enough bytes to fill a Data Block. In such a situation, the Target might be forced to end the HDR-BT Read transfer early (i.e., by sending incomplete data).

This mechanism is primarily useful when the Controller controls the SCL clock during the HDR-BT Read transfer, as the Target would otherwise not have a method for indicating that the transfer should be slowed to match the actual rate of Data Blocks that it can reasonably produce (i.e., from its inner system that might provide the data bytes).

Note:

For I3C v1.1.1 and earlier:

• See Section 5.2.4.3.4 for the Data Block Delay Mechanism; and
• See Section 5.2.4.7 for examples of HDR-BT flow control using this mechanism.

For I3C v1.2 and later:

• See Section 6.4.3.3.4 for the Data Block Delay Mechanism; and
• See Section 6.4.3.7 for examples of HDR-BT flow control using this mechanism.
• Additionally, the SCL clock stalling definitions for I3C v1.2 are now defined in Section 6.4.3.7.1, however SCL clock stalling should not be used with the Data Block Delay mechanism.
  
  

Yes, in cases where the Controller is not able to sample SDA within the 3 ns setup time, it is acceptable for the Controller to stretch the SCL low period, or to reduce the clock frequency as needed. The Controller should always sample SDA based on the effective timing budget, while considering the effective Clock-to-Data turnaround time (tSCO) as well as the effective propagation time (from Target to Controller). However, the minimum time for tLOW_DIG should be greater than SCL tSCO + the rising/falling time for SDA + tSUPP.

For further guidance, implementers should contact MIPI Alliance.

The Controller should send the GETCAPS CCC to determine whether the Target supports I3C v1.2 or later. If so, then it can use the optional capability bits for HDR Mode CCC support, as returned in the GETCAP4 byte of the GETCAPS Format 1 CCC response. Otherwise, the Controller can either rely on private agreement, or it can attempt to send a single CCC (such as GETSTATUS) in a supported HDR Mode and see whether the Target responds as expected. If the Target does not respond to the CCC in that HDR Mode (i.e., for a CCC that is known to be supported in SDR Mode), then the Controller might need to avoid sending CCCs to that Target in that HDR Mode.

In some cases, sending CCCs in that HDR Mode might cause issues for older I3C Targets (i.e., v1.0- compliant) as such Targets will not understand the CCC framing, and therefore will not be able to distinguish between a CCC (sent to any Target) and a regular HDR transfer. This could also mean that the Target would not properly recognize the End of CCC Procedure; as a result, the Controller would need to simply use the HDR Exit Pattern after each CCC in that HDR Mode, instead of other End of CCC Procedures that stay in that HDR Mode. As a last resort, the Controller could simply avoid sending any CCCs in that HDR Mode, and only use SDR Mode to send CCCs.

Note:

For I3C v1.2 and later: See Section 5.4 for the updated GETCAPS data byte formats, including the GETCAPS4 byte that indicates CCC support in HDR Modes.

In I3C v1.1.1 and earlier, the framing of transfers in HDR-BT Mode did not clearly explain when CRC Blocks were actually needed, and the definitions were not consistent for all flows (including CCC flows in HDR-BT Mode). Additionally, the CRC Block was defined as required for all HDR-BT transfers, even those that had zero data bytes (i.e., no Data Blocks). Furthermore, Broadcast CCCs defined the use of the Cmd1/Cmd2/Cmd3 bytes in the Header Block to store the first data bytes in the Broadcast CCC payload, which created complexity for implementers; and the End of CCC procedures were not defined efficiently, especially for cases where the CRC Block was required but there were no Data Blocks before it.

I3C v1.2 addresses these issues by adjusting the HDR-BT Mode framing, to correct these inconsistencies, improve efficiency and eliminate the need to send unnecessary CRC Blocks. Starting with I3C v1.2, Controllers are required to use Bit[4] in the Control byte of the Header Block to indicate that the new framing requirements are being followed. The new framing requirements are summarized here:

• Previously, Broadcast CCCs used bytes Cmd1 through Cmd3 in the Indicator Block to hold the first data bytes of the CCC. Bit[4] set to 1'b1 now indicates that Broadcast CCCs will no longer use bytes Cmd1 through Cmd3 of the Indicator Block for data bytes. All data bytes for Broadcast CCCs will now be sent in HDR-BT Data Blocks (i.e., after the Indicator Block).
• Previously, the HDR-BT CRC Block was defined as required for all HDR-BT transfers. Bit[4] set to 1'b1 now indicates that the CRC Block will not be sent with zero-byte transfers (i.e., Header Blocks with no subsequent Data Blocks).
• Previously, the Controller was required to send one HDR-BT CCC Header Block to end the CCC modality for both Broadcast and Direct CCCs sent in HDR-BT Mode. Bit[4] set to 1'b1 now indicates that the Header Block will not be sent when ending the CCC modality for Broadcast CCCs, since the CCC modality will end automatically with the HDR Restart Pattern.
• Additionally, the end of the Transition byte in the Header block has been adjusted such that the Controller will park the SDA[x:0] lanes into a safe state, where the addressed Target can safely take control of these lanes for an HDR-BT Read transfer. This was not clearly defined in v1.1.1 and there was a risk that the addressed Target would not be able to drive the SDA[x:0] lanes to the correct values for the first rising clock edge in the first Data Block (immediately after the Header Block).
• For Dual Lane only: Bit[4] set to 1'b1 now indicates that the Transition_Control byte within an HDR-BT Data Block will swap the positions of Bit[4] and Bit[5]. This is done to prevent issues during HDR-BT Read transfers in Dual Lane mode, when the Read transfer was terminated by the Controller during the first clock cycle in the Transition_Control byte, which could cause parity errors. See Q19.18 for more details. (This does not apply to Single Lane or Quad Lane.)

I3C v1.2 also defines the conditions when the Controller is allowed to stall the SCL clock during HDR-BT transfers. This was not defined clearly in I3C v1.1.1 and earlier.

Due to these framing changes, Targets that comply with I3C v1.2 and interoperate with older Controllers (i.e., those that only support I3C v1.1.1 or earlier) would also need to support the older framing for HDR-BT transfers, where Bit[4] would always be set to 1'b0.

Note that all HDR-BT diagrams in I3C v1.2 have been updated to show these changes.

Note:

For I3C v1.2 or later:

• See Section 6.4.3.3 for the HDR-BT structured protocol elements, including the Header Block and Data Block; and
• See Section 6.4.3.6 for the updated HDR-BT diagrams.

Yes. In I3C v1.2, an issue was identified where terminating an HDR-BT Read transfer could cause parity errors for the Transition_Control byte within the HDR-BT Data Block, especially when a Read transfer was terminated while the Target is trying to use the Data Block Delay mechanism (see Q19.14). In order to prevent parity errors, the SDA Lane bit packing for Dual Lane mode has been changed for this situation only (i.e., only for the Transition_Control byte within the HDR-BT Data Block). This bit packing will be corrected in the upcoming Errata for I3C v1.2, and in subsequent versions of the I3C specification. Table 1 shows the changes to the SDA Lane bit packing, which only applies to the Transition_Control byte within HDR-BT Data Blocks (i.e., not to any other uses of Transition-type bytes within Header Blocks or CRC Blocks).

Note:

1. Bit2 takes the typical place for Bit1 (i.e., for a data byte), since the High-Z bit on SDA[0] is always Bit1 for a transition byte.
2. Compared to a data byte, Bits[7:3] are unchanged except for special situations.
3. In order to prevent parity errors, Bit4 and Bit5 are swapped for the Transition_Control byte within the HDR-BT Data Block. Bit4 will be sent on SDA[1] instead of SDA[0], and Bit5 will be sent on SDA[0] instead of SDA[1]. These bits are not swapped for any other uses of Transition-type bytes.

The adjusted bit packing for Dual Lane will be used in Transition_Control bytes for all HDR-BT transfers that use the new HDR-BT framing for I3C v1.2 (see Q19.17). However, if the Controller uses the old HDRBT framing, or only supports I3C v1.1.1 and earlier, then the bit packing is not changed (i.e., Bit4 remains on SDA[0] and Bit5 remains on SDA[1]).

Figure 2 shows a corrected version of the relevant details for the Dual Lane HDR-BT Data Block, focusing on the Transition_Control byte. The figure includes a portion of Figure 165 from the I3C v1.2 specification (see Section 6.4.3.6), showing the changes and clarifications.

Note: This issue is unique to Dual Lane mode. The Target normally drives Bit3 on SDA[1] with a value that would be correct if the HDR-BT Read transfer was allowed to continue. However, if the Controller terminates the transfer on the falling edge of “Clock 0” (shown as C1 in Figure 2), then the Controller takes control of the SDA[0] line and drives zero values for the remainder of the Transition_Control byte, which means that the parity in Bit[3] is likely to be incorrect. Moving Bit4 to SDA[1] solves this issue.

Yes. In addition to the Dual Lane HDR-BT Data Block changes (described in Q19.18), the HDR-BT Header Block diagrams show incorrect handoff windows for HDR-BT Read transfers where the Target provides the clock. The handoff should come before the falling edge of the first clock cycle in the Transition byte. These figures will be corrected in the upcoming Errata for I3C v1.2, and in subsequent versions of the I3C specification.

The following corrections should be observed:

• In Figure 161 Header Block for Single Lane, the correct handoff window should be placed before the falling edge of C25 (i.e., before the High-Z on SDA[0]) while SCL is High.
• In Figure 162 Header Block for Dual Lane, the correct handoff window should be placed before the falling edge of C13 (i.e., before the High-Z on SDA[0]) while SCL is High.
• In Figure 163 Header Block for Quad Lane, the correct handoff window should be placed before the falling edge of C7 (i.e., before the High-Z on SDA[0]) while SCL is High.

Note: Other normative text in Section 6.4.3.3.1 is correct; only the handoff windows are incorrectly placed within these figures. These handoff windows do not apply to HDR-BT Write transfers. The Target should only provide the clock for an HDR-BT Read transfer if both (A) it supports this capability; and (B) if the Controller provided a value of 1'b1 in Bit2 within the Control byte of the HDR-BT Header Block, which indicates that the Target is expected to provide the clock. (See also Q24.8) If Bit2 is 1'b1 but the Target does not support this capability, then the Target must NACK the HDR-BT Read transfer.

Figure 3 shows a corrected version of the relevant details for the Dual Lane HDR-BT Header Block, focusing on the Transition byte. This figure includes a portion of Figure 162 from the I3C v1.2 specification (see Section 6.4.3.6), showing the changes and clarifications.