BIRD25 DATA DERIVATION EXPANSION

IBIS Members:

In response to recent reflector discussions, BIRD25 is proposed.

BIRD25 is intended for an IBIS Version 2.2 update clarification release or
for Version 3.0. It makes clearer the data values and under what conditions
data is expected to be provided in the "min" and "max" columns for certain
data.

The major impact of BIRD25 is to add clarity by:

(1) Giving a rational for populating the "min" and "max" columns.

(2) Allowing usage of "slow, weak" process and "fast, strong" process models
    or devices in developing IBIS models.

(3) Giving a rational for inserting C_comp "min" and "max" column entries.
    This differs from most current practice, but is on the table for
    discussion.

(4) Including conditions for [Rising Waveform] and [Falling Waveform] table
    "min" and "max" column entries, to correct an omission.

Bob Ross,
Interconnectix, Inc.

*****************************************************************************

*****************************************************************************
                 Buffer Issue Resolution Document (BIRD)

BIRD ID#: 25
ISSUE TITLE: DATA DERIVATION EXPANSION
REQUESTOR: Bob Ross, Interconnectix, Inc.
DATE SUBMITTED: 25 January 1995
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

******************************************************************************

******************************************************************************

STATEMENT OF THE ISSUE:

As IBIS has expanded in functionality, some of the derivation rules and
usage has not been fully considered or documented in the standard.

******************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Original first Paragraph of NOTES ON DATA DERIVATION METHOD section:

|==============================================================================
|
| NOTES ON DATA DERIVATION METHOD
|
| This section explains how data values are derived. The intention is to
| avoid over-guardbanding which enables simulation results that are meaningful
| and useful. This intention is accomplished by having each silicon vendor
| base its data on typical process data, and then derate by voltage and
| temperature, and a proprietary "X%" factor. This methodology also has the
| nice feature that the data can be derived either from vendor-proprietary
| silicon models, or typical device measurement over temperature/voltage.
|

Replace this with the following text:

|==============================================================================
|
| NOTES ON DATA DERIVATION METHOD
|
| This section explains how data values are derived. It describes certain
| assumed parameter and table extraction conditions if they are not
| explicitly specified. It also describes the allocation of data into
| the "typ", "min", and "max" columns under variations of Voltage,
| Temperature, and Process.
|
| The required "typ" column for all data represents nominal operating
| conditions. The "min" column corresponds to slow, weak conditions, and
| the "max" column corresponds to fast, strong conditions. It is
| permissible to use weak, slow devices or models to derive the data
| for the "min" column, and to use strong, fast devices or models to
| derive the data in the "max" columns with the voltage and temperature
| derating conditions described in the "min" or "max" columns. It is also
| permissible to use typical devices or models under voltage and temperature
| conditions and also optionally apply proprietary "X%" and "Y%" factors
| described later for further derating. This methodology has the
| nice feature that the data can be derived either from vendor-proprietary
| silicon models, or typical device measurement over temperature/voltage.
|
| All voltage keyword settings will always contain the smallest magnitude
| voltage in the "min" column and the largest magnitude voltage for the
| "max" column to represent simutaneously all supplies set at their
| minimum values and all supplies at their maximum values.
|
| The optional [Temperature] keyword parameters will have the temperature
| which causes or amplifies the slow, weak conditions in the "min" column
| and the temperature which causes or amplifies the fast, strong
| conditions in the "max" column. Therefore, the "min" column for
| [Temperature] will contain the lowest value for bipolar devices (TTL
| and ECL) and the highest value for CMOS devices. Default values are
| described later are assumed if temperature is not specified.
|
| The [Model] sub-parameter C_comp allows optional "min" and "max" values.
| If extractable, the values under the "min" and "max" columns shall be
| obtained under the same conditions that the other data is extracted.
| Otherwise, if only the range of values is known, the highest value
| should be placed in the "min" column, and the lowest value in the
| "max" column.
|
| Default conditions under which all V/I tables are extracted are given
| below when the temperature is not explicitly specified and a typical
| model or device is used. The voltage ranges for the tables cover the
| most common, single supply, standard logic situations. For situations
| where multiple supplies are used, extend the tables in a similar manner
| to voltages for the worst case reflected wave values that would be
| encountered in practice.
|
| Default conditions under which the [Ramp] sub-parameters dV/dt_r and
| dV/dt_f are given for the "typ", "min", and "max" columns. A 50 Ohm
| load is normally assumed, but this can be overriden with the value given
| by the R_load sub-parameter. The temperature and voltage conditions
| for the "min" and "max" columns are consistent with and identical to
| those of the V/I columns.
|
| The measurement setups under which the optional keyword tables for
| [Rising Waveform] and [Falling Waveform] tables are described as
| required and optional sub-parameter for those keywords. Therefore,
| there are no alternative default measurement conditions. The temperature
| and voltage conditions shall also be consistent with the [Ramp]
| sub-parameter conditions. Note, that even though waveform keywords
| may be supplied, the [Ramp] keyword is still required to the the
| IBIS model can still be used in applications which do not support
| processing of waveform data.
|
| The overriding rule for inserting data into "typ", "min", and "max"
| columns for the C_comp, V/I, ramp and waveform keywords and sub-parameters
| is that the data under each column is obtained under the same voltage
| and voltage conditions to preserve correlation and consistency.
|
| Any keyword or sub-paramater which is not explicitly mentioned in this
| section is expected to have "min" column entry to contain the
| smallest value, and the "max" column entry the largest value. For example,
| the default package sub-parameter "min" and "max" column entries are
| expected to span the smallest to largest values based on physical
| locations unrelated to the voltage, temperature, and process considerations
| in this section.
|
| The following discussion lists details and default conditions when
| explicit, optional temperature settings and test conditions are not
| provided.
|

