Subject: Re: Bird25.1 Response

From: [email-masked] (C. Kumar)
Date: Thu, 9 Feb 95 09:36:55 -0500

Given the complexity of deciding what is fast , slow , worst and best, I am more and more convinced the max, min columns should be simple. i.e. they should
contain numerical max , min values. Then you can define what is fast, slow, worst etc.
e.g

FAST = (C_comp(min), pull_up (max), pull_down (max) ...  )

This is unambigous. The draw back is there will be no way of automatically
determining what is fast slow etc and it will violate 1.1 specs!! (oops)

> 
> 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: Arpad Muranyi <[email-masked]>
Date: Thu, 9 Feb 95 09:05:05 PST

Text item: 

Hello all,

I don't see why it would violate the 1.1 spec.  I don't know of anything in it 
that would say what goes where regarding C_comp.

Arpad
------------------------------------------------------------------------------
Given the complexity of deciding what is fast , slow , worst and best,
I am more and more convinced the max, min columns should be simple.
i.e. they should
contain numerical max , min values. Then you can define what is fast,
slow, worst etc.
e.g

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

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Re: Bird25.1 Response
To: [email-masked], [email-masked]
From: [email-masked] (C. Kumar)
Date: Thu, 9 Feb 95 09:36:55 -0500