| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Leaving aside the questions of style, Ali does make some
very interesting points.
While IEEE standards are not written for a specific
implementation, the science
of high frequency interconnects is only usefully revealed
in relatively specific
examples with relatively specific requirements. Those
examples depend heavily on the
requirements of the market and on the choice of hardware
boundaries among
the required functions. An IEEE standard that does
not take these requirements into account
is interesting, but not very useful.
An XLAUI and CAUI chip to chip signal definition is one of
those interfaces that
will not be very useful. Most implementations will
probably choose to integrate
as much of that high speed function internal to their
protocol and switch ASICs
as possible. It is only when the XLAUI and CAUI
get defined for "the real
world" through ASICs providing signal to backplane
interconnects and through
motherboard-to-module interconnects
that the standard becomes helpful by allowing
interoperable connectivity.
It seems to me that IEEE could legitimately take on the
challenge of creating
specific and therefore useful electrical definitions for
backplanes and
motherboard-to-module interconnects, hopefully with
significant input about
the market and architectural requirements.
Alternatively,
they could lay aside the XLAUI and CAUI signal definitions
and allow them to
be refined through MSAs specific to the architectural
and marketing requirements.
What would not be very helpful is a generic and
non-specific nAUI electrical specification.
Bob Snively From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] Sent: Monday, December 22, 2008 12:09 PM To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx Subject: Re: [802.3BA] XLAUI / CAUI Ad Hoc Ali, Thank you for
your comments. I was
disappointed that you chose to use one of the less constructive approaches of
engaging in a discussion, which is to attribute to me a weak argument that I did
not make, so that you can then easily refute it and hold it up to ridicule.
No one would
seriously suggest that an interface specification can be written where “the host
PCB and the module PCB can be any length with same set of compliance points.”
Your question asking if that is what I am proposing and the other similar
questions are rhetorical and do not need detailed response. Everyone understands
this can not be done. It is further a
misunderstanding of IEEE standards. They are not written for a specific
implementation, but rather specify a generic set of limits against which
specific implementations are compared to determine if they are interoperable. So
your requests for specific implementation details about one module type are
inappropriate for the IEEE. This exchange
partly illustrates why we find ourselves in the unfortunate situation where no
generic specification exists for an important electrical interface identified in
several 802.3ba PMDs.
From: Ali Ghiasi
[mailto:aghiasi@xxxxxxxxxxxx] Chris The appropriate place to for nAUI
chip to module electrical specifications is in 802.3ba, not in other groups such
as MSAs. There are a number of reasons for
this. 1. SMF 40GE and 100GE PMDs (LR4 and
ER4) identify nAUI as their retimed electrical interface. The PMD optical
specifications are close to complete, allowing implementers to proceed with
specific implementations that will be interoperable. In contrast, the PMD
electrical interfaces have seen very few contributions. To allow implementers to
move forward with specific interoperable implementations, a generic chip to
module nAUI specification is
required. Page 307 Table 88-1 states CAUI is
optional for 100GBase-LR4/ER4. CL83A provides PMA to PMA CAUI electrical
specifications which satisfy this optional 2. MMF 40GE and 100GE PMDs (SR4 and
SR10) identify PPI as their un-retimed electrical interface. Considerable
progress has been made specifying this interface, which will allow implementers
to proceed with specific implementations that will be interoperable. The same
should be done for the re-retimed
PMDs. CL85 defines common pin out for the
CR4/CR10 as well as SR4/SR10 and SFF-8436 defines the QSFP module.
SR4/SR10 due to similarity is adopting 3. 802.3ba will have a detailed chip
to chip nAUI specification. Specifying a variation of nAUI in another standard
is a prescription for conflicting interpretations. It is generally a bad idea to
have to look through two standards for the definition of an
interface. If another body has solid information on
the 100GBase-LR4/ER4 module definition then they can do much better job of
defining module test points. 4. PMD electrical interfaces have
always been specified in one standard or another. XAUI was specified in
802.3ae; XAUI was not specified in the XENPAK or X2 MSA. XFI (for XFP) and
SFI (for SFP+) were specified in MSAs, they were not specified in IEEE. The XAUI
802.3ae specification underscores the problem we will face if we do not include
a chip to module component to nAUI in 802.3ba. XAUI is specified as chip to chip
only, with no allocation for additional connector loss or test points for module
applications. As a result, there is no solid XAUI chip to module specification
anywhere. IEEE CL38 only defined jitter value and
fortunately not th electrical level, if they would have then we would still had
to support 2.4 V swing PECL with 5. IEEE is the most rigorous and
public forum for writing a generic nAUI interface specification which will then
enable interoperable specific implementations. A specification in 802.3ba will
have the broadest possible pool of contributors and
reviewers. If the requirements were
known. 6. There is no body today, other
then 802.3ba, that has
the expertise to complete the nAUI specification. If this is not done in
802.3ba, then many of the same participants who are now working on the nAUI chip
to chip specification will have to organize themselves into another standards
body to write the chip to module nAUI specification.
There are a number of arguments that
have been raised against doing the nAUI chip to module specification in 802.3ba.
I have listed some of these, with responses following
them. 1. The specification can not be
written because we have no connector model.
*** To write the spec, a generic
connector model can be used, based ether on an existing model such as used for
XFP applications, or based on a model provided by connector supplier(s) based on
their best estimate of a nAUI interface connector model. At least one
company has such an estimate model available. In any case, all the limits,
such as connector loss and cross-talk should be specified in general terms (for
example such as the ICR curve used in 10GBASE-KR.) It is then up to the
implementers to design the channel to meet those limits, such as choosing a
specific connector. I just can't see how we can make such a growth
assumption, what about if it is really bad proposal because or something not
possible to meet, 2. The specification may not be
applicable to future nAUI applications, for example mezzanine
cards. *** The chip to module specification
will be generic, assuming generic connector, loss, cross-talk, etc, and will
have conservative limits applicable to a broad range of implementations.
This is similar to the chip to chip specification which is not limited to a
single type of IC package implementation. The chip to module nAUI specification
will provide a reasonable starting point for new implementations, and in most
cases accelerate their development. In the worst and unlikely case of not being
able to meet the 802.3ba standard, a new specification will have to be developed
which is no worse then would be the case without an 802.3ba
standard. Are you telling me the host PCB and the
module PCB can be any length with same set of compliance
points? 3. Since we are late in the 802.3ba
cycle and we are trying to have a complete specification in March, this
specification can not be completed in
time. *** It is an unfortunate that the
nAUI chip to module interface, which is central to SMF PMDs, has seen so little
contribution material submitted. Part of this has to do with miscommunication
and conflicting assumptions made by various contributors with respect to what
will get done and where it will get done. Hopefully our poor progress to date
will motive all of us to quickly remedy our past
oversights. Adding additional 4 compliance points to
CL83A could delay the project! Chris you are absolutely right that
we have not seen any useful presentation on 100Gbase-LR4/ER4
From: Mike
Dudek [mailto:Mike.Dudek@xxxxxxxx] During today’s
XLAUI/CAUI Ad Hoc call I picked up some action items to E-mail out some items.
Here are these
items. 1
There was significant debate as to whether the XLAUI/CAUI IEEE specification
should be just for chip to chi, or whether additional test point specifications
should be included for host/module. Ie whether the host/module specs
for the retimed interface are included in 802.3 or left for development by other
groups such as MSA’s or SFF committee. Jeff volunteered to ask CFP members
their views, however I think it is an appropriate topic for the complete
group. (FYI The non-retimed PPI host/module interface
specs are being developed in IEEE in Clause
86). 2
Detailed specification discussion. Proposals have been
made to define rise/fall times and De-emphasis.
To define rise/fall
times in a reproducible manner, particularly for waveforms with de-emphasis the
0 and 100% levels have to be defined in an un-ambiguous manner.
Clause 86 is using the stable levels on the square wave pattern (the
same levels as used for OMA/VMA measurement). I think this is the
best method, as I think this probably best predicts system performance.
Alternatives are however the peak levels as defined for De-emphasis
(see later), or the average value of the center 20% of the eye diagram (as used
to define zero and one values in the eye diagram).
A proposal has been
made to define De-emphasis as the ratio between peak-peak values and the stable
one/zero levels. Again un-ambiguous definitions are required for
peak-peak and stable one/zero. The proposal suggested that the
square wave pattern is used. The stable one/zero levels could
be defined identically to VMA (average value over center 20% of the one and zero
levels of the square wave). Other definitions are possible, but I
see no advantage in creating a different definition. For the peak
values it was suggested that it should be the value at 0.5UI, however on the
call zero time had not been defined. One definition that I think is
reasonable is the zero crossing time of the square wave. Another
definition for the zero time would be the zero crossing time of the 101010
pattern. (however this has the disadvantage of requiring a 101010 test
pattern that is not presently defined.). Yet another
definition could be to use the mean crossing point as used to align an eye mask.
There are also other possible definitions that do not require
establishing an exact zero time reference. Peak could be defined as
the peak value at any time within an averaged square wave. Peak-Peak could
be defined as the amplitude of a 101010 averaged signal (again however this has
the disadvantage of requiring the 101010 test pattern). Personally I
think the peak value at any time within the averaged square wave is probably the
easiest definition and recommend it’s use unless there are reasons not to do
this. My second choice would be 0.5UI after the zero crossing of the
square wave. Mike Dudek PMTS Standards &
Technology JDS Uniphase CO 80027 Tel 303 530 3189
x7533. From:
Dear 802.3ba
Colleagues, I'd like to schedule the next meeting for the XLAUI /
CAUI Ad Hoc as follows: Friday December 19th 8:30am - 10:30am Dial-in Number (Canada & USA) :1 877 234
4610 Participant Conference Access code: 4405734 # (see below
for additional phone numbers) Presentations should focus on technical details / values
related to the nAUI specification. In particular, I would like to focus on
the channel specification & de-emphasis proposals.
Anyone wishing to present, please follow the guidelines
described on the Procedure for Presenters web
page: http://www.ieee802.org/3/hssg/public/presentproc.html If you are planning to participate please take a moment
to read the IEEE patent policy available here: http://standards.ieee.org/board/pat/pat-slideset.ppt.
* Participant Conference
Access code: 4405734 # * Dial-in Number:416 883
8981 * Dial-in Number:1 877 234
4610 Best Regards, Ryan Market Manager Analog & Mixed-Signal
Products Gennum
Corporation Phone: 905 632 2999 x
1610 |