system verilog

23
SYSTEM VERILOG - VERIFICATION METHODOLOGY Vinchip Systems (a Design and Verification Company) Chennai.

Upload: vinchipsytm-vlsitraining

Post on 11-May-2015

2.795 views

Category:

Technology


4 download

TRANSCRIPT

Page 1: system verilog

SYSTEM VERILOG -VERIFICATION METHODOLOGY

Vinchip Systems(a Design and Verification Company)

Chennai.

Page 2: system verilog

Synopsis

Introduction

Verification methodology Key features

Verification Flow

Verification Environment

SV Based Verification

Integration, Simulation

Bug Report mechanism

Page 3: system verilog

7/17/12Introduction

• Verification is the process of

experimenting our design with possible test

scenarios.

• Verification contains many phases that

includes Testcase generation, coverage,

monitor ..,etc.

• Before tape-out our design should be

verified more than 90% successfully.

Page 4: system verilog

Verification methodology key features

The key features associated with the verification methodology are:

Assertion Based Verification

Functional Coverage Driven Verification

Constrained Random Verification

Scoreboard & Checker

Page 5: system verilog

Key features.....

Assertion Based Verification

Assertion Based Verification helps to detect more functional bugs earlier in the verification process and enables short verification cycle times and faster debugging.

Functional Coverage Driven Verification

Functional Coverage Driven Verification is the process in which the result of functional coverage is used to drive the verification to completion. It also gives a more structured approach to verification, instead of writing more testcases.

Page 6: system verilog

Key features......

Constrained Random Verification

It is well suited for designs that have diverse set of operations and sequences that are difficult to cover completely. Constrained random tests are faster to write and enables faster verification of the design.

Scoreboard & Checker

Scoreboard and Checker is a mechanism used to dynamically predict the response of the design and check the observed response against the predicted response. Usually it refers to the entire dynamic response-checking structure.

Page 7: system verilog

Verification FlowDesign Specifications

Verification plan

Testcase Scenarios Testbench Environment1

Testcase generation

(handcrafted SCV/SV generatedModel and Testbench

Devolopment

Integration of RTL with Testbench Environment

RTL function

verified

Testsuit Regression Coverage

Coverage Target

Achieved?

END

Modify RTLNo

YES

NO

YES

Page 8: system verilog

Verification Flow

Design Specification

Verification flow starts with understanding the architecture specification of the design under verification. Once the architecture is well understood then comes the verification plan.

Verification Plan

The verification plan comprises the preparation of test case scenarios and testbench environment

Page 9: system verilog

Testcase Scenarios

The testcase scenarios document includes all the possible combinations to test the functionality of the design under test.

Test Case Scenarios

Self Checking Non-Self Checking

Page 10: system verilog

Self Checking

Self checking test cases are written in such a way that it tests itself.

Self Checking

Corner Directed Coverage

Page 11: system verilog

Self Checking

Corner

Corner cases covers the scenarios which are prone to errors and non-trivial, where there are more possibilities of uncovering bugs.

Directed

Directed cases covers all the scenarios related to the general features and they are straight forward cases which are written in an orderly manner.

Coverage

Coverage cases are based on the coverage report and they contain the scenarios which are missedout in the other normal categories.

Page 12: system verilog

Non - Self Checking

Non - self checking test cases has no self checking code and they are coded such that if the program execution reaches the last line of the test case properly then a success code will be moved into a specific register. After the completion of execution that register can be checked for the success code to ensure the correctness of the design.

Non-Self checking

Random StressConstrained

RandomNegative

Applicationspecific

Page 13: system verilog

Non - Self Checking

Random

Random cases cover all the possible combinations of data as well as scenarios in a random manner.

Constrained Random

Constrained Random cases cover the all possible combinations of data as well as scenarios in a random manner, constrained for valid combinations.

Stress

Stress cases exercise the logic with more number of combinations of scenarios as well as data for a long time to ensure the reliability of the design under stress conditions.

Page 14: system verilog

Non - Self Checking

Negative

Negative cases covers the scenarios which are not possible under normal cases. They are used to analyze the behavior of the design under error conditions.

Application Specific

High level cases targeted for a particular application normally written in “C” language.

Page 15: system verilog

Testbench Environment

The testbench environment includes different types of environments to be developed for effectively verifying the design under verification. The testbench environments are of two types based on the testing strategies adopted.

• Top Level

• Block Level

Page 16: system verilog

Top Level

The top level testing includes the testing of the design as a whole and the stimulus forced in this case is the memory image generated from the assembly level or high level test files. Based on the requirement for the verification, there are three types of environments.

Top Level

Static Dynamic Coverage

Page 17: system verilog

Static

Performs functional verification in a static manner using functional model. The results of DUT and model are dumped and compared for equivalence once the execution is over.

Dynamic

Performs timing verification in a dynamic manner using the cycle accurate model. The results of DUT and model are compared for equivalence at each and every cycle dynamically.

Coverage

The following are considered :

• Line coverage

• Branch coverage

• FSM coverage

Page 18: system verilog

Block Level

Block level verification includes the verification of the different inner modules of the design for checking the scenarios which cannot be covered using the top level verification. It includes both static and dynamic environments and the stimuli in this case are inputs generated using tasks.

The testbench provides different debugging options and also uses sentinels to ensure the error free flow of data.

Page 19: system verilog

SystemVerilog Based Verification Environment

Sequencer

Driver Monitor

Sequencer

DriverMonitor

Scoreboard

DUT

Page 20: system verilog

SystemVerilog Based Testbench Development

Sequencer

Sequencer is an object that defines a set of transactions to be executed and controls the execution of other sequences.

Driver

It is the component responsible for executing or processing transactions and provides stimuli to the design-under-test (DUT).

Monitor

This block continuously monitors the DUT signals and bus functions.

Scoreboard

Driver requests are transferred to the scoreboard via monitor block.

Page 21: system verilog

Scoreboard components :

Functional Coverage Accumulation

Functional coverage is a measure of which design features have been exercised by the tests.

Dynamic response checking mechanism

The comparison of golden data with DUT data is performed dynamically. This block controls the overall verification environment such as reporting, violations and changing of the stimulus during run-time.

Reporting mechanism

Compiler directives to issue messages throughout the simulation. (Error, Info, Warning)

Page 22: system verilog

Integration,Simulation

Integration

Once the RTL coding is over, it is hooked up in the testbench environment and then the verification process can be started.

Simulation

Design is simulated using the simulation tool. Any error in the simulation triggers an error message which is dumped into an error log.

TestSuite Regression / Coverage

The Regression Environment is developed using perl and shell scripts, to automate the regression run.

Page 23: system verilog

Bug Report Mechanism

Bug reports are maintained in Google docs for all the projects in the verification phase. Once the bug is encountered it is updated in the bug report with detailed information. Status of the open bugs is updated regularly.