ISSN 2319-8885

Vol.04,Issue.51,
December-2015,
Pages:11023-11030
www.ijsetr.com

Design and Functional Verification of A SPI Master Slave Core using UVM
K. V. ASHOK KUMAR1, M. SANTOSH KRISHNA2
1

PG Scholar, JNTU, Ananthapur, AP, India, E-mail: kvashok06@gmail.com.

Member of Technical Staff, Seer Akademi, AP, India, E-mail:
santoshkrishna12@gmail.com.

Abstract: Synchronous serial interfaces are widely used to provide economical board
level interfaces between different devices
such as microcontrollers, DACs ADCs and other. Many IC manufacturers produce
components that are compatible with SPI and
Microwire/plus. The SPI Master core is compatible with both protocols as master
with some additional functionality. The SPI
consists of slave select lines, serial clock lines, as well as input and output
data lines. All transfers are full duplex transfers of a
programmable number of bits per transfer. I design the SPI Master-Slave core design
and verified using UVM. The Universal
Verification Methodology (UVM) Class Library provides the building blocks needed to
quickly develop reusable and wellconstructed verification components and test
environments using System Verilog. In this paper i have designed and developed
testing environment using system Verilog implementation of UVM for SPI Master-Slave
core design. My work introduces an
automated stimulus generating testing environment for the design and checks the
functionality of the SPI Master-Slave core
design.
Keywords: Universal Verification Methodology, Direct Memory Access and Serial
Peripheral Interface.
I. INTRODUCTION
SPI stands for Serial Peripheral Interface. SPI is
asynchronous protocol that allows a master device to initiate
communication with a slave device. Data is exchanged
between these devices. SPI is implemented by a hardware
module called the Synchronous Serial Port or the Master
Synchronous Serial Port. This module is built into many
different micro devices. It allows serial communication
between two or more devices at a high speed and is
reasonably easy to implement. The SPI bus can operate with a
single master device and with one or more slave devices. If a
single slave device is used, the SS pin may be fixed to logic
low if the slave permits it. Some slaves require the falling
edge (high to low transition) of the chip select to initiate an
action which starts conversion on said transition. With
multiple slave devices, an independent SS signal is required
from the master for each slave device. Most slave devices
have tri-state outputs so their MISO signal becomes high
impedance (logically disconnected) when the device is not
selected. Devices without tri-state outputs can't share SPI bus
segments with other devices; only one such slave could talk to
the master, and only its chip select could be activated. Fig.1
shows the signaling between an SPI Master and SPI Slave.SPI
is a Serial Interface and uses the following signals to serially
exchange data with another device as explained in fig.1.
 SS: This signal is known as Slave Select. When it goes
low, the slave device will listen for SPI clock and data
signals.
 SCK: This is the serial clock signal. It is generated by the
master device and controls when data is sent and when it
is read.

 MOSI: The signal is generated by Master, recipient is the

Slave.
 MISO: The signals are generated by Slaves, recipient is
the master.

Fig.1. SPI signaling.

II. DESIGN OF SPI
The Block diagram consists of following blocks:
 DMA
 SPI Master Controller
 Slave 0 Model
 Slave 1 Model
A. Direct Memory Access
DMA is responsible for data transfer between several
Peripherals without the intervention of processor. In this
project the DMA interface with the SPI Master controller to
transfer data between SPI Memories. The Processor programs
the DMA with Source Address, Destination Address, Transfer
length. The DMA starts the transfer by reading the source

Copyright @ 2015 IJSETR. All rights reserved.

