There are two types of functional coverage. Black box functional coverage and white box functional coverage. This blog will focus on the black box functional coverage architecture.

In order to cater to functional coverage model architecture requirements following architecture is proposed. It’s verification methodology independent. Can be used in verification environments built with or without verification methodology. Please note this is one of the way, not the only way.

Idea is very simple. We will primarily addresses two questions:

• How to organize your functional coverage?
• How to integrate it with test bench?

A good architecture exhibits the strong cohesion and low coupling. We had applied the same principles to test bench architecture. Now let’s apply the same to functional coverage model architecture as well. This translates to related functional coverage staying together and having very low coupling with the test bench. This model would then satisfy the objectives functional coverage model architecture requirements.

Lets now look how to translate this into a working model. When we say put all the related functional coverage together what do we mean? Where should they be put together? Further discussion will use the SystemVerilog language constructs as medium to explain. While the proposed model is independent of high level verification language or verification methodology used.

Functional coverage organization – strong cohesions

Related functional coverage can be grouped together with the help of two constructs. Multiple coverpoints in covergroup and multiple covergroups in a class. First level very closely related coverage can be made part of the same covergroup. Each item of very closely related items can become coverpoints of same covergroup. Related but not very closely related can made part of same class where multiple covergroups are put together. Lets call these classes as coverage container classes.

There can be multiple coverage container classes. How many container classes can be created? There is no hard limit. It’s based on the requirements. It can be driven by the combination of functional division of the requirements specifications and its implementation. Fundamentally driven by verification requirements.

Further these container classes can be organized through composition. This type of organization will help build meaningful hierarchical organization of functional coverage implementation. This makes it easy to spot any functional coverage implementation. It helps in easing the review process and maintenance.

Let’s take an example to make the point clearer. Consider any layered protocol functional coverage implementation. A container class is per layer can be created. Per layer container classes can be composed to create a top-level coverage container. This reflects the design implementation hierarchy.

Next dimension to it is, If the design is instanced multiple times, top-level functional coverage container can also be instanced multiple times to match it. Based on type of coverage requirements either per instance or merged coverage can be extracted easily with this type of organization.

In conclusion it should reflect the architecture of system being covered and adapt to its implementation.

Functional coverage integration – low coupling

Functional coverage integration is about two things. First getting the information to sample like system state, randomized transactions, randomized configurations etc. from test bench to the functional coverage model. Second sampling them at right point of time and right number of times.

Functional coverage sampling is one of those areas that is highly prone to bugs and can also limit the reusability, if its not well thought out.

First lets address how to sample at right point of time and right number of times.

SystemVerilog functional covergroup construct allows the sampling event to be either specified in the covergroup(covergroup cg @posedge intr) itself or can be sampled with the sample( cg.sample()) function.

Directly specifying the sampling event in covergroup does two things. It can build dependency of hierarchical information or local events. Events in SystemVerilog are race prone. If a clock signal is used unless there is proper guard condition it can end up sampling at wrong time.

One exception to above guideline can be made when sampling the functional coverage for the physical interface or RTL signals. Physical interface signals sampling events can use directly the related signals or clocks for sampling. It needs to take care of proper guard conditions though. For rest everything, it’s safe approach to go with the sample function and call it explicitly.

Now that brings us to next question of how will coverpoints access information to be sampled? Simple starting point for this problem is to put all the information to be sampled in the container class itself. Sample them directly in coverpoints when sample function is called.

How will this sampling information get populated in container classes? Create another class that contains all the information sampled by the coverpoints of covergroup. This class is like a transaction, transaction for coverage model. Lets call this as sample event transaction. Sample event transaction can reflect the same composition as functional coverage container classes.

Let’s go back to multilayer protocol implementation example, sample event transaction can contain sample event container per layer. The corresponding layer’s sample event container will be passed to corresponding layer’s functional coverage container for sampling. Every functional coverage container can have its corresponding sample event container and composition can reflect same hierarchy.

Putting it all together

Who will populate the sample event transaction? Well this question brings us to the last piece of puzzle.

This will act as the key component of integration of functional coverage to test bench. Sample event transaction can use composition to place various objects of the test bench that needs to be covered or provide the inputs to coverage model. Like any other transaction, sample event transaction can also have a type indicating the validity of type of information its carrying. The coverage model based on the type of the sample event object can sample the right covergroups to update the coverage models.

Sample event transaction and interface API for passing the sample event transaction to coverage model becomes single point communication between the test bench and coverage model. This helps improves the portability of the functional coverage model and ease of debugging.

The above-proposed model eases the debugging of the sampling issues. Since there is single point of communication either through breakpoints in interactive debugging or logging the sample event transaction like any other transaction it becomes easy to debug the sampling issues of the functional coverage model.

Remember a high quality functional coverage leads to high quality functional verification.

For simple reference SystemVerilog code for above proposed model either comment or drop us an email.