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.

123456789

always @(posedge clock) begin if(x == y) begin => Statement 1out1 = x+y; => Statement 2out2 = x^2 + y^2; => Statement 3else => Statement 4out1 = x; => Statement 5out2 = y; => Statement 6end

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 if(x == y) begin => State out1 = x+y; => State

123456789

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.

1 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.

123456789

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

always @(posedge clock) begin => Block 1 [ if(x == y) begin => Block out1 = x+y;

out = (x xor y) or (x and z);

always @(posedge clock) begin if(x == y) begin => Bran out1 = x+y;

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 design’s 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.

VHDL’s 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.

Don’t 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.