Re: 64/66 control code mapping
Hi Rich,
I have had some time to think about this, done some more reading, looked at a few things, and can now
reply. I must say that your questions, if anything, have given me a deeper understanding of
rectangular waveguides.
> Ignoring all slides at >3.125 Gbaud since they are not relevant to XAUI traces,
> the 8B/10B eye is superior to the slower scrambled eye in:
A few years ago, I would agree with this. Having looked at several serdes vendors, I disagree with
Mike Jenkins comments to Rick Walker in a later thread dated today, that the serdes is specified
relative to the eye. I have seen the opposite - that the UI is a little lower for the lower speeds
of a die/pll for 2.5 then for 3.125. This indicates to me that the portion for the receiver at the
higher speed is larger of the total bit time budget, in relative terms. From my way of thinking in
real terms, and it doesn't have to be right, the slower speed parts take about the same physical time
as the higher speed parts for actually bit recovery - leaving a larger piece of time available for
use else where in the system at the slower speed.
> 1) Slides 9,10,33: Test Setup AC-coupled
> 2) Slides 14,15,33: Test Setup DC-coupled
> 3) Slides 19,20,33: AC-coupled with 5.5" differential pair
> 4) Slides 24,25,33: AC-coupled with 11" differential pair and two vias
> 5) Slides 28,29,33: DC-coupled with 5.5" differential pair
>
> The only slides which show the scrambled eye to be superior is for the case of a
> 22" differential pair and 4 vias in slides 26,27,33. In these slides it appears
> to me that the positioning of the vertical axis cursors used to indicate the
> vertical eye opening is a bit ambiguous. There is clearly less ISI apparent in
> the 8B/10B eye (slide 27) than in the scrambled eye (slide 26).
I have to agree with you here. But, and I forget but I swore I said this in my verbal portion of the
discussion, that the differences you are seeing in this slide is the effect of a real system taking
it's toll. Gosh, let me try to explain. There have been other tests shown by respected people that
show eyes traversing down fr-4, but these presentations have not approached teh problem from the
system stand point where the hardware designer has to put fifty pounds of logic in a 5oz bag :). So
what I did to determine if there was a problem was to develop a board and then fit in the high speed
stuff - or, if you will, make trade-offs at the last minute.
That said, I was worried about three basic effects ( okay, lots more .... ) DC Balance, Dj-Rj-ISI,
and channel attenuation/phase. The first two didn't get me too excited as did the third - the via
RLC models really screw up the phase and attenuation of the traversing wave. I was worried that the
higher speed lines when passing through a thick via, poorly fabricated, or lots of vias, would create
excess attenuation, and in some cases, phase delay creating multiple velocity groups ( you can see
this in a few of the slides ). What you are seeing in the 22inch slides are the effects of the
attenuation and phase. The UI is still roughly the same, but attenuation has finally reduced the
vertical.
But what I was trying to get across was that system designs will have these real life issues. I
think that Rick Walker and Rich Dugan's efforts in a table of channel attenuation and phase delay
values would help us solve some of this. If I know what part is available for the board, I now know
how sloppy I can be. I can't state enough how this kind of table can be helpful. I have to admit
the Agilent peoples are really good at bounding design parameters - makes the job of a system
designer easier during debug (you know what you violated :) ).
The other point I was trying to make was that the slower speed gives a physically longer eye opening,
giving me the room to play with equalization, larger budgets for ISI, Rj, and Dj, as well as the
ability to use a little bit wider geometry to fight off skin effect and trade for capacitance. What
I really want, and I am fighting for :), is more budget for the channel attenuation and phase. The
longer time in a slower eye gives me that.
So what does it do for me? Well, the first is it relieves my tight restrictions on vias - so the fab
guys can use standard processes for my design. The second is I can go with smaller tracks if I want
to and gain routing relief. The third is I can cheat on my impedance a little and squish the board
thinner to get a few more layers in.
> In a nutshell, the "eye" analysis seems to be either inconclusive or
> questionable since 8B/10B seems to "fall off a cliff" with respect to scrambling
> somewhere between 11"/2 vias and 22"/4 vias. Where is the cliff and what
> accounts for it? This is why I'm having great difficulty with your suggestion to
> "slow down XAUI a bit".
I think I talked about this above, but what you are seeing can be modeled in spice and shows that
certain trace and via combinations provide channel attenuation/phase that the transmitter transfer
function is not expecting. I can make this happen at almost any length.
> EMI and Coding
> --------------
>
> I know you mentioned EMI in your presentation. However, there is no data in the
> presentation comparing the EMI of an 8B/10B-based XAUI and a scrambling-based
> XAUI. I know that you asked me for 8B/10B patterns in Albuquerque and I gave you
> the worst case Idle pattern. I'd like to document both 8B/10B and scrambling
> worst case Idle patterns for XAUI for anyone interested in doing a fair
> comparison.
The 8B10B spectrum was using a KRKR pattern. The scrambled pattern was using a x^7+x^6+1 pattern
simulated with a 2^7-1 (both look the same). I was told, and the SLP presentation from Tom
Truman/Kamran Azadet descibes this, that the idle time in the SLP is scrambled. The other data I
had, but did not show because I had to confirm some things with Rick Walker, is the idle for 64B/66B.
In terms of the spectral idle response, I did show this as fare and true. You did point out that I
have to re-run the data with the exact pattern you describe below, but it will still be higher in
magnitude then the scrambled idle of the SLP or the 64B/66B.
I should be able to re-run the spectral stuff end of next week if I get in some extra lab equipment I
need to make absolute measurements.
> First of all, as Mr. Dan Dove pointed out in an EMI related note to this
> reflector yesterday, the worst case pattern happens during Idle. It is well
> known that EMI testing of GbE and FC equipment takes place while the equipment
> is generating an Idle test pattern for many logistical reasons.
I agree.
> Don Alderrou of an nSerial and I have also suggested a simple method to reduce
> the repeated nature of Idle by randomly relocating /R/ columns within an Idle
> stream. I'm wondering if it's possible for you to simulate the benefits of such
> a simple trick to reduce the EMI of an 8B/10B Idle stream. If not, it's OK, I'm
> just completing my action item to document the 8B/10B-based XAUI Idle pattern
> which should be compared against an SLP-based XAUI Idle pattern in any future
> analysis.
I will do this. But I got side tracked this week thinking this response and some other ones
off-reflector and one thing led to another ... and you get the idea. My heart has the system in
mind. If all my efforts only result in an improved EMI 8B10B, then I will have been very
successful. If I can get the slower speed, I will ask for a ticker-tape parade :).
Anyway, I should be able to work on this next week in Holmdel if I can borrow Giorgio's lab again.
Those optics guys get a little excited when the electrical guy touches that fishing line and jigs
lying all over the lab :).
> Based on the above two issues with scrambled codes vs. 8B/10B and other
> comparisons of pure scrambling vs. 64B/66B, it is not apparant to me that there
> is any benefit of scrambling vs. 64B/66B for XAUI. Now if you're saying that
> BOTH scrambling at 2.5 Gbps and 8B/10B at 3.125 Gbps are equally bad over FR-4
> and simply won't work, then we have a real problem. However, your "eyes" don't
> reflect that this is the case at all.
No, I am not saying scrambling at 2.5 and 8B10B at 3.125 is equally bad. But I tried to show that
the closer we can get to zero over-head coding, the more we can tolerate attenuation and phase delay
from the geometry.
Take care
Joel
PS - Sorry for the delay - I got tied up in a really good book on wave guides and I couldn't put it
down.