RE: 850 nm solutions
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.
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.
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.
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?
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.
(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.
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.
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
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Roy Bynum
> Sent: Wednesday, May 03, 2000 1:28 AM
> To: THALER,PAT (A-Roseville,ex1); stds-802-3-hssg@xxxxxxxx
> Subject: Re: 850 nm solutions
>
> Pat,
>
> There is nothing evil about economic and business considerations. I
> recognize the economic advantage of developing silicon that
> will work in multiple standards. I recognize that the cost of talented
> personnel along with other manufacturing and competitive
> issues tends to favor reduction of diversity. I recognize that there may
> be individuals in the P802.3ae TF that stand to benefit
> directly, or whose company would benefit economically depending on how the
> standard is defined. There is nothing evil about that.
> As a customer, the only benefit that I or the company that I work for
> receives, is the manor in which the users would be enabled by
> the standard.
>
> As a customer who deploys very high bandwidth and extremely large
networks,
> I want consistent standards, but I want them specialized
> for the functions they are to perform. Over the years, the larger vendors
> have created more "generalized", like Microsoft's Windows
> NT. For mediocre desktop and server usage it will do. For people that
> require better or more reliable performance go to other
> vendors and products. While this may not have greatly effected
Microsoft's
> market in low end systems, it has almost no share in the
> very high end technology market. 10GbE is targeted at the high end
> technology market. The 10GbE WAN compatible PHY is targeted for
> an extremely large but very specialized market. As a representative
> customer of that high end technology industry market, I would
> prefer to have what I need in the standard, "up front". Instead I may
have
> to shop around for vendors that will deviate from that
> standard in order to deliver what is required, much like some large
> customers requiring vendors to support jumbo frames. This was
> also the comment by another customer concerning the need for short reach
> 10GbE interfaces.
>
> The majority of the individuals in the P802.3ae TF are "LAN" people. They
> understand the needs of a LAN only PHY. There are some
> that also work with WAN systems. Both the "LAN" and "WAN" people
recognize
> that the needs are different between LAN systems and WAN
> systems. An attempt to combine the LAN and WAN into one "UniPHY" will
> result in a standard that does not properly address the needs
> of either the LAN or the WAN.
>
> Last year, 1.6 terabit per second DWDM systems were field tested. Those
> transport systems can provide 160 10GbE WAN channels per
> fiber. Internet content sites are increasing exponentially all over the
> world, with aggregated transport bandwidths getting into
> the 10s of terabits per second per site. Facilities floor space density
is
> becoming a critical issue. The port density as well as
> per port bandwidth on data switches and servers is becoming a critical
> issue. The complexity of intra-cluster port usage in storage
> servers as well as data switches is becoming a critical issue. All of
this
> is leading to the need for data switches with multiples
> of terabits per second in aggregate bandwidth per chassis, and interface
> cards with multiple 10Gb ports each.
>
> The industry needs very condensed form factor equipment, the kind that
will
> not need to have 18" of etch between the MAC and PCS.
> The industry needs a protocol that has as much bandwidth efficiency as
> possible because the transport signaling speed is fixed.
> The industry needs transport operations and performance management based
on
> existing systems so that it does not have to deploy
> entirely greenfield operations support systems as well as untried
greenfield
> transport technology.
>
> It is the above reasons that I, as a customer, have taken a stand that
XAUI
> should be 100% transparent as far as the standard is
> concerned. This will allow vendors in the future to build very high
density
> systems, with small form factors per port, without the
> additional symbol overhead that a non-transparent XAUI would put on
non-XAUI
> MAC/PCS interfaces. At the same time, a transparent
> XAUI will allow vendors to build systems today that do need the extended
> etch distance. As a customer, I have taken a stand that
> the LAN PHY and the WAN compatible PHY should be separate tracks within
> P802.3ae, according to the objectives as written. This will
> allow for short reach block encoded parallel solutions for the LAN PHY and
a
> single serial scrambled synchronous solution for the
> WAN compatible PHY. As a customer, I have also taken a stand that the
SONET
> mapping proposal by Paul Bottroff and David Martin,
> modified to allow for 10Byte IPG compression, be standardized instead of
the
> 64B/66B block encoding for the WAN compatible PHY.
> This will allow for the highest data transfer bandwidth available with the
> shortest amount of time to market.
>
> Thank you,
> Roy Bynum
>
> ----- Original Message -----
> From: THALER,PAT (A-Roseville,ex1) <pat_thaler@xxxxxxxxxxx>
> To: Roy Bynum <rabynum@xxxxxxxxxxxxxx>; THALER,PAT (A-Roseville,ex1)
> <pat_thaler@xxxxxxxxxxx>; Rick Walker
> <walker@xxxxxxxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
> Sent: Monday, May 01, 2000 7:05 PM
> Subject: RE: 850 nm solutions
>
> > Roy,
> >
> > This is a frustrating discussion. You seem intent on twisting what is
said
> > and implying evil actions. I did not say different groups developed Hari
> and
> > XAUI. What I said is that the Infiniband TA did not develop Hari. I
should
> > know, I've been there from the beginning and in the Future IO before
that.
> >
> > Over my career, I've seen a number of times when separate groups applied
> > existing technologies to the same or similar problems and came up with
> > similar solutions. For instance, there were about 4 proposals for
10BASE-T
> > developed independently by different companies that when examined were
> > almost identical. It wasn't because we co-developed them. It was because
> > taking as a departure point what we had learned about twisted-pair cable
> > as an industry and applying that to how to run Manchester code over it,
> > a certain direction was fairly attractive and 4 out of 6 companies
> > investigating
> > it came up with very similar solutions. There were minor differences
such
> as
> > the
> > choice of where to put the equalizer, but mostly it was the same
solution.
> > That is the source of much of the "commonality" to which you refer.
> >
> > "Hari" was developed with Ethernet in Fibre Channel in mind (to the best
> of
> > my
> > understanding; I did not work in that group). But Hari as a name really
> > didn't fit into the names 802.3 has used for interfaces. Therefore, a
> > proposal
> > based on the Hari work suggests "XAUI" as a name that does fit in with
> > traditional Ethernet interface names.
> >
> > I have no idea what you are talking about when you talk about different
> > groups with the same people. Your statement about voting blocks is
totally
> > unjustified and offensive.
> >
> > Sincerely,
> > Pat Thaler
-------------------------------------------------------
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