========================================= IBIS QUALITY SPECIFICATION - Revision 1.0 ========================================= INDEX 1.0 IBIS Quality Summary 1.1 IBIS Quality level definitions 1.2 IBIS Quality summary as comments in file 2.0 General Header Section Requirements 3.0 Component Section 3.1 Component Package Requirements 3.2 Component Pin Requirements 3.3 Component Diff Pin Requirements 3.4 Component Model Selector Requirements 4.0 Model Section 4.1 Model General Requirements 4.2 Model Waveform Processing Requirements 4.3 Model I-V Table Requiremnts 4.4 Model V-T Table Requirements 4.5 Model Ramp Data Requirements 5.0 Possible Errors that should be checked 6.0 Correlation 7.0 Model limitations and Model Maker Notes 1.0 IBIS Quality Summary ======================== 1.1 IBIS Quality level definitions The 5 recognized levels of quality are: 1.1.1 Level 0 requirements Level 0 requirements can be checked by ibischk3 version 3.2.9 or later software. Use of ibischk3 is highly recommended, to avoid performing level 0 checks manually. - The version of ibischk used must be documented in the Quality Summary. - IBISCHK must yield 0 Errors - All IBISCHK warnings must be explained if they cannot be eliminated. Ideally, there should be no warnings, but it is recognized that some warnings cannot be eliminated. Additional level 0 requirements are not checked by ibischk3: - Vinl/Vinh must be defined on receivers - Standard Load/Vmeas must be defined on drivers - Overshoots must be defined for drivers and receivers 1.1.2 Level 1 requirements Level 1 includes all items in level 0, plus checks for correctness and completeness, and basic simulation tests: - All pins must be defined and validated for correct logical/physical/model mapping. - All package parasitics must be checked. - Model selectors must be validated. - [Diff Pins] must be validated. - Ccomp values must be checked. - All model spec waveforms and standard load parameters must be defined and validated. - Ramp Data must be validated in accordance with IBIS spec. - Ramp data must be validated against appropriate V-T tables if available. - V-T tables must be defined for all output drivers. - All I-V and V-T tables must be inspected. - Typ/Min/Max values must be present and in correct order for all tables and parameters. - All output models must be simulated into standard load and switch through VMEAS. - All receiver models must be simulated. 1.1.3 Level 2 requirements Level 2 includes all items in level 1, plus simulation and/or laboratory correlation: - Spice and/or Lab Correlation - Cross reference IBIS Accuracy figure of merit (FOM). 1.2 IBIS Quality summary as comments in file A summary of the quality of the IBIS model(s) contained in an IBIS file should be included in comments at the end of the Header information as prescribed in the IBIS Quality Checklist. These comments can appear after the Notes section in the Header. The IBIS Quality Summary comments must begin with the string '|IQ' (that is, the comment character followed by "IQ" for IBIS Quality. Each buffer model in an IBIS file can be separately characterized by its quality. The summary should contain a list of each buffer in the file, followed by the quality level for that buffer, followed by any comments the model creator deems necessary. An overall quality level should be indicated for each component in the file. This will be the minimum of the quality levels of the buffers used by the component. If the IBIS file contains more than one component, the overall quality of the IBIS file itself should be indicated. This will be the minimum of the quality levels of components contained in the file. If the file contains only one component, the component and file quality are synonymous, so only the component quality level needs to be indicated. The Quality Summary should also include a list of all unresolved warnings given by the Golden Parser (ibischk3) for the IBIS file, together with an explanation if necessary. Example: |IQ |IQ Buffer pdu04tv: Quality level 2a (update expected 4/1/2003) |IQ Buffer pdc01tv: Quality level 1 |IQ Buffer pdisv: Quality level 2b |IQ Buffer pduv: Quality level 3 |IQ Buffer pciv: Quality level 2a |IQ Buffer pdt04tv: Quality level 1 |IQ Buffer pdiv: Quality level 1 |IQ |IQ Component tpz773pn: Overall Quality level 1 |IQ |IQ Warning (line 433) Power Clamp Typical data is nonmonotonic |IQ Warning (line 433) Power Clamp Minimum data is nonmonotonic |IQ Warning (line 433) Power Clamp Maximum data is nonmonotonic |IQ 2.0 General Header Section Requirements ======================================= Requirements for the header section of the IBIS file, from the beginning of the file to the line before the first [Component] keyword. 2.1 {LEVEL 0} Header passes IBISCHK It is expected that semiconductor vendors pass the IBIS models they create through IBISCHK for testing purposes. A Quality Level 0 model must EITHER have no errors or warnings when passed through IBISCHK -OR- "acceptable" warnings must be identified in the IBIS file itself, under the [Notes] section below. The number of warnings expected, along with the reason why they should be considered acceptable must be identified. A Level 0 Model must NOT produce ANY errors when run through IBISCHK. Summary: - The is goal zero errors and zero warnings - In some cases zero warnings not possible. - Document known cases of acceptable warnings. - Document version of IBISCHK 2.2 {LEVEL 0} Latest [IBIS ver] used The highest IBIS version for which a parser is available should be used (presently 3.2, soon to be 4.0). Even if only IBIS 2.1 features are used in the model, the [IBIS Ver] value should be set to at least 3.2, this enables additional checking over and above the checks performed on version 2.1 models. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if old [IBIS ver] used. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2.3 {LEVEL 0} Do not use [Comment Char] If you are using the default comment character, then this keyword is not needed. Changing the comment character is not advised. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if [Comment Char] used. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2.4 {LEVEL 0} [File Name] is correct The [File Name] keyword must have the exact name of the IBIS file. File names must not contain spaces and should have a reasonable correlation to the names of the components in the file. As an example "ddr_ii.ibs" is not a desirable file name, since it does not distinguish the model file from memory devices produced by any number of vendors. A preferable name for the file would be "mt57w512h36b.ibs", as an example. 2.5 {LEVEL 0} [File Rev] is correct The IBIS specification has recommended usage for file revisions that is rarely used correctly. The following guidelines are recommended: | 0.x silicon and file in development | 1.x pre-silicon file data from silicon model only | 2.x file correlated to actual silicon measurements | 3.x mature product, no more changes likely The minor revision number 'x' should change each time the file is released. 2.6 {LEVEL 0} [Date] is correct The [Date] keyword must correctly reflect the date the file was last modified. It is recommended that the month and year be written out completely to aid scripted searches. 2.7 {LEVEL 0} [Source] is complete The [Source] keyword describes the information from which the model was created. Normal sources are SPICE and bench measurements. Enough detail should be present to enable the semiconductor vendor to trace back to the original source of the model data at a later date, for example: [Source] Derived from Spice I/O models, rev 543b, dated 11/15/02 using HSpice 2001.4/Win2K [Source] Derived from proto-a lab measurements, 9/4/01 2.8 {LEVEL 0} [Notes] is complete Any additional information that may help the user should be listed in the [Notes] section. At a minimum, this section should identify: - The version of IBISCHK used to check the completed model - Any IBISCHK warnings that are to be considered "acceptable" - A contact point (name, phone # or email) for model support - The model's edit history, with a list of past File Rev/Dates and the reason for each model change. 2.9 {OPTIONAL} [Disclaimer] and [Copyright] The [Disclaimer] keyword can contain some form of legal disclaimer, similar to what might appear on a data sheet. The [Copyright] keyword normally denotes the legal rights granted by the company that created the file. Alternatively, the company for which the model was created, if done as a "work for hire". 3.0 Component Section ===================== 3.1 Component Package Requirements ================================== Requirements for the [Package] and [Package Model] sections: 3.1.1 {LEVEL 0} [Package] must have typical values Typical values must be defined on a component. Min/Max optional but must be defined as NA if not available. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR (line 50) - The typical column must be specified. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1.2 {LEVEL 0} [Package] Parasitics must be reasonable Reasonable values are: L < 10nH, C < 20pF, R < 1 ohm Min must be less than typ and typ less than max. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if [Package] values are unreasonable. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1.3 {LEVEL 0} [Define Package Model] present if [Package Model] is present The [Define Package Model] keyword must be present if [Package Model] is present, even if contained in a separate .pkg file. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR - Unable to find Package Model '860_FCBGA' for Component 'I5000' +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1.4 {LEVEL 1} [Package] parasitics are validated against data sheet It is not necessary to check parasitics for each pin. 3.2 Component Pin Requirements ============================== Requirements for the [Pin] section: 3.2.1 {LEVEL 0} [Pin] section complete All pins must be defined for a component. In addition to signal pins: - No Connects must be represented with NC. - Power pins must be indicated POWER. - Gnd pins must be indicated GND. - Special Pins (e.g. analog) to be represented by NC with note that says not modeled. For IBIS buffer [Model] libraries, it is recommended that one pin be used for every model and that the pin name be the same as the model name. 3.2.2 {LEVEL 0} [Pin] model names not too long Model names in the [Pin] section should not exceed 20 characters for IBIS version 3.x, 30 characters for 4.x +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR (line 58) - Model name string 'BCM1250_SSTL2_7xxxxxxxxxxxxxxxx' is too long, truncating to 20 characters. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.2.3 {LEVEL 0} [Pin] models present in file Models referenced in the [Pin] section must exist in the same IBIS file or refer to a Model Selector. Bear in mind that model names in an IBIS file are case-sensitive. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR - Component 'BCM1250_Rev_AB': Model 'BCM1250_SSTL2_7xxxxx' for Pin 'A4' not defined. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.2.4 {OPTIONAL} [Pin] RLC complete RLC is optional on pins. If not defined either leave blank or use NA NA NA +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message for missing pin RLC. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.2.5 {LEVEL 1} [Pin] RLC parasitics are validated against data sheet Pin parasitics are optional, but if defined must be checked against data sheet if available. Each [Pin] RLC that is present must be within the min/max range given in the data sheet. Another rule of thumb is TD = SQRT(LC) < 300ps Zo=SQRT(L/C) <100ohm. 3.3 Component Diff Pin Requirements =================================== Requirements for the optional [Diff Pin] section: 3.3.1 {LEVEL 0} [Diff Pin] referenced pins exist If [Diff Pin] is defined, referenced physical pins must exist in the [Pin] section. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR - Component 'BCM1250_Rev_AB': Diff_Pin 'V411' not previously declared in Pin section. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.3.2 {LEVEL 0} [Diff Pin] Vdiff and Tskew complete and reasonable Vdiff must be defined and should be non-zero and positive. Skew data can be NA. Skew data must be reasonable if defined. Uncertainty window must be reasonable if defined. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ BIRD94 addresses this issue. Proposal: ibischk warning message if Vdiff is undefined or zero. Proposal: ibischk warning message if Tdelay is undefined or zero. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.3.3 {LEVEL 1} [Diff Pin] Vdiff and Tskew correct Vdiff and Tskew must correspond to data sheet. 3.3.4 {LEVEL 1} [Diff Pin] referenced pin models matched If buffer models referenced by the two physical pins of a [Diff Pin] are different, check to make sure you intended this. 3.4 Component Model Selector Requirements ========================================= Requirements for the optional [Model Selector] section: 3.4.1 {LEVEL 0} [Model Selector] referenced [Model]s exist All [Model]s referenced by a [Model Selector] must be present in the same IBIS file. 3.4.2 {LEVEL 1} [Model Selector] first [Model] is default The default [Model] reference should be listed fist in each [Model Selector] section. 4.0 Model Section ================= 4.1 Model General Requirements ============================== 4.1.1 {LEVEL 0} [Model] parameters have correct typ/min/max order Min corresponds to the conditions for weak/slow buffers, Max corresponds to conditions for strong/fast buffers. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ C_comp is the only typ/min/max [Model] parameter. ibischk v4.0.2 detects this: WARNING (line 962) - Model BCM1250_LDT_TERM: C_comp min value is not the smallest value listed WARNING (line 962) - Model BCM1250_LDT_TERM: C_comp max value is not the largest value listed +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.1.2 {LEVEL 0} [Model] Model_type The Model_type subparameter is case sensitive. The value must be one of the listed types from the IBIS specification. Examples of the commonly used model types below illustrate the required IV tables. MODEL_TYPE PULLUP PULLDOWN POWER_CLAMP GND_CLAMP COMBINED COMBINDED PULLUP+ PULLDOWN+ POWERCLAMP GND_CLAMP I/O XXX XXX XXX XXX Output XXX XXX XXX XXX 3-state XXX XXX XXX XXX I/O_Open_Drain XXX XXX XXX I/O_Open_Sink XXX XXX XXX I/O_Open_Source XXX XXX XXX Open_Drain XXX XXX XXX Open_Sink XXX XXX XXX Open_Source XXX XXX XXX +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR (line 958) - Invalid Model_type ("Serius") +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.1.3 {LEVEL 0} [Model] C_comp is reasonable C_comp must be defined, positive and less than 20pF. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if C_comp value is unreasonble. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.1.4 {LEVEL 1} [Model] C_comp is correct C_comp must represent the TOTAL die capacitance as specified by the data sheet. It MUST include the capacitances of the cell transistors at the attachment to the wiring, (for example, MOSFET pulldown Cds and pullup Cgs), the ESD structures, clamp diodes, on-die wiring to the bond pad, and the bond pad itself. Although capacitance varies with voltage, frequency and operating mode, only one value is allowed; the value should be the one that gives the best match in V-T tables and reflection characteristics (either SPICE or bench tests). It is recommended that the capacitances for different modes of operation be documented as comments if different, so that users may tune the IBIS model to their application. In IBIS 4.0 C_comp can be specified as four capacitances (Pullup, Pulldown, Power_clamp, Gnd_Clamp). +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if C_comp value is unreasonble. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.1.5 {LEVEL 2a} [Model] C_comp SPICE correlation C_comp can be extracted through SPICE characterization of cell. A number of papers describing techniques to extract C_comp, on the IBIS web site. 4.1.6 {LEVEL 2b} [Model] C_comp laboratory correlation Bench correlation of C_comp can be accomplished using techniques described in the Accuracy handbook, found on the IBIS web site. 4.1.7 {LEVEL 1} [Temperature Range] is reasonable This is the chip die temperature, NOT ambient temperature. Typ temperature is usually higher than room temperature. Normally, CMOS has the relationship: Temp(Min) > Temp(Max) while Bipolar has: Temp(Min) < Temp(Max) The default [Temperature Range] is: [Temperature Range] 50 100 0 In a high-quality model, this keyword should be present, even if the default values are intended. 4.1.8 {LEVEL 1} [Voltage Range] or [* Reference] is complete This is the operating voltage for a [Model]. It is required unless ALL FOUR of the other voltage reference keywords are supplied. Normally, Vcc(Min) < Vcc(Max). When this keyword is used alone, the other keywords default to: Pullup reference = voltage range value Pulldown reference = 0V Power clamp reference = voltage range value GND clamp reference = 0V 4.1.9 {LEVEL 1} [Pullup Reference] is reasonable The reference voltage for the [Pullup] table. This is the offset from GND. For CMOS, value > 0 is normal. 4.1.10 {LEVEL 1} [Pulldown Reference] is reasonable The reference voltage for the [Pulldown] table. This is the offset from GND. For CMOS, value = 0 is normal. 4.1.11 {LEVEL 1} [POWER Clamp Reference] is reasonable The reference voltage for the [POWER Clamp] table. This is the offset from GND. For CMOS, value > 0 is normal. For dual-supply I/O, may be different from [Pullup Reference]. 4.1.12 {LEVEL 1} [GND Clamp Reference] is reasonable The reference voltage for the [GND Clamp] table. This is the offset from GND. For CMOS, value = 0 is normal. 4.1.13 {LEVEL 1} [Model] timing test load subparameters complete IBISCHK should (but does not) issue a warning message when no timing test load is defined, since this is critical for system-level timing. Valid combinations of Vref, Rref, Cref, and Vmeas should be as follows: 1) Vmeas, Cref 2) Vmeas, Vref, Rref 3) Vmeas, Vref, Rref, Cref All other 13 (2^4 - 3) combinations should generate warnings as follows: Missing Vmeas -> Warning Cref with no Vmeas -> Warning Rref with no Vref -> Warning Vref with no Rref -> Warning 4.2 Model Waveform Processing Requirements ========================================== Requirements for received waveform processing. A number of parameters in the [Model] and [Model Spec] sections specify the switching characteristics of input and I/O buffers, in response to the received waveform. All IQ-compliant IBIS input and I/O models must have a [Model Spec] section giving S_overshoot_low and S_overshoot_high, as a minimum. 4.2.1 {LEVEL 0} [Model] Vinl and Vinh complete All input and I/O buffers have Vinl and Vinh subparameters in the [Model] section. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: WARNING - Model 'BCM1250_SSTL1_0': Model_type 'I/O_open_sink' must have Vinl set +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.2 {LEVEL 1} [Model] Vinl and Vinh correct Vinl and Vinh subparameters in the [Model] section represent the voltages at which a very slowly changing input signal is able to change the sensed input logic level for a typical corner buffer. 4.2.3 {LEVEL 1} [Model] Vinl and Vinh enclose Vmeas For I/O buffers Vinl and Vinh values should be below and above, respectively, Vmeas. Exceptions to this should be explained in a comment. It's uncommon. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if Vmeas not between Vinh or Vinl in I/O models. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.4 {LEVEL 1} [Model] Vmeas matches data sheet Vmeas in the [Model] section matches the value given in the data sheet for the part technology. 4.2.5 {LEVEL 1} [Model Spec] Vinl and Vinh complete If min and max values for Vinl and Vinh are known, these are given in the [Model Spec] section. For example, some technologies like HSTL and SSTL switch near a reference voltage that may change in typ, min, and max corners. 4.2.6 {LEVEL 0} [Model Spec] Vinl+/- and Vinh+/- complete For input buffers with different voltage thresholds for rising and falling edges, Vinh+, Vinh-, Vinl+, and Vinl- are given in the [Model Spec] section. 4.2.7 {LEVEL 0} [Model Spec] Vinl+/Vinh+ greater than Vinl-/Vinh- Vinh+ is greater than Vinh-, and Vinl+ is greater than Vinl-. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ NOTE: ibischk does compare Vinh+ to Vinh- and Vinl+ to Vinl-: WARNING - Vinh+(Typ) is not greater than or equal to Vinh-(Typ) for Model Spec defined on line 986 Proposal: ibischk caution message if Vinl+ > Vinh-. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.8 {LEVEL 1} [Model Spec] Vinl+/- and Vinh+/- enclose Vmeas For I/O buffers Vinl+ and Vinh- values should be below and above, respectively, Vmeas. Exceptions to this should be explained in a comment. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if Vmeas > Vinl+ or Vmeas > Vinh- in I/O models. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.9 {LEVEL 1} [Model Spec] Pulse subparameters complete If input voltage levels can rise above Vinh or fall below Vinl for short periods of time without being sensed as an input logic level change, Pulse_high, Pulse_low, Pulse_time are given in the [Model Spec] section. 4.2.10 {LEVEL 1} [Model Spec] Pulse_high greater than Vinh Pulse_high is greater than Vinh. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: WARNING - Pulse_high(Typ) is not greater than Vinh-(Typ) for Model Spec defined on line 986 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.11 {LEVEL 1} [Model Spec] Pulse_low less than Vinl Pulse_low is less than Vinl. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: WARNING - Pulse_low(Typ) is not less than Vinl+(Typ) for Model Spec defined on line 986 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.12 {LEVEL 1} [Model Spec] Pulse_time reasonable Pulse_time is less than the minimum rise time and fall time normally expected at the input. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if Pulse_time is greater than 100ns. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.13 {LEVEL 1} [Model Spec] S_Overshoot subparameters complete All input and I/O buffers have S_overshoot_high and S_overshoot_low in the [Model Spec] section. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if S_overshoot_high or S_overshoot_low missing. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.14 {LEVEL 1} [Model Spec] S_Overshoot subparameters match data sheet S_overshoot_high and S_overshoot_low in the [Model Spec] section correspond to the maximum and minimum DC limits for the voltage at the buffer input, as specified in the data sheet for the device technology. 4.2.15 {LEVEL 1} [Model Spec] S_Overshoot subparameters track typ/min/max When overshoot voltage limits are different in min and max corners, S_overshoot_high and S_overshoot_low should track these differences. For example, S_overshoot_high may increase with the higher supply voltage assumed for max mode. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if S_overshoot_hi does not follow the same typ/min/max order as [Pullup_reference]. Likewise, the magnitude of S_overshoot_low must track in the same order as S_overshoot_hi. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.2.16 {LEVEL 1} [Model Spec] D_Overshoot subparameters complete If greater levels of overshoot can be tolerated for short periods of time, these are given as D_overshoot_high, D_overshoot_low, and D_overshoot_time. 4.2.17 {LEVEL 1} [Model Spec] D_Overshoot subparams exceed S_Overshoot D_overshoot_high must be greater than S_overshoot_high, and D_overshoot_low must be less than S_overshoot_low. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: WARNING - D_overshoot_high(Typ) is not greater than S_overshoot_high(Typ) for Model Spec defined on line 986 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3 Model I-V Table Requirements ============================== A summary of the quality of the IBIS model(s) I-V tables is contained in this section. This should be included in |IQ section as prescribed in the IBIS Quality Checklist. These comments can appear after the Notes section in the Header. The term "table" as used in this document refers to rows and columns of numbers appearing in the text of the IBIS file. The term "curve" refers to the visual plotting of table data. Some checks are more easily performed visually. [Pullup] and [Power Clamp] tables in IBIS files are Vcc-relative. This means that the voltage values in the first column are actually offsets from Vcc. For example, the value at 0V in a [Pullup] table is actually measured at Vcc. Bear this in mind when checking Vcc-relative tables. Curve viewing tools may offer the ability to translate Vcc-relative tables so that the curves viewed are ground-relative. 4.3.1 {LEVEL 0} I-V tables complete The model verifier should check that all of the appropriate tables are present and correct, for each [Model]: [Pullup], [Pulldown], [Gnd Clamp], [Power Clamp] +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: WARNING - [Model] BCM1250_LDT_OD has no description of the buffer's low state DC drive characteristics (no [Pulldown] table). This warning can be silenced by changing the Model_type or by adding a [Pulldown] table. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.2 {LEVEL 1} I-V tables have correct typ/min/max order Inspect every I-V table. Check for proper order of the I-V tables. Columns Values in table must be: VOLTAGE, Current Typ, Current Min, Current Max In most cases current of Max is greater then current of typical, which is greater than Min, in the active region (e.g. where device is not clamping). This check is easily accomplished by viewing the curves and checking visually. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if absolute areas under the typ, min and max I/V curves do not conform. Possibly limit this to the region between ground and power voltage, since clamp curves can be unpredictable. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.3 {LEVEL 1} I-V tables have reasonable numerical range Check the numerical range of I-V values. Voltage Units are implied Volts. Current units are implied Amps. Recommendation on how to handle excessive currents. Currents in excess of 1 amp should be truncated. At least one additional point should be included that prevents the slope from being 0. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if combined I/V current > 1A. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NOTE: Bob Haller will check this 4.3.4 {LEVEL 1} [Pullup] voltage sweep range is correct The sweep for [Pullup] should be made between -vcc to 2*vcc. Pullup tables are relative to Pullup reference. The Pullup table combined with the power and ground clamp tables should be monotonic. Non-monotonic combined I-V tables must be documented. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if the lower endpoint of the [Pullup] voltage column is greater than -vcc, or if the upper endpoint is less than 2vcc. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.5 {LEVEL 1} [Pulldown] voltage sweep range is correct The sweep for [Pulldown] should be made between -vcc to 2*vcc. The Pulldown table combined with the power and ground clamp should be monotonic. Non-monotonic combined I-V tables must be documented. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if the lower endpoint of the [Pulldown] voltage column is greater than -vcc, or if the upper endpoint is less than 2vcc. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.6 {LEVEL 1} [Power Clamp] voltage sweep range is correct The [Power Clamp] should turn on near supply voltage i.e. (i.e. 3.3 volts for typ cmos power clamp). The sweep for Power clamp should be at least made between +vcc and +2vcc (it is permitted to extend the range). Non-monotonic I-V tables must be documented. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if the lower endpoint of the [Power Clamp] voltage column is greater than vcc, or if the upper endpoint is less than 2vcc. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.7 {LEVEL 1} [GND Clamp] voltage sweep range is correct [GND Clamp] should turn on approximately one Diode drop below 0.0 (i.e. 0.7 volts). The sweep for [GND Clamp] should be made at least between -vccmax and +vccmax (it is permitted to extend the range). Non-monotonic I-V tables must be documented. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if the lower endpoint of the [GND Clamp] voltage column is greater than -vcc, or if the upper endpoint is less than 0V. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.8 {LEVEL 1} I-V tables do not exhibit stair-stepping There should be no Stair Stepping of any I-V tables. This is caused by insufficient significant digits in the table current columns. It is also a common problem from the NCSU s2ibis conversion process. This check is easily accomplished by viewing the curves and checking visually. 4.3.9 {LEVEL 1} Combined I-V tables are monotonic Check that the combined tables are monotonically increasing, ie. there are no slope reversals in the current values. This check is easily accomplished by viewing the curves and checking visually. This must be checked by visual inspection until a Parser Bug is fixed in IBISCHK 4.x. This is important if there are non monotonic warnings because the Golden IBIS parser does NOT check combined tables. The Golden IBIS parser also stops reporting errors on a table after the first non-monotonic points are found. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this, but [IBIS ver] must be 4: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.10 {LEVEL 1} [Pulldown] I-V tables pass through zero/zero Typ, Min, and Max Pulldown table currents should all pass through zero at zero volts from ground (cmos). These three pull down tables should pass through zero/zero except in special cases (i.e. Differential, PECL, LVDS, or SERDES driver). +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if [Pulldown] current at 0V is greater than 1uA. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.11 {LEVEL 1} [Pullup] I-V tables pass through zero/zero For Un-terminated Models (i.e. CMOS push-pull), Typ, Min, and Max Pullup table currents should pass through zero current at zero volts for Vcc relative tables. If these curves are viewed graphically, ground relative, they should pass through their respective supply rail (eg. Typ should pass through 3.3 volts, Max should pass through 3.6 volts, min should pass through 3.0). Note that an IBIS I-V table is offset such that supply voltage on the Typ table falls at 0 volts in the table. For example, 3.3 volts usually falls at 0.0 in the table. Terminated drivers and some technologies may be exceptions i.e. Bipolar, ECL, and CMOS LVDS. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if [Pullup] current at the associated power voltage is greater than 1uA. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.12 {LEVEL 1} No leakage current in clamp I-V tables Review each clamp table. The expected currents should be less than 1 uA in the normal operating ranges (typically from 0 to 2 Vcc range in the table). If a table is truncated, use the extrapolated values based on the last two points prior to extrapolation. Or use a viewer which can combine the two clamp tables into one. Exceptions can exist for older TTL technologies where several milliamps may be observed and for some ECL and other technologies with which can have internal termination networks. Exceptions should be understood and documented. 4.3.13 {LEVEL 1} Clamp I-V behavior not double-counted Verify that if [GND Clamp] exists there is no clamp current behavior in the negative portion of the [Pulldown] table. Verify that if [Power Clamp] exists there is no clamp current behavior in the negative portion of the [Pullup] table. 4.3.14 {LEVEL 1} On-die termination modeling documented Any IBIS models with on-die termination should be labeled as such using comment lines. On die termination should be modeled in [Power Clamp] and/or [GND Clamp] tables. Document the method used to embed the termination into the clamps. NOTE: NCSU s2ibis2 does not correctly model on-die termination. It places the full termination characteristic in both [Power Clamp] and [GND Clamp] tables, effectively double-counting the termination. 4.3.15 {LEVEL 1} ECL models I-V tables swept from -Vdd to +2 Vdd. I-V tables in ECL models should be swept from -Vdd to +2 Vdd, even though the operating range is narrower. 4.3.16 {LEVEL 1} Point distributions in IV curves should be sufficient We recommend a minimum of 10 data points at points of inflection to prevent interpolation issues in simulations. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message for any I-V table in which a series of points with dI/dV changing by more than 5% from point to point has less than 10 points in the series. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.3.17 {LEVEL 2} Correlate IV curves to combined curves. I-V sweep in Simulator (level 2a) I-V sweep on Bench with table tracer (level 2b) 4.4 Model V-T Table Requirements =============================== 4.4.2 {LEVEL 0} V-T table endpoints consistent with I-V tables The voltage associated with the intersection of the V_fixture, R_fixture, and R_dut (if present) load line with the respective combined high/low DC I-V characteristic should be within 2% of the V-T table DC endpoints based on the V-T table DC range. The combined High State DC I-V characteristic is defined as the sum of the [Power Clamp], [GND Clamp], and [Pullup] I-V tables (ground relative). Similarly, the combined Low State DC I-V characteristic is defined as the sum of the [Power Clamp], [GND clamp], and [Pulldown] I-V tables (ground relative). +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this, but [IBIS ver] must be 4: NOTE: insert message here +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.4.3 {LEVEL 1} V-T tables look reasonable V-T tables should be well behaved, with continuous second derivative. V-T point density should be greater in areas with non-zero second derivative. Excess V-T points in beginning and end of V-T tables should be removed. Relative time position between all tables should be maintained. Final DC value must be achieved, ie. the ending slope should be very small. This check is easily accomplished by viewing the curves and checking visually. 4.4.4 {LEVEL 1} Model simulation successful Standard simulations run on models and documented. Documentation should include test circuit and simulator run on. 4.4.5 {LEVEL 1} Document known model limitations Document known model limitations as comments. Examples include PVT, unknown/placeholder threshold levels, LVDS restrictions, etc. 4.4.6 {LEVEL 1} Output and IO buffers have should have 2 sets of V-T tables Outputs and IO buffers should have four V-T tables: 50 Ohm Pullup (Voltage = [Pull Reference]) Rising Falling 50 Ohm Pulldown (Voltage = [Pull Reference]) Rising Falling LVDS and other terminated technologies may be modeled using 2 sets of V-T tables. by including Common mode voltage close to the region of operation. for example 50 Ohm to Vcm (Common Mode Voltage) Rising Falling +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if less than 2 sets of V/T curves. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NOTE: stopped here 8 mar 2005 4.5 Model Ramp Data Requirements ================================ The [Ramp] section is required even if [Rising Waveform] and [Falling Waveform] are present in a [Model]. [Ramp] information is used in some tools for non-simulation purposes, for example quickly finding the fastest pin on a net. 4.5.1 {LEVEL 0} Output and IO buffers have a [Ramp] section All buffers capable of output have a [Ramp] section. Input-only buffers, terminators, Series and Series_switch models do not have a [Ramp] section. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR - Model 'BCM1250_SSTL2_7': Ramp Not Defined +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.5.2 {LEVEL 1} [Ramp] R_load present if value other than 50 ohms If the [Ramp] data was measured using a load resistor other than 50 ohms, the [Ramp] section has an R_load subparameter giving the load resistor value used. 4.5.3 {LEVEL 1} [Ramp] test fixture has no reactives The fixture used for generating [Ramp] measurement waveforms has only the buffer, a load resistor, and a terminating voltage. No capacitors or inductors, for example. 4.5.4 {LEVEL 1} [Ramp] typ/min/max order is correct The typ, min, and max [Ramp] values are taken from typ, min, and max buffer measurements. They are not necessarily sorted by dV, dt, or dV/dt. Although the progression from min to max usually has dV increasing and dt decreasing, the correct order is actually determined by the test conditions used, the same conditions used to derive typ/min/max I-V tables. 4.5.5 {LEVEL 1} [Ramp] data dv and dt values positive The dV and dt values are greater than zero. Note that s2ibis2 will incorrectly generate negative [Ramp] values in the case where the [Ramp] simulation duration is much longer than the [Ramp] dt, leaving no waveform points that fall between the 20% and 80% voltage levels. The default test fixture for determining [Ramp] data has a 50 ohm resistor, tied to power for falling data and tied to ground for rising data. The initial and final values of the waveforms are used to define 20% and 80% voltage points, where [Ramp] measurements are made. These test fixtures may be similar to test fixtures used to produce [Rising Waveform] and [Falling Waveform] data, in which case the data can be checked for consistency. For example, a Rising Waveform with R_fixture = 50 and V_fixture = 0.0 should have a 20% to 80% dt that is similar to the [Ramp] dt_r value. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ ibischk v4.0.2 detects this: ERROR (line 1243) - dV must be greater than 0 in a Ramp specification +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.5.6 {LEVEL 1} [Ramp] dV consistent with supply voltages The [Ramp] dV values must not exceed 60% (80% - 20%) of: [Pullup Reference] - [Pulldown Reference] or [Voltage Range] +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if Ramp dV inconsistent with supply voltages. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.5.7 {LEVEL 1} [Ramp] dV consistent with V-T table endpoints Each [Ramp] dV value must match within a factor of two 60% (80% - 20%) of the difference between the initial and final voltages of the corresponding V-T table with test fixture matching the Ramp test fixture, if matching V-T tables are present. The [Ramp] dV values must not be less than half, nor greater than double, the calculated 60% of beginning-to-end voltage differences in the corresponding V-T tables. For Output, I/O, or 3-state models the V-T table that must be consistent with the dV values of [Ramp] dV/dt_r will be a [Rising Waveform] with R_fixture equal to the [Ramp] R_load subparameter (or 50 ohms if R_load is absent) and V_fixture equal to [Pulldown Reference] or 0V. The V-T table that must be consistent with the dV values of [Ramp] dV/dt_f will be a [Falling Waveform] with the same R_fixture, and V_fixture equal to [Pullup Reference] or [Voltage Range]. For Output_ECL, I/O_ECL, 3-state_ECL models the V-T table that must be consistent with the dV values of [Ramp] dV/dt_r will be a [Rising Waveform] with R_fixture equal to the [Ramp] R_load subparameter (or 50 ohms if R_load is absent) and V_fixture equal to ([Pullup Reference] or [Voltage Range]) minus 2V. The V-T table that must be consistent with the dV values of [Ramp] dV/dt_f will be a [Falling Waveform] with the same R_fixture and V_fixture. For Open_sink and Open_drain models the V-T table that must be consistent with the dV values of [Ramp] dV/dt_r will be a [Rising Waveform] with R_fixture equal to the [Ramp] R_load subparameter (or 50 ohms if R_load is absent) and V_fixture equal to [Pullup Reference] or [Voltage Range]. The V-T table that must be consistent with the dV values of [Ramp] dV/dt_f will be a [Falling Waveform] with the same R_fixture and V_fixture. For Open_source models the V-T table that must be consistent with the dV values of [Ramp] dV/dt_r will be a [Rising Waveform] with R_fixture equal to the [Ramp] R_load subparameter (or 50 ohms if R_load is absent) and V_fixture equal to [Pulldown Reference] or 0V. The V-T table that must be consistent with the dV values of [Ramp] dV/dt_f will be a [Falling Waveform] with the same R_fixture and V_fixture. When comparing V_Fixture against [Pullup Reference] or [Voltage Range] it is expected that the typ, min, and max values of [Voltage Range] will correspond to the V_fixture, V_fixture_min, and V_fixture_max values, respectively. This check is not to be performed using V-T tables with V_fixture or R_fixture not matching [Ramp] fixture values. Reasonably small values of C_fixture, L_fixture, R_dut, L_dut, and C_dut parameters in [Rising Waveform] and [Falling Wavform] can be overlooked in the V-T table selection process, although these may degrade the correlation of [Ramp] to V-T table endpoints. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if Ramp dV inconsistent with V-T table endpoints. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.5.8 {LEVEL 1} [Ramp] dt is consistent with 20%-80% crossing time Each dt value matches within a factor of two the difference between the times of crossing the 20% voltage point and the 80% voltage point on the corresponding [Rising Waveform] or [Falling Waveform] with test fixture most similar to the Ramp test fixture. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if Ramp dt inconsistent with V/T crossing time. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4.5.9 {LEVEL 1} [Ramp] dt is consistent with data sheet Each dt value matches within a factor of two the corresponding rise or fall time specified in the data sheet for a part pin using that buffer model. 5.0 Possible Errors =================== Here is a list of possible problems/errors that may be common. This list may be helpful in detecting correctness and completeness problems covered by the requirements of the previous sections. 5.1 {LEVEL 0} Typ/min/max order of parameters correct The parameters of different keywords for min typ max must be in the correct numerical order e.g. rpkg,cpkg,lpkg,ccomp, ( exception temp, which states only the conditions ) Ibis checks for numerical order, ( smallest value is in min column ) if the parameters are not in numerical order, please document why (doesn't apply to vI-Vt-tables ) 5.2 {LEVEL 1} C_comp checked in both input and output mode The values for c-comp must be checked for plausibility, usually each input/output/IO has different values. Sometime a compromise must be reached because c_comp input and C_comp output for optimal correlation. Model maker is encouraged to document in comments the basis for compromise i.e C_comp = |C_comp_off + |C_comp_on /2 |C_comp_off 4.0p 3.9p 4.1p |C_comp_on 1.0p 900.f 1.1p | C_comp 2.5p 2.4p 2.6p 5.3 {LEVEL 0} First/last point of waveforms equal to V_fixture values If the V_fixture values equal the power supply reference voltages for the [Pullup] or [Pulldown] tables, then the starting or ending points of the V-T tables are expected to equal these V_fixture values. For example for a 3.3 V device with the [Voltage Range] set to 3.3 V, V_fixture = 3.3 V, and R_fixture = 50 ohms, the [Rising Waveform] table should end at 3.3 V, and the [Falling Waveform] table should begin at 3.3 V. Exceptions to this check occur in cases where internal terminators or bias conditions exist such that the combined V-I tables have current flows at the V_fixture voltages. 5.4 {LEVEL 1} Sufficient points in waveform table The timestep in v-t-table should be about 1/10 of ramp-time ( the smaller of both rising and falling ; timestep: dv / 10 ), there should be at least 10 points in the transition regions ( start of transition and end of transition ) and the points don't have to be evenly spaced. ( many points in the transition region and fewer elsewhere ) This doesn't apply to waveforms from measurement. 5.5 {LEVEL 1} Minimize waveform lead-in time The v-t-tables must be referenced to a common input-stimulus-time See ibis 4 specification at the keywords [rising falling waveform] Be aware that lead-in-time is not the buffer delay. Excessive lead-in-time must be removed, but it must be the same amount of time for all waveforms Hint: The sum of risetime and falltime should be less than the expected minimum cycle time ( maximum cycle period ) If there are big lead-in-times, please explain why 5.6 {LEVEL 1} Open_sink/Open_source model with correct Vref, Cref, Rref, Vmeas The appropriate values of these 4 parameters are added referring to the min typ max conditions ( now possible in ibis4 ) The parameters for Vref,Rref are a further indication, that the model is an open-sink ( open-drain ) Be sure that Rref,Vref is appropriate to the model-type e.g. open-sink: Vref 3.3V ; Rref 500Ohm 5.7 {LEVEL 1} Differential models contain appropriate waveform tables Differential models like lvds, pecl, pcml must contain at least one rising and one falling v-t-table, and both the same termination voltage (same v-fixture ) There is a discussion, whether a waveform is always needed, but if there is a waveform supplied, the designer can decide, whether to use it or not. e.g. for LVDS ramp are outside of operating range ECL is an exception if the ramp is defined under appropriate conditions 5.8 {LEVEL 1} Models correspond to data sheet In the ibis-model file there are some models missing, which should be there corresponding to the data sheet. e.g. different driver strength, inputs with internal pullup either put them in a model selector and if there doesn't exist all models, please note in ibisfile with NC | No-model 5.9 {LEVEL 0} Model_type correct for model data Does the used model type belong to the parameters" e.g. Output with threshold parameters => suspected IO IO without threshold parameters => suspected output 5.11 {LEVEL 1} Open_sink/Open_source model not push-pull An open sink model must be modeled with a resistive load to vcc/vtt for both rising and falling. It is assumed for ramp that the 50 ohms is present and for both edges it goes to VCC. Be sure fixture voltage goes to reasonable voltage. Failure to do so will result in no rising wavforms, and unswitching waveforms. +++ IBISCHK NOTES +++++++++++++++++++++++++++++++++++++++++++++++++++++ Proposal: ibischk caution message if V-T table is flat. NOTE: does the ibischk endpoint check catch this? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 5.12 {LEVEL 1} All pins consistent with data sheet All pins must be listed. Pin names must match data sheet and/or appropriate design files. (Be careful of consistency of pins names A01 vs A1 and how tools will interpret this data). 6.0 Correlation {level 2} ========================= Please refer to "I/O Buffer Accuracy Handbook" http://www.eda.org/pub/ibis/accuracy/ The I/O Buffer Accuracy Handbook defines a quantitative method for correlating test hardware with simulation predictions and documenting the results of the correlation. The method is general and applicable to the two most common formats for I/O buffer model data: SPICE and IBIS. Its foundation is a set of "golden waveforms" derived from SPICE simulations of the I/O buffer under various test conditions defined by the I/O Buffer Accuracy handbook. If the simulations reflect test conditions and the modeling engineer has some knowledge of semiconductor processing conditions, it is possible to correlate the golden waveforms with lab data, both graphically and quantitatively. 6.1 SPICE Correlation 6.1.1 Purpose of SPICE Correlation IBIS quality level 2 specifies that the model developer must simulate identical test loads in SPICE and in a IBIS . The intention of SPICE correlation is to assess the degree to which the IBIS model data and the behavioral model internal to the behavioral simulator agree with the I/O circuit model extracted from a schematic or physical layout and simulated in SPICE. By careful attention to detail and understanding the behavior of the I/O circuit, it is possible to achieve extremely close correlation between SPICE and IBIS simulation results. Be aware that not all behavioral simulators are created equal; discrepancies may be an artifact of the behavioral simulator rather than the IBIS model extraction process. 6.1.2 SPICE Correlation overview The best recipe for success in SPICE correlation is a healthy sense of curiosity. How does the circuit work" What circuit elements are necessary and sufficient to model the behavior of the circuit" What test loads might stress the accuracy of the behavioral model" How will the circuit be used" Take the time to answer these questions before beginning the exercise. Neither the SPICE nor the IBIS simulations should include the package model at least in the first attempt at correlation. This simplifies the correlation process and makes it easier to identify discrepancies. IBIS deals primarily with I/O circuit behavior; its package model features are relatively simple and should produce the same effects in behavioral simulation as in SPICE. 6.1.3 Correlation process Correlation process is to make a quantitative comparison between behavioral simulation results and lab data. Section X.X.X defines the correlation process for IV curves and transient waveforms. It also describes how to compare data from capacitance and edge rate measurements. There are in general two different kinds of correlation: lab measurement vs. SPICE simulation and IBIS simulation vs. SPICE simulation. One of the three correlation levels defined in this section applies only to lab measurement vs. SPICE simulation correlation. The other two correlation levels apply to both types of correlation. In the case of the IBIS model, correlation is a two-step procedure. In the first step, the semiconductor vendor correlates lab data against SPICE-based golden waveforms that are embedded in the IBIS datasheet in the form of voltage-time tables. In the second step, the user correlates behavioral simulation results against the same golden waveforms using his or her simulator of choice. This approach effectively decouples the behavioral simulator from the hardware and splits the correlation problem into independent components. However, we still recommend that the semiconductor vendor run behavioral simulations using the IBIS datasheet for one behavioral simulator. This will enable the modeling engineer to fine-tune the model data and ferret out possible discrepancies that would go otherwise unnoticed. 6.1.4 Correlation Levels Model users have accuracy needs that vary with the demands imposed by their designs. For this reason, the I/O Buffer Accuracy Handbook defines several "correlation levels." A correlation level is a means for categorizing model data by the amount of effort the modeling engineer invests in verifying their accuracy. Each individual correlation level is defined on the basis of how much the modeling engineer knows about the semiconductor processing conditions of the sample component(s). For the purposes of the handbook, a metric is simply a numerical method for quantifying how well two sets of data points agree with each other. Level Component Sample Envelope Metric Overlay Metric 1 Random YES NO 2 Known typical YES YES 3 Known typical fast, slow YES YES Correlation Level 1 applies in the case that the modeling engineer knows nothing about the processing conditions of the DUT. In other words, the DUT is a random sample. The Curve Overlay Metric only applies in cases where the two curves should theoretically lie on top of one another. Therefore, the Curve Envelope Metric is the only valid metric in this case. The Envelope Metric is not useful in all waveforms or IV curves. Correlation Level 1 provides the least accuracy information. It is relevant to correlation of golden waveforms to lab measurements only. Correlation Level 2 applies in the case that the modeling engineer has a sample component that is known to come from a lot with typical semiconductor device parameters. The Envelope Metric applies in all Correlation Levels, but the Overlay Metric provides more accuracy information. Correlation Level 2 is relevant to correlation of golden waveforms to lab measurements and behavioral simulations. Correlation Level 3 applies in the case that the modeling engineer has three sample components: one from a lot with known typical semiconductor device parameters, one from a fast lot, and one from a slow lot. As in the previous two Correlation Levels, the Envelope Metric applies. Correlation Level 3 insures the highest degree of accuracy as well as confidence that the semiconductor vendor can indeed control the process in a manner consistent with the model data. This allows the model user to have confidence in the timing and noise margins of the system he or she is designing. Correlation Level C is relevant to correlation of golden waveforms to lab measurements and behavioral simulations. 6.1.5 Figures of Merit (FOM) 6.1.5.1 The Curve Overlay Metric (FOM1) The Curve Overlay Metric applies to cases in which the measured and simulated data should theoretically lie directly on top of each other. For example, a SPICE simulation of a 50 Ohm load and a IBIS simulation of the same load should theoretically yield identical results. Another example is the measurement of a known-typical sample component and a structural simulation of the same network under identical process-voltage-temperature conditions. The Curve Overlay Metric measures how well the two curves or waveforms match each other by summing the absolute value of the x-axis (or y-axis) differences between the two data points, weighing the sum against the range of data points along that axis, and dividing by the number of data points. FOM1 = 100 * [1- (SUM |X(golden) - X(dut)| / X*N)] SUM from i = 1->N 6.1.5.2 The Curve Envelope Metric (FOM2) The Curve Envelope Metric applies to cases in which the measured data are, in theory, bounded by two curves (or waveforms) that represent process-voltage-temperature extremes. In general, this metric is useful when the processing conditions of the sample component are unknown. The Curve Overlay Metric returns a yes/no value depending on whether or not every one of the data points falls within the envelope boundaries defined by the min and max curves. The plot below demonstrates a lab pull-down curve (solid line) that is slightly stronger than the typical curve (middle dashed line) and lies well within the (outer dashed lines). The Curve Envelope Metric presents a difficulty in the case of unterminated transmission line loads. Because these waveforms overshoot normal logic levels and ring back, the min and max waveforms intersect each other and do not define an envelope. Therefore, the Curve Envelope Metric may not be applied to the Open Transmission Line load or the Transmission Line and Receiver load. 6.1.5.3 Figure of Merit Determination The user must determine what values for the three figures of merit are acceptable for a given application, but the model developer should have some general goals for these values because he or she cannot know the application before hand. Shoot for FOM1 (Curve Overlay) greater than or equal to 98%. Shoot for FOM2 (Curve Envelope) less than or equal to 10%. Include plot of overlay metric. Include plot of envelope metric. Include reference to ack (tools) . Include reference to trailer (example). 7.0 Model Limitations and Model Maker Notes: ================================================= 7.1 There are certain additional pieces of information that model makers should include as comments. This includes any known limitations the model For example, this may be a specific version of spice that supports an advanced feature utilized in the IBIS model (i.e. On Die Termination). 7.2 There are certain additional pieces of information that model makers may include as comments for the rising and falling waveforms. These are not essential (and not always available), but are nice to have. These items can be helpful to a user in assessing how the rise and fall waveforms were created. These apply only if the waveforms were generated by simulation. 7.2.1 Number of Internal Stages The number of internal pre-stages used in the simulation for rising and falling waveforms may be provided in a comment, if available. This information provides a clue as to the shape of the original simulated waveforms. Ordinarily, at least 3 stages are expected. 7.2.2 Stimulus Used The rise- and falltimes and the period of the input waveform are also helpful in interpreting the output rise and fall waveforms. Revision History ================ Rev 1.0 IQ_Specification.txt 03/31/04 - IBIS Quality Committee