CODE COVERAGE

Code Coverage It is a process of validating or finding the quality of the test bench for RTL code for a particular design. This is a measurement which tells how good the design has been exercised with the test bench / test cases.
Code coverage is applied to DUT (Design under Test) to check how thoroughly the HDL exercised by test suite. Code coverage points the portion of code which did not exercised, it also points the corner/edge cases, unused/dead code.
There are varieties of tools available in the market for code coverage. Models (From Mentor Graphics) and ICC (From Cadence) are some examples of those.
With out code coverage tools designer can only say the simulation output is the expected one or not. But he will not know whether he needs more test cases or not. With help of code coverage it is very easy to know how well the HDL code exercised. From the code coverage result it is easy to determine how more TCs needed for a complete test.
Well, what are the things to be checked during code coverage? Or what are the types of code coverage? Following text describes the types of coverage which are applied together or separately. There will be a possibility to enable or disable any one particular type of the coverage during the process.
Block coverage - When block coverage enabled the tool monitors all exercisable blocks in the HDL code. Block is a statement or sequence of statements that executes with no branches and delays. Assume there are 100 blocks in one design but only 75 blocks are exercised with test suite then the block coverage is 75%. So it is sure that the design needs more test cases to exercise the complete logic.
Branch coverage- In a 'case' or 'if-else' there may be more the one branch in the design. Test case should exercise all branches for the completeness. Often some cases in a case statement of else part of 'if-else' statement will be missed. Branch coverage will identify those errors. A snippet of code considered 100% covered with branch coverage when all the branches of code executed at least once. Some time it is referred as decision coverage. Branch coverage also applied to case statements, like the following:
In this example, branch coverage will identify whether each of the three branches of the Case statement is taken.
case (z)
1 : x=0;
2 : x=10;
3 : x=20;
endcase
Condition coverage - Some tools support this feature. This is an extension of branch coverage. Condition coverage breaks down branch conditions into the elements that make the result true or false. If there are any conditions in an ‘if’ statement are missed during executing then the tool will notify.
Statement coverage - It count all executable statements in a code and makes ratio of unexecuted statement during the current simulation. Executable statements are those that have a definite action during runtime and do not include comments, compile directives or declarations. At end of this document there is a worked example for this type of coverage.
Variable coverage - Multi bit variables are monitored in this coverage. It allow to track toggles, range and values on vector (more than one bit) variables
FSM coverage - Finite state machine coverage, it helps to analyze variety of styles of state machine written in RTL.
Expression coverage - Expression coverage brings statistics for all expressions in the HDL code. Expression can be continues or procedural assignments. It identifies the expressions which are not sufficiently exercised.
Toggle coverage - A design includes various objects like bit, reg, wire, signals. These objects might or might not change during simulation run. Toggle coverage measures these signals' activities. It is very useful in gate level testing. It also gives approximate power consumption of the circuit.
Example for code coverage.
There are two modules,
mux.v - This is DUT, it is a 4 to 1 mux.
tb_mux.v - Test bench for mux which generates test vectors for DUT. The quality of this test bech for DUT is going to be checked now.

module mux (sel_a,sel_b,data_4bit,out);
input sel_a;
input sel_b;
input [3:0] data_4bit;
output out;
reg out;
always @ (sel_a or sel_b or data_4bit)begin case ({sel_a,sel_b}) 2'b00 : out <= data_4bit[0];
2'b00 : out <= data_4bit[1];
2'b00 : out <= data_4bit[2];
2'b00 : out <= data_4bit[3];
default : out <= 1'b0;
endcaseendendmodule

module tb_mux;
reg sel_a;
reg sel_b;
reg [3:0]data_4bit;
wire out;
initial
begin
data_4bit = 4'b1001;
// input set 1
sel_a = 1'b0;
sel_b = 1'b0;
// input set 2
sel_a = 1'b0;
sel_b = 1'b1;
// input set 3
sel_a = 1'b1;
sel_b = 1'b1;
// input set 4
sel_a = 1'b1;
sel_b = 1'b0;
// input set 5
sel_a = 1'bx;
sel_b = 1'bx;
end
mux dut (.sel_a(sel_a),
.sel_b(sel_b),
.data_4bit(data_4bit),
.out(out));
Endmodule
Since this example is just to get an idea about code coverage only statement coverage is enabled. Other coverage options can be enabled if it is needed.
Run 1
For the first run input set 1,2 and 3 are enabled 4 and 5 are disabled (disable in the sense comment the lines under the input set 4 and input set 5). For this run the code statement coverage is only 71.4%. How this is calculated

Code Coverage runs one
In the above figure, there are two status bars for two modules. tb_mux and dut. Measuring code coverage for test bench is not important. Only the DUT has to be checked thoroughly for it is functionality that is the job of TB. So in the above picture don’t worry about tb_mux. Our interested module is DUT and it shows 71.4%. The number of executable line in the DUT is 7. Current inputs from test bench exercises only 5 statements. So 5/7 * 100 = 74.1%

Code Coverage run one Code
Above figure shows the missing statements the case items 2'b10 and default. It is clear that the design is not tested completely. So the test bench has to be improved.
Run 2
For the second run input set 1,2,3 and 4 are enabled, 5 is disabled. For this run the code statement coverage is 85.7%.
Code Coverage run two
Calculation for second run 6/7 * 100 = 85.7%. See the following diagram for more details
Code Coverage run two Code
Run 3
For the third run all input sets 1 to 5 are enabled in the test bench. For this run the code statement coverage is 100%.
Code Coverage run three
Note that for some complex design it may not be possible to bring 100% for all types of coverage.