RE: suggested wording for message ordering

Duaine, all,

How does this rewording align with issues IM08/IM09, as
they are summarized on the issues list on the Accellera
website? In other words, are IM08 and IM09 not actually
'CLOSED', as indicated on the website?

Thanks,

Matt

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf
>Of Pryor, Duaine
>Sent: Thursday, September 23, 2004 1:02 PM
>To: 'Richard Newell'; itc@eda.org
>Subject: RE: suggested wording for message ordering
>
>
>Gentlemen,
>I think that we had a good discussion and reached consensus on
>at least part of the issues. I believe that we have
>agreement on the ordering of messages sent from hardware to software.
>
>On the ordering of messages sent from software to hardware,
>there are still some open issues.
>
>We discussed four possible orderings:
> global ordering
> Ordering within a thread
> Ordering within a port
> No ordering.
>No one advocated "no ordering".
>Richard advocated ordering within a port.
>Duaine advocated either global ordering or ordering within a thread.
>
>I've updated my proposal to reflect:
> The definition of message arrival as the time tx_rdy is
>asserted.
> Ordering based on order within a thread.
>
>This will probably take some more consideration to resolve.
>
>Duaine
>
>Location: pdf page 37, page #28
>Add a subsection on message ordering
>
>The idea of ordering message delivery to software arises from
>the fact that there is a global time order defined in the HDL
>domain by the order of cclock edges. The delivery of
>messages to software respects this ordering. In particular,
>the delivery of messages from hardware to software is ordered
>using the following rules:
>Messages from a single message out port are delivered to
>software in the same time order in which they are delivered to
>the port.
>Messages from different ports which are initiated by the
>dual-ready protocol on different cclocks are delivered to
>software in the time order in which they were presented.
>In the case that two message ports accomplish the dual-ready
>protocol and have data move in the same cclock cycle, the
>order of delivery of the messages to the software is undefined.
>
>
>Location: pdf page 61, page 53
>Since there is no global time on the software side, the
>ordering of messages from software to hardware must be
>accomplished by some other principle, native to software. On
>the software side, operations within a single thread are
>ordered while operations within separate threads are not
>ordered unless they are synchronized through mutex or
>semaphore constructs. The SCE-MI respects this order in the
>delivery of messages. In particular, messages sent from a
>single thread in the software are delivered to the HDL side,
>through the assertion of the infrastructures tx_rdy, in the
>order that the SceMiMessageInPortProxy::Send() calls are made.
> In a multithreaded or multiprocessor environment this
>requires the user to ensure the ordering of messages between
>threads or processors if this order is consequential. This
>can be accomplished using the mutex or semaphore constructs
>that all such environments provide.
>
>Duaine
>
>
Received on Tue Sep 28 07:56:24 2004