System verilog coverage

What is coverage?
 Coverage is a generic term for measuring progress to complete design verification.
 Your simulations slowly paint the canvas of the design, as you try to cover all of the
legal combinations. The coverage tools gather information during a simulation and
then post-process it to produce a coverage report.
 You can use this report to look for coverage holes and then modify existing tests or
create new ones to fill the holes.
 This iterative process continues until you are satisfied with the coverage level.

Types of coverage:
Functional coverage:
Functional coverage is a measure of what functionalities/features of the design
have been exercised by the test.
Types of functional coverage:
• Data oriented coverage
• Control oriented coverage
Data-oriented Coverage: Checks combinations of data values have occurred. We can
get Data-oriented coverage by writing Coverage groups, coverage points and also by
cross coverage.
Control-oriented Coverage: Checks whether sequences of behaviors have occurred.
We can get assertion coverage by writing System Verilog Assertion.

Types of coverage:
Code coverage:
Code coverage measures how much of the “design Code” is exercised. The
simulator tool will automatically extract the code coverage from the design code.
Types of code coverage:
• Statement coverage
• Block coverage
• Conditional/Expression coverage
• Branch/Decision coverage
• Toggle coverage
• FSM coverage

Statement/line coverage:
 This gives an indication of how many statements (lines) are covered in the
simulation, by excluding lines like module, endmodule, comments, timescale etc.
 This is important in all kinds of design and has to be 100% for verification closure.
 Statement coverage includes procedural statements, continuous assignment
statements, conditional statement and Branches for conditional statements etc.

Statement/line coverage Example:
Example:
always @(posedge clock)
begin
if(x == y) => Statement 1
out1 = x+y; => Statement 2
else => Statement 3
out1 = x; => Statement 4
end

Block coverage:
 A group of statements which are in the begin-end or if-else or case or wait or while
loop or for loop etc. is called a block.
 Block coverage gives the indication that whether these blocks are covered in
simulation or not.
Example: always @(posedge clock)
begin => Block 1[always block]
if(x == y) Block 2
out1 = x+y;
else => Block 3
out1 = x;
end

Conditional/Expression Coverage:
 This gives an indication how well variables and expressions (with logical operators)
in conditional statements are evaluated.
 Conditional coverage is the ratio of number of cases evaluated to the total number
of cases present.
 If an expression has Boolean operations like XOR, AND ,OR as follows, the entries
which is given to that expression to the total possibilities are in dictated by
expression coverage.
Example: out = (x xor y) or (x and z);
 In this example, tool analyzes the RHS of the expression and counts how many
times it has been executed. All the possible cases would be available as truth table
and uncovered expression can be easily identified from the table.

Branch/Decision Coverage :
 In this, conditions like if-else, case and the ternary operator (?: ) statements are
evaluated in both true and false cases.
Example:
always @(posedge clock)
begin
if(x == y) => Branch 1
out1 = x+y;
else => Branch 2
out1 = x;
end

Toggle Coverage:
 Toggle coverage gives a report that how many times signals and ports are toggled
during a simulation run.
 It also measures activity in the design, such as unused signals or signals that
remain constant or less value changes.

State/FSM Coverage:
 FSM coverage reports, whether the simulation run could reach all of the states and
cover all possible transitions or arcs in a given state machine.
 This is a complex coverage type as it works on behavior of the design, that means
it interprets the synthesis semantics of the HDL design and monitors the coverage
of the FSM representation of control logic blocks.
 By default, every tool disables the code coverage and user can do as per the need.
 Enabling code coverage is overhead for simulation.
 So it is recommended not to enable code coverage during your test development,
and do it during your regression run only.

Differences Between code coverage and
functional coverage:

What is cover group?
 System Verilog cover group is user-defined type that encapsulates the
specification of a coverage model.
 They can be defined once and instantiated multiple times at different places via
new function.
 Cover group can be defined in either a package, module, program, interface, or
class and usually encapsulates the following information:
• A set of coverage points
• Cross coverage between cover points
• An event that defines when the cover group is sampled

Cover Group Example:
Example_1:
covergroup cov_grp;
cov_p1: coverpoint a;
Endgroup
cov_grp cov_inst = new();
cov_inst. Sample();
In this clocking, event specifies the event at which coverage points are sampled.
Example_2:
covergroup cov_grp @(posedge clk);
cov_p1: coverpoint a;
endgroup
cov_grp cov_inst = new();
In the example-2 coverage, sampling is triggered by calling a built-in sample() method.

What is cover point?
 A cover group can contain one or more cover points.
 A cover point specifies an integral expression that is required to be covered.
 Evaluation of the cover point expression happen when the covergroup is sampled.
 The sv coverage point can optionally labeled with a icon “:” .
Example:
covergroup cg @(posedge clk);
c1: coverpoint addr;
c2: coverpoint wr_rd;
endgroup : cg

What is bins?
 A bins is a Sv keyword. It is used to store integral numbers.
 The bins for a coverage point can be automatically created by System Verilog or explicitly
defined using the bins construct to name each bin.
 Bins are explicitly declared within curly braces { } along with the bins keyword followed by bin
name and variable value/range, immediately after the coverpoint identifier.
Example:
coverpoint addr { bins b1 = {0,2,7}; //bin “b1” increments for addr = 0,2 or 7
bins b2[3] = {11:20}; //creates three bins b2[0],b2[1] and b2[2].and The 10 possible values
are distributed as follows: (11,12,13),(14,15,16) and (17,18,19,20) respectively.
bins b3 = {[30:40],[50:60],77}; //bin “b3” increments for addr = 30-40 or 50-60 or 77
bins b4[] = {[79:99],[110:130],140};//creates three bins b4[0],b4[1] and b4[2] with values
79-99,110-130 and 140 respectively
bins b5[] = {160,170,180}; //creates three bins b5[0],b5[1] and b5[2] with values 160,170
and 180 respectively
bins b6 = {200:$}; //bin “b6” increments for addr = 200 to max value i.e., 255.
bins b7 = default;} //catches the values of the coverage point that do not lie within any of
the defined bins.
endgroup

Automatic Bins or Implicit Bins:
 An automatically single bin will be created for each value of the coverpoint variable
range. These are called automatic, or implicit, bins.
 For an “n” bit integral coverpoint variable, a 2^n number of automatic bins will get
created.
Example:
c1: coverpoint addr; //addr 8bit
c2: coverpoint wr_rd; //wr_rd 1bit
endgroup : cg
The bins, will get created automatically,
for addr: c1.auto[0] c1.auto[1] c1.auto[2] … c1.auto[255]
for wr_rd: c2.auto[0] c2.auto[1]

Explicit bins:
 A separate bin is created for each value in the given range of variable or a single/multiple bins for
the rage of values.
 Bins are explicitly declared within curly braces { } along with the bins keyword followed by bin name
and variable value/range, immediately after the coverpoint identifier.
Example: coverpoint addr { bins b1 = {0,2,7}; //bin “b1” increments for addr = 0,2 or 7
bins b2[3] = {11:20}; //creates three bins b2[0],b2[1] and b2[2].and The 10 possible values
are distributed as follows: (11,12,13),(14,15,16) and (17,18,19,20) respectively.
bins b3 = {[30:40],[50:60],77}; //bin “b3” increments for addr = 30-40 or 50-60 or77
bins b4[] = {[79:99],[110:130],140};//creates three bins b4[0],b4[1] and b4[2] with
values 79-99,110-130 and 140 respectively
bins b5[] = {160,170,180}; //creates three bins b5[0],b5[1] and b5[2] with values 160,170
and 180 respectively
bins b6 = {200:$}; //bin “b6” increments for addr = 200 to max value i.e., 255.
bins b7 = default;} //catches the values of the coverage point that do not lie within any
of the defined bins.
endgroup : cg

Bins for transitions:
 The transition of coverage point can be covered by specifying the sequence,value1 =>
value2.
 It represents transition of coverage point value from value1 to value2.
Example:
coverpoint addr{ bins b1 = (10=>20=>30); // transition from 10->20->30
bins b2[] = (40=>50),(80=>90=>100=>120); // b2[0] = 40->50 and b2[1] =
80->90->100->120
bins b3 = (1,5 => 6, 7);} // b3 = 1=>6 or 1=>7 or 5=>6 or 5=>7
endgroup

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.
Example:
c1: coverpoint addr{ ignore_bins b1 = {6,60,66};
ignore_bins b2 = (30=>20=>10); }
endgroup : cg

Illegal 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.
Example:
c1: coverpoint addr{ illegal_bins b1 = {7,70,77};
ignore_bins b2 = (7=>70=>77);}
endgroup : cg

Cross Coverage:
 Cross Coverage is specified between the cover points or variables. Cross coverage
is specified using the cross construct.
 Expressions cannot be used directly in a cross; a coverage point must be explicitly
defined first.
Example1: Cross coverage by cover_point name:
bit [3:0] a, b;
c1: coverpoint a;
c2: coverpoint b;
c1Xc2: cross c1,c2;
endgroup : cg

Cross Coverage:
Example2: Cross coverage by the variable name:
bit [3:0] a, b;
covergroup cov @(posedge clk);
aXb : cross a, b;
endgroup
In this example, each coverage point has 16 bins, namely
auto[0]…auto[15].
The cross of a and b (labeled aXb), therefore, has 256 cross products,
and each cross product is a bin of aXb.

Cross Coverage:
Example3:Cross coverage between variable and expression:
bit [3:0] a, b, c;
covergroup cov @(posedge clk);
BC : coverpoint b+c;
aXb : cross a, BC;
endgroup

Conditional coverage:
 In Sv, we have 2 ways to conditionally enable the coverage.
• By using iff condition.
• By use start and stop functions.
Example: iff condition:
covergroup CovGrp;
coverpoint mode iff (!_if.reset) {
// bins for mode
}
endgroup

Conditional coverage:
Example: start and stop functions:
CovGrp cg = new;
initial begin
#1 _if.reset = 0;
cg.stop ();
#10 _if.reset = 1;
cg.start();
end

Limitations of code coverage:
 Code coverage is an important indication for the verification engineer on how well
the design code has been executed by the tests.
 But it does not know anything about the design and what the design is supposed
to do.
 There is no way to find what is missing in the RTL code, as code coverage can only
tell quality of the implemented code.
 Non-implemented features cannot be identified.
 Not possible to indicate whether all possible values of a feature are tested.
 Unable to say how well the logic has been covered, it can only say whether each
statement/block etc has been executed.
 Hence code coverage does not ensure verification completeness. Both functional
coverage and code coverage have to be 100% to make verification closure.

Limitations of functional coverage:
 This is only as good as the code written for it.
 Say you have 10 features mentioned in the design document, and you somehow
overlooked/missed or were not aware of 3 features, you'll write functional
coverage code for only 7 of them.
 And if all the 7 have been hit in the tests, you might come to the conclusion that all
the features are covered.
 So, you need to make sure that all the required information from the design
specification is included in the functional coverage block.

System verilog coverage

Recommended

More Related Content

What's hot (20)

Similar to System verilog coverage (20)

Recently uploaded (20)

System verilog coverage