Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
    • STA Foundations
    • Setup, Hold and Slack
    • Skew and Variation
    • Timing Exceptions
    • Clock Gating
      • Why Clock Gating Saves Power
      • The ICG Cell
      • Safe RTL Gating Style
      • Enable Quality Rules
      • Latch-Based Gating: Timing and Signoff
    • RTL for Timing
    • Clock Architecture
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Clock Gating
  1. Topics
  2. RTL Design
  3. Timing & Clocking
  4. Clock Gating
  5. Enable Quality Rules

Part 5 · Timing & Clocking · Intermediate

Enable Quality Rules

What the enable signal must satisfy to be gating-safe: early, registered, glitch-free, and always defined.

On this page

    Why this matters

    A late enable makes the ICG latch close before the value settles, so you get a wrong or missing clock pulse. An enable computed from the gated registers themselves can never wake the block, because the clock it needs has stopped.

    After this lesson you can: list the rules an enable must meet, compute the time left for enable logic, and say where a wake-up request must come from.

    Enable rules

    Rule

    Why

    How to follow it

    Early

    The ICG latch closes at the rising edge; the enable must settle before that

    Compute it in the previous cycle if possible

    Registered (or short logic from registers)

    A long combinational enable path can make the gating check critical

    Register the enable only if the interface allows the extra wake-up latency

    Glitch-free where it matters

    The ideal latch tracks during low and blocks high-phase changes; hardware requires stability around its closing-edge aperture

    Avoid asynchronous controls and meet library enable/test-enable setup and hold checks

    Defined at reset

    An unknown enable makes simulated clock behavior unknown; hardware behavior is not guaranteed

    Reset the enable flop or use an approved reset/test override; a known asserted override must dominate unknown controls

    Synchronous to the gated clock's source

    An enable from another clock domain is a CDC crossing

    Synchronise first; never use an unsynchronised enable

    Timing budget

    With a low-transparent latch ICG, an enable launched at a rising edge can target the next rising closing edge. This illustrative budget assumes a common 2.00 ns period and zero skew/uncertainty; actual launch/gate clock latencies and margins must be included in STA. It does not waive the minimum-delay hold check at the current closing edge.

    Enable timing for a latch ICG with a 2.00 ns clock: the enable flop launches at edge 0, clock-to-Q takes 0.35 ns, the enable logic has 1.50 ns, and the enable must meet 0.15 ns ICG setup before the latch closes at the next rising edge, where the gclk pulse starts.

    Read the bar from the launching edge on the left to the closing edge on the right. The shaded band is where the latch is open.

    • The enable leaves its flop 0.35 ns after edge 0 and then has 1.50 ns of logic.

    • It must be settled 0.15 ns before 2.00 ns, when clk rises and the latch closes. That edge is also the gclk edge the enable controls.

    • The enable may arrive while clk is still high, before the shaded band: the closed latch simply waits for the low phase. That is why the latch ICG gives the enable a full cycle.

    Item

    Value

    Clock period

    2.00 ns

    Enable flop clock-to-Q

    0.35 ns

    ICG setup to the rising edge

    0.15 ns

    Time left for enable logic

    2.00 − 0.35 − 0.15 = 1.50 ns

    A plain AND-based gate with the enable launched from a negative-edge flop gets only half a cycle: (T/2) − t_cq − t_setup = 1.00 − 0.35 − 0.15 = 0.50 ns. This is one reason to prefer the latch ICG: it gives the enable a full cycle.

    Tip

    If the enable is late, consider computing enable_next earlier or registering it. Any extra wake-up/request latency must be owned by the interface contract, with requests held or buffered until acceptance and matching data alignment. This is clock gating, not power gating: supply removal has additional isolation, retention and sequencing requirements.

    Wake-up must originate in always-on, ungated logic or another source that can change while the block is stopped. A gated-domain state machine cannot wake itself if its only progress requires the stopped clock. Reset/test overrides need their own timing and release contract; neither is exempt from applicable ICG checks. Review and test the first accepted operation at the allowed wake-up latency.

    Common mistakes

    Common pitfall

    Do not derive the enable from the outputs of the gated registers combinationally (for example en = (q != 0)). When the clock stops, q stops; if the enable depends on something that needs the clock to change, the block can never wake up.

    Interview

    “What happens if the enable arrives late?” The ICG latch closes before the enable settles, so the enable value the gate sees is stale or metastable; the effect is a wrong or missing clock pulse. STA reports it as a clock gating setup violation.

    Check yourself The clock period is 1.25 ns, clock-to-Q 0.30, ICG setup 0.12. How much combinational logic can sit between the enable flop and the ICG?

    1.25 − 0.30 − 0.12 = 0.83 ns.

    Remember

    • The enable must be early, registered or short logic from registers, defined at reset, and synchronous to the clock source.

    • With a latch ICG the enable has a full cycle: 2.00 - 0.35 - 0.15 = 1.50 ns. A negative-edge AND gate gets 0.50 ns.

    • Wake-up must come from always-on logic, not from state that needs the stopped clock.

    Rule of thumb: never derive the enable from the outputs of the gated registers.

    Keep going

    • Practice: Clock-enable synchronisation across domains

    • Interview: run a mock interview on this topic

    Related topics

    • Timing and signoff checks

    Previous

    139 / 350

    Next: Latch-Based Gating: Timing and Signoff

    Up next

    Up nextLatch-Based Gating: Timing and Signoff

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Clock Gating Saves Power
    • The ICG Cell