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
      • Why Pulses Need Help
      • Toggle Synchronizer
      • Pulse Stretching and Edge Detect
      • Spacing and Rate Limits
    • Handshake Protocols Across Domains
    • Async FIFO CDC
    • CDC Protocol Verification
  • 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

‹Pulse Synchronizers
  1. Topics
  2. CDC & RDC
  3. CDC Protocols and Handshakes
  4. Pulse Synchronizers
  5. Spacing and Rate Limits

Part 3 · CDC Protocols and Handshakes · All levels

Spacing and Rate Limits

The minimum gap between pulses, what breaks when it is violated, and how to enforce it.

On this page

    Why it matters

    Every pulse scheme has a spacing rule, and spacing violations are the most common pulse-synchroniser bug found at signoff. The mechanism is silent: the destination reports fewer events than the source sent, the counts drift apart over hours of operation, and no flag is ever raised. The rule must therefore be enforced by construction and checked by an assertion, not left to software discipline.

    The rule

    Consecutive source pulses must be spaced by at least the synchroniser latency plus the detection time at the destination, typically three or more destination clock periods. Two destination periods is only the sampling floor: it lets a change be registered, but a toggle at exactly that spacing can still merge with the previous one while the synchroniser is settling. The design document states the gap in destination periods, never in nanoseconds alone, so the rule survives clock-frequency changes.

    Violation

    What the destination sees

    How it shows up

    Two toggles inside one destination period

    One flip, or none

    Lost event; event counts diverge

    Two stretched pulses overlapping

    One long level, one edge

    Lost event; same symptom

    Sustained rate above the limit

    A fraction of events arrive

    Throughput shortfall under load, missed interrupts

    Enforcing it by design

    The robust source refuses to accept a new pulse until the minimum gap has elapsed. A compact guard is a countdown that blocks re-arming:

    design.sv
    1
    2
    3
    4
    5
    // snippet: source-side spacing guard; pulse_in is the raw event,
    // pulse_out the qualified pulse that drives the toggle or stretch logic.
    // parameter MIN_GAP: minimum source cycles between accepted pulses.
    // if (!rst_n) grant <= 1; else if (pulse_in && grant) grant <= 0;
    //   (counter reloads MIN_GAP and counts down; grant = (counter == 0))

    Where the event source cannot be throttled (a free-running interrupt line), accumulate instead: count events in a source-domain counter and cross the count with Gray code, or queue them in a FIFO. The protocol verification topic shows the assertions that pin the spacing rule and the stress scenarios that break undisciplined sources.

    What the checks look for

    A structural review asks three questions: is there a stated minimum gap, is it expressed in destination periods, and is there an assertion plus a test that violates the gap on purpose to prove the check has teeth. A testbench that only ever sends well-spaced pulses proves nothing about the guard.

    Common mistakes

    Common pitfall

    Deriving the gap from typical clock rates instead of worst-case ones. If the destination clock can slow down (power modes, debug clocks, divided clocks), the gap in nanoseconds must cover the slowest destination period the design supports.

    Interview

    State the rule as synchroniser latency plus detection time (typically three or more destination periods, with two as the sampling floor), then volunteer the enforcement: a source-side guard, an assertion, and a negative test. Interviewers also like the escape hatch: when the source cannot be throttled, count events instead of sending them one by one.

    Check yourself The destination runs between 25 MHz and 100 MHz. The source emits pulses every 60 ns. Is the spacing safe?

    At 25 MHz the destination period is 40 ns, so even the two-period sampling floor is 80 ns and the typical three-period rule is 120 ns: a 60 ns gap violates the rule at the slow corner. Either widen the gap above 120 ns or qualify the design to the fast corner only.

    Related topics

    • Assertions for protocols

    • RTL: CDC Protocols

    Previous

    34 / 179

    Next: Handshake Protocols Across Domains

    Up next

    Up nextHandshake Protocols Across Domains

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Pulses Need Help
    • Toggle Synchronizer