UPF For Low Power 2014

Using UPF for
Low Power Design and Verification

Tutorial #2: presented by members of the IEEE P1801 WG
John Biggs
Erich Marschner
Sushma Honnavara-Prasad
David Cheng
Shreedhar Ramachandra
Jon Worthington
Nagu Dhanwada
Welcome and Introductions
Erich Marschner
Verification Architect
Mentor Graphics
Using UPF for Low Power Design and Verification © 2014 Mentor Graphics 3 March 2014 2
Tutorial #2
 This tutorial presents the latest information on the Unified

Power Format (UPF), based on IEEE Std 1801-2013 UPF
which was released in late May of last year.
 Beginning with a review of the concepts, terminology,
commands, and options provided by UPF, it will cover the
full spectrum of UPF capabilities and methodology, from
basic flows through advanced applications, with particular
focus on incremental adoption of UPF.
 Tutorial attendees will come away with a thorough
understanding of UPF usage in low power design and
verification and its role in energy aware system design.
Takeaways
 Why power is important - and challenging

 How power affects implementation decisions
 What UPF is and what problems it addresses
 How UPF enables early consideration of power
 UPF concepts, commands, semantics, and usage
 UPF methodology for modeling, design, integration
 How UPF can be adopted most effectively
 What else we need to address related to power
Presenters
 John Biggs, ARM Ltd.

– Chair, IEEE P1801 UPF Work Group
 Erich Marschner, Mentor Graphics

– Vice-Chair, IEEE P1801 UPF Work Group
 Sushma Honnavara-Prasad, Broadcom

– Secretary, IEEE P1801 UPF Work Group
 David Cheng, Cadence

– Member, IEEE P1801 UPF Work Group
 Shreedhar Ramachandra, Synopsys

Other Contributors
 Jon Worthington, Synopsys

 Nagu Dhanwada, IBM

– Member, Si2 LPC and LPSG
Agenda
 Welcome & Introductions  Hard IP Modeling with Liberty
– Erich Marschner and Verilog
– Sushma Honnavara-Prasad
 Low Power Design and
Verification Challenges  Power Management Cell
– Erich Marschner Commands and Power Models
– David Cheng
 Introduction to UPF
– John Biggs  Low Power Design Methodology
for IP Providers
 UPF Basic Concepts and
– John Biggs
Terminology
– Shreedhar Ramachandra  SoC-Level Design and
Verification Challenges
 UPF Semantics and Usage
– Erich Marschner
 Adopting UPF
 BREAK
– Shreedhar Ramachandra
 Where We Go From Here

– John Biggs
Low Power Design and
Verification Challenges*
Erich Marschner
Mentor Graphics
* With slides contributed by Nagu Dhanwada and Sushma Honnavara-Prasad
Low Power Design Challenges
 Power density is increasing every process node

– Higher performance
– Lower area
– > Designs are thermally limited
– > No single technique serves all purposes
– > Aggressive power gating is used to minimize leakage
 Number of power domains and supplies on chip is
increasing
– Early architecture decisions impacts power, so early power
exploration is critical
Using UPF for Low Power Design and Verification © 2014 Broadcom 3 March 2014 9
SoC Low Power Design Challenges
 Reducing power with:

– low area overhead
– high performance
– low schedule impact
 Early power estimation and budgeting

– Silicon variation
– Correlation of models with Si data
– Lack of use case vectors
 Power aware flow

– Making all phases of design power aware
– Capturing power intent accurately
– Ensuring power intent is correctly implemented
– Verifying power intent with firmware/Software drivers
Three Phases of a Power Aware Flow
 ESL (algorithm and

system models) ESL
– Functionality
Design & Analysis &
– Architecture mapping Optimization
Validation
– TLM
– Firmware
Design
 Design (RTL and IP) Design & Analysis & Verification
– RTL module integration optimization and test
design/selection
– IP selection and
Chip integration Implementation
Analysis & Verification &
 Implementation Optimization
closure test
– Synthesis
– Physical design
Using UPF for Low Power Design and Verification © 2014 IBM 3 March 2014 11
Power Analysis is Required Throughout*
* But with varying criteria:
TPC/IPC performance
Architecture
Greatest power
savings opportunity
Floorplan
(design exploration)
Power grid / thermal analysis

Power consumption analysis
Need High level
Power minimization
faster analysis, models
(arch. verif.)
can afford lower
accuracy / detail
RTL
Static timing (CPS)
reliability analysis
Tech. map
Timing, noise,
Automated / Manual
power reduction Design
closure
Need
higher accuracy, can Place & route
afford longer run times
Signoff
No Single Metric Handles Everything
 Battery Life
–Total chip power over long time period
 Package Inductance
–Total chip power over short time period
 Reliability / Electromigration
–Very local power over a very long time period
 Static IR Drop
–Local power over moderate time period
 Decap / Transient IR drop
–Local power over very short time periods
Power-Awareness Needed in Each Phase
Design Phase Low Power Design Activities
ESL Design
• Explore architectures and algorithms for power efficiency
• Map functions to sw and/or IP blocks for power efficiency
Design & Analysis &
• Choose voltages and frequencies
Validation
mapping optimization • Evaluate power consumption for each operational mode
• Generate budgets for power, performance, area
RTL Design
• Generate RTL to match system-level model
• Select IP blocks
Design & Analysis & Verification
• Analyze and optimize power at module and chip levels
integration optimization & Test • Analyze power implications of test features
• Check power against budget for various modes
Implementation • Synthesize RTL to gates using power optimizations

• Floorplan, place and route design
Optimization
Analysis &
Closure
Verification
& Test
• Optimize dynamic and leakage power
• Verify power budgets and power delivery
Power Analysis Flow at ESL
Workloads / Power Analysis

Stimulus Power Models
Architecture parameters
Power
Benchmark (Initial Configuration) Intent
Programs/Traces
Early Analytical Performance
Models
Simulator
SystemC
Trace/Execution driven
Transaction Level Models
Trace/Execution driven Cycle Power Models
Random Stimulus Accurate Models
Generators
Power Calculation
Power
Optimization and Refinement
Reports
Power RTL Design

Intent And Simulation
Power Analysis Flow at RTL
Workloads / Power Analysis

Stimulus Power Models
Architecture parameters
Power
Benchmark (Initial Configuration) Intent
Programs/Traces
Simulator
VHDL/Verilog
RTL Description
Power Models
Random Stimulus
Generators
Power Calculation
Power
Optimization and Refinement
Reports
Power Implementation
Intent Level
System-to-Silicon
Power Aware Design Flow
ESL Design Power

Data
Design & Analysis &
Validation
mapping optimization
RTL Design
Power
Design & Analysis & Verification
Models Integration optimization & Test
Implementation
Optimization Verification
Analysis
& Closure & Test
Where Are the Models?
 Flow execution is limited

by model availability
ESL Design Power
– Implementation tasks rely upon Data
No standard today
gate level models
Design & Analysis & Validatio
– RTL tasks rely upon gate level mapping optimization n
models (directly or indirectly)

– ESL? …. Ad hoc solutions…
RTL Design
 What about IP blocks?
Power
– Behavioral models are available Models Design & Analysis & Verificatio
for ESL & RTL, but without power Integration optimization n & Test
– Simplistic power models may be

available, …accuracy? reliability?
Liberty
Implementation
 We have a problem
– Gate level models can be used Optimization
Analysis
Verificatio
& Closure n & Test
for IP power simulations, but
simulation time and resources
are prohibitive
Must Handle Different Kinds of Models
Function
Algorithmic Spec
parameters
(SystemC)
Untimed Protocol
Transaction
Level
(SystemC) Timed Protocol
Cycle Accurate Cycle Protocol

(Pin Level) Simulation
Register Transfer RTC Protocol

Level
Register Transfer Protocol

RTL
Level HDL
Modeling Paradigms and Use Scenarios
ANSI C/C++ ANSI C/C++ or Algorithmic SystemC

Input f(a) f(b) f(c) f(d)
(System Data)  Used to functionally verify algorithm, with no
Output focus on implementation issues.
Sequential
 HW and SW algorithms are described in the
same way.
 At best design is partitioned into functional
blocks, but what lies in software or hardware is
not considered.
Untimed TLM “Untimed” SystemC Transaction Level Model

f(c)
 Used to manually partition system.
f(a) f(b) f(d)
 No reset, clocks, or timing, but enough
Hierarchy, Concurrency synchronization to enable correct functionality.
 Instruction set simulation models / virtual platforms
for embedded software development would fall into
this category.
Timed TLM “Timed” SystemC Transaction Level Model

c
 Used to design and test the “system timing budget”.
a  Models have timing information, transactions will
b
FIFO d take correct number of clock cycles to execute but
Hierarchy, Concurrency & Timing
not every clock accounted for within transactions.
 Specialized structures (FIFOs) absorb irregular data
rates.
 Budget defines synthesis constraints for each block.
Cycle Accurate Model Cycle Accurate “Behavioral” SystemC Model

Clock1
Clock2  Used to verify cycle level and system behavior at a
low level.
FIFO
 Models clocking in detail, i.e all clocks ticking.
Interface Pin & Cycle Accurate  Model full pin and cycle timing at block interfaces.
 Behaves as RTL but optimized internally for speed.
RTL Model
RTL Model
Clock1
Clock2
 Model used for implementation via RTL synthesis.
 Completely cycle accurate (external and internal).
FIFO
 Logic between clock ticks is simulated.
Inter-Block Pin & Cycle Accurate
Mixed Abstraction Mixed Abstraction Level Modeling

Clock2  Used for mixed mode system/block verification.
 “transactors or adaptors” are used to connect
different abstractions within a system.
Adaptor
SoC Low Power Verification Challenges
 Modeling issues
– Are all the low power features
correctly represented?
 Capacity issues
– Number of domains
– Size of the chip
 Complexity issues
– Chip-level power state complexity
– Complex interactions between blocks
 Coverage issue
– Power state coverage
– System level use cases Source: Synopsys 2012 global user survey
– H/W-S/W co-verification
So Where Does UPF Fit In?
 UPF models active power management

– A form of power optimization
 UPF Power Intent applies at RTL and GL today
– RTL for “early” verification and to drive implementation flow
– GL for verification of implementation stages
 UPF concepts can be extended to other models
– Power states and transitions in particular
– Component-based modeling paradigm can also apply
Introduction to UPF
John Biggs
Senior Principal Engineer
ARM
Using UPF for Low Power Design and Verification © 2014 ARM Ltd 3 March 2014 25
What is UPF?
Power Intent
File(s)
HDL/
RTL
 An Evolving Standard
Simulation, Logical Equivalence Checking, …

– Accellera UPF in 2007 (1.0)
– IEEE 1801-2009 UPF (2.0)
Synthesis
– IEEE 1801-2013 UPF (2.1)
 For Power Intent

– To define power management
– To minimize power consumption Power Intent
File(s)
 Based upon Tcl Verilog
(Netlist)
– Tcl syntax and semantics
– Can be mixed with non-UPF Tcl
 And HDLs
– SystemVerilog, Verilog, VHDL P&R
 For Verification
– Simulation or Emulation
– Static/Formal Verification Power Intent
File(s)
 And for Implementation Verilog
(Netlist)
– Synthesis, DFT, P&R, etc.
Components of UPF
 Power Domain:
– Groups of elements which share a common set of power
supply requirements
 Power Supply Network

– Abstract description of power distribution (ports, nets,
sets & switches)
 Power State Table

– The legal combinations of states of each power domain
 Isolation Strategies
– How the interface to a power domain should be isolated
when its primary power supply is removed
 Retention Strategies
– What registered state in a power domain should be
retained when its primary power supply is removed
 Level Shifter Strategies

– How signals connecting power domains operating at
different voltages should be shifted
 Repeater Strategies
– How domain ports should be bufffered
P1801: IEEE-SA Entity Based Work Group
IEEE 1801 (UPF) timeline
UPF-1.0 UPF-1.0 New Project CPF-2.0 New Project New Project

Kick off Donated Revision of Donated Revision of Amendment of
Meeting to IEEE 1801-2009 to IEEE 1801-2013 1801-2013
2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
Accellera IEEE1801-2009 1801-2013 1801a-2014 1801-2016

UPF-1.0 (AKA UPF-2.0) (AKA UPF-2.1) (Amendment) (AKA UPF-3.0)
Published Published Published Planned Planned
Key:
- Accellera UPF-1.0 (2007)
Accellera UPF-1.0 (2007)

Navigation:
- set_scope
- set_design_top
Supply Nets: HDL Interface:

- create_supply_port - bind_checker
- create_supply_net - create_hdl2upf_vct
- connect_supply_net - create_upf2hdl_vct
- create_power_switch
Code Management:
Power Domains: - upf_version
- create_power_domain Strategies: - load_upf
- set_domain_supply_net - save_upf
- set_retention
- set_retention_control
Power States: - set_isolation
- add_port_state - set_isolation_control
- create_pst - set_level_shifter
- add_pst_state
Implementation:
- map_retention_cell
- map_isolation_cell
- map_level_shifter_cell
- map_power_switch_cell
Key:
IEEE 1801-2009 (UPF-2.0)

- IEEE 1801-2009 (UPF-2.0)
Navigation: Attributes: Control Logic:

- set_scope - set_port_attributes - create_logic_port
- set_design_top - set_design_attributes - create_logic_net
- HDL and Liberty attributes - connect_logic_net
Supply Nets: Supply Sets: HDL Interface:

- create_supply_port - create_supply_set - bind_checker
- create_supply_net - supply set handles - create_hdl2upf_vct
- connect_supply_net - associate_supply_set - create_upf2hdl_vct
- create_power_switch - connect_supply_set
Code Management:
- set_domain_supply_net - save_upf
- create_composite_domain - set_retention_elements - load_upf_protected
- set_retention - load_simstate_behavior
- set_retention_control - find_objects
Power States: - set_isolation
- add_port_state - set_isolation_control
- create_pst - set_level_shifter
- add_pst_state
- add_power_state
- describe_state_transition Implementation:
- map_retention_cell
- map_isolation_cell
Simstates: - map_level_shifter_cell
- add_power_state - map_power_switch_cell
- set_simstate_behavior - use_interface_cell
Key:
IEEE 1801-2013 (UPF-2.1)

- IEEE 1801-2009 (UPF-2.0)
- IEEE 1801-2013 (UPF-2.1)
- Deprecated/Legacy
Navigation: Attributes: Control Logic:

- set_scope - set_port_attributes - create_logic_port
- set_design_top - set_design_attributes - create_logic_net
- HDL and Liberty attributes - connect_logic_net
Supply Nets: Supply Sets: HDL Interface:

- create_supply_port - create_supply_set - bind_checker
- create_supply_net - supply set handles - create_hdl2upf_vct
- connect_supply_net - associate_supply_set - create_upf2hdl_vct
- create_power_switch - connect_supply_set
- set_equivalent Code Management:
- set_domain_supply_net - set_repeater - save_upf
- create_composite_domain - set_retention_elements - load_upf_protected
- set_retention - load_simstate_behavior
- set_retention_control - find_objects
Power States: - set_isolation - begin_power_model
- add_port_state - set_isolation_control - end_power_model
- create_pst - set_level_shifter - apply_power_model
- add_pst_state
- add_power_state
Implementation: Power Management Cells:
- describe_state_transition
- map_retention_cell - define_always_on_cell
- map_isolation_cell - define_diode_clamp
- map_level_shifter_cell - define_isolation_cell
Simstates:
- map_power_switch_cell - define_level_shifter_cell
- add_power_state
- use_interface_cell - define_power_switch_cell
- set_simstate_behavior
- define_retention_cell
The IEEE 1801-2013 Standard
 Motivation
– Address known issues with 1801-2009
• Improve the clarity and consistency
– Syntax clarifications, semantic clarifications
• Some restrictions, some additions
– Include limited number of critical enhancements
• Improved support for macro cell modeling
• Attribution library pins/cells with low power meta data
 Additional contributions:
– Cadence: Library Cell Modeling Guide Using CPF
– Cadence: Hierarchical Power Intent Modeling Guide Using CPF
– Si2: Common Power Format Specification, Version 2.0
=> Improved methodology convergence with CPF flows
The IEEE 1801-2013 Standard
 Revisited each and every command

– Rewrote the major strategy commands
 Rewrote many key sections:

– Definitions, UPF Concepts, Language Basics, Simulation Semantics
 Added new sections:

– Power management cell commands, UPF processing,
– Informative Annex on Low Power Design Methodology
 Final Draft (D14) approved by IEEE-SA March 2013

– A 95% (19/20) approval rate on a 95% (20/21) return.
– One the largest entity base ballot pools in IEEE-SA history
 IEEE1801-2013 Published May 30th 2013

– Available at no charge via the IEEE Get™Program
• http://standards.ieee.org/findstds/standard/1801-2013.html
• http://standards.ieee.org/getieee/1801/download/1801-2013.pdf
35
UPF Basic Concepts
and Terminology*
Shreedhar Ramachandra
Staff Engineer
Synopsys
* Slides contributed by Jon Worthington
Using UPF for Low Power Design and Verification © 2014 Synopsys 3 March 2014 36
Functional Intent vs. Power Intent
What is the difference?
Functional intent specifies Power intent specifies
• Architecture • Power distribution

• Design hierarchy architecture
• Data path • Power domains
• Custom blocks • Supply rails
• Application • Shutdown control
• State machines • Power strategy
• Combinatorial logic • Power state tables
• I/Os • Operating voltages
• EX: DSP, Cache • Usage of special cells
• Usage of IP • Isolation cells, Level shifters
• Industry-standard interfaces • Power switches
• Memories • Retention registers
• etc
Captured in RTL Captured in UPF
How Power Intent Affects
Implementation
 The power intent will
have an impact on the
implementation of the
design.
– Domains may need
separate
floorplans/regions.
– Cells may need
special power routing.
 This section will
introduce power
intent concepts in UPF
and how they relate
to implementation.
Power Domains
Defined as: PDTop

– A collection of
instances that are PD2
PD1
treated as a group for Block2
power management Block11
purposes. The
Block12
instances of a power
domain typically, but Block13
do not always, share a
primary supply set. ...
Power Domain PD1 contains 3 instances

Power Domain PD2 contains only Block2
UPF - Power Domains Domain names are created
in the new scope (P2)
Domain names are created
in the current scope (Sub)
Sub
 create_power_domain
set_scope Sub P1 PwrCtl P2
create_power_domain PD_Sub \
-include_scope
M1 M2 M1 M2
create_power_domain PD_Proc1 \
-elements {P1}
create_power_domain PD_Proc1Mem \ Sub/PD_Sub
Sub
-elements {P1/M1 P1/M2} PwrCtl
set_scope P2
Sub/PD_Proc1 PD_Proc2
create_power_domain PD_Proc2 \
-include_scope P1 P2
create_power_domain PD_Proc2Mem \
-elements {P2/M1 P2/M2}
M1 M2 M1 M2
Sub/PD_Proc1Mem PD_Proc2Mem
Power Supply Network
 Describes logical connectivity of the

power supplies, or power rails in
PDTop your design
– May include connectivity through
VDDSS2
PD1 PD2 power switches
sw_ctrl
VDDSS1
VDD_SW
Digital2
VDDSS1
Analog
UPF Power Supply Networks
- Supply Sets Supply Nets Supply Set Functions
power
 A group of related supply nets PD.primary
ground
power
 Functions represent nets Main ground
nwell
– which can be defined later pwell
deepnwell
 Electrically complete model deeppwell
– power, ground, etc.
create_power_domain PD \
 Predefined supply sets -supply {primary} \ (predefined)
-supply {backup} (user-defined)
– for domains
 User-defined supply sets create_supply_set Main \ (user-defined)

– for domains (local) -function {power} \
-function {ground} \
– standalone (global) -function {nwell}
 Supply set parameters
– for strategies set_isolation ISO –domain PD \
-isolation_supply_set PD.backup
How Logical Supply Networks Relate
to Real World Connections
 The functions in a supply set will translate into real
supply net connections.
– Often a domain’s ‘primary’ function will be
implemented as the rails within a floorplan region,
VDD and VSS in this example.
– The other functions will be routed as secondary

supplies and connect to special pins on the cell. The
example here shows a levelshifter cell with a
secondary pin called VDDL that connects to VDD2.
– Secondary supplies may be primary supplies of other

domains. Therefore the location of special cells may
result in supplies from other domains to be available at
the location where the cell is inserted.
create_supply_set top_ss\
-function {power VDD} \
-function {ground VSS}
associate_supply_set top_ss\
-handle PD.primary
Power Management Techniques
 Power Gating
 Multi-voltage
 Bias Voltage
 Dynamic Voltage and Frequency Scaling
Power Gating
Power reduction technique
to save leakage power by
VDD shutting off, or powering
down, unnecessary logic
on/off Sleepin Sleepout
VDD_SW Enabled by power switch,

or MTCMOS, cells
Gate Gate Gate Gate Gate
Requires consideration of
isolating and state
VSS retention.
Multi-Voltage
0.8
Power savings Design Top
V
technique to operate 0.8

FSM
different blocks of logic V
0.8
Block2 V
at different voltages
– Less critical blocks can be 1.2
operated at a lower Block1 V
voltage 0.8
for power savings Macro V
1.2 0.8
Macro V Macro V
Bias Voltage
 Used to change the threshold voltage of a cell to

improve the leakage characteristics of the cell
Dynamic Voltage and Frequency
Scaling
0.8
 Power Saving Technique to V
0.6
change the voltage and/or Design Top V
clock frequency while the chip 0.6
0.8
is running to save power FSM V 0.8
Block2 V
0.6
V
1.2
Block1 V
0.8
V 0.8
Macro V
0.6
V
1.2 0.8
Macro V
0.8
Macro V
0.6
V V
Power Management Architecture
 Power States and Transitions

 Supply switching
 Isolation and Level Shifting
 State Retention
Power States and Transitions
 A design may have

multiple modes of Idle
operation that affect the
power supplies.
 Modelling these modes will
allow tools to verify and
implement the power
intent. For example;
– Simulation: States can indicate
that correct isolation has been Sleep Run
specified.
– Implementation: Correct
levelshifting can be inserted.
– Verification: Confirm that the
design is still correct after
optimization.
Using UPF for Low Power Design and Verification 3 March 2014 50
UPF Power States
 UPF uses ‘add_power_state’ Proc1/PD_Proc P M
to define the states of
supplies.
Proc1
P1
add_power_state PD_Mem \
-state RUN {-logic_expr {primary ==
ON_08}} \ P
-state OFF {-logic_expr {primary == OFF}} M1 M2
Proc1/PD_Mem
add_power_state PD_Proc \
-state Normal { \
-logic_expr {primary == ON_10 && \
memory == ON_08 && \
PD_Mem == RUN} } \
PD_PROC primary memory PD_MEM
-state Sleep { \
-logic_expr {primary == OFF && \ Normal ON_10 ON_08 RUN
memory == ON_08 && \
PD_Mem == RUN} } \ Sleep OFF ON_08 RUN
-state Hibernate { \
-logic_expr {primary == OFF && \ Hibernate OFF OFF OFF
memory == OFF && \
PD_Mem == OFF} }
Supply Switching/Power Gating
vdd
 Supplies can be switched off to
save power when they are not
needed. This can be done off or on enable
chip.
 On-chip switching can be
implemented by number of vdds
methods including fine/course
grain switch cells. vss
 UPF will allow a switch construct to
be declared to represent the
switching state of the supplies.
The supplies, their states and
controlling signals are all defined
however how it is implemented is
not specified.
UPF - Power Gating
Proc1/PD_Proc P M
create_logic_port nPWR1 –direction in

Proc1
P1
nPWR
create_power_switch SW -domain PD_Proc

-input_supply_port {sw_in VDDSOC} P
-output_supply_port {sw_out VDDPROC1} M1 M2
-control_port {sw_ctl nPWR}
-on_state {on_state sw_in {!sw_ctl}} Proc1/PD_Mem
-off_state {off_state { sw_ctl}}
Normal ON_10 ON_08 RUN
Sleep OFF ON_08 RUN
Hibernate OFF OFF OFF
Coarse Grain Switch Implementation
 A UPF switch may be implemented as an array of

switches all connected together to switch as one.
 The switches power the standard cell rows and use
power meshes to connect the secondary supply.
Isolation Cells
Isolation cells are

typically used to
protect logic that is
powered on from logic
that is powered off
– Used to prevent unknown
values in unpowered
logic from propagating
into live logic
– Can also be used to
prevent leakage current
from live logic from
improperly powering
unpowered logic
UPF Isolation Strategies
Proc1/PD_Proc P M
set_isolation ISO_Proc \
Proc1
P1
-domain PD_Proc \
-applies_to outputs \ nPWR
-clamp_value 0 \
P
-isolation_signal mISO \
-isolation_sense low \ M1 M2
-location self Proc1/PD_Mem
use_interface_cell ISOX1 \
-domain PD_Mem \
-strategy ISOMem \ PD_PROC primary memory PD_MEM
-lib_cells {TechISOX1}
Sleep OFF ON_08 RUN
Level Shifters
 Changes the voltage from one discrete

value to another discrete value
– A 1’b1 driven by 1.0V logic may be
1.0V 0.7V too much for 0.7V logic and likewise a
1’b1 from 0.7V logic may not
translate into a 1’b1 for 1.0V logic
LS – A level shifter changes a 0.7V 1’b1 to
a 1.0V 1’b1 so you are propagating
valid digital values through the circuit
LS
UPF Level Shifting Strategies

Proc1/PD_Proc P M
set_level_shifter LSmem \ Proc1

