Re: 64/66 control code mapping
Ed, My comments are below.
> By "slow down" I'm assuming you mean slow down the rate at
> which implementaions are being developed around this.
I mean, the slower the speed of the interface we can have that still gives
us something functional, the better off we will be with respect to board
design. There are other issues that are releived, possibly the PLL, power
filter requirements, etc.
The interface doesn't matter to me what it is - XAUI, HARI, XGMII,
whatever, I just like things slow.
> > 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.
At this point Ed, wake up. I can walk into a suppliers warehouse and take
10 machines - any 10, go to an emi site and I consider myself lucky to find
80% pass 80% of the time.
> 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
> CHEAP.
Ed I was not trying to blame any EMI problems of a PC on any one thing in
particular. My point was that if the PC is already something that has to
be built as cheap as possible, then who would go through all the trouble of
putting a code scheme in place that won't make it any cheaper - may not
make it cost more, but even a penny matters at their volumes.
> 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.
And at what cost, Ed. You are quick to point out that we need better
engineering practises to solve the issues, but the bottom line is those
practises, when implemented, have some cost associated with them.
> > 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.
You consider this an unqualified opinion - well, I will save this for a
personal response. That said, think about it, Ed. It is all about cost.
When a customer designs a solution and as a vendor you don't penny into it,
you lost. I say it will have to change because the cost benifits won't out
weigh the new design costs. And NO, I don't know anything the rest of you
don't - I know the same things - I sit in a meeting and outline a better
engineering practice and the first question asked of me is what is the cost
associated with this.
> > 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.
Yes, Ed, and these are excellent presentations. And oh by the way, they
are based on research involving only the high speed traces - not a design
intented to account for the needs of the system such as the stuff you put
on a forwarding engine or what ever you can fit on your board besides the
PMD and the power source. That said, some of us like to have more eye
budget left over at the end of the day - because you know what, regardless
of what error rate you think we are designing to, when a diagnostics guy
and the reliability engineer get hold of the system for analysis, their
number is "ZERO". You understand that! It doesn't matter if it is a
copper trace or a fiber. Any thing other then "ZERO" at the design level
is not going to fly. Since you might require facts here - this is true at
Lucent, Nortel, Cisco, and IBM for sure. And Lucent included Cascade,
Ascend, Netstar, and Whitetree, as well as Lucent. Hope that is enough
companies for you.
> > 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
> first place.
>
> > > 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
> speculation.
So Ed, let me ask you - do you think when DMD came up that it was just
speculation? Keep your guard up, that is fine. It makes the conversation
interesting. But don't claim this is all speculation. If the entire
reflector wants me to show the EMI problems I have seen with every company
and vendor I have worked with over the last fifteen years, then I can give
you all the proof you want - I will never work again in this field, but I
can retire back to the family farm and milk cows for a living, so what do I
care. But I really don't think anyone wants to see their dirty laundry
shown in public. So, I have tried in a fair manor to these truely great
vendors and companies I have worked with to make statements that I 'know'
will make designing systems easier.
If you should feel that I am not technically qualified to participate in
these discussions, then take it up with the chair and have my name removed.
I would hope that some of my perfessional colleges do not feel that way.
Joel Goergen