Subject: Bird25.1 Response

From: [email-masked] ( Bob Ross)
Date: Wed, 8 Feb 95 21:05 PST

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

---

From: [email-masked] (Jon Powell)
Date: Thu, 9 Feb 95 08:28:29 PST

>>more useful for worst case analysis and design.

This requirement would effectively make the C_comp value an un-correlated variable,
so If we were doing a monte-carlo simulation it would enter in as another free variable.
To me this change is no different than the current specification and so I can see no
need for the bird (at least, on this point).

Of course, we could come up with a COR_C_comp or some such thing.

I am thinking that we are moving toward a situation where we want more that two variables
and perhaps multiple corners and this whole discussion may be more appropriate aimed at
a major 3.0 type enhancement.

jonp