BIRD 70.5

From: Gregory R Edlund <gedlund@us.ibm.com>
Date: Fri Aug 10 2001 - 10:00:49 PDT

I made the following changes according to our discussion at today's Open
Forum call:

1. Specified table format should conform with [Rising/Falling Waveform].
2. Specified measurement location as driver/receiver I/O pad.
3. Only one waveform required rather than one waveform pair.
4. Changed Test_Load to Test_load.
5. Specified non-inverting driver output when using single-ended waveform
with differential driver.
6. Changed "SPICE" to "reference waveforms."

Greg Edlund
Electrical Packaging
IBM Server Technology Development
3605 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
gedlund@us.ibm.com

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

BIRD ID#: 70.5
ISSUE TITLE: Golden Waveforms
REQUESTOR: Greg Edlund, IBM
DATE SUBMITTED: March 16, 2001; April 16, 2001; April 18, 2001; May 4,
2001;
                 July 23, 2001; August 10, 2001
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

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

STATEMENT OF THE ISSUE:

Golden Waveforms are a set of SPICE waveforms simulated using known ideal
test loads. They are useful in verifying the accuracy of behavioral
simulation results for any given simulator. They are not the same thing as
the traditional VT tables recommended in the "IBIS Cookbook." The "I/O
Buffer
Accuracy Handbook" recommends a set of ideal test loads for classical
push-pull and open-drain drivers.

There is currently a problem with including Golden Waveforms in an IBIS
datasheet: the simulator tries to use these waveforms to construct its
stimulus waveform, and erroneous simulations result.

This BIRD proposes a new syntactical construct to tell the simulator that a
waveform is a Golden Waveform. The simulator may then choose to ignore the
data or (better yet) run a set of simulations using the network and circuit
parameters provided and report the correlation between the simulation
results
and the Golden Waveforms. The mechanism for describing a Golden Waveform
involves two new keywords whose scope is global: [Test Load] and [Test
Data].
Under the [Test Data] keyword are eight Wavevform keywords whose scope is
local.

[Test Load] is a description of a test load network that may be referenced
by
any Golden Waveform under the [Test Data] keyword. [Test Data] is a marker
keyword that indicates the beginning of a group of Golden Waveforms.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

|=============================================================================
|
| Keywords: [Test Data]
| Required: No
| Description: Indicates the beginning of a set of Golden Waveforms
| and references the conditions under which they were
derived.
| An IBIS file may contain any number of [Test Data] sections
| representing different driver and load combinations.
|
| Sub-Params: Test_data_type, Driver_model, Driver_model_inv, Test_load
|
| Usage Rules: The name following the [Test Data] keyword is required.
| It allows a tool to select which data to analyze.
|
| The Test_data_type subparameter is required, and its value
| must be either "Single_ended" or "Differential."
| The value of Test_data_type must match the value of
|* Test_load_type found in the load called by Test_load.
|
| The Driver_model subparameter is required. Its value
| specifies the "device-under-test" and must be a valid
[Model]
| name. Driver_model_inv is only legal if Test_data_type is
| Differential. Driver_model_inv is not required but may be
| used in the case in which a differential driver uses two
| different models for the inverting and non-inverting pins.
|
| The Test_load subparameter is required and indicates which
| [Test Load] was used to derive the Golden Waveforms. It
must
| reference a valid [Test Load] name.
|
|-----------------------------------------------------------------------------
|
[Test Data] Data1
Test_data_type Single_ended
Driver_model Buffer1
Test_load Load1
|
|=============================================================================
|
| Keywords: [Rising Waveform Near], [Falling Waveform Near],
| [Rising Waveform Far], [Falling Waveform Far],
| [Diff Rising Waveform Near], [Diff Falling Waveform Near],
| [Diff Rising Waveform Far], [Diff Falling Waveform Far]
|* Required: At least one Rising/Falling waveform is required under the
| scope of the [Test Data] keyword.
| Description: Describes the shape of the rising and falling Golden
|* Waveforms of a given driver and a given [Test Load]
measured
|* at the driver I/O pad (near) or receiver I/O pad (far).
| A model developer may use the [Rising Waveform Near/Far]
and
| [Falling Waveform Near/Far] keywords to document Golden
| Waveforms whose purpose is to facilitate the correlation of
|* reference waveforms and behavioral simulations.
|
| Sub-Params: None.
|
| Usage Rules: The process, temperature, and voltage conditions under
which
| the Golden Waveforms are generated must be identical to
those
| used to generate the VI and VT tables. The Golden Waveforms
| must be generated using unpackaged driver and receiver
models.
| The simulator must NOT use the Golden Waveform tables in
the
| construction of its internal stimulus function.
|
|* The tables must conform to the format described under the
|* [Rising Waveform] and [Falling Waveform] keywords.
|
| Both differential and single-ended waveforms are allowed
| regardless of the value of Test_data_type. If
Test_data_type
| is Singled_ended then differential waveforms will be
ignored.
| If Test_data_type is Differential, a single-ended waveform
|* refers to the model specified by Driver_model and the
|* non-inverting driver output.
|
|-----------------------------------------------------------------------------
|
[Rising Waveform Far]
| Time V(typ) V(min) V(max)
   0.0000s 25.2100mV 15.2200mV 43.5700mV
   0.2000ns 2.3325mV -8.5090mV 23.4150mV
   0.4000ns 0.1484V 15.9375mV 0.3944V
   0.6000ns 0.7799V 0.2673V 1.3400V
   0.8000ns 1.2960V 0.6042V 1.9490V
   1.0000ns 1.6603V 0.9256V 2.4233V
   1.2000ns 1.9460V 1.2050V 2.8130V
   1.4000ns 2.1285V 1.3725V 3.0095V
   1.6000ns 2.3415V 1.5560V 3.1265V
   1.8000ns 2.5135V 1.7015V 3.1600V
   2.0000ns 2.6460V 1.8085V 3.1695V
