[ibis-quality] AW: renumbering iq-document.txt and iq-checklist.xls
- From: "Lenski, Eckhard" <eckhard.lenski@xxxxxxxxxxx>
- To: <ibis-quality@xxxxxxxxxxxxx>
- Date: Fri, 17 Mar 2006 14:10:26 +0100
Hello all,
I took the latest documents from the ibis wip-page and changed the files.
Please have a look at them.
Inside the files I have description what I changed
Regards
Eckhard
Mit freundlichen Grüßen / Best regards
Eckhard Lenski
Siemens AG
Communications / CAE libraries and models
Com MN PG R H B 8
Hofmannstr. 51
81359 München
Germany
Tel: +49 (89) 722 27776
Fax: +49 (89) 722 26879
mailto: eckhard.lenski@xxxxxxxxxxx
________________________________
Von: ibis-quality-bounce@xxxxxxxxxxxxx
[mailto:ibis-quality-bounce@xxxxxxxxxxxxx] Im Auftrag von Lenski, Eckhard
Gesendet: Donnerstag, 9. Februar 2006 14:09
An: ibis-quality@xxxxxxxxxxxxx
Betreff: [ibis-quality] renumbering iq-document.txt and iq-checklist.xls
Hello all,
when I last time used the checklist to check incoming models I found some
mismatches:
1) in the document: iq-document.txt
here it seems that the point 4.4.1 is missing
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 point 4.4.1 is missing ( as it is also missing in the excel-sheet for
models )
|IQ 4.3.17 LEVEL 2 Correlate IV curves to combined
curves.
|IQ 4.4.2 LEVEL 0 V-T table endpoints consistent with
I-V tables
|IQ 4.4.3 LEVEL 1 V-T tables look reasonable
|IQ 4.4.4 LEVEL 1 Model simulation successful
|IQ 4.4.5 LEVEL 1 Document known model limitations
|IQ 4.4.6 LEVEL 1 Output and IO buffers have should have
2 sets of V-T tables
|IQ 4.5.1 LEVEL 0 Output and IO buffers have a [Ramp]
section
so I think we must renumber section 4.4
2) in the iq-checklist ecxel sheet:
there still exists the point
5,1 inconsistency of waveform table
|IQ 5,8 LEVEL 1 Fewer models than in data sheet
|IQ 5,9 LEVEL 0 Wrong model type
|IQ 5,1 LEVEL 0 Inconsistency of waveform table
|IQ 5,11 LEVEL 1 Open-sink model modeled/measured as
push-pull
in the document iq-document.txt this point no longer exists, so there will
also be a renumbering necessary.
( may be we make an action item in the next telefon-conference and I will do
the changes )
regards
Eckhard
Mit freundlichen Grüßen / Best regards
Eckhard Lenski
Siemens AG
Communications / CAE libraries and models
Com SC SL CE23
Hofmannstr. 51
81359 München
Germany
Tel: +49 (89) 722 27776
Fax: +49 (89) 722 26879
mailto: eckhard.lenski@xxxxxxxxxxx
=========================================
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.1.3 Level 2a requirements
Level 2a includes all items in level 1, plus simulation correlation:
- Spice Correlation.
- Cross reference IBIS Accuracy figure of merit (FOM).
1.1.4 Level 2b requirements
Level 2b includes all items in level 1, plus laboratory correlation:
- Lab Correlation.
- Cross reference IBIS Accuracy figure of merit (FOM).
1.1.5 Level 3 requirements
Level 3 is levels 2a and 2b combined; all items in level 1, plus:
- Spice Correlation.
- 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.
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.
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.
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.
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.
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
IBIS version 3.x, 40 characters for 4.x
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.
3.2.4 {OPTIONAL} [Pin] RLC complete
RLC is optional on pins. If not defined either leave blank or use
NA NA NA
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.
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.
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.
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
4.1.3 {LEVEL 0} [Model] C_comp is reasonable
C_comp must be defined, positive and less than 20pF.
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).
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.
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.
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-.
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.
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.
4.2.11 {LEVEL 1} [Model Spec] Pulse_low less than Vinl
Pulse_low is less than Vinl.
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.
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.
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.
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.
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]
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.
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.
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.
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.
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.
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.
NOTE: Simulation Tools will extrapolate Power and ground clamps that
do not meet at a break point. It is permitted to extend sweep range
to avoid extrapolation problems.
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.
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).
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.
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
1 uA in the normal operating ranges (typically from 0 to 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.
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
4.4.1 {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).
**4.4.3 {LEVEL 1} V-T tables look reasonable
4.4.2 {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
4.4.3 {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
4.4.4 {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
4.4.5 {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
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.
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.
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]
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.
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.
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
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
5.10 {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.
**5.12 {LEVEL 1} All pins consistent with data sheet
5.11 {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
rev 1.01 16mar06 lenski
deleted lines marked with **
point 3.2.2 changed 30 characters to 40 characters
point 4.3.12 changed 0 to 2 vcc to 0 to vcc
point 5.9 changed 'linefeed'
section 4.4 renumbering as 4.4.1 was missing
section 5 renumbering as 5.10 was missing
Other related posts:
- » [ibis-quality] AW: renumbering iq-document.txt and iq-checklist.xls
