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

Weber Chuang ([email protected])
Tue, 18 May 1999 09:42:06 +0800

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?

2. the flight time effect of the load board(DIB) for DUT is automatically
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?
then what might you suggest for 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 Riazi
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 parameters
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 sections
>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 voltage.
> 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 have
>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 conditions
>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 default.
> 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 models.
> Your comments regarding this topic are highly
> Best Regards,
> Abe Riazi
> Anigma, Inc.
> **** 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 ****

**** 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 ****