CODEWITHSUNDEEP
verilogsystem-verilogvlsi
Karan Shah
Karan Shah

Reputation: 1992

Option & type_option in System Verilog

Coveegroup x;
  C: Coverpoint a {type_option.weight=0;}
Endgroup

I want to set coverpoint C weight to 0, for all the instances of covergroup x. So I have used type_option, as option is for instance specific settings.

I have created 4 objects of this covergroup, but in each object, C is considered for calculation of coverage, despite of setting it's weight to 0.

Things works fine when I use option, instead of type_option.

Please explain me the reason behind this.

Upvotes: 1

Views: 5358

Answers (1)

Unn
Unn

Reputation: 5098

Typically in coverage, one cares not only about the percentage of bins covered in each individual instance of a given coverpoint but also the aggregate coverage of that coverpoint over all instances. If you look at the coverage report generated by most tools (I am mostly familiar with VCS; but I am sure other tools do a similar thing in their reports), you will see coverage for all instances of a given coverpoint in total and then the coverage on each instance broken down in per instance coverage numbers.

Here with where type_option.weight and option.weight come in. type_option.weight is the weight for this coverpoint in the aggregate report; setting it to 0 will make the aggregate coverage on that coverpoint count for nothing towards the aggregate coverage numbers; while the individual instances still have weight in their individual instance coverage numbers. option.weight is the weight for that coverpoint in each instance's coverage, so setting it to 0 will make that coverpoint count for nothing in each instance's coverage, but the coverpoint will still count towards the aggragate coverage for that group. Setting both to 0 gives that coverpoint no weight in any count; which can be helpful if you only care about using that coverpoint in a cross and care only about how coverage comes out in that cross.

See Chapter 19 in IEEE-1800 2012 SystemVerilog LRM (it probably is 19 in earlier LRMs but Im looking at 2012 right now).

Upvotes: 1

Related Questions