VDS Unit 5 UE19EC352 Org

VERIFICATION OF DIGITAL SYSTEMS
Sumanth Sakkara
Department of Electronics and Communication Engineering.
Course Code: UE19EC352

Course: Verification of Digital Systems
Mr. Sumanth Sakkara

Department of Electronics and Communication
Engineering.
Unit-5: Advanced Interfaces.

Topic: Virtual Interfaces with the ATM Router
Mr. Sumanth Sakkara

Engineering.
Virtual Interfaces with the ATM Router
Virtual Interfaces:
Example: A chip may have multiple configurations. In one, the pins might
drive a USB bus, whereas in another the same pins may drive an I2C serial
bus. In these cases you can use a virtual interface so you can decide at run
time which drivers to run in your testbench.
In SystemVerilog by using a virtual interface, which is merely a handle or

pointer to a physical interface. A better name for a virtual interface would be
a “ref interface.”
Virtual Interfaces:
The most common use for a virtual interface is to allow objects in a

testbench to refer to items in a replicated interface using a generic handle
rather than the actual name.
Virtual interfaces are the only mechanism that can bridge the dynamic
world of objects with the static world of modules and interfaces.
Virtual interface concept comes into the picture to use signals of interface. It is most
often used in classes to provide a connection point to allow classes to access the
signals in the interface through the virtual interface.
The Testbench with Just Physical Interfaces: ATM interfaces for the receive
directions
Rx interface with clocking block:

The Testbench with Just Physical Interfaces: ATM interfaces for the Transmit
Directions
Tx interface with clocking block:
The Testbench with Just Physical Interfaces:
 Rx_if and Tx_if interfaces can be used in a program block.
The top module does not pass a clock to the testbench; instead the tests
synchronize with clocking blocks in the interfaces, thus allowing you to work at a
higher level of abstraction.
Testbench using physical interfaces

The Testbench with Just Physical Interfaces

The testbench communicating with the design through virtual interfaces
The part of the testbench that captures cells

coming in from the TX port of the router.
Note that the interface names are hard-
coded, so you have to duplicate the same
code four times for the 4´4 ATM router. For
example, only the task receive_cell0 is
shown, and the fi nal code would also have
receive_ cell1, receive_cell2 , and
receive_cell30 .
Router and testbench without interfaces

The testbench communicating with the design through virtual interfaces
Router and testbench with interfaces

Top level module with array of interfaces
The module in example instantiates

an array of interfaces, and passes this
array to the testbench. Since the DUT
was written with four RX and four TX
interfaces, you need to pass the
individual interface array elements into
the DUT instance.
Testbench with Virtual Interfaces
A good OOP technique is to create a class that uses a handle to reference an

object, rather than a hard-coded object name.
The program block in example is still passed the 4 Rx and 4 Tx interfaces as

ports. But it creates an array of virtual interfaces, vRx and vTx . These can now
be passed into the constructors for the drivers and monitors.


 Alternative: You can also skip the virtual interface array variables, and make
an array in the port list. These interfaces are passed to the constructors as
shown in the example

The task monitor:: receive_cell in example is similar to the task receive_cell0 (used in previous
examples) , except it uses the virtual interface name Tx instead of the physical interface Tx0 .
Monitor class using virtual interfaces

The task monitor:: receive_cell in example is similar to the task receive_cell0 (used in previous
examples) , except it uses the virtual interface name Tx instead of the physical interface Tx0 .
Contd….Monitor class using virtual interfaces



Unit-5: Advanced Interfaces.

Topic2: Virtual Interfaces with the ATM Router
Mr. Sumanth Sakkara

Engineering.
Connecting the Testbench to an Interface in Port List
Example connects the DUT and test using an interface in the port list.
Example program block Test with an interface in the port list
Example Top module having two interfaces in the port list:

Example program block Test with an two interfaces in the port list
Connecting the Test to an Interface with an XMR
Test needs to connect to the physical interface in the harness , so use a cross
module reference (XMR) and a virtual interface in the program block.
Use a virtual interface (virtual bus_ifc bus) so you can assign it the
physical interface in the top level module (top.bus).
Program connects to the test harness
Test code more reusable

If you add a new interface to your design, the test harness changes,
but existing tests don’t have to change
Test code for this top module with XMR

If you add a new interface to your design, the test program.
You won’t have to modify existing tests, even if the design changes., hence reusable
Connecting to Multiple Design Configurations
To verifying a design is that it may have several configurations. You could make a
separate testbench for each configuration, instead use virtual interfaces to
dynamically connect to the optional interfaces.
A Mesh Design:
Consider an 8-bit counter. This resembles a DUT that has a device such as a
network chip or processor that is instantiated repeatedly in a mesh
configuration.
The key idea is that the top-level module creates an array of interfaces and
counters.
The testbench can connect its array of virtual interfaces to the physical
ones.
Interface example for 8-bit counter
If the code printed the signal values

with a $monitor, they would
display when any signal changed.
Instead, the always block waits
until the clocking block changes,
then prints the values of the signals
at the end of the time slot with
$strobe
Simple Counter model using X_if interface (Design program)

Connecting to Multiple Design Configurations:
Top-level module
Top-level module with an array of

virtual interfaces: uses a generate
statement to instantiate
NUM_XI interfaces and counters, but
only one testbench
The key line in the testbench is

where the local virtual interface
array, vxi , is assigned to point to the
array of physical interfaces in the top
module, top.xi .
Ex: Driver class is used

The testbench assumes there is at least one

counter and thus at least one X interface.
In this simple example, you could just pass

the interface (vxi[ ]) directly into the Driver’s
constructor, rather than make a separate
variable

Driver class using virtual interfaces
Using Typedefs with Virtual Interfaces
The correct modport by

replacing “ virtual X_if.TB
” with a typedef vx_if


Passing Virtual Interface Array Using a Port
Testbench using an array of virtual interfaces
The previous examples passed the array of

virtual interfaces using a cross module
reference (XMR). An alternative is to pass
the array in a port. Since the array in the
top module is static and so only needs to
be referenced once,
Global parameter to define the number of

X interfaces
Passing Virtual Interface Array Using a Port
Testbench passing virtual

interfaces with a port
It creates an array of virtual

interfaces so that it can pass
them into the constructor for
the driver class, or just pass
the interface directly from the
port
Procedural Code in an Interface
A class contains both variables and routines, similarly an interface can contain code
(procedural code) such as routines (task), assertions, and initial and always blocks .
Interface includes the signals and functionality of the communication between two blocks.
(modport, task, etc)
The inner workings of these routines are hidden from the external blocks
Access to these routines is controlled using the modport statement, just as with signals. A
task or function is imported into a modport so that it is then visible to any block that uses the
modport .
Procedural Code in an Interface
These routines can be used by both the design and the testbench. Hence same protocol.
If only one person implements the interface protocol for both parts, who checks it? You can
verify a protocol with assertions in an interface.
An assertion can check for illegal combinations, such as protocol violations and unknown
values.
Functional coverage code uses this type of assertion to trigger the gathering of coverage
information also.
Interface with Parallel Protocol
The interface has two tasks,

initiatorSend and targetRcv , that
send a transaction between two
blocks using the interface signals.
It sends the address and data in

parallel across two 8-bit buses.
Interface with Parallel Protocol
The interface in has two tasks,

initiatorSend and targetRcv , that
send a transaction between two
blocks using the interface signals.
It sends the address and data in

parallel across two 8-bit buses.
Interface with Serial Protocol
The interface implements a serial

interface for sending and receiving
the address and data values.
It has the same interface and

routine names as previous
example.
Interface with Serial Protocol

The two protocols can swap without having to change any design or testbench
code.
Limitations of Interface Code

Tasks in interfaces are fine for RTL, where the functionality is strictly defined.
However, these tasks are a poor choice for any type of verification IP.
 Interfaces and their code cannot be extended, overloaded, or dynamically

instantiated based on configuration.
An interface cannot have private data. Any code for verification needs
maximum flexibility and configurability, and so should go in classes that run in a
program block.
An interface can have routines that drive the signals and assertions to check
the protocol, but put the test in a program block, not an interface.
A Complete SystemVerilog Testbench
Overall connection between the design and testbench


Block diagram for the squat design
The top level of the design is called
squat design. The module has 1..N
Utopia Rx interfaces that are sending
UNI formatted cells.
Inside the DUT, cells are stored,

converted to NNI format, and
forwarded to the Tx interfaces.
The forwarding is done according to a

lookup table that is addressed with the Utopia: Universal Test and Operations Interface for ATM
VPI field of the incoming cell. UNI: User Network Interface
NNI: Network Node Interface
The table is programmed through the VPI : Virtual Path Identifier
management interface.
The top level module, defines arrays

of interfaces for the Rx and Tx ports.
Testbench program
The testbench program passes
the interfaces and signals
through the port list.
Ports vs. cross module

references.
The actual testbench code is in

the Environment class.
The testbench loads control

information into the ATM switch through
the Management interface, also known
as the CPU interface.
The cpu_ifc interface is only used to

load the lookup table that maps VPI to
forwarding masks.
The Utopia interface, which is

used by the testbench to
communicate with the squat design
by transmitting and receiving ATM
cells.
Modports for the design and

