RE: sc_start

Bishnupriya, Philipp,

Okay. I will add

bool sc_pending_activity_at_current_time();
bool sc_pending_activity_at_future_time();
bool sc_pending_activity();

and make the "no activity" warning from sc_start(0) mandatory.

I propose what I think is a simple rule: sc_delta_count is incremented after each evaluation phase in which at least one process runs. There are two justifications:
- Aside from the questions over sc_start(0) and starting after sc_pause(), there anyway at least one runnable process when the scheduler reaches the eval phase
- It avoids having surprising jumps in the value of sc_delta_count, i.e. values that are not visible from ANY process

If we find this proposal actually breaks anything, I will withdraw it.

If sc_start(0) always causes the delta count to increment even if no processes run (I've not checked whether that is actually true, either), I think that might be an anomaly.
 
 The primitive channel event methods seem very fragile whatever, and we should probably resolve that issue too. The LRM says "Member function event shall return the value true if and only if the value of the channel was written or modified in the immediately preceding delta cycle."  What is that supposed to mean? 8=(

Cheers,

John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 01/18/2011 05:33PM
Cc: "acg@forteds.com" <acg@forteds.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: sc_start

John, Philipp,

I'm on the same page with you wrt sc_start(0) issuing a mandatory warning when no processes run in the eval phase, and adding the API 'sc_time sc_time_to_pending_activity()'.

Things are less clear to me as far as sc_delta_count() is concerned. What rule are we converging to? Delta count will not be incremented unless at least one process runs in the eval phase? Do we have a clean set of rules?

The alternative is delta count is incremented every time eval phase executes, including non-active sc_start(0) calls, as it does now. What is the downside of keeping the rules unchanged, as they are now? Agreed it is not as clean, but I don't see a clear alternate picture either. That sc_start(0) executes one delta cycle has been in the LRM for a long time now, so we are not introducing any new delta count related issues with that semantics. The sc_pending_activity_at_current_time() and such APIs are new, but those actually make life better here, by providing a means of cutting back on unnecessary wheel spinning. The mandatory warning will also make things better. So can't we just recommend in the LRM to use the new APIs and leave the simple rule that every time eval phase is executed, delta count increments (or whatever the current rule is).          

My 2 cents.

Thanks,
-Bishnupriya

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Tuesday, January 18, 2011 8:45 PM
To: john.aynsley@doulos.com
Cc: acg@forteds.com; Bishnupriya Bhattacharya; P1666 Technical WG
Subject: Re: sc_start

John,

you're right, sc_signal::event is indeed already fragile.
So maybe we're not really breaking "correct" models, when we're changing
its innards.

I think, a better implementation could take the current time into
account as well.  Something like:

     sc_time_stamp()  == m_time
  && sc_delta_count() == m_written_delta + 1

Would this work?

  I'm not sure, if we should restrict its use to sensitive processes.  A
run-time check for this would be too costly, making it simply undefined
would be no benefit.

  Maybe we should make its use from other processes
implementation-defined for now.  This would give us the room to work on
a rigorous definition in the LWG.

Greetings from Oldenburg,
  Philipp

On 18/01/11 13:38, john.aynsley@doulos.com wrote:
> Philipp,
>
> A quick experiment (file attached) reveals that sc_signal::event is
> already broken in this sense. In other words, the evaluation of event()
> assumes that something is listening (i.e. sensitive) to a signal
> whenever it gets updated (most probably the caller of event() itself).
> So I do not see that we would be making matters worse with the suggested
> definition of sc_delta_count().
>
> Re. event() we could
> - Most obviously, fix the implementation so that it does not rely on
> sc_delta_count
> - More obscurely, add the constraint that event() (and its friends) are
> only defined when called from a process sensitive to the given event.
>
> Cheers,
>
> John A
>
>
>
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To: john.aynsley@doulos.com
> Cc: bpriya@cadence.com, P1666 Technical WG
> <systemc-p1666-technical@eda.org>
> Date: 17/01/2011 17:13
> Subject: 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.