Text item: Text_1
|==============================================================================
| Keyword: [End]
| Required: Yes
| Description: Defines the end of the .ibs file.
|------------------------------------------------------------------------------
[End]
|
|==============================================================================
|
| NOTES ON DATA DERIVATION METHOD
|
| This section explains how data values are derived. The intention is to
| avoid over-guardbanding which enables simulation results that are meaningful
| and useful. This intention is accomplished by having each silicon vendor base
| its data on typical process data, and then derate by voltage and temperature,
| and a proprietary "X%" factor. This methodology also has the nice feature
| that the data can be derived either from vendor-proprietary silicon models, or
| typical device measurement over temperature/voltage.
|
$| 1) V/I curves for CMOS devices:
$| typ = nominal voltage, nominal temp deg C, typical process
$| min = low voltage tol, max temp deg C, typical process, minus "X%"
$| max = hi voltage tol, min temp deg C, typical process, plus "X%"
$|
$| V/I curves for bipolar devices:
$| typ = nominal voltage, nominal temp deg C, typical process
$| min = low voltage tol, min temp deg C, typical process, minus "X%"
$| max = hi voltage tol, max temp deg C, typical process, plus "X%"
$|
$| Nominal, min, and max temperature are specified by the manufacturer
$| of the part. The default range is 50C nom, 0C min, and 100C max
$| temperatures.
$|
$| X% should be statistically determined by the silicon vendor based
$| on numerous fab lots, test chips, process controls, etc. The value
$| of X need not be published in the IBIS file, and may decrease over
$| time as data on the I/O buffers and silicon process increases.
$|
$| Temperatures are junction temperatures.
$|
| 2) Voltage Ranges:
| Points for each curve must span the voltages listed below:
|
| Curve Low Voltage High Voltage
| ----------- ----------- ------------
| [Pulldown] GND - POWER POWER + POWER
| [Pullup] GND - POWER POWER + POWER
| [GND Clamp] GND - POWER GND + POWER
| [POWER Clamp] POWER POWER + POWER
|
| For example, a device with a 5 V power supply voltage should be
| characterized between (0 - 5) = -5 V and (5 + 5) = 10 V; and a
| device with a 3.3 V power supply should be characterized between
| (0 - 3.3) = -3.3 V and (3.3 + 3.3) = 6.6 V for the pulldown curve.
$|
$| When tabulating output data for ECL type devices, the voltage points
$| must span the range of Vcc to Vcc - 2.2V. This range applies to both the
$| pullup and pulldown tables. Note that this range applies ONLY when
$| characterizing an ECL output.
$|
$| These voltage ranges must be spanned by the IBIS data. Data derived
$| from lab measurements may not be able to span these ranges as such and
$| so may need to be extrapolated to cover the full range. This data must
$| not be left for the simulator to provide.
|
| 3) Ramp Rates:
$| The following steps assume that the default load resistance of 50 ohms is
$| used. There may be devices that will not drive a load of only 50 ohms
$| into any useful level of dynamics. In these cases, use the manufacturer's
$| suggested (non-reactive) load and add the load sub parameter to the [Ramp]
$| specification.
$|
$| The ramp rate does not include package and parameters; it is the intrinsic
$| output stage rise and fall time only.
$|
$| The ramp rates (listed in AC characteristics below) should be derived
$| as follows:
$|
$| a. If starting with the silicon model, remove all packaging. If starting
$| with a packaged device, perform the measurements as outlined below then
$| use whatever techniques are appropriate to derive the actual, unloaded
$| rise and fall times.
$|
$| b. If: The Model_type is one of the following: Output, I/O, or
$| 3-state (not open or ECL types);
$| Then: Attach a 50 ohm resistor to GND to derive the rising edge
$| ramp. Attach a 50 ohm resistor to POWER to derive the
$| falling edge ramp.
$|
$| If: The Model_type is Output_ECL or I/O_ECL;
$| Then: Attach a 50 ohm resistor to the termination voltage
$| (Vterm = VCC - 2v). Use this load to derive both the
$ | rising and falling edges.
$|
$| If: The Model_type is either an open_sink type or open_drain type;
$| Then: Attach either a 50 ohm resistor or the vendor-suggested
$| termination resistance to either POWER or the vendor-
$| suggested termination voltage. Use this load to derive both
$| the rising and falling edges.
$|
$| If: The Model_type is an open_source type;
$| Then: Attach either a 50 ohm resistor or the vendor-suggested
$| termination resistance to either GND or the vendor-suggested
$| termination voltage. Use this load to derive both the rising
$| and falling edges.
$|
$| c. Due to the resistor, output swings will not make a full transition as
$| expected. However the pertinent data can still be collected as
$| follows:
$| 1) determine the 20% to 80% voltages of the 50 Ohm swing
$| 2) measure this voltage change as "dv"
$| 3) measure the amount of time required to make this swing "dt"
$| d. Post the value as a ratio "dv/dt". The simulation tool vendor
$| extrapolates this value to span the required voltage swing range in
$| the final model.
$|
$| e. Typ, Min, and Max must all be posted, and are derived at the same
$| extremes as the V/I curves, which are:
$|
$| Ramp rates for CMOS devices:
$| typ = nominal voltage, nominal temp deg C, typical process
$| min = low voltage tol, max temp deg C, typical process, minus "X%"
$| max = hi voltage tol, min temp deg C, typical process, plus "X%"
$|
$| Ramp rates for bipolar devices:
$| typ = nominal voltage, nominal temp deg C, typical process
$| min = low voltage tol, min temp deg C, typical process, minus "X%"
$| max = hi voltage tol, max temp deg C, typical process, plus "X%"
$|
$| where nominal, min, and max temp are specified by the manufacturer of
$| the part. The preferred range is 50C nom, 0C min, and 100C max
$| temperatures.
$|
$| Note that the derate factor, "Y%", may be different than that used
$| for the V/I curve data. This factor is similar to the X% factor
$| described above. As in the case of V/I curves, temperatures are
$| junction temperatures.
$|
$| f. During the IV measurements, the driving waveform should have a
$| rise/fall time fast enough to avoid thermal feedback. The specific
$| choice of sweep time is left to the modeling engineer.
$|
| It is expected that this data will be created from silicon vendor
| proprietary silicon-level models, and later correlated with actual device
| measurement.
|
$-----------------------------------cut here -----------------------------------
|==============================================================================
NOTES ON IBIS_CHK PROGRAM
(not to be left in the actual specification)
$The V/I table DATA SHOULD BE MONOTONIC to insure that most simulators provide
$stable simulations. Monotonic data is needed to insure that all data is
$single valued. MONOTONIC DATA IS NOT REQUIRED to provide a valid IBIS model.
$It is recognized that automated measurement equipment may be used to acquire
$this data and as such may include "noise" that causes the data to be non-
$monotonic. It is also recognized that some devices may be non-monotonic in
$certain regions. Therefore the IBIS specification allows non-monotonic data.
$Simulation tools should filter out non-monotonic data if such data causes
$instabilities in the simulation results. The IBIS_CHK program tests for non-
$monotonic data and provides a maximum of one note per V/I table if non-
$montonic data is found.
$
$ "NOTE: Line xxx of V/I table yyy for model zzz is non-monotonic!
$ Most simulators will filter this data to remove the non-monotonic data."
$
$ Where xxx is the line number in the IBIS file.
$ Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp.
$ Where zzz is the name of the model.
$
$***************************************************************************
$Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors.
$***************************************************************************
$For each of the following V/I tables: Pullup, Pulldown, POWER_clamp,
$GND_clamp
$
$ 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table.
$
$ 2) IF:The current in the TYPICAL column corresponding to Vmax is less than
$ the current in the TYPICAL column corresponding to Vmin than
$ the table is assumed to have decreasing current.
$ ELSE IF:The current in the TYPICAL column corresponding to Vmax
$ is greater than the current in the TYPICAL column corresponding to
$ Vmin than the table is assumed to have increasing current.
$ ELSE: The table is assumed to have equal current."
$
$ Note: This works for all cases of discontinuities unless the magnitude of
$ discontinuity is such that this model is in all probability
$ completely unrealistic.
$
$***************************************************************************
$Change 3- Add a header comment statement at the TOP of the IBIS_CHK program
$ to insure that new changes to the IBIS_CHK program do not break tests
$ that worked in old MAJOR versions. This approach makes the program
$ larger however it insures the parser always works the same on older
$ versions of IBIS. This approach uses more memory, but has the reward
$ of low maintaining costs. The IBIS_CHK program is very small and
$ would not be effected by this until many revisions have occurred.
$***************************************************************************
$NOTICE TO ANY PERSON MODIFING THIS PROGRAM!
$-------------------------------------------
$This program SHALL NOT BE MODIFIED unless there is an associated IBIS Buffer
$Issue Resolution Document (BIRD). Said BIRD shall be agreed upon by IBIS
$committee vote. Only the currently elected IBIS_CHK 'czar and programmer' is
$allowed to modify the source code. The present CZAR is Jon Powell (April
$1994). The IBIS committee may also hire programmers from time to time to make
$major changes to the source code.
$
$Note: Source licensees are free to modify their own copies of this source
$code in any way they choose. Source licensees shall not redistribute
$the source code modified or otherwise. Source licensing is available from the
$IBIS open forum. The IBIS open forum is non-profit.
$
$The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED
$when adding code for the next version of the IBIS specification. Instead
$completely new code for all functions and features shall be created. This
$may require duplication of numerous functions.
$
$Each function shall be preceded by VXX_ where XX is the MAJOR version
$of the IBIS specification which is being parsed and tested. A MAJOR version
$would for example be 1.x going to 2.x. A MINOR version would for example be
$1.1 to 1.2. Functions using the above syntax would look as follows:
$V01_GetValue
$
$MINOR revisions DO NOT required new code.
$
$Startup code shall be provided at the top of the program that reads the
$version number from the IBIS file and runs the portion of the program
$corresponding to that MAJOR version. Code that is used only by the program
$startup function is not duplicated.
$
$-----------------------------------cut here ----------------------------------
$|=============================================================================
$| PACKAGE MODELING
$| The [Package_Model] keyword is used within a [Component] to indicate
$| which package model should be used for that part.
$|
$| The resolved specification permits .ibs files to contain [Define
$| Package Model] keywords as well. These are described in
$| "SYNTAX FOR THE .PKG FILE", below. When package model definitions
$| occur within a .ibs file, their scope is "local"--they are known only
$| within that .ibs file and no other. In addition, within that .ibs file,
$| they override any globally defined package models that have the same
$| name.
$|
$|==============================================================================
$| Keyword: [Package Model] Package_Model_Name
$| Required: No
$| Description: Indicates the name of the package model
$| Usage Rules: The Package_Model_Name is limited to 40 characters.
$| Spaces are allowed in the name. The name should include the
$| company name or initials to help ensure uniqueness. If the
$| package model is in a separate .pkg file, it must be kept in
$| the same directory as the .ibs file.
$| Other Notes: Use the [Package_Model] keyword within a [Component] to
$| indicate which package model should be used for that part.
$| The specification permits .ibs files to contain [Define
$| Package Model] keywords as well. These are described
$| in the "package modeling" section below. When package model
$| definitions occur within an .ibs file, their scope is
$| "local"--they are known only within that .ibs file and no
$| other. In addition, within that .ibs file, they override any
$| globally defined package models that have the same name.
$|
$| SYNTAX FOR THE .PKG FILE
$|
$| Package models are stored in a file whose name looks like <filename>.pkg.
$|
$| The <filename> provided must adhere to MS-DOS file name conventions: it must
$| not exceed 8 characters in length. All of these characters must be lower
$| case. The extension ".pkg" is used to identify files containing package
$| models.
$|
$| The .pkg file must contain all of the Required elements of a normal .ibs
$| file, including [IBIS Ver], [File Name], [File Rev], and the [End] keywords.
$|
$| Optional elements include the [Date], [Source], [Notes], [Disclaimer],
$| and [Comment char] keywords.
$|
$| All of the above elements follow the exact same rules as those for a normal
$| .ibs file.
$|
$| The [Component] and [Model] keywords are FORBIDDEN in the .pkg file. The
$| .pkg file is only for package models.
$|
$|==============================================================================
$| Keyword: [Define Package Model]
$| Required: Yes
$| Description: Mark the beginning of a package model description.
$| Usage Rules: If the .pkg file contains data for more than one package,
$| each section must begin with a new [Define Package Model]
$| keyword. The length of the Package_Model_Name must not
$| exceed 40 characters in length and blank characters are
$| allowed.
$|------------------------------------------------------------------------------
$[Define Package Model] Package_Model_Name
$|==============================================================================
$|
$|==============================================================================
$| Keyword: [Manufacturer]
$| Required: Yes
$| Description: Declares the manufacturer of the part(s) that use this package
$| model.
$| Usage Rules: The length of the Manufacturer's name must not exceed 40
$| characters (blank characters are allowed, e.g., Texas
$| Instruments). In addition, each manufacturer must use a
$| consistent name in all .ibs files.
$|------------------------------------------------------------------------------
$[Manufacturer] Manufacturer's Name | e.g., Intel Corp.
$|
$|==============================================================================
$| Keyword: [OEM]
$| Required: Yes
$| Description: Declares the manufacturer of the package.
$| Usage Rules: The length of the Manufacturer's name must not exceed 40
$| characters (blank characters are allowed, e.g., Texas
$| Instruments). In addition, each manufacturer must use a
$| consistent name in all .ibs files.
$| Other Notes: This keyword is useful if the semiconductor vendor sells a
$| single IC in packages from different manufacturers (e.g. AMP,
$| Kyocera).
$|------------------------------------------------------------------------------
$[OEM] Pkgs_R_Us Inc.
$|==============================================================================
$|
$
$The [Description] keyword is used to indicate to a human being what
$the model is describing.
$|
$|==============================================================================
$| Keyword: [Description]
$| Required: Yes
$| Description: Provides a concise yet easily human-readable description of
$| what kind of package the [Package_Model] is representing.
$| Usage Rules: The description must be less than 60 characters in length,
$| must fit on a single line, and may contain spaces.
$|------------------------------------------------------------------------------
$[Description] 220-Pin Quad Ceramic Flat Pack
$|
$|==============================================================================
$| Keyword: [Number of Pins]
$| Required: Yes
$| Description: Tells the parser how many pins to expect.
$| Usage Rules: The value must be a positive integer less than 60
$| characters long.
$|------------------------------------------------------------------------------
$[Number of Pins] 128
$|
$|==============================================================================
$| Keyword: [Pin Names]
$| Required: Yes
$| Description: Tells the parser the set of names that are used for the package
$| pins, and to defines an ordering of them. The first pin name
$| given is the "lowest" pin, and the last pin given is the
$| "highest." The pin names can not exceed 5 characters in
$| length.
$| Usage Rules: Following the [Pin Names] field, the names of the pins are
$| listed. There must be as many names listed as there are
$| pins (as given by the preceding [Number of Pins].)
$|------------------------------------------------------------------------------
$[Pin Names]
$A1
$A2
$| .
$| .
$| .
$A22
$B1
$| .
$| .
$| .
$| etc.
$|
$|==============================================================================
$| Keyword: [Model Data]
$| Required: Yes
$| Description: Indicates the beginning of the formatted model data.
$|------------------------------------------------------------------------------
$[Model Data]
$|
------------------------------ end of part 4 ------------------------------
Received on Wed May 25 00:33:36 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT