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

2. Synopsis
Introduction
Verification methodology Key features
Verification Flow
Verification Environment
SV Based Verification
Integration, Simulation
Bug Report mechanism

3. 7/1
Introduction
• 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.

4. 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

5. 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.

6. 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.

7. Verification Flow
Design Specifications
Verification plan
Testcase Scenarios Testbench Environment1
Testcase generation Model and Testbench
(handcrafted SCV/SV generated Devolopment
Integration of RTL with Testbench Environment
No RTL function
Modify RTL
verified
YES
Testsuit Regression Coverage
NO Coverage Target
Achieved?
YES
END

8. 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

9. 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

10. Self Checking
 Self checking test cases are written in such a way that it
tests itself.
Self Checking
Corner Directed Coverage

11. 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.

12. 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
Constrained Application
Random Stress Negative
Random specific

13. 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.

14. 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.

15. 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

16. 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

17.  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

18. 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.

19. SystemVerilog Based Verification
Environment
Scoreboard
Sequencer Sequencer
Driver Monitor Monitor Driver
DUT

20. 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.

21. 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)

22. 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.

23. 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.