Advanced VLSI(21EC71)

By
Dr. Parameshwara M. C.
Associate Professor & HoD, Department of ECE,
Vemana Institute of Technology, Koramangala,
Bengaluru-560034

Prof. Parameshwara M. C. Dept. of ECE, Vemana IT, Bangalore 1

 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.

Dept. of ECE, Vemana IT, Bangalore 2

 What to Randomize?
Randomizing the stimulus:
• The data fields using $random function
• It will result in low payback in terms of bugs found.
• You can find only data-path bugs.
• The challenging bugs are in the control logic
• Hence it is required to randomize all decision points in your DUT
• Device configuration
• Environment configuration
• Primary input data
• Encapsulated input data
• Protocol exceptions
• Delays
• Transaction status
• Errors and violations

Dept. of ECE, Vemana IT, Bangalore 3

 What to Randomize?
Randomizing the stimulus:
Device configuration
• What is the most common reason why bugs are missed during testing of the RTL design?
• Not enough different configurations have been 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.
Environmental configuration
• The device that you are designing operates in an environment containing other devices.
• When you are verifying the DUT, it is connected to a testbench that mimics this environment.
• You should randomize the entire environment, including the number of objects and how they are configured.
Primary Input Data
• Take a transaction such as a bus write or ATM cell and fill it with some random values.
• This requires proper preparation of transaction classes.
Encapsulated input data
• Many devices process multiple layers of stimulus.
• TCP traffic that is then encoded in the IP protocol, and finally sent out inside Ethernet packets.
• Each level has its own control fields that can be randomized to try new combinations.

Dept. of ECE, Vemana IT, Bangalore 4

 What to Randomize?
Randomizing the stimulus:
Protocol exceptions, errors, and violations
• The most challenging part of design and verification is how to handle errors in the system
• You need to anticipate all the cases where things can go wrong, inject them into the system, and make sure the design
handles them gracefully, without locking up or going into an illegal state.
Delays
• Many communication protocols specify ranges of delays.
• The bus grant comes one to three cycles after request.
• Data from the memory is valid in the fourth to tenth bus cycle.
• Your testbench should always use random, legal delays during every test to try to find that (hopefully) one combination
that exposes a design bug.

Dept. of ECE, Vemana IT, Bangalore 5

Randomization in System Verilog:

Dept. of ECE, Vemana IT, Bangalore 6

 Random number functions:
• Sometimes you need to perform an action immediately before every
randomize call or immediately afterwards.
• SystemVerilog lets you do this with two special void functions,
pre_randomize and post_randomize.
• Verilog has several functions for nonlinear distribution such as
$dist_exponential.

Dept. of ECE, Vemana IT, Bangalore 7

 Random number functions:
• For some applications, you want a nonlinear random distribution. For instance, small
and large packets are more likely to find a design bug such as buffer overflow than
medium-sized packets.
• So you want a bathtub shaped distribution; high on both ends, and low in the middle.

Dept. of ECE, Vemana IT, Bangalore 8

Random number functions:

Dept. of ECE, Vemana IT, Bangalore 9

Random number functions:

Dept. of ECE, Vemana IT, Bangalore 10

 Common randomization problems:
• We may be comfortable with procedural code, but writing constraints and understanding random
distributions requires a new way of thinking.
• Here are some issues we 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?
• We get pairs of values such as (32, 32) and (2, 62). But you could also see (-64, 128).

Dept. of ECE, Vemana IT, Bangalore 11

 Common randomization problems:
Use care with signed variables Contd..
• 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.

Dept. of ECE, Vemana IT, Bangalore 12

 Random Number 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 test-bench 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.

Dept. of ECE, Vemana IT, Bangalore 13

 Random Number Generators:
Pseudorandom number generators
• 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.

Dept. of ECE, Vemana IT, Bangalore 14

 Random Number Generators:
Random Stability — multiple generators
• Verilog has a single PRNG that is used for the entire simulation.
• In System Verilog 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.

Dept. of ECE, Vemana IT, Bangalore 15

 Random Number Generators:
Random Stability — multiple generators

Dept. of ECE, Vemana IT, Bangalore 16

 Random Number Generators:
Random Stability — multiple generators

Dept. of ECE, Vemana IT, Bangalore 17

 Random Number Generators:
Random Stability — multiple generators
• 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.

Dept. of ECE, Vemana IT, Bangalore 18

 Functional Coverage: Coverage Types

• Coverage is a generic term for measuring progress to complete design verification.

• The coverage tools gather information during a simulation and then post-process it to
produce a coverage report.
• This report is used to look for coverage holes and then modify existing tests or create
new ones to fill the holes.
• This iterative process continues until you are satisfied with the coverage level.
• Functional coverage is a measure of which design features have been exercised by the
tests.

Dept. of ECE, Vemana IT, Bangalore 19

 Functional Coverage:
• Start with the design specification and create a verification plan with a detailed list of
what to test and how.
• 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.
• Use directed tests if absolutely necessary.

20
 Functional Coverage: Coverage Types
Code coverage
Code coverage measures how thoroughly your tests exercised the “implementation” of the
design specification, and not the verification plan.
• Line Coverage :how many lines of code have been executed.
• Path Coverage :which paths through the code and expressions have been executed.
• Toggle Coverage :which single-bit variables have had the values 0 or 1.
• FSM Coverage :which states and transitions in a state machine have been visited.
Functional coverage
• The goal of verification is to ensure that a design behaves correctly in its real
environment.
• Functional coverage is tied to the design intent and is sometimes called “specification
coverage”.
• Consider what happens if a block of code is missing from the design. Code coverage cannot
catch this mistake, but functional coverage can. 21
 Functional Coverage: Coverage Types
Bug rate
• It is an indirect way to measure coverage.
• It is based on the rate at which fresh bugs are found.
• You can keep track of how many bugs you found each week, over the life of a project.

Dept. of ECE, Vemana IT, Bangalore 22

 Functional Coverage: Coverage Types
Assertion Coverage
• Assertions are pieces of declarative code that check the relationships between design
signals, either once or over a period of time.
• These assertions can be simulated along with the design and testbench.
• Many assertions are more easily expressed using SystemVerilog Assertions (SVA).
• Assertions can have local variables and perform simple data checking.
• The most familiar assertions look for errors such as two signals that should be mutually
exclusive or a request that was never followed by a grant. These Assertions are coded
with the assert property statement.
• Some assertions might look for interesting signal values or design states, such as a
successful bus transaction. These are coded with the cover property statement.

Dept. of ECE, Vemana IT, Bangalore 23

 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.
• Gather information, not data.
• Only measure what you are going to use
• Measuring completeness
• 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.
• Create additional constraints and tests to explore new
areas.
• What if the functional coverage is high but the code
coverage is low? Your tests are not exercising the full
design, and you need to revise your verification plan
and add more functional coverage points to locate
24
untested functionality.