RE: IM08 and IM09 - port ordering

Hi all,

I disagree with John on the issue of port ordering. Further, I thought that this was an issue we had already decided, and I don't see any new information being brought in to cause us to reconsider this.

As John points out, properly written applications should not need port ordering.

There are costs to implementing port ordering. One of these is that all messages will have to be held until the cclock advances. I don't think this is a good thing for either the end user or the infrastructure developer.

Just because the agreed changes were not put into the draft specification in a timely manner does not mean that we now have to change our earlier decision. I recommend we implement our earlier decision to drop port ordering.

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

> -----Original Message-----
> From: Stickley, John [mailto:john_stickley@mentorg.com]
> Sent: Friday, August 20, 2004 3:50 PM
> To: brian_bailey@acm.org
> Cc: Richard Newell; itc@eda.org
> Subject: 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
> ________________________________________________________________
>
>
Received on Mon Aug 23 18:59:24 2004