ovm_component

Creates a new component with the given leaf instance name and handle to to its parent.  If the component is a top-level component (i.e. it is created in a static module or interface), parent should be null.

The component will be inserted as a child of the parent object, if any.  If parent already has a child by the given name, an error is produced.

If parent is null, then the component will become a child of the implicit top-level component, ovm_top.

All classes derived from ovm_component must call super.new(name,parent).

Returns a handle to this component’s parent, or null if it has no parent.

Returns the full hierarchical name of this object.  The default implementation concatenates the hierarchical name of the parent, if any, with the leaf name of this object, as given by ovm_object::get_name.

These methods are used to iterate through this component’s children, if any.  For example, given a component with an object handle, comp, the following code calls ovm_object::print for each child:

string name;
ovm_component child;
if (comp.get_first_child(name))
  do begin
    child = comp.get_child(name);
    child.print();
  end while (comp.get_next_child(name));

Returns the number of this component’s children.

Returns 1 if this component has a child with the given name, 0 otherwise.

Renames this component to name and recalculates all descendants’ full names.

Looks for a component with the given hierarchical name relative to this component.  If the given name is preceded with a ‘.’  (dot), then the search begins relative to the top level (absolute lookup).  The handle of the matching component is returned, else null.  The name must not contain wildcards.

The build phase callback is the first of several methods automatically called during the course of simulation.  The build phase is the second of a two-pass construction process (the first is the built-in new method).

The build phase can add additional hierarchy based on configuration information not available at time of initial construction.  Any override should call super.build().

Starting after the initial construction phase (new method) has completed, the build phase consists of calling all components’ build methods recursively top-down, i.e., parents’ build are executed before the children.  This is the only phase that executes top-down.

The build phase of the ovm_component class executes the automatic configuration of fields registed in the component by calling apply_config_settings.  To turn off automatic configuration for a component, do not call super.build() in the subtype’s build method.

See ovm_phase for more information on phases.

The connect phase callback is one of several methods automatically called during the course of simulation.

Starting after the build phase has completed, the connect phase consists of calling all components’ connect methods recursively in depth-first, bottom-up order, i.e., children are executed before their parents.

Generally, derived classes should override this method to make port and export connections via the similarly-named ovm_port_base #(IF)::connect method.  Any override should call super.connect().

This method should never be called directly.

See ovm_phase for more information on phases.

The end_of_elaboration phase callback is one of several methods automatically called during the course of simulation.

Starting after the connect phase has completed, this phase consists of calling all components’ end_of_elaboration methods recursively in depth-first, bottom-up order, i.e., children are executed before their parents.

Generally, derived classes should override this method to perform any checks on the elaborated hierarchy before the simulation phases begin.  Any override should call super.end_of_elaboration().

This method should never be called directly.

See ovm_phase for more information on phases.

The start_of_simulation phase callback is one of several methods automatically called during the course of simulation.

Starting after the end_of_elaboration phase has completed, this phase consists of calling all components’ start_of_simulation methods recursively in depth-first, bottom-up order, i.e. children are executed before their parents.

Generally, derived classes should override this method to perform component- specific pre-run operations, such as discovery of the elaborated hierarchy, printing banners, etc.  Any override should call super.start_of_simulation().

This method should never be called directly.

See ovm_phase for more information on phases.

The run phase callback is the only predefined phase that is time-consuming, i.e., task-based.  It executes after the start_of_simulation phase has completed.  Derived classes should override this method to perform the bulk of its functionality, forking additional processes if needed.

In the run phase, all components’ run tasks are forked as independent processes.  Returning from its run task does not signify completion of a component’s run phase; any processes forked by run continue to run.

The run phase terminates in one of four ways.

If the default 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.

The run task should never be called directly.

See ovm_phase for more information on phases.

The extract phase callback is one of several methods automatically called during the course of simulation.

Starting after the run phase has completed, the extract phase consists of calling all components’ extract methods recursively in depth-first, bottom-up order, i.e., children are executed before their parents.

Generally, derived classes should override this method to collect information for the subsequent check phase when such information needs to be collected in a hierarchical, bottom-up manner.  Any override should call super.extract().

This method should never be called directly.

See ovm_phase for more information on phases.

The check phase callback is one of several methods automatically called during the course of simulation.

Starting after the extract phase has completed, the check phase consists of calling all components’ check methods recursively in depth-first, bottom-up order, i.e., children are executed before their parents.

Generally, derived classes should override this method to perform component specific, end-of-test checks.  Any override should call super.check().

This method should never be called directly.

See ovm_phase for more information on phases.

The report phase callback is the last of several predefined phase methods automatically called during the course of simulation.

Starting after the check phase has completed, the report phase consists of calling all components’ report methods recursively in depth-first, bottom-up order, i.e., children are executed before their parents.

Generally, derived classes should override this method to perform component-specific reporting of test results.  Any override should call super.report().

This method should never be called directly.

See ovm_phase for more information on phases.

Suspends the process tree spawned from this component’s currently executing task-based phase, e.g.  run.

Resumes the process tree spawned from this component’s currently executing task-based phase, e.g.  run.

Returns the status of the parent process associated with the currently running task-based phase, e.g., run.

Kills the process tree associated with this component’s currently running task-based phase, e.g., run.

An alternative mechanism for stopping the run phase is the stop request.  Calling global_stop_request causes all components’ run processes to be killed, but only after all components have had the opportunity to complete in progress transactions and shutdown cleanly via their stop tasks.

Recursively calls kill on this component and all its descendants, which abruptly ends the currently running task-based phase, e.g., run.  See run for better options to ending a task-based phase.

The stop task is called when this component’s enable_stop_interrupt bit is set and global_stop_request is called during a task-based phase, e.g., run.

Before a phase is abruptly ended, e.g., when a test deems the simulation complete, some components may need extra time to shut down cleanly.  Such components may implement stop to finish the currently executing transaction, flush the queue, or perform other cleanup.  Upon return from its stop, a component signals it is ready to be stopped.

The stop method will not be called if enable_stop_interrupt is 0.

The default implementation of stop is empty, i.e., it will return immediately.

This method should never be called directly.

Processes all port, export, and imp connections.  Checks whether each port’s min and max connection requirements are met.

It is called just before the end_of_elaboration phase.

Users should not call directly.

Calling set_config_* causes configuration settings to be created and placed in a table internal to this component.  There are similar global methods that store settings in a global table.  Each setting stores the supplied inst_name, field_name, and value for later use by descendent components during their construction.  (The global table applies to all components and takes precedence over the component tables.)

When a descendant component calls a get_config_* method, the inst_name and field_name provided in the get call are matched against all the configuration settings stored in the global table and then in each component in the parent hierarchy, top-down.  Upon the first match, the value stored in the configuration setting is returned.  Thus, precedence is global, following by the top-level component, and so on down to the descendent component’s parent.

These methods work in conjunction with the get_config_* methods to provide a configuration setting mechanism for integral, string, and ovm_object-based types.  Settings of other types, such as virtual interfaces and arrays, can be indirectly supported by defining a class that contains them.

Both inst_name and field_name may contain wildcards.

• For set_config_int, value is an integral value that can be anything from 1 bit to 4096 bits.
• For set_config_string, value is a string.
• For set_config_object, value must be an ovm_object-based object or null.  Its clone argument specifies whether the object should be cloned.  If set, the object is cloned both going into the table (during the set) and coming out of the table (during the get), so that multiple components matched to the same setting (by way of wildcards) do not end up sharing the same object.

The following message tags are used for configuration setting.  You can use the standard ovm report messaging interface to control these messages.  CFGNTS -- The configuration setting was not used by any component.  This is a warning.  CFGOVR -- The configuration setting was overridden by a setting above.  CFGSET -- The configuration setting was used at least once.

See get_config_int, get_config_string, and get_config_object for information on getting the configurations set by these methods.

These methods retrieve configuration settings made by previous calls to their set_config_* counterparts.  As the methods’ names suggest, there is direct support for integral types, strings, and objects.  Settings of other types can be indirectly supported by defining an object to contain them.

