Greetings IBIS folks:
Thank you for your responses so far regarding the recent email
clarification issues and concerns.
Regarding Steven Peter's comments on the reason for the voltage
ranges, the extension of the GND_CLAMP model to POWER in the
REVERSED BIASED direction makes sense with repect to handling a
reflected wave. However, the POWER_CLAMP range should extend to
GND (Rather than just to POWER) for the same reason in the
REVERSED BIASED direction. The only reason I can think of for
not extending the POWER_CLAMP is that it's characteristics can
be concatenated with the GND_CLAMP characteristics to form an
INPUT model (or model for I/O or 3-STATE in the input mode).
In the FORWARD BIASED clamping direction in a transmission line
environment, the algorithm may see initially the full voltage
signal, but would eventually converge to a much lower value
based on the non-linear VI clamping characteristics in
conjunction with the characteristic impedance of the line.
If, for example, there is a -5 Volt reflected
step signal in a 50 Ohm line, the maximum current seen at the
termination end of a GND_CLAMP cannot initially exceed 100
milliAmps, thus eventually causing the convergence to a
voltage value at much less than 5 Volts at the clamping
end. Since the -5 Volt signal comes from undershoot,
it would not normally provide a buildup of voltage across the
clamp over several reflection intervals. So I think it
is reasonable for IBIS to accomodate a vendor supplied reduced
voltage range (e.g., whatever voltage produces a several hundred
milliAmp response) in the FORWARD BIASED direction. However,
it may be easier for convergence algorithms to have an
explicit point at the forward biased POWER value.
Regarding the package model, several techniques exist to
extract the L and C components ranging from measurement to
mathematical extraction based on geometry. When the results
are presented as a single LC lump - as is commonly done for only
a first order approximation, it might be arbitrary where to
place the C. Both choices have appeared in practice.
I can accept Kellee Crisafulli's justification on R_pkg for
future MCM macomodeling capability. But an alternative might be
to include the R characteristics in the PULLUP and PULLDOWN
data. However, this solution does not deal with R being
distributive.
As a final note, please do not interpret my comments as being
negative. I think the work done to date has been excellent.
Thanks, Bob Ross (Interconnectix, Inc.)
Received on Tue Aug 31 16:35:28 1993
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT