Re: XAUI/XGXS
Ed,
XAUI/XGXS is located between the RS and PCS. It is PCS independent. As such, it
offers both the WWDM and Serial PMDs a means to start off with a reasonable PMD
jitter budget, due to the ability to perform jitter attenuation at the point of
location of the PCS.
A physical instantiation of a WWDM link may employ XAUI/XGXS to go across long
(e.g. ~20") PCB traces between a chip implementing the MAC/RS and as transceiver
module. An "eye-opener" circuit or full retimer circuit within the transceiver
module may be used to meet link jitter requirements. In this case, the XAUI/XGXS
acts as an "agent" for the PCS/PMA. This instantiation requires, of course, that
the WWDM PCS/PMA employ the same coding and singaling as XAUI/XGXS.
I'll provide more details on this at the Ottawa meeting.
Best Regards,
Rich
--
Edward Chang wrote:
>
> Rich:
>
> Thanks for very elaborated explanation of XAUI/XGXS, and it is very clear.
> I appreciate that.
>
> In general, I do not have problems with the objectives set by HRRI (or
> XAUI/XGXS), and I think those features - deskew, clock frequency
> compensation, error control, EMI-- are good design goals for a general
> purpose parallel runs. Even for an application which does not need all of
> them, they will not cause reverse affect anyway. I may not quite agree with
> all your reasoning of requirements for a case design -- 10GbE WWDM system;
> nevertheless, they are good reasons for general purpose parallel run design.
> Besides, XAUI/XGXS is an option.
>
> I believe your presentation of showing XAUI/XGXS being located between
> Reconciliation and PCS layers in a Reference Model is mainly for a serial
> application. As you mentioned in the WWDM application, the whole XAUI/XGXS
> functions are actually distributed among PCS, PMA and extended to the inputs
> of PMD. Therefore, the Reference Model for parallel WWDM link is different
> from a serial link. I believe it is not an important issue anyway?
>
> Regards,
>
> Edward S. Chang
> NetWorth Technologies, Inc.
> EChang@xxxxxxxxxxxxxxxx
> Tel: (610)292-2870
> Fax: (610)292-2872
>
> -----Original Message-----
> Subject: Re: XAUI/XGXS
>
> Edward Chang wrote:
> >
> > Rich:
> >
> > Thanks to show me the XAUI proposal. I may have missed this one, since it
> > was not included in the David's March presentation list. You submitted
> > later.
>
> Ed,
>
> The XAUI/XGXS proposal has been available from the March presentations page
> of
> the 10 GbE web page since the time of the meeting and referenced in many,
> many
> reflector notes since then.
>
> > Well, this is a good opportunity to discuss a few XAUI questions.
> >
> > For CWDM application, it needs four parallel, transmission lines to extend
> > the connections from SERDES (PMA) to transceivers + CWDM (PMD with
> > re-timer). Normally, in a board layout, these line lengths can be made
> > short enough to treat as a usual four asynchronous PC traces without any
> big
> > deal.
> >
> > As we all know, for a switch application, these four self-clocking lines
> may
> > extend beyond 10 inches. In this case, a re-timer can be added to restore
> > the amplitude and remove DJ.
> >
> > We gave a name "HARI" to these four differential lines. Basically, they
> are
> > pure electrical issue with electrical specification only - transparent to
> > any code.
>
> Hari has been changed to XAUI/XGXS as of the March presentation. Electrical
> specifications were only one component of the original Hari proposal. Coding
> was
> another component. The proposed code for Hari was 8B/10B. This has not
> changed
> with the name change to XAUI/XGXS. Hari electrical and coding specifications
> include some common elements. Among those is skew specifications and deskew
> functionality. Codes other 8B/10B may not have the ability to handle skew in
> the
> same manner. The XAUI/XGXS proposal is complete in that it describes all
> mechanisms required for reliable operation of a parallel arrangement of
> multiple
> serial lanes, 4 lanes to be exact in this case. To say that the
> Hari-XAUI/XGXS
> proposal is "transparent to any code" is incorrect.
>
> > These four lines can use "Word striping" as in Mike Jenkins' proposal to
> > move data from XGMII, through PCS (8B/10B), PMA, HARI, PMD in a straight
> > forward manner. At the receiving side, the data from four lines can be
> > individually clocked into each one's FIFO after de-serializing, then let
> > FIFO perform the final deskew for XGMII interface.
> >
> > It seems pretty straight forward, and it does the job.
>
> A complete XAUI/XGXS proposal based on word striping has never been aired.
> The
> March 2000 XAUI/XGXS proposal requires column striping to meet all link
> requirements including the recent desire to reduce 8B/10B EMI through
> randomization of the Idle pattern. Other link requirements include lane and
> link
> synchronization, clock tolerance compensation and link deskew.
>
> > My question is the XAUI interface has additional coding requirement on top
> > of 8B/10B code to perform column striping. Why it is needed? I do not
> see
> > the need in a 4-line CWDM application. It seems, XAUI makes it more
> > complicated to achieve additional objectives, than a pure electrical
> > interface HARI for a CWDM application. Does the serial application
> require
> > XAUI's additional features, but not a simple four parallel electrical
> lines?
>
> The March 2000 XAUI/XGXS proposal supports one, and only one code, 8B/10B.
> No
> other coding is required to perform column striping. Column striping simply
> refers to the simultaneous transmission of 4 bytes of information from the
> MAC
> directly across XAUI lanes 0:3. Alternatively, word-striping requires that
> the 4
> consecutive 32-bit words from the MAC be buffered prior to transmitting the
> first byte across each of lanes 0:3 (i.e. in a column-striped fashion). My
> answer to "Why it is needed?" is that column striping results in an
> architecture
> which is simple, lowest in latency and requires the least buffering. Please
> allow me to turn the question around: If the MAC supplies 32-bit words to
> the
> PHY, why should the PHY have to stripe the words one at a time across all
> four
> lanes before transmitting anything?
>
> I'm confused with your statement: "It seems, XAUI makes it more complicated
> to
> achieve additional objectives, pure electrical interface HARI for a CWDM
> application". I assume that by CWDM you're referring to the WWDM PHY
> proposal
> which also uses 8B/10B encoding. Prior to transmission, the data on each
> WWDM
> lane must be serialized by a PMA, a 10:1 serializer in this case. Prior to
> that,
> the data must be encoded by the PCS, 8B/10B in this case. Prior to encoding,
> the
> data must be sourced from the MAC. It is directly sourced through the
> reconciliation layer on a byte-by-byte basis in this case. XAUI/XGXS is
> always
> optional. It is optional for a WWDM PHY. XAUI/XGXS may optionally be used in
> a
> WWDM WAN PHY to go across long (~20") PCB traces as well as attenuate jitter
> at,
> or in close proximity to, the transceiver module.
>
> Pushing a "Pure electrical interface Hari" and "Word striping" does not
> compute
> to me. How do you get a pure electrical interface to buffer a full word on
> each
> lane before transmitting anything in that lane?
>
> XAUI/XGXS is just as optional for Serial applications as it is for WWDM. The
> intention of XAUI/XGXS for Serial applications is to support low pin count,
> long
> PCB traces between the MAC/RS and PCS.
>
> > There are some comments on the XGXS functions listed in the presentation.
> >
> > (1) Perform clock tolerance compensation:
> >
> > All clocks are generated from one write clock source, which provide XGMII
> > clocking, SEWRDES (HARY self clocking data) clocking; therefore, it seems
> > there is no need for clock tolerance compensation. There are phase
> > differences, which contribute skew, but not frequency deviation.
>
> The group that developed Hari specified a clock tolerance compensation
> capability. The use of this capability is implementation dependent. In the
> case
> that the RS or XGMII clock source is not adequate enough to guarantee that
> Hari
> operates within spec, an optional clock reference may be used to clock the
> Hari
> interface. The optional usage of such a reference dictates the utilization
> of
> the Hari clock tolerance compensation capability. This Hari capability was
> propagated to the XAUI/XGXS proposal.
>
> > (2) Perform error control to prevent error propagation:
> >
> > Electrically, HARI interface is not any different from other PC runs
> design.
> > I believe, the normal PC design rules can assure HARI will not generate
> any
> > extra errors. Do we have to worry about additional error generation by
> > those four lines (HARI)? I do not think so. Otherwise, we may have to
> add
> > error correction for other PC runs.
>
> On the contrary, the Hari interface is very, very different from "other PC
> runs
> design". I'm not aware of 8B/10B encoding being used within PC's today.
>
> Each lane of a Hari receiver, due to nature of 8B/10B code, must perform
> error
> control by definition. If a code violation is detected at the receiver, the
> propagated code must indicate that the received code-group was invalid. What
> do
> you suggest that the received invalid code-group be changed to instead?
>
> > For EMI? No, I do not think so. For 8B/10B code, as long as it stays
> > inside a cabinet or going out of a cabinet with a fiber cable, I believe,
> > there is no EMI problem to worry about.
>
> Good coding practices are typically simple and very cost effective. For
> 8B/10B
> code, good coding practices clearly go hand in hand with good electrical and
> mechanical design practices to minimize EMI. I'd hate to be telling a
> customer
> pointing out an EMI problem to me that "there is no EMI problem to worry
> about."
>
> > Regards,
> >
> > Edward S. Chang
> > NetWorth Technologies, Inc.
> > EChang@xxxxxxxxxxxxxxxx
> > Tel: (610)292-2870
> > Fax: (610)292-2872
> >
> > Ed,
> >
> > XAUI has nothing to do with a 10.3125 Gbaud line rate. That rate is
> > associated
> > with the overhead of 64B/66B: 66/64 * 10 = 10.3125. Where are you getting
> > this
> > information?
> >
> > FYI: XAUI is proposed as an 8B/10B 4-lane serial interface with each lane
> > running at 3.125 Gbaud.
> >
> > Please refer to:
> > http://grouper.ieee.org/groups/802/3/ae/public/mar00/taborek_1_0300.pdf
> > for further details.
> >
> > --
> >
> > Best Regards,
> > Rich
> >
> > Edward Chang wrote:
> > >
> > > Comments:
> > >
> > > I agree XAUI should be 100% transparent. XAUI has its unique value in
> 10
> > > Gbps serial application to maintain symbol rate at 10.3125 which is very
> > > close to 10 Gbps. However, it comes with a lot of complicated coding
> > > manipulations.
> > >
> > > For CWDM approach, the data rate is low which, does need XAUI approach.
> > The
> > > straight forward, mature, and market-proved block code will do nice job.
> > In
> > > the reference model, it will completely skip the XAUI of 64b/66b, and
> the
> > > MAC will go directly to 8B/10B coding (PCS) followed by SERDES (PMA).
> > Just
> > > the same as GbE ... simple and cost-effective.
> > >
> > > If the XAUI proposal is trying to make all applications using XAUI of
> > > 64b/66b, it is a wrong approach. Keep it flexible. Not everyone needs
> > the
> > > complex manipulation of the coding scheme.
> > >
> > > Regards,
> > >
> > > Edward S. Chang
> > > NetWorth Technologies, Inc.
> > > EChang@xxxxxxxxxxxxxxxx
> > > Tel: (610)292-2870
> > > Fax: (610)292-2872
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com