P1
-domain PD_Mem \
-applies_to outputs \ nPWR
-location self
P
LS
LS
M1 M2
use_interface_cell LSX2 \ Proc1/PD_Mem

-domain PD_Mem \
-strategy LSMem \
-lib_cells {TechLSX2}
Sleep OFF ON_08 RUN
State Retention
 A sequential element that can

retain its value despite being VDD
powered off VDDB
– Useful to recover the last
known state of the design when
power was removed SAVE RR
– Reduces the amount of time RESTORE
needed reset a design to a
specific state to continue VSS
operation
Retention
Register
RR
UPF Retention Strategies
Proc1/PD_Proc P M
SRb
set_retention RET1 \
RR
Proc1
P1
-domain PD_Proc \
-save_signal {SRb posedge} \ nPWR
-restore_signal {SRb negedge}

P
M1 M2
map_retention_cell RET1 \ Proc1/PD_Mem
-domain PD_Proc \
-lib_cells {TechRRX4}
Sleep OFF ON_08 RUN
Multi-Voltage Special Cell Requirement
Power
Level Isolation Retention Always-
Switches
Shifters Cells Registers on Logic
(MTCMOS)
0.9V Multiple
0.7V 0.9V
Voltage (MV)
Domains

Multi-Supply
OFF
with Shutdown
 
0.9V
No State
0.9V 0.9V
Retention
OFF Multi-Voltage
with
0.9V
0.7V 0.9V
Shutdown   
OFF
Multi-Voltage
with Shutdown

SR
0.9V
& State    
0.7V 0.9V Retention
UPF Semantics and Usage
Erich Marschner
Mentor Graphics
A Deeper Look at UPF Power Intent
 Logic Hierarchy
 Power Domains
 Power Domain Supplies
 Supply Sets
 Supply Connections
 Power Related Attributes
 Power Domain State Retention
 Power Domain Interface Management
 Supply Network Construction
 Supply Equivalence
Logic Hierarchy
 Design Hierarchy
– A hierarchical description in HDL
 Logic Hierarchy
– An abstraction of the design hierarchy (instances only)
 Scope
– An instance in the logic hierarchy
 Design Top
– The topmost scope/instance in the logic hierarchy to which a
given UPF file applies
Logic Hierarchy
 Design Hierarchy UPF

– Instances, generate stmts,
block stmts, etc. Sub
 Logic Hierarchy
– Instances only P1 PwrCtl P2
– UPF objects
• Created in instance scopes M1 M2 M1 M2
• Referenced with hierarchical
names
 Mapping to Floorplan
– May or may not reflect
implementation
• Depends upon the user and tools
Navigation
 set_design_top DUT TB
set_design_top TB/Sub
Sub SB
 set_scope
set_scope .
P1 PwrCtl P2
set_scope P1/M1
set_scope ..
set_scope M2 M1 M2 M1 M2
set_scope /P2
Note:
These are all instance names
Logic Hierarchy
module
instance
Highconn Top
of a port
Lowconn functional
of a port element
A B
C D E F
macro
instance
M1 M2 M3 M4 M5 M6 M7 M8
Power Domains
 Partition the Logic Hierarchy

– Every instance must be in (the extent of) exactly one domain
 Can be further partitioned
– A subtree of the design can be carved out as another domain
 Unless declared “atomic”
– Atomic power domains cannot be further subdivided
 Can be composed into larger domains
– If all subdomains have the same primary power supply
 Have an upper and a lower boundary
– Boundaries represent a change in primary supply
Partitioning the Logic Hierarchy - 1
create_power_domain PD1 -elements {.} …
PD1
Top
A B
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
create_power_domain PD2 -elements {A} …
PD1
PD1 Top
Lower
Boundary
PD2
PD2 A B
Upper
Boundary
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
create_power_domain PD3 -elements {B} …
PD1
Top
PD2 PD3
A B
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
create_power_domain PD4 -elements {A/D B/E} -atomic …
PD1
Top
PD2
Upper
Boundary PD2 PD3
A B
PD2
Lower
Boundary PD4
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
Atomic domain cannot be further partitioned
create_composite_domain PD23 -subdomains {PD2 PD3} …
PD1
Top
PD23
Upper
Boundary PD2
(PD2) (PD3)
PD3
A B
PD23
PD23
Lower
Boundary PD4
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
Power Domain Boundaries
 Define Domain Interfaces

– Isolation/Level shifting are only inserted at power domain
boundaries
 Upper Boundary
– Includes lowconn of declared ports of “top-level” instances
 Lower Boundary
– Includes highconn of ports of instances in another domain
– Includes macro instance ports with different supplies
 Macro Instances
– May have multiple supplies
– Each port may have a different supply
Domain Supplies
 Primary supply
– Provides the main power, ground supplies for cells in the domain
– Can also provide additional supplies (nwell, pwell, …)
 Default retention supply
– Provides a default supply for saving the state of registers
 Default isolation supply
– Provides a default supply for input or output isolation
 Additional user-defined supplies
– Can be defined for particular needs (e.g., hard macros)
 Available supplies
– Can be used by tools to power buffers used in implementation
Power Domain Supply Sets
create_power_domain PD1 -supply
… {AO} …
P R I AO
Primary, PD1
Retention, Top User-
Isolation Defined
Supplies Supply
PD2
(PD2) PD3
(PD3)
A B
PD23
PD4
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
Supply Sets
 Consists of a set of up to 6 supply “functions”

– power, ground, nwell, pwell, deepnwell, deeppwell
 Represent a collection of supply nets
– One supply net per (required) function
 Can be “global” or “local” to a power domain
– Power domains have a few predefined supply set “handles”
 Can be associated with one another
– To model supply connections abstractly
 Have power states with simstates
– Determine domain functionality in power aware simulation
Supply Sets Supply Nets Supply Set Functions
power
PD.primary ground
 A group of related supply nets
power
 Functions represent nets Main ground
nwell
– which can be defined later
pwell
deepnwell
 Electrically complete model deeppwell
– power, ground, etc.
create_power_domain PD \
 Predefined supply sets -supply {primary} \ (predefined)
-supply {backup} (user-defined)
– for domains
 User-defined supply sets create_supply_set Main \ (user-defined)

– for domains (local) -function {power} \
-function {ground} \
– standalone (global) -function {nwell}
 Supply set parameters
– for strategies set_isolation ISO –domain PD \
-isolation_supply_set PD.backup
Associating Supply Sets 1
associate_supply_set PD1.primary -handle PD2.primary
P R I AO
PD1
Supply Top
Set
Association
P
PD2
(PD2) PD3
(PD3)
A B
PD23
PD4
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
Associating Supply Sets 2
associate_supply_set PD1.AO -handle PD3.AO
P R I AO
PD1
Top Supply
Set
Association
P AO
PD2
(PD2) PD3
(PD3)
A B
PD23
PD4
C D E F
M1 M2 M3 M4 M5 M6 M7 M8
Supply Connections
 Implicit connections
– Primary supply is implicitly connected to std cells
 Automatic connections
– Supplies can be connected to cell pins based on pg_type
 Explicit connections
– Supplies can be connected explicitly to a given pin
 Precedence rules apply
– Explicit overrides Automatic overrides Implicit
 Supply states determine cell behavior
– Cells function when supply is on,
– Cells outputs are corrupted when supply is off
Implicit Supply Connections
…
P R I AO
PD1
Top
P AO
PD2
(PD2) PD3
(PD3)
A B
PD23
Implicit
Connections:
power, ground PD4
only C D E F
M1 M2 M3 M4 M5 M6 M7 M8
PG Types
 Describe the usage of supply pins of cells, macros

– primary_power, primary_ground
– backup_power, backup_ground
– internal_power, internal_ground
– nwell, pwell, deepnwell, deeppwell
 Typically defined in Liberty library models
– primary power/ground are common to all
 Can also be defined in HDL or UPF
– Using attributes …
 Drive implicit and automatic supply connections
– Each function of a domain supply set maps to a pg_type
Automatic Supply Connections
connect_supply_set PD3.AO -elements {B/F/M7 B/F/M8}
P R I AO
PD1
Top
P AO
PD2
(PD2) PD3
(PD3)
A B
PD23
Automatic
Connections
PD4 based on
C D E F pg_type
M1 M2 M3 M4 M5 M6 M7 M8
PG Type-Driven Connections
 Automatic connection
connect_supply_set PD3.AO -elements {B/F/M7 B/F/M8} \
-connect {power primary_power} \
-connect {ground primary_ground}
connect_supply_set PD3.AO -elements {B/F/M7 B/F/M8} \

-connect {power backup_power} \
-connect {ground backup_ground}
 Implicit connection
– Equivalent to
connect_supply_set PD2.primary -elements {.} \
-connect {power primary_power} \
-connect {ground primary_ground}
Explicit Supply Connections
connect_supply_net PD3.AO.power -ports {B/F/M7/VDDB …}
P R I AO
PD1
Top
P AO
PD2
(PD2) PD3
(PD3)
A B
PD23
Explicit
Connection
PD4 to specific
C D E F ports
M1 M2 M3 M4 M5 M6 M7 M8
Power Attributes
 Characteristics of a port or design element

– That relate to power intent or implementation
 Defined in UPF, HDL, or Liberty
– Liberty and HDL attributes are imported into UPF
 Used to identify power supplies for ports
– Related supplies for ports and cell pins
 Used to specify constraints for IP usage
– Clamp value constraints for isolation of ports
 Used to specify structure and behavior information
– Hierarchy leaf/macro cells, net connections, simstate use
Predefined UPF Attributes
 Supply Attributes  Structural Attributes

– UPF_pg_type – UPF_is_leaf_cell
– UPF_related_power_port – UPF_is_macro_cell
– UPF_related_ground_port – UPF_feedthrough
– UPF_related_bias_ports – UPF_unconnected
– UPF_driver_supply
– UPF_receiver_supply
 Behavioral Attributes
– UPF_retention
 Isolation Attributes – UPF_simstate_behavior
– UPF_clamp_value
– UPF_sink_off_clamp_value
– UPF_source_off_clamp_value
Attribute Definitions
 UPF  HDL
