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’s 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.
Pre_reset, reset, post_reset, pre_configure, configure, post_configure, pre_main, main, post_main, pre_shutdown, shutdown and post_shutdown. Diagram below explains explicitly in graphical manner.
Fig. 2: Run phase execution explanation.
All different components run through various run-time phases. Reset related checks also takes place as part of the run_phase. There are activities that takes place before reset occurs. This phase is known as pre_reset phase. Next, the reset occurs. It could be active-low or high. The interface also needs to go to default mode. Both the activities takes place in reset phase. Everything running separately after reset is partitioned and is known as post_reset phase.
As part of configuration phase, DUT activities are considered. Pre_configure is known for activities to prepare the DUT after reset. In the configure phase, DUT is brought back in a known state where the test-vectors can be applied to it. In the post_configure phase, , we wait for the configuration to propagate through and bring it back to synchronization.
As part of main phase, the main task is to generate the stimulus required to and apply it to DUT. pre_main task makes sure that everything is fine and all components are ready to generate the test-vectors. In the main phase, the test-vectors are applied to the DUT. Sequences begins to generate the stimulus.
As part of the shutdown phase, we make sure that the stimulus that was generated during the main phase is applied appropriately to the DUT and the result data is taken out.
Next is the Clean Up phase. Everything starting from extraction, reporting to final category belongs to this class. As part of extraction, we basically gather all the information that was collected by Scoreboards and Monitors. Next, we compare the results obtained from the Actual DUT and Reference model. It is also known as Analysis phase. Basically, its used to compare the results and make sure that the DUT behaved correctly. As part of report phase, result is displayed as requested. Simulation results are displayed by writing the results to assigned files.
In case if lost or just to keep up with the pace, please visit blog part 1 and part 2.
Also, for clarity of basics, consider taking a look at the following UVM webinar. You can ask all your questions as part of the comment section.