[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