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