Class uvm_task_phase
- uvm_pkg :: uvm_void
class my_comp extends uvm_component;
task main_phase(uvm_phase phase);
phase.raise_objection(this, "Applying stimulus")
...
phase.drop_objection(this, "Applied enough stimulus")
endtask
endclass
There is however one scenario wherein time advances within a task-based phase without any objections to the phase being raised. If two (or more) phases share a common successor, such as the uvm_run_phase and the uvm_post_shutdown_phase sharing the uvm_extract_phase as a successor, then phase advancement is delayed until all predecessors of the common successor are ready to proceed. Because of this, it is possible for time to advance between uvm_component::phase_started and uvm_component::phase_ended of a task phase without any participants in the phase raising an objection.
Constructors
Functions
- virtual function void traverse ( uvm_component comp, uvm_phase phase, uvm_phase_state state ) [source]
Traverses the component tree in bottom-up order, calling execute for each component. The actual order for task-based phases doesn't really matter, as each component task is executed in a separate process whose starting order is not deterministic.
- virtual function void execute ( uvm_component comp, uvm_phase phase ) [source]
Fork the task-based phase phase for the component comp .
Base class for all task phases. It forks a call to uvm_phase::exec_task() for each component in the hierarchy.
The completion of the task does not imply, nor is it required for, the end of phase. Once the phase completes, any remaining forked uvm_phase::exec_task() threads are forcibly and immediately killed.
By default, the way for a task phase to extend over time is if there is at least one component that raises an objection.