Re: Interface reality check
Jonathan,
The question was raised at the January interim meeting and has not since
been satisfactorily answered. The response then was that the additional
delay of the 8B10B decode was used as part of the 64B/66B encoding to detect
symbol errors. If that is the case, then the lack of 8B10B precoding may
cause problems for 64B/66B in the form of undetected errors. This would
make XAUI an implementation requirement for 64B/66B. With that question
comes the issue of making a difference between the LAN only PHY and the WAN
compatible PHY relative to the RS/PCS interface.
Thank you,
Roy Bynum
----- Original Message -----
From: Jonathan Thatcher <Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Friday, April 07, 2000 12:14 PM
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
> > >
> > >
> >