8/10/2019 111 Paper

1/12

Low Power Functional Verificationand Closure of Power Intent

Cadence Design Systems

Neyaz Khan

Canvas Conversations

Presented at

8/10/2019 111 Paper

2/12

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, isbecoming 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 verificationprocess. 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 ofverification automation for functional closure of power intent.

Introduction

Its no secret that todays devices are increasingly power-hungry - a single data-center can consume enoughpower 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 betweenthat 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 entertainmentdevices [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 devicephysics 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 functionaldesign, 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 RTLdevelopment 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:

Power = Pswitching+ Pshort-circuit + Pleakage +Pstatic Eqn 1

Pswitching= a .f.Ceff.Vdd2

Eqn 2

Wherea= 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

8/10/2019 111 Paper

3/12

Pshort-circuit = Isc.Vdd Eqn 3

WhereIscis the short circuit current during switching and Vddthe supply voltage

Managing Multiple Power Domains

Since supply voltage effects both the switching [Eqn2] and the short-circuit power [Eqn3], there is a need toscale back voltage level to the least possible value that meets performance. This results in multiple power-

domains 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 reduceleakage 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 becorrectly 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 arestill powered-up as shown in Figure 1.

Isolation cell

VDD

PwR

VSS

Switch

Iso

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. Theseretain their state while the power is off.

8/10/2019 111 Paper

4/12

VDD

Switch

Ret

Clk

PwR

SRPGCell

D

VRETVDD

Q

VSS

Figure 2: State Retention Power Gating

Power Cycle SequenceFor 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 shownin Figure 3

Remove clocks on SRPG flopsOptional CGE

Signal isolation enabled

SRPG in retention state

POWER OFF state

Power switch on

Restore of gate loads

Switch back from state retention

PSR

PSE

Power switch off

Ensure state retention

Isolation of gate loads

ISE

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 basicoperation consists of the DMA engine waking up when encrypted data is available, and performing a multi-

channel DMA operation over the two MACs shown in Figure 4.

Power Control Module

The Power Control Module (PCM) in Figure 1generates 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 controlsignals are not shown here.

8/10/2019 111 Paper

5/12

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 usingCoverage 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 control-

signal transitions that are needed to exercise the targeted Power Modes. It would also specify the desiredbehaviour 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.

8/10/2019 111 Paper

6/12

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 Modelaround 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 in terest have been extracted from the design and captured in theVerification 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 stepby 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 eCover Groups. The CPF file is parsed

for intended Power Intent and the corresponding ecode is generated automatically an example of which isshown in Figure 6.

8/10/2019 111 Paper

7/12

Figure 6: Power Coverage Models

Coverage Closure of Power Goals.

So what does closure really mean in the context of achieving Power goals? Power Closurewould formally be defined as achieving pre-defined Verification goals using specified metricssuch as Coverage. In our example, the metrics are Functional Coverage from targeted CoverGroups created to measure Power Coverage (section 0) and Assertions. The Coverage goalsin our testcase are specified in the executable Verification Plan (section 0) and the resultscaptured during simulation. As shown in Figure 7, the cumulative coverage results are thenannotated onto the corresponding elements in the Verification Plan to reflect achievedverification 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 inthe 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.

8/10/2019 111 Paper

8/12

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 theverification 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 root-cause 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

8/10/2019 111 Paper

9/12

The problem with the verification of Power intent is that there are no standard flows or tools in place today. Thetraditional 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 easilyanswered.

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 thatcan 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 1lists 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 digitalsimulation, 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

TechniqueSim

SupportComments

Clock-gating YesDoes not require any special sim.Support.

Multi VoltageIslands

No Digital sim not effected byvoltage. No special sim supportrequired

DVFS YesFrequency scaling does notrequire any special support

Power Shut-off Yes

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

8/10/2019 111 Paper

10/12

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.

8/10/2019 111 Paper

11/12

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 flagincorrect PSO behaviour - both during Power-down and Power-up sequence.

// Isolation must occur before Power Shut-OffPwrAsrt_Iso_before_PowerOff:

assert always ({!iso_en; iso_en} |->

(power_shutoff before !iso_en)) @(posedge clk);

// Isolation must hold steady during Power OffPwrAsrt_hold_Iso_during_PowerOff:

assert always ( {!iso_en; iso_en[*] ; power_shutoff} |->(iso_en until !power_shutoff)

) @(posedge clk);// Power Up cyclePwrAsrt_PowerUp_cycle:

assert always ({power_shutoff; !power_shutoff} |->{iso_en[*]}

) @(posedge clk);

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.

Figure 11: Assertion Based Checkers

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 controlsequences in the traditional Dynamic simulation environment, and to achieve a high level of coverage would

take even more cycles.

Conclusion

8/10/2019 111 Paper

12/12