SoC Verification is one of the hot issues in VLSI. More than 70 percent of the time is spent on verification. So, there is a need for constructing a reusable and robust verification environment. Universal verification methodology (UVM) is a promising solution to address these needs. This paper presents a survey on the features of UVM. It presents its pros, cons, and opportunities. Moreover, it presents simple steps to verify an IP and build an efficient verification environment. A SoC case study is presented to compare traditional verification with UVM-based verification.

UVM Architecture and Skeleton: the big picture.
Partial UVM class tree (uvm_pkg), we can inherit from any class.

Figures - uploaded by Khaled Salah

Author content

All figure content in this area was uploaded by Khaled Salah

Content may be subject to copyright.

ResearchGate Logo

Discover the world's research

  • 20+ million members
  • 135+ million publications
  • 700k+ research projects

Join for free

Abstract— SoC Verification is one of the hot issues in

VLSI. More than 70 percent of the time is spent on

verification. So, there is a need for constructing a

reusable and robust verification environment. Universal

verification methodology (UVM) is a promising solution

to address these needs. This paper presents a survey on

the features of UVM. It presents its pros, cons, and

opportunities. Moreover, it presents simple steps to

verify an IP and build an efficient verification

environment. A SoC case study is presented to compare

traditional verification with UVM-based verification.

Index Terms — UVM, SystemVerilog, TLM, IP, SoC,

Verification, Driver, Monitor, Sequence, Test, OOP.

I. INTRODUCTION

Now, SYSTEMVERILOG (SV)/UVM gradually

dominate the verification landscape. SV does not support

MACROS and the language alone was insufficient to

enable widespread adoption of the best-practice verification

techniques that inspired its development that is why we

need UVM [1]- [2]. UVM is a methodology for SoC

functional verification that uses TLM standard for

communication between blocks and SystemVerilog for its

languages, or in other words, it uses SV for creating

components and TLM for interconnects between

components.

Methodology is a systematic way of doing things with a

rich set of standard rules and guidelines. Methodology

provides the necessary infrastructure to build a robust,

reliable, and complete verification environment.

Methodology shrinks verification efforts with its predefined

libraries. It makes life easier by preventing the designer

from making mistakes or poor decisions. It also helps make

sure that whatever you do will mesh nicely with what others

do (re-usability). Methodology is basically set of base class

library which we can use to build our testbenches.

UVM main goals are: reusability to reduce time to

market and it is targeted to verify systems from small to

large concept (Fig. 1), speed verification: it helps the

designers to find more bugs earlier in the design process, so

it provides practical and efficient SoC verification flow by

reusing IP testcase and testbench, standardization: vendor

independent, dynamic not static like traditional testing

(TABLE I), randomization, and automation [3]- [4]. UVM

makes multi-master multi-slave systems verification easier

as it separates tests from testbench. TABLE II summarizes

the companies, simulators and versions related to UVM [5]-

[6], it is noted that UVM is supported by all major

simulator vendors, which is not the case with earlier

methodologies [7]. Various IPs are connected to and

controlled through a bus, so the functional verification uses

BFM (bus functional model).

The rest of this paper is organized as follows. In Section II,

SystemVerilog features are proposed. In Section III, TLM

features are proposed. In Section IV, UVM features are

introduced. Conclusions are given in Section V.

TABLE I

COMPARISON BETWEEN UVM AND TRADITIONAL TESTING

Constrained random variable

10~40% to solve constraints

Higher (assertion, coverage)

TABLE II

COMPANIES, SIMULATORS AND VERSIONS RELATED TO UVM

UVM=ቐܱܸܯǡܣܸܯሺܯ݁݊ݐ݋ݎሻ

ܷܴܯሺ ܥܽ݀݁݊ܿ݁ሻ

ܸܯܯሺݏݕ݊݋݌ݏݕݏሻ

UVM supports all simulators {Questa, IUS, and VCS}

UVM=൝ܷܸܯͳǤͲ՜ܴܧܮܧܣܵܧܦ

ܷܸܯͳǤͳሺܽǡܾǡܿǡ݀ሻ՜ܴܧܮܧܣܵܧܦ

ܷܸܯͳǤʹ՜ܴܧܮܧܣܵܧܦ

Fig. 1 Levels of verification: UVM verifies systems from small to large

concept. SoC is a collections of IPs.

II. SYSTEMVERILOG

Initially, Verilog is used for verification. But, for

complex design, developing a verification environment in

Verilog is tedious process and consumes a lot of time. So,

SystemVerilog is used to create verification environment

which reduces effort to develop testbench. SystemVerilog

is an extensive set of enhancements to Verilog and it is

called hardware description verification language (HDVL),

the important features of it are summarized in Fig. 2.

SystemVerilog supports constrained random stimulus

generation and coverage analysis, and object-oriented

A UVM-Based Smart Functional

: Concepts, Pros, Cons

Khaled Salah

Mentor Graphics, Egypt

Khaled_mohamed@mentor.com

2014 9th International Design and Test Symposium

94

,(((

2

programming (OOP) structure which contributes to

transaction-level verification and providing the reusability

of verification. Object-oriented programming can greatly

enhance the reusability of testbench components [8]- [11]. It

has C-like control constructs such as foreach, and VHDL-

like package and import features. In this section, we

discuss the main features of SV, where OOP is introduced

in Section II-A, Easy call of C programs (DPI) is

introduced in Section II-B, constrained randomization is

introduced in Section II-C, functional coverage is

introduced in Section II-D, assertion is introduced in

Section II-E, other constructs such as : interface, modport,

clocking, fork_join, and always are introduced in Section

II-F, and new data types are introduced in Section II-G.

A. Object Oriented Programming

Object oriented programming is used for code

reusability (inheritance), where object= entity (hold the

data) + method (operate on the data). It is packing data and

function in one structure, moving functions inside data

structure is for consistency. Comparison between

instantiation of class in SystemVerilog and instantiation of

module in Verilog is shown in TABLE III. Moreover,

comparison between procedural code and OOP is shown in

TABLE IV. The main features of OOP are summarized in

TABLE V. The OOP in SV has some restrictions as it

supports only single inheritance [11].

B. Easy call of C programs (DPI)

In Verilog, calling C programs is called PLI and it is

complicated, In SV it is called direct programming interface

(DPI) and it makes C program calls easier [11]. SV

functions can be called in C using export and C functions

can be called in SV using import.

C. Constrained Randomization

Constrained random verification applies stimuli to the

device under test (DUT) that are solutions of constraints.

These solutions are determined by a constraint solver.

Thereby, the generated stimulus is much more likely to hit

corner cases which make discovering unexpected bugs

easier. Randomizing the stimulus also makes reaching the

verification coverage easier. We put some constraints on

that stimulus in order to generate legal or interesting

scenarios. Make sure that there is no conflict or contradict

between constraints. Constraints are like control knobs.

Weighted constraints are very important to hit boundary

values. In a nutshell, constrained random should be an

intelligent process. You can disable constrains using

constrain_mode (0) method.

D. Functional Coverage

Functional coverage is a user-defined metric that

measures how many percentages of the verification

objectives are met by the test-plan [2]. Quality of

verification depends upon the quality of test plan. Actually,

coverage answers the question "did we do enough

randomization?". For coverage closure, we may need to

write direct-testing, enhance stimulus generator, or

randomize seeds {vsim –sv_seed }.

E. Assertion

Assertion acts as constraints that determine and define

legal and expected behavior when blocks interact with each

other [2]. Complex protocol checks are often implemented

using SystemVerilog Assertions. Assertions could be tool

independent: used with both static and dynamic tools. SV

has two types of assertions: immediate (clock-independent)

and concurrent (clock-dependent) [9]. Assertion improves

observability and debug ability.

F. Other Constructs: Interface + modport+ clocking

+ fork_join (any none) +always (comb_ff_latch)

One of the problems of direct DUT signal access is that

driver and monitor are dependent on signal name of DUT,

and duplicate efforts. So, using interface as a signal-map

makes it easy to add or remove wire, reduce errors which

occur during model connections, remove redundancy in

wires (Fig. 3 ). Modport: for direction which is

input/output/inout. Clocking block is highly recommended

usage in testbench to avoid race conditions. Fork-join acts

like simply begin-end but inside fork-join all statements are

taken as concurrent. Classic fork-join is a "join all"

construct. That's if you fork two threads, then both of them

need to finish for the join to end. With join_none, one can

spawn threads and continue, this is useful in launching

multiple input data streams for example.

To assist synthesis, there are some extra keywords. The

always_comb, always_latch, and always_ff keywords

identify the intent of the process, so that a synthesis tool can

detect user errors [6], i.e. , the synthesis compiler can tell us

when we have the wrong type of logic in our RTL models.

G. New Data Types

Bit (2-valued) and logic (4-valued) are new data typed

introduced by SV to allow continuous assignments to logic

variables. Using a 2-valued data type will speed up

simulation of the code. We no longer need to worry about

when to declare module ports or local signals as wire or reg.

With SV, we can declare all module ports and local signals

as logic, and software tools will correctly infer nets or

variables for you [10]. SV also offers dynamic and

associative array and queue.

TABLE III

COMPARISON BETWEEN INSTANTIATION OF CLASS IN

SYSTEMVERILOG AND INSTANTIATION OF MODULE IN

VERILOG

Instantiation of class in systemverilog

Instantiation of module in

Verilog

Dynamic @ run time, Parameterized

class

TABLE IV

COMPARISON BETWEEN PROCEDURAL CODE AND OOP BY

EXAMPLE

Struct driver { wire A,B}

Void init {};

send_data {};}

2014 9th International Design and Test Symposium

95

,(((

Fig. 2 UVM consists of TLM and SV.

Fig. 3 Interface versus conventional connections.

TABLE V

MAIN FEATURES OF OOP

Defines set of properties and behavior of object, and it

is a data type.

Is an instant of the class and defined inside

program/module.

"Extends " for code reusability.

Bind data and method together for consistency.

It means to have many forms. Bind data and method at

run time. "Virtual " keyword.

III. TLM

Transaction-Level Modeling (TLM) provides abstraction

level description for the IP which means lack of details

(Fig. 4). Advantages: simulation speed increases,

observation of traffic is easier, debugging on TLM level is

easier than debugging on RTL. Disadvantages: accuracy

decreases. TLM separates communication from

computation and it is unidirectional put/get interface that

works as a bridge to enable UVM verifies multi-languages

like SYSTEMC. TLM is a library built on top of SystemC

which itself is a class library of C++. It encapsulates the

communication between different modules to separate

communication from computation. Translation of TLM2.0

from SystemC to SystemVerilog is needed, because it is

written at the beginning in SystemC. Connect () method

using TLM analysis port is the most famous method for

TLM in UVM. We have three types for TLM

communications: port, export, and analysis_port.

Fig. 4 Abstraction level versus accuracy, ESL is Electronic System Level.

IV. UVM

In this section we discuss the main features of UVM,

where UVM infrastructure is introduced in Section II-A,

Steps to verify an IP using UVM is introduced in Section

II-B, and Drawbacks of UVM is introduced in Section II-C,

Opportunities for UVM are discussed in Section II-D. A

case study is introduced in Section II-E.

A. UVM Infrastructure

UVM testbench is composed of reusable verification

component, which consists of a complete set of elements

for stimulating, checking, and collecting coverage

information for a specific protocol or design. These

verification components are applied to the DUT to verify it

[12]. The testbench should be layered to break the problem

into manageable pieces to help in controlling the

complexity.

The UVM main infrastructure, components, and all the

terminology related to UVM is introduced and summarized

in TABLE VI, and the general architecture is shown in Fig.

5. Master sequencer generates the data and it is sent to the

DUT through the driver. The data received by the slave are

feed back to the scoreboard via collector for comparison

then here the sent and received data item are compared in

the scoreboard. The monitor samples the stimulus and

responses. The configuration parameters are used to

configure these components. All these components can be

reused. The driver, monitor, and responder are called

transactors/translators/adaptors.

-

UVM

(Logic, bit)

Object Oriented Programming

Easy call of C programs (DPI)

Assertions

Interface+ modport +clocking

+ fork_join+ always

(comb_ff_latch)

2014 9th International Design and Test Symposium

96

TABLE VI

UVM INFRASTRUCTURE DESCRIPTION

For communication between classes and modules.

Representation of arbitrary activity in a device which has attributes and bounded by time.

Apply stimulus to DUT (protocol specific). Also, Covert TLM to RTL (pin wiggles). BFM = bus functional model.

Think in the driver as a normal testbench .

Monitor traffic, collect coverage, and send them to the various analysis ports such as coverage and scoreboard.

It looks like duplication of driver, but without triggering DUT wires (passive).

Collector = Receiver=Responder

Detects signal level activity, convert RTL to TLM and send it to monitor.

Sequencer = Producer = Generator

Execution of traffic, coordinate what to do. Running different streams without the need to change the component

instantiation. It is like arbitration logic.

Generate stimulus. Protocol dependent and consists of multiple of Sequence items. It is generated from test class.

Low level representation like address, data. A transaction object from the sequencer that stimulates the driver.

Inside driver to connect to RTL, like pointer to enable configuration at run-time. It is a reference to the actual interface.

Different sequences used by sequencer.

To connect between sequencer and driver.

Agent=Component = Module = UVC

Instantiate, configure subcomponents like {driver, sequencer, monitor, collector}. Agent for TX, agent for RX.

Tx, Rx, Master, Slave, Arbiter.

Coordinate traffic between different UVCs, does not have a sequence item. It is protocol independent. It starts

sequences on sequencer. Virtual sequences mean that sequences are calling other sequences.

Self-checking mechanism. Check that the design is doing what we expect. Need abstract reference model which can be

MATLAB or Python.

Golden

model and RTL must be developed by different teams, errors might be in both. Compare

(received, expected)

. It is a TLM-

based checking. It is preferred to separate protocol checking from data checking for

reusability. We can build the assertions inside the scoreboard.

For completeness as it measures important behavior, covers operation, dimension (as buffer size). Did we exercise the

whole testplan? To stress the device

if not. We need to know what all the tests have accomplished and this is done by

storing the data in a database and merging it all together. So, basically we should implement a regression environment

for functional coverage measurement.

Illegal bins should be analyzed to check if any test case is out of

the design

specifications.

Did we exercise the whole code? .

Contains all subcomponents, connections.

Call testbench, configure traffic, and can be {directed, random constrained, intelligent: driven random constrained to

remove redundancy}. Coverage driven testing -> continue randomization until coverage =100%.

To change the behavior of an already instantiated component to provide flexibility. Such as #slaves, #masters.

It provides configuration information to all parts of TB. Configuration database is like parameters in Verilog.

For class override at run-time, this helps making modifications to an existing testbench. Create () method.

Synchronization of UVM components. UVM components have different phases that operate in a particular sequence:

Build

(new())-> connect (TLM 2.0)-> end of elaboration (Config) ->strt_sim-> run->extract->check->report

*elaboration= @compile time,

*on the fly = @ run time

.

Build and connect are functions as they consume zero time. Run is task as it consumes some time.

The UVM comes with a bunch of classes which are used to implement the verification environment.

UVM packages:

UVM_components (structural).

UVM_objects (configuration).

3) UVM_transaction (stimulus).

Any component that is busy should raise an objection to ending the test, and then drop the objection when it is finished.

For example, you can raise objection until coverage is 100% (get_coverage( )) and then drop the objection.

Mechanism to setup and access DUT internal registers and memory. It extends from uvm_reg. IP-XACT format.

It is a roadmap summarizes test function points according with IP specification. (Failing to plan = planning to fail). It

should be smart test-plan which effectively and efficiently tests the DUT.

Macro is a construct that enables user to extend the language. Macros implement some useful methods in classes as it

can be used for shorthand notation of complex implement. They are optional, but recommended. The most common

ones are:

– This

macro registers the new class type. It's usually used when deriving new classes like a

new agent, driver, monitor and so on.

object_utils – This macro registers the objects like sequences.

– This macro registers a variable in the UVM

factory and implements some functions like copy (),

compare () and print ().

object_param_utils – This macro registers the parameterized objects.

param_utils– This macro registers the parameterized components.

uvm_info – This very useful macro to print messages from the UVM environment during simulation time.

uvm_fatal – This very useful macro to print fatal error

messages from the UVM environment during simulation time.

`

uvm_error – This very useful macro to print error messages from the UVM environment during simulation time.

uvm_warning – This very useful macro to print warning messages

from the UVM environment during simulation

time.

+Plusarg = command line processing

Some of the famous UVM +plusarg are:

+UVM_TESTNAME

2014 9th International Design and Test Symposium

97

Fig. 5 UVM Architecture and Skeleton: the big picture.

The UVM library defines a set of base classes and utilities

that facilitate the design of scalable, reusable verification

environments as depicted in Fig. 6. The basic building

blocks for all environments are components and the

transactions they use to communicate which are called

objects [12]- [14].

1) UVM_VOID

The uvm_void class is the base class for all UVM classes.

It is an abstract class with no data members or functions. It

allows for generic containers of objects to be created. It

works similar to a void pointer in the C programming

language.

2) UVM_OBJECT

All components and transactions derive from uvm_object,

which defines an interface of core class-based operations:

create, copy, compare, print, and record. It also defines

interfaces for instance identification (name, type name,

unique id, etc.) and the random seeding.

3) UVM_COMPONENT

The uvm_component class is the root base class for all

UVM components. Components are objects that exist

throughout simulation. Every component is uniquely

addressable using hierarchical path name.

4) C. UVM_TRANSACTION

The uvm_transaction is the root base class for UVM

transactions. It extends uvm_object to include timing and

recording interface. Simple transactions can derive directly

from uvm_transaction.

5) UVM_ROOT

The uvm_root class is special uvm_component that serves

as the top level component for all UVM components,

provides phasing control for all UVM components, and

other global services. UVM_TOP is a singleton of it.

6) UVM_CALLBACK

The uvm_callback class is the base class for user-defined

callback classes. We define an application-specific callback

class that extends from this class. In that, we will define one

or more virtual methods, called a callback interface that

represent the hooks available for user override.

Fig. 6 Partial UVM class tree (uvm_pkg), we can inherit from any class.

DUT

Driver

Monitor

Collector

2014 9th International Design and Test Symposium

98

B. Steps to verify an IP Smartly Using UVM

The steps to verify an IP smartly using UVM can be

summarized as follows:

1) Understand the specification: implement the DUT.

2) Prepare verification plan: feature extraction, specifies

how design will be verified, constrained random

coverage driven, written in excel sheet, link it to

coverpoint in coverage code written in SystemVerilog.

You should expose your DUT to stress testing.

3) Build verification environment in the following order:

interface, configuration, scoreboard, and monitors,

generate sequences based on verification plan, Env

Class+ simple testcase and simulate it. Debug from the

generated uvm report summary.

4) Measuring coverage progress against the test-plan, run

regressions, and add testcases for coverage holes. For

closing coverage you start to run with multiple seeds,

but sometimes certain scenarios can never be covered

by the randomness and we need a directed test case.

5) Error handling and debugging: when you find a bug,

before debugging it ask yourself the following

questions: Is this mistake somewhere else also? What

next bug is hidden behind this one? What should I do

to prevent bugs like this?. Then, you can start

debugging using waveforms, tracing, or logging. Use

built-in watchdog timer class to handle testcase

hanging.

6) When all tests in the test plan have been tested and no

bugs were found, then the verification task is over.

C. Drawbacks of UVM

Synthesis tool for SV is limited. This is a major

drawback which is restricting designers to accept SV as a

design languages. Also, there are limitations for using

UVM with emulators. Moreover, UVM is very

complicated, so it does not make sense with small projects.

Besides, there are challenges in using UVM at SoC Level.

Also, debugging Macros is difficult. UVM provides no

links between testbenches and code running in the

embedded processors.

D. Opportunities for UVM

UVM methodology can be enhanced to offer a flexible

framework for the virtual prototyping of multi-discipline

testbenches that supports both digital and Analog Mixed-

Signal (AMS) at the architectural level [15]. The extension

of UVM for mixed-signal verification of analog models is

reported in literature [15]. Moreover, UVM is a promising

solution in verifying 3D-SoC which has many IPs and

heterogeneous systems.

E. A Case Study: WISHBONE

A SoC case study is presented to illustrate the pros and

cons of the UVM and to compare traditional verification

with UVM-based verification. WISHBONE SoC

interconnect architecture for portable IP cores are used as a

case study [16]. The results can be shown in TABLE VII,

where the UVM-based approach improves the coverage

time by 12 times.

TABLE VII

COMPARSION BETWEEN DIRECT TESTING AND UVM

# Tests to reach 100 % coverage

V. CONCLUSIONS

This paper presents an overview on building a reusable

RTL verification environment using the UVM verification

methodology. UVM is a culmination of well-known ideas

and best practices. This paper also presents a survey on the

features of UVM. It presents its pros, cons, challenges, and

opportunities. Moreover, it presents simple steps to verify

an IP and build an efficient and smart verification

environment. A SoC case study was presented to compare

traditional verification with UVM-based verification.

REFERENCES

[1] J. Bromley "If SystemVerilog Is So Good, Why Do We Need the

UVM? Sharing Responsibilities between Libraries and the Core

Language" FDL, 2013.

[2] M.F. S. Oliveira, F. Haedicke, R. Drechsler, C. Kuznik, H.M. Le,

W. Ecker, W. Mueller, D. Große, V. Esen "The System Verification

Methodology for Advanced TLM Verification " ISSS, 2012.

[3] H. Zhaohui, A. PIERRES,H. Shiqing, C. Fang, P. ROYANNEZ, E.

P. SEE, Y. L. HOON "Practical and Efficient SOC Verification Flow

by Reusing IP Testcase and Testbench" ISOCC, 2012.

[4] S. Raghuvanshi, V. Singh "Review on Universal Verification

Methodology (UVM) Concepts for Functional Verification"

International Journal of Electrical, Electronics and Data

Communication, ISSN: 2320-2084 Volume-2, Issue-3, March-2014.

[5] Young-Nam Yun, "Beyond UVM for practical SoC verification",

SoC Design Conference (ISOCC), pp158-162, 2011.

[6] S. Sutherland, D. Mills "Synthesizing SystemVerilog: busting the

myth that SystemVerilog is only for verification", SNUG Silicon

Valley 2013. http://www.sutherland-hdl.com/papers/2013-SNUG-

SV_Synthesizable-SystemVerilog_paper.pdf.

[7] B. Vaidya N. Pithadiya "An Introduction to Universal Verification

Methodology" journal of information, knowledge and research in

electronics and communication engineering, volume – 02, ISSUE –

02, 2013.

[8] C. Spear and G. Tumbush, "SystemVerilog for Verification (2nd

Edition)", A Guide to Learning the Testbench Language Features,

Springer, LLC, (2012).

[9] H. Sohofi, Z. Navabi "Assertion-Based Verification for System-

Level Designs" ISQED, 2014.

[10] S. Sutherland and D. Mills "Can My Synthesis Compiler Do That?

What ASIC and FPGA Synthesis Compilers Support in the

SystemVerilog-2012 Standard" DVCon-2014, San Jose, CA.

[11] Y-Jin. Oh and G-Yong. Song, "System-Level Verification Platform

using SystemVerilog Layered Testbench & SystemC OOP"

International Journal of Control and Automation Vol.7, No.2 (2014),

pp.221-230.

[12] Vijayan U, Anjo C.A, Vignesh Raja B, Arun Kumar N

"Development of Basic Template Environment for Functional

Verification of VLSI Design Using UVM" International Journal of

Emerging Technology and Advanced Engineering, Volume 3, Issue

12, December 2013.

[13] Accellera, ʊ Universal Verification Meth odology (UVM) 1.1 User's

Guide, CA, May 2011.

[14] B. Vaidya, N. Pithadiya "An Introduction to Universal Verification

Methodology" Journal of Information, Knowledge and Research in

Electronics and Communication Engineering, 2013.

[15] T. Vörtler, T. Klotz "Enriching UVM in SystemC with AMS

extensions for randomization ad functional coverage", DVCON

Europe), October 2014.

[16] www.opencores.org.

2014 9th International Design and Test Symposium

99

... when the signal is at low it causes wait states to be inserted to the transfer and it also enables the slaves to have some extra time which is to provide or sample the data, the slave uses H -RESP signal which is used to indicate the failure or success of a transfer [3] E. Verification Background Due to increase in the complexity of the designs and circuits nowadays verification is a must to avoid failure of chips [5]. But how good is the verification is it efficient or not, there are many methods in verification domain but many industries adopt UVM as their verification method because of its efficiency and reusable nature [6]. RTL designs and circuits were verified using the same design language ie Verilog language by using test bench, but later on when the circuit complexity increased these conventional methods were difficult to use as they had many problems like delay mismatch and slow process, Then later on they proposed a language which can be used for both design and advanced verification called as System Verilog System Verilog was introduced for both design and verification, they are more advanced than Verilog language and more flexible than the hardware description language [7], system Verilog is standardized as IEEE 1800, system Verilog is based on Verilog with some advancements and extensions it is a evolution to Verilog System Verilog's verification environment is flexible and the architecture can be developed on the ideas of the verification engineer on his basis, all the blocks in the architecture are coded separately and interfaced which is more faster and delay mismatch can be avoided. ...

... UVM was developed from OVM later upgraded to VMM then further upgraded to VMM 1.2 and then UVM was introduced, UVM was made a standard by accellera, aldec, cadence, mentor graphics and synopsis provide support to UVM Figure 7 shows verification architecture of UVM from the diagram we can see that there are several blocks in the test environment such as sequence item, sequencer, active, passive agent and a scoreboard and a common interface to link the test design model or the test vectors to the DUT and perform verification same as the System verilog environment but this environment is a standard architecture which should be followed by every verification engineers and cannot skip therfore to avoid portable issues . including UVM is more flexible and have more features than system verilog [6]. From the architecture we can see that there are two diferent blocks active and passive agent in which active agent maintains input transactions and passive agent maintains output transactions. ...

  • G. Madhura
  • Ravishankar Holla Ravishankar Holla

System on Chip (SOC) designs involves the integration of intellectual property (IP) cores, each separately designed and verified. Most important is the method by which the IP cores are connected i.e., Interconnect. Verification of new Interconnect block design with a uniform communication bus is discussed in this paper, which can be reused among many projects. This block is combination of different bus protocols, removing signals that are chip or block specific. UVM based framework is developed to verify the new Interconnect block. Random constraint stimulus vectors generated using UVM are driven automatically to the Design Under Test (DUT) to obtain higher functional coverage. The new design and its UVM verification approach developed makes it easy to reuse the Interconnect block in different SOC architectures at both design and verification levels.

  • Gaddam Renuka Gaddam Renuka

Embedded SoC System verification have become chief challenge in recent years due to increase in complex architectures and software's. Even though SoC caters the needs for implementing the complex architectures, verification still remains crucial in terms of the accuracy, time computation and most importantly complex methodologies. Several methodologies were proposed, one such is Universal Verification Methodology (UVM), which occupies the major role in the SoC verification, UVM needs brighter light of research for the better improvisation in terms of the testing features and time of computation. Hence HUM (Hybrid Universal Methodology) was proposed with idea of extending the UVM by integrating the Fault Injection Systems along with Intelligent Predictors. The proposed tool has been tested with the IoTWireless Transceivers algorithms. The algorithms are targeted for the ARM architectures and results proved to be more vital.

  • Khaled Salah Khaled Salah
  • Ahmad El-Shiekh
  • Ahmad El-Alfy
  • Hassan Mostafa

This paper proposes a new CAD tool that automates the RTL code generation based on the IPXACT standard (develop RTL code using XML files). Many related work generates RTL design using C language. In this work, the generation is based on XML descriptions. The tool is developed using Python. The generated RTL code can be synthesized by the synthesis tool like Design Compiler. Several commercial tools like MATLAB have this capability, but the proposed tool is faster and more configurable.

The Universal Verification Methodology (UVM) is a coverage driven verification approach, which has become the standard for the verification of digital systems. The framework provided by UVM makes it possible to create structured test environments, which facilitates the reuse of verification components and scenarios. However, the UVM library is only available for SystemVerilog, limiting the verification of designs at the register transfer level. Recently, UVM has been made available in SystemC/C++, shifting the focus to system-level verification including analog/mixed-signal functions by using SystemC-AMS. However, UVM itself fully relies on features built directly into the SystemVerilog language necessary for constrained randomization and functional coverage. In this paper we propose an API similar to SystemVerilog that enables randomization and coverage in UVM for SystemC. A special focus is the introduction of continuous distribution functions for the randomization of real-value data types and means to capture these real values for functional coverage. These extensions will allow the creation of coverage-based test environments in SystemC and SystemC-AMS, enabling verification of heterogeneous analog/mixed-signal systems.

The IEEE-1800 SystemVerilog [20] system description and verification language integrates dedicated verification fea-tures, like constraint random stimulus generation and func-tional coverage, which are the building blocks of the Univer-sal Verification Methodology (UVM) [3], the emerging stan-dard for electronic systems verification. In this article, we introduce our System Verification Methodology (SVM) as a SystemC library for advanced Transaction Level Modeling (TLM) testbench implementation. As such, we first present SystemC libraries for the support of verification features like functional coverage and constrained random stimulus gen-eration. Thereafter, we introduce the SVM with advanced TLM support based on SystemC and compare it to UVM and related approaches. Finally, we demonstrate the appli-cation of our SVM by means of a testbench for a two wheel self-balancing electric vehicle.

As design abstraction has now got to its next upper level that is System Level, one of the main challenges in this area is how to verify designs that are modeled at System Level. In this paper, we are presenting an environment for functionally verifying system-level designs using assertions. This environment adapts existing EDA simulation tools, which are mainly used for RTL design and verification, and utilizes them for system level verification. In this environment, designs are modeled in SystemC-TLM 2.0, and assertions are written in SystemVerilog. Design and verification parts are connected together using SystemVerilog DPI mechanism, and designs are verified against system level assertions in the course of simulation.

  • Jonathan Bromley Jonathan Bromley

Probably the most effective catalyst for widespread adoption of advanced SystemVerilog features has been availability of the Universal Verification Methodology (UVM). In addition to a rich base class library, it provides a reference best-practice verification methodology. Fully supported by major tool vendors, and maintained by an industry-recognized body (Accellera) UVM has enjoyed widespread adoption by a diverse user base. For many users, "verification using SystemVerilog" is synonymous with "verification using the UVM". After outlining the UVM's value to users, and discussing how it has built on field-proven techniques from other languages and methodologies, this paper goes on to explore the relationship between the UVM and its host language SystemVerilog. In particular, it considers whether the addition of some features to SystemVerilog could have made the UVM smaller, easier to use, or even completely redundant. After examining some selected technical challenges and their solutions, the paper concludes that the needs of users are best served by a combination of an expressive base language and a comprehensive reference methodology.

  • Young-Jin Oh
  • Gi-Yong Song

Systems have recently performed multiple functions through a combination of several IPs. SystemVerilog has useful components for modeling and verification at System-level. The OOP of SysemVerilog supports only single inheritance in a verification environment based on a layered testbench of SystemVerilog. It is restricted to construct environment verification. SystemC is a language for system level design at multiple abstraction levels and supports multiple inheritance. We adopt SystemC to design components of a verification platform which employ multiple inheritance, and combine it with the SystemVerilog-based verification platform using SystemVerilog DPI and the ModelSim macro in this paper. Employing the multiple inheritance of SystemC makes the design of a verification environment simple and easy through code reusability. Another characteristic of OOP with SystemVerilog and SystemC is that it can create a reconfigurable verification platform.

  • Chris Spear
  • Greg Tumbush

There are several steps needed to verify a design: generate stimulus, capture responses, determine correctness, and measure progress. However, first you need the proper testbench, connected to the design, as shown in Fig. 4.1.

  • Chris Spear
  • Greg Tumbush

As you verify your design, you need to write a great deal of code, most of which is in tasks and functions. SystemVerilog introduces many incremental improvements to make this easier by making the language look more like C, especially around argument passing. If you have a background in software engineering, these additions should be very familiar.

  • Chris Spear

SystemVerilog for Verification teaches the reader how to use the power of the new SystemVerilog testbench constructs plus methodology without requiring in-depth knowledge of Object Oriented Programming or Constrained Random Testing. The book covers the SystemVerilog verification constructs such as classes, program blocks, C interface, randomization, and functional coverage. SystemVerilog for Verification also reviews some design topics such as interfaces and array types. There are extensive code examples and detailed explanations. The book will be based on Synopsys courses, seminars, and tutorials that the author developed for SystemVerilog, Vera, RVM, and OOP. Concepts will be built up chapter-by-chapter, and detailed testbench using these topics will be presented in the final chapter. SystemVerilog for Verification concentrates on the best practices for verifying your design using the power of the language. "You can verify complex designs thoroughly and quickly if you start with the right tools. This book teaches you the SystemVerilog constructs for verification with over 300 examples. Learn proven techniques so you can build testbenches that automatically generate stimulus to catch those bugs. The SystemVerilog language contains hundreds of new features. This book shows you how to use the important ones to get your job done. You will learn how to use techniques such as: object oriented programming; constrained random stimulus; functional coverage; and interfaces and clocking blocks." SystemVerilog for Verification teaches the reader how to use the power of the new SystemVerilog testbench constructs plus methodology without requiring in-depth knowledge of Object Oriented Programming or Constrained Random Testing. The book covers the SystemVerilog verification constructs such as classes, program blocks, C interface, randomization, and functional coverage. SystemVerilog for Verification also reviews some design topics such as interfaces and array types. There are extensive code examples and detailed explanations. The book will be based on Synopsys courses, seminars, and tutorials that the author developed for SystemVerilog, Vera, RVM, and OOP. Concepts will be built up chapter-by-chapter, and detailed testbench using these topics will be presented in the final chapter. SystemVerilog for Verification concentrates on the best practices for verifying your design using the power of the language. SystemVerilog for Verification teaches the reader how to use the power of the new SystemVerilog testbench constructs plus methodology without requiring in-depth knowledge of Object Oriented Programming or Constrained Random Testing. The book covers the SystemVerilog verification constructs such as classes, program blocks, C interface, randomization, and functional coverage. SystemVerilog for Verification also reviews some design topics such as interfaces and array types. There are extensive code examples and detailed explanations. The book will be based on Synopsys courses, seminars, and tutorials that the author developed for SystemVerilog, Vera, RVM, and OOP. Concepts will be built up chapter-by-chapter, and detailed testbench using these topics will be presented in the final chapter. SystemVerilog for Verification concentrates on the best practices for verifying your design using the power of the language. SystemVerilog for Verification teaches the reader how to use the power of the new SystemVerilog testbench constructs plus methodology without requiring in-depth knowledge of Object Oriented Programming or Constrained Random Testing. The book covers the SystemVerilog verification constructs such as classes, program blocks, C interface, randomization, and functional coverage. SystemVerilog for Verification also reviews some design topics such as interfaces and array types. There are extensive code examples and detailed explanations. The book will be based on Synopsys courses, seminars, and tutorials that the author developed for SystemVerilog, Vera, RVM, and OOP. Concepts will be built up chapter-by-chapter, and detailed testbench using these topics will be presented in the final chapter. SystemVerilog for Verification concentrates on the best practices for verifying your design using the power of the language. This book provides practical information for hardware and software engineers using the SystemVerilog language to verify electronic designs. The authors explain methodology concepts for constructing testbenches that are modular and reusable. The text includes extensive coverage of the SystemVerilog 3.1a constructs, and reviews SystemVerilog 3.0 topics such as interfaces and data types. Included are detailed explanations of Object Oriented Programming and information on testbenches, multithreaded code, and interfacing to hardware designs. © 2006 Springer Science+Business Media, LLC All rights reserved.

  • Hu Zhaohui
  • Arnaud Pierres
  • Hu Shiqing
  • Yean Ling Hoon

The SOC verification is challenging in verifying multiple IPs' integration and on-chip inter-IP communication in the complex system. SOC Engineers have to spend tremendous efforts on learning details inside IP design, developing complex testbench and testcase for each IP, and debugging on IP internal behavior. Reusing IP verification environment in SOC verification is always a desired methodology in theory but challenging in the implementation in reality. This paper presents a practical and efficient SOC verification flow by reusing IP test bench and test case based on UVM. SOC and IP Engineers work in their own specialized area and collaborate on debugging based on SOC-IP interface. It has been successfully used in project to decrease SOC verification complexity and debugging difficulty. Efficient flow shortens the verification cycle by 2 times and reduced engineer resources by 2 times.

  • Young-Nam Yun
  • Jae-Beom Kim
  • Nam-Do Kim
  • Byeong Min

As the size and complexity of SoC design grow, an efficient and structured verification environment is becoming more important than ever before. It is because many engineers with different knowledge and skills are involved in SoC verification, and they have to deal with different aspects of verification. This paper looks over the diversity of SoC verification and suggests a practical application method of UVM (Universal Verification Methodology) to build an efficient and structured verification environment which meets various requirements of SoC verification. This paper shows standardized and well-organized testbench architecture that includes directory structure of testbench files, and mechanism such as interface and handles across the components. The proposed UVM application method helps testbench developers maintain consistency of testbenches and reduce the quality gap among verification works that are done by multiple verification engineers, by using standardized testbench. It ensures that IP verification engineers do their job independently and the testbenches can be reused in top level verification environment. In addition, it provides a good infrastructure to hardware designers, who have little knowledge about verification languages and methodologies, and who want to write directed test cases only. The proposed method has been validated with a set of reference testbenches developed for an application processor SoC.