21EC71 Advanced VLSI

Advanced VLSI
(21EC71)
SEMESTER – VII

“Small disciplines repeated with consistency every day lead to great

achievements gained slowly over time.” – John C. Maxwell

Module 5
Randomization: Introduction, What to randomize? , Randomization in System
Verilog, Random number functions, Common randomization problems, Random Number
Generators.

Functional Coverage: Coverage types, Coverage strategies, Simple coverage

example, Anatomy of Cover group and Triggering a Cover group, Data sampling, Cross
coverage, Generic Cover groups, Coverage options, Analyzing coverage data, measuring
coverage statistics during simulation.

Text Book 2

Vijaykumar Sajjanar
[email protected],
vjkr.github.io

www.bldeacet.ac.in Page | 1
21EC71 Advanced VLSI

TABLE OF CONTENTS
Randomization ......................................................................................................................................................................................... 4
What to Randomize ................................................................................................................................................................................ 4
Randomization in SystemVerilog ..................................................................................................................................................... 6
Simple class with random variables .......................................................................................................................................... 6
Checking the result from randomize ......................................................................................................................................... 6
The constraint solver ........................................................................................................................................................................ 6
Random System Functions .................................................................................................................................................................. 7
Common Randomization Problems ................................................................................................................................................ 8
Use care with signed variables ..................................................................................................................................................... 8
Random Generators ............................................................................................................................................................................... 9
Pseudorandom number generators ........................................................................................................................................... 9
Random Stability — multiple generators ................................................................................................................................ 9
Random Stability — hierarchical seeding ............................................................................................................................... 9
Functional Coverage ........................................................................................................................................................................... 10
Coverage Types ................................................................................................................................................................................ 10
Code coverage .............................................................................................................................................................................. 10
Functional coverage .................................................................................................................................................................. 11
Bug rate ........................................................................................................................................................................................... 11
Assertion Coverage .................................................................................................................................................................... 11
Functional Coverage Strategies ..................................................................................................................................................... 12
Gather information, not data ...................................................................................................................................................... 12
Only measure what you are going to use .............................................................................................................................. 12
Measuring completeness ............................................................................................................................................................. 12
Simple Functional Coverage Example ......................................................................................................................................... 13
Anatomy of a Cover Group ............................................................................................................................................................... 14
Defining a cover group in a class .............................................................................................................................................. 14
Triggering a Cover Group ................................................................................................................................................................. 15
Sampling using a callback ............................................................................................................................................................ 15
Cover group with an event trigger ........................................................................................................................................... 16
Triggering on a SystemVerilog Assertion ............................................................................................................................. 16
Data Sampling ........................................................................................................................................................................................ 17
Individual bins and total coverage .......................................................................................................................................... 17
Creating bins automatically ........................................................................................................................................................ 17
Limiting the number of automatic bins created ................................................................................................................ 17
Sampling expressions .................................................................................................................................................................... 18
Naming the cover point bins ...................................................................................................................................................... 18
Conditional coverage ..................................................................................................................................................................... 18

www.bldeacet.ac.in Page | 2
21EC71 Advanced VLSI

Transition coverage........................................................................................................................................................................ 19
Wildcard states and transitions ................................................................................................................................................ 19
Ignoring values ................................................................................................................................................................................. 19
Illegal bins ........................................................................................................................................................................................... 19
Cross Coverage ...................................................................................................................................................................................... 20
Coverage Options ................................................................................................................................................................................. 21
Cover group comment ................................................................................................................................................................... 21
Per-instance coverage ................................................................................................................................................................... 21
Coverage threshold using at_least ........................................................................................................................................... 21
Printing the empty bins ................................................................................................................................................................ 21
Coverage goal .................................................................................................................................................................................... 22
Analyzing Coverage Data .................................................................................................................................................................. 23
Measuring Coverage Statistics During Simulation ................................................................................................................ 24

www.bldeacet.ac.in Page | 3
21EC71 Advanced VLSI

RANDOMIZATION
As designs grow larger, it becomes more difficult to create a complete set of stimuli
needed to check their functionality. You can write a directed testcase to check a certain set of
features, but you cannot write enough directed testcases when the number of features keeps
doubling on each project.

The solution is to create testcases automatically using constrained-random tests

(CRT). A directed test finds the bugs you think are there, but a CRT finds bugs you never
thought about, by using random stimulus. You restrict the test scenarios to those that are both
valid and of interest by using constraints. A CRT environment needs not only to create the
stimulus but also to predict the result, using a reference model, transfer function, or other
techniques.

