Code Coverage – Can we get a little help here?

Productivity boost from Condition and Path Coverage

Satyam Jani, Product Manager Software Division
Like(3)  Comments  (0)

Don’t get me wrong, coverage analysis has been used by engineers for years now and it usefulness in improving productivity and verification environment quality can’t be stressed enough. Code coverage, specifically popular statement and branch coverages, is already pretty awesome.

 

It’s the less talked about areas of code coverage, condition coverage and path coverage, that I’m talking about today. The latest release of Riviera-PRO™ 2015.06 offers a little help here in the form of both condition and path coverage for its UCIS-compatible coverage database.

 

Let’s talk about these coverage types, and they can enhance the coverage analysis process.

 

Condition Coverage

 

Condition coverage monitors and factorizes logical expressions used in conditional statements. This is considered as an extension to expression coverage, which factorizes logical expressions, but condition coverage monitors expressions that occur as a condition within constructs such as if, then, while, and so on.

 

Let’s consider following example, where you have following conditional expression in your code:

 

(ce = '1') = TRUE

 

When you run condition coverage on such code – it gives you following results.

 

Fig1: Condition Coverage Summary

 

Fig2: Condition Coverage Details

 

In the condition coverage report you will notice that there are two expressions that have been tested - (ce = '1') = TRUE and ce = '1'

 

For both of these expressions, it turns out that our test case is evaluating only 1 out of 2 possible cases. This is reflected in coverage summary table that shows that only 2 out of 4 coverage bins were covered. The total number of coverage bins corresponds to the number of rows displayed in all the truth tables for the given conditional expressions.

 

Now think about this, your statement coverage might tell you that this line has been covered but it does not give you full details if this expression was fully exercised for all the conditions.

 

Path Coverage

 

As we have pointed out above, Expression/Condition coverage shows more detail compared to statement coverage, similarly this holds true when analyzing path coverage data with branch coverage. Conditional statements like if-else and case create different paths for the stimulus to flow in your design. While branch coverage shows you the execution of branches, path coverage shows you the execution of the program paths and analyzes all possible sequences of program execution.

 

So what is a program path? It is a sequence of execution of conditional statements performed in a specific order. So basically Path Coverage collects information about in which order the consecutive statements are executed, the branches that are examined and how logical conditions evaluated during simulation.

 

Analysis of a path coverage report is not an easy task as it requires deeper understanding of a particular design. So for the purpose of this blog, let’s use a simple example.

 

Consider following sample code:

 

Fig3: Example Code

 

Here two conditional blocks are formed by if statements - Block1 (1) and Block2 (2). Each block has two branches, if returning true (T) and else returning false (F).

 

Typically when you force a=1, b=1 and a=0, b=0 – your statement/branch coverage will give you 100% coverage. Table below shows the path covered by these test.

Fig4: Program Path

 

But these two data sets allow testing only 2 (T1-T2 and F1-F2) of 4 possible paths (T1-T2, T1-F2, F1-T2, and F1-F2), meaning path coverage would be only 50%. The sample code is not tested with a=0, b=1 and a=1, b=0 which covers path F1-T2 and T1-F2. This means that statement/branch coverage would not detect the path leading to the divide-by-zero error, which occurs for a=0, b=1, i.e. for the F1-T2 path.

 

Now if your code contains more branches, then the total number of possible path combinations would skyrocket. For a simulation that has very large number of paths to analyze, it may be very difficult to create a complete set of test-vectors to examine all the paths. Using path coverage will allow you to analyze a subset of paths instead of verifying thousands of sub path combinations.

 

So in a nutshell – condition and path coverage adds more useful details to your coverage analysis allowing you to complete your verification process more confidently.

 

If you’d like to learn more, I invite you to explore our many online resources for Riviera-PRO, including Fast Track to Riviera-PRO, Part 1: Design Entry and Simulation, and Fast Track to Riviera-PRO, Part 2: Advanced Debugging, Code Coverage and Scripting.

 

To take a test drive, visit www.aldec.com/products/riviera-pro or contact sales@aldec.com.

Satyam manages Aldec’s leading FPGA design entry and simulation tool – Active-HDL. He received his B.S. in Electronics Engineering from Sardar Patel University, India in 2003 and M.S in Electrical Engineering from NJIT, New Jersey in 2005.  His practical engineering experience includes areas in Solid state electronics, Digital Designing and functional verification. He has worked in wide range of engineering positions that include FPGA Design Engineer, Applications Engineer and Product Manager.

  • Products:
  • Riviera-PRO
  • アドバンスベリフィケーション

Comments

Ask Us a Question
x
Ask Us a Question
x
Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.