Power-Aware Gate-Level Simulation

Chapter 10 · Section 10.2 · Low-Power GLS

Project thread — the mini-SoC's switchable domains are verified with power-aware GLS. This lesson is how the run models power; 10.3–10.5 detail isolation, retention, and corruption; 10.6 ties them together.

1. Why Should I Learn This?

Power-aware GLS is a different kind of run — knowing what it models is how you read its results.

• It corrupts powered-down logic to X (models loss of state/drive) — power-driven X-injection.
• It applies isolation and retention from the UPF.
• It reveals missing isolation/retention and sequencing bugs a normal run can't.

This makes the UPF (10.1) actionable and frames the rest of the chapter.

2. Real Silicon Story — the corruption X read as a logic bug

A power-aware run showed a block's outputs going X on power-down. An engineer filed it as a logic bug and started debugging the block's logic.

There was no logic bug. The block's domain had powered down, so power-aware GLS corrupted its logic to X — the correct modelling of an unpowered domain (no state, no drive). The X was expected; the real question was whether isolation was clamping that X before it reached powered domains (10.3). Reading the corruption X as a logic bug sent debugging in the wrong direction entirely.

Lesson: a corruption X on power-down is power-down modelling, not a logic bug — the domain is unpowered. The real questions are about isolation, retention, and sequencing.

3. Concept — what power-aware GLS models

The core difference (vs normal GLS):

• Normal GLS = always-on (10.1).
• Power-aware GLS = normal GLS + UPF → models power.

What it models on a power transition:

• Power-down → corruption: the simulator drives the powered-down domain's logic to X — modelling the loss of state and drive in unpowered gates.
• Isolation: the domain's outputs are clamped to a known value so corruption doesn't leak (10.3).
• Retention: selected flops save state (on a retention supply) and restore it on power-up (10.4).
• Power-up → restore: the domain repowers; retained state returns, non-retained state is X until reloaded.

Power-driven X-injection (the analog of 8.5):

• Just as a timing violation injects X via a notifier (8.5), a power-down injects X via corruption — both are modelling mechanisms, and both Xs propagate (Chapter 6).

What it reveals (normal GLS cannot):

• Missing isolation — corruption escaping a powered-down domain into an ON domain.
• Missing/incorrect retention — state lost across power-down.
• Sequencing bugs — isolate/save/switch out of order (10.5).
• Corruption crossing domain boundaries.

Scope (accuracy):

• Corruption-to-X models an unpowered domain (real silicon: undefined) — a corruption X is expected on power-down, not a bug.
• Functional check — not power integrity (10.1). GLS stays dynamic; STA signs off timing (0.3).

4. Mental Model — the simulator flips the breaker and watches

Power-aware GLS is an inspector who can actually flip the breakers (normal GLS can only look at an always-lit building).

• Flip a breaker off → that wing goes dark (corruption X) — expected, it's unpowered.
• The safety clamps (isolation) should stop the dark wing's wires from shorting the lit wing (corruption leaking).
• The battery-backed fixtures (retention) should remember their settings for when power returns.
• Flip the breaker on → the wing relights; battery-backed settings return, the rest starts blank (X until reset/reload).

The dark wing (corruption X) isn't a fault — it's what off looks like. The inspector's job is checking the clamps, batteries, and switching order.

5. Working Example — corruption, isolation, and the reveal

What power-aware GLS models on a transition (representative):

# Power-aware GLS on a power-down/up cycle (tool-neutral, driven by UPF 10.1):
#   pwr_en=1 : domain ON  -> logic computes normally
#   pwr_en=0 : domain OFF -> simulator CORRUPTS domain logic to X (loss of state/drive)
#              -> ISOLATION clamps domain OUTPUTS to clamp_value (no X leak, 10.3)
#              -> RETENTION flops SAVE selected state (10.4)
#   pwr_en=1 : domain powers up -> RETENTION restores; non-retained state = X until reloaded
# corruption X on power-down is EXPECTED (models unpowered) -- NOT a logic bug.

// A powered-down domain output WITHOUT isolation leaks X into the ON domain — REPRESENTATIVE
assign on_domain_sig = off_domain_out & enable;   // off_domain_out = X (corrupted) -> leaks X
// WITH isolation, off_domain_out is clamped (e.g. to 0) when OFF -> no leak (10.3)

Practical context (representative, tool-neutral):

# Reading a power-aware run (tool-neutral):
#   corruption X inside a powered-DOWN domain ......... EXPECTED (models unpowered)
#   X escaping into an ON domain ...................... missing/late ISOLATION (10.3) -> BUG
#   state lost after power-up (should persist) ........ missing/incorrect RETENTION (10.4) -> BUG
#   corruption before isolation/save ................. SEQUENCING bug (10.5)
#   note: FUNCTIONAL power-intent check, not power integrity (IR-drop/energy) -- separate

