Bird25.1 Response

To Members:

Thank you for your comments. Jon raised very nicely the fundamental paradox
and problem with respect to positioning the values of C_comp.

From a model development point of view, it would be nice to give ONE rule
that positions C_comp and gives the BEST representation of the device.

Unfortunately, the assumption that enough information is available to
correlate C_comp may not be valid in most(?) cases. I don't know how well
C_comp actually correlates to the "voltage" and "temperature" variables
vs its correlation to internal metalization variations. Furthermore,
when models are developed using data book information containing specification
tables, the correlation is not known at all. So, the assumed C_comp
correlation to voltage/temperature/process variations may not always be
valid, and information about such potential correlation is often unavailable.

From a simulator point of view, it is very desireable for the modeling
information to be well-defined. In particular, if it is always known that
the "max" column contains the largest value of C_comp, then that column
can be relied upon to provide the largest load for the slowest timing
condition for an Input model - as a consistent configuration. Otherwise,
a worst case corner may require doing a min/max search on all of the entries.
While this may appear simple, it is one additional complication and source
of variation. Also, if there are inconsistencies between the various models
within a design, there could be combined capacitance variaitons which cancel,
defeating the reason for worst case analysis.

So perhaps the best resolution is just to require the max C_comp value
to be positioned in the "max" column, regardless of conditions under which
it is extracted. The surprising tradeoff is that by overriding some
extractions which give the most accurate model, one creates a set of models
which function in a more consistent manner and which taken together are
more useful for worst case analysis and design.

More discussion is welcome before I issue a new revision to BIRD25.1.

Bob Ross,
Interconnectix, Inc
Received on Wed Feb 8 21:09:14 1995