LVS-22

VLSI TESTING AND VERIFICATION

UNIT-4
VERIFICATION PLAN
Contents:

• Introduction
• Role Of Verification Plan
• Specifying The Verification Plan
• Defining The First Success
• EX: ASIC Verification Plan
• Conclusion
0
 INTRODUCTION

• The verification plan is a specification document for the

verification effort
• Ad-hoc approaches are inefficient
• Define first-time success
• Which features are critical and which optional
• Define a verification schedule
• Specify the features that must be verified
• The RTL design team must contribute
• Plan how to verify the response
• Some responses are difficult to verify visually
ROLE OF THE VERIFICATION PLAN:
 Traditionally, verification is an adhoc process.
• Your decision would be simple.
• Left to each hardware designer to do as they wish.
• Performed as time allows.
• Hoping that system integration would be smooth and that the board designs would not
need too many barnacles.
• Implemented in FPGAs, trading additional per-unit costs for flexibility in fixing problems
later found during system integration.

 Tools exist to help determine when you are done.

• Linting Tools, Simulators, Waveform Viewers etc…

• Code coverage, bug find rate, and code change rates.
• Provide a snapshot of the current situation.
• They cannot be used to predict the future.
SPECIFYING THE VERIFICATION PLAN:

• A definition of what the design does shall be specified.

• input patterns it can handle,
• errors it can sustain
• based on functional specification document of the design agreed
upon by the design and verification teams.
• A definition of what the design must not do shall be specified.
• The verification requirements must outline which errors to look for.
• Any functionality not covered by the verification process shall be
defined
• The conditions considered to be outside the usage space of the
design must be outlined
• Each verification requirement must have a unique identifier.
• Requirements should be ranked and ordered
• Stimulus requirements shall be identified.
DEFINING THE FIRST SUCCESS:
If, and only if, it is in the plan, will it be verified.
• what first-time success is.
• you must identify which features must be exercised under which conditions
and what the expected response should be.

From the verification plan, a detailed schedule can be created.

• Once the plan is written.
• You can define a detailed verification schedule, and allocate testbenches to resources, parallelizing verification as much
as possible.

The team owns the verification plan.

EX:ASIC VERIFICATION
An ASIC verification plan would consists of:
• Functional requirements
• Design requirements
• Defining coverage goals and
• Embedded firmware requirements

Specification:
• Captures Requirements Of The Design.
• Functional and Design Requirements.
• Design Requirements.
• Peripheral Specific Requirements.
• System Specific Requirements.

Defining The Coverage Goals:

• Constraints

Embedded Firmware Requirements:

• piece of software embedded into the ROM/EPROM.
• firmware verification is restricted to SOC level .
• Startup sequences, bootstrap loaders, memory test routines, tests for production etc.
CONCLUSION

• Verification plan gives an early estimate on effort, resource required, reuse

percentage and coverage goals.

• Verification closure is an iterative process where the plan is measured

against the implementation and coverage goals.

• Verification reuse can be achieved with proper planning, reusable

verification environment and proper documentation.