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
--
Best Regards,
Rich
-------------------------------------------------------
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