Re: Event starvation

I completely agree with Phillip on this.

On Sat, Nov 20, 2010 at 10:28 AM, Philipp A. Hartmann <
philipp.hartmann@offis.de> wrote:

> Martin, John,
>
> I don't like like to see yet another additional function like "sc_run"
> to start the scheduler. This just adds further confusion.
>
> If we care about backwards compatibility, I would propose the following:
>
> 1) sc_start() - run until starvation, keep time of starvation
>
> This solves a real problem, without breaking old models.
> With the current sc_time_stamp() == sc_max_time(), there's just
> nothing you can do after sc_start() returns.
>
> 2) sc_start( const sc_time&, bool return_early = false );
> sc_start( double , sc_time_unit, bool return_early = false );
>
> If 'return_early' is false, keep the old behaviour of warping
> the time at least until the given argument (default).
> Otherwise, return with simulation time at point of starvation.
>
> With this, all cases should be covered, without breaking old models:
>
> // event starvation at T_starve < T_end
>
> // "old" sc_start()
> sc_start( sc_max_time(), false );
> sc_assert( sc_time_stamp() == sc_max_time() );
>
> // "new" sc_start()
> sc_start( sc_max_time(), true );
> sc_assert( sc_time_stamp() == T_starve );
>
> // old sc_start(T) remains
> sc_start( T_end /*, false */ );
> sc_assert( sc_time_stamp() == T_end );
>
> // new early return
> sc_start( T_end, true );
> sc_assert( sc_time_stamp() == T_starve );
>
> We can also add an enum instead of the less articulate boolean parameter:
>
> enum sc_scheduler_policy {
> SC_RUN_UNTIL_TIME,
> SC_RUN_EARLY_EXIT
> };
>
> With such an enum, we could even add an
>
> SC_RUN_ALL_DELTAS
>
> which -- in combination with SC_ZERO_TIME -- would then be equivalent to
> do {
> sc_start(SC_ZERO_TIME); // single delta
> } while( sc_pending_activity_at_current_time() );
>
> Of course, the above identifiers are really bad now,
> but I fail to come up with nice names here.
>
> Thoughts?
> Philipp
>
> On 19/11/10 12:04, Martin Janssen wrote:
> >
> > For backward compatibility reasons, would it make sense to use another
> > function for the
> > new behavior, e.g. sc_run(100, SC_NS) ?
>
> > -Martin
> >
> >
> > On 2010-11-19 11:37, john.aynsley@doulos.com wrote:
> >> Folks,
> >>
> >> A few of us have been having a side conversation about how we
> >> incorporate sc_pause into the scheduler. One issue that we have thrown
> >> up that I would like to refer back to everyone is what happens on
> >> event starvation.
> >>
> >> As we have already discussed, the current OSCI sim does this...
> >>
> >> sc_start(100, SC_NS); // Event starvation at sc_time(50, SC_NS)
> >> sc_assert( sc_time_stamp() == sc_time(100, SC_NS) );
> >>
> >> We have proposed making the following change
> >>
> >> sc_start(100, SC_NS); // Event starvation at sc_time(50, SC_NS)
> >> sc_assert( sc_time_stamp() == sc_time(50, SC_NS) );
> >>
> >> This is a change to 1666-2005 and is not backward compatible with the
> >> current OSCI sim, but we believe it is the better solution. The old
> >> behavior can be achieved as follows:
> >>
> >> ev.notify(100, SC_NS);
> >> sc_start(100, SC_NS); // Simulation will run for the full 100 ns
> >>
> >> Is everyone okay with this change?
>
>
>
> --
> 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
> Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.