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

Re: 64/66 control code mapping

Many excellent points Joel.  Just a few minor points of
rebuttle below.  I ahave also removed some of the earlier material
to reduce the size of the message.

> Ed, My comments are below.
> 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.

Understood, though I had actually hoped it might have been the first.
I still think that too many things are being "cast into stone" as
far as implementations without the requisite background work being
done first.

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

Agreed.  And as I referenced, with clock speeds getting faster and 
chassis designs remaining the same, it will probably get worse before 
the FCC cracks down and gets this problem corrected.  This is one of
the reasons I generally build my own machines rather than buy them.
It generally costs more, but at least I can have my computer on 
and my kits can watch TV at the same time.

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

You are correct.  Pennies always matter.  Ford found that out with
the gas tanks on Pintos.  Unfortunately they found out the hard way
that if you shave the margins too thin, it will cost you more
in the long run.

But again, we are missing sight of the target here.  The goal here is
not to offer 10GE at the same cost as 1GE.  I believe we are looking at
a cost target increase of 3x for a 10x increase in BW.  That I believe
IS do-able.
> > 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.

Yes they do.  Some of the added cost in 10GE will be in materials, and
some will be in design.  But cost is cost, no mater the source.  We as
engineers need to figure out how best to meet the cost target based on
the system level requirements and the resources available.  Not everyone
will be able to do that.  Thats called competition.  In any competition
there will be some winners and some loosers.

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

I know.  I just went throuugh the same excercise myself.  But just
because cost is an issue doesn't mean its the only issue.  Yes it
mist be considered, but it must be considered in concert with the
other requirments of the design of product.

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

I think you will find that the eye budget left on these links is quite 
large.  Unlike an external link where we often require a 30% eye opening
after all random and deterministic jitter components are allocated,
these internal signals are providing >80% eye opening at the receiver.
Since these are copper based links, the jitter present is predominantly
deterministic; i.e., they do not suffer from the large random jitter 
expansion that takes place in optical links.  If a CDR cannot pull an
error free signal from an 80% eye opening, then you have a CDR that
needs some work, not the remainder of the link.

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

No I don't.  But until presentations were made to document both the
existence and the effects of DMD it was not considered. Once it was
proven through actual data to be "real", it was addressed by 802.3z
in both the optical interface spreadsheet, the link requirements,
and even a specialized patch cable.

> Keep your guard up, that is fine.  It makes the conversation 
> interesting.  But don't claim this is all speculation.  

Speculation may not be the correct term.  An un-proven hypothesis
would probably be a better description.  As a hypothesis, this
makes this an edjucated guess.  Many such guesses are based
on knowledge of previous systems and previous test results from
similar applications.  these hypothesese MAY be correct, but until 
actually implemented, either physically or in models that reflect 
the specific implementation in question, it remains a hypothesis.

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

You really WANT to milk cows?  Man I got tired of getting up at 4AM
a LONG time ago (why do think I'm in engineering now?).

But seriously, yes I'm sure you did find EMI problems.  And you
also applied your skills as an engineer to correct them.  Some of
these corrections probably involved only minor changes to the product,
and some of them added cost to the end product.
> 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.

Just the opposite.  You are imminently qualified.  Thats why I'm 
responding.  Your statements include much in areas where work
needs to be directed to either prove or disprove the hypothesis
in place.  I just want us to make sure that the final decisions 
aren't based just on hypotheis, but are based on facts.

I also consider you to be one of the few people capable of such
proofs or disproofs.  I may not fall into that same category.
Again, I do not believe ANY of your statements to be false.
But I do believe that data on many of these has not yet been
presented (to the comittee, in an open forum) to either prove 
or disprove them.


Ed Grivna
Cypress Semiconductor

> Joel Goergen