Does the mandated "single-retry model" apply to all Directed Read CCCs?

At Section the I3C v1.1 Specification states: “I3C mandates a single-retry model for Direct GET CCC Commands.” Based on this statement, adopters have a general notion that the Master is required to retry once for the Directed GET CCCs if the Slave NACKs for the first time. This may not be applicable for other “read” Directed CCCs (such as RSTACT, MLANE, vendor read, etc.) that are not defined for dedicated Read CCCs (i.e., CCCs that have names of the form GETxxx).

Does an I3C Slave need to receive and process the Broadcast ENEC, DISEC, and other Bus-state CCCs before being assigned a Dynamic Address?

Yes. An I3C Slave is expected to monitor Broadcast CCCs; the special exception is for Hot-Join Slaves, as explained below.

The Slave should process all supported Broadcast CCCs, but it is required to process supported ones that affect Bus state. This includes the ENTHDRn CCCs (which turn the HDR Exit Detector on), as well as the ENEC and DISEC CCCs for whatever events the Slave supports (e.g., IBI).

What is the I3C Open-Drain tHigh Max? Table 10 shows it as 41 ns, but a Note says it may be longer

In I3C v1.1, Table 10 (I3C Open Draining Timing parameters) lists the tHigh symbol as having a maximum value of 41 ns, and then Note 4 says that “tHigh may be exceeded when the signals can be safely seen by I2C Slaves”. This means that a 41 ns tHigh will ensure that no legacy I2C Slave will see the SCL changes, and so will not interpret the START followed by the Address phase nor the ACK/NACK. The Master may use a much longer tHigh if there is no harm with a legacy I2C Slave on the I3C Bus seeing the clocks.

Are there any special timing requirements for sending the first START + 7’h7E + W?

Yes. The I3C Master must emit the first START, 7’h7E at Open-Drain speeds (usually I2C Fm+ speeds) so that I3C Slaves with I2C Spike Filters will be able to see the I3C Broadcast Address, and then as a result turn off the Spike Filter. If the Master knows that none of the I3C Slaves has a Spike Filter, then it may omit this. Similarly, if the Master knows that all of the I3C Slaves have accurate Spike Filters, then it may use the I3C 2.5 MHz open-drain speed (i.e., 200 ns Low, 200 ns High).

When does a Slave escalate Slave Reset to Full-Chip reset?

If the Slave does not receieve a RSTACT CCC before seeing the Slave Reset Pattern, then it uses the default action of Peripheral Reset (i.e., reset just the I3C block). If the Slave again receives no RSTACT CCC before seeing a Slave Reset, then it then escalates to a Full-Chip Reset. It therefore holds the state after any default Peripheral Reset, so as to activate the escalation. That state is cleared if the Slave sees either an RSTACT CCC, or a GETSTATUS CCC addressed to it.

What is the minimal Slave Reset support required in I3C v1.1?

Although MIPI Alliance strongly recommends true support of Slave Reset, such that a Master can fully reset a Slave chip when needed, it is not required. Full Chip Reset allows replacement of the SRSTn trace that would normally be used to reset a Device.

The minimal reset is a reset of the I3C peripheral, at least to a level that will allow a ‘stuck’ I3C peripheral to start working again. How much of a reset that requires is up to the Slave Vendor; for example, it could be handled by an internal interrupt which would allow firmware/software in the Slave to handle the reset.

When does the RSTACT CCC state clear in an I3C Slave?

The RSTACT state will be cleared back to default upon either:

  1. Detection of a Slave Reset Pattern. This will enact the RSTACT action, and then clear the state.
  2. Detection of a completed START (but not repeated START). This consists of the SDA line going from High to Low while the SCL line remains High, followed by the first falling edge on SCL. The RSTACT may be cleared either on that falling edge, or on the rising edge that follows.