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] 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 12 05:11:44 2011
This archive was generated by hypermail 2.1.8 : Wed Jan 12 2011 - 05:11:48 PST