Configuration settings are stored in a global table and in each component instance.  With each call to a get_config_* method, a top-down search is made for a setting that matches this component’s full name and the given field_name.  For example, say this component’s full instance name is top.u1.u2.  First, the global configuration table is searched.  If that fails, then it searches the configuration table in component ‘top’, followed by top.u1.

The first instance/field that matches causes value to be written with the value of the configuration setting and 1 is returned.  If no match is found, then value is unchanged and the 0 returned.

Calling the get_config_object method requires special handling.  Because value is an output of type ovm_object, you must provide an ovm_object handle to assign to (not a derived class handle).  After the call, you can then $cast to the actual type.

For example, the following code illustrates how a component designer might call upon the configuration mechanism to assign its data object property, whose type myobj_t derives from ovm_object.

class mycomponent extends ovm_component;

  local myobj_t data;

  function void build();
    ovm_object tmp;
    super.build();
    if(get_config_object("data", tmp))
      if (!$cast(data, tmp))
        $display("error! config setting for 'data' not of type myobj_t");
      endfunction
    ...

The above example overrides the build method.  If you want to retain any base functionality, you must call super.build().

The clone bit clones the data inbound.  The get_config_object method can also clone the data outbound.

See Members for information on setting the global configuration table.

Check all configuration settings in a components configuration table to determine if the setting has been used, overridden or not used.  When recurse is 1 (default), configuration for this and all child components are recursively checked.  This function is automatically called in the check phase, but can be manually called at any time.

Additional detail is provided by the following message tags

• CFGOVR -- lists all configuration settings that have been overridden from above.
• CFGSET -- lists all configuration settings that have been set.

To get all configuration information prior to the run phase, do something like this in your top object:

function void start_of_simulation();
  set_report_id_action_hier(CFGOVR, OVM_DISPLAY);
  set_report_id_action_hier(CFGSET, OVM_DISPLAY);
  check_config_usage();
endfunction

Searches for all config settings matching this component’s instance path.  For each match, the appropriate set_*_local method is called using the matching config setting’s field_name and value.  Provided the set_*_local method is implemented, the component property associated with the field_name is assigned the given value.

This function is called by ovm_component::build.

The apply_config_settings method determines all the configuration settings targeting this component and calls the appropriate set_*_local method to set each one.  To work, you must override one or more set_*_local methods to accommodate setting of your component’s specific properties.  Any properties registered with the optional `ovm_*_field macros do not require special handling by the set_*_local methods; the macros provide the set_*_local functionality for you.

If you do not want apply_config_settings to be called for a component, then the build() method should be overloaded and you should not call super.build().  If this case, you must also set the m_build_done bit.  Likewise, apply_config_settings can be overloaded to customize automated configuration.

When the verbose bit is set, all overrides are printed as they are applied.  If the component’s print_config_matches property is set, then apply_config_settings is automatically called with verbose = 1.

Called without arguments, print_config_settings prints all configuration information for this component, as set by previous calls to set_config_*.  The settings are printing in the order of their precedence.

If field is specified and non-empty, then only configuration settings matching that field, if any, are printed.  The field may not contain wildcards.

If comp is specified and non-null, then the configuration for that component is printed.

If recurse is set, then configuration information for all comp’s children and below are printed as well.

The raised callback is called when a decendant of the component instance raises the specfied objection.  The source_obj is the object which originally raised the object.  count is an optional count that was used to indicate a number of objections which were raised.

The dropped callback is called when a decendant of the component instance raises the specfied objection.  The source_obj is the object which originally dropped the object.  count is an optional count that was used to indicate a number of objections which were dropped.

The all_dropped callback is called when a decendant of the component instance raises the specfied objection.  The source_obj is the object which originally all_dropped the object.  count is an optional count that was used to indicate a number of objections which were dropped.  This callback is time-consuming and the all_dropped conditional will not be propagated up to the object’s parent until the callback returns.

A convenience function for ovm_factory::create_component_by_name, this method calls upon the factory to create a new child component whose type corresponds to the preregistered type name, requested_type_name, and instance name, name.  This method is equivalent to:

factory.create_component_by_name(requested_type_name,
                                 get_full_name(), name, this);

If the factory determines that a type or instance override exists, the type of the component created may be different than the requested type.  See set_type_override and set_inst_override.  See also ovm_factory for details on factory operation.

A convenience function for ovm_factory::create_object_by_name, this method calls upon the factory to create a new object whose type corresponds to the preregistered type name, requested_type_name, and instance name, name.  This method is equivalent to:

factory.create_object_by_name(requested_type_name,
                              get_full_name(), name);

If the factory determines that a type or instance override exists, the type of the object created may be different than the requested type.  See ovm_factory for details on factory operation.

A convenience function for ovm_factory::set_type_override_by_type, this method registers a factory override for components and objects created at this level of hierarchy or below.  This method is equivalent to:

factory.set_type_override_by_type(original_type, override_type,replace);

The relative_inst_path is relative to this component and may include wildcards.  The original_type represents the type that is being overridden.  In subsequent calls to ovm_factory::create_object_by_type or ovm_factory::create_component_by_type, if the requested_type matches the original_type and the instance paths match, the factory will produce the override_type.

The original and override type arguments are lightweight proxies to the types they represent.  See set_inst_override_by_type for information on usage.

A convenience function for ovm_factory::set_inst_override_by_type, this method registers a factory override for components and objects created at this level of hierarchy or below.  In typical usage, this method is equivalent to:

factory.set_inst_override_by_type({get_full_name(),".",
                                   relative_inst_path},
                                   original_type,
                                   override_type);

The relative_inst_path is relative to this component and may include wildcards.  The original_type represents the type that is being overridden.  In subsequent calls to ovm_factory::create_object_by_type or ovm_factory::create_component_by_type, if the requested_type matches the original_type and the instance paths match, the factory will produce the override_type.

The original and override types are lightweight proxies to the types they represent.  They can be obtained by calling type::get_type(), if implemented, or by directly calling type::type_id::get(), where type is the user type and type_id is the name of the typedef to ovm_object_registry #(T,Tname) or ovm_component_registry #(T,Tname).

If you are employing the `ovm_*_utils macros, the typedef and the get_type method will be implemented for you.

The following example shows `ovm_*_utils usage

class comp extends ovm_component;
  `ovm_component_utils(comp)
  ...
endclass

class mycomp extends ovm_component;
  `ovm_component_utils(mycomp)
  ...
endclass

class block extends ovm_component;
  `ovm_component_utils(block)
  comp c_inst;
  virtual function void build();
    set_inst_override_by_type("c_inst",comp::get_type(),
                                       mycomp::get_type());
  endfunction
  ...
endclass

A convenience function for ovm_factory::set_type_override_by_name, this method configures the factory to create an object of type override_type_name whenever the factory is asked to produce a type represented by original_type_name.  This method is equivalent to:

factory.set_type_override_by_name(original_type_name,
                                  override_type_name, replace);

The original_type_name typically refers to a preregistered type in the factory.  It may, however, be any arbitrary string.  Subsequent calls to create_component or create_object with the same string and matching instance path will produce the type represented by override_type_name.  The override_type_name must refer to a preregistered type in the factory.

A convenience function for ovm_factory::set_inst_override_by_type, this method registers a factory override for components created at this level of hierarchy or below.  In typical usage, this method is equivalent to:

factory.set_inst_override_by_name({get_full_name(),".",
                                   relative_inst_path},
                                    original_type_name,
                                   override_type_name);

The relative_inst_path is relative to this component and may include wildcards.  The original_type_name typically refers to a preregistered type in the factory.  It may, however, be any arbitrary string.  Subsequent calls to create_component or create_object with the same string and matching instance path will produce the type represented by override_type_name.  The override_type_name must refer to a preregistered type in the factory.

This factory debug method performs the same lookup process as create_object and create_component, but instead of creating an object, it prints information about what type of object would be created given the provided arguments.

