L 9 Verification Strategies What the verification strategy

L 9 - Verification Strategies • • • What the verification strategy depends on Checking responses Random verification From specification to features From features to testcases From cases to testbenches EE 694 v - Verification 1

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. , whitebox or black-box EE 694 v - Verification 2

Strategy Depends On (2) • Level of abstraction – High level - (courser granularity) • • • – Low level - (fine granularity) • • EE 694 v - Verification 3

Verifying the Response • Verifying the response is a difficult task • Applying stimulus is easy – • • You must know – – EE 694 v - Verification 4

Methods to Check Response • Visual inspection of the value of responses • Visual inspection of the signal waveforms • • • EE 694 v - Verification 5

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 – – EE 694 v - Verification 6

Random Verification (2) • Must address how result will be checked – • EE 694 v - Verification 7

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 – – EE 694 v - Verification 8

Feature of a UART Design EE 694 v - Verification 9

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 – - EE 694 v - Verification 10

Error Types • The type of errors depend on what the model describes and how the design was captured • • EE 694 v - Verification 11

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

From Features to Testcases (2) • Should-have features (continued) – – • Nice-to-have features – – EE 694 v - Verification 13

Testcase Grouping • Features naturally fall into groups – Example - A CPU interface • • • EE 694 v - Verification 14

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

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

From Testcases To Testbenches • Testcases naturally fall into groups – – • Each testbench should list the testcases it implements • EE 694 v - Verification 17

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 EE 694 v - Verification 18