21EC71 : Advanced VLSI

Module 3: Verification Guidelines & Data Types

Prof. MANJUNATH E
Dept. of Electronics & Communication Engineering
Dr. T Thimmaiah Institute of Technology
Kolar Gold Fields
 3. 1 The Verification process
• The first step in the verification process is to prepare a verification plan which is
tightly coupled with the design specification.
• The verification process allows verification engineers to find bugs.
• RTL Designer write a code using HDL to meet spec.
• Its required to understand the input format, the transformation function, and output
format
• As a Verification engineer, must also read the hardware specification, create the
verification plan, and build tests showing the RTL code correctly implements the
features.
• The testbench is a setup or environment that allows verification (functional

21EC71
correctness) of DUT.

2
 Testing at different levels
• Block level — Easy to detect bugs, modules created by a single Person
• To simulate a single design block, low level simulation – run very fast, high
performance.
• Next level, find discrepancies at boundaries between blocks —because of
different interpretation
• At higher level — entire block is tested, simulation performance reduces.
• All I/0 ports are active, processors are crunching data, & caches are being
refilled.

21EC71
3
• Data alignment and timing bugs are sure to occur.
• Test DUT that executes multiple operations concurrently as many
blocks as possible are active.
• After confirming the DUT performance, need to check how it operates
with errors?
• Error injection and handling can be the most challenging part of
verification

** One can never prove there are no bugs left, always look
for new verification tactics.

21EC71
4
 3.2 Basic Testbench Functionality
The purpose of a testbench is to determine the correctness of the design under test (DUT).
This is accomplished by the following steps.

• Generate stimulus
• Apply stimulus to the DUT
• Capture the response

• Check for correctness

• Measure progress against the overall verification goals
Some steps are accomplished automatically by the testbench, while others are manually
determined by you. The methodology you choose determines how the above steps are
carried out.

21EC71
5
 3.3 Directed Testing
• Using this approach, you look at the hardware specification and write a
verification plan with a list of tests, each of which concentrated on a set of
related features
• Write stimulus vectors that exercise these features in the DUT
• Then simulate the DUT with these vectors and manually review the resulting
log files and waveforms to make sure the design does what you expect.
• Once the test works correctly, you check off the test in the verification plan
and move to the next.

• This incremental approach makes steady progress. It also produces almost immediate
results, since little infrastructure is needed when you are guiding the creation of every
stimulus vector. Given enough time and staffing, directed testing is sufficient to verify

21EC71
many designs.

6
 21EC71
7
 21EC71
8
 21EC71
9
 3.4 Methodology Basics
This method uses the following principles-
• Constrained-random stimulus
Constrained-random stimulus refers to generating input values
for the testbench in a random manner, but within defined
constraints or boundaries that ensure meaningful test cases.
• Functional coverage
Functional coverage measures how much of the design's
intended functionality has been tested. It ensures that all
expected behaviors and scenarios have been exercised by the

21EC71
test cases.

10
• Layered testbench using transactors
A layered testbench separates functionality into different layers,
typically including stimulus generation, signal transformation, and
communication with the design under test (DUT). Transactors are
components within these layers that handle specific tasks such as
protocol conversion or driving signals.
• Common testbench for all tests
A single, shared testbench infrastructure is used across all tests.
Rather than creating unique testbenches for each test case, this
approach centralizes common functionality
• Test-specific code kept separate from testbench
Code that is specific to an individual test is separated from the main
testbench code. This test-specific code could include unique

21EC71
constraints, parameters, or edge case scenarios that apply only to that
test.
11
 21EC71
12
3.5 Constrained-Random Stimulus
• Generate Random Input Value
• The values are sent into the design, and also into a high-level model that predicts
what the result should be. The design’s actual output is compared with the
predicted output.

21EC71
13
 21EC71
14
 21EC71
15
3.6 What Should you Randomize?

You need to think broadly about all design input,

such as following

1.Device & Environment configuration

2.Input Data
3.Protocol Exceptions, Errors and Violations
4.Delays and Synchronization
5.Parallel Random testing

21EC71
16
 3.7 Functional Coverage
The process of measuring and using functional coverage
consists of several steps.
First, you add code to the testbench to monitor the stimulus
going into the device, and its reaction and response, to
determine what functionality has been exercised.
Next, the data from one or more simulations is combined
into a report.
Lastly, you need to analyze the results and determine how to

21EC71
create new stimulus to reach untested conditions and logic

17
 21EC71
18
3.8 Testbench Components

21EC71
19
Flat Test Bench

21EC71
20
3.9 Layered Testbench

21EC71
21
 21EC71
22