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.