AMS Interface · All levels
SerDes Basics: Debug Playbook
Debug Playbook for SerDes Basics.
Debug playbook
Debug Playbook for SerDes Basics focuses on link-up success, lane BER, lane deskew margin, protocol errors. The goal is to connect observed symptom to boundary mechanism, ownership, and signoff risk.
AMS debug is a hunt for first divergence, not downstream symptom management. Most costly delays come from wrong-owner first actions.
Root-cause tree
ROOT-CAUSE TREE — SerDes Basics
link-up success, lane BER, lane deskew margin, protocol errors regressed
|
same silicon / run tags?
/ \
no yes
| |
env mismatch boundary contract or
tag mismatch true physical issue
/ \ |
clk reset isolate first failing
map sequence boundary transitionFreeze reproducer: mode, firmware/config, and evidence tags.
Find the first boundary signal that diverges.
Map divergence to contract clause and owner.
Classify failure: contract, sequencing, coupling, package, or tool-view mismatch.
Prove mechanism with one reduced reproducer.
Apply smallest reversible fix and rerun cross-domain regressions.
Review memo template
STAFF AMS REVIEW MEMO — SerDes & High-Speed I/O / SerDes Basics
1. Symptom
- Watched metric: link-up success, lane BER, lane deskew margin, protocol errors
- Failing mode/condition: <power/clock/temp/workload>
- Boundary under suspicion: <macro/wrapper/interface/lane/island>
- Repro setup: <sim/emulation/lab + firmware/config tags>
2. Mechanism hypothesis
- Primary mechanism: SerDes converts parallel data to high-speed serial lanes with CDR, encoding, and lane management; system behavior depends on alignment, training, and channel quality.
- Competing hypothesis: <contract gap, sequencing, physical coupling, package, tooling>
- Missing evidence: <waveform, report, scope/analyzer capture, dashboard snapshot>
3. Proposed action
- Minimal reversible change: <RTL/config/layout/policy>
- Expected metric movement: <delta and conditions>
- Regression risk: timing, noise, power, performance, compatibility
4. Signoff
- Re-run artifact: SerDes architecture diagram, lane status capture, BER dashboard
- Required owners: SerDes architect, digital integration owner, bring-up owner
- Final decision: fix, waive with controls, or escalateAMS deep dive
SerDes closure requires protocol, training, and SI evidence together.
Concept diagram
SERDES FLOW
training -> equalization -> lane margin -> protocol stabilityMetric graph
BER VS EQ
BER
^
| high low high
+-----------------> EQ settingReports and artifacts
lane BER
training state transitions
EQ sweep report
link retry counters
Mini case study
Link looked protocol-clean but lane margin collapsed under thermal sweep.
Debug branches
Correlate LTSSM and lane metrics
Check SI margins
Review firmware timeout assumptions
Senior review question
Ask: what boundary condition proves this topic is actually closed?
Key takeaways
State boundary, mode, and evidence tag with every claim.
Always align analog, digital, and physical owners before signoff decisions.
Common pitfalls
Fixing averages while tails still fail.
Skipping package/supply evidence in jitter or SerDes issues.
Shipping with waivers that lack owner and expiration criteria.
Principal AMS review addendum
SerDes converts parallel data to high-speed serial lanes with CDR, encoding, and lane management; system behavior depends on alignment, training, and channel quality.
Metric: link-up success, lane BER, lane deskew margin, protocol errors