Significant concern over objection API changes.

[john_fowler]

Hello all,

There is significant concern over the changes to the uvm_objection::raise_objection and uvm_objection::drop_objection.

A string argument called 'description' was inserted as the second argument. This 'description' is primarily used when the 'trace_mode' is enabled--not all time.

Not only is this a backwards compatibility issue--it allows a silent failure as the simulators will not provide any indication functionality is changing. For instance, in OVM code such as...

| ovm_test_done.raise_objection(this, 2);

Caused 2 objections to be raised. In UVM, the same code (barring "o to u" change) causes one objection to be raised and a description of '2'. There is no warning, error, etc. generated by the simulators cause this is valid SystemVerilog.

I propose that UVM defines the raise/drop_objection APIs with the 'description' argument as the third argument.

John

[uwes]

hi john,

it appears strange to me that

ovm_test_done.raise_objection(this, 2);

is matching the API function signature of

function void raise_objection (uvm_object obj=null, string description="",

int count=1);

the only correct mapping of

ovm_test_done.raise_objection(this, 2);

to uvm would be

uvm_test_done.raise_objection(this,, 2);

the "2" in the second position should never be mapped to a string parameter - also you are only allowed to omit parameters (with defaults) from the end of the args list.

as far as i understand the ovm function signatures should never match the uvm signature and therefore requires a mandatory code change.

regards

/uwe

[john_fowler]

This is not the case for all simulators today. The issue would be completely avoided if the primarily debug argument was be added to the end of the API.

Even if the simulators catch it and force a mandatory code change, why cause the user pain for something such as trace/debug when adding it to the end was an option?

John

[uwes]

hi john,

i'm not sure why the arguments were ordered the way they are now. i agree that the reordering would avoid the mandatory code change, however the use case that the sv compiler accepts an existing argument line and maps it without type checking is a tool issue which has to be fixed in the tool (and not by avoiding it).

regards

/uwe

[john_fowler]

Definitely agree to the tool issue (and addressing that outside these forums).

Regardless, forcing the user to change something that could be avoided (especially for a debug feature) seems against the message of how easy it is to move from OVM to UVM.

John