nested uvm_object class in uvm_sequence_item caused sv compiler to fail

[Robert_Liu]

module test;

import uvm_pkg::*;

`include "uvm_macros.svh"

class foo extends uvm_sequence_item;

    class bar extends uvm_object;

        local int a;

        `uvm_object_utils_begin(bar)

            `uvm_field_int(a, UVM_ALL_ON)

        `uvm_object_utils_end

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

    endclass: bar

    `uvm_object_utils(foo)

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

[uwes]

hi,

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_*

 

/uwe

[Robert_Liu]

Maybe the simplest way is to extend class bar from "uvm_report_object". Could uvm_report_object be used directly by users?

[dave_59]

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.

[mastrick]

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.

[tudor.timi]

The philosophy behind nested classes is that they have access to private members of the parent class. If you want to do scoping, you're better off using packages (though it's not possible to define a nice hierarchical structure of packages).