Re: sc_start

I like the proposal for sc_get_pending_notification_time(), and agree with your analysis.

On Jan 13, 2011, at 4:01 AM, Philipp A. Hartmann wrote:

> John, all,
>
> I've spent some thought on this. I'm not convinced that
> sc_pause/sc_start(0) should do a time step.
>
> If sc_start(0) sometimes advances simulation time to the time of the
> next pending timed notification, it is not consistent with sc_start(T)
> (with T<earliest_pending).
>
> Usually, the following relation holds:
> sc_time T = …, now = sc_time_stamp();
> sc_start( T, … );
> sc_assert( sc_time_stamp() <= now + T ) // for all T.
>
> Breaking this relation seems to be very surprising. Moreover, it's
> not backwards compatible (current behaviour does not advance simulation
> time) in a quite silent and subtle way.
>
> For sc_pause, there would be no longer any (local) guarantee about the
> simulation time after the pause. This silently depends on the state of
> the rest of the system, which is surprising as well. With the potential
> time step at the end, one would need to manually inject
> an artificial delta notification to guarantee a pause at the
> current time.
>
> The issue we want to address is the advance to the earliest pending
> time, since this is currently not possible to determine. Maybe the
> correct solution is to add a function to retrieve the relative time of
> the next pending timed notification (semi-pseudo-code):
>
> sc_time sc_get_pending_notification_time()
> {
> if( sc_pending_activity_at_current_time() )
> return SC_ZERO_TIME;
> return (timed_notif_exist) ? timed_notif_time
> : sc_max_time()-sc_time_stamp();
> }
>
> You could then step through the simulation via
>
> while( sc_time_stamp() < sc_max_time() )
> sc_start( sc_get_pending_notification_time() );
>
> without any required changes to the delta cycle semantics.
>
> But then again, my original remark holds that an sc_start(0) without any
> activity should probably issue a warning. Whether or not we want to
> require this in the LRM is another question.
>
> Opinions?
>
> Greetings from Oldenburg,
> Philipp
>
> On 12/01/11 18:08, john.aynsley@doulos.com wrote:
>> Philipp, All,
>>
>> Good points. The existence of sc_start(0) and sc_pause() makes the
>> current definition of the delta cycle inadequate. I think the new
>> definition of a delta cycle needs to be
>>
>> a) An evaluation phase
>> b) An update phase
>> c) A delta notification phase
>> and if and only if the set of runnable processes is still empty
>> d) A timed notification phase
>>
>> That way, sc_start(0) will advance simulation time to the time of the
>> earliest pending delta notification, timed notification, or time-out,
>> and so will sc_pause(). In other words, each delta cycle ends by
>> advancing time, if necessary.
>>
>> Does that work?
>>
>> Cheers,
>>
>> John A
>>
>>
>> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>> To: Bishnupriya Bhattacharya <bpriya@cadence.com>,
>> "john.aynsley@doulos.com" <john.aynsley@doulos.com>, David C Black
>> <dcblack@xtreme-eda.com>
>> Cc: SystemC P1666 Technical <systemc-p1666-technical@eda.org>
>> Date: 12/01/2011 13:11
>> Subject: Re: sc_start
>>
>>
>>
>>
>>
>> Bishnupriya, David, John,
>>
>> sorry, I have missed your mails on this. I'll try to explain my concern
>> below. Replies to both of your mails embedded below. Especially
>> David's comments on the simulation time advance may require some
>> clarifications to the LRM.
>>
>> On 11/01/11 17:40, David C Black wrote:
>>> Just for clarification...
>>>
>>> I assume the concept of "no activity" includes "no opportunity to
>>> move time forward". In other words, if there are no pending
>>> processes, but a timed notification or wait, then the simulator
>>> should move the clock forward.
>>
>> Agreed. I had the "immediate starvation" in mind.
>> I'm not sure, what happens to the simulation time, though.
>>
>>> Should this cause a warning or not. I would argue no.
>>
>> Yes, when there's anything to do there's no need for a warning.
>> But as it stands now, the LRM says:
>>
>> "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. The value of the starvation policy argument shall be ignored."
>>
>> Note, that there's no 'timed notification phase', in case of an empty
>> delta notification queue. So maybe this needs to be clarified as well.
>> Otherwise, we don't have a mechanism to step to the next time stamp,
>> right? Am I missing something?
>>
>>> All timed events will result in some activity or eventual starvation
>>> (since something has to put the events in the queue in the first
>>> place, and conceptually with the intent some process will act on the
>>> events)
>>
>> A time step with immediate starvation is fine. The state of the
>> simulator has advanced. No need for a warning in that case.
>>
>> sc_time_stamp last = sc_time_stamp();
>> // if no current activity
>> sc_assert( ! sc_pending_activity_at_current_time() );
>> // after a delta step
>> sc_start( SC_ZERO_TIME );
>> // there should at least be a time step
>> sc_assert( sc_time_stamp() != last );
>>
>> But this may require changes to the wording of sc_start( SC_ZERO_TIME ).
>>
>> On 11/01/11 19:21, Bishnupriya Bhattacharya wrote:
>>>
>>> How does one run into an infinite loop, with code like below?
>>>
>>> do {
>>> sc_start(0);
>>> while (sc_pending_activity_at_current_time())
>>
>> You are right, with such a loop you'll not run into an endless loop.
>> But sc_pending_activity_at_current_time() is new in SystemC.
>>
>> Consider the following example:
>>
>> // write some stimuli to a DUT from sc_main here
>> // - but due to an error, e.g. missing sensitivity,
>> // no action is triggered
>>
>> // start simulation in a loop to obtain a stable output
>> do {
>> sc_start(0); // nothing is to be done, returns immediately
>> } while( ! dut.ready.read() ); // will never hold
>>
>> I don't say, that this is good modelling style. But I've seen this in
>> the past, and beginners are quite surprised to get an endless loop
>> instead of an error. Especially, if the simulation time is not advanced
>> as it seems to be intended by the current wording of the LRM.
>>
>> It may be just a quality of implementation issue, and not necessarily
>> require any changes to the LRM. It may still be good to add such a
>> check to an implementation.
>>
>> Greetings from Oldenburg,
>> Philipp
>>
>>> From: owner-systemc-p1666-technical@eda.org [
>> mailto:owner-systemc-p1666-technical@eda.org
>> <mailto:owner-systemc-p1666-technical@eda.org>] On Behalf Of
>> john.aynsley@doulos.com
>>> Sent: Tuesday, January 11, 2011 6:56 PM
>>> To: systemc-p1666-technical@eda.org
>>> Subject: sc_start
>>>
>>> All,
>>>
>>> Philipp writes:
>>>
>>> 5.3.4.2 Function sc_start
>>>
>>> "When function sc_start is called with a zero-valued time argument,
>> the scheduler shall run for one delta cycle,..."
>>>
>>> Should there be a warning, if no activity is due in that delta cycle
>> (sc_pending_activity_at_current_time() == false)? Otherwise, one can
>> easily run into an endless loop...
>
>
> --
> 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
>

------------------------------------------------------
David C Black, System-Level Specialist
XtremeEDA USA Corporation http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL design assurance needs)
Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609

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