Re: BIRD 58

Mike:

Thank you for your input. You have some valid points regarding
allowing C_comp to be distributed. This will work for creating
driver models as the summation of individual drivers. The
problem is that if the top-level model is an I/O model, we
would normally not put in a C_comp value = 0. Then in the
Input mode, we would have to add up all of the C_comps in
the lower level models to come up with the effective C_comp.

This is a possible workable solution that does not require
any Specification syntax change - just a few more words of
interpretation. It would also support moving all of the
C_comp to the top-level for another method of building a
behavioral buffer by construction.

We will have to consider this.

Bob Ross
Mentor Graphics

Subject: Re: BIRD 58
Date: Fri, 26 Mar 1999 14:10:46 -0500
From: Mike LaBonte <mikelabonte@cadence.com>
To: ibis-users@vhdl.org

Regarding the c_comp issue discussed in the Mar 26 IBIS meeting,
related to BIRD 58, I would like to register my opinion in favor
of allowing for the use of separate c_comp values attributed to
each Driver Schedule stage.

Although c_comp may be named as such because of the original
intention that it encapsulate an overall component level capacitance,
the practical matter is that Driver Schedule stages are most
likely to correspond to actual transistors in an IO section. Each
transistor does have it's own effective die capacitance. The
designer of the stage buffers may (should) have validated their
behavior individually, with c_comp intact. To then use them in a
scenario where the c_comp values are not used may not make sense.
(insert discussion of the aggregate capacitance for a cluster of
transistors vs. sum of individually calculated capacitances here).

Furthermore, IBIS could gain maximum flexibility by stating that
the c_comp values of individual stages are used in addition to
the c_comp that might be specified for the top-level model. In
this way, model designers can specify c_comp=0 for any portion
that is not to be used. This part of the proposal is debatable in
my own mind, simply because I have some difficulty producing an
elegant explanation of what the top-level capacitance represents,
when the`"transistor" capacitance is already accounted for. But it
offers flexibility. And it eliminates the requirement that simulators
ignore c_comp data present in the Model, which users may not be aware
of.

Mike LaBonte
Received on Mon Mar 29 18:11:05 1999