testbench connections to the
interface.
The interface has clocking blocks

for the transmit and receive
paths, and modports for the
design and testbench
connections to the interface.
Testbench Blocks
The environment class:
Inside this class lies the blocks of your layered testbench, such as generators, drivers,
monitors, and scoreboard.
The environment class controls the sequencing of the four testbench steps: generate a
random configuration, build the testbench environment, run the test and wait for it to
complete, and a wrap_up phase to shut down the system and generate reports.
Environment class
 The environment class controls the sequencing
of the four testbench steps: generate a random
configuration, build the testbench environment,
run the test and wait for it to complete, and a
wrap_up phase to shut down the system and
generate reports.
Example shows the ATM environment class. It

uses the virtual interface vCPU_T defined in
previous example.
VERIFICATION OF VLSI CIRCUITS USING SYSTEMVERILOG
SV Testbench Environment
SV Testbench Environment Simulation

Ex: Half Adder
56
57
Layered Testbench
58
DUT: Half Adder Example (output s,c, input a,b)
Packet class is also known as transaction class
Packet
We declare all the input and output signals available in the design in
the packet class
The inputs will be declared as rand
60
Packet
61
Generator: 1) The generator will randomize the input signals
2) The randomized inputs are put into the mailbox using the put method .put()
62
Generator
63
Mailbox: Used to pass the information from one class to another class
Driver: The Driver drives the stimulus into the DUT through interface
DUT & Interface

Interface is the bunch of signals that
connect the TB to DUT
64
Virtual Interface
65
Driver
vif is a handle of virtual interface
66
Monitor
The DUT receives the stimulus & generates the outputs
The outputs are sampled/collected in the monitor
67
Monitor
68
Reference Model
The RM is similar to DUT (Design Team) but created by the verification team
Sometimes RM will be written inside the score board
Only inputs are

sampled in monitor 1
Only outputs are

69
Scoreboard
It is a comparator used to compare the output from the RM and the DUT
Only inputs are

Only outputs are

70
Scoreboard
71
72
73
74
UNIT-5
Topic : Interfacing with C/C++
Mr. Sumanth Sakkara

Engineering.
Interfacing with C/C++
 In Verilog, you can communicate with C routines using the Programming Language Interface
(PLI).
 If you just want to connect a simple C routine using the PLI, you need to write dozens of lines
of code and it overheads your simulation as it copies data between the Verilog.
The SystemVerilog introduces Direct Programming Interface (DPI) which is basically an

interface between SystemVerilog and a foreign programming language, in particular the C
language.
Functions implemented in C can be called from SystemVerilog using import "DPI"

declarations. (Imported tasks and functions)
 It allows the designer to easily call C functions from SystemVerilog and to export
SystemVerilog functions, so that they can be called from C.
 Currently SystemVerilog only supports an interface to the C language. C++ code has to be
wrapped to look like C.
Example: System Verilog and C program. DPI
module Bus(input In1, output Out1);

import "DPI" function void slave_write (input int address,
input int data);
export "DPI" function write; extern void write(int, int); // Imported
from SystemVerilog
// This SystemVerilog function could be called from C void slave_write(const int I1, const int
function void write(int address, int data); I2)
// Call C function {
slave_write(address, data); // Arguments passed by copy buff[I1] = I2;
endfunction ...
... }
endmodule
 Passing Simple Values :

(i) Passing Integer and Real Values
The most basic data type that you can pass between SystemVerilog and C is an int ,
the 2-state, 32-bit type.
SystemVerilog code calling C factorial routine
C factorial function

(i) Passing Integer and Real Values
Import statement declares that a SystemVerilog routine factorial is implemented in
a foreign language such as C.
The modifier "DPI-C" specifies that this is a Direct Programing Interface routine
32-bit signed values are passed using the SystemVerilog int data type that maps
directly to the C int type.
The SystemVerilog int is always 32 bits, whereas the width of an int in C is operating
system dependent. The C function takes an integer as an input and so the DPI passes
the argument by value.

(ii) The Import Declaration
The Import declaration defines the prototype of the C task or function, but using SystemVerilog
types.
C function with a return value is mapped to a SystemVerilog function.
You can import routines anywhere in your SystemVerilog code where you can declare a routine
including inside programs, modules, interfaces, packages, and $unit , the compilation-unit space.
The imported routine will be local to the declaration space in which it is declared.
 If you need to call an imported routine in several locations in your code, put the import
statement in a package which you import where it is needed. Any changes to the import
statements are localized to the package.

If the name of the imported C function conflicts with a SystemVerilog name, you can import the
function with a new name.
The C function expect is mapped to the SystemVerilog name fexpect , as the name expect is a
reserved keyword in SystemVerilog.
The name expect becomes a global symbol, used to link with the C code, whereas fexpect is a
local SystemVerilog symbol.

