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 1993Received on Tue Sep 28 15:33:08 2010
This archive was generated by hypermail 2.1.8 : Tue Sep 28 2010 - 15:33:34 PDT