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
  • Equivalence Checking14
  • Formal Coverage and Signoff15
  • Methodology and Debug13
  • Interview Prep15
  • Capstone: A Chip-Block Verification Lab24
    • The Brief
    • Stage 1: FIFO and Handshake
    • Stage 2: Registers and Arbiter
      • Stage 2 CSR Proofs from the Table
      • Stage 2 Arbiter Grant Latency and Starvation
      • Stage 2 Reset Determinism and Connectivity
    • Stage 3: Pipeline and Equivalence
    • Stage 4: Induction and Signoff
    • Solutions
    • Appendix: Run It Yourself on an Open-Source Flow
Loading lesson

←Capstone: A Chip-Block Verification Lab
  1. Topics
  2. Formal Verification
  3. Capstone: A Chip-Block Verification Lab
  4. Stage 2: Registers and Arbiter

Part 10 of 10Part 10 of 10/Capstone: A Chip-Block Verification LabAll levels

Stage 2: Registers and Arbiter

Prove the register map from its table, derive and prove the arbiter's wait bound, and check reset determinism and a chain in pairs.

  • 3topics
  • 3lessons

Stage 2 covers the control surface: four registers with write-1-to-clear and read-only behaviour, and the arbiter that shares the datapath. The register work is table-driven: each row of the map becomes properties. The arbiter work is bound-driven: you derive the wait limit, then prove it. The stage ends with pair proofs, two copies of one design for reset determinism, and a chain whose connections come from a table. The causes of the faults are in the Solutions topic after stage 4.

Lesson

After it you can...

Stage 2 CSR Proofs from the Table

Turn the register map into a property set, check it is complete, and find three planted faults.

Stage 2 Arbiter Grant Latency and Starvation

Derive the wait bound with a model, prove it, and find three planted faults.

Stage 2 Reset Determinism and Connectivity

Prove two-copy reset determinism and a table-driven chain, each with a failing partner.

Suggested order: top to bottom. Registers first, because their proofs need no helpers; the arbiter next, because its helpers preview stage 4; pairs last, because they reuse the designs of stages 1 and 2.

The register map table yields property labels by access type. A completeness check compares them with the labels in the listing. Variants and mutants test the set and the engine checks the rows.
The table-driven loop of stage 2: the map gives property shapes, a check compares them with the listing, and variants and mutants test the set.
Check yourself Why do the register proofs need no helper assertions?

Every combination of register values is reachable by writes and set pulses, so the induction step never starts in an unreachable state. Helpers repair unreachable-state leakage; here there is none.

Related topics

  • Back: Stage 1 Covers and Mutants

  • Earlier: Register (CSR) Verification

  • Formal Glossary

PreviousNext: Stage 2 CSR Proofs from the Table

Up next

Up nextStage 2 CSR Proofs from the Table

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • The Brief
  • Stage 1: FIFO and Handshake
  • Stage 3: Pipeline and Equivalence