PCIe / CXL Debug: Reports & Metrics

Reports and metrics

Reports & Metrics for PCIe / CXL Debug focuses on link degrade event count, completion timeout rate, poison/error log. The goal is to connect the observable symptom to protocol mechanism, ownership, and regression risk.

The job of a report is to turn link degrade event count, completion timeout rate, poison/error log 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 — link degrade event count, completion timeout rate, poison/error log

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 — PCIe / CXL Debug

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 link degrade event count, completion timeout rate, poison/error log 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

PCIe is reliable packet delivery over unreliable links; debug flows PHY -> DLL -> TLP -> firmware.

Concept diagram

PCIe DEBUG TOP-DOWN

L0 link healthy?  -> credits OK?  -> TLP completes?  -> driver happy?

Skip a layer and you will mis-own the bug.

Metric graph

LINK DEGRADE EXAMPLE

target x4 Gen4  ---- ---- ---- ----
actual   x4 Gen4  ---- ---- ---- ----   (eval board)
actual   x1 Gen3  -                   (product board)

Package/SI often shows up as width downgrade, not hard fail.

Metrics and artifacts to collect

• link width/speed

• replay count

• completion timeout

• AER error log

• LTSSM history

Mini case study

Endpoint enumerated but DMA timed out: completion credits exhausted because a switch port was misconfigured in firmware, not because the endpoint was broken.

Debug branches

• If degrade at width/speed, PHY/SI before driver.

• If replay storm, link layer before transaction layer.

• If CXL coherency bug, separate .io vs .cache vs .mem traffic.

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

link degrade event count, completion timeout rate, poison/error log must be split by traffic class, payload size, and reset mode.