Verification

1
Verification The importance
2
Project 1 is underway

• Open discussion of the Verification Plan for
  project 1.
• Discussion.

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.

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 todays environment verification resides
  squarely on the critical path.

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.

6
Reconvergence Model

• A conceptual representation of the verification
  process.
• One of the most important questions is What are
  you verifying?

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

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

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.

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.

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?

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.

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

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

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

16
Testing versus Verification

• Verification Ensure design meets its functional
  intent
• Testing Ensure part was manufactured correctly

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?

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

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

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.