I3C Interview Questions

I3C keeps the two wires, START, STOP and the 7-bit address header, and legacy I2C targets can share the bus. Data moves to push-pull, at up to 12.5 MHz. Open drain stays only where several devices may drive: arbitration, ACKs and address assignment. Only the controller drives SCL, so targets cannot stretch the clock. I3C adds dynamic addresses, common command codes, in-band interrupts and hot-join. The ninth bit of a data byte becomes parity or end-of-data.

A push-pull 1 does not wait for a pull-up resistor to charge the bus. So bits get much shorter: 80 ns push-pull against 240 ns open drain on the lesson bench. Where several devices may drive at once, a 0 must win and a 1 must lose quietly, as in a wired-AND. So these stay open drain: the header after START, where targets may raise interrupts, plus ACK slots and address assignment. The header after a repeated START, and data, are push-pull.

It must be a target only, with a static address, Fast-mode support and no clock stretching. A true 50 ns spike filter on SCL hides the short I3C clock highs from it. Then the bus can run I3C at full speed, which is called a mixed fast bus. Without the filter, the device sees I3C traffic as clocks. The bus speed then drops to what the slowest unfiltered legacy device tolerates.

The transmitter drives it. On a write, it is odd parity from the controller: the XOR of the eight data bits with 1. Parity lets the target detect a corrupted byte. On a read, it is end-of-data from the target: 0 ends the message, and 1 offers more. So the target decides how much it returns, though the controller may abort after a 1 with a repeated START.

It cannot NACK the byte, because the ninth bit belongs to the controller. Error type S2 says the target ignores the rest and waits for a STOP or a repeated START. The controller sees nothing on the wire. It learns of the error later, from the Protocol Error bit that GETSTATUS returns.

No. I3C Basic v1.0 leaves out the HDR (high data rate) modes themselves. But a full I3C controller may still put the bus into HDR for other devices. Every target must detect the HDR entry command and the HDR Exit Pattern, even one with no HDR support. A target that misses the exit treats HDR traffic as SDR and misreads what follows. Feature lists differ between I3C editions, so name the edition you quote.

The controller broadcasts ENTDAA, then runs rounds of Sr (repeated START) with 7E/R. Every target without an address ACKs and sends its 48-bit provisional ID, then BCR and DCR. These bits go out in open drain, with no ACKs in between. The lowest 64-bit value wins and gets a 7-bit address plus odd parity, which it ACKs. A loser stops driving and competes again in the next round. A round that nobody ACKs ends DAA.

Yes. In I3C a lower address means higher priority. Several targets may raise an in-band interrupt after the same START. The lowest address then wins the header arbitration, because 0 bits win on the wire. So the controller should give low addresses to targets with urgent interrupts. It can reassign addresses later with SETNEWDA or RSTDAA.

Either two targets sent identical ID, BCR and DCR, or one target kept driving after it lost. Both then ACK the same address. The controller knows how many devices need an address. It must compare that number with the count actually assigned, and fewer means a collision. It then resets the duplicate with RSTDAA (direct or broadcast) and runs DAA again.

With a vendor-fixed ID, two copies of one part share the maker and part bits. Only the 4-bit instance ID tells them apart. The system designer sets it, for example with straps or fuses. If two boards strap the same value, the IDs tie, so the controller must check after DAA.

The target NACKs when the parity bit is wrong. The controller moves on to the next round, and the same target wins again with the same ID. If it NACKs a second time, the controller must leave DAA. It then runs an error procedure that the system designer defines. So a target with a broken parity check blocks every target behind it.

No. With SETDASA, the controller gives one target at a time a dynamic address, using its known static address. SETAASA does it for all supporting targets at once, with no arbitration: each static address becomes the dynamic one. ENTDAA then handles targets that have only a provisional ID. In a mixed system, the controller sends SETAASA before ENTDAA.

The target puts its own address with R into the arbitrable header after a START. If the bus stays free for the Bus Available time, the target pulls SDA low itself. The controller then completes the START and drives the clock. The controller has three answers. It can ACK and read the mandatory byte, if BCR bit 2 promises one. Or it can NACK so the target retries later, or NACK and disable its events with DISEC.

IBI saves a host pin and a board trace per device. The interrupt carries the source's address and often a data byte, so the host need not poll to find who asked. The price is latency that depends on the bus. A request waits for a START or the Bus Available time, controller stalls add delay, and a lower-address target wins collisions. Keep a pin where worst-case latency must stay tightly bounded.

The header is open drain, so the lowest address on the wire wins. Any assigned dynamic address (0x03 to 0x7B) is lower than 7E. So an interrupting target always beats the controller's broadcast header. Between targets, the lower address wins. The losers may try again, but only after the next Bus Available condition, not on a repeated START.

A plain NACK refuses only this request, and the target tries again after the Bus Available condition. To stop the requests, the controller NACKs, sends a repeated START and then DISEC with DISINT set. A controller that NACKs forever without DISEC wastes the bus on retries.

After its ACK, the controller releases SDA and expects the target to drive the byte. Nobody drives, so the keeper or pull-up lets SDA rise while SCL is high. That is a STOP on the wire. A decoder closes the frame early, and a controller that carries on reads 0xFF. The fix is in the target, but only a checker that knows BCR[2] can flag it directly.

It needs several devices, because most I3C faults involve more than one device. Use two targets with near-identical IDs for DAA ties, and two simultaneous IBIs for header contention. Add a legacy I2C neighbour for the coexistence and no-stretch rules, and HDR enter and exit followed by an SDR read. Check with a wire checker and a driver view that shows who drives a 1, for push-pull faults. Also self-check effects such as addresses assigned and bytes read.