1 OF 3 EXTENDED IBIS

From: Bob Ross <bob@icx.com>
Date: Sun Feb 20 1994 - 18:42:17 PST

To IBIS Members:

The long text that follows is an UNOFFICIAL DRAFT designated IBIS Version 1.1X
which uses IBIS Version 1.1 as the baseline and includes the BIRDS which have
been approved to date. THIS MAIL WILL COME IN 3 SECTIONS.

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

This 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.1X" 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.
|******************************************************************************
|==============================================================================|
| |
| 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
|*******************************************************************************
|* 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
|*******************************************************************************
|*******************************************************************************
|* 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.
|*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 |
|*
|* BIRD7.2 modification
|* 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, and I/O_ECL 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. |
| Other Notes: A complete [Model] description normally contains the following |
| keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp], |
| [POWER_clamp], 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. |
|*
|* 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
Received on Sun Feb 20 19:00:14 1994

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