Re: Operations disallowed while paused

Philipp,

My two cents...

I generally agree with your analysis. SC_CTOR and SC_HAS_PROCESS are not errors.

Re. g) h) and i), I am inclined to say they are all errors in the LRM. If an implementation happens not to detect one of these as an error, it would not be the end of the world, just a wrinkle in the implementation (c.f. the old PoC implementation of multiple writers)

John A

-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
To: john.aynsley@doulos.com
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 01/15/2011 09:09PM
Cc: systemc-p1666-technical@eda.org
Subject: Re: Operations disallowed while paused

John,

please find my classification of the different operations below.
Generally speaking, error reporting should be consistent in all
forbidden cases for each operation.

On 11/01/11 14:30, john.aynsley@doulos.com wrote:
> All,
>
> Philipp writes:
>
>
>         5.5.2 sc_pause
>
>         "It shall be an error to perform any of the following operations
> while the simulation is paused:"
>
>         For the callbacks, the LRM states that "the following constructs
> shall not be used".  While there is not a real difference, the current
>  wording for sc_pause implies that all cases are required to be
>  detected as an error by the implementation.
>
> [JA]  Good question. Which of these do we want to be errors? I agree
> that not everything in the list is an error. Note that "error" => "shall
> not", but not vice-versa.
> Here are the candidates. Please comment for each item whether you think
> the implementation should be obliged to report an error or whether it is
> merely disallowed.
>
> John A
>
> *a) The instantiation of objects of class sc_module, sc_port, sc_export,
> or sc_prim_channel*
> *b) Port binding*
> *c) Export binding*

Errors.

> *d) Invocation of the macros SC_CTOR, SC_METHOD, SC_THREAD, SC_CTHREAD, or*
> *SC_HAS_PROCESS*

SC_METHOD, SC_THREAD, SC_CTHREAD -> errors
SC_CTOR, SC_HAS_PROCESS -> disallowed

> *e) Use of the member sensitive of class sc_module to create static
> sensitivity*
> *f) Calls to the member functions dont_initialize, set_stack_size,
> reset_signal_is or*
> *async_reset_signal_is of the class sc_module*

Errors.

> *g) Calls to event finder functions*

Sadly, event finder functions don't automatically decay to their event
siblings ( p.pos() => p->posedge_event()), after the port is bound.  But
since this is a quite frequent error, I think it should be detected.

> *h) Calls to the process control member functions kill, reset, or
> throw_it of class sc_process_handle*

Error, since this may be surprising.

> *i) Calls to the member functions wait or next_trigger of classes
> sc_module and sc_prim_channel or*
> *to the non-member functions wait or next_trigger*

Not sure.  Maybe disallowing these is sufficient.

Greetings from Oldenburg,
  Philipp

-- 
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 · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.