A covergroup's raw bin hits are only half the story. Coverage options control how that raw hit data actually turns into a reported percentage — how many hits a bin needs before it counts as covered, what target counts as "done," and how much one covergroup's score should count when it's combined with others into a single project-wide number.

13 min read | Intermediate Level

What You'll Learn

  • The difference in scope between option and type_option
  • How at_least changes exactly how many hits a bin needs before it counts as covered
  • How goal lets a covergroup report 100% before every one of its bins has actually been hit
  • How weight controls how much a covergroup contributes when combined into an aggregate coverage score
  • What auto_bin_max, per_instance, and comment each control

option vs type_option

Both are set the same way — option.name = value; or type_option.name = value; inside a covergroup — but they apply to different things. option controls settings for one specific covergroup instance (or acts as that instance's own default). type_option controls settings for the covergroup type as a whole, shared identically across every instance of it, and can't be overridden per instance.

at_least: How Many Hits Count as Covered

By default, a single hit is enough for a bin to count as covered. at_least raises that threshold:


covergroup cg @(posedge clk);
  cp_addr: coverpoint addr {
    option.at_least = 3;   // a bin needs 3 hits before it counts as covered
    bins low  = {[0:63]};
    bins high = {[64:127]};
  }
endgroup

If addr falls in the low range only twice during a test, that bin is not counted as covered yet — at_least requires 3 hits, and only 2 have happened. It takes a third hit before the bin flips to covered and starts contributing to the reported percentage.

Quick Check

Q: With option.at_least = 3, if low is hit exactly 3 times and high is hit exactly once, what does the coverpoint's own coverage percentage show?

Show Answer

50%. low meets the 3-hit threshold and counts as covered; high has only 1 hit, below the threshold, so it doesn't count yet — one out of two bins covered.

goal: A More Achievable Target

goal sets what percentage of actual bin hits gets reported as "100% done" for that covergroup:


covergroup cg @(posedge clk);
  option.goal = 80;   // reported as fully covered once 80% of bins are hit

  cp_mode: coverpoint mode {
    bins b[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};   // 10 explicit bins
  }
endgroup

If 8 of the 10 mode bins are actually hit — 80% of them — this covergroup reports 100% coverage, since it met the goal that was set. The other 2 bins are still genuinely unhit; the goal just means reaching them isn't required for this covergroup to be considered complete.

Quick Check

Q: With option.goal = 80 and only 7 of the 10 bins hit, what would the reported coverage be?

Show Answer

70%, not 100%. The raw hit rate (7/10 = 70%) is still below the 80% goal, so it hasn't been met yet — goal only caps the reported percentage at 100% once the raw rate reaches or exceeds it; it doesn't change how the percentage is calculated below that point.

weight: Contribution to a Combined Score

When several covergroups are combined into one overall project coverage number, weight controls how much each one counts in that combination — a plain average by default, or a weighted one if set:


covergroup cg1 @(posedge clk);
  option.weight = 5;   // counts 5x as much in a combined score
  ...
endgroup

covergroup cg2 @(posedge clk);
  option.weight = 1;   // default weight
  ...
endgroup

If cg1 is at 100% and cg2 is at 0%, a plain average would report 50% combined. With cg1 weighted 5 times as heavily as cg2, the combined score instead becomes (5×100 + 1×0) / (5+1) = 83.3% — cg1's score dominates the combined result, in proportion to its weight.

Quick Check

Q: Does changing cg1's weight affect cg1's own reported coverage percentage?

Show Answer

No. weight only affects how cg1's score is combined with other covergroups into an aggregate — cg1's own individual percentage is still calculated exactly the same way, based only on its own bins.

auto_bin_max, per_instance, and comment

Three more commonly-used options, each simpler than the ones above:

  • option.auto_bin_max = N; — caps how many bins are automatically created for a coverpoint that doesn't explicitly define its own bins. The default is 64; a coverpoint covering a wide value range without explicit bins gets split into up to this many automatically-sized bins.
  • option.per_instance = 1; — by default, coverage from multiple instances of the same covergroup (for example, one inside a class that gets constructed many times) is combined into a single aggregate result. Setting this reports each instance's own coverage separately instead, which matters when it's important to know whether every individual instance was exercised, not just the group as a whole.
  • option.comment = "..."; — a plain documentation string attached to the coverage report, with no effect on the calculated percentage at all.

Where Are These Used?

goal is commonly set below 100 for bins that are legitimately difficult or impractical to hit in every regression configuration, giving sign-off a realistic target instead of blocking indefinitely on a handful of edge cases. weight is used to make coverage of a critical protocol area count more heavily than a lower-priority debug-only coverpoint when reporting one combined number. per_instance is essential whenever a design instantiates the same IP block multiple times and it matters whether each instance was actually exercised, not just the group collectively.

Common Beginner Mistakes

Mistake #1: Assuming a single hit always counts as covered

That's only true at the default at_least = 1. Why? Once at_least is raised, a bin can be hit and still not count toward coverage until it reaches the required number of hits — worth checking before assuming a coverage report is wrong.

Mistake #2: Assuming 100% reported coverage means every bin was hit

Not if goal is set below 100. Why? A covergroup reporting 100% only guarantees its goal was met, not that every possible bin was actually exercised — the two are only the same thing when goal is left at its default of 100.

Mistake #3: Expecting weight to change a covergroup's own percentage

As the third Quick Check shows, it doesn't — weight only matters once that covergroup's score is being combined with others. Why? A covergroup's own individual report is always based purely on its own bins, regardless of what weight it's been given for aggregation purposes.

Mistake #4: Confusing option with type_option

Setting option.goal affects one specific instance's default; setting type_option.goal affects every instance of that covergroup type uniformly. Why? Using the wrong one means a setting meant to apply everywhere only ends up affecting a single instance, or vice versa.

Practice Exercise

Challenge: Compute a Combined Score

Covergroup cg_a is at 60% coverage with option.weight = 3. Covergroup cg_b is at 100% coverage with the default weight. What is their combined coverage score?

Hint

Use the same weighted-average formula from this article's main weight example — multiply each covergroup's percentage by its own weight, sum those, then divide by the total weight.

Solution

70%. (3×60 + 1×100) / (3+1) = (180 + 100) / 4 = 280 / 4 = 70. cg_a's lower score still pulls the combined result down, but its heavier weight (3) means it pulls harder than cg_b's default weight of 1 would otherwise allow.

Summary

In this tutorial, you learned:

  • option applies to one covergroup instance (or its own default); type_option applies uniformly to every instance of that covergroup type
  • at_least sets how many hits a bin needs before it counts as covered, rather than the default of just one
  • goal lets a covergroup report 100% once it reaches a chosen percentage of actual bin hits, rather than requiring every bin literally hit
  • weight controls how much a covergroup's score counts when combined with others into an aggregate number, without changing that covergroup's own reported percentage
  • auto_bin_max, per_instance, and comment control automatic bin count limits, per-instance reporting, and report documentation, respectively
Did you find what you were looking for?

Quiz

Test Your Knowledge

1 of 5 Score: 0 / 5