set_port_attributes -ports Out1 \ SystemVerilog or Verilog-2005
-attribute \
{UPF_related_power_port "VDD" (* UPF_related_power_port = "VDD",
UPF_related_ground_port = "VSS" *)
set_port_attributes -ports Out1 \
-attribute \ output Out1;
{UPF_related_ground_port "VSS“
VHDL
attribute UPF_related_power_port of
set_port_attributes -ports Out1 \ Out1: signal is "VDD";
-related_power_port "VDD" \
-related_ground_port "VSS" attribute UPF_related_ground_port of
Out1: signal is "VSS";
 Liberty
– related_power_pin, related_ground_pin
– pg_type, related_bias_pins, is_macro_cell, etc.
UPF Attribute Usage
 Supply Attributes  Used to specify

– UPF_pg_type – cell/macro supply port types
– UPF_related_power_port – logic port related supplies
– UPF_related_ground_port – primary IO port related supplies
– UPF_related_bias_ports – driver/receiver supply sets
– UPF_driver_supply • can be defined only in UPF
– UPF_receiver_supply • no supply set data type in HDL or
Liberty
pg_type pg_type
primary_power pwr_aon gnd pwr_sw

backup_power
related_power_port related_power_port
VDD VDD VSS VDDB VDDB

related_ground_port related_ground_port
VSS VSS
receiver supply IN1 OUT1 driver supply
power: (VDD) power: (VDDB)

ground: (VSS) ground: (VSS)
UPF Attribute Usage
 Supply Attributes  Used to specify

– UPF_pg_type – cell/macro supply port types
– UPF_related_power_port – logic port related supplies
– UPF_related_ground_port – primary IO port related supplies
– UPF_related_bias_ports – driver/receiver supply sets
– UPF_driver_supply • can be defined only in UPF
– UPF_receiver_supply • no supply set data type in HDL or
Liberty
 Isolation Attributes  Used to specify

– UPF_clamp_value – clamp value requirements in
– UPF_sink_off_clamp_value case source is powered off when
sink is powered on
– UPF_source_off_clamp_value
• used to define power constraints
for IP blocks
UPF Attribute Usage
 Used to identify  Structural Attributes

– leaf cells in the hierarchy – UPF_is_leaf_cell
– macro cells in the hierarchy – UPF_is_macro_cell
– feedthrough paths through – UPF_feedthrough
a macro cell – UPF_unconnected
– unconnected macro ports
feedthrough
ports: IN1, OUT1
VDD VSS VDDB
IN1 OUT1
unconnected
IN2 logic OUT2 ports: OUT3
IN3 OUT3
UPF Attribute Usage
 Used to identify  Structural Attributes

– leaf cells in the hierarchy – UPF_is_leaf_cell
– macro cells in the hierarchy – UPF_is_macro_cell
– feedthrough paths through – UPF_feedthrough
a macro cell – UPF_unconnected
– unconnected macro ports
 Used to define  Behavioral Attributes

– whether state retention is – UPF_retention
required for a given element – UPF_simstate_behavior
– whether simstates determine
power aware behavior (i.e.,
corruption)
Hard Macro Supplies
receiver supply F driver supply
power: (VDD) power: (VDD)

ground: (VSS) control ground: (VSS)
VDD VSS VDDB
pg_type pg_type
primary_power backup_power
Periphery
receiver supply driver supply
Core
power: (VDDB) power: (VDDB)
ground: (VSS) Data InM7 M8
Data Out ground: (VSS)
data
 Modeled with Attributes

In a memory cell with separate supplies
– Attributes of cell pins:
for peripheral logic and memory core,
• PG type attributes
different ports will have different
• Related supply attributes
• In UPF, HDL, or Liberty
driver supplies or receiver supplies.
– Imply anonymous supply sets
Supply Power States
 Defined on supply sets

– In particular, power domain primary supply
 Represent how cells behave in various situations
– When / whether cell outputs are corrupted
 Defined by a logic expression
– State holds when logic expression is TRUE
 Also may include a supply expression
– Defines the legal values of supply set fns when in that state
 Also includes a simstate
– Simstate defines precise simulation semantics in this state
 Not necessarily mutually exclusive!
Supply Set Power State Definition
 Simple
add_power_state PD1.primary -supply \
-state {ON -logic_expr {PwrOn} -simstate NORMAL} \
-state {OFF -logic_expr {!PwrOn} -simstate CORRUPT}
 More Complex
add_power_state PD1.primary -supply \
-state {RUN -logic_expr {PwrOn && !Sleep && Mains} \
-simstate NORMAL} \
-state {LOW -logic_expr {PwrOn && !Sleep && Battery} \
-simstate NORMAL} \
-state {SLP -logic_expr {PwrOn && Sleep} \
-simstate CORRUPT_ON_CHANGE} \
-state {OFF -logic_expr {!PwrOn} \
-simstate CORRUPT}
Simstates - Precedence and Meaning
lower  NORMAL
– Combinational logic functions normally
– Sequential logic functions normally
 NORMAL – Both operate with characterized timing
 CORRUPT_STATE_ON_CHANGE
 CORRUPT_STATE_ON_CHANGE – Sequential state/outputs maintained as long as
outputs are stable
 CORRUPT_STATE_ON_ACTIVITY
 CORRUPT_STATE_ON_ACTIVITY – Sequential state/outputs maintained as long as
inputs are stable
 CORRUPT_ON_CHANGE
 CORRUPT_ON_CHANGE – Combinational outputs maintained as long as
outputs are stable
– Sequential state/outputs corrupted
 CORRUPT_ON_ACTIVITY
 CORRUPT_ON_ACTIVITY – Combinational outputs maintained as long as
inputs are stable
 CORRUPT  CORRUPT
– Combinational outputs corrupted
higher
Domain Power States
 Defined on power domains

– In particular, power domains representing an IP block
 Represent aggregate state of supplies, subdomains
– Abstract functional/power modes of a component
 Defined by a logic expression (like supply set states)
– Typically refers to power states of other objects
 Does NOT include a supply expression
– Supply expressions are only for supply set power states
 Does NOT include a simstate
– Simstates are only for supply set power states
 Not necessarily mutually exclusive!
Domain Power State Definition
 Examples  Examples
add_power_state PD_TOP -domain \ add_power_state PD_Mem -domain \
-state {Normal \ -state {UP \
-logic_expr \ -logic_expr {primary == ON}} \
{primary == ON && \ -state {RET \
backup == ON && \ -logic_expr {retention == ON}} \
PD_mem == UP} } \ -state {DOWN \
-state {Sleep \ -logic_expr {retention == OFF}}
-logic_expr \
{primary == OFF && \
backup == ON && \
PD_TOP .primary .backup PD_MEM
PD_mem == UP} } \
-state {Off\ Normal ON ON UP
-logic_expr \
{primary == OFF && \ Sleep OFF ON RET
backup == OFF && \
Off OFF OFF DOWN
PD_Mem == DOWN} }
Power Management Strategies
 Retention strategies
– Identify registers to retain, controls/conditions, and supplies
– Must satisfy any retention constraints (clamp value attributes)
 Repeater strategies
– Identify ports to be buffered and their supplies
– Input and output ports can be buffered
 Isolation strategies
– Define how to isolate ports where required - control, supplies
– Actual isolation insertion is driven by source/sink power states
 Level shifter strategies
– Define how to level-shift ports where required - supplies
– Actual level shifter insertion is driven by threshold analysis
Retention Strategies
Balloon Latch Live Slave Latch

set_retention BL -domain PD1 \ set_retention LSL -domain PD1 \
-elements {…} \ -elements {…} \
-save_signal … \ -retention_condition … \
-restore_signal … \ -retention_supply …
-retention_supply …
Isolation Strategies
 Specifying Ports
– Using -elements and -exclude_elements
– Using filters: -applies_to, -diff_supply_only, -sink, -source
 Precedence Rules
– More specific rules take precedence over more generic rules
 Specifying Location
– Using locations self, parent, other, and fanout
 Handling Fanout to Different Domains

– Using -sink to isolate different paths
 Isolation Supplies and Cells

– Location affects default isolation supply and usable cell types
Specifying Ports
 Elements list includes ports

-elements { <port name> }
-elements { <instance name> }
-elements { . }
[if no -elements list, default is all ports of domain]
 Exclude elements list excludes ports
-exclude_elements { … }
 Filters further limit the set of ports

-applies_to <inputs | outputs | both>
-source <domain name> | <supply set name>
-sink <domain name> | <supply set name>
-diff_supply_only
What Happens if Multiple Strategies?
set_isolation ISO1 \ set_isolation ISO2 \

-elements {A B[0]} … -elements {A[5] B} …
A 0 1 2 3 4 5 B 0 1 2 3 4 5
Precedence Rules for Strategies
lower
 Strategy for all ports of a specified set_isolation ISO1 -domain PD \

power domain …
 Strategy for all ports of a specified set_isolation ISO2 -domain PD \

power domain with a given -applies_to inputs …
direction
 Strategy for all ports of an set_isolation ISO3 -domain PD \
instance specified explicitly by -elements {i1} …
name
set_isolation ISO4 -domain PD \
 Strategy for a whole port specified -elements {i1/a i1/b} …
explicitly by name
 Strategy for part of a multi-bit set_isolation ISO5 -domain PD \
port specified explicitly by name -elements {i1/a[3] i1/b[7]} …
higher
Interface Cell Locations
 Self
– The domain for which the strategy is defined
 Parent
– The domain “above” the self domain
 Other
– The domains “above” and “below” the self domain
 Fanout
– The domain in which the receiving logic is contained
Isolation Cell Locations
set_isolation ISO1 -domain PD2 -location …
-location other
P R I AO -diff_supply_only
Output Isolation PD1
Top
might inhibit
-location parent insertion of
Output Isolation this cell
P AO
-location self PD2
(PD2) PD3
(PD3)
Input Isolation A B -location fanout
PD23 Output Isolation
-location self (-sink PD4)
Output Isolation
PD4 -location fanout
C D E F Output Isolation
-location other (-sink PD3.AO)
Output Isolation
M1 M2 M3 M4 M5 M6 M7 M8
Other Isolation Cell Parameters
 Clamp Value
– specified with
-clamp_value < 0 | 1 | any | Z | latch >
 Control
– specified with
-isolation_signal <signal name>
-isolation_sense <high | low>
 Supply
– specified with
-isolation_supply <supply set name>
– if not specified, uses default_isolation supply of location
• can be a single-rail cell if containing domain is always on when enabled
• otherwise typically requires a dual-rail cell
Strategy Execution Order
PD_Proc PD_Mem
Logic
Logic
Retention, then Repeater, then Isolation, then Level Shifter
Strategy Interactions
Level
Retention Repeater Isolation
Shifter
Retention -- affects affects affects
affected
Repeater -- affects affects
by
affected affected
Isolation -- affects
by by
Level affected affected affected
--
Shifter by by by
Strategies may change driver and/or receiver supplies of a port

This may affect -source/-sink filters of subsequently executed strategies
Supply Ports/Nets
 Represent supply ports, pins, and rails

– Primary supply inputs, supply pins of cells, nets in between
 Are connected together to create supply network
– Together with power switches to control power distribution
 Deliver power/ground/etc. supplies to domains
– Delivered values determine how domain functions
 Have and propagate {state, voltage} values
– States are UNDETERMINED, OFF, PARTIAL_ON, FULL_ON
– Voltages are fixed-point values with microvolt precision
 Examples
– {FULL_ON 1.2} {PARTIAL_ON 0.81} {OFF}
“Power” (Supply) Switches
 Have one or more supply inputs

– Defined with -input_supply_port
 Have one supply output

– Defined with -output_supply_port
 Have one or more control inputs

– Defined with -control_port
 Have one or more control states

– Defined with -on_state or -on_partial_state
– Also can include -error_state and/or -off_state
 Conditionally propagate input supply values to output

– Based on which control states are active
Power Switches
 Examples
create_power_switch Simple \ Input and Output
-output_supply_port {vout} \ Supply
-input_supply_port {vin} \ Ports
-control_port {ss_ctrl} \ Control Port

-on_state {ss_on vin { ss_ctrl }} \ Switch
-off_state {ss_off { ! ss_ctrl }} Input States
and Output State
create_power_switch TwoStage \
-output_supply_port {vout} \
-input_supply_port {vin} \
-control_port {trickle_ctrl} \
-control_port {main_ctrl} \
-on_partial_state {ts_ton vin { trickle_ctrl }} \
-on _state {ts_mon vin { main_ctrl }} \
-off_state {ts_off { ! trickle_ctrl && ! main_ctrl }}
Supply Network Construction
Commands
VDD1 VDD2 VDD3 VSS create_supply_port …
create_supply_net …
connect_supply_net …
Pwr1 Pwr2 Pwr3 Gnd
create_power_switch …
Pwr1sw Pwr23mx
create_supply_net \
-resolved …
PwrRes
create_supply_set \
-update
Pri
Supply Equivalence
 Supply Ports/Nets/Functions
– Electrically equivalent if same/connected/associated
– Functionally equivalent if
• they are electrically equivalent, or
• they are declared functionally equivalent
- example: outputs of two switches that have same input and control
 Supply Sets
– Functionally equivalent if
• both have the same required functions, and
corresponding required functions are electrically equivalent; or
• both are associated with the same supply set; or
• they are declared functionally equivalent
- Declaration works for verification only;
must be explicitly connected for implementation
A Deeper Look at UPF Power Intent
 Logic Hierarchy
 Power Domains For more details, read the
IEEE 1801-2013 UPF spec,
 Power Domain Supplies
especially
 Supply Sets Clause 4, UPF Concepts
 Supply Connections
 Power Related Attributes
 Power Domain State Retention
 Power Domain Interface Management
 Supply Network Construction
 Supply Equivalence
BREAK
Using UPF for Low Power Design and Verification 3 March 2014 117
Hard IP Modeling with
Liberty and Verilog
Sushma Honnavara-Prasad
Principal Engineer
Broadcom
Leaf Cells vs Macros (IPs)
 Leaf cell
– An instance that has no descendants, or an instance that has
the attribute UPF_is_leaf_cell associated with it.
– In a typical ASIC flow,
• Used to denote a standard cell/IO/Analog IP etc in the design
• Have simulation models/.libs associated with them
 Macros
– Also called IPs, a piece of functionality optimized for
power/area/performance
• Soft macros – handed off as synthesizable HDL (technology
agnostic)
• Hard macros – handed off as LEF/GDS (technology specific)
- Also a leaf cell
– UPF_is_macro_cell attribute allows the model to be
recognized as part of lower boundary of the domain
containing the instance
Models Dealing with Power
 Why do we need them:

– Power models provide a compact abstraction of the design
while preserving the structural/functional power related
properties of the design
– Type of models we use change based on the
design/verification phase
 UPF Power models
 Simulation models
• Power aware RTL/Gate models (Verilog/VHDL/SV)
 Implementation models
• Liberty
• LEF etc.
Liberty Attributes and UPF
 Leaf cell/macro cell power intent may be contained in

liberty (.lib models)
 .lib can describe power/power management cell attributes
.lib UPF Purpose

pg_pin - Supply pin definition
pg_type UPF_pg_type Function of a supply
pg_function - Supply expression for
generated supplies
related_power_pin UPF_related_power_port Power associated with a port
related_ground_pin UPF_related_ground_port Ground associated with a port
Supply Attributes
.lib UPF Purpose
is_macro_cell UPF_is_macro_cell Identify a hard-macro
- UPF_is_leaf_cell Identify a leaf-cell (all cells in
.lib are considered leaf cells)
always_on define_always_on_cell Cells that can remain on while
the domain is off
antenna_diode_type define_diode_clamp Define/describe diode clamps
is_isolation_cell define_isolation_cell Define isolation cell
isolation_cell_enable_pin -enable Identifies isolation cell enable
always_on -always_on_pins Always on Pin attribute
is_level_shifter define_level_shifter_cell Define level shifter cells
level_shifter_enable_pin -enable Enabled level shifter control
Power management cell attributes
.lib UPF Purpose
switch_cell_type create_power_switch_cell Define a power-switch cell
user_pg_type gate_bias_pin Identifies supply pin associated
with gate input
retention_cell define_retention_cell Define a retention cell
retention_pin - Identifies the retention control(s)
save_action save_function Save pin function that enables
save action
restore_action restore_function Restore pin function that enables
restore action
Power management cell attributes
Example: Embedded SRAM
module RAM (cs, clk, addr,

din, dout, we, pwron_in,
pwron_out, iso, float,
clk_out);
input cs, clk, we;
input float;
input [3:0] addr;
input [31:0] din;
output [31:0] dout;
input pwron_in, iso;
output pwron_out;
output clk_out;
endmodule
Embedded SRAM: Liberty
cell (SRAM) {
is_macro_cell : true;
switch_cell_type : fine_grain;
pg_pin (VDD) {
pg_type: primary_power;
voltage_name: VDD;
direction: input;
}
pg_pin (VSS) {
pg_type: primary_ground;
voltage_name: VSS;
direction: input;
}
pg_pin (VDDSW) {
pg_type: internal_power;
voltage_name: VDDSW;
direction: internal;
pg_function: VDD;
switch_function: pwron_in;
}
pin (iso) {
related_power_pin : VDD;
related_ground_pin : VSS;
}
}
pin (pwron_in) {
switch_pin: true;
}
pin (clk) {
related_power_pin : VDDSW;
}
pin (cs) {
related_power_pin : VDDSW;
}
pin (pwron_out) {
function: pwron_in;
}
pin (dout[0]) {
}
pin (dout[1]) {
}
Embedded SRAM: Power Aware HDL
assign VDDSW = pwron_in && VDD;
assign supply_on = VDDSW && !VSS;
//Corrupt all the inputs associated

// with VDDSW when pwron_in is 0
assign clk_int = (supply_on)?clk: ‘x’;
assign cs_int = (supply_on)?cs: ‘x’;
//Corrupt array if iso !=1 when off

if (!pwron_in && !iso)
array[M] <= 16{1’bx};
//Corrupt outputs when VDDSW is off

// and not isolated
assign dout = (iso)? 16{1’b0}: (supply_on)? dout_int:16{1’bx};
Power Model and Power
Management Cell Commands
David Cheng
Architect
Cadence Design Systems
Using UPF for Low Power Design and Verification © 2014 Cadence 3 March 2014 130
Power Model
For static tools (where the block content is a black box)

Liberty cell modeling provides basic modeling
Power model provides additional modeling:
– Power states (power modes)
– Feedthrough and floating ports
– Detailed isolation picture of boundary ports
For dynamic tools (where the block content is visible)
Similar to the block’s design UPF
Power model provides a clear boundary that prevents higher-
scope UPF constructs from “coming into” the block
Commands for Power Model
 Commands to define a power model containing other UPF
commands
begin_power_model power_model_name [-for model_list]
<UPF commands>
end_power_model
apply_power_model power_model_name
[-elements instance_list]
[-supply_map {
{lower_scope_handle upper_scope_supply_set}*
}]
 Certain commands cannot be used within a power model definition

•name_format
•save_upf
•save_scope
•load_upf –scope
•begin_power_model/end_power_model/apply_power_model
•Any deprecated/legacy commands/options
Same Example - Different Colors
VDD
 For static tools:
pwron_in Power pwron_out
– Only describes the Switch
boundary (the red part) float
VDDSW
– Internal is a black box clk_out
– Similar to Liberty model dout[0]
ISO
clk
cs dout[1]
ISO
we Logic Memory
periphery Array
addr dout[15]
ISO
din
iso
Possible Checks in Mind
 Do I always assert iso VDD

before I assert pwron_in? pwron_in Power pwron_out
Switch
 Are my power states/
float
modes consistent with VDDSW
the block’s? clk_out
dout[0]
 Is my logic compatible ISO
clk
with the asserted clamp
values? cs dout[1]
ISO
we Logic Memory
 Are clk and clk_out periphery Array
treated the same? addr dout[15]
ISO
 No check needed for float din
iso
Power Model Description
Blue: Liberty can also describe
Red: Liberty weaker
begin_power_model
create_power_domain PD1 \ VDD
–include_scope pwron_in Power pwron_out

Switch
create_supply_set SS_VDD ...
float
create_supply_set SS_VDDSW ... VDDSW
clk_out
set_port_attributes \ dout[0]
–elements . \ clk
ISO
–applies_to inputs \
cs
–receiver_supply SS_VDDSW ISO
dout[1]
we Logic Memory
set_port_attributes \ periphery Array
–ports {pwron_in iso} addr dout[15]
–receiver_supply SS_VDD din
ISO
set_port_attributes \
–elements . \
iso
–applies_to outputs \
–driver_supply SS_VDD
...
Power Model Description
Blue: Liberty can also describe
Red: Liberty weaker
...
VDD
–ports {float} pwron_in Power pwron_out
Switch
–unconnected
float
VDDSW
clk_out
–ports {clk clk_out} \
dout[0]
–feedthrough ISO
clk
set_isolation -domain PD1 \
cs
–elements {dout} \ ISO
dout[1]
–clamp_value 1 \ we Logic Memory

periphery Array
–isolation_signal iso ...
addr dout[15]
create_pst PST1 \
ISO
din
–supplies {VDD VDDSW...}
end_power_model
iso
Liberty Description
pin (clk_out) { VDD
function: clk; pwron_in Power pwron_out

Switch
} float
VDDSW
pin (float) {
clk_out
} dout[0]
ISO
clk
pin (dout[0]) {
cs
related_power_pin : VDD; ISO
dout[1]
we Logic Memory
related_ground_pin : VSS; periphery Array
is_isolated: true; addr

ISO
dout[15]
din
(isolation_enable_condition:
iso;)
} iso
Possible Checks in Mind
 Do I always assert iso
VDD
before I assert pwron_in?
– Now possible with Liberty’s pwron_in Power pwron_out
isolation_enable_condition Switch
float
VDDSW
 Are my power states/
clk_out
modes consistent with the
dout[0]
block’s? ISO
clk
– Liberty has no PSTs
cs dout[1]
 Is my logic compatible with ISO
we Logic Memory
the asserted clamp values? periphery Array
– Liberty has no “clamp_value” addr dout[15]
ISO
 Are clk and clk_out treated din
the same?
– Liberty has no “feedthrough”
iso
 No check needed for float
– Liberty has no “unconnected”
Two Flavors of Dynamic Simulation for a Block
Power aware
HDL alone is enough
Often “hard macros”
(Review Sushma’s slide)
Power unaware
HDL + UPF
Often “soft macros”
E.g., an HDL block that goes through implementation and
is now “hardened”
Without power model, the UPF looks just like your regular
design
Power Unaware HDL
assign VDDSW = pwron_in && VDD;  Note: many details abstracted out,
assign supply_on = VDDSW && !VSS; e.g.:
 always @ (addr or cs or...)
//Corrupt all the inputs associated
// with VDDSW when pwron_in is 0  if (we) { write } else { read }
assign clk_int = (supply_on)?clk: ‘x’;  assign dout_int = ...
assign cs_int = (supply_on)?cs: ‘x’;
//Corrupt array if iso !=1 when off

if (!pwron_in && !iso) Only the RED code
array[M] <= 16{1’bx}; is required
//Corrupt outputs when VDDSW is off

// and not isolated
assign dout = (iso)? 16{1’b0}: (supply_on)? dout_int:16{1’bx};
Power Model (for Dynamic Tools)
A power model is similar to the block’s design UPF, except a
clear boundary that prevents higher-scope UPF constructs from
“coming into” the block
Example: two supply ports
in a block are shorted at
higher scope
With the clear boundary
of a power model, the
VDD1 VDD2
simulation tool would
treat the two supplies
still as “different set_isolation ... –diff_supply_only
supplies”
Other examples exist
Summary on Power Model
In short, power model indicates this block is already done

For static tools (where the block content is a black box)
Liberty cell modeling provides basic modeling
Power model provides additional modeling:
– Power states (power modes)
– Feedthrough and floating ports
– Detailed isolation picture of boundary ports
For dynamic tools (where the block content is visible)
Similar to the block’s design UPF
Power model provides a clear boundary that prevents higher-
scope UPF constructs from “coming into” the block
Modeling Power Management Cells
 1801-2013 provides commands to model the

following power management cells
– State retention cells
– Always-on cells
– Isolation cells
– Level shifter cells
– Power switch cells
– Diode cells
 An alternative to modeling low power management
cells using Liberty
Example: State Retention Cells
Wake
Retention flops with both save and restore
Sleep
VDD
Retention define_retention_cell -cells SR1 \
Latch -save_function {Sleep high} \
VDD_SW Q
–restore_function {Wake high} \
D State -restore_check !Clk -save_check !Clk \
Clk
Register -power_switchable VDD_SW -power VDD \
-ground VSS
RESETN
Retention flops with live slave latch

Slave
VDD
Latch
define_retention_cell -cells SR1 \
VDD_SW Q -restore_check !Clk -save_check !Clk \
D Master
Latch
-power_switchable VDD_SW -power VDD \
Clk -ground VSS
RESETN
Relationship to Liberty
 1801-2013 Annex H contains the current mapping
– Sushma covered with some examples earlier
 1801 does not have to “wait” for Liberty if special
needs arise, e.g.:
VSW VDD
Isolation cell with two control pins
a
en Y define_isolation_cell -cells myiso \
iso -power_switchable VSW -power VDD -ground VSS \
-enable iso -aux_enables en -valid_location source
vss
Multi-bit isolation cell
2
define_isolation_cell -cells IsoLL \
-power_switchable VSW -power VDD -ground VSS \
2
2
-valid_location source \
-pin_groups {{in1 out1 en1} {in2 out2 en2} \
3
3
3
{in3 out3 en3}}
Work with Strategies, Example:
VSW VDD
Cell definition
define_isolation_cell -cells isoandlow \
a -power_switchable VSW –power VDD -ground VSS \
en Y
-enable iso -aux_enables en
iso
Strategy specification
vss set_isolation iso1 –domain PD1 –location self \
-isolation_signal { iso_drvr en_drvr} \
-isolation_sense { high low } -clamp_value 0
Summary on 1801-2013 Library Cell
Commands
Model commonly used power management cells
Compact form to specify common attributes of

many cells in a single command
An alternative modeling in addition to Liberty
Direct mapping with corresponding strategies
Low Power Design Methodology
for IP Providers
John Biggs
ARM
ARM® Cortex®-A MPCore Example
 Generic simplified example ®
 Symmetric Multicore Cluster

– 1-4 CPUs with L2 cache
 Each CPU has 2 power domains
– Integer CPU, L1 Cache, Debug and
Trace
– Floating point and SIMD engine
 The MPCore has 3 power
domains
– L2 cache RAMs.
– L2 cache control
– Debug and Trace
Cortex-A MPCore Power Domains
Clamps may be physically

located in FPU logic hierarchy
Tip: Align Power Domains and Logic Hierarchy
 Multi-element power domains can lead TOP

to unexpected “intra-domain” isolation
create_power_domain RED –elements {A B} A B C
iso
 These can often be avoided with a TOP

different approach
create_power_domain RED –elements {.} A B C D
create_power_domain BLUE –elements {C}
E
 Better to align power domains with logic TOP
hierarchy if at all possible
RED BLUE
create_power_domain RED –elements {RED}
create_power_domain BLUE –elements {BLUE}
A B C D
Failing that, use -diff_supply_only option
or the -source/-sink filters
Cortex-A MPCore Power States
PD_CPU PD_FPU
RUN RUN *
RETENTION RET !RUN
OFF OFF OFF
!RUN = RET or OFF
PD_CPU0 PD_CPU1 PD_CLSTR PD_L2RAM PD_DBG
RUN RUN RUN RUN RUN *
RETENTION !RUN !RUN !RUN RET *
DORMANT OFF OFF OFF ON *
DEBUG * * * * RUN
OFF OFF OFF OFF OFF OFF
Successive Refinement of Power Intent
1 IP Creation 2 IP Configuration 3 IP Implementation
RTL RTL RTL

Constraint Constraint
UPF Config’n
+ Soft IP Golden Source UPF
Constraint
+
UPF Configuration +
UPF

Impl’tion
UPF
IP Provider: IP Licensee/User: Synthesis
 Creates IP source  Configures IP for context

Impl’tion UPF
 Creates low power  Validates configuration Netlist
implementation
constraints  Freezes “Golden Source”
 Implements configuration
P&R
 Verifies implementation
against “Golden Source”
Impl’tion UPF
Netlist
A Soft IP Provider Need Only Declare Four Things:
1. The "atomic" power domains in the design

• These can be merged but not split during implementation
2. The state that needs to be retained during shutdown

• Without prescribing how retention is controlled
3. The signals that need isolating high/low

• Without prescribing how isolation is controlled
4. The legal power states and sequencing between them

• Without prescribing absolute voltages
CPU Constraints
CPU
FPU
Put everything in PD_CPU
execpt PD_FPU
1. Atomic power domains
create_power_domain PD_CPU -elements {.} \
–exclude_elements “$FPU” -atomic
create_power_domain PD_FPU –elements “$FPU” –atomic
2. Retention requirements Retain “all or nothing”

set_retention_elements RETN_LIST -elements {.}
3. Isolation requirements
set_port_attributes -model cortex_cpu -applies_to outputs \
-exclude_ports “$CPU_CLAMP1” -clamp_value 0
set_port_attributes -model cortex_cpu –ports “$CPU_CLAMP1” -clamp_value 1
set_port_attributes -elements “$FPU” -applies_to outputs -clamp_value 0
Clamp everything low by default

Then call out the exceptions
CPU Constraints (cont…)
CPU
FPU
Define PD_FPU in terms
of its supply sets
4. Power State
add_power_state PD_FPU -domain \
-state {RUN -logic_expr {primary == ON \ PD_FPU primary retention
&& default_retention == ON }} \
-state {RET -logic_expr {primary == OFF \ RUN ON ON
&& default_retention == ON }} \
RET OFF ON
-state {OFF -logic_expr {primary == OFF \
&& default_retention == OFF }} OFF OFF OFF
add_power_state PD_CPU -domain \

-state {RUN -logic_expr {primary == ON \
&& default_retention == ON} \ PD_CPU primary retention PD_FPU
-state {RET -logic_expr {primary == OFF \
&& default_retention == ON \ RUN ON ON *
&& PD_FPU != RUN}} \
-state {OFF -logic_expr {primary == OFF \ RET OFF ON !RUN
&& default_retention == OFF \
OFF OFF OFF OFF
&& PD_FPU == OFF}}
Define PD_CPU in terms
of its supply sets and In RET the FPU state can
the state of PD_FPU be anything but RUN
DEBUG
Cluster Constraints
Put everything in CPU0 CPU1
PD_CLSTR
FPU0 FPU1
except PD_L2RAM
1. “Atomic” power domains and PD_DEBUG
L2RAM
create_power_domain PD_CLSTR -elements {.} \
–exclude_elements {“$L2RAM” “$DEBUG”} -atomic
create_power_domain PD_L2RAM –elements “$L2RAM” -atomic
create_power_domain PD_DEBUG –elements “$DEBUG” -atomic
2. Retention requirements
set_retention_elements RETN_LIST -elements {.} Retain “all or nothing”
3. Isolation requirements
set_port_attributes –model cortex_cluster -applies_to outputs \
-exclude_ports “$CLSTR_CLAMP1” -clamp_value 0
set_port_attributes –model cortex_cluster –ports “$CLSTR_CLAMP1” -clamp_value 1
set_port_attributes -elements $L2RAM -applies_to outputs \
-exclude_ports “$L2RAM_CLAMP1” -clamp_value 0
set_port_attributes -elements $L2RAM –ports “$L2RAM_CLAMP1” -clamp_value 1
set_port_attributes -elements $DEBUG –applies_to outputs -clamp_value 0
Clamp everything low by default

Then call out the exceptions
DEBUG
Cluster Constraints (cont…)
CPU0 CPU1
FPU0 FPU1
Define PD_L2RAM
in terms of its L2RAM
supply sets
4. Power Domain State
add_power_state PD_L2RAM -domain \
-state {RUN -logic_expr {primary == ON \ PD_L2RAM primary retention
&& default_retention == ON }}\
-state {RET -logic_expr {primary == OFF \ RUN ON ON
&& default_retention == ON }}\
RET OFF ON
-state {OFF -logic_expr {primary == OFF \
&& default_retention == OFF}} OFF OFF OFF
add_power_state PD_DEBUG -domain \

-state {RUN -logic_expr {primary == ON }}\ PD_DEBUG primary
-state {OFF -logic_expr {primary == OFF }}
RUN ON
Define PD_DEBUG in terms OFF OFF

of its supply sets
DEBUG
Cluster Constraints (cont…)
CPU0 CPU1
FPU0 FPU1
4. Power Domain State (Cont.) L2RAM

add_power_state PD_CLSTR -domain \
-state {RUN -logic_expr {primary == ON && PD_L2RAM == RUN \
&& uCPU0/PD_CPU == RUN || uCPU1/PD_CPU == RUN}} \
-state {RET -logic_expr {primary == OFF && PD_L2RAM == RET \
&& uCPU0/PD_CPU != RUN && uCPU0/PD_CPU != RUN}} \ Define PD_CLSTR in
-state {DMT -logic_expr {primary == OFF && PD_L2RAM == RUN \ terms of its supply
&& uCPU0/PD_CPU == OFF && uCPU0/PD_CPU == OFF}} \ sets and also the
-state {DBG -logic_expr {PD_DEBUG == RUN}} state of PD_L2RAM
-state {OFF -logic_expr {primary == OFF && PD_L2RAM == OFF \ and PD_DEBUG
&& uCPU0/PD_CPU == OFF && uCPU0/PD_CP == OFF \
&& PD_DEBUG == OFF}}
PD_CLSTR primary PD_L2RAM PD_CPU0 PD_CPU1 PD_DEBUG
RUN ON RUN RUN RUN *

RET OFF RET !RUN !RUN *
DMT OFF RUN OFF OFF *
DBG * * * * RUN
OFF OFF OFF OFF OFF OFF
1 IP Creation 2 IP Configuration
RTL
+ Soft IP
Constraint
UPF
We now have UPF constraints to go along

with the unconfigured RTL
IP Provider: This is what an IP provider would deliver

 Creates IP source
 Creates low power
implementation
constraints
Flat vs Hierarchical
 Configure instances in SOC

context nPWR1 nISO1
PMU nPWR2 nISO2
set_scope /SOC
load_upf cpu_cnstr.upf –scope CLSTR/CPU1
load_upf cpu_cnstr.upf –scope CLSTR/CPU2
CLSTR
load_upf clstr_cnstr.upf –scope CLSTR
 Isolation
set_isolation ISO -domain PD_CPU1
-isolation_signal PMU/nISO1
-location self
 Power switches CPU1 CPU2

create_power_switch SW -domain PD_CPU1
-input_supply_port {sw_in VDDSOC}
-output_supply_port {sw_out VDDCPU1}
-control_port {sw_ctl PMU/nPWR1}
-on_state {on_state sw_in {!PMU/nPWR1}}
-off_state {off_state { PMU/nPWR1}}
Flat vs Hierarchical
 Configure IP out of context SOC

create_logic_port nISO –direction in PMU
nISO1 nISO2
create_logic_port nPWR –direction in nPWR1 nPWR2
set_isolation ISO -domain PD1

-isolation_signal nISO
create_power_switch SW -domain PD CLSTR
-control_port {sw_ctl nPWR}
 Load configured IP in to
context
set_scope /CLSTR
load_upf cpu_config.upf –scope CPU1
load_upf cpu_config.upf –scope CPU2 CPU1 CPU2
create_logic_port nISO1
create_logic_port nPWR1
connect_logic_net CPU1/ISO –port nPWR1
connect_logic_net CPU1/ISO –port nISO1
 Connect up to PMU
CPU Configuration
CPU
FPU
Compose PD_CPU and PD_FPU in to single

domain
create_composite_domain PD_myCPU –subdomains {PD_CPU PD_FPU}
PD_FPU not
Create power control ports required
create_logic_port nPWRUP_CPU -direction in
create_logic_port nISOLATE_CPU -direction in
Create isolation strategies to fulfill isolation

requirements Clamp all outputs
set_isolation ISO_LO -domain PD_myCPU \ low by default
–applies_to outputs -clamp_value 0 \
-isolation_signal nISOLATE_CPU -isolation_sense low \
-location self
set_isolation ISO_HI -domain PD_myCPU \ Clamp the exceptions high
-elements “$CPU_CLAMP1” -clamp_value 1 \ (more specific overrides
more generic)
-location self
CPU Configuration
CPU
FPU
 Update power supply state with supply

expressions
add_power_state PD_myCPU.primary –supply -update\
-state {ON -supply_expr {power == FULL_ON && ground == FULL_ON }}\
-state {OFF -supply_expr {power == OFF || ground == OFF }}
 Update power domain state with logic

expressions
add_power_state PD_CPU -domain -update \
-state {RET -illegal} \ CPU state retention
-state {RUN -logic_expr {!nPWRUP_CPU}} \ not required
-state {OFF -logic_expr { nPWRUP_CPU}}
add_power_state PD_FPU -domain -update \ PD_FPU is switched

-state {RUN -logic_expr {!nPWRUP_CPU}} by nPWRUP_CPU
-state {OFF -logic_expr { nPWRUP_CPU}}
add_power_state PD_myCPU –domain -update \ Express PD_myCPU

-state {RUN -logic_expr {PD_CPU = RUN && PD_FPU == RUN} state in terms of
-state {OFF -logic_expr {PD_CPU = OFF && PD_FPU == OFF}
PD_CPU & PD_FPU
DEBUG
Cluster Configuration
CPU0 CPU1
FPU0 FPU1
Create Cluster power control ports L2RAM

create_logic_port nPWRUP_CLSTR -direction in
create_logic_port nISOLATE_CLSTR -direction in
create_logic_port nPWRUP_L2RAM -direction in
create_logic_port nISOLATE_L2RAM -direction in
create_logic_port nRETAIN_L2RAM -direction in
create_logic_port nPWRUP_DEBUG -direction in
create_logic_port nISOLATE_DEBUG -direction in
Create CPU power control ports

create_logic_port nPWRUP_CPU0 -direction in
create_logic_port nISOLATE_CPU0 -direction in
create_logic_port nPWRUP_CPU1 -direction in
create_logic_port nISOLATE_CPU1 -direction in
Connect CPU power control ports

connect_logic_net nPWRUP_CPU0 -port uCPU0/nPWRUP_CPU0
connect_logic_net nISOLATE_CPU0 -port uCPU0/nISOLATE_CPU0
connect_logic_net nPWRUP_CPU1 -port uCPU1/nPWRUP_CPU1
connect_logic_net nISOLATE_CPU1 -port uCPU1/nISOLATE_CPU1
DEBUG
CPU0 CPU1
FPU0 FPU1
Single pin
Create retention strategy for L2RAM retention
L2RAM
control
set_retention PD_L2RAM \
-save_signal {nRETAIN_L2RAM posedge} \
-restore_signal {nRETAIN_L2RAM negedge} \
-retention_condition {nRETAIN_L2RAM} \
Create isolation strategies to fulfill isolation requirements

set_isolation ISO_LO -domain PD_CLSTR -clamp_value 0 \ Clamp all outputs
low by default
-location self
set_isolation ISO_HI -domain PD_CLSTR –elements “$CLSTR_CLAMP1” -clamp_value 1
-location self
set_isolation ISO_LO -domain PD_L2RAM -clamp_value 0 \
Clamp the exceptions high
-isolation_signal nISOLATE_L2RAM -isolation_sense low \
-location self (more specific overrides
set_isolation ISO_LO -domain PD_DEBUG -clamp_value 0 \
more generic)
-isolation_signal nISOLATE_DEBUG -isolation_sense low \
-location self
DEBUG
CPU0 CPU1
FPU0 FPU1
 Update power supply state with supply expressions L2RAM

add_power_state PD_CLSTR.primary -supply -update \
-state {ON -supply_expr {power == FULL_ON && ground == FULL_ON}}\
-state {OFF -supply_expr {power == OFF || ground == OFF }}
add_power_state PD_L2RAM.primary -supply –update ...
add_power_state PD_L2RAM.default_retention -supply –update ...
add_power_state PD_DEBUG.primary -supply –update ...
 Update power domain state with logic expressions

add_power_state PD_L2RAM -domain -update \
-state {RUN -logic_expr {!nPWRUP_L2RAM && !nRETAIN_L2RAM}} \
-state {RET -logic_expr { nPWRUP_L2RAM && nRETAIN_L2RAM}} \
-state {OFF -logic_expr { nPWRUP_L2RAM }}
add_power_state PD_DEBUG -domain \
-state {RUN -logic_expr {!nPWRUP_DEBUG}} \
-state {OFF -logic_expr { nPWRUP_DEBUG}}
add_power_state PD_CLSTR -domain \
-state {RUN -logic_expr {!nPWRUP_CLSTR}} \
-state {RET -logic_expr {!nPWRUP_CLSTR}} \
-state {DMT -logic_expr { nPWRUP_CLSTR}} \
-state {OFF -logic_expr { nPWRUP_CLSTR}}
RTL RTL
Constraint
UPF
+ Soft IP Golden Source
Constraint
+
UPF Configuration
UPF
We now have a fully

configured technology
IP Provider: IP LicenseeUser: independent “Golden
Reference” ready for
implementation
 Creates low power  Validates configuration
implementation
CPU Implementation
CPU
FPU
 Create supply nets and update supply set functions

create_supply_net VDD
create_supply_net VDD_CPU Use VDD_CPU for
create_supply_net VSS
primary power
create_supply_set PD_myCPU.primary –update\
-function {power VDD_CPU} -function {ground VSS}
create_supply_set PD_myCPU.default_isolation –update \ Use VDD for
-function {power VDD} -function {ground VSS} isolation power
 Map the isolation strategies on to specific library cells

use_interface_cell CPU_LO -strategy ISO_LO -domain PD_CPU -lib_cells “$ISO_LO”
use_interface_cell CPU_HI -strategy ISO_HI -domain PD_CPU -lib_cells “$ISO_HI”
 Create a switch to fulfill the power state

create_power_switch SW_CPU -domain PD_myCPU \
-input_supply_port {sw_in VDD} \
-output_supply_port {sw_out VDD_CPU} \
-control_port {sw_ctl nPWRUP_CPU} \ Switch drives VDD_CPU with VDD
-on_state {on_state sw_in {!sw_ctl}} \
when nPWRUP_CPU is low
-off_state {off_state {sw_ctl}}
Cluster Implementation DEBUG
CPU0 CPU1
 Create supply nets and update supply set FPU0 FPU1
functions
create_supply_net VDD L2RAM
create_supply_net VDD_CLSTR
create_supply_net VDD_L2RAM
create_supply_net VDD_DEBUG Use VDD_CLSTR
create_supply_net VSS
for primary power
create_supply_set PD_CLSTR.primary -update \
-function {power VDD_CLSTR} -function {ground VSS}
create_supply_set PD_CLSTR.default_isolation -update \
-function {power VDD} -function {ground VSS} Use VDD for
isolation power
create_supply_set PD_L2RAM.primary -update \
-function {power VDD_L2RAM} -function {ground VSS}
create_supply_set PD_L2RAM.default_isolation -update \
-function {power VDD} -function {ground VSS}
create_supply_set PD_L2RAM.default_retention -update \
Use VDD for
retention power
create_supply_set PD_DEBUG.primary -update \
-function {power VDD_CLSTR} -function {ground VSS}
create_supply_set PD_DEBUG.default_isolation -update \
Cluster Implementation
 Map the isolation strategies on to specific library cells

use_interface_cell CLSTR_LO -strategy ISO_LO -domain PD_CLSTR -lib_cells “$ISO_LO”
use_interface_cell CLSTR_HI -strategy ISO_HI -domain PD_CLSTR -lib_cells “$ISO_HI”
use_interface_cell L2RAM_LO -strategy ISO_LO -domain PD_L2RAM -lib_cells “$ISO_LO”
use_interface_cell DEBUG_LO -strategy ISO_LO -domain PD_DEBUG -lib_cells “$ISO_LO”
DEBUG
Cluster Implementation
CPU0 CPU1
FPU0 FPU1
 Create switches to fulfill the power state
create_power_switch SW_CLSTR -domain PD_CLSTR \ L2RAM
-output_supply_port {sw_out VDD_CLSTR} \
-control_port {sw_ctl nPWRUP_CLSTR} \
-on_state {on_state sw_in !sw_ctl}} \
Switch drives VDD_CLSTR with VDD
create_power_switch SW_L2RAM -domain PD_L2RAM \ when nPWRUP_CLSTR is low
-output_supply_port {sw_out VDD_L2RAM} \
-control_port {sw_ctl nPWRUP_L2RAM} \
create_power_switch SW_DEBUG -domain PD_DEBUG \

-output_supply_port {sw_out VDD_DEBUG} \
-control_port {sw_ctl nPWRUP_DEBUG} \
RTL RTL RTL

Constraint Constraint
UPF Config’n
+ Soft IP Golden Source UPF
Constraint
+
UPF Configuration +
UPF

Impl’tion
UPF
IP Provider: IP Licensee/User: Synthesis

Impl’tion UPF
 Creates low power  Validates configuration Netlist
implementation
 Implements configuration
P&R
 Verifies implementation
against “Golden Source”
Impl’tion UPF
Netlist
Hand Off as Hard Macro
 No need to re-verify the low power implementation
– Just need to verify its low power integration in to the SoC
1. Power aware simulation model

• Corruption and retention behaviours during shutdown
• Assertions to check correct sequencing of power controls
2. Liberty model with power/ground pin syntax

• related_power_pin, power_down_function etc.
Liberty:
related_
3. Macro level UPF (descriptive not directive) power_
PD pin UPF:
• “Virtual” switches to “expose” internal supply sets Blue set_port_
attributes
• Power states, related power pins, isolation etc. -model
Hard Macro
Hand Off as Hard Macro
 Improved support for Macro Cell modelling in IEEE1801-2013
begin_power_model CLSTR
create_power_domain PD_CLSTR -elements {.}
create_supply_set PD_CLSTR.primary –update -function {power VDD} -function {ground VSS}
add_power_state PD_CLSTR –domain
-state {RUN -logic_expr {primary == DEFAULT_NORMAL &&
(!nPWRUP_CPU0 || !nPWRUP_CPU1) && !nPWRUP_L2RAM && nRETAIN_L2RAM}}
-state {RET -logic_expr {primary == DEFAULT_NORMAL &&
( nPWRUP_CPU0 && nPWRUP_CPU1) && !nPWRUP_L2RAM && !nRETAIN_L2RAM}}
-state {DMT -logic_expr {primary == DEFAULT_NORMAL &&
( nPWRUP_CPU0 && nPWRUP_CPU1) && !nPWRUP_L2RAM && nRETAIN_L2RAM}}
-state {DBG -logic_expr {primary == DEFAULT_NORMAL && !nPWRUP_DGB}
-state {OFF -logic_expr {primary == DEFAULT_CORRUPT}
end_power_model
apply_power_model CLSTR –elements uCLSTR -supply_map {PD_CLSTR.primary SS1}
 Alternatively just use the original RTL+UPF to model Hard Macro
SoC-Level Design and
Verification
Principal Engineer
Broadcom
SoC Power Intent Specification
Introduction
 A typical SoC contains:

– Hard IP (fully implemented macros)
IO Ring
– Soft IP (HDL integrated into top level) MACRO1
– Analog/mixed signal macros

– IO pads
 Challenges involved: Module 1 Module 2 MACRO2
– Number of power supplies and their

connections
– Number of system power states
– Modularizing the top level UPF
– Specification of top level iso/ls Module 3 Module N MACRON
requirements due to multiple domains
SoC UPF Outline
load_upf $env(UPF_PATH)/core/upf/core.upf –scope u_core
load_upf $env(UPF_PATH)/iopads/upf/iopads.upf –scope u_pads
if { $env(HIER_MODE) eq “TRUE” } {
load_upf $env(UPF_PATH)/hard_block/upf/hard_block.upf \
–scope u_hard_block
}
create_power_domain PD_TOP –elements { . }

source $env(UPF_PATH)/top/upf/top_power_ports.upf
source $env(UPF_PATH)/top/upf/top_power_nets.upf
source $env(UPF_PATH)/top/upf/top_supply_sets.upf
associate_supply_set aonss –handle PD_TOP.primary
source $env(UPF_PATH)/top/upf/top_submodule_connections.upf
source $env(UPF_PATH)/top/upf/top_macro_connections.upf
source $env(UPF_PATH)/top/upf/top_port_attributes.upf
source $env(UPF_PATH)/top/upf/top_system_states.upf
source $env(UPF_PATH)/top/upf/top_strategies.upf
Top-Level Supply States
Supplies Type nom turbo offmode
IO supplies Constant 1.8V

AON supply Constant 0.8V
VAR1 supply Variable/switchable 0.8V 0.9V Off
VAR2 supply Variable/switchable 0.8V 0.9V Off
VAR3 supply Variable 0.8V 0.9V
VAR4 supply Switchable 0.9V Off
Note: Some states are left

add_power_state var1ss -supply \ out for brevity
-state { nom -supply_expr { (power == {FULL_ON 0.8}) && (ground == {FULL_ON 0}) && \
(nwell == {FULL_ON 0.8}) } \
-state { turbo -supply_expr { (power == {FULL_ON 0.9}) && (ground == {FULL_ON 0}) && \
(nwell == {FULL_ON 0.9}) } \
-state { offmode -supply_expr { (power == {OFF}) && (ground == {FULL_ON 0}) && \
(nwell == {OFF}) -simstate CORRUPT}
add_power_state var3ss -supply \

-state { nom -supply_expr { (power == {FULL_ON 0.8}) && (ground == {FULL_ON 0}) && \
(nwell == {FULL_ON 0.8}) } \
-state { turbo -supply_expr { (power == {FULL_ON 0.9}) && (ground == {FULL_ON 0}) && \
(nwell == {FULL_ON 0.9}) }
Top-Level Power States
State ioss aonss var1ss var2ss var3ss var4ss
nom nom nom nom nom nom nom

state1 nom nom turbo turbo turbo nom
state2 nom nom turbo nom nom nom
state3 nom nom nom turbo nom nom
state4 nom nom nom nom turbo nom
state5 nom nom off nom nom nom
......

on nom nom !off !off nom | turbo !off
var1off nom nom off !off | off nom | turbo !off
var2off nom nom !off off nom | turbo !off
var4off nom nom off !off | off nom | turbo off
alloff nom nom off off nom | turbo off
Top-Level Power States
on nom nom !off !off nom | turbo !off
var1off nom nom off - (any) nom | turbo !off
var2off nom nom !off off nom | turbo !off
var4off nom nom off - (any) nom | turbo off
alloff nom nom off off nom | turbo off
add_power_state PD_TOP -domain \

-state { on \
-logic_expr { (var1ss != offmode) && (var2ss != offmode) && \
(var3ss == nom || var3ss==turbo) && (var4ss != offmode)} } \
-state { var1off \
-logic_expr { (var1ss == offmode) && (var3ss == nom || var3ss==turbo) && \
(var4ss != offmode)} } \
-state { var2off \
-logic_expr { (var1ss != offmode) && (var2ss == offmode) && \
(var3ss == nom || var3ss==turbo) && (var4ss != offmode)} } \
-state { var4off \
-logic_expr { (var1ss == offmode) && (var3ss == nom || var3ss==turbo) && \
(var4ss == offmode)} } \
-state { alloff \
-logic_expr { (var1ss == offmode) && (var2ss == offmode) && \
(var3ss == nom || var3ss==turbo) && (var4ss == offmode)} }
Top-Level Power Transitions
t2 ALLON
i1 Transition name next to arrow stands
for transition TO the state, eg: i1 is a
t1 i2 transition to ALLON state from
t3 i4 ALLOFF state
VAR1OFF ALLOFF
t3 t4
t4
t2 i3
t1 t2 t5
VAR2OFF VAR4OFF
describe_state_transition i1 -object PD_TOP -from {ALLOFF} -to {ALLON} –illegal

describe_state_transition i2 -object PD_TOP -from {ALLON} -to {ALLOFF} –illegal
describe_state_transition i3 -object PD_TOP -from {ALLON} -to {VAR4OFF} –illegal
describe_state_transition i4 -object PD_TOP -from {VAR4OFF} -to {ALLON} –illegal
describe_state_transition t1 –object PD_TOP -from {ALLON} –to {VAR1OFF VAR2OFF}

describe_state_transition t2 –object PD_TOP -from {VAR1OFF} –to {ALLON VAR2OFF VAR4OFF}
describe_state_transition t3 –object PD_TOP -from {VAR2OFF} –to {VAR1OFF ALLON}
describe_state_transition t4 –object PD_TOP -from {VAR4OFF} –to {VAR1OFF ALLOFF}
describe_state_transition t4 –object PD_TOP -from {ALLOFF} –to {VAR4OFF}
SoC UPF Integration Tips
Summary
 Design/UPF Partitioning
 Modularization
 Mixed language handling
 IO modeling
 Macro handling
Design/UPF Partitioning
 Partition design UPF into sub-module UPF

– Place and route block boundary
– Power domain boundary
load_upf $env(UPF_PATH)/module1/upf/module1.upf \
-scope core_inst/module1_inst
 Iso/Ls inside blocks or at top level

– Number of domains < N, Iso/Ls insertion at top
• Block/sub-module implementation is simplified, all domain crossings at top
– Number of domains > N, Iso/Ls inside implementation blocks/sub-
modules
• Block/sub-module low power implementation is self contained
• Top level domain crossings are minimized, simplifying top level
implementation
Modularizing Top-Level UPF
 Break up the contents of top level UPF into multiple

files for readability
– Top level power ports
– Top level power nets
– Top level supply sets
– Macro connections
– System power states
source $env(UPF_PATH)/top/upf/top_power_ports.upf
source $env(UPF_PATH)/top/upf/top_power_nets.upf
source $env(UPF_PATH)/top/upf/top_macro_connections.upf
source $env(UPF_PATH)/top/upf/top_system_states.upf
Mixed Language Handling
 Be aware of HDL case sensitivity

– Verilog/VHDL (and UPF) – case sensitive
– VHDL – case insensitive
– Issue: This particular affects how we write a UPF for a piece
of HDL code
• find_objects – by default returns case sensitive match patterns
 Bus notation differences

– Verilog/System Verilog – square bracket
– VHDL – parenthesis
 Tip
– Keeping the domain boundary in one HDL type helps keep the
UPF simple.
IO Modeling
 IO pad con
– Special structure involving multiple power supplies
– Need many connect_supply_net connections
– Special IO cells connected to analog constants need additional
domains (hierarchies)
set pad_inst_list [find_objects . -pattern “PADRING_*” \
-object_type model -transitive]
foreach pad_inst $pad_inst_list {
connect_supply_net pad_ring_VSS -ports “$pad_inst/VSSP”
}
 Supply port/net/set reduction using equivalence

– Several IO supplies are functionally equivalent
– Some supplies might be connected at package level/off-chip
set_equivalent –function_only { AVDD VDD1P8 pad_ana_VDD }

set_equivalent –function_only { AVSS pad_AVSS ana_VSS VSS dig_VSS }
Handling Macros
 Macro connections
– Analog macros - all non-default connections need to specified
with connect_supply_net
– Analog model should include pg_pin
definitions/related_power_pin/ground_pin definitions
– Special care needs to be taken for macros with internal
supplies
• Does that need additional top level isolation/level-shifting
set pll_inst_list [find_objects . -pattern *u_pll* -object_type inst \

-leaf_only -transitive]
foreach inst $pll_inst_list {
connect_supply_net 1p8ss.power -ports “$inst/AVDD1P8”
connect_supply_net 1p8ss.ground -ports “$inst/AVSS”
}
SoC Verification
Power Aware Simulation
Power-aware Bench,
UPF HDL
libraries (.v/.sv/.lib) Drivers
Power aware simulator
Reports Waveform Coverage
SoC Test-bench UPF
# Set the scope to the test bench

set_design_top top/chip_tb_inst
# Load chip upf

load_upf $env(UPF_PATH)/chip/upf/chip.upf –scope u_chip
# Global settings –treat all partial on as OFF

set_partial_on_translation OFF
# Simstate settings – simulation behavior for a model/library

load_simstate_behavior MACRO_LIB -file macro_lib_simsate.upf
set_simstate_behavior ENABLE -lib ANA_PLL_LIB -model ANA_PLL
....
SoC Test-bench
module chip_tb;
....... Supply driver
(model off chip suplies)
`ifdef DEFINE_UPF_PKG
import UPF::*;
`endif
// Constant supplies VDD_1P8 AVSS VDD_VAR
initial
begin
supply_on(“VDD_1P8”, 1.8);
supply_on(“AVSS”, 0);
Chip
supply_off(“VDD_VAR”, 0);
.......
SoC Test-bench
// Dynamic supplies
always @ (posedge system_clk, negedge por)
begin
if(supply_requested)
begin
if(supply_value==0x1)
supply_on(“VDD_VAR”,0.8);
else if(supply_value==0x2)
else if(supply_value==0x3)
else
end
else Note: system_clk, por and supply_value
are signals in the test bench, not UPF
supply_off(“VDD_VAR”,0);
objects
end
end
Adopting UPF
Principal Engineer
Broadcom
Recommendations for Adopting UPF
Draw a power • A color coded domain hierarchy illustrating picture

• Visually describes the domains, relationships, isolation
diagram locations, power connectivity etc
Enable • Initial UPF could leave out implementation details

incremental UPF • UPF can be refined during the flow
• Understanding what is implementable with a given set

Know your of libraries is useful
libraries • A rich library set could allow various implementations,
the user can choose the most optimal combination
• Tcl variables, foreach loops, procs could help making the

Unleash the UPF compact and readable
power of Tcl • For example: find_objects can return a list which a
foreach loop could consume to do a certain operation
• Try to keep the UPF technology agnostic if possible, this

Enable UPF reuse way, it can be paired with technology agnostic RTL and
reused.
Avoid vendor • Use of tool specific commands in a UPF file is not

allowed per standard. It is possible vendors might allow
specific this, but it would make the UPF non-portable.
constructs • Use of a pure UPF based solution is recommended
• If loading other UPF files or helper tcl files, avoid hard-coding the
Avoid hardcoding path. Try using a configurable env variable instead.
paths • Avoid hardcoding HDL hierarchical paths if possible by using
find_objects (allows use of same UPF in spite of hierarchy changes)
• Add comments wherever possible. UPF is like HDL, the author’s

explanation in the form of comments might be useful to the end
Keep it readable user
• Indent command options appropriately to make them readable.
• Try to break up the UPF into functional boundaries if possible

Modularize instead of having a long file. Again, think how we would write RTL.
It is never easy to debug a big-flat design with no hierarchies.
Adopting UPF*
Shreedhar Ramachandra
Staff Engineer
Synopsys
* Slides contributed by Jon Worthington
 1) Determine the domains needed by identifying

areas of the design that will have different supply
needs.
– Sometimes cells that have the same supply requirements
may actually benefit to being in a unique domain if there are
other reasons to treat them differently. Such as if they reside
in a very different physical regions of the chip, or require a
different set of strategies or power states to apply to them.
– Consider the hierarchy connections between cells of the same

domain. Should they really cross a different domain just
because they need to traverse logic hierarchy? An extra level
of hierarchy my help here.
 Make sure you build a UPF that is common to both your

verification and implementation flow
– you want to verify what you are implementing.
 Build the complete power state table –

– In verification you check for the correctness and completeness of your power
state table and in implementation, static checking you take the power state
table as golden for all the optimization. So start with a complete PST.
 Analyze your protection requirements early

– so that you can build generic isolation policies that still give you optimum
results without redundant isolation cells.
 Check your libraries.

– You should have libraries characterized at all corners based on all the
combinations of voltages on the supply nets to make sure that the power
intent is implementable and that you have protection cells to meet the
requirements of your power intent.
 Make sure the power architecture your implement

will actually save power.
– Ensure the saved power outweighs the additional power
consumed by iso cells, level shifters, and power switches
 Make sure the power intent you create aligns with

the physical implementation of your design.
– As an example, at the RTL level ISO cells and LS can be
specified in a wide range of locations. But in the physical
implementation, these cells will require special power
connections that can have real impact on the physical design.
Tip: Align Power Domains and Logic Hierarchy
 Multi-element power domains can lead TOP

to unexpected “intra-domain” isolation
create_power_domain RED –elements {A B} A B C
iso
 These can often be avoided with a TOP

different approach
create_power_domain RED –elements {.} A B C D
create_power_domain BLUE –elements {C}
E
 Better to align power domains with logic TOP
hierarchy if at all possible
RED BLUE
create_power_domain RED –elements {RED}
create_power_domain BLUE –elements {BLUE}
A B C D
Failing that, use -diff_supply_only option
or the -source/-sink filters
Where We Go From Here
John Biggs
ARM
IEEE 1801 (UPF) timeline
UPF-1.0 UPF-1.0 New Project CPF-2.0 New Project New Project

Kick off Donated Revision of Donated Revision of Amendment of
Meeting to IEEE 1801-2009 to IEEE 1801-2013 1801-2013
2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
Accellera IEEE1801-2009 1801-2013 1801a-2014 1801-2016

UPF-1.0 (AKA UPF-2.0) (AKA UPF-2.1) (Amendment) (AKA UPF-3.0)
Published Published Published Planned Planned
P1801 Work Group Plans
 1801-2013 Amendment PAR (2014)

– Project on the agenda for approval at the March 2014 IEEE-SA
board meeting
– Correct technical/editorial errors and inconsistencies
– Address a small number of critical enhancements
 1801 Full Revision PAR (2015/16)

– Project approved at the June 2013 IEEE-SA board meeting
– Extend scope of “Power Intent” up towards System Level
– Add power modeling and estimation capabilities
• SAIF integration and extension
– Consider further UPF/CPF methodology convergence
– Enhance and extend Low Power Methodology Annex
System Level Power Intent
 Depends on perspective
– SW Centric: abstract, task, transaction/event based
– HW Centric: detailed, component, state/level based
 Bridge the gap

– Top down: Add detail to the abstract SW centric
world of system performance modelling.
– Bottom up: Add abstraction to detailed HW centric
world of RTL+UPF implementation
 Extend UPF as far as is appropriate

– Raise abstraction level of “power intent”
– Need a better understanding of the system level requirements.
 Working closely with the IEEE Low Power Study Group

– Helping to coordinate various standard activities in this area
– Si2/LPC, Liberty, IP-XACT IEEE1666 SystemC
System Energy Analysis & Optimization
Software Centric Analysis and Optimization:
Applications Software impacts on energy consumption – trend based analysis
Detecting and correcting energy bugs in software
System power management (RFTS/DVFS) optimization
System Power Management
Middleware OS level system and runtime power management bring-up

& OS
System Centric Analysis and Optimization:
Energy aware heterogeneous multi-core architecture exploration
Drivers Energy aware hardware-software partitioning
Energy aware SoC hardware architecture and exploration
Memory system topology and interconnect optimization
Hardware Scenario driven power state space optimization
Platforms Power Management Unit (and PMIC) architecture and design
Dedicated hardware (ASIP) for energy efficiency
SoC Hardware Centric Optimization:

Low power design and verification
Component level power optimization
IP Power aware SoC component integration and optimization
Macro model enhancements for low power design
Source: Alan Gibbons, Synopsys Inc.
System Level Power Subcommittee
 Formed Feb 2014

– 18 people from 11 Entities, Chair: Alan Gibbons, Synopsys
– Requirements gathering phase
• Focus on Virtual Prototyping
– Face2Face meeting April 8/9/10th in UK
 Near term objectives:
– Identify practical use models
– Determine accuracy and granularity requirements
– Scope and extent of standardisation?
• Power model structure, consumption data, activation, interfaces...
– Evaluate feasibility of extending 1801 to meet requirements
• Deliver proposal on specific extensions to 1801 Work Group
– Develop and prototype specific examples
Interested in working on UPF?
Join the working group!
Send email to [email protected]
http://standards.ieee.org/develop/wg/UPF.html
211

UPF For Low Power 2014

Uploaded by

Copyright:

Available Formats

UPF For Low Power 2014

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UPF For Low Power 2014

Uploaded by

Copyright:

Available Formats

Using UPF for

Low Power Design and Verification

 This tutorial presents the latest information on the Unified

 Why power is important - and challenging

 John Biggs, ARM Ltd.

 Erich Marschner, Mentor Graphics

 Sushma Honnavara-Prasad, Broadcom

 David Cheng, Cadence

 Shreedhar Ramachandra, Synopsys

 Jon Worthington, Synopsys

 Nagu Dhanwada, IBM

 Where We Go From Here

* With slides contributed by Nagu Dhanwada and Sushma Honnavara-Prasad

 Power density is increasing every process node

 Reducing power with:

 Early power estimation and budgeting

 Power aware flow

 ESL (algorithm and

Power grid / thermal analysis

Static timing (CPS)

Implementation • Synthesize RTL to gates using power optimizations

Workloads / Power Analysis

Power RTL Design

Workloads / Power Analysis

ESL Design Power

 Flow execution is limited

models (directly or indirectly)

– Simplistic power models may be

Cycle Accurate Cycle Protocol

Register Transfer RTC Protocol

Register Transfer Protocol

ANSI C/C++ ANSI C/C++ or Algorithmic SystemC

Untimed TLM “Untimed” SystemC Transaction Level Model

Timed TLM “Timed” SystemC Transaction Level Model

Cycle Accurate Model Cycle Accurate “Behavioral” SystemC Model

Mixed Abstraction Mixed Abstraction Level Modeling

 UPF models active power management

Simulation, Logical Equivalence Checking, …

 For Power Intent

 Power Supply Network

 Power State Table

 Level Shifter Strategies

UPF-1.0 UPF-1.0 New Project CPF-2.0 New Project New Project

Accellera IEEE1801-2009 1801-2013 1801a-2014 1801-2016

Accellera UPF-1.0 (2007)

Supply Nets: HDL Interface:

IEEE 1801-2009 (UPF-2.0)

Navigation: Attributes: Control Logic:

Supply Nets: Supply Sets: HDL Interface:

IEEE 1801-2013 (UPF-2.1)

Navigation: Attributes: Control Logic:

Supply Nets: Supply Sets: HDL Interface:

=> Improved methodology convergence with CPF flows

 Revisited each and every command

 Rewrote many key sections:

 Added new sections:

 Final Draft (D14) approved by IEEE-SA March 2013

 IEEE1801-2013 Published May 30th 2013

* Slides contributed by Jon Worthington