Re: reset_event

John,

some comments below.

On 15/11/10 11:27, john.aynsley@doulos.com wrote:

> Re. when reset_event() is notified, I cannot see that it makes any
> difference "when" it is notified relative to the reset action (assuming
> notify() is called from reset(), of course, which it has to be) because
> the effect of an immediate event notification is merely to make some
> processes runnable. Any such processes will not actually be executed until
> the current process yields (the one calling reset()).

You're right in case of an (immediate) reset() call. For the other
cases (e.g. by triggering an async reset signal), the event should be
notified from "within" the process being reset, e.g. just before
re-entering the process function. This may have been too obvious, though.

> When sc_pause() is called (or sc_stop() is called, for that matter) all
> kinds of activity can indeed be scheduled before the calling process
> yields. This activity includes event notifications (immediate, delta, and
> timed) and process control calls (including immediate ones). Any activity
> scheduled for the current evaluation phase will be executed before
> simulation is paused or stopped, so there could be a long chain of
> immediate notifications. sc_get_status() == SC_RUNNING during such
> execution. On return from sc_start(), the set of runnable processes will
> be empty, although there may exists update requests and delta
> notifications.

Ok, I agree with that.

> When sc_start() is called again, the set of runnable processes will still
> be empty,

So any immediate notification from within sc_main() is implicitly a
delta notification? Or an error? Or ignored?

sc_event e;

void
module::some_process(){
  // ...
  wait(e);
}

int sc_main( int, char*[] )
{
  module m("m");
  sc_start();
  // sc_pause or event starvation, 'm.some_process' waits for 'e'

  e.notify(); // allowed? -> m.some_process runnable?
              // or forbidden, as if we're in the update phase?

  sc_start(); // m.some_process runnable _before_ the next delta?
};

I'd vote for disallowing immediate notifications during SC_PAUSED
alongside with update(), see NOTE 3 in 6.10.4.

> so the schedule will jump to processing request_updates and
> delta notifications. We must specify that the delta_cycle count shall only
> get incremented once between evaluation phases across the pause.

Without immediate notifications, the delta count should be naturally
incremented by simply starting the scheduler again. Am I missing something?

  But we should specify, that the delta count should stay the same, if
no update requests or delta/timed notifications are scheduled (i.e.
sc_start() would return immediately).

> After return from sc_start() the main scheduler loop is not running,
> although request_update() may be called to schedule update requests.

And probably e.notify( const sc_time& ), right?

> We do need to consider which process control methods may be called when
> simulation is paused:
>
> suspend - yes?
> resume - yes?
> disable - yes?
> enable - yes?
> sync_reset_on/off - yes?

Seems to be OK to allow these.

> kill - no? (permitted during elaboration, but during elaboration there is
> no call stack to unwind)
> reset - no? (permitted during elaboration, but during elaboration there is
> no call stack to unwind)
> throw_it - no! (may only be called from a process)
>
> In other words, I am proposing that the immediate semantics of the process
> control methods can only be executed during simulation.

I fully agree.

> After calling sc_pause() or sc_stop(), simulation is still running until
> return from sc_start(). Right now there is no way to ask the kernel
> whether sc_pause() or sc_stop() have been called. It is legal (a warning)
> to call sc_stop() more than once. So, what should happen if sc_stop() is
> called after sc_pause() or sc_pause() after sc_stop() before the calling
> process has yielded?
>
> Should sc_stop() take precedence over sc_pause()?

Yes, I would do it like the tape decks back in the good old days... ;-)

 - sc_stop overrides sc_pause
 - sc_pause after sc_stop, or multiple sc_pause calls are no-ops
   (no need to warn, since sc_stop is visible anyway)

> Do we want to add:
>
> bool sc_stop_called() const;
> bool sc_pause_called() const;

I don't think these are necessary.

Greetings from Oldenburg,
  Philipp

>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> john.aynsley@doulos.com
> Cc:
> bpriya@cadence.com, systemc-p1666-technical@eda.org
> Date:
> 12/11/2010 23:46
> Subject:
> Re: reset_event
>
>
>
> John, Bishnupriya,
>
> I agree with having immediate notification of reset_event. We should
> probably require, that this event is notified "after" the reset action
> has been performed, though.
>
> But I'm somewhat puzzled about the interaction of sc_pause and the
> reset/terminated events. Due to the immediate semantics and the
> immediate notification of these events, all kinds of model activity
> could be triggered during SC_PAUSED, when processes are reset from
> within sc_main.
>
> This feels indeed worrisome to me, as Bishnupriya put it in an earlier
> mail. Do we need to require, that this implicit/immediate evaluation
> phase at least sets the status back to SC_RUNNING? Or do we want to
> prohibit this use of kill/reset/throw_it from in between calls to
> sc_start?
>
> Thanks,
> Philipp
>
> On 12/11/10 16:40, john.aynsley@doulos.com wrote:
>> Bishnupriya,
>>
>> I am just trying to pin down the semantics of reset_event().
>>
>> Every flavor of reset, namely
>>
>> * reset()
>> * resumption while in the synchronous reset state
>> * async_reset_signal()
>>
>> is ultimately equivalent to a call to reset() happening during an
>> evaluation phase. We want this to cause the notification of the event
> that
>> will be returned by the new method reset_event(). I can see two
>> possibilities:
>>
>> * The reset event is notified using an immediate notification, in which
>> case any processes sensitive to the reset event will become runnable in
>> the same evaluation phase in which reset() is called
>>
>> or
>>
>> * The reset event is notified using a delta notification, in which case
>> any processes sensitive to the reset event will become runnable one
> delta
>> cycle later.
>>
>> The immediate notification feels right to me.
>>
>> What do you think?
>>
>> Thanks,
>>
>> John A

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