uvm_event in uvm 1.2

[ejo]

The uvm_event has become a generic class in uvm 1.2, and the default data type is uvm_object. Is this just to stay compatible with existing code, or does it also indicate that the data type is supposed to derive from an uvm_object (or at least be a class)?

 

One topic of the posted uvm 1.2 demos shows how a string can be passed through an uvm_event. While this appeared to work perfectly on the demo simulator, is it portable? Is it guaranteed that a plain event.trigger() will produce a valid, empty string at the receiver side?

 

 

Erling

[uwes]

hi,

 

>Is this just to stay compatible with existing code

yes, existing code will continue to work. new code can provide a different parameter type. 

 

>does it also indicate that the data type is supposed to derive from an uvm_object (or at least be a class)?

upper and lower type bounds cannot be expressed in sv (see for instance http://docs.oracle.com/javase/tutorial/java/generics/bounded.html for java type bounds

 

 

as its coded right now 

 

virtual function void trigger (T data=null);

 

the use of the "null" default value assumes that the handle passed is of a class type (otherwise the "null" default value would be illegal). if the parameter is set to a non-class type then the code might not compile if the implicit default value is being used.

 

/uwe

[ejo]

So a class data type will work for sure, but whether or not any other type will work is implementation defined. Is that the correct understanding?

 

 

Erling

[uwes]

hi,

 

in case T is of a non-class type then the code will only work IF ALL invocations of trigger specify an explicit argument value. the implicit default value is not assignment compatible with non-class types. 

 

(there might be an issue in IUS in this area which is currently under investigation)

 

regards

/uwe

[ejo]

There is another annoyance with the new uvm_event definition, and that is warnings for events that are not supposed to carry data. All uvm_event declarations have to be replaced with uvm_event#() to silence the compiler.

 

The warnings could be disabled all together, of course, but this seems to be dangerous in uvm because virtually every type parameter is equipped with a default. Is there a valid reason for this? Consider the uvm_pool: the KEY defaults to int, and T defaults to uvm_void. The int is already overloaded with implicit, unwanted conversions, and uvm_void seems to have been invented to create similar problems for the entire class hierarchy. Not sure what purpose it serves to combine these types implicitly in a map just like that. It seems warnings are best kept enabled.

 

Anyway, I think a better solution would have been to keep the uvm_event as it was, and instead add a representation for generic notifications. In this way, a built-in type or plain old data would not be triggered through an event with undefined behavior, but instead sent and received through a well defined notifier with a mandatory data type to make clear what is to be communicated.

 

 

Erling

[dave_59]

 

There is another annoyance with the new uvm_event definition, and that is warnings for events that are not supposed to carry data. All uvm_event declarations have to be replaced with uvm_event#() to silence the compiler.

 

The warnings could be disabled all together, of course, but this seems to be dangerous in uvm because virtually every type parameter is equipped with a default. Is there a valid reason for this?

 

The ability to require a class/module parameter override, as well as provide macro argument defaults, came with the IEEE 1800-2009 standard. Support for these feature was not widely available at the time the UVM was developed. It possible that many UVM developers are not aware of these features either.

[uwes]

 

 All uvm_event declarations have to be replaced with uvm_event#() to silence the compiler.

 

 

hi,

 

the warning that a param data type is used with a default parameterization is (if at all) kind of a lint check or style recommendation. there is nothing which warrants a warning here IMHO

 

if you got

 

 

class A#(type T=Y); endclass

 

 

then A the following refer to the same type

 

A#(Y) === A#() === A

 

 

Actually the only reason to write A#() comes from a different (quite unknown) angle see 8.25.1 in the 2012lrm. 

 

module test352; 
class A#(type T=int);
   T v0; // current param T
   A::T v1; // current param T -- NOT default T
   A#(T)::T v11;// same as above
   A#(string)::T v2; 
   A#()::T v3;  // T in default specialization
   A#(int)::T v31; // same as above
endclass 
   initial begin
      A#(string) my_a = new();
      $display($sformatf("%p",my_a));      
   end
endmodule // test352

Basically when you use the class scope resolution operator with param classes is the only time A#() might be required.

 

regards

/uwe

[dave_59]

Usually when someone writes A, it's not that they meant A#(), but that they forgot to provide an override  A#(TT).

 

For example

class A#(type T=int);
endclass
class B#(type TT = int) extends A;
endclass

or

class A#(type T=int) extends uvm_object;
`uvm_params_object_utils(A)

In both these cases, the user mistakenly thinks A refers to the generic template class, and their will code will work as long as only the default parameters are in use. But the point of making a class parametrizable is to provide different overrides, and the code will break as soon as that happens. It was a poor language choice to allow A to refer to both to the generic class and the default specialization, depending on usage.