A CRT is made of two parts:

1. the test code that uses a stream of random values to create input to the DUT,

2. a seed to the pseudo-random number generator (PRNG),

WHAT TO RANDOMIZE
When you think of randomizing the stimulus to a design, the first thing that you might
think of is the data fields. This stimulus is the easiest to create – just call $random. The
problem is that this gives a very low payback in terms of bugs found. The primary types of
bugs found with random data are data path errors, perhaps with bit-level mistakes. You need
to find bugs in the control logic.

You need to think broadly about all design input such as the following.

�Device configuration

�Environment configuration

�Primary input data

�Encapsulated input data

�Protocol exceptions

�Delays

�Transaction status

�Errors and violations

Device and environment configuration: What is the most common reason why bugs
are missed during testing of the RTL design? Not enough different configurations are tried.
Most tests just use the design as it comes out of reset, or apply a fixed set of initialization
vectors to put it into a known state. You should randomize the entire environment

www.bldeacet.ac.in Page | 4
21EC71 Advanced VLSI

configuration, including the length of the simulation, number of devices, and how they are
configured. Of course you need to create constraints to make sure the configuration is legal.

Input data: When you read about random stimulus, you probably thought of taking a
transaction such as a bus write or ATM cell and filling the data fields with random values.
You need to anticipate any layered protocols and error injection, plus scoreboarding and
functional coverage.

Protocol exceptions, errors, and violations: Look at all the errors that can occur.
What happens if a bus transaction does not complete? If an invalid operation is encountered?
Does the design specification state that two signals are mutually exclusive? Drive them both
and make sure the device continues to operate. It is frustrating to spend hours tracking back
through code trying to find the root of a malfunction, especially when you could have caught
it close to the source with a simple assertion.

Delays and synchronization: How fast should your testbench send in stimulus?
Always use constrained random delays to help catch protocol bugs. Try to coordinate the
various drivers so they can communicate at different relative timing.

Parallel random testing : You need to plan how to organize your files to handle
multiple simulations. Each job creates a set of output files such as log files and functional
coverage data. You can run each job in a different directory, or you can try to give a unique
name to each file.

www.bldeacet.ac.in Page | 5
21EC71 Advanced VLSI

RANDOMIZATION IN SYSTEMVERILOG
The random stimulus generation in SystemVerilog is most useful when used with
OOP. You first create a class to hold a group of related random variables, and then have the
random-solver fill them with random values. Note that you can randomize individual
variables, but this case is the least interesting. True constrained-random stimuli is created
at the transaction level, not one value at a time.

SIMPLE CLASS WITH RANDOM VARIABLES

Example 6-1 shows a class with random variables, constraints, plus testbench code to
use this class. This class has four random variables. The first three use the rand modifier,
so that every time you randomize the class, the variables are assigned a value. The kind
variable is randc, which means random cyclic, so that the random solver does not repeat a
random value until every possible value has been assigned.

Note that the constraint expression is grouped using curly braces: {}. This is because
this code is declarative, not procedural, which uses begin...end.

CHECKING THE RESULT FROM RANDOMIZE

Randomization can fail if your code has conflicting constraints (see next section), so
you should always check the status.If it fails, randomize returns 0. The assertion checks the
result and prints an error if there was a failure. You should set your simulator’s switches to
terminate when an error is found.

THE CONSTRAINT SOLVER

The process of solving constraint expressions is handled by the System-Verilog
constraint solver. The solver chooses values that satisfy the constraints. The values come
from SystemVerilog’s PRNG, that is started with an initial seed. If you give a SystemVerilog
simulator the same seed and the same testbench, it always produces the same results. The
solver is specific to the simulation vendor.

www.bldeacet.ac.in Page | 6
21EC71 Advanced VLSI

RANDOM SYSTEM FUNCTIONS

☀ $urandom( ) ☀ $random( ) ☀ $urandom_range( )

The system function $urandom provides a mechanism for generating pseudorandom

numbers. The function returns a new 32-bit random number each time it is called. The
number shall be unsigned.

variable = $urandom(seed);

The seed is an optional argument that determines the sequence of random numbers
generated. The seed can be an integral expression. for a particular seed, the same value will
get generated.

Example

bit [31:0] addr1;

bit [31:0] addr2;

bit [64:0] addr3;

bit [31:0] data;

