Phasing

UVM implements an automated mechanism for phasing the execution of the various components in a testbench.

Contents
PhasingUVM implements an automated mechanism for phasing the execution of the various components in a testbench.
Pre-Defined PhasesThis section describes the set of pre-defined phases provided as a standard part of the UVM library.
uvm_build_phaseCreate and configure of testbench structure
uvm_connect_phaseEstablish cross-component connections.
uvm_end_of_elaboration_phaseFine-tune the testbench.
uvm_start_of_simulation_phaseGet ready for DUT to be simulated.
uvm_run_phaseStimulate the DUT.
uvm_extract_phaseExtract data from different points of the verficiation environment.
uvm_check_phaseCheck for any unexpected conditions in the verification environment.
uvm_report_phaseReport results of the test.
uvm_final_phaseTie up loose ends.
uvm_pre_reset_phaseBefore reset is asserted.
uvm_reset_phaseReset is asserted.
uvm_post_reset_phaseAfter reset is de-asserted.
uvm_pre_configure_phaseBefore the DUT is configured by the SW.
uvm_configure_phaseThe SW configures the DUT.
uvm_post_configure_phaseAfter the SW has configured the DUT.
uvm_pre_main_phaseBefore the primary test stimulus starts.
uvm_main_phasePrimary test stimulus.
uvm_post_main_phaseAfter enough of the primary test stimulus.
uvm_pre_shutdown_phaseBefore things settle down.
uvm_shutdown_phaseLetting things settle down.
uvm_post_shutdown_phaseAfter things have settled down.
User-Defined PhasesTo defined your own custom phase, use the following pattern
Phasing ImplementationThe API described here provides a general purpose testbench phasing solution, consisting of a phaser machine, traversing a master schedule graph, which is built by the integrator from one or more instances of template schedules provided by UVM or by 3rd-party VIP, and which supports implicit or explicit synchronization, runtime control of threads and jumps.
uvm_phaseThis base class defines everything about a phase: behavior, state, and context
uvm_domainPhasing schedule node representing an independent branch of the schedule.
uvm_bottomup_phaseVirtual base class for function phases that operate bottom-up.
uvm_topdown_phaseVirtual base class for function phases that operate top-down.
uvm_task_phaseBase class for all task phases.

Pre-Defined Phases

This section describes the set of pre-defined phases provided as a standard part of the UVM library.

Summary
Pre-Defined Phases
This section describes the set of pre-defined phases provided as a standard part of the UVM library.
Common PhasesThe common phases are the set of function and task phases that all uvm_components execute together.

Common Phases

The common phases are the set of function and task phases that all uvm_components execute together.  All uvm_components are always synchronized with respect to the common phases.

The common phases are executed in the sequence they are specified below.

uvm_build_phase

Create and configure of testbench structure

uvm_topdown_phase that calls the uvm_component::build_phase method.

Upon entry

  • The top-level components have been instantiated under uvm_root.
  • Current simulation time is still equal to 0 but some “delta cycles” may have occurred

Typical Uses

  • Instantiate sub-components.
  • Instantiate register model.
  • Get configuration values for the component being built.
  • Set configuration values for sub-components.

Exit Criteria

Summary
uvm_build_phase
Create and configure of testbench structure

uvm_connect_phase

Establish cross-component connections.

uvm_bottomup_phase that calls the uvm_component::connect_phase method.

Upon Entry

  • All components have been instantiated.
  • Current simulation time is still equal to 0 but some “delta cycles” may have occurred.

Typical Uses

  • Connect TLM ports and exports.
  • Connect TLM initiator sockets and target sockets.
  • Connect register model to adapter components.
  • Setup explicit phase domains.

Exit Criteria

  • All cross-component connections have been established.
  • All independent phase domains are set.
Summary
uvm_connect_phase
Establish cross-component connections.

uvm_end_of_elaboration_phase

Fine-tune the testbench.

uvm_bottomup_phase that calls the uvm_component::end_of_elaboration_phase method.

Upon Entry

  • The verification environment has been completely assembled.
  • Current simulation time is still equal to 0 but some “delta cycles” may have occurred.

Typical Uses

  • Display environment topology.
  • Open files.
  • Define additional configuration settings for components.

Exit Criteria

  • None.
Summary
uvm_end_of_elaboration_phase
Fine-tune the testbench.

uvm_start_of_simulation_phase

Get ready for DUT to be simulated.

uvm_bottomup_phase that calls the uvm_component::start_of_simulation_phase method.

Upon Entry

  • Other simulation engines, debuggers, hardware assisted platforms and all other run-time tools have been started and synchronized.
  • The verification environment has been completely configured and is ready to start.
  • Current simulation time is still equal to 0 but some “delta cycles” may have occurred.

Typical Uses

  • Display environment topology
  • Set debugger breakpoint
  • Set initial run-time configuration values.

Exit Criteria

  • None.
Summary
uvm_start_of_simulation_phase
Get ready for DUT to be simulated.

uvm_run_phase

Stimulate the DUT.

This uvm_task_phase calls the uvm_component::run_phase virtual method.  This phase runs in parallel to the runtime phases, <uvm_pre_reset_ph> through <uvm_post_shutdown_ph>.  All components in the testbench are synchronized with respect to the run phase regardles of the phase domain they belong to.

Upon Entry

  • Indicates that power has been applied.
  • There should not have been any active clock edges before entry into this phase (e.g. x->1 transitions via initial blocks).
  • Current simulation time is still equal to 0 but some “delta cycles” may have occurred.

Typical Uses

  • Components implement behavior that is exhibited for the entire run-time, across the various run-time phases.
  • Backward compatibility with OVM.

Exit Criteria

  • The DUT no longer needs to be simulated, and
  • The <uvm_post_shutdown_ph> is ready to end

The run phase terminates in one of four ways.

1.  Explicit call to <global_stop_request>

When <global_stop_request> is called, an ordered shut-down for the run phase begins.  First, all enabled components’ <uvm_component::stop> tasks are called bottom-up, i.e., childrens’ <uvm_component::stop> tasks are called before the parent’s.

Stopping a component is enabled by its uvm_component::enable_stop_interrupt bit.  Each component can implement <uvm_component::stop> to allow completion of in-progress transactions, flush queues, and other shut-down activities.  Upon return from <uvm_component::stop> by all enabled components, the run phase becomes ready to end pending completion of the runtime phases (i.e. the <uvm_post_shutdown_ph> being ready to end.

If any component raised a phase objection in uvm_component::run_phase(), this stopping procedure is deferred until all outstanding objections have been dropped.

2.  All run phase objections have been dropped after having been raised

When all objections on the run phase objection have been dropped by the uvm_component::run_phase() methods, <global_stop_request> is called automatically, thus kicking off the stopping procedure described above.

If no component ever raises a phase objection, this termination mechanism never happens.

3.  Explicit call to uvm_component::kill or uvm_component::do_kill_all

When uvm_component::kill is called, that component’s uvm_component::run_phase processes are killed immediately.  The uvm_component::do_kill_all methods applies to the component and all its descendants.

Use of this method is not recommended.  It is better to use the stopping mechanism, which affords a more ordered, safer shut-down.  If an immediate termination is desired, a <uvm_component::jump> to the <uvm_extract_ph> phase is recommended as this will cause both the run phase and the parallel runtime phases to immediately end and go to extract.

4.  Timeout

The phase ends if the timeout expires before an explicit call to <global_stop_request> or uvm_component::kill.  By default, the timeout is set to 0, which is no timeout.  You may override this via <set_global_timeout>.

If a timeout occurs in your simulation, or if simulation never ends despite completion of your test stimulus, then it usually indicates a missing call to <global_stop_request>.

Summary
uvm_run_phase
Stimulate the DUT.

uvm_extract_phase

Extract data from different points of the verficiation environment.

uvm_bottomup_phase that calls the uvm_component::extract_phase method.

Upon Entry

  • The DUT no longer needs to be simulated.
  • Simulation time will no longer advance.

Typical Uses

  • Extract any remaining data and final state information from scoreboard and testbench components
  • Probe the DUT (via zero-time hierarchical references and/or backdoor accesses) for final state information.
  • Compute statistics and summaries.
  • Display final state information
  • Close files.

Exit Criteria

  • All data has been collected and summarized.
Summary
uvm_extract_phase
Extract data from different points of the verficiation environment.

uvm_check_phase

Check for any unexpected conditions in the verification environment.

uvm_bottomup_phase that calls the uvm_component::check_phase method.

Upon Entry

  • All data has been collected.

Typical Uses

  • Check that no unaccounted-for data remain.

Exit Criteria

  • Test is known to have passed or failed.
Summary
uvm_check_phase
Check for any unexpected conditions in the verification environment.

uvm_report_phase

Report results of the test.

uvm_bottomup_phase that calls the uvm_component::report_phase method.

Upon Entry

  • Test is known to have passed or failed.

Typical Uses

  • Report test results.
  • Write results to file.

Exit Criteria

  • End of test.
Summary
uvm_report_phase
Report results of the test.

uvm_final_phase

Tie up loose ends.

uvm_topdown_phase that calls the uvm_component::final_phase method.

Upon Entry

  • All test-related activity has completed.

Typical Uses

  • Close files.
  • Terminate co-simulation engines.

Exit Criteria

  • Ready to exit simulator.
Summary
uvm_final_phase
Tie up loose ends.
Run-Time PhasesThe run-time schedule is the pre-defined phase schedule which runs concurrently to the <uvm_run_ph> global run phase.

Run-Time Phases

The run-time schedule is the pre-defined phase schedule which runs concurrently to the <uvm_run_ph> global run phase.  By default, all uvm_components using the run-time schedule are synchronized with respect to the pre-defined phases in the schedule.  It is possible for components to belong to different domains in which case their schedules can be unsynchronized.

uvm_pre_reset_phase

Before reset is asserted.

uvm_task_phase that calls the uvm_component::pre_reset_phase method.  This phase starts at the same time as the <uvm_run_ph> unless a user defined phase is inserted in front of this phase.

Upon Entry

  • Indicates that power has been applied but not necessarily valid or stable.
  • There should not have been any active clock edges before entry into this phase.

Typical Uses

  • Wait for power good.
  • Components connected to virtual interfaces should initialize their output to X’s or Z’s.
  • Initialize the clock signals to a valid value
  • Assign reset signals to X (power-on reset).
  • Wait for reset signal to be asserted if not driven by the verification environment.

Exit Criteria

  • Reset signal, if driven by the verification environment, is ready to be asserted.
  • Reset signal, if not driven by the verification environment, is asserted.
Summary
uvm_pre_reset_phase
Before reset is asserted.

uvm_reset_phase

Reset is asserted.

uvm_task_phase that calls the uvm_component::reset_phase method.

Upon Entry

  • Indicates that the hardware reset signal is ready to be asserted.

Typical Uses

  • Assert reset signals.
  • Components connected to virtual interfaces should drive their output to their specified reset or idle value.
  • Components and environments should initialize their state variables.
  • Clock generators start generating active edges.
  • De-assert the reset signal(s) just before exit.
  • Wait for the reset signal(s) to be de-asserted.

Exit Criteria

  • Reset signal has just been de-asserted.
  • Main or base clock is working and stable.
  • At least one active clock edge has occurred.
  • Output signals and state variables have been initialized.
Summary
uvm_reset_phase
Reset is asserted.

uvm_post_reset_phase

After reset is de-asserted.

uvm_task_phase that calls the uvm_component::post_reset_phase method.

Upon Entry

  • Indicates that the DUT reset signal has been de-asserted.

Typical Uses

  • Components should start behavior appropriate for reset being inactive.  For example, components may start to transmit idle transactions or interface training and rate negotiation.  This behavior typically continues beyond the end of this phase.

Exit Criteria

  • The testbench and the DUT are in a known, active state.
Summary
uvm_post_reset_phase
After reset is de-asserted.

uvm_pre_configure_phase

Before the DUT is configured by the SW.

uvm_task_phase that calls the uvm_component::pre_configure_phase method.

Upon Entry

  • Indicates that the DUT has been completed reset and is ready to be configured.

Typical Uses

  • Procedurally modify the DUT configuration information as described in the environment (and that will be eventually uploaded into the DUT).
  • Wait for components required for DUT configuration to complete training and rate negotiation.

Exit Criteria

  • DUT configuration information is defined.
Summary
uvm_pre_configure_phase
Before the DUT is configured by the SW.

uvm_configure_phase

The SW configures the DUT.

uvm_task_phase that calls the uvm_component::configure_phase method.

Upon Entry

  • Indicates that the DUT is ready to be configured.

Typical Uses

  • Components required for DUT configuration execute transactions normally.
  • Set signals and program the DUT and memories (e.g. read/write operations and sequences) to match the desired configuration for the test and environment.

Exit Criteria

  • The DUT has been configured and is ready to operate normally.
Summary
uvm_configure_phase
The SW configures the DUT.

uvm_post_configure_phase

After the SW has configured the DUT.

uvm_task_phase that calls the uvm_component::post_configure_phase method.

Upon Entry

  • Indicates that the configuration information has been fully uploaded.

Typical Uses

  • Wait for configuration information to fully propagate and take effect.
  • Wait for components to complete training and rate negotiation.
  • Enable the DUT.
  • Sample DUT configuration coverage.

Exit Criteria

  • The DUT has been fully configured and enabled and is ready to start operating normally.
Summary
uvm_post_configure_phase
After the SW has configured the DUT.

uvm_pre_main_phase

Before the primary test stimulus starts.

uvm_task_phase that calls the uvm_component::pre_main_phase method.

Upon Entry

  • Indicates that the DUT has been fully configured.

Typical Uses

  • Wait for components to complete training and rate negotiation.

Exit Criteria

  • All components have completed training and rate negotiation.
  • All components are ready to generate and/or observe normal stimulus.
Summary
uvm_pre_main_phase
Before the primary test stimulus starts.

uvm_main_phase

Primary test stimulus.

uvm_task_phase that calls the uvm_component::main_phase method.

Upon Entry

  • The stimulus associated with the test objectives is ready to be applied.

Typical Uses

  • Components execute transactions normally.
  • Data stimulus sequences are started.
  • Wait for a time-out or certain amount of time, or completion of stimulus sequences.

Exit Criteria

  • Enough stimulus has been applied to meet the primary stimulus objective of the test.
Summary
uvm_main_phase
Primary test stimulus.

uvm_post_main_phase

After enough of the primary test stimulus.

uvm_task_phase that calls the uvm_component::post_main_phase method.

Upon Entry

  • The primary stimulus objective of the test has been met.

Typical Uses

  • Included for symmetry.

Exit Criteria

  • None.
Summary
uvm_post_main_phase
After enough of the primary test stimulus.

uvm_pre_shutdown_phase

Before things settle down.

uvm_task_phase that calls the uvm_component::pre_shutdown_phase method.

Upon Entry

  • None.

Typical Uses

  • Included for symmetry.

Exit Criteria

  • None.
Summary
uvm_pre_shutdown_phase
Before things settle down.

uvm_shutdown_phase

Letting things settle down.

uvm_task_phase that calls the uvm_component::shutdown_phase method.

Upon Entry

  • None.

Typical Uses

  • Wait for all data to be drained out of the DUT.
  • Extract data still buffered in the DUT, usually through read/write operations or sequences.

Exit Criteria

  • All data has been drained or extracted from the DUT.
  • All interfaces are idle.
Summary
uvm_shutdown_phase
Letting things settle down.

uvm_post_shutdown_phase

After things have settled down.

uvm_task_phase that calls the uvm_component::post_shutdown_phase method.  The end of this phase is synchronized to the end of the <uvm_run_ph> phase unless a user defined phase is added after this phase.

Upon Entry

  • No more “data” stimulus is applied to the DUT.

Typical Uses

  • Perform final checks that require run-time access to the DUT (e.g. read accounting registers or dump the content of memories).

Exit Criteria

  • All run-time checks have been satisfied.
  • The <uvm_run_ph> phase is ready to end.
Summary
uvm_post_shutdown_phase
After things have settled down.

User-Defined Phases

To defined your own custom phase, use the following pattern

1. extend the appropriate base class for your phase type

class my_PHASE_phase extends uvm_task_phase("PHASE");
class my_PHASE_phase extends uvm_topdown_phase("PHASE");
class my_PHASE_phase extends uvm_bottomup_phase("PHASE");

2. implement your exec_task or exec_func method

task exec_task(uvm_component comp, uvm_phase schedule);
function void exec_func(uvm_component comp, uvm_phase schedule);

3. the implementation usually calls the related method on the component

comp.PHASE_phase(uvm_phase phase);

4. after declaring your phase singleton class, instantiate one for global use

static my_``PHASE``_phase my_``PHASE``_ph = new();

5. insert the phase in a phase schedule or domain using the uvm_phase::add method inside your VIP base class’s definition of the <uvm_phase::define_domain> method.

Summary
User-Defined Phases
To defined your own custom phase, use the following pattern

Phasing Implementation

The API described here provides a general purpose testbench phasing solution, consisting of a phaser machine, traversing a master schedule graph, which is built by the integrator from one or more instances of template schedules provided by UVM or by 3rd-party VIP, and which supports implicit or explicit synchronization, runtime control of threads and jumps.

Each schedule leaf node refers to a single phase that is compatible with that VIP’s components and which executes the required behavior via a functor or delegate extending the phase into component context as required.  Execution threads are tracked on a per-component basis and various thread semantics available to allow defined phase control and responsibility.

Class hierarchy

A single class represents both the definition, the state, and the context of a phase.  It is instantiated once as a singleton IMP and one or more times as nodes in a graph which represents serial and parallel phase relationships and stores current state as the phaser progresses, and the phase implementation which specifies required component behavior (by extension into component context if non-default behavior required.)

The following classes related to phasing are defined herein

uvm_phase : The base class for defining a phase’s behavior, state, context

uvm_bottomup_phase : A phase implemenation for bottom up function phases.

uvm_topdown_phase : A phase implemenation for topdown function phases.

uvm_task_phase : A phase implemenation for task phases.

Summary
Phasing Implementation
The API described here provides a general purpose testbench phasing solution, consisting of a phaser machine, traversing a master schedule graph, which is built by the integrator from one or more instances of template schedules provided by UVM or by 3rd-party VIP, and which supports implicit or explicit synchronization, runtime control of threads and jumps.

uvm_phase

This base class defines everything about a phase: behavior, state, and context

To define behavior, it is extended by UVM or the user to create singleton objects which capture the definition of what the phase does and how it does it.  These are then cloned to produce multiple nodes which are hooked up in a graph structure to provide context: which phases follow which, and to hold the state of the phase throughout its lifetime.  UVM provides default extensions of this class for the standard runtime phases.  VIP Providers can likewise extend this class to define the phase functor for a particular component context as required.

Phase Definition

Singleton instances of those extensions are provided as package variables.  These instances define the attributes of the phase (not what state it is in) They are then cloned into schedule nodes which point back to one of these implementations, and calls it’s virtual task or function methods on each participating component.  It is the base class for phase functors, for both predefined and user-defined phases.  Per-component overrides can use a customized imp.

To create custom phases, do not extend uvm_phase directly: see the three predefined extended classes below which encapsulate behavior for different phase types: task, bottom-up function and top-down function.

Extend the appropriate one of these to create a uvm_YOURNAME_phase class (or YOURPREFIX_NAME_phase class) for each phase, containing the default implementation of the new phase, which must be a uvm_component-compatible delegate, and which may be a null implementation.  Instantiate a singleton instance of that class for your code to use when a phase handle is required.  If your custom phase depends on methods that are not in uvm_component, but are within an extended class, then extend the base YOURPREFIX_NAME_phase class with parameterized component class context as required, to create a specialized functor which calls your extended component class methods.  This scheme ensures compile-safety for your extended component classes while providing homogeneous base types for APIs and underlying data structures.

Phase Context

A schedule is a coherent group of one or mode phase/state nodes linked together by a graph structure, allowing arbitrary linear/parallel relationships to be specified, and executed by stepping through them in the graph order.  Each schedule node points to a phase and holds the execution state of that phase, and has optional links to other nodes for synchronization.

The main build operations are: construct, add phases, and instantiate hierarchically within another schedule.

Structure is a DAG (Directed Acyclic Graph).  Each instance is a node connected to others to form the graph.  Hierarchy is overlaid with m_parent.  Each node in the graph has zero or more successors, and zero or more predecessors.  No nodes are completely isolated from others.  Exactly one node has zero predecessors.  This is the root node.  Also the graph is acyclic, meaning for all nodes in the graph, by following the forward arrows you will never end up back where you started but you will eventually reach a node that has no successors.

Phase State

A given phase may appear multiple times in the complete phase graph, due to the multiple independent domain feature, and the ability for different VIP to customize their own phase schedules perhaps reusing existing phases.  Each node instance in the graph maintains its own state of execution.

Phase Handle

Handles of this type uvm_phase are used frequently in the API, both by the user, to access phasing-specific API, and also as a parameter to some APIs.  In many cases, the singleton package-global phase handles can be used (eg. connect_ph, run_ph) in APIs.  For those APIs that need to look up that phase in the graph, this is done automatically.

Summary
uvm_phase
This base class defines everything about a phase: behavior, state, and context
Class Hierarchy
uvm_phase
Class Declaration
class uvm_phase extends uvm_object
Construction
newCreate a new phase node, with a name and a note of its type name - name of this phase type - task, topdown func or bottomup func
get_phase_typeReturns the phase type as defined by uvm_phase_type
State
get_stateAccessor to return current state of this phase
get_run_countAccessor to return the integer number of times this phase has executed
find_by_nameLocate a phase node with the specified name and return its handle.
findLocate the phase node with the specified phase IMP and return its handle.
isreturns 1 if the containing uvm_phase refers to the same phase as the phase argument, 0 otherwise
is_beforeReturns 1 if the containing uvm_phase refers to a phase that is earlier than the phase argument, 0 otherwise
is_afterreturns 1 if the containing uvm_phase refers to a phase that is later than the phase argument, 0 otherwise
Callbacks
exec_funcImplements the functor/delegate functionality for a function phase type comp - the component to execute the functionality upon phase - the phase schedule that originated this phase call
exec_taskImplements the functor/delegate functionality for a task phase type comp - the component to execute the functionality upon phase - the phase schedule that originated this phase call
Schedule
addBuild up a schedule structure inserting phase by phase, specifying linkage
get_parentReturns the parent schedule node, if any, for hierarchical graph traversal
get_full_nameReturns the full path from the enclosing domain down to this node.
get_scheduleReturns the topmost parent schedule node, if any, for hierarchical graph traversal
get_schedule_nameReturns the schedule name associated with this phase node
get_domainReturns the enclosing domain
get_impReturns the phase implementation for this this node.
get_domain_nameReturns the domain name associated with this phase node
Synchronization
get_objectionReturn the uvm_objection that gates the termination of the phase.
raise_objectionRaise an objection to ending this phase Provides components with greater control over the phase flow for processes which are not implicit objectors to the phase.
drop_objectionDrop an objection to ending this phase
sync and unsyncAdd soft sync relationships between nodes
syncSynchronize two domains, fully or partially
unsyncRemove synchronization between two domains, fully or partially
wait_for_stateWait until this phase compares with the given state and op operand.
Jumping
jumpJump to a specified phase.
jump_allMake all schedules jump to a specified phase, even if the jump target is local.
get_jump_targetReturn handle to the target phase of the current jump, or null if no jump is in progress.

new

function new( string  name  =  "uvm_phase",
uvm_phase_type  phase_type  =  UVM_PHASE_SCHEDULE,
uvm_phase  parent  =  null )

Create a new phase node, with a name and a note of its type name - name of this phase type - task, topdown func or bottomup func

get_phase_type

function uvm_phase_type get_phase_type()

Returns the phase type as defined by uvm_phase_type

get_state

function uvm_phase_state get_state()

Accessor to return current state of this phase

get_run_count

function int get_run_count()

Accessor to return the integer number of times this phase has executed

find_by_name

function uvm_phase find_by_name( string  name,   
bit  stay_in_scope  =  1 )

Locate a phase node with the specified name and return its handle.  With stay_in_scope set, searches only within this phase’s schedule or domain.

find

function uvm_phase find( uvm_phase  phase,   
bit  stay_in_scope  =  1 )

Locate the phase node with the specified phase IMP and return its handle.  With stay_in_scope set, searches only within this phase’s schedule or domain.

is

function bit is( uvm_phase  phase )

returns 1 if the containing uvm_phase refers to the same phase as the phase argument, 0 otherwise

is_before

function bit is_before( uvm_phase  phase )

Returns 1 if the containing uvm_phase refers to a phase that is earlier than the phase argument, 0 otherwise

is_after

function bit is_after( uvm_phase  phase )

returns 1 if the containing uvm_phase refers to a phase that is later than the phase argument, 0 otherwise

exec_func

virtual function void exec_func( uvm_component  comp,
uvm_phase  phase )

Implements the functor/delegate functionality for a function phase type comp - the component to execute the functionality upon phase - the phase schedule that originated this phase call

exec_task

virtual task exec_task( uvm_component  comp,
uvm_phase  phase )

Implements the functor/delegate functionality for a task phase type comp - the component to execute the functionality upon phase - the phase schedule that originated this phase call

add

function void add( uvm_phase  phase,   
uvm_phase  with_phase  =  null,
uvm_phase  after_phase  =  null,
uvm_phase  before_phase  =  null )

Build up a schedule structure inserting phase by phase, specifying linkage

Phases can be added anywhere, in series or parallel with existing nodes

phasehandle of singleton derived imp containing actual functor. by default the new phase is appended to the schedule
with_phasespecify to add the new phase in parallel with this one
after_phasespecify to add the new phase as successor to this one
before_phasespecify to add the new phase as predecessor to this one

get_parent

function uvm_phase get_parent()

Returns the parent schedule node, if any, for hierarchical graph traversal

get_full_name

virtual function string get_full_name()

Returns the full path from the enclosing domain down to this node.  The singleton IMP phases have no hierarchy.

get_schedule

function uvm_phase get_schedule( bit  hier  =  )

Returns the topmost parent schedule node, if any, for hierarchical graph traversal

get_schedule_name

function string get_schedule_name( bit  hier  =  )

Returns the schedule name associated with this phase node

get_domain

function uvm_domain get_domain()

Returns the enclosing domain

get_imp

function uvm_phase get_imp()

Returns the phase implementation for this this node.  Returns null if this phase type is not a UVM_PHASE_LEAF_NODE.

get_domain_name

function string get_domain_name()

Returns the domain name associated with this phase node

get_objection

function uvm_objection get_objection()

Return the uvm_objection that gates the termination of the phase.

raise_objection

virtual function void raise_objection ( uvm_object  obj,   
string  description  =  "",
int  count  =  1 )

Raise an objection to ending this phase Provides components with greater control over the phase flow for processes which are not implicit objectors to the phase.

while(1) begin
  some_phase.raise_objection(this);
  ...
  some_phase.drop_objection(this);
end
...

drop_objection

virtual function void drop_objection ( uvm_object  obj,   
string  description  =  "",
int  count  =  1 )

Drop an objection to ending this phase

The drop is expected to be matched with an earlier raise.

sync and unsync

Add soft sync relationships between nodes

Summary of usage

target::sync(.source(domain)
             [,.phase(phase)[,.with_phase(phase)]]);
target::unsync(.source(domain)
               [,.phase(phase)[,.with_phase(phase)]]);

Components in different schedule domains can be phased independently or in sync with each other.  An API is provided to specify synchronization rules between any two domains.  Synchronization can be done at any of three levels:

  • the domain’s whole phase schedule can be synchronized
  • a phase can be specified, to sync that phase with a matching counterpart
  • or a more detailed arbitrary synchronization between any two phases

Each kind of synchronization causes the same underlying data structures to be managed.  Like other APIs, we use the parameter dot-notation to set optional parameters.

When a domain is synced with another domain, all of the matching phases in the two domains get a ‘with’ relationship between them.  Likewise, if a domain is unsynched, all of the matching phases that have a ‘with’ relationship have the dependency removed.  It is possible to sync two domains and then just remove a single phase from the dependency relationship by unsyncing just the one phase.

sync

function void sync( uvm_domain  target,   
uvm_phase  phase  =  null,
uvm_phase  with_phase  =  null )

Synchronize two domains, fully or partially

targethandle of target domain to synchronize this one to
phaseoptional single phase in this domain to synchronize, otherwise sync all
with_phaseoptional different target-domain phase to synchronize with, otherwise use phase in the target domain

unsync

function void unsync( uvm_domain  target,   
uvm_phase  phase  =  null,
uvm_phase  with_phase  =  null )

Remove synchronization between two domains, fully or partially

targethandle of target domain to remove synchronization from
phaseoptional single phase in this domain to un-synchronize, otherwise unsync all
with_phaseoptional different target-domain phase to un-synchronize with, otherwise use phase in the target domain

wait_for_state

task wait_for_state( uvm_phase_state  state,   
uvm_wait_op  op  =  UVM_EQ )

Wait until this phase compares with the given state and op operand.  For UVM_EQ and UVM_NE operands, several uvm_phase_states can be supplied by ORing their enum constants, in which case the caller will wait until the phase state is any of (UVM_EQ) or none of (UVM_NE) the provided states.

To wait for the phase to be at the started state or after

wait_for_state(UVM_PHASE_STARTED, UVM_GT);

To wait for the phase to be either started or executing

wait_for_state(UVM_PHASE_STARTED | UVM_PHASE_EXECUTING, UVM_EQ);

jump

function void jump( uvm_phase  phase )

Jump to a specified phase.  If the destination phase is within the current phase schedule, a simple local jump takes place.  If the jump-to phase is outside of the current schedule then the jump affects other schedules which share the phase.

jump_all

static function void jump_all( uvm_phase  phase )

Make all schedules jump to a specified phase, even if the jump target is local.  The jump happens to all phase schedules that contain the jump-to phase, i.e. a global jump.

get_jump_target

function uvm_phase get_jump_target()

Return handle to the target phase of the current jump, or null if no jump is in progress.  Valid for use during the phase_ended() callback

uvm_domain

Phasing schedule node representing an independent branch of the schedule.  Handle used to assign domains to components or hierarchies in the testbench

Summary
uvm_domain
Phasing schedule node representing an independent branch of the schedule.
Class Hierarchy
Class Declaration
class uvm_domain extends uvm_phase
Methods
get_domainsProvies a list of all domains in the provided domains argument.
get_uvm_schedule
get_common_domainGet the “common” domain, which consists of the common phases that all components execute in sync with each other.
add_uvm_phasesAppends to the given schedule the built-in UVM phases.
get_uvm_domainGet a handle to the singleton uvm domain
newCreate a new instance of a phase domain.

get_domains

static function void get_domains( output  uvm_domain  domains[string] )

Provies a list of all domains in the provided domains argument.

get_uvm_schedule

static function uvm_phase get_uvm_schedule()

get_common_domain

static function uvm_domain get_common_domain()

Get the “common” domain, which consists of the common phases that all components execute in sync with each other.  Phases in the “common” domain are build, connect, end_of_elaboration, start_of_simulation, run, extract, check, report, and final.

add_uvm_phases

static function void add_uvm_phases( uvm_phase  schedule )

Appends to the given schedule the built-in UVM phases.

get_uvm_domain

static function uvm_domain get_uvm_domain()

Get a handle to the singleton uvm domain

new

function new( string  name )

Create a new instance of a phase domain.

uvm_bottomup_phase

Virtual base class for function phases that operate bottom-up.  The pure virtual function execute() is called for each component.  This is the default traversal so is included only for naming.

A bottom-up function phase completes when the execute() method has been called and returned on all applicable components in the hierarchy.

Summary
uvm_bottomup_phase
Virtual base class for function phases that operate bottom-up.
Class Hierarchy
uvm_bottomup_phase
Class Declaration
virtual class uvm_bottomup_phase extends uvm_phase
Methods
newCreate a new instance of a bottom-up phase.
traverseTraverses the component tree in bottom-up order, calling execute for each component.
executeExecutes the bottom-up phase phase for the component comp.

new

function new( string  name )

Create a new instance of a bottom-up phase.

traverse

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.

execute

protected virtual function void execute( uvm_component  comp,
uvm_phase  phase )

Executes the bottom-up phase phase for the component comp.

uvm_topdown_phase

Virtual base class for function phases that operate top-down.  The pure virtual function execute() is called for each component.

A top-down function phase completes when the execute() method has been called and returned on all applicable components in the hierarchy.

Summary
uvm_topdown_phase
Virtual base class for function phases that operate top-down.
Class Hierarchy
uvm_topdown_phase
Class Declaration
virtual class uvm_topdown_phase extends uvm_phase
Methods
newCreate a new instance of a top-down phase
traverseTraverses the component tree in top-down order, calling execute for each component.
executeExecutes the top-down phase phase for the component comp.

new

function new( string  name )

Create a new instance of a top-down phase

traverse

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

Traverses the component tree in top-down order, calling execute for each component.

execute

protected virtual function void execute( uvm_component  comp,
uvm_phase  phase )

Executes the top-down phase phase for the component comp.

uvm_task_phase

Base class for all task phases.  It forks a call to uvm_phase::exec_task() for each component in the hierarchy.

A task phase completes when there are no raised objections to the end of phase.  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.

The only 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
Summary
uvm_task_phase
Base class for all task phases.
Class Hierarchy
uvm_task_phase
Class Declaration
virtual class uvm_task_phase extends uvm_phase
Methods
newCreate a new instance of a task-based phase
traverseTraverses the component tree in bottom-up order, calling execute for each component.
executeFork the task-based phase phase for the component comp.

new

function new( string  name )

Create a new instance of a task-based phase

traverse

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.

execute

protected virtual function void execute( uvm_component  comp,
uvm_phase  phase )

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

class uvm_phase extends uvm_object
This base class defines everything about a phase: behavior, state, and context
class uvm_domain extends uvm_phase
Phasing schedule node representing an independent branch of the schedule.
virtual class uvm_bottomup_phase extends uvm_phase
Virtual base class for function phases that operate bottom-up.
virtual class uvm_topdown_phase extends uvm_phase
Virtual base class for function phases that operate top-down.
virtual class uvm_task_phase extends uvm_phase
Base class for all task phases.
virtual class uvm_component extends uvm_report_object
The uvm_component class is the root base class for UVM components.
virtual function void build_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_build_phase phase implementation method.
The uvm_root class serves as the implicit top-level and phase controller for all UVM components.
virtual function void connect_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_connect_phase phase implementation method.
virtual function void end_of_elaboration_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_end_of_elaboration_phase phase implementation method.
virtual function void start_of_simulation_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_start_of_simulation_phase phase implementation method.
virtual task run_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_run_phase phase implementation method.
int enable_stop_interrupt = 0
This bit allows a component to raise an objection to the stopping of the current phase.
virtual function void kill ()
Kills the process tree associated with this component’s currently running task-based phase, e.g., run.
virtual function void do_kill_all ()
Recursively calls kill on this component and all its descendants, which abruptly ends the currently running task-based phase, e.g., run.
virtual function void extract_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_extract_phase phase implementation method.
virtual function void check_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_check_phase phase implementation method.
virtual function void report_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_report_phase phase implementation method.
virtual function void final_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_final_phase phase implementation method.
virtual task pre_reset_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_pre_reset_phase phase implementation method.
virtual task reset_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_reset_phase phase implementation method.
virtual task post_reset_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_post_reset_phase phase implementation method.
virtual task pre_configure_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_pre_configure_phase phase implementation method.
virtual task configure_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_configure_phase phase implementation method.
virtual task post_configure_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_post_configure_phase phase implementation method.
virtual task pre_main_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_pre_main_phase phase implementation method.
virtual task main_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_main_phase phase implementation method.
virtual task post_main_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_post_main_phase phase implementation method.
virtual task pre_shutdown_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_pre_shutdown_phase phase implementation method.
virtual task shutdown_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_shutdown_phase phase implementation method.
virtual task post_shutdown_phase( uvm_phase  phase )
The Pre-Defined Phases::uvm_post_shutdown_phase phase implementation method.
function void add( uvm_phase  phase,   
uvm_phase  with_phase  =  null,
uvm_phase  after_phase  =  null,
uvm_phase  before_phase  =  null )
Build up a schedule structure inserting phase by phase, specifying linkage
The uvm_void class is the base class for all UVM classes.
virtual class uvm_object extends uvm_void
The uvm_object class is the base class for all UVM data and hierarchical classes.
function new( string  name  =  "uvm_phase",
uvm_phase_type  phase_type  =  UVM_PHASE_SCHEDULE,
uvm_phase  parent  =  null )
Create a new phase node, with a name and a note of its type name - name of this phase type - task, topdown func or bottomup func
function uvm_phase_type get_phase_type()
Returns the phase type as defined by uvm_phase_type
This is an attribute of a uvm_phase object which defines the phase type.
function uvm_phase_state get_state()
Accessor to return current state of this phase
function int get_run_count()
Accessor to return the integer number of times this phase has executed
function uvm_phase find_by_name( string  name,   
bit  stay_in_scope  =  1 )
Locate a phase node with the specified name and return its handle.
function uvm_phase find( uvm_phase  phase,   
bit  stay_in_scope  =  1 )
Locate the phase node with the specified phase IMP and return its handle.
function bit is( uvm_phase  phase )
returns 1 if the containing uvm_phase refers to the same phase as the phase argument, 0 otherwise
function bit is_before( uvm_phase  phase )
Returns 1 if the containing uvm_phase refers to a phase that is earlier than the phase argument, 0 otherwise
function bit is_after( uvm_phase  phase )
returns 1 if the containing uvm_phase refers to a phase that is later than the phase argument, 0 otherwise
virtual function void exec_func( uvm_component  comp,
uvm_phase  phase )
Implements the functor/delegate functionality for a function phase type comp - the component to execute the functionality upon phase - the phase schedule that originated this phase call
virtual task exec_task( uvm_component  comp,
uvm_phase  phase )
Implements the functor/delegate functionality for a task phase type comp - the component to execute the functionality upon phase - the phase schedule that originated this phase call
function uvm_phase get_parent()
Returns the parent schedule node, if any, for hierarchical graph traversal
virtual function string get_full_name()
Returns the full path from the enclosing domain down to this node.
function uvm_phase get_schedule( bit  hier  =  )
Returns the topmost parent schedule node, if any, for hierarchical graph traversal
function string get_schedule_name( bit  hier  =  )
Returns the schedule name associated with this phase node
function uvm_domain get_domain()
Returns the enclosing domain
function uvm_phase get_imp()
Returns the phase implementation for this this node.
function string get_domain_name()
Returns the domain name associated with this phase node
function uvm_objection get_objection()
Return the uvm_objection that gates the termination of the phase.
class uvm_objection extends uvm_report_object
Objections provide a facility for coordinating status information between two or more participating components, objects, and even module-based IP.
virtual function void raise_objection ( uvm_object  obj,   
string  description  =  "",
int  count  =  1 )
Raise an objection to ending this phase Provides components with greater control over the phase flow for processes which are not implicit objectors to the phase.
virtual function void drop_objection ( uvm_object  obj,   
string  description  =  "",
int  count  =  1 )
Drop an objection to ending this phase
function void sync( uvm_domain  target,   
uvm_phase  phase  =  null,
uvm_phase  with_phase  =  null )
Synchronize two domains, fully or partially
function void unsync( uvm_domain  target,   
uvm_phase  phase  =  null,
uvm_phase  with_phase  =  null )
Remove synchronization between two domains, fully or partially
task wait_for_state( uvm_phase_state  state,   
uvm_wait_op  op  =  UVM_EQ )
Wait until this phase compares with the given state and op operand.
function void jump( uvm_phase  phase )
Jump to a specified phase.
static function void jump_all( uvm_phase  phase )
Make all schedules jump to a specified phase, even if the jump target is local.
function uvm_phase get_jump_target()
Return handle to the target phase of the current jump, or null if no jump is in progress.
equal
not equal
The set of possible states of a phase.
static function void get_domains( output  uvm_domain  domains[string] )
Provies a list of all domains in the provided domains argument.
static function uvm_phase get_uvm_schedule()
static function uvm_domain get_common_domain()
Get the “common” domain, which consists of the common phases that all components execute in sync with each other.
static function void add_uvm_phases( uvm_phase  schedule )
Appends to the given schedule the built-in UVM phases.
static function uvm_domain get_uvm_domain()
Get a handle to the singleton uvm domain
function new( string  name )
Create a new instance of a phase domain.
function new( string  name )
Create a new instance of a bottom-up phase.
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.
protected virtual function void execute( uvm_component  comp,
uvm_phase  phase )
Executes the bottom-up phase phase for the component comp.
function new( string  name )
Create a new instance of a top-down phase
virtual function void traverse( uvm_component  comp,
uvm_phase  phase,
uvm_phase_state  state )
Traverses the component tree in top-down order, calling execute for each component.
protected virtual function void execute( uvm_component  comp,
uvm_phase  phase )
Executes the top-down phase phase for the component comp.
function new( string  name )
Create a new instance of a task-based phase
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.
protected virtual function void execute( uvm_component  comp,
uvm_phase  phase )
Fork the task-based phase phase for the component comp.