K. V. ASHOK KUMAR, M. SANTOSH KRISHNA
address register and transfer length register. The DMA wait
C. SPI Slave Memory
for the SPI Master Controller to become free and issues a read
A SPI Slave in system verilog module capable of doing
request to the master controller with the required address .It
transaction level operation with the memory model. It
then wait for the master controller to return the data read from
interfaces with master on the SPI bus and converts read and
the slaves. The DMA stores this data and issues a write
write operation to memory transactions. The SPI Slave
request to the Master Controller with the destination address.
receive command and address data on the SPI bus from the
DMA wait till the master completes the write operation. It
SPI Master and receiving a read request from SPI Master to
then increments the transfer counter and then, repeats the
SPI Slave does a read transaction from SPI Memory with the
whole process till the transfer counter is not equal to the
given address and does a SPI transaction to the SPI master on
transfer length register every time increment the address of
the SPI bus.
write and read request to the SPI Master Controller. The
III. VERIFICATION
DMA, then assert the dma-done signal indicating the
The process of verification parallels the design creation
completion of data transfer.
process. A designer reads the hardware specification for a
block, interprets the human language description, and creates
the corresponding logic in a machine-readable form, usually
RTL code written using Verilog or VHDL language. To do
this, the user needs to understand the input format, the
transformation function, and the format of the output. There is
always ambiguity in this interpretation, perhaps because of
ambiguities in the original document, missing details or
conflicting descriptions. The System Verilog language
provides three important benefits over Verilog. Design
verification is the most important aspect of the product
development process, consuming as much as 80% of the total
product development time. The intent is to verify that the
design meets the system requirements and specifications.
Approaches to design verification consist of
 Logic simulation/emulation and circuit simulation, in
which detailed functionality and timing of the design are
checked by means of simulation or emulation;
 Functional verification, in which functional models
describing the functionality of the design are developed
to check against the behavioral specification of the design
without detailed timing simulation; and
 Formal verification, in which the functionality is checked
