In 2002 eRM (e-Reuse Methodology) from Verisity is introduced that provided rules for building reusable, consistent, extensible and Plug and Play verification environments. In 2003 RVM (Reuse Verification Methodology) from Synopsis for Vera verification language is introduced it included base classes, message capabilities and packing guidelines. In 2006 AVM (Advanced Verification Methodology) from Mentor came and it was first open source Verification solution. Concept of TLM ports were adopted from System C to communicate between Verification Components. In 2007 URM (Universal Reuse Methodology) from Cadence that modified eRM with added features such as factory, configuration and class automation for SV. In 2008 OVM (Open Verification Methodology) from Cadence and Mentor provided multi-vendor verification solution. Integration of multi-language test benches was also added.

In 2010 UVM (Universal Verification Methodology) from Mentor, Cadence and Synopsis came into picture it is based on OVM, and adopted as a proven library industry wide verification methodology. It is methodology for verification that uses System Verilog or we can say System Verilog is the foundation of UVM. This methodology provides basic building blocks, coding guidelines and advice on reusing verification components. UVM Test Benches are layered and structured test benches, where each structure has a specific role to play

A standard structure of Universal verification component includes following elements:

• Data Items :-They represents stimulus transactions that are input to the DUT. In a test, many data items are generated and sent in to the DUT. Examples: CMD, Instructions , Data packets.
• Driver:- It is an active entity having logic that drives the DUT. It repeatedly pulls data items generated by sequencer and drives it to Design under test.
• Sequencer :-It is an stimulus generator that generates and returns data items upon request from the driver. A sequencer has an ability to react to the current state of DUT and generate more useful data items by changing randomization weights.
• Monitor:-It is a passive entity that samples DUT signals but does not drive them. It is useful in collecting coverage and checking performance. It can also be used to predict result based on sampled inputs and verifying them against sampled outputs
• Scoreboard :-It is Passive entity that is generally used for checking data integrity.
• Agent:-They are used to encapsulate driver, sequencer and monitor. An UVM TB can contain more than one agent. Different agents can be used to target different protocols in an SOC based verification env Agents can be configured as active and passive. Active agents are one which emulates devices and drives DUT�s ports. Passive agents only monitors DUT activity.
• Environment :-It is top-level component of an UVM TB, that can contain one or more agents. It can also contain Score Boards that are used to perform end-to-end transmission checks or perform checks against reference models. An environment may contain an environment level monitor. These monitor is used for performing checking and coverage for activities that may not be related to a single agent. Environment can also contain configuration properties that can be used to customize topology and behavior to make it reusable

The UVM library provides all the building blocks that we require to build modular, scalable, reusable, verification environments. This library contains base classes, utilities and macros to support the entire verification process.

uvm_void class is the base class for all UVM classes. It is an abstract class with no data members or functions. uvm_object class is the base class for all UVM data and hierarchical classes. uvm_transaction class is base class for all UVM Transaction, It inherits all features of uvm_object. uvm_report_object class provides an interface to UVM reporting facility. It allows UVM Components to issue various messages during simulation time. uvm_component is the base class for all UVM Components. Components are quasi-static objects that exists throughout the simulation In addition it provides Hierarchy, searching and traversing component hierarchy, Phasing, defines test flow of all the components. Configuration, allows configuring component topology. Factory, for creating and overriding components

In System Verilog classes are instantiated at run-time. This raise a questions that what will be the good time to start data generation and transfer, assuming all verification components have been created and connected properly. ? UVM Provides concept of Phases to solve this issue. Each phase has a defined order of execution.

All phases works on bottom up manner (child is connected with parent) except Build phase which works on top down approach. All phases are functions while Run phase which is time consuming is a task and runs in parallel. Run phase is further sub divided into four phases that executes one after other as shown in fig 4.

Components can raise and drop objection (phase.raise_objection (this) , phase.drop_objection (this)). Raising and dropping of objection is done in run phase and a component that raises objection remains in same phase till all the objections are dropped.

Universal Verification Methodology is a standardized methodology for verifying IC and SOC designs. The UVM class library brings much automation to the system Verilog language such as sequences , sequencers , reporting and data automation features etc. This methodology is an Accellera standard with support from multiple vendors: Aldec, Cadence, Mentor Graphics, and Synopsys due to which it is universally acceptable Verification methodology