Class uvm_task_phase

• uvm_pkg :: uvm_void

  • uvm_pkg :: uvm_object

    • uvm_pkg :: uvm_phase

      • uvm_pkg :: uvm_task_phase

Reset

Inheritance Diagram of uvm_task_phase

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.

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

function new ( string name )

Create a new instance of a task-based phase

Functions

virtual function void traverse ( uvm_component comp, uvm_phase phase, uvm_phase_state state )

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 )

Fork the task-based phase phase for the component comp .

×