Re: [IBIS] RE: On BIRD133 and "corner"

Arpad

I have to agree with you.

Walter,

Think redistribution layer. This layer is neither included in the
silicon spice model nor the package model. Due to the higher Er of the
silicon it can be thought of as mostly capacitive.

Scott

Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC

On 7/15/2011 6:34 PM, Muranyi, Arpad wrote:
>
> Walter,
>
> Regarding: "C_Comp, IV curves and VT curves are totally related", I
> have to
>
> disagree.
>
> While you are correct that in a SPICE to IBIS conversion C_comp
>
> can be related to the I-V and V-t curves which were obtained from
>
> the same device at the same conditions, this C_comp may not be
>
> your min or max C_comp. Often C_comp is put into the IBIS model
>
> from a different source of information. This way you can get min
>
> and max C_comp, but it becomes unrelated to the device from which
>
> the I-V and V-t curves were measured.
>
> Don't forget that IBIS models are often made from pre-silicon
>
> SPICE models which do not include the on-die interconnect
>
> (metal) and pad capacitance effects, and to make up for this
>
> missing information often C_comp is massaged manually from
>
> other calculations.
>
> Once you consider these things you should see why C_comp is
>
> more or less an independent variable...
>
> Thanks,
>
> Arpad
>
> =================================================================
>
> *From:*Walter Katz [mailto:wkatz@sisoft.com]
> *Sent:* Friday, July 15, 2011 5:03 PM
> *To:* Muranyi, Arpad; 'ibis@server.eda.org'
> *Subject:* RE: [IBIS] RE: On BIRD133 and "corner"
>
> Arpad,
>
> C_Comp, IV curves and VT curves are totally related. Any logical
> Spice-2-IBIS process (either physical measurements on representative
> typical, slow or fast parts or similar simulation measurements of
> typical, slow or fast SPICE models) determine IV and VT curves, along
> with AC analysis (VNA measurements or SPICE AC simulations) to
> determine C_Comp. It is very common to measure smaller C_Comp for fast
> parts and large C_Comp for slow parts. It is critical for accurate
> timing to use the correct C_Comp with the corresponding IV and VT
> curves. There is too much confusion by moth model makers and model
> users on how to generate C_Comp and how to use C_Comp.
>
> We have spent a huge amount of time on C_Comp, when there is the
> following simple solution:
>
> New parameter C_Comp_Corner with the following rules:
>
> A Model must have C_Comp or C_Comp_Corner, but not both.
>
> C_Comp Typ Min Max shall be considered a range and not correlated with
> Process Corner.
>
> The User may indicated to the EDA tool whether Min/Max should be used
> with Slow/Fast or Fast/Slow or independent.
>
> The Typ, Min, Max values shall comply with the following numerical
> relationship :
>
> Min Value <= Typ Value <= Max Value.
>
> C_Comp_Corner Typ Min Max shall be considered to align with Typ Min
> Max of Temperature, Voltage Range, and IV and VT curves Typ Min Max.
>
> C_Comp_Corner specifically does not require Min Value <= Typ Value <=
> Max Value.
>
> I think the above is perfectly clear. This is such a trivial change to
> IBIS I do not know why we are spending so much time on it.
>
> Walter
>
> *From:*owner-ibis@eda.org [mailto:owner-ibis@eda.org] *On Behalf Of
> *Muranyi, Arpad
> *Sent:* Friday, July 15, 2011 4:30 PM
> *To:* 'ibis@server.eda.org'
> *Subject:* [IBIS] RE: On BIRD133 and "corner"
>
> Mike,
>
> Good thoughts! I agree that we need to look at this with a fresh
>
> mind. I think part of the problem is that there are certain groups
>
> of data which track, and others which do not. For example, I-V
>
> and V-t curves are strongly related, because the conditions to
>
> get a certain set of I-V curves will also be the same conditions
>
> to get a corresponding certain set of V-t curves. So it would
>
> probably make sense to have an indication in the model data for
>
> which parameters track each other and which do not. Our typ/min/max
>
> is not defined well enough to know whether they imply tracking or
>
> independent data. We only find out about that in Section 9 but
>
> that is not detailed enough to make serious conclusions from it.
>
> The problem is that this is only true to a certain extent, or put
>
> it differently, there are mixed conditions, some of which track,
>
> some of which don't.
>
> For example, the edge rate of the output may depend on the amount
>
> of capacitance on the die. This capacitance may depend on the
>
> etching characteristics of how metal was put on the die. Therefore
>
> we could say that C_comp and the V-t tables do have some relation,
>
> while C_comp and I-V tables do not have that relation. On the other
>
> hand, I-V and V-t tables are related by other relations (supply
>
> voltage, temperature, etc...) which may not have an effect on C_comp
>
> variations. So I can see partial dependencies between the tree
>
> parameters (I-V, V-t and C_comp), but not complete dependencies.
>
> If we provided these three parameters in an IBIS model with the
>
> expectation that all possible combinations must be simulated, we
>
> would ask for a lot of simulations which never happen in real life.
>
> But associating only the same kind from typ/min/max may not cover
>
> all the situations which do happen in real life. BIRD 133 goes in
>
> this direction and I am actually concerned about that.
>
> What we should do is define a mechanism for the model data that
>
> could allow the description of the relations somehow. How much
>
> does a V-t table vary if I change C_comp, or if I change the I-V
>
> table, etc... I have our good old Design of Experiments in the
>
> back of my mind (maybe in a reversed way) which gives information
>
> on which variable(s) result in the biggest changes in the result.
>
> Any ideas on how to go on with these concepts?
>
> Arpad
>
> ======================================================================
>
> *From:*owner-ibis@eda.org [mailto:owner-ibis@eda.org] *On Behalf Of
> *Mirmak, Michael
> *Sent:* Friday, July 15, 2011 2:25 PM
> *To:* 'ibis@server.eda.org'
> *Subject:* [IBIS] On BIRD133 and "corner"
>
> /(the opinions below are purely personal and are not intended to
> represent those of any organization whatsoever)/
>
> //
>
> I would like to gently and in a friendly way disagree with the
> concepts and objectives of BIRD133. While the BIRD itself does indeed
> cleanly address an inconsistency in IBIS -- and should likely be
> approved for that reason -- I believe the entire "corner" concept in
> IBIS needs to be scrapped and a new approach defined.
>
> In detail...
>
> Traditional IBIS was originally intended to enable model makers to
> describe two types of data under the same format:
>
> -Simulation data
>
> -Measurement data
>
> The format included either single values or tables of data grouped
> under "typ", "min" and "max" headings, including temperature, I-V
> tables, V-t tables, voltage and buffer capacitance (C_comp).
>
> For measurement especially, "min" and "max" are really "condition 1",
> "condition 2", etc. In other words, we are using "min", etc. as
> labels to group data into a set because the data in the set was
> gathered under shared conditions. I suggest that measured IBIS data
> is therefore great for correlation, but *that the "max" and "min"
> labels should not necessarily be interpreted as describing performance
> extremes.*
>
> For simulation, data under "min" and "max has the "condition grouping"
> implication, but also is meant to imply that the model *maker is
> providing characterization of the extremes of performance to the
> user.* Having data at the performance extremes therefore enables the
> user/system designer to ensure that the design works with any
> manufactured version of that silicon design.
>
> BIRD133 closes a gap in IBIS that has confused many. C_comp is
> defined in IBIS as associating the numerically smallest value with
> "min" and largest with "max" but the other IBIS data columns, like
> temperature, may associate "high" with "min", where "min"*is a label
> implying a group of conditions leading to a performance corner. *
>
> BIRD133 explicitly allows linking of C_comp values with a "corner" as
> used in the rest of the model. However, I would argue that, as I
> mentioned in an IBIS Summit presentation
> (http://www.eda.org/ibis/summits/jun10/mirmak.pdf), the concept
> "corner" used for the entire part may not be meaningful, particularly
> if I want to run a statistical analysis. Having only three corners
> simply compounds the problem.
>
> Ultimately, I simulate to see whether my system has margin, and how
> much, when extremes of behavior are noted in design components (and,
> ideally, I want some idea of how likely to occur these extremes are).
> Having all parameters grouped into only three corners is not
> sufficient. I really want to know what extremes or ranges exist for
> each individual parameter in my buffer (and traces and ...), and vary
> those independently to see margin impacts.
>
> What does "max" mean? Maximum edge rate? Maximum impedance? Maximum
> transition delay? "Max" is a misleading title, as the parameters
> that enable my buffer's transition speed to be at a maximum (aka,
> "fast") may not line up with maximum impedance. Similarly, Arpad
> Muranyi mentioned auto-compensated designs during today's IBIS Open
> Forum meeting - this is a good example of a case where process and
> condition variations may make little or no difference to the output
> behavior of a buffer. The conditions labeled "min" and "max" may not
> lead to impedances on such a buffer that are in any way different.
> Therefore, the word "max" over an I-V table for that buffer is
> misleading. Today's configurable buffers may also allow me to
> independently vary or compensate termination resistance vs. buffer
> capacitance vs. edge rate, etc. So "min" and "max" become meaningless.
>
> Apply the same approach to traces and you may see a similar problem: a
> "max" trace model could be maximum impedance, maximum delay, maximum
> loss or something else, and a single group called "max" is unlikely to
> show the same behavior for all of those electrical parameters.
>
> So, in short, I suggest that we really want to enable a more general
> description for buffer extremes:
>
> -Remove the association of "min" "typ" and "max" columns between IBIS
> parameters (meaning, "typ" voltage would no longer be associated with
> "typ" temperature and "typ" I-V data)
>
> -Instead, describe individual parameters such as buffer capacitance,
> I-V behavior, etc. using either an expected range, or one or more
> single values/columns where each *value or data set is associated with
> a label*
>
> -*The maximum number of labeled data sets would be unlimited (similar
> to the description of Series MOSFET or of [Model Selector] in general)*
>
> -Separately, a map of labels to groups may be provided, so that model
> makers could describe the conditions and outputs associated with a
> particular measurement, for correlation purposes (e.g., I-V table "A"
> was gathered using the temperature and voltage shown in group "Z24")
>
> -The same mapping could be used to define fixed associations, if the
> model maker decides they apply (for example, that for the given part,
> buffer capacitance really does always track with temperature)
>
> -The groupings would enable users to separate linked and independent
> parameters for statistical or sweep simulation purposes
>
> Ideally, equation-based descriptions make this move to
> independently-varying parameters much easier. However, data tables
> still have a place and labels can help there. This label/group
> approach would enable piecewise descriptions of buffer behavior (this
> has definite advantages when trying to define buffer impedance using
> S-parameters, where the impedance may also be significantly
> voltage-dependent).
>
> Comments are welcome.
>
> -MM
>
>
> --
> 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, 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