How does UPF define power-domain scope and extent, and what do the -applies_to_boundary options (upper/both/ lower) control?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Technical Explanation
A power domain has two distinct notions: its scope, which is the hierarchy level that acts as the domain's root, and its extent, which is the actual set of design elements that belong to it. These are not the same thing — the scope just anchors where the domain lives in the hierarchy, while the extent is whatever you list with elements. Separately, when a domain has nested child domains, a strategy (isolation or level-shifter) needs to know which of the domain's boundaries it should apply to — the boundary facing the parent (upper), the boundary facing a contained child domain (lower), or both.
Architecture-level Reasoning
Because power domains can nest, a single strategy declared on the outer domain is ambiguous about whether it should fire at the outer domain's own edge or at the inner child domain's edge too. The upper/both/lower vocabulary exists specifically to remove that ambiguity for lower-domain-boundary support.
Step-by-step Walkthrough
1) A domain's scope is set via -scope on create_power_domain (the hierarchy root); its extent is set via -elements. 2) When domains nest (e.g. PD_TOP containing PD_MID containing PD_BOT), a levelshifter or isolation strategy declared with -applies_to_boundary upper only fires at the strategy domain's own outer boundary; applies_to_boundary lower fires at the boundary of a contained child domain; -applies_to_boundary both fires at both.
Command
set_level_shifter LS1 -domain PDM -applies_to_boundary both -applies_to
both -location otherSwitch-by-switch
-applies_to_boundary both: the strategy is enforced at both the
upper (parent-facing) and lower (child-facing) boundary of the
domain named in -domain. -location other: places the shifter at the
upper boundary port for an upper-boundary crossing, or the lower
boundary port for a lower-boundary crossing.Expected Result
Level shifters (or isolation cells) are correctly placed at every boundary the strategy is meant to cover, with no ambiguity about upper vs lower crossings in a nested-domain design.
Possible Implementation Error
Specifying a strategy with the default (upper-only) boundary behavior on a domain that actually needs its lower boundary (facing a fullynested child domain) covered too, silently leaving the lower crossing unprotected.
Likely Tool / Clp Warning
No specific error code for a missed lower-boundary strategy is documented; the omission would surface as a voltage-violation or missing-isolation finding once boundary checks run.
Root Cause
-applies_to_boundary is not automatic — it must be explicitly set to both when a domain has children whose boundary also needs the strategy.
Debugging Sequence
1) Draw out the domain nesting (PDT/PDM/PDB style) and mark each boundary. 2) Check each set_level_shifter/set_isolation statement's -applies_to_boundary value against which boundaries actually exist. 3) Re-run with -applies_to_boundary both where a nested child boundary was missed. An uncovered domain boundary is a functional/electrical correctness gap that must be resolved before physical implementation proceeds.
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