Re: sc_start

John, Bishnupriya,

answers below.

On 13/01/11 17:14, john.aynsley@doulos.com wrote:
>
> Having re-read this thread, I am a bit confused. Let me recap what I
> think we have concluded:
>
> sc_time now = sc_time_stamp();
> sc_start(SC_ZERO_TIME);
> sc_assert( sc_time_stamp() == now);
>
> Right? I am fine with that.

Yes. Same for

  extern sc_time pause_time;

  pause_time = sc_time_stamp(); // ... somewhere in a process
  sc_pause();
  wait();
  // ...
  sc_start( ... );
  sc_assert( sc_time_stamp() == pause_time );

This is essentially as it is defined with the current delta cycle semantics.

> Re. sc_start(0) issuing a warning if no activity happened, this is
> equivalent to
>
> if ( sc_pending_activity_at_current_time() )
> sc_start(SC_ZERO_TIME);
> else
> SC_REPORT_INFO("", "In effect, the implementation would issue
> this warning instead of the application?");
>
> In other words, "no activity" means
> !sc_pending_activity_at_current_time() when sc_start(0) is called,
> right? I am neutral on making this change to the LRM.

Yes. I like Bishnupriya's suggestion to make the warning optional ("may
or may not"). Another issue here is the delta_count, when there's no
activity:

  sc_dt::uint64 delta = sc_delta_count();
  sc_start(0);
  sc_assert( sc_delta_count() == delta + 1);

Should this hold in all cases (even when there's no activity)?
In the PoC, the delta count is always incremented.

> Re. adding further functions, I like Bishnupriya's suggestion of:
>
> bool sc_pending_activity_at_current_time();
> bool sc_pending_activity_at_future_time();
> bool sc_pending_activity();

I also like this idea.

To complete this set of functions to achieve a step-wise walk through
the simulation, the relative _time_ of the next activity should be
accessible as well, right?

sc_time sc_next_pending_activity()
returns:
  · SC_ZERO_TIME,
       iff sc_pending_activity_at_current_time() == true
  · _relative_ time until next timed notification,
       iff sc_pending_activity_at_future_time() == true
  · sc_max_time() - sc_time_stamp(),
       otherwise

  The reason for 'sc_max_time() - sc_time_stamp' in the "other" case
ensures, that it if safe to call sc_start( sc_next_pending_activity() )
at all times, resulting in said step-wise walk.

> From: Bishnupriya Bhattacharya <bpriya@cadence.com>
> To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>,
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc: David C Black <dcblack@xtreme-eda.com>, SystemC P1666 Technical
> <systemc-p1666-technical@eda.org>
> Date: 13/01/2011 14:53
> Subject: RE: sc_start
>
>
>
>
>
> John, Philipp,
>
> I strongly agree with Philipp that delta cycle semantics should not be
> changed, and neither should sc_start(0) advance time.
>
> I'm fine with sc_pending_notification_time(). The other alternative,
> symmetric to sc_pending_activity_at_current_time() is to provide "bool
> sc_pending_activity_at_future_time()", which returns true if there are
> pending timed notifications. Then we can even provide "bool
> sc_pending_activity()" which is the 'or' of these 2 APIs.
>
> I also see Philip's point about sc_start(0) issuing a warning if no
> activity happened. I'm neutral about LRM mandating this. I would vote
> for LRM using wording like "may or may not".

[snip]

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