****************************************************************************** ****************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 12.2 ISSUE TITLE: Non-Linear Driver Waveforms REQUESTOR: Stephen Peters, Intel Corp. DATE SUBMITTED: April 25, 1994 DATE REVISED: April 29, 1994; May 13, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: May 13, 1994 ****************************************************************************** ****************************************************************************** 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_fixture, V_fixture, C_fixture, L_fixture, | R_dut, L_dut, C_dut | 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 points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | 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. The waveform table may | contain a maximum of 100 data points. There is a | maximum of 100 waveform tables allowed per model. | Note that for backwards compatibility the existing | [Ramp] keyword is still required. | | 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. If more | than one rising or falling edge waveform table is | present, then the data in each of the respective tables | must be time correlated. In other words, the rising | (falling) edge data in each of the rising (falling) edge | waveform tables must be entered with respect to a | common reference point on the input stimulus waveform. | | The 'fixture' sub-parameters specifies the loading | conditions under which the waveform is taken. | The R_dut, C_dut, and L_dut are analogous to the the | package parameters R_pkg, C_pkg and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | | | | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture | | | \/ | | | \/ | |_________| | | | | | | | | C_dut === | === C_fixture | | | | | | | | | gnd | gnd | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used its value defaults 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_fixture = 500 V_fixture = 5.0 C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |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_fixture = 50 V_fixture = 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.3 0.5 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_fixture and V_fixture). 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. (PLEASE SEE THE NOTE BELOW ON VERSION 12.0 TO 12.1 CHANGES) 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. VERSION 12.0 TO 12.1 CHANGES: Based on e-mail suggestions and conversions in the April 29th IBIS open forum the following changes were made: 1. The sub-parameters now have an '=' between the sub-parameter name and value. 2. The maximum number of data points in a waveform table has been specified (100 max). 3. A statement was added that requires that all rising/falling edge data be time correlated. To make this perfectly clear: the data in one rising edge table must be time correlated to the data in any other RISING edge waveform table. Likewise for falling edge data. There is no requirement for time correlation between the data in rising and falling waveform tables. Note also the requirement that the correlation be to a reference point on the input stimulus waveform. This is to prevent a user from time correlating the waveforms to a point on an output waveform -- this defeats the purpose of time correlation. 4. The sub_parameters were expanded and changed from 'load' to 'dut' and 'fixture' to better indicate there proper use. A connection diagram was also added. 5. Cleaned up a few typos in the original version. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ******************************************************************************