Finding the Flow

8/10/2019 Finding the Flow

1/49

1


2/49

Finding the Flow

Planning and Executing

Verification Environments using

James Keithan

Convergence Verification

2009, Convergence Verification. All rights reserved.


3/49

Agenda

Introduction

DV Factors DV Tools

Flowchart Planning

Task Assignment xecu on

Checkpoints

Summary



4/49

Introduction

Landscape

A lot of material written about this subject Most of which I agree with

Bio

First simulator language CAPS X

First HLV language Specman as first U.S. InSpec AE

Currently Sr. contributor in AVM, VMM, and OVM projects

usin Questa, VCS, and IncisiveIncisive

Goal

ProvideActionable steps for planning and execution



5/49

DV Factors

To be in, lets look at the roblem

What about the design is important? Collect the specs, and read them

oo or unc ons, usses, an reg s ers

Talk to all stakeholders

Take notes

My pressure points follow



6/49

DV Factors

What are the ma or factors?

Design size Design type

Model maturity

State space Resources

Other factors, important, but secondary from above

Prediction

Reuse



7/49

DV Factors

What are the factors to consider?

Design size Simple isnt it? How big is the design?

ASICs and FPGAs both can exceed

practical simulations size constraints

Here we look for aspects in the design

Repetition

# and size of FIFOS Memory



8/49

DV Factors


Design type Always the classic

a a over or a a runc er

Telecom etal. Mover

NOT TRUE Anymore

Most modern designs have aspects of both

This implies Multiple Layers of Checking



9/49

DV Factors


Design type Therefore we consider - Number and Percentage

Number - How many different types of blocks

Note all IP, new, reused, and purchased

the classic split?

More Mover, generally easier

More Cruncher, harder prediction



10/49

DV Factors


Interface Maturity Here the DV rubber meets the road

cqu r ng ransac or mo e s o en e ar es par

Do you have common interfaces?

PCIe DDR etc.

Or are you dealing with the next big thing? PLB6, New DRAM, etc.

These can increases factors of complexity,up to 10X

.



11/49

DV Factors


Model Maturity Similar to Transactors with these differences:

They involve Prediction (vs. protocol)

Correctness model sources vary widely , ,

In the end you may have to write it yourself

Another whole project!



12/49

DV Factors

What are the factors to consider? State Space Size

No This is where the DV rubber meets . .

- verification practice manager

This issues invades all areas of TB planning What stimulus do we need? Generate state space

Have we checked everything? Check state space

Are we done? Cover state space

Reg model becomes most important deliverable Every block should share one model



13/49

DV Factors


Resources Human and Infrastructure

What is the comfort level of my people?

Do I have enough _______________ ? ,

Training

Technology

Consultants

Todays Verification challenges requires that



14/49

DV Tools

We dont need more tools we need better automation

Gary Smith, DVCon 2008 Yes and No

u oma on s a rea y poss e you o yourse

I would add,

we need to know What tool to use How and When

Step back:

look at what kind of automation we want

Look at what tools we have Make practical decisions



15/49

DV Tools

What do we do the most of?

Run simulations Debug simulations

Where can automation best help?

Running and Interpreting simulations

Given that, lets look at what is out there

vManagervManager

Runs tests, displays results

Highly customizable



16/49

DV Tools

Simulators & Lan ua es

Certain assumptions for this paper; Use an Object Oriented Language -

os e y ys em er og

Testing through Random Generation of TLMs

Assertion coverage also key

Formal Verification

Use early, best on data Mover designs

Here, in my experience, the tools are ready,



17/49

DV Tools

Simulators & Lan ua es

I use Incisive Enterprise Manager With OVM base library,

vPlan regression runner

OVM base class

SVA SystemVerilog Assertions

OOP



18/49

Phases

Althou h not terribl ri id, each with si nificant overla ,

here is a list of recommended development phases: Plan & document

Basic monitors

Basic checks Advanced stimulus

Advanced monitors

Advanced checks

Regressions to closure

We will concentrate on



19/49

Flowchart Planning

Flowchart Planning is:Defining testbench components, environments,

init ialization, and tests, through structured analysis ofthe designs block diagram

It does not directly produce thorough requirements Although it contributes to this effort

And Temporal Assertions

Flowchart Planning produces the Environment

- Planning provides a flow that quantifies effort

Starts with a High Level block diagram of the design



20/49

Flowchart Planning

Ste s in the rocess, with an exam le to follow;

1. Make a block diagram of the design Keep it high level, include all external and major internal blocks

2. Flowchart Data flow in one copy

In, through and out of design

.

What directs data flow?

4. Flowchart Initialization sequence in yet another copy

Setup comes from where? Goes to where? How?

5. Identify locations for assertions

, ,



21/49

Flowchart Planning

Ste s continued;

6. Cull data types from Data flow chart Group as much together as possible

7. Cull Device models from Control flow chart

This reveals the Interfaces [Transactors] needed

Also look for Data/Control overla

8. Cull State models from Initialization flow chart

Normally a full Register Model is needed

Helps define initialization sequences9. List all assertions, by functional block

-



22/49

Flowchart Planning

Step 1: DCR Bus Interconnect example

block diagram

lBus

(OPB)

On-ChipPeripher



23/49

Flowchart Planning

Ste s in the rocess

2. Flowchart Data flow in one copy Avoid too much detail

a or oc s on y

We want a sense where the data comes and goes

That is enough for now



24/49

Flowchart Planning

Step 2: Data Flow

lBus(OPB)

On-ChipPeripher



25/49

Flowchart Planning

Ste s in the rocess

3. Flowchart Control flow in another copy Control is that which starts, stops, or throttles Data

o n a za on a s o come

External factors that effect the design



26/49

Flowchart Planning

Step 3: Control Flow

lBus(OPB)

On-ChipPeripher



27/49

Flowchart Planning

Ste s in the rocess, with an exam le to follow;

4. Flowchart Initialization sequence in yet another copy How is the DUT setup to run?

ys ca rese an o ware eg s er oa s

In this case more detail Is better

Start looking for overlaps, data & control Keep separate for now



28/49

Flowchart Planning

Step 4: Initialization Flow

lBus(OPB)

On-ChipPeripher



29/49

Flowchart Planning

Ste s in the rocess

5. Identify locations for assertions These are temporal check over time

us pro oco s

Internal State Machines

Latency parameters



30/49

Flowchart Planning

Step 5: Assertion Density

lBu

s(OPB)

On-ChipPeripher



31/49

Flowchart Planning

Step 6: Cull Data types,eripheralBus(OPB)

From data flow,

to Define TransactionsPLB Transactions

On-Chip

Memory

Peripheral

Look to form larger groups Here we can group PLB & OPB

Instructions to Processor

OPB Transactions

different types

DCR Separate, quit different

Note: Re isters hold State

Bridge Data

DCR Transactions

Re ister Setu Data

Data/Control overlap

Peripheral data is ignored

Consider this environment partitioning



32/49

Flowchart Planning

Step 7: Device ModelseripheralBus(OPB)

From Control Flow

ROM Model

On-Chip

PLB Transactors

OPB Transactors Check for other models;

needed but not directly in

Register Setup Data

PLB Arbiter prediction

Memory models

Peripherals are ignored to simplify

r ter pre ct on u o en severa o ese



33/49

Flowchart Planning

Step 8: State ModelseripheralBus(OPB)

From Initialization Flow

Block Re ister Mirror

On-Chip

A class of regs for each block

Same Base Register Class

Here we are looking for two, often

overlapping state types

Cache State

Memory State

n a za on we ave o se up

before a test can run

Results device state updates

Form one or two state containers

depending on degree of overlap



34/49

Task Assigning

From the revious exercise we list the tasks

Pull from each step the items that need building

Data flow gives Stimulus

ransac ons

Control flow gives models to exercise the design

Transactors Initialization flow gives State Model

Register Abstraction Layer

Assertion flow gives, . . . assertions!



35/49

Task Assigning

From the revious exercise we Do Not et:

Requirements: Too high level

This Must be done & turned into Coverage

es s s: xcep n a za on

These still need to be done, in parallel with

testbench creation



36/49

Task Assigning

Task and Effort estimates

Some general rules of thumb

