Re: Question about sc_start_starvation.cpp

For the moment I will set the simulator up to run to the time of the last event before or at the end time, and not update the time if there are no events between the time sc_start was called and the end time. If we decide differently I'll modify to suit.

Andy

On Jan 24, 2011, at 9:30 AM, john.aynsley@doulos.com wrote:

> I agree with Philipp's analysis. It's just a question of what we want, i.e. do we or don't we count events past the end time when determining starvation. Perhaps the early exit is most useful, because if you wanted to run to the exit time you could have chosen SC_RUN_TO_TIME.
>
> John A
>
>
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To: john.aynsley@doulos.com, Andy Goodrich <acg@forteds.com>
> Cc: bpriya@cadence.com, systemc-p1666-technical@eda.org
> Date: 24/01/2011 10:51
> Subject: 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.