RE: IM08 and IM09 - port ordering

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

Phone: +1 (408) 882 4785

Fax (US only): (877) 684 4835

 
Received on Tue Aug 3 08:02:37 2004