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

I feel that BIRD 133 is intended to solve the correlation between the IBIS
corner simulations and golden sources (simulation or measurement) for
C-Comp/IBIS model. I agree that it does not solve everything related to
C-comp or corner issues in IBIS. But I do think it is one step ahead and
solves correlation issue for C-comp corners in existing IBIS spec. It is
very easy for EDA companies to implement and back compatible with old
versions too.

Michael, you did bring us very interesting thoughts about corners in
IBIS/Modeling. I personally do like the new idea and fresh mind. J

Due to my very limited knowledge, I could not think how to use it to make
changes in existing IBIS spec. So here is a request from me:

Could you please give us a simple example? How would it help for
correlations? And how could simulator/EDA tool implement?

Thank you!

Lance Wang

IO Methodology Inc.

SimDET IBIS Validator - Make sure it runs accurately. FREE!

www.iometh.com/Product/IBISValidator

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  <http://www.mailscanner.info/> MailScanner, 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