[wpbread]
UVM (Universal Verification Methodology) provides a framework for organizing the execution of a testbench into different phases, known as the UVM phases. The UVM phases help to structure the testbench creation and execution, making it easier to build and debug complex testbenches. UVM Phases also provide synchronizing mechanism for the environment. UVM phasing interface is implemented in uvm_component base class.
Table of Contents
Phase Categories
Phase Description
Here are the different UVM phases and a brief description of each:
| Phase | Description | Method Type | Execution Order |
| build_phase | This is the first phase of the testbench execution. During this phase, the testbench components are created and initialized. | function | top-down |
| connect_phase | In this phase, the connections between the testbench components are established. This includes connecting the analysis ports, setting up the scoreboard, and connecting the drivers and monitors to the DUT (Design Under Test). | function | bottom-up |
| end_of_elaboration_phase | This phase is used to make any final adjustments to the structure, configuration or connectivity of the testbench before simulation starts. | function | bottom-up |
| start_of_simulation_phase | This phase is used for printing testbench topology or configuration information. | function | bottom-up |
| run_phase | This is the phase in which the testbench generates stimulus and applies it to the DUT. The sequences and sequence items are executed during this phase, and the drivers generate the necessary signals to apply the stimulus. | task | parallel |
| extract_phase | This phase is used to retrieve and process information from scoreboards and functional coverage monitors | function | |
| check_phase | This phase is used to check that the DUT behaved correctly and to identify any errors that may have occurred during the execution of the test bench | function | |
| report_phase | The report phase is the last phase of the testbench execution. In this phase, the test results are generated and displayed. Any errors, warnings, or other messages are reported during this phase. | function | |
| final_phase | This phase is the last phase and used to complete any other outstanding actions that the test bench has not already completed | function |
Parallel Run-Time Phases
The following run-time phases execute in-order, in parallel with the run_phase phase.
reset_phase, configure_phase, main_phase, shutdown_phase with their pre and post variants.
| Phase | Description |
| pre_reset_phase | It starts at the same time as the run phase and used to perform the operations before applying reset to DUT. Eg: as waiting for a power-good signal to go active. |
| reset_phase | It is used to generate the reset and to put an interface into its default state |
| post_reset_phase | It is used to perform any operations after applying reset. Usually, this phase is not used. |
| pre_configure_phase | This phase is used to gather the configuration information and to wait for the components to be ready for the configuration after reset. |
| configure_phase | This phase is used to configure the DUT and to initialize the memories in the testbench. |
| post_configure_phase | This phase is used to wait for the configuration information to progress to the DUT. It is used to ensure that the main testcase can started for the simulation. |
| pre_main_phase | It is to ensure that all the components are ready to start the simulation. |
| main_phase | This phase is used to generate and apply the stimulus to the DUT. |
| post_main_phase | This phase is to take care of any finalization of the main_phase. |
| pre_shutdown_phase | This phase is to wait for the stimulus generation which is still generated. |
| shutdown_phase | This phase is used to ensure that all the stimulus has reached the DUT and the outputs are taken from the DUT. |
| post_shutdown_phase | It is to perform any final activities before exiting from the actual simulation phases. |
Starting UVM Phase Execution
To start a UVM testbench, the run_test() method has to be called
To start a UVM testbench, the run_test() method has to be called from the static part of the testbench. It is usually called from within an initial block in the top level module of the testbench. Calling run_test() constructs the UVM environment root component and then initiates the UVM phasing.
UVM Phase Debug
The uvm_cmdline_processor class provides +UVM_PHASE_TRACE, turns on tracing of phase executions. Users simply need to put the argument on the command line.