Thesis Main

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



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



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.



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.



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



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



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



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



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



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



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



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



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.



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.

http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

http://en.wikipedia.org/wiki/I%C2%B2C

http://en.wikipedia.org/wiki/Full_duplex


http://en.wikipedia.org/wiki/System_Management_Bus

http://en.wikipedia.org/wiki/Address_space


http://en.wikipedia.org/wiki/GPIB

http://en.wikipedia.org/wiki/SCSI

http://en.wikipedia.org/wiki/Galvanic_isolation



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)



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.



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

http://en.wikipedia.org/wiki/Analog-to-digital_converter

http://en.wikipedia.org/wiki/Digital-to-analog_converter

http://en.wikipedia.org/wiki/IEEE_802.15.4

http://en.wikipedia.org/wiki/IEEE_802.11

http://en.wikipedia.org/wiki/Flash_memory#Serial_flash

http://en.wikipedia.org/wiki/EEPROM#Serial_bus_devices

http://en.wikipedia.org/wiki/MultiMediaCard

http://en.wikipedia.org/wiki/Secure_Digital



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



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.



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.

http://www.answers.com/topic/synchronization-computer-science

http://www.answers.com/topic/serial-interface

http://www.answers.com/topic/half-duplex

http://www.answers.com/topic/master-slave-technology-1

http://www.answers.com/topic/data-frame-1

http://www.answers.com/topic/chip-select





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.



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



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.



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



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



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.



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.



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



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



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



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



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



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



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



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.



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.



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.



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



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,



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.



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



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



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.



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



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).



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).



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.



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



51

• Software Resources

VCS (Verilog Compiler Simulator)

VERDI (Visualization Environment for Rich Data Interpretation)

• Literature

Books, Journals



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



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



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



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.



56

Table 5. 1 Instruction set for SPI flash memory (S25FL128R 2009)



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



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.



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)



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.



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.



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.



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



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).



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



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



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



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



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



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



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



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.



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.



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



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



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


mode and in a dual data lane mode. The sequencer configures the address length to be 3


output is available on both MOSI, MISO lane.




The QSPI output is seen on both MISO, MOSI data line indicating that the BSPI

is operating the dual data lane mode


operation


each operation



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


mode and in quad data lane mode. The sequencer configures the address length to be 3


output is available on MOSI, MISO, WP_n and HOLD_n lane.




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


operation

Start address of

0600h

Output at dual data line

APB signals no

activity

Data read from

flash



78


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


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



79


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


mode and in a dual data lane mode. The sequencer configures the address length to be 4


output is available on both MOSI, MISO lane.


FFFFh indicating that the QSPI is operating the 4 byte addressing mode as


Start address of

1F00h

Output at single data line

Data read

from

flash

1 to indicate 32

bits address



80

The QSPI output is seen on both MISO, MOSI data line indicating that the BSPI

is operating the dual data lane mode


operation


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


mode and in quad data lane mode. The sequencer configures the address length to be 4


output is available on MOSI, MISO, WP_n and HOLD_n lane.


FFFFh indicating that the BSPI is operating the 4 byte addressing mode as


Start address of

1F00h

1 to indicate 32 bits

address

Output at dual data lines

Data

read from

flash



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


operation


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



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



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



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



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.



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



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.



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



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

****


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


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



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 = 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


buffer = 61

Comparison

using the

checker passing



91


buffer = 62


buffer = 34


buffer = 46


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


act = 61


act = 62


act = 34


act = 46


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

Thesis Main

Documents

cyril prasanna

referring

critical machine

quiet slow

advanced studiespostgraduate

entire verification

full verification

ovm verification