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.
A reference-clock monitor measures real gated-clock activity while protocol assertions bind idle, gate enable, wake request, and the first accepted 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.
- 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.
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.
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. |
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 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.