FUNCTIONAL V E R I F I C A T I O N &
ASSERTION BASED
VERIFICATION
Workshop Curriculum
Phone Number
+91-9599745251
Visit Our Website
www.semidesign.in
Content
➢ Detailed explanation of Importance of Coverage
➢ Branch, Condition & Expression Coverage
➢ FSM Coverage
➢ Functional Coverage with all type of bins
➢ Toggle Coverage
➢ Lab Session & Case study
➢ How to reach 100% Coverage logical questions
➢ Introduction to Assertions
➢ Writing Sequences and Different type of Operators
➢ Immediate Assertion & Concurrent Assertion logic building
➢ Practical approach on How to connect assertions with DUT
➢ Assertions in Project Level
➢ Tips to develop a logical coding
➢ Interview preparation, Hands on Lab sessions, Assignments
Design complexity
Roles and Responsibilities of a Verification Engineer
➢ Writing test scenarios to verify the design
➢ Creating test scenarios to verify the design
➢ Understand the specification thoroughly
➢ Focus on thoughtful test plan based on RS
➢ Why do we need this feature what is the main purpose
of the feature etc….
Questions ?????
➢ When do we say the verification of a design is done???
➢ What is a verification plan????
➢ How would you track the progress of the verification project…
What metrics would you use????
➢ What is coverage ???
➢ What is the difference between code coverage and functional
coverage ??
➢ During a project if we observe high functional coverage i…e close to
98% and low code coverage i..e less than(<) 60 % what can be
inferred from this situation????
➢ During a project if we observe high code coverage i…e close to 98%
and low functional coverage i..e less than(<) 60 % what can be
inferred from this situation????
➢ Can we get the functional coverage information for the failing
testcases????
Representation of an ideal verification environment
Representation of an ideal verification environment with coverage
Code Coverage
Code Coverage: It is a metric used to measure how much the RTL
code is exercised by a given test suite.
Code coverage is automatically extracted by the simulator when
enabled
Coverage
➢Coverage is defined as the percentage of verification objectives
that have been met.
➢It is used as a metric for evaluating the progress of a verification
project.
➢Coverage metric forms an important part of measuring progress
in constrained random testbenches and also provides good
feedback to the quality and effectiveness of constrained random
testbenches.
➢Two types of coverage metrics namely:
1. Code coverage
2. Functional coverage
Code Coverage
Functional Coverage
Functional Coverage is very important in Test Bench Development.
It is a model, which helps us to track the covered items listed on
the verification plan.
Usually, the goal of a verification engineer is to ensure whether the
design behaves correctly in its real environment according to
specifications
Functional Coverage
Assertions
Assertions are primarily used to validate the behavior of a
design.
Assertions can be checked dynamically by simulation, or
statically by property checking or formal verification tools.
System Verilog supports rich constructs to implement
assertions in terms of sequences and property specifications
Code Coverage
Statement/Line coverage: This measures how many statements
(lines) are covered during the simulation of tests. This is generally
considered important and is targeted to be 100% covered for
verification closure.
Code Coverage
path coverage: Path coverage is considered to be more efficient
than branch coverage because it can detect the scenarios related to
the sequence of operations.
Code Coverage
Block coverage: A group of statements between a begin-end or if-
else or case statement or while loop or for loop is called a block.
Block coverage measures whether these types of block codes are
covered during simulation. Block coverage looks similar to
statement coverage with the difference being that block coverage
looks for coverage on a group of statements.
Code Coverage
Toggle coverage: It measures how well the signals and ports in the
RTL design are toggled during the simulation run. It will also help in
identifying any unused signals that does not change value.
The transition could be from 0 -> 1, 1 -> 0, x -> z, z -> x etc.
The toggle coverage doesnot consider the zero – delay glitches, this
will be useful in gls simulation.
Code Coverage
FSM coverage: FSM coverage measures whether all of the states and
all possible transitions in a given state machine are covered during a
simulation.
Functional Coverage
Why functional coverage has gained more significance ???
What would have happened if the functional coverage was not
there???
What is directed verification??
What is the constrained random verification???
How is it related to the functional coverage ???
Functional Coverage
System Verilog provides 2 ways to do the functional verification of
the design.
Cover group which is uses information from transactor, monitor and
checker.
Assertion coverage which is uses temporal language which can be
outside or inside RTL
Functional Coverage
Cover group is a user defined construct which encapsulates the
coverage model specification.
A covergroup can be defined inside a program , class, interface and
module.
Covergroup encapsulates the specification of
o Set of coverage point.
o Cross coverage between coverage points.
o A clocking event that synchronizes coverage points.
o Coverage options
o Optional formal argument.
Functional Coverage
The basic syntax of covergroup
Functional Coverage
bit [1:0] addr;
logic [7:0] data;
covergroup cg @(posedge clk);
a: coverpoint addr;
b: coverpoint data;
endgroup
cg cov = new();
cov.sample();
Functional Coverage
What is a coverpoint???
- A coverpoint is an integral expression or variable that has to be
covered on sampling the covergroup.
How many coverpoints a covergroup can have???
How many bins each coverpoint can have???
There are three types of coverpoints namely
- item functional cover points.
- cross functional cover points.
- transitional cover points.
Industry specific guidelines for functional coverage
Your test plan should be based on the functionality you want to
verify w.r.t to specification.
You should have a coverage matrix with the list of cover point
details w.r.t to your test plan scenario and there should be a link of
traceability between test scenario and cover point.
Environment should have control mechanism for enabling or
disabling coverage and assertions for better controllability in your
environment.
Don’t enable functional coverage at the beginning of the verification
to avoid simulation overhead in the starting phase of verification
During the initial time of the verification bug ratio is typically
higher, as you move forward to the verification bug ratio would start
to drop. Here is the time when you should enable coverage and start
analyzing it
Industry specific guidelines for functional coverage
Functional coverage plan needs to be updated as verification
progresses
As your knowledge of the design and corner case understanding
increases, you should keep updating your functional coverage plan
Make effective use of cover group “trigger” and sampling
mechanism.
Follow meaningful names of cover group and cover points. This will
help when you in debug process
Coverage should not be captured on failing simulations. Make sure to
gather coverage for only passing simulation. If few tests are not
passing in regression first make sure to fix those issues before
coming to a conclusion on coverage achievement
If your tests are keep exercising the same logic in design, start
developing the new tests for uncovered coverage part of coverage
(coverage holes)
Coverage bins
Bins are used to collect the coverage information
We can create a set of bins for a particular range.
The bins can be automated or can explicitly written by a
verification engineer.
Implicit bins
While defining the cover point, if you do not specify any bins,
then Implicit bins are created.
The number of bins creating can be controlled by auto_bin_max
parameter.
➢https://www.edaplayground.com/x/ngFt
Explicit bins
We can explicitly create bins.
Explicit bins creation is a recommended method, when the
requirement is as follows:
- when the user knows the exact values that has to be covered ,
then we can use explicit bins.
- when user is not interested in all the bins for suppose then also
we prefer to use explicit bins.
We can even provide the naming convention for bins.
A separate bin for each value in a given range.
A single bin for all the values in a range list
Ignore bins
A set of values or transitions associated with a coverage-point can
be explicitly excluded from coverage by specifying them as
ignore_bins.
All values or transitions associated with ignore_bins are excluded
from coverage
https://www.edaplayground.com/x/hjKh
iIlegal bins
A set of values or transitions associated with a coverage-point can
be marked as illegal by specifying them as illegal_bins.
All values or transitions associated with illegal bins are excluded
from coverage.
If an illegal value or transition occurs, a runtime error is issued.
https://www.edaplayground.com/x/QuHB
Wildcard bins
Wildcard is a keyword associated with bins.
Wildcard characters are x and z or ? each of which evaluate to 0 and
1.
Ex: We can use this types of bins for priority encoder.
By default, a value or transition bin definition can specify 4-state
values.
When a bin definition includes an X or Z, it indicates that the bin
count should only be incremented when the sampled value has an X
or Z in the same bit positions.
The wildcard bins definition causes all X, Z, or ? to be treated as
wildcards for 0 or 1 (similar to the ==? operator).
For example:
wildcard bins g12_16 = { 4'b11?? };
The count of bin g12_16 is incremented when the sampled variable
is between 12 and 16
1100 1101 1110 1111
https://www.edaplayground.com/x/QuV7
.
Transition bins
Transition coverage is a powerful tool for capturing and analyzing
state changes in sequential circuits, and it helps to ensure that the
design is thoroughly tested for all possible transitions.
Transitional functional point bin is used to examine the legal
transitions of a value.
SystemVerilog allows to specifies one or more sets of ordered value
transitions of the coverage point.
Type of Transitions:
Single valur transitions
Sequence of transitions
Set of transitions
Consecutive repetitions
Range of repetition
Non consecutive repetition
Goto repetetion
Cross Coverage
Cross coverage is specified between two or more coverpoints
variable.
Cross coverage is allowed only between coverpoints defined within
the same covergroup.
Expression cannot be used directly in a cross
Cross coverage is a combination of coverpoints and variables also.
When variable is used without a defined coverpoint for the
variable,a coverpoint is explicitly covered.
Interview Questions
During a project if we observe high functional coverage i…e close to
98% and low code coverage i..e less than(<) 60 % what can be inferred
from this situation????
There could be lot of design code which are not used for the
functionality implemented as per design specification. (also known
and dead code)
There is some error in the user defined functional coverage metrics.
Either the test plan is not capturing all the design features/scenarios
corner cases or implementation of functional coverage monitors for
same is missing.
The design code not covered in code coverage could be mapping to
this functionality.
There could be potential bugs in implementing functional coverage
monitors causing them to be showing as falsely covered. Hence it is
important in the verification project to have proper reviews of the
user defined functional coverage metrics and its implementation
