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.
Regards,
Mike
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 (apologies...no 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,
> > 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).
>
> 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
components.
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 http://www.lsilogic.com |_____|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~