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: //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