A Literature

Review On
Verification of PCI bus using
Universal Verification Methodology (UVM).

in
M.E/M.TECH - (VLSI & ESD Design)
Guided by

Srikanth Jadcherla

Prepared by
Pithadiya Nayan V.
111060752029

Gujarat Technological University

Ahmadabad

Gujarat Technological University

Ahmadab
 Literature Review Report 201
3

ad
CERTIFICA
TE

This is to certify that Literature Review entitled Verification of PCI

bus using Universal Verification Methodology (UVM) was carried
out by Mr. Pithadiya Nayan Vijaykumar (111060752029) at GTU
PG School for partial fulfillment of M.E. degree to be awarded by
Gujarat Technological University. This research work has been carried
out under my supervision and is to the satisfaction of department. The
students work has been published for publication.

Date: 10/01/2013
Place: Ahmadabad

Guide:-

Prof. Srikanth Jadcherla

Chairman and CEO,
Seer Akademi (India),

Hyderabad GTU coordinator

Seal of Institute

Pithadiya Nayan Page 2

 ACKNOWLEDGEMENT

Apart from the effort of myself, the success of any task depends largely on the
encouragement and guidelines of many others. I take this opportunity to
express my gratitude to the people who have been instrumental in the
successful completion of this literature review. I would like to express my
deepest gratitude to Santosh Sir, Teaching Assistant, Seer-Akademi, without
his encouragement and guidance this literature review would not have
materialized. I would like to show my greatest appreciation to my external
guide Srikanth jadcherla, CEO, Seer Akademi. I can't thank him enough for his
tremendous support and help. I feel motivated and encouraged every time I
talked with him. I take immense pleasure in thanking Mr. Amaranth Sir,
Teaching Assistant (Seer-Akademi) and Mr. Karthik, Coordinator, GTU for
having permitted me to carry out this work and for all valuable assistance in the
literature review.

Table of Contents
Pithadiya Nayan Page 3
1. Problem Statement..........................................................................................................7
1.1 Objective....................................................................................................................7
1.2 Scope of thesis............................................................................................................7
1.3 Expected Outcome.....................................................................................................8
1.4 Motivation..................................................................................................................8
2. Introduction......................................................................................................................9
2.1 Introduction PCI bus..................................................................................................9
2.2 WISHBONE Slave Unit................................................................................................10
2.2.1 WISHBONE Slave Unit Architecture........................................................................10
2.2.1.1 WISHBONE Slave module............................................................................11
2.2.1.2 WBW_FIFO..................................................................................................11
2.2.1.3 WBR_FIFO....................................................................................................11
2.2.1.4 PCI MASTER Module..................................................................................11
2.3 PCI Target Unit.....................................................................................................11
2.3.1 PCI Target Unit Architecture..................................................................................12
2.3.1.1 PCI Target Module........................................................................................12
2.3.1.2 PCIW_FIFO..................................................................................................12
2.3.1.3 PCIR_FIFO....................................................................................................13
2.3.1.4 WISHBONE Master Module........................................................................13
2.4 Clocks...................................................................................................................13
2.5 FIFO........................................................................................................................13
2.6 Address Translation Logic....................................................................................15
2.6.1 Description of Address Translation Logic......................................................15
3. UVM................................................................................................................................17
3.1 UVM Verification Component Overview................................................................17
3.1.1 Data Item (Transaction)....................................................................................17
3.1.2 Driver (BFM)...................................................................................................17

3.1.3 Sequencer..........................................................................................................17
3.1.4 Monitor.............................................................................................................18
3.1.5 Agent.................................................................................................................19
3.1.6 Environment.....................................................................................................19
Pithadiya Nayan Page 4
 3.2 The UVM Class Library...........................................................................................21
3.3 Other UVM Facilities..............................................................................................21
3.3.1 UVM Factory...................................................................................................22
3.3.2 Transaction-Level Modeling (TLM).................................................................22
Proposed Solution..................................................................................................................24
Reference................................................................................................................................25

Table of Figures

Figure 1 PCI Bridge Core Architecture.....................................................................................9

Figure 2 WISHBONE Slave Unit Architecture......................................................................10
Figure 3 PCI Bus Target Unit Architecture.............................................................................12
Figure 4 Detailed description of FIFO Register line...............................................................13

Pithadiya Nayan Page 5

Figure 5 FIFO architecture......................................................................................................14
Figure 6 Block diagram of Address Translation Logic...........................................................16
Figure 7 Typical Verification Component Environment.........................................................20
Figure 8 UVM class Hierarchy...............................................................................................21

Pithadiya Nayan Page 6

 1. Problem Statement
Verification of PCI bus using Universal Verification Methodology (UVM)

1.1 Objective

a. Understand the architecture of the PCI bus and Wishbone Bridge

b. Learn the Universal Verification Methodology (UVM)

c. Verify the PCI bus design using Universal Verification Methodology (UVM)

1.2 Scope of thesis

The goal of the thesis is to verify the PCI bus using Universal Verification Methodology
(UVM).

This project is divided into three phases. First phase is to understand the PCI bus
architecture. Second phase is to understand the flow of UVM and learn UVM programming.
Final phase is to verify the PCI bus design. [1] [7]

First phase is to understand the PCI bus architecture and its operation. This is really main
part for verification because without understand the architecture and behaviour we arent
able to verify our design.

The Second phase is to understand UVM flow and learn the UVM programming. Thats
really challenging for me because to understand new methodology and implement some
design. UVM is latest methodology which is industrial standard today.so I choose to verify
my design with this methodology.

The third and final most phase is to verify the PCI bus design using UVM. In this I will write
some assertions. I will also try to make my coverage maximum as much as I can.

1.3 Expected Outcome

Pithadiya Nayan Page 7

 a. Verified PCI bus design using Universal Verification Methodology (UVM).

1.4 Motivation

Verification is used to confirm that the system, subsystem or component meets documented
requirements or specifications levied on the design. Verification takes huge time for any
design. Verification takes 60% of time in any design. So if your design will take 1 year than
verification will take 8 months from that one year. So you can understand the importance of
Verification.

Verification can be done using different kind of methodology like systemverilog, UVM,
OVM and VMM.

I choose the Universal Verification Methodology for verify my design because UVM is latest
and now a days very popular. Even it is industrial standard now. So I would like to learn it
and make my design using that methodology.

Pithadiya Nayan Page 8

 2. Introduction

2.1 Introduction to PCI bus

PCI Bridge consists of two units: PCI target unit and WISHBONE slave unit. Each unit
consists of its own set of functions to support bridging operations from WISHBONE to PCI
and from PCI to WISHBONE. WISHBONE slave unit acts as a slave on WISHBONE side
of the bridge and initiates transactions as a master on PCI bus. PCI target unit acts as a
target on PCI side of the bridge and as master on WISHBONE side. Both units operations
are independent of each other. PCI target unit implements target interface on PCI bus and
master interface on WISHBONE bus, while WISHBONE slave unit implements slave
interface on WISHBONE bus and master [1]

Figure 1 PCI Bridge Core Architecture

Pithadiya Nayan Page 9

2.2 WISHBONE Slave Unit
PCI bus is accessible from WISHBONE bus through WISHBONE slave unit. PCI address
space is accessed through two to five images. Each image is selected with address provided
on WISHBONE slaves module interface compared with base address masked with value of
address mask stored in WB slave configuration registers. Each image can be mapped to
memory or I/O space on PCI bus.
WB slave unit supports posted writes and pre-fetched reads in memory space, accesses to
I/O space are handled as single read or write transactions.
Posted writes are stored in WISHBONE Write FIFO (WBW_FIFO), pre-fetched reads are
stored in WISHBONE Read FIFO (WBR_FIFO).
WISHBONE slave unit connects to WISHBONE masters acting as a slave. This section
describes the architecture of WISHBONE slave unit and is divided into subsections.

2.2.1 WISHBONE Slave Unit Architecture

This section describes architecture of WISHBONE slave unit. Detailed description is
provided in following sections.

Figure 2 WISHBONE Slave Unit Architecture

