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