Re: sc_start

From: <john.aynsley@doulos.com>
Date: Sun Jan 16 2011 - 02:52:49 PST

Philipp, Bishnupriya, All,

Good point re the definition of delta count. Similarly, what if we have

chan.request_update();
ev.notify(SC_ZERO_TIME);
sc_start(...);

and there happens not to be any runnable processes on the call to sc_start. Would the first spin through eval->update->delta cause the delta count to be incremented?

With a quick experiment, I've found that a timed notification that does not cause a process to awake does NOT seem to cause the delta count to increment. What DOES cause the delta count to increment is an attempt to resume() a suspend()-ed process (even when no process actually runs in that eval phase). Is that what we want?

I think we need to clear this up, if only to allow sc_delta_count() to be used reliably for understanding and for debugging.

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 08:24PM
Cc: bpriya@cadence.com, David Black <dcblack@xtreme-eda.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: Re: sc_start

John,

I like the name sc_time_to_pending_activity().

  And I agree, that the delta count should probably not be incremented
after an "empty" evaluation phase.

  AFAICS, the delta count is currently incremented whenever the
scheduler has finished an evaluation phase, regardless of the number of
processes that were run.  This does not only relates to sc_start(0), but
also to timed notifications et.al. without any waiting processes (e.g.
ev.notify(T)).

Greetings from Oldenburg,
  Philipp

On 15/01/11 19:36, john.aynsley@doulos.com wrote:
> Philipp, Bishnupriya,
>
> Comments below...
>
> -----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
>
>     To: john.aynsley@doulos.com
>     From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>     Date: 01/13/2011 04:33PM
>     Cc: Bishnupriya Bhattacharya <bpriya@cadence.com>, David C Black
>     <dcblack@xtreme-eda.com>, SystemC P1666 Technical
>     <systemc-p1666-technical@eda.org>
>     Subject: Re: sc_start
>
>     John, Bishnupriya,
>
>     answers below.
>
>     On 13/01/11 17:14, john.aynsley@doulos.com wrote:
>     >
>     > Having re-read this thread, I am a bit confused. Let me recap what I
>     > think we have concluded:
>     >
>     >         sc_time now = sc_time_stamp();
>     >         sc_start(SC_ZERO_TIME);
>     >         sc_assert( sc_time_stamp() == now);
>     >
>     > Right? I am fine with that.
>
>     Yes.  Same for
>
>       extern sc_time pause_time;
>
>       pause_time = sc_time_stamp();   // ... somewhere in a process
>       sc_pause();
>       wait();
>       // ...
>       sc_start( ... );
>       sc_assert( sc_time_stamp() == pause_time );
>
>     This is essentially as it is defined with the current delta cycle
>     semantics.
>
>     [JA] Yes, agreed.
>
>     > Re. sc_start(0) issuing a warning if no activity happened, this is
>     > equivalent to
>     >
>     >         if ( sc_pending_activity_at_current_time() )
>     >           sc_start(SC_ZERO_TIME);
>     >         else
>     >            SC_REPORT_INFO("", "In effect, the implementation would
>     issue
>     > this warning instead of the application?");
>     >
>     > In other words, "no activity" means
>     > !sc_pending_activity_at_current_time() when sc_start(0) is called,
>     > right? I am neutral on making this change to the LRM.
>
>     Yes.  I like Bishnupriya's suggestion to make the warning optional ("may
>     or may not").  Another issue here is the delta_count, when there's no
>     activity:
>
>       sc_dt::uint64 delta = sc_delta_count();
>       sc_start(0);
>       sc_assert( sc_delta_count() == delta + 1);
>
>     Should this hold in all cases (even when there's no activity)?
>     In the PoC, the delta count is always incremented.
>
>     [JA] Interesting. While the scheduler is running,
>     sc_pending_activity_at_current_time() == true whenever the
>     evaluation phase is entered, meaning there exist runnable processes,
>     so the delta count is only incremented after having run at least one
>     process. If we force a delta cycle without any activity using
>     sc_start(0), should the delta count increment? I think not, in which
>     case I am starting to lean toward making that "no activity" warning
>     mandatory. (As an aside, some of my regression tests are showing the
>     delta count being incremented at unexpected times, and I've yet to
>     resolve why.)
>
>     > Re. adding further functions, I like Bishnupriya's suggestion of:
>     >
>     > bool sc_pending_activity_at_current_time();
>     > bool sc_pending_activity_at_future_time();
>     > bool sc_pending_activity();
>
>     I also like this idea.
>
>     To complete this set of functions to achieve a step-wise walk through
>     the simulation, the relative _time_ of the next activity should be
>     accessible as well, right?
>
>     sc_time sc_next_pending_activity()
>     returns:
>       · SC_ZERO_TIME,
>            iff sc_pending_activity_at_current_time() == true
>       · _relative_ time until next timed notification,
>            iff sc_pending_activity_at_future_time() == true
>       · sc_max_time() - sc_time_stamp(),
>            otherwise
>
>       The reason for 'sc_max_time() - sc_time_stamp' in the "other" case
>     ensures, that it if safe to call sc_start( sc_next_pending_activity() )
> ÿ ÿ at all times, resulting in said step-wise walk.
>
> ÿ ÿ [JA] Agreed. I propose the name:
> ÿ ÿ sc_time sc_time_to_pending_activity();
>

-- 
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 Sun Jan 16 02:53:36 2011

This archive was generated by hypermail 2.1.8 : Sun Jan 16 2011 - 02:53:38 PST