The following class are used to specify a phase and its implied functionality.
| Phasing Definition classes | The following class are used to specify a phase and its implied functionality. |
| uvm_phase | This base class defines everything about a phase: behavior, state, and context. |
| uvm_phase_state_change | Phase state transition descriptor. |
| uvm_phase_cb | This class defines a callback method that is invoked by the phaser during the execution of a specific node in the phase graph or all phase nodes. |
| uvm_phase_cb_pool | Convenience type for the uvm_callbacks#(uvm_phase, uvm_phase_cb) class. |
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.
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 its 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 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 phase handles can be used (eg. <uvm_run_phase::get()>) in APIs. For those APIs that need to look up that phase in the graph, this is done automatically.
| uvm_phase | ||||
| This base class defines everything about a phase: behavior, state, and context. | ||||
| Class Hierarchy | ||||
| ||||
| Class Declaration | ||||
| ||||
| Construction | ||||
| State | ||||
| Callbacks | ||||
| Schedule | ||||
| Phase Done Objection | Task-based phase nodes within the phasing graph provide a uvm_objection based interface for prolonging the execution of the phase. | |||
| Synchronization | The functions ‘sync’ and ‘unsync’ add soft sync relationships between nodes | |||
| Jumping | ||||
Task-based phase nodes within the phasing graph provide a uvm_objection based interface for prolonging the execution of the phase. All other phase types do not contain an objection, and will report a fatal error if the user attempts to raise, drop, or get_objection_count.
The functions ‘sync’ and ‘unsync’ add soft sync relationships between nodes
my_phase.sync(.target(domain)
[,.phase(phase)[,.with_phase(phase)]]);
my_phase.unsync(.target(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:
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.
Phase state transition descriptor. Used to describe the phase transition that caused a <uvm_phase_cb::phase_state_changed()> callback to be invoked.
| uvm_phase_state_change | ||||
| Phase state transition descriptor. | ||||
| Class Hierarchy | ||||
| ||||
| Class Declaration | ||||
| ||||
This class defines a callback method that is invoked by the phaser during the execution of a specific node in the phase graph or all phase nodes. User-defined callback extensions can be used to integrate data types that are not natively phase-aware with the UVM phasing.
| uvm_phase_cb | |||||
| This class defines a callback method that is invoked by the phaser during the execution of a specific node in the phase graph or all phase nodes. | |||||
| Class Hierarchy | |||||
| |||||
| Class Declaration | |||||
| |||||
Convenience type for the uvm_callbacks#(uvm_phase, uvm_phase_cb) class.
| uvm_phase_cb_pool | |
| Convenience type for the uvm_callbacks#(uvm_phase, uvm_phase_cb) class. |
This base class defines everything about a phase: behavior, state, and context.
class uvm_phase extends uvm_object
Phase state transition descriptor.
class uvm_phase_state_change extends uvm_object
This class defines a callback method that is invoked by the phaser during the execution of a specific node in the phase graph or all phase nodes.
class uvm_phase_cb extends uvm_callback
The uvm_void class is the base class for all UVM classes.
virtual class uvm_void
The uvm_object class is the base class for all UVM data and hierarchical classes.
virtual class uvm_object extends uvm_void
Objections provide a facility for coordinating status information between two or more participating components, objects, and even module-based IP.
class uvm_objection extends uvm_report_object
The uvm_callback class is the base class for user-defined callback classes.
class uvm_callback extends uvm_object