RE: 1000BASE-T PCS question

[bin.guo@xxxxxxx]

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