[SI-LIST] Re: Skew and Jitter
- From: "Todd Westerhoff" <twesterh@xxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Tue, 1 Apr 2003 10:58:59 -0500
Bob,
I agree with you assessment of V-T waveform data (and the ways it is
correctly or incorrectly prepared), and its effect on accuracy.
The reason I said "IBIS may work for you" was because the original question
was about the accumulation of jitter/skew along a path with multiple
devices. I felt I didn't know enough of the details to draw definite
conclusions. Bottom line - my qualification was a application-specific
knowledge/timing thing, not a statement about limited accuracy as far as
IBIS goes.
Does that make sense?
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: Robert Haller [mailto:rhaller@xxxxxxxxxx]
Sent: Tuesday, April 01, 2003 10:51 AM
To: jeff.loyer@xxxxxxxxx
Cc: twesterh@xxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: Re: [SI-LIST] Re: Skew and Jitter
Jeff,
Todd, please correct me if I am wrong , but I believe the statement you
made was;
>> IBIS may work for you.
In fact if the VT tables are properly created (i.e. the offset between
rising and falling is correct), then IBIS WILL WORK.
The issue is plenty of model creators don't understand that the rising
and falling waveforms need to be correlated to the same reference point
in time. So as always, the results of your simulations are as good as
your models going in.
regards
bob
--
Robert J. Haller (rhaller@xxxxxxxxxx)
Principal Consultant
Signal Integrity Software Inc.
6 Clock Tower Place, Suite 250
Maynard, MA 01754
Phone: (978) 461-0449, ext 15
Loyer, Jeff wrote:
> 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
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> "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
------------------------------------------------------------------
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:
