Mechanism to understand

Mechanism for I2C Timing & Arbitration focuses on NACK rate, clock-stretch duration, bus recovery time. The goal is to connect the observable symptom to protocol mechanism, ownership, and regression risk.

I2C shares open-drain wires with address arbitration, acknowledge cycles, and optional clock stretching. Think of it as a contract enforced at boundaries: the sender promises stability and legality, the receiver promises forward progress, and the fabric in between promises not to silently change identity or ordering.

• Identify the transaction boundary: request, data, response, completion, or retry.

• Identify the flow-control boundary: valid/ready, grant, credit, FIFO depth, or lane state.

• Identify what the receiver is allowed to assume and what the sender must hold stable.

Layered view

PROTOCOL STACK VIEW — I2C Timing & Arbitration

software / firmware intent
        |
        v
transaction semantics: address, ID, length, attributes, ordering
        |
        v
link / channel behavior: handshake, credits, backpressure, retries
        |
        v
physical or timing layer: clocking, reset, pins, lanes, PHY
        |
        v
observability: waveform, VIP transaction, counter, analyzer trace

Debug rule: never jump layers without carrying the transaction identity with you.

I2C start/stop and ACK waveform

I2C FRAME

SDA  ‾‾\__/‾‾\__ ... __/‾‾  ‾‾\__/‾‾
SCL  ‾‾‾‾\_/‾\_/‾ ... \_/‾‾‾‾‾‾‾‾
      S  A6..A0 R/W ACK  data..  ACK  P
      ^                            ^
    START                        STOP

START: SDA falls while SCL high
STOP : SDA rises while SCL high
ACK  : receiver pulls SDA low on the 9th clock

Clock stretching

CLOCK STRETCHING (slave holds SCL low to buy time)

SCL master wants: ‾\_/‾\_/‾\_/
SCL on the bus  : ‾\_____/‾\_/   <- slave kept it low
                       ^^^^ stretch window

Master must tolerate stretch or it sees corrupted data.

Layer responsibilities

LAYER RESPONSIBILITY — I2C Timing & Arbitration

layer          owns                         common failure
-----------    --------------------------   -----------------------
software       intent, ordering needs       wrong assumption
transaction    id/addr/len/attributes       ordering / outstanding
link/channel   handshake, credits, retry    backpressure / deadlock
physical       clock/reset/lanes/PHY        timing / training / SI
observability  waveform/log/counter         missing evidence

Protocol deep dive

I2C/SPI/UART bugs are contract bugs: timing, reset value, IRQ type, and DMA watermark.

Concept diagram

PERIPHERAL CONTRACT

firmware writes regs -> RTL state machine -> pins -> board -> device
        ^                    |
        +------- IRQ/DMA ----+

If IRQ is level but driver assumes edge, you get lost events.

Metric graph

FIFO WATERMARK vs DMA

FIFO fill
 100%|        *** overrun risk
  75%|     ***
  50%|  ***     <- ideal DMA trigger band
  25%| *
   0%+----------------> time

Metrics and artifacts to collect

• NACK rate

• overrun count

• CS setup/hold violations

• IRQ miss rate

Mini case study

SPI flash worked in loopback but failed in system: CS deasserted one cycle early relative to device hold time. Board + RTL + mode bits together formed the contract.

Debug branches

• If overrun, FIFO depth vs ISR latency vs DMA burst.

• If NACK on I2C, pull-ups, speed, and clock stretch.

• If garbage data, CPOL/CPHA and MSB/LSB first.

Senior review question

Ask: what is the first transaction that deviates, and which spec rule does it test?

Key takeaways

• Connect every protocol claim to a transaction identity and measurable metric.

• Store the artifact (waveform, log, counter) next to every signoff decision.

Common pitfalls

• Debugging timeouts without finding the first bad transaction.

• Quoting peak bus width without payload efficiency and retry overhead.

• Treating VIP compliance as a substitute for system integration replay.

Mechanism deep dive

I2C shares open-drain wires with address arbitration, acknowledge cycles, and optional clock stretching.

Walk the transaction forward: request accepted → data moves → response completes → software visible effect.