RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min

From: Fabio BRINA <fabio.brina@st.com>
Date: Tue Sep 28 2010 - 03:11:12 PDT

Thank you Arpad for your clear answer,
Thank you Bob, I think your write a good proposal,
Thank you all,

I'd like to say my little opinion, that come from the simply
observation of an IBIS text like the following:

|*********************************************************
|*********************************************************
|
[Model] MOD1
Model_type I/O
Polarity Non-Inverting
Vinl = 0.250V
Vinh = 1.650V
Vmeas = 0.9V
|
Cref = 30pF
Rref = 0.7K
Vref = 0.9V
|
| variable typ min max
C_comp 5.51pF 5.22pF 5.82pF
|
| variable typ min max
[Temperature Range] 25.0 85.0 -25.0
[Voltage Range] 1.800V 1.700V 2.000V
[Pulldown]
| voltage I(typ) I(min) I(max)
|
-1.8000V -44.300mA -36.420mA -53.700mA
-1.7460V -44.170mA -36.180mA -53.600mA
-1.6920V -43.960mA -35.930mA -53.500mA
-1.6380V -43.730mA -35.670mA -53.300mA
...

every user guess that the columns of current I(typ) I(min) I(max) are
associated to the Temp. and Voltage supply few lines above.
I think that would be logical (but it's only an opinion) that the
C_comp values are associated to the same columns of Temp. and Voltage Supply
(so C_comp(min)=5.22pF come from Temp=85 and Voltage=1.7V)

After that, we can define the relationship from C_comp values with
"process corners" with the support of designers. In the extreme case
of lack of support (not so unusual for truth...), we can maintain the
typ corner for all the three cases.

Thank you,
Regards,

Fabio

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Bob Ross
Sent: Tuesday, September 28, 2010 3:17 AM
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
Received on Tue Sep 28 03:12:24 2010

This archive was generated by hypermail 2.1.8 : Tue Sep 28 2010 - 03:12:43 PDT