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

Re: 64/66 control code mapping

Hello Joel,

I could have done a better job making my points clearly in the
earlier note.  Please let me try again below on a couple issues.
Thanks much for your thoughts on this matter, Joel.


Joel Goergen wrote:
> Mike,
> > 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.
> I don't see it this way from my comparisons of vendor data sheets.

	Lots of vendor data sheets will follow standards specs.
	With Fibre Channel as an example ( rotten
	eggs or tomatoes, please, it's just what I know), the
	2G jitter specs scale pretty closely from the 1G specs.
	That is, about the same percentage jitter.

	To motivate it another way, worst case patterns attempt 
	to fake out the receiver by generating late edges (due
	to long run lengths), then switching to early edges (due
	to ...010101... patterns).  Switching back and forth can
	excite any resonances in the response.  But even without
	resonance, if you can move the edges by 50% of the bit time,
	the receiver cannot move the strobe immediately and will
	mis-sample bits.  That's why percentage is important.

	(This brings up the question of how to generate such patterns
	for scrambled codes.  Are there prescriptions for how to
	'reverse engineer' patterns?)
> > 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.
> I don't disagree.  And I think Shimon ( I know I screwed up the spelling ) asked
> the question at the end of the presentation that he would like to see the effects
> the receiver has to deal with.  I have not had time to go to serdes vendors and
> ask them for help - though TI, ME and Agilent have offered suggestions and
> input.  We have to look at this, but I am told at the moment it is not a
> 'stopper'.

	We're a serdes vendor :-)  It's probably not a stopper, I
	agree.  But it is (for some of us, anyway) terra incognita.
	Right now, we can build 8b/10b systems, then spec developers 
	can spend their time on tougher problems.

	On the EMI issues, as I've said, lower swings and buried
	signal lines will help a lot.  There are other tricks,
	but that gets into the byte vs. word stripe thing....
> > 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."  The 60% eye opening shown is well within
> > receiver capabilities.  Specifications require them to work
> > down to 30 or 35% eye opening.  Also, the presentation,
> >
> > 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).
> Are you making the assumption that the high speed trace will be a perfect
> geometry, or that it will be given absolute priority over everything else on the
> board.  If you are, then the cliff won't be there.  And you are correct, anyone
> familar with wave guides can help compensate the eye - or it can be done in the
> chip.  But if you consider the high speed stuff might get treated second, third
> or tenth, then the picture changes a quite alot.

	The 20" PCB traces used in the eye diagrams shown in the
	presentation I referenced (jenkins_1_1199) were pretty
	much an afterthought in the board layout.  No special care
	was taken.  There were two vias and pads for six discrete

	On the compensation, it's best inside the chip, so systems
	folks don't have to get out any Smith charts (for those
	old enought to know what that is) to compensate on the board.

	Regarding PCB layout, the situation has gotten a lot cleaner
	since terminators moved onto the chip.  There's only a few 
	main things to ensure, and they are fairly easy to communicate
	to the PCB layout folks. 
> > 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.
> I really don't disagree with you.  And if there was a way to keep 8B10B without
> the over-speed, sign me up.  But the 64/66 and scrambling methods give the slower
> speed, have less spectral content to deal with, and allow more channel
> attenuation.  Yup - I know, they also require people to work hard and quickly to
> demonstrate the technical feasability.
> Take care
> Joel Goergen

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