addr1 = $urandom();

addr2 = $urandom(89);

addr3 = {$urandom(),$urandom()};

data = $urandom * 6;

$random() is same as $urandom() but it generates signed numbers.

The $urandom_range() function returns an unsigned integer within a specified range.

Example:

$urandom_range( int unsigned maxval, int unsigned minval = 0 );

addr1 = $urandom_range(30,20);

addr2 = $urandom_range(20); //takes max value as '0'

addr3 = $urandom_range(20,30); //considers max value as '30' and min value as '20'

www.bldeacet.ac.in Page | 7
21EC71 Advanced VLSI

COMMON RANDOMIZATION PROBLEMS

You may be comfortable with procedural code, but writing constraints and
understanding random distributions requires a new way of thinking. Here are some issues
you may encounter when trying to create random stimulus.

USE CARE WITH SIGNED VARIABLES

When creating a testbench, you may be tempted to use the int, byte, or other signed
types for counters and other simple variables. Don’t use them in random constraints unless
you really want signed values. What values are produced when the class in Example 6-32 is
randomized? It has two random variables and wants to make the sum of them 64.

Obviously, you could get pairs of values such as (32, 32) and (2, 62). But you could
also see (-64, 128), as this is a legitimate solution of the equation, even though it may not be
what you wanted. To avoid meaningless values such as negative lengths, use only unsigned
random variables.

Even this version causes problems, as large values of pkt1_len and pkt2_len, such as
32’h80000040 and 32’h80000000, wrap around when added together and give 32’d64 /
32’h40. You might think of adding another pair of constraints to restrict the values of these
two variables, but the best approach is to make them only as wide as needed, and to avoid
using 32- bit variables in constraints.

www.bldeacet.ac.in Page | 8
21EC71 Advanced VLSI

RANDOM GENERATORS
How random is SystemVerilog? On the one hand, your testbench depends on an
uncorrelated stream of random values to create stimulus patterns that go beyond any
directed test. On the other hand, you need to repeat the patterns over and over during debug
of a particular test, even if the design and testbench make minor changes.

PSEUDORANDOM NUMBER GENERATORS

Verilog uses a simple PRNG that you could access with the $random function. The
generator has an internal state that you can set by providing a seed to $random. All IEEE-
1364-compliant Verilog simulators use the same algorithm to calculate values.Example 6-57
shows a simple PRNG, not the one used by SystemVerilog.

The PRNG has a 32-bit state. To calculate the next random value, square the state to
produce a 64-bit value, take the middle 32 bits, then add the original value. You can see how
this simple code produces a stream of values that seem random, but can be repeated by
using the same seed value. SystemVerilog calls its PRNG for a new values for randomize
and randcase.

RANDOM STABILITY — MULTIPLE GENERATORS

Verilog has a single PRNG that is used for the entire simulation. What would happen
if SystemVerilog kept this approach? Testbenches often have several stimulus generators
running in parallel, creating data for the design under test. If two streams share the same
PRNG, they each get a subset of the random values. In SystemVerilog, there is a separate
PRNG for every object and thread. Changes to one object don’t affect the random values
seen by others.

RANDOM STABILITY — HIERARCHICAL SEEDING

Every object and thread have its own PRNG and unique seed. When a new object or
thread is started, its PRNG is seeded from its parent’s PRNG. Thus a single seed specified at
the start of simulation can create many streams of random stimulus, each distinct.

www.bldeacet.ac.in Page | 9
21EC71 Advanced VLSI

FUNCTIONAL COVERAGE
As designs become more complex, the only effective way to verify them thoroughly is
with constrained-random testing (CRT). Use a feedback loop to analyze the coverage results
and decide on which actions to take in order to converge on 100% coverage. Your first
choice is to run existing tests with more seeds; the second is to build new constraints. Only
resort to creating directed tests if absolutely necessary.

COVERAGE TYPES
Coverage is a generic term for measuring progress to complete design verification.
Your simulations slowly paint the canvas of the design, as you try to cover all of the legal
combinations.

Coverage

Code Functional Assertion

Bug Rate
Coverage Coverage Coverage

CODE COVERAGE
The easiest way to measure verification progress is with code coverage. Here you are
measuring how many lines of code have been executed (linecoverage), which paths through
the code and expressions have been executed (path coverage), which single-bit variables
have had the values 0 or 1 (toggle coverage), and which states and transitions in a state
machine have been visited (FSM coverage).

