Mike,
The proposal was to have a new keyword Final_Stage_Subckt that would allow
for different subckts for typ, slow, fast, and additional subckts for
Driving High, Driving Low and Receiving/3-state. This and determining the
nodes of the subckt are easy. It is not trivial to implement an IBIS model
in Spice that switches from one Final_Stage_Subckt to a different
Final_Stage_Subckt during a transition from H to L or from L to H or if
doing bus turn around simulations that would require switching between an
Driving and Receiving in an IO. The more difficult task is to determine the
waveform that turns on and off the pullup and pulldown IV curves from the
ramp dV/dt or the V-T data. Doing the C-comp correction is assuming a
constant C-comp is already messy. The solution to this problem is to have
the V-T tables represent how the pullup curves get turned on and off during
a transition, instead of representing what the output of the buffer is into
a standard load.
The fact that C_comp is used to correct the actual rise time that goes into
a simulation is critical and it is therefore important to know which C_comp
to use for each typ/slow/fast corner.
Walter
Walter Katz
303.449-2308
Mobile 303.883-2120
wkatz@sisoft.com
www.sisoft.com
-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org]On Behalf Of Mike
LaBonte
Sent: Friday, October 01, 2010 2:22 PM
To: Mirmak, Michael; Lance Wang; IBIS; IBIS
Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min
I liked the proposal from some time ago to allow for a passive subcircuit to
represent die capacitance. This could model complexities such as frequency
dependence. Maybe there is a reasonable way to have it also model state
dependence. And the idea looks even better now that we are on the verge of
having IBIS-ISS as the circuit language.
Mike
On 9/30/10 11:17 PM, "Mirmak, Michael" <michael.mirmak@intel.com> 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
-- 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 Fri Oct 1 12:15:32 2010
This archive was generated by hypermail 2.1.8 : Fri Oct 01 2010 - 12:15:50 PDT