Clock Gating Verification: Enable Timing, CTS, Scan and Wake-Up

Clock gating suppresses selected clock pulses to reduce unnecessary switching. Proving that an enable is logically valid, that its pulses are safe, and that the block can wake again are separate obligations. An insertion message in a synthesis log does not close all of them.

VLSI Korea view: a good clock gate stops without losing required state, reopens when work needs it, and delivers a real power saving. The fraction of gated registers is only a starting observation.

This article serves RTL designers tracing a clock enable through synthesis and engineers accepting that implementation into CTS, DFT and system verification. A reproducible experiment and an explicitly assumed power calculation support two decisions: which registers to group, and which gated branches to retain.

The usual explanation correctly emphasizes reduced clock switching. Our disagreement concerns the acceptance boundary: pulse integrity, state semantics, physical timing and liveness must hold together. We call this analytical framework the Four-contract gating review.

1. An ICG stores an enable, not the application data

The example uses rising-edge registers and an ASIC-style gate with a low-transparent latch. The latch accepts the enable while the clock is low and holds it while the clock is high. ANDing that stored value with the clock prevents a mid-high change of the external enable from immediately chopping the output pulse.

The functional schematic in the public SKY130 dlclkp documentation exposes this structure. Its functional inputs are GATE and CLK, and its output is GCLK. It is not a cell with a separate test-enable input.

The latch is not a PLL. It neither synthesizes a new clock frequency nor cleans up the source's phase noise. The interval between surviving pulses can vary with the workload, but the gate does not arbitrarily redefine the period of the source pulses it passes.

Clock gating also differs from power gating. It leaves the supply connected, allowing stopped registers to retain their state under valid power conditions. It therefore does not eliminate leakage, and external inputs can still cause switching in downstream combinational logic.

A latch is not a synchronizer for an asynchronous enable. A change near the latch-closing boundary still requires the real cell's setup and hold conditions to be satisfied. Synchronization and request persistence remain separate CDC and protocol design questions.

2. Clean pulses and correct state require different observations

VLSI Korea wrote an ideal RTL experiment with a 10 ns clock period. The clock toggles every 5 ns; the enable and the stored latch value start at 0. That initialization is an experiment assumption, not a reset specification for a physical ICG.

Raising enable at 7 ns, after the first rising edge, makes a raw AND output high only during 7–10 ns. It produces a 3 ns fragment instead of the normal 5 ns high interval. The low-transparent latch path does not create a new rising edge at that instant.

Dropping the request at 12 ns means it does not survive until the next normal rising edge. Suppressing an invalid pulse is therefore different from guaranteeing that this short request becomes one accepted operation. A requester needs a persistence and acceptance rule if it expects work to execute exactly once.

The second case raises enable at 22 ns and lowers it at 38 ns. The raw AND truncates its high interval to 35–38 ns, while the latch path completes 35–40 ns. The storage that preserves pulse shape must not be confused with the protocol that preserves the meaning of work.

These are zero-delay RTL observations from Icarus Verilog. They do not measure silicon minimum pulse width, slew, PVT, jitter, library timing arcs, SDF or metastability. The 3 ns pulse is objectionable here because it fragments this experiment's normal pulse, not because that duration is a universal process limit.

A few waveforms can give false confidence. Check for extra edges between functional sampling points, preservation of the last required edge before disable, and valid data at the first edge after enable. Each failure needs separate evidence.

3. Read the representation before counting the gated registers

The public Yosys 0.46 clockgate documentation describes replacing groups that share clock and enable with an ICG and enable-less FFs. We checked that interface in the installed Yosys 0.67+post and executed a separate, deliberately small register-bank example.

The input is a 32-bit bank expressed as always @(posedge clk) if (en) q <= d;. After proc; opt, the intermediate netlist contains one $dffe with WIDTH 32. Cell-object count and stored-bit count are different quantities at this point.

Running clockgate -pos cg E:CK:Q -min_net_size 8 on that representation converted no FFs. Changing only the minimum to 1 produced one cg and one $dff with WIDTH 32. In this execution and representation, the threshold did not interpret the word width as a count of physical flop instances.

This is not a recommendation to adopt a production minimum of 1. It is a reason to inspect the current IR, enable polarity, reset and initialization representation, and mapping order. If another pass has already split words into bit-level cells, re-establish what the same threshold means.

The transformation retains 32 state bits. It removes the register-enable representation and adds a control object on the clock path. Saying that it “reduced the FF count” would incorrectly suggest reduced storage or an observed physical area saving.

Our cg is an ideal latch-plus-AND model for the phase experiment. It is not a mapped SKY130 cell or a result validated with a timing library. With enable and data changed on falling edges, the original and transformed designs matched on 200 samples with known values.

The comparison does not award a pass merely because both sides remain X in an unknown initial state. It also does not prove arbitrary asynchronous enables, interrupted reset, scan shifting or actual pulse-width violations. Explicitly bounding an experiment tells the next engineer what still needs verification.

Separately, OpenROAD clock_gating searches candidate control conditions and uses ABC simulation and SAT to establish their logical validity. Discovering a new condition is different from moving an already shared enable. Neither logical proof alone establishes routed timing.

4. Moving a gate changes both clock and enable paths

Combining a large register population behind one gate can reduce the gate count. Widely dispersed sinks, however, change downstream clock wiring, buffering and enable-routing obligations. The useful objective is a feasible physical implementation for both clock and enable, rather than the smallest gate count.

A gate nearer the root may suppress more downstream switching while serving more sinks and control requirements. A leaf gate can narrow that scope, but its upstream tree continues switching. This is a topology argument, not a formula for the optimum gate location in a specific process.

The OpenROAD CTS documentation describes -balance_levels as an attempt to keep similar tree levels across non-register cells such as gates and inverters; its default is false. Attempting level balance does not establish acceptable skew, insertion delay, enable timing and pulse checks.

After routing, the clock at the enable-launch register can arrive at a different time from the clock at the gate. Evaluate the actual library's gating setup and hold, clock transition and pulse conditions in the appropriate modes and corners. A data-path intuition alone is insufficient.

Nor should every gated clock automatically receive another create_generated_clock. Propagation and gate recognition depend on the tool, library and constraint methodology. First establish that the source clock propagates correctly, then define any necessary relationship; an extra name cannot repair a misunderstood unconstrained path.

For scan, establish where test override joins enable, whether it passes through storage, and whether the test clock reaches the sinks. The dlclkp example has no separate test pin, and using Yosys -tie_lo to tie a pin to 0 does not complete scan accessibility.

By contrast, the OpenTitan generic clock-gating primitive ORs functional and test enables before a low-transparent latch. Its source explicitly assumes a synchronized functional enable. Comparing the examples shows why a cell name alone cannot establish test-pin availability, combination position or responsibility for synchronization.

VLSI Korea view: equivalence provides evidence that sampled state is correct under its assumptions. Silicon timing, scan and wake-up must still satisfy those assumptions.

5. Calculate savings from the capacitance that actually stops

We built a small reproducible model with entirely assumed inputs: effective clock-branch capacitance of 20 pF, supply of 0.8 V, frequency of 500 MHz, and average gate/control overhead of 0.5 mW. The branch capacitance is defined on a clock charging-cycle basis.

Using Pbranch = C × V² × f gives 6.4 mW of branch dynamic power. Let d be the clock-disabled time fraction and r the fraction of branch capacitance that actually stops. The simplified steady-state net saving is d × r × 6.4 − 0.5 mW. Overhead can itself vary with workload, but it is held fixed here.

Under the full-removable-branch assumption, break-even requires a disabled fraction of 7.8125%. Halving the removable load raises that threshold to 15.625%; retaining only a quarter raises it to 31.25%. Identical idle fractions can therefore justify different decisions after gate placement and downstream load are considered.

At a disabled fraction of 25%, stopping the full modeled load saves 1.1 mW, while stopping only a quarter yields −0.1 mW net. These are not measurements of a particular design. The sensitivity analysis shows why “how much is idle?” must be followed by “what actually stopped?”

An average fraction also hides burst length. One long idle interval and many short intervals consume different amounts of qualification and restart time. Repeated opening and closing can add transition cost even when the total count of idle cycles is unchanged.

For an assumed idle opportunity of 40 cycles, subtract 10 qualification cycles and 2 restart cycles to obtain 28 stopped cycles. At a period of 2 ns, suppressed energy is 358.4 pJ; overhead charged across the whole idle interval is 40 pJ, and the separate transition cost is 50 pJ. Net energy saved is therefore 268.4 pJ.

The 10-cycle input happens to match the controller documentation discussed below, but this model is not that controller's measured power result. All physical inputs, including restart time and transition energy, are assumptions. They expose how costs can dominate short idle bursts.

To replace the assumptions, collect post-CTS capacitance, the power model at the operating voltage and frequency, the actual workload's idle-length distribution, and wake latency. Separately account for omitted leakage changes, enable-cone switching, clock-buffer internal power and power-delivery stress on restart.

Business consequences follow only after that engineering evidence exists. A verified branch saving may reduce a system power budget, but it cannot immediately be converted into cooling savings or a product-margin improvement. Other blocks may consume the released budget, execution may take longer, or a different constraint may dominate the product.

6. Write down the priorities for idle, root shutdown and wake

In the OpenTitan Earlgrey clock-manager documentation, software control of transactional clocks is a hint. The described qualification checks Idle for 10 local clocks, while power-manager root disable takes priority over local controls. Local qualification therefore cannot be generalized into protection for ongoing work during every shutdown.

The dashed WFI blocks in this original diagram are possible paths that the documentation says are not implemented in the first design. A line in a diagram is not evidence of a shipped function. This is a public design example for understanding control scope, not our experiment's implementation or its power-measurement target.

Bring that distinction into a design review by asking concrete priority questions. What wins when a local hint, hardware busy, root power request, reset and test override coincide? Is requesting a stop the same event as acknowledging that the clock has actually stopped?

The next sequence is VLSI Korea's generic review proposal: block new work, drain accepted work, request gating, then confirm that the clock has stopped. The logic that originates a restart request and the logic that opens the gate cannot both depend exclusively on the stopped clock. That arrangement cannot wake itself.

The OpenTitan DMA documentation gives an example in which a CONTROL write enables a clock gate and activity keeps it enabled. The transferable decision is to draw the boundary between accepting new work and stopping the work path, rather than prescribing the same register interface for every IP.

If a bus can issue requests while its destination clock is stopped, specify persistence or retry. Declaring idle solely because an internal queue is empty can overlook a late response or another master's request. Determine whether that risk exists from the actual protocol and its definition of outstanding transactions.

The clock-manager DV documentation separates SVA checks for controls, status and gated clocks. The allowed cycles of a sampled assertion are not an analog glitch detector's time resolution. Eventual functional response and pulse violations between sampling edges need different observations.

7. Make the implementation handoff explicit

The RTL owner supplies enable semantics, reset state and state that must survive a stop. Synthesis supplies register correspondence and actual insertion conditions; physical design checks gate placement, sinks and the routed clock/enable relationship. DFT and verification trace those same sinks in their respective modes.

For Korean fabless and IP-integration teams combining external blocks, the interface specification should explicitly identify who can restart a clock. Our 32-bit example is a starting experiment, not a substitute for a vendor IP's reset and test contracts. The existing Glitch-Free Clock MUX reference addresses source switching, while the synthesis pass-trace article helps interpret intermediate representations.

Assign evidence to each question. Use legal-input comparison and formal analysis for function; library, STA and pulse checks for phase; test-mode connectivity and coverage for scan; and protocol verification starting from a stopped state for wake. Finally confirm that the workload used for the power estimate obeys those constraints.

The counterargument matters. A small branch or one that wakes frequently may be better left ungated. A tight enable path, an efficient cell-internal enable, or dedicated FPGA clock resources can invalidate a direct application of this latch-plus-AND example.

The thesis has observable failure conditions. Redesign the gate if post-CTS removable capacitance cannot repay overhead, if the wake source sits inside the stopped cone, or if scan and timing verification invalidate the RTL assumptions. A high gated-register percentage cannot overrule those findings.

The following dates are editorial checkpoints, not announced releases: 2027-03-07 for the recorded transformation, register representation and scan connection; 2027-06-07 for idle-burst distributions and routed break-even inputs; and 2027-09-07 for root-control priority, wake reachability and library pulse constraints. The evidence cutoff is 2026-09-07.

Sources and reproducibility

Yosys 0.46 clockgate command · OpenROAD clock gating · OpenROAD clock tree synthesis · OpenTitan Earlgrey clock manager theory · OpenTitan DMA theory of operation · SKY130 dlclkp cell documentation and schematic · OpenTitan clock manager DV · OpenTitan generic clock-gating primitive

Figures: Copyright 2020 The SkyWater PDK Authors; Copyright 2024 lowRISC contributors (OpenTitan project). The OpenTitan figure includes work developed as part of the OpenTitan project (repository). Licensed under Apache 2.0. The full license and applicable NOTICE accompany the source figures in the appendix below. Rasterization and a single watermark were added; no endorsement is implied.

AI assisted public-source organization, writing and diagram production. The article received independent factual review. RTL experiments use ideal models, and physical calculation inputs are assumptions. No PDK signoff or silicon power measurement is claimed.

                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright [yyyy] [name of copyright owner]

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.