Date: Wed Jan 19 2011 - 07:17:57 PST
I am also in favor of enforcing Verilog semantics and deprecating all cases where a running process is required to notice an immediate notification from itself.
[cid:image002.jpg@01CBB7A8.FF1B7790]<http://www.cadence.com/>
Michael McNamara | Vice President and General Manager, System Level Design
M: 1.408.348.7025 W: www.cadence.com<http://www.cadence.com/> E: mcnamara@cadence.com
[cid:image003.png@01CBB7A8.FF1B7790]<http://www.linkedin.com/in/michaeltymcnamara> [cid:image004.gif@01CBB7A8.FF1B7790] <http://www.verilog.com/>
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, January 19, 2011 7:15 AM
To: Philipp A. Hartmann
Cc: Bishnupriya Bhattacharya; David Black; Jerome CORNET; P1666 Technical WG
Subject: Re: P1666 surprising result with immediate notification
Philipp, Jerome,
This is all good stuff, but since we have already punted process priorities and process parallelization to the LWG, I guess we should punt yield() to the LWG as well. I am not opposed to introducing yield at some stage.
I keep with the proposal to clarify the LRM to enforce the "Verilog semantics" and to deprecate all cases where a running process is required to notice an immediate notification send from itself (preferably with a warning from the PoC Sim)
John A
From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com, Jerome CORNET <jerome.cornet@st.com>
Cc:
Bishnupriya Bhattacharya <bpriya@cadence.com>, David Black <dcblack@xtreme-eda.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Date:
19/01/2011 14:59
Subject:
Re: P1666 surprising result with immediate notification
________________________________
John, Jerome,
Is it really necessary to have a yield() function in the core language?
We should at least choose a less conflicting name, like sc_yield(), if
we consider to allow this from within channels etc. as well.
If there's a valid use case for such a functionality (which I don't
see yet), an implementation can easily build it on top of the existing
(and proposed) immediate notification semantics already.
All you need are two events and a "pingback" method process:
sc_event yield_request_event, yield_ack_event;
SC_METHOD(yield_pingback);
sensitive << yield_request_event;
void yield_pingback() { yield_ack_event.notify(); }
void yield() // will return in the current evaluation phase!
{
yield_request_event.notify();
wait( yield_ack_event );
}
In a small example attached to this mail, a PoC class
'sc_utils::yieldable' is defined that you can inherit in addition to
sc_module to have a yield() available in your module.
What's not possible with this implementation is a yield() from within
an SC_CTHREAD, though. But this is also not possible with the current
(broken) notification semantics, right?
Greetings from Oldenburg,
Philipp
On 19/01/11 12:41, john.aynsley@doulos.com wrote:
> Jerome, All,
>
> Consider the following definition:
>
> void yield(); can be called from a thread process only. (Clocked
> thread???). It is like a wait in the sense that it yields control to the
> kernel, but unlike a wait in the sense that it also adds the yielding
> process to the set of runnable processes in the current evaluation phase.
>
> Of course, the difficulty in SystemC is that the scheduler is not fair, so
> the process in question might be the very next process to be selected by
> the scheduler, and so on ad infinitum as long as the same process keeps
> calling yield. Without some other modification to the scheduling
> algorithm, such a yield does not seem very useful in SystemC as it stands.
> (I am not opposed to us considering such modifications)
>
> Cheers,
>
> John A
[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 [attachment "yield.cpp" deleted by John Aynsley/doulos] -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
