Re: 64/66 control code mapping
Hi Rick,
As you say, we're not far apart. Let me make two points below.
(And thanks for the feedback. I'm just defending the game I know,
but it's good to learn new stuff along the way.)
Regards,
Mike
Rick Walker wrote:
>
> Dear Mike:
>
> > Mike Jenkins <jenkins@xxxxxxxx> writes:
> > I'd like to make a couple comments on your note below: Regarding
> > horizontal eye opening, serdes jitter tolerance is more a function of
> > the PERCENTAGE eye opening rather than the absolute amount in
> > picoseconds. That is, the uncertainty in the receiver's strobe
> > placement is a function of the eye closure -- the distribution of edge
> > placements it is trying to align to. Looking at your analysis below,
> > the 'Eyedelta%' (percentage of the bit) width is virtually identical
> > for the scrambled and 8b/10b encodings in each case.
>
> Hmm. I don't fully agree.
>
> To see the absurdity, we could talk about doing a 12.5Gb/s codec in
> 0.15um CMOS. By your rule of thumb, we shouldn't be daunted by the 80ps
> eye opening because it is still a fixed percentage of the UI when
> compared to a 2.5G system with a 400ps eye.
>
> There are fixed timing offsets inherent in a multi-phase CMOS design.
> These errors directly subtract from eye time-margin. A 300ps opening
> with a 50ps process dependant skew at the multi-phase transmitter mux, a
> 50ps skew in the front-end latch phases, and a skin-loss jitter of 50ps
> gives a link with a 300-150 = 150 ps margin. A lower speed code with a
> 370ps unit-interval would be degraded to 220ps margin. So, in this
> example, a 25% code overhead incurs a 46% timing penalty w.r.t. a more
> efficient code.
>
> I would buy your argument if the 8b/10b code was implemented in a
> process with 25% higher device speed. Otherwise, the fixed errors
> penalize a smaller unit-interval system to a larger degree than a code
> with a bigger UI.
I did say "serdes jitter tolerance is *MORE* a function of
the PERCENTAGE eye opening rather than the absolute amount
in picoseconds," not "...*ONLY* a function...." To see the
absurdity in the other direction, though, how well would
a 100Mb receiver deal with the 370 ps eye opening (that is,
an eye open 3.7%)? Not a pretty picture, I think. The
percentage is important, especially as it approaches 50%.
[snip]
>
> All things equal, a scrambled code will not show the same degradation
> unless the PCB is lengthened by 25% w.r.t the 8b/10b system.
I believe the scrambled code has an additional degradation
(above and beyond receiver difficulties) due to the run
length. In an 8b/10b system, the first bit to get clobbered
by skin effect is the 8th bit of K28.5...
|
_________ V _
...____/ \_/ \_...
...because the preceding edge is the latest possible and
the following edge is the earliest possible due to the
waveform reaching the maximum possible amplitude prior to
this bit. Longer run lengths make this marginally worse.
>
> However, regarding "a low-risk plan", I don't know of any backplane
> systems that are actually running with 3.125G - do you? I know that
> 2.5G 8b/10b is widely deployed.
This market is semiconductor limited, not PCB, I think.
Backplane applications seem to want the fastest stuff
available. "If you build it, they will come." ;-)
>
> Best regards,
> --
> Rick Walker
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Jenkins Phone: 408.433.7901 _____
LSI Logic Corp, ms/G715 Fax: 408.433.7461 LSI|LOGIC| (R)
1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
Milpitas, CA 95035 http://www.lsilogic.com |_____|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~