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 Paths
  • Concept Map
  • How to Read the Diagrams
  • Part 0: What Is a Protocol?10
  • Part 1: Timing and Clocking11
  • Part 2: Encoding and Framing12
  • Part 3: Handshakes13
  • Part 4: Flow Control17
  • Part 5: Transactions19
  • Part 6: Concurrency and Performance17
  • Part 7: Ordering13
  • Part 8: Sharing and Arbitration12
  • Part 9: Deadlock and Liveness13
    • Deadlock, Livelock and Starvation
    • Deadlock Conditions and Graphs
    • Channel Dependencies
    • Message-Dependent Deadlock
    • The Consumption Assumption
    • Routing Deadlock
    • Pre-allocation or Retry
    • Retry Livelock
    • Timeouts and Watchdogs
    • Hang Debug
    • Proving Deadlock Freedom
    • Protocols Compared: Deadlock and Liveness
    • Drills: Deadlock and Liveness
  • Part 10: Reliability and Recovery20
  • Part 11: Bring-Up and Link Management10
  • Part 12: Power8
  • Part 13: Shared State and Coherence9
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 9: Deadlock and Liveness
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 9: Deadlock and Liveness
  4. Drills: Deadlock and Liveness

Part 9 · Deadlock and Liveness · All levels

Drills: Deadlock and Liveness

Interview questions, a whiteboard exercise and a ten-question checkpoint for Part 9.

On this page

    Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.

    Interview questions

    Check yourself Livelock vs deadlock: how do you tell them apart?

    Deadlock is frozen (no handshakes); livelock is busy (retries, NAKs) with no completions.

    Check yourself Name the four conditions for deadlock.

    Mutual exclusion, hold and wait, no preemption, circular wait.

    Check yourself May a slave wait for write data before accepting the address?

    Yes; the master must not wait for the address to be accepted before offering data.

    Check yourself Why must responses have their own virtual channel?

    Requests can only finish by sending responses; shared buffers let requests block them: message-dependent deadlock.

    Check yourself Why must a master always be able to accept a response?

    Deadlock-freedom arguments assume responses are consumed; reserve space at request time.

    Check yourself How does a ring network deadlock, and the fix?

    Every buffer fills with packets waiting for the next; a dateline with two VCs breaks the cycle.

    Check yourself Why does CHI use retry plus a protocol credit?

    Waiting holds resources, pre-allocation doesn't scale, plain retry can livelock; the credit guarantees the retry is accepted.

    Check yourself How long should a completion timeout be?

    Above the target's worst legitimate latency, below what the system tolerates; recover by freeing everything and discarding late responses.

    Whiteboard exercise

    Task. A 2×2 mesh connects two processors and two memory controllers. Processors send read requests; memories send read data back; memories also send snoops to processors, which answer with snoop responses. Make it deadlock-free and argue it.

    Check yourself Open a model answer

    Routing: XY on the mesh, so no routing cycles. Message classes and their dependencies: a read request may cause snoops; a snoop causes a snoop response; the memory can only send read data after the snoop responses arrive. So four classes, ordered request < snoop < snoop response < read data, each in its own virtual channel on every link and in every router and interface queue. Consumption: processors always accept read data and snoops' responses are always accepted by memories, with space reserved when the request or snoop is issued. Argument: number the resources (class, then XY order within a class) so every wait goes to a higher number; no cycle can exist. Assumptions checked with per-interface assertions; stress-test with all four agents saturating every class.

    Checkpoint: ten questions

    Check yourself 1. What distinguishes starvation from livelock?

    Under starvation the rest of the system progresses; under livelock no one completes.

    Check yourself 2. What is a wait-for graph?

    Arrows from each agent or resource to what it waits for; a cycle is a deadlock.

    Check yourself 3. Which deadlock condition does hardware usually break?

    Circular wait.

    Check yourself 4. State the general channel-dependency rule.

    The offering side never waits for the accepting side's readiness.

    Check yourself 5. How many classes for request → snoop → snoop response?

    Three.

    Check yourself 6. How do PCIe endpoints satisfy the consumption assumption?

    They advertise infinite completion credits, reserving space before each read.

    Check yourself 7. Why don't bigger buffers prevent routing deadlock?

    The cycle remains; a big enough burst still fills it.

    Check yourself 8. What does immediate retry cost as requesters grow?

    Wasted attempts about 2N − 1 per completion in the model, and unbounded waits for unlucky requests.

    Check yourself 9. What must happen to a timed-out request's tag?

    It must not be reused until a late response can no longer be matched to it.

    Check yourself 10. What must a deadlock-freedom proof include besides the graph?

    Its assumptions (consumption, dependency rules, no shared resources) with how each is checked, and liveness arguments for retries and arbiters.

    Revisit

    • 9.1 Deadlock, Livelock and Starvation

    • 9.2 Deadlock Conditions and Graphs

    • 9.3 Channel Dependencies

    • 9.4 Message-Dependent Deadlock

    • 9.5 The Consumption Assumption

    • 9.6 Routing Deadlock

    • 9.7 Pre-allocation or Retry

    • 9.8 Retry Livelock

    • 9.9 Timeouts and Watchdogs

    • 9.10 Hang Debug

    • 9.11 Proving Deadlock Freedom

    Keep going

    Next: Part 10: Reliability and Recovery. What if bits go wrong?

    Previous

    141 / 234

    Next: Part 10: Reliability and Recovery

    Up next

    Up nextPart 10: Reliability and Recovery

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Deadlock, Livelock and Starvation
    • Deadlock Conditions and Graphs
    • Channel Dependencies