against a “golden” model. Formal verification further
includes property checking (or model checking), in which
Fig.2.
the property of the design is checked against some
B. SPI Master Controller
presumed “properties” specified in the functional or
SPI Master Controller is responsible for data transfer on the
behavioral model (e.g., a finite-state machine should not
SPI bus with the slaves. It takes request from DMA convert
enter a certain state), and equivalence checking, in which
them into SPI transactions. The DMA puts Read Write
the functionality is checked against a “golden” model.
request through the SPI master controller. In case of a read
Although equivalence checking can be used to verify the
request the DMA indicate the address of the read operation to
synthesis results in the lower levels of the EDA flow, the
the SPI master controller. The SPI master controller assert the
original design capture requires property checking.
slave select signal based on the address and issues a read
In test plan, we prepare a road map for how do achieve the
command to the slave which is of 8 bits . The lower 7 bits
goal, it is a living document. Test plan includes, introduction,
indicating the address of read on the MSB “0” indicating read
assumptions, list of test cases, list of features to be tested,
operation. The master for response data from the slave after
approach, deliverables, resources, risks and scheduling, entry
receiving data from the slave the master controller make
and exit criteria. Test plan helps verification engineer to
available data DMA to read. In case of a write operation the
understand how the verification should be done. A test plan
DMA indicates the address of write operation and also
could come in many forms, such as a spreadsheet, a document
supplies master controller the data to be read the master
or a simple text file. Sometimes, test plan simply reside in the
controller issues a write command to the slave lower 7 bit
engineer's head which is dangerous in which the process
address and MSB is “1” indicates a write transaction. It
cannot be properly measured and controlled. Test plan also
immediately follows this with write data and indicates the
contains the descriptions of Test Bench architecture and
completion of operation to DMA by asserting the master free
description of each component and its functionality.
signal.
International Journal of Scientific Engineering and Technology Research
Volume.04, IssueNo.51, December-2015, Pages: 11023-11030
Design and Functional Verification of A SPI Master Slave Core using UVM
could add, remove and override blocks in our test bench and
IV. UVM INTRODUCTION
As digital systems grow in complexity, verification
build different environments without rewriting the whole test.
methodologies get progressively more essential. While in the
early beginnings, digital designs were verified by looking at
waveforms and performing manual checks, the complexity we
have today don’t allow for that kind of verification anymore
and, as a result, designers have been trying to find the best
way to automate this process. The System Verilog language
came to aid many verification engineers. The language
featured some mechanisms, like classes, cover groups and
constraints, that eased some aspects of verifying a digital
design and then, verification methodologies started to appear.
UVM is one of the methodologies that were created from the
need to automate verification. The Universal Verification
Methodology is a collection of API and proven verification
guidelines written for System Verilog that help an engineer to
create an efficient verification environment. It’s an opensource standard
maintained by Accellera and can be freely
acquired in their website. By mandating a universal
convention in verification techniques, engineers started to
develop generic verification components that were portable
from one project to another, this promoted the cooperation
and the sharing of techniques among the user base. It also
Fig.3. Representation of a UVM Environment.
encouraged the development of verification components
generic enough to be easily extended and improved without
To illustrate the advantage of this feature, let’s imagine a
modifying the original code. All these aspects contributed for
situation where we are testing a another DUT that uses SPI
a reduced effort in developing new verification environments,
for communication. If, by any chance, we want to test a
as designers can just reuse test benches from previous projects
similar DUT but with I2C instead, we would just need to add
and easily modify the components to their needs.
a monitor and a driver for I2C and override the existing SPI
blocks, the sequencer and the scoreboard could reused just
A. Defining The Verification Environment
fine.
Before understanding UVM, we need to understand
verification. Right now, we have a DUT and we will have to
B. Components of UVM Test Bench
interact with it in order to test its functionality, so we need to
A UVM Test bench is composed of reusable universal
stimulate it. To achieve this, we will need a block that
verification components (UVCs).A UVM-UVC is and
generates sequences of bits to be transmitted to the DUT, this
encapsulated, ready to use and configurable verification
block is going to be named sequencer. Usually sequencers are
environment intended for an interface protocol, a design subunaware of the
communication bus, they are responsible for
module or even for software verification. Each UVC follows
generating generic sequences of data and they pass that data
a consistent architecture and contains a complete set of
to another block that takes care of the communication with
elements for sending stimulus, as well as checking and
the DUT. This block will be the driver. While the driver
collecting coverage information for a specific protocol or
maintains activity with the DUT by feeding it data generated
design. The interface UVC is applied to the Device under test
from the sequencers, it doesn’t do any validation of the
(DUT) to verify implementation of the design protocol logic
responses to the stimuli. We need another block that listens to
or as a means of program the DUT. Module UVCs contain
the communication between the driver and the DUT and
internal verification logic for a subsystem or a module and
evaluates the responses from the DUT. This block is the
enable the subsystem verification in a larger system. UVMmonitor. Monitors sample
the inputs and the outputs of the
UVCs speedup the process of creating efficient testbench for
DUT, they try to make a prediction of the expected result and
the DUT, and are structured to work with any hardware
send the prediction and result of the DUT to another block,
description language (HDL) and a high-level verification
the scoreboard, in order to be compared and evaluated. All
language(HVL) including Verilog, VHDL, e, System Verilog
these blocks constitute a typical system used for verification
and System C. The UVCs can be reused for multiple
and it’s the same structure used for UVM test benches. The
verification environments. The verification environment also
representation of a similar environment in Fig.3. Usually,
contains a multi-channel sequence mechanism i.e. a virtual
sequencers, drivers and monitors compose an agent. An agent
sequencer that synchronizes the timing and the data between
and a scoreboard Compose an environment. All these blocks
the different interfaces and allows fine control of the test
are controlled by a greater block denominated of test. The test
environment for a particular test. The main components and
block controls all the blocks and sub blocks of the test bench.
detailed explanation about each universal verification
This means that just by changing a few lines of code, we
component is as follows:
International Journal of Scientific Engineering and Technology Research
Volume.04, IssueNo.51, December-2015, Pages: 11023-11030
K. V. ASHOK KUMAR, M. SANTOSH KRISHNA
DUT .The monitor, the driver and the DUT are all going to be
C. Data Items
Data items represent stimulus transactions that are input to
connected to this module. The top block is responsible for:
the DUT. Examples of data items are networking packets, bus
 Connecting DUT to test class using interface,
transactions and instructions. The fields and attributes of a
 Generating clock for DUT,
data item are derived from data item’s specification. In a
 Registering the interface in the UVM factory. This is
typical test, many data items are generated and sent to the
necessary in order to pass this interface to all other
DUT. By randomizing data items using System Verilog
classes that will be instantiated in the test bench,
constraints, it helps to create a large number of meaningful
 Running Test
