Skip to guide

The ground moves

State, Power & Clock Integrity

Keep the testbench and architectural model coherent while reset, power, clock, and domain boundaries change underneath in-flight work.

Choose exactly what to kill, flush, preserve, pause, isolate, restart, and prove at every lifecycle boundary.

4 connected case studiesFailure → evidence → recoveryMechanism diagrams, code, stress, and Q&A
The ground movesOne reusable contract across 4 cases.
  1. 01RUNObserve valid architectural state
  2. 02DISRUPTReset, gate a clock, or remove power
  3. 03CONTAINKill, clamp, flush, preserve, or pause
  4. 04RECOVERRelease only after initialization is valid

Reset recovery · Power gating · Clock gating · CDC DV

01 · State and power

Mid-Test Reset Orchestration

Make every testbench component survive a warm, IP-level, or subsystem reset without hanging, comparing stale traffic, or corrupting its register model.

Mechanism · failure · evidence · recovery
Epoch-aware recoveryReset is a coordinated state transition, not a pause button.

A reset observer ends the old comparison epoch, cancels traffic, clears interfaces and models, then releases stimulus only after the DUT advertises readiness.

01Run · epoch 11requests and responses in flight02Reset assertedstop sequences · drop objections03Quiescedrive idle · cancel stale responses04Rebuild · epoch 12reset RAL, predictors, and scoreboards05Resumewait for ready · start fresh traffic
Before resetExpected ID 7 · epoch 11discardAfter readyExpected ID 1 · epoch 12compare

observed transaction epoch = active scoreboard epoch → eligible for comparison

Why it matters

  • Modern SoCs reset more than once at power-on. Warm resets, IP resets, and subsystem resets can occur while the rest of the chip remains live.
  • A testbench that cannot recover from reset during traffic cannot verify high-availability or error-recovery behavior.
  • Hardware clears registers and pipelines immediately, while software testbench objects preserve state until they are told what to discard, retain, or restart.

What is difficult

  • A sequence can block forever waiting for a response that the reset erased.
  • A scoreboard can retain pre-reset expected items and compare them against unrelated post-reset traffic.
  • Reset scope is not always global. One agent may need to restart while unrelated interfaces continue running.
  • UVM phase jumping requires every component and domain to move coherently, which is difficult to debug and scale across a large team.

Failure signatures

  • A driver completes a stale handshake or leaves valid asserted across reset.
  • A sequencer keeps requests that can no longer receive responses.
  • Expected or actual queues leak across the reset boundary and create false mismatches.
  • The RAL mirror retains pre-reset values even though hardware returned non-sticky fields to defaults.
  • A DUT buffer fails to clear and releases old data after reset.

Two viable approaches—and their cost

UVM phase jumping

Force the UVM domain back to reset_phase so components reinitialize through standard phase callbacks.

Strengths
  • Uses the official UVM phase mechanism.
  • Can coordinate component reinitialization through existing reset-phase code.
Costs
  • Difficult to debug when only part of the environment jumps.
  • Can deadlock when components or domains do not move together.
  • Provides less granular control for an IP-only reset while other agents continue.

Centralized reset handler

Monitor reset as a dynamic sideband event and explicitly broadcast cleanup and restart work.

Strengths
  • Keeps reset behavior explicit and independent of the UVM phase controller.
  • Can reset one agent or subsystem without disturbing unrelated traffic.
  • Makes each component's flush, kill, preserve, and restart policy reviewable.
Costs
  • Every stateful component needs a reset cleanup or recovery method.
  • The environment must define ordering between aborting stimulus, flushing checks, and resetting mirrors.

Interview answer, built from the mechanism

  1. Treat reset as a dynamic event rather than a one-time phase. A dedicated reset handler detects the edge and tells every affected component what to do.
  2. Make the driver interruptible with fork-join_any so the reset watcher can abort a bus handshake immediately. Stop sequencer activity so no blocked request remains behind.
  3. Flush expected and actual scoreboard state that hardware discarded, and call the appropriate RAL reset type so the mirror matches hardware defaults while sticky state is preserved.
  4. Wait for reset release, perform any required reboot or initialization checks, and only then resume stimulus.