Corruption on power-down, isolated vs leaking, as a real waveform:

6. Debugging Session — a corruption X mistaken for a logic bug

7. Common Mistakes

• Reading a corruption X as a logic bug. It models an unpowered domain (expected).
• Debugging the block's logic instead of isolation/retention/sequencing.
• Expecting a normal GLS run to reveal power bugs. It's always-on (10.1).
• Ignoring X leaking into an ON domain. That's a real missing-isolation bug (10.3).
• Forgetting power-aware GLS is functional, not power integrity (10.1).

8. Industry Best Practices

• Run power-aware GLS and read its log to separate modelling from bugs.
• Treat corruption X on power-down as expected — check isolation/retention/sequencing instead.
• Verify X doesn't leak into ON domains (isolation, 10.3).
• Verify needed state survives power-down (retention, 10.4).
• Verify power sequencing (isolate/save/switch order, 10.5).

Senior Engineer Thinking

• Beginner: "The block went X on power-down — the logic is broken."
• Senior: "That's the domain being unpowered — corruption X is expected. Is it clamped by isolation? Is retention saving the state I need? Is the sequencing right? Those are the real questions."

The senior reads corruption X as modelling and debugs isolation, retention, and sequencing.

Silicon Impact

Power-aware GLS is what makes the UPF actionable — and its central interpretive skill is separating modelling (corruption X = unpowered, expected) from bugs (X leaking, state lost, bad order). Get this wrong and you either chase phantom logic bugs (wasting time on expected corruption) or, worse, miss a real one: an unclamped corruption X that leaks into an always-on domain (missing isolation, 10.3) or lost retention state ships as a power-cycle-triggered silicon failure (0.3). Because power-driven X-injection is the same mechanism as timing-check X (8.5), the same discipline applies: the X is a modelling flag — trace it, classify it, fix the real cause. Power-aware GLS, read correctly, is the functional safety net for every power transition.

Engineering Checklist

• Ran power-aware GLS (netlist + UPF, 10.1).
• Read a corruption X on power-down as expected modelling.
• Checked isolation — no X leak into ON domains (10.3).
• Checked retention — needed state preserved/restored (10.4).
• Checked sequencing (isolate/save/switch order, 10.5); kept it a functional check.

Try Yourself

1. Apply a UPF and run power-aware; power a domain down — watch its logic corrupt to X (expected).
2. Observe: the corruption X is the unpowered domain, not a logic bug.
3. Change: route the powered-down domain's output into an ON domain without isolation.
4. Expect: the corruption X leaks into the ON domain — a real missing-isolation bug (10.3) power-aware GLS reveals. Add isolation and confirm the ON domain stays clean.

Power-aware simulation is an EDA-tool feature; the corruption/isolation/retention behaviour is standardized and illustrated tool-neutrally here.

Interview Perspective

• Weak: "Power-aware GLS just runs the design with power on."
• Good: "It applies the UPF to corrupt powered-down domains to X, and models isolation and retention."
• Senior: "Power-aware GLS = normal GLS + UPF. On power-down it corrupts the domain to X (modelling loss of state/drive — power-driven X-injection, the analog of timing-check X), then applies isolation and retention. A corruption X is expected; the real checks are isolation (no leak), retention (state preserved), and sequencing. It's a functional power-intent check, not power integrity."

9. Interview / Review Questions

10. Key Takeaways

• Power-aware GLS = normal GLS + UPF (10.1) — it models power, which a normal always-on run cannot.
• On power-down, the simulator corrupts the domain's logic to X (models loss of state/drive) — power-driven X-injection, the analog of the timing-check X (8.5); this corruption X is expected, not a logic bug.
• It also applies isolation (clamp outputs, 10.3), retention (save/restore state, 10.4), and restores on power-up.
• It reveals what normal GLS can't: missing isolation (X leaking into an ON domain), missing/incorrect retention (state lost), sequencing bugs (10.5), and corruption crossing domains.
• Read a corruption X as modelling; debug isolation/retention/sequencing, not the block logic. It's a functional power-intent check, not power integrity (dynamic; STA signs off timing, 0.3). Next: 10.3 — isolation & level-shifter cells in sim.

Quick Revision

Power-aware GLS = normal GLS + UPF → models power. Power-down → corrupts domain to X (loss of state/drive; power-driven X-injection, 8.5-analog) — expected, not a logic bug. Applies isolation (clamp, 10.3) + retention (save/restore, 10.4); restores on power-up. Reveals missing isolation (X leak), lost retention, sequencing bugs. Read corruption X as modelling; debug iso/retention/sequencing. Functional, not power integrity. Next: 10.3 — isolation & level-shifters.