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

I always wanted to have separate values of C_COMP for Inputs and Outputs in IO cells because they tend to optimize to slightly different values.
 In general I found to split the difference or lean toward the input value, particularly on a Multi-load network.
Bob

-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross
Sent: Wednesday, September 29, 2010 1:33 AM
To: Baker, Bonnie
Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org'
Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min

All:

Thanks Bonnie for your solution to the problem. You comply with IBIS, but provide a comment line for the value-to-corner mapping. That is the best we can do with IBIS today.

For consistency for a particular PVT setting, all corner entries for a [Model] should have been for the same PVT conditions. [Model Spec] is already consistent in that respect.

I have a number of objections to [Model Corner] proposal. One concern is that the C_comp parameters are related to actual silicon or Spice extraction values, and the other parameters are specification parmeters. overrides, spec. test setups, and limits. C_comp should remain separate.

For better consistency, the IBIS committee should have defined a corner aligned C_comp by a keyword [C_comp] like [Pullup], etc.

We did decide on a statistical range C_comp because in the early days, buffer to buffer differences due to metalization was a factor. We intend to let the user try different C_comp values to check design robustness. I now believe that was the wrong decision.

Bob

Baker, Bonnie wrote:
> All,
>
> I had big concerns about this a few months ago. Originally, I was posting my IBIS models from my CMOS devices with the c_comp warnings from the parser. I then chose to list these values in numerical order to get away from those warnings because the IBIS standard and I felt the warnings were red flags to my customer. I have been reading the string over the last few days and I want to share our "solution" to this problem. Embedded in each buffer we have the following text:
>
> | typ min max
> | (nom PVT) (Fast PVT) (slow PVT)
> C_comp 9.298e-13 9.221e-13 9.527e-13
> |
> | Where nom PVT is Nominal Process, 3.3V, 25C
> | Fast PVT is Strong Process, 3.6V, -40C
> | Slow PVT is Weak Process, 3.0V, 85C
>
>
> Bonnie Baker
>
> -----Original Message-----
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of
> Walter Katz
> Sent: Tuesday, September 28, 2010 8:22 AM
> To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'
> Cc: 'ibis-users@server.eda.org'
> Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min
>
> All,
>
> What Bob is proposing will work for C_Comp, but will leave all the
> other
> 100 or so other parameters that have typ min max, that may need typ
> slow fast, along with a number of other insonsistant methods of
> defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc
> are defined by corner in several JEDEC specs, while they are defined with sensitivity in IBIS 5.0.
>
> We have found that being able to specify parameters by Corner in
> addition to Range is an important feature that is used very often in AMI modeling.
>
> Walter
>
> -----Original Message-----
> From: Bob Ross [mailto:bob@teraspeed.com]
> Sent: Monday, September 27, 2010 9:17 PM
> To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'
> Cc: 'ibis-users@server.eda.org'
> Subject: 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
-- 
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