UVM ARCHITECTURE FOR VERIFICATION

http://www.iaeme.com/IJECET/index.asp 29 editor@iaeme.com
International Journal of Electronics and Communication Engineering & Technology
(IJECET)
Volume 7, Issue 3, May–June 2016, pp. 29–37, Article ID: IJECET_07_03_004
Available online at
http://www.iaeme.com/IJECET/issues.asp?JType=IJECET&VType=7&IType=3
Journal Impact Factor (2016): 8.2691 (Calculated by GISI) www.jifactor.com
ISSN Print: 0976-6464 and ISSN Online: 0976-6472
© IAEME Publication
UVM ARCHITECTURE FOR
VERIFICATION
Pankaj S.Vitankar
Department of Electronics & Telecommunication Engineering
Vishwabharati Academy’s College of Engineering, Ahmednagar, India
Dr. A. K. Kureshi
Savitribai Phule University of Pune, Pune, India
ABSTRACT
The System Verilog UVM promises to improve verification productivity
while enabling teams to share tests and test benches between projects and
divisions. This promise can be achieved; the UVM is a powerful methodology
for using constrained randomization to reach higher functional coverage
goals and to explore combinations of tests without having to write each one
individually. Unfortunately the UVM promise can be hard to reach without
training, practice and some significant expertise. Verification is one of the
most important activities in the flow of ASIC/VLSI design. Verification
consumes large amount of design flow cycle & efforts to ensure design is bug
free. Hence it becomes intense requirement for powerful and reusable
methodology for verification. The Universal Verification Methodology (UVM)
is a powerful verification methodology that may be used to verify a wide range
of design sizes and types. UVM is derived from other methodology like VMM,
OVM, eRM. It is useful to verify designs in any language like Verilog, VHDL,
System Verilog. Reusable verification environment is possible using UVM &
hence saving considerable time in Verification cycle. This paper talks about
the architecture of environment using UVM. It also focuses on terms & ways
used in Verification using UVM.
Key words: ASIC, VLSI, Simulation, Verification, eRM, OVM, VMM, UVM
Cite this Article: Pankaj S.Vitankar and Dr. A. K. Kureshi, UVM
Architecture for verification, International Journal of Electronics and
Communication Engineering & Technology, 7(3), 2016, pp. 29–37.
http://www.iaeme.com/IJECET/issues.asp?JType=IJECET&VType=7&IType=3

Pankaj S.Vitankar and Dr. A. K. Kureshi
1. INTRODUCTION
The Universal Verification Methodology, also referred to as UVM [1], is designed to
have verification of ASIC [2], full custom. It is also helpful to verify FPGA based
designs. All the constructs and capabilities of UVM may not be useful to one project
rather it depends on the project, hence the name Universal. UVM base class libraries
[3] provide the common platform for verification engineer to develop complex test
bench. There are often multiple classes, methods or macros those are basic constructs
to develop testbench.UVM Class Reference Manual documents all of these classes but
which class to use is not much clear. Some of them are for internal use of the UVM
methodology. The goal of this paper is learning and adopting UVM. Paper also
suggests architecture of test bench [4] using preferred classes for developer.
Verification is important part of VLSI Design. History shows failures of chips due
to lack of proper verification strategy [5]. The statistics also shows that around 70%
of total time for chip specs to manufacture process is required for verification. Due to
increasing need of reducing time to market, time required for verification need to
reduce.
Reduction in time for verification can happen through reusability. That means the
stuffs already developed for verification should be reused for current scope of
verification. Maximum is the reusability minimum time required for verification.
There are many methods suggested by different EDA vendors. Some of such well
known methodologies include eRM (e Reusable Methodology) [6], introduced by
Verisity & later adopted by Cadence. eRM requires knowledge of e language &
Specman tool [7]. Other methodologies like OVM (Open Verification Methodology)
[8] and VMM [9] are introduced by Synopsys. There become need to have tool
independent methodology & should be universal across. This gives the UVM
(Universal Verification Methodology) which supported by Cadence, Mentor Graphics
as well as Synopsys. The UVM becomes interesting due to tool independent. The base
code of UVM is System Verilog [10].
2. SCOPE & SYSTEM DESIGN
The scope of this paper is approach to develop verification environment using UVM.
The required components definitions, there use & to reach to testbench development.
Idea here is to demonstrate efficient way of developing UVM testbench. To make
UVM testbench automated so that it can catch RTL bugs without manual efforts. Such
developed UVM testbench is fast enough. Number of transfers/stimuli may be
generated with UVM testbench without much manual efforts. UVM testbench
captures functional coverage [11] and is measure of verification. Almost all required
features and utilities of UVM are demonstrated.
3. UVM TEST BENCH ARCHITECTURE
UVM libraries are huge set of classes, macros [12]. It is the first step for verification
engineer to select proper classes for his/her verification components development
[13]. Once selected proper classes, verification engineer need to implement those
components as per the requirement.
Fig. 1 shows UVM testbench Architecture components and suggests UVM classes
to be used for the development of those components.

UVM Architecture for verification
Figure 1 UVM test bench Architecture
All complex test benches may be architected as shown in the figure with little or
more modification depending on project complexity. As shown in the figure the
environment should be instantiated in the test case. This makes easy for configuration
of environment with respect to test case. The environment may consist of one or more
agents depending on interface protocol supported by DUT. All agents have similar
architecture and consist of one or all of monitor, driver, sequencer and sequences.
UVM scoreboard is used for data checking.
4. EXAMPLE OF COMPONENT CODE
The code will depend on UVM guidelines. Approach is taken to make more reusable.
This paper also covers scoreboard and coverage.
Environment code using two agents would look like (full code is not mentioned
here)
class mem_env extends uvm_env;
mem_env_config mem_env_cfg;
mem_1_agent mm_1_agent;
mem_2_agent mm_2_agent;
mem_1_reg_predictor mm_1_reg_predictor;
mem_2_reg_predictor mm_2_reg_predictor;
mem_env_vir_sequencer mm_env_vir_sequencer;
uvm_component_utils(mem_env)

function new(string name , uvm_component parent);
super.new(name , parent);
endfunction
//Not all code shown here
::::::::::::::::::::::::::
::::::::::::::::::::::::::
endclass
5. RESULTS
With UVM test bench, functional coverage can be achieved. Typical UVM test bench
with coverage definition & test cases are the main outcome of this effort. UVM log
reports, waveform and functional coverage numbers are importance in verification
field.
Fig. 2 shows UVM log report if there is no any bug in the DUT. Corresponding
waveform is shown in Fig. 4. Please note that with UVM testbench number of stimuli
can be generated automatically. Fig.4 is snapshot of waveform of such number of
stimulus generated.
Figure 2 UVM test bench report without any RTL bug
Fig. 3 indicates UVM log report for captured RTL bug. Encircled portion in red
color indicates the actual bug. In this case, data written to memory and data read from
memory from same address is different. Expectation is to have same data. Report
shows expected data is `d12 but received is `d13. Corresponding waveforms for this
report are shown in Fig. 5 and Fig. 6. Write operation to memory as seen from Fig.5 is
to address `d0 with data `d12. Fig. 6 shows read operation from memory to address
`d0. As seen from waveform read data is `d13.
As seen we get ready log report from UVM test bench and we may save
considerable time compare to analyzing waveform manually.

Figure 3 UVM test bench report with RTL bug
Figure 4 Waveform without RTL bug

Figure 5 Waveform for write transfer
Figure 6 Read (Bug: Written Data & Read Data is not same)
Functional coverage is measure of verification. Fig. 7 shows functional coverage
status before UVM testbench is run.
Figure 7 Functional Coverage before UVM test bench run
Fig. 8 shows some improvement in functional coverage as we run few test cases.
The status shows that we have not yet covered all functionality and there is still need
of more test cases to run targeting uncovered portion.

Figure 8 Functional Coverage as UVM Testbench run
Fig. 9 shows achievement of our target of 100% functional coverage. This may
require number of test cases to run. If our definition of functional coverage complete,
we may conclude of verification activity after achieving 100% functional coverage.
Please note that there is also need of achieving code coverage to conclude on
verification activity. Code coverage is simulation tool dependent and hence not
discussed in this paper.
Figure 9 Final Functional Coverage achieved from UVM Testbench
6. CONCLUSION
UVM is a rich and capable class library that has evolved over several years from
much experience with real verification projects large and small, and SystemVerilog
itself is a large and complex language. As a result, although UVM offers a lot of
powerful features for verification experts, it can present a daunting challenge to
Verilog and VHDL designers who want to start benefitting from test bench reuse.
With UVM testbench, functional coverage can be achieved. Typical UVM
testbench with coverage definition & testcases are the main outcome of this effort.
The showcase of waveform & functional coverage numbers to indicate its importance
in verification field

