RE: Interface reality check
Proof:
1) Define simple as being X gates.
2) Determine optimal XGMII to XAUI mapping is 0.8X gates -- simple.
3) Determine optimal XAUI to 64x/66b mapping is 0.8X gates -- simple.
4) Optimal XGMII to 64b/66b mapping is therefore 1.6X gates -- not simple.
I had to respond to this to bring some humor to the discussion. I don't
personally feel that the above is truly valid -- in our industry most
wouldn't define 2X to be significantly different from X.
However, I don't think that it's right to continue (1) calling XAUI optional
and at the same time (2) saying that the mapping is simple enough that we
shouldn't worry about including it where it isn't strictly needed.
If (1) is the case, then it's the case, period. Any encoding that depends
on all or part of the XAUI functionality cannot say "this is for free
because it's a part of XAUI", or "these codegroups are propagated through
the XAUI block" it should say "this functionality is required, and it could
be taken from an XAUI block, if one is present."
If (2) is the case, then we should agree that the XAUI encoding is
optionally *exposed* but always implemented. Then any PHY proposal is free
to assume that the functionality can be used.
The current situation, where PHY presenters aren't sure where there is XAUI,
cannot continue much longer. If I were trying to propose a PHY, would I
propose the X gate solution that depends on the Y gate XAUI (and get blasted
for assuming XAUI since "it's optional") or would I propose the Z gate (X >
Z > (X+Y)) solution that is independant of XAUI (and get trounced by the Z >
X comparison since "XAUI is for free"). I can't know the right proposal
without knowing what other parts of the system are going to be there, FOR
SURE.
Wasn't that the whole point of nailing down XGMII at the beginning? To
define a common interface that all PHYs plug into? Haven't we since
essentially said: "no-one's using XGMII between chips, so here's another
interconnect solution, but it's optional so don't rely on it in your PHYs,
but it has a bunch of features designed to reduce the cost of PHYs, so some
will rely on it, and in truth it's always going to be there so if you aren't
relying on it architecturally, you should still expect to pay for it when
compared to other PHYs..."
The very helpful function that MII/GMII performed -- completely isolating
the MAC and PHY -- has been lost. We now have an interface that everyone
agrees on but will not actually be visible, XGMII, and with XAUI we have
another interface that has mixed levels of support.
The understanding seems to be that in the near term we'll see
MAC<>XGMII<>XAUI chips mated to XAUI<>WDM or XAUI<>XGMII<>MAS type PHYs,
only going to MAC<>XGMII<>XAUI<>WDM or MAC<>XGMII<>MAS after some time.
But it is important to note that the correct comparison is XGMII<>XAUI<>WDM
versus XGMII<>MAS. It's not correct to assume XAUI will be there to ease
the implementation of the WDM PHY unless we agree that it's not optional.
To make an analogy... 8B10B TBI @ 125Mhz <> 8B10B serdes @ 1.25GHz was the
initial way to get gigabit over to a fiber. A popular gigabit choice has
become to integrate the serdes function with the MAC, or at least the 8B10B
encoder with a TBI output (the latter case being helpful because 1.25GHz
serdes processes couldn't perform the 8B10B encoding efficiently). Copper
gigabit PHYs therefore may, in addition to GMII, include a 1.25GHz serdes
input, and/or a TBI input, followed by an 8B10B decoder, all followed by a
MAS encoder. This is their choice given the MAC chips prevalent in the
market.
HOWEVER, the gigabit over copper standard was defined as GMII<>MAS and I
doubt that there would have been much support for assuming 8B10B encoding
existing anywhere just because the serdes, for a while, was an efficient way
to get signals between MACs and PHYs. Likewise, I don't think it's
appropriate to architect the various 10G PHYs assuming that the XAUI is
present -- like TBI it is nothing more than a convenient way, given the
current technologies, to get signals between chips. It is only an
architectural solution for a subset of PHYs, and therefore should be thought
of as being a part of the PHY just like the 8B10B is considered part of
1000-BaseLX/SX and not gigabit ethernet in general.
-Simon
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Jonathan Thatcher
> Sent: Friday, April 07, 2000 10:15 AM
> To: HSSG
> Subject: RE: Interface reality check
>
>
>
> I do not understand this statement.
>
> If there is a simple and direct mapping from the XGMII to XAUI
> (8b/10b), and
> there is a simple and direct mapping from XAUI to 64b/66b, then there must
> be a simple and direct mapping from XGMII to 64b/66b.
>
> I would love to see a proof why this would not be true.
>
> jonathan
>
> > -----Original Message-----
> > From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > Sent: Friday, April 07, 2000 7:17 AM
> > To: rtaborek@xxxxxxxxxxx; HSSG
> > Subject: Re: Interface reality check
> >
> >
> >
> > Rich,
> >
> > You are making statements that are not based in fact. The
> > 64B/66B proposals
> > are based on the continuance of the LAN only PHY block coding
> > schemes. Rich
> > Walker has stated that when he made the 64B/66B he did not
> > take into account
> > the possibility of the absence of 8B10B Hari. The 8B10B
> > block coding keeps
> > getting brought back over and over again under different
> > names. The only
> > reason that this would happen is that it becomes obvious that
> > the group as a
> > whole did not support it in each of its previous iterations.
> > This has not
> > happened to the WAN compatible PHY proposals that do not use
> > block coding.
> >
> > Thank you,
> > Roy Bynum
> >
> >
> > ----- Original Message -----
> > From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
> > To: HSSG <stds-802-3-hssg@xxxxxxxx>
> > Sent: Thursday, April 06, 2000 9:54 PM
> > Subject: Re: Interface reality check
> >
> >
> > >
> > > Roy,
> > >
> > > Absolutely not.
> > >
> > > It should be clear that 64B/66B is a single lane serial
> > transmission code
> > which
> > > is embodied in multiple strongly endorsed IEEE P802.3ea
> > proposals. These
> > > include:
> > >
> > > a) LAN Serial PHY:
> > >
> > http://grouper.ieee.org/groups/802/3/ae/public/mar00/bhatt_1_0300.pdf
> > > b) UniPHY:
> > >
> > http://grouper.ieee.org/groups/802/3/ae/public/mar00/frazier_1
> > _0300.pdf
> > >
> > > Note that the UniPHY covers all WAN application spaces,
> > whether SONET/SDH
> > or
> > > native Ethernet.
> > >
> > > Best Regards,
> > > Rich
> > >
> > > --
> > >
> > > Roy Bynum wrote:
> > > >
> > > > Rich,
> > > >
> > > > Are you referring to the LAN only PHY?
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > --
> > > > >
> > > > > Rick,
> > > > >
> > > > > Agreed. I should have qualified as "pure scrambled"
> > code. 64B/66B
> > > > > certainly does not fit into this category. This is one
> > of the clear
> > > > > benefits of 3.125% overhead.
> > > > >
> > > > > Best Regards,
> > > > > Rich
> > > > >
> > > > > --
> > > > >
> > > > > Rick Walker wrote:
> > > > > >
> > > > > > > Agreed. Cool! 8B/10B plug: 8B/10B supports the
> > detection of poor
> > > > > > > signal quality on a link regardless of the information being
> > > > > > > transported. In fact simple receiver circuitry can
> > determine the
> > BER
> > > > > > > at the decoder in real time. Try that with a
> > scrambled code ;_)
> > > > > >
> > > > > > 64b/66b also supports the measurement of bit error
> > rate by looking
> > at
> > > > > > master transition violations regardless of the
> > information being
> > > > > > transmitted.
> > > > > >
> > > > > > You are right, however, in that 64b/66b is not a pure
> > scrambled
> > code,
> > > > > > but one augmented by periodic frame sync bits.
> > > > > >
> > > > > > Best regards,
> > > > > > --
> > > > > > Rick Walker
> > >
> > > -------------------------------------------------------
> > > 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
> > >
> > >
> >
>