RE: Empty events lists

Eric,

It is already the case that 1666-2005 requires the implementation to call sc_report_handler::report with severity SC_ERROR in the case of an error. However, 1666 does not pin down the message types of errors, so that theoretically the message types are implementation-specific. In practice, of course, other implementation simple copy the OSCI PoC message types (because they are typically built on the PoC implementation). For example, the message type  "/IEEE_Std_1666/deprecated" for deprecated features.

We could look at pinning down the error message types in 1666 if people feel sufficiently motivated at this point.

John A

-----"Roesler, Eric E" <eric.e.roesler@intel.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Philipp A Hartmann <philipp.hartmann@offis.de>, "bpriya@cadence.com" <bpriya@cadence.com>
From: "Roesler, Eric E" <eric.e.roesler@intel.com>
Date: 11/03/2010 05:20PM
Cc: "david.long@doulos.com" <david.long@doulos.com>, "p.goel@acm.org" <p.goel@acm.org>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: Empty events lists

              
  I agree with making these cases errors, just to avoid confusion for users.  However, I strongly recommend the errors are configurable (ie sc_report_handler::set_actions() or similar ), say to disable throwing an exception.  I don’t know what kind of language could be used in the LRM to encourage implementations to do that.
  Â 
  It’s very annoying to be gated while debugging due to an unrelated error (that may be in code not under your control). 
  Â 
  EricR
  Â 
  Â 
  
  
      From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
 Sent: Tuesday, November 02, 2010 11:51 AM
 To: Philipp A Hartmann; bpriya@cadence.com
 Cc: david.long@doulos.com; p.goel@acm.org; P1666 Technical WG
 Subject: Re: Empty events lists
    Â 
  All,
 
 Okay, so I propose that wait(empty_list) and wait(delay, empty_list) are both errors. Agreed?
 
 (But otherwise I could live with Bishnupriya's error/warning proposal)
 
 John A
 
 -----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
  
    To: john.aynsley@doulos.com
 From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
 Date: 11/02/2010 09:45AM
 Cc: p.goel@acm.org, david.long@doulos.com, P1666 Technical WG <systemc-p1666-technical@eda.org>
 Subject: Re: Empty events lists
  John, All

since wait() typically means 'wait for static sensitivity, if present',

'wait(empty_list)' should at least NOT degenerate to 'wait()'.

  If we really want to add some semantics, I think we definitely need to

warn the user to avoid accidental confusion.  So to combine this with

Puneet's proposal, this could mean:

  wait( empty_or_list )  => warn and wait forever

                            (Any event fired?  No.  => Wait)

  wait( empty_and_list ) => warn and return immediately

                            (All events fired? Yes. => Return)

  wait( delay, empty_or_list )  => warn and wait( delay )

  wait( delay, empty_and_list ) => warn and return immediately

But maybe it's easier to simply error out in all cases, since the user

can easily work around this as shown in my earlier mail.  I tend to

prefer this.

Greetings from Oldenburg,

  Philipp

On 02/11/10 17:30, john.aynsley@doulos.com wrote:

> Puneet, Bishnupriya, All,

>

> I too understand what Puneet is saying. But SystemC event lists are not lists in a functional programming sense, and the typical SystemC user is not a functional programmer. On the other hand, there are existing semantics and clear expectations attached to wait(), i.e. it means wait forever.

>

> So, now we introduce explicit wait lists, allowing constructs such as wait(list) or wait(delay, list). If the list is empty, I think for SystemC users there are 3 obvious choices we could make

>

> - wait(empty_list) => wait forever

> - wait(empty_list) => error

> - wait(empty_list) => warning and wait forever

>

> Bisnupriya has proposed

> - wait(empty_list) => error

> - wait(delay, empty_list) => warning and wait(delay)

>

> I am not entirely comfortable with having the first as an error and the second as a warning. It's not a show-stopper for me, but if we are not going to have wait(empty_list) wait forever, then I would prefer both forms to be an error. It seems more straightforward.

>

> John A

>

>

>

> -----puneet@coverify.com wrote: -----

> To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>

> From: Puneet Goel

> Sent by: puneet@coverify.com

> Date: 11/02/2010 04:11AM

> Cc: david.long@doulos.com, john.aynsley@doulos.com, owner-systemc-p1666-technical@eda.org, systemc-p1666-technical@eda.org

> Subject: Re: Empty events lists

>

>> It is like when you define an operation on a list, you start with a

>> seed.

>

> Like in case of summation on a list you start with the result seeded

> to 0. In case of multiplication (factorial) you start with the result

> seeded to 1. In case of ORing a list, we start with the result seeded

> to false. And in case of ANding a list, we start with the result

> seeded to true.

>

> Similarly is we think about sc_event_and_list, we would seed the

> result with an immediate event. And for sc_event_or_list, we should

> seed the result with an event that never gets notified.

>

> Regards

> - Puneet

> 

>

>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation ú FuE-Bereich Verkehr
Escherweg 2 ú 26121 Oldenburg ú Germany
Phone/Fax: +49-441-9722-420/282 ú PGP: 0x9161A5C0 ú http://www.offis.de/    
 -- 
 This message has been scanned for viruses and 
 dangerous content by MailScanner, and is 
 believed to be clean. 
    
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.