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
    • 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 Verification
  1. Topics
  2. Formal Verification
  3. Formal Applications

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

Formal Applications

Each application worked end to end on a running design: a table or property set, a runnable proof, its failing partner, and the counterexample read.

  • 6topics
  • 20lessons

Simulation shows a design working; this section proves it, one application at a time. Every lesson takes the same shape: a table or a small property set that is the source of truth, a runnable proof over all inputs and all reachable states, a failing partner that shows the proof can catch a real bug, and the counterexample read cycle by cycle. The designs are the running ones: the chain of pipeline, FIFO and handshake stage carries the connectivity proof, the register block carries the register proofs, the arbiter and a two-stage chain carry the progress proofs, and the FIFO, handshake stage and pipeline carry the data-integrity sets. Where no running design shows the point, a small lesson-local module is named in its lesson and used only there.

Topic

What it covers

After it you can...

Connectivity Checking

A connection table proved structurally for every mode, with generated checks

Write a connectivity table, generate its checks, and read a wrong-row counterexample.

Register (CSR) Verification

Reset values, read-only bits, write-1-to-clear and access timing from a register table

Prove a register map from its table, including the hardware-set race.

Deadlock, Livelock and Starvation Checks

Three distinct progress failures, bounded grants, fairness documented as a register

Tell the three apart, prove bounded progress, and state what fairness you assumed.

Reset Determinism and X

What two-state formal can and cannot say about X, proved with two-copy harnesses

Prove reset determinism and say exactly what an X question still needs.

Data, Handshake and Pipeline Property Sets

Full property sets for the FIFO, the handshake stage and the pipeline

Write a complete safety set with ordering, conservation and latency.

Other Applications, Honestly Scoped

Information flow, dead-state analysis, and where formal sits in CDC, low-power and CPU flows

Scope what a proof does and does not show, and point each neighbour flow at its owner.

Suggested order: top to bottom. Modules that carry a name such as chain_top or chain2 belong to their topic only: each lesson that uses one says where it is defined. Connectivity first, because its table-driven method is reused by the register topic; registers next, because every block has them; progress and X in either order after that; the datapath sets after the handshake and pipeline behaviour is familiar; the scoping lesson last, because it tells you when to stop. Each lesson states its result exactly: proven for this model under these assumptions, a counterexample at a named cycle, or inconclusive with what is missing.

A top-down flow. A table or property set goes into a proof over all values. A bug variant also goes into the same proof. The proof ends either in a proven result with its assumptions stated, or in a counterexample trace that is read as a cycle table with a root cause.
The method every application in this section follows: a table or property set is proved over all values, and a bug variant that must fail shows the check can bite; a counterexample is read as a cycle table.
Check yourself A new block needs a formal plan and you can afford three proofs. Which applications do you pick first?

Connectivity from the table, the register set from the map, and reset determinism. They catch wiring, decoding and reset bugs that simulation finds late, and each is cheap to prove.

Every application in this section is an interview story with the same spine: the table or property, the assumption it rests on, the bug variant that fails, and the cycle table of the trace. Practise telling one per topic.

Related topics

  • Up: Formal Verification course hub

  • Glossary

  • Verification First Principles: Formal Apps

PreviousNext: Connectivity Checking

Up next

Up nextConnectivity Checking

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • How to Use This Course
  • Reading Paths
  • Glossary