Understanding the inner workings of UVM – Part 3

In this blog, I am going to discuss different phases that UVM follows.

The reason why UVM came up with such phases is because synchronization among all design-testbench was necessary. Using Verilog and VHDL, verification engineers did not have facilities such as clocking block or run phases. Now, it is very important that the time at which test vectors applied from test-bench reaches the Design Under Test(DUT) at the same time. If timing for different signals varies then synchronicity lacks and thus verification can not be achieved as expected. That is the main reason why UVM has different phases.

The whole environment of UVM is structured on phases. They are active right from the beginning of the simulation to the end of the simulation. The topic discussed here will help people who are new to UVM. To start with, most of the phases are call back methods. The methods are either function or task. They are all derived from the UVM_Component class, same as other test-bench components. If you remember the first blog, we went through how to write a class. We understood the OOP concepts such as inheritance and even used them by extending the base class. Now, creating objects of the class is also important in order to use it as and when required. It is known as build_phase. This step takes place first. Next, after we write different classes, it is important to connect them. For example, if I write different classes with different functionality, at the end I provide them all under one top class. In Verilog it was top level module. In system Verilog it was class Environment. Under that main class, you connect all your semi classes which is known as connect_phase. Next, comes the end_of_elaboration_phase. By the time this phase becomes active, everything is connected and simulation next moment on wards is ready to begin.

Below is the diagram showing all different phases in UVM.

Fig 1 – UVM Different phases

The build, connect, end_of_elaboration Phases take place at 0 simulation time. Next, the actual simulation execution takes place in the run¬¬_phase. Whatever test-bench stimulus is generated, that is going to be passed and applied to the DUT in this phase. To keep clarity, run_phase is dynamic task. It contains several other tasks as part of it. All the run tasks execute concurrently. All components in the test-bench are brought to synchronization with the help of the run phase. It is used most commonly for stimulus generation, driving and monitoring the test vectors. run_phase can be divided into different segments to understand further closely.

For the rest of this article, visit the Aldec Design and Verification Blog.

Tags: asic, co-simulation, coverage, debugging, documentation, FPGA, osvvm, Riviera-PRO, uvm, verification

Category: Functional Verification

This entry was posted on Monday, March 26th, 2018 at 3:07 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.