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.