The UVM testbench follows a layered architecture, where each component is dedicated to a specific task and interacts with the rest of the testbench through well-defined interfaces. This design promotes modularity and reusability, making it easier to manage and extend the testbench. Figure 1 illustrates a typical UVM testbench architecture.
Figure 1: UVM Testbench Architecture
UVM Testbench
The UVM Testbench is the top-level module in the hierarchy, where both the UVM Test and the Design Under Test (DUT) are instantiated. It also handles the configuration of connections between these components. One of the key features of the UVM Test is that it is dynamically instantiated at run-time, enabling the testbench to be compiled just once while running various tests, making the verification process more flexible and efficient.
UVM Test
The UVM Test is the top-level component in the UVM testbench hierarchy, dynamically created at run-time. It plays a crucial role in the verification process by performing three key functions:
- Instantiating the top-level environment.
- Configuring the environment using factory overrides or the configuration database.
- Applying stimulus by invoking UVM sequences, which drive the stimulus through the environment to the DUT.
UVM Sequence
The UVM Sequence is an object that controls the generation and flow of stimulus to the driver.
Config/Factory Overrides
Factory registration is the process of making all the created classes known to the factory, enhancing the flexibility and scalability of the testbench. This allows the base class objects to be overridden by any of their inherited child class objects at runtime. By registering classes with the factory, you enable seamless swapping of different object types without changing the underlying code.
UVM Environment
The UVM Environment is a hierarchical component that groups other verification components that are interrelated. The Top-level Environment encapsulates all the verification components targeting the DUT. Typically, the UVM Agents, UVM Scorboards or even other UVM Environments are instantiated in the top-level Environment.
UVM Sequencer
The UVM Sequencer manages the execution of sequences and is responsible for arbitration when multiple sequences are running. It communicates with drivers by sending sequence items.
UVM Scoreboard
The UVM Scoreboard collects the resposes from the DUT and checks for correctness by comparing to a reference model know as the predictor.
UVM Agent
The UVM Agent is a hierarchical component that groups three other components. Typically, the grouped components are sequencer, driver and monitor.
Sequencer
The UVM Sequencer manages the stimulus flow.
Driver
The UVM Driver is responsible for applying stimulus to the DUT interface. It receives individual sequence item transactions from the UVM Sequencer and translates them into pin-level signals for the DUT. The UVM Driver utilizes a Transaction Level Modeling (TLM) port to convert these high-level transactions into the appropriate low-level stimulus for the DUT, ensuring accurate signal application at the interface.
Monitor
The UVM Monitor samples the DUT interface. Similary to the Driver, a TLM port is incorporated to converts pin-level reponses to a transactions item for the rest of the testbench components.
Design Under Test (DUT)
As the name suggests, the Design Under Test (DUT) refers to the synthesizable Verilog/SystemVerilog component that is being tested for functional correctness.