thesis main
TRANSCRIPT
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programmes (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad Serial Peripheral Interface
Development of OVM Verification Environment for
Functional Verification of Quad Serial Peripheral
Interface
M.Sc.[Engg.] Dissertation in VLSI System Design
Submitted by : Kiran N.
Registration No : CGB0910003
Academic Supervisors : Dr. Cyril Prasanna Raj P. Professor & Head, Dept. of EEE,
MSRSAS Industrial Supervisors : Mr. Linu Thomas
Manager, IC Design Engineering,
Broadcom
M. S. Ramaiah School of Advanced Studies
Postgraduate Engineering and Management Programme Coventry University (UK)
#470-P Peenya Industrial Area, 4th
Phase, Bengaluru-560 058
Tel; 080 4906 5555, website: www.msrsas.org
March-2012
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
ii
M.S.RAMAIAH SCHOOL OF ADVANCED STUDIES
Postgraduate Engineering and Management Programme
Coventry University (UK)
Bangalore
Certificate
This is to certify that the M.Sc. [Engg.] Project Dissertation titled
“Development of OVM Verification Environment for Functional
verification of Quad Serial Peripheral Interface” is a bonafide record of the
Project work carried out by Mr.Kiran N. Reg no. CGB0910003 in partial
fulfilment of requirements for the award of M.Sc. [Engg.] Degree of
Coventry University in VLSI System Design,March-2012.
Dr. Cyril Prasanna Raj P. Mr. Linu Thomas Academic Supervisor Industrial Supervisor Professor & HOD, Dept. of EEE, Manager , IC Design Engineering MSRSAS-Bangalore Broadcom
Dr. Cyril Prasanna Raj P. Dr. Govind R. Kadambi Processor & HOD, Dean-PEMP Dept. of EEE MSRSAS
MSRSAS
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
iii
Declaration
“Development of OVM Verification Environment for Functional
Verification of Quad Serial Peripheral Interface’’’’
The Project Dissertation is submitted in partial fulfilment of academic requirements for
M.Sc. [Engg.] Degree of Coventry University in VLSI System Design. This dissertation is a
result of my own investigation. All sections of the text and results, which has been obtained
from other sources, are fully referenced. I understand that cheating and plagiarism constitute
a breach of University regulations and will be dealt with accordingly.
Signature :
Name of the Student : KIRAN N.
Registration No : CGB0910003
Date : March 2012
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
iv
Acknowledgement
This work is deemed incomplete without acknowledging the various individuals
immensely instrumental in ushering a great deal of effort, time and invaluable guidance.
Firstly I would like to thank my parents and my project supervisors Mr. Cyril Prasanna
Raj P., Professor & Head Department of EEE, MSRSAS and Mr. Linu Thomas,
Manager, IC design engineering, Broadcom for providing valuable suggestions and
encouragement their help, support, guidance and confidence in my abilities to execute my
project successfully.
I would also like to extend my sincere thanks to the management of M. S. Ramaiah
School of Advanced Studies for the help and support provided during the project. I am
extremely grateful to Dr. S. R. Shankapal., President, MSRSAS, and Dr. Govind R.
Kadambi., Dean – PEMP, MSRSAS whose emphasis for excellence and quality kept me
focused on this project and helped to complete it.
I would like to thank Mr. Padmanaban K., Asst. Professor and Mr. Abdul Imran
Rasheed, Sr. Teaching Assistant, for his continued support and providing timely help on
project formalities.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
v
Abstract
Verification has attained pinnacle priority in the age of multimillion gates mixed signal
system on chip designs. Quad Serial Peripheral Interface (QSPI) is a relative new technology
used for the serial data communication between the core and the peripherals connected to it.
The Open Verification Methodology (OVM) based verification environment is the most
sought after in the industry because of its inherent features like reusability and
configurability. QSPI presents a new variety of verification challenges unlike its predecessor
technology Serial Peripheral Interface (SPI). The development of an OVM based verification
methodology for functional verification of QSPI module is done in this project.
QSPI in this application follows the protocol specified by the spansion flash memory
peripheral. The OVM verification environment is designed to verify this master slave
protocol of data transfer. The verification environment is set up by extended the base class
available in the OVM library. It is designed to interact with the AXI and APB system buses
to perform the backdoor write onto the peripheral and read back from it to validate the
functionality. The sequencer in verification environment is designed to generate random
stimulus in burst of 16 bits which encapsulates the commands, address location and actual
data to be written. The desired functionality of the QSPI like 24/32 bit address modes and
single, dual and quad mode of operations is verified successfully using the environment
setup.
The functional verification for the QSPI module and Sub blocks was carried out
Synopsys VCS tool and coverage was obtained using VERDI tool. The final coverage
obtained for the QSPI block stands at 89.3 % line coverage, 83.62 % conditional coverage
and 57 % toggle coverage. The maximum rate of data transfer is tabulated to be at 33 Mbps
at a frequency of 80 MHz. The OVM based verification environment developed is totally
reusable and can be used to verify other designs with the required modifications.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
vi
Table of Contents
Declaration ................................................................................................................... iii
Acknowledgement ........................................................................................................ iv
Abstract ......................................................................................................................... v
Table of Contents ......................................................................................................... vi
List of Tables ................................................................................................................ ix
List of Figures ................................................................................................................ x
Abbreviation ................................................................................................................ xii
Nomenclature ............................................................................................................. xiii
1 – Introduction ........................................................................................................... 14
1.1 Intoduction ................................................................................................... 14
1.2 Top level block diagram ............................................................................... 17
1.3 Scope of the QSPI and OVM environment ................................................... 18
1.4 Motivation for development of OVM environment....................................... 18
1.5 Challenges in development of OVM verification environment ..................... 18
1.6 Applications of QSPI and OVM verification environment ............................ 19
1.7 Block diagram for the OVM based verification environment ........................ 19
1.8 Thesis organization ...................................................................................... 20
2 – Background Theory on Quad SPI and OVM ....................................................... 22
2.1 Terms and definitions ................................................................................... 22
2.2 Introduction to SPI standard ......................................................................... 24
2.2 The principle of SPI operation ...................................................................... 24
2.2.1 Data and Control Lines of the SPI ...................................................... 28
2.2.2 SPI Configuration .............................................................................. 29
2.2.3 SPI v/s I2C ......................................................................................... 30
2.3 Open Verification Methodology ................................................................... 32
2.4 OVM phases: ............................................................................................... 34
2.5 Testbench Layered Organisation .................................................................. 35
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
vii
2.6 Summary ..................................................................................................... 39
3 - Literature Review on OVM and QSPI .................................................................. 40
3.1 Important observations ................................................................................. 40
3.2 Overview of Literature Review .................................................................... 40
3.3 Gaps in literature review .............................................................................. 46
3.4 Summary of the Literature Review ............................................................... 47
4 – Problem Definition ................................................................................................ 49
4.1 Introduction ................................................................................................. 49
4.2 Aim and objectives of the project ................................................................. 49
4.3 Methods and methodology ........................................................................... 49
4.4 Resources Used ............................................................................................ 50
5-Design of Quad SPI .................................................................................................. 52
5.1 Introduction to QSPI for serial flash memory peripheral ............................... 52
5.2 Top level block diagram of QSPI ................................................................. 52
5.3 Device operations......................................................................................... 53
5.4 Sub blocks design ........................................................................................ 57
5.4.1 Master Serial Peripheral Interface ....................................................... 57
5.4.2 Boot Serial Peripheral Interface .......................................................... 58
5.4.3 Read Ahead FIFO .............................................................................. 60
5.5 Summary ..................................................................................................... 61
6 – Implementation of OVM Verification Environment ............................................ 62
6.1 Introduction to OVM verification environment development ........................ 62
6.2 Block diagram of the OVM based verification environment ......................... 65
6.3 Design of verification environment components ........................................... 65
6.3.1Sequencer: .......................................................................................... 65
6.3.2 Test case generator: ............................................................................ 67
6.3.3 Checker .............................................................................................. 67
6.4 Implementation of test cases ........................................................................ 67
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
viii
6.4.1 Steps Implemented for testbench design .................................................... 68
6.5 Summary ..................................................................................................... 72
7 – Results and Discussions ......................................................................................... 73
7.1 Coverage analysis ........................................................................................ 73
7.1.1 Line Coverage .................................................................................... 73
7.1.2 Block Coverage .................................................................................. 73
7.1.3 Branch coverage ................................................................................. 74
7.1.4 Path Coverage .................................................................................... 74
7.1.5 Toggle Coverage ................................................................................ 74
7.2 Simulation results......................................................................................... 74
7.2.1 Boot Serial Peripheral Interface .......................................................... 74
7.2.1.1 BSPI in 3 byte addressing and single data lane mode ....................... 75
7.2.1.2 BSPI in 3 byte addressing and dual data lane mode ......................... 76
7.2.1.3 BSPI in 3 byte addressing and quad data lane mode......................... 77
7.2.1.4 BSPI in 4 byte addressing and single data lane mode ....................... 78
7.2.1.5 BSPI in 4 byte addressing and dual data lane mode ......................... 79
7.2.1.6 BSPI in 4 byte addressing and Quad data lane mode ........................ 80
7.2.2 Master Serial Peripheral Interface ....................................................... 81
7.2.3 Read Ahead FIFO .............................................................................. 82
7.3 Regression results ........................................................................................ 83
7.4 Coverage report............................................................................................ 84
7.4 Summary ..................................................................................................... 85
8-Conclusions and recommendations for future work ............................................... 86
8.1 Conclusion ................................................................................................... 86
8.2 Recommendations for future work: ............................................................. 86
References .................................................................................................................... 87
Appendix ...................................................................................................................... 88
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
ix
List of Tables
Table 2. 1 SPI Modes ......................................................................................................... 29
Table 2. 2 Comparison between SPI and I2C interfaces ....................................................... 30
Table 5. 1 Instruction set for SPI flash memory ................................................................. 56
Table 5. 2 APB Signal description ...................................................................................... 58
Table 5. 3 AXI read channel Signal description .................................................................. 59
Table 5. 4 AXI address channel Signal description ............................................................. 60
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
x
List of Figures
Figure 1. 1 Top level block diagram ................................................................................. 17
Figure 1. 2 Block diagram for OVM based verification environment .................................. 20
Figure 2. 1 A simple SPI module ........................................................................................ 25
Figure 2. 2 Cascading several SPI devices .......................................................................... 26
Figure 2. 3 Master with independent slaves ........................................................................ 27
Figure 2. 4 Generic QSPI block diagram ............................................................................ 31
Figure 2. 5 OVM verification environment ......................................................................... 34
Figure 2. 6 OVM phases .................................................................................................... 35
Figure 2. 7 Layered testbench architecture of OVM ............................................................ 36
Figure 2. 8 Concentric testbench organisation ..................................................................... 37
Figure 3. 1 QSPI Architecture for AXI4 interface and serial flash memory ......................... 41
Figure 3. 2 Architecture of Serial Peripheral Interface ....................................................... 43
Figure 3. 3 SPI frame format .............................................................................................. 44
Figure 3. 4 Hardware and Software co- verification ............................................................ 45
Figure 5. 1 Block diagram of QSPI ..................................................................................... 53
Figure 5. 2 QSPI in single master and multiple slaves configuration ................................... 54
Figure 5. 3 Block Diagram Master SPI ............................................................................... 57
Figure 5. 4 Block Diagram Boot SPI .................................................................................. 59
Figure 5. 5 Block Diagram RAF ......................................................................................... 61
Figure 6. 1 Functional verification concept ......................................................................... 63
Figure 6. 2 Block Diagram of the OVM based verification Environment ............................ 66
Figure 6. 3 Frame format for quad mode............................................................................. 68
Figure 6. 4 Interface block of QSPI ................................................................................... 69
Figure 6. 5 code for wrap burst data generation .................................................................. 70
Figure 6. 6 Interface signals for QSPI Verification Environment ........................................ 71
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
xi
Figure 7. 1 3byte addressing mode in single data lane mode ............................................... 75
Figure 7. 2 3byte addressing mode in dual data lane mode .................................................. 77
Figure 7. 3 4byte addressing mode in quad data lane mode ................................................ 78
Figure 7. 4 4byte addressing mode in single data lane mode ............................................... 79
Figure 7. 5 4byte addressing mode in dual data lane mode .................................................. 80
Figure 7. 6 4byte addressing mode in Quad data lane mode ................................................ 81
Figure 7. 7 MSPI single data lane mode .............................................................................. 82
Figure 7. 8 MSPI single data lane mode .............................................................................. 82
Figure 7. 9 RAF single data lane mode ............................................................................... 83
Figure 7. 10 Regression result for QSPI module ................................................................. 84
Figure 7. 11 Coverage report for QSPI module ................................................................... 85
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
xii
Abbreviation
AMBA Advanced Microprocessor Bus Architecture
APB Advanced Peripheral Bus
AVM Advanced Verification Methodology
AXI Advanced eXtensible Interface
BSPI Boot Serial Peripheral Interface
DUT Design Under test
EDA Electronic Design Automation
IP Intellectual Property
MSPI Master Serial Peripheral interface
OOP Object Oriented Programming
OVM Open Verification Methodology
OVM Open Verification Methodology
QSPI Quad Serial Peripheral Interface
RAF Read Ahead FIFO
SoC System On Chip
SPI Serial Peripheral Interface
TLM Transaction Level Modeling
UVM Universal Reuse Methodology
VLSI Very Large Scale Integrated Circuits
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
xiii
Nomenclature
GHz Giga Hertz
bps bits per second
Gbps Giga bits per second
Mbps Mega bits per second
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programmes (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad Serial Peripheral Interface
1 – Introduction
This chapter provides an overview of the project on the whole. It gives an insight into the
purpose of the project, scope of the project and challenges involved. It gives an
introduction to the actual project.
1.1 Intoduction
The drastically increasing design complexities are forcing verification engineers to
develop new and improved verification techniques to handle these complexities. System
on Chip (SOC) designs integrate million if not billions of gates in the design, these
designs require better verification effort than the normal design primarily because of the
enormicity of and design and secondly because of the complexity of design. Verification
takes up a major chunk of the design time and the quality of the verification decides the
success of the design once it is taped out. To meet the quality of verification and the short
time frame to achieve the confidence, verification teams around the world adopt
verification methodologies.
Verification methodologies are a systematic way of doing things with a rich set of
standard rules and guidelines. It provides the necessary infrastructure to build robust,
dependable and complete verification environment. It reduces the verification effort with
pre defined libraries and makes verification effort easier by avoiding errors which have
occurred previously. Number verification methodologies are present in the industry
currently and each of them has their own set of advantages and disadvantages. Based on
the requirement of the design and how easily the design can built into the verification
environment a particular methodology is adopted.
A good verification methodology starts with a statement of the function the DUT
is intended to perform (Molina 2007). From this is derived a verification plan, broken
down feature-by-feature, and agreed in advance by all those with a specific interest in
creating a working product. This verification approach will be the basis for the whole
verification process. Verification will be complete when every item in the plan has been
tested to the required level, where the required means importance and the priorities
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
15
assigned to testing the various functionalities have been agreed in advance and are
concurrently revised during the project.
In SoC designs it very important for proper communication between different
block involved in the design. Since some of Intellectual Property (IP) may not be
originally developed integration of all the blocks is major challenge. To overcome this
Interfaces are developed which primarily are required for any two blocks of different
characteristics to communicate. These interfaces ensure proper data transfer between the
blocks considering all factors like clocking issue, baud rates etc( Peretez 2009).
The apt way to approach the verification process is to start off using simple
directed tests to bring up the design and then use completely random tests to check the
state space in an elaborate fashion and bring up as many bugs as possible with minimum
effort employed to test writing. Typically this will help achieve a functional coverage
much less than 100%, and the rest of the verification process is spent writing a series of
tests, in which random stimulus is constrained and shaped in a different way to push the
design into corner cases. The design state space is typical so huge that random stimulus
alone will be able to explore all the key scenarios, but directed or highly constrained tests
can be used to zero in on such scenarios to give good overall coverage. Constrained
random stimulus can be viewed as a compromise between the two extremes cases, but
proper usage comes down to making a series of good judgements. To have the priorities
set in the verification plan to direct verification resources to the key areas is the solution.
Open Verification Methodology (OVM) is a methodology for the functional
verification of digital hardware, primarily using simulation. The hardware or system to be
verified would typically be described using Verilog, SystemVerilog, VHDL or System C
at any appropriate abstraction level. This could be behavioural, register transfer level, or
gate level. OVM is explicitly simulation-oriented, but OVM can also be used alongside
assertion-based verification, hardware acceleration or emulation. OVM facilitates the
construction of verification environments and tests, both by providing reusable machinery
in the form of a library of SystemVerilog classes, and also by providing a set of
guidelines for best practice when using SystemVerilog for verification.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
16
Serial communication is the preferred mode of communication on SoC’s where
more than the speed of data transfer the broad real estate and error free data transmission
are of higher priority. The serial communication architectures are generally used of short
distance data transfer. In board designs where signal integrity is major issue using parallel
communication architectures of data transfers can have telling effect on the overall
performance of the system. Hence simpler and safer serial communication architectures
are preferred. The serial communication architectures used on SoC include SPI, I²C etc.
Out of the available architectures SPI is preferred for high speed data transfer applications
like signal processing, digital streaming etc for the ease of operation and high throughput.
Advantages of SPI architectures over other serial bus architectures include
Full duplex communication
Higher throughput than I²C or SMBus
Complete protocol flexibility for the bits transferred
Not limited to 8-bit words
Arbitrary choice of message size, content, and purpose
Extremely simple hardware interfacing
Typically lower power requirements than I²C or SMBus due to less circuitry
(including pullups)
No arbitration or associated failure modes
Slaves use the master's clock, and don't need precision oscillators
Slaves don't need a unique address — unlike I²C or GPIB or SCSI
Transceivers are not needed
Uses only four pins on IC packages, and wires in board layouts or connectors,
much less than parallel interfaces
At most one unique bus signal per device (chip select); all others are shared
Signals are unidirectional allowing for easy Galvanic isolation.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
17
In this particular project Open Verification Methodology (OVM) verification
environment is developed is developed for the verification Quad Serial Peripheral
Interface (QSPI) IP which is used as interface for the host processor to communicate with
the peripherals attached to it.
1.2 Top level block diagram
The top level block diagram of a networking application based SoC from Broadcom is as
shown in Figure 1.1. The SPI block acts as an interface for high frequency data transfer in
this case connected to GPS module.
Figure 1. 1 Top level block diagram (BCM21551 product brief 2007)
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
18
1.3 Scope of the QSPI and OVM environment
The verification environment is a reusable entity which can be used further many serial
communication IP with few required adjustment made into the design. Since the serial
communication protocols are preferred means of data communication and SOC designs
and application of the OVM verification environment developed in this project has
tremendous implementation scope. It is necessary to make few changes in the sequences
generated and the timing for driving of the control signals for a particular module. This
can accomplished through a few minor changes in the code rather than developing all the
classes for the verification environment from scratch.
1.4 Motivation for development of OVM environment
The QSPI module is capable of high through puts of up to 80MHz and hence from an
integral part of the SoC designs. Without it faster serial data transfer will not be possible
and hence in turn restricting the overall performance of the SoC
The motivation for the project is developing an OVM based verification environment
which is able to perform the functional verification of the QSPI module and obtain a
respectable coverage. This verification environment once developed can be used for serial
communication protocol interfaces in SoC design and hence saving time and improving
the verification effort by covering all the difficult corners of design and attaining
maximum possible coverage to avoid costly re-spins for SoC.
1.5 Challenges in development of OVM verification environment
The challenges in the designing of the OVM verification environment for the QSPI
module include
The QSPI is a relatively new and advanced interface so there not many supporting
documents for other the data sheets to learn about the behavior of module once
applied which would have given key insights on the cases or modes for the
verification effort needs to be stronger.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
19
Understanding the working of the QSPI IP as the design is newly developed and
has many modes of operation.
Developing the OVM verification environment from scratch and integrate all the
component classes with the Design Under Test DUT (QSPI) and ensuring proper
working of the entire verification environment for attain maximum possible
coverage.
1.6 Applications of QSPI and OVM verification environment
The QSPI finds its application in almost any and every SoC designs and in swift
data transmission applications like digital streaming, digital signal processing.
SPI is used to talk to a variety of peripherals, such as
Under sensors: temperature, pressure, ADC, touchscreens, video game
controllers
Under control devices: digital potentiometers, DAC
Camera lenses
Ethernet, USB, USART, CAN, IEEE 802.15.4, IEEE 802.11
Flash and EEPROM memories
Real-time clocks
LCD displays
MMC or SD card
The verification environment can be used for other serial and other on chip
communication protocol and interfaces.
1.7 Block diagram for the OVM based verification environment
The Block diagram of the verification environment is as shown in the Figure 1.2. The
verification environment has a layered structure. The top most layer OVM_test being the
test bench which includes all the test cases and classes. The second layer OVM_env is
environment which is an assembly of all the component classes sequencer, driver and
monitor and their interconnections which help bring about the purpose of verification
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
20
through the test bench layer. The last layer is the DUT in this case the Quad SPI module
which is verified by sending the randomly generated packets and crosschecking the
corresponding output available at the output for validating its operation.
Figure 1. 2 Block diagram for OVM based verification environment
1.8 Thesis organization
The thesis is organised with 8 chapters to describe the work of developing the verification
environment based on OVM for functional verification of QSPI module
Chapter 2 is an overview of the working of the general architecture of SPI module in
standard mode and quad mode. Also an overview of the OVM verification environment
and its contents is presented
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
21
Chapter 3 consists of overview of the literature review carried out giving insights into the
working of QPSI module and OVM verification environment. Also why OVM
verification environment is used for SOC designs.
Chapter 4 discusses the problem definition for verification environment Development for
QSPI which is made with defining objectives to be met along the flow and methodologies
used to achieve the objectives are brought out.
Chapter 5 describes the working of the QSPI for serial flash memory peripheral and
functionality of the each of the blocks.
Chapter 6 describes the verification approach for each of the sub blocks inside the QSPI
and the corresponding testcases for the each of the blocks and functionality intended for
verification.
Chapter 7 discusses the results obtained for the work carried out in verifying the QSPI
module which is dealt in depth and final coverage obtained is documented.
Chapter 8 discusses the conclusions and outcomes drawn based on the project work
carried out and corresponding results obtained.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
22
2 – Background Theory on Quad SPI and OVM
This chapter provides overview of the understanding of the theory behind the design of
the QSPI block and OVM verification environment. It gives an insight into the working
principle and various architectures of the QSPI which are available. The working
principle of OVM verification environment and description of some important terms like
functional coverage
2.1 Terms and definitions
Serial communication: The communication protocol in which is data is sent and
received on a single data bus sequentially one bit at a time.
Serial Peripheral Interface: The Serial Peripheral Interface Bus or SPI bus is
a synchronous serial data link standard for full duplex mode communication.
Devices communicate in master/slave mode where the master device initiates
the data frame. Multiple slave devices are allowed with individual slave
select (chip select) lines.
Quad SPI: It is an advanced version of the SPI. It has 4 data lines instead of the
one in SPI and hence has higher throughput.
Throughput : It is amount of successful data transaction done over a specified
period of machine cycles.
System on Chip: It is an integrated circuit which integrates all the components like
processor, memory, buses, sensors and converters on single silicon wafer die.
Verification environment: For verification of complex designs an environment is
built using a suitable language. The components of this environment help in
reducing the time and verification effort required for attaining the desired results.
Coverage: Coverage value represents the verification effort carried on the designs.
Functional verification: It verifies the design intent. Its main purpose is to ensure
that design implements the intended functionality.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
23
FIFO: First In First Out buffer which stores the bit read in from the flash memory
and stored for future processing.
Bus: A group of data lines used to transmit data from one to point to another with
a module
OOP: Object Oriented Programming lets us create complex data types and tie
them together with routines that work with them
Class: A basic building block containing variables and routines that manipulate it.
Object: It is an instance of a class
Modports: It helps define the direction of ports as though they declared in the
module. Modports are used to restrict interface access within modules
Interface: It enables connectivity between the modules and allows smooth flow of
design between the modules. Using the interface facilitates the reuse of the design.
The program size is also reduced as all the signals and variables are placed under
a single name.
Virtual Interface: It can be used as a reference to a module which is already
present and allows sub programs to operate in other parts of the design.
Program block: It is mainly used for writing test benches. It is defined within the
keywords program and end program. They help reduce race conditions.
Virtual Class: the class exists simply as a base class from which other class can be
derived.
Super: The super keyword is used from within a sub class to refer to properties of
base class this when the property of sub class has been overridden and cannot be
accessed directly. It is required to use.
Multiplexer: It is combinational circuit which has 2n number of data input lines
and single output line. The Select lines ‘n’ in number decide which input is sent
out to output.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
24
Arbiter: A control unit which decides which driver is going to be active during
any particular bus cycle. Arbiters are of two types, round robin arbiter which
allots the bus to the driver components on the basis of turn taking without any
particular priority. The other type is the Priority bus arbiter which allots the bus to
driver components based on a predefined priority. At any bus cycle the driver unit
with the highest priority can become the owner of the bus.
2.2 Introduction to SPI standard
The possibility of serial communication with peripheral devices via SPI (Serial
Peripheral Interface) has been discussed here. Serial bus systems are preferred instead of
a parallel bus, because of the simpler wiring. The speed advantage of the parallel data
transmission gets less important, as the efficiency of serial buses increases. The clock
frequencies of SPI devices can go up to some Megahertz and even more. The serial
transmission is perfectly sufficient for a lot of application. The usage of SPI is not only
limited to the measuring area, it is also used in the audio field.
The SPI (Created by Motorola) is also known as Microwire, trade mark of
National Semiconductor. The functionality of both is the same. There are also the
extensions QSPI (Queued Serial Peripheral Interface) and Microwire PLUS.
The popularity of other serial bus systems like I2C, CAN bus or USB shows, that serial
buses get used more and more for SOC designs.
2.2 The principle of SPI operation
The Serial Peripheral Interface is used primarily for a synchronous serial
communication of host processor and peripherals. A connection of two processors via SPI
is just as well possible. In the standard configuration for a slave device as shown in
Figure 2.1, two control and two data lines will be used. The data output SDO serves on
the one hand the reading back of data, offers however also the possibility to cascade the
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
25
devices. The data output of the preceding device forms the data input for next IC. The
Chip Select (CS) signal is used to the select a particular peripheral connected the host.
Serial Clock (SCKL) is the master clock which is used to synchronise the data transfer.
Figure 2. 1 A simple SPI module
There is a MASTER and a SLAVE mode. The clock signal will be produced by the
master device, and determines the state of the chip select lines, i.e. it activates the SLAVE
that it wants to communicate with. Therefore the CS and SCKL are outputs.
The SLAVE device receives the clock and chip selected from the MASTER, and
therefore CS and SCKL are inputs.
It means there is only one master, while the number of slaves is only limited by the
number of chip selected.
A SPI device can be simple shift register upto an independent subsystem. The
basic principle of a shift register will always be present. Command codes as well as data
values will be serially transferred and pumped into a shift register and are then internally
available for parallel processing. The length of the shift registers is not fixed, and can
differ from devices to devices. The shift registers are normally 8Bit or integral multiples
of the bit. There also exist shift registers with an odd number of bits. For example two
cascaded 9Bit EEPROMs can store 18Bit data.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
26
If a SPI device is not selected, its data output goes into a high-impedance state (hi-
Z), so that it does not interfere with the currently activated devices. When cascading
several SPI devices, they are treated as only one slave and therefore connected to the
same chip selected there. There are two meaningful types of connections for master and
slave devices. The Figure 2.2 shows the type of connection for cascading the several
devices.
Figure 2. 2 Cascading several SPI devices
In this architecture the cascaded devices are looked at as one larger device and
therefore receive the same chip selected. The data output of the preceding device is tied to
the input data of the next device, and thus forms a wider shift register. A single chip
select signal is fed into all the slaves and SDO of the first is connected to the SDI of the
next. The data sent into the SDI of the first slave is transferred through all the slaves and
the corresponding output is read out from the SDO of the last slave in the cascading
architecture. An alternative bus structure is shown in Figure 2.3 which the slaves are
independently connected to the master
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
27
Here, the clock and the SDI data lines are brought to each slave. The SDO data lines are
tied together and led back to the master again. Only the chip selected is separately
brought to each SPI device.
Figure 2. 3 Master with independent slaves
Both types may be combined.
It is possible to connect two micro controllers via SPI. For such a network, two protocol
variants will be possible.
1) There is only one master and several slaves
2) Each micro controller can take the role of the master.
For the selection of slaves, two versions would be possible but only one variant is
supported by hardware. The hardware supported variant is with the chip selected, while in
the other the selection of the slaves is done by means of an ID packed into the selected
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
28
frames. The assignment of the IDs is done by the software. Only the selected slave drives
its output, all other slaves are in high-impedance state. As long as the slave is selected by
its address the output remains active
The first variant, which is the single-master protocol, resembles the normal master-slave
communication. The micro controller which is configured as a slave behaves like a
normal peripheral device.
The second possibility works with several masters and is therefore named as multi-master
protocol. Each micro processor also has the possibility to take the roll of the master and to
also address another micro processor.
One controller should always permanently provide a clock signal. There will be two SPI
system errors.
1) The first occurs if several SPI devices want to become master at the same time.
2) The second is a collision error that occurs for example when SPI devices work with
different polarities.
2.2.1 Data and Control Lines of the SPI
The SPI requires two control lines (CS and SCLK) and two data lines (SDI and
SDO). Motorola named these lines as MOSI (Master-Out-Slave-In) and MISO (Master-
In-Slave-Out). The chip select line is named as SS (Slave-Select).
With CS (Chip-Select) the corresponding peripheral device will be selected. This
pin is an active-low. In the unselected state the SDO lines are hi-Z and therefore are
inactive. The clock line SCLK is brought to the device whether it is selected or not. The
clock will serves as synchronization for the data communication.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
29
Majority of SPI devices provide these four lines. Sometimes it happens that SDI and SDO
are multiplexed, for example in the temperature sensor LM74 from National
Semiconductor, or that one of these lines is missing. A peripheral device which must and
cannot be configured, is required no input line, only a data output. As soon as it gets
selected it starts sending data.
2.2.2 SPI Configuration
There is no official specification, what exactly SPI is and what not and as a result,
it is necessary to consult the data sheets of the components which one wants to use. The
permitted clock frequencies and the type of valid transitions are very important.
There are no general rules for transitions where data should be latched. In practice four
modes are used. These four modes are the combinations of CPOL and CPHA. In Table
2.1, the four modes are listed.
Table 2. 1 SPI Modes
SPI-mode CPOL CPHA
0
1
2
3
0
0
1
1
0
1
0
1
If the phase of the clock is zero, i.e. CPHA = 0, data is latched at the rising edge of the
clock with CPOL = 0, and at the falling edge of the clock with CPOL = 1. the polarities
are reversed if CPHA = 1. Falling edge CPOL = 0 means and rising edge CPOL = 1.
The micro controllers from Motorola allow the polarity and the phase of the clock
to be adjusted. A positive polarity results in latching data at the rising edge of the clock.
Data is put on the data line already at the falling edge in order to stabilize it. Most
peripherals which are only the slaves, work with this configuration itself. Transitions are
reversed if it should become necessary to use the other polarity.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
30
2.2.3 SPI v/s I2C
Although both SPI and I 2C provide good support for communication with slow peripheral
devices that are accessed intermittently, each of the way of communication have its own
advantages towards each other. SPI is better suited than I2C for applications that are
naturally thought of as data streams (as opposed to reading and writing addressed
locations in a slave device). An example of a "stream" application is data communication
between microprocessors or digital signal processors. Another is data transfer from
analog-to-digital converters.
SPI can also achieve significantly higher data rates than I2C which is limited to 400 KHz
in most cases. SPI-compatible interfaces often range into the tens of megahertz. SPI really
gains efficiency in applications that take advantage of its duplex capability, such as the
communication between a "codec" (coder-decoder) and a digital signal processor, which
consists of simultaneously sending samples in and out.Table 2.2 gives the comparison
between the interfaces
Table 2. 2 Comparison between SPI and I2C interfaces
SPI I2C
Three bus lines are required; a data input
line (SI1), a data output line (SO1) and a
serial clock line (SCK1)[plus 1 Chip Select
(CS)]
Two bus lines are required; a serial data
line (SDA) and a serial clock line (SCL)
No official specification (component
dependent)
With official specification (I2C protocol
created by Philips)
Higher data rates (up to 10 MHz or more) Support transfer speeds of around 100kHz
(original standard, or 400kHz using the
most recent standard)
More efficient in point-to-point (single
master, single slave) applications
More efficient in multi-master, multi-slave
applications
Lack of built-in device addressing Built-in addressing scheme and
straightforward
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
31
Does not have an acknowledgement
mechanism to confirm receipt of data.
Have an acknowledgement mechanism to
confirm receipt of data
Less overhead when handling point-to-
point application
More overhead when handling point-to-
point application
2.2.4 Quad SPI
Quad SPI module is an advanced version of the commonly used Serial Peripheral
Interface (SPI) module.
The Quad SPI module consists of four data lines and a characteristic two control
lines. The QSPI module which is verified in this project can also operate in dual
mode in which there are two data lines and two control lines. The block diagram
of the QUAD SPI is as shown in Figure 2.4. The quad SPI consists of three sub
blocks Read Ahead FIFO (RAF), Boot SPI (BSPI) and Master SPI (MSPI). The
functionality of these sub blocks is elaborated in the future chapters.
Figure 2. 4 Generic QSPI block diagram
SPI
Control
signals
SPI data
Lines
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
32
2.2.5 QSPI Specifications
65 nm technology
Logic size: 19,656 gates
Memory size: 10,678 gates
Total logic size (gates): 30,334 gates
Total logic size (µm2): 48,534 µm
2
Supply voltage: 3.6 V – 2.7 V
Serial clock (SCK) frequency for read instruction: 40 MHz
Serial clock frequency for other instructions: 80 MHz (single data lane), 104 MHz
(Dual and Quad lanes)
2.2.6 Features of QSPI
Enables CPU to boot from an external SPI flash device via a set of pre fetch
buffers
Flexible command per cycle and bits per cycle
Supports single, dual and quad mode reads
Single AXI interface for data transfer and to configure registers
Two 16-byte read ahead buffers for read operation
2.3 Open Verification Methodology
OVM verification methodology was combinational effort of Mentor graphics and
Cadence by combining the Universal Reuse Methodology (URM) and Advanced
Verification Methodology (AVM) developed. OVM was developed to make full
utilization of the tremendous verification capabilities of SystemVerilog. It was first open
SystemVerilog verification methodology which made very popular.
OVM caters a base classes library which permits users to create, reusable and modular
verification environments in which component classes communicate with each other
through Transaction-Level Modelling (TLM) interfaces. It allows intra-company and also
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
33
inter-company reuse using a common methodology of classes to develop stimulus and
block system reuse.
It is supported on multiple verification tools and hence has become the de facto
standard methodology. It is suited for speed verification for novice as well expert
verification engineers. The OVM class library allows users to create sequential
constrained-random stimulus, aggregate and take into the functional coverage
information, and include assertions in configurable testbench environment. Features are
as follows.
TLM communication as the underlying foundation for connecting verification
components to facilitate modularity and reuse
Common user-extensible phasing to coordinate execution activity of all
components in the environment
Ability to modify test bench environments on-the-fly and write multiple tests from
the same base environment with minimal code changes
Common configuration interface, so all components may be customized on a per-
type or per-instance basis without changing the underlying code
Straightforward test writer interface for configuring a testbench and specifying
constrained layered sequential stimulus
Common message reporting and formatting interface
The main feature of OVM is that it supports functional verification using
SystemVerilog with a supporting library for system verilog code
The 3 main building blocks of OVM based verification are
OVM_components
OVM_env
OVM_test
A generic OVM verification environment is as shown in Figure 2.5. The verification
environment OVM_env of OVM is follows a standard which makes it easy for reuse to
verify a different design. The components OVM_components like Sequencer which
generates the stimulus, driver which drives in stimulus into the DUT, monitor which
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
34
monitor the operations of the DUT for the particular sequence and finally the scoreboard
which keeps a check on transactions taking place inside the environment. The test
OVM_test is derived from ovm_component class and there is no extra functionality is
added. The test can altered according to specific functionality of the design which needs
to be verified.
Figure 2. 5 OVM verification environment
2.4 OVM phases:
Previously verilog modules relied on the simulators to elaborate the overall design
and start its execution but as OVM components are realised through classes they can be
instantiated, connected and run from outside the verilog elaborator.
OVM has standard elaboration simulation phases which it follows. Components
execute their behaviour in strictly ordered, pre-defined phases. Each phase is defined by
its own virtual method, which derived components can override to incorporate
component-specific behaviour. The pre defined stages are as shown in Figure 2.6.
Initially during the build phase all the components of the verification environment are
instantiated. During the connect phase all the components are interconnected and then
during the end of elaboration phase all the connections are hardened which helps to
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
35
inspect the complete verification environment before the simulation begins. The start of
simulation executes just before time 0. Run is a pre defined task phase and all the task are
programmed to run in parallel. The extract phase is intended to collect information
relating to coverage, check phase is where the validation of the extracted data is done and
finally during the report phase all the final reports are produced.
Figure 2. 6 OVM phases (Glasser 2009)
2.5 Testbench Layered Organisation
The test benches in OVM are organised in layer architectures. This helps in
configuring the components and interfaces in an easier way. The layered architecture is as
seen in Figure 2.7. At the lowest layer is the DUT in this case QSPI module with pin level
interface. Next is the transaction layer which consists of devices which convert between
the transaction level and pin level. It consists of Components like drivers, monitors etc
and it is a protocol specific layer.
The next is operational layer which consists of components like stimulus
generators, masters, slaves and constraints above this is the analysis layer which is where
all the analysis of the coverage and reports are done. It consists of components like
coverage collectors, performance analysers, score boards and golden reference models.
This along with the operational layer are design specific which indicates that for the
Build
Connect
End of elaboration
Start of simulation
Run
Extract
Check
Report
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
36
already present verification environment if a new design were to be connected only the
components in these 2 layers need modification. The final layer is the control layer which
consists of a test controller and it is test bench specific which implies that if a new
testbench were to be designed for the same design only the components in this layer
would need modification. This layered architecture helps in improving the reusability of
the verification environment as specific component can be changed for corresponding
modifications.
Figure 2. 7 Layered testbench architecture of OVM (Glasser 2009)
Figure 2.8 shows a concentric components organisation which throws more light on the
interconnection between layers. The inner most ring is equivalent to bottommost layer
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
37
and the outermost ring is equivalent to the top most layer of the layered testbench
architecture.
Figure 2. 8 Concentric testbench organisation (Glasser 2009)
2.5.1 Transactors
The stream of data generated for verification is converted into pin level activity and vice
versa with the help transactors. The transactor is characterised by having at least one pin
level interface which implies direct connection with the ports of the DUT and one
transaction level interface
Monitors: It is used to monitor the bus. It observes the pins and converters the
signals into streams of transactions. They do not affect the operation of the DUT.
Driver: The driver converts the stream of transaction into pin level activity.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
38
Responder: It responds to the activity on the pins unlike the monitor which
initiates the activity.
2.5.2 Operational Components
These components provide the stimulus for the DUT to operate upon. All the components
are transaction level components and have only transaction level interface. The general
operational components include masters, slaves and stimulus generators.
Master: It is bi directional component that intiate the activities like sending and
receiving data. They can be used to send randomised transaction or directed
transaction or also constrained random transactions.
Slave: they like the masters are bi directional components which respond to
requests sent from the master and send responses to intimate the occurrence of an
event to the master
Stimulus Generators: These are used to generate particular transactions which are
intent on making the DUT perform or behave in a particular way. They like the
masters can generate direct, random and constrained random stimulus. They built
for free running or controlled operation and can be configured to operate in an
independent or dependent way according to the application.
2.5.3 Analysis Components
They are used to receive information about the transaction happening within the testbench
and the corresponding outputs generated by the DUT.
Scoreboard: It is used to verify to proper operation of the DUT. It Collects
information fed into the DUT and checks for the corresponding output being
generated and determines if it matches with the expected result.
Coverage Collector: they are used to collect the streams of transactions and count
the transactions or various aspects of the transactions. Its purpose is to determine
the completeness of the verification effort.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
39
2.5.4 Controllers
It forms the main thread of a test and controls the entire activity. Generally
controllers receive information from the Scoreboards and coverage collectors and sends
information to the environment components.
2.6 Summary
The SPI is synchronous serial communication interface which is used for data
transfer between the host processor and the peripherals connected to it. The SPI doesn’t
have a standard protocol of operation and hence it follows the protocol of the peripheral
connected to it. Quad SPI is an advanced version which has a higher throughput than the
conventional SPI and has 4 data lines instead of one. It is preferred serial peripheral
interface ahead of I2C in SoC designs for its high noise immunity, higher data transfer
rates and lesser board area.OVM verification methodology is most sought after in the
industry because of it advanced features like layered testbench organisation which
facilitates reuse and hence in turn saves design time. OVM consists of built in base
classes which can be extended to build other components of the verification environment
and helps achieve high degree of verification effort in lesser time. The next chapter
consists of information in published literature about the various architectures of the QSPI
and how to go about developing a verification environment for effective verification of
SoC designs.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
40
3 - Literature Review on OVM and QSPI
This chapter deals with finding of the literature review conducted for
understanding the working of the SPI and OVM verification environment. The gaps in the
literature mentioned in this chapter for the development of the verification environment
are highlighted.
3.1 Important observations
SPI module plays an important role in the embedded systems and SoC designs as
they provide a high speed and high noise immunity mode of communication between the
host processor and the corresponding peripheral connected.
The goal of adopting a particular methodology is to obtain maximum level of confidence
in the quality of the design in a given amount of time and engineering resources. For
achieving this goal methodologies use assertions, functional abstraction, and automation
through randomization, reuse all at the same time.OVM supports all the above features
and also functional verification.
Verification begins from the specifications: the design specs and the test plans.
The goal for the verification engineers is to create, based on these specs, a full
verification environment, and do that as fast as possible, with minimal effort. Thus the
enablers must be:
Means to capture all SOC specifications and complexity in an executable
form
Automation of all verification activities
Reusability of verification components.
For good quality of verification always functional verification of the design
should be prioratized. Test writing writing should be intense and attack the design by first
random tests and then constraining the random vectors and finally usage of assertion and
directed tests to plug holes in verification
3.2 Overview of Literature Review
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
41
LogiCORE IP AXI Quad Serial Peripheral Interface (AXI Quad SPI) (V1.00a),
Product specification, October 19, 2011, Xilinx, Inc.
The Quad SPI in this application has designed to purely interact with AXI 4 bus
with the serial flash memory devices from winbond/Numonyx which act as the SPI
slaves. The slaves connected are high importance because SPI has no standard protocol
on its own and hence it generally follows the protocol of the devices interfaced with it. In
this application of Xilinx the serial peripherals connected are memories which is same
peripherals targeted in this project. The architecture of Quad SPI is as shown in Figure
3.1.
Figure 3. 1 QSPI Architecture for AXI4 interface and serial flash memory (Xilinx 2011)
The QSPI architecture is configured in Standard SPI mode, the AXI Quad SPI core is a
full-duplex synchronous channel which supports a four-wire interface (receive, transmit,
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
42
clock and slave-select) between a master and a selected slave. In Dual/Quad SPI mode,
this core supports additional pins for interfacing with external memory. These additional
pins are used while transmitting the command, address and data based upon the control
register settings and command used. The core supports manual slave select as the default
operation mode for slave select mode. This mode allows manual control of the slave
select line using the data written to the slave select register, thereby allowing transfers of
an arbitrary number of elements without toggling the slave select line between elements.
However, the slave select line must be toggled before the start of each new transfer.
This architecture is capable of supporting only the AXI bus which is generally a high
traffic and so sending control signals from the processor for data transfer from the serial
flash memory will take critical machine cycles and hence hindering the overall
performance
M68HC11E Family Data Sheet, 2005, Freeescale Seminconductor, Inc.
This paper provides insights into the actual design of the SPI. The architecture used in
this paper is used to support peripheral devices like
Frequency synthesizers
Liquid crystal display (LCD) drivers
Analog-to-digital (A/D) converter subsystems
Other microprocessors
The architecture of SPI is as shown in Figure 3.2 The main block inside SPI architecture
basically consists of a shift register and the read data buffer. In this architecture the
system is single buffered in the transmit direction and double buffered in the receive
direction. This is done to make sure that new data for transmission cannot be written to
the shifter until the previous transfer is complete; however, received data is transferred
into a parallel read data buffer so the shifter is free to accept a second serial character. As
long as the first character is read out of the read data buffer before the next serial
character is ready to be transferred, no overrun condition occurs.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
43
The QSPI architecture SPI status block represents the SPI status functions (transfer
complete and write collision) performed by the serial peripheral status register (SPSR).
The SPI control block represents those functions that control the SPI system through the
serial peripheral control register (SPCR).The SPI allows simultaneous transmission and
reception of data and serial clock of synchronizes the transfer and processing of
information on the data lines.
Figure 3. 2 Architecture of Serial Peripheral Interface (Freescale Semiconductor 2005)
The frame format for this application is as shown in Figure 3.3. A slave select line allows
individual selection of a slave SPI device; slave devices that are not selected do not
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
44
interfere with SPI bus activities. On a master SPI device, the select line can optionally be
used to indicate a multiple master bus contention.
This architecture is capable of operating only in the standard mode of operation at speeds
of 10-20 MHz which is quiet slow compared to advanced Quad SPI which is capable of
operating at speeds upto 80 MHz this increase in throughput is brought about by adding
an extra two data lines hold and wp/n which acts as control signal in standard mode and
data lines in quad and dual mode of operation.
Figure 3. 3 SPI frame format
Guy Mosensoson, Practical Approaches to SOC Verification, Verisity Design, Inc.
Few of the typical areas where bugs can be found in SoC designs are mentioned as
Interactions between blocks that were assumed verified
Conflicts in accessing shared resource
Arbitration problems and dead locks
Priority conflicts in exception handling
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
45
Unexpected HW/SW sequencing
According to this paper verification begins from the specifications the design
specs and the test plans. The goal for the verification engineers is to create, based on these
specs, a full verification environment, and do that as fast as possible, with minimal effort.
Thus the enablers must be:
Means to capture all SOC specifications and complexity in an executable
form
Automation of all verification activities
Reusability of verification components.
The preferred verification approach is to perform hardware and software co verification
as shown in Figure 3.4. For the full verification effort both the hardware and software
must visible to each other and test case should be written understanding the dependencies
of both.
Figure 3. 4 Hardware and Software co- verification
The Limitations of this paper is that the author doesn’t tell as to what steps or how to go
about performing hardware and software co –verification by writing interdependent tests.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
46
D. Geist, G. Biran, T. Arons, M. Slavkin, Y. Nustov, M. Farkas, K. Holtz, A
Methodology For the Verification of a ‘System on Chip, DAC, 2008.
According to this paper the goal of adopting a particular methodology is to obtain
maximum level of confidence in the quality of the design in a given amount of time and
engineering resources. For achieving this goal methodologies use assertions, functional
abstraction, and automation through randomization, reuse all at the same time.OVM
supports all the above features and also functional verification.
Few of the steps are highlighted are:
System based verification,
Software driven flow,
Having a proper test plan,
Setting up test priorities,
Adopting bottom up methodology,
Integrating test for full chip verification
Use of already verified IP’s for faster verification
For good quality of verification always functional verification of the design
should be prioritized. Test writing should be intense and attack the design by first random
tests and then constraining the random vectors and finally usage of assertion and directed
tests to plug holes in verification.
This paper recommends the use of system C verification language instead of
system verilog because according to the author it is more adept for SoC verification but in
the contrary system verilog is tested and verified to be a more adept to SoC verification.
3.3 Gaps in literature review
The Xilinx QSPI architecture is capable of supporting only the AXI bus which is
generally a high traffic and so sending control signals from the processor for data
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
47
transfer from the serial flash memory will take critical machine cycles and hence
hindering the overall performance.
The Freescale semiconductor SPI architecture is capable of operating only in the
standard mode of operation at speeds of 10-20 MHz which is quiet slow compared
to advanced Quad SPI which is capable of operating at speeds upto 80 MHz this
increase in throughput is brought about by adding an extra two data lines hold and
wp/n which acts as control signal in standard mode and data lines in quad and dual
mode of operation.
The design of the sequencer and the data formats for the standard mode of the SPI
is present but the QSPI has operates in 2 more modes which involves configuring
different frame formats.
3.4 Summary of the Literature Review
It is observed from literature review that
• For achieving the goal methodologies use of assertions, functional abstraction,
automation through randomization, reuse all at the same time.OVM supports all
the above features and also functional verification.(Giest 2008)
• A full verification environment, should be able to accomplish the verification task
as fast as possible, with minimal effort which can done by automation of all
verification activities, reusability of verification components. (Mosensoson 2010)
• QSPI has three main modes of operation and control registers for performing
various controlling operation. (Mckenna 2010)
• The present SPI module used as interface between host processor and external
peripherals currently operates at a frequency of 10 MHz with a single data_in line
(Freescale semiconductor 2005).
• Quad SPI module has 4 data lines which can be used for high speed data transfer.
It operates at a higher frequency of 80 MHz (Xilinx 2011).
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
48
• The present verification environment is suitable for verification of low speed
interface and so a new verification environment has to be developed for the
verification of the QSPI module in a short duration (Parag 2011).
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
49
4 – Problem Definition
4.1 Introduction
This chapter discusses the problem statement and definition based on findings in the
literature review. The project objectives obtained from the problem definition have been
described. The methodologies for implementing the objectives have also been described.
The Quad SPI module is a relatively new technology and hence requires new and
advanced verification measures.
4.2 Aim and objectives of the project
4.2.1 Aim
To design and develop an OVM based verification environment for the Quad SPI IP and
to attain maximum possible coverage for the same.
4.2.2 Objectives
• To review literature on Quad SPI module, OVM and verification environments
• To study Quad SPI module functionality and arrive at functional specifications for
verification environment
• To develop OVM based verification environment for Quad SPI
• To identify suitable test cases and verify functionality of Quad SPI
• To perform functional verification and achieving maximum possible coverage of
the QSPI module for various test cases.
4.3 Methods and methodology
• Literature review for Quad SPI protocol IP has been carried out by referring
reviewed journals, books, manuals and related documents.
• Literature review for OVM verification environment has been carried out by
referring reviewed journals, books, manuals and related documents.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
50
• Literature review for developing suitable test cases for attain maximum coverage
has been carried out by referring reviewed journals, books, manuals and related
documents.
• Based on application and reviewed literature design specifications for the
verification environment are arrived at.
• The specifications and design of the individual components OVM has been
carried out.
• Design of the verification environment has been carried out based on
specifications derived using System Verilog hardware design and verification
language and integrating the individual components
• Based on the literature review conducted on quad SPI module test case for its
functional verification has been written
• The functional verification was carried out using the VCS tools and observations
will be documented
• The waveforms have been debugged using the VERDI tool and any bugs will be
reported.
• The quad SPI IP is integrated into the verification environment and tests are run.
• The tests are run using the different test cases in the designed environment using
the VCS tool.
• Based on the literature review conducted the techniques used for attaining more
coverage for the QSPI design are adopted.
• Coverage driven verification methodologies are implemented in order to attain
more coverage.
• Maximum coverage for QSPI IP obtained using the VCS tool and the waveform
debug tool VERDI are reported.
4.4 Resources Used
• Computing Resources
PC with 1 GB RAM, Pentium 4 Processor
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
51
• Software Resources
VCS (Verilog Compiler Simulator)
VERDI (Visualization Environment for Rich Data Interpretation)
• Literature
Books, Journals
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
52
5-Design of Quad SPI
This chapter includes the description and design of sub-blocks of the QSPI module and
the interfaces of the QSPI with the other blocks of the SoC. It also gives an insight into
the various modes of operation of the QSPI and the SPI flash memory device operations.
5.1 Introduction to QSPI for serial flash memory peripheral
SPI is the most preferred serial bus architecture after SoC design applications. It
basically consists of two data lines for data communication and three control signals. The
SPI can be configured as a master or slave based on the application. There is no particular
or specified protocol for the data communication for the interface but for complex
applications a higher level protocol can be implemented according to the application. The
QSPI module is an advancement of the SPI interface as it contains 4 data lines for faster
data transfer.
The basic functionality of SPI interface is controlled data transfer from the memory to the
processor which can be done in 3 different ways mentioned above with each of modes
have specific purpose. The specifications include
65 nm technology
Supply voltage: 3.6V – 2.7 V
Serial clock (SCK) frequency for read instruction: 40 MHz
Serial clock frequency for other instructions: 80 MHz (single data lane),104 MHz
(Dual and Quad lanes)
5.2 Top level block diagram of QSPI
The block diagram of the QSPI is as shown in Figure 5.1. The QSPI is connected to the
AXI bus for read operations through the BSPI. The AXI bus is for large data
communication within the system. The data read from the flash memory is returned to the
processor through the AXI bus. The reason for implementing each of the blocks will be
explained in the upcoming section. The AXI to RBUS converter converts the signals from
the bus into the simple RBUS or APB bus format which is then fed into RAF, BSPI and
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
53
MSPI. The RBUS bridge shares the data on the bus to the various blocks according to the
application requirement. The APB is used to transfer commands from the processor into
the MSPI and RAF for required operation to be performed on the SPI flash memory
connected to the interface.
Figure 5. 1 Block diagram of QSPI
5.3 Device operations
The configuration of the QSPI along with various flash memory slaves as shown in
Figure 5.2. The number of Chip select signals depends on the number of slaves connected
to the interface in this case its three. Based on the number on the chip select signal the
corresponding slave memory as accessed. The SPI acts as the master and sends a SCLK
AXI
System
bus
Interface to
control register data
transfer
SPI
Control
signals
SPI data
Lines
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
54
clock signal to the slave after which the data is transfer on the required clock edge. The
clock edge for the transmission of data can also be configured using the CPOL or clock
polarity signal.
Figure 5. 2 QSPI in single master and multiple slaves configuration (S25FL128R 2009)
Few of the operations which can be performed on the flash memories connected to the
QSPI are as follows
Quad Page programming
The Quad Page Program (QPP) instruction allows up to 256 bytes of data to be
programmed using 4 pins as inputs at the same time, thus effectively quadrupling the data
transfer rate, compared to the Page Program (PP) instruction. The Write Enable Latch
(WEL) bit must be set to a 1 using the Write Enable (WREN) command prior to issuing
the QPP command.
Dual and QUAD I/O mode
QSPI device supports Dual and Quad I/O operation when using the Dual/Quad Output
Read Mode and the Dual/Quad I/O High Performance Mode instructions. Using the Dual
or Quad I/O instructions allows data to be transferred to or from the device at two to four
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
55
times the rate of standard SPI devices. When operating in the Dual or Quad I/O High
Performance Mode (BBh or EBh instructions), data can be read at fast speed using two or
four data bits at a time, and the 3-byte address can be input two or four address bits at a
time.
Monitoring write operation using the status register
The host system can determine when a Write Register, program, or erase operation is
complete by monitoring the Write in Progress (WIP) bit in the Status Register. The Read
from Status Register command provides the state of the WIP bit. Two additional bits in
the Status Register (P_ERR, E_ERR) to indicate whether a Program or Erase operation
was a success or failure.
Sector erase or bulk erase
The Sector Erase (SE) and Bulk Erase (BE) commands set all the bits in a sector or the
entire memory array to 1. While bits can be individually programmed from 1 to 0, erasing
bits from 0 to 1 must be done on a sectorwide (SE) or array-wide (BE) level. In addition
to the 64-KB Sector Erase (SE).
Hold mode
The Hold input (HOLD#) stops any serial communication with the device, but does not
terminate any Write Registers, program or erase operation that is currently in progress.
The Hold mode starts on the falling edge of HOLD# if SCK is also low). If the falling
edge of HOLD# does not occur while SCK is low, the Hold mode begins after the next
falling edge of SCK (non-standard use). The Hold mode ends on the rising edge of
HOLD# signal (standard use) if SCK is also low. If the rising edge of HOLD# does not
occur while SCK is low, the Hold mode ends on the next falling edge of CLK
(nonstandard use).
The Table 5.1 gives the commands for the various operations to performed on the SPI
flash memory through the QSPI.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
56
Table 5. 1 Instruction set for SPI flash memory (S25FL128R 2009)
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
57
5.4 Sub blocks design
The design of the 3 main sub blocks of the QSPI module is explained along with their
corresponding input and output signals.
Quad SPI module which includes
Direct boot read from the memory using Boot Serial Peripheral Interface (BSPI)
Register routed read from the memory using Read Ahead Register (RAF)
The master read and write using Master Serial Peripheral Interface (MSPI)
5.4.1 Master Serial Peripheral Interface
This module acts as the master for the several peripherals connected to the processor
sending commands for the read and write operations through the four data lines. The
MSPI is configured using the APB bus which is used for register configuration. The block
diagram of the MSPI is as shown in Figure 5.3.The MSPI is fed in the address location
through the PADDR signal of the corresponding slave out of the 16 slaves connected to it.
The operation to be performed is based on PWRITE signal and the corresponding
command instruction is sent into the flash memory through the mspi_flash_out to read or
write data. The signal description of the RBUS or APB is as shown in Table 5.2
Figure 5. 3 Block Diagram Master SPI
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
58
Table 5. 2 APB Signal description (ARM 2004)
5.4.2 Boot Serial Peripheral Interface
The boot SPI is purely for the fast read data read operation at the boot time. The AXI bus
interfaced with the BSPI is purely used for read operation and no write is allowed. During
the boot the BSPI is programmed to automatically and independently read from the flash
drive connected the processor hence saving valuable processing cycles. The block
diagram of the BSPI block is as shown in Figure 5.4.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
59
Figure 5. 4 Block Diagram Boot SPI
The read channel signals description of the AXI bus is given in Table 5.3 and the address
channel signals description is as shown in Table 5.4
Table 5. 3 AXI read channel Signal description (ARM 2003)
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
60
Table 5. 4 AXI address channel Signal description (ARM 2003)
5.4.3 Read Ahead FIFO
The read operation from the flash memory peripheral is done directly from the BSPI or
can be done through the RAF module for better control over data extraction. RAF is a
DMA like module which provides efficient access. It works on a separate clock called
Rbus clock. The block diagram of the RAF block is as shown in Figure 5.4. the read is
performed using the APB or Rbus.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
61
Figure 5. 5 Block Diagram RAF
5.5 Summary
QSPI module basically contains three major blocks which include MSPI, BSPI and RAF
which interact with the systems buses like AXI and APB to bring about specific
functionality. In this application the peripheral connected to the QSPI are serial flash
memories hence the main functionalities of the QSPI is to read and write from
corresponding memory and also bulk erase operation.
The BSPI is configured to read from the flash memory during boot independent of the
processor clock cycles and uses AXI buses for data communication. The MSPI is used to
read and write commands and data according the serial flash memory protocol. The RAF
performs indirect read and write operations complimenting the MSPI into SPI Flash
memory using the RBUS.
The next chapter deals with the development of the OVM verification environment for
the QSPI described in this chapter and also verification of the modes of operation of the
QSPI after its integration into environment.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
62
6 – Implementation of OVM Verification Environment
This chapter provides an overview of the design of an OVM based verification
environment for a QUAD SPI module which sits inside a networking SoC called IPROC
from Broadcom. Verification of SoC designs is a very complex and time consuming
procedure and so verification industry experts have adopted modular verification strategy
according to which the large design is initially broken down to smaller modules and each
of these modules are separately verified for the required functionality. After this the
modules are again integrated and a final verification is carried out on the SoC. This
procedure helps in understanding and debugging any faults which arise during the
verification.OVM facilitates the construction of verification environments and tests, both
by providing reusable machinery in the form of a library of System Verilog classes, and
also by providing a set of guidelines for best practice when using System Verilog for
verification.
6.1 Introduction to OVM verification environment development
The productivity of verification can be enhanced by reusing verification
components, and this is one of the main objectives of OVM. Verification reuse is made
possible by having a verification environment which is modular in nature where each
component has clearly defined responsibilities, it allows flexibility in the way in which
components are used and configured, by having a mechanism which allows imported
components to be customized in accordance to the application at hand, and by having
well-defined coding guidelines to ensure consistency.
Open Verification Methodology (OVM) key features include a base class’s library which
permits users to create, reusable and modular verification environments in which
component classes communicate with each other through Transaction-Level Modelling
(TLM) interfaces. It allows intra-company and also inter-company reuse using a common
methodology of classes to develop stimulus and block system reuse. OVM is used for
faster verification of modules which provides adequate verification effort. In this project
for the verification of the Quad SPI module the modified OVM verification is
environment is used in which the verification environment consists of sub blocks like
Sequencer, Checker and Generator.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
63
The design of the OVM verification environment encourages layered and modular
verification environments, in which verification components in all layers can be reused in
different environments. Low-level driver and monitor components can be reused across
multiple designs-under-test. The entire verification environment can be reused by
multiple tests and modified top-down by those tests. The scenarios can be reused for
various applications. This amount of reuse is made possible by having OVM verification
components to be configured in a very flexible way without much alteration to their
source code.
6.1.1 Functional verification:
The main purpose of performing functional verification is ensuring that the design
implements the intended functionality or design intent.
Figure 6. 1 Functional verification concept
Functional verification approaches:
Black box verification:
In this approach there is least amount or no knowledge of the actual
implementation of the design
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
64
this approach suffers from lack of visibility and controllability
the advantages is that it is independent of implementation of design it is not
concerned if it is ASIC, FPGA, gate level based
White box:
It has full visibility and controllability of internal structure and implementation of
the design being verified.
This method is tightly tied to a particular implementation and changes in design
may require changes in the testbench
It is compliment to the black box technique and can be used to ensure that low
level implementation specific features behave properly.
It is also called as system level verification as it is concerned about system
verification than individual components.
Grey box:
It contains both the features of black and white box techniques.
Test cases may or may not be relevant on another application
Adds functions to the design to increase Observability and controllability
The white box functional verification technique is used in this implementation as the
internal structures and design implementation on SoC were known.
The QUAD SPI module is integrated into the OVM verification based environment. The
QSPI module is verified for its functionality in the 3 and 4 byte addressing mode for the
single and dual and quad lane modes in each of the 3 sub blocks of the QSPI namely
1. Boot Serial Peripheral Interface (BSPI)
2. Master Serial Peripheral Interface (MSPI)
3. Read Ahead FIFO (RAF).
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
65
6.2 Block diagram of the OVM based verification environment
The block diagram for the OVM based Verification Environment for the Quad Serial
peripheral interface is as shown in Figure 6.2. Broadcom is developing a SoC for network
application called IPROC. The Quad SPI module is a part of this SoC. The QSPI module
has interfaces as can be seen in the Figure 6.2
Advanced eXtensible interface (AXI)
Advanced Peripheral Bus (APB)
SPI flash memory
The QSPI interacts with the ARM processor through the AXI bus in the SoC. The AXI
bus is used purely for reads during the boot when accessing the SPI. The APB interface is
used for writing into and read from the control registers housed inside the interface. The
SPI Flash memory is written into or read from using the data lanes which can be
configured according the mode of operation of the QSPI block. The verification
environment is in the top level consists of a Test generator which generates the test
patterns and a sequencer which routes these test to the ARM processor and the checker
which validates the operation of the QSPI by comparing the data being sent through the
test case and the corresponding output obtained from the memory.
6.3 Design of verification environment components
6.3.1Sequencer:
A series of transaction is called a sequence and the flow of transaction generation is
controlled by a sequencer.The sequence class is defined by extending ovm_sequence
class. ovm_sequencer does the generation of this sequence of transaction, ovm_driver
takes the transaction from Sequencer and processes the packet/ drives to other component
or to DUT. The sequencer should send in the data into the processor in accordance to the
AMBA AXI 3 bus protocol.
The AMBA AXI has four independent channels namely
Address channel
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
66
Read channel
Write channel
Write response channel
Figure 6. 2 Block Diagram of the OVM based verification Environment
For the transmission of data between the modules attached to the bus at either ends.
Different configurations of channels are used different transactions. For example for a
write transaction first the address and control information is sent on the address channel
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
67
from the master after which in the immediate next clock cycle the data to be
written to the slave is sent in form of burst transactions. The number and size of the burst
are configured considering the need of the design.
Next the write response channel is used by the slave to send a response to the
master to confirm the successful completion of the transaction. The AXI bus as stated
earlier is required for backdoor writes into the flash memory for the verification purpose
and also during the read from the memory during booting of the system through the BSPI
module of the QSPI. Hence the sequencer class must be designed to handle both the
interfaces and the protocols.
6.3.2 Test case generator:
The generator is class which decides the actual data that needs to sent into the DUT check
for the desired functionality. The different modes of operation and all possible scenarios
should be covered. For this the test generator class has been programmed with knobs
which decide which particular operation to check for. For each of the modules inside the
QSPI there are separate knobs which check for 3 byte and 4 byte addressing mode for
single lane dual lane and quad lane operation modes. The test data is produced in random
fashion constraint random fashion in accordance to the need of the design which helps
improve the overall coverage of the module.
6.3.3 Checker
The checker class is design to check for the correlation between the results obtained to the
expected output related to the particular type input stimulus provided to the DUT by the
test generator. The checker is designed to interact with the ARM processor which is used
to perform the back door write into the flash memory and on the other hand reads from
the flash memory to correlate the data being written into the read out from it. The checker
helps in debugging any faults in the design.
6.4 Implementation of test cases
The SPI does not have a standard protocol and is generally operated in the master
slave protocol according to which the master instigates the data transfer by sending the
PCLK clock signal into slave after which according to the command the full duplex data
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
68
communication between the two takes place. There is no acknowledgement for a
completed transmission and nothing to validate the integrity of the signal. This can be
used for simple applications. For complex application the SPI adopts to protocol specified
by the peripheral in this case spansion flash memory device.
The timing diagram of the protocol for a simple read data transfer is as shown IN
Figure 6.3. Initially the Chip select (CS) signal is made low after which the Serial clock is
sent to the slave to start the transfer of the 8 bit instruction followed by the 24/32 bit
address and a dummy byte of instruction is sent only in quad and dual mode of operation.
At the falling edge of the serial clock the data from the peripheral is read into the master
through the SIO1 data line after which the data is processed to the host processor.
Figure 6. 3 Frame format for quad mode
6.4.1 Steps Implemented for testbench design
Setting up the verification environment and its components extending the base
classes provided in the OVM library.
Connecting all the components based on the transaction level model
Implementing a fully randomised testbench and then analysing the coverage
results and indentifying the coverage holes
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
69
Implementing constrained random stimulus to cover the holes indentified and
performing the coverage analysis again
Writing directed test bench stimulus to cover the remaining coverage holes and
obtain the final coverage
6.4.2 Implementation of SPI and serial flash memory interface block
The interface of QSPI and flash memory is as shown in Figure 6.4. the interface is used to
encapsulate all the communication between the top modules. It includes connectivity
definition, modports and clocking blocks.
6.4.3 Sequence generation
The sequence is modelled in the form of burst for the transactions. The are 3 main types
of bursts which are implemented on AXI and APB buses.
Fixed burst:
In this the address location remains unchanged for each transfer in the burst. This is used
in applications where repeated read or write from one particular location is required. It is
similar to reading or writing into a FIFO
Incrementing burst:
interface input_transfer (input bit SCK);
wire [7:0] command_data;
wire [23:0] mem_addr;
reg CS;
clocking block cb@(posedge SCK);
ouput read_data;
endclocking
modport IP (clocking cb, input SCK);
endinterface
Figure 6. 4 Interface block of QSPI
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
70
In an incrementing burst the address is automatically incremented after each transfer
within a burst. The incrementing value can be configured based on the size of the burst.
Wrapping burst:
It is similar to the incrementing burst but when the wrap boundary is reached it wraps
round to a predefined lower address. The wrap boundary is the size of the each transfer in
the burst multiplied by the total number of transfers in the burst. The wrapping burst
mode of data transfer is used by the sequencer to transfer data into the DUT.
It has 2 main restrictions
The start address should be aligned to the size of transfer
The length of the burst must be 2, 4, 8 or 16 only.
The following expression are used to determine the address of transfers with in a burst
Aligned_address =(INT (strat_address/number_bytes)) * number_bytes
Where:-
start_address is the location from which the data transfer has to begin. This is
decided by the master
number_bytes is the maximum number of bytes in each data transfer
INT is a function used to round off the value obtained to nearest integer.
The following expression is used to determine the wrap_boundary
Wrap_boundry=(INT(start_address/(number_bytes*burst_length))*(number_bytes*burst_
length)
The code for burst generation is as shown in Figure 6.5
read_data (bit [31:0] address, reg [7:0] data, int unsigned size=4);
barray data;
for (int i=0;i<size;i++)
data.bytes[i]= data[i^8+:8];
end
endtask
Figure 6. 5 code for wrap burst data generation
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
71
The implementation for each of the sub-blocks is shown along the interface
signals for each interface to highlight which interface is used which mode of operation
and also the particular sub-block. The interface signals are grouped as shown in Figure
6.3.
The first group is the signals from the AXI bus interface with the QSPI interface,
second group is the address read channel interface of the AXI bus, the third group is the
data lines of the QSPI, fourth group indicates the read data signals of the AXI interface,
fifth group shows the signals used to program the control registers to specify the mode of
operation of the QSPI and final group indicates the signals from the APB bus interface.
Figure 6. 6 Interface signals for QSPI Verification Environment
Control
signals
Read
address
Read address
Control
Signals
Address
QSPI data
lanes
Read
data
APB
interface
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
72
6.5 Summary
The OVM verification environment is set up by extending the base_class classes provided
in the OVM library. The verification environment developed consists of a sequncer which
generates burst of in wrapping burst of 16 bits length, a test case generator and checker to
verify the data. The MSPI, BSPI and RAF sub blocks of the QSPI are verified separately
using the OVM verification environment. The test cases for each of the blocks are
generated according the interfaces connected to the blocks in the design. The
implementation of the test cases is done inside the OVM based verification environment
developed.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
73
7 – Results and Discussions
This chapter shows the actual coverage achieved along the regression test which involves
verifying each block of the QSPI as unified block.
7.1 Coverage analysis
Coverage is used to measure the efficiency of verification implementation. It
provides a quantitative measurement of the testing space. It describes the degree to which
the source code of the QSPI has been verified. It is also referred as structural coverage.
Following classification in the code coverage is reported for the QSPI with the linear,
constrained random and test case has been identified to improve the coverage through the
verification environment.
Statement coverage /line coverage
Block/segment coverage
Branch coverage
Toggle coverage
Path coverage
7.1.1 Line Coverage
Statement coverage, also known as line coverage is the easiest understandable
type of coverage. This is required to be 100% for every project. From N lines of code and
according to the applied stimulus how many statements (lines) are covered in the
simulation is measured by statement coverage. It considers only the executable statements
.Line coverage of the design QSPI for linear TB is reported at 64.7% and 89.88% for
constraint random test bench.
7.1.2 Block Coverage
The nature of the statement and block coverage looks somewhat same. The
difference is that block coverage considers branched blocks of if/else, case branches,
wait, while, for etc. Block coverage of the design QSPI for linear TB is reported 45.19%
for linear test bench and 49.87% for constraint random test bench.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
74
7.1.3 Branch coverage
Branch coverage which is also called as Decision coverage report s the true or
false of the conditions like if-else, case and the ternary operator (?:) statements. For an
"if" statement, decision coverage will report whether the "if" statement is evaluated in
both true and false cases, even if "else" statement doesn't exist, Branch coverage the
design of QSPI for linear TB is reported 64.51% for linear test bench, 82.97% for
constraint random test bench.
7.1.4 Path Coverage
Path coverage represents yet another interesting measure. Due to conditional
statements like if-else, case in the design different path is created which diverts the flow
of stimulus to the specific path. Path coverage is considered to be more complete than
branch coverage because it can detect the errors related to the sequence of operations.
Path will be decided according to the if-else statement According to the applied stimulus
the condition which is satisfied only under those expressions will execute, the path will be
diverted according to that. Path coverage is possible in always and function blocks. Path
created by more than one block is not covered.
7.1.5 Toggle Coverage
It makes assures that how many times variables and nets toggled? .Toggle
coverage could be as simple as the ratio of nodes toggled to the total number of nodes
.Toggle coverage of the design QSPI for linear TB has been reported has 56.41%, 58.93%
for constraint random test bench.
7.2 Simulation results
7.2.1 Boot Serial Peripheral Interface
The boot SPI is purely for the fast read data read operation at the boot time. The AXI bus
interfaced with the BSPI is purely used for read operation and no write is allowed. During
the boot the BSPI is programmed to automatically and independently read from the flash
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
75
drive connected the processor hence saving valuable processing cycles. The control signal
bits per phase [9] operations are:
0 –configures number of address bits to 24
1- configures number of address bits to 32
7.2.1.1 BSPI in 3 byte addressing and single data lane mode
Figure 7.1 shows the simulation result for the BSPI configured for a 3 byte addressing
mode and in a single data lane mode. The sequencer configures the address length to be 3
byte long and QSPI control signals for fast read are fed into the input of the QSPI and the
output is available on a single MISO lane.
Figure 7. 1 3byte addressing mode in single data lane mode
Start address of
0600h
Input control signals at intervals of 28
clock cycles
Output at single
data line
0 to indicate 24
bits address APB signals no
activity
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
76
The start address for the 3 byte addressing mode is randomised in the range 0000h-1EFFh
after the base address of the flash drive.
The start address as can be seen in the Figure 7.1 starts in the range 0600h up to
1EFFh indicating that the BSPI is operating the 3 byte addressing mode as
configured in the control registers
The QSPI output is seen only on the MISO data line indicating that the BSPI is
operating the single data lane mode
The APB signals are unaltered indicating the only the AXI bus is used for read
operation
The read data operation is valid and successful as rvalid signal is set high after
each operation
7.2.1.2 BSPI in 3 byte addressing and dual data lane mode
Figure 7.2 shows the simulation result for the BSPI configured for a 3 byte addressing
mode and in a dual data lane mode. The sequencer configures the address length to be 3
byte long and QSPI control signals for fast read are fed into the input of the QSPI and the
output is available on both MOSI, MISO lane.
The start address as can be seen in the Figure 7.2 starts in the range 0600h up to
1EFFh indicating that the BSPI is operating the 3 byte addressing mode as
configured in the control registers
The QSPI output is seen on both MISO, MOSI data line indicating that the BSPI
is operating the dual data lane mode
The APB signals are unaltered indicating the only the AXI bus is used for read
operation
The read data operation is valid and successful as rvalid signal is set high after
each operation
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
77
Figure 7. 2 3byte addressing mode in dual data lane mode
7.2.1.3 BSPI in 3 byte addressing and quad data lane mode
Figure 7.3 shows the simulation result for the BSPI configured for a 3 byte addressing
mode and in quad data lane mode. The sequencer configures the address length to be 3
byte long and QSPI control signals for fast read are fed into the input of the QSPI and the
output is available on MOSI, MISO, WP_n and HOLD_n lane.
The start address as can be seen in the Figure 7.3 starts in the range 0600h up to
1EFFh indicating that the BSPI is operating the 3 byte addressing mode as
configured in the control registers
The QSPI output is seen on both MISO, MOSI, WP_n and HOLD_n data lines
indicating that the qSPI is operating the quad data lane mode
The APB signals are unaltered indicating the only the AXI bus is used for read
operation
Start address of
0600h
Output at dual data line
APB signals no
activity
Data read from
flash
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
78
The read data operation is valid and successful as rvalid signal is set high after
each operation
Figure 7. 3 4byte addressing mode in quad data lane mode
7.2.1.4 BSPI in 4 byte addressing and single data lane mode
The start address for the 4 byte addressing mode is randomised in the range 1F00h-FFFFh
after the base address on the flash drive. Figure 7.4 shows the simulation result for the
BSPI configured for a 4 byte addressing mode and in single data lane mode. The
sequencer configures the address length to be 4 byte long and QSPI control signals for
fast read are fed into the input of the QSPI and the output is available on MOSI lane.
The start address as can be seen in the Figure 7.4 starts in the range 1F00h up to
FFFFh indicating that the QSPI is operating the 4 byte addressing mode as
configured in the control registers
The QSPI output is seen on both MISO, data line indicating that the QSPI is
operating the single data lane mode
Start address of
0600h Output at all four data line
APB signals no
activity
Data read from
flash
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
79
The read data operation is valid and successful as rvalid signal is set high after
each operation
Figure 7. 4 4byte addressing mode in single data lane mode
7.2.1.5 BSPI in 4 byte addressing and dual data lane mode
Figure 7.5 shows the simulation result for the BSPI configured for a 4 byte addressing
mode and in a dual data lane mode. The sequencer configures the address length to be 4
byte long and QSPI control signals for fast read are fed into the input of the QSPI and the
output is available on both MOSI, MISO lane.
The start address as can be seen in the Figure 7.5 starts in the range 1F00h up to
FFFFh indicating that the QSPI is operating the 4 byte addressing mode as
configured in the control registers
Start address of
1F00h
Output at single data line
Data read
from
flash
1 to indicate 32
bits address
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
80
The QSPI output is seen on both MISO, MOSI data line indicating that the BSPI
is operating the dual data lane mode
The APB signals are unaltered indicating the only the AXI bus is used for read
operation
The read data operation is valid and successful as rvalid signal is set high after
each operation
Figure 7. 5 4byte addressing mode in dual data lane mode
7.2.1.6 BSPI in 4 byte addressing and Quad data lane mode
Figure 7.6 shows the simulation result for the BSPI configured for a 4 byte addressing
mode and in quad data lane mode. The sequencer configures the address length to be 4
byte long and QSPI control signals for fast read are fed into the input of the QSPI and the
output is available on MOSI, MISO, WP_n and HOLD_n lane.
The start address as can be seen in the Figure 7.6 starts in the range 1F00h up to
FFFFh indicating that the BSPI is operating the 4 byte addressing mode as
configured in the control registers
Start address of
1F00h
1 to indicate 32 bits
address
Output at dual data lines
Data
read from
flash
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
81
The QSPI output is seen on both MISO, MOSI, WP_n and HOLD_n data lines
indicating that the QSPI is operating the quad data lane mode
The APB signals are unaltered indicating the only the AXI bus is used for read
operation
The read data operation is valid and successful as rvalid signal is set high after
each operation
Figure 7. 6 4byte addressing mode in Quad data lane mode
7.2.2 Master Serial Peripheral Interface
This module acts as the master for the several peripherals connected to the processor
sending commands for the read and write operations through the four data lines. The
MSPI is configured using the APB bus which is used for register configuration. Figure
7.7 and 7.8 shows the MSPI operating in single data line mode. Figure 7.8 shows the
value for read operation through APB bus from the flash memory control.
Start address of
1F00h
Data
read from
flash
Output at all four data line
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
82
Figure 7. 7 MSPI single data lane mode
Figure 7. 8 MSPI single data lane mode
7.2.3 Read Ahead FIFO
The read operation from the flash memory peripheral is done directly from the BSPI or
can be done through the RAF module for better control over data extraction. RAF is a
AXI bus idle Comm
and
(1C
h)for
fast
read
Corresponding
output
Read address
APB
protocol
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
83
DMA like module which provides efficient access. It works on a separate clock called
Rbus clock. It is used for both read and writes operations in QSPI. Figure 7.9 shows the
simulation result for the test cases designed to read from the flash memory through RAF.
Figure 7. 9 RAF single data lane mode
7.3 Regression results
The regression is process of combining the all the sub blocks in the design and combining
them to verify them as one unit. All the test cases for each block are run at a time to
verify the proper functionality of the design. Figure 7.10 shows the regression results for
the entire block of QSPI.
Read
operation
Purely APB
interface
Register
write
operation
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
84
Figure 7. 10 Regression result for QSPI module
7.4 Coverage report
The overall coverage report for the QSPI module is shown in Figure 7.11. The line
Conditional and toggle coverage for each block is shown. The maximum overall coverage
attained for QSPI block is
Line :89.88
Conditional: 83.63
Toggle: 58.93
The toggle coverage stands at a very low value because many signals of the AXI interface
for write operation need not be verified and hence the signals involved in the interface
remain un-toggled
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
85
Figure 7. 11 Coverage report for QSPI module
7.4 Summary
The final coverage obtained for the QSPI block stands at 89.3% line coverage, 83.62%
conditional coverage and 57% toggle coverage. The coverage values are based on the fact
that few of the functionality of the module are not used in the parent design. The required
functionality of the QSPI has been successfully verified.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
86
8-Conclusions and recommendations for future work
The conclusions drawn based on the modelling of the OVM based verification
environment for QSPI module recommendations on future work are discussed.
8.1 Conclusion
The design implementation flow and the verification methodology adopted for
verifying the QSPI has been designed and verified.
The environment has been designed, which is developed using the OVM base
classes is reusable and configurable according to any serial communication design
A verification environment has been developed to verify this QSPI design and
functional coverage is reported for the implemented design. Function simulation
and function coverage is carried out using Synopsys VCS, VERDI tools
Functional verification of QSPI is carried out by applying constraint random test
cases. Line coverage is reported 89.32 %, conditional coverage is reported at
83.62 % and toggle coverage is reported at 58.33 % for constraints random test
cases
The coverages values obtained are only for the functionality of the module which
is required for the SoC on which is implemented and hence the overall coverage
of the module can be increased if the entire functionality of the design is verified
8.2 Recommendations for future work:
The present verification environment can be enhanced for verification of other
communication protocols with suitable modifications the test cases block of the
design
The verification environment design complexity can be reduced by using the
enhanced features of the System verilog language which is used to design it.
The verification environment can be tool and language independent so that any
design can be verified on any platform
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
87
References
ARM IHI 0022A (2003), AMBA AXI protocol specification revision:r0p0, ARM
limited
ARM IHI 0024B (2004), AMBA 3APB protocol specification, ARM limited
BCM21551 product brief. (2007), Single-Chip 65-nm HSUPA + RF + BT + FM +
Multimedia SoC. Broadcom Corporation, California USA.
D. Geist, G. Biran, T. Arons, M. Slavkin, Y. Nustov, M. Farkas, K. Holtz (2008), A
Methodology For the Verification of a ‘System on Chip, DAC, Louisiana.
Daniel McKenna, Using the QuadSPI Module on MPC56xxS, freescale
semiconductors, application note, Document Number: AN4186
DS843 (v1.00a). (2011), LogiCORE IP AXI Quad Serial Peripheral Interface (AXI
Quad SPI , Xilinx Inc, USA
Guy Mosensoson (2010), Practical Approaches to SOC Verification, Verisity Design
Inc.
Janick Bergeron (2006), Verification methodology manual for SystemVerilog, Springer
Pvt. Ltd., London.
Mark Glasser.(2009),Open Verification Methodology Cookbook. USA: Springer
Molina and O. Cadenas (2007), Functional verification: approaches and challenges,
Computer architecture Department, Universitat politecnica de catalunya,
Barcelona, Spain.
Parag Goel, Pushkar Naik (October 22nd
2011), System Verilog + OVM: Migrating
Verification Challenges and Maximizing Reuseability , Applied
Microelectronics.
Pretez landau, Guy Regev (2009), A Methodology for Timely Verification of a Complex
SoC, Percello Ltd., USA.
S25FL128R (2009), 128 Megabit CMOS 3.0 Volt Flash Memory with 104-MHz SPI
(Serial Peripheral Interface) Bus, Spansion Datasheet.
Santanu Chattopadhyay (2010), Embedded System Design, PHI learning pvt. Ltd.,
USA.
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
88
Appendix
The log file for the BSPI 3 byte operation indicating the successful matching of the data
read from the SPI flash and the data which was actually written into the flash through the
backdoor.
Logfile:
[ 6212.0ns] iproc_soc.iproc_tbc.scn.spif : Initiating SPI Flash Read of 0 bytes
from 1e400400 address
[ 6212.0ns] iproc_soc.iproc_tbc.scn.spif : Beat Len = 8, beat_size= 2
[ 6212.0ns] iproc_soc.iproc_tbc.scn.spif : BSPI Read initiated with
Burst=WRAP, Size = 4, Length = 8 , Address = 1e400400, total len = 32
[ 6212.0ns] iproc_soc.iproc_tbc.scn.spif : Aligned address = 400400, wrap = 0
[ 6212.0ns] iproc_soc.iproc_tbc.scn.spif : Write Backdoor to spi flash at address
= 400400 for INCR Xfer
[ 6212.0ns] iproc_soc.iproc_tbc.driver.spif : BSPI Read started from Address (
1e400400) , Beat Size = 4, Beat len = 8 , Param = a4
[ 6212.0ns] iproc_soc.iproc_tbc.Mctlr.ihost_axi.m0 : mem_rd :: address =
1e400400 byte_count = 32 nbytes = 4 burstlen = 8 arsize = 2 burst=Wrap
*Denali* <top.usb30d_pipe>@6244 ns :: Pipe FSM state: Pipe_SeqIdle =>
Pipe_SeqResetStart
*Denali* <top.usb30d_pipe>@6252 ns :: Pipe FSM state: Pipe_SeqResetStart =>
Pipe_SeqReset
*Denali* <top.usb30d_pipe>@6252 ns :: LTSSM FSM state: Ltssm_PollingLFPS
=> Undefined
*Denali* <top.usb30d_pipe>@6316 ns :: Pipe FSM state: Pipe_SeqReset =>
Pipe_SeqResetDeassert
*Denali* <top.usb30d_pipe>@6340 ns :: Pipe FSM state: Pipe_SeqResetDeassert
=> Pipe_SeqIdle
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
89
*Denali* <top.usb30d_pipe>@6340 ns :: LTSSM FSM state: Undefined =>
Ltssm_SsDisabled
*Denali* <top.usb30d_pipe>@6348 ns :: LTSSM FSM state: Ltssm_SsDisabled
=> Ltssm_RxDetectReset
*Denali* <top.usb30d_pipe>@6356 ns :: LTSSM FSM state:
Ltssm_RxDetectReset => Ltssm_RxDetectActive
*Denali* <top.usb30d_pipe>@6380 ns :: LTSSM FSM state:
Ltssm_RxDetectActive => Ltssm_PollingLFPS
*Denali* <top.usb30d_pipe>@9740 ns :: Pipe FSM state: Pipe_SeqIdle =>
Pipe_SeqRcvrDet
[ 18549.0ns] iproc_soc.iproc_tbc.driver.spif : BSPI Read data from Address (
1e400400) is
[ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : Write data
Byte Array: cnt = 32
06 00 00 ea 22 00 00 ea 26 00 00 ea 2a 00 00 ea
33 00 00 ea 32 00 00 ea 43 00 00 ea 52 00 00 ea
****
Byte Array: cnt = 32
06 00 00 ea 22 00 00 ea 26 00 00 ea 2a 00 00 ea
33 00 00 ea 32 00 00 ea 43 00 00 ea 52 00 00 ea
****
[ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : BSPI Read completed for 32 bytes,
Read data
Byte Array: cnt = 32
06 00 00 ea 22 00 00 ea 26 00 00 ea 2a 00 00 ea
33 00 00 ea 32 00 00 ea 43 00 00 ea 52 00 00 ea
Back door write
Read from
the same
address
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
90
****
[ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : BSPI Read comparision Passed for
address = 1e4004
[ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : Beat Len = 2, beat_size=
2
The log file for verification of the working of the MSPI module is as shown below for the
read operation.
The log for the single lane MSPI read is shown below
Logfile:
Write:-
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction status = 1
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 63
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 61
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 62
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 34
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 46
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 60
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 5c
Read:-
[ 388575.0ns] iproc_soc.iproc_tbc.driver.spif : read transaction status = 1
[ 488872.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 0000003b , read
buffer = 3b
[ 488971.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000063 , read
buffer = 63
[ 489070.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000061 , read
buffer = 61
Comparison
using the
checker passing
M.S Ramaiah School of Advanced Studies –Postgraduate Engineering and Management Programme (PEMP)
Development of OVM Verification Environment for Functional Verification of Quad SPI
91
[ 489169.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000062 , read
buffer = 62
[ 489268.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000034 , read
buffer = 34
[ 489367.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000046 , read
buffer = 46
[ 489466.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000060 , read
buffer = 60
[ 489565.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 0000005c , read
buffer = 5c
Compare:-
[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 3.exp = 63,
act = 63
[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 4.exp = 61,
act = 61
[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 5.exp = 62,
act = 62
[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 6.exp = 34,
act = 34
[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 7.exp = 46,
act = 46
[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 8.exp = 60,
act = 60
[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 9.exp = 5c,
act = 5c
[ 489565.0ns] iproc_soc : base_env_ext Calling test_end
[ 489565.0ns] aximac_sae_ckr0 : test_end(): Calling data_ckr test end
[ 489565.0ns] aximac_sae_ckr0 : test_end(): Done data_ckr test end
PASSED