RE: sc_start

John, Philipp,

I strongly agree with Philipp that delta cycle semantics should not be changed, and neither should sc_start(0) advance time.

I'm fine with sc_pending_notification_time(). The other alternative, symmetric to sc_pending_activity_at_current_time() is to provide "bool sc_pending_activity_at_future_time()", which returns true if there are pending timed notifications. Then we can even provide "bool sc_pending_activity()" which is the 'or' of these 2 APIs.

I also see Philip's point about sc_start(0) issuing a warning if no activity happened. I'm neutral about LRM mandating this. I would vote for LRM using wording like "may or may not".

-Bishnupriya

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Thursday, January 13, 2011 3:31 PM
To: john.aynsley@doulos.com
Cc: Bishnupriya Bhattacharya; David C Black; SystemC P1666 Technical
Subject: Re: sc_start

John, all,

I've spent some thought on this. I'm not convinced that
sc_pause/sc_start(0) should do a time step.

  If sc_start(0) sometimes advances simulation time to the time of the
next pending timed notification, it is not consistent with sc_start(T)
(with T<earliest_pending).

Usually, the following relation holds:
    sc_time T = …, now = sc_time_stamp();
    sc_start( T, … );
    sc_assert( sc_time_stamp() <= now + T ) // for all T.

  Breaking this relation seems to be very surprising. Moreover, it's
not backwards compatible (current behaviour does not advance simulation
time) in a quite silent and subtle way.

  For sc_pause, there would be no longer any (local) guarantee about the
simulation time after the pause. This silently depends on the state of
the rest of the system, which is surprising as well. With the potential
time step at the end, one would need to manually inject
an artificial delta notification to guarantee a pause at the
current time.

  The issue we want to address is the advance to the earliest pending
time, since this is currently not possible to determine. Maybe the
correct solution is to add a function to retrieve the relative time of
the next pending timed notification (semi-pseudo-code):

sc_time sc_get_pending_notification_time()
{
  if( sc_pending_activity_at_current_time() )
    return SC_ZERO_TIME;
  return (timed_notif_exist) ? timed_notif_time
         : sc_max_time()-sc_time_stamp();
}

You could then step through the simulation via

while( sc_time_stamp() < sc_max_time() )
  sc_start( sc_get_pending_notification_time() );

without any required changes to the delta cycle semantics.

But then again, my original remark holds that an sc_start(0) without any
activity should probably issue a warning. Whether or not we want to
require this in the LRM is another question.

Opinions?

Greetings from Oldenburg,
  Philipp

On 12/01/11 18:08, john.aynsley@doulos.com wrote:
> Philipp, All,
>
> Good points. The existence of sc_start(0) and sc_pause() makes the
> current definition of the delta cycle inadequate. I think the new
> definition of a delta cycle needs to be
>
> a) An evaluation phase
> b) An update phase
> c) A delta notification phase
> and if and only if the set of runnable processes is still empty
> d) A timed notification phase
>
> That way, sc_start(0) will advance simulation time to the time of the
> earliest pending delta notification, timed notification, or time-out,
> and so will sc_pause(). In other words, each delta cycle ends by
> advancing time, if necessary.
>
> Does that work?
>
> Cheers,
>
> John A
>
>
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To: Bishnupriya Bhattacharya <bpriya@cadence.com>,
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>, David C Black
> <dcblack@xtreme-eda.com>
> Cc: SystemC P1666 Technical <systemc-p1666-technical@eda.org>
> Date: 12/01/2011 13:11
> Subject: Re: sc_start
>
>
>
>
>
> Bishnupriya, David, John,
>
> sorry, I have missed your mails on this. I'll try to explain my concern
> below. Replies to both of your mails embedded below. Especially
> David's comments on the simulation time advance may require some
> clarifications to the LRM.
>
> On 11/01/11 17:40, David C Black wrote:
>> Just for clarification...
>>
>> I assume the concept of "no activity" includes "no opportunity to
>> move time forward". In other words, if there are no pending
>> processes, but a timed notification or wait, then the simulator
>> should move the clock forward.
>
> Agreed. I had the "immediate starvation" in mind.
> I'm not sure, what happens to the simulation time, though.
>
>> Should this cause a warning or not. I would argue no.
>
> Yes, when there's anything to do there's no need for a warning.
> But as it stands now, the LRM says:
>
> "When function sc_start is called with a zero-valued time argument,
> the scheduler shall run for one delta cycle, that is, an evaluation
> phase, an update phase, and a delta notification phase, in that
> order. The value of the starvation policy argument shall be ignored."
>
> Note, that there's no 'timed notification phase', in case of an empty
> delta notification queue. So maybe this needs to be clarified as well.
> Otherwise, we don't have a mechanism to step to the next time stamp,
> right? Am I missing something?
>
>> All timed events will result in some activity or eventual starvation
>> (since something has to put the events in the queue in the first
>> place, and conceptually with the intent some process will act on the
>> events)
>
> A time step with immediate starvation is fine. The state of the
> simulator has advanced. No need for a warning in that case.
>
> sc_time_stamp last = sc_time_stamp();
> // if no current activity
> sc_assert( ! sc_pending_activity_at_current_time() );
> // after a delta step
> sc_start( SC_ZERO_TIME );
> // there should at least be a time step
> sc_assert( sc_time_stamp() != last );
>
> But this may require changes to the wording of sc_start( SC_ZERO_TIME ).
>
> On 11/01/11 19:21, Bishnupriya Bhattacharya wrote:
>>
>> How does one run into an infinite loop, with code like below?
>>
>> do {
>> sc_start(0);
>> while (sc_pending_activity_at_current_time())
>
> You are right, with such a loop you'll not run into an endless loop.
> But sc_pending_activity_at_current_time() is new in SystemC.
>
> Consider the following example:
>
> // write some stimuli to a DUT from sc_main here
> // - but due to an error, e.g. missing sensitivity,
> // no action is triggered
>
> // start simulation in a loop to obtain a stable output
> do {
> sc_start(0); // nothing is to be done, returns immediately
> } while( ! dut.ready.read() ); // will never hold
>
> I don't say, that this is good modelling style. But I've seen this in
> the past, and beginners are quite surprised to get an endless loop
> instead of an error. Especially, if the simulation time is not advanced
> as it seems to be intended by the current wording of the LRM.
>
> It may be just a quality of implementation issue, and not necessarily
> require any changes to the LRM. It may still be good to add such a
> check to an implementation.
>
> Greetings from Oldenburg,
> Philipp
>
>> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org
> <mailto:owner-systemc-p1666-technical@eda.org>] On Behalf Of
> john.aynsley@doulos.com
>> Sent: Tuesday, January 11, 2011 6:56 PM
>> To: systemc-p1666-technical@eda.org
>> Subject: sc_start
>>
>> All,
>>
>> Philipp writes:
>>
>> 5.3.4.2 Function sc_start
>>
>> "When function sc_start is called with a zero-valued time argument,
> the scheduler shall run for one delta cycle,..."
>>
>> Should there be a warning, if no activity is due in that delta cycle
> (sc_pending_activity_at_current_time() == false)? Otherwise, one can
> easily run into an endless loop...

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