CDC Engineer Guide

Write a parameterized 2-FF synchronizer in SystemVerilog.

Requirements:
- Parameter: STAGES (default=2, can be set to 3 for higher MTBF)
- Parameter: WIDTH (default=1, for multi-bit use only if data is quasi-static)
- Source domain: clk_src (data changes in this domain)
- Dest domain: clk_dst (output synchronized to this clock)
- Active-low asynchronous resets for both domains: rst_src_n, rst_dst_n

Critical synthesis constraints (add as RTL attributes):
- (* dont_touch = "true" *) on the synchronizer chain
- (* async_reg = "true" *) on every synchronizer FF
- Set false path from source FF to first sync FF in SDC

After the RTL, generate:
1. The SDC constraint: set_false_path -from [get_cells ...src_ff] -to [get_cells ...sync_ff1]
2. Explanation: why must we prevent synthesis from merging or optimizing the sync chain?
3. When should STAGES=3 be used instead of STAGES=2?

Write a reset synchronizer in SystemVerilog with async assert and synchronous deassert.

Design requirements:
- Input: async_rst_n (active-low, asynchronous from any domain)
- Clock: clk_dst (destination domain clock)
- Output: sync_rst_n (synchronized active-low reset for clk_dst domain)

Behavior required:
- Assert (go low): immediately when async_rst_n goes low (asynchronous)
- Deassert (go high): synchronized to clk_dst after 2 FF stages

RTL must include:
- (* async_reg = "true" *) on both sync FFs
- (* dont_touch = "true" *) on the sync chain
- Correct use of asynchronous sensitivity list: @(posedge clk or negedge async_rst_n)

Also explain:
1. Why does async assert prevent missing reset?
2. Why does synchronous deassert prevent reset removal metastability?
3. What happens if you use purely synchronous reset instead?

Design a pulse synchronizer for crossing a single-cycle pulse from CLK_A to CLK_B.

Constraint: CLK_B may be slower than CLK_A (worst case 2:1 frequency ratio).
A direct pulse synchronizer will miss pulses if CLK_B is slower.

Use the toggle synchronizer approach:
1. Source domain: convert pulse → level toggle (XOR with feedback)
2. 2-FF sync: synchronize the toggle to CLK_B
3. Dest domain: detect edge on synchronized toggle → regenerate pulse

Write the complete RTL for all 3 stages.

After the RTL:
1. What is the minimum pulse width at CLK_A for this to work reliably?
2. What is the latency in CLK_B cycles before the output pulse appears?
3. Can this synchronizer handle back-to-back pulses? What is the minimum gap?
4. Add an SVA assertion: output pulse width is exactly 1 CLK_B cycle

Calculate the MTBF (Mean Time Between Failures) for my synchronizer design.

Technology parameters (from PDK characterization):
- Metastability resolving time constant (tau): 0.08ns  (7nm FinFET)
- Metastability window (T0): 0.15ps
- Synchronizer resolution time (Tw): 0.85ns  (clk period - setup - hold)
- Launch clock frequency (fc): 1000 MHz
- Capture clock frequency (fd): 800 MHz

MTBF formula: MTBF = e^(Tw/tau) / (T0 * fc * fd)

Steps I want shown:
1. Calculate e^(Tw/tau) with your values
2. Calculate denominator T0 * fc * fd
3. Final MTBF in seconds, then convert to years
4. Does this meet a 10-year mission life target?
5. How much would Tw need to increase to achieve 100-year MTBF?
6. Impact of adding a 3rd synchronizer stage: how much does Tw increase?
   (Assume extra FF adds 0.8ns of resolution time)

Perform a CDC review of this asynchronous FIFO implementation.

Check all of these specifically:

1. POINTER ENCODING
   - Are write and read pointers Gray-coded before crossing clock domains?
   - Is the binary-to-Gray conversion correct? (gray = bin ^ (bin >> 1))
   - Are pointers one bit wider than needed for address to enable full/empty detection?

2. SYNCHRONIZATION
   - Are Gray pointers synchronized with a 2-FF chain in the destination domain?
   - Are the synchronizer FFs attributed correctly (dont_touch, async_reg)?

3. FULL/EMPTY FLAGS
   - Full flag: generated in write domain using synchronized read pointer
   - Empty flag: generated in read domain using synchronized write pointer
   - Are both flags registered (not combinational)?

4. RESET
   - Are both write and read domains reset independently?
   - Do both pointer sets reset to 0 correctly?
   - Is there a potential reset ordering issue?

5. MEMORY ARRAY
   - Is the RAM read/write in the correct clock domain?

Report issues as: [CRITICAL / WARNING / INFO] — description — fix

[PASTE ASYNC FIFO RTL HERE]

Explain in detail why Gray code pointers are necessary in an async FIFO.

Walk me through this specific failure scenario:
- 4-deep FIFO, 2-bit binary pointer
- Write pointer transitions from 01 (decimal 1) to 10 (decimal 2)
- Both bits change simultaneously: MSB 0→1, LSB 1→0
- The read clock samples the pointer mid-transition

Show me:
1. What binary value could the read domain sample during the transition?
2. Why this causes incorrect full/empty flag generation
3. How Gray code avoids this: only 1 bit changes per count step
4. Verify the 4-bit Gray code sequence:
   0000, 0001, 0011, 0010, 0110, 0111, 0101, 0100 ... (show full 16-entry table)
5. One exception: at wraparound (1111 → 0000), does any multi-bit transition occur?
6. Why is the pointer 1 bit wider than the address width?
   (e.g., 4-deep FIFO uses 3-bit pointer, not 2-bit)

Generate a SpyGlass CDC waiver for this violation and justify it technically.

SpyGlass violation:
Rule: W_CDC_UNSYNC
Signal: u_config/cfg_mode[3:0]
Source clock: CLK_APB (100 MHz)
Dest clock: CLK_CORE (1 GHz)
Violation: 4-bit bus crossing without synchronizer

Context:
- cfg_mode[3:0] is a configuration register written by APB during boot only
- Once written, it is static for the entire mission mode (never toggles during CLK_CORE operation)
- Software guarantee: APB write completes before CLK_CORE starts processing

Justify and generate:
1. Technical justification (why this crossing is functionally safe)
2. The condition under which this waiver is valid
3. SpyGlass waiver syntax in the .waiver file format
4. What simulation or formal check could provide additional confidence?
5. Risk level: LOW / MEDIUM / HIGH and why
6. What would happen if someone violates the software write-before-start guarantee?

I have 12 SpyGlass CDC violations. Help me classify each as REAL BUG or WAIVABLE.

Violation 1: scan_en crossing from TEST_CLK to CLK_CORE
  (scan_en is static during mission mode)

Violation 2: u_data_bus[31:0] direct crossing CLK_A → CLK_B (no synchronizer, no FIFO)
  (changes every cycle in CLK_A)

Violation 3: por_rst_n crossing from POWER_ON_CLK to CLK_CORE
  (used as async reset, deassert synchronized separately)

Violation 4: u_status_reg[7:0] crossing CLK_CORE → CLK_APB
  (read-only status register, CLK_APB polls at much lower rate)

Violation 5: interrupt signal crossing CLK_CORE → CLK_CPU
  (single-cycle pulse, no synchronizer)

For each violation:
1. REAL BUG or WAIVABLE — with confidence level (high/medium/low)
2. If real bug: what is the correct fix?
3. If waivable: what is the justification and any remaining risk?
4. Overall: how many of my 12 violations are likely real bugs vs false positives?
   (Give a typical industry percentage for SpyGlass CDC false positive rate)

I need to cross a 32-bit data bus from CLK_A (500 MHz) to CLK_B (250 MHz).
Help me choose the right CDC structure.

Compare these approaches for my 32-bit bus:

1. Gray code encoding
   - When is this appropriate?
   - What data patterns can be Gray-coded efficiently?

2. Async FIFO (Gray pointer sync)
   - Best for streaming data (continuous flow)
   - Overhead: 2 synchronizer chains, FIFO memory

3. Handshake protocol (req/ack)
   - Best for bursty/infrequent transfers
   - Latency cost: 4+ destination cycles per transfer

4. DMUX (enable qualification / data qualifier)
   - Data is stable — only enable pulse crosses domains
   - Risk: data must be truly stable for entire sync latency

5. MCP (Multi-Cycle Path with data qualification)
   - SDC exception to relax timing

For MY case (32-bit, 500→250 MHz, streaming pipeline data, latency tolerance: 4 cycles):
- Which structure do you recommend and why?
- What is the exact throughput and latency of each option?
- Write the RTL skeleton for your recommended approach.

Write a complete 4-phase handshake CDC module in SystemVerilog.

Interface:
- CLK_A domain: req_a (pulse), data_a[31:0] (stable when req_a asserted), ack_a (done)
- CLK_B domain: valid_b (data available), data_b[31:0] (captured data), ready_b (accept)

4-phase protocol:
- Phase 1: CLK_A asserts req (level), holds data stable
- Phase 2: CLK_B detects req (via 2-FF sync), captures data, asserts ack (level)
- Phase 3: CLK_A detects ack (via 2-FF sync), deasserts req
- Phase 4: CLK_B detects req deasserted, deasserts ack

Requirements:
- All crossing signals must use 2-FF synchronizers
- RTL must be deadlock-free (no state where both sides wait forever)
- Add an SVA assertion: data_b must remain stable from valid_b until ready_b

After the RTL:
- What is the minimum transfer time in CLK_A cycles?
  (function of CLK_A and CLK_B frequencies)
- What is the maximum safe data rate for 500 MHz / 250 MHz clocks?

Review the CDC architecture for this design and identify all crossings.

Clock domains:
- CLK_CORE: 1 GHz (CPU + datapath)
- CLK_APB:  100 MHz (configuration bus)
- CLK_MEM:  800 MHz (DDR controller)
- CLK_USB:  480 MHz (USB PHY)
- TEST_CLK: 10 MHz (scan, gated off in mission)

