IBIS BIRDS ROLLUP

From: Bob Ross <bob@icx.com>
Date: Tue May 17 1994 - 08:22:38 PDT

To IBIS Editing Committee Members:

This is a complete rollup of all of the approved and pending BIRDS into one
document prior to editing committee work with the exception of BIRD10.1 which
is complete in itself.

This document has been produced mostly through "cut and paste", with some
minor corrections, but without concern about formatting and consistency details.

The intent is to capture the approved changes and show WHERE they apply. This
should serve as a reminder to all of us of what has been done so far, and should
be useful to the newer members when they hear references to work already done.

Bob Ross, Interconnectix, Inc.

|******************************************************************************
|* ENHANCED VERSION OF IBIS VERSION 1.1 DESIGNATED "VERSION 1.1Z" SHOWING
|* APPROVED "BIRDS" (BIRD = BUFFER ISSUE RESOLUTION DOCUMENT).
|*
|* CHANGES FOR ADDITIONS AND REPLACEMENT DESIGNATED BY "|*" SECTIONS PLUS
|* NOTES ON BIRDS AT END.
|*
|* BIRDS INCLUDED IN VERSION 1.1X ARE BIRD3, BIRD4, BIRD5.2, BIRD6.2, BIRD7.2.
|* FEBRUARY 20, 1994.
|*
|* BIRDS INCLUDED IN VERSION 1.1Y ARE BIRD2.2, BIRD9.3, BIRD11.2 AND REFERENCE
|* TO BIRD10.1, MAY 6, 1994
|*
|* BIRDS INCLUDED IN VERSION 1.1Z ARE BIRD8.2 AND BIRD12.2, MAY 13, 1994
|*
|# ALSO INCLUDED ARE THE LATEST VERSIONS OF PENDING BIRDS DESIGNATED BY "|#"
|# SO THAT THIS DOCUMENT CAN BE USED DURING THE EDITING COMMITTEE MEETING
|# AND DURING THE IBIS FORUM DISCUSSION. PENDING BIRDS INCLUDE BIRD13.2,
|# BIRD14, BIRD15, AND BIRD5.4. THE VERSION FOR PEMDING BIRDS IS DENOTED
|# VERSION 2.0 - MAY 15, 1994. THIS WILL BE UPDATED DAILY UNTIL THE EDITING
|# COMMITTEE MEETS.
|******************************************************************************
|==============================================================================|
| |
| Statement of Intent: |
| |
| In order to enable an industry standard method to electronically transport |
| IBIS Modeling Data between silicon vendors, simulation software vendors, and |
| end customers, this template is proposed. The intention of this template is |
| to specify a consistent format that can be parsed by software, allowing each |
| simulation vendor to derive models compatible with their own product. |
| |
| One goal of this template is to represent the current state of IBIS data, |
| while allowing a growth path to more complex models / methods (when deemed |
| appropriate). This would be accomplished by a revision of the base |
| template, and possibly the addition of new keywords or categories. |
| |
| Another goal of this template is to ensure that it is simple enough for |
| silicon vendors and customers to use and modify, while ensuring that it is |
| rigid enough for software simulation vendors to write reliable parsers. |
| |
| Finally, this template is meant to contain a complete description of the I/O |
| elements on an entire component. Consequently, several models will need to |
| be defined in each file, as well as a table that equates the appropriate |
| buffer to the correct pin and signal name. |
| |
| Version 1.1 of this electronic template was finalized by an industry-wide |
| group of simulation experts representing various companies and interests. |
| "IBIS Open Forum" meetings were held biweekly to accomplish this task. |
| |
| Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS |
| ASCII file format. It represents the minimum amount of I/O buffer |
| information required to create an accurate IBIS model of common CMOS and |
| bipolar I/O structures. Future revisions of the ASCII file will add items |
| considered to be "enhancements" to Version 1.0 to allow accurate modeling |
| of new, or other, I/O buffer structures. Consequently, all future |
| revisions will be considered super sets of Version 1.0, allowing backward |
| compatibility. In addition, as modeling platforms develop support for |
| revisions of the IBIS ASCII template, all previous revisions of the |
| template must also be supported. |
| |
| Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as |
| the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various |
| comments have been added for further clarification. |
| |
|==============================================================================|
| |
| General syntax rules and guidelines: |
| |
| 1) The content of the IBIS_ASCII file is case sensitive, except for file |
| names, reserved words and keywords. Reserved words and keywords are not |
| case sensitive, and file names must be all lower case. |
| |
| 2) The following words are reserved words and must not be used for |
| any other purposes in the document: |
| POWER - reserved model name, used with power supply pins, |
| GND - reserved model name, used with ground pins, |
| NC - reserved model name, used with no connect pins, |
| NA - used where data not available. |
| |
| 3) File names used in the IBIS_ASCII file must only have lower case |
| characters to enhance UNIX compatibility and must conform to DOS rules. |
| (The length of a file name should not exceed eight plus three characters |
| and it must not contain special characters which are illegal in DOS). |
| |
| 4) The IBIS_ASCII file must have no more than 80 characters per line. |
| |
| 5) Anything following the comment character is ignored and considered a |
| comment on that line. The default "|" (pipe) character can be changed by |
| the keyword [Comment char] to any other character. The [Comment char] |
| keyword can be used throughout the file as desired. |
| |
| 6) Keywords must be enclosed in square brackets, [], and must start in |
| column 1 of the line. |
| |
| 7) Valid scaling factors are: |
| M = mega, k = kilo, m = milli, u = micro, n = nano, p = pico. |
| When no scaling factors are specified, the appropriate base units are |
| assumed. (These are Volts, Amperes, Ohms, Farads and Henries). The parser |
| will look at only one alphabetic character after a numerical entry, |
| therefore it is enough to use only the prefixes to scale the parameters. |
| However, for clarity, it is allowed to use full abbreviations for the |
| units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS |
| allowed (e.g., 1.2345e-12). |
| |
| 8) The V/I data tables should use enough data points around sharply curved |
| areas of the V/I curves to describe the curvature accurately. In linear |
| regions there is no need to define unnecessary data points. |
| |
| 9) Currents are considered positive when their direction is into the |
| component. |
| |
|==============================================================================|
| Keyword: [IBIS Ver] |
| Required: Yes |
| Description: Used to specify the IBIS ASCII template version. This will be |
| used to inform an electronic parser of the kinds of data types |
| that will be present in the file. |
| Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is |
| normally on the first line of the file, but can be preceded |
| by comment lines (that must begin with a "|"). |
|------------------------------------------------------------------------------|
[IBIS Ver] 1.1 | Used for template variations
|==============================================================================|
| Keyword: [Comment char] |
| Required: Optional |
| Description: Used to define a new comment character to replace the default |
| "|" (pipe), if desired. |
| Usage Rules: The new comment character which is to be defined must be |
| followed by the underscore character and the letters "char". |
| For example: "|_char" redundantly redefines the comment |
| character to be the pipe character. The new comment character |
| will be in effect only following the [Comment char] keyword. |
| The following characters can NOT be used: A B C D E F G H I J |
| K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o |
| p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = |
| Other Notes: The [Comment char] keyword can be used throughout the file, as |
| desired. |
|------------------------------------------------------------------------------|
[Comment char] |_char
|==============================================================================|
| Keyword: [File name] |
| Required: Yes |
| Description: Used to specify the name of the IBIS file, "filename.ibs". |
| Usage Rules: The file name must comply with normal DOS rules (8 char. max. |
| and no characters that are illegal in DOS). In addition, it |
| must be all lower case, and use the extension ".ibs". |
|------------------------------------------------------------------------------|
[File name] ver1_1.ibs
|==============================================================================|
| Keyword: [File Rev] |
| Required: Yes |
| Description: Used to track the revision level of a particular .ibs file. |
| Usage Rules: Revision level can be set at the discretion of the engineer |
| defining the file. 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 |
|------------------------------------------------------------------------------|
[File Rev] 1.0 | Used for .ibs file variations
|==============================================================================|
| Keywords: [Date] [Source] [Notes] [Disclaimer] |
| Required: Optional |
| Description: Optionally used for further file clarifications. |
| Usage Rules: The [Date] information is allowed to contain blanks, and be of |
| any format up to 40 characters. |
|------------------------------------------------------------------------------|
[Date] 04/19/93 | Latest file revision date
[Source] Put originator and source of information here. For example:
                From silicon level SPICE model at Intel,
                From lab measurement at IEI,
                Compiled from manufacturer's data book at Quad Design, etc...
[Notes] This section can be used for any special notes related
                to the file.
[Disclaimer] This information is for modeling purposes only, and
                is not guaranteed. | May vary by component
|==============================================================================|
| Keyword: [Component] |
| Required: Yes |
| Description: Used to mark the beginning of the IBIS description of the |
| integrated circuit named after the keyword. |
| Usage Rules: If the .ibs file contains data for more than one component, |
| each section must begin with a new [Component] keyword. The |
| length of the Component Name must not exceed 40 characters, |
| and blank characters are allowed. |
|------------------------------------------------------------------------------|
[Component] Component Name
|==============================================================================|
| Keyword: [Manufacturer] |
| Required: Yes |
| Description: Used to clarify the component's manufacturer. |
| 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
|==============================================================================|
| Keyword: [Package] |
| Required: Yes |
| Description: Used to define a range of values for the default packaging |
| resistance, inductance, and capacitance of the component pins. |
| Sub-Params: R_pkg, L_pkg, C_pkg |
| Usage Rules: Typical column must be specified. If data for the other |
| columns are not available, they must be noted with "NA". |
| Other Notes: If RLC parameters are available for individual pins, they can |
| be listed in columns 4-6 under keyword [Pin]. The values |
| listed in the [Pin] description section override the default |
| values defined here. |
|------------------------------------------------------------------------------|
[Package]
| variable typ min max
R_pkg 250.0m 225.0m 275.0m
L_pkg 15.0nH 12.0nH 18.0nH
C_pkg 18.0pF 15.0pF 20.0pF
|==============================================================================|
| Keyword: [Pin] |
| Required: Yes |
| Description: Used to associate the component's I/O models to its various |
| external pins and signal names. |
| Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin |
| Usage Rules: All pins on a component must be specified. The first column |
| must contain the pin name. The second column, signal_name, |
| gives the data book name for the signal on that pin. The |
| third column, model_name, associates the I/O model for that |
| pin. Each model_name must have a [Model] keyword below, |
| unless it is a reserved model name (POWER, GND, or NC). |
| |
| Each line must contain either three or six columns. A pin |
| line with three columns only associates the pin's signal and |
| model. Six columns can be used to override the default |
| package values (specified under [Package]) FOR THAT PIN ONLY. |
| When using six columns, the headers R_pin, L_pin, and C_pin |
| must be listed. If "NA" is in columns 4 through 6, the |
| default packaging values must be used. |
| |
| Column length limits are: |
| [Pin] 5 characters max |
| model_name 20 characters max |
| signal_name 20 characters max |
| R_pin 9 characters max |
| L_pin 9 characters max |
| C_pin 9 characters max |
|------------------------------------------------------------------------------|
[Pin] signal_name model_name R_pin L_pin C_pin
|
  1 RAS0# Buffer1 200.0m 5.0nH 2.0pF
  2 RAS1# Buffer2 209.0m NA 2.5pF
  3 EN1# Input1 NA 6.3nH NA
  4 A0 3-state
  5 D0 I/O1
  6 RD# Input2 310.0m 3.0nH 2.0pF
  7 WR# Input2
  8 A1 I/O2
  9 D1 I/O2
 10 GND GND 297.0m 6.7nH 3.4pF
 11 RDY# Input2
 12 GND GND 270.0m 5.3nH 4.0pF
