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-Aware Partitioning
      • Choosing Domain Boundaries
      • Register at the Boundary
      • Minimising Crossings
      • Crossing Inventory
    • Clock Gating and Muxing
    • Interface and IP Rules
    • Quasi-Static Signals and Configuration
  • CDC Signoff Methodology24
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹CDC-Aware Partitioning
  1. Topics
  2. CDC & RDC
  3. Architecture and Design Rules
  4. CDC-Aware Partitioning
  5. Crossing Inventory

Part 6 · Architecture and Design Rules · Intermediate

Crossing Inventory

Keeping a table of every crossing; a template table; why it is the base of signoff.

On this page

    Signoff cannot check what it cannot list. The crossing inventory is the table of every signal that changes clock domain: what it is, where it goes, how it is synchronised, and who owns it. The structural report, the waiver list, and the review agenda are all views of this table.

    The template

    One row per crossing (a bus or a protocol group counts as one row with its width noted). Keep it in version control beside the RTL and update it with every interface change.

    Column

    What to write

    ID

    A stable identifier, for example CDC-014, used in waivers and review notes.

    Signal

    Hierarchical name and width.

    Source domain

    Clock and reset of the launching flop.

    Destination domain

    Clock and reset of the receiving logic.

    Type

    Level, pulse, multi-bit, stream, or reset.

    Protocol

    Two-flop synchroniser, toggle, handshake, FIFO, Gray, or reset synchroniser, with the module name.

    Owner

    The engineer who answers for this row.

    Status

    Clean, waived (with waiver ID), or open.

    Example rows (illustrative)

    ID

    Signal

    Source → destination

    Type / protocol

    Status

    CDC-014

    dma_done

    clk_fast → clk_slow

    Pulse / toggle synchroniser

    Clean

    CDC-015

    cfg_word[31:0]

    clk_slow → clk_fast

    Multi-bit / handshake with stable data

    Clean

    CDC-016

    adc_stream

    clk_adc → clk_sys

    Stream / async FIFO, depth 16

    Clean

    CDC-017

    dbg_clk_static

    clk_dbg → clk_sys

    Quasi-static / qualified capture

    Waived (W-003)

    Why it is the base of signoff

    • Structural analysis is reconciled against it: every tool finding maps to a row, and every row without a finding is still reviewed for protocol correctness.

    • Waivers attach to rows, never to the design as a whole, so a waiver cannot silently cover a new signal.

    • The review walks the table top to bottom; an empty status column is an open signoff item.

    • Diffing the table between releases shows exactly which crossings changed and need re-verification.

    How to keep it honest

    Generate the first draft from the structural report rather than by hand, so nothing is forgotten, then have each owner confirm their rows. Re-generate on every release and treat added rows as new signoff work, not paperwork.

    Common pitfall

    An inventory filled in once and never diffed rots within one release: new crossings arrive without rows and the table stops matching the design. Generate it from the tool output every time, or it becomes fiction.

    Check yourself A waiver says “all crossings between clk_a and clk_b are Structurally clean”. What is wrong with it?

    It is not attached to inventory rows, so nobody can tell which signals were actually checked, and any new signal between those clocks inherits the waiver silently. Waive listed IDs with evidence, one row at a time.

    Related topics

    • Minimising Crossings

    • Documenting Crossings

    Previous

    82 / 179

    Next: Clock Gating and Muxing

    Up next

    Up nextClock Gating and Muxing

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Choosing Domain Boundaries
    • Register at the Boundary