RE: Verbosity Control

Bisnupriya,
 
 Re SC_IGNORE_VERBOSITY, I agree. Let's remove it.
 
 Re. sc_gen_report, I agree. Let's not add it.
 
 Re default verbosity, I agree with the principle, and I think I understand what you are suggesting, i.e.
 
 #define SC_REPORT_INFO( msg_type , msg ) \
 Â Â Â  sc_report_handler::report( SC_INFO , msg_type , msg , __FILE__ , __LINE__ )
 
 where report internally sets verbosity = 200 for SC_INFO reports before checking against max verbosity? If that is what you mean, then yes, I fully agree! (I got confused when you said that the sc_report_handler::report() signature should assign the default verbosity value.)
 
 John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "alan.fitch@doulos.com" <alan.fitch@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 12/08/2010 10:11AM
Cc: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "owner-systemc-p1666-technical@eda.org" <owner-systemc-p1666-technical@eda.org>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: RE: Verbosity Control

    
Alan, thanks for the rationale.
 
John, given Alan's comments below, I would vote not to include this additional enum because the benefits are not clear. That leaves us with the remaining 2 opens
 
- should existing signature of sc_report_handler::report() assign default verbosity value of 200 to SC_INFO messages and compare with max verbosity? I strongly feel it should
- should sc_core::sc_gen_report() with verbosity argument be added? I would vote no.
 
Did I miss anything?
 
Thanks,
-Bishnupriya 
    
      From: alan.fitch@doulos.com [mailto:alan.fitch@doulos.com]
Sent: Wednesday, December 08, 2010 3:18 PM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org
Subject: RE: Verbosity Control

   
owner-systemc-p1666-technical@eda.org wrote on 08/12/2010 05:04:06:

<snip>
> About SC_IGNORE_VERBOSITY = 9999, I'm not sure I understand. What
> can users do with this? Define SC_MY_VERBOSITY = 700? How will he
> define it? By changing the header file?  
>

Hi Bishnupriya,
  the idea is that if you want to loop through all values of an enumerated type, you know what the last enumerated value is, i.e. SC_IGNORE_VERBOSITY. Then if in future you add new values to the enumerated type (e.g. in IEEE 1666-2016! ) your looping code still works. It's just something I've seen in other tools that use enumerations, so that extra levels can be inserted and you still know the last enumeration.

However now I think about it, it doesn't help in this case because the enumeration values are not separated by 1, but by 100. So you couldn't easily write a loop to go through all possible enumeration values - and anyway, when would you want to?

So I'm not too worried, it was just an idea.

regards
Alan
 
> -Bishnupriya
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Wednesday, December 08, 2010 8:45 AM
> To: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
> Subject: RE: Verbosity Control

> Bishupriya,
>
> See below:
>
> Also, what do you think of adding sc_gen_report as proposed by
> Philipp? I see no reason to do so right now.
>
> 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/07/2010 05:41PM
> Cc: Bishnupriya Bhattacharya <bpriya@cadence.com>
> Subject: RE: Verbosity Control

> John,
>  
>  
> 1) The enum SC_IGNORE_VERBOSITY = 9999 was proposed by Alan for the
> case where we have only one report() signature with an optional
> verbosity argument at the end. We are not going with that signature.
> Philip had also not liked this enum. So I don't think we need this enum.
>
> [JA] SEE SEPARATE EMAIL TO ALAN
>  
> 2) I agree on your point to not change the existing macros to supply
> verbosity argument - that can be misleading. However, I don't like
> that some SC_INFO messages are subject to verbosity check and some
> are not. This is not consistent. Its better - as per the original
> proposal - that the existing report() signature assigns a default
> verbosity value of 200 to the INFO messages and check these against
> max verbosity. Then all INFO messages have a verbosity property -
> either explicitly user assigned or an implicit default value, and
> all INFO messages are subject to verbosity check. This is nice and
> clean and fully backward compatible.  
>
> [JA]  I'm not sure I understand. Are you saying change the
> definitions of the current SC_REPORT_INFO macro to call the
> overloaded sc_report_handler::report method with a verbosity, but
> leave SC_REPORT_WARNING/ERROR/FATAL unchanged? I would be fine with that.
>  
> 3)  About the new macro, I like adding SC_REPORT_INFO_VERB(msg_type,
> msg, verbosity).
>  
> Users will either do
>  
>    sc_report_handler::report(SC_INFO, "myid", "mymsg", 500,
> __FILE__, __LINE__);
>    sc_report_handler::report(SC_WARNING, "myid", "msg", __FILE__, __LINE__);
>  
> or
>  
>   SC_REPORT_INFO_VERB("myid", "mymsg", 500);
>   SC_REPORT_WARNING("myid", "msg");
>
> [JA] Yes, this is how I understood it.
> ÿ
> We should have this discussion on the reflector also.
> ÿ
> Thanks,
> -Bishnupriya
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

-- 
Alan    Fitch
Senior Consultant
Doulos - Developing Design Know-how
VHDL    * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project    Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood,    Hampshire, BH24 1AW, UK
Tel: ÿ+ 44 (0)1425 471223 ÿ ÿ ÿ    ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ Email:    alan.fitch@doulos.com 
Fax: ÿ+44 (0)1425 471573 ÿ ÿ ÿ    ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿhttp://www.doulos.com
--------------------------------------------------------------------------------
Doulos    Ltd is registered in England and Wales with company no. 3723454
Its    registered office is 4 Brackley Close, Bournemouth International    Airport,
Christchurch, BH23 6SE, UK. 
This message (and associated    files) may contain information that is confidential, 
proprietary,    privileged, or subject to copyright. It is intended solely for the use
of    the individual to whom it is addressed and others authorised to receive it.    If
you have received this email in error, please notify the sender and    delete all
copies. This message may contain personal views which are not    the views of
Doulos, unless specifically  stated.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.