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

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • CDC/RDC Glossary
  • CDC/RDC Metrics Reference
  • CDC/RDC Interview Prep
  • CDC/RDC Signoff Cheatsheet
  • Clock Domains and Failure Modes8
  • Metastability and Synchronizers16
  • CDC Protocols and Handshakes16
    • Pulse Synchronizers
    • Handshake Protocols Across Domains
    • Async FIFO CDC
    • CDC Protocol Verification
      • Assertions for Protocols
      • Formal Protocol Checks
      • Coverage and Stress
      • Metastability-Aware Simulation
  • Reconvergence and Gray Coding16
  • Reset Domain Crossing16
  • Architecture and Design Rules16
  • CDC Signoff Methodology24
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹CDC Protocol Verification
  1. Topics
  2. CDC & RDC
  3. CDC Protocols and Handshakes
  4. CDC Protocol Verification
  5. Formal Protocol Checks

Part 3 · CDC Protocols and Handshakes · All levels

Formal Protocol Checks

What formal methods prove for crossing protocols and the assumptions they need.

On this page

    Why it matters

    Simulation shows the protocol working on the cases it tried; formal methods prove the property on all cases within the stated assumptions. For handshakes and FIFO pointers the state space is small enough that proof is practical, which makes it the strongest evidence in a signoff review, provided the assumptions are written down and themselves reviewed.

    What formal proves

    Property

    What the proof covers

    Typical bound or scope

    No lost or duplicated pulse

    Every source event yields exactly one destination event

    All spacings down to the stated minimum gap

    Handshake data integrity

    Captured word equals the offered word on every transfer

    All phase alignments of the two clocks

    FIFO no overflow or underflow

    Writes never exceed depth, reads never precede writes

    All pointer and flag combinations reachable from reset

    Deadlock freedom

    Every offered transfer eventually completes

    With the fairness assumption that both clocks keep running

    The assumptions the proof needs

    1. Clock behaviour: both clocks run within their specified ranges for the whole proof. A stopped or gated clock is outside the proof unless modelled.

    2. Reset behaviour: the proof starts from the reset state the design actually reaches, with both sides reset together as the reset lesson requires.

    3. Single-step pointers: Gray pointers advance by one only; jumps are excluded by assumption and must be excluded by design too.

    4. Synchroniser abstraction: the proof typically treats the synchroniser as a bounded-latency delay (settling within N cycles), not as a metastable element. Metastability itself is argued separately (see the next lessons).

    5. Environment discipline: the source obeys the spacing or stability rules; the proof shows the protocol correct given a disciplined environment, and the assertions lesson shows the environment checked.

    Common mistakes

    Common pitfall

    Proving the protocol under assumptions the design does not enforce, then citing the proof as absolute. A proof that assumes single-step pointers says nothing about a design whose pointer can reload. Review the assumptions with the same care as the proof result.

    Interview

    Name one property, one assumption behind it, and how you would check the assumption. That three-part answer is what interviewers score.

    Check yourself A formal proof shows a handshake never drops a word, assuming the source holds data stable until ack. What remains to verify?

    That the real source actually holds data stable: the assumption needs its own assertion (the data-stability checker of the previous lesson) bound in simulation.

    Related topics

    • Assertions for protocols

    • RTL: CDC verification

    Previous

    44 / 179

    Next: Coverage and Stress

    Up next

    Up nextCoverage and Stress

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Metastability-Aware Simulation