BIRD 12.1

Hello Fellow IBISians --

     Based on the conversation today I've updated Bird 12 to 12.1.
The details of the change are listed in the ANALYSIS PATH/DATA section
of the bird. I hope I captured everything. Thanks again for everyones
input.

                Best Regards,
                Stephen Peters
                Intel Corp.

----------------------- CUT HERE ------------------------------

                 Buffer Issue Resolution Document (BIRD)

BIRD ID#: 12.1
ISSUE TITLE: Non-Linear Driver Waveforms
REQUESTER: Stephen Peters, Intel Corp.

DATE SUBMITTED: April 25, 1994, Revised April 29, 1994
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

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

STATEMENT OF THE ISSUE: The IBIS specification does not contain enough
information to adequately describe the characteristics of a device whose
output switching waveform is significantly non-linear. This BIRD proposes
a method to describe these non-linear ramp waveforms.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are added to
the specification, [Rising waveform] and [Falling waveform]. These
keywords introduce a table of time vs. voltage points that describe the
shape of a waveform.
|
| Keywords: [Rising waveform], [Falling waveform]
| Required: No
| Description: Used to describe the shape of the rising and falling edge
| waveforms of a driver.
| Sub-params: R_fixture, V_fixture, C_fixture, L_fixture,
| R_dut, L_dut, C_dut
| Usage Rules: Each [Rising waveform] and [Falling waveform] keyword
| introduces a table of time vs. voltage points that
| describe the shape of an output waveform. These
| time/voltage points are taken under the conditions
| specified in the R/L/C/V_fixture and R/L/C_dut
| sub-parameters. The table itself consists of
| one column of time points, then three columns of
| voltage points in the standard typ, min and max format.
| The four entries must be placed on a single line and
| must be separated by at least one white space or tab
| character. All four columns are required, however, data
| is only required in the typical column. If minimum
| or maximum data is not available the reserved word "NA"
| is used. The first value in the time column does not
| have to be '0'. Time values must increase as
| one parses down the table. The waveform table may
| contain a maximum of 100 data points. Note that for
| backwards compatibility the existing [Ramp] keyword
| is still required.
|
| A waveform table must include the entire waveform;
| i.e., the first entry (or entries) in a voltage column
| must be the DC voltage of the output before switching
| and the last entry (or entries) of the column must be
| the final DC value of the output after switching.
|
| A [Model] specification can contain more than one
| rising edge or falling edge waveform table;
| however, each new table must begin with the appropriate
| keyword and sub-parameter list as shown below. If more
| than one rising or falling edge waveform table is
| present, then the data in each of the respective tables
| must be time correlated. In other words, the rising
| (falling) edge data in each of the rising (falling) edge
| waveform tables must be entered with respect to a
| common reference point on the input stimulus waveform.
|
| The 'fixture' sub-parameters specifies the loading
| conditions under which the waveform is taken.
| The R_dut, C_dut, and L_dut are analogous to the the
| package parameters R_pkg, C_pkg and L_pkg and are used
| if the waveform includes the effects of pin
| inductance/capacitance. The diagram below shows the
| interconnection of these elements.
|
| |
| |
| PACKAGE | TEST FIXTURE
| _________ |
| | DUT | L_dut R_dut | L_fixture R_fixture
| | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture
| | | \/ | | | \/
| |_________| | | |
| | | |
| C_dut === | === C_fixture
| | | |
| | | |
| gnd | gnd
|
| Only the R_fixture and C_fixture sub-parameters are
| required, the rest of the sub-parameters are optional.
| If a sub-parameter is not used its value defaults to
| zero. The sub-parameters must appear in the text after
| the keyword and before the first row of the waveform
| table.
|
[Rising waveform]
R_fixture = 500
V_fixture = 5.0
C_fixture = 50p
L_fixture = 2n
C_dut = 7p
R_dut = 1m
L_dut = 1n
|Time V(typ) V(min) V(max)
 0.0ns 0.3 0.5 NA
 0.5ns 0.3 0.5 NA
 1.0ns 0.6 0.7 NA
 1.5ns 0.9 0.9 NA
 2.0ns 1.5 1.3 NA
 2.5ns 2.1 1.7 NA
 3.0ns 3.0 2.7 NA
 3.5ns 3.2 3.0 NA
