OVM verification

M.S.Ramaiah School of Advanced Studies 1

Final Project Presentation

Development of OVM Verification Environment for Functional Verification of Quad Serial

Peripheral Interface

Kiran N.CGB0910003

M. Sc. [Engg.] in VLSI System Design

Academic Guide :

Cyril Prasanna Raj . P

HoD, Dept. of EEE,

MSRSAS, Bangalore.

Industrial Guide :

Linu Thomas,

Manager, IC Design Engineering,

Broadcom (I) Pvt. Ltd.


Aim of the Project

To design and develop an OVM based verification environment for the Quad SPI IP and attain maximum possible coverage for the same


Top Level Block Diagram

QSPI


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


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.

• 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 has been arrived at.

• The specifications and design of the individual components OVM has been carried out.


Methods and Methodology• 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 is carried out using the VCS tools and observations have been documented

• The waveforms have been debugged using the VERDI tool and any bugs have been reported and rectified.

• The quad SPI IP has been integrated into the verification environment and tests have been run.

• The tests have been 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 have been adopted.

• Coverage driven verification methodologies have been implemented in order to attain more coverage.

• Maximum coverage for QSPI IP using the VCS tool and the waveform debug tool VERDI is reported.

Methods and Methodology


Introduction• Quad SPI module is an advanced version of the commonly

used Serial Peripheral Interface (SPI) module.

• The SPI is used for synchronous serial data communication between a host processor and the peripherals connected to it. It is master-slave protocol type of interface. It was primarily developed by Motorola

• In its most general form the SPI consists of two data lines and two control lines.


Introduction cont..• The two control lines are Chip Select(CS) which is used to

select the corresponding peripheral device connected and then Clock Select (SCLK) which is used for synchronizing the data transfer.

• The two data lines are for the data input and output. The SPI in general consists of a shift register which is used to shift data into and out of the interface and a serial buffer which stores the data when the module is made inactive.

• 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


Introduction cont..• The QSPI module finds its application in System On Chip

(SoC) designs to assists the hard core processor to communicate with the peripherals attached to it.

• Since the interconnect is small the noise immunity is best in case of serial communication which the QSPI uses and also the frequency of operation is around 80 MHz is which is ideal and well suited for on chip operations.

• Verification methodologies are a must to tackle verification complexities and design closure times. Out of the popular verification methodologies (Open Verification Methodology) OVM preferred in the industry for SoC designs.


• OVM is Functional verification methodology developed using the System verilog (Hardware Design Verification language)HDVL

• The three main building blocks of OVM include OVM_ components, OVM_env and OVM_test.

• Component classes include

1. Sequencer

2. Driver

3. Monitor

4. Scoreboard

• Env class helps connect

all the components together.

Introduction cont..

QSPI

M.S.Ramaiah School of Advanced Studies

Scope of the project

• The OVM verification environment is a reusable entity which can be used further for many serial communication IP with few required adjustment made into the design and has a long life span.

• Since the serial communication protocols are preferred means of data communication in SOC designs and also QSPI works at highest frequency comparatively and hence it has tremendous implementation scope. QSPI being a relatively new technology also has a long life span till there is new advancement in serial interface technology.

12


Motivation for the project

• 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 to avoid costly respins. Without it saving time and improving the verification effort by covering all the difficult corners of design and attaining maximum possible coverage will be difficult

• 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

13


Project Plan

Design of verification environment

Arrival of specification for the verification environment

Testing of DUT

Literature Review

Obtaining Required Coverage

Writing test cases

Linking of DUT to verification environment

Test bench creation and testing

the modules using developed test-bench

NO


Literature Review• The QSPI architecture for the AXI 4 interface is used for

only to interface the serial flash memories connected as peripherals. The architecture for this application can only be used for high data rate reads as it concentrates only on the AXI bus 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

• 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, 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

16

Literature Review cont..


Literature Review – Comparison

Sl no.

Title Author Year Specification

Merits and demerits

1. A methodology for timely verification of Complex SoC

Guy Regev, Peretz Landau

2009 System/SW based verification methodology, bottom up methodolgy

+High coverage achieved,-covering BMP functionality

2. A Methodology for the Verification of a System on Chip

D. Geist, G. Brain,T. Arons,M. Slavkin,Y. Nustov,M. Farkas,K. Holtz

2008 System based verification, test polarisation to pin point system bugs

+efficient verification of the entire system on chip design


Summary of Literature Summary

