When engineers start learning RTL verification, two coverage terms appear repeatedly: code coverage and functional coverage.

Both help a verification team understand how thoroughly a design has been exercised, but they answer different questions.

Code coverage asks:

Which parts of the RTL were executed?

Functional coverage asks:

Which features, scenarios, values, combinations, and behaviors defined as important in the verification plan were exercised?

That distinction is important.

A simulation can achieve high code coverage while still missing important functional scenarios. Likewise, a carefully designed functional coverage model can show that intended scenarios were exercised while code coverage reveals RTL that the tests never reached.

Functional coverage is generally defined by the verification team from the specification and test plan, while code coverage is collected from the design implementation by simulation or coverage tools. AMD’s current Vivado documentation describes functional coverage as a user-defined metric based on features and conditions identified in the test plan.

For VLSI engineers, understanding both metrics is important because coverage is not just a percentage shown in a report. It is a way to identify what has been exercised, what is still missing, and where the verification plan needs attention.

What Is Code Coverage?

Code coverage measures which parts or constructs of the RTL were exercised during simulation.

Depending on the simulator and coverage configuration, code coverage can include metrics such as:

• Statement or line coverage
• Branch coverage
• Condition or expression coverage
• Toggle coverage
• FSM state coverage
• FSM transition coverage

The exact metrics and terminology vary by tool.

For example, consider:

always_comb begin

    if (enable)

        data_out = data_in;

    else

        data_out = ‘0;

end

A test that exercises enable = 1 may execute the first branch.

If the testbench never applies enable = 0, the other branch may remain uncovered.

Code coverage can therefore help identify RTL paths that have not been exercised.

What question does code coverage answer?

Primarily:

“Did simulation execute this part of the implementation?”

That is useful because unexecuted RTL deserves investigation.

However, execution alone does not prove that the behavior was correct.

A line can execute and still produce an incorrect result.

What Is Functional Coverage?

Functional coverage is a user-defined measurement of whether the scenarios and behaviors considered important in the verification plan have actually occurred.

Instead of starting from the RTL source code, functional coverage starts from the design specification and verification intent.

For example, suppose an RTL block contains an ALU supporting:

• ADD
• SUB
• AND
• OR

A functional coverage model could define coverage for each operation.

It could also define important operand conditions such as:

• Zero
• Maximum value
• Minimum value
• Positive values
• Negative values
• Equal operands
• Different operands

The verification team might then create cross coverage to determine whether important combinations occurred.

SystemVerilog provides constructs such as covergroup, coverpoint, bins and crosses for creating functional coverage models.

What question does functional coverage answer?

Primarily:

“Did we exercise the scenarios and behaviors we intended to verify?”

This makes functional coverage closely connected to the verification plan.

Functional Coverage vs Code Coverage: The Main Difference

The easiest way to remember the distinction is:

The two metrics are therefore complementary rather than interchangeable.

A Simple Example: ALU Verification

Consider an ALU with four operations:

ADD

SUB

AND

OR

Suppose the testbench executes:

ADD

ADD

ADD

SUB

SUB

AND

OR

The RTL associated with all four operations may have been executed.

Code coverage could therefore look very good.

But what if the verification plan requires testing:

• ADD with zero
• ADD with maximum values
• SUB resulting in zero
• SUB with underflow conditions
• AND with all-zero operands
• AND with all-one operands
• OR with mixed operands

If these scenarios were not deliberately tracked, high code coverage would not tell you that they were missing.

Functional coverage can.

A simplified coverage model could define:

covergroup alu_cg;

  cp_opcode: coverpoint opcode;

  cp_operand_type: coverpoint operand_type;

  opcode_x_operand:

    cross cp_opcode, cp_operand_type;

endgroup

The exact model should come from the specification and verification plan, not simply from whatever signals happen to be available.

Why 100% Code Coverage Does Not Mean Complete Verification

This is one of the most important concepts for a VLSI verification engineer.

Suppose your simulation reaches every executable RTL statement.

