Reports and metrics

Reports & Metrics 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.

The job of a report is to turn NACK rate, clock-stretch duration, bus recovery time into a decision. A single average number is almost never enough; you need the distribution, the traffic class breakdown, and a clear gap between legal maximum and product target.

Metric movement

METRIC GRAPH — NACK rate, clock-stretch duration, bus recovery time

throughput / success
  ^
  |                         target
  |                       - - - - - - -
  |                  o after bounded fix
  |              o
  |         o baseline
  |    o failing run
  +--------------------------------------> experiment
    config A     isolated root cause     accepted change

Readout:
  - compare identical payload, clock, reset, traffic seed, and firmware setup
  - separate headline bandwidth from useful payload bandwidth
  - explain why the protocol mechanism moved the metric

Latency distribution

LATENCY HISTOGRAM — I2C Timing & Arbitration

count
  |               ███
  |             ███████
  |          █████████████
  |        █████████████████        <- long tail = the real complaint
  |      ████████████████████████████
  +------------------------------------> latency
   p50      p90    p95       p99  (watch p99, not the average)

Average hides the tail; product pain lives at p95/p99.

• Track NACK rate, clock-stretch duration, bus recovery time by traffic class, payload size, and clock/reset mode.

• Report p50/p95/p99 latency when user-visible stalls matter.

• Include legal maximums and product targets; they are not the same thing.

• Always store the metric next to the artifact that produced it.

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.

How to read the numbers

NACK rate, clock-stretch duration, bus recovery time must be split by traffic class, payload size, and reset mode.