tests and maximum coverage. As Driver deals with signal
activities at bit level, it does not make sense to keep this level
E. Sequencer
of abstraction in DUT. So concept of transaction was created.
A sequencer is an advanced stimulus generator that
A transaction is a class object usually extended from
controls the items provided to the driver for execution. By
uvm_transaction or uvm_sequence_item classes, which
default, a sequencer behaves similarly to a simple stimulus
includes information needed to model the communication
generator and returns a random data item upon request from
between two or more components. Transactions are the
the driver. This default behavior allows you to add constraints
smallest data transfers that can be executed in a verification
to the data item class in order to control distribution of
model. They can include variables, constraints and even
randomized values.
methods for operating themselves. Due to their higher
abstraction level, they are not aware of communication
F. Driver
protocol between components so they can be reused and
A driver is an active entity which emulates logic that
extended for different kind of tests if correctly programmed.
drives the DUT.A typical driver repeatedly pulls data items
The transaction could include two variables; the address of
generated by a sequencer and drives it to the DUT by
the device and the data to be transmitted to that device. The
sampling and driving the DUT signals.
transaction would randomize these two variables and
verification environment would make sure that the variables
G. Monitor
would assume all possible and valid values to cover all
The monitor is a self contained passive entity that
combinations. In order to drive stimulus to DUT, a driver
observes the communication of the DUT with the testbench
component converts transactions into pin wiggles .Sequences
by converting pin wiggles into transactions. Monitor observes
are ordered collection of transactions, they shape transactions
the outputs of the design and incase of not respecting protocol
to our needs and generates as many as need. Sequence are
rules, the monitor must return an error. The monitor is a
extended from uvm_sequence andtheir main job is generating
passive component, it does not drive any signals into the DUT
multiple transactions. After generating transactions, sequencer
its purpose is to extract signal information and translate it into
takes them to driver. Sequence through driver is as shown in
meaningful information to be evaluated by other components.
Fig.4.
A verification environment is not limited to just one monitor,
it can have multiple of them. Monitors collects transactions
from virtual interface and use the analysis ports to send those
transactions to the score board.

Fig.4. Sequence through Driver.

D. Top Block
There are mainly two components that connects DUT with
Test bench in UVM.
 Top block of Test bench,
 A Virtual Interface
The top block will create instances of the DUT and of the
Test bench and the virtual interface will act as a bridge
between them. Interface is a module that holds all signals of

H. 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 test writer, Agent is used. Agent is basically a
container. Some agents are proactive and initiate transactions
to the DUT, while other agents react to transaction requests.
Agents should be configurable so that they can be either
active or passive. In active mode it drives the signal to the
DUT. So driver and sequencer are instantiated in active mode.
In passive mode it just sample the DUT signals does not drive
them. So only monitor is instantiated in passive mode.
I. Scoreboard
Scoreboard is a crucial element in a self checking
environment, it verifies the proper operation of a design at
functional level. This component is the most difficult one to
write, it varies from design to design and from designer to
designer.

International Journal of Scientific Engineering and Technology Research

Volume.04, IssueNo.51, December-2015, Pages: 11023-11030
Design and Functional Verification of A SPI Master Slave Core using UVM
J. Environment
Environment is at the top of the test bench
architecture, it will contain one or more agents depend on
design. The environment contains configuration properties
that enable you to customize the topology and behavior to
make it reusable. For example, active agents can be changed
into passive agents when the verification environments is
reused for system verification. The environment class
(uvm_env) is designed to provide a flexible, reusable and
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.
K. Interface
Interface is the bridge between the design-under-test and the
verification environment as shown in Figure 4.7. The
interface encapsulates all the pin-level connections that are
made to the DUT. An interface is a bundle of nets or
variables.
V. SIMULATION RESULTS
A. DMA Issues Read Operation to SPI Master
As shown in fig 6.1 when ever reg_write is high i.e. 1 we
have reg_addr [1:0] is reg_wdata[7:0] what it actually means
that reg_addr0 stores the sa_reg data,reg_addr1 stores the
da_reg data and reg_addr2 stores the length register data. In
figure we can observe that reg_addr0 value is cc and
reg_addr1 value is 14 i.e. MSB 1 indicates the destination
address value nothing but slave1 and reg_addr2 value is 13
i.e. length register value is 19.Whenever start signal is 1 and
enable is 1 we have mem_addr is cc and wr_rdbar is 0 and
spi_master free then DMA issues read request to spi master
.This fig.5 shows DMA issues read operation to SPI Master.

