Verification – The importance

1. Verification – The importance EE694v-Verification-Lect2

2. Project 1 is underway • Open discussion of the Verification Plan for project 1. • Discussion. EE694v-Verification-Lect2

3. Verification – The Importance • Verification model • Verification approaches • Verification issues • Versus testing • Design for verification • Reuse • Type I & II mistakes • Reference: “Writing Testbenches: Functional Verification of HDL Models,: Janick Bergeron, Kluwer Academic Press, 2000. for all figures in this lecture. EE694v-Verification-Lect2

4. Importance of Verification • Verification consumes 70% of design effort and is often 80% of total code. • Typical textbooks on VHDL or Verilog treat verification and testbench creation only very lightly • Navabi textbook used in EE762 • 3 pages on verification • 4 pages on testbenches • In today’s environment verification resides squarely on the critical path. EE694v-Verification-Lect2

5. Importance (cont) • Verification is currently the target of several new tools • That reduce to overall verification time by enabling parallelism of effort • Write and debug testbenches in parallel with each other and with implementation of design • That enable higher levels of abstraction • Work more efficiently as low-levels of detail are ignored. • This is acceptable as long as reduction in control and observability are acceptable and chosen wisely • That employ automation • Must fully understand what tool is and is not capable of. EE694v-Verification-Lect2

6. Reconvergence Model • A conceptual representation of the verification process. • One of the most important questions is: “What are you verifying?” EE694v-Verification-Lect2

7. Reconvergence Model (cont) • Purpose of verification - ensure result of some transformation is as intended or expected, i.e., reconcile result with starting point. • Examples of possible transformations • RTL coding of a design from a specification • Insertion of a scan chain • Synthesizing code into a gate-level netlist • Layout of a gate-level netlist in the target technology EE694v-Verification-Lect2

8. Human Intervention • Necessary for a group or individual to interpret a specification • If the same individual does both the interpretation of the specification and the verification of the coding the common origin is the interpretation not the specification. If the interpretation is wrong… EE694v-Verification-Lect2

9. Reducing human-itroduced errors • Human-introduced errors reduced through • Automation – Take human intervention completely out of the process (or kind of – still there in the specification and design of the automation process) • Poka-Yoka – Reduce human intervention to simple and foolproof steps. Usually last step toward complete automation. Verification process remains an art. • Redundancy – Every transformation accomplished is either verified independently by another individual or separate transformations are done and the results compared. EE694v-Verification-Lect2

10. Verification Approaches • Formal Verification - Equivalence Checking • Mathematically prove origin and output are logically equivalent and transformation preserved functionality • Keeps synthesis tool honest, i.e., identify when the synthesis tool produces an incorrect result. EE694v-Verification-Lect2

11. Verification Approaches • Formal Verification - Model Checking • Assertion or characteristics of a design are formally proven or disproved. • Example: Are all states in a state machine reachable? EE694v-Verification-Lect2

12. Verification Approaches • Functional Verification • Main purpose is to insure design implements intended functionality • Only shows that design meets intent of specification but cannot prove it. • Can prove that a design does not implement intended function by finding a single case. EE694v-Verification-Lect2

13. Verification Approaches • Testbench Generation • Use code coverage metrics and the source code under analysis to generate a testbench that either meets some code coverage or exercises the design to violate a property. • Actually do little to contribute to the verification process EE694v-Verification-Lect2

14. Functional Verification Approaches • Black Box verification • Performed without knowledge of actual implementation • Access to I/O interface only • No access to internal signals and no knowledge of structure and implementation • Only approach possible if functional verification was implemented in parallel while the design was being done EE694v-Verification-Lect2

15. Functional Verification Approaches (continued) • White Box verification • Full visibility and controllability of internal structure and signals • Tightly integrated with a particular implementation • Gray Box verification • Compromise between the other two • Uses the I/O interface but also has knowledge of significant features EE694v-Verification-Lect2

16. Testing versus Verification • Verification – Ensure design meets its functional intent • Testing – Ensure part was manufactured correctly EE694v-Verification-Lect2

17. Design for Verification • Just as design-for-test requires addition of circuitry, add non-functional features to facilitate verification • As you do a design need to ask not only “what is this supposed to do?” but also “how is this going to be verified?” EE694v-Verification-Lect2

18. Design Reuse • Major obstacle to reuse is cultural!! • Engineers have little willingness to incorporate an unknown design into their own. Do not trust that the design is as good to the one they can produce. • Requires trust in the design to be used • Trustworthiness can be demonstrated through a proper verification process EE694v-Verification-Lect2

19. Type I and Type II mistakes • Type I – False negatives – verification finding errors where none exist – Type I errors are easy to identify • Type II – False positives – MOST SERIOUS – failed to identify an error where one exists EE694v-Verification-Lect2

20. Project 1 and Type I/II • When you find discrepancies what is approach • Establish if reference model or RTL model is the source of the error. • High probability that it is the RTL model, but that is not a certainty!  • Elevates analysis of errors to a critical level in the verification effort. EE694v-Verification-Lect2