Mechanism and evidence
A resumed clock is not yet an accepted transfer.
Inspect four wake-up checkpoints and compare the first legal transfer with premature availability.
Checkpoint 1 · The clock is parked.
- CLOCK STATE
- parked
- VALID
- 1
- READY
- 0
- ACCEPTED
- 0
Compare all 4 checkpoints
1 · The clock is parked.
- CLOCK STATE
- parked
- VALID
- 1
- READY
- 0
- ACCEPTED
- 0
2 · The wake request arrives.
- CLOCK STATE
- wake
- VALID
- 1
- READY
- 0
- ACCEPTED
- 0
3 · The first edge restores progress.
- CLOCK STATE
- edge 1
- VALID
- 1
- READY
- 0
- ACCEPTED
- 0
4 · The second edge permits useful work.
- CLOCK STATE
- edge 2
- VALID
- 1
- READY
- 1
- ACCEPTED
- 1
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.
Confirm no new handshake is counted while the clock is stopped.
Inspect the checker Selected checkpoint pseudocode
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
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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
endtaskThe always-on reference clock provides an observation point. The 1 ps offset avoids sampling in the same simulator region as the clock edge.
Understand the failure+
A reference-clock monitor measures real gated-clock activity while protocol assertions bind idle, gate enable, wake request, and the first accepted transfer.
- REF_CLK continues; IDLE qualifiesIdle is observed before the gate closes.
- ↓ CLK_EN low; GATED_CLK stops lowEnable changes while REF_CLK is low. READY deasserts while the destination is stopped.
- ↓ WAKE_REQ held until restartThe wake request persists while GATED_CLK is low; CLK_EN is restored in the low reference-clock phase.
- ↓ GATED_CLK resumes full pulsesWake and idle clear after the restarted clock has a complete pulse.
- ↓ READY after two full rising edgesOnly then may the first transfer be accepted.
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.
- Idle detector -> ICG enable -> Gated clock
- Wake-up request -> ICG enable
- Gated clock -> READY gate
- Wake-up request + READY gate -> First accepted beat
- 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.
- Non-intrusive and usable without direct access to ICG cells.
- Scales well for broad power-intent regressions.
- 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.
- Proves that clock activity stops during the required interval.
- Can catch digitally visible glitches and cycle-level transition errors.
- 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
- 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.
- 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.
- 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.
- 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 | Responsibility | Required change |
|---|---|---|
| Monitor | Activity tracking | Count idle cycles and verify that gated-clock transitions stop. |
| Driver | Wake-up stress | Send a request exactly N cycles after idle and measure acceptance latency. |
| SVA | Pulse integrity | Check the enable protocol, disabled-clock stability, and digitally visible pulse-width violations. |
| Period tracker | Dynamic scaling | Measure the current period and update checker expectations after a legal frequency change. |
Build the checker+
Implementation patterns
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
endtaskThe always-on reference clock provides an observation point. The 1 ps offset avoids sampling in the same simulator region as the clock edge.
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
- Let the IP remain idle for the specified 32-cycle threshold and prove that its gated clock becomes stable.
- Send wake-up requests at N=0, N=1, and boundary offsets around the idle threshold.
- Toggle backpressure while the clock wakes and prove that the first beat is neither lost nor duplicated.
- Exercise legal dynamic-frequency changes and update every expected period from measured edges.
- 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.

