RE: XAUI/XGXS
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
--
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