[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, 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