Search Results

Filters

Filters

Topic

Show More

Show Less

Content Type

Show More

Show Less

Audience

Resource Type

Show More

Show Less

Tags

Show More

Show Less

2419 Results

  • Block Level Testbench

    As an example of a block level testbench, consider a testbench built to verify a SPI Master DUT. In this case, the UVM environment has two agents - an APB agent to handle bus transfers on its APB slave port, and a SPI agent to handle SPI protocol transfers on its SPI port. The structure of the overall UVM verification environment is illustrated in the block diagram. Let us go through each layer of the testbench and describe how it is put together from the top down.

  • Integration Level Testbench

    This testbench example is one that takes two block level verification environments and shows how they can be reused at a higher level of integration. The principles that are illustrated in the example are applicable to repeated rounds of vertical reuse.

  • Testbench Architecture

    This chapter covers the basics and details of UVM testbench architecture, construction, and leads into other chapters covering each of the constituent parts of a typical UVM testbench. A UVM testbench is built using SystemVerilog (dynamic) class objects interacting with SystemVerilog (static) interfaces and modules in a structured hierarchy. The hierarchy is composed of layers of functionality. At the center of the testbench is the Design Under Test (DUT).

  • Specifying Registers

    Hardware functional blocks connected to host processors are managed via memory mapped registers.

  • Register-Level Functional Coverage

    The UVM supports the collection of functional coverage based on register state in three ways:

  • Testbench Basics

    Before we can get into discussing the recipes presented in the UVM Cookbook, we have to make sure that we're all talking about the same ingredients. This chapter introduces the UVM concepts that the reader should know in order to understand the recipes presented herein. This section will be incredibly valuable to new UVM users, but experienced UVM users may be able to just straight to the UVM Testbench chapter.

  • Interfaces and Virtual Interfaces

    The SystemVerilog interface provides a convenient means of organizing related signals into a container in order to simplify connections between modules. An interface may be declared with or without ports. If it is declared with ports, then those ports need to be assigned to signals when the interface is instantiated.

  • UVM

    The (2018) version conforms to the IEEE 1800.2 UVM Standard and promotes an emulation-friendly UVM testbench architecture that promotes reuse of your UVM environment as your project moves from simulation to emulation and beyond. Find all the UVM methodology advice you need in this comprehensive and vast collection.

  • UVM Cookbook

    The UVM Cookbook conforms to the IEEE 1800.2 UVM Standard and promotes an emulation-friendly UVM testbench architecture that promotes reuse of your UVM environment as your project moves from simulation to emulation and beyond.

  • UVM Sequences

    In testbenches written in traditional HDLs like Verilog and VHDL, stimulus is generated by layers of sub-routine calls which either execute time consuming methods (i.e. Verilog tasks or VHDL processes or procedures) or call non-time consuming methods (i.e. functions) to manipulate or generate data.

  • UVM Configuration Database

    The uvm_config_db is a UVM utility class that is used to pass configuration data objects between component objects in a UVM testbench. Any call to the uvm_config_db is parameterized with the type of the data object that is stored or retrieved. To store an object in the uvm_config_db, its set() method is used, and to retrieve an object from the uvm_config_db, its get() method is used.

  • Handling Parameterization

    Parameters are commonly used to configure design IP and interfaces. From the perspective of VIP, parameters usually affect the width of bus fields or the number of channels or lanes in use. SystemVerilog interfaces may be parameterized and, when they are, their virtual interface handles also need to be parameterized.

  • Virtual Interface BFMs

    In order to make verification components reusable between testbenches they are organized as uvm_agents with an associated signal interface. These are also referred to as UVCs (Universal Verification Components). Inside the uvm_agent, there are two types of uvm_components that interact with the virtual interface.

  • Abstract-Concrete Class Connections

    An alternative to using a virtual interface handle for DUT to UVM testbench connections is to use an abstract-concrete class pair. The abstract version of the class defines templates for all the methods that are available in the BFM. The concrete version of the class is declared in the BFM and it extends the abstract version, providing an implementation of the methods. The handle of the concrete class is assigned to the abstract handle in the agent classes via the uvm_config_db.

  • Connecting the Testbench to the DUT

    The UVM testbench objects cannot make a direct connection to the DUT signals in order to drive or sample them. The connection between an agent’s driver and monitor component objects and the DUT is indirected through one or more BFM components that have static signal ports. In this section of the UVM cookbook we consider the problem of connecting the UVM testbench to the RTL DUT.

  • Messaging in Sequences

    Sequences typically use messaging, either for debug, traceability or to report on the outcome of a built-in checking mechanism.

  • Messaging

    The UVM messaging system provides an infrastructure for printing messages in a consistent format from a UVM testbench

  • UVM Report Catcher

    There are situations where you may need to change a message generated by the messaging system, and the uvm_report_catcher is built-in call-back mechanism for doing this.

  • Command-Line Verbosity Control

    There are several UVM plusargs that can be used to control messaging verbosity, actions and severity from the command line.

  • Testing Message Status

    At the end of a UVM simulation, the report server issues a messaging summary to the transcript of the simulation.

  • Using Messaging

    The recommended way to use the UVM messaging system is to use the message macros, since they automatically insert the file name and line number of the message source into the UVM message string which is useful for debugging

  • Complex Address Maps

    In SoC design, the address mapping of registers and memory is often more complex than a single map.

  • Accellera UVM 1.2 Summary

    Cookbook topics which link to this page are affected by backwards compatibility issues or migration issues, when the Accellera UVM 1.2 release is used. Check the categories below for sources of information and advice, and a summary of the changes involved in migrating from UVM 1.1x to UVM 1.2.

  • Comprehensive Metrics-Based Methodology to Achieve Low Power SoCs

    In this session, you will be introduced to the tutorial agenda and markets, metrics, dimensions and Lifecyle of low-power design and verification.

  • Questa Verification IP Integration

    In this session, you will learn how to integrate Questa Verification IP (QVIP) within your UVMF testbench.