Re: LRM clarification re sc_start

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.