RE: [SI-LIST] : Looking Inside IBIS Model

Beal, Weston ([email protected])
Tue, 18 May 1999 08:57:05 -0500


Your message shows that you understand the issue and have put some thought
into solving the problem. Thank you. I'll give you my opinion on your
questions, and I'm sure someone will contend with me on some detail.
Comments inline...

Weston Beal
Signal Integrity Engineer
Compaq Computer Corp.

-----Original Message-----
From: Weber Chuang [mailto:[email protected]]
Sent: Monday, 17 May, 1999 8:42 PM
To: '[email protected]'
Subject: RE: [SI-LIST] : Looking Inside IBIS Model

Hi SI-gurus,

I generate IBIS model for our customers, and I simulate
the PCB also(with
QUAD/xtk), and do timing calculations, so I know the
importance of correct
correlation(mapping) between datasheet and models, yet still
some problems
bother me, I guess you all might help, so here it is,

1. we can simulate the spice netlist in hspice and
primetime(maybe motive)
to generate the AC timing, yet we need to correlate it with
tester values, I
think no one would argue about this, but the tester values
seem to include
tester jitter, DUT internal PLL jitter, rise-fall
difference, DUT package
effects and also some test-probe loading effects, do someone
have some good
idea or experience in removing all the effects and then get
a good first
order approximation between simulated values and
characterized values?
If you look at how we calculate min and max flight times, we
are including all the factors that we can. By the same logic, Tco (or
Tvalid) should include all the effects of the component including internal
PLL jitter, internal clock tree skew, and package parasitics. Tco refers to
the real component. Tco(min) should be the minimum of all minimums and
vice-versa for max. Then we use the timing reference load to correlate Tco
to the start of Tflight (derating in XTK) in our board simulation. A
correct simulator will place the timing reference load at the pin of the
device when calculating Tflight. In XTK you need to simulate TIME_TO_VM
this way, which in general is not done. I just realize a couple of months
ago that we've been doing it wrong. Tco is measured to the pin, so Tflight
must start at the pin, so the timing reference load must be connected at the
pin. IS, from Interconnectix/Mentor Graphics does timing calculation this

2. the flight time effect of the load board(DIB) for DUT is
calibrated out by the tester, yet the tester does the round
trip measurement
without the DUT, so the acquired round trip measurement is
different from
the real case(with DUT ), so there will be always some
offset for this, is
there anything we should/could do for this?

3. if DUT is A, and the trace on load board(DIB) is B, and
loading effect of
tester head is C, then we can either by calculation or by
using TDR to find
the propagation delay of B, since this delay will be
corrected by tester
itself, so the Rref and Cref and Vref that I should put on
the IBIS should
be C since the AC timing will be the ones from tester, is
that right?

4.continued from 3, but I think the effect for [A driving
(B+C)] would
differ from [(A driving C)+B] if from a more detailed scale,
is that right?
In general, this is correct.
then what might you suggest for this?
I think that 2, 3, and 4 are all the same problem. In some
cases the tester might be calculating the correct compensation, but I doubt
that it is always correct. I would do a SPICE simulation from the IC driver
to the tester receiver and another with just the IC driver, pin, and test
load. From that, you can see if the difference is equal to the propagation
time of the ideal transmission line in the tester. If not, then you also
have the correction factor to add after the tester correction factor.

I'm just thinking this out as I write, so I might have
missed something.

Thank you for thinking about this and trying to solve the
problem. I hope all IC vendors will put some work into this.

Best Regards

Weber Chuang(ChingFu Chuang)
Signal Integrity Engineer,
VIA Technologies, Inc. Taipei, Taiwan, ROC
TEL : 886-2-22185452 ext : 6522
email : [email protected]
Very Innovative Architecture

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Abe
Sent: Tuesday, May 18, 1999 2:29 AM
To: '[email protected]'
Subject: RE: [SI-LIST] : Looking Inside IBIS Model

Dear SI-List Members:

Thanks for your comments on this subject.

I hope IBIS model developers will carefully review this
series of
emails. As it was pointed out, inclusion of accurate timing
should be a requirement (rather than optional).
Furthermore, test loads
for Min, Typ, and Max corners are often different, and this
should be
also defined in the IBIS model.


Abe Riazi
[email protected]

>From: Beal, Weston[SMTP:[email protected]]
>Sent: Monday, May 17, 1999 6:47 AM
>To: '[email protected]'
>Subject: RE: [SI-LIST] : Looking Inside IBIS Model
>Dear people,
>This topic is very important in timing simulation and is
one of my pet
>peeves. I agree whole-heartedly with Abe, except for the
comment that "if
>accurately specified they can aid board level timing
simulation runs." In
>fact, I would argue that the timing test load MUST be
included to do any
>meaningful timing simulation.
>My first check of an IBIS file is to see if the IBIS author
has correctly
>used the Vmeas, Vref, Rref, and Vref parameters. If not,
they probably
>don't understand IBIS and the whole file is suspect. The
timing test load
>should be defined for every driver including I/O and should
not be included
>for receiver only models. If you create any IBIS files,
please take the
>time to understand the correct usage of Vmeas, Vref, Rref,
and Cref. Your
>customers will love and praise you :-)!
>Weston Beal
>Signal Integrity Engineer
>Compaq Computer Corp.
> -----Original Message-----
> From: Abe Riazi [mailto:[email protected]]
> Sent: Saturday, 15 May, 1999 11:50 AM
> To: '[email protected]'
> Cc: Walt Otto
> Subject: [SI-LIST] : Looking Inside
IBIS Model
> Dear All,
> An IBIS model contains several different
>including package
> parasitics, pin mapping, DC I-V curves and
V-T tables. Each
> performs a useful function and desreves
attention when
>evaluating the
> accuracy of an IBIS behavioral model.
> Also present in some models are
parameters Cref, Rref,
>Vref and
> Vmeas, which define the test load used by
the semiconductor
>vendors when
> determining propagation delay or switching
time of the
>device. Where:
> Cref: A shunt capacitor which connects
the driver output
>to Ground.
> Rref: A resistor connecting the output of
device to Vref.
> Vref: Timing specification test load
> Vmeas: Reference voltage for timing
measurements, with a
> between input logic low ( Vinl ) amd input
voltage high (
>Vinh )
> thresholds.
> Based on IBIS standards, Vmeas, Cref,
Rref, and Vref
>parameters are
> optional. Therefore, there are many models
which lack these
> But if accurately specified they can aid
board level timing
> runs.
> I always look for them in driver models
for several
> 1. For an appraisal of the quality of
the model.
> 2. For a comparison with the test load
specified in the
>AC timing
> section of the device's datasheet.
> 3. If determined to be consistent with
the datasheet,
>then to be
> employed in time_To_Vm calibration runs of
the Quad models
> from IBIS models by means of IBIS2XTK
conversion program.)
> I have seen numerous models having test
load parameters
> with the datasheet and have asked following
question from
>several IBIS
> model developers:
> For timing calibration runs should the
test load defined
>in the IBIS
> model be used or the one specified in the
datasheet ?
> The answers have varied. Some IC vendors
have suggested
>using the
> test load defined in the model, while others
>recommended the
> circuit described by the datasheet. I agree
with the
>latter, and prefer
> using the dataheet's test load, whenever
there is a
>diference between
> the test loads of the model and the
datasheet. Another
>benefit gained
> by referring to the datasheet is that the
test loads for the
>Min, Typ
> and Max corners can be different; this
variation is often
>described in
> the datasheet, but seldom in the IBIS model.
> It is important to note that during
development of an
>IBIS model the
> parameters Rref, Cref, and Vmeas are not
utilized for
>generation of any
> of the waveforms (i.e. pullup, pull down,
rising, falling,
>etc.). They
> should not be confused with R_fixture,
C_fixture, and
>V_fixture which
> are in contrast used for creation of rising
and falling
> To clarify certain points of this
discussion, three
>examples have
> been prepared:
> Example 1. Following parameters were
obtained from IBIS
>model of a
> Vinl = 1.2 V, Vinh = 1.6 V, Vmeas = 1.4
V, Vref = 1.4 V,
>Rref = 28
> Ohms, Cref = 0.0 pF, R_fixture = 28 Ohms,
V_fixture = 1.8 V.
> Example 2. Parmameters adapted from
behavioral mode1 of
>a Graphic
> Accelator chip:
> Vinl = 0.8 V, Vinh = 2.0 V, Vmeas = 1.4
V, Cref = 0.0 pF,
>R_fixture =
> 50 Ohms, V_fixture = 3.3 V, V_fixture_min =
3.135 V,
>V_fixture_max =
> 3.465 V.
> Example 3. Extracted from IBIS model of
a Programmable
>Logic Device
> (PLD):
> Vinl = 0.8 V, Vinh = 2.0 V, Vmeas = 1.5
V, Rref = 100 K,
>Cref = 50
> pF, Vref = 0.0 V, R_fixture = 50 Ohms,
V_fixture =
>V_fixture_max =
> V_fixture_min = 0.0 V.
> The fixture parameters define the loading
>under which a
> rising or falling waveform is generated.
According to IBIS
> only R_fixture and V_fixture are required,
the remaining
> are optional. It is believed that test
fixtures composed of
> V_fixture, V_fixture_min and V_fixture_max
provide the
>optimum data
> needed for production of a behavioral model.
When a
>subparameter is
> missing, its value is assumed to be zero by
> To summarize, test load and test fixture
parameters are
> equivalent. When Vmeas, Vref, Rref, and
Cref are accurately
> for a driver model, consistent with the
datasheet, then they
> valuable information which can facilitate
the timing
> runs and hence enhance the overall
efficiency of a SI
>simulation. Test
> load circuits are not needed for receiver
> Your comments regarding this topic are
> Best Regards,
> Abe Riazi
> Anigma, Inc.
> **** To unsubscribe from si-list: send
e-mail to
>[email protected] In the BODY of message put:
>si-list, for more help, put HELP. si-list archives are
accessible at
> ****
>**** To unsubscribe from si-list: send e-mail to
[email protected]
>In the BODY of message put: UNSUBSCRIBE si-list, for more
help, put HELP.
>si-list archives are accessible at ****

**** To unsubscribe from si-list: send e-mail to
[email protected] In the BODY of message put:
si-list, for more help, put HELP. si-list archives are
accessible at ****

**** To unsubscribe from si-list: send e-mail to
[email protected] In the BODY of message put: UNSUBSCRIBE
si-list, for more help, put HELP. si-list archives are accessible at ****

**** To unsubscribe from si-list: send e-mail to [email protected] In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at ****