Interface Protocols · All levels

I2C Timing & Arbitration: Inputs & Outputs

Inputs & Outputs for I2C Timing & Arbitration.

Inputs and outputs contract

Inputs & Outputs 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.

Treat these as a signed interface contract. Ambiguity here is the single biggest source of wasted integration weeks, because two teams debug against different assumptions.

diagram
INPUTS
  - protocol spec revision and feature subset
  - clock/reset assumptions
  - address map, ID/tag width, ordering attributes
  - traffic class, QoS, firmware register settings

OUTPUTS
  - legal transaction trace
  - integration waiver list
  - VIP/compliance report
  - owner-signed debug or signoff note

Transaction sequence

diagram
SEQUENCE — I2C Timing & Arbitration

  initiator            interconnect/PHY            target
      |  request (id) ------->  |                     |
      |                         |  forward ----------> |
      |                         |                     | work
      |                         |  <---- response ---- |
      |  <----- complete ------ |                     |
      |
   metric captured here: NACK rate, clock-stretch duration, bus recovery time

Ownership map

diagram
OWNERSHIP MAP — I2C Timing & Arbitration

evidence type        owner who reads it
-----------------    ---------------------------
waveform/RTL        peripheral owner
spec/VIP            board owner
firmware/system     driver owner

Rule: every metric must have a named owner before a review starts.

Protocol deep dive

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

Concept diagram

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

diagram
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.

Principal review addendum

Re-read I2C Timing & Arbitration against one concrete product workload, not a synthetic directed test.

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