Known crossings:
1. CLK_APB → CLK_CORE: config registers (write during boot, read any time)
2. CLK_CORE → CLK_APB: status/interrupt registers (read by APB any time)
3. CLK_CORE → CLK_MEM: memory request bus [31:0] + valid
4. CLK_MEM → CLK_CORE: memory response bus [63:0] + valid
5. CLK_USB → CLK_CORE: USB receive FIFO (streaming, 480→1000 MHz)
6. CLK_CORE → CLK_USB: USB transmit FIFO (streaming, 1000→480 MHz)

For each crossing:
1. Recommended CDC structure (2-FF sync, async FIFO, handshake, qualified)
2. Risk level: which crossings are highest risk?
3. SpyGlass CDC rule that would flag each if not handled
4. Any reconvergence risks (same data captured by two paths in same domain)?

Explain CDC reconvergence and review my design for this issue.

Background: I have two signals crossing from CLK_A to CLK_B separately:
- Signal X: crosses via 2-FF synchronizer → sync_x
- Signal Y: crosses via 2-FF synchronizer → sync_y
- Both X and Y originate from the same FF in CLK_A domain

In CLK_B domain: logic computes: result = sync_x AND sync_y

Question:
1. What is CDC reconvergence and why is it dangerous here?
2. Even though both signals are individually synchronized, why can result be wrong?
3. Draw the timing: show a scenario where sync_x = 1 and sync_y = 0 simultaneously
   when X and Y were actually equal in CLK_A domain
4. What are the three safe ways to fix this reconvergence?
   - Option A: use one synchronizer for both (pack into a bus)
   - Option B: use async FIFO
   - Option C: add a data qualifier / enable signal
5. Does SpyGlass catch reconvergence? What rule number?

Write a complete SpyGlass CDC analysis Tcl script for my design.

Design info:
- Top module: soc_top
- Clocks: CLK_CORE (1GHz), CLK_APB (100MHz), CLK_MEM (800MHz), CLK_USB (480MHz)
- Asynchronous inputs: por_rst_n, scan_en, test_mode
- Clock gating cells: ICGX (integrated clock gate)

Script must configure:
1. Waiver file path: ./cdc_waivers.sgdc
2. Clock definitions (cdc_clock, period, uncertainty)
3. Async port declarations
4. CDC rule set: enable W_CDC_UNSYNC, W_CDC_NO_SYNC, W_CDC_RECONVERGE
5. Set synchronizer recognition: recognize standard 2-FF cell sequence
6. Run analysis and output report
7. Filter out violations below severity: MEDIUM

Also generate a starter .sgdc waiver file template with:
- Waiver syntax for scan_en (static, safe to waive)
- Waiver syntax for por_rst_n (async reset, properly handled)
- Comment field format for reviewer sign-off

Review my CDC signoff status. Is this design ready for tapeout?

Current CDC status:
- SpyGlass CDC: 0 unwaived violations
- Total waivers: 14 (all documented in cdc_waivers.sgdc)
- Waiver categories: 6x scan signals, 3x power-on resets, 5x quasi-static config
- Async FIFOs: 4 instances — all reviewed and Gray pointer verified
- Synchronizers: 22 instances — all have dont_touch + async_reg attributes
- Reset synchronizer: 3 instances — all async-assert sync-deassert verified
- MTBF: all synchronizer paths > 100 years at mission life conditions
- Formal CDC: not run (SpyGlass only)
- Functional simulation: CDC paths exercised in 3 directed tests

Questions:
1. Is the waiver count (14) reasonable for a design this size?
2. Should I run formal CDC (JasperGold/Meridian) in addition to SpyGlass?
3. Is simulation alone sufficient for CDC verification?
4. Any checklist item I am missing?
5. GO / NO-GO recommendation with justification.

I have an intermittent functional failure that I suspect is a CDC issue. Help debug.

Symptom:
- The chip works correctly most of the time
- Rarely (1 in ~10,000 runs), the configuration register u_cfg/mode_reg[3:0]
  reads back with 1 bit inverted after being written
- The failure is non-deterministic and temperature/voltage sensitive
- SpyGlass shows clean CDC for this signal (waived as quasi-static)

Context:
- mode_reg is written by APB at 100 MHz at startup
- mode_reg is read by CLK_CORE at 1 GHz
- The waiver justification: "APB write completes before CLK_CORE reads"
- There is no explicit hardware handshake — it relies on software ordering

Root cause analysis:
1. Is this likely a metastability failure? Why does it appear rarely?
2. Does temperature/voltage sensitivity point to metastability? What is the physics?
3. Could the software ordering guarantee be violated? Under what conditions?
4. What is the real fix? (not a waiver)
5. How do I reproduce this in simulation? (hint: add random metastability injection)
6. Write the RTL fix: add a proper 2-FF synchronizer for mode_reg