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