UVM PHASES

Phases provides proper synchronization between all the components

 Each tb component derived from uvm component that has

predefined phases.
 Each component cannot move to the next phase unless current
phase execution is completed for all the components.
 UVM phase are executed at a certain order and all are virtual
methods
 Few phases consume simulation time for implementation called as
task.
 Other phases do not consume simulation for implementation
called as function

Main categories in UVM Phases

a) BUILD PHaSE USED to confIgUrE

or conStrUct tHE
tEStBEncH
B) rUn PHaSE tImE conSUmIng tB
actIvIty
c) cLEan UP coLLEct anD rEPort
PHaSE tHE rESULt of tHE
SImULatIon
------------------------------------------------------------------------

There are total 9 phases in UVM

PHASE PHASE NAME DESCRIPTION EXECUTION
TYPE APPROACH
Create TB
Function Build_phase component
TOP-DOWN

Connect TB
Connect_phase component
Function using TLM BOTTOM-UP
port
mechanism
Make final
End_of_elaboration adjustment
Function phase before
simulation BOTTOM-UP
starts.
It also displays
uvm topology
Used for
Start_of_simulation displaying
Function phase banners
Display TB BOTTOM-UP
topology
Configuration
information
Actual
simulation
happen in Run
TASK Run_phase phase PARALLEL
It is time
consuming
task
 12 sub phases
added in
parallel with
run phase
Sub phases in
run phase
a) Reset
b) Configure
c) Main
d) shutdown
Retrieves and
Extract_phase process
information
Function from BOTTOM-UP
scoreboards
and functional
coverage
Checks the
DUT behavior
Indentifies
Function error that may BOTTOM-UP
Check_phase have occured

Display the
Function Report_phase result of BOTTOM-UP
simulation
Complete any
Function Final_phase() other pending TOP-DOWN
jobs
EXAMPLE OF PHASES

https://www.edaplayground.com/x/Hxr4

OUTPUT:
# KERNEL: UVM_INFO @ 0: reporter [RNTST] Running test test...
# KERNEL: UVM_INFO /home/runner/testbench.sv(27) @ 0:
uvm_test_top.env.agt_h.drv [INFO] build phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(97) @ 0:
uvm_test_top.env.agt_h.mon [INFO] build phase of monitor class
# KERNEL: UVM_INFO /home/runner/testbench.sv(33) @ 0:
uvm_test_top.env.agt_h.drv [INFO] Connect phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(103) @ 0:
uvm_test_top.env.agt_h.mon [INFO] Connect phase of monitor class
# KERNEL: UVM_INFO /home/runner/testbench.sv(178) @ 0:
uvm_test_top.env.agt_h [INFO] Connect_phase of agent class
# KERNEL: UVM_INFO /home/runner/testbench.sv(40) @ 0:
uvm_test_top.env.agt_h.drv [INFO] end_of_elaboration_phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(110) @ 0:
uvm_test_top.env.agt_h.mon [INFO] end_of_elaboration_phase of monitor class
# KERNEL: UVM_INFO /home/build/vlib1/vlib/uvm-1.2/src/base/uvm_root.svh(583)
@ 0: reporter [UVMTOP] UVM testbench topology:
# KERNEL: --------------------------------------------------------------
# KERNEL: Name Type Size Value
# KERNEL: --------------------------------------------------------------
# KERNEL: uvm_test_top test - @335
# KERNEL: env environment - @348
# KERNEL: agt_h agent - @357
# KERNEL: drv driver - @513
# KERNEL: rsp_port uvm_analysis_port - @532
# KERNEL: seq_item_port uvm_seq_item_pull_port - @522
# KERNEL: mon monitor - @367
# KERNEL: sqr sequencer - @376
# KERNEL: rsp_export uvm_analysis_export - @385
# KERNEL: seq_item_export uvm_seq_item_pull_imp - @503
# KERNEL: arbitration_queue array 0 -
# KERNEL: lock_queue array 0 -
# KERNEL: num_last_reqs integral 32 'd1
# KERNEL: num_last_rsps integral 32 'd1
# KERNEL: --------------------------------------------------------------
# KERNEL:
# KERNEL: UVM_INFO /home/runner/testbench.sv(46) @ 0:
uvm_test_top.env.agt_h.drv [INFO] start_of_simulation_phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(116) @ 0:
uvm_test_top.env.agt_h.mon [INFO] start_of_simulation_phase of monitor
class
# KERNEL: UVM_INFO /home/runner/testbench.sv(222) @ 0: uvm_test_top [INFO]
run_phase of test class
# KERNEL: UVM_INFO /home/runner/testbench.sv(123) @ 0:
uvm_test_top.env.agt_h.mon [INFO] run_phase of monitor class
# KERNEL: UVM_INFO /home/runner/testbench.sv(53) @ 0:
uvm_test_top.env.agt_h.drv [INFO] run_phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(60) @ 0:
uvm_test_top.env.agt_h.drv [INFO] extract_phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(130) @ 0:
uvm_test_top.env.agt_h.mon [INFO] extract_phase of monitor class
# KERNEL: UVM_INFO /home/runner/testbench.sv(66) @ 0:
uvm_test_top.env.agt_h.drv [INFO] check_phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(136) @ 0:
uvm_test_top.env.agt_h.mon [INFO] check_phase of monitor class
# KERNEL: UVM_INFO /home/runner/testbench.sv(72) @ 0:
uvm_test_top.env.agt_h.drv [INFO] report_phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(142) @ 0:
uvm_test_top.env.agt_h.mon [INFO] report_phase of monitor class
 # KERNEL: UVM_INFO /home/runner/testbench.sv(79) @ 0:
