1
\$\begingroup\$

It seems that verifying a design is a more complex task than the actual design itself and takes a lot longer to carry out. We may even need to create testbench to very the original testbench that tests the DUT.

Anyway, there does seem to be a lot of terminology involved in this as well and at this point I only wish to know what is code coverage and especially functional coverage. These terms are also used with reference to SystemVerilog that I am trying to read about.

Edit:

Just one more question here. What is a "configuration" in systemverilog? The book says "Generate configuration : Randomize the configuration of the DUT and the surrounding environment." What does that mean?

\$\endgroup\$

2 Answers 2

3
\$\begingroup\$

Code coverage is a metric that tells you if you have executed each line of code in the implementation of your design. There are a number of other metrics for code coverage that tools can easily calculate for you non-intrusively (e.g has each single toggled to their true and false states). The theory is that you could not have tested code that was never executed. But code coverage does not tell you anything about the correctness of the code that executed. Therefore it is a necessary but insufficient verification metric.

Functional coverage is a metric that tells you if you have tested all the required functionality of a design. Supposedly when someone sits down to create a design, they have a specification that lists all the feature that the design needs to provide. There are a number of ways to collect functional coverage data, but typically you need to track a test for each feature or set of features, and that the test succeeded to mark a feature as functionally covered. No knowledge of the implementation of the design is needed.

You may want to look at our Coverage Cookbook for more information.

\$\endgroup\$
1
\$\begingroup\$

Code coverage means that you have verified all of the lines of code in the design. For example, if there is an if statement, you have checked both branches.

Functional coverage is where you have verified all of the scenarios that the design is to be used. These scenarios are generally from a user or a system point of view.

Just to give another point of view, these are similar to white-box testing vs. black-box testing.

White-box testing (also called clear-box testing) is where you know about the internals of the design, and are testing everything from this point of view. One form of this is code coverage testing.

Black-box is where the tester/test doesn't know the internals and is trying to determine if the design is meeting design specifications from a user point of view. This is functional testing.

\$\endgroup\$
4
  • \$\begingroup\$ So functional testing has to do with the possible scenarios that the design shall be used in. Thus the % if functional coverage is actually subjective? There is a certain type of coverage in which we see how much % of logic in the design netlist was exercised by the testbench. What is this type of coverage called? \$\endgroup\$
    – quantum231
    Commented Feb 17, 2015 at 20:18
  • 1
    \$\begingroup\$ The netlist can be considered a form of code, so it is very similar to the idea of code coverage testing. \$\endgroup\$
    – caveman
    Commented Feb 17, 2015 at 23:08
  • 1
    \$\begingroup\$ Functional testing is supposed to be testing through the functional requirements specification of the design. If this document is complete and unambiguous, it is not subjective at all. :) \$\endgroup\$
    – caveman
    Commented Feb 17, 2015 at 23:14
  • 3
    \$\begingroup\$ Code coverage does not mean you have verified anything - only that you have executed the code \$\endgroup\$
    – dave_59
    Commented Feb 18, 2015 at 4:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.