Re: BIRD24 COMMENT

To Arpad, Kumar, Will and everyone

I support Arpad's comments concerning "V_load", and can only add that
it would really take up to 6 such sub-parameters, 3 for dV/dt_r and 3
for dV/dt_f to cover the V_fixture, V_fixture_min and V_fixture_max
options in the [Rising Waveform] and [Falling Waveform] keywords.

I believe C_comp is really an "effective" die capacitance. The actual
output driver or a COMPETE Spice model of its internal components will
contain a number of (non-linear) reactive components, transition times, etc.
plus any other internal effects such as metalization which may be lumped
as a capacitance. For the large-signal dynamic transitions, the total
mathematical characterization would be exceedingling large and complicated.
Even the time varying, non-linear resistive elements would produce an
effective reactive component in the overall analysis by following the
line of reasoning and collecting terms:

   V(t) = I(t)R(t), dV(t)/dt = R(t)dI(t)/dt + V(t)dR(t)/dt, ... etc.

As an IBIS modeling assumption, the total reactive effect is ASSUMED to be
dominated by a constant C_comp value.

With respect to "golden waveform" extraction, one may think they
are being helpful by trying to remove some internal lumped capacitor
that is positioned in a C_comp location. I contend that the best model
will be produced from data representing the actual device, not from
data produced from a transformed model because of some second order
interactions such as expressed above. Therefore, I strongly want to
discourage the concept of even the boolean parameter C_comp_in = T or F
option. Inclusion of such an option would tarnish the waveform.

Bob Ross,
Interconnectix, Inc.

> This raises an interesting point. How reliable is the value of C_comp itself?

> Anyway I am not in favor any "implied" quantities associated with waveform
 tables. Every parasitc associated with that wave should be explicitly stated.
 So for example C_dut can include the effects of C_comp.

> While I am at it I also want to raise another point regarding ky word Ramp.
> That specification includes R_load. But there is no provisison for V_load.

> If we look at the notes on Ramp rates there are situations in which V_load is
> vendor specified and there is no place in IBIS models where thie information is
> carried.
Received on Wed Dec 7 12:29:09 1994