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 1993Received on Wed Sep 29 07:49:49 2010
This archive was generated by hypermail 2.1.8 : Wed Sep 29 2010 - 07:50:01 PDT