• The present SPI module used as interface between host processor and external peripherals currently operates at a frequency of 10-20 MHz with a single data_in line. (Spansion S25FL128R,2010)

• Quad SPI module has 4 data lines which can be used for high speed data transfer. It operates at a higher frequency of 80-100 MHz.(Spansion S25FL128R,2010)

• The present verification environment is suitable for verification of low speed interface and so a new verification environment has to developed for the verification of the QSPI module in a short duration.(Parag,2011)

• For speedy verification of sub blocks of SOC designs OVM is sought after methodology in the industry (Pretez,2009)


Design of the QSPI

19

Interface to control register data transfer

Interface to control register data transfer

AXI System bus

AXI System bus

SPI data LinesSPI data Lines


Design of the QSPI cont

QSPI primarily consists of 3 blocks• Boot Serial Peripheral Interface (BSPI)• Master Serial Peripheral Interface (MSPI)• Read Ahead FIFO (RAF).

1.Boot SPI • 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.

20


Design of the QSPI cont

21

2.Master SPI

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.

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.


Signal description of the QSPI

22

Signal I/O Description

SO/IO1 I/O Serial Data Output: Transfers data serially out of the device on the falling edge of SCK. Functions as an input pin in Dual and Quad I/O, and Quad Page Program modes.

SI/IO0 I/O Serial Data Input: Transfers data serially into the device. Device latches commands, addresses, and program data on SI on the rising edge of SCK. Functions as an output pin in Dual and Quad I/O mode.

SCK Input Serial Clock: Provides serial interface timing. Latches commands, addresses, and data on SI on rising edge of SCK.

CS Input Chip Select: Places device in active power mode when driven low. Deselects device and places SO at high impedance when high. After power-up, device requires a falling edge on CS# before any command is written.


Signal description of the QSPI cont ..

23

Signal I/O Description

HOLD#/IO3 I/O Hold: Pauses any serial communication with the device without deselecting it. When driven low, SO is at high impedance, and all input at SI and SCK are ignored. Requires that CS# also be driven low. Functions as an output pin in Quad I/O mode.

W#/ACC/IO2 I/O Write Protect: Protects the memory area specified by Status Register bits BP2:BP0. When driven low, prevents any program or erase command from altering the data in the protected memory area. Functions as an output pin in Quad I/O mode.


Verification Env for QSPI

24


Components of OVM env• Sequencer: A sequence is series of transaction and sequencer

is used to for controlling the flow of transaction generation. A sequence of transaction 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.

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

• 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 helps in debugging any faults in the design.

25


Read operationStandard modeThe host system must first select the device by driving CS# low. The READ command is then written to SI, followed by a 3 byte address (A23-A0). Each bit is latched on the rising edge of SCK. The memory array data, at that address, are output serially on SO at a frequency 20 MHz, on the falling edge of SCK.


Read operationDual modeThe host system must first select the device by driving CS# low. The Dual Output Read command is then written to SI, followed by a 3-byte address (A23-A0) and a dummy byte. Each bit is latched on the rising edge of SCK. Then the memory contents, at the address that is given, are shifted out two bits at a time through the IO0 (SI) and IO1 (SO) pins at a frequency 60 MHz on the falling edge of SCK.


Read operationQuad modeThe host system must first select the device by driving CS# low. The Quad Output Read command is then written to SI, followed by a 3-byte address (A23-A0) and a dummy byte. Each bit is latched on the rising edge of SCK. Then the memory contents, at the address that are given, are shifted out four bits at a time through IO0 (SI), IO1 (SO), IO2 (W#/ACC), and IO3 (HOLD#) pins at a frequency 80 MHz on the falling edge of SCK.


Results and DiscussionsScenario 1: Standard modeDriving input : CS select signal is made low Instruction (03 h) and 24 bit address (400400 h) is sent on SI sent into the SPI flash. Total 32 clock cycles Hold and W/ACC are made high for single mode operation.Obtained output: At the 32nd falling edge cycle of the SCK the data (24 h)from flash memory address location (400400 h) is read into the BSPI till CS signal is made high again wrapping burst format is used. The data read is then available on the AXI and is cross verified for validity.

03 h, 400400 h

24 h 400400 h

24 h


Results and Discussions cont..Scenario 2: Dual mode

Driving input : CS select signal is made low Instruction (3B h) and 24 bit address (E03766 h) is sent on SI sent into the SPI flash. A dummy bit of 8 bits and so a total 40 clock cycles.

Obtained output: At the 40th falling edge cycle of the SCK the data (47h) from flash memory address location (E03766 h) is read into the BSPI on both SI and SO lines in only 4 clock cycles till CS signal is made high again wrapping burst format is used. The data read is then available on the APB and is cross verified by checker for validity.

3B h,E03766 h, XX h47 h


Results and Discussions cont..

31

Scenario 3: Quad mode Driving input : CS select signal is made low Instruction (EB h) and 32 bit address (1E28588 h) is sent on SI sent into the SPI flash. A dummy bit of 8 bits and so a total 48 clock cycles.Obtained output: At the 48th falling edge cycle of the SCK the data (FF h) from flash memory address location (E03766 h) is read into the BSPI on both SI , SO, Hold and W/ACC lines in only 2 clock cycles till CS signal is made high again wrapping burst format is used. The data read is then available on the APB and is cross verified by checker for validity.

FF h

EB h,1E8588 h, XX h


[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 63[ 43197.0ns] iproc_soc.iproc_tbc.driver.spif : write transaction data = 61[ 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[ 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


Log file:

Single data lane mode through SO

Command of 03h through SI


[ 18549.0ns] iproc_soc.iproc_tbc.driver.spif : BSPI write data from Address ( 1e400400) is[ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : Write dataByte 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 ea33 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 comparision Passed for address = 1e400400[ 18549.0ns] iproc_soc.iproc_tbc.scn.spif : Beat Len = 2, beat_size= 2


Log file:

Dual data lane mode through SO and SI



Quad data lane mode through SO ,SI, w/acc, hold


Coverage Analysis Coverage value represents the verification effort carried on the

designs.

• Line Coverage: It is the measure to check for the total number of lines of code which is being executed.

• Conditional Coverage: It is the measure to check if all the conditional statements present in the code are traversed.

• FSM Coverage: It is a measure to find out the state transitions & unvisited states in an FSM

• Toggle Coverage: It is a measures the transitions of the stimulus [changes in the signal logic] w.r.t the execution of the code.

35


Regression Result

36

The regression is combination the all the sub blocks in the design done 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.


Coverage Report for QSPI

37

020406080

100

Coverage

Line

Conditional

Toggle

The final coverages obtained •Line :89.88•Conditional: 83.63•Toggle: 58.93


Applications of the Project

• The QSPI finds its application in almost any and every SoC designs and in swift data transmission applications like digital streaming, digital signal processing.

• The QSPI can communicate with wide range of peripherals like flash memories ,sensors, ADC, DAC,LCD displays etc

• The verification environment can be used for other serial and other on chip communication protocol and interfaces.

• The verification environment is tool independent as System Verilog programming language is used for coding and hence the same design can used for other tools from other EDA tool vendors.

38


Challenges faced during the project

• The QSPI is a relatively new and advanced interface so there are not many supporting documents other than few data sheets to understand the behavior of module once implemented hence few key insights into the cases or modes of operation are missing for developing a stronger verification effort

• 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

• Attaining high values of coverages as the some of the functionality depends on other blocks inside in SoC

39


Conclusion

• The Quad SPI module is verified for 3 data transfer modes of operation along with 3 and 4 byte addressing modes and is reported to operate at 80MHz for Quad read mode operation

• 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

40


Recommendations for Future work

• The verification environment developed can enhance by introducing better coding techniques and more blocks which help debug the design in a easier way.

• The present verification environment can be enhanced for verification of other communication protocols with suitable modifications the test cases block of the design

41


Literature• D. Geist, G. Biran, T. Arons, M. Slavkin, Y. Nustov, M. Farkas, K. Holtz (2008), A Methodology

For the Verification of a ‘System on Chip, DAC, Louisiana.

• Daniel McKenna, Using the QuadSPI Module on MPC56xxS, freescale semiconductors, application note, Document Number: AN4186

• Guy Mosensoson (2010), Practical Approaches to SOC Verification, Verisity Design Inc.

• Janick Bergeron (2006), Verification methodology manual for SystemVerilog, Springer Pvt. Ltd., London.

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


Literature• Pretez landau, Guy Regev (2009), A Methodology for Timely Verification of a Complex

SoC, Percello Ltd., USA.

• S25FL128R, S25FL256R, S25FL512R Marketing Requirements Specification, Spansion Datasheet.

• Santanu Chattopadhyay (2010), Embedded System Design, PHI learning pvt. Ltd., USA


Thank You

OVM verification

Documents

Transcript of OVM verification