Functional Verification Figure 1.1 p 6 Detection of errors in the design Before fab for design errors, after fab for physical errors

Design Error, Traffic Light Controller Figure 1.2 p 8Figure 1.3 p 9 Design may not match specification Design (and spec) may not match intent Example: Elm St. light may starve is Main St. has traffic

General Verification Approaches Simulation-Based - Simulate the design with test stimuli and check the results Formal Verification - Proving facts about the design Only a small part of the space can be explored Hard to tell if testing is sufficient Model checking, Equivalence checking Time and space issues Hard to tell if properties are complete

Functional Verification Challenges 1.State Space Size - Capturing state can consume space and exploring state space consumes time 2.Test Generation - Generating input sequences to reveal errors 3.Response Analysis - Checking the results to see that they are correct

State Space Size Fig 1.5, p colors 1024 x 768 pixels Pressing a button superimposes name on the screen Must consider screen state as well Total states = 5 * 2 32 * 1024 * 768 = 16,888,498,602,639,360

Test Generation/ Response Analysis Table 1.1, p13 Test gen and analysis depends on the design

Test and Response Options Functional-Based Stimulus - Instruction stream loaded into memory Result Validation - Do the resulting registers have the correct values after each instruction? Microprocessor Digital Video Converter Functional-Based Stimulus - Streaming encoded video Result Validation - Does the video appear correctly on a monitor?  How do you test internal components (forwarding, DCT)?

Costs of Testing Schedule (Time-to-Market) - Release your product before your competition Paying Engineers - Could be working on another project Test Hardware Purchase/Maintainance - oMachines to run simulation/debug oMay need special test fixtures to model environment Quality Requirements - oCost of recall oLoss of life/money

Cost of Errors During Lifetime Fig 1.7, p 17 The cost of undetected problems grows over time

Verification Cycle Fig 1.9, p 25 Start with a functional specification Verification partially in parallel with design process Big cycle involves learning from previous designs

Functional Specification A natural language description of the functionality Hard to define, varies based on design style Defines I/O behavior without implementation detail May include timing diagrams, UML, scenarios, etc. Ambiguous and Incomplete - All natural languages are ambiguous. Ambiguity is resolved during design Specification is generally not executable Cannot be understood by an automatic tool

Verification Plan A plan for organizing the verification process Abstract, no testing details Includes required tools, completion criteria, resources, functions to be verified, etc. Used to manage the process

Develop Environment Write code and setup tools used to perform testing 1.Write testbench to generate test stimuli 2.Define assertions to check responses 3.Define reference model to compare responses 4.Determine when and where to sample values

Debug and Regression Perform simulation, debug the HDL and the environment Regression - Continuous running of tests in verification plan Randomness in tests Design modifications

System Test and Escape Analysis Apply tests to the real system Fast, but bad observability Captures effects not modeled by a simulator Determine why simulation missed bugs Reproduce bugs in simulation Good for future designs