Download presentation
Presentation is loading. Please wait.
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 EE694v - Verification
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 EE694v - Verification
3
Strategy Depends On (2) Level of abstraction
High level - (courser granularity) Low level - (fine granularity) EE694v - Verification
4
Verifying the Response
Verifying the response is a difficult task Applying stimulus is easy You must know EE694v - Verification
5
Methods to Check Response
Visual inspection of the value of responses Visual inspection of the signal waveforms EE694v - Verification
6
Random Verification Does random verification mean you randomly apply 0’s and 1’s to inputs? Can create conditions that are not covered in verification plan EE694v - Verification
7
Random Verification (2)
Must address how result will be checked EE694v - Verification
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 EE694v - Verification
9
Feature of a UART Design
EE694v - Verification
10
Component-level Versus System-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 EE694v - Verification
11
Error Types The type of errors depend on what the model describes and how the design was captured EE694v - Verification
12
From Features to Testcases
Features can be classified as must-have, should-have, and nice-to-have Must-have features Should-have features EE694v - Verification
13
From Features to Testcases (2)
Should-have features (continued) Nice-to-have features EE694v - Verification
14
Testcase Grouping Features naturally fall into groups
Example - A CPU interface EE694v - Verification
15
Testcase Grouping - (2) For each testcase, need expected response and how the response will be determined valid/in error EE694v - Verification
16
Design For Verification
Testing of some features is often very hard to do May require a change to design EE694v - Verification
17
From Testcases To Testbenches
Testcases naturally fall into groups Each testbench should list the testcases it implements EE694v - Verification
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 EE694v - Verification
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.