Re: Event starvation

Philipp,

I agree with changing the behavior of sc_start() to exit-on-starvation

I agree a new argument to sc_start is better than sc_run

I agree an enumeration is more understandable than a bool. I suggest

enum sc_starvation_policy {
SC_RUN_TO_TIME,
SC_EXIT_ON_STARVATION
};

I am ambivalent about adding SC_RUN_ALL_DELTAS, because it is one more thing for people to get their heads round. I would almost prefer to write the explicit loop, because that gives emphasis to the meaning of sc_start(SC_ZERO_TIME) and sc_pending_activity_at_current_time().

Cheers,

John A

-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
To: Martin Janssen <Martin.Janssen@synopsys.com>
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 11/20/2010 04:28PM
Cc: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: Re: Event starvation

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.