RE: IM13

Hi Duaine,

> 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).

> 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).

Per
Received on Wed Mar 24 13:28:43 2004