Coverage is a metric to assess the progress of functional verification activity.

This plays a
major role to get a clear picture on how well the design has been verified and also to identify
the uncovered areas in verification.
Code coverage and functional coverage are the two types of coverage methods used in
functional verification.
Code coverage is a basic coverage type which is collected automatically. It tells you how well
your HDL code has been exercised by your test bench. In other words, how thoroughly the
design has been executed by the simulator using the tests used in the regression.
Functional coverage measures how well the functionality of the design has been covered by
your test bench. In functional coverage user has to define the functionality to be measured
through coverage.
There are different categories of code coverage.

Statement coverage
Block coverage
Conditional/Expression coverage
Branch/Decision coverage
Toggle coverage
FSM coverage

Statement Coverage /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.
always @(posedge clock)
begin
if(x == y) begin
=> State
out1 = x+y;
=> State

1
2
3
4
5
6
7
8
9

always @(posedge clock)

begin
if(x == y) begin => Statement 1
out1 = x+y; => Statement 2
out2 = x^2 + y^2; => Statement 3
else => Statement 4
out1 = x; => Statement 5
out2 = y; => Statement 6
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. The nature of the block coverage & line coverage looks
similar. Block coverage looks for a group of statements called block and line
coverage/statement coverage checks whether each statement is covered. The dead-code in
design code can be found by analyzing block coverage.

always @(posedge clock)

