MIPI CSI / DSI Overview: Reports & Metrics

Reports and metrics

Reports & Metrics for MIPI CSI / DSI Overview focuses on lane error rate, frame drop count, blanking budget. The goal is to connect the observable symptom to protocol mechanism, ownership, and regression risk.

The job of a report is to turn lane error rate, frame drop count, blanking budget 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 — lane error rate, frame drop count, blanking budget

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 — MIPI CSI / DSI Overview

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 lane error rate, frame drop count, blanking budget 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

USB/Ethernet/MIPI failures cross MAC counters, PCS framing, PHY adaptation, and channel SI.

Concept diagram

HIGH-SPEED STACK

app -> MAC/framing -> PCS/encoding -> SerDes/PHY -> channel

CRC errors often mean PCS/PHY/channel, not TCP.

Metric graph

BER vs EQ SETTING

BER
1e-3 |*
1e-6 |  *
1e-9 |     **** usable window
1e-12|          *
     +-----------------> EQ tap

Metrics and artifacts to collect

• CRC error rate

• retrain count

• frame drop

• lane error

• BER

Mini case study

Ethernet link up at 100G but lossy: equalization margin on one lane narrow after package change. Digital counters were clean; PHY margin was not.

Debug branches

• If link up but lossy, PHY margin and retrain.

• If enumeration OK but throughput low, check packet size and DMA batching.

• If MIPI frame drops, blanking budget and lane polarity.

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

lane error rate, frame drop count, blanking budget must be split by traffic class, payload size, and reset mode.