Fig.6.SPI Master issues read transactions to slave1.

C. Slave1 Gives Read Data To SPI Master And It Gives
Data to DMA and DMA Issues Write Transactions To SPI
Master
Because of serial communication Slave1 gives read data
to SPI Master when MISO is 1.here rdata is 97.SPI Master
gives rdata to DMA when spi master free is 1. Then DMA
issues write transactions to spi master with the wdata is 97,
enable is high,wr_rdbar is 1,da is 14 as shown in Fig.7.

Fig.7.Slave1 gives read data to SPI Master and it gives data

to DMA and DMA issues write transactions to SPI Master.
Fig.5. DMA issues read operation to SPI Master.
B. SPI Master Issues Read Transactions To Slave1
Sa is cc so data is available at slave1. So SPI Master issues
read transactions to slave1 when MOSI is 1 and ssbar is 1 as
shown in Fig.6.

D. SPI Master Issues Write Operation To Slave And Slave

0 Write The Data
Slave 0 write the data when MOSI is 1 and rdata is 97. So
one spi transaction completed, like that process will repeat for
19 times because of length is 19 after that DMA stop the
operation when dma_done is 1 as shown in Figs.8 and 9.
International Journal of Scientific Engineering and Technology Research
Volume.04, IssueNo.51, December-2015, Pages: 11023-11030
K. V. ASHOK KUMAR, M. SANTOSH KRISHNA
D. Coverage Report
The following report describes the coverage report. This
includes Assertion coverage and group coverage as shown in
Figs.11 to 13.

Fig.8.SPI Master issues write operation to slave and slave

0 write the data.
Fig.11. Total coverage report.

Fig.9.Operation completed when dma_done.

Fig.12.Detailed coverage report.

C. RTL Schematic
The following diagram describes the Schematic of RTL as
shown in Fig.10.

Fig.10.RTL Schematic.

Fig.13.Coverage report for assertions.

International Journal of Scientific Engineering and Technology Research
Volume.04, IssueNo.51, December-2015, Pages: 11023-11030
Design and Functional Verification of A SPI Master Slave Core using UVM
URG (unified report Generator) generates combined reports
individual devices are identified, commands may be issued
for all types of coverage information. It contains the overall
that affect only one device in that scan chain. Different
score for the functional coverage. The reports consist of a set
vendors use different JTAG connectors. Bit strings used in
of HTML or text files. URG is an inbuilt tool in VCS which is
JTAG are often long and not multiples of 8 bit words; for
used for functional coverage analysis. Sometimes functional
example, a boundary scan reports signal state on each of
coverage is reused from VIP or legacy project, instead of
several hundred pins. SGPIO is essentially another
developing from scratch. There are cases, when all cover(incompatible) application
stack for SPI designed for
groups are not valid and hence partial reuse is required, which
particular backplane management activities. SGPIO uses 3-bit
in turn requires exclusion of the unused cover-groups. Here,
messages.
we can either simply remove unused code after porting
VII. CONCLUSION
coverage, if it is accessible or exclude cover-groups without
Automated test-cases are generated and applied to my
removing any code. This approach is mainly used while
design. Functionality of SPI Protocol was verified.
Developing the Verification IP for any design (DUT)
reusing VIP functional coverage.
becomes very simple by using UVM. Universal Verification
VI. APPLICATIONS
Methodology verifies the design in most effective way. The
The board real estate savings compared to a parallel I/O bus
basic functionality and operation of SPI and description of
are significant, and have earned SPI a solid role in embedded
registers, signals, pin is discussed. It describes that how we
systems. That is true for most chip processors, both with
can create serial communication environment between the
higher end 32-bit processors such as those using ARM, MIPS,
master and the selected slave device. Functional verification
or PowerPC and with other microcontrollers such as the
of SPI contains the description of verification platform using
AVR, PIC, and MSP430. These chips usually include SPI
System Verilog for the design under test (DUT) that is SPI. In
controllers capable of running in either master or slave mode.
accordance with the design specification we created the
In-system programmable AVR controllers (including blank
verification environment to validate the functionality and
ones) can be programmed using an SPI interface. Chip
operation of configurable intellectual property SPI. The VIP
or FPGA based designs sometimes use SPI to communicate
developed for SPI Protocol was reusable and using which
between internal components; on-chip real estate can be as
design can be verified successfully. By using this verification
costly as its on-board cousin. The full-duplex capability
environment 100% functional and assertion coverage can be
makes SPI very simple and efficient for single master/single
achieved.
slave applications. Some devices use the full-duplex mode to
VII. REFERENCE
implement an efficient, swift data stream for applications such
[1] Tianxiang Liu ”IP Design of Universal Multiple Devices
as digital audio, digital signal processing, or telecommuniSPI Interface” IEEE.978-
1-61284-632-3, 2011.
cations channels, but most off-the-shelf chips stick to half[2] Freescale
Semiconductor, Freescale SPI Block Guide
duplex request/response protocols.
V04.01, October 14).2008.
SPI is used to talk to a variety of peripherals, such as
[3]AccelleraOrganization,“UniversalVerificationMethodolog
 Sensors: temperature, pressure, ADC, touch screens,
