54 3 Modeling UPF

tle concepts inherent in UPF semantics that also drives the construction and model-
ing of UPF. For example, refinement of power domain elements, refinement of UPF
strategies, refinement of power states through derivatives or through in place, power
state overlap, inter-domain dependency etc. These features mainly govern how UPF
evolves through the DVIF at different design abstraction levels through refinement
and contributes in PA design integrations, implementations, and verifications per-
spective. The succeeding sections will discuss these features and flows in detail.

3.2 Successively Refinable UPF

The successive refinement of UPF corresponds power management and reduction

throughout the DVIF where UPF development starts from early RTL and gradually
refined down the implementation flow at GL-netlist and PG-netlist, augmented with
appropriate detail for each design-implementation phase.
As mentioned earlier in introductory sections that IEEE 1801 standardization
provides the flexibility to develop UPF from RTL with the perspective to adopt
appropriate power reduction techniques at very early stage of design abstraction.
This enable to comprehend the primary UPF constraints including rudimentary
parts, like power domain with minimum extent of design instances as elements (also
known as atomic power domain), abstract supply sets, and possible power states. In
addition it also comprehend to virtually infer boundary strategies, like ISO, LS,
ELS, RFF, PSW, RPT, etc. that in turn allows to simulate or verify power manage-
ment and reduction techniques and pre-assess many post synthesis or post P&R
power implementation artifacts. However logical ports and specific control infor-
mation are not in the scope of constraint UPF.
In addition, many internally developed RTL design blocks and externally pro-
cured IPs are reused over few generation of a design, hence it is also important to
enumerate any power management information of reusable IP at RTL. One of the
major concern here that these IPs accompany technology or implementation inde-
pendent UPF. Hence successive refinement of UPF allows IP provider to deliver
UPF constraints of IP component along with the RTL functional specification that
ensures the component will interact correctly in any given application with the
existing power management and reduction techniques for the entire system.
Basically the contents of UPF constraints for an IP are exactly same as the regular
portion of the design as explained above.
The successive refinement of UPF complete flow is summarized in the following
Fig. 3.6 represented from IEEE 1801-2015 Language Reference Manual (LRM).
Recalling the Fig. 3.3 Example of Complex SoC, the following Example 3.58
shows the sample of constraint UPF.
Example 3.58 Sample Constraint UPF
create_power_domain PD_SOC –elements {.} -atomic
create_power_domain PD_COREA –elements {u_ca_cpu0} -atomic
3.2 Successively Refinable UPF 55

Fig. 3.6 Successive refinement of power management in the DVIF with successively adding con-
straint, configuration and implementation UPF (Courtesy: IEEE 1801-2015 LRM)

create_power_domain PD_CPU0 –elements {u_ca_advcpu0} –atomic

# Create the L2 Cache domain
create_power_domain PD_L2 –elements {u_ca_l2/u_ca_l2_datarams u_ca_
l2/u_ca_l2_tagrams u_ca_l2/u_cascu_l1d_tagrams} –atomic
# RFF
set_retention_elements PD_COREA_RETN –elements “u_ca_cpu0”
# ISO
set_port_attributes –elements {u_ca_hierarchy}
-applies_to outputs
-clamp_value 0
set_port_attributes -ports u_ca_hierarchy/output_port_a
-clamp_value 1
# Power States
add_power_state PD_CPU0 –domain \
-state {RUN -logic_expr {primary == ON}} \
-state {SHD -logic_expr {primary == OFF}}
add_power_state PD_CPU0.primary –supply \
56 3 Modeling UPF

-state {ON -simstate NORMAL} \

-state {OFF -simstate CORRUPT}
When the design development further progresses in the flow and the design
building blocks or the reusable IPs are in the integration process with the entire
design, it is required to specify the configuration of the design and UPF as well. The
configuration UPF which is an extension of existing constraint UPF, basically works
in combination and adds the missing portion of constraint UPF. Which are logic and
power management control ports and detail of strategies like ISO on crossing differ-
ent power domain boundaries, RFF for the entire design or only a portion of the
regular flops etc.
Another important aspect of configuration is the power states are updated with
logic expression to accommodate the control inputs. However since the technology
specific implementation detail is still not available at system integration of DVIF
phase; hence configuration UPF is limited to only the attributes mentioned so far
and typically do not consider voltage values, logical reference of PSW or any spe-
cific cell information.
The following example denotes the configuration UPF for the SoC design shown
in Fig. 3.3 and works in combination with the constraint UPF is shown in Example
3.58.
Example 3.59 Sample Configuration UPF
# Logic and power management control ports
create_logic_port -direction in nRETNCPU0
create_logic_net nRETNCPU0
connect_logic_net nRETNCPU0 -ports nRETNCPU0
# RFF
set_retention ret_cpu0 -domain PD_COREA \
-retention_supply_set PD_COREA.default_retention \
-save_signal {nRETNCPU0 negedge}
-restore_signal {nRETNCPU0 posedge}
# ISO
set_isolation iso_cpu_0 -domain PD_COREA \
-isolation_supply_set PD_SOC.primary \
-clamp_value 0 \
-applies_to outputs \
-isolation_signal nISOLATECPU0 \
-isolation_sense low
# Power states updates for PD
add_power_state PD_CPU0 –domain -update \
-state {RUN -logic_expr {nPWRUP_CPU0 == 0 && nPWRUPRetn_CPU0 ==
0}} \
-state {RET -logic_expr {nPWRUP_CPU0 == 1 && nPWRUPRetn_CPU0 ==
0 && nRETN_CPU0 == 0 && nISOLATE_CPU0== 0}} \
-state {SHD -logic_expr {nPWRUP_CPU0 == 1 && nPWRUPRetn_CPU0 ==
1}}
# Power state update for supply set
3.2 Successively Refinable UPF 57

add_power_state PD_CPU0.primary –supply -update \

-state {ON -supply_expr {power == FULL_ON && ground == FULL_ON} \
-logic_expr {nPWRUP_CPU0 == 0}} \
-state {OFF -supply_expr {power == OFF || ground == OFF} \
-logic_expr {nPWRUP_CPU0 == 1}}
Finally, when the design is ready for implementation, it is the time to furnish
UPF with technology specific physical entities like supply net and supply port for
specific supply set, ISO or RFF cell, and their mapping information, logical and
physical control and supply connectivity of PSW. As well further updates on power
states with supply expression and exact supply voltage information. However, this
final implementation UPF is concatenated on previous constraint and configuration
UPF, and their combination completes the UPF modeling for the entire design.
Conventionally the RTL along with the constraint and configuration UPF are
referred as the golden source and remain fixed throughout the entire DVIF. Once the
configuration specified by the golden source are validated, it is then combined with
implementation UPF to complete synthesis, post synthesis and post layout imple-
mentation and verification processes. The following example denotes the imple-
mentation UPF for the SoC design shown in Fig. 3.1 and works in combination with
the constraint and configuration UPF.
Example 3.60 Sample Implementation UPF
# Supply Port & Net
create_supply_port VDD
create_supply_net VDD -domain PD_SOC
create_supply_net VDDSOC -domain PD_SOC
# Physical PSW connectivity
create_power_switch ps_SOC_primary –domain PD_SOC \
-input_supply_port { VDD VDD } \
-output_supply_port { VDDSOC VDDSOC } \
-control_port { nPWRUPSOC nPWRUPSOC } \
-on_state { on_state VDD {!nPWRUPSOC} } \
-off_state { off_state {nPWRUPSOC} }
# Physical Supply net connectivity for Supply Set
create_supply_set PD_COREA.primary -update \
-function {power VDDCPU0} -function {ground VSS}
create_supply_set PD_COREA.default_retention -update \
-function {power VDDRCPU0} -function {ground VSS}
# Update of Power state with supply voltage
add_power_state PD_COREA.primary –supply -update \
-state {ON -supply_expr {power == {FULL_ON 0.81} && ground == {FULL_
ON 0.00}}} \
-state {OFF -supply_expr {power == OFF|| ground == OFF}}
add_power_state PD_COREA.default_retention –supply -update \
-state {ON -supply_expr {power == {FULL_ON 0.81} && ground == {FULL_
ON 0.00}}} \
-state {OFF -supply_expr {power == OFF|| ground == OFF}}
58 3 Modeling UPF

The following List 3.24 summarizes the required features for modeling con-
straint, configuration and implementation UPF.
List 3.24 Required Feature Summery of Constraint, Configuration and
Implementation UPF
Constraint UPF
–– Atomic power domains
–– Clamp value requirements
–– Retention requirements
–– Fundamental power states
–– Legal, illegal states, transitions
Configuration UPF
–– Actual power domains
–– Additional domain supplies
–– Additional power states
–– Isolation and Retention strategies
–– Control signals for power management
Implementation UPF
–– Voltage updates for power states
–– Level Shifter strategies
–– Mapping to Library power management cells
–– Location updates for Isolation
–– Supply ports, nets, switches, and sets
–– Port states or Power state tables
It is evident that the successive refinement of UPF addresses the needs of various
design or IP resources within their own scope in the DVIF. For example, the IP
developers who create reusable IP with independent power manageable constraints,
the system integrator who configure IP blocks and integrate them together with
power management logic, the chip implementers who map the logical design onto a
technology specific physical implementations.
One of the major challenges of successive refinement of UPF is to identify power
management and reduction constraints that will remain unchanged for a particular
design life span. Hence this UPF modeling style sometimes tends to be more biased
towards the verification objectives, specifically power intent verification and simu-
lation targets at constraints and configuration UPF level, while structural, architec-
tural and functional verification and simulation at implementation levels.
Nevertheless the UPF abstraction choice is originated from verification objectives
more than just modelling power management and reduction techniques from a
designer perspective. Although the incrementally refinable UPF discussed in next
Sect. 3, provides greater flexibility for designers to define UPF objects once and
refine indefinitely when require.
3.3 Incrementally Refinable UPF 59

3.3 Incrementally Refinable UPF

Incrementally refinable UPF is primarily referred to the refinement process by

derivatives and refinement in place of UPF fundamental power states. These meth-
odological approaches are deeply discussed in Sect. 1.3, with relevant Examples
3.30, 3.31, 3.30 etc. for definite and deferred power states.
The refinement by derivation creates a set of mutually-exclusive sub states or a
completely new state based on the original power state. This is actually done through
updating the logic expression (–logic_expr). The refinement in place actually modi-
fies the original power states instead of creating a new power state. This is actually
done through the UPF –update options of the power state in add_power_state
command.
Both the refinement procedures are conducted in an incremental manner.
Because, as the design rolls from RTL to GL-netlist or PG-netlist, more precise
design information and implementation specific parameters became available incre-
mentally. Thus the definite power states create more specific power states from ini-
tial abstract states and deferred power state becomes definite with updating
implementation specific information like voltage values, power switch types etc.
There are several other UPF commands and some of their arguments supports
incremental refinement and termed as refinable commands and refining arguments
respectively.
A refinable command may be invoked multiple times on the same object and
each invocation may add additional arguments to those specified in previous
­invocations. Actually the arguments of a refinable command that may be added after
the first invocation are called refining arguments. Such arguments added in a con-
secutive manner on each iteration of incremental refinement and may have addi-
tional information about that argument added after the first invocation of the
command.
Hence secondarily, apart from UPF power states, which is the core of UPF mod-
eling and PA verification, the incrementally refinable UPF correspond to other UPF
commands as well. For example power domain, power supply set, and different
UPF strategies are also subject to refinement in place through –update options.
So apart from power states, there are multitude of such refinable commands and
refining arguments, it is more appropriate to understand the incrementally refinable
UPF for the fundamental constituent parts like power domains, power supply set
and UPF strategies and then extend the contexts for modeling UPF for the entire
design. In the following subsections, some of the refinable commands and refining
arguments semantics for the fundamental constituent parts are discussed in detail.
Refinement of Power Domains
The UPF create_power_domain command defines power domains also have
–update option and may be used in much similar style of power state to incremen-
tally refine some of the options and possibly their arguments like –elements, -sub-
domains, -supply etc. of an already defined power domain. The following example
explains the power domain refinement through –update on –supply arguments at
60 3 Modeling UPF

configuration level which was previously defined without –supply information at

constraint level.
Example 3.61 Refinement of Power Domain Through –supply Arguments
# Snippet of CONSTRAINT UPF
set_design_top rtl_top
# Create power domain for memory controller
create_power_domain PD_mem_ctrl -elements {mc0}
# Snippet of CONFIGURATION UPF
# Update PD_mem_ctrl to include the isolation and retention supply sets
create_power_domain PD_mem_ctrl -update \
-supply { retain_ss } \
-supply { isolate_ss }
The incrementally updated ISO and RFF supplies in Example 3.61 will enable to
define corresponding supply set at later phase of DVIF after they are associated with
the corresponding power domains as follows.
Example 3.62 Application of Power Domain Refinement at a Later Stage in
DVIF
# Snippet of CONSTRAINT UPF
# add supply_sets still no voltage information needed
create_supply_set 0d81_ss
# designate actual supply_sets for isolation and retention supples for
PD_mem_ctrl
associate_supply_set 0d81_ss -handle PD_mem_ctrl.isolate_ss
associate_supply_set 0d81_ss -handle PD_mem_ctrl.retain_ss
# Snippet of CONFIGURATION UPF
# Setup retention strategy for memory controller domain
set_retention mem_ctrl_ret \
-domain PD_mem_ctrl \
-retention_supply_set PD_mem_ctrl.retain_ss \
-retention_condition {(mc0/clk == 1'b0)} \
-elements {mem_ctrl_ret_list} \
-save_signal {mc_save high} \
-restore_signal {mc_restore low}
Refinement of Supply Set
The supply set refining arguments are –update and –function and obviously works
in much same way as incremental refinement of power domain works. The UPF
create_supply_set command that defines a new supply set requires to update in
implementation UPF with physical power and ground entities as follows in Example
3.63. However, it is important to understand that these supply set were just abstractly
defined in constraint level so far and associated to different power domains as pri-
mary without specific power and ground (PG) port details. It is also required to
know that the PG detail is mandatory to route supply power and ground to every
design elements or cell-specifically in P&R level.
3.3 Incrementally Refinable UPF 61

Example 3.63 Refinement of Power Supply Set through –function Arguments

# Snippet of CONSTRAINT UPF
# add supply_sets still no voltage information needed
create_supply_set 0d99_ss
create_supply_set 0d81_ss
create_supply_set 0d81_sw_ss
# Designate primary supplies for all domains
associate_supply_set 0d99_ss -handle PD_top.primary
associate_supply_set 0d99_ss -handle PD_sram.primary
associate_supply_set 0d81_ss -handle PD_intl.primary
associate_supply_set 0d81_sw_ss -handle PD_mem_ctrl.primary
# Snippet of IMPLEMENTATION UPF
create_supply_set 0d99_ss -function {power VDD_0d99 } -function {ground
VSS} -update
create_supply_set 0d81_ss -function {power VDD_0d81 } -function {ground
VSS} -update
create_supply_set 0d81_sw_ss -function {power VDD_0d81_SW } -function
{ground VSS} -update
In the implementation UPF snippet above, the power and ground functions are
actually physical ports and nets and must be defined and connected as shown below
before they are updated.
Example 3.64 Application of Power Supply Set Refinement at a Later Stage
in DVIF
# Snippet of IMPLEMENTATION UPF
# Create top level power domain supply ports
create_supply_port VDD_0d99 -domain PD_top
create_supply_port VDD_0d81 -domain PD_top
create_supply_port VSS -domain PD_top
# Create supply nets
create_supply_net VDD_0d99 -domain PD_top
create_supply_net VDD_0d81 -domain PD_top
create_supply_net VSS -domain PD_top
create_supply_net VDD_0d81_sw -domain PD_mem_ctrl
# Connect top level power domain supply ports to supply nets
connect_supply_net VDD_0d99 -ports VDD_0d99
connect_supply_net VDD_0d81 -ports VDD_0d81
connect_supply_net VSS -ports VSS
Refinement of UPF Power Strategies
UPF strategies among ISO, LS, ELS, RFF, PSW and RPT etc. also have refinable
commands and handful of refining options and arguments. However, all the strate-
gies inherit incremental refinement through –update. Though for ISO, LS or ELS
and RPT the –update command allows refinement through supplementary informa-
tion on a previously defined command for the same strategy and same power
domain, and also requires that the strategy execution occurs in the same scope.
62 3 Modeling UPF

While for PSW and RFF refinement allows the addition of instances and retention
strategies.
The following Example 3.65 shows the refinement of ISO as a representative of
all other UPF strategies.
Example 3.65 Refinement of ISO Through –update
# Snippet of CONFIGURATION UPF
# Setup ISO strategy for memory controller domain; No location information yet
set_isolation mem_ctrl_iso_1 \
-domain PD_mem_ctrl \
-isolation_supply_set PD_mem_ctrl.isolate_ss \
-clamp_value 1 \
-elements {mc0/ceb mc0/web} \
-isolation_signal mc_iso \
-isolation_sense high
# Update PD_mem_ctrl isolation strategies with -location info
set_isolation mem_ctrl_iso_1 -update \
-domain PD_mem_ctrl \
-location parent
Hence it must be distinctive at this point that the fundamental difference of incre-
mental refinement and successive refinement terminology as consciously used in
UPF has significant role on evolving UPF over a particular DVIF life cycle. Where
in generic form, the first, incremental refinement corresponds to the pertinent refine-
ment of UPF semantic components and the later successive refinement corresponds
to utilize the refined components to model the complete UPF for the entire design to
be consumed in the verification and implementation flow.
More specifically incremental refinement denotes how and successive refinement
denotes when the refinement actually occurs. However, both occurs within the same
bounded space with different perspectives.

3.4 Hierarchical UPF

Hierarchical UPF has a complete different focus in modeling UPF from that of suc-
cessively or incrementally refinable UPF, though these both are tightly integrated
while developing hierarchical UPF. Here the effort is to develop UPF at design block
level within its own HDL reference instance scope and gradually or in parallel build
up UPF for the entire design in bottom-up manner by calling or loading them from
the extent to their immediate or prospective hierarchical top of HDL references.
However, this UPF development strictly relies on successively refinable flow and
incrementally refinable methodologies. But in broader aspect, hierarchical UPF is a
flow in PA design verification and implementation process.
Primarily hierarchical UPF objective is to simplify block level design verification,
facilitates maintenance of block level design independently, and as well implementa-
tion of such block level design through the synthesis process. Because block level PA
3.4 Hierarchical UPF 63

verification and synthesis with UPF is always simpler than perusing the same for the
entire SoC. The following example shows the constructions and constituent parts of
hierarchical UPF based on the design example shown in Sect. 2.2, Figs. 2.1 and 2.2.
Example 3.66 Sample Hierarchical UPF from Verification and
Implementation Perspective
set_design_top cpu_top
# Load Successively Refinable UPF
load_upf cpu_constraints.upf
load_upf cpu_configuration.upf
load_upf cpu_implementation.upf
# Fundamental Constituent Part of cpu_top UPF
# Creating PD, supply set, power states etc.
create_power_domain PD_top
……..
# load hierarchical UPF
load_upf PD_sub3.upf -scope umem_top
load_upf PD_sub2.upf -scope udecode_top
# New scope for mem sub domain
set_scope cpu_top/umem_top
# Further load of sub block Successively Refinable UPF
load_upf mem_constraints.upf
load_upf mem_configuration.upf
# Fundamental Constituent Part of mem UPF
# Creating PD, supply set, power states etc.
create_power_domain PD_sub3 –elements {.}
……..
# load hierarchical UPF for mem sub domain
load_upf sub3.1_PD.upf -scope cpu_top/umem_top/umem_sub
As shown in the example above, the hierarchy navigation in UPF occurs as the
commands are executed in the context of a scope within the logic hierarchy. In the
latter part of the above example, the set_scope UPF command is used to navigate
within the hierarchy and to set the current scope to cpu_top/umem_top, within
which commands are executed. The current scope is represented by a relative path-
name from the design top instance.
The set_scope command changes the current scope locally within the subtree
depending on the current design top instance or module. Since the design top
instance is typically an instance of the design top module, they both have the same
hierarchical substructure; therefore, set_scope can be written relative to the module,
but still work correctly when applied to an instance. The set_scope command is
only allowed to change scope within this subtree. It cannot change the scope above
the design top instance or to a scope that is below in the leaf-level instance.
Hence based on the scope level, it is required to understand the extent of design
top instance designated as top power domain.
The design top instance and design top module are typically paired in hieratical
UPF which is cpu_top shown in the first part in the above Example 3.66. The top
64 3 Modeling UPF

instance is represented by a hierarchical name relative to the root scope. It is consis-

tent with SystemVerilog $root, the root of the logic hierarchy is the scope in UPF
where the top modules are implicitly instantiated. Other locations within the logic
hierarchy are referred as the design top instance, which has a corresponding design
top module, and the current scope.
There is an UPF command set_design_top that actually associates the design top
module to each instance in a larger hierarchical UPF flow. Generally, in such a flow, it is
required to manually set the design top instance and design top module. When a sub
domain UPF is called or load from its relative top power domain through load_upf com-
mand, the design top instance are implicitly changed to the current scope of the invoked
sub domain with the -scope argument as shown in the Example 3.66 for PD_sub3.upf
and PD_sub2.upf, where the scopes are umem_top & udecode_top respectively.
However, after the subdomain set_scope cpu_top/umem_top is defined, the
scope changes as current to this instances locally and includes all descendent sub-
tree within the same scope. Hence sub3.1_PD.upf may be allowed to invoke under
the current scope with load_upf –scope cpu_top/umem_top/umem_sub command.
Thus block level UPF can be developed independently and augment to the cor-
responding design top any time in a bottom-up way. Hence hierarchical UPF as a
flow ease the modeling, maintenance and verification of UPF for a large design and
must accommodate the recommended successive refinable flow, formats and incre-
mentally refinable semantics every when they are required.
However, there are other prospect of modeling hierarchical UPF. Specifically
integration of Macro cell (soft or hard Macro both) in hierarchical order. Hence this
is the secondary artifact of hierarchical UPF that also facilitates Macro integration
in conjunction with simplifying block level design verification, maintenance, and as
well synthesis.
The Macro integration is done through another special UPF set_port_attribute
commands.
Example 3.67 Syntax UPF Command set_port_attribute to Supplement
Hierarchical Flow
set_port_attributes
[-model name]
[-elements element_list]
[-exclude_elements element_exclude_list]
[-ports port_list]
[-exclude_ports port_exclude_list]
[-applies_to <inputs | outputs | inouts | {<inputs | outputs | inouts >*}>]
[-attribute {name value}]*
[-clamp_value <0 | 1 | any | Z | latch | value>]
[-sink_off_clamp <0 | 1 | any | Z | latch | value>]
[-source_off_clamp <0 | 1 | any | Z | latch | value>]
[-driver_supply supply_set_ref]
[-receiver_supply supply_set_ref]
[-literal_supply supply_set_ref]
[-pg_type pg_type_value]
3.4 Hierarchical UPF 65

[-related_power_port supply_ port_name]

[-related_ground_port supply_ port_name]
[-related_bias_ports supply_ port_name_list]
[-feedthrough]
[-unconnected]
[-is_analog]
[-is_isolated]
The set_port_attributes command is for specifying information associated with
ports of models or instances. Model ports are referenced by –model and instance
ports are referenced by using either -elements or -ports (and obviously without
–model) option(s). If -model is specified and the model name is (.) (a dot), the com-
mand applies to the model corresponding to the current scope.
Despite other options, the -driver_supply and -receiver_supply corresponds to
the UPF attributes UPF_driver_supply and UPF_receiver_supply respectively as
noted for logic port source and sink driving mechanism in Sect. 1.
These options or attributes can be used to specify the driver supply of a Macro
cell output port or the receiver supply of a Macro cell input port. They can also be
used to specify the assumed driver supply of external logic driving a primary input
or to specify the assumed receiver supply of external logic receiving a primary out-
put; specifically when the Macro is implemented separately from the context in
which it will be instantiated. These attributes are ignored if applied to a port that is
not on a Macro boundary.
Recalling the Fig. 3.3 of example of a complex SoC, and considering the CPU
Cluster A, where any soft Macro is required to integrate on the PD_CPU0 as refer-
ence power domain, the redrawn figure is shown in Fig. 3.7.
The relevant set_port_attribute commands for the Macro with corresponding
driver and receiver supply is shown in Example 3.68.
Example 3.68 Snippet of UPF for Macro Integration at PD_CPU0 Hieratical
Level
# UPF in Context to PD_CPU
set_port_attributes –ports inP -driver_supply PD_CPU0.primary
set_port_attributes –ports outP -receiver_supply PD_CPU0.primary
Here the external Macro which is represented by the symbolic logic clouds in Fig. 3.7
are defined in terms of the interface or boundary context of the driver and receiver supply
for inP or outP ports of PD_CPU0 power domain. Although the supplies are modelled
using available supplies or handles as (PD_CPU0.primary) of PD_CPU0.
However when considering the Macro integration from a higher level of hierar-
chical perspective, for example, CPU Cluster A, which is actually the entire SoC or
PD_SOC, as redrawn in Fig. 3.8 from Fig. 3.3.

Fig. 3.7 Soft macro PD_CPUA0

integration perspective for
PD_CPU0 power domain
L1 Cache
66 3 Modeling UPF

CPU Cluster A
PD_CPUA Power Control Unit

PD_COREA

Fig. 3.8 Soft macro integration perspective for the CPU cluster A (actually PD_SOC)

Example 3.69 Snippet of UPF for Macro Integration at PD_SOC Hieratical

Level
# UPF in Context to PD_CPU
set_port_attributes –ports inP -receiver_supply PD_CPU0.primary
set_port_attributes –ports outP -driver_supply PD_CPU0.primary
# UPF in Context to CPU Cluster A or PD_SOC
set_port_attributes –ports top/inP -driver_supply PD_SOC.primary
set_port_attributes –ports top/outP -receiver_supply PD_SOC.primary
It is required to notice here that the boundary interface contexts of Macro for
PD_CPU0 is changed while considering a higher level of hierarchical context from
PS_SOC. That is the driver and receiver supply for inP and outP ports are reversed
in Example 3.69 compared to Example 3.68.
Hence it is comprehensive that hierarchical UPF simplifies the block level design
verification, block level synthesis of the design with block level and its independent
UPF, and as well facilitates Macro integration at any hierarchical contexts.
In this concluding part of this chapter it is distinctly visible that UPF modeling is
primarily governed by PA design verification and secondarily to accommodate the
verification in different level of design implementation in the DVIF efficiently.

Epilogue: The Chapter 3 – Modeling UPF is an enormous chapter that cov-

ers the fundamentals and advanced topics for efficient and effective UPF
modeling. It provided the key to the readers to explore all possible artifacts of
low power design and power aware verification for succeeding chapters of
this book. This chapter started with explaining the fundamental constituent
parts of general UPF constructs and explains power domains through cre-
ate_power_domain – elements {.} UPF constructs. The HighConn,
LowConn, lower or upper domain boundary, domain interface, ports etc. are
explained through exploiting the common and formal port definitions for
actual signal connections in terms of hierarchical design instances.
3.4 Hierarchical UPF 67

When a portion of design element is confined within a domain, the next obvi-
ous aspects is to provide the power supply. The power supply abstractions are
explained through the create_supply_set –function or (and) –update con-
structs in conjunctions with associate_supply_set –handle and create_
power_domain –supply and –update constructs. Next the add_power_state
construct for power state – the pivotal factor and the central force of UPF
modeling and power aware verification is explained through complex SoC
design example in comprehensive manner. While mentioning the specific rea-
son of conventional PST (add_port_state, add_pst_state and create_pst)
becoming obsolete; the superiority of add_power_state covers detail through
refinement by derivatives for definite power state through “new state”, and
refinement in place for deferred power state through “-update”.

The guidelines, recommendations and compositions summery of power states

listed in Lists 3.17, 3.18, and 3.19 will remain as point of reference while
writing UPF or conducting PA verification. The power strategies are also con-
stituent part of UPF and ISO, LS, PSW, RFF, RPT are explained in this chap-
ter with syntax, semantics and practical usage perspective. Finally the UPF
modeling flow and constructional refinement features are explained through
successive and incremental refinements aspects. In addition, benefit and usage
of hierarchical construction of UPF are also covered at the end of the
chapter.