Verification

Functional coverage in SystemVerilog

Q: Weighting, options and goals

Each covergroup and coverpoint accepts option fields that tune how coverage is scored. Common ones include option.weight (relative contribution to the total), option.goal (the percentage considered "covered"), option.at_least (hit count required before a bin counts), and option.per_instance (track each instance separately rather than merging). These let you reflect verification priorities — a safety-critical corner can be weighted heavily, while a low-risk path contributes little.

Q: What are illegal_bins and ignore_bins, and how do they differ?

Both remove values from normal counting. ignore_bins silently excludes values from the coverage calculation, typically because they are impossible or irrelevant. illegal_bins also excludes the values but additionally triggers a runtime error if the value ever occurs — it is an active check that a forbidden condition never happened.

Q: When is a covergroup sampled?

A covergroup samples either when you explicitly call its sample() method or when the clocking event in its declaration (for example @(posedge clk)) fires. You should sample only when the tracked variables hold valid, meaningful data — usually at a transaction boundary — otherwise you record garbage combinations that inflate or distort the metric.

By CourseTron Team · 7 min read · Updated Oct 2026

Table of Contents

🖨 Download / Print this guide (PDF)

In short: Functional coverage is a user-defined, metric-driven way of measuring whether your testbench has actually exercised the behaviors described in the specification. Unlike code coverage, which the simulator computes automatically from the RTL, functional coverage is written by the verification engineer using covergroups, coverpoints, bins and cross coverage to answer the question "did we test what we meant to test?"

What Is functional coverage?

Functional coverage is a quantitative measure of how much of a design's intended functionality has been stimulated and observed during simulation. It is a cornerstone of modern constrained-random verification, where the testbench generates thousands of randomized stimuli and you need an objective way to confirm that the interesting scenarios were actually reached. In SystemVerilog, functional coverage is expressed through a dedicated construct called the covergroup, which samples one or more variables at defined moments and records which values, ranges and value-combinations occurred.

The essential idea is that the verification plan is translated into an executable set of coverage goals. Each goal corresponds to a behavior in the specification — for example "every FIFO depth from empty to full was observed" or "a read collided with a write on the same cycle." When simulation ends, the tool reports a coverage percentage. A closed, 100% functional coverage model is strong evidence that the test suite has visited the scenarios the architects cared about.

Flow from verification plan through covergroup, coverpoints and bins to the coverage report.

How Covergroups, Coverpoints and Bins Work

A covergroup is a class-like container. You declare it once, then instantiate it, and call its sample() method (or attach a sampling event) whenever the values of interest are valid. Inside the covergroup, each variable you want to track becomes a coverpoint.

A coverpoint's values are organized into bins. A bin is a bucket that counts how many times a particular value or range occurred. If you do not declare bins explicitly, SystemVerilog creates automatic bins — one per value for small enumerations, or a capped number controlled by auto_bin_max. Explicit bins give you precise control:

covergroup cg_pkt @(posedge clk);
  cp_len : coverpoint pkt.len {
    bins small  = {[0:63]};
    bins medium = {[64:511]};
    bins large  = {[512:1023]};
    bins jumbo  = {[1024:$]};
  }
  cp_kind : coverpoint pkt.kind;   // auto bins per enum value
endgroup

cg_pkt ck = new();            // instantiate
...
ck.sample();                  // call when pkt is valid

Beyond simple value bins, SystemVerilog supports transition bins (bins t = (S0 => S1 => S2);) to capture ordered sequences of values, wildcard bins for don't-care bit patterns, and ignore_bins / illegal_bins to exclude values from the denominator or to flag conditions that must never occur.

A sampled pkt.len value lands in exactly one bin, whose hit count then increments.

Key fact: Code coverage is produced automatically by the simulator from the RTL structure and tells you which lines, branches and toggles executed. Functional coverage is hand-written from the specification and tells you which behaviors were tested. 100% code coverage with poor functional coverage is a classic false sense of safety — the code ran, but the meaningful scenarios may never have occurred.

Cross Coverage: Testing Combinations

Individually covering two variables is rarely enough. The hard bugs usually live at the intersection of conditions. Cross coverage records the combinations of two or more coverpoints that occurred together:

covergroup cg_bus @(posedge clk);
  cp_op   : coverpoint op   { bins rd = {READ}; bins wr = {WRITE}; }
  cp_size : coverpoint size { bins b1 = {1}; bins b4 = {4}; bins b8 = {8}; }
  x_op_size : cross cp_op, cp_size;   // 2 x 3 = 6 combinations
endgroup

The cross above produces six cross-bins. Reaching all of them proves that reads and writes were each exercised at every burst size — a far stronger claim than covering operation and size separately. Crosses can explode combinatorially, so engineers prune them with binsof / intersect expressions and ignore_bins to remove combinations that are impossible by design.

Cross coverage of two read/write bins by three burst-size bins gives six cross-bins.

Weighting, options and goals

Each covergroup and coverpoint accepts option fields that tune how coverage is scored. Common ones include option.weight (relative contribution to the total), option.goal (the percentage considered "covered"), option.at_least (hit count required before a bin counts), and option.per_instance (track each instance separately rather than merging). These let you reflect verification priorities — a safety-critical corner can be weighted heavily, while a low-risk path contributes little.

Functional vs Code Coverage in Practice

The two metrics are complementary, not interchangeable:

Code coverage (line, branch, condition/expression, toggle, FSM-state) is cheap — you simply enable it at compile time. It answers "was this RTL exercised?" and is excellent at exposing dead or untested code.
Functional coverage requires engineering effort to author, but it answers "was this feature verified?" It can reach behaviors code coverage is blind to, such as a specific legal combination of protocol fields that no single line of RTL uniquely represents.

A mature signoff flow tracks both. Code coverage finds unreached logic; functional coverage confirms the intent of the test plan was met. Holes in one often reveal gaps that the other missed, and coverage-closure meetings typically review them side by side before tapeout.

Learn this hands-on

Real projects and industry tool flows, with certification.

Explore CourseTron Courses →

How Industry Tools Handle It

All three major simulators — Synopsys VCS, Cadence Xcelium and Siemens Questa — implement the IEEE 1800 functional coverage semantics and emit results into a unified database (Synopsys uses the Unified Coverage Database, UCDB, standardized through Accellera's UCIS). Verification teams merge coverage from hundreds of regression runs into one database, then open a coverage GUI or generate HTML/spreadsheet reports showing per-bin hit counts and overall percentages.

Coverage is almost always paired with a written verification plan (vPlan) that is annotated back against the collected data, so managers can see exactly which specification features are closed. UVM provides no new coverage syntax — functional coverage is pure SystemVerilog — but teams commonly place covergroups inside dedicated UVM subscriber or coverage-collector components that connect to analysis ports, keeping coverage sampling decoupled from the drivers and monitors.

functional coverage — Interview FAQ

What is the difference between functional coverage and code coverage?

Code coverage is generated automatically by the simulator from the RTL and measures which structural elements (lines, branches, toggles, FSM states) executed. Functional coverage is written by the engineer from the specification and measures which intended behaviors were stimulated. You can have 100% code coverage and still have large functional holes, which is why both are required for signoff.

What is the difference between a coverpoint and a cross?

A coverpoint tracks the values of a single variable, organized into bins. A cross tracks the combinations of two or more coverpoints occurring together. Crosses catch interaction bugs that separate coverpoints cannot, because a bug may only appear when, say, a WRITE coincides with a maximum burst size.

What are illegal_bins and ignore_bins, and how do they differ?

Both remove values from normal counting. ignore_bins silently excludes values from the coverage calculation, typically because they are impossible or irrelevant. illegal_bins also excludes the values but additionally triggers a runtime error if the value ever occurs — it is an active check that a forbidden condition never happened.

When is a covergroup sampled?

A covergroup samples either when you explicitly call its sample() method or when the clocking event in its declaration (for example @(posedge clk)) fires. You should sample only when the tracked variables hold valid, meaningful data — usually at a transaction boundary — otherwise you record garbage combinations that inflate or distort the metric.