Detect, Polling, and Configuration States: Inputs and Outputs

Inputs and outputs contract

Inputs and Outputs for Detect, Polling, and Configuration States focuses on Link-up time, detect timeout count, and config state entry success rate. The purpose is to turn memory observations into mechanism-backed actions with explicit owners and release-safe validation.

Use this contract for architecture, controller firmware, PHY, and validation handoffs. Missing inputs create expensive late-stage rework and inconclusive debug loops.

INPUTS
  - workload distribution and QoS target
  - firmware revision, controller policy profile, timing registers
  - data-rate / voltage / temperature operating state
  - training snapshot and reliability policy status

OUTPUTS
  - bottleneck classification with command-level evidence
  - owner-signed mitigation proposal
  - before/after trend for latency, bandwidth, and reliability
  - regression matrix with rollback triggers

Ownership split

OWNERSHIP LAYERS - Detect, Polling, and Configuration States

layer              owner
-----------------  ----------------
protocol/RTL       PHY owner
PHY/SI             PHY + SI/PI owner
firmware/OS        FW + driver owner
validation         compliance + post-silicon

PCIe/CXL deep dive

LTSSM and equalization determine whether high-speed links are stable under corner traffic and retimer paths.

Concept diagram

LTSSM + EQ

Detect -> Polling -> Config -> L0 <-> Recovery

Metric graph

LINK INSTABILITY SOURCES

EQ margin           ██████
retimer FW          ████
SI/cable plant      ███

Reports and artifacts

• LTSSM state log

• EQ coefficient dump

• negotiated speed/width snapshot

• recovery trigger timeline

Mini case study

Gen5 passed cold boot EQ but entered Recovery loops under DMA heat after retimer firmware update.

Debug branches

• Capture ordered sets at failure boundary

• Compare EQ presets across temperature corners

• Bypass retimer to isolate segment faults

Senior review question

Ask: which latency, bandwidth, and reliability evidence proves this PCIe/CXL topic is closed under real traffic?

Key takeaways

• Always tie controller and PHY counter shifts to application latency and throughput outcomes.

• Lock firmware timing profile, thermal condition, and DIMM state before comparing PCIe/CXL captures.

Common pitfalls

• Chasing peak bandwidth while ignoring p99 latency and fairness tails.

• Changing timing guardbands without separating SI noise from scheduling issues.

• Declaring closure without reliability gates, fault injection, and regression replay.

Handoff explanation

Inputs extend beyond timing registers. PCIe/CXL analysis inputs include traffic distribution, address map, queue policy, training state, SI/PI condition, thermal state, and firmware version.

Outputs must be action-ready: Link-up time, detect timeout count, and config state entry success rate, artifact packet (LTSSM state log, TS1/TS2 capture, and lane polarity map), bottleneck class, owner, expected gain, and rollback scope. "Bandwidth improved" without this packet is not signoff-ready.

The safest handoff is a before/after evidence set: environment tags, traces, hypothesis, chosen fix, rejected alternatives, and regression criteria.