You might report:

Code coverage = 100%

That sounds complete, but it does not answer several important questions:

• Did every required feature occur?
• Did all important input combinations occur?
• Were boundary conditions tested?
• Were error conditions exercised?
• Were protocol corner cases tested?
• Did the design produce the expected result?
• Were important sequences tested in the correct order?

Code coverage tells you that the implementation was exercised.

It does not establish that the specification was completely tested or that every observed result was correct.

Verification resources similarly emphasize that 100% code coverage does not imply complete functional verification.

Why 100% Functional Coverage Does Not Mean the Design Is Bug-Free

Functional coverage has its own limitation.

Imagine that the verification team defines only these bins:

ADD

SUB

AND

OR

All four bins are hit.

Functional coverage could report:

100%

But what if the verification plan forgot an important requirement?

For example:

• Reset behavior was not included.
• An illegal opcode scenario was omitted.
• A boundary condition was forgotten.
• A specific protocol sequence was never modeled.
• A required error response was not included.

The coverage model cannot report something it was never asked to measure.

This is why functional coverage quality depends heavily on the quality of the verification plan and coverage model.

A high percentage of a poorly defined coverage model is not the same as comprehensive verification.

Code Coverage Metrics VLSI Engineers Should Know

Code coverage is not one single metric.

1. Statement Coverage

Measures whether executable statements were executed.

Useful for identifying RTL that was never reached.

2. Branch Coverage

Measures whether different decision outcomes were exercised.

For example:

if (valid)

    …

else

    …

Ideally, verification should exercise both relevant paths.

3. Expression or Condition Coverage

Examines conditions within decision expressions.

For example:

if (valid && ready && enable)

A coverage tool can help determine whether relevant condition combinations were exercised, depending on the tool and coverage configuration.

4. Toggle Coverage

Measures signal transitions.

It can help identify signals or bits that never changed during simulation.

Toggle coverage can be particularly useful for finding signals that may not be adequately exercised, but a toggle does not by itself demonstrate meaningful functional behavior.

5. FSM Coverage

For designs containing finite state machines, coverage may track:

• States reached
• Transitions exercised

This can reveal state or transition paths that were not reached by the tests.

Functional Coverage Metrics VLSI Engineers Should Know

SystemVerilog functional coverage gives verification engineers more control over what they consider important.

Covergroups

A covergroup defines a functional coverage model.

For example:

covergroup bus_cg;

    …

endgroup

The model can then be instantiated and sampled according to the verification environment.

Coverpoints

A coverpoint specifies what value or expression you want to observe.

For example:

cp_opcode: coverpoint opcode;

The coverpoint can then be divided into bins.

Bins

Bins group values or conditions that are important to the verification plan.

For example:

cp_size: coverpoint size {

    bins small  = {[0:3]};

    bins medium = {[4:7]};

    bins large  = {[8:15]};

}

The exact bins should reflect meaningful design behavior rather than arbitrary ranges.

Cross Coverage

Cross coverage measures combinations between coverage points.

For example:

opcode_x_size:

    cross cp_opcode, cp_size;

This can answer a question such as:

“Did we test every important operation with every important data-size category?”

Cross coverage can become very large, so it should be used selectively.

Functional Coverage Is Based on the Verification Plan

One of the biggest mistakes beginners make is creating coverage from RTL signals without first understanding the specification.

A better process is:

Specification, features, Verification requirements, Coverage plan, Coverpoints / bins / crosses, Stimulus, Coverage results

For example, suppose a FIFO specification says:

• Empty state must be handled.
• Full state must be handled.
• Simultaneous read/write is supported.
• Overflow attempts must be handled.
• Underflow attempts must be handled.

A functional coverage model could track these scenarios.

The coverage model therefore reflects what matters from a functional perspective, not simply which RTL signals exist.

Code Coverage and Functional Coverage Can Show Different Results

The most useful way to understand the two metrics is to look at combinations.

High Code Coverage + Low Functional Coverage

This can indicate that the tests are exercising much of the RTL but are not covering enough of the scenarios defined in the verification plan.

Possible reasons include:

• Missing tests
• Poor stimulus constraints
• Missing corner-case scenarios
• Incomplete functional coverage model
• Incorrect assumptions in the testbench

It should trigger investigation rather than an automatic conclusion.

Low Code Coverage + High Functional Coverage

This combination can also occur.

Possible explanations include:

• The functional model covers a subset of intended scenarios.
• Some RTL is not reachable.
• There may be dead or redundant code.
• Some implementation paths need additional stimulus.
• The coverage model and RTL may not be aligned.

Again, the right response is to investigate the gap.

Verification Academy discussions specifically caution against treating the two metrics as interchangeable and recommend investigating why the gap exists rather than using the percentages as a simple pass/fail indicator.

High Code Coverage + High Functional Coverage

This is generally a stronger coverage position, but it still does not prove that verification is complete.

You still need to consider:

• Assertions
• Scoreboards
• Reference models
• Checkers
• Negative testing
• Error injection
• Reset scenarios
• Protocol compliance
• Performance requirements
• Formal verification where applicable
• Testbench quality
• Specification completeness

Coverage is evidence about what was exercised.

It is not a mathematical proof that the design contains no bugs.

What About Assertions?

Assertions and coverage are related, but they serve different purposes.

An assertion generally checks whether a property is obeyed.

For example:

If VALID is high and READY is low,

the transfer payload should remain stable.

A coverage point could instead record:

Did the VALID-without-READY condition actually occur?

So:

Assertion:
“Was the rule obeyed?”

Coverage:
“Did the situation occur?”

This distinction is important when building a verification environment.

Assertion-based verification checks properties from coverage constructs, which record that scenarios or conditions occurred.

How Code Coverage and Functional Coverage Work Together

A practical verification flow might look like this:

Step 1: Define the specification

Understand what the DUT is supposed to do.

Step 2: Create the verification plan

Identify:

• Features
• Modes
• Input conditions
• Corner cases
• Error conditions
• Important sequences

Step 3: Build functional coverage

Translate those requirements into:

• Covergroups
• Coverpoints
• Bins
• Crosses
• Transition coverage where useful

Step 4: Run tests

Use directed, constrained-random, regression and other appropriate tests.

Step 5: Collect code coverage

Analyze:

• Statements
• Branches
• Expressions
• Toggles
• FSM states/transitions

according to the project’s coverage methodology.

Step 6: Compare the gaps

Ask:

What functionality is missing?

and:

What RTL remains unexecuted?

Step 7: Investigate

Do not immediately modify the coverage model just to increase the percentage.

Determine why the bin or RTL path was missed.

Step 8: Close legitimate coverage holes

Possible actions include:

• Add stimulus
• Modify constraints
• Add a test
• Improve the coverage model
• Fix unreachable RTL
• Remove genuinely dead code
• Document justified exclusions

Coverage Metrics VLSI Engineers Should Remember

The availability and exact interpretation of these metrics depend on the simulator and verification methodology.

Final Takeaway

Functional coverage and code coverage answer different questions, and a strong VLSI verification strategy uses both.

Code coverage looks at the implementation:

Did the simulation execute the RTL?

Functional coverage looks at the verification intent:

Did we exercise the important functionality and scenarios identified in the verification plan?

Neither metric proves correctness by itself.

A design can execute 100% of its RTL and still miss an important functional scenario. Conversely, a functional coverage model can report 100% while overlooking a requirement that was never included in the model.

The most useful coverage process is therefore:

Specification → Verification Plan → Functional Coverage → Stimulus → Code Coverage → Gap Analysis → Coverage Closure

For VLSI engineers, the real skill is not achieving an impressive coverage percentage. It is being able to explain what the percentage represents, identify what is missing, understand why it is missing, and decide what action is justified by the verification evidence.

That is the difference between simply collecting coverage and actually using coverage to improve verification.