ovm_report... _info or _message?

[bromleyj]

hi all,

We have ovm_report_info() and ovm_report_message(). As far as I can tell, they're identical. Which is preferred?

I get the impression that ovm_report_info is more heavily used within the OVM kit itself, and the name seems to me to be more symmetrical with the other built-in severity levels (warning, error, fatal). But there are plenty of examples of the use of _message instead.

Opinions?

Thanks

[mglasser]

ovm_report_message is for backward compatibility with AVM, ovm_report_info is now preferred.

Avm_report_message prints "MESSAGE" as the leading text, as does ovm_report_message. Ovm_report_info, on the other hand, prints "INFO" as the leading text. Avm_report_message (in the backward compatibility library) calls ovm_report_message. This creates a truly backward compatible routine as the text printed is identical. If we had left out ovm_report_message and instead just wrapped ovm_report_info with avm_report_mesage users would find meaningless and annoying differences with their golden transcripts.

Any remaining uses of ovm_report_message in the OVM library or examples will be cleaned up by replacing with ovm_report_info.

-- Mark

[bromleyj]

ovm_report_message is for backward compatibility with AVM, ovm_report_info is now preferred.



Thanks, that makes good sense.

[gordon]

ovm_report_message is for backward compatibility with AVM, ovm_report_info is now preferred.

Avm_report_message prints "MESSAGE" as the leading text, as does ovm_report_message. Ovm_report_info, on the other hand, prints "INFO" as the leading text. Avm_report_message (in the backward compatibility library) calls ovm_report_message. This creates a truly backward compatible routine as the text printed is identical. If we had left out ovm_report_message and instead just wrapped ovm_report_info with avm_report_message users would find meaningless and annoying differences with their golden transcripts.

Any remaining uses of ovm_report_message in the OVM library or examples will be cleaned up by replacing with ovm_report_info.

-- Mark

To developers:

The backwards-compatibility is a great goal, but needs to be isolated from and not intrude on the normal public API, to avoid entropy:

- avm_report_message and other avm_report_XX should only be available via specification of the optional avm_compatibility.svh file. At present these exist also as ovm_report_object methods in an unguarded form. I know that for compatibility we have to declare them as methods of ovm_report_object so that we can typedef avm_report_client to that[1]. Can we at least guard this compatibility API with an `ifdef of AVM_compatibility_SVH or similar.

- under-the-hood methods like ovm_report_message to implement better compatibility (e.g. Mark's goal of golden logfile compatibility) should likewise be exposed only when compatibility mode is used. Note that WRT this goal, ovm_report_message() is broken in 1.0 / 1.0.1 as it just calls the underlying OVM_INFO severity messaging.

- same goes for uRM compatibility :-)

- one way to measure success: browse the OVM class headers in some existing or future SV source code browser tool (or, say, a text editor!!), check that the API is really clear and matches the reference manual, without the presence of confusing legacy method calls.

[1] [if only we had AOP these methods could be moved to avm_compatibility.svh :-)].

[dave_59]

There should be no ovm_report_message, it was changed to ovm_report_info() just before the release. It was probably left in for compatibility with earlier OVM pre-releases.

avm_report_message should map to m_rh.report(OVM_INFO,..)

Dave

[alain]

While we're at it: I could not find any examples of using ovm_report_handlers. It seems by default with ncsim even an ovm_report_warning stops the simulation :-(

It would be great if someone could post an example of how to use report handlers and set_severity_action.

-- alain.

[sandipn]

Hi Alain,

For getting out of this issue you can use the global reporting facility provided.
You can set the verbosity using the set_report_verbosity_level(int level).
And you can set the action as per severity using the function set_report_severity_actions(severity s,action a).

You can use this setting in all class to use an global reporting.

If you want to use report_handler then you can create the instance of report_handler in your class and you can pass that handle to all its child class so that they can use it for reporting.

example:- report_handler rh;
rh = new("report_handler");
Generate the message using report handler then ...

rh.report(INFO,"id","messsage hi ...",5,"file name",line number);

same as above for all just severity and id will change..

Regards,
Sandip.

[alain]

Thanks Sandip.

Actually, I have found that I have to use the following:



ovm_urm_report_server::set_global_actions(OVM_INFO , OVM_DISPLAY | OVM_EXIT);


If I add OVM_EXIT to OVM_INFO, ncsim stops at the first info message, as expected. When I look at OVM_WARNING with:


ovm_urm_report_server::get_global_actions(OVM_WARN ING);


it says that the action is 'b1 (OVM_DISPLAY), and yet when I cal ovm_report_warning, the system is telling me



*** OVM: DUT warning at time 210.00 ns
Checked at line 0 in <unknown>
In ovm_test_top.xyz_checker
WARNING: <my warning msg>
Will stop execution immediately (check effect is DISPLAY EXIT )
*** Warning: A DUT warning has occurred


Looks like a bug to me :-)

-- alain.