Please change "HDL" in the first sentence to "hardware".
 
Also, regarding this sentence...
Messages from different ports which complete the dual-ready
protocol on different cclocks are delivered to software in the time
order in which the receive ready signals are asserted.  
 
We had agreed that the messages would be in cycle-stamp order.  Receive 
ready order may not always be the same as that.  I suggest the following wording:
Messages from different ports which complete the dual-readyprotocol on different cclocks are delivered to software in the order of their respective cycle stamps.
=======================================================


Here is the proposal for IM13
 
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 from hardware 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 complete the dual-ready
protocol on different cclocks are delivered to software in the time
order in which the receive ready signals are asserted.  
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.

===============================================================

Were you making any assumptions regarding the timing of messages originating on
the software side?
 
For example, did you assume that outbound messages would be presented 
(i.e., "transmit ready") on particular u-clk ticks (simultaneously, or 
in a particular order)?  If so, how does the use of the 
service loop influence this?  What if the service loop is called in an 
independent thread?

Issue extension

so far we have been discussing message ordering for the output
ports.  But what of the input ports?  I have not seen anything
in the spec that tells me what the requirements for message
ordering on input ports are, if any.  I think it is fair to
assume that messages to the same ports arrive at the port in
the same order they are sent [1].  But what about messages sent
to different ports?  If I send message 1 to port 1 before I send
message 2 to port 2, should message 1 arrive at port 1 before
message 2 arrives at port 2 (the notion of before relates to
uclock cycles)?  Or is the implementation free to choose how to
service the queue of pending input messages?  Is there an
implementation choice between a single (virtual) queue or 
multiple (per-port) queues?

[1] This is a nit, but we should add a sentence to the spec
saying that message ordering within a port (input as well as
output) is strictly preserved.

=================================================================================

The existence of global time in the HDL side gives a natural order to
two messages which occur at different uclocks.   So if message A occurs
at uclock u(A) and message B occurs at u(B) then A happens before B if
u(A) < u(B).    That order was respected for message delivery.    

> It seems to me that there are four levels at which message ordering
> for output ports comes in to play:
>
>  1) Arrival at the port, i.e., when is TransmitReady asserted;
>
>  2) Order in which messages are acknowledged by the infrastructure,
>     i.e., when is ReceiveReady asserted;
>
>  3) Order in which messages are transferred to the SW side;
>
>  4) Order in which Receive() callbacks are called.
>
>I assume (4) is the most important and should reflect (1).  Is there
>also a requirement that (2) reflects (1)?  That would seem to make
>sense because it will affect the HDL side.  I assume (3) is
> irrelevant to the application as long as (4) reflects (1).

>> DWP=> Yes, 4 should reflect 1, that give the total order.
>> Also, 2 reflects 1 due to the port priority scheme.

This allows synchronous or reactive models as well as asynchronous or
streaming ones to be written easily.   In the case that u(A)==u(B) there
is some ambiguity in ordering.   This is where the priority mechanism came in.


Especially with reactive models, which could implement state machines based
on the messages they receive, the global time of HDL must be respected.
If implementations were allowed to ignore the global time in HDL, synchronous
and reactive models would become far too difficult to implement.


Since the software side has no notion of global time other than that inherited
through its interaction with HDL, the requirements for ordering of input messages
are different.   


> Are you saying that for input ports the implementation is *not*
> required to guarantee that if message A is Send() before message B,
> that message A shows up (TransmitReady asserts) at the HDL side
> before message B?
> 
> I propose that text is added to the standard to spell out the
> message ordering requirements (assuming the commitee agrees to
> them).

>> DWP=> Remember that the software can be multithreaded as well, so A before B
>> does not make sense in all cases.   If A and B are sent by the same thread,
>> the implementation should probably guarantee order is some sense.  

The user is responsible for guaranteeing one of three conditions:

 

	Input Message A happens before input message B

	Input Message B happens before input message A

	the order of input messages A and B is irrelevant.

Duaine

===================================================================================