WISHBONE slave unit consists of a few functional parts allowing WISHBONE master to
perform a Read/Write accesses to PCI bus.

2.2.1.1 WISHBONE Slave module

WISHBONE slave module is 32-bit WISHBONE slave interface as defined in
Pithadiya Nayan Page 10
WISHBONE specification Rev.1B. It includes three to six image units for address
translation from WISHBONE bus and therefore it handles Read/Write cycles to images of
PCI address space and configuration space accesses.

2.2.1.2 WBW_FIFO
WISHBONE slave module uses WBW_FIFO (WISHBONE WRITE FIFO) for posting
memory and I/O writes performed by WISHBONE master. Parameterized depth of
WBW_FIFO leaves system designer an option of defining it, regarding needs of particular
application for posting more or less writes.
Writing to WBW_FIFO is adapted to WISHBONE bus speed, while writing to PCI bus
from WBW_FIFO is adapted to PCI bus speed.

2.2.1.3 WBR_FIFO
WISHBONE slave module uses WBR_FIFO (WISHBONE READ FIFO) for storing data
read from PCI targets. Reading from PCI bus to WBR_FIFO is adapted to PCI bus
speed, while reading from WBR_FIFO is adapted to WISHBONE bus speed.

2.2.1.4 PCI MASTER Module

PCI MASTER Module is 32-bit/66MHz, PCI local bus specification Rev. 2.2 compliant
initiator interface. The core requests PCI bus through its PCI MASTER module. PCI
interface of the core is described in detail in Chapter 5-XY: PCI I/O interface description.

2.3 PCI Target Unit

WISHBONE bus is accessible to PCI agents through PCI target unit of the bridge. PCI
target unit provides two to five images of WISHBONE side memory space. Each of these
images is selected with address provided during address cycle on the PCI bus compared
with base address masked with mask value stored in PCI configuration registers. Each
image can be mapped into I/O or memory space.
Writes through PCI target unit are handled as posted writes while reads are pre-fetched.
Posted writes are stored in PCIW_FIFO and pre-fetched reads are stored in PCIR_FIFO.

2.3.1 PCI Target Unit Architecture

This section describes architecture of PCI target unit. Detailed description is provided in
following sections.

Pithadiya Nayan Page 11

PCI BUS
 Figure 3 PCI Bus Target Unit Architecture

PCI target unit consists of a few functional parts allowing PCI initiators to perform a
Read/Write accesses to WISHBONE bus.

2.3.1.1 PCI Target Module

PCI TARGET module is 32-bit/66MHz, PCI local bus specification Rev. 2.2 compliant
target interface. It includes three to six image units for address translation from PCI bus
and therefore it handles Read/Write cycles to images of WISHBONE address space and
configuration space accesses.

2.3.1.2 PCIW_FIFO
PCI TARGET module uses PCIW_FIFO (PCI WRITE FIFO) for posting memory and I/O
Writes performed by PCI initiator. Parameterized depth of PCIW_FIFO leaves system
designer an option of defining it, regarding needs of particular application for posting more
or less writes. Writing to PCIW_FIFO is adapted to PCI bus speed, while writing to
WISHBONE bus from PCIW_FIFO is adapted to WISHBONE bus speed.

2.3.1.3 PCIR_FIFO
WISHBONE master module uses PCIR_FIFO (PCI READ FIFO) for storing data read
from WISHBONE slaves.
Reading from WISHBONE bus to PCIR_FIFO is adapted to WISHBONE bus speed, while
reading from PCIR_FIFO is adapted to PCI bus speed.

Pithadiya Nayan Page 12

2.3.1.4 WISHBONE Master Module
WISHBONE master module is 32-bit WISHBONE master interface as defined in
WISHBONE specification Rev. 1B. The core requests WISHBONE bus through its
WISHBONE MASTER module. WISHBONE interface of the core is described in detail
in Chapter 5-XY: WISHBONE I/O interface description.

