Re: IM08 and IM09 - port ordering

ITC Team,

I don't think it hurts to leave port ordering in there.
It is a nice measure to insure consistent message ordering
of arrival on the S/W side when multiple output messages
are sent at once.

Such consistency only promotes better interoperability
among different implementations.

I do however agree with Richard's suggestion of changing
uclock to cclock.

Presumably the source of an output message is from a clocked
DUT module anyway. So, if a message transmit request
is asserted on a given cclock, it will, by definition,
be asserted on the same uclock. But I agree with Richard
that it is better to express in terms of cclocks.

So, basically what we're saying is:

- If the user has gone to the trouble to assign different
    message priorities to different ports, and,
- If messages to those ports arrive on the same cclock,
- Then, the assigned port priorities will guarantee a specific
   order of arrival of those messages on the host side.

This is the spirit of what this feature was originally trying
to accomplish.

Now, assuming all ports are of unassigned (therefore default 10)
priority or are otherwise equal priority, then the order
of message arrival on the host is implementation dependent and
undefined.

But port priority, when set, and when differentiated among ports,
would at least lead to consistent ordering of arrival
among implementations and this mechanism could be used in cases
where ordering of simultaneous messages matters. That said,
properly written applications should not care about the arrival
ordering of simultaneously transmitted messages.

An analogy to this is that well written VHDL or Verilog application
should not care about what order active processes are executed
in a given delta cycle.

So, aside from changing uclock to cclock as Richard suggested,
I would recommending leaving the latest wording unchanged.

I also agree with Richard that "with some exceptions" here
is confusing.

> With some exceptions, the output port priority must follow the following
> semantics:
>

Let's just remove it as follows:

"The output port priority must follow the following semantics:"

-- johnS

Brian Bailey wrote:
> Hi Richard,
>
> I may be confusing everything here I am afraid as I think there was
> an agreement to completely drop the port ordering. I again forgot to
> take it out of the latest rev of the document.
>
>
>
> Brian
>
>
>
> ------------------------------------------------------------------------
>
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Richard
> Newell
> Sent: Monday, August 02, 2004 2:08 PM
> To: itc@eda.org
> Subject: IM08 and IM09 - port ordering
>
>
>
> Hi all,
>
>
>
> In the latest version of the spec posted
> (http://www.eda.org/itc/open/scemi-104.pdf) the port ordering paragraphs
> read as follows:
>
>
>
> ------------------------------------------------------------------------
>
> (part of paragraph "5.2.3.1 Parameters" on page 28)
>
>
>
> PortPriority
>
> The priority for determining which output messages are sent to the
> output channel first if more than one of them
>
> arrive on the same uclock . See 5.3.1 for more details.
>
> ------------------------------------------------------------------------
>
> (part of paragraph "5.3.1 Parameters" on page 37)
>
>
>
> Message output port priority
>
> The priority of a message output port shall be derived from the
> PortPrority parameter defined in the Sce-MiMessageOutPort macro. This
> must be used by the infrastructure linker to decide which output ports
> to service first (when they present message data on the same uclock) and
> are implemented over a number of "physical message channels" which is
> less than the limitless number of virtual message channels. For those
> who do not care, the default value of 10 does not need to be overridden
> and need not be specified in the instantiation statement.
>
>
>
> With some exceptions, the output port priority must follow the following
> semantics:
>
>
>
> ? 0 < allowed priority values < 20 ? The default priority value is 10 .
>
> ? The lower the number, the higher the priority.
>
> ? Output port priority 0 is reserved for internal use by the infrastructure.
>
> ? For message output ports with the same priority number, their relative
> priority is undetermined and
>
> strictly an artifact of infrastructure linker implementation.
>
> ------------------------------------------------------------------------
>
>
>
> I distinctly remember an agreement reached that port ordering would be
> done on the basis of cclock cycles, not on uclock cycles as currently
> worded. I think "uclock" should be replaced with "cclock" in these two
> paragraphs.
>
>
>
> Also, in reviewing the wording, I find the reference to the
> "infrastructure linker" here a little out of place. It seems to imply
> that the infrastrucutre linker is part of the run-time mechanism that
> orders the data. I would suggest replacing "infrastructure linker" with
> just "infrastructure".
>
>
>
> Lastly, I am not sure what "exceptions" are being referred to. Is there
> a reason for that clause?
>
>
>
> Rich
>
>
>
>
>
>
>
>
>
>
>
>
>
> ________________________________________________________
>
> G. Richard Newell Director, Hardware Product Marketing
>
> Aptix Corporation 1249 Innsbruck Drive
>
> Sunnyvale California 94089
>
> Email: richardn@aptix.com
> <mailto:richardn@aptix.com>
>
> Phone: +1 (408) 882 4785
>
> Fax (US only): (877) 684 4835
>
>
>

-- 
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________