RE: IM13

-----Original Message-----
From: Bojsen, Per [mailto:bojsen@zaiqtech.com]
Sent: Wednesday, March 24, 2004 1:28 PM
To: Pryor, Duaine; ''itc@eda.org' '
Subject: 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).

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

> 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?

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.

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 15:31:26 2004