Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: MAC delay constraint




Gareth,

We did discuss delay constraints at the meeting. There were quite a few good
comments on them in the ballot especially ones by Adam Healey which
contained analysis showing that some of the current numbers were to small
and proposed more achievable values. The editor's took away an action item
to make the delay specs more consistant from clause to clause and to assure
that d2.1 has a consistant set of numbers that will allow interoperability
at our interoperability interfaces.

I'm not sure what you meant to say in your last comment. We cannot get
interoperability by just having an overall spec. We need specs that will
allocate the delay to each side of compatability interfaces and that is what
we agreed to do.

If you want to be part of what's going on, you really need to participate in
the comment generation and resolution process. Reflector discussions can
help bat ideas around, but they aren't what changes the draft. 

Pat

-----Original Message-----
From: Gareth Edwards [mailto:Gareth.Edwards@xxxxxxxxxx]
Sent: Wednesday, January 24, 2001 10:16 AM
To: HSSG
Cc: Shimon.Muller@xxxxxxxxxxx
Subject: MAC delay constraint



Hello all,

I watched with interest in December as a discussion started on the
reflector on delay constraints within the various clauses, which then
diverged into a discussion on what constituted a point-to-point link and
what the effects of 40km of fiber would be. Neither discussion addressed
the point at hand, namely the bounding of delays in layers, consistent
with some budget defined in clause 31.

For instance, in clause 46.2.7 and table 46-5 of the D2.0 draft, the end
to end delay time for the MAC+RS is specified at 256 bit times. The PCS
has a similar specification which is equivalent to 1024 bit times but is
quoted in ns to avoid coded/uncoded bit time confusion. Clause 51 PMA
indicates that there is a minimum of 16 (coded) bit time delay due to
the serdes function, but places no upper bound on what this delay could
be. The clause 52 PMD has no specified delay, but an editor's note
saying something along the lines of "This is not important anymore".

Leaving for now the obvious stylistic inconsistencies, there is a total
budget in clause 31B.3.7 for MDI->MAC Control->MDI of 40 pause_quanta. I
can only see 5 pause_quanta accounted for in the above specification.
Have we underestimated the requirements for delay within the sublayers,
given the total requirement? 

Does anyone else see this? I think Shimon does, but his comment at
Irvine was rejected on the basis that it proposed to drop individual
layer constraints in favour of the 31B.3.7 spec; this makes
interoperability difficult at best.

Cheers
Gareth

--
/ /\/\ Gareth Edwards               mailto:gareth.edwards@xxxxxxxxxx
\ \  / Design Engineer
/ /  \ System Logic & Networking    Phone:   +44 131 666 2600 x234
\_\/\/ Xilinx Scotland              Fax:     +44 131 666 0222