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
M.Sc.[Engg.] Dissertation in VLSI System Design
Submitted by Registration No Academic Supervisors
: : :
Kiran N. CGB0910003 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)
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. Academic Supervisor Professor & HOD, Dept. of EEE,
MSRSAS-Bangalore
Mr. Linu Thomas Industrial Supervisor Manager , IC Design Engineering Broadcom Dr. Govind R. Kadambi
Dean-PEMP MSRSAS
Dr. Cyril Prasanna Raj P. Processor & HOD,

Dept. of EEE MSRSAS
Development of OVM Verification Environment for Functional Verification of Quad SPI
ii
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
iii
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.
iv
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.
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
vi
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
vii
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
viii
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
ix
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
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
xi
Abbreviation
AMBA APB AVM AXI BSPI DUT EDA IP MSPI OOP OVM OVM QSPI RAF SoC SPI TLM UVM VLSI Advanced Microprocessor Bus Architecture Advanced Peripheral Bus Advanced Verification Methodology Advanced eXtensible Interface Boot Serial Peripheral Interface Design Under test Electronic Design Automation Intellectual Property Master Serial Peripheral interface Object Oriented Programming Open Verification Methodology Open Verification Methodology Quad Serial Peripheral Interface Read Ahead FIFO System On Chip Serial Peripheral Interface Transaction Level Modeling Universal Reuse Methodology Very Large Scale Integrated Circuits
xii
Nomenclature
GHz bps Gbps Mbps Giga Hertz bits per second Giga bits per second Mega bits per second
xiii
M.S Ramaiah School of Advanced Studies Postgraduate Engineering and Management Programmes (PEMP)
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
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.
15
Serial communication is the preferred mode of communication on SoCs 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, IC 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 IC 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 IC 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 IC 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.
16
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)
17
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.
18
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
19
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
20
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.
21
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.
22
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.
23
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 I 2C, 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
24
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.
25
If a SPI device is not selected, its data output goes into a high-impedance state (hiZ), 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
26
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
27
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 (MasterIn-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.
28
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 0 1 2 3
CPOL 0 0 1 1
CPHA 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.
29
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 I 2C 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 Two bus lines are required; a serial data line (SI1), a data output line (SO1) and a line (SDA) and a serial clock line (SCL) serial clock line (SCK1)[plus 1 Chip Select (CS)] No official specification (component With official specification (I2C protocol created by Philips) dependent) 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 More efficient in multi-master, multi-slave master, single slave) applications applications Lack of built-in device addressing Built-in addressing scheme and
straightforward
30
Does not have an acknowledgement Have an acknowledgement mechanism to mechanism to confirm receipt of data. confirm receipt of data Less overhead when handling point-to- More overhead when handling point-topoint application 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.
SPI data Lines
SPI Control signals Figure 2. 4 Generic QSPI block diagram
31
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 m2 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
32
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 pertype 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
33
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
34
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. Build Connect End of elaboration Start of simulation Run Extract Check Report
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
35
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
36
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.
37
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.
38
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 doesnt 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.
39
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
40
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,
41
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.
42
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
43
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
44
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 doesnt tell as to what steps or how to go about performing hardware and software co verification by writing interdependent tests.
45
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 IPs 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
46
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).
47
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).
48
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.
49
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
50
Software Resources VCS (Verilog Compiler Simulator)
VERDI (Visualization Environment for Rich Data Interpretation) Literature Books, Journals
51
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
52
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.
SPI Control signals
AXI System bus
Interface to control register data transfer
SPI data Lines
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
53
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
54
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.
55
Table 5. 1 Instruction set for SPI flash memory (S25FL128R 2009)
56
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
57
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.
58
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)
59
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.
60
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.
61
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 classs 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.
62
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
63
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).
64
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
65
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
66
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
67
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
68
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. 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
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:
69
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
70
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.
Read address
Read address Control Signals Address
QSPI data lanes Read data
Control signals
APB interface
Figure 6. 6 Interface signals for QSPI Verification Environment
71
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.
72
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.
73
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
74
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.
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
Figure 7. 1 3byte addressing mode in single data lane mode
75
The start address for the 3 byte addressing mode is randomised in the range 0000h-1EFFh after the base address of the flash drive. The start address as can be seen in the Figure 7.1 starts in the range 0600h up to 1EFFh indicating that the BSPI is operating the 3 byte addressing mode as configured in the control registers The QSPI output is seen only on the MISO data line indicating that the BSPI is operating the single data lane mode The APB signals are unaltered indicating the only the AXI bus is used for read operation The read data operation is valid and successful as rvalid signal is set high after each operation 7.2.1.2 BSPI in 3 byte addressing and dual data lane mode Figure 7.2 shows the simulation result for the BSPI configured for a 3 byte addressing mode and in a dual data lane mode. The sequencer configures the address length to be 3 byte long and QSPI control signals for fast read are fed into the input of the QSPI and the output is available on both MOSI, MISO lane. The start address as can be seen in the Figure 7.2 starts in the range 0600h up to 1EFFh indicating that the BSPI is operating the 3 byte addressing mode as configured in the control registers The QSPI output is seen on both MISO, MOSI data line indicating that the BSPI is operating the dual data lane mode The APB signals are unaltered indicating the only the AXI bus is used for read operation The read data operation is valid and successful as rvalid signal is set high after each operation
76
Start address of 0600h
Output at data line
dual
Data read from flash
Figure 7. 2 3byte addressing mode in dual data lane mode
7.2.1.3 BSPI in 3 byte addressing and quad data lane mode Figure 7.3 shows the simulation result for the BSPI configured for a 3 byte addressing mode and in quad data lane mode. The sequencer configures the address length to be 3 byte long and QSPI control signals for fast read are fed into the input of the QSPI and the output is available on MOSI, MISO, WP_n and HOLD_n lane. The start address as can be seen in the Figure 7.3 starts in the range 0600h up to 1EFFh indicating that the BSPI is operating the 3 byte addressing mode as configured in the control registers The QSPI output is seen on both MISO, MOSI, WP_n and HOLD_n data lines indicating that the qSPI is operating the quad data lane mode The APB signals are unaltered indicating the only the AXI bus is used for read operation
77
The read data operation is valid and successful as rvalid signal is set high after each operation
Start address of 0600h Output at all four data line
Figure 7. 3 4byte addressing mode in quad data lane mode
7.2.1.4 BSPI in 4 byte addressing and single data lane mode The start address for the 4 byte addressing mode is randomised in the range 1F00h-FFFFh after the base address on the flash drive. Figure 7.4 shows the simulation result for the BSPI configured for a 4 byte addressing mode and in single data lane mode. The sequencer configures the address length to be 4 byte long and QSPI control signals for fast read are fed into the input of the QSPI and the output is available on MOSI lane. The start address as can be seen in the Figure 7.4 starts in the range 1F00h up to FFFFh indicating that the QSPI is operating the 4 byte addressing mode as configured in the control registers The QSPI output is seen on both MISO, data line indicating that the QSPI is operating the single data lane mode
78
The read data operation is valid and successful as rvalid signal is set high after each operation
Start address of 1F00h
Output at single data line
Data read from flash 1 to indicate 32 bits address
Figure 7. 4 4byte addressing mode in single data lane mode
7.2.1.5 BSPI in 4 byte addressing and dual data lane mode Figure 7.5 shows the simulation result for the BSPI configured for a 4 byte addressing mode and in a dual data lane mode. The sequencer configures the address length to be 4 byte long and QSPI control signals for fast read are fed into the input of the QSPI and the output is available on both MOSI, MISO lane. The start address as can be seen in the Figure 7.5 starts in the range 1F00h up to FFFFh indicating that the QSPI is operating the 4 byte addressing mode as configured in the control registers
79
The QSPI output is seen on both MISO, MOSI data line indicating that the BSPI is operating the dual data lane mode The APB signals are unaltered indicating the only the AXI bus is used for read operation The read data operation is valid and successful as rvalid signal is set high after each operation
Start address of 1F00h
Output at dual data lines
Data read from flash 1 to indicate 32 bits address
Figure 7. 5 4byte addressing mode in dual data lane mode
7.2.1.6 BSPI in 4 byte addressing and Quad data lane mode Figure 7.6 shows the simulation result for the BSPI configured for a 4 byte addressing mode and in quad data lane mode. The sequencer configures the address length to be 4 byte long and QSPI control signals for fast read are fed into the input of the QSPI and the output is available on MOSI, MISO, WP_n and HOLD_n lane. The start address as can be seen in the Figure 7.6 starts in the range 1F00h up to FFFFh indicating that the BSPI is operating the 4 byte addressing mode as configured in the control registers
80
The QSPI output is seen on both MISO, MOSI, WP_n and HOLD_n data lines indicating that the QSPI is operating the quad data lane mode The APB signals are unaltered indicating the only the AXI bus is used for read operation The read data operation is valid and successful as rvalid signal is set high after each operation
Start address of 1F00h Output at all four data line
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.
81
AXI bus idle
Comm and (1C h)for fast read Corresponding output
Figure 7. 7 MSPI single data lane mode
Read address
APB protocol
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
82
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.
Purely APB interface Read operation
Register write operation
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.
83
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
84
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.
85
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
86
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 semiconductors, application note, MPC56xxS, freescale
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.
87
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
88
*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_RxDetectReset => Ltssm_RxDetectActive *Denali* <top.usb30d_pipe>@6380 ns Ltssm_RxDetectActive => Ltssm_PollingLFPS :: LTSSM FSM state:
LTSSM
FSM
state:
*Denali* <top.usb30d_pipe>@9740 ns :: Pipe FSM state: Pipe_SeqIdle => Pipe_SeqRcvrDet [ 18549.0ns] iproc_soc.iproc_tbc.driver.spif : BSPI Read data from Address ( 1e400400) is [ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : Write data Byte Array: cnt = 32 06 00 00 ea 22 00 00 ea 26 00 00 ea 2a 00 00 ea 33 00 00 ea 32 00 00 ea 43 00 00 ea 52 00 00 ea **** Byte Array: cnt = 32 06 00 00 ea 22 00 00 ea 26 00 00 ea 2a 00 00 ea 33 00 00 ea 32 00 00 ea 43 00 00 ea 52 00 00 ea **** [ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : BSPI Read completed for 32 bytes, Read data Byte Array: cnt = 32 06 00 00 ea 22 00 00 ea 26 00 00 ea 2a 00 00 ea 33 00 00 ea 32 00 00 ea 43 00 00 ea 52 00 00 ea Read from the same address Back door write
89
**** [ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : BSPI Read comparision Passed for address = 1e4004 [ 2 18549.0ns] iproc_soc.iproc_tbc.scn.spif : Beat Len = 2, beat_size= Comparison using the checker passing The log file for verification of the working of the MSPI module is as shown below for the read operation. The log for the single lane MSPI read is shown below
Logfile:
Write:-
[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction status = 1 [ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 63 [ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 61 [ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 62 [ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 34 [ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 46 [ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 60 [ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 5c Read:[ 388575.0ns] iproc_soc.iproc_tbc.driver.spif : read transaction status = 1 [ 488872.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 0000003b , read buffer = 3b [ 488971.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000063 , read buffer = 63 [ 489070.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000061 , read buffer = 61
90
[ 489169.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000062 , read buffer = 62 [ 489268.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000034 , read buffer = 34 [ 489367.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000046 , read buffer = 46 [ 489466.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 00000060 , read buffer = 60 [ 489565.0ns] iproc_soc.iproc_tbc.driver.spif : data read form rx reg = 0000005c , read buffer = 5c Compare:[ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 3.exp = 63, act = 63 [ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 4.exp = 61, act = 61 [ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 5.exp = 62, act = 62 [ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 6.exp = 34, act = 34 [ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 7.exp = 46, act = 46 [ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 8.exp = 60, act = 60 [ 489565.0ns] iproc_soc.iproc_tbc.scn.spif : data compare Passed for entry 9.exp = 5c, act = 5c [ 489565.0ns] iproc_soc : base_env_ext Calling test_end [ 489565.0ns] aximac_sae_ckr0 : test_end(): Calling data_ckr test end [ 489565.0ns] aximac_sae_ckr0 : test_end(): Done data_ckr test end PASSED
91

Thesis Main

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis Main

Uploaded by

Copyright:

Available Formats

M.

Submitted by Registration No Academic Supervisors

Kiran N. CGB0910003 Dr. Cyril Prasanna Raj P.

Mr. Linu Thomas

M. S. Ramaiah School of Advanced Studies

M.S.RAMAIAH SCHOOL OF ADVANCED STUDIES

Dr. Cyril Prasanna Raj P. Processor & HOD,

Development of OVM Verification Environment for Functional Verification of Quad SPI

Name of the Student

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

1.2 Top level block diagram

Figure 1. 1 Top level block diagram (BCM21551 product brief 2007)

Development of OVM Verification Environment for Functional Verification of Quad SPI

1.3 Scope of the QSPI and OVM environment

1.4 Motivation for development of OVM environment

1.5 Challenges in development of OVM verification environment

Development of OVM Verification Environment for Functional Verification of Quad SPI

1.6 Applications of QSPI and OVM verification environment

1.7 Block diagram for the OVM based verification environment

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 1. 2 Block diagram for OVM based verification environment

1.8 Thesis organization

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

2 Background Theory on Quad SPI and OVM

2.1 Terms and definitions

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

2.2 Introduction to SPI standard

2.2 The principle of SPI operation

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 2. 1 A simple SPI module

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 2. 2 Cascading several SPI devices

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 2. 3 Master with independent slaves

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

SPI Control signals Figure 2. 4 Generic QSPI block diagram

Development of OVM Verification Environment for Functional Verification of Quad SPI

2.3 Open Verification Methodology

Development of OVM Verification Environment for Functional Verification of Quad SPI

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 2. 5 OVM verification environment

2.4 OVM phases:

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 2. 6 OVM phases (Glasser 2009)

2.5 Testbench Layered Organisation

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 2. 7 Layered testbench architecture of OVM (Glasser 2009)

Development of OVM Verification Environment for Functional Verification of Quad SPI

Figure 2. 8 Concentric testbench organisation (Glasser 2009)