Re: Another lib to check.

From: <john.aynsley@doulos.com>
Date: Fri Jan 21 2011 - 02:54:06 PST

Philipp, Andy,

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.

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.

John A

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
[attachment "time_to_pending.cpp" deleted by John Aynsley/doulos] 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Jan 21 02:54:55 2011

This archive was generated by hypermail 2.1.8 : Fri Jan 21 2011 - 02:55:05 PST