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
    • CDC Tool Flow
    • CDC Constraints and STA
      • How CDC Meets Timing
      • Clock Groups and False Paths
      • Bounded Delay Constraints
      • Constraint Reviews
    • CDC Waiver Policy
    • CDC Review Gate
    • CDC Signoff Dashboard
    • Formal and Simulation CDC Verification
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹CDC Constraints and STA
  1. Topics
  2. CDC & RDC
  3. CDC Signoff Methodology
  4. CDC Constraints and STA
  5. Bounded Delay Constraints

Part 7 · CDC Signoff Methodology · Advanced

Bounded Delay Constraints

Limiting skew and delay on crossing buses and pointer bits with datapath-only delay limits.

On this page

    Some crossings are safe only if all their bits arrive together. Gray-coded pointers rely on a single bit changing at a time; a crossing bus relies on its bits settling in the same destination cycle. A bounded datapath delay limit expresses that requirement: the data-path delay from source to synchroniser must stay under a stated bound, ignoring clock skew, which is handled separately.

    The concept

    A datapath-only delay limit says: however the clocks relate, this data must travel from its source register to the first synchroniser flop within this much delay. It does not check setup or hold against a clock edge; it checks the wire-and-gate delay of the data path alone. Again, this is a generic concept with per-flow syntax — signoff cares about the bound existing and being met, not about how it is spelled.

    Why Gray pointers and buses need a bound

    Crossing

    What goes wrong with skew

    What the bound guarantees

    Gray-coded pointer

    Two pointer bits changing in different cycles look like two Gray steps, and the FIFO compares a torn pointer

    All pointer bits settle within one bound, provided the source advances at most one Gray step per destination sampling window; the bound enforces simultaneity, the protocol enforces spacing

    Crossing data bus with enable

    Late bits are captured with the next enable while early bits used the last one

    The whole bus is stable before the enable is sampled

    Multi-bit control with handshake

    Skewed bits sampled across different cycles can double-trigger the receiver

    Related bits move as one across the boundary

    The bound is sized from the protocol: the data must be stable for the window the receiver assumes. A bound tighter than the protocol needs wastes implementation effort; a looser one proves nothing. The number always traces back to a protocol argument, never to a round value someone liked.

    Bounds do not replace structure

    A delay bound without a synchroniser is just a fast unsafe path, and a synchroniser without a bound on a Gray pointer is a structure whose assumption is unchecked. The two are reviewed together: the structural check confirms the synchroniser and the Gray discipline, timing confirms the bound is met, and the waiver file records the protocol argument linking them.

    Common pitfall

    Applying one bound value to every bus in the design copies a number without its argument. Each bound belongs to one crossing and one protocol window; a copied bound is an unreviewed claim wearing the clothes of a reviewed one.

    Check yourself A Gray pointer crosses with a correct two-flop-per-bit structure but no delay bound. What can still go wrong?

    Skew between pointer bits can spread one Gray step across two destination samples, so the receiver compares a torn pointer. The structure assumes near-simultaneous arrival; only a bound enforces it.

    Check yourself Who consumes the bound value, and who consumes the protocol argument behind it?

    Timing analysis consumes the bound: it checks the datapath delay against it. The CDC reviewer consumes the protocol argument: it justifies why that particular bound is the right one.

    Related topics

    • How CDC Meets Timing

    • Constraint Reviews

    • RTL: Async FIFO

    Previous

    101 / 179

    Next: Constraint Reviews

    Up next

    Up nextConstraint Reviews

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • How CDC Meets Timing