All, After having read the whole set of emails (I think), I've found little discussion of the TX/RX equalization IP and its effect on channel behavior. This is admittedly a complex problem, but it's also the problem that we're trying to solve. What matters is that the RX can reliably receive data ...how are we to predict this if we don't include the TX and RX capabilities in our analysis? What I hear Scott and Al saying is that the details of the channel model matter. Roughing out the channel model, neglecting differential / common mode conversion and then running a "gazillion" bit simulation [Nice, Al] isn't going to get you the precise answer you wanted. I agree - there's not much point in running a detailed analysis based on approximate data. The hardest part of the SI engineer's job is being realistic about what simulation results do and don't represent, given the collection of imperfect data, confusion and hype we all have to work with. I also hear Scott and Al saying (and I agree) that there are limits on what can be modeled. Computers are ready to give you answers with as many decimalplaces as you want, but that doesn't make them meaningful. There's a critical difference between precision and accuracy that doesn't get discussednearly enough. The fact is, manufacturing tolerances exist, modeling the detailed consequences of those variances (laminate weave, to name one) is difficult, and properly accounting for those effects in end to end link analysis is even more difficult. Frankly, that's what we're paid todo ... understand the phenomena that exist in a physical system, the limitations of the data and modeling methods we have to work with, then put the pieces together to predict how a design will work. That's engineering, in my opinion. Worst case eye analysis has its usefulness, but it's often oversold as a "push-button" solution to a very complex problem. What's been discussed hereis based on Peak Distortion Analysis (PDA), an analytical method for using a pulse response to predict a worst case stimulus pattern for eye closure. PDA predicts worst case eye closure according to some specific metric (for instance, minimum eye height in the middle of the eye opening). It's traditionally been used as a front-end for time-domain SPICE analysis, and answers the question "given that I can only simulate a limited number of bits, what pattern should I use to look for a worst-case eye opening?" It's based on the assumption that any TX/RX equalization is included in the pulse response, and that equalization is both linear and time-invariant (LTI). Statistical analysis is often confused with PDA, as they're both statistical techniques. In some ways, statistical analysis is just PDA the other way around - it takes the pulse response and predicts the distributions of the eye at the receiver. It makes the same LTI assumptions that PDA does. The benefit is that a statistical eye provides us with visual insight as to how our circuit might behave. PDA gives us a worst-case stimulus according to a specific metric and that's about it. Take your pick, but I prefer to have more data to look at. Remember that the effects of TX/RX equalization must be included in the pulseresponse that PDA starts with. That means if you don't have a model foryour receiver's equalization included in your pulse response, the results you get represent the RX pad, not the internal sampling point. If you're working with a spec that defines minimum eye opening at the RX pad and doesn't require modeling the receiver, this can work. If you have a closed eye at the receiver pad, you're stuck. Time-domain analysis comes in two flavors - SPICE-based (where we can model arbitrary nonlinear behavior and simulate hundreds/thousands of bits) and channel analysis (which goes under a variety of names), where we model a combination of linear and nonlinear behavior to simulate millions / billions of bits. Running a three week time-domain simulation is an interesting experiment, but I don't see where that fits into anyone's design schedule. The real question is determining which conditions to include in time-domain simulations that fit within our project schedules. If we're going to run a million, or ten million, or a hundred million bits inthe time-domain, we had better be running models that represent our actual TX and RX equalization and clock recovery behavior, or what's the point? We had better know what behaviors those models do / don't represent, or what's the point? This is a complicated problem that requires an organized methodology for modeling and analysis. We need to be able to "rough out" a channel model andTX/RX IP for "what-if" analysis and progressively substitute more detailedmodels and perform more detailed analysis as our design progresses. I don't mind running overnight simulations when the situation merits it, but I want to be doing them to refine an implementation strategy, not making basic architectural decisions. I want to be able to trade off between running quick simulations with less detail and longer simulations with more detail, depending on the problem I've solving ... and I'd like to know how closely my quick simulations approximate the answers I get from my longer ones. I think we actually need a combination of PDA, statistical analysis and time-domain analysis, and a methodology for knowing what to use when. Weneed to run simulations using models that represent our actual semiconductor TX/RX IP, and (last but not least) - we need to know what our simulation results represent and what they don't. A tall order, to be sure. But possible. My $0.02. Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx[1] www.sisoft.com[2] --- Links --- 1 mailto:twesterh@xxxxxxxxxx 2 http://www.sisoft.com ------------------------------------------------------------------ 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 technical documents are available at: http://www.si-list.net 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