Robert_Liu Posted January 11, 2017 Report Share Posted January 11, 2017 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". Quote Link to comment Share on other sites More sharing options...
uwes Posted January 12, 2017 Report Share Posted January 12, 2017 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 Quote Link to comment Share on other sites More sharing options...
Robert_Liu Posted January 12, 2017 Author Report Share Posted January 12, 2017 Maybe the simplest way is to extend class bar from "uvm_report_object". Could uvm_report_object be used directly by users? Quote Link to comment Share on other sites More sharing options...
dave_59 Posted January 12, 2017 Report Share Posted January 12, 2017 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. Quote Link to comment Share on other sites More sharing options...
mastrick Posted January 12, 2017 Report Share Posted January 12, 2017 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. Quote Link to comment Share on other sites More sharing options...
tudor.timi Posted February 17, 2017 Report Share Posted February 17, 2017 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). ljepson74 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.