Understanding the inner workings of UVM - Part 3

UVM Basics Part 3 of 3

Vatsal Choksi, Applications Engineer
Like(2)  Comments  (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.


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. The links are provided below.


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.


I hope the blog series really helps you understand and learn the fundamentals of UVM.

Vatsal provides technical support for Aldec’s software products such as Active-HDL and Riviera-PRO. He is proficient in FPGA/ASIC digital design and verification.As a technical support engineer, Vatsal has deep understanding of verification languages such VHDL, Verilog/SystemVerilog, SystemC and methodologies such as OSVVM, UVVM and UVM. Vatsal received his master’s degree in the field of Electrical and Electronics Engineering from California State University Sacramento in year 2015. His desire and passion is to know and learn more about design and verification that makes him suitable at solving complex verification issues.


All three articles, UVM - Part 1,2 and 3 are good. Thank you :)
Mahesh K. over 6 years
Hey, thanks Mahesh! I am glad you found if useful!
Vatsal C. over 6 years
Hey, thanks Mahesh! I am glad you found if useful!
Vatsal C. over 6 years
Ask Us a Question
Ask Us a Question
Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.