RE: BIRD 65.2

From: Dagostino, Tom <tom_dagostino@mentorg.com>
Date: Wed Feb 07 2001 - 23:49:42 PST

Re: required C_comp

In stead of requiring all 4 values of C_comp (you don't need C_comp_pullup,
etc with an open drain driver) require the appropriate C_comp for every IV
table in the model.

Tom Dagostino
IBIS and Tau Modeling Manager
SDD
Mentor Graphics Corp.
503-685-1613
tom_dagostino@mentor.com

-----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.
 
Received on Wed Feb 7 23:53:49 2001

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT