*From*: "Alfred P. Neves" <al.neves@xxxxxxxxxxx>*To*: <dave.instone@xxxxxxxxxx>, "'steve weir'" <weirsi@xxxxxxxxxx>*Date*: Mon, 17 Jul 2006 10:23:50 -0700

List, Maybe the safest approach to return to the mathematics. An interesting perspective is the limit of sinx/x when x-->0? It is 1, but does not equal 1. sin(0)/0=0/0=0 doesn't it? Small apparent distinction but a very big mathematical difference. When I learned that this abstract concept troubled me I knew I wasn't going to be a mathematician, just another lowly engineer. The concept behind peak-peak Total Jitter (TJ) is ill-defined, period. We deal with the fallacy of a well-defined peak-peak jitter because is represents a useful tool for solving jitter problems. Trying fixing a backplane with a reported poor BER performance and that is the only information you have. Where would someone start? Now, state that the excessive ISI is being created by poor connector launches contributing X psec peak-peak of DJ at 5gbpsec and you have a clue on where to start (call Teraspeed Consulting LLC). Fixing this problem makes for a better system, even if we don't really know the peak-peak jitter; we have improved the BER and the jitter however. The best we can do to circumvent the fallacy is make a large amount of measurements with a direct BER measurement tool such as a BERT and establish a specified confidence interval. Interestingly, even a direct measurement of BER only yields the estimate of the BER parameter. You would need an infinite number of measurements to insure perfect 100% confidence level(another limit!). You can also use a useful RJ-DJ, TJ extraction tools and hope we meet the conditions for the underlying methodology also, but the Agilent Jitterfest showed some interesting results to say the least, and these methods are based on a specified model. The Dual-Dirac model can be used to analyze a jitter process under certain conditions, but this is only a model and represents the prevailing method for RJ-DJ view of TJ at a specified BER. This relatively simple, but very useful model, can only be used to estimate TJ at a BER, if, and only if, the tails of the jitter pdf have reached their asymptotic form well above the BER of interest. We therefore create a condition that if linearize the outer RJ dominated edges of the jitter distribution we have straight lines, which the specifications refer to as Q-scale. As long as the measured Q-scale is linear and the tails of the jitter pdf have reached their asymptotic form you can determine the TJ(BER) for this region. The important point is that we establish a BER region of interest, impose some constraints, and for this region we can estimate TJ=2Qber+DJ(sigma-sigma). (Read Agilent's excellent papers on this topic, Teraspeed Consulting also runs a 3 day jitter class where we discuss this model in detail). Another practical limitation of practical jitter methods, and confusion, is the central limit theorem. If we add non-Gaussian sources of jitter (DJ), with any distribution (finite mean and variance), the limit of adding an infinite number is a resulting jitter process with a Gaussian distribution. A good example is crosstalk, which is not RJ, but fools many of the tools into thinking that it is pure RJ, when there is only 1 source of crosstalk. However, in the limit of adding infinite sources of crosstalk, your resulting jitter distribution IS pure RJ according to central limit theorem. Right now many of the RJ-DJ extraction tools do not handle even a few contributing sources of DJ added together (they think they are RJ) and these methods need to be supplemented with field solver analysis, and measure-based analysis using TDNA and VNA analysis (Ransom Stephens and I wrote a paper in last DesignCon regarding this) for backplane type systems. I'm still waiting for that gold bar to drop on my desk though... 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 David Instone Sent: Monday, July 17, 2006 7:32 AM To: steve weir Cc: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: Fibre channel interconnect margins Steve, and list Lets try this another way. The original statement that started all this was: > I suppose we're way off in the weeds, here, but is the noise actually > >unbounded? Or does it just behave in a Gaussian-like manner within > >the realm of times/rates that matter for shipping product? My take on this is that in real world circuits the jitter, or the effects of the noise, is bounded and only behaves in a Gaussian like manner within limits. Why do I say this? Well if I want to produce a signal with random jitter, ie as per definition unbounded and Gaussian, then I buy a noise source add its output to my perfect un-jittered signal using a limiting amplifier and I get a signal with 'Random Jitter'. Well for a start I have to pay around $5000 to get a noise source that stands half a chance of actually being Gaussian down to just +/- 7 sigma and even then unless the waveform I'm adding it to has the right shape it's still not going to produce truly Gaussian jitter. So back to reality, is my 50c IC with $50 PSU really going to have truly Gaussian unbounded jitter out to infinity, or even +/- 7sigma, when my lab source is struggling to do +/- 7 sigma? Not a chance in hell, well maybe 1 in infinity. So the spec says RJ is unbounded and Gaussian, nice, convenient and simple. But what does it mean in practice? Could it mean that within the limits of your measurement, and also the ability of the jitter producing mechanisms in your product, that the jitter approximates a Gaussian curve, I believe so. Now I'm going to risk diverting the thread again. A Gaussian curve is a mathematical function that best fits naturally occurring events that seem to be random. Does this force randomly occurring events to fit a Gaussian curve out to infinity? Dave steve weir wrote: > David, I did not regard it as an attack just an opinion that is > different and worth discussing. > > The basis of our disagreement appears to be in the definition of > bound. I look at things from the standpoint of electrical noise. > Time interval in a timing circuit is the result of the magnitude of > some electrical quantity, and is always causal, each event defining a > new interval follows the previous. This means that noise effectively > multiplies the interval by some factor 1/oo <= K <= oo. Jitter is > still unbounded, but every incremental interval has a positive duration. > > So far we have been talking about noise in the oscillator itself. > > Now, let's see what a PLL does to this quagmire. If noise hammers the > VCO then the PLL feedback loop applies gain to divide the effect of > the noise. If we still believe in infinity, infinity divided by > anything is still infinity. In practice will the oscillator stop for > an unlimited time? It will only when it fails. On the other end, two > successive pulses can occur essentially on top of each other. > > A receiver PLL will take a finite amount of time to realign within a > fixed amount of phase to the jittered stream for the case of the > oscillator event, and will take a different, much longer amount of > time to align to the short term frequency offset that noise in the PLL > error amplifier causes. The phase error between the source stream and > the recovered clock in the latter case generally follows a classic 2nd > order step response. The golden PLL is a PLL with specific frequency > response and damping. Even if we have a PLL that uses N=1, the PLL > only starts correcting after a timing error is already apparent. For > a timing error of sufficient magnitude data moves outside the timing > window, a data recovery error is guaranteed, and no PLL is going to > prevent that. A nasty little problem that gets into systems is power > supply noise coupled into the VCO and/or error amplifier by one means > or another. For systems with high Ns it can get really ugly. > > On a slightly different tack, for a PLL using a PFD, the unit interval > is that at the phase comparator input which is VCO/N or Fref. Noise > whacking the error amplifier will push the VCO off frequency until new > information arrives to get it back. If the noise jumps the VCO up it > can take up to VCO/N cycles before we start correcting. If noise > slows the VCO down, it will take at least one cycle of Fref to get it > back. > > So, I think the only place that we are having any semantic trouble is > on the notion of unbounded noise. While we likely will never see such > a thing, the math really does tell us that an interval can go > virtually to zero 1/oo, or last forever. I think the important part > of this concept is that it says that random noise ( jitter ) will > create data errors sooner or later. And I think doubt about that is > where the discussion began. The tough issue is finding the actual > random jitter. The value is often way overestimated because > deterministic jittter that we have difficulty correlating gets > incorrectly classified as RJ. People turn the crank on the math and > conclude that their links are 10E-12 or 10E-14 when they are really > more like 10E-20 from an RJ standpoint. > > Regards, > > > Steve. > At 06:35 AM 7/4/2006, David Instone wrote: >> Steve, >> Firstly, my initial response was in support of Alan's posting not an >> attack on your reply to him. Your definition follows that of FC and >> other serial standards. FC defines random jitter in FC-PI-3 as >>> jitter, random (RJ): Jitter that is characterized by a Gaussian >>> distribution. Random jitter is defined to be the peak-to-peak value >>> for a BER of 10-12, taken to be approximately 14 times >>> the standard deviation of the Gaussian distribution. >> >> >> So lets look at it both ways >>> That means that any single incremental interval can never have >>> jitter of more than -(1UI-epsilon). >> If that jitter is all Gaussian then hasn't it been truncated, or do >> we have to say that it's not RJ because it's bounded? >> >> >>> If on the other hand we want to integrate phase compared to some >>> distant fixed timing reference, then a stream can theoretically >>> precess total time interval error by an unbounded amount. >> FC measures jitter against a timing reference derived from a golden >> PLL. If over any finite period of time the RJ causes the frequency >> as seen by the PLL to change then the PLL will move the VCO, thus >> creating a limit to the max observed RJ. If the RJ is distributed so >> that the frequency does not have to change then the 'single >> incremental interval' effect will apply. Have we not then got a >> jitter distribution that is Gaussian in form but with limits to the >> maximum deviations? >> >> Regards >> Dave >> >> steve weir wrote: >>> David, >>> >>> I would just like to make certain that we are talking along the same >>> lines here. The operation of the oscillator, no matter what its >>> construction is causal. So the closest that any two events can >>> occur is epsilon. That means that any single incremental interval >>> can never have jitter of more than -(1UI-epsilon). >>> >>> If on the other hand we want to integrate phase compared to some >>> distant fixed timing reference, then a stream can theoretically >>> precess total time interval error by an unbounded amount. >>> >>> Regards, >>> >>> >>> Steve. >>> At 03:10 AM 7/4/2006, David Instone wrote: >>>> Steve, >>>> I didn't disallow an infinite time between events. I allow for >>>> the time between events to be between 0 and infinity, but not >>>> negative. Thus if I'm measuring the time between edges and my >>>> reference I can measure an infinite time between my reference and a >>>> following edge but never more than 1 UI between the last edge and >>>> my reference. That last edge could of course be from a edge that >>>> should have occurred an infinite amount of time in the future, but >>>> from the point of view of the measurement it's only 1 UI early. >>>> Regards >>>> Dave >>>> >>>> >>>> steve weir wrote: >>>>> David, I disagree. It does not change causality. It changes the >>>>> incremental delay between two events. Imagine for a moment that >>>>> we have a simple relaxation oscillator as the basis of our VCO. >>>>> In the presence of an infinitely large noise pulse, which is the >>>>> limit for random noise, it takes an infinite amount of time for >>>>> the ramp to reach the threshold. The next cycle will not begin >>>>> untilt he current cycle completes. It may sound like something >>>>> from Douglas Adams, but it really is mathematically and physically >>>>> sound. >>>>> >>>>> Regards, >>>>> >>>>> Steve. >>>>> At 01:50 AM 7/4/2006, David Instone wrote: >>>>>> Because it makes for a nice simple clean definition. However, I >>>>>> believe you have to take the real world into consideration. >>>>>> Allowing the RJ to be really unbounded means that each edge in a >>>>>> bit stream could be advanced or delayed by an infinite amount. >>>>>> Taken to extremes this means that the order of edges could be >>>>>> reversed. This is obviously absurd, the measured time between >>>>>> edges can reduce until it is zero, it cannot go negative. The >>>>>> time between edges can of course go to +ve infinity, but that >>>>>> isn't a bit error, the system has failed or been switched off. >>>>>> steve weir wrote: >>>>>>> RJ really is unbounded by definition. >>>>>>> >>>>>>> Steve. >>>>>>> At 09:46 AM 7/3/2006, Steven Kan wrote: >>>>>>> >>>>>>>>> Date: Fri, 30 Jun 2006 21:48:56 -0700 >>>>>>>>> From: Alan.Hiltonnickel@xxxxxxx >>>>>>>>> Subject: [SI-LIST] Re: Fibre channel interconnect margins >>>>>>>>> >>>>>>>>> In fact, I think that companies DO ship products that toss a >>>>>>>>> random error approximately every 10e-xx or so. Why? Because >>>>>>>>> the statistical >>>>>>>>> theory behind those errors is that random/Gaussian noise is, by >>>>>>>>> definition, unbounded - errors are a fact of life, even if the >>>>>>>>> error >>>>>>>>> rate is very low. >>>>>>>> I suppose we're way off in the weeds, here, but is the noise >>>>>>>> actually unbounded? Or does it just behave in a Gaussian-like >>>>>>>> manner within the realm >>>>>>>> of times/rates that matter for shipping product? I suppose if I >>>>>>>> sat in my >>>>>>>> chair for long enough, a truly unbounded system might cause a >>>>>>>> gold bar to >>>>>>>> pop into existence on my desk, but my empirical GBR (gold-bar >>>>>>>> rate) is >>>>>>>> currently 0. >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> --- >> >> > > > -- Dave Instone Oxford Semiconductor Ltd 25 Milton Park Abingdon Oxon ox14 4ea UK www.oxsemi.com +44 (0)1235 824963 ------------------------------------------------------------------ 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: //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: //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: //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: //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

**Follow-Ups**:**[SI-LIST] Re: Fibre channel interconnect margins***From:*Andrew Ingraham

**References**:**[SI-LIST] Re: Fibre channel interconnect margins***From:*David Instone

- » [SI-LIST] Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins
- » [SI-LIST] Re: Fibre channel interconnect margins