| Authors: Michael Donnelly - Lockheed MartinDoug Krening - Verification ConsultantMike Horn - Mentor Graphics Abstract: In 2010–2011, Lockheed Martin Space Systems designed and verified eight FPGAs for the Command and Data Handling (C&DH) subsystem of the NOAA/NASA Geostationary Operational Environmental Satellite R-Series (GOES-R), scheduled to launch in 2015. Hardware validation and integration of these FPGAs went smoothly. Perhaps the best measure of the success: the FPGAs performed with almost no functional failures during integration and test. 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: Dramatically reducing agent development effort using a highly parameterized base agentProviding data rate controls in a driver that preserves interesting transaction bursts and gaps while maintaining a desired throughput using an interface throttling classEncapsulating, 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: A translator port to support incoming high-level transactions in a layered protocolAn internal analysis block to support checking of low-level protocol-related activity within the agentTwo separate analysis ports allowing the agent to separate stimulus and response transactionsA shared object to support variable sharing between agent members 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. 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. View & Download: Read the entire Weathering the Verification Storm: Methodology Enhancements used on a Next Generation Weather Satellite C&DH Program technical paper. Source: DVCon 2013 | |