Subject: BIRD 70.3

From: "Gregory R Edlund" <[email-masked]>
Date: Fri, 4 May 2001 14:16:02 -0500

BIRD 70.3 has four new keywords for differential waveforms.

I removed the "timing-related" subparameters in favor of using an extra set
of Golden Waveforms that
specify the standard (timing) test load.

There is still one outstanding issue:  what are the legal combinations of
test_data_type and test_load_type?

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

BIRD ID#:      70.3
ISSUE TITLE:   Golden Waveforms
REQUESTOR:     Greg Edlund, IBM
DATE SUBMITTED:       March 16, 2001; April 16, 2001; April 18, 2001;
                      May 4, 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, 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 Driver_model subparameter is required.  Its value
|               specifies the "device-under-test" and must be a valid
[Model]
|               name.
|
|               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 pair 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].
|               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
|               SPICE 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.
|
|-----------------------------------------------------------------------------
|
[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_data_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, R_diff_near,
|               R_diff_far.
|
| Usage Rules:  The value of the Test_data_type subparameter 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_data_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.
|               V_term2 defines the termination voltage for parallel
|               termination resistors Rp2_near and Rp2_far.
|
|               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.
|
|               If Test_load_type is differential, a the test load is a
|               pair of the above circuits.  If the R_diff_near
subparameter
|               is used, it is connected between the near nodes of the two
|               circuits.  If the R_diff_far subparameter is used, it is
|               connected between the near nodes of the two circuits.
|
|-----------------------------------------------------------------------------
|
[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      = 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.

BIRD 70.3 adds 192 lines of code to IBIS, of which 138 are comments.

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

ANY OTHER BACKGROUND INFORMATION:

See BIRD 69.1.

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

Greg Edlund
Electrical Packaging
IBM Server Technology Development
3605 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
[email-masked]

---

From: Al Davis <[email-masked]>
Date: Fri, 4 May 2001 22:27:50 -0700

On Fri, 04 May 2001, Gregory R Edlund wrote:
> I removed the "timing-related" subparameters in favor of using an
> extra set of Golden Waveforms that
> There is still one outstanding issue:  what are the legal
> combinations of test_data_type and test_load_type?

That's easy.  Just say they need to be the same.

It needs clarification of the meaning of the various waveforms, and 
which can be used with which type.

Something like:

Diff waveforms are only used with type differential, and are measured 
differentially.  The other waveforms may be used with either 
single_ended or differential types.  When used with the differential 
type, they represent the common mode waveforms, measured from one 
side to ground.

It would probably be an improvement to explicitly say they are 
common-mode, as in [Common Mode Rising Waveform Near], so the Diff or 
Common forms are used with type differential, and the plain is used 
with single-ended.  Reason:  the plain one will be interpreted as the 
most significant, but in differential mode the differential one 
really is.