FuncCov | Universal Verification Methodology

We listen now a days a keyword very frequently in Functional Verification i.e. “Functional Coverage“. In this post, we’ll try to understand ‘What is Functional Coverage’, its application and benefits. Before jumping to the functional coverage, lets have a quick recap of the existing functional verification measurement criteria.

As we all know that in traditional directed verification methodology, we used to measure the verification status by testcase pass/fail (functional correctness) & code coverage (which determines how much design code is exercised by the test scenarios generated by the Testbench). If we further classify code coverage, it comes into various different types e.g.

Line Coverage (which lines of code are exercised)
Toggle Coverage (monitors signal’s value changes from 0 to 1 and from 1 to 0)
Condition Coverage (weather certain expressions and sub-expressions in code evaluate to true or false)
Branch Coverage (analyzes how if and case statements & itenary operator (?:) establish branches of execution in code)
FSM Coverage (which states and possible state transitions are exercised)

This is in very brief about code coverage which is almost automatic in nature to implement with the verification flows by just incorporating few switches with the used Functional Simulator e.g. VCS (Synopsys), ISE (Cadence), Questa (Mentor Graphics).

The identified limitation with ‘Code Coverage’ is that it does not tell if all the intended functionality of the design is being verified or not. It just tells if the written design code is fully exercised or not. For example, if any feature is left to get implemented in the design RTL code by the designer because of human error/mistake, code coverage might indicate 100% coverage which may be true from design RTL code perspective but may not be sufficient from the specification based design verification point of view. Also in the highly complex designs, there are numerous states and range of variables & their transitions which might not thoroughly exercised & it is required to have some mechanism to trace those holes and fix it later using additional test cases.

Now lets try to understand about ‘Functional Coverage’. Functional Coverage is the metric of how much design functionality has been exercised/covered by the testbench or verification environment which is explicitly defined by the verification engineer in the form of a functional coverage model. In its simplistic form, it is user defined mapping of each functional feature to be tested to a so called ‘cover point’ & these coverage point used to have certain conditions (ranges, defined transitions or cross etc.) to fulfill before its announced 100% covered during simulation. All these conditions for a cover point are defined in form of ‘bins’.

During simulation, as & when a certain conditions of a coverpoint hits, those bins (conditions) are getting covered and it gives us the measurement of verification progress. After executing a number of testcases, a graphical report may be generated to analyze the functional coverage report and plan can be made to cover up the holes. Number of cover points can be captured under one ‘covergroup’ & collection of number of cover groups is usually called a ‘functional coverage model’.

I’ll try to illustrate it with an example below.

Figure 1 – Functional Coverage Model Development Flow

Following Functional Coverage Model comprises of a covergroup called “tx_word_format_cg” which defines the functional coverage of UART word format determined from the Line Control Register (LCR) bits coverage:

covergroup tx_word_format_cg

with function sample(bit[5:0] lcr);

option.name = “tx_word_format_cg”;

option.per_instance = 1;

WORD_LENGTH: coverpoint lcr[1:0] {

bins bits_5 = {0};

bins bits_6 = {1};

bins bits_7 = {2};

bins bits_8 = {3};

}

STOP_BITS: coverpoint lcr[2] {

bins stop_1 = {0};