Re: make "errors" be "warnings" in process control spec

All,

I agree, that no process control operation should cause a process to be
evaluated (or even unwound) during the update phase.

On the other hand, I would have expected that these operations would
then be effective in the following evaluation phase, which would be
quite useful and in line with event notifications.

But this again would of course contradict the usual immediate semantics.
 Bummer.

Greetings from Oldenburg,
Philipp

On 16/09/10 20:09, Bishnupriya Bhattacharya wrote:
> John,
>
> I'm fine with disallowing all the constructs from update() phase - that seems safer.
>
> -Bishnupriya
>
> ________________________________
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Thursday, September 16, 2010 11:11 PM
> To: Bishnupriya Bhattacharya
> Cc: SystemC P1666 Technical
> Subject: RE: make "errors" be "warnings" in process control spec
>
> Bishnupriya, All,
>
> I feel very unsettled about the idea of allowing any process control extensions to be executed from the update phase, which is clearly intended for the update of primitive channels. In particular, allowing reset() to switch in and execute a process function from the beginning feels like it should be forbidden except from the evaluation phase.
>
> Opinions?
>
> John A
>
>
>
> From: Bishnupriya Bhattacharya <bpriya@cadence.com>
> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc: SystemC P1666 Technical <systemc-p1666-technical@eda.org>
> Date: 14/09/2010 10:20
> Subject: RE: make "errors" be "warnings" in process control spec
>
> ________________________________
>
>
>
> John,
>
> For the sixth point, yes, this is specially true for throw_it(). For the other constructs, there will be some effect if they are issued from phase callbacks or from a module's ctor, and so they are allowed. As for calling from update phase, it is also allowed for the other constructs, although I do not feel strongly on this point.
>
> Thanks,
> -Bishnupriya
>
> ________________________________
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Friday, September 10, 2010 6:59 PM
> To: Bishnupriya Bhattacharya
> Cc: SystemC P1666 Technical
> Subject: Re: make "errors" be "warnings" in process control spec
>
> Bishnupriya,
>
> I have already caught the first 5 points.
>
> Regarding the 6th point, does this only apply to throw_it? Are there similar constraints on calling other process control methods from phase callbacks or from the update phase?
>
> John A
>
> From: Bishnupriya Bhattacharya <bpriya@cadence.com>
> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, SystemC P1666 Technical <systemc-p1666-technical@eda.org>
> Date: 08/09/2010 12:36
> Subject: make "errors" be "warnings" in process control spec
>
>
> ________________________________
>
>
>
> John,
>
> I reviewed all the places in the current spec where it says something "shall be an error". For all of these, I feet it will be fine (and probably better) to say "shall generate a warning". Some of these have already been discussed in the reflector and it has been concluded that these should be made warnings instead of errors.
>
> I include the full list below.
>
> Thanks,
> -Bishnupriya
>
>
> - "sync_reset_on() shall only be applicable to thread processes, it shall be an error to invoke sync_reset_on() on a method process"
> - "It shall be an error to specify reset_signal_is() for a method process"
> - "throwing an exception in a terminated process shall be an error if the include_descendants flag is not set"
> - "Throwing an exception in a process that has not started execution yet shall have no effect for the same reasons as above, and shall be an error"
> - "Throwing an exception when simulation is not running (before simulation start or after simulation end) shall have no effect and shall be an error"
> - "The thrower shall always be a process. It shall be an error to throw an exception from any other context, for example from a phase callback or from the update() routine of a user defined channel"
>
> -------------------------------------------------------------------------------------------------------------------------------------
> Bishnupriya Bhattacharya | R&D - SystemC Simulation, Debug & Analysis | Cadence
> P: +91.80.4184.1197 www.cadence.com<http://www.cadence.com/>
> -------------------------------------------------------------------------------------------------------------------------------------
>
>
>
>
>

-- 
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.