Re: Wording proposal for request_safe_update

John,

Although, this might appear to be in support of a parallel SystemC
implementation that is *not* its intent. Nor do I think it would suffice in
that vein. This addition simply provides another mechanism for modeling when
part of the solution likes outside the SystemC domain and requires
interaction with other OS threads or processes.

On Mon, Nov 22, 2010 at 10:00 AM, <john.aynsley@doulos.com> wrote:

> All
>
> Clearly there is some support for David's proposal. The only question is
> whether this should be punted to the LWG for consideration alongside the
> parallel SystemC discussion or whether we are ready to go for IEEE 1666
> standardization right away.
>
> What do people think?
>
> John A
>
>
>
> From: "Jeremiassen, Tor" <tor@ti.com> To: Jerome CORNET <
> jerome.cornet@st.com>, David C Black <dcblack@xtreme-eda.com>, "
> systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org> Date: 22/11/2010
> 14:00 Subject:
> RE: Wording proposal for request_safe_update
> Sent by: owner-systemc-p1666-technical@eda.org
> ------------------------------
>
>
>
> All,
>
> TI fully supports the proposal for request_safe_update.
>
> Tor
>
>
> ---
> Tor Jeremiassen, Ph.D.
> Simulation and Modeling CTO
> SDO Foundational Tools
> Texas Instruments Ph: 281 274 3483
> P.O. Box 1443, MS 730 Fax: 281 274 2703
> Houston, TX 77251-1443 Email: *tor@ti.com* <tor@ti.com>
>
> ------------------------------
>
> *From:* owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org<owner-systemc-p1666-technical@eda.org>]
> *On Behalf Of *Jerome CORNET*
> Sent:* Monday, November 22, 2010 7:05 AM*
> To:* David C Black; systemc-p1666-technical@eda.org*
> Subject:* RE: Wording proposal for request_safe_update
>
> All,
>
> I am fully in favor of the proposal, which has the advantage of simplicity
> (and for which an implementation is proposed).
> At ST, we have previously envisaged to make a different proposal, involving
> callbacks of the scheduler, but we have decided it would be beneficial
> and simpler to converge on David’s. Just a note to say that we are dealing
> with the same kind of use cases [as described in David’s previous email]
> here.
>
> Regards,
>
> Jerome
>
> *From:* owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org<owner-systemc-p1666-technical@eda.org>]
> *On Behalf Of *David C Black*
> Sent:* Sunday, November 21, 2010 9:52 AM*
> To:* systemc-p1666-technical@eda.org*
> Subject:* Wording proposal for request_safe_update
>
> I believe my proposal should have the following effects:
>
> - Change most references to "*request_update*" to read "*request_update
> * or *request_safe_update*". In some text when referring to to "*
> request_update* and *update*", use the language "*request_update*, *
> request_safe_update* and *update*"
> - In section 6.15.1 (page 135) insert a line after "void *
> request_update*():"
> void *request_safe_update*();
> - In section *6.15.6* (page 136), retitled "*request_update,
> request_safe_update and update*" add:
> void *request_safe_update*();
> Member function *request_safe_update* shall cause the scheduler to
queue an update request for the specific primitive channel instance making
> the call. It differs from *request_update* in that it will
 implemented
> in an OS thread safe manner that allows it to be called reliably from
> outside the simulator OS thread. It may have a performance degradation
> relative to *request_update* due to the use of mutex or other
> mechanisms for thread safety.
>
>
>
> - Potentially add
>
> NOTE 3 - Due to the asynchronous nature of calls to *request_safe_update*,
> it is necessary that code implementing the update phase must take care when
> handling updates from the set of safe update requests. It is possible for a
> *request_safe_update* call to be made at anytime from start of simulation
> including during the update phase.
> NOTE 4 - There shall be no guarantees as to whether a call to *
> request_safe_update* shall be acted upon in the current delta cycle or the
> one immediately following. It is only guaranteed that the request will
> honored within one of two possible delta cycles, the current one or the one
> following.
> NOTE 5 - *request_safe_update* is not recommended for use in normal *
> sc_prim_channel*'s, and should be reserved to channels requiring
> asynchronous interface to the simulator itself.
>
> I'm not sure much else needs to be added.
>
> David
>
>
>
> --
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> 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.