Presenter

1
Testbench Automation Concepts
Teaching Functional Verification Workshop DAC
2002, Sunday June 9th.

• Title of Presentation
• Presenter

Matthew J Morley
2
Agenda

• The University Program
• Functional Verification at a Glance
• Key Testbench Concepts
• Setting Objectives
• Modeling and Data Abstraction
• Data Injection and Collection
• Self Checking
• Summary

3
The 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 Verisitys 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

4
Verification Vault
5
Verification Vault
6
Verification Advisor

• An extensive repository of verification lore
• Organized into design patterns
• HTML based for easy access
• Kept in sync with Specman major releases

7
Verification 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

8
(No Transcript)
9
Agenda

• The University Program
• Functional Verification at a Glance
• Key Testbench Concepts
• Setting Objectives
• Modeling and Data Abstraction
• Data Injection and Collection
• Self Checking
• Summary

10
(No Transcript)
11
(No Transcript)
12
Agenda

• The University Program
• Functional Verification at a Glance
• Key Testbench Concepts
• Setting Objectives
• Modeling and Data Abstraction
• Data Injection and Collection
• Self Checking
• Summary

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

• 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?

14
Coverage

• 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.

15
Coverage 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)

16
Modeling 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

17
Data modelling
Upping the level of abstraction somewhat
struct frame kind LLC, L2,
ETHERNET llc LLCHeader destAddr uint
(bits48) srcAddr uint (bits48) size
int
Physical data and virtual (auxiliary) data both
play an important role in the verification
environment.
18
(No Transcript)
19
Test 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

20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)