Correct use of Macros in Questa?

[jgg]

Hi all,

Could someone clarify the expected use of the macros under Questa?

For instance
`ovm_object_utils(xx)

There are quite a few instances in the examples where the macro use is ifdef'd off for Questa, which I suppose is because Questa does not support the nested classes a version of the macro needs... But, the macro has an alternate version (which, IMHO, is cleaner..) that is enabled on Questa that uses a parameterized class to construct the necessary wrapper class.

Are the examples correct and even the parametric class method does not work in Questa - or are they just out of date?

Thanks,
Jason

[stuart]

Here is a general summary and explanation of user-level macros in OVM.

There are two kinds of macros in OVM: one which saves the user the burden of writing repetitive code and the other which allows us to provide multiple vendor solutions for features where the language feature set of the simulators differs.

It is NEVER required that the user use macros when using OVM. They are only there for convenience.

Here is a breakdown of the kinds of macros in OVM:

Field macros (`ovm_*_utils with `ovm_field_*): these macros implement all of the do_* functions for a data item and they implement the factory registration. If you do not use these macros, you must make sure that you register your type with the factory in order to have access to the factory mechanism. Likewise, you must make sure that you implement all of the data related methods.

class mydata extends ovm_object;
int a;
string str;
//implements factory registration and get_type_name() for
//mydata and begins field block
`ovm_object_utils_begin(mydata)
//implements copy, compare, record, print, sprint, pack,
//unpack for fields
`ovm_field_int(a, OVM_DEFAULT)
`ovm_field_string(str, OVM_DEFAULT)
`ovm_object_utils_end
endclass

Note that for the data macros, you may use the macros for some things and implement the do_* functions for other things (for instance, if you want to manually print an object you can set the OVM_NOPRINT flag and then implement the do_print method).

Factory registration macros (`ovm_*_registry): registers either a component type or an object type with the factory. Looks very similar to the ovm_*_registry#() template class, and in fact, expands to an instance of this class for Questa, but expands to a wrapper class for IUS. The longer term path will be to use the registry classes if you’re not a macro fan, but for now, to have the same code run on both Questa and IUS, you’ll need to use the registry macro.

Sequence action macros (`ovm_do*): these macros expand into a set of procedural calls between a sequence and a sequencer. The macros expand to between 2 and 8 lines. The purpose of these macros in this case is that it is not possible to use functions (SystemVerilog does not support templatized functions) and it is tedious for a user to constantly have to use 8 lines of code to do the same thing.

Sequence registration macro (`ovm_update_sequence_lib_and_item): This procedural macro, called in the sequencer’s constructor, updates the sequence library for the specific sequencer where the sequence library is set up using the `ovm_declare_sequence_lib declarative macro. If you use the layered_stimulus package, the sequence registration macro is neither provided nor required.

-Stuart