Michael:
To add, one proposal documented as BIRD79 with 24 new
subparameters was considered and rejected.
A number of different ideas already are on the table, which
require up to 10 new/relocated sub-parameters (adding a separate
driving and non-driving C_comp), or a global re-mapping method
for all C_comp entries from by-value to by corner (usually just
sybollically interchanging min and max).
Bob
Just dealing with some of the primary issues has
Mirmak, Michael 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
>
-- 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 1993Received on Thu Sep 30 22:32:44 2010
This archive was generated by hypermail 2.1.8 : Thu Sep 30 2010 - 22:35:43 PDT