Subject: DRAFT IBIS Rev 2.0, part 4

From: Derrick Duehren <[email-masked]>
Date: Wed, 25 May 94 00:30:21 PST

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 ------------------------------