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
      • Register Table to Properties
      • W1C, Read-Only and Reset-Value Proofs
      • Access Timing and Error Responses
      • Hardware Set versus Software Clear Races
    • 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 Applications
  1. Topics
  2. Formal Verification
  3. Formal Applications
  4. Register (CSR) Verification

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

Register (CSR) Verification

Proving a register map from its table: reset values, access types, timing, and the hardware-set race.

  • 4topics
  • 4lessons

Every block has registers, and register bugs are integration bugs in miniature: a read-only bit that accepts writes, a clear that sets, a reset value one revision out of date, an error returned a cycle late. This topic proves the four-register control block from its register table: reset values, read-write behaviour, write-1-to-clear, read-only discipline, access timing with wait states, and the race between a hardware event and a software clear in the same cycle. The table is the source of truth throughout.

Lesson

After it you can...

Register Table to Properties

Turn a register table into a property set with a generator and see a table typo fail.

W1C, Read-Only and Reset-Value Proofs

Write sampling-correct properties for clear-on-write and read-only bits, and kill each family with a bug.

Access Timing and Error Responses

Prove same-cycle error responses and wait-state-safe properties.

Hardware Set versus Software Clear Races

Specify a race priority, prove it, and cover the collision.

Suggested order: top to bottom. The table lesson builds the method, the access-type lesson is the heart of it, timing extends it to bus behaviour, and the race lesson handles the one cycle every register team argues about. For the map itself and the simulation-side flow, see the register-map and register-model lessons linked below.

A top-down diagram. The register table feeds a property generator, which emits reset-value checks and access-type and isolation checks. Both families run together as one proof.
A register table generates reset-value checks and access-type checks (including isolation) that run as one proof.
Check yourself A new register is added to the map. What changes in the proof?

One table row, then regenerate: the reset, access-type and isolation checks for that register appear automatically, and the proof reruns. Nothing is hand-edited, so nothing is forgotten.

Related topics

  • RTL: CSR Contract and Address Map

  • RTL: Generated Register Workflow

  • UVM: Why Register Model

PreviousNext: Register Table to Properties

Up next

Up nextRegister Table to Properties

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • Connectivity Checking
  • Deadlock, Livelock and Starvation Checks
  • Reset Determinism and X