Low Power Functional Verification

and Closure of Power Intent

Cadence Design Systems

Neyaz Khan
Canvas Conversations

Presented at

Abstract
As gate densities increase with the availability of newer deep-submicron processes, and as designers cram more
functionality on a typical SoC, the limiting factor has very quickly become the power dissipation on a chip.
Functional verification which was already a major bottleneck in todays fast paced electronics industry, is
becoming an increasingly more difficult problem as designers implement advanced power management
techniques on a chip. There is an urgent need to include power verification as part of the RTL verification
process. This paper focuses on the verification of power intent which has traditionally been ignored during the
RTL development process. It examines the available power management techniques and also proposes a way to
include power verification as part of a comprehensive verification plan. It concludes with an example of
verification automation for functional closure of power intent.

Introduction
Its no secret that todays devices are increasingly power-hungry - a single data-center can consume enough
power to light up 2500 homes [1]. Power management is becoming an increasingly urgent problem for almost
every category of design as power density measured in watts per square centimeter is rising at an alarming
rate. In an often published Intel chart, of power density versus process node, the slope of the curve lies between
that of a nuclear reactor and a rocket nozzle [3], and the problem is getting worse. Nowhere is the problem
worse than that of wireless personal communication systems, where the Swiss army knife effect on mobile
phones is leading towards the rapid convergence of computing, communications and personal entertainment
devices [2]. There is a tremendous emphasis on extending battery life, at the center of which is a very
aggressive need for on device power-management. Power management is not just limited to mobility
applications - almost every design at 65nm needs to worry about power.
In the pursuit of effective power management solutions, designers are starting to stretch the limits from device
physics to circuit-design and system-level optimization techniques. From an ASIC engineering perspective, no
longer can power management be limited to the post-synthesis phase almost as an afterthought to functional
design, but rather an effective energy management has to be built into the design itself [8]. Designing an SoC
for good power management requires that low power design must be considered when defining the architecture.
To maximize efficiency, power intent must also be captured together with functional intent at the RTL
development stage and the effects of power control on device functionality verified together with device
functionality. In other words, the verification of power intent must start during RTL development stage.

Power Management
Lets take a quick look at some advanced Power management techniques used in the industry today. But first,
lets take a look at the source of Power consumption on a chip, and examine the need for functional verification
for each:
Eqn 1
Power = Pswitching + Pshort-circuit + Pleakage + Pstatic
Pswitching = a .f.Ceff .Vdd2
Eqn 2
Where a = switching activity, f = clock-freq, Ceff = effective capacitance & Vdd = supply voltage
Dynamic power can be lowered by reducing switching activity and clock frequency which effects performance,
and also by reducing capacitance and supply voltage

Pshort-circuit = Isc .Vdd

Eqn 3
Where Isc is the short circuit current during switching and Vdd the supply voltage

Managing Multiple Power Domains

Since supply voltage effects both the switching [Eqn2] and the short-circuit power [Eqn3], there is a need to
scale back voltage level to the least possible value that meets performance. This results in multiple powerdomains on a chip, often separated by level shifters. At the RTL level, there is no specific way to verify the
effect of voltage-levels in digital simulation today.

Power Shut-off
Power gating is employed to shut off power in standby mode, see Figure 1. Since leakage power is the dominant
source of power dissipation in the 90 nm and smaller technologies - this is a very effective way to reduce
leakage power. There is a need for a specific power-down sequence, which includes isolation (see section 0).
Erroneous power-up/down sequences are the root causes of errors that can cause a chip respin. This needs to be
correctly and exhaustively verified along with functional RTL.

Isolation
Isolation logic is used typically at the output of a powered down block to prevent X-propagation from powered
down blocks. Isolation precedes power-down to prevent possible damage to CMOS gates. Isolation cells are
placed between two power domains and are typically connected from domains powered-off to domains that are
still powered-up as shown in Figure 1.
VDD
PwR

Isolation cell

Switch
Iso

VSS

Figure 1: Isolation Gate and Power-down switch

State Retention Power Gating

There are specific cases where the state of key control flops need to be retained before gating power off, and
restored after turning power on. To speed power up recovery, SRPG flops can be used, see Figure 2. These
retain their state while the power is off.

VDD
PwR

Switc
h
VRET

VDD
D

