3.

1 Fundamental Constructs of UPF 21

Hence it is evident that the supply set actually represents a potential connection
to a corresponding portion of a design through supply nets. After all, supply set
allows designers to define the power supply for power domains. UPF allows numer-
ous ways to define supply set and associated handles for power domains.
It is also possible to define and associate supply set and supply set handles
through UPF create_power_domain commands and -supply options.
Recalling the syntax and semantic of create_power_domain explained in Sect.
1.1, the supply set definition and supply set handle association in Examples 3.10
and 3.10 can be further made more concise and represented as follows.
Example 3.11 Defining and Association of Supply Set Through Handles for
Power Domains
create_power_domain PD_top \
-supply {primary VDD1_ss}
…
create_power_domain PD_sub2 \
-supply {primary VDD2_ss}
The examples for creation of additional supply set handles for a power domain
and their association through –update are shown below in the following two con-
secutive Examples 3.12 and 3.13.
Example 3.12 UPF Syntax for Defining Supply Sets
create_power_domain PD_top \
-supply {iso_ss} \
-supply {ret_ss}
Example 3.13 UPF Syntax for Defining Supply Sets
create_power_domain PD_top -update \
-supply {primary VDD1_ss} \
-supply {isolation VDD2_ss} \
-supply {retention VDD2_ss}
The supply set handles are generally treated as a local supply set and in addition
to power domain, these handles can also be defined for PSW, ISO, LS, ELS, and
RFF strategies. The following examples shows the supply set handles for an ISO
strategy.
Example 3.14 Supply Set Handles for ISO Strategy
create_power_domain PD_mem_ctrl -elements {mc0}
# Designate actual supply sets for isolation supplies of PD_mem_ctrl
associate_supply_set VDD_top_ss -handle PD_mem_ctrl.isolate_ss
Example 3.15 Variation of Supply Set Handles for ISO Strategy
create_power_domain PD_mem_ctrl -update \
-supply { retain_ss } \
-supply { isolate_ss }
22 3 Modeling UPF

# Designate actual supply sets for isolation supplies

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
However, the most obvious supply set definition and associations through their
handles are done by explicitly referencing power domains and supply functions, i.e.
associate_supply_set VDD_top_ss -handle PD_mem_ctrl.isolate_ss
or
-isolation_supply_set PD_mem_ctrl.isolate_ss
These two are shown in the previous two examples, Examples 3.14 and 3.15
respectively.
The following two consecutive examples, Examples 3.16 and 3.17 show further
variations of defining supply set based on the discussions and examples so far.
Example 3.16 Variation in Defining Supply Sets
create_supply_set VDD1_ss
create_supply_set VDD2_ss
create_supply_set VDD1_sw_ss
Example 3.17 Supply Set Association Through Supply Set Handles for Power
Domains
associate_supply_set VDD1_ss -handle PD_top.primary
associate_supply_set VDD2_ss -handle PD_sub2.primary
associate_supply_set VDD1_sw_ss -handle PD_sub1.primary
Here the associate_supply_set command associates two or more supply sets.
Supply set association implicitly connects corresponding functions and, as a result,
makes them electrically equivalent.
The explicit –handle option is the rooted name of a supply set of a power domain,
power switch, or strategy. Handles are names, rooted in the active scope. This allows
the association of a power domain supply set with a supply set defined in a different
scope by first setting the active scope to one in which both the supply set and the
domain or strategy are visible.
The following lists explain a few examples of UPF LRM recommended usage of
supply set handles.
Example 3.18 UPF Recommended Usage of Supply Set Handles
–– The predefined supply set handle for a power domain is as follows.
–– <domain_name>.primary
–– Supply set handles for user defined supply sets of a power domain are also
permitted.
–– The predefined supply set handle for a power-switch switch_name is
3.1 Fundamental Constructs of UPF 23

–– <switch_name>.supply
–– To note, the UPF 3.0 LRM specifies the supply as switch_supply
–– The predefined supply set handles for an isolation cell strategy isolation_name of
a power
–– domain domain_name are
–– <domain_name>.<isolation_name>.isolation_supply_set
–– If there is only one isolation supply set, or
–– <domain_name>.<isolation_name>.isolation_supply_set[index]
–– Where index starts at 0, if there are multiple isolation supply sets.
–– To note, the UPF 3.0 LRM specifies the isolation_supply_set as
isolation_supply.
–– The predefined supply set handles for a level-shifter strategy level_shifter_name
of power
–– domain domain_name are
–– <domain_name>.<level_shifter_name>.input_supply_set
–– <domain_name>.<level_shifter_name>.output_supply_set and
–– <domain_name>.<level_shifter_name>.internal_supply_set
–– To note, the UPF 3.0 LRM specifies these pre-defined level shifter handles as
input_supply, output_supply, and internal_supply respectively.
–– The predefined supply set handle for a retention strategy retention_name of a
power
–– domain domain_name is;
–– <domain_name>.<retention_name>.retention_supply_set.
–– To note, the UPF 3.0 LRM specifies this retention_supply_set as
retention_supply.
It is important to understand that the predefined supply set handles that are shown
as (.) dotted references or “dotted names” for a power domain, PSW, ISO, LS, RFF,
etc. are not necessarily the supply set or power supply syntax, for example:
.supply or
.switch_supply
These are not from the definition of create_power_domain, crate_power_
switch, set_isolation etc. And they are known as “record field names” and are
reserved in the specified context. These “records” comprise a name and a set of zero
or more values. Record field names are in a local name space of the UPF object;
e.g., a power domain may have strategies and supply set handles. Strategies them-
selves may also have supply set handles.
It is also important to understand that the dotted referencing of predefined han-
dles are also possible through the actual power supply syntax from the definition of
the commands. For example:
<domain_name>.<retention_name>.retention_supply_set
However, this is from the above list Example 3.18 and it is part of the set_reten-
tion command as follows.
24 3 Modeling UPF

[-retention_supply_set ret_supply_set]
Hence it may be summarized that supply set handles are dotted names that refer
to supply sets defined as part of a power domain, supply sets associated with UPF
strategies, supply sets associated with a power domain, and functions of a supply
set. It is visibly clear at this point that there are numerous ways to define and associ-
ate supply sets that can best be summarized as shown in the List 3.8.
List 3.8 Variations of Defining Supply Set and Association Through Supply
Set Handles
–– create_supply_set with –function
–– create_supply_set with –function and -update
–– create_power_domain –supply
–– create_power_domain –supply and –update
–– create_supply_set and associate_supply_set and –handle
–– Supply set handles with “dotted name” and “record field names”.
It is evident from the discussion in this Sect. 1.2 that the defining power supply
for a power domain and design elements explicitly impacts power supply network
distribution in UPF strategies, like ISO, LS, etc. Obviously, UPF strategies are
introduced once power domains are defined and power supplies are imposed on
them. The succeeding sections will explain the UPF power strategies from the syn-
tax, semantics, and implementation perspectives. However, it is required to define
and explain the UPF power states before the power strategies are discussed.

3.1.3 UPF Power States

The third crucial and fundamental parameter for UPF modeling are the UPF strate-
gies. However, strategies are actually based on the status of the power states of the
power supplies of the power domains. Obviously, because an ISO may be required
between an Off and an On power domain to isolate unknown value propagation;
however, the On or Off states of the corresponding power domains are revealed
through the power states of the power supplies of the domains. Hence power states
are discussed in this section before going into detail on UPF power strategies in
Sect. 1.4.
In fact, the UPF power state is the core of the entire UPF modelling and power
aware verification. The power states are defined through UPF add_power_state
commands that define one or more power states of an object. The object includes
power domains, supply sets, composite domains, groups, models, and instances.
It is worth mentioning here that power states may also be represented through the
states of a power state tables (PST), which is constructed through the combination
of add_port_state, add_pst_state, and create_pst. However these commands are
considered as legacy in UPF 2.1 LRM and onward because of their limitations to
coordinate with supply sets; specifically PST states are defined based on the supply
net only, and supply nets are usually available after the synthesis and post-layout
3.1 Fundamental Constructs of UPF 25

levels of design abstraction. In addition, there are no UPF methodologies for PST
states to refine states through DVIF, and so on.
The following Example 3.19 shows the UPF power state syntax through the
add_power_state command.
Example 3.19 UPF Power States Syntax
add_power_state object_name
[-supply | -domain]
[-state {state_name}]
[-supply_expr {boolean_expression}]
[-logic_expr {boolean_expression}]
[-simstate simstate]
[-legal | -illegal]}]*
[-complete]
[-update]

As already mentioned, the add_power_state defines one or more power states of

an object, but each power state definition is independent of any other power state
definition. Two different power states of the same object may have intersecting or
overlapping -supply_expr and (or) -logic_expr expressions. Such states may have
different legalities.
A power domain or a supply set may be in a state that matches more than one
power state definition. Hence the object, i.e. the power domain and power states, are
usually referred through the -domain and –supply, and defining any power state
through <object_name> has specific rules set by the UPF LRM, depending on the
type of objects used. The following list summarizes the rules at a glance.
List 3.9 UPF Power States <object_name> Depending on the Target Objects
–– If -supply is specified, the <object_name> must be the name of a supply set or a
supply set handle.
–– If -domain is specified, the <object_name> must be the name of a power domain.
–– If none of the above are specified, the type of <object_name> determines the
kind of object to which the command applies.
It is also important to note that in conjunction with -supply and -domain, UPF
3.0 LRM defines group, model, and instance as objects. Hence <object_name> for
such objects also requires similar rules as those shown in List 3.9.
The UPF syntax dictates that the add_power_state attributes an object with a
power state definition. The functionality and semantics of each option of the power
state syntax shown in the Example 3.19 is explained through the examples of a
complex SoC design shown in Fig. 3.3.
The SoC example is constructed with 4 CPU instances with 2 CPU cores within
each CPU cluster. The default top power domain is PD_SOC. At the SoC level there
are 2 clusters A and B and a “System Power Unit (SPCU)”, which is a power domain
PD_SPCU. Also there are interconnects and other design IPs in the design.
The “CPU Cluster A” consists of PD_CPUA0 and PD_CPUA1 power domains
that are architected in such a way so that the CPU’s can be implemented standalone.
26 3 Modeling UPF

PD_SOC SOC
PD_SPCU
System Power
IP1 IP2 IP3
Control Unit

Inter Connect Sub System

CPU Cluster A CPU Cluster B

PD_PCUA Power Control Unit PD_PCUB Power Control Unit

PD_COREA MPCore PD_COREB MPCore

L2 Cache L2 Cache

PD_CPUA0 PD_CPUA1 PD_CPUB0 PD_CPUB1

L1 Cache L1 Cache L1 Cache L1 Cache

Fig. 3.3 Example of complex SoC (Courtesy: ARM SoC)

The CPUs in a cluster shares an L2 cache and each CPU has an L1 cache. These
caches are considered as separate power domain PD_L2 and PD_L1.
In addition, each CPU cluster is also a power domain, e.g. PD_COREA. And
each possesses a secondary “Power Control Unit” confined in PD_PCUA power
domain. When the PD_COREA is turned OFF, then PD_CPUA0 and PD_CPUA1
power domains are also turned OFF. The shared L2 cache can be ON when any of
the CPU is ON. The cluster level domain PD_COREA has ON, OFF, RET, MEM_
RET power states and the core level CPUs power domain PD_CPUA0 has ON, OFF
and RET power states.
So the hierarchical and power domain boundaries are visibly clear through the
color gradation from Fig. 3.3.
As discussed so far, in order to define the power states of the SoC using add_
power_state, starting from the cluster CPUs, the recommended approach is:
List 3.10 Recommended Approach to Define Power States for Any Design
–– First create power states of the supply sets of the power domain and
–– Then create the power states of the power domain in terms of its supply sets, as
well state of any dependent power domains.
This hierarchical composition makes it possible for a SoC architect to relate the
power states of dependent IPs (includes third party IP) to the “System Level Power
States”, that is further discussed in succeeding sections.
In order to define the power states of a supply set for the PD_CPU0 power
domain in CPU Cluster A, based on the recommended approach of List 3.10, it is
3.1 Fundamental Constructs of UPF 27

required to define the power states through the primary of the supply set handle
(PD_CPUA0A0.primary), as shown in Example 3.20.
Example 3.20 Power States of a Supply Set
add_power_state PD_CPUA0.primary \
-state {ON -simstate NORMAL -logic_expr {pwr_ctrl==1}
-supply_expr {power=={FULL_ON,1.0} && ground=={FULL_ON,0}} }
-state {OFF -simstate CORRUPT -logic_expr {pwr_ctrl==0}
-supply_expr {power==OFF && ground=={FULL_ON,0}} }
Hence the add_power_state for the supply set can be defined through -logic_
expr, -supply_expr and -simstate. The logic expression is a Boolean expression
defined in terms of logic ports, logic nets, interval functions, and power states of the
given supply set or supply set handle (e.g. PD_CPUA0.primary). The supply
expression is also a Boolean expression that may reference available supply nets,
supply ports, and (or) functions of supply sets or supply set handles.
The –state <state_name> in the syntax Example 3.19 and used in Example 3.20
is a simple name of the state that is defined and also may be refined over time
throughout the DVIF.
To note, a simple name in UPF is a single identifier usually used when creating a
new object in a given scope; i.e., the identifier becomes the simple name of that
object.
The power states definition through the power domain for PD_CPUA0 is shown
below.
Example 3.21 Power States of a Power Domain
add_power_state PD_CPUA0 \
-state {ON -logic_expr {PD_CPUA0.aon==ON && PD_CPUA0.primary==ON}}
-state {RET -logic_expr {PD_CPUA0.aon==ON && PD_CPUA0.primary==OFF}}
-state {OFF -logic_expr {PD_CPUA0.aon==ON && PD_CPUA0.primary==OFF}}

In this Example 3.21, the add_power_state for the power domain is defined
only through -logic_expr, which is simply defined in terms of power states of sup-
ply sets or supply set handles, and (or) power states of lower-level power domains,
logic nets etc., but without any -supply_expr or -simstate.
From the examples, it is evident that logic_expr and supply_expr are design
logic and power supply conditions, respectively, that cause the power state to
become (or remain) active.
From Example 3.20, it is also distinctive that the -simstate option specifies the
power-related behavior of the logic expression of the power domain and implicitly
connected to the supply set. Hence –simstate plays a vital role in PA verification.
When a simstate of a supply set is the primary power of a given power domain, it
actually determines the simulation behavior of all the design elements in that
domain.
The -supply_expr specifies a Boolean expression defined in terms of supply
ports, supply nets, and (or) supply set handle functions.
28 3 Modeling UPF

Similarly the -logic_expr specifies a Boolean expression defined in terms of

logic nets and (or) power states of supply sets and (or) power domains.
The -simstate option specifies a simstate for the power states associated with a
supply set. Here the -simstate <simstate> defines a simulation state early in the
DVIF abstraction from RTL.
When a simstate of a supply set is the primary power of a given power domain,
it actually determines the simulation behavior of all the design elements in that
domain. The valid state values of simstate ranges from NORMAL to CORRUPT,
with intermediate values bearing specific significance for higher sensitivity to simu-
lation changes that could cause corruption. The corruption semantics are discussed
in Chap. 5. The following list shows the valid values for simstate.
List 3.11 Valid Values for the Simstate States
–– NORMAL,
–– CORRUPT_ON_CHANGE,
–– CORRUPT_STATE_ON_CHANGE,
–– CORRUPT_STATE_ON_ACTIVITY,
–– CORRUPT_ON_ACTIVITY,
–– CORRUPT, and
–– NOT_NORMAL.
The NOT_NORMAL simstate actually provides the flexibility to allow incre-
mental refinement to any other simstate, other than NORMAL, through add_
power_state -update commands and options. The detailed discussion of
incrementally refinable UPF is available in next Sect.3. Regarding -simstate values,
it is important to note that there are two additional predefined or default power state
values, UNDEFINED and ERROR.
These are defined for every supply set or all UPF objects. When a supply set is
defined with no -simstate the status is changed to UNDEFINED; however the
ERROR state appears only when the simstate is CORRUPT. In fact, UNDEFINED
and ERROR states are UPF 3.0 LRM semantics. The UPF 2.1 LRM does not spec-
ify UNDEFINED; instead it specifies the default DEFAULT_NORMAL, which
represents a significantly different usage perspective, specifically in dynamic simu-
lation. Although UPF 2.1, for the ERROR (or CORRUPT) states specifies a state
value termed DEFAULT_CORRUPT.
Example 3.22 Definition and Usage of Simstate
#Without -supply or -logic_expr
add_power_state PD_COREA.primary -supply \
-state {TOP_ON -simstate NORMAL} \
-state {TOP_OFF -simstate CORRUPT}
#With -supply_expr
add_power_state PD_COREA.primary –supply -update \
-state{TOP_ON -supply_expr {power=={FULL_ON 0.81} && ground=={FULL_
ON 0.00}}} \
-state{TOP_OFF -supply_expr {power=={OFF}}}
3.1 Fundamental Constructs of UPF 29

#With -logic_expr
add_power_state PD_COREA.primary –supply -update \
-state {TOP_ON -logic_expr {nPWRUP_CPU0==0}} \
-state {TOP_OFF -logic_expr {nPWRUP_CPU0==1}}
#With -simstate NORMAL, CORRUPT and with both the –logic_expr and
–supply_expr
add_power_state PD_COREA.primary -supply \
-state {TOP_ON -simstate NORMAL -supply_expr {power == FULL_ON &&
ground == FULL_ON}}\
At this point, the power state is specified with a state name that consists of a logic
expression, supply expression, and simstate. However, additional options of power
states from the syntax Example 3.19 are discussed below.
The -complete option specifies that all fundamental power states to be defined
for any object have been defined completely. This implies that all legal power states
are defined, and any state of the object that does not match a defined state is regarded
as an illegal state.
The -update indicates that this option provides additional information for a pre-
viously defined power state with the same <object_name> and that is targeted to be
executed within the same scope. Hence it is possible to define a set of power states
for a power domain or supply set and refine it incrementally though –update.
When a power state is defined with -supply_expr or with -logic_expr and refined
incrementally with another -supply_expr or –logic_expr through update, the defini-
tion becomes the conjunction of the two expressions, respectively, as shown in the
following Example 3.23.
Example 3.23 Conjunction of -supply_expr or -logic_expr Through
Incremental Update
supply_expr' = (previous -supply_expr) && (-update -supply_expr)
logic_expr' = (previous -logic_expr) && (-update -logic_expr)
It is also clear that the incremental refinement concept of power states (discussed
in further detail in succeeding Sects. 2 and 3) allows an already defined power state
to be refined through its objects if required or on demand. They derive sets of power
states for different design abstraction levels starting from the RTL and applicable up
to the PG-netlist through constraint, configuration, and implementation UPF (also
discussed in Sects. 2 and 3).
In general, the UPF LRM specifies any power state as a “named power state” that
is defined using add_power_state for a supply set and power domain. In addition,
a named power state may also be defined for following UPF attributes.
List 3.12 Attributes for Defining Named Power State
–– Composite domain,
–– Group,
–– Model, or Instance,
–– Predefined power state with ON and OFF states for supply sets, and
–– Predefined power states with UNDEFINED and ERROR states for all objects
that have power states.
30 3 Modeling UPF

However, it is also important to know that named power state may also be defined
using add_port_state, or add_pst_state for a supply set or power domain.
The following example shows the sample named power state defined through
add_power_state.
Example 3.24 Sample Named Power State
add_power_state PD_CPUA0.primary -supply \
-state {UNDEFINED -logic_expr {PD_CPUA0.primary != ON && PD_CPUA0.
primary != OFF} } \
-state {ON –simstate NORMAL \
-supply_expr {power == FULL_ON && ground == FULL_ON} } \
-state {OFF -simstate CORRUPT \
-state {ERROR -simstate CORRUPT \
-logic_expr {PD_CPUA0.primary == ON && PD_CPUA0.primary == OFF} }

The named power states shown in Example 3.24 is constructed from both –logic_
expr and –supply_expr for power domain PD_CPUA0, and its primary supply set is
denoted through the handle as PD_CPUA0.primary.
In addition it is worth to note that for the “state values” for the states of power
supply or supply set, the UPF specifies to use one of the following.
List 3.13 State Values for the Supply Set
–– OFF,
–– UNDETERMINED,
–– PARTIAL_ON,
–– FULL_ON values.
The state value represents the ability for an object to become the root supply
source to provide power. In addition to “named state”, UPF LRM further defines a
“fundamental power state” that is not a derivative or product of refinement of any
other power state of an object.
Fundamental power states of a given object are mutually exclusive and do not
refer to any other power state of the same object. The following example explains
the roots of fundamental power states of an object (i.e., power domain PD_CPUA0)
in accordance with UPF allowed attributes for defining named power states.
Example 3.25 Sample Fundamental Power State
add_power_state PD_CPUA0 -domain \
-state {UNDEFINED -logic_expr {PD_CPUA0 != RUN && PD_CPUA0 !=
SHD} } \
-state {RUN –logic_expr {primary == ON} } \
-state {SHD –logic_expr {primary == OFF} } \
-state {ERROR -logic_expr {PD_CPUA0 == RUN && PD_CPUA0 == SHD} }
So it is also clear that the fundamental power states are named power states. The
example explains UNDEFINED, ERROR, and two other RUN and SHD power
states for the PD_CPUA0 domain that are not refined at this point. Predefined power
states UNDEFINED and ERROR represent situations in which the set of power
3.1 Fundamental Constructs of UPF 31

state definitions for an object is either inconsistent or incomplete. UPF 3.0 LRM
restricts the fundamental power state active status through the following
guidelines.
List 3.14 UPF Guidelines for Specifying Fundamental Power States
–– A fundamental power state of an object will remain active whenever any refine-
ment of that power state is active.
–– Two different refinements of the same power state must be mutually exclusive.
–– The predefined ERROR power state represents the error condition in which two
states that should be mutually exclusive are both active at the same time.
–– The current power state of an object will be considered as an ERROR state when
two different fundamental states of the same object or two different refinements
of the same power state are active at the same time.
–– Two fundamental power states of the same object must not remain active at the
same time.
–– Defining a new fundamental power state is not allowed after the power states are
marked complete.
The refinement of fundamental power states through –update depends on several
factors, including their mutual-exclusion, overlapping or non-mutual exclusion,
conjunction, and disjunction of refinement possibilities and status.
The fundamental power state refinement concept extends the UPF specification
and associated PA verification boundary to early stages of RTL design and allows
verification virtually at any level of design abstraction. The concept allows an
already defined power state to be refined through objects on-demand and derives
sets of power states for different design levels of abstraction from RTL to PG-netlist.
The refinement concept is actually derived from the fundamental power states defi-
nition and their implication guidelines. The conceptual sets of refining power states
are shown in List 3.15.
List 3.15 Conceptual Sets of Fundamental Power States
1. Definite Power States,
2. Deferred Power States,
3. Indefinite Power States,
These conceptual sets of the List 3.15 are defined and explained below through
examples.
1. Definite Power States A definite power state is a power state whose defining
expression (i.e. –logic_expr {}) is made up of a single term or conjunction of terms
(i.e. usage of only “&&” operator) such that each term is one of the following:
–– A Boolean expression over signal in the design or
–– A term of the form <object> == <state>, where <object> is the name of an object
for which power states are defined and <state> is the name of a definite power
state of <object>.
The following Example explains the definition.