Re: Operations disallowed while paused

From: Philipp A. Hartmann <philipp.hartmann@offis.de>
Date: Sat Jan 15 2011 - 13:09:44 PST

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.
Received on Sat Jan 15 13:11:41 2011

This archive was generated by hypermail 2.1.8 : Sat Jan 15 2011 - 13:11:45 PST