Re: 64/66 control code mapping
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.
> What isn't shown (and can't be) in those eye diagrams is the relative
> difficulty of the receiver's job. Run lengths are a huge factor here.
> Analyses from several sources support run lengths as a big
> consideration in defining worst case jitter tolerance patterns.
Yes. This is probably something worth thinking about. PLL's for long
run-length codes need tri-stated loop filters. In my experience, we've
done monolithic SONET retimers that are as easy to build and as cheap as
FC-AL circuits. However, I agree that YMMV and everyone will have to
assess this risk for themselves. My concern is more for the PCB margin
rather than the chip design.
> Second, I want to take exception to your statement: "Once we
> reach the long PCB trace, it is clear that 8b/10b has fallen
> off of a cliff."
Perhaps I should have said, "is falling off of a cliff". The actual
"crash" has not quite occurred at 22 inches. The eye will definitely
have crashed by 30 inches, though.
> http://grouper.ieee.org/groups/802/3/ae/public/nov99/jenkins_1_1199
> shows hardware results for virtually the same physical case. The eye
> after 20 inches is beautifully open due some simple pre-emphasis. I
> just don't see the cliff (at least, nowhere nearby).
I agree. With equalization, the distance can be improved. My comment
was about the particular set of data that we have before us. In this
data, 8b/10b is showing significant reduction in 010 pulse amplitude for
a 22 inch trace. This eye pattern what occurs just before the onset of
eye closure.
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'm not arguing against any aspect of 64/66 code here. My only point
> is that serial data transmission with 8b/10b code is a well-developed
> technique in the toolbox of a large and growing number of vendors. In
> my opinion it is a low-risk plan for moving 3+ Gb/s across
> 20-something inches of PCB.
Once again, I agree. I don't think it is clear yet if it is worth
changing the code to buy a 25% distance margin on the PCB. I'm simply
trying to articulate the issues so that we can have a better chance of
making a decision.
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.
Best regards,
--
Rick Walker