******************************************************************************* ******************************************************************************* 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: Rejected March 30, 2001 ******************************************************************************* ******************************************************************************* 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. BIRD69.1 was rejected March 30, 2001 because its functionality is being considered in BIRD70. The format was changed enough to justify issuing BIRD70 and retiring BIRD69.1 to keep a record of the original proposal and Analysis information. *******************************************************************************