Methodology for effective hierarchical
verification of low power designs
Ramesh Rajagopalan (rameraja@cisco.com), Cisco Systems Inc, San Jose, CA
Namit Gupta (namit@synopsys.com), Synopsys Inc, Mountain View , CA
Authors Information
1) Ramesh Rajagopalan ,Cisco Systems Inc, rameraja@cisco.com,
phone(408)3903607
Ramesh has been in the physical design field for over 19 years and he is currently a
Technical Leader with Switching Silicon Group at Cisco. Physical design of Custom
network switching ASICs and UltraSparc microprocessors form part of his
experience.
2) Namit Gupta, Synopsys Inc,
Namit Gupta is a Staff corporate application engineer at Synopsys Inc with responsibility
for verification solutions. Gupta holds a bachelor’s degree in electronics from the
Indian Institute of Technology, Delhi. Among Gupta’s interest areas are RTL design
and verification, clock domain crossing, low power, design constraints, and ESL.
Phone 550-215-0765
Email namitg@synopsys.com
Abstract
 With increasing demand to conserve power in ASICs, there is
a need for advanced low power techniques right from
architecture planning till implementation.
 This paper/poster provides methodology used by us to come
up with efficient way to plan the power intent, do a quick check
to ensure completeness and correctness, followed by
verification and implementation.
 And during this process we faced challenges during the use of
such methodology, and came up with techniques to overcome
those for efficient implementation of low power design.
Motivation: “Correct by construction” methodology for a
low power design technique
Current size and complexity of SOC/ASIC designs dictate
- use of advanced low power techniques to reduce power and
- saving and restoring of critical design states.
Use of multiple voltages in the design is one of the widely adopted low power
technique.
- Different parts of a chip might have different speed requirements.
- A lower supply voltage reduces power consumption but also reduces
speed.
- To get maximum speed and lower power at the same time, only blocks that
need to work at higher clock rates can operate with a higher supply voltage
while the other blocks can operate with a lower voltage.
Significance of power intent description
 it is almost a necessity that from very beginning power intent is mostly clear.
This is the main reason that power intent description has become integral
part of RTL development.
 Power intent needs to be captured for various power domains, switches to
turn on/off supplies, voltage levels of supplies, protection devices like level
shifter, isolation
 Providing two or more supply voltages on a single chip introduces some
complexities and costs.
 Additional device pins must be available to supply the chip voltages, and the
power grid must distribute each of the voltage supplies separately to the
appropriate blocks.
 Where a logic signal leaves one power domain and enters another, if the
voltages are significantly different, a level-shifter cell is necessary to
generate a signal with the proper voltage swing. A level shifter cell itself
requires two power supplies that match the input and output supply
voltages.
Power intent guides physical power grid
implementation
•
Using the power intent description, abstract power supply networks are
defined, also called as “supply sets”.
•
The most important step which needs careful planning is to define valid
power states combinations
•
Once supplies are defined explicitly using “create_supply_port” OR implicitly
using “create_supply_set”, then valid supply states are defined next using
“add_port_state” and “add_power_state”.
•
This means defining when state will be “off”, “high_voltage”, “low_voltage”
etc.
•
the Power State Table (PST) describes all the possible power states of a
design and is used as a “golden” reference by implementation tools and
static verification checkers.
Why Static Verification?

Static verification checks on



Isolation and level shifters versus requirements implied by PST
Missing/Incorrect/Redundant protection devices
Is my micro-architecture correct?

Island order checks on control/clock paths in the design w.r.t enables of protection elements

Static verification Checks – to ensure that implementation is following the power intent

What were assumptions made in our methodology and how we took care of gotchas

PST is reference – What if there is a bug in PST?
 Once design is simulated with all legal states, power aware simulation can capture
such issues

How can I ensure my dynamic verification team covers all legal states and power shutdown
during simulation?
 It is extremely important to plan low power specific coverage from start and track it till
closure
Challenges : Use of PST in Hierarchical design
verification


PST as used in subchips and in a hierarchical top level verification.
Need to merge PSTs to verify hierarchical design
Use of PST in Power-Aware verification
 A power state table is a collection of all possible power states for all input supply
net/ports of a design.
 Given a PST, synthesis tool would implement the design in such a way that no
LS/ISO/Logic violation could be found in the design.
 In a flatten design, theoretically level shifters and isolation cells can be inserted at
anywhere in the design. Therefore, it is always possible to implement the design
without any LS/ISO/Logic violations for a given PST.
 However, in a hierarchical flow, because some sub-blocks are not allowed to
change, LS/ISO/Logic violations are impossible to resolve if they happen within
fixed sub-blocks.
 Those errors can only be prevented by enforcing certain relationship among
PSTs specified at different hierarchy.
 Assumptions we made for making it methodical



One PST at each scope
Only power state nominal values for state comparison
Merged PSTs reflects intersection of all legal states of all scope PSTs
Example of PST correctness need
 Consider following example, where there are 2 domains PD1
and PD2, where VDD1 is primary supply of PD1 and VDD2 is
primary supply of PD2, as per specification below are the valid
states
BUG
VDD1/
PD1
ISO
Cell
VDD2/
PD2
 If VDD1 and VDD2 is ON and OFF simultaneously, there is no
need to for ISO cell
 But with VDD1 OFF and VDD2 ON, combination in PST can
contradict this and bug will slip through
Challenges : Use of PST in Hierarchical design
verification
Figure 1: Example of PST merging with disjoint set of supply signals
X
Figure 2: PST Example of PST merging overlapping set of supply signals
X
X
Null PST
Low Power Assertions
 Automatic assertions

Common assertions based on design + power intent
 User defined assertions


Any dedicated assertion using LP data
Depending on design/project need

For example sequence of sleep signal with reset
 Goal is to increase confidence on the LP regression suite,
like…



Ensure all PD have been switched on/off
Ensure all Multi-Rail Macros have been switched as expected…
Specific checks to workaround missing or inaccurate models
Need for PST validation
 PST describes all valid combinations of voltage values
 This information is used by implementation tools to determine
protection needs
 At runtime, simulator has accurate knowledge of state and
voltage value of each net of the design…


Can report PST state changes
Can report when reaching an ‘illegal’ state
Limitations and Future Work

Assumptions we made for making it methodical



One PST at each scope
Only power state nominal values for state comparison
Merged PSTs reflects intersection of all legal states of all scope PSTs
Future Work:
PST verification is a very critical step and we need to fine tune the
methodology to make it of signoff quality.