2.4 Clocks
The PCI core has two clock domains. One is from PCI bus and the other from
WISHBONE bus. The adjustment of different bus clocks is made by FIFO with its
interconnection logic. And there is no mater, which bus operates on higher frequency, what
leads to the fact, that there is no difference between all four FIFOs.

2.5 FIFO

Figure 4 Detailed description of FIFO Register line

FIFO is structured from more than one FIFO lines. The number of FIFO lines is the number
of FIFOs depth, and it can be configurable (how the number of FIFO depth is defined will
be discussed in detail in design document and implementation notes). The structure of one
FIFO line is well described in Figure 2-4. It consists of 4 control bits (how they are
used, will be described in detail in design document, e.g. one bit is used to sign last data of
the burst transfer etc.), 4 command or byte enable bits (coding will be described in detail in
design document), 32 address or data bits.

Pithadiya Nayan Page 13

FIFOs are implemented as circular data buffers between WISHBONE and PCI interfaces.
As mentioned above, the FIFO with its interconnection logic adapts the different bus
speeds.
There are data written to the FIFO on the input side with the input bus clock, which is
also connected to the FIFO registers. The Input Pointer (input counter) stores the value of
the input offset address of the first free FIFO line. Its clock frequency is the same as the
frequency of the input bus side.

Figure 5 FIFO architecture

The Output Pointer (output counter) stores the value of the output offset address of the
first FIFO line from which data is to be read. Its clock frequency is the same as the
frequency of the output bus side, with which the data are read.
The comparator between both Pointers (counters) validates if there is any data waiting in
the FIFO to be read (exact counter/comparator operation will be described in detail in
design document). There is also a comparator between the counter, with a value of an Input
Pointer incremented for one, and the Output Pointer. When both are equals, the FIFO is
full.

Pithadiya Nayan Page 14

2.6 Address Translation Logic
As mentioned, WISHBONE slave unit and PCI target unit incorporates several address
space images. For each address space image there must be one address translation logic.
Each address translation logic includes its own set of 32-bit registers:
BASE ADDRESS register [31:0];
ADDRESS MASK register [31:0];
TRANSLATION ADDRESS register [31:0];
IMAGE CONTROL register [31:0].

2.6.1 Description of Address Translation Logic

For description of address translation logic you must also see the Figure 2-6. All AND
blocks and OR block are BIT oriented operators which stands for logic operations
between bits with same weight
The base address is written into the Base Address register. How many Most Significant
bits are masked and replaced with translation address bits, depends on Address Mask
register, which also defines the size of the image. There is one rule, how to set the
Address Mask register. Address bits that can be masked, must start with MSbit (bit[31])
and follow till twelfth bit (bit[11]). All the allowed masked bits define the smallest size of
4kBytes that can be assigned. Between mask bits there must be no zeros, otherwise this
image will have two base addresses with one base address register, what do not complies
with PCI specification. Because of that, the output of Address Mask register is connected
to Mask Correction unit.
To find out if address falls into the correct address range, the masked bits of an input
address and of the base address must be compared (the number of masked bits defines the
unchanging address of current address range, and with that the size of this image).
Masking of the input and the base addresses is made with AND logic functions between
each one of the address and address mask.
To get the correct output address, there must be combined (with OR logic function) the
unmasked bits of the input address and masked bits of the translation address. The
unmasked bits of the input address can be achieved with masking (with AND logic
function) the input address with negated mask bits.

Pithadiya Nayan Page 15

 Figure 6 Block diagram of Address Translation Logic

3. UVM

3.1 UVM Verification Component Overview

The following subsections describe the components of a verification component.

3.1.1 Data Item (Transaction)

Data items represent the input to the device under test (DUT). Examples include
networking packets, bus transactions, and instructions. The fields and attributes of a data
item are derived from the data items specification. For example, the Ethernet protocol
specification defines valid values and attributes for an Ethernet data packet. In a typical
test, many data items are generated and sent to the DUT. By intelligently randomizing data

Pithadiya Nayan Page 16

item fields using Systemverilog constraints, you can create a large number of meaningful
tests and maximize coverage. [7]

3.1.2 Driver (BFM)

