Blog: FirstEDA Verification Series – Code Coverage

Code Coverage: An Introduction
—

FirstEDA Verification Series – our technical team and partners are collaborating on a number of informative articles covering the essentials. Our objective is to provide bite-sized insights on important topics such as code coverage, assertions, OSVVM, design rule checking and formal methods.

As an important step in a metric driven verification process, code coverage provides a structural level check on the effectiveness of your tests. By collecting simulation data on the execution of each line of VHDL or Verilog, it can quickly highlight areas of your code that are not exercised.

By analysing the source code during simulation, detailed coverage data can be logged and then reported in a meaningful manner. Where coverage ‘holes’ exist, it normally indicates incomplete tests or unused code. As all untested code could contain bugs, they should be investigated.

Reflecting the underlying structure of HDLs, there are a number of code coverage classes that are of interest: statement, branch, condition & expression, toggle, path & FSM. Access to these is tool dependent – our Aldec simulators (Active-HDL & Riviera-PRO) provide full support!

Statement and branch are the most basic and I will be covering these in more detail in subsequent articles.

The reality is that 100% code coverage for any given design may be impractical due to hard constraints. Accordingly, the results can still be used as a ‘verification advisor’, guiding a design review to determine:

1. Is higher coverage achievable with further tests?
2. Is the uncovered code redundant i.e. can it be removed?
3. Are the lower coverage results acceptable in the context of the design?

Ultimately, it’s for the design engineer, in conjunction with the verification engineer (if the roles are separated), to determine the sign-off criteria.

A simplified flow appears below (fig.1).

Fig1. Coverage analysis block diagram

As you can imagine, certain HDL constructs such as ‘if’ or ‘case’ embedded in statements or branches have a major bearing on the coverage results if they are not executed exhaustively. The same applies for condition and toggle coverage, where all subexpression combinations in complex branches needs to be exercised.

This is illustrated in the table below (fig.2), a representative breakdown for a first run.

Fig2. Example Summary of possible Initial Coverage Type results not reaching 100%

That’s the overview complete. In the next article I will be digging into statement coverage in more detail.

We trust that you find these articles of interest. We’d be delighted to receive any (constructive!) feedback and please don’t hesitate to contact support@firsteda.com with any questions.

Thank you for your attention!