Component responsibility contract

Component responsibilities and required verification changes for Mid-Test Reset Orchestration
ComponentResponsibilityRequired change
DriverHandshake abortWrap sequence-item driving and reset detection in fork-join_any.
SequencerSequence killCall stop_sequences() to clear blocked and queued requests.
ScoreboardData flushClear expected and actual queues plus local counters and state machines.
RAL modelMirror resetCall the correct reg_model.reset() type to match hardware defaults.
Reset handlerEvent orderingBroadcast reset, coordinate cleanup, wait for release, and authorize restart.

Implementation patterns

Abort an in-flight driver operationsystemverilog
task mac_driver::run_phase(uvm_phase phase);
  forever begin
    wait (vif.rst_n === 1'b1);

    fork
      begin : drive_process
        forever begin
          seq_item_port.get_next_item(req);
          drive_item(req);
          seq_item_port.item_done();
        end
      end

      begin : reset_watcher
        @(negedge vif.rst_n);
        uvm_report_info("DRV", "Reset detected: abort drive", UVM_LOW);
      end
    join_any

    disable fork;
    cleanup_signals();
  end
endtask

task mac_driver::cleanup_signals();
  vif.valid <= 1'b0;
  vif.data  <= 'z;
  // The reset handler kills the sequence, so this path does not call item_done().
endtask

The drive loop and reset watcher race. Reset wins immediately, disable fork removes stale drive activity, and the interface returns to an idle value before the next boot.

Coordinate scoreboard, sequencer, and RAL cleanupsystemverilog
function void mac_scoreboard::flush();
  exp_fifo.flush();
  actual_fifo.flush();
  m_expected_count = 0;
endfunction

task mac_env::run_phase(uvm_phase phase);
  forever begin
    @(negedge vif.rst_n);

    agt.sqr.stop_sequences();
    scb.flush();
    reg_model.reset();

    wait (vif.rst_n === 1'b1);
    uvm_report_info("ENV", "Reset released: resume", UVM_LOW);
  end
endtask

Cleanup follows the hardware state transition: stop producers, discard predictions that no longer exist, synchronize the register mirror, then wait for reset release.

Stress recipe

  1. Fill request queues, response queues, pipelines, and DUT buffers before asserting reset.
  2. Assert reset during an active valid-ready handshake and confirm the driver drops valid without hanging.
  3. Exercise warm, IP-level, subsystem, and full reset scopes while unrelated agents remain active.
  4. Verify sticky registers retain their value while non-sticky fields and the RAL mirror return to the correct reset type.
  5. Restart traffic immediately after the allowed reboot window and reject any pre-reset data.

Follow-up questions

How do you verify registers that are sticky and are not cleared by a warm reset?

Model distinct RAL reset kinds. On a warm reset, call model.reset("WARM") so only non-sticky fields return to their warm-reset defaults while sticky mirrors retain their values.

What happens to the sequence that reset interrupted?

Usually the environment kills it. If the use case requires a resumable sequence, checkpoint its progress in a configuration object before termination and restart from that state after reset recovery.

How do you expose a DUT buffer that fails to clear on reset?

Run a dirty-reset test: fill every buffer with traffic, assert reset while state is maximally dirty, then check immediately after release that no pre-reset payload leaks out.

02 · State and power

Power Gating, Isolation, and Retention

Verify that a powered-down island is isolated safely, its retained state survives, volatile state resets, and the surrounding NoC never consumes X-state traffic.

Mechanism · failure · evidence · recovery
Power-state contractIsolate first, power down second; restore before reconnecting.

The checker correlates the power controller, isolation boundary, retained state, volatile state, and externally visible outputs across every legal transition.

01Isolateclamp outputs02Savecapture retained state03Power offisland may become X04Power onwait for pwr_good05Restorereload retained state06Releaseremove isolation
Always-on domainPower controllerisolate · save · gate · restoreIsolation boundarySAFE_CLAMPblocks X propagationSwitchable islandretained + volatile stateOFF

!pwr_good → isolated outputs equal the specified clamp value · retained state returns only after restore

Why it matters

  • SoCs remove power from idle GPU, NPU, and other islands while the rest of the chip remains active.
  • Isolation must prevent an unpowered block's floating or unknown outputs from contaminating live logic.
  • Retention registers must preserve architectural state so the block can resume without a full cold boot.

What is difficult

  • Powered-down outputs can become X and poison monitors, scoreboards, or neighboring logic.
  • The testbench must distinguish volatile state that resets from retention state that remains powered.
  • Power-up includes a recovery interval in which clocks or power may be present but traffic is not yet valid.
  • A logic-only power model is fast but cannot prove the implementation of physical isolation and level-shifter cells.

Failure signatures

  • An output is not clamped while its source island is off.
  • A monitor samples X-state traffic and corrupts checking state.
  • The RAL model resets retention mirrors even though silicon retained the values.
  • A scoreboard clears transactions that should pause across a legal sleep interval.
  • A dirty power-down during a burst hangs the shared NoC.
  • Traffic resumes before Reset-Done or Initialization-Complete.

Two viable approaches—and their cost

UPF-aware simulation

Inject Unified Power Format intent so the simulator models supply states, isolation, retention, and level shifting.

Strengths
  • Most realistic representation of implementation power intent.
  • Can expose physical isolation, retention, and level-shifter integration bugs.
Costs
  • Adds significant simulation cost.
  • Requires labor-intensive power-intent setup.
  • X-propagation failures can be difficult to debug.

Power-aware UVM agent

Use power-status sidebands to pause sampling and apply explicit retention-versus-volatile model policy.

Strengths
  • Runs quickly in ordinary logic simulation.
  • Lets each agent and RAL block define its power-state behavior explicitly.
  • Prevents expected off-state X values from corrupting the scoreboard.
Costs
  • Depends on the accuracy of the testbench power model and sideband signals.
  • Cannot detect a missing or incorrectly connected physical isolation cell by itself.

Interview answer, built from the mechanism

  1. Focus on the isolation-retention boundary. A power-aware monitor gates functional transaction decoding as soon as the island turns off, while boundary assertions continue observing clamp values and legal power sequencing.
  2. Use assertions or UPF-aware simulation to prove that outputs are clamped to their required safe values while the island is unavailable.
  3. Split the RAL model into volatile and retention regions. Reset volatile mirrors during a power cycle while leaving retention mirrors untouched.
  4. After power-up, enforce a blanking window until Reset-Done or Initialization-Complete, then compare retained state and resume paused flow.

Component responsibility contract

Component responsibilities and required verification changes for Power Gating, Isolation, and Retention
ComponentResponsibilityRequired change
MonitorIsolation awarenessGate functional transaction publication when pwr_good is low, but keep power-state and clamp observation active.
RAL modelState preservationDefine retention fields and bypass their reset during power cycles.
ScoreboardFlow controlPause during power-down without clearing transactions that must survive.
Assertions or UPFClamp proofCheck every island output reaches its specified safe value while off.

Implementation patterns

Gate functional sampling while keeping boundary proof activesystemverilog
task power_aware_monitor::run_phase(uvm_phase phase);
  forever begin
    @(posedge vif.clk);

    if (!vif.pwr_good) begin
      handle_power_down_cleanup();
      wait (vif.pwr_good);
      wait (vif.init_complete);
    end
    else if (vif.valid && vif.ready) begin
      sample_transaction();
    end
  end
endtask

The functional monitor uses the externally visible availability contract to decide when transactions are meaningful. Separate always-on assertions continue checking isolation clamps and power sequencing throughout the off interval.

Reset volatile mirrors and preserve retentionsystemverilog
virtual function void update_ral_mirror(bit power_up);
  if (power_up) begin
    reg_model.volatile_block.reset("POWER");
    // reg_model.retention_block remains unchanged.
  end
endfunction

The model applies power-cycle defaults only to state that silicon actually loses.

Prove off-state output clampssystemverilog
property p_outputs_clamped_while_off;
  @(posedge aon_clk) disable iff (!por_n)
    !pwr_good |-> (island_outputs == SAFE_CLAMP_VALUE);
endproperty

assert property (p_outputs_clamped_while_off);

An always-on clock observes the boundary and proves that an unavailable island cannot drive an unsafe value into live logic.

Stress recipe

  1. Start a multi-beat transfer, remove island power before the final beat, and prove that isolation prevents X propagation.
  2. Check every output's required 0 or 1 clamp value throughout the off interval.
  3. Write distinct patterns into volatile and retention registers before sleep, then compare both classes after wake.
  4. Vary the blanking interval and reject all traffic until Reset-Done or Initialization-Complete.
  5. Run the fast power-aware UVM checks in broad regressions and use UPF-aware tests for structural signoff scenarios.

Follow-up questions

How do you verify isolation cells specifically?

Use SVA or UPF-aware checks to require the specified clamp value on every island output whenever the power-gate state says the island is unavailable, independent of its internal logic.

How do you handle X-state on the bus during power-up?

Apply a monitor blanking window for a defined number of cycles and keep sampling disabled until Reset-Done or Initialization-Complete proves that the interface is valid.

What is a dirty power-down test?

Remove power in the middle of a burst. Verify immediate isolation, legal handling of the interrupted transaction, and continued progress on the global NoC.

03 · State and power

Clock Gating and Wake-Up Integrity

Correlate idle state with real clock activity, prove glitch-free gating, and verify that a sleeping interface wakes before accepting its first data beat.

Mechanism · failure · evidence · recovery
Sleep and wake integrityNo runt pulses. No accepted work before the clock returns.

A reference-clock monitor measures real gated-clock activity while protocol assertions bind idle, gate enable, wake request, and the first accepted transfer.

01idle qualifiesclock may stop02wake arrivesrequest is retained03clock restartsN-cycle deadline04ready risesfirst beat may transfer

request ∧ !clock_active → hold request stable until clock_active ∧ ready

Why it matters

  • Clock gating is a primary dynamic-power mechanism because stopping register clocks eliminates unnecessary switching.
  • A design can pass every functional test while a broken ICG path leaves an IP permanently active, wasting power and creating thermal or battery-life failures.
  • The wake-up handshake must hide clock-tree restart latency so the first request or data beat is not lost.

What is difficult

  • Ordinary functional traffic is gating-blind when the clock never stops.
  • A black-box activity monitor detects gross power leaks but may miss cycle-level enable and pulse-integrity failures.
  • White-box assertions give precise ICG visibility but require stable access to internal hierarchy.
  • Dynamic frequency scaling changes the expected period while clock checkers are running.

Failure signatures

  • The gated clock continues toggling after the IP satisfies its idle threshold.
  • An unlatched enable creates a runt pulse shorter than a legal clock period.
  • Only part of a register bank captures a malformed pulse, corrupting state.
  • A runt pulse pushes a receiving flip-flop toward metastability.
  • The slave raises READY before the gated clock has stabilized and loses the first beat.
  • A fixed-period checker falsely fails after a legal dynamic frequency change.

Two viable approaches—and their cost

Toggle-rate monitor

Count clock activity relative to idle state or data handshakes over an observation window.

Strengths
  • Non-intrusive and usable without direct access to ICG cells.
  • Scales well for broad power-intent regressions.
Costs
  • Primarily detects gross failures such as a clock that never gates.
  • Can miss individual runt pulses and precise enable-protocol violations.

Active-clock assertions

Bind SVA to the ICG output and enable path to prove the digital enable protocol, stable off-state behavior, and simulator-visible pulse-width rules.

Strengths
  • Proves that clock activity stops during the required interval.
  • Can catch digitally visible glitches and cycle-level transition errors.
Costs
  • Requires white-box access to internal RTL or bound interfaces.
  • Hierarchical binding and implementation-specific ICG naming can complicate reuse.

Interview answer, built from the mechanism

  1. Use activity-to-clock correlation. Track the IP's idle state and, after its specified idle threshold, verify that the gated clock no longer changes.
  2. Bind SVA at the ICG boundary to check the digital enable protocol and simulator-visible pulse width. The enable may only change in the phase permitted by the clock-gating architecture. Then use the intended integrated clock-gating structure, implementation checks, and timing analysis to sign off physical pulse integrity.
  3. Stress wake-up by issuing a request a configurable number of cycles after idle. READY must remain low until the clock tree is stable, then the first beat must transfer exactly once.
  4. For dynamic clock scaling, measure edge-to-edge time and update the expected period used by every timing checker.

Component responsibility contract

Component responsibilities and required verification changes for Clock Gating and Wake-Up Integrity
ComponentResponsibilityRequired change
MonitorActivity trackingCount idle cycles and verify that gated-clock transitions stop.
DriverWake-up stressSend a request exactly N cycles after idle and measure acceptance latency.
SVAPulse integrityCheck the enable protocol, disabled-clock stability, and digitally visible pulse-width violations.
Period trackerDynamic scalingMeasure the current period and update checker expectations after a legal frequency change.

Implementation patterns

Correlate a 32-cycle idle threshold with clock activitysystemverilog
task clk_gating_checker::run_phase(uvm_phase phase);
  logic gated_clk_previous;
  gated_clk_previous = vif.gated_clk;

  forever begin
    @(posedge vif.ref_clk);

    if (vif.idle_for_32_cycles) begin
      #1ps;
      if (vif.gated_clk !== gated_clk_previous)
        uvm_report_error("PWR_ERR", "Clock toggled during IDLE");
    end

    gated_clk_previous = vif.gated_clk;
  end
endtask

The always-on reference clock provides an observation point. The 1 ps offset avoids sampling in the same simulator region as the clock edge.

Require a stable disabled clocksystemverilog
property p_clock_stable_while_disabled;
  @(posedge vif.ref_clk) disable iff (!vif.rst_n)
    !vif.clk_en |=> $stable(vif.gated_clk);
endproperty

assert property (p_clock_stable_while_disabled);

The production-safe invariant is stability, whether the implementation parks the gated clock at 0 or 1. A separate technology-specific assertion can require the actual park level.

Stress recipe

  1. Let the IP remain idle for the specified 32-cycle threshold and prove that its gated clock becomes stable.
  2. Send wake-up requests at N=0, N=1, and boundary offsets around the idle threshold.
  3. Toggle backpressure while the clock wakes and prove that the first beat is neither lost nor duplicated.
  4. Exercise legal dynamic-frequency changes and update every expected period from measured edges.
  5. Inject enable transitions near unsafe clock phases and detect simulator-visible malformed pulses; separately review ICG inference, implementation checks, and timing for physical sign-off.

Follow-up questions

What is a runt pulse, and why is it dangerous?

It is a clock pulse shorter than the legal period, commonly created when an enable is not latched safely. It can violate flip-flop timing or toggle only part of a register bank, producing metastability or corrupted state.

How do you verify dynamic clock scaling?

Use a real-time period tracker that measures consecutive clock edges and publishes the new expected period to all dependent checkers after each legal frequency transition.

How do you handle clock wake-up latency?

Verify the handshake contract: a request may arrive while the slave is gated, but READY stays low for the specified X-cycle stabilization interval and the first data beat is accepted only afterward.

04 · Temporal integrity

CDC & RDC Dynamic Verification

Combine structural CDC analysis with dynamic handshake assertions, Gray-pointer checks, reset stress, and randomized clock phase to expose cross-domain protocol failures.

Mechanism · failure · evidence · recovery
Two clocks, one protocolStress phase; prove the digital containment contract.

Clock phase variation can expose bad assumptions, while assertions and structural analysis prove Req–Ack stability, bundled data, Gray-pointer transitions, and reset release.

CLK_AREQCLK_BACK
Source domainREQ + stable DATADestination FF1may resolveDestination FF2synchronized levelProtocolACK releases DATA

Jitter ≠ analog metastability model · structural CDC + constraints + MTBF remain required

Why it matters

  • Modern SoCs run blocks at different frequencies to save power. Clock Domain Crossing and Reset Domain Crossing failures are major silicon-respin risks.
  • Ideal zero-delay RTL simulation cannot reproduce analog metastability, so dynamic verification must target the digital protocols that contain and tolerate it.
  • A crossing can fail randomly in the lab when an asynchronous signal is sampled during a transition or when one domain exits reset while another still holds stale state.

What is difficult

  • A standard UVM monitor samples on a clock edge, while a real asynchronous signal might arrive 5 ps before that edge and violate setup or hold.
  • Full analog metastability behavior is not practical to simulate at SoC scale.
  • Control CDC uses synchronizers or a request-acknowledge handshake, while datapath CDC often needs a stable-data protocol, FIFO, or DMUX.
  • Asynchronous FIFO pointers must cross in Gray code, with only one bit changing per pointer step.
  • Reset-glitch protection must reject pulses shorter than a clock cycle without masking a valid reset.

Failure signatures

  • Request changes again before acknowledgement and the destination loses or duplicates an event.
  • The data bus changes while a CDC handshake is active.
  • A binary pointer, rather than its Gray-coded form, is connected to an asynchronous FIFO synchronizer.
  • A short reset glitch escapes the reset synchronizer and partially resets the destination domain.
  • A waking block samples stale data from a domain that remains in reset.
  • RTL assumes a fixed phase relationship between nominally asynchronous clocks.
  • A short control pulse is never observed in the destination domain.

Two viable approaches—and their cost

SVA protocol checkers

Assert Req-Ack-Stable and Gray-pointer invariants at the digital protocol boundary.

Strengths
  • Proves that control and bundled data remain stable for the required handshake.
  • Provides a precise failure cycle and signal-level contract.
Costs
  • Does not prove the physical synchronizer implementation.
  • Cannot reproduce analog metastability resolution.

Clock jitter and skew injection

Vary the phase relationship between asynchronous clocks and sample crossings at difficult alignments.

Strengths
  • Exposes RTL that accidentally depends on a fixed phase relationship.
  • Stresses reset release and handshake latency across many alignments.
Costs
  • Requires a flexible clock-control agent and reproducible phase logging.
  • Still models digital timing, not transistor-level metastability.

Interview answer, built from the mechanism

  1. I use a hybrid assertion-and-stress strategy. Structural CDC and RDC are handled by lint or formal tools, while UVM verifies dynamic handshake integrity.
  2. Assertions require Request to remain stable until Ack, bundled Data to remain stable throughout the active handshake, and asynchronous FIFO Gray pointers to change by one bit per step.
  3. A clock-control agent varies source and destination phase and adds jitter so simulation visits difficult sampling alignments. Reset tests independently release domains and inject narrow reset glitches.
  4. For datapath CDC, I verify the selected architecture: stable bundled data before Valid crosses, or FIFO/DMUX behavior with correct pointer and reset-epoch handling.

Component responsibility contract

Component responsibilities and required verification changes for CDC & RDC Dynamic Verification
ComponentResponsibilityRequired change
SVA checkerHandshake and pointer integrityCheck Req-Ack-Stable, bundled-data stability, and one-bit Gray-pointer transitions.
CDC interfaceDomain-specific samplingDefine source and destination clocking blocks with explicit input and output skews.
Clock controllerPhase stressVary the asynchronous clock phase and add reproducible jitter.
Reset agentReset-glitch stressInject pulses shorter than one clock and coordinate independent domain release.

Implementation patterns

Gray-pointer one-bit transition assertionsystemverilog
// Gray Code pointers only change by 1 bit at a time
property p_gray_code_continuity(ptr);
  @(posedge clk)
  $changed(ptr) |->
    ($countones(ptr ^ $past(ptr)) == 1);
endproperty

assert_wr_ptr_gray: assert property (
  p_gray_code_continuity(vif.wr_ptr_gray)
);

assert_rd_ptr_gray: assert property (
  p_gray_code_continuity(vif.rd_ptr_gray)
);

The XOR identifies changed pointer bits and $countones requires exactly one when the pointer changes. The property is applied to both write and read Gray pointers.

Bundled-data stability assertionsystemverilog
property p_data_stability_during_cdc;
  @(posedge clk_src)
  disable iff (!vif.rst_n)
  $rose(vif.req) |->
    $stable(vif.data_bus) until_with (vif.ack);
endproperty

assert_cdc_data_stable: assert property (
  p_data_stability_during_cdc
)
else
  `uvm_error(
    "CDC_DATA",
    "Data bus toggled during active handshake!"
  );

After Request rises, the bundled data must remain stable through the cycle in which Ack completes the transfer.

Source and destination clocking blockssystemverilog
interface cdc_if(input clk_src, input clk_dest);
  logic req;
  logic ack;
  logic [31:0] data;

  // Source Clocking Block: Driving logic
  clocking src_cb @(posedge clk_src);
    default input #1step output #100ps;
    output req, data;
    input ack;
  endclocking

  // Destination Clocking Block: Sampling logic
  clocking dest_cb @(posedge clk_dest);
    default input #200ps output #1step;
    input req, data;
    output ack;
  endclocking
endinterface

The source drives req/data and samples ack; the destination samples req/data and drives ack. The slide labels 100 ps source output skew and 200 ps destination input skew.

1 GHz destination clock with ±50 ps jittersystemverilog
initial begin
  clk_dest = 0;
  forever begin
    // 1000ps base period (1GHz)
    // Add +/- 50ps of jitter every loop iteration
    int jitter = $urandom_range(0, 100) - 50;
    #((1000 + jitter) / 2.0 * 1ps);
    clk_dest = ~clk_dest;
  end
end

Every half-cycle uses a 1,000 ps nominal full-period value plus a random integer from -50 ps through +50 ps before division by two.

Stress recipe

  1. Run structural CDC/RDC analysis first and retain its crossing inventory for dynamic test selection.
  2. Randomize the source-destination phase across many alignments around the nominal 1 GHz, 1,000 ps destination period.
  3. Add the source example's integer jitter range of -50 ps through +50 ps and log the seed and phase.
  4. Drive Request and hold Data stable until Ack; inject a data toggle during the handshake as a negative test.
  5. Advance asynchronous FIFO read and write pointers and require one-bit Gray transitions.
  6. Sweep reset pulses around the specified minimum input width. Verify the documented assertion behavior, synchronized deassertion in each domain, and narrow-pulse rejection only when an explicit glitch filter is part of the contract.
  7. Release source and destination resets independently and check that no stale data or previous-reset pointer escapes.
  8. Exercise both a control handshake and a datapath FIFO or DMUX crossing.

Follow-up questions

Why do we use Gray code for asynchronous FIFOs?

Gray code changes one bit per adjacent value. That limits ambiguity when a pointer crosses domains. The source describes the sampled pointer as at most one step away, which helps prevent false FIFO full or empty decisions.

How do you verify reset-glitch protection?

Start from the reset contract. Sweep pulses around the specified minimum assertion width, verify asynchronous assertion when that is the architecture, and prove deassertion is synchronized independently in every destination domain. Only expect narrow-pulse rejection when the design contains an explicit, specified glitch filter or primitive with that guarantee.

What is datapath CDC, and how is it different from control CDC?

Control CDC commonly uses a synchronizer or handshake. Datapath CDC often uses a FIFO, a DMUX, or bundled-data protocol. Verify that Data is stable before Valid or Request crosses and remains stable for the receiving contract.

Continue the evidence chain

Connect cases to system strategy.

Move from focused failure modes to a complete plan, executable architecture, coverage model, regression system, and sign-off argument.