Methodology Enhancements used on a Next Generation Weather Satellite C&DH Program

To help with this effort, Lockheed Martin created and introduced three new parts to its verification methodology. While originally developed in OVM, these techniques have subsequently been ported to UVM. UVM versions of the enhancements will be shown and discussed here. The three enhancements are:

1. Dramatically reducing agent development effort using a highly parameterized base agent
2. Providing data rate controls in a driver that preserves interesting transaction bursts and gaps while maintaining a desired throughput using an interface throttling class
3. Encapsulating, modifying and covering variations to an interface's pin-level timing using an interface timing class

Parameterized Base Agent

When working with an agent-based UVM verification environment (an agent is an encapsulation of code needed to interact with a bus protocol), one thing becomes obvious: the architecture of most agents adheres to a small number of topologies. Though there is some variation depending on the application, an agent generally contains a monitor, sequencer, driver, configuration information and other various support classes.

In each agent these classes are interconnected identically, pulling configuration and virtual interface information from the configuration database and sharing much common base code. Taking advantage of this commonality, by using vendor-specific tools to auto-generate this code, helps avoid duplication of effort.

However, these tools have two main drawbacks. First, their cost can be prohibitive. Second, the tools are relatively inflexible regarding agent architecture. That is, if an organization wishes to utilize an agent that consists of more than a sequencer, driver and monitor, it may be out of luck.

SystemVerilog's capabilities can help with these issues. Parameters combined with classes in SystemVerilog allow for the creation of a set of base classes, which together form a highly parameterized base agent. As a concrete example, consider the agent shown in Figure 1. This agent has several enhancements over the standard sequencer, driver and monitor architecture:

1. A translator port to support incoming high-level transactions in a layered protocol
2. An internal analysis block to support checking of low-level protocol-related activity within the agent
3. Two separate analysis ports allowing the agent to separate stimulus and response transactions
4. A shared object to support variable sharing between agent members

^{Figure 1: An ACTIVE agent architecture}

The additional functionality included in this agent most likely eliminates the use of a code auto-generation tool, most of which use standard templates. Creating a reusable base agent capable of handling much of the low-level housekeeping requires diving into the world of SystemVerilog parameterized classes.

The problem at hand is to create a base class that takes advantage of the common construction of any concrete child class yet allows the types of the various class member objects to vary among its children. For instance, an RS422 agent and an AXI bus agent share the same basic architecture, yet the RS422 driver class must have radically different functionality than the AXI driver class.

This problem is illustrated in Figure 2.

class agent_base extends uvm_agent;
   // members
   …
   <drv_class> drv
  
   function void build_phase(uvm_phase phase);
     …
     drv = <drv_class>::type_id::create("drv", this);
   endfunction : build_phase
   …
endclass : agent_base

^{Figure 2: Parameterized agent problem}

In this figure, a base agent class attempts to declare and create a driver object. But since the driver class type must be specified in the base class, the base agent cannot instantiate a driver in a generic fashion.