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