[SI-LIST] Re: Do you really ship products at BER 10e-xx ?

From: "Alfred P. Neves" <al.neves@xxxxxxxxxxx>

To: <Chris.Cheng@xxxxxxxxxxxx>

Date: Wed, 13 Apr 2005 16:32:21 -0700

Chris,
Your making really good practical points, but I still think these issues
come down to
1. Methodology
2. System Reliability of a designed/manufactured link with transceiver
3. Objective
You already discussed 2 - the systems your designing are reliable,
right?
Starting with Methodology then ... What engineering methodology do you
use to insure, Ill call it "almost perfect" BER in the system? After the
proto is constructed what verification methods are being used to confirm
your initial design methods?
In a recent 3 day Jitter class taught by Teraspeed Consulting, the
direction we have been using is a combined method of using 3D Solvers,
verification via measure-based methods using both TDR and VNA
s-parameters, spectrum analysis of PLL loop response (including
transmitter output when running clock like patterns), autocorrelation of
the accumulated or phase jitter and subsequent FFT (Wavecrest) to obtain
the power spectral density of the jitter, measuring large samples of
data and creating statistically significant bathtub curves (Synthesis
Research), and Digital Storage Oscilloscope using DL-11 Delay
(Tektronix), BERT (Agilent).
We illustrated a unified method for high integrity backplane design
using jitter data from different sources. For example, the power
spectral density should correspond to the FFT of the autocorrelation.
The DSO jitter numbers must agree with Wavecrest. Turning aggressors
off/on provides meaningful changes in the bathtub curves considering BUJ
type of jitter as measured with tools that capture a lot of data
(Synthesis Research) versus using 3D solver analysis of the system
crosstalk. Significant crosstalk is not hard to model or measure using
a VNA, and crosstalk can be analyzed with both the jitter boxes and
spectrum analzyer (if you can turn aggressors off/on) even though it is
very low probability.
Dealing with objective: Consider the objective of providing a Design
Team in a large semiconductor company with suggested design improvements
for a 3.125Gbpsec transmitter. Real problem, lots of $$$ on the table,
what's your methodology? How do you approach this problem considering
they want to use as much existing silicon as possible for the next gen
5Gbpsec part. Would you need to redesign the output driver, less
jitter on the multiplying PLL, lower VCO noise, greater immunity from
the VCO from supply junk?
Another example of a different objective: In an ATE test case, the
testers system clock, which was setting the sampling instances of the
A/D (DUT) was too jittery and the ENOB was not being achieved. A
significant yield loss and product introduction was directly impacted- a
bad thing after a product is designed, characterized, and ready to ship.
We directly referenced the RJ to ENOB (a few good IEEE papers on this)
and generated a target RJ specification. After designing a new clock,
the part achieved almost the theoretical ENOB we were heroes. We did
not have to over design the system however, and the solution took only
several days to implement.
I totally agree that if you have a good engineering team (Chris Cheng)
working the design a very good link with low power supply junk and use
well characterized and designed transceivers your not probably going to
have to deal with measuring 10's of Femtoseconds of RJ. However, not
analyzing RJ carefully and its impact on the system performance does not
provide a concerted methodology, and this method extends into the design
phase of the link using 3D solver analysis and meaningful eye diagrams
simulation of the links DJ.
Alfred P. Neves
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
Hillsboro Office
735 SE 16th Ave.
Hillsboro, OR, 97123
(503) 679 2429 Voice
(503) 210 7727 Fax
Main office
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed is the registered service mark
of Teraspeed Consulting Group LLC
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Chris Cheng
Sent: Wednesday, April 13, 2005 2:12 PM
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Do you really ship products at BER 10e-xx ?
Al and Tom,
Since both of your response to me are similar so I will just answer one
but the point should be the same.
Before we go further, let's also follow Ed's suggestion and not rat hole
this to a DJ/RJ debate.
I've play Cal Lottery long enough to know my early retirement plan is
not a probability function based on lottery. Neither can my system
design.
At the end of the day, I believe most of the phenomenons you mention
below are either predictable/bounded or the probability distribution is
so small that it will be dwarfed by the predictable noises.
>Any real system, with a real transmitter generating some very small
>finite amount of Random Jitter, RJ, cannot operate "error free". It is
>an issue of probabilities. By definition, RJ is unbounded, therefore
>there is always some probability of a failure.
Definition is arbitrary, you can claim RJ is unbounded but we need a
real example to show why a real system phenomenon is unbounded. Just
because the spec says so is meaningless.
>The jitter issue, specifically regarding serial links such as
>backplanes, can be broken down into 4 primary categories:
>1. RJ generated from the transmitter - due to Transmitters VCO and
>Reference clock jitter transfer
I have done enough PLL analysis and testing in a digital environment to
convince myself the jitter component induced by the supply noise dwarf
any reference clock jitter transfer. And the supply noise induced jitter
is a very predictable phenomenon that is clearly not unbounded. You can
both simulate and characterize the behavior (BUTT). One can argue about
whether the supply noise can be predicted but with proper filtering and
power distribution, they can be limited to guarantee the jitter will not
exceed certain limit (once again, a bounded limit).
>2. Deterministic jitter (DJ) due to Transmitter - Duty cycle
>distortion and Intersymbol interference, periodic jitter due to power
>supply and plane resonance
Once again, can be simulated, measured and bounded.
>3. DJ due to the physical link - losses in the system (resonance,
>skin, dielectric), impedance mismatches, crosstalk, resonances
Ditto.
>4. Tolerance of the Receivers - BER measured with combinations of RJ,
>DJ and swept PJ (T11.2 Annex A)
If the above phenomenon's are bounded, it will becomes a simple whether
you make your setup/hold time or not. Nothing undeterministic about it.
>Of course, if a good transmitter and a well designed link and a
>receiver with significant tolerance is incorporated into the design,
>the actual BER will appear to be perfect, and it may be directly
>impractical to measure. In this case, it may be necessary to add
>jitter to see how the system tolerates it with respect to the receivers
>tolerance. A system with low RJ and significant DJ, with steep bathtub
>curves will not start to have a moderate 1E-8 BER type of problem, it
>will probably have catastrophic loss of lock and BER problems. Chris,
>Andy I think this is the behavior you were describing, no?
May be, but it sure sounds like some instrument company or spec
committee try to push some 5 sigma spec down my throat and say "ah ha,
even though your measured jitter is blah blah blah and your system is
working, but 5x sigma later you are doomed so you need our help..."
>I would pose an interesting question for Chris - if his particular
>system has 1ps RMS more jitter on the REFCLK for a 3.125Gbpsec
>transmitter (if it had 1psec RMS initially, it now has 1.414psec RMS
>now), would it still meet BER performance for the full link? What is
>your confidence it still works? How much BER testing would be
>required? How well is his oscillator vendors testing their product for
>jitter and phase noise?
I would say I don't care because I believe the jitter induced by supply
noise will dwarf that input reference transfer. 1 or 2ps jitter is
NOTHING compared with the jitter induced by supply noise at the right
frequency.
>How about 30mV more peak-peak switching noise at 400kHz - how tolerant
>are the PLL's from losing lock, multiply the higher freq components and
>creating a serios PJ problem, how would this impact the Receiver
>tolerance - would the system still work, would you now have occasional
>failure?
Now that's an interesting thought and I believe where most parts can
fail. But is that an unbounded phenomenon ? I don't think so. Afterall,
the same 30mV that will hit the PLL supply at say 100MHz will probably
never fail the system no matter how long you wait. The behavior and
response of the PLL can be simulated and predicted. And like I said
above, that's why companies pay me peanuts to design power distribution
system that doesn't have 30mV of noise at 400KHz in the first place (or
at least protect the PLL with enough filters that the VCO won't see that
30mV).
>This is not meant to be critical in any way, but unfortunately most
>BSEE programs do not require a single class in Stochastic Processes
>(after all who in their right mind would elect that class), and that is
>why a lot of the engineering community graples with abstract jitter
>issues. We have not been trained to think "stochastically".
Sorry Al, I don't know jack about stochastic process but none of the
above is undeterministic or at least big enough when compared with the
predictable part.
I would propose another explanation for these BER 10e-xx spec or bath
tub curves for electrical physical channels. It is based on the laziness
of the engineer who really doesn't want to dig down to analyze and
predict these effects such as ISI, PLL jitter or crosstalk so he/she
just stick the probe at the receiver and measure the jitter and say
"hmmm, I don't know where they come from so let's just call them
noise/jitter and extrapolate 5x sigma to sand bag myself with enough
margin and ship it." And that I suspect, is why you will ultimately have
those intermittent failures.
And if you bring in Mr. Heisenberg, I am out of here.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
http://www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
http://www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu