OVM Based Verification of Advanced Microcontroller Bus...

Vol 04, Article 11174; November 2013 International Journal of VLSI and Embedded Systems-IJVES

http://ijves.com ISSN: 2249 – 6556

2013 – IJVES Indexing in Process - EMBASE, EmCARE, Electronics & Communication Abstracts, SCIRUS, SPARC, GOOGLE Database, EBSCO, NewJour, Worldcat,

DOAJ, and other major databases etc.,

657

OVM Based Verification of Advanced Microcontroller Bus

Architecture – AHB Master K JAYA SWAROOP1, V SURENDRA BABU2

1,2 ECE Department, SIR C.R.REDDY College of Engineering, ANDHRA UNIVERSITY,ELURU,INDIA [email protected], [email protected]

ABSTRACT

A verification environment to verify an ARM-based SoC (System-on-Chip) by using open verification

methodology (OVM) is presented in this paper. The paper also introduced how to verify the AMBA (Advanced

Microprocessors Bus Architecture) by open verification methodology, include AHB (Advanced High

Performance Bus) Master. Verification technology is designed to enable creation of robust, Achieve re usability

in plug and play manner, interoperable verification IP and test-bench components to verify any AMBA protocol

based SoC it improves quality and reduces schedule time it is the standard framework to build the verification

environment waveforms, code coverage is also discussed in the paper.

Keywords: SoC (system on chip), AHB (Advance high performance bus), AMBA (Advanced Microcontroller Bus

Architecture), OVM (Open Verification Methodology).

[1] INTRODUCTION

The tremendous advancements in VLSI technologies in the past few years have fuelled the need for inti-crate

trade-offs among speed, power dissipation and area, The ICs can be made very compact, having up to several

billion transistors in an area the size of a fingernail. OVM is a documented methodology with a supporting

building-block for the verification of semiconductor chip designs. Functional verification is widely

acknowledged as the bottleneck in the chip design flow to date, up to 80% of all designs development time and

resources are spent on functional verification. In current industrial practice, simulation-based verification is the

main functional verification for large and complex designs. With dynamic verification, the verification is done

by generating a massive number of tests using random test generators, simulating the tests on the design, and

checking that the design behaves according to its specification. Coverage is often used to monitor the progress

of the verification process and point to areas in design that not have been properly tested. However, the test

program need to provide more automation to maximize the functional coverage from each test case and reduce

the time needed to create a test case. Using OVM has test case multiple tests are compiled together and a test

case can be chosen at the run time using command line the constraint random test cases in the OVM are much

shorter than the directed test cases with OVM test class we don't need to recompile the environment again to run

a new test case which saves huge time for big verification environments. It provides the high-level data

structures available in object-oriented languages, such as system Verilog. These data structures enable a higher

level of abstraction and modelling of complex data types so Methodology can be used to simulate the design and

verify them by test case. In this paper, how to put up the simulation environment using Open Verification

Methodology is introduced. The simulation environment using by OVM is efficient and high-performance. The

paper discusses the usage experience to verify a SoC by the IP and the AHB master during verify the SoC, a

great deal of visual simulation waveform inspection is required. To generate the waveform will be time-

consuming. The paper presents SoC bus transaction verification IP written by Open Verification Methodology,

which are called reference model to compare the behaviour of the DUT. The IP can be integrated into OVM

simulation environment. We can greatly reduce the waveform inspection time.

2. OPEN VERIFICATION METHODOLOGY ENVIRONMENTS The main purpose of the verification environment is to generate stimulus, apply stimulus to the DUT (design

under test), and check results to verify that the function is correct. Then test cases may be modified or added

referring to the coverage reports. By using Open Verification Methodology we can easily do these works.

2.1 Introduction of the Verification Environment

Fig.1 shows the contractual of the OVM verification environment. The environments include the AHB DUT

written by Verilog test bench's which include methodology interface, simulation AHB-top module, and AHB

test bench. In the Methodology test bench, the generator can be used to create constrained random test vectors.

These test vectors are sent to the driver and then the driver can stimulate the AHB DUT. The monitor is

responsible for extracting signal information from the bus and translating it into events, structures and status

information. This information is made available to other components using TLM interface. The monitor collects

bus information through a virtual interface. The collected data is used in coverage collection and checking for

scoreboard Fig.2 shows OVM agent The AHB test bench can configure the agent as either active or passive. In

active mode the agent builds the AHB sequencer, AHB driver and AHB monitor. In this configuration, stimulus

http://ijves.com/

mailto:[email protected]

mailto:[email protected]





658

is driven onto the bus via the sequencer/driver and the monitor capture the bus. In passive mode the agent

includes only an AHB monitor the AHB sequencer and AHB driver are not included inside the agent. A passive

agent only captures bus activity and it does not drive stimulus into the DUT the interface part (Interface) is the

interface to be used to joining the DUT and the test program. All the parts are instanced in the AHB-top. The

verification environment will also be reused, without modifications, by as many test cases as possible to

minimize the amount of codes required to verify the AHB DUT.

Fig. 1. Open Verification Methodology Verification Environment

Fig. 2 Open verification Methodology Agent

2.2 AMBA AHB Master Design

Fig. 3. AHB Master block diagram

http://ijves.com/





659

The AHB master specifies a certain behaviour that is pipeline rule the master must perform pipelined accesses

first comes an address phase during which the address and control signals are driven. As shown in the fig. 3

AHB master Block design. The extensibility of length of the bus cycle. The slave cancan drive HREADY low to

stretch the length of a bus cycle the AHB protocol also has provisions for several masters only one master can

access the slaves at the given time. All of the other masters must respect this and wait until the bus is assigned to

them. The master must observe the status of HRESP. If RETRY or SPLIT is given, the master must immediately

drive the IDLE value on its HTRANS output. HLOCK must be asserted on the bus cycle that precedes the first

address phase of the locked sequence and to be deserted during the last address phase.

Fig. 4 Executing flow in the OVM verification

3. OPEN VERIFICATION METHODOLOGY HIERARCHY

As shown in the fig. 4 executing flow in the open verification methodology hierarchy consist of components

Ovm_object: is the virtual base class for all components and transactions in an Ovm environment

Ovm_sequencer: A sequencer is an advanced stimulus generator that controls the items that are provided to the

driver for execution. By default, a sequencer behaves similarly to a simple stimulus generator and returns a

random data item upon request from the driver. It allows adding constraints to the data item class in order to

control the distribution of randomized values.

Ovm_driver: The DUT inputs are driven by the driver that runs single commands such as bus read or write. A

typical driver repeatedly receives a data item and drives it to the DUT by sampling and driving the DUT signals.

Ovm_monitor: The DUT output drives the monitor that takes signal transitions and groups them together into

commands. A monitor is a passive entity that samples DUT signals but does not drive them. Monitors collect

coverage information and perform checking.

Ovm_agent: Agent encapsulates a driver, sequencer, and monitor. Agents can emulate and verify DUT devices.

OVCs can contain more than one agent. Some agents (for example, master or transmit agents) initiate

transactions to the DUT, while other agents (slave or receive agents) react to transaction requests.

Ovm_scoreboard: It is a very crucial element of a self-checking environment. Typically, a scoreboard verifies

whether there has been proper operation of your design at a functional level.

Ovm_env: The environment is the top-level component of the Open Verification Component. The environment

class is architected to provide a flexible, reusable and extendable verification component. The main function of

the environment class is to model behaviour by generating constrained random traffic monitoring DUT

responses, checking the validity of the AHB protocol activity, and collecting coverage.

Transaction: Data items represent the input to the AHB DUT. The sequencer which creates the random

transactions are then retrieved by the driver and hence used to stimulate the pins of the AHB DUT. Since we use