uvm_test_top.env.agt_h.drv [INFO] final_phase of driver class
# KERNEL: UVM_INFO /home/runner/testbench.sv(149) @ 0:
uvm_test_top.env.agt_h.mon [INFO] final_phase of monitor class
# KERNEL: UVM_INFO /home/build/vlib1/vlib/uvm-
1.2/src/base/uvm_report_server.svh(869) @ 0: reporter [UVM/REPORT/SERVER]

From this observation it is clear that all

phases executes from build phase to final
phase
--------------------------------------------------------------------------------------

Que 1) Why build_phase() is executed top down in

uvm_component hierarchy?

1) In uvm all the TB component like a

test,env,agent,driver,monitor,sequencer,scoreboard are based on
uvm_component.
2) The build_phase is used to create lower level component(child
component) from the parent component.
3) So, the build the TB hierarchy we always need parent object first.
Without parent component we cant create child component.

Que 2) Why are phases introduced for UVM

based system verilog testbench but not for
verilog based testbench?

1) In verilog all components are static.

2) In system verilog introduced OOPS concept feature in TB.
3) In the case of UVM based SV TB,Class objects can be created at
any time during simulation based on the requirement.
Hence it is required to provide proper synchronization.
The uvm phasing mechanism serves the purpose of
synchronization.
Que 3) Why we require run phase is a task?
Why cant be used as a function?

1) Function: Not consume simulation time

Task : Consume simulation time

2) In UVM, the run phase is a predefined phase that represents

the actual execution of the test scenarios on the DUT.
3) It is a part of UVM framework,and its purpose is to coordinate
the test execution and manage various task
4) The run phase implemented as a phase in UVM because it
provides proper synchronization with other phases of the TB.
5) If we try to use the run phase as function ,several issues would
arise
Synchronization:
 The run phase needs to be synchronized with other UVM
phases like build phase and connect phase.
 These phase have specific purposes and executes in a
certain order
 If the run phase implemented as a function,it would be
challenging to ensure proper synchronization and
coordination with other phases.
Control over Test execution:
 The uvm run phase is responsible for controlling the
simulation time and executing test sequences in DUT.
 If implemented as a function this level of control would be
difficult to achieve.
Consistency with UVM methodology:
 Uvm is a standard methodology and using the run phase
as a phase follows the uvm guidelines.
 Using it as function,it would deviate from the standard
UVM approach and might make code less maintainable
and less compatible.
Que 4) if we include “build phase” and
“connect phase” inside the “run phase” will
it work?

1) In UVM , the build phase,connect phase and run phase are

different and predefined phases of TB lifecycle
2) Each phases have specific purpose and executes in
particular order.
3) Combining the build phase and connect phase inside the
run phase, phases would not work properly and violets the
fundamental principle of uvm topology.

Build phase:
 The build phase is responsible for creating lower level
components.
 It is very crucial to complete the build phase before
moving to other phase.

Connect phase :
 connection between TB components.Actual
connection happen in connect phase.
 This is crucial for setting up communication between
TB and DUT.

Run phase:
 in this phase actual stimulus is applied to the DUT and
test scenarios are executed.

If we include build phase and connect phase inside run

phase, we would encounter several issues.
 Ordering synchronization : May be execute in
incorrect order.
 Phase dependencies : We would loose ability to
separate the different functionalities.
  Maintainability : less maintainable code.

Que 4) How does UVM phase execution

start?

1) The run_test() method is required to call from static part

of the TB(top module)
2) This will trigger up the UVM testbench.
3) Run_test usually called in the initial block from top level
TB component.
4) The run_test() method call to construct the UVM
environment root component and then initiates uvm
mechanism.
Q 5) What will happen if the uvm build phase isexecuted
bottom-up?
The build phase is typically executed top-down, meaning that
higher-level components are built before their lower-level child
components.
If the UVM build phase is executed bottom-up, it would mean that
lower-level components are built before their parent higher-level
components. This approach could potentially lead to various issues
and challenges:
Connection Dependencies: Many times, the proper functioning of
lower-level components depends on the correct configuration and
setup of higher-level components. Building bottom-up might
result in missing connections or improper configurations, causing
functional errors in the testbench.
Hierarchical Organization: UVM promotes a hierarchical
organization of components, with higher-level components
encapsulating the functionality of their child components. Building
bottom-up could disrupt this hierarchy and potentially make the
testbench more difficult to understand and maintain.
Debugging Complexity: When issues arise, debugging becomes
more complex when the build phase is executed bottom-up. It might
be harder to identify whether the problem is stemming from a lower-
level component or due to improper configuration in a higher-level
component.
Q 6) Explain the significance of the reset_phase in UVM. The
reset_phase prepares the design and testbench for simulation by
applying a reset to the DUT (Design Under Test) and initializing key
components. This phase ensures a known starting point for the
verification process.
Q 7) What is the role of the configure_phase in UVM? The
configure_phase is responsible for configuring verification
components, setting their parameters, and preparing them for
operation. It allows customization of the testbench setup before
simulation begins.
Q 8) How does the main_phase fit into the UVM simulation flow?
The main_phase serves as a user-defined entry point for custom
simulation activities. It allows users to insert application-specific logic
into the UVM simulation flow, enabling specialized testing or
monitoring.
Q 9) What is a phase objection in UVM and why is it used? A phase
objection is a synchronization mechanism used to coordinate the
execution of UVM phases among different components. It ensures that
components wait until certain conditions are met before proceeding
to the next phase, enabling proper synchronization.
Q 10) How is communication achieved between different UVM
components during various phases?
Communication between UVM components during different phases is
achieved through various mechanisms, including hierarchical
references, callbacks, phase objections, analysis ports, and
transactions.
Q 11) Describe the difference between a phase and a phase
process in UVM. A phase represents a specific stage of the
verification process (e.g., build , run , check ), while a phase process
refers to the execution of tasks and methods associated with that
phase. A phase process manages the actions performed within a
phase.
Q 12) What is the use of the set_starting_phase method in UVM?
The set_starting_phase method allows you to specify a different
starting phase for the simulation. This is useful for scenarios where you
want to begin simulation from a phase other than the default.
Q 13) How can you enforce synchronization between different
UVM components during various phases?
synchronization between UVM components by using phase objections.
Components can object to a phase's completion until specific
conditions are met, ensuring proper synchronization before
proceeding.
Q 14) Describe the importance of the finalize_phase and how it's
used in UVM. The finalize_phase allows components to perform
cleanup and finalize operations before the simulation ends. It provides
an opportunity to close files, generate reports, and release resources.
Q 15) What is the role of the uvm_phase_started and
uvm_phase_ready_to_end callbacks in UVM phases? The
uvm_phase_started callback is triggered when a phase begins, and the
uvm_phase_ready_to_end callback is triggered when a phase is about to
end. These callbacks allow you to perform actions or checks at specific
points within a phase.
Q 16) Explain the concept of phase jump in UVM and when it
might be necessary. A phase jump is the process of moving directly
from one phase to another, skipping intermediate phases. It might be
necessary when you need to bypass certain phases for efficiency or to
address specific debugging or simulation challenges.
Q 17) How does UVM handle overlapping phases and potential
contention between different components? UVM uses phase
objections to handle overlapping phases and contention between
components. Objections prevent components from advancing to the
next phase until all participating components have completed the
overlapping phase.