How is UPF hierarchy built for nested/composite power domains?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Explanation
Nested power domains arise naturally from scoping create_power_domain calls to sub-instances that already sit inside a bigger domain's elements -- there's no separate 'declare this as a child' command. UPF also provides create_composite_domain to formally combine several subdomains sharing one supply into a single higher-level domain object.
Implementation Walkthrough
Basic nesting form: create_power_domain -elements {list} [-scope instance] domain_name, where -scope sets the hierarchy level at which the domain is rooted; a domain whose -elements already live inside a larger domain's extent naturally nests within it. Composite domains use create_composite_domain -subdomains -supply to combine already-declared subdomains into one composite object. Mychip itself is a simple example of nesting: PD_MYCHIP (top, -include_scope) contains three sibling subdomains -- PD_CPU (-elements {U_CPU}), PD_COP (-elements {U_COP}), and PD_DSP (-elements {U_DSP}).
Command
create_composite_domain COMP1 -subdomains {PD_A PD_B} -supply {SS_TOP}Switch-by-switch
-subdomains: the list of already-declared power domains being
combined into the composite; -supply: the supply set the composite
domain uses; (for ordinary nesting) -elements: the instances forming
the (sub)domain's extent; -scope: the hierarchy instance where the
domain is rooted.Expected Tool Behavior
Nested domains inherit their containment relationship automatically from their -elements scope; a composite domain lets isolation/ retention/etc. strategies be written once against the combined object instead of duplicated per subdomain.
Example
Mychip's PD_MYCHIP/PD_CPU/PD_COP/PD_DSP nesting, where the three functional-block domains sit as siblings inside the always-on top domain.
Common Mistake
Leaving some instance uncovered by any -elements list anywhere in the nesting -- before commit_upf, every instance must belong to a power domain, so a gap at any level of the hierarchy is a compliance problem.
Likely Error Or Warning
This topic is not covered in enough depth here to give a fully reliable answer for a create_composite_domain-specific error; general atomicdomain nesting conflicts in a hierarchical flow produce an explicit UPF-168 error.
Debugging Approach
Run report_power_domain to inspect a domain's actual Elements and confirm the nesting matches intent.
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