Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min

All:

The reasons for why we decided at that time to specify
C_comp by numerical value are well stated, and they
are quite valid. But the decision created a consistency
mistake because we did not specify buffer values completely
for direct corner correlation.

I would favor just addressing only the C_comp issue. A
simpler alternate proposal would be to introduce a new model
sub-parameter such as "C_comp_corner" that specifies the value
to be used for the corresponding corner. That would fit in
with existing IBIS.

We could establish rules such as

    C_comp is always required for full range
       which could be outside the corner range for
       buffer tolerance design and also to provide a
       guarenteed support path for all existing tools.

    C_comp_corner is optional for picking a corner value
       for direct corner correlation.

Or we could require one or the other.

Bob

Walter Katz wrote:
> All,
>
>
>
> There is a very simple solution to this issue, please review the
> enclosed draft {Model Corner] draft BIRD.
>
>
>
> Walter
>
>
>
> -----Original Message-----
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of
> Mirmak, Michael
> Sent: Monday, September 27, 2010 12:02 PM
> To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org
> Subject: RE: [IBIS] C_comp Max < C_comp Min
>
>
>
> One other item to note: not all device technologies associate a
> numerically-smallest capacitance with the ?fast/strong? process.
> Assuming that CMOS rules universally apply would not have been
> appropriate, and IBIS does not include any notations as to which process
> technology is used in the design for the data presented. Without that
> information or some basic ordering assumption, parsers have no means to
> confirm that the C_comp data had been entered correctly.
>
>
>
> As Arpad states, the only way to have enforceable parsing rules was to
> order the C_comp from numerically-smallest to ?largest, with the
> assumption that the EDA tool would supply the missing information,
> likely from asking the user (for example, the tool might inquire about
> the process used for the IC in question).
>
>
>
> Michael Mirmak
>
> Intel Corp.
>
> Chair, IBIS Open Forum
>
>
>
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of
> Muranyi, Arpad
> Sent: Monday, September 27, 2010 7:35 AM
> To: ibis@server.eda.org; ibis-users@server.eda.org
> Subject: RE: [IBIS] C_comp Max < C_comp Min
>
>
>
> Fabio,
>
>
>
> The reason you are getting that message is because the die capacitance
>
> does not have a direct relationship with the fast/slow process corners
>
> and when we wrote the IBIS specification we decided that it was best
>
> to just put the small number into the min place and the big number into
>
> the max place. It was expected that an EDA tool would allow the user
>
> to try out all possible combinations between min/max curves and C_comp.
>
>
>
> Arpad
>
> ========================================================================
>
>
>
> ------------------------------------------------------------------------
>
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Fabio
> BRINA
> Sent: Monday, September 27, 2010 7:12 AM
> To: ibis@server.eda.org; ibis-users@server.eda.org
> Subject: [IBIS] C_comp Max < C_comp Min
>
> Hello Ibis experts,
>
>
>
> I'm working in CMOS tecnology;
>
> very often in the C_comp extraction I obtain the Min value bigger then
> Max value:
>
> the values come from ac simulations in these conditions:
>
>
>
> C_comp Min value consider: Vcc Min, Process Min, Temp Max
>
> C_comp Max value consider: Vcc Max, Process Max, Temp Min
>
>
>
> The Ibis Check output is:
>
>
>
> WARNING (line 76) -
>
> Model mod1: C_comp min value is not the smallest value listed
>
> WARNING (line 76) -
>
> Model mod1: C_comp max value is not the largest value listed
>
>
>
> Is that situation acceptable?
>
> or I have to switch the Min Value with Max Value?
>
>
>
> ... suggestions are welcome !
>
>
>
> Thank you,
>
> Fabio
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner <http://www.mailscanner.info/>, and is
> believed to be clean.
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
401-284-1827                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993