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

I liked the proposal from some time ago to allow for a passive subcircuit to
represent die capacitance. This could model complexities such as frequency
dependence. Maybe there is a reasonable way to have it also model state
dependence. And the idea looks even better now that we are on the verge of
having IBIS-ISS as the circuit language.

Mike

On 9/30/10 11:17 PM, "Mirmak, Michael" <michael.mirmak@intel.com> wrote:

> Not to "pile on", but should we not consider having voltage- and
> frequency-dependent C_comp values?
>
> This topic has been the subject of various proposals over the years.
>
> - MM
>
> -----Original Message-----
> From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of
> Lance Wang
> Sent: Wednesday, September 29, 2010 8:04 AM
> To: 'ibis@server.eda.org'; 'ibis-users'
> Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min
>
> Arpad,
> Thanks for adding these valid points.
>
> I was trying to focus on the biggest concern and it was based on my
> knowledge only. :)
>
> Regards,
>
> Lance Wang
> 978-764-2298
> IO Methodology Inc.
> www.iometh.com
>
>
>
>
>
> -----Original Message-----
> From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
> Of Muranyi, Arpad
> Sent: Wednesday, September 29, 2010 10:49 AM
> To: ibis@server.eda.org; ibis-users
> Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min
>
> Lance,
>
> Add to that the different values needed
> some times for high and low states too...
>
> In addition, you may also want to consider
> the different amount of capacitance between
> the output and the GND or the output and
> the Power rails.
>
> Arpad
> =============================================
>
> -----Original Message-----
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Lance Wang
> Sent: Wednesday, September 29, 2010 9:45 AM
> To: 'ibis@server.eda.org'; 'ibis-users'
> Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min
>
> I would like to echo Bob's comment.
>
> Accurate C-comp value is more important nowadays for high-speed buffers.
> Depending on my knowledge, the biggest inconsistency issue is that IBIS only
> allows one C-comp value for an I/O buffer. (per corner, of course)
>
> If we spell-out with two values for driving and receiving in IBIS, the IBIS
> simulations will give out more accurate results related to ringing and
> timing issues. I think it will be a great news especially for high-speed
> memory buffers.
>
> Best regards,
>
> Lance Wang
> 978-764-2298
> IO Methodology Inc.
> www.iometh.com
>
>
>
>
>
>
> -----Original Message-----
> From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
> Of Haller, Robert
> Sent: Wednesday, September 29, 2010 8:51 AM
> To: Bob Ross; 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
>
> 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
>
>
> --
> 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
>
>
> --
> 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