A driver is an active entity that emulates logic that drives the DUT. A typical driver
repeatedly receives a data item and drives it to the DUT by sampling and driving the DUT
signals. (If you have created a verification environment in the past, you probably have
implemented driver functionality.) For example, a driver controls the read/write signal,
address bus, and data bus for a number of clocks cycles to perform a write transfer. [7]

3.1.3 Sequencer
A sequencer is an advanced stimulus generator that controls the items that are provided to
the driver for execution. By default, a sequencer behaves similarly to a simple stimulus
generator and returns a random data item upon request from the driver. This default
behavior allows you to add constraints to the data item class in order to control the
distribution of randomized values. Unlike generators that randomize arrays of transactions
or one transaction at a time, a sequencer captures important randomization requirements
out-of- the-box. A partial list of the sequencers built-in capabilities includes:

Ability to react to the current state of the DUT for every data item generated.

Captures the order between data items in user-defined sequences, which forms a
more structured and meaningful stimulus pattern.

Enables time modeling in reusable scenarios.

Supports declarative and procedural constraints for the same scenario.

Allows system-level synchronization and control of multiple interfaces.

3.1.4 Monitor
A monitor is a passive entity that samples DUT signals but does not drive them. Monitors
collect coverage information and perform checking. Even though reusable drivers and
sequencers drive bus traffic, they are not used for coverage and checking. Monitors are used
instead. A monitor:

Collects transactions (data items), A monitor extracts signal information from a bus

Pithadiya Nayan Page 17

 and translates the information into a transaction that can be made available to other
components and to the test writer.

Extracts events, The monitor detects the availability of information (such as a

transaction), structures the data, and emits an event to notify other components of
the availability of the transaction. A monitor also captures status information so it is
available to other components and to the test writer.

Perform checking and coverage.

Checking typically consists of protocol and data checkers to verify that the DUT
output meets the protocol specification.

Coverage also is collected in the monitor.

Optionally prints trace information.

A bus monitor handles all the signals and transactions on a bus, while an agent monitor
handles only signals and transactions relevant to a specific agent.
Typically, drivers and monitors are built as separate entities (even though they may use the
same signals) so they can work independently of each other. However, you can reuse code
that is common between a driver and a monitor to save time. Do not have monitors depend
on drivers for information so that an agent can operate passively when only the monitor is
present. [7]

3.1.5 Agent
Sequencers, drivers, and monitors can be reused independently, but this requires the
environment integrator to learn the names, roles, configuration, and hookup of each of these
entities. To reduce the amount of work and knowledge required by the test writer, UVM
recommends that environment developers create a more abstract container called an agent.
Agents can emulate and verify DUT devices. They encapsulate a driver, sequencer, and
monitor. Verification components can contain more than one agent. Some agents (for
example, master or transmit agents) initiate transactions to the DUT, while other agents
(slave or receive agents) react to transaction requests. Agents should be configurable so
that they can be either active or passive. Active agents emulate devices and drive
transactions according to test directives. Passive agents only monitor DUT activity. [7]

Pithadiya Nayan Page 18

3.1.6 Environment
The environment (env) is the top-level component of the verification component. It
contains one or more agents, as well as other components such as a bus monitor. The env
contains configuration properties that enable you to customize the topology and behavior
and make it reusable. For example, active agents can be changed into passive agents when
the verification environment is reused in system verification. Figure illustrates the
structure of a reusable verification environment. Notice that a verification component may
contain an environment-level monitor. This bus-level monitor performs checking and
coverage for activities that are not necessarily related to a single agent. An agents monitors
can leverage data and events collected by the global monitor. [7]

Figure 7 Typical Verification Component Environment

The environment class (uvm_env) is architected to provide a flexible, reusable, and

Pithadiya Nayan Page 19

extendable verification component. The main function of the environment class is to model
behavior by generating constrained- random traffic, monitoring DUT responses, checking
the validity of the protocol activity, and collecting coverage.
You can use derivation to specialize the existing classes to their specific protocol. This
manual describes the process and infrastructure that UVM provides to replace existing
component behavior with IP-specific behavior.

