[SI-LIST] Re: Skew and Jitter
- From: Jonathan Dowling <jdowlin2@xxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Tue, 1 Apr 2003 18:21:54 -0800 (PST)
All,
My view is that driver jitter is a noise phenomenon.
To accurately model driver jitter would require:
A - Detailed model of chip+package+board pwr/gnd
B - Full on-chip RC model of extracted pads for whole
databus (or at least 1 data group)
C - Full on-chip RC model of extracted path from
control block to all databus pads (or 1 data group)
D - Coupled network tranmission line model
E - All of the above connected together in transient
simulation delivering timely results which
impact the actual design.
--------------------------------------------------------
D is what all SI engineers claim to know.
A Board+Pkg is possible if you own the chip.
(In a separate tool. Not in the circuit design tool.)
It is difficult (impossible?) to merge the on-chip pwr/gnd
model with the pkg+board model and reasonably account for
locality.
B is possible, but generally large and in need of hand
massage to merge into noise simulation database (see below).
C is unlikely.
In my estimation, all attempts at -E- have failed (not for
lack of trying) in the sense that the results were not
timely and/or convincing and did not impact the design/
validation effort in any measurable way.
Generally, the I/O blocks require intricate patterns for
stimulation. You have to reproduce (correctly) all of the
timing for the inputs to the logical block and set all
flip-flops to the correct state at time zero. This requires
the expertise of the circuit design owner to have a chance
of making the circuit operate properly. Add the PLL block
and now you're talking transient simulation in uS instead
of nS.
For leading edge design, accurate spice models for the
process you are targeting don't exist anyway. So, in the
end, a prediction of driver jitter amounts to alot of hand-
waving. For this reason, I generally let circuit designers
estimate pad skew based on their previous experience and
only attempt to model the network skew (from output pads
onward).
In some behavioral tools, it is possible to introduce
inter-pair differential skew, or duty-cycle jitter from
the driver outputs into the network simulation.
Incorporating these effects into the network simulation
can help you budget the timing impact better because it
can be captured directly instead of added as a separate
term in the timing analysis. Many source-synchronous
DDR-style data systems suffer duty-cycle distortion in a
significant way.
To sum up:
o Don't imagine that an IBIS model captures pre-driver jitter.
o Don't imagine that a full Hspice model of the entire system
is a reliable predictor of pre-driver jitter either. If the
simulation converges, you're not modeling enough of the problem.
o You can manually introduce inter-pair differential skew, driver
jitter, and duty-cycle distortion in some coupled network
simulation tools.
o If the edge-rate is extremely fast, you're not getting much
out of the VT curve modeling in IBIS. It was introduced to
handle I/O's with edge-rate control (that is they intentionally
deliver slowed edges). You can make do with old fashioned
linear dV/dt ramps for drivers with edge-rates in excess
of 4[V/ns].
-jd
In the computer industry, timely SI counsel for the design
manager is more scarce than the milk of queens. To plan in
the dark, design in the dark, and stumble in debug, this is
his usual lot. But the SI engineer, as he seeks the food of
light, so he lives in light. He makes his berth an Aladdin's
lamp, and lays him down in it; so that in the pitchiest night
the company's darkened office still houses an illumination.
--- Jon Powell <jonpowell@xxxxxxxxxxxx> wrote:
>
> Jeff,
> I don't think this is (in particular) an IBIS flaw. The problem is that you
> don't really know the timing of the signals that control the output buffers
> (or the Jitter that is going to be inherent on those IC internal signals).
> This would be true of any SPICE circuits that you have also, because it is
> very unlikely that you have a SPICE circuit for the entire IC or even if you
> do that that circuit is really modeling all of the Jitter sources.
>
> I have seen people handle this problem quite succesfully using IBIS (or lets
> say behavioral) models. (JD, speak up here). With IBIS (and some IBIS
> simulators) you can give exact timing of when you want the outputs to swing.
> by giving modulating the patterns of these swings you can simulate (at least
> statistically) many of the aspects of jitter. With SPICE you could probably
> add some additional components of jitter (like, (maybe) doing a better job
> with internal IC voltage droop) but then again, many IBIS simulators provide
> this kind of power too.
>
> So, my main point... It appears that the main type of jitter you are looking
> to simulate is caused by the timing and jitter on the internal I/O driving
> signals, and you won't know that any better with SPICE than you will with
> IBIS, so you have to try and come up with MIN/MAX timing that shows the
> worst eye windows.
>
> regards,
> jon
>
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Loyer, Jeff
> Sent: Tuesday, April 01, 2003 7:15 AM
> To: twesterh@xxxxxxxxx; si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Skew and Jitter
>
>
>
> Hi Todd,
> Your comments leave me a bit disturbed, so I'd like to clarify what I =
> think I heard...
>
> I have run simulations with a Xilinx part (HSLT4 drive, in this case), =
> where I excite the part with a series of 1's and 0's, driving into a =
> topology of interest, to a receiver. I then take the resultant =
> waveform, and break it into Unit Intervals (UI's), and overlay the UI's =
> to get an eye. From that, I make a pronouncement (oooh - nice word, =
> huh?) of the quality of the "eye".
>
> What I hear you saying (doing my "active listening" thing) is:
> I've been blissfully ignorant; these simulations may be meaningless (or, =
> at the least, suspect). The timing between the input of the HSTL4 =
> driver going high (or low) and the resultant driver pulse going high (or =
> low) isn't guaranteed to be particularly meaningful (representative of =
> device characteristics). Therefore, there could be a substantial skew =
> between positive and negative going pulses, induced solely by the IBIS =
> model. I've tried to illustrate it below (with wonderful ASCII art). =
> I'm trying to show an ideal input pulse, and a possible ideal resultant =
> pulse (0 rise and fall times, driving into an ideal system). The only =
> non-ideal element I've added is a delay between the negative-going input =
> pulse and the resultant output (the output for positive-going pulses is, =
> in this ideal model, zero).
>
> Due only to the difference in delays, the "eye" is substantially reduced =
> in width. Is this the problem you're describing?
>
> Note: I couldn't figure out how to put tops on my pulses.
> =20
> Input Pulse: __| |___| |___|
>
> Resultant output (negative-going delayed): __| |_| |_|
>
> If this is the problem, it seems to be a big drawback to IBIS. I can =
> see how you would want to use Spice models only. In fact, wouldn't it =
> make IBIS useless for anthing but a check for reflections?
>
> I'm hoping I've misinterpreted things, or there's a solution. Please =
> let me know.
>
> -----Original Message-----
> From: Todd Westerhoff [mailto:twesterh@xxxxxxxxx]
> Sent: Monday, March 31, 2003 2:05 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Skew and Jitter
>
>
>
> Good point, Douglas. I was assuming, but not stating, that either:
>
> a) the HSpice model somehow modeled the whole path through the device, =
> or
> b) the rise/fall delays from the device input to the input of the output
> buffer were balanced
>
> If either of those assumptions are true, the HSpice results should be
> correct.
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:twesterh@xxxxxxxxx
> ph: 978-936-2149
> "When did the choices get so hard, with so much more at stake?
> Life gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of SI Eng
> Sent: Monday, March 31, 2003 4:35 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Skew and Jitter
>
>
> Todd, Thanks for your response. Correct me if I'm wrong here, but if =
> the
> issue is that time 0 wouldn't be identical for Rise and Fall edges, this
> would apply to a Spice simulation of the I/O cell as well. If the prop.
> delays for Rise and Fall are different through a device, then to set =
> time 0
> at the input to the I/O buffer - where the stimulus is applied - would =
> give
> an erroneous result when the Rise and Fall waveforms are merged for an =
> eye
> diagram. The relative positions between Rise and Fall would be wrong. =
> One
> would have to know the exact delay of Rise vs. Fall of the internal path
> from the output flop to the input of the I/O Buffer in order to set the
> relative position of Rise and Fall corrrectly. No ? Douglas ----- =
> Original
> Message ----- From: "Todd Westerhoff" <twesterh@xxxxxxxxx>To:
> <si-list@xxxxxxxxxxxxx>Sent: Monday, March 31, 2003 10:28 AMSubject:
> [SI-LIST] Re: Skew and Jitter
>
> >
> > IBIS simulates output behavior only, it doesn't try to predict the
> behavior
> > through the part in question. If you can simulate the pieces of your
> chain
> > individually and then sum the jitter contributions from the pieces, =
> IBIS
> may
> > work for you.
> >
> > Eye diagrams and IBIS are a special discussion in their own right. =
> You
> > should be aware that rising and falling waveforms are usually =
> extracted
> > independently for IBIS mnodels, and that "time 0" in the waveform =
> tables
> is
> > not necessarily meaningful (as in, it might be the time the output =
> starts
> to
> > switch, and it might not). If you're going to run pattern simulations =
> and
> > look at eye-digrams using IBIS models, you need to be sure that "time =
> 0"
> is
> > correlated across the rising and fallinng waveform table data. If it
> isn't,
> > you could be making assumptions that aren't necessarily valid.
> >
> > If you have the time and resources to do so, it's worthwhile to study =
> the
> > problem using both Spice and IBIS models initially, then move over to =
> IBIS
> > if you find good correlation between the two approaches.
> >
> > Todd.
> >
> > Todd Westerhoff
> > High Speed Design Specialist
> > Cisco Systems
> > 1414 Massachusetts Ave - Boxboro, MA - 01719
> > email:twesterh@xxxxxxxxx
> > ph: 978-936-2149
> > =
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.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 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: