Walk through the "smart-derive isolation strategy" gotcha for newly punched control ports — what goes wrong and how is it fixed?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Technical Explanation
By default, whenever the tool punches a new hierarchical pin to carry a retention, switch, or isolation control signal down through the hierarchy, it automatically derives a -no_isolation strategy on that newly punched pin. That is normally the safe default. The problem arises when the driver of that control pin is actually LESS always-on than the control pin itself needs to be — in that situation the pin genuinely needs isolation, but no_isolation sits at the highest precedence level in the isolation-strategy resolution order, so there is no way to override it and add real isolation once the tool has already derived -no_isolation. The violation becomes unfixable through normal means.
Architecture-level Reasoning
The default exists because most newly punched control pins really don't need isolation (they're driven by something at least as always-on as themselves), so auto-deriving -no_isolation avoids unnecessary isolation cells in the common case — but the default blindly assumes that relationship holds, and when it doesn't, its own top-of-precedence status becomes the trap.
Step-by-step Walkthrough
1) Domain A (supplies PDT: VDDT, VSS) contains domain C (supplies PDC: VDDC, VSS) with retention registers. 2) A save signal is punched from A down to C as C/save. 3) The power-state table has a state (Pst2) where VDDT is off while VDDC is on. 4) Because the newly punched C/save pin got the default auto-derived no_isolation strategy, the tool cannot insert isolation on it — yet in Pst2 the driver side (A, via VDDT) is off while the receiving domain C is still on, which is exactly the condition that needs isolation. This produces an isolation violation on C/ save that cannot be fixed because -no_isolation outranks everything else. 5) The fix is set_app_options -list {mv.cells.smart_derive_iso_strategy_on_new_control_ports true}, which makes the tool check the control path for a violation FIRST, before it derives -no_isolation — so it only auto-derives -no_isolation when it's actually safe to do so. This option is currently supported only for the retention control path.
Command
set_app_options -list
{mv.cells.smart_derive_iso_strategy_on_new_control_ports true}Switch-by-switch
-list {mv.cells.smart_derive_iso_strategy_on_new_control_ports
true}: enables the smart-derivation check, which inspects the
newly punched control pin's driver-vs-pin always-on relationship
before deciding whether -no_isolation is safe to auto-derive;
supported currently only for the retention control path.Expected Result
The newly punched retention control pin correctly receives a real isolation strategy (instead of an unfixable auto-derived no_isolation) whenever its driver is less always-on than the pin itself, eliminating the otherwise-unfixable isolation violation.
Possible Implementation Error
Leaving the default behavior in place on a hierarchy where a retention save/restore signal is punched from an always-on parent domain down into a domain that can be on while the parent's relevant supply is off in some PST state — producing exactly the Pst2-style violation.
Likely Tool / Clp Warning
The violation itself is an isolation violation on the punched control pin (e.g. C/save) reported once the PST state combination (VDDT off, VDDC on) is checked; there is no specific numbered error code documented for this particular case, only the mechanism and its fix.
Root Cause
The default smart-derivation logic derives -no_isolation on newly punched control pins unconditionally, without first checking whether the actual driver-to-pin always-on relationship makes that safe — and because -no_isolation has the highest precedence among isolation strategies, once derived it cannot be overridden.
Debugging Sequence
1) Identify every retention/switch/isolation control signal that gets punched as a new hierarchical pin during UPF processing. 2) For each, check whether the PST contains a state where the driving domain's relevant supply is off while the receiving domain is on. 3) If such a state exists, confirm whether mv.cells.smart_derive_iso_strategy_on_new_control_ports is enabled; if not, enable it before the control-port derivation happens (it is currently only supported for the retention control path). An unfixable auto-derived -no_isolation on a control pin that genuinely needs isolation is a hard blocker that must be resolved (via the app option) before the design can pass isolation-strategy verification.
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