Coverage

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 10

Functional Coverage

Introduction
Code coverage reflects how thorough the HDL code
was exercised. the set of features provided by code
coverage tools usually includes line/block coverage,
arc coverage for state machines, expression
coverage, event coverage and toggle coverage.
There are some limitiation with this approach. they
are,
Overlooking non-implemented features.
The inability to measure the interaction between
multiple modules.
The ability to measure simultaneous events or
sequences of events.

Functional coverage perceives the design


from a user's or a system point of view.
Have you covered all of your typical scenarios?
Error cases? Corner cases? Protocols?
Functional coverage also allows relationships,
"OK, I've covered every state in my state
machine, but did I ever have an interrupt at the
same time?
When the input buffer was full, did I have all types
of packets injected?
Did I ever inject two erroneous packets in a row?"

SystemVerilog functional coverage features are


below.

Coverage of variables and expressions, as well as cross


coverage between them
Automatic as well as user-defined coverage bins
Associate bins with sets of values, transitions, or cross
products
Filtering conditions at multiple levels
Events and sequences to automatically trigger coverage
sampling
Procedural activation and query of coverage
Optional directives to control and regulate coverage

Functional Coverage types


There are 4 places where functional coverage points can
be coded in a verification enviroment, and they can be
classfied as

F1 : Functional
F2 : Functional
DUT
F3 : Functional
states
F4 : Functional
DUT

coverage points are very near the randomization


coverage points are sampled at input interface of
coverage points which sample internal DUT
coverage points which sample output interface of

F1 Coverage pointsThese set of coverage points are coded in


class which is instantiated very near to the randomization and it is
before actual BFM/driver to DUT.
F2 Coverage pointsThese set of coverage points are coded in
class which is instantiated inside a input monitor or coverage class
itself will have ablitiy to sample the DUT input signals. This is
perfect for having functional coverage on stimulus that DUT is
being driven with,
F3 Coverage pointsThese set of coverage points are coded in
class which is instantiated as standalone class, and it monitors the
internal states of DUT, like FSM states, or some registers.
F4 Coverage pointsThese set of coverage points are coded in
class which is instantiated inside a output monitor or coverage
class itself will have ablitiy to sample the DUT output signals. This
is perfect for having functional coverage on output of DUT,

CoverGroup Inside a
Class
As said earlier, covergroup can be embedded inside a
class, interface, or module. When emebedded inside a
class, it allows to generate coverage on subset of class
properties. Important difference between a covergroup in
module and covergroup in class is that, it is optional to
create the instance of covergroup in class. as this is kind
of automatic i.e the coverage group is implicitly declared.
An embedded covergroup can define a coverage model
for protected and local class properties without any
changes to the class data encapsulation. Class members
can become coverage points or can be used in other
coverage constructs, such as conditional guards or option
initialization. A class can have more than one covergroup.

Cross coverage
coverage group can specify cross coverage
between two or more coverage points or
variables. Cross coverage is specified using the
cross construct. When verifying complex
systems it is important that combination of
functional points are verified.

cross cmd (READ/WRITE) and addres for


memory component
cross packet type and packet length for a
networking component

Coverage options
Coverage OptionsLike in Vera, Systemverilog provides ways to control
the behavior of the covergroup, coverpoint and cross. One of the most
common usage of these coverage options is setting weightage of a
covergroup. In a advanced testbench there could be many covergroups,
and from the verification point of view some covergroups have high
priority, and they migh be is less number, on other there hand there
could be covergroups which are of low priority, and they are in large
number. There is no way simulator is going to know this priority
information, so Systemverilog provides options to communicate this to
simulator. This way, even if don't have good coverage on low priority
covegroup, it won't effect overall coverage in big way.

There are two types of options

covergroup instance specific options
All instance specific options

You might also like