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

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