RE: suggested wording for message ordering

See comments, below.

<<begin Duaine>>
-----Original Message-----
From: Pryor, Duaine [mailto:duaine_pryor@mentorg.com]
Sent: Thursday, September 09, 2004 2:24 PM
To: 'itc@eda.org'
Subject: suggested wording for message ordering

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.
<<end Duaine>>

<<Rich>> I suggest that "HDL domain" be changed to "hardware domain".

<<begin Duaine>>
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. The principle used is wall-clock time. Messages sent from the software to the HDL side are delivered in the order that the send functions are called. 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.
In particular, messages are delivered to the hardware side in the order that the SceMiMessageInPortProxy::Send() calls are made. This implies that within any single thread, messages are delivered in order, but between threads ordering is undefined unless the user coordinates the order of calls.

Duaine
<<end Duaine>>

I object to introducing message ordering requirements for messages going from the software to the hardware side.

The proposal implies that if an outbound message is held up for any reason, for example if the transactor in-port it is going to is "not ready", then all subsequent messages to any and all ports must be queued. Even those destined for other in-ports that are "ready" must be held back by the infrastructure until the oldest message can be delivered. This imposes undue requirements of storage and performance on the infrastructure, or alternatively a large performance penalty on the user.

It seems we are trying to implement a concept of time in the wrong way. The proposals that Joe Sestrich of Zaiq made some time ago are a better way of controlling time and/or order dependent operations. I propose we table the wording Duaine has proposed until we have had a chance to consider Joe's proposals fully, as part of the version 2 work.

Rich

________________________________________________________
G. Richard Newell Director, Hardware Product Marketing
Aptix Corporation 1249 Innsbruck Drive
Sunnyvale California 94089
Email: richardn@aptix.com
Phone: +1 (408) 882 4785
Fax (US only): (877) 684 4835
Received on Wed Sep 15 18:13:42 2004