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
    • Writing Properties That Can Fail and Say Something
    • Assumptions as a Contract
      • Assumption Taxonomy and Ownership
      • Assume Versus Assert by Side
      • The Assumption Review
      • Turning Assumptions into Assertions
    • Abstraction and Complexity
    • Assume-Guarantee and Black Boxes
    • Reusable Property Sets
  • Proof Engines and Convergence23
  • Formal Applications20
  • Equivalence Checking14
  • Formal Coverage and Signoff15
  • Methodology and Debug13
  • Interview Prep15
  • Capstone: A Chip-Block Verification Lab24
Loading lesson

←Property Development and Constraints
  1. Topics
  2. Formal Verification
  3. Property Development and Constraints
  4. Assumptions as a Contract

Part 3 of 10Part 3 of 10/Property Development and ConstraintsAll levels

Assumptions as a Contract

Treat every assumption as a promise with an owner and a discharging assertion, place each rule on the right side of an interface, review the list, and convert it at integration.

  • 4topics
  • 4lessons

Every proof is relative: it holds under its assumptions, and an assumption is a promise that something else keeps. A wrong assumption does not make a proof fail. It makes the proof pass while the chip fails. This topic turns assumptions into a managed contract: six kinds with owners, the rule that places each assumption and assertion on its side of an interface, a review that probes for over-constraint, and the conversion that checks at integration what each block assumed.

Lesson

After it you can...

Assumption Taxonomy and Ownership

Classify an assumption by kind, owner, discharge target and lifetime, and show it is load-bearing.

Assume Versus Assert by Side

Place a rule on the right side of an interface and see both wrong placements fail.

The Assumption Review

Run the review: ledger, discharge, covers, mutation and the share of input space removed.

Turning Assumptions into Assertions

Convert a block-level assumption into an assertion on the neighbour and find the bug the unit proof hid.

Suggested order: top to bottom. The taxonomy gives the vocabulary, the side rule removes most placement errors, the review is the gate, and the conversion checks at integration what the review lists.

Three boxes in a column: an assumption in block A, the same rule asserted on block B, the proof run on B.
Each assumption in one block is discharged by an assertion on the block that drives it, and that assertion has its own proof run.
Check yourself A proof passes in seconds and its assumption list is empty. Is that good news?

Suspicious. Either the block really is self-contained, or the rules it depends on were never written down. Check what the design assumes about reset, inputs and configuration.

Defend an assumption list on a whiteboard: every row needs an owner, a discharging assertion and a lifetime. An assumption with no owner is a rumour; one with no discharging assertion is a hope.

Related topics

  • Up: Property Development and Constraints

  • Verification First Principles: Assumptions and Over-Constraint

PreviousNext: Assumption Taxonomy and Ownership

Up next

Up nextAssumption Taxonomy and Ownership

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • Writing Properties That Can Fail and Say Something
  • Abstraction and Complexity
  • Assume-Guarantee and Black Boxes