To All:
BIRD69.1 is issued with changes provided by Greg Edlund and documented in the
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION section.
Bob Ross
Mentor Graphics
*******************************************************************************
*******************************************************************************
BIRD ID#: 69.1
ISSUE TITLE: Golden Waveforms
REQUESTOR: Greg Edlund, IBM
DATE SUBMITTED: December 15, 2000, February 22, 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.
*******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
I propose that we add two new keywords and a corresponding set of sub-
parameters to accommodate the inclusion of Golden Waveform in an IBIS
datasheet. These sub-parameters should also facilitate simulation.
|=============================================================================
| Keywords: [Rising Golden Waveform], [Falling Golden Waveform]
| Required: No
| Description: Documents expected behavioral simulation results using
| known ideal test loads for simulation accuracy reporting.
| Sub-Params: 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,
| R_diff, T_ref, V_term1, V_term1_min, V_term1_max, V_term2,
| V_term2_min, V_term2_max,
| Pkg_pin, Receiver_model_name, Test_point
| Usage Rules: Each [Rising Golden Waveform] and [Falling Golden Waveform]
| keyword introduces a table of voltage vs. time points that
| describe the shape of a reference waveform. These voltage-
| time waveforms are generated under the conditions specified
| by the subparameters. The process, temperature, and voltage
| conditions under which the 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 table itself consists of one column of time points, then
| three columns of 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. All four
| columns are required. However, data is only required in the
| typical column. If minimum or maximum data is not available,
| use the reserved word "NA". The first value in the time
| column need not be '0'. The waveform table can contain a
| maximum of 1000 data rows. A maximum of 100 waveform tables
| are allowed per model.
|
| The subparameters specify the loading conditions under which
| the waveform is generated. The diagram below shows the
| interconnection of these elements.
|
| 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
|
|
| R_diff is not shown in the schematic but would be connected
| between the true and complement far end nodes in the case
| of a differential driver. In this case, the true and
| complement nets will be identical as defined by the other
| subparameters.
|
| T_ref is the time at which the output of the driver crosses
| V_meas when driving C_ref/R_ref/V_ref with an input signal
| identical to the one used to generate the Golden Waveform.
| Behavioral simulators may use T_ref to establish a time
| base for time correlation measurements.
|
| 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.
|
| Pkg_pin is required and indicates which, if any, pin model
| was used to generate the Golden Waveform. If the Golden
| Waveform represents a packaged simulation, then its value
| must be a valid pin name as defined by the [Pin] keyword.
| If the Golden Waveform represents an unpackaged simulation,
| then the Pkg_pin subparameter must have the value "none."
|
| Receiver_model_name is required and indicates which, if any,
| receiver model was used to simulate the Golden Waveform.
| If the Golden Waveform represents a simulation using a
| receiver, its value must be a valid model name. If the
| Golden Waveform represents a simulation with no receiver,
| then the Receiver_model_name subparameter must have the
| value "none."
|
| Test_point is required and defines the node in the above
| schematic at which the Golden Waveform is measured. It must
| have the value near or far.
|
| Using the Golden Waveform tables, it is possible to run
| behavioral simulations under conditions identical to the ones
| used to generate the waveforms in SPICE. The behavioral
| waveforms can be correlated against the Golden Waveforms in
| voltage and time to produce a quantitative measurement of
| the accuracy of 1) the model data, 2) the behavioral model,
| and 3) the behavioral simulator.
|
| If a parameter is not used, it defaults to the value
| specified in the following table:
|
| C1_near = 1f
| Rs_near = 1M
| Ls_near = 1p
| C2_near = 1f
| Rp1_near = 1M
| Rp2_near = 1M
| Td = 1ns
| Zo = 50
| Rp1_far = 1M
| Rp2_far = 1M
| C2_far = 1f
| Ls_far = 1p
| Rs_far = 1M
| C1_far = 1f
| T_ref = 1.00ns
| R_diff = 1M
| V_term1 = 1.0
| V_term1_min = 1.0
| V_term1_max = 1.0
| V_term2 = 1.0
| V_term2_min = 1.0
| V_term2_max = 1.0
|
|-----------------------------------------------------------------------------
[Rising Golden Waveform]
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
T_ref = 2.00ns
V_term1 = 1.50
V_term1_min = 1.35
V_term1_max = 1.65
V_term2 = 0.00
V_term2_min = 0.05
V_term2_max = 0.05
Pkg_pin none
Receiver_model_name Input1
Test_point 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 Golden Waveform]
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
T_ref = 2.00ns
V_term1 = 1.50
V_term1_min = 1.35
V_term1_max = 1.65
V_term2 = 0.00
V_term2_min = 0.05
V_term2_max = 0.05
Pkg_pin none
Receiver_model_name Input1
Test_point 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
|
*******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
The East Coast IBIS Users Group identified a need to document accuracy
information and formed the IBIS Accuracy Subcommittee to address this need.
This subcommittee met during the year 1997-1998 and drafted what became
the "I/O Buffer Accuracy Handbook." This document outlines a set of
procedures that can be used by modeling engineers to verify behavioral
simulation accuracy, using SPICE simulations as a reference. This BIRD
provides an infrastructure within IBIS for communicating important accuracy
data as defined by the "I/O Buffer Accuracy Handbook."
It is not intended that this BIRD require any simulator changes except to
ignore the new keywords and sub-parameters. However, should a simulator
vendor decide to use the new keywords and sub-parameters, it is intended
that they provide a complete set of information for carrying out simulations
that may be used to report correlation statistics to the user. In the
absence of simulator support, the user would have to perform the correlation
work manually (which many of us are doing already) using the information
in the new Golden Waveform tables.
It is entirely up to the modeling engineer to decide which values to assign
to which sub-parameters. This is an engineering decision that should be
based on the design of the I/O buffer under test. The generalized test load
network should cover a broad range of I/O buffer families.
Since these new keywords and sub-parameters are not required, I don't see
any backward compatibility problems.
BIRD69.1 Changes by Greg Edlund:
I have updated BIRD 69 according to our discussion during the Open Forum
last Friday. Here is a summary of the changes:
1. Removed subparameter Driver_model_name (was redundant).
2. Removed "=" from Node and Receiver_model_name.
3. Changed name of subparameter Node to Test_point to enhance clarity.
4. Added subparameter R_diff to handle far-end termination for differential
drivers.
5. Replaced V_term with V_term1. Added V_term2 to allow for termination to
negative voltages, e.g. ECL.
6. Added subparameter Pkg_pin to indicate which package model, if any, to
use.
*******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
I have discussed similar ideas with members of several simulator vendor
companies, and each had a positive response in general.
Please see the "I/O Buffer Accuracy Handbook" for complete details on
correlation test loads, procedures, and metrics.
The C program "ack" could provide an example of correlation metric
calculation for interested simulator vendors.
Thanks to Jerry Hayes at IBM for coming up with the idea for a generalized
test load network.
*******************************************************************************
Received on Wed Feb 23 06:49:58 2000
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT