Abbreviations
API – Application Programming Interface
BFM – Bus-Functional Model
DUT – Design Under Test
OOP – Object-Oriented Programming
OVM – Open Verification Methodology (a predecessor of UVM)
TLM – Transaction Level Modeling (or Transaction Level Model)
UVM – Universal Verification Methodology
VIP – Verification Intellectual Property
Glossary
This glossary is not intended to be a comprehensive replacement for the official UVM Class Reference but just defines the main terms used in the Easier UVM Coding Guidelines.
Agent (class uvm_agent) — a component that contains one sequencer, one driver, and one monitor, and which senses and drivers the signals of one SystemVerilog interface.
Analysis port (class uvm_tlm_analysis_port) — a specific type of transaction-level port that can be connected to zero, one, or many analysis exports and through which a component may call the method write implemented in another component, specifically a subscriber.
Analysis export (class uvm_tlm_analysis_export) — a specific type of export that receives an incoming transaction stream from an analysis port.
Analysis imp (class uvm_tlm_analysis_imp) — a specific type of imp that receives an incoming analysis transaction stream. The component class that instantiates an analysis imp must define the method write required by that imp.
Barrier (class uvm_barrier) — an object that causes a set of processes to be blocked until a specified number of processes reach the barrier, at which point all processes waiting at the barrier are allowed to proceed.
Build phase — a pre-defined phase and a method of class uvm_component that is called during the phase of that name. The method build_phase may be overridden to get and set information in the configuration database and to create lower-level objects, including ports, exports, and child components.
Callback — a method of a class that can be overridden by the user when extending that class and which is called automatically by the UVM library under certain well-defined circumstances. UVM offers several distinct categories of callback, including callbacks for sequences, events, objections, registers, register fields, the report catcher, and user-defined callbacks.
Checking — the process by which the verification environment checks the functional correctness of the DUT, either using either procedural code within a UVM component or using concurrent assertions within a SystemVerilog interface.
Component (class uvm_component) — the structural building block of a UVM verification environment, conceptually equivalent to a Verilog module though implemented as an object in UVM. Components are constructed during the build phase, connected to other components using ports and exports, and able to be overridden (i.e. replaced) using the factory during the build phase. Components typically override the phase methods that are executed during the standard UVM phases.
Configuration database — a repository for storing the configuration information used to parameterize the verification environment.
Configuration object — an object, associated with a component and stored in the configuration database, which is used to configure the behavior or structure of its associated component. A configuration object is constructed and initialized by a module, test or env and is read by its associated component during the build phase.
Connect phase — a pre-defined phase and a method of class uvm_component that is called during the phase of that name. The method connect_phase may be overridden to make connections between ports and exports. The connect_phase methods are called bottom-up.
Coverage — data collected during simulation and used to determine when verification is complete. Function coverage is user-defined, structural coverage depends solely on the structure of the source code. Functional coverage data is typically collected using the SystemVerilog covergroup statement within subscribers or scoreboards or using the SystemVerilog cover property statement within SystemVerilog interfaces.
Driver (class uvm_driver) — a component that receives transactions from a sequencer and that actively or reactively drives the signal-level interface of the DUT as directed by the contents of those transactions. A driver may also send information from the signal-level interface back upstream to the sequencer, either by modifying the request object or using a separate response object.
Env (class uvm_env) — a component that instantiates one or more agents or lower-level envs and is used to add a level of component hierarchy within the verification environment. The top-level env is instantiated from the test.
Export — an object that allows a component to receive an incoming transaction stream that originates in another component. An export must receive its transaction stream either from a port on another component or from an export on a parent component, and must send transactions forward either to an export on a lower-level component or to an imp on a lower-level component.
Factory (class uvm_factory) — a UVM mechanism that allows a component, transaction, or sequence object to be replaced with an object of another type at the time it is created, thereby providing a general mechanism by which the behavior or structure of a class representing VIP can be modified as it is used.
Imp — an object that allows a component to implement the methods associated with an incoming transaction stream. Whereas an export must be connected to a lower-level export or imp, the component class that instantiates an imp must define any methods required by that imp.
Monitor (class uvm_monitor) — a passive component that senses the signal-level interface of the DUT (or, alternatively, that receives transactions from lower layers of the verification environment), gathers data into transactions, and sends those transactions out through an analysis port to the verification environment for checking and coverage collection.
Phase (class uvm_phase) — a UVM mechanism that subdivides execution into various predefined phases, the purpose of which it to allow verification components to agree on when to build components, connect ports, run simulation, reset the DUT, and so forth.
Port — an object that allows a component to send an outgoing transaction stream to another component. A port must be connected either to an export on another component or to a port on a parent component.
Register model (class uvm_reg_block) — an object instantiated between sequences or scoreboards and agents that abstracts certain details of the control and status registers in the DUT, thus permitting sequences or scoreboards to access registers by name without having to know their address, endianness, or whereabouts in the DUT.
Request — a transaction object created by a sequence and sent to a driver.
Response — a transaction object sent from a driver back to a sequence. The response object may be the request object itself or may be a new object created by the driver.
Run phase — a pre-defined phase and a method of class uvm_component that is called during the phase of that name. The run_phase method is the only common phase that is a task and may therefore consume time, the other methods being functions.
Sequence (class uvm_sequence) — an object that generates transactions or starts other sequences. A sequence class contains a user-defined task body that is called when the sequence is started. The task body does the work of the sequence. A sequence that directly generates transactions must always execute on a sequencer. A sequence indicates its readiness to generate a transaction by calling method start_item, and delivers the transaction by calling method finish_item. A sequence may retrieve a response to a transaction by calling method get_response. A sequence may be synchronized with other parts of the verification environment using barriers, callbacks, or events.
Sequencer (class uvm_sequencer) — a component that coordinates and arbitrates between transactions generated by sequences running on that component and that sends those transactions downstream to a single driver or to another sequencer. A sequencer performs arbitration when multiple sequences running on that same sequencer attempt to generate transactions in parallel.
Scoreboard (class uvm_scoreboard) — a component that receives transactions from multiple agents and typically performs end-to-end checking of DUT functionality, though it may also collect functional coverage information. A scoreboard may or may not incorporate a reference model of DUT functionality.
Starting phase (methods set_starting_phase, get_starting_phase) — the phase in which a sequence is started. From uvm-1.2 onward, the starting phase can only be accessed using the methods set_starting_phase and get_starting_phase in order to prevent the value from being modified after it has been read.
Subscriber (class uvm_subscriber) - a component that contains exactly one analysis imp and that implements the method write associated with that analysis imp to process an incoming transaction stream.
Test (class uvm_test) — the top-level user-defined UVM component in the component hierarchy. The test object is instantiated implicitly from uvm_top when method run_test is called. A test may modify the behavior or structure of the verification environment in order to increase functional coverage.
Transaction (class uvm_sequence_item) — an object that represents a communication abstraction such as a handshake, bus cycle, or data packet. A transaction class contains user-defined data members that represent the properties of the protocol, and user-defined methods to copy, compare, print, pack, unpack, and record those members. Transactions are typically generated by a sequence and passed to a driver or generated by a monitor and passed to zero or more subscribers. Transactions are passed between components using ports and exports.
Virtual sequence (class uvm_sequence) — a sequence that does not itself generate transactions but that typically starts other sequences on other sequencers. By this definition, because a virtual sequence does not itself interact with a sequencer, it can be started without a sequencer. Virtual sequences are typically used to coordinate the behavior of multiple agents (though strictly speaking a sequence that coordinates multiple agents need not be a virtual sequence).
Write (method) — a method that is called through an analysis port and implemented within a component that has an analysis imp. The implementation of the method write typically performs checking or functional coverage collection.
Links
Easier UVM Coding Guidelines
Easier UVM - Deeper Explanations
Easier UVM Code Generator
Easier UVM Video Tutorial
Easier UVM Paper and Poster
Easier UVM Examples Ready-to-Run on EDA Playground
Back to the full list of UVM Resources
