Pat,
In addition to zero DC content and guaranteed transitions to which
a PLL can lock, 8B10B (that's the way IBM wrote it originally) code
has the string ...0011111... or it's inverse which occurs only as the
first 7 characters of a 10-bit character, making byte alignment to
these sync characters easy. Alignment for more efficient codes (e.g.,
64b/66b) is much more complex and statistical.
The spectral content comes from limiting "running disparity" (the
ratio of 0's to 1's) which limits the low frequency content more
than, say, scrambled data, allowing the use of smaller blocking
capacitors. (At these high frequencies, good capacitors with large
values are not cheap, if they can be gotten at all.)
Lastly, 6B10B also provides a reasonably high error detection
capability.
Besides Infninband, 8B10B has been selected by Fibre Channel, 1G and
10G Ethernet, SerialATA, 3GIO, and, I suspect, more. Some of the
popularity may be momentum, but that's a lot of people going through
the same cost/benefit analysis as you. They all decided it was worth
the costs.
Regards,
Mike
"Zabinski, Patrick J." wrote:
>
> Jeffrey,
>
> Thanks for the feedback.
>
> Looking at the spectrum of an un-encoded/raw data stream versus
> an 8b/10b-encoded data stream, I can see how the power
> spectral density will be increased at a frequency
> equal to the data rate/2, which would provide more
> information for a PLL to synch onto.
>
> If this is the case, is there a way of analyzing exactly how
> much better a PLL can synch when using 8b/10b vs when
> not using 8b/10b? If there is, can the analysis be
> generalized to allowing me to determine how often
> transitions need to be in order for a PLL to lock?
>
> Thanks,
> Pat
>
> >
> > # What's the purpose of 8b/10b encoding?
> >
> > Generally as I understand, it is to be able to recover the clock by
> > ensuring some number of transitions per period (8 per 10?).
> > Clocks change
> > period frequently when working at high speeds, due to
> > temperature, etc... not
> > to meantion the fact that otherwise the sending clock would
> > inevitably be
> > out of phase, plus period, of your receiver's clock.
> >
> >
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
> or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Jenkins Phone: 408.433.7901 _____
LSI Logic Corp, ms/G715 Fax: 408.433.7495 LSI|LOGIC| (R)
1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
Milpitas, CA 95035 http://www.lsilogic.com |_____|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~pc
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List archives are viewable at:
http://www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
