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