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

Abe Riazi (
Mon, 17 May 1999 11:29:15 -0700

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

>From: Beal, Weston[]
>Sent: Monday, May 17, 1999 6:47 AM
>To: ''
>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 []
> Sent: Saturday, 15 May, 1999 11:50 AM
> To: ''
> 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
> 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
>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 In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at ****