| .
| .
| .
 18 VCC3 POWER
 19 NC NC
 20 Vcc5 POWER 226.0m NA 1.0pF
|###############################################################################
|# PENDING BIRD14 ADDITION FOR VERSION 2.0
|#=============================================================================
|# Keyword: [SPECS]
|# Required: No
|#Description: Used to list pin-level specifications that differ from
|# the more global sub-params listed under [Model] below.
|# Sub-Params: Vinl, Vinh, Vt, Cref, C_comp
|#Usage Rules: Only pins that have values different from the default
|# values specified in [Model] sub-parameters should be
|# listed. Sub-parameters not used on a line must be
|# filled in with NA.
|# The [SPECS] section consists of five characters for a
|# pin number, six for Vinl, six for Vinh, five for Vt,
|# five for Cref, and six for each of the three
|# sub-parameters in C_comp. These three sub-parameters
|# represent the following: typ, min, and max. All
|# sub-parameters must be separated by at least one
|# blank space. This comes to a total of fifty-two
|# characters.
|#-----------------------------------------------------------------------------
[SPECS]
|# C_comp
Pin Vinl Vinh Vt Cref typ min max
1 0.8V 2.0V 1.5V 50pF 4.5pF 3.0pF 6.0pF
4 NA NA 2.5V 30pF NA NA NA
9 1.5V 3.5V NA NA NA NA NA
|###############################################################################
|*******************************************************************************
|* BIRD10.1 ADDITION FOR VERSION 1.1Y
|*==============================================================================
|* Keyword: [Package Model]
|* Required: No
|* Description: Used to indicate the name of the package model
|* Usage Rules: The Package_Model_Name is limited to 40 characters.
|* Spaces are allowed in the name.
|* Other Notes:
|* 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
|* "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 which have the same
|* name.
|*------------------------------------------------------------------------------
|*
[Package Model] Package_Model_Name
|*******************************************************************************
|*******************************************************************************
|* BIRD10.1 ADDITION FOR VERSION 1.1Y
|*==============================================================================
|* NOTE, KEYWORDS FOR [Define Package Model] through [End Model Data]
|* FOR EACH "Package_Model_Name" ARE CURRENTLY DEFINED IN BIRD10.1. THESE
|* PACKAGE MODELS MAY IN A SEPARATE FILE <package_file_name>.pkg ACCORDING
|* TO BIRD10.1. THE KEYWORDS MAY ALSO EXIST IN IBIS FILES <ibis_file_name>.ibs
|* WITHIN [Define Package Model] ... [End Model Data] BLOCKS FOR EACH
|* PACKAGE MODEL THAT IS DEFINED. FOR REFERENCE, THESE KEYWORDS THAT
|* MAY EXIST IN THE IBIS FILE ARE LISTED HERE. REFER TO BIRD10.1 FOR
|* THEIR FULL DESCRIPTION, SYNTAX AND USAGE.
|*
|* [Define Package Model]
|* [Manufacturer]
|* [OEM]
|* [Description]
|* [Number of Pins]
|* [Pin Names]
|* [Model Data]
|* [Resistance Matrix]
|* [Inductance Matrix]
|* [Capacitance Matrix]
|* [Row]
|* [Bandwidth]
|* [End Model Data]
|*==============================================================================
|*******************************************************************************
|*******************************************************************************
|* BIRD5.2 ADDITION FOR VERSION 1.1X
|*==========================================================================
|* Keyword: [Pin_Mapping]
|* Required: Optional
|*Description: Used to indicate which power and ground buses a given driver
|* or receiver is connected.
|* Sub-Params: gnd, pwr
|*Usage Rules: Each power and ground bus is given a unique name which must
|* not exceed 20 characters. The first column contains a pin
|* number. Each pin number must match one of the pin numbers
|* declared previously in the [Pin] section of the IBIS file.
|* The second column, "gnd", designates the ground bus connection
|* for that pin. Similarly, the third column, "pwr", designates
|* the power bus connection.
|*
|* If the [Pin_Mapping] keyword is present, then the bus
|* connections for EVERY pin listed in the [Pin] section must
|* be given.
|*
|* If a pin has no connection, then both the "pwr" and "gnd"
|* entries for it may by NC.
|*
|* Column length limits are:
|* [Pin_Mapping] 5 characters max
|* gnd 20 characters max
|* pwr 20 characters max
|*---------------------------------------------------------------------------
[Pin_Mapping] gnd pwr
1 GNDBUS1 PWRBUS1 | Signal pins and their associated
2 GNDBUS2 PWRBUS2 | ground and power connections
.....
.....
.....
11 GNDBUS1 NC | One set of ground connections.
12 GNDBUS1 NC | NC indicates no connection to
13 GNDBUS1 NC | power bus.
.....
21 GNDBUS2 NC | Second set of ground connections
22 GNDBUS2 NC
23 GNDBUS2 NC
.....
31 NC PWRBUS1 | One set of power connections.
32 NC PWRBUS1 | NC indicates no connection to
33 NC PWRBUS1 | ground bus.
.....
41 NC PWRBUS2 | second set of power connections
42 NC PWRBUS2
43 NC PWRBUS2
|*******************************************************************************
|###############################################################################
|# PENDING BIRD5.4 REPLACEMENT OF BIRD5.2 FOR VERSION 2.0
|#==========================================================================
|# Keyword: [Pin_Mapping]
|# Required: Optional
|#Description: Used to indicate which power and ground buses a given driver,
|# receiver, or terminator is connected.
|# Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref
|#Usage Rules: Each power and ground bus is given a unique name which must
|# not exceed 15 characters. The first column contains a pin
|# number. Each pin number must match one of the pin numbers
|# declared previously in the [Pin] section of the IBIS file.
|# The second column, "pulldown_ref", designates the ground bus
|# connections for that pin. Here the term "ground bus" can
|# also mean another "power bus". The third column "pullup_ref"
|# designates the power bus connection. The forth and fifth
|# columns "gnd_clamp_ref" and "power_clamp_ref" contain
|# entries, if needed, to specify different ground bus
|# and power bus connections than those previously specified.
|#
|# If the [Pin_Mapping] keyword is present, then the bus
|# connections for EVERY pin listed in the [Pin] section must
|# be given.
|#
|# Each line must contain either three or five columns. "NC"
|# is used for entries which are not needed or which follow
|# the conditions below:
|#
|# If a pin has no connection, then both the "pulldown_ref"
|# and "pullup_ref" entries for it will be NC.
|#
|# GND and POWER pin entries and buses are designated by
|# entries in either the "pulldown_ref" or "pullup_ref" columns.
|# There is no implied association to any column other than
|# through explicit designations in other pins.
|#
|# For any other type of pin, the "pulldown_ref" column contains
|# the power connection for the [Pulldown] table for non-ECL type
|# [Models]. This is also the power connection for the [GND_clamp]
|# table and the [Rgnd] model unless overriden by a specification
|# in the "gnd_clamp_ref" column.
|#
|# Also, the "pullup_ref" column contains the power connection
|# for the [Pullup] table and, for ECL type models, the [Pulldown]
|# table. This is also the power connection for the [POWER_clamp]
|# table and the [Rpower] model unless overriden by a specification
|# in the "power_clamp_ref" column.
|#
|# Column length limits are:
|# [Pin_Mapping] 5 characters max
|# pulldown_ref 15 characters max
|# pullup_ref 15 characters max
|# gnd_clamp_ref 15 characters max
|# power_clamp_ref 15 characters max
|#
|#---------------------------------------------------------------------------
[Pin_Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref
|#
1 GNDBUS1 PWRBUS1 | Signal pins and their associated
2 GNDBUS2 PWRBUS2 | ground and power connections
|#
3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP
4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP
5 GNDBUS2 PWRBUS2 NC PWRCLAMP
6 GNDBUS2 PWRBUS2 GNDCLMP NC
                                           | Some possible clamping connections
|# ..... | are shown above for illustration
|# ..... | purposes
|# .....
11 GNDBUS1 NC | One set of ground connnections.
12 GNDBUS1 NC | NC indicates no connection to
13 GNDBUS1 NC | power bus.
|# .....
21 GNDBUS2 NC | Second set of ground connections
22 GNDBUS2 NC
23 GNDBUS2 NC
|# .....
31 NC PWRBUS1 | One set of power connections.
32 NC PWRBUS1 | NC indicates no connection to
33 NC PWRBUS1 | ground bus.
|# .....
41 NC PWRBUS2 | Second set of power connections
42 NC PWRBUS2
43 NC PWRBUS2
|# .....
51 GNDCLMP NC | Additional power connections
52 NC PWRCLMP | for clamps
|###############################################################################
|******************************************************************************
|* BIRD6.2 ADDITION FOR VERSION 1.1X
|*==========================================================================
|* Keyword: [Diff_Pin]
|* Required: Optional
|*Description: Used to associate differential pins, their differential
|* threshold voltages and differential timing delays.
|* Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max
|*Usage Rules: Entries follow these rules: Only differential pin pairs
|* are entered. The [Diff_pin] column contains a non-inverting
|* pin number and the inv_pin column always contains the
|* corresponding inverting pin number for output and I/O output.
|* The vdiff column contains the specified differential threshold
|* voltage between pins if the pins are Input or I/O Model_types.
|* For Output only differential pins, the vdiff entry is 0V.
|* The tdelay columns contain launch delays of the non-inverting
|* pins relative to the inverting pins. The values can be either
|* polarity.
|*
|* BIRD2.2 Addition within BIRD6.2
|* If a pin is a differential input pin the differential input threshold
|* (vdiff) overrides and supercedes the need for Vinh and Vinl.
|*
|* If vdiff is not defined for a pin that is defined as requiring a Vinh by
|* its [Model] type, the parser will issue a warning and vdiff will be set to
|* the default value of 200mV.
|*
|*Other Notes: The output pin polarity specification in the table overrides
|* the [Model] Polarity specification such that the pin in the
|* [Diff_pin] column will be Non-Inverting and the pin in the
|* inv_pin column will be Inverting. This convention allows
|* one [Model] to be used for both pins.
|*
|* Column length limits are:
|* [Diff_Pin] 5 characters max
|* inv_pin 5 characters max
|* vdiff 9 characters max
|* tdelay_typ 9 characters max
|* tdelay_min 9 characters max
|* tdelay_max 9 characters max
|*
|* Each line must contain either four or six columns. If "NA" is
|* entered in the vdiff, tdelay_typ or tdelay_min columns, its
|* entry will be interpreted as 0V or 0ns. If "NA" appears in
|* the tdelay_max column, its value will be interpreted as the
|* tdelay_typ value. When using six columns, the headers
|* tdelay_min and tdelay_max must be listed. Entries for the
|* tdelay_min column are based on minimum magnitudes; and
|* tdelay_max column, maximum magnitudes. One entry of vdiff
|* regardless of its polarity is used for difference magnitudes.
|*---------------------------------------------------------------------------
[Diff_Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max
|*
 3 4 150mV -1ns 0ns -2ns | Input or I/O pair
 7 8 0V 1ns NA NA | Output* pin pair
 9 10 NA NA NA NA | Output* pin pair
16 15 200mV 1ns | Input or I/O pin pair
20 19 0V NA | Output* pin pair, tdelay = 0ns
22 21 NA NA | Output*, tdelay = 0ns
                                      | * Could be Input or I/O with vdiff = 0V
|******************************************************************************
|==============================================================================|
| Keyword: [Model] |
| Required: Yes |
| Description: Used to define a model, and its attributes. |
| Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp |
|###############################################################################
|# PENDING BIRD14 replacement of Sub-Params:
|# Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vt, Cref
|###############################################################################
|*
|* BIRD7.2 and 9.3 modifications
|* Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain,
|* Open_sink, I/O_open_sink, Open_source, I/O_open_source,
|* Input_ECL, Output_ECL, I/O_ECL and Terminator model must
|*
| begin with the keyword [Model]. The model_name must match |
| the one that is listed under the [Pin] keyword and must not |
| contain more than 20 characters. An .ibs file must contain |
| enough [Model] keywords to cover all of the model_names |
| specified under the [Pin] keyword, except for those |
| model_names which use reserved words (POWER, GND and NC). |
| Model_names with reserved words are an exception and |
| they do not have to have a corresponding [Model] keyword. |
| C_comp is allowed to use "NA" for the min and max values only. |
|*
|* BIRD2.2 addition
|* The model types Input, I/O, I/O_open_drain, I/O_open_sink,
|* I/O_open_soure must have Vinl and Vinh defined. If
|* they are not defined, the parser will issue a warning and the default
|* values of Vinl=.8V and Vinh=2.0V will be assumed.
|*
|* The model types Input_ECL and I/O_ECL must have Vinl and Vinh defined. If
|* they are not defined, the parser will issue a warning and the default
|* values of Vinl=-1.475V and Vinh=-1.165V will be assumed.
|*
|* BIRD9.3 change
|* Other Notes: A complete [Model] description normally contains the following
|* keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp],
|* [POWER_clamp], [Rgnd], [Rpower], [Rac], [Cac],
|* and [Ramp]. However, some models may have only
|* a subset these keywords. For example, an input structure
|* normally only needs the [Voltage range], [GND_clamp], and
|* possibly the [POWER_clamp] keywords. If one or more of
|* [Rgnd], [Rpower], [Rac] and [Cac] keywords are used, then
|* the Model_type must be Terminator.
|*
|* BIRD2.2 addition
|* A "Terminator" is an input only device that can have analog loading effects
|* on the circuit being simulated but has no digital logic thresholds.
|* Examples of "Terminators" are: Capacitors, Termination Diodes, Pullup
|* resistors etc.
|*
|* BIRD7.2 addition
|* Model_types with "open_sink" specify that the output has
|* an OPEN side (the [Pullup] keyword is not used or I = 0mA
|* for all voltages specified) AND the output SINKS current.
|* Model_types with "open_drain" have the identical meaning and
|* are retained for backward compatibility. Model_types with
|* "open_source" specify that the output has an OPEN side (the
|* [Pulldown keyword is not used or I = 0mA for all voltages
|* specified) AND the output SOURCES current. Model_types with
|* "_ECL" specify that the model represents and ECL type logic
|* which follows different conventions for the [Pulldown] keyword.
|*
| Note that C_comp defines the silicon die capacitance. This |
| value should not include the capacitance of the package. |
| |
|###############################################################################
|# PENDING BIRD14 addition
|# Component timings are usually specified into a
|# reference capacitance that can be listed as Cref. Vt is
|# the test voltage at a driver that timings are specified
|# to. (This is usually around the 50% level of the voltage
|# thresholds. For example, TTL=1.5V, CMOS=2.5V.)
|###############################################################################
|------------------------------------------------------------------------------|
[Model] model_name
|*
|* BIRD7.2 and BIRD9.3 modification
Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain,
                Open_sink, I/O_open_sink, Open_source, I/O_open_source,
                Input_ECL, Output_ECL, I/O_ECL, Terminator | List one only
|*
Polarity Non-Inverting, Inverting | List one only, if any
Enable Active-High, Active-Low | List one only, if any
| Signals RAS, CAS, A(0-64), D(0-128),... | Local list, if desired
Vinl = 0.8V | input logic "low" DC voltage, if any
Vinh = 2.0V | input logic "high" DC voltage, if any
|###############################################################################
|# PENDING BIRD14 addition
Vt=1.5V |Test voltage timings are specified to
Cref=50pF |Reference capacitance timings are specified into
|###############################################################################
| variable typ min max
C_comp 12.0pF 10.0pF 15.0pF
|==============================================================================|
| Keyword: [Voltage range] |
| Required: Yes |
| Description: Used to define the power supply voltage tolerance over which |
| the model is intended to operate. |
| Usage Rules: Actual voltages (not percentages) are to be presented in the |
| usual typ, min, max format. "NA" is allowed for the min and |
| values only. |
| Other Notes: [Voltage range] also describes the voltage range over which |
| the various V/I curves and ramp rates were derived. |
|------------------------------------------------------------------------------|
| variable typ min max
[Voltage range] 5.0V 4.5V 5.5V
|******************************************************************************
|* BIRD3 replacement of [Voltage range] text above for VERSION 1.1X
|*==========================================================================
|* Keyword: [Voltage range]
|* Required: Yes, if [Pullup reference], [Pulldown reference],
|* [Power_clamp reference], and [GND_clamp reference] are not
|* present
|*Description: Used to define the power supply voltage tolerance over which
|* the the model is intended to operate. It also specifies the
|* default voltage rail the pullup and POWER_clamp V/I data is
|* referenced to.
|*Usage Rules: Actual voltages (not percentages) are to be presented in the
|* usual typ, min, max format. "NA" is allowed for the min and
|* max values only.
|*---------------------------------------------------------------------------
|* variable typ min max
[Voltage range] 5.0v 4.5v 5.5v
|*===========================================================================
|* Keyword: [Pullup reference]
|* Required: Yes, if the [Voltage range] keyword is not present.
|*Description: Used to define a voltage rail other than that defined by
|* the [Voltage range] keyword as the reference voltage
|* for the pullup V/I data.
|*Usage Rules: Actual voltages (not percentages) are to be presented in the
|* usual typ, min, max format. "NA" is allowed for the min and
|* max values only.
|*Other Notes: This keyword, if present, also defines the voltage range over
|* which the min and max dV/dt_r values are derived.
|*---------------------------------------------------------------------------
|* variable typ min max
[Pullup reference] 5.0V 4.5V 5.5V
|*===========================================================================
|* Keyword: [Pulldown reference]
|* Required: Yes, if the [Voltage range] keyword is not present.
|*Description: Used to define a power supply rail other than 0v as the
|* reference voltage for the pulldown V/I data. If this keyword
|* is not present the voltage data points in the pulldown V/I table
|* are referenced to 0v.
|*Usage Rules: Actual voltages (not percentages) are to be presented in the
|* usual typ, min, max format. "NA" is allowed for the min and
|* max values only.
|*Other Notes: This keyword, if present, also defines the voltage range over
|* which the min and max dV/dt_f values are derived.
|*---------------------------------------------------------------------------
|* variable typ min max
[Pulldown reference] 0V 0V 0V
|* Keyword: [POWER_clamp reference]
|* Required: Yes, if the [Voltage range] keyword is not present.
|*Description: Used to define a voltage rail other than that defined by
|* the [Voltage range] keyword as the reference voltage
|* for the POWER_clamp V/I data.
|*Usage Rules: Actual voltages (not percentages) are to be presented in the
|* usual typ, min, max format. "NA" is allowed for the min and
|* max values only.
|*Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below.
|*---------------------------------------------------------------------------
|* variable typ min max
[POWER_clamp reference] 5.0V 4.5V 5.5V
|*===========================================================================
|* Keyword: [GND_clamp reference]
|* Required: Yes, if the [Voltage range] keyword is not present.
|*Description: Used to define a power supply rail other than 0v as the
|* reference voltage for the GND_clamp V/I data. If this keyword
|* is not present the voltage data points in the GND_clamp V/I table
|* are referenced to 0v.
|*Usage Rules: Actual voltages (not percentages) are to be presented in the
|* usual typ, min, max format. "NA" is allowed for the min and
|* max values only.
|*Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section below.
|*---------------------------------------------------------------------------
|* variable typ min max
[GND_clamp reference] 0V 0V 0V
|*============================================================================
|* NOTES ON SPECIFYING POWER SUPPLIES
|* It is the intention that standard TTL and CMOS devices be specified
|* using only the [Voltage range] keyword. However, in cases where
|* the output characteristics of a device depend on more than a single
|* supply and ground, or a pullup, pulldown or clamp structure is referenced
|* to something other than the default supplys, the additional 'reference'
|* keywords are to be used.
|* If the [Voltage range] keyword is not present then all four of the
|* other keywords must be present. If the [Voltage range] keyword is
|* present the other keywords are optional and may or may not be used as
|* required. It is legal (although redundant) for an optional keyword to
|* specify the same voltage as specified by the [Voltage range] keyword.
|******************************************************************************
|==============================================================================|
| Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] |
| Required: Yes, if they exist in the device |
| Description: The data points under these keywords define the V/I curves of |
| the pulldown and pullup structures of an output buffer and the |
| V/I curves of the clamping diodes connected to the GND and the |
| POWER pins, respectively. |
|*
|* BIRD11.2 Continuation of Previous Paragraph:
|* Currents are considered positive
|* when their direction is into the component.
|*
| Usage Rules: In each of these sections the first column contains the |
| voltage value, and the three remaining columns hold the |
| typical, minimum, and maximum current values. The four |
| entries, Voltage, I(typ), I(min), and I(max) must be placed on |
| a single line and must be separated by at least one white |
| space or tab character. |
| All four columns are required under these keywords, however |
| data is only required in the typical column. If minimum |
| and/or maximum current values are not available, the reserved |
| word "NA" must be used. "NA" can be used for currents in the |
| typical column, but numeric values MUST be specified for the |
| first and last voltage points on any V/I curve. Each V/I |
| curve must have at least 2, but not more than 100, voltage |
| points. |
| Other Notes: It should be noted that the V/I curve of the [Pullup] and the |
| [POWER_clamp] structures are 'Vcc relative', meaning that the |
| voltage values are referenced to the Vcc pin. The voltages in |
| the data tables are derived from the equation: |
| Vtable = Vcc - Voutput |
| Therefore, for a 5V component, -5 V in the table actually |
| means 5 V above Vcc, which is +10 V with respect to ground; |
| and 10 V means 10 V below Vcc, which is -5 V with respect to |
| ground. Vcc-relative data is necessary to model a pullup |
| structure properly, since the output current of a pullup |
| structure depends on the voltage between the output and Vcc |
| pins and not the voltage between the output and ground pins. |
| Note that the [GND_clamp] V/I curve can include quiescent |
| input currents, or the currents of a 3-stated output if so |
| desired. |
|******************************************************************************
|* BIRD4 ADDITION FOR VERSION 1.1X
|* When tabulating data for ECL devices, the data in the pulldown table
|* is measured with the output in the 'logic low' state. In other words,
|* the data in the table represents the V-I characteristics of the
|* output when the output is at the most negative of its two logic
|* levels. Likewise, the data in the pullup table is measured with the
|* output in the 'logic one' state and represents the V-I characteristics
|* when the output is at the most positive logic level. Note that in BOTH
|* these cases the data is referenced to the VCC supply voltage, using
|* the equation Vtable = Vcc - Voutput.
|******************************************************************************
|* BIRD8.2 ADDITION FOR VERSION 1.1Z
|* 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"
|* which causes the data to be non-monotonic. It is also
|* recognized
|* that some device 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.
|* To be monotonic the V/I table data must meet any one of the
|* following 8 criteria:
|* 1- The CURRENT axis either increases or remains constant as
|* the voltage axis is increased.
|* 2- The CURRENT axis either increases or remains constant as
|* the voltage axis is decreased.
|* 3- The CURRENT axis either decreases or remains constant as
|* the voltage axis is increased.
|* 4- The CURRENT axis either decreases or remains constant as
|* the voltage axis is decreased.
|*
|* 5- The VOLTAGE axis either increases or remains constant as
|* the current axis is increased.
|* 6- The VOLTAGE axis either increases or remains constant as
|* the current axis is decreased.
|* 7- The VOLTAGE axis either decreases or remains constant as
|* the current axis is increased.
|* 8- The VOLTAGE axis either decreases or remains constant as
|* the current axis is decreased.
|*
|* The IBIS_CHK program will test for non-monotonic data and
|* provide 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.
|*
|* It is also recognized that the some data may be monotonic if
|* currents from both the output stage and the clamp diode are
|* added together as most simulators do. To limit the complexity
|* of the version 2.0 IBIS_CHK program, it will consider only one
|* V/I table at a time monotonicity testing.
|*
|###############################################################################
|# PENDING BIRD15 addition
|# Assumptions: It is assumed that the simulator sums the clamp
|# curves together with the appropriate pullup or
|# pulldown curve when a buffer is driving high or low,
|# respectively. From this assumption and the nature
|# of 3-statable buffers it follows that the data in
|# the clamping curve sections are handled as
|# constantly present curves and the pullup and
|# pulldown curves are used only when needed in the
|# simulation.
|#
|# The clamp curves of an input or I/O buffer can be
|# measured directly with a curve tracer, the I/O
|# buffer being 3-stated. However, sweeping enabled
|# buffers results in curves that are the sum of the
|# clamping curves and the output structures. Based on
|# the assumption outlined above, the pullup and
|# pulldown curves of an IBIS model must represent the
|# difference of the 3-stated and the enabled buffer's
|# curves. (Note that the resulting difference curve
|# may demonstrate a non-monotonic shape). This allows
|# the simulator to sum the curves, without the danger
|# of double counting, and arrive at an accurate model
|# in both the 3-stated and enabled conditions.
|#
|# Since in the case of a non 3-statable buffer this
|# difference curve cannot be generated through lab
|# measurements (because the clamping curves can not be
|# measured alone), the pullup and pulldown curves of
|# an IBIS model may contain the sum of the clamping
|# characteristics and the output structure. In this
|# case the clamping curves must contain all zeroes, or
|# the keywords must be omitted.
|#
|###############################################################################
|******************************************************************************
|------------------------------------------------------------------------------|
[Pulldown]
| Voltage I(typ) I(min) I(max)
|
   -5.0V -40.0m -34.0m -45.0m
   -4.0V -39.0m -33.0m -43.0m
| .
| .
    0.0V 0.0m 0.0m 0.0m
| .
| .
    5.0V 40.0m 34.0m 45.0m
   10.0V 45.0m 40.0m 49.0m
|
[Pullup]
|
| Voltage I(typ) I(min) I(max)
|
   -5.0V 32.0m 30.0m 35.0m
   -4.0V 31.0m 29.0m 33.0m
| .
| .
    0.0V 0.0m 0.0m 0.0m
| .
| .
    5.0V -32.0m -30.0m -35.0m
   10.0V -38.0m -35.0m -40.0m
|
[GND_clamp]
|
| Voltage I(typ) I(min) I(max)
|
   -5.0V -3900.0m -3800.0m -4000.0m
   -0.7V -80.0m -75.0m -85.0m
   -0.6V -22.0m -20.0m -25.0m
   -0.5V -2.4m -2.0m -2.9m
   -0.4V 0.0m 0.0m 0.0m
    5.0V 0.0m 0.0m 0.0m
|
[POWER_clamp]
|
| Voltage I(typ) I(min) I(max)
|
   -5.0V 4450.0m NA NA
   -0.7V 95.0m NA NA
   -0.6V 23.0m NA NA
   -0.5V 2.4m NA NA
   -0.4V 0.0m NA NA
    0.0V 0.0m NA NA
|*******************************************************************************
|* BIRD9.3 ADDITION FOR VERSION 1.1Y
|*==========================================================================
|* Keywords: [Rgnd], [Rpower], [Rac], [Cac]
|* Required: Yes, if they exist in the device
|* Description: The data for these keywords define the resistance values of
|* Rgnd and Rpower connected to GND and the POWER pins,
|* respectively.
|* Usage Rules: For each of these sections the three columns hold the
|* typical, minimum, and maximum resistance values. The three
|* entries for R(typ), R(min), and R(max) or C(typ), C(min),
|* and C(max) must be placed on a single line and must be
|* separated by at least one white space or tab character.
|* All three columns are required under these keywords, however
|* data is only required in the typical column. If minimum
|* and/or maximum values are not available, the reserved word
|* "NA" must be used indicating the R(typ) or C(typ) value by
|* default.
|* Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and
|* [Rgnd] is connected to 'GND'. However, [GND_clamp reference]
|* voltages, if defined, apply to [Rgnd]. [POWER_clamp reference]
|* voltages, if defined, apply to [Rpower]. |* Either or both [Rgnd] and [Rpower] may be defined and may
|* co-exist with [GND_clamp] and [POWER_clamp] structures.
|* If an AC terminator is specified, then both [Rac] and [Cac]
|* are required.
|* When [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the
|* Model_type must be Terminator.
|*------------------------------------------------------------------------------
|* variable R(typ) R(min) R(max)
|*
[Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator
[Rpower] 220Ohm 200Ohm NA |
|*
[Rac] 30Ohm NA NA |
|*
|* variable C(typ) C(min) C(max) | AC terminator
|*
[Cac] 50pF NA NA |
|*******************************************************************************
|==============================================================================|
| Keyword: [Ramp] |
| Required: Yes, except for inputs |
| Description: Used to define the rise and fall times of a buffer. |
| Sub-Params: dV/dt_r, dV/dt_f |
| Usage Rules: These parameters describe an ideal slope and can be expressed |
| as a ratio of any reasonable voltage and time values as shown |
| in the examples. The [Ramp] values are allowed to use "NA" |
| for the min and max values only. |
|------------------------------------------------------------------------------|
[Ramp]
| variable typ min max
dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n
dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n
|###############################################################################
|# PENDING BIRD13.2 REPLACEMENT OF [Ramp] FOR VERSION 2.0
|#==============================================================================
|# Keyword: [Ramp]
|# Required: Yes, except for inputs
|# Description: Used to define the rise and fall times of a buffer.
|# Sub-Params: dV/dt_r, dV/dt_f, ramp
|# Usage Rules: These parameters describe an ideal slope and can be expressed
|# as a ratio of any reasonable voltage and time values as shown
|# in the examples. The [Ramp] values are allowed to use "NA"
|# for the min and max values only.
|# The load sub-parameter is optional if the preferred 50 ohm load is used.
|# It is required if a non-standard load is used.
|#------------------------------------------------------------------------------
[Ramp]
|# variable typ min max
dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n
dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n
load 300ohms
|###############################################################################
|*******************************************************************************
|* BIRD12.2 ADDITION FOR VERSION 1.1Z
|*==========================================================================
|* Keywords: [Rising waveform], [Falling waveform]
|* Required: No
|* Description: Used to describe the shape of the rising and falling edge
|* waveforms of a driver.
|* Sub-params: R_fixture, V_fixture, C_fixture, L_fixture,
|* R_dut, L_dut, C_dut
|* Usage Rules: Each [Rising waveform] and [Falling waveform] keyword
|* introduces a table of time vs. voltage points that
|* describe the shape of an output waveform. These
|* time/voltage points are taken under the conditions
|* specified in the R/L/C/V_fixture and R/L/C_dut
|* sub-parameters. The table itself consists of
|* one column of time points, then three columns of
|* voltage points in the standard typ, min and max format.
|* The four entries must be placed on a single line and
|* must be separated by at least one white space or tab
|* character. All four columns are required, however, data
|* is only required in the typical column. If minimum
|* or maximum data is not available the reserved word "NA"
|* is used. The first value in the time column does not
|* have to be '0'. Time values must increase as
|* one parses down the table. The waveform table may
|* contain a maximum of 100 data points. There is a
|* maximum of 100 waveform tables allowed per model.
|* Note that for backwards compatibility the existing
|* [Ramp] keyword is still required.
|*
|* A waveform table must include the entire waveform;
|* i.e., the first entry (or entries) in a voltage column
|* must be the DC voltage of the output before switching
|* and the last entry (or entries) of the column must be
|* the final DC value of the output after switching.
|*
|* A [Model] specification can contain more than one
|* rising edge or falling edge waveform table;
|* however, each new table must begin with the appropriate
|* keyword and sub-parameter list as shown below. If more
|* than one rising or falling edge waveform table is
|* present, then the data in each of the respective tables
|* must be time correlated. In other words, the rising
|* (falling) edge data in each of the rising (falling) edge
|* waveform tables must be entered with respect to a
|* common reference point on the input stimulus waveform.
|*
|* The 'fixture' sub-parameters specifies the loading
|* conditions under which the waveform is taken.
|* The R_dut, C_dut, and L_dut are analogous to the the
|* package parameters R_pkg, C_pkg and L_pkg and are used
|* if the waveform includes the effects of pin
|* inductance/capacitance. The diagram below shows the
|* interconnection of these elements.
|*
|* |
|* |
|* PACKAGE | TEST FIXTURE
|* _________ |
|* | DUT | L_dut R_dut | L_fixture R_fixture
|* | die |__@@@@@__/\ /\______|__@@@@_______/\ /\_____ V_fixture
|* | | \/ | | | \/
|* |_________| | | |
|* | | |
|* C_dut === | === C_fixture
|* | | |
|* | | |
|* gnd | gnd
|*
|* Only the R_fixture and V_fixture sub-parameters are
|* required, the rest of the sub-parameters are optional.
|* If a sub-parameter is not used its value defaults to
|* zero. The sub-parameters must appear in the text after
|* the keyword and before the first row of the waveform
|* table.
|*
|*------------------------------------------------------------------------------
[Rising waveform]
R_fixture = 500
V_fixture = 5.0
C_fixture = 50p
L_fixture = 2n
C_dut = 7p
R_dut = 1m
L_dut = 1n
|*Time V(typ) V(min) V(max)
 0.0ns 0.3 0.5 NA
 0.5ns 0.3 0.5 NA
 1.0ns 0.6 0.7 NA
 1.5ns 0.9 0.9 NA
 2.0ns 1.5 1.3 NA
 2.5ns 2.1 1.7 NA
 3.0ns 3.0 2.7 NA
 3.5ns 3.2 3.0 NA
|*
[Falling waveform]
R_fixture = 50
V_fixture = 0
|*Time V(typ) V(min) V(max)
 10.0ns 3.2 3.0 NA
 10.5ns 3.0 2.7 NA
 11.0ns 2.1 1.7 NA
 11.5ns 1.5 1.3 NA
 12.0ns 0.9 0.9 NA
 12.5ns 0.6 0.7 NA
 13.0ns 0.3 0.5 NA
 13.5ns 0.3 0.5 NA
|*******************************************************************************
|###############################################################################
|# PENDING BIRD13.2 ADDITION FOR VERSION 2.0
|#==============================================================================
|# Keyword: [Temperature range]
|# Required: Yes, if other than the preferred 0, 50, 100 degree C range
|# Description: Used to define the temperature range over which the model is
|# to operate.
|# Usage Rules: Actual temperatures (not percentages) are to be presented in
|# the usual typ, min, max format. "NA" is not allowed.
|# Other Notes: [Temperature range] also describes the temperature range over
|# which the various V/I curves and ramp rates were derived. Note
|# that these are die temperatures, not ambient temperatures.
|#------------------------------------------------------------------------------
|# variable typ min max
[Temperature range] 27.0C -50C 130.0C
|###############################################################################
|==============================================================================|
| Keyword: [End] |
| Required: Yes |
| Description: Used to define the end of the .ibs file. |
|------------------------------------------------------------------------------|
[End]
|==============================================================================|
| |
| NOTES ON DATA DERIVATION METHOD |
| |
| This section explains how data values are derived. The intention here is to |
| avoid over-guardbanding, enabling simulation results that are meaningful and |
| useful. This is accomplished by having each silicon vendor base their 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, 50 degrees C, typical process |
| min = low voltage tol, 100 degrees C, typical process, minus "X%" |
| max = hi voltage tol, 0 degrees C, typical process, plus "X%" |
| |
| V/I curves for bipolar devices: |
| typ = nominal voltage, 50 degrees C, typical process |
| min = low voltage tol, 0 degrees C, typical process, minus "X%" |
| max = hi voltage tol, 100 degrees C, typical process, plus "X%" |
| |
| where X% should be statistically determined by the silicon vendor |
| based on numerous fab lots, test chips, process controls, ... 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. |
| |
|###############################################################################
|# PENDING BIRD13.2 REPLACEMENT OF 1) FOR VERSION 2.0
|#
|# 1) V/I curves for CMOS devices:
|# typ = nominal voltage, nominal temperature deg C, typical process
|# min = low voltage tol, max temperature deg C, typical process, minus"X%"
|# max = hi voltage tol, min teperature deg C, typical process, plus "X%"
|#
|# V/I curves for bipolar devices:
|# typ = nominal voltage, nominal temperature deg C, typical process
|# min = low voltage tol, min temperature deg C, typical process, minus "X%"
|# max = hi voltage tol, max teperature deg C, typical process, plus "X%"
|#
|# where nominal, min, and max temperature are specified by the manufacturer of
|# the part. The preferred 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, ... 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. |
|
|******************************************************************************
|* BIRD4 ADDITION FOR VERSION 1.1X
|* 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.
|******************************************************************************
|###############################################################################
|# PENDING BIRD13.2 ADDITION FOR VERSION 2.0
|# 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 fullrange. This must not be left for the
|# simulator.
|###############################################################################
| |
| 3) Ramp Rates: |
| The ramp rates (listed in AC characteristics below) should be |
| derived by: |
| 1. Start with silicon model, remove all packaging. |
| 2. Attach 50 Ohm resistor to GND to derive rising edge ramp. |
| 3. Attach 50 Ohm resistor to POWER to derive falling edge ramp. |
| 4. Due to the resistor, output swings will not make a full |
| transition as expected. However the pertinent data can still |
| be collected as follows: |
| a) determine the 20% to 80% voltages of the 50 Ohm swing |
| b) measure this voltage change as "dv" |
| c) measure the amount of time required to make this swing "dt" |
| 5. Post the value as a ratio "dv/dt", the simulation tool vendor |
| will extrapolate this value to span the required voltage swing |
| range in the final model. |
| 6. Typ, Min, and Max must all be posted, and are derived at the |
| same extremes as the V/I curves, which are: |
| |
| Ramp times for CMOS devices: |
| typ = nominal voltage, 50 degrees C, typical process |
| min = low voltage tol, 100 degrees C, typical process, minus "Y%" |
| max = hi voltage tol, 0 degrees C, typical process, plus "Y%" |
| |
| Ramp times for bipolar devices: |
| To be determined by manufacturer. |
| |
| 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 here also. |
| |
| 7. The rise time of an open-drain device must be measured into |
| a 50 Ohm pullup resistor tied to the power pin. |
| |
|******************************************************************************
|* BIRD7.2 REPLACEMENT OF 3) FOR VERSION 1.1X
|* NOTE, Items 3. and 7. above deleted, Items 4. thru 6. renumbered 3. thru 5.
|*
|* 3) Ramp Rates:
|###############################################################################
|# PENDING BIRD13.2 ADDITION FOR VERSION 2.0
|# The following steps assume that the preferred load resistance of 50 ohms is
|# used.
|# There may be devices which will not drive a load of only 50 ohms into any
|# useful level of dynamics. In these cases use the manufacturers
|# suggested ( non-reactive ) load and add the load sub parameter to the
|# [Ramp] specification.
|#
|###############################################################################
|* The ramp rates (listed in AC characteristics below) should be derived
|* as follows:
|*
|* 1. Start with the silicon model, remove all packaging.
|*
|* 2. 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.
|*
|* 3. Due to the resistor, output swings will not make a full
|* transition as expected. However the pertinent data can still
|* be collected as follows:
|* a) determine the 20% to 80% voltages of the 50 Ohm swing
|* b) measure this voltage change as "dv"
|* c) measure the amount of time required to make this swing "dt"
|* 4. Post the value as a ratio "dv/dt", the simulation tool vendor
|* will extrapolate this value to span the required voltage swing
|* range in the final model.
|* 5. Typ, Min, and Max must all be posted, and are derived at the
|* same extremes as the V/I curves, which are:
|*
|* Ramp times for CMOS devices:
|* typ = nominal voltage, 50 degrees C, typical process
|* min = low voltage tol, 100 degrees C, typical process, minus "Y%"
|* max = hi voltage tol, 0 degrees C, typical process, plus "Y%"
|*
|* Ramp times for bipolar devices:
|* To be determined by manufacturer.
|*
|* 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 here also.
|###############################################################################
|# PENDING BIRD13.2 REPLACEMENT OF 5. FOR VERSION 2.0
|# 5. Typ, Min, and Max must all be posted, and are derived at the
|# same extremes as the V/I curves, which are:
|#
|# Ramp times for CMOS devices:
|# typ = nominal voltage, nominal temperature deg C, typical process
|# min = low voltage tol, max temperature deg C, typical process, minus"X%"
|# max = hi voltage tol, min teperature deg C, typical process, plus "X%"
|#
|# Ramp times for bipolar devices:
|# typ = nominal voltage, nominal temperature deg C, typical process
|# min = low voltage tol, min temperature deg C, typical process, minus "X%"
|# max = hi voltage tol, max teperature deg C, typical process, plus "X%"
|#
|# where nominal, min, and max temperature 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 here also. |###############################################################################
|###############################################################################
|# PENDING BIRD13.2 ADDITION FOR VERSION 2.0
|#
|# 6. During the IV measurements
|# the driving waveform should be of a rise/fall time fast enough to avoid
|# thermal feedback which is probably not realistic but slow enough that package
|# parasitics do not distort the data. The specific choice of sweep time is
|# left to the modelling engineer.
|###############################################################################
|******************************************************************************
|
| It is expected that this data will be created from silicon vendor |
| proprietary silicon-level models, and later correlated with actual device |
| measurement. |
|==============================================================================|

