Usage of sub-phases and phase jump in UVM

In this blog, we will see usage of UVM sub-phases by taking an example of reset test. As we know, in UVM, run_phase is divided into multiple sub-phases:

1. pre_reset_phase(), reset_phase(), post_reset_phase(): Phases involved in reset activity.
2. pre_configure_phase(), configure_phase(), post_configure_phase(): Phases involved in configuring DUT.
3. pre_main_phase(), main_phase(), post_main_phase(): Phases involved in driving main stimulus to the DUT.
4. pre_shutdown_phase(), shutdown_phase and post_shutdown_phase(): Phases involved in settling down the DUT after driving main stimulus.

In every verification environment, reset testing is a crucial feature and in many cases, we find issues. In it, user drives random sequence to the DUT and in between data transmission, reset is applied followed by driving restart sequence. So, we will see how the reset testing could be easily tested using sub-phases and “jump” feature of UVM.

Figure 1

As shown in Figure 1, test should wait to reset de-asserted and then it shall drive reset sequence (if defined). In post reset phase, it should check any signals status like interrupt based on reset sequence. Also, it is good to check the reset values of the signals in the pre_reset_phase() which is not shown here.

Figure 2

As shown in Figure 2, driver should drive reset value of the signals in the reset phase and then it waits for the reset de-asserted. It should clean all the queues and array in the pre_reset/reset phase and also resets the configurations. Same thing shall be applicable to the other components like monitor and a scoreboard.

If queues/arrays will not be cleared, then you may face unwanted issues like scoreboard mismatch or transaction field error during simulation. Many of us have faced these kinds of issues because of these small mistakes in the testbench.

Then it comes to configure phase. In pre_configure phase, user can set the configuration fields in the different testbench component and in configure phase, the DUT initialization sequence could be driven which enables DUT to run the traffic on the bus.

As shown in Figure 1, in the main phase of the testcase, we can drive the main sequence which contains main traffic which DUT samples and responds. Also, it includes a useful feature of “phase jumping”, which could be used while testing the reset functionality. By using this feature, we can jump back to reset phase from the main phase where we apply the reset. So that, all component’s phases will be set to the reset phase and all fields will have their default values.

However, user needs to take care many things while using this phase jumping feature like if any component (like a driver/monitor) doesn’t implement these sub phases properly and all traffic is driven from run_phase then it creates a big problem for the user.

In the shutdown phase, user can drive sequence like sleep sequence or somewhat else.

Note: This coding practice is not mandatory, but it’s just an example. It is not good to use a phase jumping feature in case any of the components of testbench don’t use the sub-phases of UVM.

Reference:

1. Universal Verification Methodology (UVM) 1.2 Class Reference