Vertical reuse for further levels of integration can be achieved by extending the process described for the PSS example.
Each level of integration adds another layer, so for instance a level 2 integration environment would contain two or more level 1 envs and the level 2 env configuration object would contain nested handles for the level 1 env configuration objects. Obviously, at the test level of the hierarchy the amount of code increases for each round of vertical reuse, but further down the hierarchy, the configuration and build process has already been implemented in the previous generation of vertical layering.
( download source code examples online at http://verificationacademy.com/uvm-ovm ).
Component
An UVM testbench is built from component objects extended from the uvm_component base class. When an uvm_component object is created, it becomes part of the testbench hierarchy which remains in place for the duration of the simulation. This contrasts with the sequence branch of the uvm class hierarchy, where objects are transient - they are created, used and then garbage collected when dereferenced.
The uvm_component static hierarchy is used by the reporting infrastructure for printing out the scope of the component creating a report message, by the configuration process to determine which components can access a configuration object, and by the factory for factory overrides. This static hierarchy is represented by a linked list which is built up as each component is created, the components location in the hierarchy is determined by the name and parent arguments passed to its create method.
For instance, in the code fragment below, an apb_agent component is being created within the spi_env, which in turn is created inside a test as m_env. The hierarchical path to the agent will be "uvm_test_top.m_env.m_apb_agent" and any references to it would need to use this string.
//
// Hierarchical name example //
class spi_env extends uvm_env;
//....
apb_agent m_apb_agent; // Declaration of the apb agent handle
Component 40
// ...
function void build_phase(uvm_phase phase);
// Create the apb_agent:
//
// Name string argument is the same as the handle name // The parent argument is 'this' - i.e. the spi_env //
// The spi_env has a hierarchical path string "top.m_env" this is concatenated // with the name string to arrive at "uvm_test_top.m_env.m_apb_agent" as the // hierarchical reference string for the apb_agent
m_apb_agent = apb_agent::type_id::create("m_apb_agent", this);
// ...
endfunction: build_phase
// ....
endclass: spi_env
The uvm_component class inherits from the uvm_report_object which contains the functionality required to support the UVM Messaging infrastructure. The reporting process uses the component static hierarchy to add the scope of a component to the report message string.
The uvm_component base class template has a virtual method for each of the UVM Phases and these are populated as required, if a phase level virtual method is not implemented then the component does not participate in that phase.
Also built into the uvm_component base class is support for a configuration table which is used to store configuration objects which are relevant to a components child nodes in the testbench hierarchy. When the config_db API is used, this static hierarchy is used as part of the path mechanism to control which components are able to access a configuration object.
In order to provide flexibility in configuration and to allow the UVM testbench hierarchy to be built in an intelligent way, uvm_components are registered with the UVM factory. When an UVM component is created during the build phase, the factory is used to construct the component object. Using the factory allows a component to be swapped for one of a derived type using a factory override. This can be a useful technique for changing the functionality of a testbench without having to recompile. There are a number of coding conventions that are required for the implementation to work and these are outlined in the arcticle on the UVM Factory.
The UVM package contains a number of extensions to the uvm_component for common testbench components. Most of these extensions are very thin, i.e. they are literally just an extension of the uvm_component with a new name space, this means that an uvm_component could be used in their stead. However, they can help with self-documentation since they indicate what type of component the class represents. There are also analysis tools available which use these base classes as clues to help them build up a picture of the testbench hierarchy. A number of the extended components instantiate sub-components and are added value building blocks. The following table summarizes the available uvm_component derived classes.
Class Description Contains sub-components?
uvm_driver Adds sequence communcation sub-components, used with the uvm_sequencer Yes uvm_sequencer Adds sequence communcation sub-components, used with the uvm_driver Yes uvm_subscriber A wrapper around an uvm_analysis_export Yes uvm_env Container for the verification components surrounding a DUT, or other envs surrounding a (sub)system No
uvm_test Used for the top level test class No
uvm_monitor Used for monitors No
uvm_scoreboard Used for scoreboards No
uvm_agent Used as the agent container class No
Agent 42
Agent
A UVM agent can be thought of as a verification component kit for a specific logical interface. The agent is developed as a package that includes a SystemVerilog interface for connecting to the signal pins of a DUT, and a SystemVerilog package that includes the classes that make up the overall agent component. The agent class itself is a top level container class for a driver, a sequencer and a monitor, plus any other verification components such as functional coverage monitors or scoreboards. The agent also has an analysis port which is connected to the analysis port on the monitor, making it possible for a user to connect external analysis components to the agent without having to know how the agent has been implemented. The agent is the lowest level hierarchical block in a testbench and its exact structure is dependent on its configuration which can be varied from one test to another via the agent configuration object.
In order to illustrate the design and implementation of an agent we shall take an APB bus agent and show how it is packaged, configured, built and connected. The APB agent uses an interface which is called apb_if and will be stored in a file called apb_if.sv. The various class template files for the agent are collected together in a SystemVerilog package which is saved in a file called apb_agent_pkg.sv. Any component, such as an env, that uses files from this package will import this package.
package apb_agent_pkg;
import uvm_pkg::*;
`include "uvm_macros.svh"
`include "apb_seq_item.svh"
`include "apb_agent_config.svh"
`include "apb_driver.svh"
The agent has a configuration object which is used to define:
• Which of the agent's sub-components get constructed (Topology)
• The handle for the virtual interface used by the driver and the monitor
• The behavior of the agent
By convention, UVM agents have a variable of type UVM_ACTIVE_PASSIVE_e which defines whether the agent is active (UVM_ACTIVE) with the sequencer and the driver constructed, or passive (UVM_PASSIVE) with neither the driver or the sequencer constructed. This parameter is called active and by default it is set to UVM_ACTIVE.
Whether other sub-components are built or not is controlled by other variables which should have descriptive names. For instance, if there is a functional coverage monitor, then the bit that controls whether the functional coverage monitor gets built or not might be called has_functional_coverage.
The configuration object will contain a handle for the virtual interface that is used by the driver and the monitor. The configuration object is constructed and configured in the test and it is in the test that the virtual interface handle is assigned to the virtual interface passed in from the testbench module.
The configuration object may also contain other variables which affect the way in which the agent behaves or is configured. For instance, in the configuration object for the apb agent, there are variables which set up the memory map and determine which apb PSEL lines are activated for which addresses.
The configuration class should have all its variables set to common default values.
The following code example shows the configuration object for the apb agent.
//
// Class Description:
//
//
class apb_agent_config extends uvm_object;
// UVM Factory Registration Macro //
`uvm_object_utils(apb_agent_config)
// Virtual Interface virtual apb_if APB;