[source]

Class uvm_pkg::uvm_task_phase

uvm_pkg :: uvm_void
- uvm_pkg :: uvm_object
  
  uvm_pkg :: uvm_phase
  
  uvm_pkg :: uvm_task_phase

Inheritance Diagram of uvm_task_phase

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Class

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

new(string name)

Function

new

Create a new instance of a task-based phase

Parameters:: name (string)

Functions

traverse(uvm_component comp, uvm_phase phase, uvm_phase_state state)

Function

traverse

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.

Parameters:

comp (uvm_component)
phase (uvm_phase)
state (uvm_phase_state)

m_traverse(uvm_component comp, uvm_phase phase, uvm_phase_state state)

Parameters:

comp (uvm_component)
phase (uvm_phase)
state (uvm_phase_state)

execute(uvm_component comp, uvm_phase phase)

Function

execute

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

Parameters:

comp (uvm_component)
phase (uvm_phase)