Yes. In the I3C v1.1 specification, Figure 164 CRC Block for Dual Lane and Quad Lane (i.e., the HDR-BT 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 2 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.

MIPI I3C FAQ Figure 2 - Q19.8

Figure 2 Corrected Figure 164, CRC Block for Dual Lane

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.

FAQ Type: 
I3C