Can you describe a basic low-power implementation mistake, like a missing isolation cell?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Definition
A missing isolation cell is a boundary between a shutdown domain and an always-on (or differently-timed) domain where no isolation strategy has clamped the crossing signal, so the receiver can see a floating or invalid voltage whenever the source domain is powered down.
Mentor Explanation
This requirement is one of two mandatory considerations when mixing shutdown blocks with always-on logic: isolation cells must be placed at the outputs of switchable blocks so that a valid logic signal is presented downstream even when the block is off. Skipping this is a classic mistake because the failure is often silent in early simulation (where power-down behavior may not even be modeled) and only shows up as intermittent, voltage-dependent logic corruption in a physical implementation or in gate-level power-aware simulation. This class of error is treated seriously in tooling: even when a designer deliberately suppresses automatic isolation insertion, check_mv_design still reports the resulting missing isolation cells as errors, and the diagnostic command 'analyze_mv_design level_shifter' exists specifically to report crossings where a management strategy could not be fulfilled, with explicit error codes such as MV-1108 ('Cannot insert level shifter... because the path does not have an effective level shifter strategy') illustrating the level-shifter analog of the same class of mistake. A related, more subtle version of this mistake shows up in the 'smart derivation of -no_isolation' scenario: by default the tool auto-derives a no-isolation rule on newly punched hierarchical pins for retention/switch/isolation control signals, but if the actual driver of that control pin is less always-on than the control pin itself, the resulting violation cannot be fixed because no_isolation takes the highest precedence — requiring the dedicated 'mv.cells.smart_derive_iso_strategy_on_new_control_ports' app option as a fix.
Example
A block's data output feeds an always-on state machine, but the designer wrote a set_isolation strategy only for a different, unrelated port on that same domain — check_mv_design would flag the unprotected output as still lacking isolation once the power state table shows that source domain going off while the destination stays on.
Why It Matters
I ask beginners to talk through this exact failure mode because it's the archetypal 'why does low-power verification matter' story — a functionally-correct netlist with a missing isolation cell can pass ordinary DRC/LVS and functional simulation, yet fail catastrophically the moment real power sequencing is exercised.
Command
analyze_mv_design -level_shifter [-through net_or_pin]Common Beginner Mistake
Believing that if a domain 'always looks the same voltage as its neighbor most of the time,' isolation can be skipped — isolation necessity depends on the full set of legal power states and controlsignal relationships (shared switch control, shutdown ordering, nesting), not just typical-case voltage equality.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising