low_power_ver_wp.pdf

7/28/2019 low_power_ver_wp.pdf

1/14

Introduction

The mandate to reduce system power consumption and design energy-ecient

ICs has led to the increasing use o low-power IC design techniques. In addition

to well-established techniques like clock gating, IC designers today are using

advanced techniques such as power shuto, back body biasing, and dynamic

voltage and requency scaling (DVFS). More and more chips have multiple

operating modes as well as multiple power domains with dierent, and perhaps

dynamically variable, voltage levels.

The central problem with low-power verication is the explosion in scope and

complexity caused by low-power design techniques. Some chips today have

20 to 50 power domains and hundreds o power modes. As a result, chips may

have thousands or tens o thousands o possible power states. Verication

engineers must ensure that the chip unctions correctly in each state that could

plausibly occur, and that all transitions between states are properly handled.

Because o this complexity, verication planning is essential or low-power

designs. An ad-hoc approach is not likely to succeed. The verication eort

should start with a measurable, executable plan that sets orth goals and prior-

ities. This plan should guide verication eorts all the way to verication closure,

which occurs when goals are met. Along the way, low-power design eects

must be continuously analyzed and veried rom the systems level to GDSII.

With low-power design, verication engineers ace new challenges such asthe ollowing:

Ensuring that the system-level architecture is using the power modes

eciently and correctly.

Veriying the interactions between dierent power domains.

Veriying the transitions between dierent power modes and states.

Modeling low-power structures that do not exist in RTL.

Power-Aware Verication Spans IC Design Cycle

A Plan-To-Closure Approach Helps Ensure Silicon SuccessBy John Decker, Neyaz Khan, and Richard Goering, Cadence Design Systems

The central problem with low-power verication is the complexity caused by using todays

advanced low-power design techniques. A plan-to-closure approach can ease power-aware

IC verication tasks. This approach starts with a verication plan that is tracked through

coverage metrics. It uses the Common Power Format (CPF) to capture and maintain power

intent throughout the verication fow. Cadence solutions address these and more tough

simulation challenges.

Contents

Introduction .................................1

Requirements or Low-Power

Verication ..................................2

Power-Aware

Verication Planning ....................3

Low-Power Verication

Throughout The Flow ...................6

Tough Challenge #1

Veriying Power Shuto ............. 11

Tough Challenge #2

Veriying DVFS ...........................13

IP Design and

Reuse or Low Power ................. 13

Conclusion .................................14


2/14

Ensuring that isolation, state retention, and power shuto are handled properly, and that the device can power

on correctly within a given time period.

Dierent power optimization techniques have diering impacts on verication. For example, clock gating has a

minor impact, multiple power domains and multi-Vt libraries have a moderate impact, and power shuto, DVFS,

and multiple operating modes have a major impact (see Figure 1).

PCM 0.7V

1.1V

0.7VPCM

CLK

CPU

0.7V or

1.1V0.7V

PCM 1.1V or

shutoff

SW

ImpactonVerification

Clock Gating Synthesis opto

Multiple Power domains Multi-Supply voltage Multi-VT library Advanced opto

Power shutoff Dynamic voltage & freq. HW & SW control Multiple operating modes Complex domain interactions

Figure 1: Some advanced low-power design techniques have a proound impact on verication.

This paper shows how a plan to closure approach can ease power-aware IC verication tasks. Such an approach

starts with a verication plan that is tracked through coverage metrics. It makes use o the Common Power

Format (CPF) to capture power intent throughout the verication fow. The paper discusses the use o behavioral

simulation, RTL simulation, assertions, emulation, and ormal verication or low-power verication. It looks at

tough simulation challenges posed by techniques such as power shuto and DVFS, and proposes some solutions.

Requirements or Low-Power Veriication

A successul low-power verication methodology requires these prerequisites:

An executable, metric-driven verifcation plan. Verication planning brings all stakeholders together to

capture the verication intent, and to identiy criteria or verication closure. Because low-power design

introduces a great deal o complexity into the verication environment, a measurable low-power verication

strategy must be developed up ront.

A common view o the power architecture. There are a large number o tools in the low-power verication

fow, and all must share a coherent view o the power architecture. In the Cadence Design Systems fow, the

Common Power Format (CPF) provides that view.

Tools with a native understanding o power intent. Simulators and other tools in the low-power veri-

cation fow need to understand low-power states and requirements. I a test unexpectedly orces a power event,

or instance, the tool must be able to recognize that. This is only practical i a tool provides high perormance or

low-power verication.

Reuse o existing IP and methodologies. A low-power verication approach must support a high degree

o reuse, even i existing design and verication IP was not developed specically or low power. The side le

approach used by CPF, which does not require modications to RTL code, is one step in this direction.

Automated, early ormal checking. Static checking can expose problems and veriy changes in the power

architecture with minimal impact to the rest o the verication environment.

www.cadence.com 2

Power-Aware Verifcation Spans IC Design Cycle A Plan-To-Closure Approach Helps Ensure Silicon Success


3/14

Power-Aware Veriication Planning

Defning an architecture

The low-power verication fow begins when a power architecture is dened or the design. This architecture

partitions the design into major blocks and determines which power-saving techniques can be used by each block.

As decisions are made about the power architecture, they need to be captured in a ormat that can be used by all

tools. The Cadence fow uses CPF or this purpose.

An architect will create a system-level CPF le to dene the top-level power domains and system-level power

modes in the design. This le will typically include inormation that identies the ollowing:

Major power domains

Use o power shuto, retention, isolation, level shiting, DVFS, multiple supply voltages, and other techniques

Major modes o operation

Power-up restoration policies

Interace requirements between domains

The ollowing code example shows how CPF describes power domains:

# Dene the top domainset_design TOP

# Dene the default always on domaincreate_power_domain name pdTop default#

Dene Power Shutoff domainscreate_power_domain name pdA

-instances {uA uC}

-shutoff_condition {!uPCM/pso[0]}

create_power_domain name pdB

-instances {uA uC}

-shutoff_condition {!uPCM/pso[1]}

#Dene Power ModesCreate_power_mode name M_ON

-nominal_conditions {[email protected] [email protected]}

Create_power_mode name M_OFF-nominal_conditions {pdA@off pdB@off}

