Jump to content
Sign in to follow this  

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

Share this post

Link to post
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_*



Share this post

Link to post
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.

Share this post

Link to post
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.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this