Scribd
Upload
5 views12 pages

AVLSI (PRATHU Maa)

Uploaded by

snehachic48
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views12 pages

AVLSI (PRATHU Maa)

Uploaded by

snehachic48
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

RAJARAJESWARI COLLEGE OF ENGINEERING

Department Name: Electronics and Communication Engineering


Subject: Advanced VLSI
Subject Code: 21EC71

Seminar Topic: Testbench Components and Layered Testbench

Submitted By: Prathiksha N Subject Coordinator: Dr S M Vijaya


USN: 1RR21EC060
Testbench Components
❑In simulation, the testbench wraps around the DUT,
just as a hardware tester connects to a physical chip
as shown in figure .
❑Both the testbench and tester provide stimulus and
capture responses.
❑The difference between them is that your testbench
needs to work over a wide range of levels of abstraction, creating transactions
and sequences, which are eventually transformed into bit vectors.
❑A tester just works at the bit level.
What goes into that testbench block?
❑It is comprised of many Bus Functional Models (BFM), which you can think
of as testbench components — to the DUT they look like real components,
but they are part of the testbench, not the RTL design.
❑If the real device connects to AMBA, USB, PCI, and SPI buses, you have to
build equivalent components in your testbench that can generate stimulus and
check the response, as shown in Figure.
❑These are not detailed, synthesizable models,
but instead highlevel transactors that obey the
protocol, and execute more quickly.
❑On the other hand, if you are prototyping using
❑FPGAs or emulation, the BFMs do need to be
synthesizable.
Layered Testbench

❑ A key concept for any modern verifi cation methodology is the layered
testbench.
❑ Although this process may seem to make the testbench more complex, it
actually helps to make your task easier by dividing the code into smaller
pieces that can be developed separately.
❑ Don’t try to write a single routine that can randomly generate all types of
stimuli, both legal and illegal, plus inject errors with a multi-layer protocol.
❑ The routine quickly becomes complex and unmaintainable.
❑ In addition, a layered approach allows reuse and encapsulation of Verifi
cation IP (VIP) which are OOP concepts.
A Flat Testbench
The Signal and Command Layers
❑At the bottom is the signal layer that contains the design under test and the
signals that connect it to the testbench.
❑ The next higher level is the command layer.
❑The DUT’s inputs are driven by the driver that runs single commands, such
as bus read or write.
❑ The DUT’s output drives the monitor that takes signal transitions and groups
them together into commands.
❑ Assertions also cross the command/signal layer,
as they look at individual signals and also changes
across an entire command.
The Functional Layer
❑Figure shows the testbench with the functional layer added, which feeds
down into the command layer.
❑The agent block (called the transactor in the VMM) receives higher-level
transactions such as DMA read or write and breaks them into individual
commands or transactions.
❑These commands are also sent to the scoreboard that predicts the results of
the transaction. The checker compares the commands from the monitor
with those in the scoreboard.
The Scenario Layer
❑The functional layer is driven by the generator in the scenario layer, as
shown in Figure.
❑ What is a scenario? Remember that your job as a verification engineer is
to make sure that this device accomplishes its intended task.
❑An example device is an MP3 player that can concurrently play music
from its storage, download new music from a host, and respond to input
from the user, such as adjusting the volume and track controls.
❑Each of these operations is a scenario. Downloading a music file takes
several steps, such as control register reads and writes to set up the
operation, multiple DMA writes to transfer the song, and then another
group of reads and writes.
❑ Each of these operations is a scenario. Downloading a music file takes several steps, such as control register
reads and writes to set up the operation, multiple DMA writes to transfer the song, and then another group of
reads and writes.
❑ The scenario layer of your testbench orchestrates all these steps with constrained-random values for
parameters such as track size and memory location
The Test Layer and Functional Coverage
❑Design bugs that occur between DUT blocks are harder to find as they
involve multiple people reading and interpreting multiple
specifications.
❑This top-level test is the conductor: he does not play any musical
instrument, but instead guides the efforts of others.
❑The test contains the constraints to create the stimulus.
❑Functional coverage measures the progress of all tests in fulfilling the
verification plan requirements.
❑The functional coverage code changes through the project as the
various criteria complete.
❑This code is constantly being modified and thus it is not part of the
environment. You can create a directed test in a constrained-random
environment.
❑ This code is constantly being modified and thus it is not part of the environment. You can create a directed
test in a constrained-random environment.
❑ Simply insert a section of directed test code into the middle of a random sequence, or put the two pieces of
code in parallel.
❑ The directed code performs the work you want, but the random “background noise” may cause a bug to
become visible, perhaps in a block that you never considered.
THANK YOU

You might also like