title of presentation presenter matthew j morley teaching functional verification workshop dac 2002,...

Title of PresentationPresenter

Matthew J Morley

Teaching Functional Verification Workshop

DAC 2002, Sunday June 9th.

Testbench Automation ConceptsTestbench Automation Concepts

Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002

AgendaAgenda

• The University Program

• Functional Verification at a Glance

• Key Testbench Concepts– Setting Objectives

– Modeling and Data Abstraction

– Data Injection and Collection

– Self Checking

• Summary


The University ProgrammeThe University Programme

• A low key affair since October 1999

– http://www.verisity.com/programs/university

• Currently around 15 member universities

– Canada, USA, Europe and Asia

• You Gain:

– Access to Verisity’s products and documentation

– e Language reference materials

– Entry into Verification Vault upon request

– On-line use of Verification Advisor

• We offer limited support for research projects and course development around e and Specman Elite


Verification VaultVerification Vault


Verification AdvisorVerification Advisor

An extensive repository of verification lore

Organized into design patterns

HTML based for easy access Kept in sync with Specman

major releases


Verification AdvisorVerification Advisor

• Provides expert guidance from the beginning:

– What should I do first? What is the right design process?

– What kind of data structures and checking schemes do I need

for this task?

• As well as concrete, clearly documented, examples for the

most complex activities:

– Selecting verification components for data-transfer devices,

bus-client devices, and protocols like PCI bus

– Building a fully functional eVC from scratch


The Functional Verification SpaceThe Functional Verification Space

Verification

Process

DesignStage

Module

SystemChip

Writing Tests

Verif. Env Development

IP

Software

SOCTrend


AgendaAgenda






– Self Checking

• Summary


Functional ViewFunctional View

Data & TemporalData & TemporalCheckingChecking

Constraint-drivenConstraint-drivenTest GenerationTest Generation

Design/Interface Specification and Design/Interface Specification and Functional Test PlanFunctional Test Plan

HDLHDL SimulatorSimulator

HDL (Device Under Test)HDL (Device Under Test)

FunctionalFunctionalCoverage Coverage AnalysisAnalysis


Process ViewProcess View

Coverage AnalysisCoverage Analysis

SimulationSimulationDUT

Test Test EnvironmentEnvironment

Functional Test Functional Test Plan Plan

Design SpecDesign Spec

TestsTests

Environment Development…

Verification…


AgendaAgenda






– Self Checking

• Summary


Setting ObjectivesSetting Objectives

• What do we want to achieve overall?

• What information do we have, is it adequate?

• What features are present, behaviors expected; how do these features interact?

• What are misbehaviors?

• How to codify these as individual goals?

Require to establish measurable criteria in order to judge how thorough the verification effort has been


CoverageCoverage

• Test that an interrupt is handled during JSR.

• The instruction decoder received an interrupt signal during a JSR instruction.

• For each interrupt received record the opcode in the decode register.


Coverage GroupCoverage Group

extend instr_s { event interrupt; -- Emitted on interrupted

cover interrupt is { item opcode using ranges = { range ([ADD..SHFL], “Arithmetic Op”); range ([JMP..JSR], “Branch Op”); }; };};


Modeling Structure & DataModeling Structure & Data

Start mush as the designer would, modeling:

• Overall system architecture

• Major data flows and functional elements

But paying much closer attention to

• (structure) Peripherals, I/O channels

• (behavior) BFMs that drive/readout data

• (data) The data themselves


Data modellingData modelling

struct frame {kind : [LLC, L2, ETHERNET];llc : LLCHeader;destAddr : uint (bits:48);srcAddr : uint (bits:48);size : int;

};

Upping the level of abstraction somewhat…

Physical data and virtual (auxiliary) data both play an important role in the verification environment.


Constraining Data InputsConstraining Data Inputs

extend frame {payload : list of byte;keep payload.size() in [0..size];

};

Each frame has a payload of a certain size:

extend frame {keep size == 0;

};

An individual test may specify a more specific size…


Test GenerationTest Generation

So this is what we mean by constrained, random

test generation

• The testbench defines the underlying test infrastructure

• Individual test files constrain that environment with specific goals in mind

• The generator creates a whole family of test stimuli given different random seeds


PackingPacking

Data Space

Test Criteria

Random Gen

BFM

pack() DUT

struct frame {kind : [LLC, L2, ETHERNET];llc : LLCHeader;destAddr : uint (bits:48);srcAddr : uint (bits:48);size : int;payload : list of byte;

};

Input Transactor

serial_bits = pack(low,current_frame)


Data CheckingData Checking

BFM

unpack() DUT

Output Transactor

?

Our favorite checking scheme involvessomething like a scoreboard

• Upon generation/injection compute expected packet header and destination channel

• Enter packet into scoreboard

• When packets emerge check them off the SB

Dilemma: how to determine that the emerging packetcorresponds to that transmitted?


Temporal CheckingTemporal Checking

DUTinput output

?

expect @exec_intr => {

[..9]; true(‘service’==0);

[3]*(not rise(‘service’)

} @clk;


SummarySummary

• Data generation & stimulus injection

• Data retrieval & coverage recording

• Check Data integrity & transformation

• Check sequential & temporal behavior

---

-

----

coverage

DB

?checking

Log

Data Generator

Abstract test file

DUTinput output

title of presentation presenter matthew j morley teaching functional verification workshop dac 2002,...

Documents

verification vault slide

glance key testbench

verification components

scratch slide

specman elite slide

functional evc

specman major releases

datatransfer devices