Example: The C function stat is given a new name in SystemVerilog, file_exists .
 Argument Directions :
Imported C routines can have zero or more arguments.
By default the argument direction is input (data goes from SystemVerilog to C), but can also be
output and inout .
The direction ref is not supported.
A function can return a simple value such as an integer or real number, or have no return value if
you make it void .
A function can return a simple value such as an integer or real number, or have no return value if
you make it void .
C factorial routine with const argument

C factorial routine with const argument
You can reduce the chances of bugs in your C code by declaring any input arguments as const as
shown in below example, so the C compiler will give an error for any write to an input. .
Argument Types
Argument Types
Each variable that is passed

through the DPI has two
matching definitions: one for
the SystemVerilog side, and
one for the C side.
The C structures are defi

ned in the include file
svdpi.h .
Importing a Math Library Routine

Example shows how you can call many functions in the C math library directly,
without a C wrapper, thereby reducing the amount of code that you need to
write. The Verilog real type maps to a C double .
Example:
Create a C function, shift_c, that has two input arguments: a 32-bit unsigned input value i
and an integer for the shift amount n. The input i is shifted n places. When n is positive,
values are shifted left, when n is negative, shifted right, and when n is 0, no shift is
performed. The function returns the shifted value. Create a SystemVerilog module that
calls the C function and tests each feature. Provide the output.
Example:
Create a C function, shift_c, that has two input arguments: a 32-bit unsigned input value i and an
integer for the shift amount n. The input i is shifted n places. When n is positive, values are shifted
left, when n is negative, shifted right, and when n is 0, no shift is performed. The function returns
the shifted value. Create a SystemVerilog module that calls the C function and tests each feature.
Provide the output.
THANK YOU
Sumanth Sakkara
sumanthsakkara@pes.edu
+91 80 6666 3333 Ext 741
THANK YOU
Sumanth Sakkara
sumanthsakkara@pes.edu
+91 80 6666 3333 Ext 741

VDS Unit 5 UE19EC352 Org

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VDS Unit 5 UE19EC352 Org

Uploaded by

Copyright:

Available Formats

VERIFICATION OF DIGITAL SYSTEMS

Course Code: UE19EC352

Mr. Sumanth Sakkara

Unit-5: Advanced Interfaces.

Mr. Sumanth Sakkara

In SystemVerilog by using a virtual interface, which is merely a handle or

The most common use for a virtual interface is to allow objects in a

Rx interface with clocking block:

The Testbench with Just Physical Interfaces:

 Rx_if and Tx_if interfaces can be used in a program block.

Testbench using physical interfaces

The Testbench with Just Physical Interfaces

The testbench communicating with the design through virtual interfaces

The part of the testbench that captures cells

Router and testbench without interfaces

The testbench communicating with the design through virtual interfaces

Router and testbench with interfaces

Top level module with array of interfaces

The module in example instantiates

Testbench with Virtual Interfaces

A good OOP technique is to create a class that uses a handle to reference an

The program block in example is still passed the 4 Rx and 4 Tx interfaces as

Testbench with Virtual Interfaces

Testbench with Virtual Interfaces

Testbench with Virtual Interfaces

Testbench with Virtual Interfaces

Contd….Monitor class using virtual interfaces

Testbench with Virtual Interfaces

Testbench with Virtual Interfaces

Unit-5: Advanced Interfaces.

Mr. Sumanth Sakkara

Connecting the Testbench to an Interface in Port List

Connecting the Testbench to an Interface in Port List

Example program block Test with an interface in the port list

Example Top module having two interfaces in the port list:

Connecting the Testbench to an Interface in Port List

Connecting the Test to an Interface with an XMR

Connecting the Test to an Interface with an XMR

Program connects to the test harness

Test code more reusable

Connecting the Test to an Interface with an XMR

Test code for this top module with XMR

Connecting the Test to an Interface with an XMR

Connecting to Multiple Design Configurations

Connecting to Multiple Design Configurations

Interface example for 8-bit counter

If the code printed the signal values

Connecting to Multiple Design Configurations

Simple Counter model using X_if interface (Design program)

Connecting to Multiple Design Configurations:

Top-level module with an array of

Connecting to Multiple Design Configurations

The key line in the testbench is

Ex: Driver class is used

Connecting to Multiple Design Configurations

The testbench assumes there is at least one

In this simple example, you could just pass

Connecting to Multiple Design Configurations

Using Typedefs with Virtual Interfaces

The correct modport by

Using Typedefs with Virtual Interfaces

Using Typedefs with Virtual Interfaces

Passing Virtual Interface Array Using a Port