3.2 The UVM Class Library

The UVM Class Library provides all the building blocks you need to quickly develop well-
constructed, reusable, verification components and test environments. The library consists
of base classes, utilities, and macros. Components may be encapsulated and instantiated
hierarchically and are controlled through an extendable set of phases to initialize, run, and
complete each test. These phases are defined in the base class library but can be extended to
meet specific project needs. [7]

Pithadiya Nayan Page 20

 Figure 8 UVM class Hierarchy

3.3 Other UVM Facilities

The UVM Class Library also provides various utilities to simplify the development and
use of verification environments. These utilities support debugging by providing a user-
controllable messaging utility. They support development by providing a standard
communication infrastructure between verification components (TLM) and flexible
verification environment construction (UVM factory).
The UVM Class Library provides global messaging facilities that can be used for failure
reporting and general reporting purposes. Both messages and reporting are important
aspects of ease of use. [7]

3.3.1 UVM Factory

The factory method is a classic software design pattern that is used to create generic code,
deferring to run time the exact specification of the object that will be created. In
functional verification, introducing class variations is frequently needed. For example, in
many tests you might want to derive from the generic data item definition and add more
constraints or fields to it; or you might want to use the new derived class in the entire
environment or only in a single interface; or perhaps you must modify the way data is sent

Pithadiya Nayan Page 21

to the DUT by deriving a new driver. The factory allows you to substitute the verification
component without having to provide a derived version of the parent component as well.

The UVM Class Library provides a built-in central factory

that allows:
Controlling object allocation in the entire environment or for specific objects.
Modifying stimulus data items as well as infrastructure components (for example, a
driver).
Using the UVM built-in factory reduces the effort of creating an advanced factory or
implementing factory methods in class definitions. It facilitates reuse and adjustment of
predefined verification IP in the end- users environment. One of the biggest advantages of
the factory is that it is transparent to the test writer and reduces the object-oriented expertise
required from both developers and users.

3.3.2 Transaction-Level Modeling (TLM)

UVM components communicate via standard TLM interfaces, which improve reuse. Using
a Systemverilog implementation of TLM in UVM, a component may communicate via its
interface to any other component that implements that interface. Each TLM interface
consists of one or more methods used to transport data. TLM specifies the required
behavior (semantic) of each method, but does not define their implementation. Classes
inheriting a TLM interface must provide an implementation that meets the specified
semantic. Thus, one component may be connected at the transaction level to others that are
implemented at multiple levels of abstraction. The common semantics of TLM
communication permit components to be swapped in and out without affecting the rest of
the environment. [7]

Pithadiya Nayan Page 22

 Literature Review Report 201
3

Proposed Solution

As we all know PCI bus design is very complex so obviously verification of PCI bus
also very complicate. Generally everyone do verification using simple Verilog or
system Verilog method. If I verify my design using with same method than it will get
very complicated and will take much more time.

UVM is latest method and any industries want their design should verify with UVM
only.

I took this challenge and will verify my design with UVM method. For that I will
study systemverilog first because all the basic of systemverilog going to use in UVM.
Even UVM have advantages of code reuse and make design verification easy.

Pithadiya Nayan Page 23

 Literature Review Report 201
3

Reference

[1] PCI Bus In High Speed I/O Systems Applications, Al chame, 1988.

[2] The Design of PCI Bus Interface, Haruyasu Hayasaka Hi roaki Harami i sh i Naohiko
Shimizu

[3] The Control Unit of PCI Bus, Antonyuk V.P., Klepfer E.I., Lobur M.V., Zaharko
J.M., Pereyma M. Y.

[4] Beyond UVM for practical Soc Verification, Young-Nam Yun, Jae-Beom Kim,
Nam-Do Kim, Byeong Min

[5] Systemverilog Basic on www.systemverilog.in

[6] RTL code of PCI Bus on www.opencores.org

[7] UVM manual www.uvmworld.org/pdf/UVM_DAC2011_Final_Color.pdf

[8] UVM example www.testbench.in

[9] UVM Video Lecture www.doulos.com

Pithadiya Nayan Page 24