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

Re: [802.3BA] XLAUI / CAUI Ad Hoc



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.


Chris

 


From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxxxxx]
Sent: Monday, December 22, 2008 10:30 AM
To: Chris Cole
Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx; John DAmbrosia; Ryan Latchman
Subject: Re: [802.3BA] XLAUI / CAUI Ad Hoc

 

Chris

Thank you for summarizing all the discussions and please see my response below.

Chris Cole wrote:

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
interface requirements for 100Gbase-LR4/ER4.


 

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
many aspect of SFP+ compliance boards.  If SFF-8431 had not fully defined the PPI and compliance baords,  I highly doubt 802.3ba would have define
the module interface due to the amount of time it would have taken.  IEEE 802.3ba has ZERO information how CAUI will be used to implement a
100GBase-LR4/ER4 module, but I can see the following implementations:
    o. Build the optics on the line card with CAUI - current specifications satisfy this requirement
    o. Provide pluggable module with 5" host PCB and 5" of module PCB
    o. Provide pluggable module with shorter host PCB and longer of module PCB
    o. Provide pluggable module with longer host PCB and shorter of module PC
Based on just assumptions we can not write additional 4 set of specifications for CL83A!


 

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
termination resistors!  I would even argue adding PPI definition in CL86 is questionable and we had long debate about in Portland.  MSA and SFF
specifications with technology evolution can easily be updated but not the IEEE specifications.


 

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,
because we did not have the facts!
How about crosstalk limits as defined in SFF-8083?

 

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
module implementation or a clear request, but I did find your presentation http://www.ieee802.org/3/ba/public/may08/cole_02_0508.pdf page 5 showing a transceiver architecture
from 40000 ft.  Searching on Google did not turn anything useful either and as far as I know 802.3ba has not received any liaison report or requests from any MSA or SFF group
that might be working on a 100G module, John should be able to confirm this.

Thanks,
Ali


Chris


From: Mike Dudek [mailto:Mike.Dudek@xxxxxxxx]
Sent: Fri 12/19/2008 11:27 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] XLAUI / CAUI Ad Hoc

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

1480 Arthur Ave.

Louisville

CO 80027

Tel  303 530 3189 x7533.

mike.dudek@xxxxxxxx

 

 

 


From: Ryan Latchman [mailto:Ryan.Latchman@xxxxxxxxxx]
Sent: Monday, December 15, 2008 7:18 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] XLAUI / CAUI Ad Hoc

 

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 US PDT

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.

 

Ryan Latchman invites you to attend this online meeting.

Topic: Ryan.Latchman@xxxxxxxxxx's meeting
Date: Friday, December 19, 2008
Time: 11:30 am, Eastern Standard Time (GMT -05:00, New York )
Meeting Number: 596 318 109
Meeting Password: XLAUICAUI

Please click the link below to see more information, or to join the meeting.

-------------------------------------------------------
To join the online meeting
-------------------------------------------------------
1. Go to https://teluswebconferencing.webex.com/teluswebconferencing/j.php?ED=111351007&UID=0
2. Enter your name and email address.
3. Enter the meeting password: XLAUICAUI
4. Click "Join".


-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://teluswebconferencing.webex.com/teluswebconferencing/mc
2. Click "Assistance".
3. Click "Support".

You can contact me at:
ryan.latchman@xxxxxxxxxx
1-905-632 x2999

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://teluswebconferencing.webex.com/teluswebconferencing/j.php?ED=111351007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=3tdGmcXADv4wTwWr4RVet2RMq2d2AZbUPcHgWZBtexo=

The host requests that you check for compatibility of rich media players for Universal Communications Format (UCF) before you join the session. UCF allows you to view multimedia during the session. To check now, click the following link:
https://teluswebconferencing.webex.com/teluswebconferencing/systemdiagnosis.php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com
We've got to start meeting like this(TM)

 

* Participant Conference Access code: 4405734 #

* Dial-in Number:416 883 8981      Toronto

* Dial-in Number:1 877 234 4610      Canada & USA

 

Best Regards,

 

Ryan

 

 

Ryan Latchman

Market Manager

Analog & Mixed-Signal Products

Gennum Corporation

Phone:  905 632 2999 x 1610