1 / 18

L9 - Verification Strategies

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. Strategy Depends On. What needs verification Functionality of system/sub-system/part/…

rachel
Télécharger la présentation

L9 - Verification Strategies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related