Re: Comments on postings on 64/66 control code mapping
I would like to thank Ed Grivna for his analysis and comments.
I think somehow we have a fear of the future here that is high on opinion
and low on facts. Like it or not we are going to higher rates --- even
than 10 Gbps-- in the future. Design baselines and methods will have to
change. I don't think Intel, et al, are going to slow down the processor
speed advances just because people want to use 20 year old box
designs!. And clock lines themselves are more persistent than 8b/10b coded
lines which statistically have some randomness.
But, we have built not just one, but 12 lanes on standard FR4 materials
considering harmonics to 2.54 GHz and higher with <1% crosstalk in a dense
lane packaging using 8b/10b codes with all the repeat persistent patterns
you get with Fibre Channel idle. It can be done, it is not "black magic",
just good physics and engineering principles. In mass production this can
be made inexpensive.
Another area we have observed is poor power supply design bleeding into
the GBICs and requiring extra engineering to PROTECT the GBICs. Don't
forget -- this is a two way street. Not only do high speed devices CAUSE
interference, they are also susceptible to interference from other places,
many of which are either poorly designed, poorly installed or both.
We should realize that in part we are using the standards process here to
educate the designers and marketplace on the requirements to participate in
this new high rate world.
End users want quality and workability, not simply lowest component price.
It is a system and use optimization problem, not simply a "component one".
My comments here should be interpreted in general and not as an argument
for or against four lanes or one, or one coding scheme versus another.
Infinity I/O, Inc.
At 08:08 AM 3/17/00 -0600, Ed Grivna wrote:
>please see my embedded coments below.
> > Kamran /Rick/All
> > I know I still have more lab verification, and I know 8B10B is
> > well known/used, but we have got to do something to slow the
> > XAUI/HARI portion down a hair.
>By "slow down" I'm assuming you mean slow down the rate at
>which implementaions are being developed around this.
> > Aside from concerns we have all been addressing, there were two
> > more brought to my attention yesterday in a customer meeting.
> > The first is if we are worried about being like Infiniband, and
> > I am not saying we should be and I am not saying we should not be,
> > but 8B10B at 3.125 in a PC is 'nuts because most PCs barely
> > pass emissions as it is'. The addition of the spectral content
> > of 8B10B could be a disater for that interface. We should be
>You are correct that some PCs are built poorly and have EMI problems.
>But this is not true of all PCs.
>You also need to keep in mind that most PCs are built toward a
>completely different cost structure than what is being considered
>here. Then you also need to consider that the PC enclosure design
>that most companies use has changed little in the last 20 years.
>At that time PCs ran with a processor clock rate of 4.77 MHz. Now
>the same processor internal clocks have passed 1 GHz.
>I don't think you can blame the EMI problems of a PC on the 8B/10B
>code. For example, I've seen the radiated emissions of a PC
>REDUCED when the internal IDE drives are replaced with a Fibre Channel
>card. Why? Simple, the IDE bus in PCs is an UNTERMINATED transmission
>line. It has generates tons of EMI, but is still used because its
>Yes, you CAN build lousy cards that will radiate something fierce.
>But you can also apply good, sound, engineering practices to build
>that same card such that it will be very quiet. The same is true for
>optical modules. There are GBICs out there that are made with
>full metal shells to keep the EMI down. Others are built with
>plastic shells. Some of the plastic ones are much worse than the
>metal ones. Some plastic ones are BETTER than the metal ones.
>The differnce? The engineering INSIDE the module.
> > careful, if that is one of our resaons, about trying to be similar
> > to an interface that most likely will have to change.
>Hmn. Most likely will have to change? Where did this come from?
>Do you know something that the rest of us don't? Unless you
>can back this statement up with some facts, I will consider this
>to be an unqualified opinion.
> > The second actually bothered me more because I never thought about
> > it and have to do some more verification to determine validity,
> > but the customer pointed out that only fr-4 was readily available
> > in his country, where as some of the materials I have been using
>I'm missing something here. One of the target goals of XAUI was
>to operated on FR4. So whats the issue? AMP/Tyco has presented
>data showing even raw 10 GBd signalling will work on FR4 (not very
>well, but it works) so long as you don't add any connectors.
>Mike Jenkins of LSI Logic has presented data showing >2.5GBd signaling,
>in CMOS, over 24" of FR4, with an eye opening at the RX end
>big enough to drive a truck through. And oh by the way, this was all
>done with 8B/10B coded data streams.
> > was very difficult for them to find. That being said, with respect
> > to skin effect of the geometry and the erratic loss tangency
> > of fr-4 ( the real part isn't pretty either ), the slower speed
> > can make a difference.
>Absolutely. Thats why XAUI splits the data into 4 streams in the
> > > If it appears that 8B/10B is no longer desirable due to EMI and
> > > skin-loss limitations on the PCB, we will be quite happy to
> > > present our ideas w.r.t. using 64b/66b on the 4 XAUI lanes.
>I don't believe that anyone has shown any data to this effect.
>Until some one does, this is all speculation. Unfortunatly we
>can't design based on speculation, we must limit ourselves to the
>available facts, or perform the necessary resarch to validate
>(or invalidate) alternate hypothesis, when can then be presented
>as new facts.
>If you are signing up for this research effort, I believe you will
>find everyone in support of your efforts. None of us are afraid
>of new knowledge. But we must all keep our guard up to ensure
>that what we are basing decisions on are facts, and not just
> > >
> > > --
> > > Rick Walker
> > Joel Goergen