BIRD 12, non-linear ramps

Hello Fellow IBISans

     Another egg has hatched........

                Regards,
                Stephen Peters
                Intel Corp.

--------------------------- cut here -----------------------------

                 Buffer Issue Resolution Document (BIRD)

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

DATE SUBMITTED: April 25, 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_load, V_load, C_load, L_load
| 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 point are taken under the conditions
| specified in the R_load, V_load, C_load and L_load
| 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.
|
| 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. The
| waveform table may contain as many points as needed
| to accurately describe the wave. Note that for backwards
| compatibility the existing [Ramp] keyword is still
| required and the [Ramp] values should be derived as
| described in Version 1.1 of the IBIS specification.
|
| The R_load and V_load sub-parameters are required while
| the C_load and L_load sub-parameters are optional. R_load
| and V_load are the thevenin equivalent resistance and
| voltage the driver is switching into. C_load and
| L_load are analogous to the the package parameters C_pkg
| and L_pkg and are used if the waveform includes the
| effects of pin inductance/capacitance. If they are not
| specified they default 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_load 50
V_load 1.5
C_load 10p
L_load 2n
|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_load 50
V_load 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.0 0.0 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_load and V_load). 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.

     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.

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

ANY OTHER BACKGROUND INFORMATION:

*******************************************************************************
Received on Mon Apr 25 09:24:46 1994