|******************************************************************************|
| ADDITIONAL NOTES FOR IBIS EXTENSIONS (BIRDS) |
|******************************************************************************|

*******************************************************************************

NOTES ON BIRD2.2

3) Add the following requirements to [Model]:

The model types Input, I/O, I/O_open_drain, I/O_open_sink,
I/O_open_source must have Vinl and Vinh defined. If
they are not defined, the parser will issue a warning and the default
values of Vinl=.8V and Vinh=2.0V will be assumed.

The model types Input_ECL and I/O_ECL must have Vinl and Vinh defined. If
they are not defined, the parser will issue a warning and the default
values of Vinl=-1.475V and Vinh=-1.165V will be assumed.

ECL defaults derived from FAIRCHILD F100K ECL
data book specification of Guaranteed input HIGH and LOW.

4) The following is added to the differential specification to clarify
Differential input threshold:

If a pin is a differential input pin the differential input threshold
(vdiff) overrides and supercedes the need for Vinh and Vinl.

If vdiff is not defined for a pin that is defined as requiring a Vinh by
its [Model] type, the parser will issue a warning and vdiff will be set to
the default value of 200mV.

5) The golden parser must be modified to allow "Terminators" and (4) and
check for (3) and (4).

*******************************************************************************

NOTES ON BIRD3

