Re: sc_start

John,

I agree that the delta count should only be incremented for 'real'
evaluation phases. But we have to be careful to define the exact
semantics, e.g. to avoid breaking e.g. the sc_signal<T>::event() function:

  "Member function event shall return the value true if and only if the
   value of the signal changed in the update phase of the immediately
   preceding delta cycle; that is, a member function write or operator=
   was called in the immediately preceding evaluation phase, and the
   value written or assigned was different from the previous value of
   the signal."

  When there's no activity in the evaluation phase after the write to
some signal, wouldn't the missing delta count increment result in the
wrong result for event()?

  Since the delta count is not defined very accurately, the event()
function seems to be quite fragile as well. Even currently, event() may
return true even though the time stamp is different.

Wrt. your other issue at the start of the simulation without other
runnable processes:

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

I think, it should be consistent with the overall definition of the
delta counts. If we decide to increment the delta count for every
non-empty delta notif. phase, it should be incremented. If not (which
might requires fixes to sc_signal::event()), it should stay 0.

Greetings from Oldenburg,
  Philipp

On 17/01/11 10:08, john.aynsley@doulos.com wrote:
> All,
>
> Further, I think I would prefer to see sc_delta_count incremented ONLY
> following evaluation phases in which at least one process actually runs.
> Then we will not get surprises with sc_delta_count apparently skipping
> values.
>
> Opinions?
>
> John A
>
>
> From: john.aynsley@doulos.com
> To: "Philipp A Hartmann" <philipp.hartmann@offis.de>
> Cc: bpriya@cadence.com, "David Black" <dcblack@xtreme-eda.com>, "P1666
> Technical WG" <systemc-p1666-technical@eda.org>
> Date: 16/01/2011 10:53
> Subject: Re: sc_start
> Sent by: owner-systemc-p1666-technical@eda.org
>
>
>
>
>
> 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://offis.de/en/
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.