L9 - Verification Strategies - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

L9 - Verification Strategies

Description:

... document to determine features that must be verified Each feature to be verified Feature of a UART Design Component-level Versus System -level Features ... – PowerPoint PPT presentation

Number of Views:60
Avg rating:3.0/5.0
Slides: 19
Provided by: Joanne262
Learn more at: https://www.cse.psu.edu
Category:

less

Transcript and Presenter's Notes

Title: L9 - Verification Strategies


1
L9 - Verification Strategies
  • What the verification strategy depends on
  • Checking responses
  • Random verification
  • From specification to features
  • From features to testcases
  • From cases to testbenches

2
Strategy Depends On
  • What needs verification
  • Functionality of system/sub-system/part/
  • Level of granularity
  • Types of testcases and ability to verify
    responses
  • Level of knowledge of implementation, i.e.,
    white-box or black-box

3
Strategy Depends On (2)
  • Level of abstraction
  • High level - (courser granularity)
  • Low level - (fine granularity)

4
Verifying the Response
  • Verifying the response is a difficult task
  • Applying stimulus is easy
  • You must know

5
Methods to Check Response
  • Visual inspection of the value of responses
  • Visual inspection of the signal waveforms

6
Random Verification
  • Does random verification mean you randomly apply
    0s and 1s to inputs?
  • Can create conditions that are not covered in
    verification plan

7
Random Verification (2)
  • Must address how result will be checked

8
From Specification to Features
  • Verification plan identifies the features that
    will be verified
  • Use specification document to determine features
    that must be verified
  • Each feature to be verified

9
Feature of a UART Design
10
Component-level VersusSystem-level Features
  • Component can be a unit, reusable component or an
    entire ASIC
  • System can be a subset of a few ASICs, an entire
    board design, a few ASICs, a complete product,
  • System level features usually limited to
  • - -

11
Error Types
  • The type of errors depend on what the model
    describes and how the design was captured

12
From Features to Testcases
  • Features can be classified as must-have,
    should-have, and nice-to-have
  • Must-have features
  • Should-have features

13
From Features to Testcases (2)
  • Should-have features (continued)
  • Nice-to-have features

14
Testcase Grouping
  • Features naturally fall into groups
  • Example - A CPU interface

15
Testcase Grouping - (2)
  • For each testcase, need expected response and how
    the response will be determined valid/in error

16
Design For Verification
  • Testing of some features is often very hard to do
  • May require a change to design

17
From Testcases To Testbenches
  • Testcases naturally fall into groups
  • Each testbench should list the testcases it
    implements

18
Verifying Testbenches
  • Purpose of testbenches is to verify that design
    meet the specification
  • Must ensure that testbench covers all must-have
    features of the design completely
  • Testbenches should also cover the should-have
    features adequately
Write a Comment
User Comments (0)
About PowerShow.com