Title of Presentation Presenter Matthew J Morley Teaching Functional Verification Workshop DAC 2002, Sunday June 9 th. Testbench Automation Concepts

Testbench Automation Concepts DAC 2002 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

Testbench Automation Concepts DAC 2002 The University Programme A low key affair since October 1999 – 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 2002 Verification Vault

Testbench Automation Concepts DAC 2002 Verification Vault

Testbench Automation Concepts DAC 2002 Verification 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 2002 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

Testbench Automation Concepts DAC 2002 The Functional Verification Space Verification Process Design Stage Module System Chip Writing Tests Verif. Env Development IP Software SOC Trend

Testbench Automation Concepts DAC 2002 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

Testbench Automation Concepts DAC 2002 Functional View Data & Temporal CheckingConstraint-driven Test Generation Design/Interface Specification and Functional Test Plan HDL Simulator HDL (Device Under Test) FunctionalCoverageAnalysis

Testbench Automation Concepts DAC 2002 Process View Coverage Analysis Simulation DUT Test Environment Functional Test Plan Design Spec Tests Environment Development… Verification…

Testbench Automation Concepts DAC 2002 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

Testbench Automation Concepts DAC 2002 Setting 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 2002 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.

Testbench Automation Concepts DAC 2002 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”); };

Testbench Automation Concepts DAC 2002 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

Testbench Automation Concepts DAC 2002 Data 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 2002 Constraining 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 2002 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

Testbench Automation Concepts DAC 2002 Packing 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 2002 Data Checking BFM unpack() DUT Output Transactor ? Our favorite checking scheme involves something 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 packet corresponds to that transmitted?

Testbench Automation Concepts DAC 2002 Temporal Checking DUT inputoutput ? => { [..9]; true(‘service’==0); [3]*(not rise(‘service’)

Testbench Automation Concepts DAC 2002 Summary Data generation & stimulus injection Data retrieval & coverage recording Check Data integrity & transformation Check sequential & temporal behavior K --- L - J ---- coverage DB ? checking Log Data Generator Abstract test file DUT inputoutput