RE: Wording proposal for request_safe_update

I believe this is a separate issue from the parallel SystemC discussion and should be standardized now.

Best regards,

Tor Jeremiassen


---
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<mailto:tor@ti.com>

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, November 22, 2010 10:00 AM
To: Jeremiassen, Tor
Cc: David C Black; Jerome CORNET; owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org
Subject: RE: Wording proposal for request_safe_update

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<mailto:tor@ti.com>

________________________________

From: owner-systemc-p1666-technical@eda.org [mailto: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] 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.