begin
=> Block 1 [
if(x == y) begin
=> Block
out1 = x+y;

1
2
3
4
5
6
7
8
9

always @(posedge clock)

begin => Block 1 [always block]
if(x == y) begin => Block 2 [If block]
out1 = x+y;
out2 = x^2 + y^2;
else => Block 3 [Else block]
out1 = x;
out2 = y;
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 indicated by expression coverage.
out = (x xor y) or (x and z);

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 Branch coverage or Decision coverage reports, conditions like if-else, case and the ternary
operator (?: ) statements are evaluated in both true and false cases.
always @(posedge clock)
begin
if(x == y) begin
=> Bran
out1 = x+y;

1
2
3
4
5
6
7
8
9

always @(posedge clock)

begin
if(x == y) begin => Branch [If branch]
out1 = x+y;
out2 = x^2 + y^2;
else => Branch [Else branch]
out1 = x;
out2 = y;
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 behaviour 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.
To enable code coverage in Incisive, give -coverage all option to irun. You can also specify
which type is required as follows
-coverage block:fsm
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.
1. Non-implemented features cannot be identified.
Missing feature cannot be identified by code coverage as it only look into design code and
does not know the functionality of the design.
2. Not possible to indicate whether all possible values of a feature are tested.
For example code coverage cannot report whether all legal combination of states are executed
by the tests. Another example is, generate packets using randomization with all possible
lengths. code coverage cannot identify whether all possible lengths are evaluated in
simulation or not.
3. Unable to say how well the logic has been covered, it can only say whether each
statement/block etc has been executed
4. Code coverage does not look into the sequences of events which is happened before, after
or during the line of code 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.

Code coverage and Functional coverage comparison

Which is important Functional or Code Coverage?

Code coverage is a measure of quality of RTL code execution while simulating the test-cases.
Functional coverage measure how well the design functionality have been covered by the
tests during simulation. That means it is an indicator of designs functional state.
Functionality is defined using coverage groups and points. The functional coverage metric is
very subjective, so to improve the quality of functional coverage report, quality of functional
coverage points and its implementation have to be improved.
So both code coverage and functional coverage are equally important in verification. That
means, even if you have 100% code coverage, but functional coverage is not 100%,
verification is not complete. If you have 100% functional coverage without 100% code
coverage, either you have unnecessary code lying around or functional coverage is measured
wrong.
Verification completeness can be achieved with proper functional coverage goals and also
with 100% code & functional coverage.
These coverage goals will give the measure of completeness of verification.
Code coverage: This will give information about how many lines are exected, how many
times expressions, branches executed. This coverage is collected by the simulation tools.
Users use this coverage to reach those corner cases which are not hit by the random testcases.
Users have to write the directed testcases to reach the missing code covearage areas.
Functional coverage: This coverage will be defined by the user. User will define the coverage
points for the functions to be covered in DUT. This is completly under user control.
Both of them have equal importance in the verification. 100% functional coverage does not
mean that the DUT is completly exercised and vice-versa. Verification engineers will
consider both coverages to measure the verifcation progress.
Functional Coverage Tracks Your Test Plan

Functional coverage is code that observes execution of a test plan. As such, it is code you
write to track whether important values, sets of values, or sequences of values that correspond
to design or interface requirements, features, or boundary conditions have been exercised.
Functional coverage is important to any verification approach since it is one of the factors
used to determine when testing is done. Specifically, 100% functional coverage indicates that
all items in the test plan have been tested. Combine this with 100% code coverage and it
indicates that testing is done.
Functional coverage that examines the values within a single object is called either point
(SystemVerilog) or item (e) coverage. I prefer the term item coverage since point can also
be a single value within a particular bin. One relationship we might look at is different
transfer sizes across a packet based bus. For example, the test plan may require that transfer
sizes with the following size or range of sizes be observed: 1, 2, 3, 4 to 127, 128 to 252, 253,
254, or 255.
Functional coverage that examines the relationships between different objects is called cross
coverage. An example of this would be examining whether an ALU has done all of its
supported operations with every different input pair of registers.
Many think functional coverage is an exclusive capability of a verification language such as
SystemVerilog. However, functional coverage collection is really just a matter of
implementing a data structure.
VHDLs Open Source VHDL Verification Methodology (OSVVM) provides a package,
CoveragePkg, with a protected type that facilitates capturing the data structure and writing
functional coverage.
Code Coverage is not enough
VHDL simulation tools can automatically calculate a metric called code coverage (assuming
you have licenses for this feature). Code coverage tracks what lines of code or expressions in
the code have been exercised.
Code coverage cannot detect conditions that are not in the code. For example, in the packet
bus item coverage example discussed above, code coverage cannot determine that the
required values or ranges have occurred unless the code contains expressions to test for
each of these sizes. Instead, we need to write functional coverage.
In the ALU cross coverage example above, code coverage cannot determine whether
particular register pairs have been used together, unless the code is written this way.
Generally each input to the ALU is selected independently of the other. Again, we need to
write functional coverage.
Code coverage on a partially implemented design can reach 100%. It cannot detect missing
features (oops forgot to implement one of the timers) and many boundary conditions (in
particular those that span more than one block). Hence, code coverage cannot be used
exclusively to indicate we are done testing.
In addition, code coverage is an optimistic metric. In combinational logic code in an HDL, a
process may be executed many times during a given clock cycle due to delta cycle changes

on input signals. This can result in several different branches of code being executed.
However, only the last branch of code executed before the clock edge truly has been covered.
Test Done = Test Plan Executed and All Code Executed
To know testing is done, we need to know that both the test plan is executed and all of the
code has been executed. Is 100% functional coverage enough?
Unfortunately a test can reach 100% functional coverage without reaching 100% code
coverage. This indicates the design contains untested code that is not part of the test plan.
This can come from an incomplete test plan, extra undocumented features in the design, or
case statement others branches that do not get exercised in normal hardware operation.
Untested features need to either be tested or removed.
As a result, even with 100% functional coverage it is still a good idea to use code coverage as
a fail safe for the test plan.
Why You Need Functional Coverage, even with Directed Testing
You might think, I have written a directed test for each item in the test plan, I am done
right?
As design size grows, the complexity increases. A test that completely validates one version
of the design, may not validate the design after revisions. For example, if the size of a FIFO
increases, the test may no longer provide enough stimulus values to fill it completely and
cause a FIFO Full condition. If new features are added, a test may need to change its
configuration register values to enable the appropriate mode.
Without functional coverage, you are assuming your directed, algorithmic, file based, or
constrained random test actually hits the conditions in your test plan.
Dont forget the engineers creed, In the divine we trust, all others need to show supporting
data. Whether you are using directed, algorithmic, file based, or constrained random test
methods, functional coverage provides your supporting data.