Re: sc_start

Andy,

see below for a proposal.

On 19/01/11 19:16, Andy Goodrich wrote:
> A couple of questions:
>
> (1) What should sc_time_to_pending_activity() return if there is no
> future activity?

  sc_max_time() - sc_time_stamp()

> (2) Should sc_time_to_pending_activity() return a delta from the current
> time or an absolute time?

  delta to the current time

Both choices are consistent with the desired use case to run the
simulation step-wise in a loop:

  // while( sc_future_activity() ) - or
  while( sc_time_stamp() < sc_max_time() )
    sc_start( sc_time_to_pending_activity(), SC_RUN_TO_TIME );

Greetings from Oldenburg,
  Philipp

> On Jan 19, 2011, at 9:31 AM, Bishnupriya Bhattacharya wrote:
>
>> John,
>>
>> I’m ok with both of these.
>>
>> Thanks,
>> -Bishnupriya
>> *From:* john.aynsley@doulos.com
>> <mailto:john.aynsley@doulos.com> [mailto:john.aynsley@doulos.com]
>> *Sent:* Wednesday, January 19, 2011 3:05 PM
>> *To:* Philipp A. Hartmann
>> *Cc:* Andy Goodrich; Bishnupriya Bhattacharya; SystemC P1666 Technical
>> *Subject:* Re: sc_start
>>
>>
>> Philipp, All,
>>
>> sc_time sc_time_to_pending_activity() was just an oversight. I have
>> added it to the LRM.
>>
>> You and I now support the following proposal:
>>
>> * sc_delta_count is only incremented after each evaluation phase in
>> which at least one process runs.
>>
>> *Opinions, anyone else?*
>>
>> Re sc_signal events, I agree with the proposed change the LRM (and
>> similar changes for other methods):
>>
>> "Member function *event *shall return the value *true *if and only if
>> the value of the channel was written or modified in the immediately
>> preceding delta cycle*and at the current simulation time*"
>>
>> *Opinions, anyone else?*
>>
>> Thanks,
>>
>> John A
>>
>> From:
>>
>> "Philipp A. Hartmann" <philipp.hartmann@offis.de
>> <mailto:philipp.hartmann@offis.de>>
>> To:
>>
>> john.aynsley@doulos.com <mailto:john.aynsley@doulos.com>
>> Cc:
>>
>> Bishnupriya Bhattacharya <bpriya@cadence.com
>> <mailto:bpriya@cadence.com>>, Andy Goodrich <acg@forteds.com
>> <mailto:acg@forteds.com>>, SystemC P1666 Technical
>> <systemc-p1666-technical@eda.org
>> <mailto:systemc-p1666-technical@eda.org>>
>> Date:
>>
>> 18/01/2011 20:37
>> Subject:
>>
>> Re: sc_start
>>
>>
>>
>>
>>
>>
>> John,
>>
>> comments embedded.
>>
>> On 18/01/11 19:55, john.aynsley@doulos.com
>> <mailto:john.aynsley@doulos.com> wrote:
>> >
>> > Okay. I will add
>> >
>> > bool sc_pending_activity_at_current_time();
>> > bool sc_pending_activity_at_future_time();
>> > bool sc_pending_activity();
>>
>> What about:
>>
>> sc_time sc_time_to_pending_activity();
>>
>> I would like to see this added as well.
>>
>> > and make the "no activity" warning from sc_start(0) mandatory.
>> >
>> > I propose what I think is a simple rule: sc_delta_count is
>> incremented after each evaluation phase in which at least one process
>> runs. There are two justifications:
>> > - Aside from the questions over sc_start(0) and starting after
>> sc_pause(), there anyway at least one runnable process when the
>> scheduler reaches the eval phase
>> > - It avoids having surprising jumps in the value of sc_delta_count,
>> i.e. values that are not visible from ANY process
>> >
>> > If we find this proposal actually breaks anything, I will withdraw it.
>>
>> I concur with this proposal. I can't think of real code (apart from
>> regression tests comparing delta count outputs) that would break.
>>
>> Since you don't have explicit control over the delta counts needed at
>> each time step without looking at the system as a whole, there's not
>> much you can do with the delta count except the decision whether you are
>> in a different one.
>>
>> > If sc_start(0) always causes the delta count to increment even if no
>> processes run (I've not checked whether that is actually true,
>> either), I think that might be an anomaly.
>>
>> Yes, it is. The following prints "6" with the PoC implementation:
>>
>> #include <systemc.h>
>> int sc_main( int, char*[] )
>> {
>> for( int i=0; i<5; i++ )
>> sc_start( 0, SC_NS );
>> std::cout << sc_delta_count() << std::endl;
>> return 0;
>> }
>>
>> > The primitive channel event methods seem very fragile whatever, and
>> we should probably resolve that issue too. The LRM says "Member
>> function event shall return the value true if and only if the value of
>> the channel was written or modified in the immediately preceding delta
>> cycle." What is that supposed to mean? 8=(
>>
>> I agree, that we should clarify the specification here.
>> As said in my last mail, it might be sufficient to look at the
>> simulation time as well:
>>
>> "Member function event shall return the value true if and only if
>> the value of the channel was written or modified in the immediately
>> preceding delta cycle AT THE SAME TIME STAMP."
>>
>> Fortunately, sc_signal does not support delays as VHDL signals do.
>> Consequently, the event should always occur exactly one delta cycle
>> after the write.
>>
>> I can see that this may theoretically break existing models, that
>> somehow manage to exploit the current anomaly. But to me, the
>> 'immediately preceding delta cycle' is clearly at most zero seconds
>> ago… ;-)
>>
>> Greetings from Oldenburg,
>> Philipp
>>
>> > -----Bishnupriya Bhattacharya <bpriya@cadence.com
>> <mailto:bpriya@cadence.com>> wrote: -----
>> > To: "Philipp A. Hartmann" <philipp.hartmann@offis.de
>> <mailto:philipp.hartmann@offis.de>>, "john.aynsley@doulos.com
>> <mailto:john.aynsley@doulos.com>" <john.aynsley@doulos.com
>> <mailto:john.aynsley@doulos.com>>
>> > From: Bishnupriya Bhattacharya <bpriya@cadence.com
>> <mailto:bpriya@cadence.com>>
>> > Date: 01/18/2011 05:33PM
>> > Cc: "acg@forteds.com <mailto:acg@forteds.com>" <acg@forteds.com
>> <mailto:acg@forteds.com>>, P1666 Technical WG
>> <systemc-p1666-technical@eda.org <mailto:systemc-p1666-technical@eda.org>>
>> > Subject: RE: sc_start
>> >
>> > John, Philipp,
>> >
>> > I'm on the same page with you wrt sc_start(0) issuing a mandatory
>> warning when no processes run in the eval phase, and adding the API
>> 'sc_time sc_time_to_pending_activity()'.
>> >
>> > Things are less clear to me as far as sc_delta_count() is concerned.
>> What rule are we converging to? Delta count will not be incremented
>> unless at least one process runs in the eval phase? Do we have a clean
>> set of rules?
>> >
>> > The alternative is delta count is incremented every time eval phase
>> executes, including non-active sc_start(0) calls, as it does now. What
>> is the downside of keeping the rules unchanged, as they are now?
>> Agreed it is not as clean, but I don't see a clear alternate picture
>> either. That sc_start(0) executes one delta cycle has been in the LRM
>> for a long time now, so we are not introducing any new delta count
>> related issues with that semantics. The
>> sc_pending_activity_at_current_time() and such APIs are new, but those
>> actually make life better here, by providing a means of cutting back
>> on unnecessary wheel spinning. The mandatory warning will also make
>> things better. So can't we just recommend in the LRM to use the new
>> APIs and leave the simple rule that every time eval phase is executed,
>> delta count increments (or whatever the current rule is).
>> >
>> > My 2 cents.
>> >
>> > Thanks,
>> > -Bishnupriya
>> >
>> > -----Original Message-----
>> > From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
>> > Sent: Tuesday, January 18, 2011 8:45 PM
>> > To: john.aynsley@doulos.com <mailto:john.aynsley@doulos.com>
>> > Cc: acg@forteds.com <mailto:acg@forteds.com>; Bishnupriya
>> Bhattacharya; P1666 Technical WG
>> > Subject: Re: sc_start
>> >
>> > John,
>> >
>> > you're right, sc_signal::event is indeed already fragile.
>> > So maybe we're not really breaking "correct" models, when we're changing
>> > its innards.
>> >
>> > I think, a better implementation could take the current time into
>> > account as well. Something like:
>> >
>> > sc_time_stamp() == m_time
>> > && sc_delta_count() == m_written_delta + 1
>> >
>> > Would this work?
>> >
>> > I'm not sure, if we should restrict its use to sensitive processes. A
>> > run-time check for this would be too costly, making it simply undefined
>> > would be no benefit.
>> >
>> > Maybe we should make its use from other processes
>> > implementation-defined for now. This would give us the room to work on
>> > a rigorous definition in the LWG.
>>
>> [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://www.offis.de/
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.