a sequencer, the transaction class has to be derived from the ovm_sequence_item class, which is a subclass of

ovm_transaction. By intelligently randomizing data item fields using SystemVerilog constraints, one can create

a large number of meaningful tests and maximize coverage.

http://ijves.com/





660

Interface: Interface is nothing but bundle of wires which is used for communication between DUT (design under

test) and verification environment.

4. AHB MASTER BEHAVIOUR ANALYSIS

Coverage is a generic term for measuring progress to complete design verification. The coverage tools gather

information during a simulation and then post process is to produce a coverage report. By enabling the code

coverage there is overhead on the simulation takes more time. So it is recommended not to enable the code

coverage always Functional coverage is a measure of which AHB master design features have been exercised by

the tests functional coverage is tied to the DUT intent and is sometimes called specification coverage we can run

the same random test bench over and over, simply by changing the random seed, to generate the new stimulus. It

individual simulation generates a data base of functional coverage information. By merging all this information

together, overall progress can be measured by using functional coverage this information is only valid for a

successful simulation as shown in fig 5 showing the simulation result of coverage with cover groups. We

achieved the 100 percent of functional coverage for AHB master.

Fig. 5 shows functional coverage

5. AHB MASTER WAVEFORM ANALYSIS

The size is given as “000” which represents the burst size 4 and hence four continuous write or read operation

happens. Here the count is introduced in order to generate the address with respect the given initial address and

the count is increment .the operation remains the same as simple read and write but the only change is that after

each operation, count will check for the burst size given. The burst count is not equal of the burst size given, the

count will get incremented and the next address is get generated based on which the read or write operation that

currently performed is carried out. When the count is equal to burst length, that represents the burst operation

over and count resets to zero. Hence master and slave go IDLE state.

Table. 1 Transfer type of AHB master

HWRITE signal will be maintained as HIGH or LOW throughput the HBURST write or HBURST read

operation and is made don’t care operation after the burst operation over. Similarly, the HREADY signal is also

made HIGH for each operation in the HBURST which is clearly shown in the waveform fig.6 and also the

HTRANSFER operation starts at non-sequential and it is followed by sequential the address is related to the

previous transfer (see table 1) that are four different types IDLE indicates that no data transfer is required BUSY

indicates the bus master is continuous with a burst of transfer but the next transfer cannot take place

immediately. SEQ indicates the remaining transfer in a burst are sequential that is clearly shown in the figure.7

the screen shots of the simulated waveform results shown that the communication among different IP cores

using AHB master is proper.

http://ijves.com/





661

Fig. 6 Waveform for AHB master–burst operation of size 4

Fig. 7 Waveform for AHB master–transfer operation

6. CONCLUSIONS

In this paper we use open verification methodology (OVM) to put a verification environment this methodology

reduces the simulation time required to find bugs, when compared to a conventional methodology. The checker

keeps track of all the activity during simulation and checks the response right way we analyse the functional

coverage with cover groups, cover points and bins we achieve the 100% functional coverage for AHB master. ACKNOWLEDGEMENTS

We thank surendra babu for explaining the changes made in the specifications we are grateful to yashdeep for

many insightful comments about our specifications that helped us improve our paper.

REFERENCES

[1] ARM Ltd. AMBA Specification Rev.2.0 May 1999.http://www.arm.com

[2] OVM User Guide, Version 2.1.1, March 2010 http://www.ovmworld.org

[3] Open Verification Methodology: Fulfilling the Promise of System Verilog' by Thomas L. Anderson,

Product Marketing Director Cadence Design Systems, Inc.

[4] ‘System Verilog for Verification: A Guide to Learning the Test bench Language Features’ by Chris Spear

s.l.: Springer, 2006

[5] Chris spear, system Verilog for verification, New York: springer, 2006.

http://ijves.com/

http://www.ovmworld.org/

OVM Based Verification of Advanced Microcontroller Bus...

Documents

Transcript of OVM Based Verification of Advanced Microcontroller Bus...