The UVM Committee is to be congratulated for producing such an extensive and
useful implementation of the UVM class library. UVM delivers on its goals of
enabling the creation of modular reusable verification components, environments and
tests. However, it is important to realize that when using UVM, most of the
implementation of the library is dedicated to infrastructure and support of the
relatively small set of features that Test Writers, Environment Writers and Sequence
Writers will actually use. Indeed, the set of features identified in this paper consists of
10 classes, 30 methods and 7 macros that users need to be familiar with, in order to
use UVM (in addition to proper SystemVerilog coding and general use-model
approaches).
When compared to the 357 classes and 1037 unique methods (938 functions and
99 tasks) that comprise UVM1.2, this means that UVM users really only need to learn
3% of UVM (2% of classes and 3% of methods) to be productive. Given the anecdotal
feedback from many current and prospective UVM users that UVM is too
complicated and too hard to learn, this paper should serve to allay those fears to some
degree. Those feelings surely are exacerbated when one considers that the UVM
Reference Manual, which is the “official documentation” for UVM, includes
documentation for such a large number of classes and methods that will never (and in
reality were never meant to) be deployed by UVM users. Perhaps the Accellera UVM
Working Group could use this as an opportunity to streamline the UVM Specification
to focus on including only the “user-facing” API in the version that it contributes to
the IEEE.
ADVANTAGES
 Better Performance in terms of CPU time and memory usage.
 Much easier debugging
 Reusability of base classes, methods, environment
 Easier to synchronize the communication between verification components
 Very much structured testbench
 Fixed run flow because of UVM phases
 Easy to prepare the code
 Lesser time to build the testbench
APPLICATIONS
1. The Universal Verification Methodology (UVM) is a powerful verification
methodology that was architected to be able to verify a wide range of design sizes and
design types
2. The Universal Verification Methodology (UVM) is a standardized methodology for
verifying integrated circuit designs.
3. UVM (Universal Verification Methodology) is a library which is used in
SystemVerilog language to provide automation in various fields. Thus it
can't be compared in a "versus SystemVerilog" mode cos it extends the
capabilities of the systemverilog language.

REFERENCES
[1] Universal Verification Methodology (UVM) 1.1 User guide by accellera
[2] Michael Smith, “Application Specific Integrated Circuits” Pearson Education
Asia
[3] Universal Verification Methodolog (UVM) 1.2 Class by accellera
[4] Rich Edelman Mentor Graphics Fremont, CA Shashi Bhutada Mentor Graphics,
Los Angeles, CA“An approach to automating UVM testbench writing”.
[5] H. Foster. Redefining Verification Performance (part 2), August 2010
[6] e Reusable Methodology, Cadence
[7] Incisive Enterprise Specman Products, Verification automation from block to
chip to system levels, Cadence
[8] OVM-SC Library Reference Version 2.0.1, February, 2009., Cadence Design
Systems, Inc
[9] VMM user guide, Synopsys, Inc
[10] SystemVerilog 3.1a Language Reference Manual, Accellera’s Extensions to
Verilog
[11] J. Bergeron. Writing Testbenches: Functional Verification of HDL models.
Kluwer Academic Publishers,
[12] A. Erickson. Are OVM & UVM Macros Evil? A Cost-Benefit Analysis. In
Proceeding of Design and Verification Conference (DVCON) , Mar. 2011
[13] Vijayakumar Suvvari and M.V.H. Bhaskara Murthy, VLSI Implementation of
Huffman Decoder Using Binary Tree Algorithm, International Journal of
Electronics and Communication Engineering & Technology, 4(6), 2013, pp. 85–
92.
[14] Mr. Nitin S. Sonar and Dr. R.R. Mudholkar, Implementation of Data Error
Corrector Using VLSI Technique, International Journal of Electronics and
Communication Engineering & Technology, 5(5), 2014, pp. 91–95
[15] Advanced UVM in the real world, Mark Litterick Jason Sprott Jonathan Bromley

UVM ARCHITECTURE FOR VERIFICATION

More Related Content

What's hot

Similar to UVM ARCHITECTURE FOR VERIFICATION

More from IAEME Publication

Recently uploaded

UVM ARCHITECTURE FOR VERIFICATION