RE: 1000BASE-T PCS question

[bin.guo@xxxxxxx]

Ed,

Thanks for pointing out.  I believe that the Max 3 bit run length I
mentioned is actually the end result of 4B/5B_PLUS_NRZI.  The worst case
used in our earlier study is created by FDDI - using the most unbalanced
symbols.  I am not promoting 4B/5B.  In fact, even we could prove at the
time that you can achieve similar BER for 4B/5B by using larger coupling
time constant than that used for 8B/10B, if the cost of few hundreds of gate
is a concern.   But it is certainly a non-issue now.  So the question now
becomes whether the 20% or 25% overhead is justifiable or not, or it is
necessary to use the block code for achieving the 10G specified BER. 

Bin Guo
ADL, AMD 

> -----Original Message-----
> From:	elg@xxxxxxxxxxx [SMTP:elg@xxxxxxxxxxx]
> Sent:	Thursday, May 27, 1999 2:16 PM
> To:	rtaborek@xxxxxxxxxxxxxxxx; kardontchik.jaime@xxxxxxxxxxx; Guo, Bin
> Cc:	stds-802-3-hssg@xxxxxxxx
> Subject:	RE: 1000BASE-T PCS question
> 
> Hi Bin and Rich,
> 
> With respect to the 4B/5B code used on FDDI, you need to be careful
> with the generalizations.  First off, its not just 4B/5B, its 
> 4B5B _PLUS_ NRZI.  That extra XOR in the path for NRZI coding changes
> the transistion density and run lengths for a number of the chracters.
> 
> The other thing to watch out for are the control codes.  The 8B/10B
> code has 12 defined control codes, and 4B/5B (I believe) has 16.
> A number of these control codes contain specific warnings not to use
> them in any repeated fashion because of the severe imbalance in the
> character and lack of transitions.
> 
> -Ed Grivna
> > 
> > Rich,
> > 
> > The DC imbalance( draft) of 4B/5B used in FDDI is not unbounded, but is
> > bounded within +/- 10%,  even with the worst case code.  We had a prove
> on
> > this during the code debate in Fiber Channel.  With proper AC coupling
> time
> > constant, the effective DC draft is very much tolerable and the BER
> > objective can still be met with 4B/5B.  One of the reason why
> considering
> > 4B/5B at the time is that 8B/10B costs hundreds of more gates to
> implement,
> > which is non-issue now.  The code also has max 3-bit run length, and
> this
> > high transition density feature makes data recovery a lot easy.
> > 
> > When 100Base-T borrowed it from FDDI, it has to keep the coding
> unchanged
> > for protocol compatibility, but need to do scrambling after.  So these
> 4B/5B
> > features are essentially removed by scrambling.  Issue such as the
> longer
> > run length (possible 60-70 bits without transitions) takes some jitter
> > budget and makes timing recovery to work harder, that may be part of the
> > reason the BER performance is limited.
> > 
> > Scrambling randomizes data, removes data dependency and make it more
> > "balanced" only for relatively long term. It could create worse short
> term
> > imbalances than the original data.  All it can do is to "average" --
> avoid
> > the worst case data sequences, but not provide any guaranteed features
> as
> > the block codes for BER.
> > 
> > 8B/10B is balanced within a block (a byte) and provides probably the
> best
> > features in terms of BER.
> > 
> > Bin 
> > 
> > > -----Original Message-----
> > > From:	Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxxxxx]
> > > Sent:	Thursday, May 27, 1999 11:07 AM
> > > To:	Jaime Kardontchik
> > > Cc:	HSSG_reflector
> > > Subject:	Re: 1000BASE-T PCS question
> > > 
> > > 
> > > Jaime,
> > > 
> > > I have some additional comments below:
> > > 
> > > Jaime Kardontchik wrote:
> > > > 
> > > > Rich,
> > > > 
> > > > For simplicity, I did not mention nor I did include in the
> > > > figures that the 4D encoded symbols are randomized before
> > > > sending them to the transmitters. This procedure is described
> > > > in the 1000BASE-T standard.
> > > 
> > > I believe that the randomizing is to ensure that the frequency
> spectrum
> > > transmitted on each pair is well distributed and also even across all
> > > four pairs. If this is the case, scrambling may be applicable to WWDM,
> > > but it may not apply to MAS, Serial TDM, or parallel optics.
> > > 
> > > > The produce assures that the output levels send down the
> > > > wires (or the fiber) are DC balanced. However, you will not
> > > > get the nice extremely short running disparity that one could
> > > > get with the 8b/10b encoder, since the randomization is based
> > > > on the scrambler. The scrambler used is 33 delays long (much
> > > > longer than the scrambler used in Fast Ethernet) and it is
> > > > expected to produce a better short term balance than the one
> > > > obtained in Fast Ethernet.
> > > 
> > > DC balance of signaled information in an optical link is required for
> > > one or more of the following reasons. Please note that this may not be
> > > an all-inclusive list:
> > > 
> > > - To enable AC-coupling onto the medium without distortion or the use
> of
> > > a separate DC-balancing line code;
> > > 
> > > - To avoid short-term DC offset which may require the inclusion of DC
> > > level-restoring circuitry which, in turn, affects receiver sensitivity
> > > and dynamic range and make the link more susceptible to low-frequency
> > > noise;
> > > 
> > > - To avoid the data dependent heating of the laser(s);
> > > 
> > > Note that all of the above affects of DC imbalance affect the
> > > reliability of the link and can, therefore, be considered a link
> > > penalty. The same requirement for DC balance may not exist for UTP as
> > > for optical links. We need to be careful about doing away with this
> > > requirement as it was one of the key reasons that 8B/10B won out over
> > > 4B/5B in the early days of Fibre Channel development. Recall that
> 4B/5B
> > > was used by FDDI at that time and that DC Balance problems were noted
> > > due to the unbounded nature of 4B/5B.
> > >  
> > > > The clock can be recovered (in the same way as it is recovered in
> > > > Fast Ethernet). Many simulations were run during the development
> > > > of the 1000BASE-T standard and presented during its meetings
> > > > showing that this is the case. There is already a well known
> > > > company that has 1000BASE-T transceivers on Silicon, and
> > > > has shown that they work in the last Interop gathering.
> > > 
> > > I agree that clock recovery is a second-order concern relative to data
> > > recovery due to the attenuation, SNR, dispersion, etc. at the
> receiver.
> > > However, it is still a valid PHY architecture concern. In the presence
> > > of gross data-dependent DC imbalance, this second-order effect may
> > > quickly become a first-order concern.  
> > > 
> > > > Jaime
> > > > 
> > > > Jaime E. Kardontchik
> > > > Micro Linear
> > > > San Jose, CA 95131
> > > > email: kardontchik.jaime@xxxxxxxxxxx
> > > 
> > > -- 
> > > 
> > > Best Regards,
> > > Rich
> > > 
> > > ------------------------------------------------------------- 
> > > Richard Taborek Sr.    Tel: 650 210 8800 x101 or 408 370 9233       
> > > Principal Architect         Fax: 650 940 1898 or 408 374 3645
> > > Transcendata, Inc.           Email: rtaborek@xxxxxxxxxxxxxxxx 
> > > 1029 Corporation Way              http://www.transcendata.com 
> > > Palo Alto, CA 94303-4305    Alt email: rtaborek@xxxxxxxxxxxxx