Verification Plan - Functional Verification - Lecture Slides, Slides of Computer Science

Download Verification Plan - Functional Verification - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Verification Plan

Verification Plan

 This is the specification for the

verification effort. It gives the what am

I verifying and how am I going to do it!

Specifying the Verification

 When are you done? Metrics  The specification determines the “what has to be done”!  The specification does NOT determine the following:  How many will it take?  How long will it take?  Are you are doing needs to be done?  Verification Plans define that!

Specifying the Verification

(continued)

 The plan starts from the design specification

• why – The reconvergence model!!  Must exist in written form  “the same thing as before, but at twice the speed, with these additions…” – Not acceptable specification.  The specification is a golden document – it is the “law”.  It is the common source for the verification efforts and the implementation efforts.

Defining 1st^ time success

(continued)

 Plan creates a well defined line, that when crossed can endanger the whole project and its success in the market.  It defines:  How many test scenarios (testbenches/testcases) must be written  How complex they need to be  Their dependencies  From the plan, a detailed schedule can be produced:  Number of resources it will take – people, machines, etc  Number of tasks that needs to be performed  Time it will take with current resources

Verification Plan

 Team owns it! Everyone involved in the project has a stake in it.  Anybody who identifies deficiencies should have input so they are fixed.  The process used to write the plan is not new. It has been used in the industry for decades. It is just now finding its way to hardware. Others who use it:  NASA  FAA  Software

Verification Levels (continued)

 How to decide what levels? There are trade- offs:  Smaller ones offer more control and observability but more effort to construct more environments  Larger ones, the integration of the smaller partitions are implicitly verified at the cost of lower control and observability but less effort because fewer environments  Whatever level is decided, those pieces should remain stable.  Each verifiable piece should have its own specification document Docsity.com

Unit Level

 Usually pretty small  Interfaces and functionality tend to change often  Usually don’t have independent specification associated with them  Environment (if one) is usually ad hoc  Not intended to gain full coverage, just enough to verify basic operation (no boundary conditions)  High number of units in a design usually means it is not reasonable to do unit level due to high level of effort for environments

ASIC/FPGA Level

 Physical partition provides a natural

boundary for verification

 Once specified, very little change due to ramification down stream.

 FPGA’s used to get debugged at

integration. Now they are so dense,

that a more ASIC flow is required.

System Level

 What is a system?  Everyone’s definition is a little different.  Verification at this level focuses on interaction, not function buried in one piece.  A large ASIC may take this approach. (Assuming that all pieces that make up the ASIC are specified, documented, and fully verified).  Assume that individual components are functionally correct.  Testcase defines the system.

Current Practices for Verifying

a System

 Designer Level Sim

 Verification of a macro (or a few small macros)

 Unit Level Sim

 Verification of a group of macro’s

 Chip (Element) Sim

 Verification of an entire logical function (I.E. processor, storage controller, Ethernet MAC, etc)

 System Level Sim

 Multiple chip verification  Sometimes done at a ‘board’ level  Can utilize a mini operating system

In an Ideal World….

 Every Macro would have perfect verification performed  All permutations would be verified based on legal inputs  All outputs checked on the small chunks of the design  Unit, Chip, and System level would then only need to check interconnections  Ensure that macros used correct Input/Output assumptions and protocols

Verification Strategies

 Must decide the following:

 White Box, Black Box, Grey Box  Types of testcases  Level of abstraction where majority of verification takes place  How to verify the response  How random will it be

Verifying the Response

 Deciding how to apply stimulus is usually easy part.  Deciding response is hard part.  Must plan how to determine the expected response  How to determine that design provided response that you expected  Detect errors and stop simulation as early as possible. Why?  Error identified when it takes place – easier to debug  No wasted simulation cycles