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

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.)


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%.

> 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      |_____|