User Guide: DSim Coverage Options

Controlling Functional Coverage

Functional coverage applies to SystemVerilog only.

The -no-fcov option disables functional coverage collection at run time. When given, no functional coverage is written to the output sqlite3 database (normally "metrics.db") when simulation ends. Also, covergroups sensitive to an event will not be activated during the run, which should save some run time. However, the covergroups and coverpoints are partially created, so that user code can naively call coverage methods without immediately failing on a null reference. Care should be taken not to rely on coverage computation or side-effects from covering expressions (e.g. function calls) which may alter a run without coverage.

Functional coverage is collected by default. We believe that all of the supported SV-LRM-defined language features ought to be enabled and working without requiring special command line switches.

The coverage option auto_bin_max is specified in the SV-LRM to limit the number of automatic bins created for a coverpoint, but is specifically not applicable to bins of enumeration type. The option -limit-enum-bins has been added to override the SV-LRM compliant behavior, and to subject bins of enumerated type to the same limit.

By default, wildcard bins are processed by a dedicated 4-state wildcard engine that uses bit masking to determine if a sample input matches a wildcard. However, under certain circumstances, a wildcard bin must be expanded into an equivalent set of range bins. e.g. { 4'b11xx } can be expanded into { [12:15] }. This expansion may occur under the following conditions:

• The coverpoint requires multiple bins, so different matches may go into different bins.
• There is a multiple-bin default, which requires determination of which values do not hit any other bin.

However, some wildcard definitions are not practical to expand. e.g. { 32'bxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0 }. This expands into all two-billion even numbers, and will likely not complete at run time due to memory exhaust. The -wildcard-limit option is used to set a limit on wildcard bin expansion. If the limit is encountered, a warning will be printed and the expansion will be incomplete.

Controlling Code Coverage

DSim supports three types of code coverage:

• Line/block coverage: indicates which statements in the code base have been executed.
• Toggle coverage: indicates which integer-valued nets/variables have changed state.
• Focused expression coverage: indicates which conditions that lead to a boolean-valued expression have been encountered. The focused expression model is used.

Line/block and expression coverage requires that the code base be instrumented at compile time. Toggle coverage requires the option at runtime.

All forms of code coverage apply to SystemVerilog. Block coverage is also supported for VHDL.

Line/block Coverage

Line/block coverage requires instrumentation at compile time. Performance is reduced when line coverage is enabled.

Toggle Coverage

Toggle coverage requires that VPI callback permission (+acc+b) be set on any net or variable whose toggles are to be captured. Toggle coverage itself is a run-time option, much like waveform dump.

The toggle coverage model counts transitions from 0 to 1 and 1 to 0. Transitions to/from z or x are not counted.

Expression Coverage

Expression coverage requires instrumentation at compile time. Performance is reduced when expression coverage is enabled.

DSim uses a focused expression coverage model. For each boolean expression being covered, the minimal set of input conditions required to exercise all paths through the expression is computed.

The result of analyzing each expression for focused expression coverage is a truth table. Every time an expression gets evaluated, all rows in the truth table are searched and the counter in the matching row is incremented. Large truth tables both take up a lot of memory and consume a lot of run time doing the search. The -expr-cov-row-limit option can be used to limit which expressions are covered; expressions requiring larger truth tables will not be covered. Typically these expressions are used in datapaths, and not control logic.

If one input condition is used more than once in an expression, it may not be possible to cover all paths through the expression. The input condition may be used in conflicting ways that impede either control or observability.

DSim tries to handle zero-delay glitches so that you get meaningful coverage information. However it is possible that the existence or non-existence of certain optimizations may cause zero-delay glitches to impact your coverage results. Every time an expression gets evaluated, a process for the sampled input conditions is scheduled in the Postponed region of the current time step (clause 4.4 of the SV-LRM). It is scheduled on a coverage queue associated with the currently evaluated expression. The coverage queue is cleared before the expression gets evaluated again for any of the following reasons:\ — The procedure containing the given expression, having been suspended earlier due to reaching an event control or wait statement, resumes execution.\ — The procedure containing the given expression was declared as an always_comb or always_latch, and its execution is resumed due to a transition on a member of its implicit sensitivity list.

If an expression is part of a compound statement, the coverage results may vary depending on what optimizations are present in the simulation. For instance,

logic  a, b, c, d;
logic [3:0] status;

initial begin
   #100;
   status = 4'b0000;
   #0 b = 1'b1;
end

always_comb begin
   if (a | b)
      // a statement that reads status
   else if (c | d)
      // a statement that reads status
   else
      // a statement that reads status
end

Assume that status changes while a, b, c, and d are 1'b0, as in the initial block. This is followed by a change to b, which causes b to transition to 1'b1. In this case, the always_comb block is executed twice at time 100 (because of the #0 delay before the second assignment). The first time through, the first if is false, so the second if is evaluated, and data is sampled for c | d. The second time through, the first if is true, so no further data is sampled for c | d.

Compare the previous example, with an example where b transitions to 1'b1 simultaneously with the status change, while a, c, and d are 1'b0

initial begin
   #100;
   status <= 4'b0000;
   b <= 1'b1;
end

In this case, the always_comb block is executed once at time 100, after the two non-blocking assignments have completed. The first if is true, so no data is sampled for c | d.

This contrived example is not impacted by optimizations, but does illustrate that you can get different decisions depending on the stimulus driving the input conditions of an expression. If the initial blocks were replaced by other driving sources, whose behavior can be impacted by optimizations, you could get similar differences.