Okay, that's what I will write up in the draft LRM.
John A
-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "Philipp A. Hartmann" <philipp.hartmann@offis.de>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 01/19/2011 05:31PM
Cc: Andy Goodrich <acg@forteds.com>, SystemC P1666 Technical <systemc-p1666-technical@eda.org>
Subject: RE: sc_start
John,
Â
I’m ok with both of these.
Â
Thanks,
-Bishnupriya
From: 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>
To:
john.aynsley@doulos.com
Cc:
Bishnupriya Bhattacharya <bpriya@cadence.com>, Andy Goodrich <acg@forteds.com>, SystemC P1666 Technical <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 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> wrote: -----
> To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> From: Bishnupriya Bhattacharya <bpriya@cadence.com>
> Date: 01/18/2011 05:33PM
> Cc: "acg@forteds.com" <acg@forteds.com>, P1666 Technical WG Â Â Â Â Â Â Â Â <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
> Cc: 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://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 19 11:09:13 2011
This archive was generated by hypermail 2.1.8 : Wed Jan 19 2011 - 11:09:15 PST