Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • AMS Metrics Reference
  • AMS Interface Glossary
  • Reading Path
  • Analog-Digital Boundaries61
  • PLL & DLL Clocking61
  • SerDes & High-Speed I/O61
    • SerDes Basics
    • Equalization Overview
    • Link Training
      • Link Training: Mechanism
      • Link Training: Inputs & Outputs
      • Link Training: Reports & Metrics
      • Link Training: Debug Playbook
      • Link Training: Worked Example
      • Link Training: Pitfalls & Red Flags
      • Link Training: Interview Drills
      • Link Training: Review Checklist
      • Link Training: Theory Deep Dive
      • Link Training: Design Space
      • Link Training: Expanded Case Study
      • Link Training: Step-by-Step Walkthrough
      • Link Training: Comparison Matrix
      • Link Training: Software / Programmer View
      • Link Training: Silicon PPA Impact
    • High-Speed SI Awareness
    • SerDes & High-Speed I/O: Tricky Q&A
  • ADC / DAC Interfaces61
  • Mixed-Signal Integration61
  • Noise & IR at the Boundary61
  • AMS Interface Interview Prep61
  • AMS Interface Cheatsheet
Loading lesson

‹SerDes & High-Speed I/O
  1. Topics
  2. Analog & Mixed-Signal
  3. SerDes & High-Speed I/O
  4. Link Training

AMS Interface · All levels

Link Training

SerDes & High-Speed I/O: Training protocols establish lane polarity, timing, equalization, and protocol states; digital state machines must synchronize with PHY indications and timeout policies.

  • 15topics
  • 15lessons

Topics in this section

  1. 1Link Training: Mechanism1 lesson
  2. 2Link Training: Inputs & Outputs1 lesson
  3. 3Link Training: Reports & Metrics1 lesson
  4. 4Link Training: Debug Playbook1 lesson
  5. 5Link Training: Worked Example1 lesson
  6. 6Link Training: Pitfalls & Red Flags1 lesson
  7. 7Link Training: Interview Drills1 lesson
  8. 8Link Training: Review Checklist1 lesson
  9. 9Link Training: Theory Deep Dive1 lesson
  10. 10Link Training: Design Space1 lesson
  11. 11Link Training: Expanded Case Study1 lesson
  12. 12Link Training: Step-by-Step Walkthrough1 lesson
  13. 13Link Training: Comparison Matrix1 lesson
  14. 14Link Training: Software / Programmer View1 lesson
  15. 15Link Training: Silicon PPA Impact1 lesson
On this page

    What this topic teaches

    Link Training converts analog-digital assumptions into a measurable engineering contract. Training protocols establish lane polarity, timing, equalization, and protocol states; digital state machines must synchronize with PHY indications and timeout policies. The hard part is proving which boundary broke first, under which mode, and with which evidence.

    The senior-engineer question

    When training pass rate, time-to-L0, fallback mode frequency moves, can you isolate the first failing boundary, identify owner, and define the smallest reversible change that proves root cause?

    Diagram
    AMS CLOSURE FLOW — Link Training
    
    spec + handoff assumptions
            |
            v
    boundary implementation (wrapper/cells/reset)
            |
            v
    physical context (floorplan/power/package)
            |
            v
    metrics + artifacts (jitter/BER/noise/validity)
            |
            v
    root-cause classification -> bounded fix -> regression
    
    Debug rule: always name mode, boundary, evidence tag, and owner.

    Picture the boundary behavior

    Start every study session by drawing the contract before opening logs or reports. The diagrams below are what to reproduce on whiteboard.

    Training state path

    Diagram
    detect -> poll -> config EQ -> align -> active/L0
          ^                                  |
          +------------- retry/fallback -----+

    Boundary sequence

    Diagram
    AMS BOUNDARY SEQUENCE — Link Training
    
    analog macro -> wrapper / boundary cell -> synchronizer or sampler -> digital consumer
          |                 |                         |                     |
      analog assumptions    legal voltage/state       clock/reset contract   protocol/data validity
    
    metric under watch: training pass rate, time-to-L0, fallback mode frequency

    Who owns which layer

    Diagram
    AMS OWNERSHIP LAYERS — Link Training
    
    layer                owns                                failure mode
    ------------------   ----------------------------------  --------------------------
    spec contract         clocks/resets/interfaces            hidden assumption drift
    wrapper logic         synchronizers/framing/flags         silent data corruption
    physical integration  floorplan/isolation/power           coupled noise and droop
    signoff governance    waivers/checklists/dashboard        release with blind spots
    closure               debug order + regression            fix regresses another mode

    Evidence to collect

    • Primary metric: training pass rate, time-to-L0, fallback mode frequency.

    • Primary artifact: training state trace, firmware log, protocol analyzer capture.

    • Owners to bring into review: firmware owner, PHY owner, system validation lead.

    • One tagged reproduction and one reduced reproducer.

    • Cross-check from at least two evidence planes: functional and physical/signoff.

    Ownership map

    Diagram
    OWNERSHIP MAP — Link Training
    
    artifact                  owner
    ----------------------    -----------------------------
    integration artifact    firmware owner
    implementation artifact PHY owner
    signoff artifact        system validation lead
    
    Every boundary issue needs a named owner before fixes start.

    Subpages in this topic

    Each topic includes mechanism, contract I/O, reports, debug, worked example, pitfalls, interview, checklist, theory, design-space, extended case study, walkthrough, comparison matrix, software view, and silicon PPA impact.

    Key takeaways

    • Carry boundary and mode context with every metric.

    • Prove mechanism with tagged evidence before changing silicon-facing logic.

    • Close with explicit owner-aligned regression criteria.

    Common pitfalls

    • Assuming lock/ready/valid means healthy behavior.

    • Ignoring package and power contributors in jitter/SerDes issues.

    • Waivers without expiry, owner, or mitigation plan.

    AMS deep dive

    SerDes closure requires protocol, training, and SI evidence together.

    Concept diagram

    Diagram
    SERDES FLOW
    
    training -> equalization -> lane margin -> protocol stability

    Metric graph

    Diagram
    BER VS EQ
    
    BER
     ^
     |  high  low  high
     +-----------------> EQ setting

    Reports 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.

    PreviousNext: Link Training: Mechanism

    Up next

    Up nextLink Training: Mechanism

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • SerDes Basics
    • Equalization Overview
    • High-Speed SI Awareness