| ...
  10.0000ns 2.7780V 2.3600V 3.1670V
|
[Falling Waveform Far]
| Time V(typ) V(min) V(max)
   0.0000s 5.0000V 4.5000V 5.5000V
   0.2000ns 4.7470V 4.4695V 4.8815V
   0.4000ns 3.9030V 4.0955V 3.5355V
   0.6000ns 2.7313V 3.4533V 1.7770V
   0.8000ns 1.8150V 2.8570V 0.8629V
   1.0000ns 1.1697V 2.3270V 0.5364V
   1.2000ns 0.7539V 1.8470V 0.4524V
   1.4000ns 0.5905V 1.5430V 0.4368V
   1.6000ns 0.4923V 1.2290V 0.4266V
   1.8000ns 0.4639V 0.9906V 0.4207V
   2.0000ns 0.4489V 0.8349V 0.4169V
| ...
  10.0000ns 0.3950V 0.4935V 0.3841V
|
|=============================================================================
|
| Keywords: [Test Load]
| Required: No
| Description: Defines a generic test load network and its associated
| electrical parameters for reference by Golden Waveforms
| under the [Test Data] keyword. The Golden Waveform
| tables correspond to a given [Test Load] which is specified
| by the Test_load subparameter under the [Test Data]
keyword.
|
| Sub-Params: Test_load_type, C1_near, Rs_near, Ls_near, C2_near,
Rp1_near,
| Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far,
| C1_far, V_term1, V_term2, Receiver_model,
Receiver_model_inv,
| R_diff_near, R_diff_far.
|
| Usage Rules: The Test_load_type subparameter is required, and its value
| must be either "Single_ended" or "Differential."
|
| The subparameters specify the electrical parameters
| associated with a fixed generic test load. The diagram
| below describes the single_ended test load.
|
| All subparameters except Test_load_type are optional.
| If omitted, series elements are shorted and shunt elements
| are opened by default.
|
|
| V_term1
| o-----------o
| | |
| \ \
receiver_model_name
| ______ / /
______
| | | NEAR Rp1_near \ \ Rp1_far FAR |
|
| | |\ | / / | |\
|
| | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \
|
| | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-|
> |
| | | / | | | | Td | | | | | /
|
| | |/ | | C1_near | \ Zo \ | C2_far | | |/
|
| |______| === === / / === ===
|______|
| | C2_near | \ \ | C1_far |
| | | / / | |
| | | | V_term2 | | |
| o--------------o o-----------o o--------------o
| | Rp2_near Rp2_far |
| GND GND
|
|
| If the Td subparameter is present, then the Zo subparameter
| must also be present. If the Td subparameter is not
present,
| then the simulator must remove the transmission line from
| the network and short the two nodes to which it was
| connected.
|
| V_term1 defines the termination voltage for parallel
| termination resistors Rp1_near and Rp1_far. This voltage
| is not related to the [Voltage Range] keyword.
| If either Rp1_near or Rp1_far is used, then V_term1 must
| also be used.
|
| V_term2 defines the termination voltage for parallel
| termination resistors Rp2_near and Rp2_far.
| If either Rp2_near or Rp2_far is used, then V_term2 must
| also be used.
|
|
| Receiver_model is optional and indicates which, if any,
| receiver is connected to the far end node. If not used, the
| network defaults to no receiver.
|
| Receiver_model_inv is not required but may be used in the
| case in which a differential receiver uses two different
| models for the inverting and non-inverting pins.
| Receiver_model_inv is ignored if Test_load_type is
| Single-ended.
|
| If Test_load_type is Differential, then the test load is a
| pair of the above circuits. If the R_diff_near or
R_diff_far
| subparameter is used, a resistor is connected between the
| near or far nodes of the two circuits. If Test_load_type
is
| Single_ended, R_diff_near and R_diff_far are ignored.
|
|-----------------------------------------------------------------------------
|
[Test Load] Load1
Test_load_type Single_ended
C1_near = 1p
Rs_near = 10
Ls_near = 1n
C2_near = 1p
Rp1_near = 100
Rp2_near = 100
Td = 1ns
Zo = 50
Rp1_far = 100
Rp2_far = 100
C2_far = 1p
Ls_far = 1n
Rs_far = 10
C1_far = 1p
R_diff_far = 100
Receiver_model Input1
| variable typ min max
Vterm1 1.5 1.4 1.6
Vterm2 0.0 0.0 0.0
|
| Example Transmission Line and Receiver test load from "I/O Buffer
Accuracy
| Handbook," section 3.4.4.
|
[Test Load] Tline_rcv
Td = 1n
Zo = 50
Receiver_model Input1
|
|-----------------------------------------------------------------------------

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an
attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is
actually more compact and efficient because it allows multiple models to
access the same [Test Load]. Recommendations came from Bob Ross, Al Davis,
and the IBIS Open Forum, 3/2/01.

