Wording proposal for request_safe_update

From: David C Black <dcblack@xtreme-eda.com>
Date: Sun Nov 21 2010 - 00:51:40 PST

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, and is
believed to be clean.
Received on Sun Nov 21 00:52:39 2010

This archive was generated by hypermail 2.1.8 : Sun Nov 21 2010 - 00:52:41 PST