Low Power Verification · All levels

Isolation & Level Shifting: Tricky Q&A

Senior interview and review questions for Isolation & Level Shifting.

Section Q&A bank

Use these drills after completing all topics in Isolation & Level Shifting. Answer with context, mechanism proof, artifact, owner, and release decision.

Why can an apparently correct isolation rule still fail at runtime during power-down transitions?

diagram
[INT][LPV][ISOLATION-AND-LEVEL-SHIFTING]

Q: Why can an apparently correct isolation rule still fail at runtime during power-down transitions?

A:
Rule presence only proves intent exists, not that control timing is safe. If isolation enable asserts after source rails droop, transient unknowns can propagate into always-on logic before clamps become active. Runtime correctness therefore requires sequencing checks that tie isolation control, reset behavior, and power-state transitions together under realistic latency and clock-gating conditions.

FOLLOW-UP TRAP: Assuming static 'strategy exists' reports guarantee glitch-free behavior through dynamic power transitions.

When validating level shifters, why is checking source and destination voltages alone insufficient?

diagram
[INT][LPV][ISOLATION-AND-LEVEL-SHIFTING]

Q: When validating level shifters, why is checking source and destination voltages alone insufficient?

A:
Voltage compatibility catches direction errors, but many failures involve control behavior: enabled shifters can malfunction if enable is not always-on, glitches during ramp, or asserts with wrong polarity. Verification must prove both electrical suitability and control-sequence correctness across all legal power modes, including scan and bring-up states.

FOLLOW-UP TRAP: Treating level-shifter validation as only a static voltage-direction lookup problem.

What is a subtle bug pattern when both isolation and level shifting are required on one crossing?

diagram
[INT][LPV][ISOLATION-AND-LEVEL-SHIFTING]

Q: What is a subtle bug pattern when both isolation and level shifting are required on one crossing?

A:
A common subtlety is correct cells in wrong order or wrong domain. For example, a level shifter inserted before isolation can still pass static checks yet forward unstable behavior during source shutdown; similarly, isolation powered by the collapsing domain is ineffective exactly when needed. Correctness requires topology, domain residency, and power-rail assumptions to be verified together.

FOLLOW-UP TRAP: Believing presence of both cell types is enough regardless of ordering and supply residency.

How can redundant isolation hide real issues instead of being just an area inefficiency?

diagram
[INT][LPV][ISOLATION-AND-LEVEL-SHIFTING]

Q: How can redundant isolation hide real issues instead of being just an area inefficiency?

A:
Redundant cells can mask ownership mistakes in UPF hierarchy and create misleadingly clean behavior that differs from architectural intent. They also complicate debug because multiple clamps may interact, obscuring which control truly protects a path. Removing redundancy with evidence-based analysis often reveals missing or mis-scoped protection that was previously hidden by accidental over-insertion.

FOLLOW-UP TRAP: Dismissing redundant isolation as harmless overhead with no verification or debug consequences.

Q&A drill guide

diagram
SYMPTOM -> LPV FAILURE CLASS -> EVIDENCE -> OWNER ACTION -> VALIDATION

Sketch while answering

diagram
BOUNDARY SAFETY VIEW

domain crossing -> level-shift requirement -> isolation control -> OFF/ON transition behavior

Common traps

  • Map each crossing to expected LS and isolation behavior.

  • Verify enable timing against collapse and restore edges.

  • Check clamp safety for protocol-facing signals.

Key takeaways

  • Tie each LPV claim to a concrete transition boundary and one proving artifact.

  • Prefer minimal reversible fixes with explicit owner and rollback criteria.

Common pitfalls

  • Treating power-aware failures as random before boundary classification.

  • Waiving X-prop failures before proving impact and root cause.

  • Declaring closure without deterministic replay across key modes.