Introduction:

Hi Friends! Till now you’ve seen different topics & concepts being discussed on this site about UVM methodology. Today I’m going to share something which is common to almost every concept of UVM. In other way, we can say that this concept is the backbone of the UVM Verification Methodology. This is related to the process which deals from the starting of the simulation till end of the simulation.

So in this post, we’re going to know about UVM Phasing. UVM Phasing is a continuously evolved concept with time. This may sound very basic for few experienced users but I believe it will be certainly helpful to many of those friends who are relatively new to UVM.

In order to have a consistent Testbench flow, UVM introduces “Phases” to synchronize major functional steps a simulation runs through. These steps are sequential in nature which are executed in the following order:

• Build Phases
  1. Where the Testbench is constructed, connected and configured.
• Run-time Phases
  1. Stimulus generation & time consuming simulation takes place here.
• Clean up Phases
  1. Here the Test results are collected and reported.

We’ll see more details of these 3 Phases in the upcoming section of this post.

We know that UVM environment is built of static components those are derived from  the UVM base class i.e. uvm_component which contains number of virtual methods. These virtual methods supports the UVM Phasing mechanism. Hence a verification component can be developed in isolation since there is a established understanding on what is expected to happens in each of the execution phase.

Big Picture:

Lets see now the overall picture of the UVM Phasing using the Diagram 1 below:

Diagram 1: UVM Phases

Here we can see 3 groups of Phases which are briefly described as well.

• Build Phases group contains 3 sub-phases
• Run Phases group contains 13 sub-phases
• Cleanup Phases group comprises of 4 sub-phases

Before getting into the details of each sub-phase, lets see how the UVM Phase execution gets started from the very beginning of a simulation cycle.

How UVM Phasing is triggered?:

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.

// Top level Testbench module
module top_tb;

....
....
// UVM start up:
initial
 begin
 uvm_config_db #(virtual bus_if)::set(null, "*", "BUS_vif" , BUS);
 run_test("bidirect_bus_test");
 end

endmodule: top_tb

Once the run_test() method is called, it constructs the root component of the UVM environment & then triggers/initiates the UVM Phasing process. The run_test() method can be passed with a string argument, which in the above code is “bidirect_bus_test”, to define the default type name which is used as the root node of the Testbench Hierarchy.

In addition, run_test() method also checks for a command line plusarg called UVM_TESTNAME and uses that plusarg string to lookup a factory registered uvm_component to override any default type name.

Hence to execute the “bidirect_bus_test” using command line plusarg, we’ve to use the following command line:

% <simulator executable> +UVM_TESTNAME=bidirect_bus_test

What each of UVM Phase Performs?:

Lets detail out each of the UVM Phase/Sub-Phase with respect to the activities being performed during their execution:

1) Build Phase:

The build phases are executed at the start of the UVM Testbench simulation and their overall purpose is to construct, configure and connect the Testbench component hierarchy. All the build phase methods are functions and therefore execute in zero simulation time.

build:

Once the UVM Testbench root node component is constructed, the build phase starts to execute. It constructs the testbench component hierarchy from the top downwards. During the build phase uvm_components are indirectly constructed using the UVM factory.

connect:

The connect phase is used to make TLM connections between components or to assign handles to testbench resources. It has to occur after the build method so that Testbench component hierarchy could be in place and it works from the bottom-up of the hierarchy upwards.

end_of_elaboration:

The end_of_elaboration phase is used to make any final adjustments to the structure, configuration or connectivity of the Testbench before simulation starts. Its implementation can assume that the Testbench component hierarchy and inter-connectivity is in place. This phase executes bottom up.

2) Run Phase:

The UVM Testbench stimulus is generated and executed during the run time phases which follows the build phases. Run phase was present in OVM as well but additional other phases were added to UVM to give finer run-time granularity for tests, scoreboard and other components.

start_of_simulation:

The start_of_simulation phase is a function which occurs before the time consuming part of the testbench begins. It is intended to be used for displaying banners; Testbench topology; or configuration information. It is called in bottom up order.

run phase:

The run phase occurs after the start_of_simulation phase and is used for the stimulus generation and checking activities of the Testbench. The run phase is implemented as a task, and all uvm_component run tasks are executed in parallel. Transactors such as driver and monitor will nearly always use this phase.

pre_reset:

pre_reset phase starts at the same time as the run phase. Its purpose is to take care of any activity that should occur before the reset. E.g. waiting for a power signal to go active.

reset:

As name indicates, reset phase is specially for DUT or Interface specific reset behavior. This phase would be used to generate reset to put the DUT/Interface into a default state.

post_reset:

This phase is intended for any activity required just after the reset phase.

pre_configure:

This phase is intended for anything that is required to prepare for the DUT configuration process after the DUT is out of reset.

configure:

configure phase is used to put the DUT into a known state before the stimulus could be applied to the DUT. For example – programming the control registers of the device for a particular test scenario.

post_configure:

This phase is intended to wait for the effect of the configuration to propagate through the DUT.

pre_main:

pre_main is used to ensure that all the components needed to generate the stimulus are ready to do so.

main:

main phase is where the stimulus specified by the Test case is generated and applied to the DUT. It completes in two conditions: One is the stimulus gets exhausted and another is when timeout occurs. Sequences are started in this phase to generate the stimulus.

post_main:

Used for any final act after the main phase.

pre_shutdown:

This phase is acts like a buffer to apply any stimulus before the shutdown phase starts.

shutdown:

The shutdown phase is to ensure that the effects of stimulus generated during the main phase has propagated through the DUT and that the resultant data has drained away. It might also be used to execute the time consuming sequences that read status registers.

post_shutdown:

post_shutdown is intended for any final activity before exiting the run phase. After it UVM Testbench starts the cleanup phase.

3) Clean up Phase:

The clean up phases are used to extract information from Scoreboards and Functional Coverage Monitors to determine whether the test case has passed and/or reached its coverage goals. The clean up phases are implemented as functions and therefore take zero time to execute. They work from the bottom to the top of the component hierarchy.

extract:

The extract phase is used to retrieve and process information from Scoreboards and Functional Coverage Monitors. This may include the calculation of statistical information used by the report phase. This phase is usually used by Analysis side components.

check:

This phase is also used by the Analysis Components. This phase is used to check if the DUT behaved correctly and to find any error that may have occurred during the stimulus execution.

report:

The report phase is used to display the results of the simulation to the standard output or to write the results to file. This phase is usually used by Analysis Components.

final:

The final phase is used to complete any other outstanding actions that the Testbench has not already completed.

---

So these are all the different phases through which a Standard UVM Testbench runs through to generate reset, doing configuration, stimulus generation & performing simulation and finally report generation.

I hope this write up on UVM Phasing should be helpful to give you a fairly good picture of the different phases a UVM static component like Driver or Monitor etc. & dynamic component like Sequences goes through during life time of UVM Simulation.

I wish you all the best for your learning! See you soon with next post..till then bye!  🙂

---