Re: *_dut params for waveform tables

From: Bob Ross <bob_ross@mentorg.com>
Date: Fri Nov 13 1998 - 18:17:48 PST

Syed:

Some comments (and opinions) are in your text.

Bob Ross
Mentor Graphics

> Date: Tue, 10 Nov 1998 10:43:49 -0800 (PST)
> From: Syed Huq <shuq@cisco.com>
> Message-Id: <199811101843.KAA06215@jasper.cisco.com>
> To: ibis-users@vhdl.org
> Subject: *_dut params for waveform tables

> IBISgurus,

> For waveform tables, there are sub-params called R_dut, L_dut and C_dut. These
> are same as R_pkg, L_pkg and C_pkg. From talking to a few IBIS experts I
> understand that waveform tables should be generated without any pkg parasitics.
> Simulators will attach the package parasitcs to the waveform tables and
> run simulations.

> That means, do not include *_dut in your s2ibis2 translation. If that is true,
>
> Why does s2ibis2 include R_d, L_d and C_d parameters ?

It was designed to comform with the Version 2.1 Spec.

> Why does IBIS even have *_dut parameters in the spec ?

In retrospect this may have not been a good decision. However,
at the time we wanted to be able to document the package parasitics
when you really had to extract waveforms from the pin (versus the
die). However, may of us learned after the fact that the values
themselves may lead to time-constant numerical problems during simulation.
It may be theoretically possible to deal with these problems with smoothing
algorithms, but in practice it is safer to not use the values.

> How does one avoid double counting of pkg numbers for V/T ?

If the package effects are negligible, then a suitable accurate
model might be constructed by just not using the DUT values.
Another method might be to time scale the V/T table to compensate
for the measurement degradation - if the degradation can be
determined.

> Are the *_dut only for measurement based IBIS models ?

They were intended for measurement models and should never
be used for Spice models where the package parameters can be
removed.

> Regards,
> Syed
> Cisco Systems,Inc
Received on Fri Nov 13 18:22:55 1998

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:46 PDT