18
Copyright © 2017 IEEE. All rights reserved.
IEEE Std 1800.2-2017
IEEE Standard for Universal Verification Methodology Language Reference Manual
4. UVM class reference
The UVM base class library provides the building blocks needed to quickly develop well constructed and
reusable verification components and test environments in SystemVerilog. All UVM API should maintain
random stability.
The UVM classes and utilities are divided into the following categories pertaining to their role or function.
The subsequent clauses of this standard give a more detailed overview of each category—and the classes
that comprise them.
Base—The basic building blocks for all environments are components, which do the actual work,
transactions, which convey information between components, and ports, which provide the interfaces used
to convey transactions. The UVM’s core base classes provide these building blocks. See Clause 5
.
Reporting—The reporting classes provide a facility for issuing reports (messages) with consistent
formatting and configurable side effects, such as logging to a file or exiting simulation. Reports can also
filter out messages based on their verbosity, unique ID, or severity. See Clause 6
.
Recording—The recording classes provide a facility to record transactions into a database using a consistent
API. Users can configure what gets sent to the back-end database, without knowing exactly how the
connection to that database is established. See Clause 7
.
Factory—As the name implies, the UVM factory is used to manufacture (create) UVM objects and
components. A factory can be configured to produce an object of a given type on a global or instance basis.
Factories allow dynamically configurable component hierarchies and object substitutions without having to
modify their code or break encapsulation. See Clause 8
.
Phasing—This category defines the phasing capability provided by UVM. See Clause 9
.
Synchronization—These event and barrier synchronization classes can be used for process synchronization.
See Clause 10
.
Containers—These classes are type parameterized data structures that provide queue and pool services. The
class-based queue and pool types allow for efficient sharing of the data structures compared with their
SystemVerilog built-in counterparts. See Clause 11
.
UVM TLM—The UVM TLM library defines several abstract, transaction-level interfaces and the ports and
exports that facilitate their use. Each UVM TLM interface consists of one or more methods used to transport
data, typically whole transactions (objects) at a time. Component designs that use UVM TLM ports and
exports to communicate are inherently more reusable, interoperable, and modular. See Clause 12
.
Components—Components form the foundation of UVM. They encapsulate the behavior of drivers,
scoreboards, and other objects in a testbench. The UVM base class library provides a set of predefined
component types, all derived directly or indirectly from uvm_component. See Clause 13
.
Sequences—Sequences encapsulate user-defined procedures that generate multiple
uvm_sequence_item-based transactions (see 14.1
). Such sequences can be reused, extended, randomized,
and combined sequentially and hierarchically in interesting ways to produce realistic stimulus to a DUT. See
Clause 14
.
Sequencers—The sequencer serves as an arbiter for controlling transaction flow from multiple stimulus
generators. More specifically, the sequencer controls the flow of uvm_sequence_item-based transactions
(see 14.1
) generated by one or more uvm_sequence #(REQ,RSP)-based sequences (see 14.3). See
Clause 15
.
Authorized licensed use limited to: University of Liverpool. Downloaded on May 22,2017 at 20:59:50 UTC from IEEE Xplore. Restrictions apply.
我的内容管理
展开