The reset logic was accidently left out. A code coverage tool would report that every
line had been exercised, yet the model was not implemented correctly.

www.bldeacet.ac.in Page | 10
21EC71 Advanced VLSI

FUNCTIONAL COVERAGE
The goal of verification is to ensure that a design behaves correctly in its real
environment, be that an MP3 player, network router, or cell phone. The design specification
details how the device should operate, while the verification plan lists how that functionality
is to be stimulated, verified, and measured. Consider what happens if a block of code is
missing from the design. Code coverage cannot catch this mistake, but functional coverage
can.

BUG RATE
An indirect way to measure coverage is to look at the rate at which fresh bugs are
found. You should keep track of how many bugs you found each week, over the life of a
project. The bug rate drops, hopefully to zero, as the design nears tape-out. However, just
because the bug rates approaches zero, you are not yet done. Every time the rate sags, it is
time to find different ways to create corner cases.

ASSERTION COVERAGE
Assertions are pieces of declarative code that check the relationships between design
signals, either once or over a period of time. These can be simulated along with the design
and testbench, or proven by formal tools.

Sometimes you can write the equivalent check using SystemVerilog procedural code,
but many assertions are more easily expressed using SystemVerilog Assertions (SVA).

www.bldeacet.ac.in Page | 11
21EC71 Advanced VLSI

FUNCTIONAL COVERAGE STRATEGIES

Before you write the first line of test code, you need to anticipate what are the key
design features, corner cases, and possible failure modes. This is how you write your
verification plan. Don’t think in terms of data values only; instead, think about what
information is encoded in the design.

GATHER INFORMATION, NOT DATA

Design signals with a large range (more than a few dozen possible values) should be
broken down into smaller ranges, plus corner cases. For example, your DUT may have a 32-
bit address bus, but you certainly don’t need to collect 4 billion samples. Check for natural
divisions such as memory and IO space. For a counter, pick a few interesting values, and
always try to rollover counter values from all 1’s back to 0.

ONLY MEASURE WHAT YOU ARE GOING TO USE

Gathering functional coverage data can be expensive, so only measure what you will
analyze and use to improve your tests. Your simulations may run slower as the simulator
monitors signals for functional coverage, but this approach has lower overhead than
gathering waveform traces and measuring code coverage. Once a simulation completes, the
database is saved to disk. With multiple testcases and multiple seeds, you can fill disk drives
with functional coverage information. But if you never look at the final coverage reports,
don’t perform the initial measurements.

MEASURING COMPLETENESS
Your manager constantly asks you, ―Are we there yet?‖ How can you tell if you have
fully tested a design? You need to look at all coverage measurements and consider the bug
rate to see if you have reached your destination.

At the start of a project, both code and functional coverage are low. As you develop
tests, run them over and over with different random seeds until you no longer see increasing
values of functional coverage.

www.bldeacet.ac.in Page | 12
21EC71 Advanced VLSI

SIMPLE FUNCTIONAL COVERAGE EXAMPLE

To measure functional coverage, you begin with the verification plan and write an
executable version of it for simulation. In your SystemVerilog test-bench, sample the values
of variables and expressions. These sample locations are known as cover points.

