Subject: BIRD25.1 DATA DERIVATION EXPANSION

From: [email-masked] ( Bob Ross)
Date: Tue, 7 Feb 95 19:18 PST

IBIS Members:

First, thank you Will Hobbs, Derrick Duehren and Intel for arranging and
hosting the very successful IBIS Summit on February 6.

Based on discussions there, BIRD25.1 is issued.  It contains an
initial statement to point to the Notes on Data Extraction per Karl
Kachigan's suggestion.  It also changes the default of C_comp to be
consistent with existing practice when min and max values are
given independent of process information.  This is the major change
from BIRD25.  There are also some minor text corrections.

The major impact of BIRD25.1 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 process corner rational for inserting C_comp "min" and "max" 
    column entries.
 
(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.1
ISSUE TITLE:             DATA DERIVATION EXPANSION
REQUESTOR:               Bob Ross, Interconnectix, Inc.
DATE SUBMITTED:          25 January 1995 
DATE REVISED:            7 February 1995
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:

Item #12 is added to the "General syntax rules and guidelines fpr ASCII
IBIS files" section at the beginning to point to important information
in the NOTES ON DATA DERIVATION METHOD section at the end:

| 12)  Important supplimental information is contained in the last section,
|      "NOTES ON DATA DERIVATION METHOD", concerning how data values are
|      derived.
|

Replace the first Paragraph of NOTES ON DATA DERIVATION METHOD section shown
below:

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

The replacement text follows: 

|==============================================================================
|
|                       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
| 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 smallest value
| should be placed in the "min" column, and the largest 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 which handle 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 operating 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 so that 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 and  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 accept 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 terms 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, the smaller value is positioned
in the "min" column and the larger value in the "max" column.  This 
arbitrary correlation may relate to internal die size tolerance and 
strength, but may be opposite of the correlation of capacitance value 
and speed.  However, it is consistent with existing practice to date.

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

---

From: [email-masked] (Jon Powell)
Date: Wed, 8 Feb 95 10:25:37 PST

|

I feel that this statement is too weak. We are proposing a change to the way a
model is created. Presumably this means a change to the IBIS version number
(2.1 -> 2.2). I think it is reasonable to require that 2.2 rev. models follow
the stronger requirement of min max definition. If you don't know where the data
came from then it is either a) a 2.1 model  b) unsuitable for use  c) wrong.

The problem is that if we allow this multiple definition there is no way to determine
how the data was collected and so me must ALWAYS assume that the data is WRONG and so
this strengthening does not accomplish anything.

It is as if we have said: You can fix the problem or not, and you don't have to tell
us which you did.

respectfull submitted, 
jon powell