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
  • 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
    • CDC/RDC Whiteboard Framework
    • CDC/RDC Framework Drills
    • Scenario: Metastability Bug
      • The Scenario
      • Investigation Steps
      • Root Cause and Fix
      • How to Narrate It
    • Scenario: Metastability Escape in Silicon Bring-up
    • Scenario: Async FIFO Pointer Mismatch
    • Scenario: Waiver Debate
    • Scenario: RDC Waiver Under Tapeout Pressure
    • CDC/RDC Interview Q&A Bank
    • CDC/RDC Interview Q&A Bank (Expanded)
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Scenario: Metastability Bug
  1. Topics
  2. CDC & RDC
  3. CDC and RDC Interview Prep
  4. Scenario: Metastability Bug
  5. Investigation Steps

Part 10 · Interview Prep · All levels

Investigation Steps

The debug order: crossing audit, structural report, synchroniser legality, fanout, then targeted testing.

Investigate in an order that can clear suspects cheaply. Each step below either ends the hunt or narrows it; never reorder them so that an expensive theory comes before a cheap audit.

Step

Action

What it clears or finds

1. List the crossings

Every signal entering the FSM's clock from another clock, from the netlist, not the block diagram.

Clears the idea that the boundary is where you think it is.

2. Read the structural report

Each crossing's classification and synchroniser status.

Finds unsynchronised crossings and illegal synchronisers in minutes.

3. Check synchroniser legality

No logic between flops, source registered, one destination clock, per Structure and Rules.

Finds the synchroniser that is present but broken.

4. Trace the fanout

What the synchroniser output, or the raw crossing, drives: one gate or several.

Finds the divergence point where two gates sampled different values.

5. Targeted testing

Metastability-aware simulation of the suspect path plus constrained-random traffic around it.

Confirms the protocol survives either resolution; it cannot reproduce the field failure on demand.

In this scenario step 2 finds it: the interrupt enters the FSM clock with no synchroniser, and step 4 shows the raw crossing fanning out to the next-state logic and to a status register. The mechanism reference is Metastability Mechanism. Notice what never appears: weeks of bench reproduction effort, which the symptom already told you would fail.

Common pitfall

Starting with gate-level resimulation of the failing test. The failure needs an unlucky alignment the bench never hit in a month; more simulation of the same kind is the most expensive way to learn nothing new.

Check yourself The structural report is clean but the freeze persists. What is the next suspect, and why?

A legal synchroniser whose output still fans out unsafely, or a different failure mode at the same boundary: lost or duplicated events, or a second crossing the audit missed. The report checks structure, not protocol or completeness of the crossing list.

Related topics

  • Next: Root Cause and Fix

  • Violation classes

Previous

154 / 179

Next: Root Cause and Fix

Up next

Up nextRoot Cause and Fix

Sign in to save progress

Practice this lessonReport an error

See also

  • How to Narrate It