Re: Question about sc_start_starvation.cpp

John,

I agree with Andy's view on this. But there are obviously two
alternative views. See below.

On 24/01/11 10:54, john.aynsley@doulos.com wrote:
>
> Oh, I see. I think the LRM is wrong and the PoC sim is wrong.
>
> The issue is this:
>
> // time = 0
> ev.notify(100, SC_NS);
> sc_start(50, SC_NS, SC_EXIT_ON_STARVATION);
>
> The current LRM wording says that on exit, simulation time shall be set
> to of the most recent event notification, which is 0. But what if there
> is a future event notification?

In this case, no timed notification exists within the interval
  [0, 50 SC_NS].

  With SC_EXIT_ON_STARVATION, I think the time should not move at all
(and issue the same warning as with sc_start(0) and
sc_pending_activity_at_current_time() == 0.

> I think I got the LRM wording wrong. I had meant to say:
>
> "If the argument of type sc_starvation_policy has the value
> SC_EXIT_ON_STARVATION, the implementation shall set simulation time
> equal to either the maximum time of any pending event notification or
> time-out or to the end time, whichever is the smaller."

The "maximum time of any pending notification or time-out smaller than
the end time" of course needs to be determined on the fly, while the
simulation is running until the end time.

> i.e.
> start = sc_time_stamp();
> sc_start(delay, SC_EXIT_ON_STARVATION);
> sc_assert( sc_time_stamp() == MIN ( MAX(time of every pending
> notification) , start + delay );

I think, one interpretation could be, that the following assertions hold
( I use (A => B) <=> (!A || B) to denote implication):

  sc_time exit = sc_time_stamp();
  sc_time end = start + delay;
  sc_time starvation = end - exit;

  // at most end time
  sc_assert( exit <= end );

  // if there are pending current activities, we have reached end time
  sc_assert( !sc_pending_activity_at_current_time() || (exit == end) );

  // if we have exited early, any future activity is beyond end time
  sc_assert( !sc_pending_activity_at_future_time()
          || ( sc_time_to_future_activity() > starvation ) );

Especially the last one is the interesting one. Do we actually jump
early out of the scheduler, if the timed notifications would jump over
the end time (exit<end)?

  You seem to propose to always advance the simulation time to end time,
if activity is pending:

  sc_assert( !sc_pending_activity() || (exit==end) );

which would then require, that (exit < end) is equivalent to a "real"
starvation:

  sc_assert( ( sc_pending_activity() || (exit<end) ) )
           && ( !(exit<end) || !sc_pending_activity() );

  I think, if we simply don't consider notifications beyond the end
time, "starvation" might occur earlier than the end time. All of this
of course only makes a difference, if there are pending actions beyond
the end time.

> Is that correct?

It's more a question what we want to have here. I don't have a strong
opinion on this with a slight tendency towards an early exit (exit<end)
even with pending future notifications.

Greetings from Oldenburg,
  Philipp

> From: Andy Goodrich <acg@forteds.com>
> To: john.aynsley@doulos.com
> Date: 24/01/2011 09:31
> Subject: Re: Question about sc_start_starvation.cpp
>
>
>
>
>
> John, here is my change to your test that now succeeds with a fix to the
> simulator. Notice the change in assertion I made, which I think is
> correct, but I wanted a sanity check on it. I don't think time should
> move when the bold face call is made.
>
> Thanks,
> Andy
>
>
> int sc_main(int argc, char* argv[])
> {
> Top top("top");
>
> sc_assert( sc_get_status() == SC_ELABORATION );
> sc_assert( sc_time_stamp() == SC_ZERO_TIME );
> sc_start(100, SC_NS);
> sc_assert( sc_time_stamp() == sc_time(100, SC_NS) );
>
> sc_start(10, SC_NS, SC_RUN_TO_TIME);
> sc_assert( sc_time_stamp() == sc_time(110, SC_NS) );
>
> *sc_start(10, SC_NS, SC_EXIT_ON_STARVATION);*
> // sc_assert( sc_time_stamp() == sc_time(120, SC_NS) );
> sc_assert( sc_time_stamp() == sc_time(110, SC_NS) );
>
> sc_start(80, SC_NS, SC_EXIT_ON_STARVATION);
> sc_assert( sc_time_stamp() == sc_time(150, SC_NS) );
>
> sc_start();
> sc_assert( sc_time_stamp() == sc_time(150, SC_NS) );
> sc_assert( sc_get_status() == SC_PAUSED );
>
> cout << endl << "Success" << endl;
> return 0;
> }
>
>
> On Jan 24, 2011, at 12:53 AM, john.aynsley@doulos.com
> <mailto:john.aynsley@doulos.com> wrote:
>
> Andy,
>
> Here's my log...
>
>
> SystemC 2.3.0_20110120_beta-OSCI --- Jan 21 2011 11:06:20
> Copyright (c) 1996-2011 by all Contributors
> ALL RIGHTS RESERVED
>
> Fatal: (F4) assertion failed: sc_time_stamp() == sc_time(150, SC_NS)
> In file: sc_start_starvation.cpp:42
> Abort
>
> If I print out the time when it fails, sc_time_stamp() = 200 NS. I
> reckon it should exit after the notification at 150 NS.
>
> John A
>
> From: Andy Goodrich < acg@forteds.com <mailto:acg@forteds.com> >
> To: John Aynsley < john.aynsley@doulos.com
> <mailto:john.aynsley@doulos.com> >
> Date: 23/01/2011 22:14
> Subject: Question about sc_start_starvation.cpp
>
>
>
>
>
>
> John, I think there is a bug in sc_start_starvation.cpp:
>
> sc_start(10, SC_NS, SC_RUN_TO_TIME);
> sc_assert( sc_time_stamp() == sc_time(110, SC_NS) );
>
> sc_start(10, SC_NS, SC_EXIT_ON_STARVATION);
> sc_assert( sc_time_stamp() == sc_time(120, SC_NS) );
>
> The second sc_assert fails for me and sc_time_stamp() is still at 100,
> SC_NS, which I believe is correct, since no event occurs, so time should
> not move.
>
> Am I correct?
>
> Thanks,
> Andy

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