Re: sc_start

Sounds good, that is what I will implement.

Andy

On Jan 19, 2011, at 10:56 AM, Philipp A. Hartmann wrote:

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