SRPG
Cell

Clk
Ret
VSS

Figure 2: State Retention Power Gating

Power Cycle Sequence

For Power Down, a very specific sequence needs to be followed: Isolation, followed by State-Retention,
followed by power shut-off. On the power-up cycle, the exact opposite sequence needs to be followed as shown
in Figure 3
ISE

Signal isolation enabled

PSR

SRPG in retention state

PSE

POWER OFF state

Restore of gate loads

Isolation of gate loads

Ensure state retention
Power switch off

Optional CGE

Switch back from state retention

Power switch on

Remove clocks on SRPG flops

Figure 3: Power Up/Down Sequence

Given that there are multiple, and possibly nested power domains, coupled with different power-sequences,
some of which may share common power-control signals and the presence of multiple-levels of gated clocks,
there is a tremendous need for verification support. The complexity and possible corner cases need to be
thoroughly analyzed - functional and power-intent must be analyzed and thoroughly verified together using
advanced verification techniques. In the following sections, lets take a closer look at how to achieve that.

The Design
The design used for this work is the MAC-DMA design which is part of a larger SoC design. The basic
operation consists of the DMA engine waking up when encrypted data is available, and performing a multichannel DMA operation over the two MACs shown in Figure 4.

Power Control Module

The Power Control Module (PCM) in Figure 1 generates all power control signals. It typically gets its control
from an external source under software control. The PCM often works in conjunction with an on-chip clock &
reset controller for timing and synchronization of Power control signals. For simplicity, the detailed control
signals are not shown here.

Figure 4: Block diagram of design

Verification Flow
The Verification flow starts with the creation of a Verification Plan which contains metrics for both Dynamic
and Static Verification. Dynamic Verification, also known as Simulation, is employed for the creation of
constrained and targeted stimulus so as to reach the Metrics in the fastest and most optimal fashion using
Coverage Driven Verification techniques. The creation of appropriate stimulus is constantly adjusted
throughout the verification process by comparing collected metrics against the targets. This is best done by
using tools to automate and managing the Verification process. Static or formal verification is also performed
on appropriate and key control design units. While, this best describes the functional Verification flow for the
full SoC, the following sections focus mostly on the Verification of Power intent.

Verification Planning
Verification planning starts with bringing all stake-holders together - System Engineers, Architects, Designers
& Verification engineers to capture the verification intent. It is the process of analyzing the design
specification with an aim toward quantifying the scope of the verification problem and specifying its solution.
[4].

Capturing Power Intent

Needless to say, the Verification plan must also contain a section on the Verification of Power-Intent. This
section of the Verification plan describes the verification requirements to exercise all Power Modes and controlsignal transitions that are needed to exercise the targeted Power Modes. It would also specify the desired
behaviour of design elements and specify the conditions and sequences of events that would lead to the design
elements being in a desired Power State see Figure 5.

Figure 5: Verification Plan for Capturing Power Intent

Executable Verification Plan

The end product of the planning stage is the generation of a machine executable Verification Plan that can be
used to track the progress of the Verification effort using metrics like Functional Coverage. For more details on
how functional coverage can be used for verification closure refer to [4]

The Role of Functional Coverage in the Verification of Power Intent

Functional Coverage is widely used in the industry to measure the quality of a verification effort and to answer
the basic questions am I done verifying my design [8]. Similarly, Functional Coverage can be used to gauge,
and quantitatively measure the quality and completeness of Power intent by first creating a Coverage Model
around the Power control elements of the design (section 0), and then managing the verification effort (section
0) in an efficient way so as to maximize the collection of Coverage data in an optimal way.

Functional Closure of Power Intent

Power closure is achieved as a two step process:

Coverage Model Design for Power Intent.

Once the desired features of interest have been extracted from the design and captured in the
Verification plan, the next step is to quantify the desired functionality that needs to be tested.
This step is typically referred to as Coverage model design for a detailed analysis and step
by step process refer to [7].
The measure of how well the power intent has been functionally verified is gauged by using functional coverage
models to capture power intent. These are currently implemented using e Cover Groups. The CPF file is parsed
for intended Power Intent and the corresponding e code is generated automatically an example of which is
shown in Figure 6.

Figure 6: Power Coverage Models

Coverage Closure of Power Goals.

