Title of Presentation Presenter Matthew J Morley Teaching Functional Verification Workshop DAC 2002,...
-
Upload
maude-gallagher -
Category
Documents
-
view
214 -
download
0
Transcript of 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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
Verification VaultVerification Vault
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
Verification VaultVerification Vault
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
The Functional Verification SpaceThe Functional Verification Space
Verification
Process
DesignStage
Module
SystemChip
Writing Tests
Verif. Env Development
IP
Software
SOCTrend
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
Process ViewProcess View
Coverage AnalysisCoverage Analysis
SimulationSimulationDUT
Test Test EnvironmentEnvironment
Functional Test Functional Test Plan Plan
Design SpecDesign Spec
TestsTests
Environment Development…
Verification…
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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.
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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”); }; };};
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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.
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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…
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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)
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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?
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
Temporal CheckingTemporal Checking
DUTinput output
?
expect @exec_intr => {
[..9]; true(‘service’==0);
[3]*(not rise(‘service’)
} @clk;
Testbench Automation Concepts • DAC 2002Testbench Automation Concepts • DAC 2002
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