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
  • Reading Path
  • Cache Coherency Glossary
  • The Shared Course Model
  • Cache Coherency Revision Sheet
  • Why Coherence Exists8
  • States and Protocols12
  • Transactions12
  • Races and Controller Design8
  • Progress and the Fabric16
    • Virtual Networks and Progress
      • A Protocol Deadlock
      • Message Classes and Virtual Networks
      • Deadlock, Livelock, Starvation
      • Stating Progress Assumptions
    • Filtering and Snoop Pruning
    • Latency, Fairness and QoS
    • Hierarchical and Chiplet Coherence
  • Ordering and Synchronization12
  • Performance and Scalability12
  • Real Protocols12
  • SoC Integration12
  • Power, Clocking and Reliability12
  • Verification12
  • Debug and Bring-up12
  • Interview and Design Review17
  • Capstone: A Coherent Model Lab5
Loading lesson

‹Virtual Networks and Progress
  1. Topics
  2. Cache Coherency
  3. Progress and the Fabric
  4. Virtual Networks and Progress
  5. Deadlock, Livelock, Starvation

Part 5 · Progress and the Fabric · All levels

Deadlock, Livelock, Starvation

Distinguish lack of enabled progress, repeated ineffective work, unfair service and ordinary temporary stalls.

On this page

    What can still move when a transaction does not finish?

    A flat latency counter cannot classify the failure. Inspect enabled transitions and resource ownership. Use the two-core model with a pending request for X, and add only the finite queues or arbitration policy each case describes.

    Case

    What happens

    Classification

    Evidence

    P_X and Q wait on each other

    No permitted service can free either resource.

    Deadlock in the modelled subsystem, which is closed: no outside event can free a resource.

    A held/requested dependency cycle and no enabled escape.

    MSI: M passes back and forth

    C0 receives Data(M) but answers C1's Fwd-GetM before its store performs. C1 then does the same. The line moves between them and no store completes.

    Livelock.

    Messages keep moving, no useful operation completes. Repair: the policy in Simultaneous Upgrades.

    C1's GetM is NACKed on every retry

    H keeps admitting C0's requests for other lines into every freed slot, so C1's retry for X is always NACKed.

    Starvation of C1.

    The eligible request is bypassed without bound. Remedies: Retries, NACKs and Credits.

    Output temporarily full, then drains

    The blocked sender resumes after capacity returns.

    Backpressure, not by itself a progress failure.

    A finite stall with a named capacity-return event.

    Decision tree: a held/requested cycle with no escape is deadlock, a wait on a named capacity or external event is backpressure, endless activity with no completion is livelock, and completion of others while one eligible request is bypassed without bound is starvation.
    Classify by what can still move. A timeout alone shows none of these.

    Different diagnoses require different repairs

    A reserved response path can remove the earlier P/Q deadlock. It does not make an unfair arbiter service C1. A fair arbiter does not repair a full resource cycle. Random backoff can reduce collisions but is not a deterministic proof that every operation eventually finishes.

    Eventual completion after a backpressure stall holds under A1-A6 (assumptions), here chiefly A4: the downstream consumer eventually accepts. Without it, 'the queue will drain' is a wish rather than an argument.

    A finite test can demonstrate a deadlock checkpoint for a closed modelled system, or detect an excessive wait under an assumed bound. It cannot establish an infinite execution from a timeout alone. Preserve state and dependencies when reporting a hang instead of only reporting elapsed cycles.

    Common pitfall

    Calling every lack of completion deadlock. A response still in transit under an unbounded-latency model may be delayed without a closed cycle; a waiter losing arbitration may be starving while the system remains busy.

    Interview

    For each term, identify what stops: all relevant transitions, useful work despite activity, or only one request despite other useful work.

    Check yourself If C0 completes a new write every ten cycles while C1 never wins, is the whole fabric deadlocked?

    Not on that evidence. The system is making useful progress, but C1 may be starving. Review eligibility and fairness rather than trying to break a nonexistent global wait cycle.

    Related topics

    • Shared course model

    • Next: scope the guarantee

    Previous

    48 / 167

    Next: Stating Progress Assumptions

    Up next

    Up nextStating Progress Assumptions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • A Protocol Deadlock