Most of the above is fairly
self-explanatory. The key here is to realize that the four 'reference'
keywords, in effect, create separate power supply rails that override
the default [Voltage range] supply. The intention was to create a very
general and flexible way to handle multiple supply devices and ECL.
To illustrate with some examples:

  1. An RS223 line driver has a +/- 12V output swing. One way to specify
     this device is shown below
                                typ min max
     [Voltage range] 12.0V 11.5V 12.5V | fixes pullup and
                                                       | POWER_clamp ref
     [Pulldown reference] -12.0V -11.5V -12.5V | fixes pulldown ref
     [GND_clamp reference] -12.0V -11.5v -12.5V | fixes GND_clamp ref
  
     Optionally, the [Voltage range] keyword could be replaced with the
     [Pullup reference] and [POWER_clamp] reference.

  2. A device uses two supplies, a 3V supply for its I/O and a 5V supply for
     it's internal logic. The power clamp diodes are referenced to the 5V
     supply. Their are two equally valid ways this device can be specified.

                                typ min max
     [Voltage range] 3.3V 3.0V 3.6V | fixes pullup reference
     [POWER_clamp reference 5.0V 4.5V 5.5V | fixes POWER_clamp
                                                      | reference
                        
                                typ min max
     [Voltage range] 5.0V 4.5V 5.5V | fixes both pullup and
                                                      | POWER_clamp reference
     [Pullup reference] 3.3V 3.0V 3.6V | overrides [Voltage
                                                      | range] specification
                                                      | on the pullup

  3. When specifying a device with an ECL type output structure, the pulldown
     curves must be referenced to the most positive supply (the same one that
     the pullup curves are referenced to). The easiest way to do this is
     define the value of the [Voltage range] as 0v. Both the pullup AND
     pulldown V/I curves will be referenced to 0v (remember, the pulldown
     defaults to 0v).

                                typ min max
     [Voltage range] 0V 0V 0V | VCC supply
     [Pulldown reference] 0V 0V 0V | not really
                                                        | required, its
                                                        | specified for
                                                        | completeness
     [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode

     Alternately, one could specify the VEE supply and then override the
     default values of the pullup and pulldown references
                                typ min max
     [Voltage range] -4.5V -4.0V -5.5v | VEE supply
     [Pullup reference] 0v 0v 0V
     [Pulldown reference] 0v 0v 0v
     [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode

     Finally, to specify ECL logic that is used with a +5V supply
     (positive ECL) one can do the following:

                                typ min max
     [Voltage range] 5.0V 4.5V 5.5V | VCC supply
     [Pulldown reference] 5.0V 4.5V 5.5V | override default

     The default references are used for the pullup and GND_clamp V/I
     curves.

*******************************************************************************

NOTES ON BIRD4

(1) The reason the voltage range over which an ECL output is specified
should be relaxed is that, with ECL, one is dealing with much smaller
signal swings and terminated transmission lines.

(2) The rational for specifying such a large voltage range was to allow
for the case of a CMOS output driving an unterminated transmission line.
When an incident voltage wave hits the end of an unterminated line it
will reflect back to the source at double the amplitude. Thus, a CMOS
output that swings rail-to-rail could see a reflection of up to 2*VCC
(or -VCC in the negative direction). However, with an ECL output, the
output swing is only ~800mv (typically -.9v to -1.7v) and furthermore,
because of the vary nature of ECL, any transmission lines will be
terminated with an Rt close to the lines Zo. Even in the case where the
mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv,
and the voltage range at the source due to reflections is -.6 to -2.0v.
Therefore, a range of VCC to VCC -2.2v is adequate to specify the output
under any reasonable conditions, and should be enough to allow simulators
to extrapolate the curves.

(3) The second proposal is an effort to make perfectly clear to both the
user and the person creating an IBIS specification for a particular part
how ECL device are to be handled.

******************************************************************************

NOTES ON BIRD5.2

  To be better able to simulate the ground bounce effect, it is
necessary to know which pins of a part are connected to a common
ground or power bus. This BIRD provides a simple mechanism for
identifying these common buses. This improves the simulation of
ground bounce by limiting the noise effects of switching drivers
to other drivers and receivers on the same bus.

STATEMENT OF THE RESOLVED SPECIFICATIONS:

  Each power and ground bus is given a unique name which must not
exceed 20 characters.

  An additional OPTIONAL keyword, [Pin_Mapping], is added to the
specification. Following this keyword is information indicating to
which power and ground buses a given driver or receiver is connected.
As an example of the new format, say that we have two ground buses
(named GNDBUS1 and GNDBUS2) which each bus together 3 pins:

  Pins: 11 12 13 21 22 23
           + + + + + +
           | | | | | |
           | | | | | |
  Buses: +-----+------+-----> to a few +-----+------+-----> to a few
              GNDBUS1 drivers GNDBUS2 more

and two similarly structured power buses (PWRBUS1 and PWRBUS2):

  Pins: 31 32 33 41 42 43
           + + + + + +
           | | | | | |
           | | | | | |
  Buses: +-----+------+-----> to a few +-----+------+-----> to a few
              PWRBUS1 drivers PWRBUS2 more

  We assume that the "signal name" for pins 11-13 and 21-23 are all
"GND", and that the names for pins 31-33 and 41-43 are all "VDD". The
new [Pin_Mapping] specification would be as follows:

[Pin_Mapping] gnd pwr
1 GNDBUS1 PWRBUS1
2 GNDBUS2 PWRBUS2
.....
....
....
11 GNDBUS1 NC
12 GNDBUS1 NC
13 GNDBUS1 NC
.....
21 GNDBUS2 NC
22 GNDBUS2 NC
23 GNDBUS2 NC
.....
31 NC PWRBUS1
32 NC PWRBUS1
33 NC PWRBUS1
.....
41 NC PWRBUS2
42 NC PWRBUS2
43 NC PWRBUS2

Explanation:

  In the above example, the first column contains a pin number; each
pin number must match one of the pin numbers declared previously in
the [Pin] section of the IBIS file. The second column, "gnd", designates
the ground bus connection for that pin; similarly, the third column, "pwr",
designates the power bus connection.

  For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd"
column indicates the ground bus to which it is attached. The entry in
the "pwr" column is NC because there is, of course, no connection to
any power bus. The situation for a POWER pin (e.g. pins 31-33 and
41-43) is analogous.

  The above example also contains two ordinary signal pins (pins 1 and
2). For these pins, the entries in the "gnd" and "pwr" columns
designate the power and ground buses to which their buffer models are
connected. Thus, for pin 1 there is an instance of the associated I-V
model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an
instance of an I-V model which connects to PWRBUS2 and GNDBUS2.

  If the [Pin_Mapping] keyword is present, then the bus connections for
EVERY pin listed in the [Pin] section must be given.

  If a pin has no connection, then both the "pwr" and "gnd" entries for
it may be NC.

******************************************************************************
###############################################################################

NOTES ON PENDING BIRD5.4

General Explaination:

  Each power and ground bus is given a unique name which must not
exceed 15 characters.

  An additional OPTIONAL keyword, [Pin_Mapping], is added to the
specification. Following this keyword is information indicating to
which power and ground buses a given driver or receiver is connected.
As an example of the new format, say that we have two ground buses
(named GNDBUS1 and GNDBUS2) which each bus together 3 pins:

  Pins: 11 12 13 21 22 23
           + + + + + +
           | | | | | |
           | | | | | |
  Buses: +-----+------+-----> to a few +-----+------+-----> to a few
              GNDBUS1 drivers GNDBUS2 more

and two similarly structured power buses (PWRBUS1 and PWRBUS2):

  Pins: 31 32 33 41 42 43
           + + + + + +
           | | | | | |
           | | | | | |
  Buses: +-----+------+-----> to a few +-----+------+-----> to a few
              PWRBUS1 drivers PWRBUS2 more

  We assume that the "signal name" for pins 11-13 and 21-23 are all
"GND", and that the names for pins 31-33 and 41-43 are all "VDD". The
new [Pin_Mapping] specification would be as follows:

[Pin_Mapping] pulldown_ref pullup_ref
1 GNDBUS1 PWRBUS1
2 GNDBUS2 PWRBUS2
.......
......
......
11 GNDBUS1 NC
12 GNDBUS1 NC
13 GNDBUS1 NC
.......
21 GNDBUS2 NC
22 GNDBUS2 NC
23 GNDBUS2 NC
.......
31 NC PWRBUS1
32 NC PWRBUS1
33 NC PWRBUS1
.......
41 NC PWRBUS2
42 NC PWRBUS2
43 NC PWRBUS2

Explanation:

  In the above example, the first column contains a pin number; each
pin number must match one of the pin numbers declared previously in
the [Pin] section of the IBIS file. The second column, "pulldown_ref",
designates the ground bus connection for that pin; similarly, the third
column, "pullup_ref", designates the power bus connection.

  For a GND pin, such as pins 11-13 and 21-23, the entry in the "pulldown_ref"
column indicates the ground bus to which it is attached. The entry in
the "pullup_ref" column is NC because there is, of course, no connection to
any power bus. The situation for a POWER pin (e.g. pins 31-33 and
41-43) is analogous.

  The above example also contains two ordinary signal pins (pins 1 and 2).
For these pins, the entries in the "pulldown_ref" and "pullup_ref" columns
+designate the ground and power buses to which their buffer models are
connected. Thus, for pin 1 there is an instance of the associated I-V
model which connects to PWRBUS1 and GNDBUS1. Pin 2 creates an
instance of an I-V model which connects to PWRBUS2 and GNDBUS2.

  If the [Pin_Mapping] keyword is present, then the bus connections for
EVERY pin listed in the [Pin] section must be given.

  If a pin has no connection, then both the "pullup_ref" and "pulldown_ref"
entries for it may be NC.

Optional Extension:

[Pin_Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref
1 GNDBUS1 PWRBUS1
2 GNDBUS2 PWRBUS2
3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP
4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP
.......
......
......
11 GNDBUS1 NC
12 GNDBUS1 NC
13 GNDBUS1 NC
.......
21 GNDBUS2 NC
22 GNDBUS2 NC
23 GNDBUS2 NC
.......
31 NC PWRBUS1
32 NC PWRBUS1
33 NC PWRBUS1
.......
41 NC PWRBUS2
42 NC PWRBUS2
43 NC PWRBUS2
.......
51 GNDCLMP NC
52 NC PWRCLMP

Explanation of Optional Extension:

This extension illustrates a hypothetical situation where the clamping
circuitry is connected to different rails than those of the pullup and pulldown
tables. Pins 51 and 52 are hypothetical clamping supplies, and their
attachments are shown at pins 3 and 4.

While the nomenclature can lead to some potential confusion, the intended
operation is according to this interpretation:

The "pulldown_ref" column contains the power connection for the [Pulldown]
table for non-ECL type [Models]. This is also the power connection for the
[GND_clamp] table unless overriden by a specification in the gnd_clamp_ref
column.

The "pullup_ref" column contains the power connection for the [Pullup] table
and for ECL type models, the [Pulldown] table. This is also the power
connection for the [POWER_clamp] table unless overriden by a specification
in the power_clamp_ref column.

###############################################################################
******************************************************************************

NOTES ON BIRD6.2

  Since only a small percentage of components contain differential pins,
[Diff_Pin] is optional. The component itself may be required to convey the
associations between pins for differential inputs and/or outputs. Such cases
may occur in practice when pairs of pins are connected using closely-spaced,
coupled nets or twisted-pair cabling.

  Pins which provide complimentary outputs should not be associated with
each other when the analysis is normally done using only one pin at a
time. However, there may be cases related to other pending extensions
(package models, power association, etc.) where association of complimentary
pins may be appropriate.

  [Diff_pin] should be used for pins designed for differential operation.
Inputs of such components have differential input sensitivity specifications
such as "Vpp" or "VT+" and "VT-" which define the differential threshold
voltages between two input pins. The vdiff column is introduced for such
specification limits (the magnitudes used for both polarities) which would
trigger an output change. Two switching cycles show that the actual switching
can occur at either polarity vdiff relative to one pin (A0_bar). If the actual
switching completes near tmax (the threshold past the cross-over), then the
first switching completes when (A0 - A0_bar) is negative and the second when
(A0 - A0_bar) is positive. One application of vdiff is for timing analysis
bounds.

 |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT
 | __
 | Polarities of vdiff relative to A0 signal show both
 |<-- tmax -->| polarities used to bound the transition region
 | |
 |<-- tmin ->|| (output = 0) (output = 1)
 __________ || ____________ _____________
           \ || / \ / A0
          __\||/__ __\ /__
          + \/ - vdiff - \/ + DIFFERENTIAL INPUT
          __ /\ __ __ /\ __
            / \ / \ __
 __________/ \____________/ \_____________ A0

  For timing purposes, an output is referenced to an equal voltage cross-over
of output pins. Setting the vdiff entry to 0V is thus chosen when the pins
are for differential outputs only. Note, the cross-over does NOT mean that
the outputs are at 0V.

  The Tskew value is the time difference between the mid-point of the two
output transitions. It is equivalent to the time-delay of one pin relative
to the other pin. Although an absolute value is specified, either pin can
delayed relative to the other pin. This specification assumes the outputs
are reasonably identical and the rise and fall transitions are reasonably
similar. tdelay may relate to Tskew values of unloaded outputs, but
are considered separate in IBIS as a launch delay of the non-inverting
output relative to the inverting output. tdelay can be either polarity.

  Tskew can be shown per National Interface Databook, diagram on pg 1-121
along with tdelay:

       3V _______________
         / \ INPUT TO SAME COMPONENT
 1.5V__ / \
       /| |\
0V ___/ | | \______________
        | tPLH | |tPHL|
 ___________ __________ _________ __
 ^ ^ |\ Tskew/ \ / ^ D0
 | Vo/2 | \|<>|/ \/ Vo/2
Vo v__ | _\ /__ __|/\|_____v DIFFERENTIAL OUTPUT
           | \/ / \
 | | /\ /| |\
 v_________|__/ \__________/ | | \_______ D0
           | | | |
           | | >| |< Tskew Tskew = |tPLH - tPHL|
           | |
>| |< tdelay (positive value)
            

  Conventions similar to those in [Pin] are followed with respect to required
and optional column entries and to column lengths.

******************************************************************************

NOTES ON BIRD7.2

Open-drain is corrected to Open_drain as a Model_type selection and is kept
for backward compatibility. I/O_open_drain is added. The new types with
"open_sink" and "open_source" are added to generically describe an output
with either an open [Pullup] or [Pulldown] and an output that sinks or
sources current. Without requiring an explicit test, these new Model_types
signal that the [Pullup] or [Pulldown] tables are not defined or are not to
be used if defined. Model_types for ECL are defined to fill the functionality
table below.

Conditions: | Model_type:
             |
pullup&down: | Output 3-state I/O
no pullup: | Open_sink I/O_open_sink
             | Open_drain I/O_open_drain
no pulldown: | Open_source I/O_Open_source
no pullup/dn:| Input
ECL up&down: | Output_ECL I/O_ECL
ECL no up/dn:| Input_ECL

Note, "ECL" is intended to be generic. It can be used to model "PECL" logic
spanning from Vcc = 5V to GND. Input_ECL is redundant, but may signal the
simulator to use different default Vinl and Vinh values if these OPTIONAL
(a BIRD2.1 issue) input parameters are not specified.

Currently, the user may choose to model the "Open" side directly through
control of the [Pullup] and [Pulldown] keyword. Omission of [Pullup] could
be interpreted as an "open_sink" device. Omission of [Pulldown] could be
interpreted as an "open_source" device. However, this method was never
specified in IBIS Version 1.1 as the correct method and therefore was not
the only method to specify "Open" devices.

The user may choose to model the "Open" side directly through control of the
[Pullup] and [Pulldown] data. If all of the data contains I(typ) = 0mA
entries (a minimum of two entries are required), then that [Model] could be
interpreted as "open". Zero valued [Pullup] data corresponds to "open_sink"
or "open_drain" types. Zero valued [Pulldown] data corresponds to
"open_source" types.

Without the additional Model_types, the above two approaches plus the existance
of "Open_drain" provide a confusing and inconsistent specification and
require the simulator to perform a variety of tests before being able to
process the data.

The "ECL" model types are added to avoid similar confusion.

******************************************************************************

NOTES ON BIRD8.2

NO ADDITIONAL NOTES NEEDED

******************************************************************************

NOTES ON BIRD9.3

  A set of terminator components is useful to be formatted using IBIS because
they are found as packaged components. All of the options can support (typ),
(min) and (max) specifications.

(1) Parallel Resistor Termination:

  The additonal elements [Rpower] and [Rgnd] provide terminations to Vcc, Gnd
or both. Devices such as the Motorola MCC142233 to MCC142236 Switchable SCSI
Passive Bus Terminator series would be modeled with these elements.

  At least two other techniques could be used in IBIS Version 1.1. The
[POWER_clamp] or [GND_clamp] tables could be used (with as few as two data
points each) to represent resistors. Another method could be to use R_pkg
(or R_pin) with [POWER_clamp] or [GND_clamp] structures configured as a
very low impedance. Processing tabular data for these purposes would be less
efficient and less obvious than working with resistive elements directly.

(2) RC (or AC) Termination:

  R_pkg (or R_pin) and C_comp can provide RC terminations. This proposal
specifies [Rac] connected to [Cac] elements. This will allow packaged RC
terminations which include built in clamping diodes to be modeled directly.

  Diode terminators already can be modeled using IBIS Version 1.1:

(3) Diode Termination:

  Devices such as the TI SN74S1050 thru SN74S1056 Schottky Barrier Diode
Bus-Termination Arrays can be modeled using existing [POWER_clamp] and
[GND_clamp] structures.

  The total context model is attached showing the proposed additions.

                        |<-------------TERMINATOR Model--------------->|

                            VOLTAGE RANGE or
                            POWER_CLAMP REF
                                   o
                                   |
                        POWER_ |---o---|
                        CLAMP | |
                            |--o--| \
                            | | /
                            | VI | \ RPOWER PACKAGE Keyword
                            | | / Parameters
                            |--o--| | |<----------------->|
                               | |
                               | | PIN
                         o-----o-------o-----o-----/\/\/\--UUUUUU---o--o
                         | |GND_ | | R_PKG L_PKG |
                         | |CLAMP | | |
                         | |--o--| | | |
                         | | | \ | |
                         | | VI | /RGND | |
                         | | | \ \ |
                         | |--o--| / / RAC |
                         | | | \ |
                         | |---o---| / |
                         | | | |
                 C_COMP --- o --- CAC C_PKG ---
                        --- GND or --- ---
                         | GND_CLAMP REF | |
                         | | |
                         |-------------------o----------------------|
                                             |
                                             o
                                            GND

                                      |<-------->|
                                        Proposed
                                       Terminator
                                        Keywords

******************************************************************************

NOTES ON BIRD10.1

Refer to BIRD10.1 for the complete specification and description

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Summary:
-------

A new keyword, [Package Model], is added to the .ibs file. This
keyword is used within a [Component] to indicate (by name) the package
model that should be used for a part. Package models can be found
either in separate package model files, which bear the .pkg extension,
or within the same .ibs file as the [Component]. An additional new
keyword, [Define Package Model], is also added to the specification;
this is used to mark the beginning of the actual package model data.
The purpose of breaking up the package model and the component model
is to make associations between the two more flexible: several
components may share a single package model, or one component may have
several different incarnations which use different packages (and thus,
different package models).

Use of [Package Model] is OPTIONAL. If it is not provided, then the
table of RLC values listed in the [Pin] section of the [Component] is
used as the "package model" for the part. On the other hand, if the
[Package Model] IS given, then the R_pin, L_pin and C_pin values in
the [Pin] section may either be ignored, or may be used for less
detailed simulations without coupling. Probably this data will simply
be left out of the [Pin] section when a [Package Model] is used;
this practice is permitted by the IBIS Ver. 1.1 specification since
[Pin] data may contain either 3 or 6 columns.

A .pkg file is just an ordinary IBIS file, with the restriction that
it cannot contain [Component]'s or [Model]'s. Only package models
declared by the [Define Package Model] keyword may be contained within
these files. Of course, all of the necessary components of an IBIS
file ([IBIS Ver], [File Name], [File Rev], etc. through [End]) must
still be included within a .pkg file.

The package model to be used treats every package as a collection of
current carrying "paths," which lead from the board, through the
packages pins, leadframe traces and bonding wires to a bonding pad on
the die itself. Each path has a self-resistance, self-inductance and
self-capacitance associated with it. In addition, there is the
flexibility to describe mutual inductance, mutual resistance and
coupling capacitance drops between every path. This data can be
listed concisely as three RLC parameter matrices. This BIRD describes
how these matrices are to be formatted.

******************************************************************************

NOTES ON BIRD11.2 ... THESE NOTES REFER TO CHANGES IN THE IBIS_CHK PROGRAM

   ***************************************************************************
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 competely
           unrealistic.

     Examples:
        *** example with non-monotonic data at the end point
        V: I:
        0.00 0.0
        4.90 50.0ma
        4.91 49.9ma
        4.93 56.7ma
        5.00 3.0ma -> V/I table has increasing current (3.0 > 0)
                             Vmax = 5.0, I =3.0mA
                             Vmin = 0.0, I =0.0

        *** example with negative to positve voltages with negative first
        V: I:
       -5.00 -0.1ma
        0.00 0.0
        5.00 100.0ma -> V/I table has increasing current (100 > -0.1)
                             Vmax = 5.0, I=100mA
                             Vmin = -5.0, I=-0.1mA

        *** example with table data entered postive voltages first
        V: I:
        5.00 10.1ma
        0.00 0.0
       -5.00 -10.1ma -> V/I table has increasing current (10.1 > -10.1)
                             Vmax = 5.0, I=10.1mA
                             Vmin = -5.0, I=-10.1mA

        *** example with only two entrys
        V: I:
        0.00 0.0
       -5.00 10.1ma -> V/I table has decreasing current (0 < 10.1)
                             Vmax = 0.0, I=0
                             Vmin = -5.0, I=10.1mA
        *** ECL example
       [Pullup]
       Voltage I(typ) I(min) I(max)
        0.0 0 0 0
        0.7 -0.2m -0.2m -0.2m
        0.73 -0.4m -0.4m -0.4m
        0.75 -0.8m -0.8m -0.8m
        0.76 -1.2m -1.2m -1.2m
        0.77 -1.6m -1.6m -1.6m
        0.8 -4.4m -4.4m -4.4m
        0.82 -7.6m -7.6m -7.6m
        0.85 -14.2m -14.2m -14.2m
        0.9 -30.0m -30.0m -30.0m
        1.0 -58.0m -50.0m -68.0m -> V/I table has decreasing current ( -58 < 0)
                                                 Vmax = 1.0, Ityp=-58mA
                                                 Vmin = 0, Ityp=0

       [Pulldown]
       Voltage I(typ) I(min) I(max)
        0.0 0 0 0
        1.6 -0.2m -0.2m -0.2m
        1.62 -0.4m -0.4m -0.4m
        1.64 -0.6m -0.6m -0.6m
        1.65 -0.8m -0.8m -0.8m
        1.66 -1.2m -1.2m -1.2m
        1.67 -1.6m -1.6m -1.6m
        1.68 -2.4m -2.4m -2.4m
        1.69 -3.2m -3.2m -3.2m
        1.70 -4.4m -4.4m -4.4m
        1.72 -7.4m -7.4m -7.4m
        1.75 -14.2m -14.2m -14.2m
        1.8 -30.5m -30.5m -30.5m
        1.9 -65.0m -60.0m -75.0m -> V/I table has decreasing current ( -65 < 0)
                                                  Vmax = 1.9, Ityp=-65mA
                                                  Vmin = 0.0, Ityp= 0

        *** An abreviated INTEL model for a CMOS output
        
  |****************************************************************************
        [Pulldown]
        | Voltage I(typ) I(min) I(max)
           -5.00V -38.70mA -29.47mA -51.22mA
           -1.00V -24.88mA -19.18mA -32.90mA
           -0.50V -14.35mA -11.06mA -19.05mA
            0.00V -11.84pA -554.66pA -11.03pA
          100.00mV 3.20mA 2.47mA 4.27mA
          200.00mV 6.24mA 4.80mA 8.30mA
            4.90V 38.68mA 29.45mA 51.18mA
            5.00V 38.70mA 29.47mA 51.22mA
           10.00V 39.96mA 30.37mA 53.06mA -> V/I table increasing
        [GND_clamp]
        | Voltage I(typ) I(min) I(max)
           -5.00V -680.00mA NA NA
           -1.10V -75.50mA NA NA
         -600.00mV -950.00uA NA NA
         -500.00mV -78.00uA NA NA
         -200.00mV 0.00pA NA NA
         -100.00mV 0.00pA NA NA
            0.00V 0.00pA NA NA
            5.00V 0.00pA NA NA -> V/I table increasing (0 > -680)
        [Pullup]
        | Voltage I(typ) I(min) I(max)
           -5.00V 38.14mA 27.33mA 54.76mA
           -4.50V 37.49mA 26.87mA 53.79mA
           -1.00V 17.13mA 12.81mA 23.55mA
           -0.50V 9.26mA 6.96mA 12.66mA
            0.00V 13.57pA 613.51pA 11.04pA
          100.00mV -1.96mA -1.48mA -2.67mA
          200.00mV -3.87mA -2.92mA -5.27mA
          500.00mV -9.26mA -6.96mA -12.66mA
            1.80V -26.79mA -19.79mA -37.25mA
            1.90V -27.74mA -20.46mA -38.64mA
            4.60V -37.62mA -26.97mA -54.00mA
            4.70V -37.76mA -27.06mA -54.20mA
            5.00V -38.14mA -27.33mA -54.76mA
           10.00V -44.52mA -33.72mA -61.15mA -> V/I table decreasing
        [POWER_clamp]
        | Voltage I(typ) I(min) I(max)
           -5.00V 1.05A NA NA
           -1.10V 79.00mA NA NA
           -1.00V 54.00mA NA NA
         -900.00mV 29.00mA NA NA
         -800.00mV 10.40mA NA NA
         -200.00mV 0.00uA NA NA
         -100.00mV 0.00uA NA NA
            0.00V 0.00pA NA NA -> V/I table decreasing

  3) IF the model is any of the following types:(Input_ECL, Output_ECL, I/O_ECL)
           {
           Verify that:
             - Pullup V/I table has equal or decreasing current
             - POWER_clamp V/I table has equal or decreasing current
             - Pulldown V/I table has equal or decreasing current
             - GND_clamp V/I table has equal or increasing current
           }
        ELSE
           {
           Verify that:
              - Pullup V/I table has equal or decreasing current
              - POWER_clamp V/I table has equal or decreasing current
              - Pulldown V/I table has equal or increasing current
              - GND_clamp V/I table has equal or increasing current
           }

     Note: This specifically allows constant current generators and 0 current
           tables. 0 current tables may be used to indicate table is unused.

  4) If any table verification fails report the following error message:
     'Error found in xxx V/I table at line number nnn!'.
      Where xxx is one of the following Pullup, Pulldown, POWER_clamp, GND_clamp.
      Where nnn is the line number.

   ***************************************************************************
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 donot 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 apporach 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 occured.
   ***************************************************************************
NOTICE TO ANY PERSON MODIFING THIS PROGRAM!
-------------------------------------------
This program SHALL NOT BE MODIFIED unless there is an associated IBIS 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 which reads the
version number from the IBIS file and runs the portion of the program
corresponding
to that MAJOR version. Code which is used only by the program startup function
is not duplicated.

******************************************************************************

NOTES ON BIRD12.2

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Currently, the IBIS
specification assumes that all devices can be described accurately using
a single risetime and falltime parameter. In other words, the switching
waveform of the device is a relatively linear ramp. However, devices that
shape the output waveform (risetime controlled devices) do not have a
linear switching ramp. Trying to model devices of this type using a
linear ramp model results in mis-predicting both the time to logic threshold
and maximum edge rate.

     As IBIS is a specification that focuses on the behavior of a device
rather than it structure or implementation, it would be ideal if there
were a simple set of measurements one could take in order to describe
the non-linearity. Obviously, the waveform shape itself is a good
place to start. The fundamental assumption here is that the shape of the
waveform, combined with the loading conditions, give simulator vendors
enough additional information to construct accurate models of non-linear
waveform drivers. Ideally, an IBIS model will include waveforms taken
under several different loading conditions (R_fixture and V_fixture). By
choosing the appropriate loading conditions a modeler can give the
simulator vendors enough information to accurately simulate a device.
The most straight forward way to describe a waveform shape is with a
table of time vs. voltage points. (Note that one could take this table
and enter it into a spreadsheet or graphing program and produce a picture
of the waveform -- and that is one of the intents of the format.)

     One remaining issue is the ability to align the starting points of
waveforms taken under different loading conditions (i.e. waveforms in
two different tables). Jon Powell (Quad Design) has an action item to
produce various waveforms and show this is possible. (PLEASE SEE THE
NOTE BELOW ON VERSION 12.0 TO 12.1 CHANGES)

     In addition to providing more complete information to simulator vendors,
explicitly describing the waveform allows one to validate a particular
simulator's results. By performing a simulation into the specified load(s)
and then comparing the results with the waveform(s) as listed in the IBIS
file, one can perform anything from a quick sanity check of the data to
a detailed analysis between simulators. A 'self-validating' model is a
very powerful tool for checking and maintaining model quality.

 3. A statement was added that requires that all rising/falling edge
    data be time correlated. To make this perfectly clear: the data
    in one rising edge table must be time correlated to the data in
    any other RISING edge waveform table. Likewise for falling edge
    data. There is no requirement for time correlation between the
    data in rising and falling waveform tables. Note also the requirement
    that the correlation be to a reference point on the input stimulus
    waveform. This is to prevent a user from time correlating the
    waveforms to a point on an output waveform -- this defeats the
    purpose of time correlation.

*******************************************************************************
###############################################################################

NOTES ON PENDING BIRD13.2

The spec should have flexibility enough to handle models of parts manufactured
to MIL spec and automotive spec as well as parts for special purposes which are
perhaps more sensitive than even consumer or commercial spec allows. Thus the
relaxation , or tightening as the case may be, of the temperature and voltage
range mandates. The added keyword and sub-parameter are to allow the simulator
useable specification of the relaxed or tightened ranges for the relevant
measurements.

The ramp rate is still mandated to be determined between 20 and 80 % of actual
swing to promote the linearity of the measured portion of the edge. The load
is mandated to be non-reactive so as to preserve the inherent dynamics of the
driver, and not introduce false dynamics due to the load.

Backward compatibility is addressed by making the new specifications optional
if the preferred votage and temperature ranges and load resistance are used.

###############################################################################

NOTES ON PENDING BIRD14

      Presently if a particular [Model] needs to be used for a couple
of buffers in which the only differences are in the Vinl, Vinh, or
C_comp sub-parameters, separate [Model]s have to be made. With the
[SPECS] keyword, only one [Model] has to be made with the
sub-parameters being passed down from the [SPECS] section. This
feature will reduce the size of the .IBS file. The [SPECS] section
allows separating the details from the core of a [Model], and at the
same time, gives the user the sub-parameters he needs. The [SPECS]
keyword is also optional and hence fully backward compatible.

      The keywords Cref and Vt and all other sub-parameters of a
[Model] are to be used as default values only. All sub-parameters in
a [Model] are overriden by any values listed in the [SPECS] section.

      All of the data in the [SPECS] section, Cref, and Vt is
standard data available in data books. Allowing the specification of
Cref and Vt enhances the usability of an IBIS model by providing key
parameters for simulation.

###############################################################################

NOTES ON PENDING BIRD15

NONE ARE NEEDED

###############################################################################
Received on Tue May 17 09:22:20 1994

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT