A CDC Sign-Off Plan for Your Block

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItBreak ItCompareScale It

1. A CDC Sign-Off Plan for Your Block
2. CompareA False Path vs a Max Delay on a Gray BusL3 Senior

   Compare a false path with a max-delay constraint on the Gray-coded pointer bus of an asynchronous FIFO.

   Reveal the Model Answer

   A false path tells STA to ignore the bus, so place and route may stretch one bit far longer than another. Gray code only promises one change per step at the source. If the skew exceeds a destination period, two steps can overlap at the receiver. A max-delay bound of about one period keeps the bits together, and STA then checks it.

   Read the diagram as text

   • Write domain: wclk · write pointer · memory
   • Read synchronizers: Pointer and ready first stages
   • Read domain: rclk · read pointer · output
   • Write synchronizers: Pointer and ready first stages

   • Write domain → Read synchronizers: Bounded Gray / ready paths
   • Read synchronizers → Read domain: Normal same-clock timing
   • Read domain → Write synchronizers: Bounded Gray / ready paths
   • Write synchronizers → Write domain: Normal same-clock timing
   • Write domain → Read domain: Stable-word protocol + data bound

   From lesson L8.1, an asynchronous FIFO: each Gray pointer path gets a delay bound, never a plain false path.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A false path tells STA to ignore the bus, so place and route may stretch one bit far longer than another. Key point 2 Gray code only promises one change per step at the source. Key point 3 If the skew exceeds a destination period, two steps can overlap at the receiver. Key point 4 A max-delay bound of about one period keeps the bits together, and STA then checks it.

   Half-Truth

   "Gray code is safe whatever the wire delays."

   It is safe only if each change reaches every bit before the next change. Unbounded skew breaks that.

   Source Lesson L8.1 and its source: Dassa and Mirsky, A New Approach to Easily Resolve the Hidden Timing Dangers of False Path Constraints on Clock Domain Crossings (DVCon), §II.A

   • Lesson L8.1Capstone: Constrain the Asynchronous FIFO
   • Lesson L2.6Clocks in SDC
3. What IfThe Max Delay That Did NothingL3 SeniorL4 Staff

   What if the SDC also declares the two clocks as asynchronous groups? Does the max-delay still apply?

   Reveal the Model Answer

   No. set_clock_groups -asynchronous acts as false paths between the two clocks. In SDC precedence a false path outranks set_max_delay, so the pointer bound is dropped. This was confirmed on OpenSTA 3.1.0. Write the bound with path-level exceptions, and check the report to show it is applied.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 No. Key point 2 set_clock_groups -asynchronous acts as false paths between the two clocks. Key point 3 In SDC precedence a false path outranks set_max_delay, so the pointer bound is dropped. Key point 4 This was confirmed on OpenSTA 3.1.0. Key point 5 Write the bound with path-level exceptions, and check the report to show it is applied.

   Tool as Truth

   "Writing the constraint is enough."

   Exceptions interact, and one can silently override another. Only the timing report shows whether the bound is applied.

   Source Synopsys, Using the Synopsys Design Constraints Format (application note), timing exception precedence; confirmed on OpenSTA 3.1.0 in lesson L2.6

4. WhyWhat Metastability Injection AddsL3 Senior

   Why add metastability injection to simulation, and what can it never prove?

   Reveal the Model Answer

   A synchronizer model that randomly adds a cycle of delay per bit shows how the design behaves when a crossing resolves late. It exposes logic that assumes an exact latency, and reconvergence that only fails with skew. It cannot prove absence: it finds only what the tests happen to reach.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A synchronizer model that randomly adds a cycle of delay per bit shows how the design behaves when a crossing resolves late. Key point 2 It exposes logic that assumes an exact latency, and reconvergence that only fails with skew. Key point 3 It cannot prove absence: it finds only what the tests happen to reach.

   Half-Truth

   "With injection on, passing regressions sign off CDC."

   Random delay finds only part of the errors. The structural and protocol checks still carry the sign-off.

   Source Mehta, ASIC/SoC Functional Design Verification (2018) ch. 8.5 CDC verification methodology (random-delay simulation models)

5. What IfResets That Cross Clock DomainsL3 Senior

   Asked if they mention resets

   What if the block's three clock domains each have their own reset?

   Reveal the Model Answer

   Each domain gets its own reset synchronizer: assert at once, release on two edges of its own clock. Then the domains leave reset at different times. Every crossing needs a rule for that window, such as a ready flag from the receiver. A reset in one domain must not corrupt a flop in another domain that is mid-capture.

   1. Assert

      The pin falls and both domains are in reset at once, with or without their clocks.

   2. A releases first

      A's clock is running, so two of its edges release A. In the lab that is edge 3.

      Follow the calls, values and waits

      1. data release: ra_q1, rst_a_n → tog_a
   3. A sends too soon

      Without the flag, A sends as soon as it is out of reset. Its toggle reaches flops that are held at 0.

      Follow the calls, values and waits

      1. data event: tog_a → t1, t2, t3
   4. B says it is awake

      The fix: B raises up_b one edge after its release, and the flag crosses into A through two flops. A sends only when ready_a is 1.

      Follow the calls, values and waits

      1. data release: rb_q1, rst_b_n → t1, t2, t3
      2. data ready: t1, t2, t3 → up_b to up_q2

   Read the diagram as text

   • rst_n pin: shared by both domains
   • ra_q1, rst_a_n: release on clk_a
   • tog_a: flips once per event
   • rb_q1, rst_b_n: release on clk_b
   • t1, t2, t3: two flops, edge detect
   • up_b to up_q2: B is awake, told to A

   • rst_n pin → ra_q1, rst_a_n: assert at once
   • rst_n pin → rb_q1, rst_b_n: assert at once
   • ra_q1, rst_a_n → tog_a: rst_a_n
   • rb_q1, rst_b_n → t1, t2, t3: rst_b_n
   • tog_a → t1, t2, t3: toggle
   • t1, t2, t3 → up_b to up_q2: up_b

   The ready flag is a register in B that crosses like any other bit: from a flop, through two flops, into A.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Each domain gets its own reset synchronizer: assert at once, release on two edges of its own clock. Key point 2 Then the domains leave reset at different times. Key point 3 Every crossing needs a rule for that window, such as a ready flag from the receiver. Key point 4 A reset in one domain must not corrupt a flop in another domain that is mid-capture.

   Misconception

   "One reset synchronizer, shared by all three domains, is enough."

   It releases on one clock. In the other domains the release is asynchronous again, so their flops can leave reset in different cycles.

   Source Cummings, Mills and Golson, Asynchronous & Synchronous Reset Design Techniques - Part Deux (SNUG Boston 2003) §6.2

   • Lesson R6.5Reset Across Clock Domains
   • Lesson R2.2Reset: Assert, Release, and What RTL Cannot Show
   • Lesson F5.6CDC and RDC with Formal
6. Break ItHow a Waived Crossing Becomes a Silicon BugL3 SeniorL4 Staff

   Break it: how does a reviewed CDC waiver still turn into a bug in silicon?

   Reveal the Model Answer

   A waiver records an assumption, such as "this bus is static during operation". The tool stops checking, but nothing enforces the assumption. Later, software writes the register while traffic runs, or an RTL change adds a new path under the old waiver. Waivers need a stated assumption, an owner and a re-check after every change.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A waiver records an assumption, such as "this bus is static during operation". Key point 2 The tool stops checking, but nothing enforces the assumption. Key point 3 Later, software writes the register while traffic runs, or an RTL change adds a new path under the old waiver. Key point 4 Waivers need a stated assumption, an owner and a re-check after every change.

   Delivery

   "Waived means reviewed, so it is safe for the life of the project."

   The waiver was true for the RTL on the day it was reviewed. Without a re-check, it hides every later change on that path.

7. What IfThe Configuration Register That Never ChangesL3 Senior

   What if the crossing is a configuration register that "never changes while the block runs"?

   Reveal the Model Answer

   Then it can cross without a synchronizer, but only if that rule really holds. Write it down as a protocol: the block is idle or in reset when the register changes. Check it with an assertion in simulation and formal. Tell the software team, because they are the ones who could break it.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Then it can cross without a synchronizer, but only if that rule really holds. Key point 2 Write it down as a protocol: the block is idle or in reset when the register changes. Key point 3 Check it with an assertion in simulation and formal. Key point 4 Tell the software team, because they are the ones who could break it.

   Half-Truth

   "Configuration is static, so it needs no CDC handling at all."

   It needs a rule instead of a synchronizer. Without an assertion, the first driver that writes it while the design runs breaks it.

   Source Mehta, ASIC/SoC Functional Design Verification (2018) ch. 8.5 CDC verification methodology (protocol verification)

8. Scale ItCDC Sign-Off on a Many-Clock SoCL3 SeniorL4 Staff

   How do you sign off clock domain crossings on an SoC with dozens of clocks?

   Reveal the Model Answer

   Start with structural analysis: define the clocks and their relationships. Then let the tool find every crossing and check that each has the right synchronizer for its type. Next comes protocol checking: each scheme's rules, such as hold times and Gray steps, become assertions in formal and simulation. Add reconvergence checks and reviewed waivers. Use metastability injection in simulation to expose designs that assume exact timing.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Start with structural analysis: define the clocks and their relationships. Key point 2 Then let the tool find every crossing and check that each has the right synchronizer for its type. Key point 3 Next comes protocol checking: each scheme's rules, such as hold times and Gray steps, become assertions in formal and simulation. Key point 4 Add reconvergence checks and reviewed waivers. Key point 5 Use metastability injection in simulation to expose designs that assume exact timing.

   Tool as Truth

   "Our regressions pass with all clocks running, so CDC is covered."

   RTL simulation never goes metastable and rarely hits the bad clock phase. CDC needs structural and protocol checks, not only passing tests.

   Source Mehta, ASIC/SoC Functional Design Verification ch. 8.5 (PDF p186-188); Sutherland, RTL Modeling with SystemVerilog ch. 8.1.6

   Wrong Altitude

   A staff-level answer that stops at "run the CDC tool".

   The interviewer wants the flow: constraints, structure, protocol, reconvergence, waiver review and who owns each step.

   • Lesson F5.6CDC and RDC with Formal
   • Lesson R6.2The Two-Flop Synchronizer and What It Cannot Carry
9. Prove ItSolve R6.2.1: The Job That Finished TwiceSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem R6.2.1