Re[2]: Bird25.1 Response

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

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
>

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: ibis@vhdl.org, bob@icx.com
Message-Id: <9502091436.AA11712@hot>
From: cpk@cadence.com (C. Kumar)
Date: Thu, 9 Feb 95 09:36:55 -0500
Received: by hot (5.65+/1.5)
        id AA11712; Thu, 9 Feb 95 09:36:55 -0500
Received: from hot by cadence.Cadence.COM (5.61/3.14)
        id AA04550; Thu, 9 Feb 95 06:35:46 -0800
Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma
        id sma002111; Thu Feb 9 06:37:01 1995
Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA0214
Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
        id AA13432; Thu, 9 Feb 95 06:42:23 PST
Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, 9 Feb 95 06:
Received: from aurora.intel.com by relay.jf.intel.com with smtp
        (Smail3.1.28.1 #2) id m0rcaIQ-000twcC; Thu, 9 Feb 95 06:56 PST
Received on Thu Feb 9 09:10:25 1995