RE: BIRD 65.2

Al,

You are raising good points. First of all, I agree that IBIS-X
will solve most or all of these issues. However, this BIRD was
originally written a long time ago, when we had no idea how long
it will take to make IBIS-X a reality. Even though that day is
getting closer, I am still not entirely sure when it will happen.

When this BIRD was first written, the idea was to have a quick
release of IBIS4 with minor fixes. This BIRD was written, because
when HSPICE implemented their new B-element (the IBIS element) they
connected the C_comp to the ideal "node 0" ground. I could not
do ANY reasonable power bounce simulations that way, and I had
to ask them to fix it IMMEDIATELY, which they did. So HSPICE
has this fixed now, and it would make sense for the IBIS spec
to have it fixed the same way.

Unfortunately, the quick release of IBIS4 has gotten dragged out
way beyond my expectations. It was targeted to be done by the
summer following the East Coast summit a year and a half ago.
I agree, if IBIS-X happens soon it may not make sense to have
IBIS4 at all, but we don't know that for sure yet.

Now, I understand that this BIRD does not answer many of the
more detailed questions, such as voltage and frequency dependency,
non linearity, etc... I will be glad to leave that to IBIS-X.
However, the intent was to get this fixed on the first order,
since the connection to node 0 does not make sense at all.

Regarding prototyping, is it not enough that HSPICE version 2000.2
has it and it works?

Regarding the splitting of the DC and AC currents, all I can say
is that whether it is done correctly or not, the HSPICE B-element
in v2000.2 is much more useful than the earlier versions without
this fix. I CAN simulate return currents and power delivery
simulations much more accurately than I could before which was
basically bogus. It may be true that there is still room for
improvements in terms of accuracy, but as I said it above, I
will leave those issues to be addressed in IBIS-X.

Regarding how you can measure the independent C_comp values I
am including an HSPICE example for you in the attachment. I
am not sure if it will go through the email reflector, so I
am sending a duplicate of this message to you directly. This
example shows only two capacitance calculations for C_vcc and
C_gnd, but the idea can be easily extended to four, if
independent clamping circuits would require that. This
example is done in the time domain, and is not the only
way you can do this. There are other techniques using
the .AC sweep for this.

Regarding TT (transit time), even though it can be viewed
as a related item (AC capacitance), I still think of it
differently. It controls how the diode currents turn on
or off with respect to time. This C_comp BIRD is more
related to how much of the total capacitance current should
come from the vcc and/or gnd pins. This has not much to do
with time.

I hope this will answer some of your questions.

Sincerely,

Arpad
============================================================

-----Original Message-----
From: Al Davis [mailto:aldavis@ieee.org]
Sent: Wednesday, February 07, 2001 10:56 AM
To: ibis@eda.org
Subject: Re: BIRD 65.2

(Most of this message is a repeat, because the issues have not been
addressed.)

I have some questions and reservations on this. To summarize, although
I agree that such a thing is needed, this proposal does not solve the
problem adequately and has the potential for introducing problems that
have not been considered. Also, the problem it intends to solve
becomes a non-issue once IBIS-X is completed.

The first question is how difficult it is to implement. Ordinarily, I
would say that it is necessary to prove it with a prototype, but it is
a simple topology change, so it would be no worse than the existing
C_comp. Incidentally, the C_comp as we know it is rarely implemented
correctly for driving models. It is very difficult to do correctly.
The implementations tend to be very good for non-driving models, where
it is just a simple capacitor. In any case, it is no worse than what
we have so I am satisfied on this point.

Still, testing is a problem. How do you measure it? How do you
validate that the measured data actually relates to reality? Before
approval of this bird, I would like to see a description of a procedure
for measuring it, and a procedure for validating that the measured data
is actually correct and useful. These procedures should be tried on a
prototype.

The purpose is stated to be information on how the capacitance is
distributed over the 4 ground/power nodes. Another way to look at it
is how the current in the capacitance is distributed. OK. Now back
up. We have pullup/pulldown and the clamps for the DC conditions. The
proposed c_comp's are the dynamic parts. Existing models usually do
not model the split of these correctly. The pullup and power clamp are
sort of in parallel, so the measurement is usually to measure the
clamps in input or tri-state mode, and the pullup/pulldown in driving
mode, by measuring a total and subtracting off the clamps. This often
leads to the pullup/pulldown showing strange bahavior when it is masked
by the clamps, because the subtraction magnifies the errors. In any
case, the current path is not necessarily as intended. The standard
provides the mechanism to properly model the current paths, but most
models do not. They arbitrarily mix them.

Given that most models do not get the DC split correct, what justifies
even trying for the dynamic part?

The next issue is that this capacitance is strongly nonlinear.
Measuring it in the various states produces very different results.
Even then, there is no hint at what they do during the transition,
other than that the wave tables include the effect. The wave tables do
not provide information on how that current is distributed to the 4
power/ground nodes, and possibly also to other connection nodes
including input and enable.

The nonlinear nature of this capacitance is significant in the
development of the simulator algorithms. Some actual models will only
work accurately when the capacitance is treated as nonlinear.

Part of this capacitance is already in the standard as transit time.
The [TT*] parameters are essentially equivalent to the C_comp_power and
C_comp_ground parts, complete with the nonlinear component. Thus, part
of what this bird proposes is already available. (OK -- the bird asks
for the linear part.) Do you have any examples of actual models that
use these parameters? with test data showing the quality of
correlation to the real device? How many simulators support it fully?
It has been in the standard for a long time.

Considering the number of unanswered questions, and that this
functionality and much more will be available in IBIS-X, I think it is
best not to rush into this.

So, Arpad, you should prototype this in IBIS-X (trivial) , and also
prototype a measurement system for it in IBIS-X (not so trivial). This
will validate both this bird and IBIS-X. The rest of us should wait
for the answer.

Note to readers not familiar with IBIS-X: This is a proposed future
IBIS based on a macro language. It is fully backward compatible with
IBIS as we know it, and provides the capability to add extensions like
this one easily. Arpad and I are both on the sub-committee that is
working on it. A prototype implementation of IBIS-X is being built,
and a partial one (incomplete work in progress) is available for review
to the committee and to those interested.

The change in wording of the "required" section is an improvement, but
it still needs work.

How about:

Either the C_comp parameter or all four of C_comp_pullup,
C_comp_pulldown, C_comp_power, and C_comp_gnd are required. If C_comp
is provided, the others are not allowed.