文章来源:
http://www.docin.com/p-1084596102.html
UPF Fundamentals – Power State Tables
Power State Table (PST) concept
Defining your power intent Power State Table (PST)
- Once you know more about what you are trying to define, specify the design switching characteristics in a power state table
- Requires knowing (or deciding) the operational voltages for each power domain, and the supplies being used.
- Must know each voltage for each supply net, in each mode
- UPF uses power state tables (PST) to define the relationship between these domains’ operational voltages
- Defines all legal voltage states and power state combinations for a design
- Captures dynamic voltage scaling (DVS/DVFS) and shutdown scenarios.
How Many States are needed?
- Mush define a state for each valid combination of supply values.
- –Example: Given 5 power domains
- Each domain with at least one supply
- Each supply with at least one value…
- –Example: Given 5 power domains
Power State Table
|
Top |
Orange |
Green |
Purple |
Blue |
FullOn |
0.8V |
1.0V |
0.8V |
0.8V |
0.8V |
LowPower |
0.8V |
1.0V |
0.8V |
0.6V |
0.8V |
LowerPower |
0.8V |
1.0V |
0.6V |
0.6V |
0.6V |
How Many States are needed?
- Shutdown quickly expands PST
- Must represent both switched and unswitched supply nets in PST
- Each shutdown supply will have at least two values
- If all shutdown supplies operate independently, even more states must be defined.
Power State Table
|
Top |
Orange |
Green pre-switch |
Purple pre-switch |
Blue pre-switch |
Green |
Purple |
Blue |
FullOn |
0.8V |
1.0V |
0.8V |
0.8V |
0.8V |
0.8V |
0.8V |
0.8V |
LowPwr |
0.8V |
1.0V |
0.8V |
0.6V |
0.8V |
0.8V |
0.6V |
0.8V |
LowerPwr |
0.8V |
1.0V |
0.6V |
0.6V |
0.6V |
0.6V |
0.6V |
0.6V |
PwrSave |
0.8V |
1.0V |
0.6V |
0.6V |
0.6V |
0.6V |
0.6V |
OFF |
Hibernate |
0.8V |
1.0V |
0.6V |
0.6V |
0.6V |
OFF |
OFF |
OFF |
Is “Always-on” Really Always on?
- For a given shutdown power domain, cells in that domain remaining powered up during shutdown are referred to as “Always-ON” (AO)
- Even if that “always-on” supply is also switchable
- Hence the concept of “relative always-on”
- An object that is powered up more than another is considered “always-on” from the perspective of that other object, regardless of whether it, too, can be shutdown.
PST
|
TOP |
PD1 |
PD2 |
ON |
0.8V |
0.8V |
0.8V |
LP |
0.8V |
0.8V |
OFF |
Sleep |
0.8V |
OFF |
OFF |
- PD1 is always-on, relative to PD2
- TOP is always-on, relative to PD2 and PD1.
Defining PST using supply Nets
Power State Table Commands
- add_port_state <port_name>
{-state {name <nom> |<min nom max> |<off>}}
--Defines all possible state information for a supply port
- create_pst <table-name> -supplieds {list}
--Create “header” of a PST, using a specific ordered list of supply nets.
- add_pst_state <state_name>
-pst <table-name> -state <supply_states>
--Defines valid combination of supply net values for each possible state of the design
Power State Table – Example
- Two power domains: TOP, pd1
- Four supplies, with these possible values
- VDD 1.08V
- VDD_PD1 1.08V, 0.7V
- VDD_PD1S 1.08V, 0.7V, OFF
- VSS 0.0V
Power State Table
There are the allowed combinations of supply values
PST Commands – Usage Tips
- You can use multiple add_port_state commands for the same port_name, as long as you are using different state identifier names
- You cannot use multiple add_pst_state commands using the same state_name
Wildcards are allowed for “don’t_care” state values in the PST
Power State Tables in Hierarchical Flow
- For the UPF, typically only one PST is defined, at the top level
- Hierarchical UPF methodology generally has PST’s being defined at the child level as well
- Notes when using Hierarchical UPF:
- Supply ports which are connected in hierarchy with connect_supply_net should have the same power state names and values defined, for error propagation to the top level
- Derived power states for which a design is checked against may not be the same as the power states defined at the top level
- Review UPF-505 warnings generated during synthesis, for ignored or partially ignored power states.
Defining PST using supply Sets
Power State Definition with Supply Sets
- Defining power states tables with supply nets and supply ports
- Use the add_port_state, create_pst, and add_pst_state commands to create the PST
- Defining power states with supply sets
- Define state information for a supply set by specifying the state of a specific supply function in the supply set
- UPF command is add_power_state instead of add_port_state
- NOTE: Supply sets mush have already been defined prior to using add_power_state
- Using the create_supply_set command
add_power_state –Command Syntax
add_power_state<object_name> -state state_name
[-supply_expr {boolean_function}]
[-logic_expr {boolen_function}]
[-simstate simstate]
Where “boolean_function” is a System Verilog Boolean expression, not tcl
- For Synopsys today, the following requirements apply:
- object_name must be a supply set name
- Only one state can be added at a time for each add_power_state command
- Only one supply set function can be referenced for each add_power_state command
- Each sate_name and supply voltage must be unique for the supply set function being defined
- Although the state_name can be reused in defining another supply set function
What is a Supply Net State?
- IEEE 1801 specification defines power state of a supply net to be one of the following:
Supply Net/Port State |
Semantic |
OFF |
Supply net/port is electrically OFF. All elements driven by it will be corrupted. |
FULL_ON |
Supply net/port is connected to a supply-drive (e.g. VRM) which is fully ON |
PARTICAL_ON |
Supply net/port is connected to multiple power switches all of which are not FULL_ON |
UNDETERMINED |
Supply net/port has no connected path to a supply-drive |
- These states are used in defining power state of a supply set function, using –supply_expr argument in the add_power_state command.
add_power_state –supply_expr
- The –supply_expr argument is used for defining the power behavior of supply nets and supply ports of a given supply set, for the power state being defined.
- For Synopsys today, this argument has the following syntax:
supply_set_function == function_state
- Where supply_set_function can be power of ground, and function_state can be one of the following:
`{status}
`{status, nom}
`{status, min, max}
`{status, min, nom, max}
- Status can be OFF or FULL_ON
- Min, nom, max are floating point numbers representing the min/nom/max voltages, respectively, of the specified state
- If status is FULL_ON, then at least one voltage must be specified
add_power_state –logic_expr
- The –logic_expr argument dictates when a particular state is TRUE; it is used for defining the behavior of supply sets, in terms of logic nets and supply nets
- Boolean expression evaluates to TRUE when the object_name is the state being defined
- Simple example: series of equality/inequality subexpressions of supply set (or power domain) comparisons to state names –logic_expr {core_pd == turbo && ram_pd != sleep}
- But can also be more complex expressions, to include logic events such as clock gating or frequency constraints in defining power state
- For synopsis today, this arguments is ignored in implementation tools and is used only by verification tools
- Used by simulation to determine in what state a domain exists, at a given time in simulation.
add_power_state –UPF Example
NOTE: Example assumes flat (single-scope) mode for all supply sets to be available globally.
- Two power domains: TOP, pd1
- Four supply nets, with these possible values
- VDD 1.08V
- VDD_PD1 1.08V, 0.7V
- VDD_PD1S 1.08V, 0.7V, OFF
- VSS 0.0V
- Three supply sets:
- ssTOP – primary supply set for the TOP domain, where
- ssTOP.power == VDD
- ssTOP.ground == VSS
- ssTOP – primary supply set for the TOP domain, where
- ssPD1 – primary supply set for the pd1 domain, where
- ssPD1.power == VDD_PD1S
- ssPD1.ground == VSS
- ssPD1_unswitched –always-on supply set, used for ISO, RR, etc.
- ssPD1_unswithed.power == VDD_PD1
- ssPD1_unswitchd.ground == VSS
Is a PST Still Needed when Using Supply Sets?
- add_power_state defines the state of a supply
- PST defines the relationship between supplies’ states
- Without a PST, the full cross-product of all supplies states will be assumed in implementation
- If this is the desired implementation, a PST is not necessary, but tool performance will be significantly slower
- Current recommendation is to continue using PST’s in designs using supply sets
- Can use supply nets and ports for the PST commands, or can use supply set handles (<supply_set_name.function>)