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 1993Received on Mon Sep 27 18:16:47 2010
This archive was generated by hypermail 2.1.8 : Mon Sep 27 2010 - 18:17:24 PDT