Existing text follows.

******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION

As IBIS expands to capture more capability, there needs to be consistent
alignment of certain correlated data. More restrictive guidelines are
needed in specifying "min" and "max" column entries so that related
groupings for the die model can all exist in the same column.

The rational for "min" and "max" columns needs to be expressed.

Because Spice based I/O models frequently are given as separate
"slow, weak" and "fast, strong" models such as in the TI Advanced Bus
Interface SPICE I/O Models Data Book, provisions to except such models
needed to be stated. This is consistent with actual usage and needs
to be included in supporting utilities such as "s2ibis" for Version 2.1.

If the [Temperature] keyword is used, the data that goes into the "min"
and "max" columns is restated in context of the reason for providing the
"min" and "max" columns. Furthermore, while temperature itself may
not necessarily be used in processing an IBIS model, it could be
used to generate it through automated tools. Therefore, the
temperature used needs to be aligned with the other data in the
column.

There exists a potential conflict in IBIS in that the C_comp "min" and
"max" column entries can be derived in certain cases from actual Spice
models or data and is correlated with other "min" column or "max"
column entries. The largest value does not necessarily reside in the
"max" column. Without clarification, the larger value of C_comp would
be positioned in the "max" column, and any correlation would be lost.
Because automated extraction of IBIS data from die models is a reality,
it is important to obtain each column of data under identical conditions.
When correlation of C_comp is not known, then typically the larger value
is used for slower buffer conditions ("min" column entry applications).
Here a change is proposed that in the case where only the range of data
values is known, the larger value be positioned in the "min" column.
While this may require an update revision of existing models, it is
important to resolve this. Otherwise, IBIS may be faulted for an
unnecessary inconsistency, and the processing of IBIS data will remain
ambiguous with respect to C_comp variations. It should NOT be assumed
that the "min" corner use a "max" C_comp value because such an
assumption would preclude the knowledge and proper usage of more
reliable, correlated C_comp values.

Conditions for [Rising Waveform] and [Falling Waveform] column entries
are clarified to be consistent with the [Ramp] sub-parameter entries.

The "min" column and "max" column entries apply only to the "process-
based" IBIS data. Other data follow standard "min" and "max" entries
based on magnitude because they pertain to variations that are unrelated
to process parameter variations or else their application (such as
terminator resistor values) would be treated (optionally) as an independent
variation for analysis and design.

******************************************************************************

ANY OTHER BACKGROUND INFORMATION
Received on Wed Jan 25 21:06:39 1995