y (UVM) 1.1 Class Reference”, June 2011.
video game controllers
[4] IEEE Computer Society “IEEE Standard Verilog®
 Control devices: audio codec’s, digital potentioHardware Description Language”,
IEEE Std 1364™- 2005,
meters, DAC
07 April 2006.
[5] http://www.testbench.in.
 Camera lenses: Canon EF lens mount
[6] IP Design of Universal Multiple Devices SPI Interface
 Communications: Ethernet, USB, USART, CAN, IEEE8
Tianxiang Liu1, Yunfeng Wang1 * Department of Electronic
02.15.4, IEEE 802.11, handheld video games
Engineering, Xiamen University,2011 IEEE.
 Memory: flash and EEPROM
[7] www.Colorlesscube.com.
 Real-time clocks
[8] http://www.systemverilog.in/systemverilog.php
 LCD, sometimes even for managing image data
[9] M.Sandya1, K.Rajasekhar, “Design and Verification of
 Any MMC or SD card (including SDIO variant)
Serial Peripheral Interface”, International Journal of
Engineering Trends and Technology- Volume3Issue4- 2012
For high performance systems, FPGAs sometimes use SPI to
[10] Juan Francesconi, J. Agustin Rodriguez, Pedro M. Julian,
interface as a slave to a host, as a master to sensors, or for
2014. UVM Based Testbench Architecture for Unit
flash memory used to bootstrap if they are SRAM-based.
Verification. ISBN: 978-987-1907-86-1 IEEE Catalog
JTAG is essentially an application stack for a three-wire SPI
Number CFP1454E-CDR.
flavor, using different signal names.TCK not SCK, TDI not
[11] Alexander W. Rath, Volkan Esen and Wolfgang Ecker,
MOSI, TDO not MISO. It defines a state machine (driven by
2014.ATransaction-OrientedUVM-BasedLibraryfor Verifia TMS signal instead of a chip
select line), protocol messages,
cation of Analog Behavior, IEEE- 978-1-4799- 2816-3, pp
a core command set, the ability to daisy-chain devices in a
806-811.
"scan chain", and how vendors define new commands. The
[12]http://www.low-powerdesign.com/article_CadenceUVM.
devices in a scan chain are initially treated as a single device,
[13] An Accellera Organization, June 2011. Universal
and transitions on TMS update their state machines; once the
Verification Methodology (UVM) 1.1 Class Reference.
International Journal of Scientific Engineering and Technology Research
Volume.04, IssueNo.51, December-2015, Pages: 11023-11030
K. V. ASHOK KUMAR, M. SANTOSH KRISHNA
[14] http://www.totalphase.com/support/articles.
[15] Clifford E. Cummings, Tom Fitzpatrick, “OVM & UVM
Techniques for Terminating Tests” DVCon 2011.

International Journal of Scientific Engineering and Technology Research

Volume.04, IssueNo.51, December-2015, Pages: 11023-11030