Jump to content

nested uvm_object class in uvm_sequence_item caused sv compiler to fail

Recommended Posts

module test;

import uvm_pkg::*;

`include "uvm_macros.svh"

class foo extends uvm_sequence_item;

    class bar extends uvm_object;

        local int a;


            `uvm_field_int(a, UVM_ALL_ON)


        function new(string name="bar"); super.new(name); endfunction

    endclass: bar


    function new(string name="foo"); super.new(name); endfunction

endclass: foo

foo::bar foobar_inst = foo::bar::type_id::create("xxx");

initial foobar_inst.print();

endmodule: test

`uvm_field_int reference to the uvm_report_warning which is defined in uvm_sequnce_item and uvm_package. The tool report error that "bar" class reference to non-staic method in class "foo".

Link to comment
Share on other sites


this comes from uvm_report_info/warning which for the uvm_object bar should refer to uvm_pkg::uvm_report_* functions. due to the nested class these refer to foo::uvm_report_* which is illegal. the underlying problem is that the function call uvm_report_* in the macros has been designed to either reference uvm_pkg::uvm_report_* or the functions directly visible in the current type "local"::uvm_report_*. 


a workaround is to add new uvm_report_* functions into bar forwarding the call to uvm_pkg::uvm_report_*



Link to comment
Share on other sites

You could extend your class from uvm_report_object. But this also creates a uvm_report_handler object which has a lot of overhead.

A few other options are

  • Avoid using a nested class. What is it doing for you in this situation? Define the class bar at the same level as foo.
  • Avoid using the `uvm_field macros - also a lot of overhead.
Link to comment
Share on other sites

Strangely enough, we have just encountered this issue for the first time today.  Thanks Robert for posting!

In our case, the nested class does not use the field macros but rather calls uvm_report_info directly.  We use nested class in this case because this class is used as a replacement class in the test, and to allow us to compile all tests in one executable without conflict, we require such classes to be nested within the test class that uses it.

Guess I'll file a mantis to see if the implementation can tolerate such usage.

Link to comment
Share on other sites

  • 1 month later...

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.

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...