The following design has a transaction that comes in eight flavors. The testbench
generates the port variable randomly, and the verification plan requires that every value be
tried. As you can see, the testbench generated the values 1, 2, 3, 4, 5, 6, and 7, but never
generated a port of 0. For this example, the very next random transaction (#33) has a port
value of 0, giving 100% coverage.

www.bldeacet.ac.in Page | 13
21EC71 Advanced VLSI

ANATOMY OF A COVER GROUP

A cover group is similar to a class — you define it once and then instantiate it one or
more times. It contains cover points, options, formal arguments, and an optional trigger. A
cover group encompasses one or more data points, all of which are sampled at the same time.

A cover group can be defined in a class or at the program or module level. It can
sample any visible variable such as program/module variables, signals from an interface, or
any signal in the design (using a hierarchical reference).

DEFINING A COVER GROUP IN A CLASS

A cover group can be defined in a program, module, or class. In all cases, you must
explicitly instantiate it to start sampling. If the cover group is defined in a class, you do not
make a separate name when you instance it; you just use the original cover group name.

Example 9-5 is very similar to the first example of this chapter except that it embeds a
cover group in a transactor class, and thus does not need a separate instance name.

www.bldeacet.ac.in Page | 14
21EC71 Advanced VLSI

TRIGGERING A COVER GROUP

The two major parts of functional coverage are the sampled data values and the time
when they are sampled. When new values are ready (such as when a transaction has
completed), your testbench triggers the cover group.

This can be done directly with the sample task, as shown in Example 9-5, or by using
a blocking expression in the covergroup definition. The blocking expression can use a wait or
@ to block on signals or events.

SAMPLING USING A CALLBACK

One of the better ways to integrate functional coverage into your testbench is to use
callbacks, This technique allows you to build a flexible testbench without restricting when
coverage is collected. You can decide for every point in the verification plan where and when
data is sampled. And if you need an extra ―hook‖ in the environment for a callback, you can
always add one

Make your own extension, Driver_cbs_coverage, of the base callback class,

Driver_cbs, to call the sample task for your cover group in post_tx. Push an instance of the
coverage callback class into the driver’s callback queue, and your coverage code triggers the
cover group at the right time. The following two examples define and use the callback
Driver_cs_coverage.

www.bldeacet.ac.in Page | 15
21EC71 Advanced VLSI

COVER GROUP WITH AN EVENT TRIGGER

In Example 9-8, the cover group CovPort is sampled when the testbench triggers the
trans_ready event. The advantage of using an event over calling the sample routine directly
is that you may be able to use an existing event such as one triggered by an assertion.

TRIGGERING ON A SYSTEMVERILOG ASSERTION

If you already have a SVA that looks for useful events like a complete transaction, you
can add an event trigger to wake up the cover group.

www.bldeacet.ac.in Page | 16
21EC71 Advanced VLSI

DATA SAMPLING
How is coverage information gathered? When you specify a variable or expression in
a cover point, SystemVerilog creates a number of ―bins‖ to record how many times each
value has been seen. These bins are the basic units of measurement for functional coverage.
If you sample a one-bit variable, a maximum of two bins are created.

INDIVIDUAL BINS AND TOTAL COVERAGE

To calculate the coverage for a point, you first have to determine the total number of
possible values, also known as the domain. There may be one value per bin or multiple
values. Coverage is the number of sampled values divided by the number of bins in the
domain.

A cover point that is a 3-bit variable has the domain 0:7 and is normally divided
into eight bins. If, during simulation, values belonging to seven bins are sampled, the
report will show 7/8 or 87.5% coverage for this point.

CREATING BINS AUTOMATICALLY

SystemVerilog automatically creates bins for cover points. It looks at the domain of
the sampled expression to determine the range of possible values.

LIMITING THE NUMBER OF AUTOMATIC BINS CREATED

The cover group option auto_bin_max specifies the maximum number of bins to
automatically create, with a default of 64 bins. If the domain of values in the cover point
variable or expression is greater than this option, SystemVerilog divides the range into
auto_bin_max bins. For example, a 16-bit variable has 65,536 possible values, so each of
the 64 bins covers 1024 values.

The following code takes the chapter’s first example and adds a cover point option
that sets auto_bin_max to two bins. The sampled variable is still port, which is three bits
wide, for a domain of eight possible values. The first bin holds the lower half of the range,
0–3, and the other hold the upper values, 4–7.

www.bldeacet.ac.in Page | 17
21EC71 Advanced VLSI

SAMPLING EXPRESSIONS
You can sample expressions, but always check the coverage report to be sure you are
getting the values you expect. You may have to adjust the width of the computed expression,
as shown in section 2.15. For example, sampling a 3-bit header length (0:7) plus a 4-bit
payload length (0:15) creates only 24 or 16 bins, which may not be enough if your
transactions can actually be 0:23 bytes long.

NAMING THE COVER POINT BINS

Automatically generated bins are okay for anonymous data values, such as counter
values, addresses, or values that are a power of 2. For other values, you should explicitly
name the bins to improve accuracy and ease coverage report analysis. SystemVerilog
automatically creates bin names for enumerated types, but for other variables you need to
give names to the interesting states.

The easiest way to specify bins is with the [] syntax.

CONDITIONAL COVERAGE
You can use the iff keyword to add a condition to a cover point.

www.bldeacet.ac.in Page | 18
21EC71 Advanced VLSI

TRANSITION COVERAGE
You can specify state transitions for a cover point. In this way, you can tell not only
what interesting values were seen but also the sequences. For example, you can check if port
ever went from 0 to 1, 2, or 3.

WILDCARD STATES AND TRANSITIONS

You use the wildcard keyword to create multiple states and transitions. Any X, Z, or ?
in the expression is treated as a wildcard for 0 or 1. The following creates a cover point with
a bin for even values and one for odd.

IGNORING VALUES
With some cover points, you never get all possible values. For instance, a 3-bit
variable may be used to store just six values, 0–5. If you use automatic bin creation, you
never get beyond 75% coverage. There are two ways to solve this problem. You can explicitly
define the bins that you want to cover. Alternatively, you can let SystemVerilog automatically
create bins, and then use ignore_bins to tell which values to exclude from functional
coverage calculation.

ILLEGAL BINS
Some sampled values not only should be ignored, but also should cause an error if
they are seen. This is best done in the testbench’s monitor code, but can also be done by
labeling a bin with illegal_bins.

www.bldeacet.ac.in Page | 19
21EC71 Advanced VLSI

CROSS COVERAGE
A cover point records the observed values of a single variable or expression. You may
want to know not only what bus transactions occurred but also what errors happened during
those transactions, and their source and destination.

For this you need cross coverage that measures what values were seen for two or
more cover points at the same time. Note that when you measure cross coverage of a variable
with N values, and of another with M values, SystemVerilog needs NxM cross bins to store
all the combinations.

The cross construct in SystemVerilog records the combined values of two or more
cover points in a group.

Example 9-28 creates cover points for tr.kind and tr.port. Then the two points are
crossed to show all combinations. SystemVerilog creates a total of 128 (8 x 16) bins. Even a
simple cross can result in a very large number of bins.

www.bldeacet.ac.in Page | 20
21EC71 Advanced VLSI

COVERAGE OPTIONS
You can specify additional information in the cover group using options. Options can
be placed in the cover group so that they apply to all cover points in the group, or they can
be put inside a single cover point for finer control. You have already seen the auto_bin_max
option. Here are several more.

COVER GROUP COMMENT

You can add a comment into coverage reports to make them easier to analyze.

PER-INSTANCE COVERAGE
If your testbench instantiates a coverage group multiple times, by default
SystemVerilog groups together all the coverage data from all the instances. But you may
have several generators, each creating very different streams of transactions, so you may
want to see separate reports.

COVERAGE THRESHOLD USING AT_LEAST

You may not have sufficient visibility into the design to gather robust coverage
information. you could set option.at_least to 8 or more to specify that after 8 hits on a bin,
you are confident that you have exercised that combination.

PRINTING THE EMPTY BINS

By default, the coverage report shows only the bins with samples. You are actually
more interested in the bins without samples. Use the option cross_num_print_missing to tell
the simulation and report tools to show you all bins, especially the ones with no hits. Set it to
a large value, as shown in Example 9-39, but no larger than you are willing to read.

www.bldeacet.ac.in Page | 21
21EC71 Advanced VLSI

COVERAGE GOAL
The goal for a cover group or point is the level at which the group or point is
considered fully covered. The default is 100% coverage.12 If you set this level below 100%,
you are requesting less than complete coverage, which is probably not desirable. This option
affects only the coverage report.

www.bldeacet.ac.in Page | 22
21EC71 Advanced VLSI

ANALYZING COVERAGE DATA

In general, assume you need more seeds and fewer constraints. After all, it is easier to
run more tests than to construct new constraints. If you are not careful, new constraints can
easily restrict the search space.

If your cover point has only zero or one sample, your constraints are probably not
targeting these areas at all. You need to add constraints that ―pull‖ the solver into new
areas. In Example 9-15, the transaction length had an uneven distribution. This situation is
similar to the distribution seen when you roll two dice and look at the total value.

The problem with this class is that len is not evenly weighted. If you want to make
total length be evenly distributed, use a solve...before constraint.

The alternative to solve...before is the dist constraint. But it is not effective, as len is
also being constrained by the sum of the two lengths.

www.bldeacet.ac.in Page | 23
21EC71 Advanced VLSI

MEASURING COVERAGE STATISTICS DURING SIMULATION

You can query the level of functional coverage on the fly during simulation by using
the get_coverage and get_coverage_inst functions. This approach allows you to check
whether you have reached your coverage goals, and possibly to control a random test.

The most practical use for these functions is to monitor coverage over a long test. If
the coverage level does not advance after a given number of transactions or cycles, the test
should stop. Hopefully, another seed or test will increase the coverage.

End of Module 5 Notes

Best of Luck

www.bldeacet.ac.in Page | 24