[SI-LIST] Re: How to simulate worse case eye

  • From: Todd Westerhoff <twesterh@xxxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Mon, 16 Mar 2009 11:34:56 -0400

 
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
  

Other related posts: