|
|
|
|
|
|
|
|
|
|
|
Introduction
|
|
|
Traditionally quality of verification was measured with help of code coverage tool. Code coverage reflects how thorough the HDL code was exercised. A code coverage tool traces the code execution, usually by instrumenting. 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?" |
|
|
|
|
|
Functional coverage was provied in Vera, Specman (E) and now in SystemVerilog. 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
|
|
|
Typically when we start documenting test cases in test plan document, we also start documenting functional coverage plan. So when we start coding testbench, we code coverage along testbench. Systemverilog language gives very good set of features that are useful in measuring coverage. |
|
|
|
|
|
There are 4 places where functional coverage points can be coded in a verification enviroment, and they can be classfied as |
|
|
|
|
|
- F1 : Functional coverage points are very near the randomization
- F2 : Functional coverage points are sampled at input interface of DUT
- F3 : Functional coverage points which sample internal DUT states
- F4 : Functional coverage points which sample output interface of DUT
|
|
|
|
|
|
Below figure shows all the 4 types. |
|
|
|
|
|
|
|
|
|
|
|
F1 Coverage points
|
|
|
These 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. There is problem with F1 type coverage points. Assume for some reason, BFM/Driver is not able to send randomizated object to DUT, even then functiona coverage gets updated. This is not acceptable. |
|
|
|
|
|
|
|
|
|
|
|
F2 Coverage points
|
|
|
These 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 points
|
|
|
These 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. I have rarely come across these kind of coverage points. Also with advent of SVA cover properties, I see little use of F3 functional coverage types. |
|
|
|
|
|
F4 Coverage points
|
|
|
These 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, |
|
|
|
|
|
Example : Coverage
|
|
|
|
|
|
1 //+++++++++++++++++++++++++++++++++++++++++++++++++
2 // DUT With Coverage
3 //+++++++++++++++++++++++++++++++++++++++++++++++++
4 module simple_coverage();
5
6 logic [7:0] addr;
7 logic [7:0] data;
8 logic par;
9 logic rw;
10 logic en;
11 //=================================================
12 // Coverage Group
13 //=================================================
14 covergroup memory @ (posedge en);
15 address : coverpoint addr {
16 bins low = {0,50};
17 bins med = {51,150};
18 bins high = {151,255};
19 }
20 parity : coverpoint par {
21 bins even = {0};
22 bins odd = {1};
23 }
24 read_write : coverpoint rw {
25 bins read = {0};
26 bins write = {1};
27 }
28 endgroup
29 //=================================================
30 // Instance of covergroup memory
31 //=================================================
32 memory mem = new();
33 //=================================================
34 // Task to drive values
35 //=================================================
36 task drive (input [7:0] a, input [7:0] d, input r);
37 #5 en <= 1;
38 addr <= a;
39 rw <= r;
40 data <= d;
41 par <= ^d;
42 $display ("@%2tns Address :%d data %x, rw %x, parity %x",
43 $time,a,d,r, ^d);
44 #5 en <= 0;
45 rw <= 0;
46 data <= 0;
47 par <= 0;
48 addr <= 0;
49 rw <= 0;
50 endtask
51 //=================================================
52 // Testvector generation
53 //=================================================
54 initial begin
55 en = 0;
56 repeat (10) begin
57 drive ($random,$random,$random);
58 end
59 #10 $finish;
60 end
61
62 endmodule
You could download file simple_coverage.sv here
|
|
|
|
|
|
In the example we have covergroup memory which basically gets sampled on every posedge of en, and it samples address for three ranges, parity for even and odd, and finally rw for read and write. |
|
|
|
|
|
Like a module/program/interface, coverage instance is created and a new() is done on it. Once this is done, at every posedge of en, all the samples are collected and stored in bins. |
|
|
|
|
|
Simulation : Coverage
|
|
|
|
|
|
@ 5ns Address : 36 data 81, rw 1, parity 0
@15ns Address : 99 data 0d, rw 1, parity 1
@25ns Address :101 data 12, rw 1, parity 0
@35ns Address : 13 data 76, rw 1, parity 1
@45ns Address :237 data 8c, rw 1, parity 1
@55ns Address :198 data c5, rw 0, parity 0
@65ns Address :229 data 77, rw 0, parity 0
@75ns Address :143 data f2, rw 0, parity 1
@85ns Address :232 data c5, rw 0, parity 0
@95ns Address :189 data 2d, rw 1, parity 0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|