[SI-LIST] Re: Skew and Jitter
- From: "Todd Westerhoff" <twesterh@xxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Tue, 1 Apr 2003 10:50:15 -0500
(email history trimmed, because it's Be Kind to Servers Day).
Jeff,
Yup, you got it. Point is, time "0" in an IBIS model isn't guaranteed to be
anything, nor is the sense of time "0" guaranteed to be correlated between
rising/falling edges (the duty cycle issue). The choice of time "0" is
arbitrary, and is corrected out by the use of Vref, Rref, Cref and Vmeas.
The _good_ news is that time "0" normally _is_ correlated for rising/falling
edges, because people don't bother to adjust it. I was just pointing out
that you need to make sure it is correlated, if you're relying on it.
Looking at it another way (and borrowing on your ASCII graphics), let's say
the rising edge data from the HSpice analysis, with the buffer input
switching at time 0, looked like:
----------------------------| <- (rising edge)
0 1n 2n 3n
So, for sake of argument, let's say the edge started rising at 3.4ns. In
practice, there will be two sets of waveform data for the rising edge
(pulled up and pulled down), but I'm simplifying here.
Well, some users don't like having IBIS models with a significant delay
before the rising edge - they expect to see the output begin rising shortly
after time 0. So, for sake of keeping the customers happy, the model maker
might trim the waveform data to:
----| <- (rising edge)
0 1n 2n 3n
... as long as the exact same amount of time is remove from each of the
rising waveform (pulled up/pulled down)curves, the model is valid. I'll
grind this one into the ground: the choice of time "0" is arbitrary.
Let's take this a bit further. Again simplifying two rising/falling
waveform pairs to a single waveform, let's say HSpice analysis gave us:
----------------------------| <- (rising edge)
0 1n 2n 3n
--------------------| <- (falling edge)
0 1n 2n 3n
... and, let's assume the model maker, following a minimize-the-lead-in-time
strategy, edited the model to produce:
----| <- (rising edge)
0 1n 2n 3n
----| <- (falling edge)
0 1n 2n 3n
The model is valid, but a straightforward duty cycle analysis using this
model is not, because the relationship between the rising and falling edges
have been altered.
Fortunately, this is rarely the case. First off, not that many people
remove time from V-T curves to begin with. Even if they do, they usually
remove the same amount of time from the rising/falling curve sets, which
preserves the edge relationships. However, an automated script that
evaluates and adjusts rising/falling edges independently could shift the
relationships without someone's realizing it.
Bottom line - if you're using IBIS to look at eye diagrams, you need enough
visibility into how the model was created to ensure the rising/falling edges
have a correlated start time.
Hope that helps,
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 Loyer, Jeff
Sent: Tuesday, April 01, 2003 10: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.
------------------------------------------------------------------
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:
