Coverage
Coverage
Coverage
Lecture 11
Coverage
1/28/2013
Coverage types
Coverage is a generic term used to measure the progress of verifying a
design. Two types of Coverage Code and Functional
Code coverage:
Here you are measuring how many lines of code have been
executed(line coverage).
Which paths through the code and expressions have been
executed(path coverage)
Which states and transitions have been executed(FSM)
Single bit variable transitions from 0 or 1 (toggle coverage)
Most Simulators include a code coverage tool.
Code Coverage checks how accurately your tests exercised the
implementation of the design specifiacation and not the verification plan.
100% code coverage does not mean your design is completely verified
1/28/2013
Code Coverage
The code coverage tool will not catch mistakes you make
Suppose your design implementation is missing a feature from the
design specification. Code Coverage will not catch it.
Suppose you forget to implement the reset logic in your flop. Code
coverage will not catch it. It will report that every line in the code is
exercised.
module dff (
output logic q,
input logic clk, d, reset_low);
1/28/2013
Environment
Generator
Scoreboard
Driver
checker
Assertions
DUT
1/28/2013
monitor
Functional Coverage
test
Test
Functional Coverage
Functional Coverage tells you how much of the design is exercised.
If the design is exercised completely for all possible scenarios then
the coverage is 100%.
Create a test plan with the list of tests that are needed from the
design specification.
Look at the coverage results, then decide on what actions one
needs take in order to achieve 100% coverage
First action is to run the existing tests with more seeds to see if you
can achieve 100% coverage.
Next step is to write more constraints and see if that fulfils the
cause.
Write Directed tests only if absolutely necessary
1/28/2013
Coverage Convergence
For e.g. if we are looking at coverage metrics for processors
Did we cover all instructions
Did we cover all addressing modes
Did we cover all valid combinations of instructions and
addressing modes.
Functional Coverage
Verification Plan
Design Specification
design
Coverage
database
tests
Coverage
Analysis
Debug
pass
1/28/2013
Functional Coverage
You can see from the previous diagram you test for pass/fail
of a test.
Pass gives you the coverage analysis
Fail has no significance
Functional Coverage data is discarded if the test failed due to design
bug.
The Coverage data gives you the verification metrics and gives you a
measure of how many items in the verification plan is complete which
is based on the design specifications
If the design does not match the specifications then the coverage
values have no meaning.
Analyze coverage with multiple runs with different seeds, more
constraints, and directed tests if needed to achieve the coverage goal.
1/28/2013
covergroup
As we have seen before functional coverage starts with
writing of the verification plan from design specification
Then in SystemVerilog we write an executable version using
covergroup and cover points
covergroup construct is a keyword that encapsulates the
specification of a coverage model. It may include a clocking
event that samples values of variables and expressions which
are called cover points.
Cover groups are defined using the keyword covergroup and
endgroup.
A covergroup instance can be created using the new operator.
1/28/2013
covergroup
Coverage model definiton
Encapsulated in the covergroup construct defined by the user
Clocking events for sampling variables or expressions which are cover
points . This is done using the keyword coverpoint
Cross coverage between coverage points using keyword cross
Optional coverage options
SystemVerilog functional coverage enables
Variable and expression coverage as well as cross coverage
Automatic and/or user-defined coverage bins
Filtering conditions (illegal values, values to ignore, etc.)
Automatic coverage sample triggering by events and sequences
Dynamic query of coverage information via built-in methods
1/28/2013
10
covergroup
Syntax is
covergroup buslogic;
..
..
endgroup
buslogic bl;
bl = new;
1/28/2013
11
covergroup example
program test1(busifc.TB ifc)
class BusTransaction;
rand bit [31:0] data;
rand bit [3:0] port;
endclass
covergroup portdata
coverpoint bt.port;
// Measure coverage
endgroup
initial begin
BusTransaction bt;
portdata pd;
pd = new();
// Instantiate group
bt = new();
repeat (32) begin
// Run a few cycles
assert(bt.randomize);
// Create a transaction
ifc.cb.port <= bt.port;
// and transmit
ifc.cb.data <= bt.data;
// onto interface
pd.sample();
// Gather coverage
@ifc.cb;
// Wait a cycle
end end endprogram
1/28/2013
12
covergroup example
In this example a random transaction is created and driven to
the interface.
Testbench samples the value of the port field using the
portdata covergroup.
16 possible values, 32random transactions. Did your
testbench have enough coverage
vcs will generate a coverage report which gives you a
summary of your coverage.
If coverage does not satisfy your requirements then you can
rerun with a new seed value, add more constraints etc.
1/28/2013
13
1/28/2013
14
1/28/2013
15
Coverage bins
Bins can be created implicitly or explicitly
When you specifiy coverpoints if you do not specify any bins then
implicit bins are created.
In the example vcs file we were trying the coverage on each port
and since there are 16 ports it will automatically create 16 bins
The number of bins to be created can be controlled by using the
auto_bin_max parameter.
covergroup portdata
coverpoint bt.port;
{ option.auto_bin_max = 8; }
endgroup
In this case total bins created will be 8 half of 16 and 1 bin for
2 ports
1/28/2013
16
Coverage Bins
Explicit bin creation is the preferred way. Not all cover points
are of interest to the user so he can use explicit bins if he
knows exactly what he wants to cover. You can also name the
bins
covergroup portdata
coverpoint bt.port {
bins portzero = {0};
bins portone = {[1:5], 7};
bins porttwo = {6, [8:15]};
}
endgroup // portdata
17
Conditional Coverage
You can add the iff keyword to add a condition to the
coverpoint
covergroup portdata
coverpoint bt.port iff(!bus.if.reset)
endgroup
This way you can turn off cover for ports during reset
assuming reset is active high.
you can also use start and stop functions to turn on and off
cover.
Here is an example of that
1/28/2013
18
Conditional Coverage
initial begin
BusTransaction bt;
portdata pd;
pd = new();
// Instantiate group
bt = new();
#1 pd.stop();
//stop coverage
bus.if.reset = 1;
//start reset
#100 bus.ifi.reset = 0; //end reset
pd.start();
//start coverage
repeat (32) begin
// Run a few cycles
assert(bt.randomize); // Create a transaction
ifc.cb.port <= bt.port; // and transmit
ifc.cb.data <= bt.data; // onto interface
pd.sample();
// Gather coverage
@ifc.cb;
// Wait a cycle
end
end
1/28/2013
19
Covergroup range
You can use the $ to specify the upper limit if it is used to
specify the right side of the range to specify the upper limit
You can use the $ to specify the lower limit if it is used on the
leftside of the range to specify the lower limit
covergroup portdata
coverpoint bt.port {
bins portzero = {[$:5]};
bins portone = {[6,7]};
bins porttwo = {[8:$]};
}
endgroup // portdata
1/28/2013
20
In this case it will create a bin each for idle, decode and
data_transfer.
If you want to group multiple values into a single bin then
you have to define your bins just as we did before
1/28/2013
21
Transition Coverage
1/28/2013
22
1/28/2013
23
1/28/2013
24
class BusTransaction
rand bit [31:0] data; //random variables
rand bit [3:0] port; //16 possible ports
endclass
// Instantiate covergroup
task main;
forever begin
bt = tr_in.get;
ifc.cb.port <= bt.port;
ifc.cb.data <= bt.data;
portdata.sample();
end
endtask
endclass
1/28/2013
25