Skip to guide

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.

Watercolor of two clock domains joined by a small bridge of register blocks.
Trace the mechanism from failure signature through independent evidence, component ownership, stress, and recovery.

Mechanism and evidence

Guided verification lab

A resumed clock is not yet an accepted transfer.

Inspect four wake-up checkpoints and compare the first legal transfer with premature availability.

STEP THROUGH
STATE & OBSERVATIONTwo-edge wake contract / 1 of 4

Checkpoint 1 · The clock is parked.

CLOCK STATE
parked
VALID
1
READY
0
ACCEPTED
0
Compare all 4 checkpoints
  1. 1 · The clock is parked.

    CLOCK STATE
    parked
    VALID
    1
    READY
    0
    ACCEPTED
    0
  2. 2 · The wake request arrives.

    CLOCK STATE
    wake
    VALID
    1
    READY
    0
    ACCEPTED
    0
  3. 3 · The first edge restores progress.

    CLOCK STATE
    edge 1
    VALID
    1
    READY
    0
    ACCEPTED
    0
  4. 4 · The second edge permits useful work.

    CLOCK STATE
    edge 2
    VALID
    1
    READY
    1
    ACCEPTED
    1
1234CLOCK STATEparkedwakeedge 1edge 2VALIDREADYACCEPTED
Inspect the contract

The clock is parked.

Clock
Parked
Accepted
0

The gated clock is stable low. A held request is waiting, but there is no active edge on which to transfer.

Evidence to inspect

Confirm no new handshake is counted while the clock is stopped.

Checkpoint 1 / 4
Inspect the checker Selected checkpoint pseudocode
Conceptual checker / selected checkpoint
if (!clock_running)
  assert(accepted_transfers == 0);
Example contract & limitations

Example contract. This fixture parks the clock low and permits acceptance on the second resumed edge. VALID remains asserted for a stream of available items; payload advances only on acceptance. This digital trace does not establish physical glitch-free clock sign-off. Checkpoints show selected state changes, not equally spaced simulation cycles.

Read the complete walkthrough

Two-edge wake contract

  1. The clock is parked.. The gated clock is stable low. A held request is waiting, but there is no active edge on which to transfer. Evidence: Confirm no new handshake is counted while the clock is stopped.
  2. The wake request arrives.. The always-on control path requests restart. READY must still reflect the unavailable functional domain. Evidence: Check the wake source and READY independently.
  3. The first edge restores progress.. One resumed edge has occurred. The fixture still requires a second edge before advertising readiness. Evidence: Count resumed edges and accepted VALID && READY handshakes on the active edge.
  4. The second edge permits useful work.. The wake contract is now satisfied. VALID and READY on this active edge transfer the first item. Evidence: Check the edge, readiness, and payload together.

Premature READY

  1. The clock is parked.. The gated clock is stable low. A held request is waiting, but there is no active edge on which to transfer. Evidence: Confirm no new handshake is counted while the clock is stopped.
  2. The wake request arrives.. The always-on control path requests restart. READY must still reflect the unavailable functional domain. Evidence: Check the wake source and READY independently.
  3. READY arrives one edge too early.. The implementation advertises readiness at the first edge. With VALID high, it would accept work before this fixture permits. Evidence: Count resumed edges and accepted VALID && READY handshakes on the active edge.
  4. The second edge permits useful work.. The second edge accepts another item from the stream. Two transfers have now occurred, including the illegal early acceptance. Evidence: Check the edge, readiness, and payload together.
Related implementation: Correlate a 32-cycle idle threshold with clock activity
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.

Two-edge wake contract, checkpoint 1: The clock is parked.. Inspect the contract.
Understand the failure
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.

  1. REF_CLK continues; IDLE qualifiesIdle is observed before the gate closes.
  2. ↓ CLK_EN low; GATED_CLK stops lowEnable changes while REF_CLK is low. READY deasserts while the destination is stopped.
  3. ↓ WAKE_REQ held until restartThe wake request persists while GATED_CLK is low; CLK_EN is restored in the low reference-clock phase.
  4. ↓ GATED_CLK resumes full pulsesWake and idle clear after the restarted clock has a complete pulse.
  5. ↓ READY after two full rising edgesOnly then may the first transfer be accepted.
01idle qualifiesclock may stop02wake arrivesrequest is retained03clock restartsN-cycle deadline04ready risesfirst beat may transfer

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

Idle-to-wake clock path

The functional request, gating enable, physical clock, and READY handshake must tell one consistent timing story.

Idle detector
Declares the IP idle after the configured cycle threshold.
ICG enable
Changes only in the technology's glitch-free clock phase.
Gated clock
Becomes constant during idle and restarts without a runt pulse.
Wake-up request
Arrives N cycles after idle to stress restart latency.
READY gate
Remains low for X stabilization cycles before acceptance.
Period tracker
Updates checker timing when dynamic scaling changes frequency.
  1. Idle detector -> ICG enable -> Gated clock
  2. Wake-up request -> ICG enable
  3. Gated clock -> READY gate
  4. Wake-up request + READY gate -> First accepted beat
  5. Gated clock -> Period tracker -> Timing checkers

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.
Compare approaches

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.
Explain it in an interview

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.
Assign responsibilities

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.
Build the checker

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 the design

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.

Engineering qualifications