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
    • CDC Waiver Policy
    • CDC Review Gate
      • Pre-Tapeout Gates
      • Review Checklists
      • Signoff Readiness
      • Handoff to Physical Design and DFT
    • 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 Review Gate
  1. Topics
  2. CDC & RDC
  3. CDC Signoff Methodology
  4. CDC Review Gate
  5. Review Checklists

Part 7 · CDC Signoff Methodology · Advanced

Review Checklists

Checklists for design, verification, and signoff owners at the CDC review gate.

On this page

    Checklists turn the gate from a meeting into a procedure. Each owner answers only their own questions, in writing, before the review — so the meeting spends its time on disagreements rather than discoveries. The three lists below are the minimum; projects add rows, never remove them without recording why.

    The checklists

    Owner

    Checks

    Design

    Every crossing has an intended synchronising structure; sources are registered with no logic before the first flop; protocols (handshake, Gray, FIFO) match the data type; boundary crossings name their owning side

    Verification

    Protocol assertions are written and passing; metastability-injection checks cover the synchronisers; quasi-static assumptions have assertions that re-check every regression; coverage includes stall and back-pressure behaviour

    Signoff

    Setup reviewed against the architecture; structural runs cover the full hierarchy at the signed-off revisions; every finding is fixed or waived with evidence; constraints reviewed against the inventory; dashboard history is continuous across revisions

    How the lists are used

    1. Each owner completes their list in writing before the review and attaches the evidence references.

    2. Items that fail become defects or waiver requests with owners and dates — never silent acceptances.

    3. Disagreements between lists (design claims a protocol the verification list cannot find) are the review agenda.

    4. The completed lists are stored with the signoff record, so a later question about any crossing has a written answer.

    The reset crossing rows deserve a cross-check with the reset material: reset strategies for synchroniser structure and reset domain crossing for the failure modes the checklists guard against.

    Tip

    Read the checklists aloud at the review, one row at a time, with the evidence on screen. Silent pre-reading lets hard rows pass on nods; reading aloud forces each claim to survive contact with its evidence.

    Check yourself Design claims a handshake crossing; verification has no assertions for it. Whose checklist fails, and what happens next?

    Both: design's structure claim lacks verification's proof, and verification's list lacks the assertions. The review records a defect — write the assertions or waive with other evidence — with an owner and a date.

    Check yourself Why must the completed checklists be stored with the signoff record?

    Because signoff is a claim about evidence, and the lists are the index to that evidence. A later ECO, audit, or failure analysis needs the written answers, not memories of the meeting.

    Related topics

    • Pre-Tapeout Gates

    • Handoff to Physical Design and DFT

    • RTL: Reset Domain Crossing

    Previous

    108 / 179

    Next: Signoff Readiness

    Up next

    Up nextSignoff Readiness

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Handoff to Physical Design and DFT