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