Create_power_mode name M_MID-nominal_conditions {[email protected] pdB@off

Figure 2 CPF code used to dene a power domain

Typically, the system-level CPF le will reerence several lower-level CPF les. These may include a technology le

that denes the libraries and technology mapping rules, and a domain-level le that denes the basic control

signal inputs and interace requirements or that domain. Since CPF is contained in a side le, no RTL changes arerequired to capture power intent. While the power intent is specied in the CPF le, the RTL or sotware running

on the device under verication still needs to be updated to include the logic that controls the power management

o the system.

An executable plan

As the power architecture is dened, a corresponding verication plan must be developed. This plan allows all

stakeholders to agree on what needs to be veried and how it will be veried. The plan denes verication closure

and describes how to measure it. With the Cadence Incisive Enterprise Manager and the Cadence Incisive

Plan-to-Closure Methodology (IPCM), the planning process results in a machine-executable verication plan that

can track the progress o the verication eort using metrics such as unctional coverage.

www.cadence.com 3



4/14

Verication planning is always important, but it is especially important or low-power design because the power

architecture adds so much complexity to the verication. The verication space increases with each power mode,

and the device must be validated in all modes.

Ideally each verication mode is ully validated, but oten the verication space is too large or exhaustive veri-

cation. The verication planning process provides a documented analysis o the important modes and required

verication. Verication engineers must understand which eatures are valid in each mode. Power modes must be

entered and exited without errors, and transitions between power domains must be handled properly.

To ulll these requirements, the verication plan should include a section on the verication o power intent. This

section should describe the power modes and the requirements or exercising them. It should dene the set o

eatures that need to be veried in each o the designs power modes. It should also dene the eatures that are

not available in given power modes. Figure 3 shows some o the power-related criteria that should be covered in a

verication plan.

0.8VLib

CPU

PowerManagement

VS

SW RTLChipCPF

ChipSDC

0.8v/1.0v

1.2v Shutoff

PCM

BD

SRSR

Mode

PM1

PM2

PM3

PM4

AC

0.8

0.8

1.0

1.0

B

1.2

Off

1.2

standby

Multiple Modes

Power managementfrom CPU/SW/HW

Interaction with

Analog components

Power control module

for detailed domain-level control

Interaction between

domains

Dynamic VoltageDomain

Standby Modeand Transitions

Power off andpower onsequences

1.2VLib

1.0VLib

LS Iso

Iso

LS

A C

Figure 3 A verication plan needs to include inormation about a variety o low-power design eatures.

In summary, the key items dened in the verication plan are:

Description o power behavior

Coverage items to ensure power behavior was tested

Assertions and/or test scenarios to ensure the design operates properly

Coverage metrics

Functional coverage can be used to gauge and measure the quality and completeness o power simulations. This

is done by creating a coverage model based on the power control elements o the design, and then managing the

verication eort to optimize the collection o coverage data.

Power closure occurs when pre-dened verication goals are met, using specied metrics such as unctional

coverage. Two steps are involved in achieving power intent closure:

www.cadence.com 4



5/14

Designing a coverage model that quanties the unctionality that needs to be tested. Incisive Enterprise Manager

provides automatic coverage generation that ensures that all dened power modes are exercised, and all dened

power control signals are toggled. It creates the cover groups needed to collect and capture metrics or low-power

simulations are automatically created. To accomplish this, the CPF le is parsed or intended power intent and

the corresponding e or SystemVerilog code is generated automatically. The automated coverage is one piece o

the overall low power coverage model. The planning process will also dene additional coverage metrics to ully

cover the low power architecture and verication plan.

Speciying coverage goals in the executable verication plan, and capturing results during simulation. This makes

it possible to use coverage metrics rom targeted cover groups to measure power coverage and assertions.

Automatic coverage generation will also be provided or SystemVerilog by the Cadence Incisive Unied Simulator.

System-level power verifcation planning

System-level verication spans multiple domains. At this level, the two main planning goals are to veriy that the

design works as expected in all power modes, and to provide the verication strategy or the power management

logic and sotware. Planning should include the ollowing:

Dening which system tasks should occur and should not occur -- in each power mode o the design, and

developing appropriate tests

Dening the interactions and isolation requirements between power domains

Ensuring proper behavior during a power mode transition

Veriying interactions between power modes and power domains

Veriying that power mode transitions operate correctly

Validating that the system has been ully tested in each power mode

At the system level, it is important to veriy power management decisions. During the planning stage, engineers

should dene what modes o operation and transitions between nodes are valid, and describe the scenarios that

will cause the transitions. They should veriy all methods that will cause a node change such as writing a register,

responding to external stimuli, or side eects o other transitions.

Next, it is important to dene coverage items to ensure that the expected scenarios appear. This typically involves

a mix o power modes and other variables or instance, in power mode X, did I get transaction Y? Finally,

assertions can be used to veriy the sequences o power management tasks, and to ensure that power events onlyhappen at legitimate times.

To ensure that power modes are veried, the plan should dene the set o scenarios, tests, transactions, and

eatures that must be covered in each unique power mode. It should identiy sequences o power mode transitions,

speciy the required time periods or each mode, and note whether specic transactions, such as memory writes,

can cross power modes. The planning phase should also identiy expected or undesired domain interactions. For

example, one domain might need to transition beore another domain, or system-level transactions might still

need to work ater a domain is turned o.

www.cadence.com 5



6/14

1. System Level Power Requirements

1.1 Power Mode A

Power mode A is defined by MAC1 being off and MAC2

being at low voltage.

1.1.1 Transition requirements

This power mode can only be entered if the MAC1 link

is disconnected, and there are no messages in the

queue assertions : xxx and yyy are required

1.1.2 Functional requirements

The following features must be tested during this

power mode

1.1.2.1 Send a transaction on MAC2

Coverage: mac_2_send cross powermode A

1.1.2.2 Attempt to read from MAC1 buffer

1.1.3 Testing Requirements

The following system tests should be run in this mode.

1.2 Power Mode B

Figure 4: A system-level verication plan

Domain-level power verifcation planning

A power domain is a collection o cells that each have the same low-power behavior and control. Domain-level

verication ensures that each power domain executes all its possible states and transactions, and that control logic

operates correctly. Veriying at the power domain level is similar to veriying a block level design; it veries the

basic unction o each domain independently o its system-level context. Power domain-level verication planning

includes the ollowing:

Translating power control module requirements and sequence requirements into coverage and assertions.

Coverage metrics include each domain state and transaction. Assertions ensure proper state transitions and

check individual control signals.

Setting internal state requirements or power transitions.

Dening state retention/isolation requirements.

Speciying isolation requirements.

Low-Power Veriication Throughout The Flow

Following the development o a verication plan, design and verication teams turn to a variety o tools and

methodologies to reach verication closure. These may include ormal property checking, equivalence checking,

simulation at various levels o abstraction, emulation, assertions, and coverage metrics. An integrated fow that has

a common understanding o power intent is important. This section shows how such tools and techniques canbe used to veriy power-aware IC designs.

Static (ormal) checking

CPF quality checking is typically one o the rst steps thats taken ater a verication plan is developed. This is

because the architectural specication itsel must be analyzed and veried or unctional, electrical, and structural

completeness and correctness.

Cadence Encounter Conormal Low Power provides automated checks that can ensure that the specied power

intent is complete and correct. It also provides a linting capability that checks or proper syntax.

www.cadence.com 6



7/14

Encounter Conormal Low Power is used throughout the verication fow. Early checks might include tests or

missing isolation or level shiter cells, tests or power control unctionality, and checks that state retention and

isolation control signals are driven correctly by domains that remain powered up. Later on, post-placement checks

can ensure that gate power pins are hooked to the appropriate power rails, that always-on cells are appropriately

powered, and that there are no sneak paths rom power-down domains back to logic.

Encounter Conormal Low Power also provides logical equivalence checking (LEC), and that too can be used

throughout the RTL-to-GDSII verication fow. Equivalence checking can prove that isolation and state retentioncells have been inserted correctly, even though these cells are in the CPF le rather than the RTL source. Figure 5

shows how static checking and LEC are used during the low-power verication fow.

EncounterConformal

(Static checking)

EncounterConformal

(Equivalence checking)

CPF Qualityand Functional

Checking

RTL-to-GateFunctional

Comparison

Gate-to-GateFunctional

Comparison

Structural andRules Checking

Structural andRules Checking

RTL & CPF

Synthesis

Gate Netlist

Place/Route

Gate Netlist

Design

Figure 5 Encounter Conormal Low Power can be used throughout the verication fow.

Low-power simulation

Ater CPF is used to capture power intent, design teams can simulate behavior such as power shuto, isolation, and

retention, and observe the eects. Because this inormation is specied in the CPF le, not the RTL, no RTL changes

are required. Given the inormation in the CPF le and the appropriate test vectors, a CPF-aware simulator such as

the Incisive Unied Simulator can exercise the power shutdown and star tup sequences or the design.

CPF commands that are understood by Incisive Unied Simulator 6.2 and above include:

Power domain denition dierent power domains and operation supply voltage

Power shuto property specication isolation, retention, and power-down triggers

Level shiters between power domains that run at dierent voltages

Low power simulation should be enabled or all simulation runs. I power-aware simulation is run only in tests

and scenarios that are designed to test power-aware eatures, simulations may not catch errors that unexpectedly

trigger low-power eatures. With Incisive Unied Simulator there is virtually no run-time impact in running with low

power enabled, and no reason not to do so.

www.cadence.com 7



8/14

Figure 6 shows the types o simulation that should be run, what device under verication (DUV) representation

they use, and what else the verication environment might include, such as coverage, the Cadence Incisive

Palladium Accelerator/Emulator, Cadence Incisive Sotware Extensions, and Cadence Incisive Formal Verier.

CoverageDB Assertion

DB

IncisiveFormal Verifier

RTL Sim

RTL CPF

Multiple Modes of DUVVerification Environment

VerificationManagement

Behavioral Simulation

Palladium

TLM

C-Models

RTL Sim

System Simulation

RTL Sim

Block Simulation

Palladium

CPU-Models

Incisive Plan-to-ClosureMethodology

VIP

Assertion

Coverage

Incisive Software

Extensions

HW/SW

Figure 6 Types o simulation used in low-power verication

The role o behavioral simulation is to veriy the system and sotware architecture o the design. In the low power

environment, there are two key tasks:

Functionally veriy the power architecture rom a systems perspective

Ensure that the power architecture is used eciently by the system sotware and hardware

For the rst task, the most common sources o unctional error are the interaces between power domains and

the transitions between power modes, especially when power shuto is used. Ensuring that all power modes and

transitions have been exercised is the only way to veriy that these interaces are dened correctly. For the second

task, the verication environment needs to ensure that all the available power modes are used, and that the low

power modes are used as oten as expected.

Veriying these issues requires extensive simulations with high-level models. This includes transac-tion level models(TLMs), C language models, and possibly emulation technology. A airly simple model o the power architecture is

probably sucient. RTL simulation will require a much more detailed model.

System-level simulation provides a detailed unctional verication o the DUV. Unlike behavioral simulation, it

requires accurate models o every component. The simulation can include the entire SoC, or it could ocus on

major sub-units, such as those containing power domains or power management logic. Simulation engines

model the power structures dened in the CPF le. These engines typically include RTL simulation and/or

hardware emulation systems.

www.cadence.com 8



9/14

Block-level simulation looks at the individual blocks that make up a power domain and its corresponding control

logic. In addition to RTL simulation, verication at this level may involve ormal property checking. One goal o

this level o simulation is to veriy that an individual domains low power eatures are veried in isolation.

Since equivalence checking can ensure that a gate-level netlist matches the original specication, gate-level

simulation is typically used or only or small, targeted tests. Still, many design teams run some gate-level

simulation or low-power designs. By simulating the logical netlist that appears ater synthesis, engineers can

veriy low-power structures such as isolation, state retention and level shiting.

The physical netlist resulting ater placement adds power and ground nets, pins, and switches. Physical netlist

simulation typically veries physical connections or checks or dynamic hazards in the design. Tools such as

Encounter Conormal Low Power and Cadence VoltageStorm Power Verication can generally handle these

concerns better.

Embedded sotware verifcation

Embedded sotware plays a crucial role in low-power design, and should be included in the verication process. In

most ICs, power modes are primarily dened and controlled by sotware. Moreover, sotware development is based

on architectural choices that impact power, such as the size o caches, the use o internal or external memory, and

the amount o I/O trac.

Incisive Sotware Extensions gives the verication testbench access to sotware executing on processor models. It

lets the verication team use the Incisive debugger to control and veriy system-level behavior including sotwareprocesses, unction calls, and variables, along with processor and register behavior. Incisive Sotware Extensions

brings constrained-random stimulus generation and unctional coverage metrics into the sotware development

world. It also permits execution o a single verication plan including both hardware and sotware.

Emulation

The enlarged verication space caused by low-power design techniques makes hardware emulation an attractive

option or power-aware verication. Emulation greatly speeds verication, allowing engineers to process ar more

clock cycles than would be possible using sotware simulation alone. Further, emulation provides a virtual model o

the design that can give sotware engineers a head star t in developing rmware and applications sotware, which,

as noted above, aects the power consumption o the SoC. The speed o emulation lets engineers run real-world

sotware applications as part o the verication process. This is critical or low power design, since the time span

or low power events is typically very large and oten requires simulating real world applications.

Cadence Incisive Palladium Dynamic Power Analysis lets users capture and analyze power switching activities orpeak and average SoC power consumption, including the eects o embedded sotware and other real-world stimuli.

This can help determine, or example, whether and how oten a given block is powered down. The emulator can

also pinpoint hot spots that show areas o high power consumption, and return the associated activity to the

sotware simulator or a more accurate analysis.

Formal property checking

A ormal property checking tool such as Incisive Formal Verier can exhaustively prove that assertions are correct,

without requiring the user to generate testbenches. For low power design, ormal property checking can:

Veriy user-generated assertions or power management

Veriy the assertions generated on the power control module associated with each power domain

Veriy that design assertions with low-power intent are correctly modeled

In the case o power shuto, Incisive Formal Verier can be run in two dierent modes. First, it is run to ensure that

all the assertions in the RTL are valid in both the powered on and powered o states in the design. Secondly, it is

used to ormally veriy the generated assertions on the power control module.

Assertion-based verifcation

Many design and verication teams use assertions to drive ormal tools, or to monitor specic test cases and ensure

specic properties during simulation. Assertions also provide coverage data that supplements the data obtained

rom cover groups.

www.cadence.com 9



10/14

Assertions are a powerul tool or low-power verication. They can be used to validate power control logic,

system-level power management, and specic requirements met beore and ater power mode transitions. But

assertions must be used properly, especially when power shutdown techniques are used. Further, engineers must

make sure that traditional (non power-related) assertions, such as those or bus protocols, hold in all power

modes and during all power mode transitions.

A number o assertions can be automatically generated rom CPF specications. Such assertions monitor and

check transitions in the power control signals to veriy legal and correct low-power behavior. These assertionsremain active, yet dormant, or powered-down modules. They can also provide coverage metrics.

Power-aware assertions go beyond the items that can be inerred by the CPF le, and may include the ollowing:

The nite state machine (FSM) or a design must be idle beore this design/block can be powered down.

During power mode A, conguration register X should be a specic value.

Bus Y should be idle or N cycles beore power-down.

The Property Specication Language (PSL) assertion segment in Figure 7 shows a power cycle with errors. The

assertions fag incorrect power shuto ( PSO) behavior during both power-down and power-up sequences.

Figure 7 PSL-based assertions or low-power control checks

As noted in the next section, it is important to understand the potential impact o PSO on pre-existing assertions,

because assertions may re inappropriately during power shuto.

Mixed-signal simulation

Most low-power ASICs and SoCs contain some analog or mixed-signal circuitry, and this needs to be included in

simulation. When a digital component powers o or changes voltage, it may impact analog components. Digital

and analog simulation need to be aware o this change and be able to track its eects.

//Isolation must occur before Power-OffPwrAsrt_ISO_before_PSO:assertalways ({!iso;iso}|-> (!pso before !iso));

//Isolation must hold steady during Power-OffPwrAsrt_hold_ISO_in_PSO: assertalways ({!iso;iso[*]; !pso} |-> (iso untilpso));

//Full power cyclePwrAsrt_Full_PwrCycle: assertalways ({!iso; iso[*2:5]; !pso[*];pso} |-> (iso[*]; !iso});

Mixed-signal simulations can take advantage o eatures in the Incisive Unied Simulator that allow low-power

eects to be propagated to analog blocks that interace directly or indirectly with powered-down digital logic. The

simulator identies the CPF infuence on the analog blocks, and inserts Power-Smart Connect Modules ( PSCM) that

help propagate the eect o power shuto onto the analog blocks. PSCMs can also back-trace the digital drivers to

get power domain and state inormation, and can perorm digital-to-analog value conversion based on the inor-

mation obtained.

Analog components used or power management in an SoC can be eciently modeled using a technique called

Real Valued Modeling (RVM). This technique bridges the gap between the perormance requirements or a ull-chip

simulation and the accuracy limitations o a mixed signal design. A signicant speedup in simulation perormancecan be achieved by replacing the analog portions o the SoC with unctionally equivalent real number models that

do not require the analog simulation engine. While the RVM models trade o accuracy or speed, they are not

aected by t ypical analog simulation problems like convergence.

www.cadence.com 10



11/14

Accurac

y

Performance

1 20x 100x 500x 10K x

Spice

TurboSpiceFastSpice

Verilog-AMSVHDL-AMS

Real/Wreal

Pure Digital

Figure 8 Speed versus accuracy tradeo or mixed-signal simulation.

In applications where power-shuto (PSO) is not applicable, power management is oten achieved through DVFS,

which dynamically scales the operating requency and voltage o the target design. The verication o DVFS is

oten a very dicult and delicate task that involves tremendous interaction between the digital and the analog

domains.

Beyond CPF, DVFS verication requires Wreal models or voltage sources and regulators like low-dropout regulators

(LDOs), as well as clock generators such as voltage-controlled oscillators (VCOs) and phase-lock loops (PLLs). The

various nominal voltages or each power domain need to be generated accurately and to be constantly monitored

throughout the simulation. Additional checks need to be perormed to keep track o complex interactions between

the digital and analog domains throughout the voltage scaling process. Any errors in voltage levels and sequences

o transitions need to be detected, and the corresponding voltage domains corrupted.

Tough Challenge #1 Veriying Power Shuto

Understanding how to deal with power shuto (PSO) is one o the most critical aspects o power-aware veri-

cation. PSO has a signicant impact on simulation, assertions, coverage, verication IP, and modeling. The rst

point to understand is what not to do. I PSO is dened in the CPF le, the user-dened verication environment

should not attempt to model power shuto corruption, state retention, or isolation inside the DUV. Doing so

actually increases the chances o ailure. The only exception to this statement is that some behavioral models,

like RAM models, may require a signal that denes when power is shut o to the module containing the RAM.

Simulation

Constructs such as power shuto corruption, power switches, save /restore logic, and isolation should be described

in the CPF le, not the RTL. The simulator needs to model the behaviors described in the CPF le during power-

down and power-up sequences.

During power-down, the simulator needs to consider isolation and state retention. During power-o, the

simulator models the corruption o data internal to the power domain by setting all the internal values to Xs.

During power-up, the simulator models the restoration o power to the domain. Incisive Unied Simulator 8.2

lets users speciy the time it should take or power-up to occur.

Assertions

In many cases, assertions will not be valid during a power-down phase. Any unclocked assertion that requires

specic signal values will probably ail during power shuto, because the signals will have gone to X states. To

avoid this problem, assertions can be made power-aware, but this makes them dependent on the power archi-

tecture and harder to reuse.

www.cadence.com 11



12/14

One way to assure that assertions will work during power shuto is to use the CPF command create_assertion_

control. This command lets users disable an assertion, or set o assertions, during the power shutdown sequence.

The user has detailed control over when the assertion is valid, and can speciy whether an assertion should be

reset or suspended during power shuto.

Gated clocks can eliminate the unwanted triggering o clocked assertions. I the clock is gated during power

shuto, any clocked assertion will be suspended.

Incisive Unied Simulator can automatically generate assertions to check PSO and isolation. Examples o assertions

or shuto and isolation are shown in the diagram below.

Only one set ofshutoff edges

Isolateeventually falls

Isolate stableduring shutoff

Shutoff Edgeafter Isolate

Shutoff disabledduring riseof Isolate

Shutoff Edge fallsbefore Isolate falls

Isolate

Shutoff

Figure 9 Sample assertions or shuto and isolation

Coverage

Coverage o power control and management is very important to the verication o low power design. The

coverage items that are internal to a power shuto domain are most oten not very interesting during power

shuto. In many cases these are automatically ignored during power shuto -- signals transition to X, and

clock gating during shuto prevents most coverage events rom triggering. In other cases, such as those

involving immediate assertions, the user may need to disable assertions manually using the CPF create_

assertion_control command.

PSO may require changes to the coverage model in two ways:

Coverage on a power domain input rom outside the power domain. Because inputs will be corrupted inside the

domain, verication IP that monitors the inputs o a power domain will see the signals toggling. Designers need

to decide whether this coverage is desired.

Internal coverage points during a multi-cycle state retention. State retention may take multiple clock cycles,

creating coverage events as data is scanned through the system. Designers need to decide whether these events

should be covered.

Scoreboards

A scoreboard monitors the inputs and/or outputs o a module, and checks the trac that passes through. When

power is shut o, the verication team needs to decide the appropriate action or the scoreboard. In many cases

no action is required -- checkers on the interace o a domain oten will continue to work throughout the power

shuto cycle. In other cases, sequences may need to be reset, or shadow registers in the verication code will

need to be synchronized with the DUV.

Verifcation IP

Some verication IP (VIP) blocks have internal state elements. It is possible or an internal state to get out o sync

with the DUV. For example, a VIP may have an internal state tracking the progress o a transaction in a shut-o

module. When powering up, the module resets itsel. I the VIP does not monitor that reset signal, its internal state

will be dierent rom the DUV. To minimize this possibility, designers should ensure that all resets and clocks in the

verication code are identical to those used in the DUV.

www.cadence.com 12



13/14

Tough Challenge #2 Veriying DVFS

Static multiple supply voltage (MSV) designs have very little impact on the simulation environment. They can be

completely veried with static checks provided by Encounter Conormal Low Power. The checking needs to ensure

that the voltage dierence between two domains is within a given threshold, and i not, that level shiters are

provided. This threshold is technology dependent but is generally less than 100 millivolts.

I the static checks are clean, the dierent voltage levels will not change the logic values seen in simulation, and

these voltage levels place no requirements on the simulation engine.

Dynamic voltage, however, does impact the simulation. First, simulation needs to veriy power domains at all legal

combinations o voltages. Secondly, the interaces between power domains need to be checked to veriy that a

correct voltage is provided across the interaces. I any problems arise, either isolation or level shiting should be

used to protect the interaces.

Determining when and where to place level shiters can be a dicult process. Using the power modes dened in

the CPF le, Encounter Conormal Low Power can determine i the respective power modes require level shiting

or not. During simulation, transition times o the power domains will help determine whether level shiters are

necessary. During RTL simulation, the transition time is merely an estimate; physical design is needed to get a more

accurate answer. Checking the transitions in RTL simulation can be viewed as an early check, but in the end this

must be veried at the physical design level with a tool such as VoltageStorm Power Verication.

Standby mode

Standby mode is a special case o DVFS. This mode reduces voltages to a level thats still high enough to retain the

states o all state elements in a domain, but too low to calculate any new values. Full power shuto, in contrast,

turns o all dynamic power and all leakage power except or state retention cells. Standby mode provides a good

savings in leakage power without the need or state retention. This simplies the complex problem o determining

the exact state retention registers that are required to restore state. Since the ull state is retained, the power-up

sequence is typically much aster than a PSO cycle, especially i the PSO does a ull reset on power up.

From a verication point o view, when an input changes in standby mode, everything downstream rom that input

is corrupted. Incisive Unied Simulator 8.2 detects standby voltages, automatically checks or unintended input

toggles, and automatically propagates X states as required.

IP Design and Reuse or Low Power

The best way to design an IP block that will be used in a low-power environment is to provide a CPF le thatdenes power behavior or the block. The block should also come with a detailed specication o the require-

ments needed to use these low-power eatures, and include assertions and tests to veriy the implementation.

Blocks are sometimes used in power environments they were not designed or. In such cases, it is up to the IP

integrator to ensure that the block operates properly. Most low-power design techniques wont perturb the block,

but with PSO, the user needs to ensure that the state retention and restoration process will work properly, and

dene the behavior o assertions.

Blocks that will be reused in a low-power environment should come with the ollowing inormation:

State retention and restoration policy

I/O requirements, including input isolation requirements

Assertion behavior when power is shut o

Coverage inormation

Another ideal deliverable is a compliance checklist that includes a verication plan, a set o coverage items and

assertions, and a set o test cases that validate whether the part is being used in an expected manner.

www.cadence.com 13



14/14

Conclusion

Functional verication is a dicult task and low-power design makes it even more dicult. With todays low power

design techniques, ICs may have dozens or hundreds o dierent power modes and domains. The IC must unction

correctly in every possible power state, and transitions between power states must be correct. Power shuto (PSO)

and dynamic voltage and requency scaling (DVFS) are particularly problematic rom a verication standpoint.

A plan-to-closure methodology, complemented by power-aware verication tools and a common way o expressing

power intent, can go a long ways towards easing the low-power verication challenge. Such a methodology begins

with a verication plan based on the low-power architecture. The plan denes verication closure and describes

how to measure it through coverage metrics.

The verication plan should describe all o the power modes and domains, and explain the eatures available in each

power mode. Addressing both system-level and domain-level verication, it provides scenarios, tests, transactions

and eatures or each power mode. A Common Power Format (CPF) le, which is separate rom the RTL code, then

conveys power intent to all o the downstream tools in the verication fow.

Every tool in the verication toolbox can contribute to low-power verication. Static, ormal checking can make sure

the power intent is complete and correct. Simulators can read the CPF le and veriy the power intent. Emulation,

ormal property checking, and assertion-based verication can all play an important role. But all these tools must

be used with an awareness o low-power eatures such as PSO and DVFS.

Anyone contemplating low-power design must also consider the challenge o low-power verication. Fortunately,help is available in the orm o verication planning, a common power ormat, and power-aware verication tools.

A plan-to-closure methodology and an integrated suite o tools can make low-power verication a manageable

challenge..

Cadence is transorming the global electronics industry through a vision called EDA360.

With an application-driven approach to design, our sotware, hardware, IP, and services help

customers realize silicon, SoCs, and complete systems efciently and proftably. www.cadence.com


2011 Cadence Design Systems, Inc. All rights reserved. Cadence and the C adence logo are registered trademarks o Cadence Design Systems, Inc.,

All rights reserved. Cadence and the Cadence logo are registered trademarks o Cadence Design Systems, Inc., All rights reserved. Cadence and the

Cadence logo are registered trademarks o Cadence Design Systems, Inc. 22319 12/11 RG/MK/ DM

low_power_ver_wp.pdf

Documents