Jump to content

Recommended Posts

Does an abstract class (virtual class ....), which extends from uvm_object, benefit from using uvm utility macros (`uvm_component_utils, `uvm_object_utils)?
 
As I understand, `uvm_component_utils and `uvm_object_utils are used to register a class w/ the factory so objects of that class can be overridden.
But, because an abstract class cannot be instantiated, it cannot be overridden.
 
Is that assessment correct?
 
Are those utils macros doing smthg else besides allowing for 'overriding' capability?  (Although I have looked at them, I know I don't fully understand all they're used for.)
 
thanks,
 
 

From uvm_object_defines.svh:

//------------------------------------------------------------------------------
//
// Title: Utility and Field Macros for Components and Objects
//
// Group: Utility Macros 
//
// The ~utils~ macros define the infrastructure needed to enable the
// object/component for correct factory operation. See <`uvm_object_utils> and
// <`uvm_component_utils> for details.
//
// A ~utils~ macro should be used inside ~every~ user-defined class that extends
// <uvm_object> directly or indirectly, including <uvm_sequence_item> and
// <uvm_component>.
//
// Below is an example usage of the ~utils~ macro for a user-defined object.
//
//|  class mydata extends uvm_object;
//| 
//|     `uvm_object_utils(mydata)
//|
//|     // declare data properties

Share this post


Link to post
Share on other sites

hi,

 

few points here:

 

1. uvm_*_utils cannot be used in virtual classes because the macros implement create() which would attempt to create an instance of a virtual class

 

2. you can use an alternative version of the macros (without the create() ) which gives you all the field handling capabilities.

 

3. technically you can also register a virtual class in the factory - all you need to ensure is that there is a concrete override. that use model makes sense in a lot of situations but unfortunately it is not simple to accomplish (http://eda.org/svdb/view.php?id=4789)

 

/uwe

Share this post


Link to post
Share on other sites

Instead of creating virtual classes, you are probably better off using interface classes introduced in SystemVerilog 2012. You can then simply require derived classes to implement the interfaces as needed. Interface classes of course would not use an UVM machinery since all their methods are pure virtual.

Share this post


Link to post
Share on other sites

@David In some cases it actually makes sense to create virtual classes instead of interface classes, because you want to provide some fields and implementations to some of the methods the class to be extended defines.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...