Where to implement functional coverage

UVM
1

I would like to know what is the recommended place to implement functional coverage

  1. non temporal functional coverage - coverpoints

I understand these can be implemented in monitors, scoreboards, subscribers, coverage collectors (though I don’t know what the last 2 really are)

  1. temporal functional coverage - cover directives

I understand these can be implemented in interfaces, modules or programs

Thanks,

2

In reply to verif_learner:

First, you should differentiate between functional coverage and assertion coverage.
Assertion coverega (assert property, cover property) cannot be implemented in Class-based Components, but in modules, interfaces and program blocks.
Functional coverage can be implemented in class-based components and in modules, interfaces and program blocks.

3

In reply to chr_sue:

Please read my post. I have clearly differentiated functional coverage into temporal and non-temporal and stated options where all these can be implemented. I wanted to know within these entities (not talking about VHDL entity here), which is the best place to implement.

I suggest you read questions clearly before responding.

4

In reply to verif_learner:

Your question is still not clear to me. Please use a word other than “place”. Perhaps you can show the options you have in mind that you want to choose a particular recommendation.

5

In reply to dave_59:

Sorry. Probably, a little context behind by question will help.

I am a bit of re-use fanatic. I have read few books and articles.
Some of them suggest users to implement coverpoints in monitors.
Some of them suggest users to implement coverpoints in scoreboards.
Some of them suggest users to implement coverpoints in subscribers.

They don’t generally indicate the reason behind these suggestions.
Probably, it is implied. I am not sure.

My own analysis is as follows:

if I implement coverpoints in monitors or scoreboards then modularity as far as functional coverage is lost. If someone wanted to just re-use functional coverage alone then it would come with additional baggage.

if I implement coverpoint in monitors or scoreboards then if I have to do some additional processing for coverpoints then it would clutter monitor code with additional code that has nothing to do with monitor functionality.

if I implement coverpoint in monitors then any functional coverage pertaining to multiple interfaces are an issue

implementing in subscriber seems to have the following advantages:
generally very clean and independently re-useable
can implement functional coverage related to multiple interfaces easily (by accessing transactions from multiple monitors).

The downside of subscriber is that some of the additional processing may already be done in scoreboards that has to be repeated or information has to be obtained from scoreboard.

Anyway, I have shared my thoughts. I would like comments from your and others on the forum.

Thanks for the help.

6

In reply to verif_learner:

First your words allow still different interpretations.
If you do not specify which Kind of data you are evaluating for functional coverage nobody can answer your question. If you expect certain data in your scoreboard and you want to check this you Can define a covergroup there. This does not limit reusability.
The UVM User-Guide does not say much about functional coverage. I implement always a coverage collector in my agents, because I want to kow which kind of data where generated during randomization. Other places for functional coverage are depending on your application.

7

In reply to chr_sue:

In reply to verif_learner:
First your words allow still different interpretations.
If you do not specify which Kind of data you are evaluating for functional coverage nobody can answer your question. If you expect certain data in your scoreboard and you want to check this you Can define a covergroup there. This does not limit reusability.
The UVM User-Guide does not say much about functional coverage. I implement always a coverage collector in my agents, because I want to kow which kind of data where generated during randomization. Other places for functional coverage are depending on your application.

ok. Thanks. I appreciate your inputs.

8

In reply to verif_learner:

  1. non temporal functional coverage - coverpoints
    I understand these can be implemented in monitors, scoreboards, subscribers, coverage collectors (though I don’t know what the last 2 really are)

chr_sue clarifies that your category 1) “covergroup” can also be implemented in modules, interfaces etc. If you’ve known this, it is fine, otherwise, he wants to remind you on this.

9

In reply to verif_learner:

Hi,

To address the dilemma between modular coverage code and non-replication of subscriber ports/code in scoreboard and coverage , I found the following two ways useful.

Way-A :

  1. extend the coverage class from the scoreboard class.
  2. define coverage in the coverage class and redefine all the write_* tasks with call to super.write_* and then add your covergroup.sample() in the write_* tasks.
  3. in the Env, instead of instantiating the scoreboard, u instantiate the coverage class and make port connections.
  4. This way you have modularity(separation) in code and no replication of ports.

Else if someone wants to stick to rudimentary and say NO to Way-A , then

Way-B :

  1. Make base class with analyisis ports.
  2. Extend scoreboard and coverage from base class.(Atleast I am saved the port declaration and New-ing)
  3. define coverage related stuff in coverage and scoreboarding checks in scoreboard.
  4. Instantiate both coverage and scoreboard in Env and make connections to monitor for both of them.
  5. set handle of scoreboard in uvm config_db
  6. In the coverage class, get scoreboard handle from config_db and that way avoid duplication of code that is already defined in scoreboard.

Regards,
nisj

10

In reply to nisreenj:

I believe it is not a good idea to calculate functional coverage in the scoreboard. Functional coverage will be calculated without any blocking operation. The scoreboar need the blocking activities because the transaction data to compare will arrive never at the same time. A good approach is to use for the coverage collector as bas class a uvm_subscriber located in the env to calculate some global coverage or in the agentds to calculate the agent related coverage.

11

In reply to nisreenj:

Hi nisreenj,
Thank you for descriptive the ways. I just wanted to understand why scoreboard handle is needed inside coverage component ?

Regards
AJ

12

In reply to amjadhav:

In reply to nisreenj:
Hi nisreenj,
Thank you for descriptive the ways. I just wanted to understand why scoreboard handle is needed inside coverage component ?
Regards
AJ

I do not agree with nisreenj. There is one important rule in UVM: keep things which do not belong together like functional coverage and scoreboarding seperately.
The UVM does not say anything where to implement the functional coverage. It is your decision where to do it.
If you want to know what did you stimulate from each agent it is useful to have a coverage collector inside your agents. If you are interested in more global coverage it has to be somewhere in the env.
Calculating functional coverage does not consume time. A good base class is the uvm_subscriber which has a built-in analysis_export/imp.

13

In reply to chr_sue:
per agent coverage helps to tracks which stimuls are generated. it’s better to develop coverage inside a agent component.