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
    • MTBF & Synchronizer Math
    • Two-Flop Synchronizers in Practice
      • Structure and Rules
      • No Logic Between Flops
      • Level and Pulse Signals
      • Simulation Models and X
    • Multi-bit CDC Hazards
    • Synchronizer Selection Guide
  • 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
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Two-Flop Synchronizers in Practice
  1. Topics
  2. CDC & RDC
  3. Metastability and Synchronizers
  4. Two-Flop Synchronizers in Practice
  5. No Logic Between Flops

Part 2 · Metastability and Synchronizers · All levels

No Logic Between Flops

Why combinational logic before the first flop or between flops is a violation, and how to fix it.

On this page

    Logic in the synchroniser path is the most common structural violation, and it takes two forms: gates between the source flop and the first synchroniser flop, and gates between the two synchroniser flops. Both destroy the guarantee the circuit is built on.

    Logic before the first flop

    A gate between the source flop and the first flop reintroduces glitches. The source flop's output is clean, but the gate's output can spike while its inputs settle, and the first flop samples those spikes as data. The synchroniser then faithfully delivers a glitch to the destination.

    design.sv
    // bad-example: a decoder output feeding the synchroniser can glitch
    always_comb ready_sel = dec_a & dec_b;   // spikes while dec_a/dec_b settle
    sync2 u_sync (.clk(clk_b), .d(ready_sel), .q(ready_b));  // captures the spike

    The fix is to register the decoded value in the source domain and cross the register output, so the synchroniser input changes at most once per source cycle.

    Logic between the flops

    A gate between the two flops is worse: it eats directly into the resolution time the first flop was promised, and its output can glitch exactly when the second flop samples. There is also a reconvergence angle: if the first flop's output fans out to two gates whose results recombine, the two paths can sample its hovering output differently and the recombined value is corrupt even though each path looked synchronised.

    The fix is structural: keep the synchroniser a self-contained two-flop module with no inputs except the source bit and no taps except the final output. Any needed logic goes after the second flop, in the destination domain, where it is ordinary synchronous logic.

    What the tools check

    Structural analysis traces the path from the first synchroniser flop to the second and flags any combinational cell on it, and likewise traces the source flop to the first flop. Review hygiene: the synchroniser lives in its own wrapper module, so there is nowhere for stray logic to hide.

    Common pitfall

    An inverter between the flops “for polarity” is still logic between the flops. Absorb the inversion into the second flop's sense or into the destination logic instead.

    Check yourself A mux selects between two source-domain signals and its output feeds one synchroniser. What is wrong, and what are the two legal fixes?

    The mux output can glitch when the select or inputs change. Either register the mux output in the source domain before the synchroniser, or synchronise the two signals separately and mux after the second flops in the destination domain.

    Check yourself The first flop's output feeds an AND gate and, separately, an inverter whose outputs later combine in an OR gate. Why is this flagged?

    The hovering output can be read differently on the two paths, so the OR can produce a value that is neither the old nor the new one. This is reconvergence on a possibly metastable signal; only the second flop's output may fan out.

    Related topics

    • Structure and Rules

    • Multi-bit CDC Hazards

    Previous

    20 / 179

    Next: Level and Pulse Signals

    Up next

    Up nextLevel and Pulse Signals

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Simulation Models and X