Re: Interface reality check
Roy,
64/66 decoder doesnt rely on 8B/10B coder delay to do error
checking.
But what it does need is a one cycle delay to catch 2-bit errors
in the 66bit frame prefix.
Most likely, the decoder implementation will be pipelined, and this
extra delay can be hidden.
see pg
12: http://grouper.ieee.org/groups/802/3/ae/public/mar00/walker_1_0300.pdf
for an example.
Let me explain what this error condition is so that everyone will be on
the same
page.
As an example, imagine that at XGMII, we want to transmit:
SDDD/DDDD D'DDD/DDDD DDDD/DDTZ
This gets encoded by the 64/66 PCS as
10_SDDD/DDDD 01_D'DDD/DDDD 10_DDDD/DDTZ
(I have not shown all the TYPE encodings in gory detail to keep
the description simple.
Also D' is a data octet which happens to be a special pattern - see
next.
)
If there is a 2-bit error in the prefix of the second frame,
and also the data pattern in the first octet D' is such that this frame
gets confused as
a T frame, It will confuse the 64/66 decoder into thinking that this was
a shorter
data packet.
10_SDDD/DDDD 10_D'DDD/DDDD 10_DDDD/DDTZ
^^
2 bit error and D' has a special
pattern to mimic a end of packet frame.
Now if there are no more errors in the next frame, then the next frame
will be
decoded as another T frame (a frame which has a T octet). But this will
violate
the state sequence requirements,
see pg 9:
http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/walker_1_0100.pdf
This is a clue that the preceding frame was an error and so we need to
forward the
error signal to the next pipe stage to invalidate the packet.
Ofcourse if there is also a 2-bit error in the prefix bits, in the third
frame also, in the above
example, we will not be able to detect the error.
If there is a single bit error instead in the third frame, then it will
clearly violate the
frame structure and will again cause an error to be forwarded.
The same reasoning also holds for longer packets.
Regards,
Birdy
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
> > >
> > >
> >
begin:vcard
n:Amrutur;Bharadwaj
tel;fax:650-857-3637
tel;home:408-244-5553
tel;work:650-813-3357
x-mozilla-html:FALSE
adr:;;3500 Deer Creek Rd. MS 26U-4;Palo Alto;CA;94304-1392;USA
version:2.1
email;internet:bharadwaj_amrutur@xxxxxxxxxxx
x-mozilla-cpt:;8544
fn:Bharadwaj Amrutur
end:vcard