Code and Functional Coverage - Why Both?

The Quality of Verification is measured through "Coverage". Lets understand why coverage than what is coverage? Generally, when we verify the DUT, we build test cases and run all possible test scenarios on the DUT, but how to prove that we have verified the DUT thoroughly? So here comes the term "Coverage". Coverage is the measurement of how much of the Design functionality exercised by the verification environment. In simple terms, its a way proving others that you have verified all the functionality and exercised all the codes of the DUT using the verification environment.

EDA Tools:

• ICCR ( Cadence)
• ModelSim (Mentor Graphics)

Coverage can be divided into two:

• Code Coverage
• Functional Coverage

RTL verification is said "completed" when we get (98-100)% Code coverage and 100% Functional Coverage.

Code coverage is further divided into

• Block Coverage
• Expression Coverage
• FSM Coverage
• Toggle Coverage

The term Functional Coverage is the measurement of functionality exercised by the verification environment and the term Code Coverage is the measurement of how much of the Design code exercised using the verification environment. It is very important to have good Code and Functional Coverage. Note it I have written good Code and Functional Coverage. So your next question is why Both? Lets have detailed understanding of why both Functional and Code coverage which was the main intent of this topic. Functional coverage alone is not enough to prove verification completion as with few test cases you can easily exercise the functionality of the design but whether you have exercised all the lines/branch/condition/FSM/Toggles of the Design using verification environments is determined through Code Coverage. Functionality of the design can be checked , but code coverage measures how good is your test environment.

Example for Code coverage: DUT (4:1 Mux )

module four_mux ( a, b, c, d, Sel_a, Sel_b , Out );
input a, b, c, d, Sel_a, Sel_b ;
output Out ;
reg Out ;
always @ ( a, b, c, d, Sel_a, Sel_b)
begin
case (Sel_a, Sel_b)
2'b00 : Out <= a; 2'b01 : Out <=b; 2'b10 : Out <=c; 2'b11 : Out <= d; default : Out <= 1'b0; endcase end endmodule

Test Case to verify 4:1 Mux

module tb_four_mux ;
reg a, b, c, d, Sel_a, Sel_b ;
wire Out ;
initial begin
a = 1'b0 ;
b = 1'b1 ;
c = 1'b0 ;
d = 1'b1 ;
// Input Combination 0
Sel_a = 1'b0 ;
Sel_b = 1'b0;
//Input Combination 1
Sel_a = 1'b0 ;
Sel_b = 1'b1 ;
//Input Combination 2
Sel_a = 1'b1 ;
Sel_b = 1'b0 ;
//Input Combination 3
Sel_a = 1'b1;
Sel_b = 1'b1;
//Input Combination X
Sel_a = 1'bx ;
Sel_b = 1'bx ;
end

//Instantiate the DUT in test bench environment
four_mux four_mux_instantiate ( .a (a),
.b (b),
.c (c),
.d (d),
.Sel_a (Sel_a),
.Sel_b (Sel_b),
.Out (Out)
);
endmodule

Let us assume that input combination x is not written in test case. So now the input combination 0, 1, 2, 3 hits the functionality of the DUT,

always @ ( a, b, c, d, Sel_a, Sel_b)
begin case ( Sel_a, Sel_b )
2'b00 : out <= a ;
2'b01: out <= b ;
2'b10: out <= c;
2'b11: out <= d;
default : out <= 1'b0 ;
endcase
end

So, depending upon the Sel_a and Sel_b, the particular input would be driving the output which is the functionality of the Mux. So, if Sel_a and Sel_b equals to 0, input a Out, when Sel_a and Sel_b equals to 1, input b would be driving the Out, when Sel_a and Sel_b equals to 2, input c would be driving the Out and when Sel_a and Sel_b equals to 3, input d would be driving Out. This is the functionality of the Design MUX. With the test input combination 0, 1 , 2 and 3 we check the functionality of the mux and we get 100% Functional Coverage but we have not exercised the statement default so our code coverage would be 85.75% (6/7 * 100). So with the code coverage percentage, we understand that we have not exercised certain Condition or codes of the Design. We improve our test environment to check whether our test case hits the default statement. Through this we get 100% code coverage and a proof that we have verified the RTL thoroughly.

Coverage obtained through Assertion is always Functional Coverage as we check the property of the Design. Code Coverage is checking how good is your testcase and how much RTL is exercised.

So, we conclude that Verification is DONE when we hit 100% Functional and Code Coverage.

About Author:
Jeyanthi Arumugam
Senior Design Engineer in Freescale, Noida

URL: http://vlsi-core.blogspot.com/2008/12/code-and-functional-coverage-why-both.html