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 Thu Sep 23 10:02:47 2004