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 bachelors degree in electronics from the
Indian Institute of Technology, Delhi. Among Guptas 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

ISO
VDD1/ Cell VDD2/
PD1 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

Figure 2: PST Example of PST merging overlapping set of supply signals

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.