So what does closure really mean in the context of achieving Power goals? Power Closure
would formally be defined as achieving pre-defined Verification goals using specified metrics
such as Coverage. In our example, the metrics are Functional Coverage from targeted Cover
Groups created to measure Power Coverage (section 0) and Assertions. The Coverage goals
in our testcase are specified in the executable Verification Plan (section 0) and the results
captured during simulation. As shown in Figure 7, the cumulative coverage results are then
annotated onto the corresponding elements in the Verification Plan to reflect achieved
verification goals. These are then used to determine power closure.

Coverage Analysis achieving closure

On examining the results in Figure 7, it looks like all the Power Domains for PDmac1 have been fully
exercised, i.e. functional coverage shows 100% covered. However, the overall value for Power Coverage is
shown to be only 75%. On further analysis, i.e., looking at the buckets for Power Mode, holes are identified in
the Coverage space which corresponds to a missing testcase where both the MACs need to be powered off.
Clearly this condition has never been verified, and needs to be fully satisfied in order to achieving power
closure.

Figure 7: Executable Verification Plan with Annotated Coverage Data

Verification Management
The main purpose is to manage, control and automate the process of functional closure, i.e. to achieve the
verification goals. The goals may be specified in terms of metrics like functional coverage, or property proofs,
or any other parameters that can track the progress and quality of verification itself.
Failure Analysis is performed to correlate failed simulation runs to the run parameters. Its very useful for rootcause analysis like first failures. As seen is Figure 8, the root cause of failure that effects all three runs is the
firing of an assertion, signifying the error that caused the first failure in all three runs.

Figure 8: Failure Analysis

Verification of Power Intent

The problem with the verification of Power intent is that there are no standard flows or tools in place today. The
traditional approach to power management has been to hack RTL and instantiate custom power control gates
etc. which are not always simulateable. In the rare cases that simulation models do exist for the power-control
element, it begs the question, how does one simulate complex power control features like state-retention and
isolation? Modifying golden RTL also raises an entire set of new problems with IP and reuse that are not easily
answered.
While some have taken the approach of creating custom libraries, or using PLI/API based routines to
manipulate simulation results, its yet to be seen how this would be effectively simulated with functional RTL.
At the back of this discussion is also the nagging doubt what is the golden source? Would it be RTL, or some
form of hybrid HDL, or some PLI based application?
The answer may lie in a solution that truly augments functional RTL by capturing Power intent in a form that
can be used by all related tools simulation, synthesis and back-end, for both functional and structural
verification.
Such a solution was used in the work reported in this paper.

Low Power Simulation Techniques

Table 1 lists some advanced Low Power Techniques used in the industry today. While, there is no special
requirements to simulate things like clock-gating, and the effect of voltage scaling is beyond the realm of digital
simulation, one of the hardest things to do from a verification point of view is to simulate the behaviour of
Power shut-off (PSO).
Table 1. Simulation Support for Low Power Techniques
Technique

Sim
Support

Clock-gating

Yes

Multi Voltage
Islands

No

DVFS

Yes

Power Shut-off

Yes

Comments
Does not require any special sim.
Support.
Digital sim not effected by
voltage. No special sim support
required
Frequency scaling does not
require any special support

Simulation of PSO Behaviour

The following sections show how PSO behaviour was successfully verified:
Power gating of targeted power domains
Isolation of specified Primary outputs
State loss due to power shut-off of specified SRPG flops
State restored on power on of specified SRPG flops

Figure 9: Simulation of PSO Power Cycle Behaviour

Failure Analysis
Is the process of reviewing failed simulation results to determining the root cause of failures as it relates to the
run-parameters. While there are several factors that can lead to simulation failures, the emphasis in this section
is on catching erroneous behaviour while verifying power intent.

Figure 10: Incorrect Sequence - Power Cycle with Errors

Assertion Based Checks