|
[Falling waveform]
R_fixture = 50
V_fixture = 0
|Time V(typ) V(min) V(max)
 10.0ns 3.2 3.0 NA
 10.5ns 3.0 2.7 NA
 11.0ns 2.1 1.7 NA
 11.5ns 1.5 1.3 NA
 12.0ns 0.9 0.9 NA
 12.5ns 0.6 0.7 NA
 13.0ns 0.3 0.5 NA
 13.5ns 0.3 0.5 NA

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Currently, the IBIS
specification assumes that all devices can be described accurately using
a single risetime and falltime parameter. In other words, the switching
waveform of the device is a relatively linear ramp. However, devices that
shape the output waveform (risetime controlled devices) do not have a
linear switching ramp. Trying to model devices of this type using a
linear ramp model results in mis-predicting both the time to logic threshold
and maximum edge rate.

     As IBIS is a specification that focuses on the behavior of a device
rather than it structure or implementation, it would be ideal if there
were a simple set of measurements one could take in order to describe
the non-linearity. Obviously, the waveform shape itself is a good
place to start. The fundamental assumption here is that the shape of the
waveform, combined with the loading conditions, give simulator vendors
enough additional information to construct accurate models of non-linear
waveform drivers. Ideally, an IBIS model will include waveforms taken
under several different loading conditions (R_fixture and V_fixture). By
choosing the appropriate loading conditions a modeler can give the
simulator vendors enough information to accurately simulate a device.
The most straight forward way to describe a waveform shape is with a
table of time vs. voltage points. (Note that one could take this table
and enter it into a spreadsheet or graphing program and produce a picture
of the waveform -- and that is one of the intents of the format.)

     One remaining issue is the ability to align the starting points of
waveforms taken under different loading conditions (i.e. waveforms in
two different tables). Jon Powell (Quad Design) has an action item to
produce various waveforms and show this is possible. (PLEASE SEE THE
NOTE BELOW ON VERSION 12.0 TO 12.1 CHANGES)

     In addition to providing more complete information to simulator vendors,
explicitly describing the waveform allows one to validate a particular
simulator's results. By performing a simulation into the specified load(s)
and then comparing the results with the waveform(s) as listed in the IBIS
file, one can perform anything from a quick sanity check of the data to
a detailed analysis between simulators. A 'self-validating' model is a
very powerful tool for checking and maintaining model quality.

VERSION 12.0 TO 12.1 CHANGES:
     Based on e-mail suggestions and conversions in the April 29th IBIS
open forum the following changes were made:

 1. The sub-parameters now have an '=' between the sub-parameter name
    and value.

 2. The maximum number of data points in a waveform table has been
    specified (100 max).

 3. A statement was added that requires that all rising/falling edge
    data be time correlated. To make this perfectly clear: the data
    in one rising edge table must be time correlated to the data in
    any other RISING edge waveform table. Likewise for falling edge
    data. There is no requirement for time correlation between the
    data in rising and falling waveform tables. Note also the requirement
    that the correlation be to a reference point on the input stimulus
    waveform. This is to prevent a user from time correlating the
    waveforms to a point on an output waveform -- this defeats the
    purpose of time correlation.

 4. The sub_parameters were expanded and changed from 'load' to 'dut'
    and 'fixture' to better indicate there proper use. A connection diagram
    was also added.

 5. Cleaned up a few typos in the original version.

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

ANY OTHER BACKGROUND INFORMATION:

*******************************************************************************
Received on Fri Apr 29 15:15:01 1994