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