Re: LRM clarification re sc_start

Do you think, this is needed?

In 5.3.4.2, it currently says:

  "When called for the first time, function sc_start shall start the
   scheduler, which shall run up to the simulation time passed as an
   argument … . The scheduler shall execute the initialization
   phase before executing the first evaluation phase, as described in
   5.2.1.1."

This first paragraph is not restricted by the value of the simulation
time argument. The following clarifies the interpretation of SC_ZERO_TIME:

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

Together, the only reasonable interpretation seems to be the current
behaviour. Do you think, there's anything missing?

Greetings from Oldenburg,
  Philipp

On 25/01/11 09:40, john.aynsley@doulos.com wrote:
> Oh, I wasn't suggesting we change anything except the wording in the LRM.
> It just needs a remark against sc_start(0) that in the special case of it
> being the 1st call to sc_start, the initialization phase runs before the
> delta cycle.
>
> John A
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> john.aynsley@doulos.com
> Cc:
> P1666 Technical WG <systemc-p1666-technical@eda.org>
> Date:
> 24/01/2011 23:04
> Subject:
> Re: LRM clarification re sc_start
>
>
>
> John, all,
>
> sorry for my last mail. Unfortunately hit the 'send' button before
> writing anything?
>
> AFAICS, the current behaviour of the PoC implementation is to do both
>
> - initialisation phase
> - one full delta cycle.
>
> With the current wording, this seems to be a reasonable interpretation.
>
> We could of course add the special case, that the first evaluation phase
> should be not be included. This would enable a real "elaboration only"
> run of the scheduler.
>
> Greetings from Oldenburg,
> Philipp
>
> On 22/01/11 11:52, john.aynsley@doulos.com wrote:
>> All,
>>
>> The LRM needs clarifying with respect to the corner case where the very
> first call to sc_start has a zero-valued time argument. The description of
> sc_start(0) says it runs eval-update-delta, which is inconsistent with the
> text descibing the first call to sc_start.
>>
>> John A
>>
>>
>> -----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
>> To: john.aynsley@doulos.com
>> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>> Date: 01/21/2011 11:58AM
>> Cc: bpriya@cadence.com, Andy Goodrich <acg@forteds.com>,
> systemc-p1666-technical@eda.org
>> Subject: sc_time_to_pending_activity example (was Re: Another lib to
> check.)
>>
>> John,
>>
>> comments below.
>>
>> On 21/01/11 11:54, john.aynsley@doulos.com wrote:
>>>
>>> Before the initialization phase there are no runnable processes. There
>
>>> may or may not be pending update requests or notifications. If not,
>>> sc_time_to_pending_activity() should return sc_max_time() during
>>> elaboration.
>>
>> Works for me. This is then consistent with sc_pending_activity(), which
>> is a Good Thing.
>>
>>> If there is no pending activity when sc_start() is called, which is the
>
>>> default, sc_time_to_pending_activity() should return sc_max_time. I
> agree
>>> with the need for the workaround. Maybe we should add a note to the LRM
>
>>> pointing this out, but I don't think it is a big deal.
>>
>> I think in a note, the issue may be too difficult to describe.
>> What about an example for the step-wise simulation? This could
>> illustrate the motivation for these functions in general:
>>
>> int sc_main( int, char*[] )
>> {
>> // instantiate design
>> ...
>>
>> // elaborate design
>> sc_start( SC_ZERO_TIME );
>>
>> // run step-wise simulation
>> while( sc_pending_activity() ) {
>>
>> // run single (time) step
>> sc_start( sc_time_to_pending_activity() );
>>
>> // run remaining current deltas (optional)
>> while( sc_pending_activity_at_current_time() ) {
>> sc_start( SC_ZERO_TIME );
>> }
>> } // pending activity
>>
>> return 0;
>> }
>>
>> Greetings from Oldenburg,
>> Philipp
>>
>>> From:
>>> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>>> To:
>>> john.aynsley@doulos.com
>>> Cc:
>>> Andy Goodrich <acg@forteds.com>
>>> Date:
>>> 21/01/2011 09:52
>>> Subject:
>>> Re: Another lib to check.
>>>
>>>
>>>
>>> John,
>>>
>>> see below.
>>>
>>> On 21/01/11 10:08, john.aynsley@doulos.com wrote:
>>>> "Update requests, timed notifications, and delta notifications may be
>>>> created before the first call to sc_start,
>>>> but immediate notifications shall not be created before the first call
>
>>> to
>>>> sc_start."
>>>
>>> Since the initialisation phase is special, we need to consider the
>>> initially running processes as well. The set of these processes can
> not
>>> be (finally) determined before the end of elaboration. But in the
>>> majority of cases, there will be processes being run in the first
> delta.
>>>
>>> If there are no update requests, delta notifs or timed notifications
>>> set up before the first call to sc_start, should
>>> sc_time_to_pending_activity() return sc_max_time() before the end of
>>> elaboration?
>>>
>>> In the attached example, the first (external) activity is at 10 ns.
>>> But there's a process scheduled at the beginning. The main loop in
>>> sc_main is essentially:
>>>
>>> sc_start( SC_ZERO_TIME ); // elaborate -- needed to avoid segfault
>>> while( sc_time_stamp() < sc_max_time() )
>>> {
>>> sc_start( sc_time_to_pending_activity() );
>>> }
>>>
>>> The first sc_start( SC_ZERO_TIME ) would be _required_, if the intent
>>> is to run the simulation step-wise, since otherwise some steps may be
>>> skipped due to additional notifications being created in the first
>>> evaluation phase.
>>>
>>> I think, I can live with this caveat, since there's an easy
>>> workaround. But still it may be surprising?
>>>
>>> Greetings from Oldenburg,
>>> Philipp
>>>
>>>> So there could be timed notifications before sc_start =>
> time-to-pending
>>>>
>>>> 0
>>>>
>>>> John A
>>>>
>>>>
>>>>
>>>> From:
>>>> Andy Goodrich <acg@forteds.com>
>>>> To:
>>>> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>>>> Cc:
>>>> John Aynsley <john.aynsley@doulos.com>
>>>> Date:
>>>> 20/01/2011 22:48
>>>> Subject:
>>>> Re: Another lib to check.
>>>>
>>>>
>>>>
>>>> The issue with sc_time_to_pending_activity() as coded is that there
> are
>>>> structures within the simulation context that have not been fully
>>>> initialized, so some of the checks that I need to perform cause
> illegal
>>>> accesses. I can use a call to sc_is_running() to detect that is the
>>> case.
>>>> Then I can return a value if the simulation is not running. should
> that
>>> be
>>>> SC_ZERO_TIME?
>>>> The vcproj issue was probably caused by my doing a cp command to
> install
>>>
>>>> it, I'll try just unzipping in place.
>>>> Sorry about missing the patch, I'll add the code.
>>>>
>>>> Andy
>>>>
>>>> On Jan 20, 2011, at 2:03 PM, Philipp A. Hartmann wrote:
>>>>
>>>> Andy, John,
>>>>
>>>> when toying with sc_time_to_futute_activity() and the step-wise
>>>> simulation, I've stumbled over a segfault. Probably, since I call
> this
>>>> function _before_ the elaboration has finished.
>>>>
>>>> John, do you think this needs to be clarified in the LRM?
>>>> Or can we derive from some other property, that the function should
>>>> return SC_ZERO_TIME in that case?
>>>>
>>>> Andy, two minor things wrt the patches I sent you:
>>>>
>>>> - float constructors seem to be missing in sc_ufix.h
>>>> (patch attached)
>>>>
>>>> - SystemC.vcproj has unix file endings, although you
>>>> _did_ ask for a verbatim copy :-(
>>>> (zipped version attached, hopefully preserving EOLs)
>>>>
>>>> Greetings from Oldenburg,
>>>> Philipp
>>>
>>>
>>>
>>
>>
>
>

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