Stimulus Classes man month each

Transactors 1 man month each internal

Transactors man month each vendor

Assertions ongoing but man month per

functional block

Functional coverage 1-2 man months perfunctional block



37/49

Task Assigning

Tasks and Effort estimates

Pulling from flow chart

Transaction Level Models (TLMs)

rocessor a a

DCR Data

Transactors / Monitors ROM

PLB

DCR

Memory



38/49

Task Assigning

Tasks and Effort estimates

Pulling from flow chart

State Containers

rocessor

Cache

Memory Each Blocks State space

Most likely register models

CPU

Arbiters

Bridges



39/49

Task Assigning

Example Resource Allocation

. . . .

Ana Processor TLM CPU Prediction CPU Prediction CPU Test Writing

.

Claudette DCR TLM DCR Transactor DCR Transactor DCR Test Writing

anny ac e a e ransac or ransac or es r ng

Erika Mem. State PLB Transactor PLB Transactor PLB Test Writing

Fred OPB Transactor OPB Transactor Arbiter Prediction OPB Test Writing

Grace MEM Transactor MEM Transactor Bridge Prediction MEM Test Writing

Henri Blk n State Space Blk n State Space Assertion Writing ARB Test Writing



40/49

Task Assigning

Other blocks that need assi nin

Our standard environment blocks

Starting, logging, stopping

ese are nc u e n ase c asses

Test running, Data collection

vMana er vMana er rovides this



41/49

Execution

Tasks are assi ned, lets et to work

Now we use Carters Metric Based Verification Requirements entered into vPlan

Employ this, use phases, and checkpoints

As team arrives at them, fill out checklist

Becoming part of sign off deliverables



42/49

Execution

Check oints are Ke to trackin ro ress

However, more checkpoints do not mean more visibality

Keep to logical milestones

My suggestions :

Modeling completion

Coverages > 90%

Closure



43/49

Execution

Modeling completion checkpoint

This early checkpoint confirms development environment is

installed, approach is documented, and stimulus models compile

Checklist Item Details Date

Simulator Installed Version :Classes and calls documented Attach Doc.

Code Reviews completed Attach Doc.

Core constraints done Revision tag:All consumers acceptance Signoffs:



44/49

Execution

Initialization running checkpoint

At this point simulations run and pass, code coverage is used as

the metric to measure progress. There are very few assertions orfunctional coverage yet


Device initialization test passes Attach Log File:Code coverage report generated Attach Report:

Assertion list documented Attach Doc:

Functional coverage documented Attach Doc:



45/49

Execution

Coverage > 90% checkpoint

At this point several simulations run, random generation is solid,

checks and assertions are all installed and all functional coverage


Code coverage reviewed Report, waivers:Assertions implemented Report, Assertion Cov:

Functional coverage implement Report, Functional Cov:

Tests run with multiple seedsAll regressions pass all seeds



46/49

Execution

Closure checkpoint

All coverpoints at 100% or waivered, Functional, Code and

Assertions. All tests pass with multiple random seeds.


Functional coverage reviewed Attach Report, waivers:Assertions trigger and pass

Review all docs

Archive EnvironmentPost Mortem



47/49

Summary

A Lot of material covered

Planning

Task Identification

Execution

Checkpointing Closure

Not Covered

Prediction Details



48/49

48


49/49

2009 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence, 1st Silicon Success Allegro Accelerating Mixed Signal Design Assura BuildGates Cadence Cadence

logo Conformal Concept Connections Diva Dracula ElectronStorm Encounter EU CAD Fire & Ice First Encounter HDL-ICE Incisive Invisible Specman InstallScape IP

Gallery Nano Encounter NanoRoute NC-Verilog NeoCell NeoCircuit Neo Circuit - RF NeoIP OpenBook OrCAD Palladium Pearl PowerSuite PSpice SignalStorm Silicon

-

Strikes Verifault-XL Verification Advisor Verilog Virtuoso VoltageStorm Xtreme are either registered trademarks or trademarks of Cadence Design Systems, Inc.

All others are the property of their respective holders.

2009 Cadence Design Systems, Inc. All rights reserved.

Documents

Finding the Flow