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

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Glossary
  • Metrics Reference
  • Formal Cheat Sheet
  • Formal Foundations19
  • Properties and SVA16
  • Property Development and Constraints19
  • Proof Engines and Convergence23
  • Formal Applications20
    • Connectivity Checking
    • Register (CSR) Verification
    • Deadlock, Livelock and Starvation Checks
      • Deadlock, Livelock, Starvation Defined
      • Arbiter Grant Latency Proof
      • Progress in a Handshake Chain
      • Fairness Assumptions for Progress Proofs
    • Reset Determinism and X
    • Data, Handshake and Pipeline Property Sets
    • Other Applications, Honestly Scoped
  • Equivalence Checking14
  • Formal Coverage and Signoff15
  • Methodology and Debug13
  • Interview Prep15
  • Capstone: A Chip-Block Verification Lab24
Loading lesson

←Formal Applications
  1. Topics
  2. Formal Verification
  3. Formal Applications
  4. Deadlock, Livelock and Starvation Checks

Part 5 of 10Part 5 of 10/Formal ApplicationsAll levels

Deadlock, Livelock and Starvation Checks

Three distinct progress failures, told apart structurally and temporally, and proved absent on the arbiter and a handshake chain.

  • 4topics
  • 4lessons

Nothing moves, something moves but never finishes, or everything moves except one victim. These are three different failures with different proofs, and confusing them wastes weeks: a deadlock needs a cycle in the wait-for graph, livelock needs activity without completion, starvation needs one requester denied while others are served. This topic defines all three once, proves bounded grants on the round-robin arbiter, finds a wait cycle in a two-stage handshake chain structurally before proving progress temporally, and writes down exactly what fairness was assumed.

Lesson

After it you can...

Deadlock, Livelock, Starvation Defined

Define the three precisely and argue circular wait on a graph.

Arbiter Grant Latency Proof

Prove one-hot, no-phantom and bounded-wait grants for four requesters.

Progress in a Handshake Chain

Find a wait cycle structurally and prove bounded progress.

Fairness Assumptions for Progress Proofs

State, bound, document and check the fairness a progress proof rests on.

Suggested order: top to bottom. Definitions first, because every later lesson uses them; the arbiter proof, which is the worked starvation case; the chain lesson, which adds the structural step; fairness last, because it tells you what the first three assumed. The safety-versus-liveness background and the liveness-engine view sit in their own lessons.

A top-down graph with two boxes and two arrows. The stage 1 valid box waits for the stage 2 ready box, and the stage 2 ready box waits for the stage 1 valid box, closing a cycle.
A wait-for graph with a cycle: stage 1 raises valid only after stage 2 raises ready, and stage 2 raises ready only after stage 1 raises valid, so neither ever moves.
Check yourself The system is silent: no grants, no transfers, no errors. Deadlock, livelock or starvation?

Deadlock until shown otherwise: no progress is possible anywhere. Livelock would show activity, starvation would show other requesters being served. Confirm on the wait-for graph, then read the temporal trace.

Related topics

  • Protocol FP: Deadlock, Livelock, Starvation

  • Protocol FP: Proving Deadlock Freedom

  • Formal: Liveness versus Safety

PreviousNext: Deadlock, Livelock, Starvation Defined

Up next

Up nextDeadlock, Livelock, Starvation Defined

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • Connectivity Checking
  • Register (CSR) Verification
  • Reset Determinism and X