These methods recursively associate the specified action with reports of the given severity, id, or severity-id pair.  An action associated with a particular severity-id pair takes precedence over an action associated with id, which takes precedence over an an action associated with a severity.

For a list of severities and their default actions, refer to ovm_report_handler.

These methods recursively associate the specified FILE descriptor with reports of the given severity, id, or severity-id pair.  A FILE associated with a particular severity-id pair takes precedence over a FILE associated with id, which take precedence over an a FILE associated with a severity, which takes precedence over the default FILE descriptor.

For a list of severities and other information related to the report mechanism, refer to ovm_report_handler.

This method recursively sets the maximum verbosity level for reports for this component and all those below it.  Any report from this component subtree whose verbosity exceeds this maximum will be ignored.

See ovm_report_handler for a list of predefined message verbosity levels and their meaning.

This function marks the acceptance of a transaction, tr, by this component.  Specifically, it performs the following actions:

• Calls the tr’s ovm_transaction::accept_tr method, passing to it the accept_time argument.
• Calls this component’s do_accept_tr method to allow for any post-begin action in derived classes.
• Triggers the component’s internal accept_tr event.  Any processes waiting on this event will resume in the next delta cycle.

The accept_tr method calls this function to accommodate any user-defined post-accept action.  Implementations should call super.do_accept_tr to ensure correct operation.

This function marks the start of a transaction, tr, by this component.  Specifically, it performs the following actions:

• Calls tr’s ovm_transaction::begin_tr method, passing to it the begin_time argument.  The begin_time should be greater than or equal to the accept time.  By default, when begin_time = 0, the current simulation time is used.

If recording is enabled (recording_detail != OVM_OFF), then a new database-transaction is started on the component’s transaction stream given by the stream argument.  No transaction properties are recorded at this time.

• Calls the component’s do_begin_tr method to allow for any post-begin action in derived classes.
• Triggers the component’s internal begin_tr event.  Any processes waiting on this event will resume in the next delta cycle.

A handle to the transaction is returned.  The meaning of this handle, as well as the interpretation of the arguments stream_name, label, and desc are vendor specific.

This function marks the start of a child transaction, tr, by this component.  Its operation is identical to that of begin_tr, except that an association is made between this transaction and the provided parent transaction.  This association is vendor-specific.

The begin_tr and begin_child_tr methods call this function to accommodate any user-defined post-begin action.  Implementations should call super.do_begin_tr to ensure correct operation.

This function marks the end of a transaction, tr, by this component.  Specifically, it performs the following actions:

• Calls tr’s ovm_transaction::end_tr method, passing to it the end_time argument.  The end_time must at least be greater than the begin time.  By default, when end_time = 0, the current simulation time is used.

The transaction’s properties are recorded to the database-transaction on which it was started, and then the transaction is ended.  Only those properties handled by the transaction’s do_record method (and optional `ovm_*_field macros) are recorded.

• Calls the component’s do_end_tr method to accommodate any post-end action in derived classes.
• Triggers the component’s internal end_tr event.  Any processes waiting on this event will resume in the next delta cycle.

The free_handle bit indicates that this transaction is no longer needed.  The implementation of free_handle is vendor-specific.

The end_tr method calls this function to accommodate any user-defined post-end action.  Implementations should call super.do_end_tr to ensure correct operation.

This function marks an error transaction by a component.  Properties of the given ovm_object, info, as implemented in its <do_record> method, are recorded to the transaction database.

An error_time of 0 indicates to use the current simulation time.  The keep_active bit determines if the handle should remain active.  If 0, then a zero-length error transaction is recorded.  A handle to the database-transaction is returned.

Interpretation of this handle, as well as the strings stream_name, label, and desc, are vendor-specific.

This function marks an event transaction by a component.

An event_time of 0 indicates to use the current simulation time.

A handle to the transaction is returned.  The keep_active bit determines if the handle may be used for other vendor-specific purposes.

The strings for stream_name, label, and desc are vendor-specific identifiers for the transaction.