Scenario: PAM4 Lane Margin Collapse

Scenario

A new retimer SKU passes compliance fixtures but fails intermittently on long-reach boards after thermal soak. One byte lane shows shrinking vertical margin while others remain stable; FEC correctable rate climbs before hard errors.

OBSERVED METRIC
Lane-specific eye height collapse and rising FEC correctables under thermal ramp.

45-MINUTE INTERVIEW FLOW
0-5: scope traffic and SLA context
5-15: map first failing SerDes transition
15-25: identify proving artifacts
25-35: propose bounded fix with owner
35-45: state validation matrix and rollback

Common pitfalls

• Retraining all lanes globally without isolating the failing lane and segment.

• Blaming retimer firmware before correlating package via and PI noise on that lane.

• Closing on room-temperature eye scan without hot-corner margin reproduction.

Scenario debrief

Score candidate response on traffic framing, timing proof, mitigation boundedness, and regression discipline.

request stream -> controller policy -> SerDes timing behavior -> measured outcome

latency/bandwidth trend

Debrief prompts

1. Which SerDes timing or queue behavior fails first in evidence?

2. Which smallest safe controller, PHY, or policy change addresses it?

3. Which benchmark + counter gate proves closure under production 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 SerDes 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.