Power Intent & UPF for Simulation

Chapter 10 · Section 10.1 · Low-Power GLS

Project thread — the mini-SoC has power domains (an always-on domain, switchable peripheral domains). This chapter is how GLS verifies their power intent; 10.6 debugs a power-gated, clock-gated block.

1. Why Should I Learn This?

Power-managed designs behave differently through power transitions — and a normal GLS run can't see any of it.

• UPF carries the power intent (domains, switches, isolation, retention) separate from logic.
• Power-aware GLS applies UPF to model power-down, corruption, isolation, retention.
• Without UPF, GLS assumes always-on and misses every power bug.

This opens the chapter (10.2 power-aware GLS, 10.3 isolation, 10.4 retention, 10.5 corruption, 10.6 the block).

2. Real Silicon Story — the power bug a normal GLS never saw

A design passed a full (normal, always-on) gate-level regression. In silicon, powering a domain down and back up caused an intermittent failure.

The normal GLS run assumed everything always on — it had no notion of power domains at all, so it could not model the domain going off, its logic corrupting, isolation clamping, or state being retained. The UPF described exactly that power intent; a power-aware GLS run applying the UPF reproduced the failure (a missing isolation, as it turned out, 10.3).

Lesson: a normal GLS run is always-on and blind to power behaviour. Power intent lives in the UPF, and only a power-aware run applying it can verify power transitions.

3. Concept — what UPF is and how it's used

What UPF describes (power intent):

• Power domains — regions sharing a supply that switch together.
• Supply nets & power switches — the rails and the switch cells that turn a domain on/off.
• Isolation strategy — clamp a powered-down domain's outputs to a known value (10.3).
• Level-shifter strategy — cross between different voltage domains (10.3).
• Retention strategy — save/restore state across power-down (10.4).

Where it fits (like SDF for timing):

• Separate file from the netlist — the netlist is logic, the UPF is power structure.
• Applied to the design; the same UPF drives synthesis/PnR (to insert isolation/retention/switch cells) and power-aware simulation (to model their behaviour).

Who generates / consumes it (artifact roles):

• Generated by the power architect (the power-management plan).
• Consumed by synthesis/PnR (insert cells) and power-aware GLS (model power-down, corruption, isolation, retention).

Scope (accuracy):

• Power-aware GLS verifies power intent functionally (logic correct through transitions) — not power integrity (IR-drop/energy — separate analysis).
• UPF snippets here are representative (real UPF is far larger). GLS stays dynamic; STA signs off timing (0.3).

4. Mental Model — UPF is the wiring diagram of the power grid

The netlist is the building's floor plan (rooms and connections); the UPF is the electrical wiring diagram — which rooms are on which breaker (power domain), where the switches are, and the rules for what happens when a breaker trips.

• Normal GLS reads only the floor plan — it assumes every light is always on.
• Power-aware GLS reads the wiring diagram too — so it can model flipping a breaker off (power-down), what goes dark (corruption), the safety clamps (isolation), and the battery-backed lights (retention).
• The wiring diagram (UPF) is written by the electrician (power architect) and used by construction (synthesis) and the inspector (power-aware sim).

Read only the floor plan and you'll never test what happens when a breaker flips.

5. Working Example — a representative UPF, and a domain switching

A representative UPF fragment (UPF is Tcl-based):

# UPF — REPRESENTATIVE, tool-neutral (real UPF is far larger)
create_power_domain PD_TOP                                 ;# always-on domain
create_power_domain PD_BLK -elements {u_blk}              ;# switchable block domain
 
create_supply_net  VDD    -domain PD_TOP
create_supply_net  VDD_BLK -domain PD_BLK
create_power_switch sw_blk -domain PD_BLK \
  -input_supply_port  {vin  VDD} \
  -output_supply_port {vout VDD_BLK} \
  -control_port {ctl pwr_en}                              ;# pwr_en switches PD_BLK on/off
 
# strategies (detailed later this chapter):
set_isolation      iso_blk -domain PD_BLK -clamp_value 0  ;# clamp outputs when OFF (10.3)
set_retention      ret_blk -domain PD_BLK                 ;# retain state across power-down (10.4)

Practical context (representative, tool-neutral):

gls/
  netlist/soc.vg      # logic (what the design does)
  upf/soc.upf         # power intent (how it is powered) <- THIS lesson
  sdf/soc.sdf         # timing (Ch4)
  tb/tb_soc.v         # drives pwr_en (power control) + stimulus
# Normal GLS:        netlist + sdf              -> always-on (no power behaviour)
# Power-aware GLS:   netlist + sdf + UPF        -> models power-down/corruption/isolation/retention
# Scope: FUNCTIONAL power-intent check; power integrity (IR-drop/energy) is a SEPARATE analysis.

A domain switching off and on under UPF control, as a real waveform:

6. Debugging Session — a power bug a normal GLS run can't see

7. Common Mistakes

• Relying on a normal (always-on) GLS run for power behaviour. It has no power intent.
• Thinking the UPF is part of the netlist. It's a separate power-intent file (like SDF for timing).
• Forgetting to drive power control in the power-aware testbench.
• Expecting power-aware GLS to prove power integrity. It's a functional check, not IR-drop/energy.
• Using a mismatched UPF vs the netlist (domains/cells must correspond).

8. Industry Best Practices

• Run power-aware GLS (netlist + UPF) for any power-managed design.
• Treat UPF as the power-intent source — separate from logic, like SDF for timing.
• Drive power control (switch enables) in the testbench; verify through transitions.
• Keep UPF and netlist consistent (domains, cells).
• Use separate power-integrity analysis for IR-drop/energy — not GLS.

Senior Engineer Thinking

• Beginner: "The full GLS regression passed, so the design is fine."
• Senior: "That was always-on — it can't see power domains. Where's the UPF? I need a power-aware run driving the switch enables to verify power-down/up. And that's a functional check — power integrity is separate."

The senior distinguishes always-on GLS from power-aware GLS and treats the UPF as the power-intent source.

Silicon Impact

Power management is pervasive in modern SoCs (battery life, thermal), and its bugs — missing isolation, lost retention, bad power sequencing — are catastrophic and power-transition-triggered: a domain powering down can corrupt an always-on domain, or a block can wake in a lost state, causing hangs or corruption that only appear after a power cycle (0.3). A normal, always-on GLS run is blind to all of it — a passing always-on regression gives false confidence. Power-aware GLS, driven by the UPF, is the tool that verifies the design is functionally correct through power transitions, catching these before tape-out. Understanding the UPF — the power-intent artifact — is the entry point to that entire verification, and to the rest of this chapter.

Engineering Checklist

• Ran power-aware GLS (netlist + UPF), not just always-on.
• Treated the UPF as the separate power-intent source.
• Drove power control (switch enables) and verified through transitions.
• Kept UPF and netlist consistent (domains, cells).
• Used separate analysis for power integrity (IR-drop/energy).

Try Yourself

1. Take a two-domain design and run a normal GLS — note there is no power-down behaviour (always-on).
2. Observe: driving a pwr_en does nothing to the logic.
3. Change: apply a UPF (domains + switch + isolation/retention) and run power-aware.
4. Expect: now the switchable domain corrupts when powered down and restores when powered up — power behaviour the normal run couldn't show. Confirm the UPF is what enabled it.

Power-aware simulation and UPF are EDA-tool features; the concepts (domains, switches, strategies) are standardized. The behaviour is illustrated tool-neutrally here.

Interview Perspective

• Weak: "GLS covers the whole design, including power."
• Good: "Normal GLS is always-on; power-aware GLS applies the UPF to model power domains switching off."
• Senior: "UPF carries power intent — domains, switches, isolation, level-shifter, retention strategies — separately from the netlist, like SDF carries timing. The same UPF drives synthesis (insert cells) and power-aware GLS (model behaviour). A normal always-on run can't see power transitions; only a power-aware run verifies them — and functionally, not power integrity, which is a separate analysis."

9. Interview / Review Questions

10. Key Takeaways

• A low-power design carries power intent in a UPF file — separate from the netlist (which is logic), much as SDF carries timing (4.1).
• UPF defines power domains, supply nets & switches, and strategies for isolation (10.3), level shifting (10.3), and retention (10.4).
• The same UPF drives synthesis/PnR (to insert isolation/retention/switch cells) and power-aware GLS (to model power-down, corruption, isolation, retention).
• A normal (always-on) GLS run cannot model power behaviour — only a power-aware run applying the UPF verifies the design through power transitions.
• Power-aware GLS is a functional power-intent check — not power integrity (IR-drop/energy, a separate analysis); GLS stays dynamic, STA signs off timing (0.3). Next: 10.2 — power-aware gate-level simulation.

Quick Revision

UPF = power intent (power domains, supply nets, switches, isolation/level-shifter/retention strategies), separate from the netlist (like SDF for timing). Same UPF → synthesis inserts cells + power-aware GLS models power-down/corruption/isolation/retention. Normal GLS is always-on (blind to power); only power-aware + UPF verifies power transitions — functionally, not power integrity (separate). Next: 10.2 — power-aware GLS.