Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: 1000BASE-T PCS question




Bin,

Thanks for your astute observation. I did a bit of research on DC
balance before writing my note and used the word "unbounded" in relation
to 4B/5B coding as it was used in my referenced text. I won't list the
reference to protect the guilty,  and will defer to your expertice on
4B/5B DC balance characteristics. 

In the end, I agree with your last assertion: "8B/10B is balanced within
a block (a byte) and provides probably the best features in terms of
BER."

--

bin.guo@amd.com wrote:
> 
> 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@transcendata.com]
> > 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@ulinear.com
> >
> > --
> >
> > 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@transcendata.com
> > 1029 Corporation Way              http://www.transcendata.com
> > Palo Alto, CA 94303-4305    Alt email: rtaborek@earthlink.net

-- 

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@transcendata.com 
1029 Corporation Way              http://www.transcendata.com 
Palo Alto, CA 94303-4305    Alt email: rtaborek@earthlink.net