Changes between BIRD 69.1 and BIRD 70:

1. Scope of the "generic test load" is now global rather than being
   local to a particular model. This is a big improvement.

2. Added one subparameter, Golden_test_load, to [Rising Waveform],
   [Falling Waveform] keywords. Added text to describe new the
subparameter.
   The Golden_test_load subparameter calls a [Test Load].

3. Exported all the other code to the new [Test Load] keyword.

4. Removed T_ref subparameter. To do timing correlation, the simulator can
   pick a point on the 50 Ohm VT waveform as its "SPICE reference point"
and
   then simulate both the 50 Ohm load and the Golden_test_load to calculate
   a time difference.

5. Removed Pkg_pin parameter. It is too complicated. The user can model a
   simple single-pin lumped circuit using the parameters supplied.

6. Added Tline_present subparameter. If not used, the Tline should be
   removed from the simulation rather than assigned a very small delay
value.
   This prevents the simulator from taking ridiculously small time steps.

7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters.
   This makes the BIRD more economical.

8. Got rid of the paragraph that read, "Using the Golden Waveform
tables..."
   This seemed to be redundant.

9. Specified which parameters are optional and which are required.

Changes between BIRD 70 and BIRD 70.1/70.2:

 1. Moved the Golden Waveforms OUT of the [Model] scope and under the
    scope of a new keyword, [Test Data].

 2. Changed [Rising Waveform] to [Rising Waveform Near/Far].
    Changed [Falling Waveform] to [Falling Waveform Near/Far].

 3. Added subparameter Driver_model under [Rising Golden Waveform] and
    [Falling Golden Waveform]. This is necessary because the waveforms
    are now outside the scope of the [Model].

 4. Changed the subparameter Golden_test_load to Test_load.

 5. Added the Vx_rise/fall subparameters to indicate the end of a timing
    interval for timing correlation.

 6. Added Tmeas_rise/fall to facilitate timing correlation.

 7. Added subparameters Test_data_type and Test_load_type to facilitate
    upward compatibility with future versions of IBIS.

 8. Removed Tline_present subparameter in favor of language explaining
    that the simulator should remove the Tline if Td is not present.

 9. Moved Driver_model and Test_load under the scope of [Test Data].

10. R_diff became R_diff_near and R_diff_far.

11. Removed timing-related keywords:
    Tmeas_rise, Tmeas_fall, Vx_rise, Vx_fall
    This function can be achieved with less complexity by including a
    Golden Waveform that represents the standard (timing) test load.

12. Added four differential waveform keywords.

Changes between BIRD 70.3 and BIRD 70.4 (see lines beginning with |* ):

 1. Added subparameter Driver_model_inv under [Test Data].

 2. Added subparameter Receiver_model_inv under [Test Load].

 3. Added language defining the legal values of Test_data_type.

 4. Made Test_load_type a required subparameter.

 5. Made Vterm subparameters required if the corresponding resistors are
    used.

Changes between BIRD 70.4 and BIRD 70.5 (see lines beginning with |* ):

 1. Specified table format should conform with [Rising/Falling Waveform].

 2. Specified measurement location as driver/receiver I/O pad.

 3. Only one waveform required rather than one waveform pair.

 4. Changed Test_Load to Test_load.

 5. Specified non-inverting driver output when using single-ended waveform
    with differential driver.

 6. Changed "SPICE" to "reference waveforms."

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

ANY OTHER BACKGROUND INFORMATION:

See BIRD 69.1.

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

 
Received on Fri Aug 10 10:02:53 2001

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:47 PDT