Scribd
Upload
284 views8 pages

UNIT-4 Verification Plan: LVS-22 Vlsi Testing and Verification

The document discusses the importance of having a verification plan for verifying an ASIC design. It explains that the plan should specify what the design is intended to do and not do, define requirements and test coverage goals, and outline a schedule for verification. An example ASIC verification plan is provided that covers functional and design requirements, defines coverage goals, and specifies requirements for embedded firmware verification. The conclusion emphasizes that a verification plan provides estimates and allows measuring progress towards coverage goals.

Uploaded by

SanthoshReddy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
284 views8 pages

UNIT-4 Verification Plan: LVS-22 Vlsi Testing and Verification

The document discusses the importance of having a verification plan for verifying an ASIC design. It explains that the plan should specify what the design is intended to do and not do, define requirements and test coverage goals, and outline a schedule for verification. An example ASIC verification plan is provided that covers functional and design requirements, defines coverage goals, and specifies requirements for embedded firmware verification. The conclusion emphasizes that a verification plan provides estimates and allows measuring progress towards coverage goals.

Uploaded by

SanthoshReddy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

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.

You might also like