There are three main phases of interest during the simulation of low-power behaviour. They are:
1. Power-Down: Time from when the device decides to power off, until the device is actually powered off.
2. Power Shutoff: time that the device is actually shut off.
3. Power-Up: The time from when the device decides to power up until it is up.
Figure 11 shows some examples of how Assertion based checkers are coded to catch erroneous behaviour
during the various stages of the power cycle described above. Note how in Figure 10, the Assertions flag
incorrect PSO behaviour - both during Power-down and Power-up sequence.
// Isolation must occur before Power Shut-Off
PwrAsrt_Iso_before_PowerOff:
assert always ({!iso_en; iso_en} |->
(power_shutoff before !iso_en)
) @(posedge clk);
// Isolation must hold steady during Power Off
PwrAsrt_hold_Iso_during_PowerOff:
assert always ( {!iso_en; iso_en[*] ; power_shutoff} |->
(iso_en until !power_shutoff)
) @(posedge clk);
// Power Up cycle
PwrAsrt_PowerUp_cycle:
assert always ({power_shutoff; !power_shutoff} |->
{iso_en[*]}
) @(posedge clk);

Figure 11: Assertion Based Checkers

Assertions are also used to provide Coverage Data to supplement those obtained from Cover-groups as
discussed in section 0. They can also be used to define properties and constraints for designs being analyzed
using a formal verification tool.

Use of Static Verification Tools

The verification of the Power Control Module (PCM) can be very effectively and efficiently performed by using
Static or Formal Verification tools. The PCM itself is typically a rather complex state-machine, and is an ideal
candidate. It would take many simulation-cycles to exhaustively verify such complex state and precise control
sequences in the traditional Dynamic simulation environment, and to achieve a high level of coverage would
take even more cycles.

Conclusion

Power management is an increasingly urgent problem in modern day chip design. While the problem is well
understood, and the industry has stepped up to meet the challenge with advanced power management
techniques, it has traditionally been applied during the post-synthesis phase. New EDA technology and tools
used in this paper was used to simulate Power Intent at the RTL development phase, where its needed the most
and can have the highest impact. Together with available Verification Process Automation tools, it provides a
unique opportunity and capability to perform Power Closure very effectively and early in the design process
with spectacular results, and the promise to improve quality and productivity in a comprehensive and repeatable
fashion.
In this case study, an executable Verification plan was created targeting Power Intent. Power Closure was
achieved based on targeted Parameters and metrics collected while simulating Power Shut Off behaviour of the
MAC-DMA design at the RTL stage.

Acknowledgement
I would like to acknowledge the contributions of the various Cadence R&D, Product Engineering, Core-Comp,
Services and Sales & Marketing teams IUS, RC, Conformal, Encounter, ET, VPA, and IFV that contributed to
the technical materials in making this paper possible.

References
[1] Therese Poletti, "Taming data centers' appetite for energy," San Jose Mercury News (CA), Page 1C, Feb. 1, 2006,
www.mercurynews.com/mld/mercurynews/business/13762620.htm.

[2] Walter Croce. Cell Phones Demand Better Battery Life. Electronic Design (July/Aug 2004) http://www.wsdmag.com/Articles/ArticleID/8629/8629.html
[3] Jack Horgan. Low Power SoC Design. EDA Cafe (17-21 May 2004) http://www10.edacafe.com/nbc/articles/view_weekly.php?articleid=209217
[4] Andrew Piziali: Verification Planning to Functional Closure of Processor-Based SoCs. DesignCon (Feb. 2006). http://www.designcon.com/2006/pdf/3tp2_piziali.pdf

[5] Robert Aitken, George Kuo, and Ed Wan, Low-power flow enables multi-supply voltage ICs. EE Times (21st March 2005).
http://www.eetimes.com/showArticle.jhtml?articleID=159902216

[6] David Lammers: Leakage current needs multipronged attack. In CMP Power Management Design Line
(5th Dec 2005) http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=174900266
[7] Andrew Piziali. Functional Verification Coverage Measurement and Analysis. Kluwer Academic Publishers, Norwell, MA, 2004.
[8] Leena Singh, Leonard Drucker, Neyaz Khan. Advanced Verification Techniques: A SystemC Based Approach for Successful tapeout. Kluwer
Academic Publishers, Norwell, MA, 2004.
[9] Mohit Bhatnagar, Jack Erickson, Anand Iyer, Pete McCrorie. Save Those Watts with A Power-Aware Design Flow for SoCs. Electronic Design
(06th July 2006). http://www.elecdesign.com/Articles/Index.cfm?ArticleID=12946
[10] PFI Core Comp Team. CPF AE LP Workshop Training Material. Cadence Internal Training 2006-2007