Walter,
You are making valid points, and took the words out of my
mouth by sending your email before I was able to write my
reply. I just want to add one more point to consider:
In light of the discussions revolving around the reactive
load issues, I wonder whether we need to revisit the basic
IBIS algorithm and come up with a better one which would
involve perhaps differential equations and higher-order
effects. I don't have a clear idea yet what such an
algorithm would look like, but there is certainly room
for some research there...
Of course, given the VHDL and Verilog AMS capabilities in
the IBIS specification, any algorithm is possible without
changing the specification itself...
Arpad
============================================================
-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Walter
Katz
Sent: Friday, October 01, 2010 2:18 PM
To: Mike LaBonte; Mirmak, Michael; Lance Wang; IBIS
Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min
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 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 13:35:34 2010
This archive was generated by hypermail 2.1.8 : Fri Oct 01 2010 - 13:36:10 PDT