RE: Verbosity Control

John,

As I had stated with the proposal submission, we're ok if it is decided that module-specific verbosity is premature to standardize at this time and only global verbosity gets standardized. So we will not hold things up if that is the general consensus.

I feel we had a good discussion in this forum on module-specific verbosity that will benefit the LWG.

Thanks,
-Bishnupriya

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, December 06, 2010 9:29 PM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; Philipp A Hartmann; P1666 Technical WG
Subject: RE: Verbosity Control

Bishnupriya, All,

I am mainly arguing from experience using the module-specific reporting features of OVM. I concede that there are use cases where module-specific customization is a good thing. But the price paid with the OVM solution (and the current proposal) is user frustratation because it seems that "you never quite know whether the set_whatever call is going to do what you want", and it seems not to work in some of the most important use cases (meaning where you have a large number of reports from transaction streams or sequences, which you cannot control on a module-specific basis), leaving the user the impression that the feature is only half-baked.

In my opinion, this feeling of half-bakedness would be exacerbated if the module-specific reporting control in SystemC only applies to verbosity.

So personally I feel strongly that we should implement global verbosity control more-or-less as originally proposed, and punt module-specific reporting in general back to the LWG.

John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 12/06/2010 09:17AM
Cc: Philipp A Hartmann <philipp.hartmann@offis.de>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: Verbosity Control

John,

This is a good discussion. Comments below.

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Sunday, December 05, 2010 11:33 PM
To: Bishnupriya Bhattacharya
Cc: Philipp A Hartmann; P1666 Technical WG
Subject: RE: Verbosity Control

Bishnupriya, All,

I am aligned with your first proposal. I too prefer two overloaded sc_report_handler::report methods, with and without the verbosity argument.

Regarding the proposal to make verbosity module-specific, I hate and loath this feature of OVM!

Philipp has already uncovered one of the problems. In a module context,

SC_REPORT_INFO_V( ... );

can pick up the global rather than the local settings, based on a bunch of technicalities well understood to OOP experts but quite beyond the wit of the average user. We may know why this->SC_REPORT_INFO_V( ... ); is only sometimes needed, but most users would think it black magic.

But it gets worse. Resolving the call to pick up the correct function (local vs global) depends on the syntactic scope in which the call is written rather than on the dynamic scope. There are places where the dynamic scope would make more sense. For example, suppose you generate reports within a transaction class and pass those transactions through interface method calls. You then start setting module-specific verbosity levels, but those get totally ignored by the transaction class. Then you start getting mad and try top_level_module.set_verbosity_level_hier(). Of course, that does not work either. Nor would sc_report_handler::set_verbosity_level_hier() given the proposed definition. In order to quieten the reports, you have to change the global settings with sc_report_handler::set_verbosity_level(), at which point you change the setting for all such transaction classes. Whoops!

[One minor technicality. sc_report_handler::set_verbosity_level_hier() will also change the global setting in addition to that of the module hierarchy.

Lets consider the use model you raise. A generalization is if any object/class other than sc_module uses the SC_REPORT_INFO_V macro then those messages are subject to the global verbosity setting, instead of the verbosity setting of the sc_module which is intuitively/naturally "associated" with this object/class. I'm not convinced that this is so surpising. If the LRM clearly states that verbosity is a property either of a module or of the global scope, then why would users expect otherwise? Note that there is no existing use model here that subconsciously guides an user towards this expectation. This is a brand new feature that users will pick up and should consciously model with. One way to consciously model things here would be for the object/class ctor to accept a sc_module* argument, and explicitly call mod->sc_gen_report() when reporting messages, or perhaps another version of the macro that accepts a module argument to make this use model easier.

As a digression, note that there are some odd things that happen today with object/event naming when we do the opposite and pick up dynamic scope, instead of syntactic scope which would have been more natural, and users do live with that.

I think we are getting sidetracked here with the SC_REPORT_INFO_V macro being able to resolve to the right invocation both in global scope and in module scope. I'm not particularly hung up with this macro. I do feel it is a good convenience to provide and will work as expected in 99% of use models. For known use models where there can be unexpected outcomes (e.g. Philip's this->SC_REPORT_INFO_V case), we should include the discussion in the LRM.

The really important discussion in my mind is whether to provide the sc_module member methods that will allow per-module verbosity control. If this member methods exist, users can always use these vanilla member methods for reporting w/o using any macros, and very explicitly choose what they want.]

Even so, just suppose we do add module-specific verbosity. What about all the other controls on reporting, particularly set_action. Would the user not expect those to be module-specific too? An OVM user would.

[This is a very good point. I have struggled with this myself. You are right that just making verbosity control module-specific, but not the other aspects of reporting (like set_actions) feels inconsistent. Ideally, we would want to start with a clean slate, and perhaps make each reporting feature be instance-specific like in OVM. But we do not have a clean slate. The other features in reporting already exist. Still an argument can be made that they can also be *extended* and made module-specific. Verbosity is brand new. We can keep it aligned with the rest of the reporting mechanism as it exists today, or we can open this additional window of module-specific control, which perhaps in the future other reporting features could also pick up. That is a choice we have to make.

For me (and Cadence), the turning point was use model benefits. As you are aware, the original proposal did not include module-specific verbosity. We quickly found out that in an application - say a virtual platform with several peripherals with each peripheral emitting verbose debug messages - turning on global verbosity translates to a flood of messages, while in many cases users/developers are interested only in debugging a particular peripheral and would like to see only the debug messages from that peripheral, instead of getting overhwhelmed with a flood of messages from everybody. This common use model is serviced perfectly with module-specific verbosity control, and really, there is no viable, practical alternative.

In summary, I feel module-specific verbosity control does add important use model benefits. The SC_REPORT_INFO_V macro that automatically resolves to global or module scope works for most common modeling scenarios - hence is good to have, but not critical. Having said that, I do see your point about the possible inconsistency with other reporting constructs (e.g. set_actions) that are not module-specific. I personally feel that it makes sense for the other reporting constructs to also be made module-specific in the future (note that this is an extension, no backwards compatibility issues), however, clearly that cannot be achieved at this time. Given that, the group has to decide which way to go for module-specific verbosity.]

In my opinion we should not put module-specific verbosity into the standard.

Another point. Why modify the existing SC_REPORT_XXX macros to pass default verbosities for each severity level when the verbosity will anyway get ignored for every severity except SC_INFO. This is just misleading for the user. We have to keep the old sc_report_handler::report anyway, so why not just use that. In fact, I would propose we leave the existing 4 macros entirely unchanged and add just one new macro:

#define SC_REPORT_INFO_VERB(msg_type , msg, verbosity ) \
    sc_report_handler::report( SC_INFO , msg_type , msg , verbosity, __FILE__ , __LINE__ )

[Valid point. I do not feel strongly about this. The only benefit to making the existing sc_report_handler::report() take into account default verbosity level for SC_INFO messages is that existing designs can turn off info messages if they want by setting the verbosity level to <200 from sc_main (a one-line src code change) or perhaps from tool command line (no source code change). I don't think this is a particularly strong use case, and am ok if we decide verbosity will have no effect whatsoever on existing designs.]

Thanks,
 -Bishnupriya

Cheers,

John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 12/03/2010 06:29PM
Cc: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: RE: Verbosity Control

Philip,

You raise very good points, as always. Please see my comments below.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.