Verification

Code Coverage Fundamentals

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.

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.

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.

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.

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

16 Comments

16 Comments

  1. junghanChoi

    July 10, 2015 at 4:04 pm

    Thank you for your post.

  2. muthukumar

    October 13, 2015 at 3:17 am

    Thanks for your post

  3. Tarun

    April 13, 2016 at 9:17 am

    Very good post

  4. ALALA

    April 15, 2016 at 4:58 pm

    Thank u god

  5. Lakshmana

    June 30, 2016 at 8:18 am

    Thanks much for detailed explanation.

  6. kumar

    September 2, 2016 at 2:51 pm

    Is there any tool which calculates these code coverage metrics given the RTL code?

    • mm

      Sini Balakrishnan

      September 14, 2016 at 12:03 pm

      Yes. All simulation tool does. For example Incisive (From Cadence). It needs switches to enable different types of coverage like branch, fsm etc.

  7. Sandeep

    October 10, 2016 at 8:33 pm

    How can I turn off a coverage in IMC on a net declared as a wire in my verilog code?

    • vk

      January 3, 2017 at 12:50 pm

      Hi Sandeep

      Did you get the solution for disabling toggle coverage for nets ?

  8. Amit Pai

    October 31, 2016 at 12:30 pm

    Thank you Sini mam

  9. Nayan

    January 4, 2017 at 10:09 pm

    Thanks for the valuable Information

  10. Mitesh Patel

    May 11, 2017 at 6:15 pm

    as per above documentation, i think code coverage is written in DUT (design file). please correct me if i am wrong

  11. Pushpak

    September 30, 2017 at 8:00 pm

    Thank you for this well written article.

  12. Phong Nguyen

    November 14, 2017 at 11:29 am

    It is very useful

    • kamesh

      December 28, 2017 at 2:01 am

      how to exclude few hiearchy instances and reserved fields during code coverage?

Leave a Reply

Your email address will not be published. Required fields are marked *

Most Popular

VLSI Pro is a professional network of VLSI engineers. Here you can find latest news, helpful articles and more on VLSI technology.

Copyright © 2016 VLSI Pro

To Top