From bob@icx.com Fri Dec 2 11:18:42 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13770; Fri, 2 Dec 94 11:18:42 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 2 Dec 94 11:00 PST Message-Id: Date: Fri, 2 Dec 94 11:00 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS SUMMIT Will I look forward to the technical exchange portion of the IBIS SUMMIT, now planned sometime in January. Here are some of the topics I am interested in: (1) More details on the diode stored charge effects in clamping circuits and how to model. (2) Some discussion of the output feedback concerns. (3) More details on Arpad's mathematical representation of temperature/ voltage interactions on VI curves, and how this may apply to other than CMOS technologies. (4) More details on possible simplified package models with coupling and delay. I would be willing to cover one or two subjects myself, possibly on issues related to waveform models and on ASIC library formulation. Bob Ross, Interconnectix, Inc. From Derrick_Duehren@ccm2.jf.intel.com Fri Dec 2 14:24:38 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15013; Fri, 2 Dec 94 14:24:38 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rDgKp-000Uf4C; Fri, 2 Dec 94 14:20 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rDgKo-000twyC; Fri, 2 Dec 94 14:20 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 2 Dec 94 14:20:09 PST Date: Fri, 2 Dec 94 14:20:09 PST From: Derrick Duehren Message-Id: <941202142009_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Ver 2.1 DRAFT (to be ratified 12/9/94) Text item: Text_1 IBISians, Attached, please find the DRAFT Version 2.1 spec we plan to ratify during our 12/9/94 teleconference. Please review it carefully before the meeting. All changes are marked. I have also posted it to the spec2_1 directory on vhdl.org. Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ Text item: ver2_1a.txt 12/1/94 3:24P |******************************************************************************* |* This is a draft IBIS version 2.1. It contains IBIS version 2.0 plus changes |* from BIRD18.2, BIRD19.1, BIRD20.1, BIRD21, pending BIRD23, and some text |* updates of dates, case corrections, and minor clarifications. All changes |* from Version 2.0 are marked with an asterisk (*) in the first, second, or |* third column. (Double asterisks indicate changes from pending BIRD23.) |* |* Ratification is expected at the 12/9/94 IBIS Open Forum teleconference. |* Bridge: Res: |* (916) 356-9999 406224 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). |******************************************************************************* |* |============================================================================== |* I/O Buffer Information Specification (IBIS) Version 2.1 (12/9/94) | | IBIS is a standard for electronic behavioral specifications of integrated | circuit input/output analog characteristics. |============================================================================== | 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 2.0 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. | | Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility | with Versions 1.0 and 1.1. All new keywords and elements added in Version | 2.0 are optional. A complete list of changes to the specification is in the | IBIS Version 2.0 Release Notes document ("ver2_0.rn"). | |* Version 2.1 update. The file "ver2_1.ibs" contains clarification text |* changes, corrections, and two additional waveform parameters beyond |* Version 2.0. | |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. 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 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 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) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in sub-parameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, and Henries.) The | parser looks 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). | | 9) 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. | | 10) Currents are considered positive when their direction is into the | component. | | 11) All temperatures are represented in degrees Celsius. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | 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] 2.1 | Used for template variations | |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character 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 is 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: Specifies 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] ver2_1.ibs | |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is 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] [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: These keywords' arguments can contain blanks, and be of | any format. The [Date] keyword argument is limited to a | maximum of 40 characters. | | Because IBIS model writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools should make this information | available. Derivative models should include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative models verbatim. |------------------------------------------------------------------------------ *[Date] 12/09/94 | The latest file revision date | [Source] Put originator and the 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] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | [Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks 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. | | NOTE: Blank characters are not recommended due to usability | issues. |------------------------------------------------------------------------------ [Component] 7403398 MC452 | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies 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] Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines 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: The typical (typ) 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. Use the [Package Model] keyword for more | complex package descriptions. If defined, the [Package Model] | data overrides the values in the [Package] keyword. | Regardless, the data listed under the [Package] keyword must | still contain valid data. |------------------------------------------------------------------------------ [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: Associates 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 | |============================================================================== | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model | Usage Rules: The package model name is limited to 40 characters. | Spaces are allowed in the name. The name should include the | company name or initials to help ensure uniqueness. The | simulator will search for a matching package model name as an | argument to a [Define Package Model] keyword in the current | IBIS file first. If a match is not found, the simulator will | look for a match in an external .pkg file. If the package | model is in a separate .pkg file, it must be kept in the same | directory as the .ibs file. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that part. | The specification permits .ibs files to contain [Define | Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models | that have the same name. |------------------------------------------------------------------------------ [Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Pin Mapping] | Required: No |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. Use the | NC reserved word for entries that are not needed or that follow | the conditions below: | | All entries with identical labels are assumed to be connected. | Each unique entry label must connect to at least one pin whose | model_name is POWER or GRD. | | If a pin has no connection, then both the pulldown_ref | and pullup_ref sub-parameters 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 overridden 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 overridden by a | specification in the power_clamp_ref column. | | The 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 | | When 5 columns are specified, the headings gnd_clamp_ref and | power_clamp_ref must be used. Otherwise, these headings can | be omitted. |--------------------------------------------------------------------------- [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 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 | . 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps | |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |*Usage Rules: Enter only differential pin pairs. The first column, |* [Diff Pin], contains a non-inverting pin number. The second |* column, inv_pin, contains the corresponding inverting pin number |* for I/O output. Each pin number must match the pin |* numbers declared previously in the [Pin] section of the IBIS |* file. The third column, vdiff, contains the specified |* output and 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 forth, fifth, |* and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, |* contain launch delays of the non-inverting pins relative to |* the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes 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, vdiff is 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 is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | 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 is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is 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, Vmeas, Cref, | Rref, Vref | Usage Rules: Each model type 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. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except | for those model names that 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. | | Model_type must be one of the following: | 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. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl=0.8V and Vinh=2.0V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl=-1.475V and Vinh=-1.165V | are assumed. | | Terminator This model type 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, and | pull-up resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | |* 3-state This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | |* Open_sink These model types indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = 0mA | for all voltages specified) and the output | SINKS current. Open_drain model type is | retained for backward compatibility. | | Open_source This model type indicates that the | output has an OPEN side (do not use the | [Pulldown] keyword, or if it must be used, | set I = 0mA for all voltages specified) and | the output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | keyword. | | The Model_type and C_comp sub-parameters are required. The | Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref sub- | parameters are optional. C_comp defines the silicon die | capacitance. This value should not include the capacitance of | the package. C_comp is allowed to use "NA" for the min and max | values only. The Polarity sub-parameter can be defined as |* either Non-inverting or Inverting, and the Enable sub- | parameter can be defined as either Active-high or Active-low. | | The Cref and Rref sub-parameters correspond to the test load | that the manufacturer uses when specifying the propagation | delay and/or output switching time of the device. The Vmeas | sub-parameter is the reference voltage level that the | manufacturer uses for the component. Include Cref, Rref, and | Vmeas information to facilitate board-level timing simulation. | The assumed connections for Cref, Rref, and Vref are shown in | the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one | or more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, | some models may have only a subset of 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. |------------------------------------------------------------------------------ | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V |Reference voltage for timing measurements Cref = 50pF |Timing specification test load capacitance value Rref = 500 |Timing specification test load resistance value Vref = 0 |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== | Keyword: [Temperature Range] | Required: Yes, if other than the preferred 0, 50, 100 degree C range | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various V/I curves and ramp rates were | derived. |------------------------------------------------------------------------------ | variable typ min max [Temperature Range] 27.0 -50 130.0 | |============================================================================== | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], | [POWER Clamp Reference], and [GND Clamp Reference] are not | present |Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the pull-up and [POWER Clamp] V/I data is | referenced. |Usage Rules: Provide actual voltages (not percentages) in the 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: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | pull-up V/I data. |Usage Rules: Provide actual voltages (not percentages) in the 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: Defines a power supply rail other than 0V as the reference | voltage for the pull-down V/I data. If this keyword is not | present, the voltage data points in the pull-down V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the 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 typ, 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: Defines 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: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Refer the "Other Notes" section of the [GND Clamp Reference] | keyword. |--------------------------------------------------------------------------- | 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: Defines 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: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Power Supplies: It is intended 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 pull-up, | pull-down, or clamp structure is referenced to something other | than the default supplies, use the additional 'reference' | keywords. | | 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. |---------------------------------------------------------------------------- | variable typ min max [GND Clamp Reference] 0V 0V 0V | |============================================================================== | 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 pull-down and pull-up structures of an output buffer and | the V/I curves of the clamping diodes connected to the GND and | the POWER pins, respectively. 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: 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. (Note: Under these keywords, all | references to 'Vcc' refer to the voltage rail defined by the | [Voltage range], [Pullup Reference], or [POWER Clamp Reference] | keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5V in the table actually | means 5V above Vcc, which is +10V with respect to ground; | and 10V means 10V below Vcc, which is -5V with respect to | ground. Vcc-relative data is necessary to model a pull-up | structure properly, since the output current of a pull-up | 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. | | When tabulating data for ECL devices, the data in the pull-down | 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 | pull-up 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 of | these cases, the data is referenced to the Vcc supply voltage, | using the equation Vtable = Vcc - Voutput. | | Monotonicity Requirements: | 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. | |* An IBIS syntax checking program shall test for non-monotonic |* data and provide a maximum of one note per V/I table if |* non-montonic data is found. For example: |* "NOTE: Line 300, Pulldown V/I table for model DC040403 is |* non-monotonic! Most simulators will filter this data |* to remove the non-monotonic data." |* |* It is also recognized that the 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 IBIS Version 2.x syntax checking programs, such |* programs will conduct monotonicity testing only on one |* V/I table at a time. | | It is assumed that the simulator sums the clamp curves | together with the appropriate pull-up or pull-down 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 pull-up and pull-down 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, with the I/O buffer 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 pull-up and | pull-down 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 can demonstrate a | non-monotonic shape.) This requirement enables 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 cannot be measured alone), the pull-up and | pull-down curves of an IBIS model can 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] | Note: Vtable = Vcc - Voutput | | 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] | Note: Vtable = Vcc - Voutput | | 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 | |============================================================================== | 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 keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max), or the three entries | for 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 coexist with [GND Clamp] |* and [POWER Clamp] structures. If the terminator consists |* of a series R and C (often referred to as either an AC or RC |* terminator), then both [Rac] and [Cac] are required. When | | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | VI | \ Rpower [Package] Keyword | | | / Sub-parameters | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | VI | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp Ref] | | | | | | | o-------------------o----------------------o | | | o | GND |------------------------------------------------------------------------------ | 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 and terminators | Description: Defines the rise and fall times of a buffer. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. | The ramp rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load sub-parameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 2.20/1.06n 1.92/1.28n 2.49/650p dV/dt_f 2.46/1.21n 2.21/1.54n 2.70/770p R_load = 300ohms | |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. |* Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, |* C_fixture, L_fixture, | 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, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are 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. Each |* table must contain at least two entries. Thus, numerical |** values are required for the first and last entries of any |** column containing numerical data. | | 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 Sub-params are analogous to 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 |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- 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. |* |* V_fixture defines the voltage for typ, min, and max |* supply conditions. However, when the fixture voltage |* is related to the power supply voltages, then the |* sub-parameters V_fixture_min and V_fixture_max can |* be used to further specify the fixture voltage for |* min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 *V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc *V_fixture_max = 5.5 |Specified, but not used in this example 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 | |============================================================================= | | PACKAGE MODELING | | The [Package Model] keyword is optional. If more than the default RLC | package model is desired, use the [Define Package Model] keyword. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... | [End Package Model] keywords for each package model that is defined. For | reference, these keywords are listed below. Full descriptions follow. | Simulators that do not support these keywords will ignore all entries between | the [Define Package Model] and [End Package Model] keywords. | | [Define Package Model] Required if the [Package Model] keyword is used |* [Manufacturer] (note 1) |* [OEM] (note 1) |* [Description] (note 1) |* [Number of Pins] (note 1) |* [Pin Numbers] (note 1) |* [Model Data] (note 1) | [Resistance Matrix] Optional |* [Inductance Matrix] (note 1) |* [Capacitance Matrix] (note 1) | [Bandwidth] Required (for Banded_matrix matrices only) |* [Row] (note 1) |* [End Model Data] (note 1) |* [End Package Model] (note 1) | |* (note 1) Required when the [Define Package Model] keyword is used | | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | | USAGE RULES FOR THE .PKG FILE | | Package models are stored in a file whose name looks like: | .pkg. | | The provided must adhere to the General Syntax Rules. Use the | ".pkg" extension to identify files containing package models. The .pkg file | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg | file. The .pkg file is for package models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package | model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes | Description: Declares the manufacturer of the package. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of | what kind of package the [Package Model] is representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |============================================================================== | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the package | pins, and to define an ordering of them. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." The pin names can not exceed 5 characters in | length. | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are | pins (as given by the preceding [Number of Pins].) |------------------------------------------------------------------------------ [Pin Numbers] A1 A2 | . | . | . A22 B1 | . | . | . | etc. | |============================================================================== | Keyword: [Model Data] | Required: Yes | Description: Indicates the beginning of the formatted package model data, | which can include the [Resistance Matrix], [Inductance Matrix], | [Capacitance Matrix], [Bandwidth], and [Row] keywords. |------------------------------------------------------------------------------ [Model Data] | |============================================================================== | Keyword: [End Model Data] | Required: Yes | Description: Indicates the end of the formatted model data. | Other Notes: In between the [Model Data] and [End Model Data] keywords is | the package model data itself. The data is a set of 3 | matrices: the resistance (R), inductance (L), and capacitance | (C) matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords below to mark the | beginning of each new matrix. |------------------------------------------------------------------------------ [End Model Data] | |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The sub-parameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the sub-parameters. | After each of these sub-parameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board | (General Syntax Rule #10). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | | For even a modest-sized package, this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | The first row only needs to specify the entries [1,1] through [1,1+B] since | any other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2, 2+B], and so on. In general, for row M | the entries [M,M] through [M,M+B] are given. | | Unlike the Full_matrix, each successive row will typically have the same | number of entries, except for the last few rows. When M + B finally exceeds | the size of the matrix N, then the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | Also, note that it is again necessarily the case that the N'th | row of an N x N matrix has just a single entry (the diagonal entry.) | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.0 [File Name] example.pkg [File Rev] 0.1 [Date] June, 9 1994 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor | base its data on typical process data, and then derate by voltage and | temperature, and a proprietary "X%" factor. This methodology also has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | 1) V/I curves for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "X%" | max = maximum voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "X%" | max = maximum voltage, max temp deg C, typical process, plus "X%" | | Nominal, min, and max temperature are specified by the manufacturer | of the part. The default range is 50C nom, 0C min, and 100C max | temperatures. | | X% should be statistically determined by the silicon vendor based | on numerous fab lots, test chips, process controls, etc.. The value | of X need not be published in the IBIS file, and may decrease over | time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | As described in the [Pulldown Reference] keyword section, the V/I curve of | the [Pullup] and the [POWER Clamp] structures are 'Vcc relative', using | the equation: Vtable = Vcc - Voutput. | | For example, a device with a 5V power supply voltage should be | characterized between (0 - 5) = -5V and (5 + 5) = 10V; and a | device with a 3.3V power supply should be characterized between | (0 - 3.3) = -3.3V and (3.3 + 3.3) = 6.6V for the pull-down curve. | | When tabulating output data for ECL type devices, the voltage points | must span the range of Vcc to Vcc - 2.2V. This range applies to both the | pull-up and pull-down tables. Note that this range applies ONLY when | characterizing an ECL output. | | These voltage ranges must be spanned by the IBIS data. Data derived | from lab measurements may not be able to span these ranges as such and | so may need to be extrapolated to cover the full range. This data must | not be left for the simulator to provide. | | 3) Ramp Rates: | The following steps assume that the default load resistance of 50 ohms is | used. There may be devices that will not drive a load of only 50 ohms | into any useful level of dynamics. In these cases, use the manufacturer's | suggested (non-reactive) load and add the load sub parameter to the [Ramp] | specification. | | The ramp rate does not include package and parameters; it is the intrinsic | output stage rise and fall time only. | | The ramp rates (listed in AC characteristics below) should be derived | as follows: | | a. If starting with the silicon model, remove all packaging. If starting | with a packaged device, perform the measurements as outlined below then | use whatever techniques are appropriate to derive the actual, unloaded | rise and fall times. | | b. If: The Model_type is one of the following: Output, I/O, or | 3-state (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | | If: The Model_type is Output_ECL or I/O_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either POWER or the vendor- | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either GND or the vendor-suggested | termination voltage. Use this load to derive both the rising | and falling edges. | | c. Due to the resistor, output swings will not make a full transition as | expected. However the pertinent data can still be collected as | follows: | 1) determine the 20% to 80% voltages of the 50 Ohm swing | 2) measure this voltage change as "dV" | 3) measure the amount of time required to make this swing "dt" | d. Post the value as a ratio "dV/dt". The simulation tool vendor | extrapolates this value to span the required voltage swing range in | the final model. | | e. Typ, Min, and Max must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "Y%" | max = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "Y%" | max = maximum voltage, max temp deg C, typical process, plus "Y%" | | where nominal, min, and max temp are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min, and 100C max | temperatures. | | Note that the derate factor, "Y%", may be different than that used | for the V/I curve data. This factor is similar to the X% factor | described above. As in the case of V/I curves, temperatures are | junction temperatures. | | f. During the IV measurements, the driving waveform should have a | rise/fall time fast enough to avoid thermal feedback. The specific | choice of sweep time is left to the modeling engineer. | | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. IBIS SPEC V2.1 12/1/94 DRAFT k:\ibis\spec\ver2_1a.txt Page 29 Printed: 12/1/94 From Derrick_Duehren@ccm2.jf.intel.com Fri Dec 2 14:46:27 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15337; Fri, 2 Dec 94 14:46:27 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rDgg1-000UfaC; Fri, 2 Dec 94 14:42 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rDgg1-000twfC; Fri, 2 Dec 94 14:42 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 2 Dec 94 14:42:04 PST Date: Fri, 2 Dec 94 14:42:04 PST From: Derrick Duehren Message-Id: <941202144204_1@ccm.hf.intel.com> To: Jerry_Budelman@ccm2.jf.intel.com, Randy_L_Wilhelm@ccm.fm.intel.com, IBIS@vhdl.org Subject: IBIS 11/18/94 Meeting Minutes Text item: Text_1 Date: Dec. 2, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum Meeting 10/28/94 To: AT&T Global Info Systems Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec Dileep Divkar* Digital Equipment Corp. Barry Katz* EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HyperLynx Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, Hoa Quoc, John Burnett INCASES Werner Rissiek, Olaf Rethmeier* Integrated Silicon Systems Eric Bracken* Integrity Engineering Greg Doyle Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren Interconnectix, Inc. Bob Ross*, Scott Bloom Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal Meta-Software Mei Wong, You-Pang Wei, John Sliney NEC Hiroshi Matsumoto MicroSim Arthur Wong National Semiconductor Syed Huq North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn PC Ware Paul Munsey*, Ron Neville* Quad Design Jon Powell Quantic Labs Mike Ventham Racal-Redac John Berrie Stanford University Randy Harr Stree Co. Mon Seng(sp?) Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zeelan Technology George Opsahl*, Hiro Moriyasu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 12/9/94 (916) 356-9999 406224 ** 2.1 RATIFICATION! ** All meetings are 8:00 AM to 10:00 AM PDT (16:00 to 18:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. NOTE: "AR" = Action Required. ------------------------------------------------------------------------------ Many thanks to Bob Ross for taking the notes for this set of meeting minutes. :-) Check-in, Intros, Announcements Dileep Divekar is now representing Contec. There were no corrections made to last month's minutes. To date eight companies have paid for the Version 2.0. We need 10 to pay fully for the Golden Parser development work. New Agenda Items: IBIS Information Technical Net Relocating L_fixture Update Cookbook and Overview documents IBIS model revision level numbering system (Later) Phase in of IBIS feature priorities. Press Updates: Will and Derrick have an outstanding AR to draft a press release with current status. No progress made has been made, but they plan to have a draft ready for discussion/approval at the 12/9/94 meeting. Progress toward enlisting new IC vendors Kellee has provided Xilinx with a set of models. Xilinx has agreed to release models that they develop to the public domain. IBIS Model generation activity is reported at Triquint Semiconductor and IBM. Bob Ross provided feedback to Syed at National on Differential Models. Golden Parser, 2.0 Paul and Ron both feel that the parser is close to completion. The Beta Version "b" of 2.0 parser has been distributed by Will. Everyone reported some difficulty in getting it compiled on non-DOS systems and there is possibly one file name error in an INCLUDE statement (s.tmp_name should have been s_temp file_name). Dave Moxley got it to compile on HP. Bob Ross compiled it on Sun, it works fine. Stephen hasn't succeeded in compiling it, and hasn't spent much time on it. Barry is in the same space-- typedefs and include file problems. AR - Everyone report to Paul and Ron any source code errors preventing compilation. The Email address is in the README file. Paul and Ron are getting an updated UNIX system and may be able to provide a make file for future releases. Bob Ross and Kellee report old problems have been fixed and no new problems have appeared. However, a Monotonicity warning message is now printed for every line for a non-monotonic table. One message per table is what was intended. Paul and Ron intend to fix this. Kellee re-ran everything he had before, and everything that was broken was fixed. The new IBISCHK2 still did not work on the large IBIS file test case on a DOS386 machine. However, Paul indicated that his revised code now works. The issue of sizing was discussed and a number of large file test cases were proposed for DOS systems with large files. Ideally, we should test the following cases with ibis_chk on: 100 - 20pin components, 1 model per component 1 - 1000 pin component .... The DEC Alpha chip has about 500 pins. Paul is doing these sizing tests. It is reasonable to assume that components will have 1000-2000 pins, with 25 models in 5 years in the future. Possible memory extension software was discussed, especially from Pfar Lap and Rational. Cost of Phar Lap is a problem for free distribution. Watcom has an extender, but it isn't too good. 5% of machines have this problem. Kellee can compile a Win32s version that does not have memory problems. There are two restrictions on win32-- need windows and win32s would have to be distributed with the parser. It is free but is 1.5 meg, implying multiple disks. Memory limitations could be solved on a company-by-company basis as needed. Large IBIS design files can be partitioned into smaller files as a last resort. A minimum machine was discussed. Code will work on 8088 - DOS systems, but 386, 4M, DOS 5.0 was presented as an acceptable minimum level. Some people have less than 4M of memory on home systems. AR - All. Stephen wants more people to do testing based on the Test Matrix, especially in untested areas. The package model area has limited testing. Stephen suggests that we should have a couple of tests: One 500-pin model with 25 models, and one with 100 separate components in a file. Kellee would like to see a 100-pin model. $ for additional features. Monotonicity and incorporating new BIRDs were discussed in the context that the IBISCHK2 project is growing in size. Paul and Ron indicated that they are comfortable with the current changes, although they have taken more time than anticipated. Some pending changes include: o Monotonicity - already fixed (not sure if he implemented it correctly) o DOS and UNIX file compatibility (control-M) Paul and Ron will investigate and report on impact of fix. (may be small, but could grow) o Case sensitivity - not done, but may take time going though 50 files. This BIRD was later rejected. Paul agreed to estimate the cost of implementing new BIRDs. The Version number of the Parser appears as the first line. We would like the first line to indicate this is a "BETA" version of the parser so that it will not be confused with the final version. AR - Arpad to notify Paul of first-line change. AR - Intel and National. What are critical the features needed by vendors in CAE systems supporting Version 2.1? Post them to the reflector before the 12/9/94 meeting. BIRD20, Monotonicity Clarification and Error Reporting APPROVED, but with the text revised in the last two paragraphs as shown: An IBIS syntax checking program shall test for non-monotonic data and provide a maximum of one note per V/I table if non-monotomic data is found. For example: "NOTE: Line 300, Pulldown V/I table for model DC040403 is non-monotonic! Most simulators will filter this data to remove the non-monotonic data." * It is also recognized that the 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 IBIS Version 2.x syntax checking programs, such programs will conduct Monotonicity testing only on one V/I table at a time. BIRD21, Minimum of 2 Entries in Waveform tables. APPROVED. AR - Bob Ross. Generate BIRD23 bringing language in line with V/I table minimum of 2-entry limitations where the first and last entry must not be an "NA" in the typical column. BIRD23 approval/ratification is expected 12/9/94. BIRD22, Subparameters not Case Insensitive. REJECTED. This is a good change for some future version, but making the case insensitivity change would present a significant risk of error to bring the IBISCHK2 parser in line with the specification because nearly all, if not all, 50 ibis_chk source files would have to be edited. The parser itself can be used effectively to identify and correct any case sensitivity violations, so while case sensitivity is an annoyance, it does not pose any limitation. Note that BIRD16 was also killed/rejected. IBIS General Session (face-to-face) Will had earlier proposed that we have our next face-to-face meeting in early December in San Jose to cover EIA affiliation and technology presentations. After some discussion and realizing conflicts with vacation dates, the Summit meeting will be scheduled in January. We discussed the decoupling of Version 2.1 ratification from EIA specification activities. The DIE committee meeting will be held Thursday and Friday, December 15 and 16. Their agenda includes EIA affiliation. The probability is low that the IBIS/EIA processes could go quickly enough to qualify for any ARPA funding, even with a December meeting. AR - Derrick arrange date/time/place for January meeting. Possible technical sessions were discussed since some very interesting material was presented last year. Possible topics include some work by Arpad on equation-based formulation of min and max tables and also on some transmission line measurement techniques, Stephen on alternative package models, and some re-presentation of last year's sessions. AR - All please submit to Will and Derrick: o What you would like to hear about o If you are considering making a presentation, what the talk is about and how long L_fixture location: L_fixture location, originally raised by Kumar, was discussed. General consensus was that there was not a compelling reason to change IBIS at this time. In fact, there may be some advantage with the current location regarding simplified, distributed line model of fixture parasitics. The appropriate mechanism for continuing this issue with the intention of modifying the specification would be through the BIRD process. Technical Information Network Will is getting a lot of detailed, technical questions rather than just the requests for IBIS information, and needs a process to respond. One process suggested was to forward the questions to the IBIS reflector for anyone interested to provide a response. New issues and concerns would then become visible. Will also noted that IBIS has been discussed on the Signal Integrity reflector, and it was suggested that questions could also be forwarded there. Wrap-up, Next Meeting Plans Our next meeting is 12/9/94. The major agenda item is ratifying IBIS Version 2.1. AR - Bob Ross/Derrick, Send to Reflector and also Post on vhdl.org a Version 2.1 DRAFT containing all of the BIRDs resolved to Date. [DONE] Also, on the agenda: Cookbook and Overview update, EIA affiliation, press release (an old AR of Will/Derrick), naming structure, and revision levels. AR - Arpad, submit a raw EGG on revision levels. (Note that IBIS 2.0 already contains a recommendation.) ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From bob@icx.com Fri Dec 2 15:12:02 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15541; Fri, 2 Dec 94 15:12:02 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 2 Dec 94 14:54 PST Message-Id: Date: Fri, 2 Dec 94 14:54 PST From: bob@icx.com ( Bob Ross) To: 73053.721@icx.com, ibis@vhdl.org Subject: ibischk2-b feedback Paul: I did a quick check of the parser, and here are a few problems: (1) The [Pin Mapping] table should NOT accept "NA", but only "NC". (2) While not specified, the [Diff Pin] table should flag as an error any occurance of duplicate pin numbers. Duplicate pin numbers are meaningless in this context. (3) The Terminator model should NOT report when the "terminator" keywords are omitted. (4) The program should test that BOTH [Rac] and [Cac] are included if one is included. From the testing so far the program is functioning VERY WELL. Bob Ross, Interconnectix, Inc. From bob@icx.com Fri Dec 2 15:16:08 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15591; Fri, 2 Dec 94 15:16:08 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 2 Dec 94 14:58 PST Message-Id: Date: Fri, 2 Dec 94 14:58 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: TEST MATRIX UPDATE Hello Fellow IBISans: Here is an update of the Test Matrix with tests I have done. Other than a few minor bugs, the parser is really looking good. I have not looked at the coupled package model features yet. Bob Ross, Interconnectix, Inc A TEST MATRIX FOR IBIS VERSION 2.x DATE: 10/31/94, 12/2/94 SPECIFICATION TESTED PASS Comments/who tested --------------------------------------+-----+-----------------------------+ Test that the parser only | | | accepts 1.0, 1.1, 2.0, 2.1 as | | | valid arguments to the [IBIS Ver] | yes | Stephen Peters | keyword. | | | | | | --------------------------------------+-----+-----------------------------+ Scaling Factors: | | | | | | Test that the parser recognizes | | | "T", "G" and "f" as valid scaling | yes | No indication either way | factors. | | Bob Ross - this is proper | | | operation | Test that the parser does not | | | recognize "t", "g" and "F" as | yes | No indication either way | Valid scaling factors. | | Bob Ross - proper operation | | | | --------------------------------------+-----+-----------------------------+ Keywords rules: | | | | | | Test that the parser recognizes | | | the [GND clamp] and [PWR clamp] | yes | Stephen Peters | keywords without the underscore. | | | Test Underscore rule for 3-word | yes | Bob Ross | Keyoreds - all 4 cases. | | | | | | Test that the parser issues an | | | error if a keyword does not begin | yes | Stephen Peters | in column 1. | | | | | | Test case insensitivity of all | | | keywords, reserved words and | yes | Pin mapping keyword does not| sub-parameters | | recognize "power" and "gnd" | | | Bob Ross - OK, should be | | | "pulldown_ref", "pullup_ref,| | | "gnd_clamp_ref", and | | | "power_clamp_ref" | | | | --------------------------------------+-----+-----------------------------+ Comments and Notes: | | | | | | Test that the parser does not | | | accept "+" and "-" as valid | yes | Stephen Peters | comment characters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Copyright] keyword. | | | | | | | | | --------------------------------------+-----+-----------------------------+ Component keyword related: | | | | | | Test that the parser issues an | | | error if the [Component] keyword | yes | Stephen Peters | has no component name after it. | | | | | | Test that the parser issues a warning | | | if the component name contains blanks | yes | Stephen Peters | | | | Test the component name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | " | parser fails if name > 40 characters | yes | " | | | | Test that the parser issues an | | | error if the [Manufacture] keyword | yes | Stephen Peters | has no Manufactures name after it. | | | | | | Test the Manufactures name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | Stephen Peters | parser fails if name > 40 characters | yes | Stephen Peters | | | | Test that an .ibs file can contain | yes | Bob Ross | more than one [Component] keyword | | | and component description. | | | | | | --------------------------------------+-----+-----------------------------+ Pin keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin] keyword. | | | | | | Test that the parser issues a | | | error when every model_name does | yes | Bob Ross | not have a corresponding model | | (I don't see the problem) | defined. | | | | | | Test the "3 column or 6 column" | | | rule. | yes | Stephen Peters | | | | Test that the parser issues an error | | | when non-numeric data is in the pin | yes | Stephen Peters | data columns | | | --------------------------------------+-----+-----------------------------+ Package Model related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Package Model] keyword. | | | | | | Test the package model name length | | | rules | | | parser accepts name < 40 characters | no | Name is taken as a DOS file | parser accepts name = 40 characters | no | name and not as argument to | parser fails if name > 40 characters | no | the [Define Package Model] | | | keyword | Verify that the parser issues an | | | error if it cannot find: | | | | | | 1. A [Define Package Model] keyword | | | that has the same argument as the | | | [Package Model] keyword or | | | | | | 2. An external .pkg file that has | | | a [Define Package Model] keyword | | | with has the same argument as the | | | [Package Model] keyword. | | | | | | Test that the parser recognizes all | | | keywords in the package model | | | description: | | | [Define Package Model] | | | [Manufacturer] | | | [OEM] | | | [Description] | | | [Number of Pins] | | | [Pin Numbers] | | | [Model Data] | | | [Resistance Matrix] | | | [Inductance Matrix] | | | [Capacitance Matrix] | | | [Bandwidth] | | | [Row] | | | [End Model Data] | | | [End Package Data] | | | | | | --------------------------------------+-----+-----------------------------+ Pin Mapping keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin Mapping] keyword. | | | | | | Test that the parser issues an | | | error if every pin listed in the | yes | Bob Ross - fixed | [Pin] keyword does not have an | | | entry in the [Pin Mapping] table | | | | | | Test the "3 column or 5 column" | yes | Stephen Peters | rule. | | | | | | Test that NC is a valid entry | | | in a column. | yes | Stephen Peters | | | | Test that each unique entry label | | | must connect to at least one pin | | | whose model name is POWER or GND | yes | Stephen Peters | | | | Test that NA is NOT a valid | | | column entry | NO | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Diff Pin keyword related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Diff Pin] keyword. | | | | | | Test that the parser recognizes | yes | Bob Ross | the 5 associated sub-parameters | | | | | | Test the "4 column or 6 column" | yes | Bob Ross | rule. | | | | | | Test that NC is NOT a valid | yes | Bob Ross | column entry. | | | | | | Test that NA is a valid column | yes | Bob Ross | entry. | | | | | | Reports error for duplicate pin | NO | Bob Ross | numbers. | | | | | | --------------------------------------+-----+-----------------------------+ [Model] keyword: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Model] keyword. | | | | | | Test that the parser recognizes | | | each Model_type: | | | Input | yes | Bob Ross | Output | yes | | I/O | yes | | 3-state | yes | | Open_drain | yes | | I/O_open_drain | yes | | Open_sink | yes | | I/O_open_sink | yes | | Open_source | yes | | I/O_open_source | yes | | Input_ECL | yes | | Output_ECL | yes | | I/O_ECL | yes | | Terminator | yes | | | | | Test that the parser issues | | | a warning if an input type model | yes | Stephen Peters | does not have Vinh or Vinl defined. | | | For All I/O_* cases. | yes | Bob Ross | | | | | | | Test that the parser issues an | | | error if the Model_type or C_comp | yes | Stephen Peters | sub-parameters are missing. | | | | | | Test that the parser accepts a | | | [Model] description with only the | | | Model_type and C_comp sub-params | yes | Stephen Peters | defined. | | | | | | Test that the parser allows NA in | | | the min and max columns only of the | yes | Stephen Peters | C_Comp sub-parameter. | | | | | | Test that the parser allows only | | | Non-inverting and Inverting as | yes | Stephen Peters | choices for the Polarity sub-param | | | | | | Test that the parser allows only | | | Active-High and Active-Low as | yes | Stephen Peters | choices for the Enable sub-param | | | | | | Test that the parser recognizes | | | the Vmeas, Cref, Rref and Vref | yes | Stephen Peters | sub-parameters. | | | | | | --------------------------------------+-----+-----------------------------+ Temperature keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Temperature Range] keyword | | | | | | --------------------------------------+-----+-----------------------------+ Power supply rail related: | | | | | | Test that the parser recognizes | | | the supply rail keywords | | | [Voltage Range] | yes | Stephen Peters | [Pullup Reference] | " | | [Pulldown Reference] | " | | [POWER Clamp Reference] | " | | [GND Clamp Reference] | " | | | | | Test that the parser issues an | | | error if the [Voltage Range] | | | keyword is absent and all four of | | | the other supply rail keywords are | yes | Stephen Peters | NOT present. | | | | | | --------------------------------------+-----+-----------------------------+ I/V table related: | | | | | | Test that the parser recognizes | | | the [Pullup], [Pulldown], [GND | yes | Stephen Peters | Clamp] and [Power Clamp] keywords. | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | Test that the parser issues an | yes | Bob Ross | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Stephen Peters | than two points. | | | | | | Test that the parser issues a | yes | Bob Ross, but too many | warning if non-monotonic data | | | is found. | | | Test for One Warning per Column | NO | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Terminator related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Rgnd], [Rpower], [Rac] and | | | [Cac] keywords. | | | | | | Test if [Rac], then [Cac] req'd. | NO | Bob Ross | | | | Test if [Cac], then [Rac] req'd. | NO | Bob Ross | | | | Test if parser issues an error with | | | above keywords AND Model_type is NOT | yes | Bob Ross | Terminator. | | | | | | Test that parser DOES NOT issue an | NO | Bob Ross | error if avote models are NOT | | | defined. (Clamps or no components | | | can also be "Terminators") | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | --------------------------------------+-----+-----------------------------+ Ramp keyword related: | | | | | | Test that the parser recognizes | | | the [Ramp] keyword and the | yes | Stephen Peters | dv/dt_r and dv/dt_f sub-parameters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the R_load sub-parameter. | | | | | | Test that the R_load sub-parameter | yes | Stephen Peters | is optional. | | | | | | --------------------------------------+-----+-----------------------------+ Waveform Related: | | | | | | Test that the parser recognizes | | | the [Rising Waveform] and [Falling | yes | Bob Ross | Waveform] keywords. | | | | | | Test that the parser recognizes | | | the sub-parameters: | | | R_fixture | yes | Bob Ross | V_fixture | yes | | V_fixture_max | yes | | V_fixture_min | yes | | C_fixture | yes | | L_fixture | yes | | R_dut | yes | | L_dut | yes | | C_dut | yes | | | | | Test that the parser issues an | | | error if the R_fixture and | yes | Bob Ross | V_fixture sub-parameters are not | | | present. | | | | | | Test that the parser issues an | | | error if a column contains over | yes | Bob Ross | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | NO | Bob Ross - Pending BIRD | than two points. | | | --------------------------------------+-----+-----------------------------+ From bob@icx.com Sat Dec 3 17:12:08 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27317; Sat, 3 Dec 94 17:12:08 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 3 Dec 94 16:54 PST Message-Id: Date: Sat, 3 Dec 94 16:54 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS VER2.1 COMMENT To Committee: Here is one correction and two suggested changes to the IBIS Version 2.1 document to be voted: (1) Change the following text: |* either Non-inverting or Inverting, and the Enable sub- | parameter can be defined as either Active-high or Active-low. | to: |* either Non-Inverting or Inverting, and the Enable sub- |* parameter can be defined as either Active-High or Active-Low. | since the subparameters are case sensitive. (2) In the Package Model Example, I suggest changing the [IBIS Ver] and [Date] as follows: *[IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 *[Date] December 9, 1994 Bob Ross Interconnectix, Inc. From Arpad_Muranyi@ccm.fm.intel.com Mon Dec 5 08:31:56 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20660; Mon, 5 Dec 94 08:31:56 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rEgG2-000UfPC; Mon, 5 Dec 94 08:27 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rEgG2-000txtC; Mon, 5 Dec 94 08:27 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 5 Dec 94 08:27:22 PST Date: Mon, 5 Dec 94 08:27:22 PST From: Arpad Muranyi Message-Id: <941205082722_6@ccm.hf.intel.com> To: ibis@vhdl.org Subject: EGG not to be hatched... Text item: Text_1 Hi IBIS folk, I had an AR from the last IBIS Open Forum to write an EGG on the IBIS model file revision level number usage. However, I realized that it has already been written down in the IBIS1.1 spec under the [File Rev} keyword section, which I completely forgot about. So I suggest to drop this EGG so that it would not hatch... Arpad Muranyi Intel Corporation From jperry@cadence.com Mon Dec 5 10:25:07 1994 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21533; Mon, 5 Dec 94 10:25:07 PST Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA09648 for ; Mon, 5 Dec 1994 10:20:44 -0800 Received: from cds9258.cadence.com(158.140.32.4) by mailgate.cadence.com via smap (V1.0mjr) id sma009582; Mon Dec 5 10:20:22 1994 Received: from [158.140.56.237] ([158.140.56.237]) by cds9258.cadence.com (8.6.8/8.6.8) with SMTP id KAA04041 for ; Mon, 5 Dec 1994 10:20:19 -0800 Message-Id: <199412051820.KAA04041@cds9258.cadence.com> Date: Mon, 5 Dec 1994 10:20:53 -0800 To: ibis@vhdl.org From: jperry@cadence.com (John Perry) X-Sender: jperry@cds9258 Subject: IBIS parser whereabouts Folks: I understand there is a parser for IBIS to check validity of model against the spec. Does anyone know where the code (ver 1.1) is located? Thanks, John Regards, John Perry Cadence Design Systems, 2655 Seely Drive, MS 7B1, San Jose, CA 95134 408-428-5022 office 408-894-3484 FAX Internet EMail - jperry@cadence.com From Derrick_Duehren@ccm2.jf.intel.com Mon Dec 5 10:50:53 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21712; Mon, 5 Dec 94 10:50:53 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rEiQL-000UgbC; Mon, 5 Dec 94 10:46 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rEiQL-000txgC; Mon, 5 Dec 94 10:46 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 5 Dec 94 10:46:08 PST Date: Mon, 5 Dec 94 10:46:08 PST From: Derrick Duehren Message-Id: <941205104608_3@ccm.jf.intel.com> To: bob@icx.com, ibis@vhdl.org Subject: Re: IBIS VER2.1 COMMENT >> 2_1b Text item: Good catches, Bob. I have captured these changes in my master copy of the spec, attached as ver2_1b.txt. - Derrick ______________________________ Reply Separator _________________________________ Subject: IBIS VER2.1 COMMENT Author: bob@icx.com at SMTPGATE Date: 12/3/94 5:37 PM To Committee: Here is one correction and two suggested changes to the IBIS Version 2.1 document to be voted: (1) Change the following text: |* either Non-inverting or Inverting, and the Enable sub- | parameter can be defined as either Active-high or Active-low. | to: |* either Non-Inverting or Inverting, and the Enable sub- |* parameter can be defined as either Active-High or Active-Low. | since the subparameters are case sensitive. (2) In the Package Model Example, I suggest changing the [IBIS Ver] and [Date] as follows: *[IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 *[Date] December 9, 1994 Bob Ross Interconnectix, Inc. Text item: ver2_1b.txt 12/5/94 10:42A |******************************************************************************* |* This is a draft IBIS version 2.1. It contains IBIS version 2.0 plus changes |* from BIRD18.2, BIRD19.1, BIRD20.1, BIRD21, pending BIRD23, and some text |* updates of dates, case corrections, and minor clarifications. All changes |* from Version 2.0 are marked with an asterisk (*) in the first, second, or |* third column. (Double asterisks indicate changes from pending BIRD23.) |* |* Ratification is expected at the 12/9/94 IBIS Open Forum teleconference. |* Bridge: Res: |* (916) 356-9999 406224 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). |******************************************************************************* |* |============================================================================== |* I/O Buffer Information Specification (IBIS) Version 2.1 (12/9/94) | | IBIS is a standard for electronic behavioral specifications of integrated | circuit input/output analog characteristics. |============================================================================== | 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 2.0 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. | | Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility | with Versions 1.0 and 1.1. All new keywords and elements added in Version | 2.0 are optional. A complete list of changes to the specification is in the | IBIS Version 2.0 Release Notes document ("ver2_0.rn"). | |* Version 2.1 update. The file "ver2_1.ibs" contains clarification text |* changes, corrections, and two additional waveform parameters beyond |* Version 2.0. | |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. 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 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 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) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in sub-parameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, and Henries.) The | parser looks 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). | | 9) 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. | | 10) Currents are considered positive when their direction is into the | component. | | 11) All temperatures are represented in degrees Celsius. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | 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] 2.1 | Used for template variations | |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character 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 is 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: Specifies 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] ver2_1.ibs | |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is 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] [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: These keywords' arguments can contain blanks, and be of | any format. The [Date] keyword argument is limited to a | maximum of 40 characters. | | Because IBIS model writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools should make this information | available. Derivative models should include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative models verbatim. |------------------------------------------------------------------------------ *[Date] 12/09/94 | The latest file revision date | [Source] Put originator and the 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] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | [Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks 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. | | NOTE: Blank characters are not recommended due to usability | issues. |------------------------------------------------------------------------------ [Component] 7403398 MC452 | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies 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] Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines 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: The typical (typ) 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. Use the [Package Model] keyword for more | complex package descriptions. If defined, the [Package Model] | data overrides the values in the [Package] keyword. | Regardless, the data listed under the [Package] keyword must | still contain valid data. |------------------------------------------------------------------------------ [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: Associates 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 | |============================================================================== | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model | Usage Rules: The package model name is limited to 40 characters. | Spaces are allowed in the name. The name should include the | company name or initials to help ensure uniqueness. The | simulator will search for a matching package model name as an | argument to a [Define Package Model] keyword in the current | IBIS file first. If a match is not found, the simulator will | look for a match in an external .pkg file. If the package | model is in a separate .pkg file, it must be kept in the same | directory as the .ibs file. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that part. | The specification permits .ibs files to contain [Define | Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models | that have the same name. |------------------------------------------------------------------------------ [Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Pin Mapping] | Required: No |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. Use the | NC reserved word for entries that are not needed or that follow | the conditions below: | | All entries with identical labels are assumed to be connected. | Each unique entry label must connect to at least one pin whose | model_name is POWER or GRD. | | If a pin has no connection, then both the pulldown_ref | and pullup_ref sub-parameters 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 overridden 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 overridden by a | specification in the power_clamp_ref column. | | The 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 | | When 5 columns are specified, the headings gnd_clamp_ref and | power_clamp_ref must be used. Otherwise, these headings can | be omitted. |--------------------------------------------------------------------------- [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 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 | . 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps | |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |*Usage Rules: Enter only differential pin pairs. The first column, |* [Diff Pin], contains a non-inverting pin number. The second |* column, inv_pin, contains the corresponding inverting pin number |* for I/O output. Each pin number must match the pin |* numbers declared previously in the [Pin] section of the IBIS |* file. The third column, vdiff, contains the specified |* output and 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 forth, fifth, |* and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, |* contain launch delays of the non-inverting pins relative to |* the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes 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, vdiff is 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 is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | 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 is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is 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, Vmeas, Cref, | Rref, Vref | Usage Rules: Each model type 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. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except | for those model names that 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. | | Model_type must be one of the following: | 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. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl=0.8V and Vinh=2.0V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl=-1.475V and Vinh=-1.165V | are assumed. | | Terminator This model type 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, and | pull-up resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | |* 3-state This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | |* Open_sink These model types indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = 0mA | for all voltages specified) and the output | SINKS current. Open_drain model type is | retained for backward compatibility. | | Open_source This model type indicates that the | output has an OPEN side (do not use the | [Pulldown] keyword, or if it must be used, | set I = 0mA for all voltages specified) and | the output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | keyword. | | The Model_type and C_comp sub-parameters are required. The | Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref sub- | parameters are optional. C_comp defines the silicon die | capacitance. This value should not include the capacitance of | the package. C_comp is allowed to use "NA" for the min and max | values only. The Polarity sub-parameter can be defined as |* either Non-inverting or Inverting, and the Enable sub- |* parameter can be defined as either Active-High or Active-Low. | | The Cref and Rref sub-parameters correspond to the test load | that the manufacturer uses when specifying the propagation | delay and/or output switching time of the device. The Vmeas | sub-parameter is the reference voltage level that the | manufacturer uses for the component. Include Cref, Rref, and | Vmeas information to facilitate board-level timing simulation. | The assumed connections for Cref, Rref, and Vref are shown in | the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one | or more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, | some models may have only a subset of 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. |------------------------------------------------------------------------------ | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V |Reference voltage for timing measurements Cref = 50pF |Timing specification test load capacitance value Rref = 500 |Timing specification test load resistance value Vref = 0 |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== | Keyword: [Temperature Range] | Required: Yes, if other than the preferred 0, 50, 100 degree C range | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various V/I curves and ramp rates were | derived. |------------------------------------------------------------------------------ | variable typ min max [Temperature Range] 27.0 -50 130.0 | |============================================================================== | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], | [POWER Clamp Reference], and [GND Clamp Reference] are not | present |Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the pull-up and [POWER Clamp] V/I data is | referenced. |Usage Rules: Provide actual voltages (not percentages) in the 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: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | pull-up V/I data. |Usage Rules: Provide actual voltages (not percentages) in the 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: Defines a power supply rail other than 0V as the reference | voltage for the pull-down V/I data. If this keyword is not | present, the voltage data points in the pull-down V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the 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 typ, 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: Defines 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: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Refer the "Other Notes" section of the [GND Clamp Reference] | keyword. |--------------------------------------------------------------------------- | 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: Defines 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: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Power Supplies: It is intended 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 pull-up, | pull-down, or clamp structure is referenced to something other | than the default supplies, use the additional 'reference' | keywords. | | 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. |---------------------------------------------------------------------------- | variable typ min max [GND Clamp Reference] 0V 0V 0V | |============================================================================== | 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 pull-down and pull-up structures of an output buffer and | the V/I curves of the clamping diodes connected to the GND and | the POWER pins, respectively. 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: 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. (Note: Under these keywords, all | references to 'Vcc' refer to the voltage rail defined by the | [Voltage range], [Pullup Reference], or [POWER Clamp Reference] | keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5V in the table actually | means 5V above Vcc, which is +10V with respect to ground; | and 10V means 10V below Vcc, which is -5V with respect to | ground. Vcc-relative data is necessary to model a pull-up | structure properly, since the output current of a pull-up | 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. | | When tabulating data for ECL devices, the data in the pull-down | 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 | pull-up 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 of | these cases, the data is referenced to the Vcc supply voltage, | using the equation Vtable = Vcc - Voutput. | | Monotonicity Requirements: | 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. | |* An IBIS syntax checking program shall test for non-monotonic |* data and provide a maximum of one note per V/I table if |* non-montonic data is found. For example: |* "NOTE: Line 300, Pulldown V/I table for model DC040403 is |* non-monotonic! Most simulators will filter this data |* to remove the non-monotonic data." |* |* It is also recognized that the 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 IBIS Version 2.x syntax checking programs, such |* programs will conduct monotonicity testing only on one |* V/I table at a time. | | It is assumed that the simulator sums the clamp curves | together with the appropriate pull-up or pull-down 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 pull-up and pull-down 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, with the I/O buffer 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 pull-up and | pull-down 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 can demonstrate a | non-monotonic shape.) This requirement enables 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 cannot be measured alone), the pull-up and | pull-down curves of an IBIS model can 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] | Note: Vtable = Vcc - Voutput | | 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] | Note: Vtable = Vcc - Voutput | | 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 | |============================================================================== | 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 keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max), or the three entries | for 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 coexist with [GND Clamp] |* and [POWER Clamp] structures. If the terminator consists |* of a series R and C (often referred to as either an AC or RC |* terminator), then both [Rac] and [Cac] are required. When | | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | VI | \ Rpower [Package] Keyword | | | / Sub-parameters | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | VI | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp Ref] | | | | | | | o-------------------o----------------------o | | | o | GND |------------------------------------------------------------------------------ | 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 and terminators | Description: Defines the rise and fall times of a buffer. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. | The ramp rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load sub-parameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 2.20/1.06n 1.92/1.28n 2.49/650p dV/dt_f 2.46/1.21n 2.21/1.54n 2.70/770p R_load = 300ohms | |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. |* Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, |* C_fixture, L_fixture, | 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, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are 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. Each |* table must contain at least two entries. Thus, numerical |** values are required for the first and last entries of any |** column containing numerical data. | | 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 Sub-params are analogous to 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 |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- 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. |* |* V_fixture defines the voltage for typ, min, and max |* supply conditions. However, when the fixture voltage |* is related to the power supply voltages, then the |* sub-parameters V_fixture_min and V_fixture_max can |* be used to further specify the fixture voltage for |* min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 *V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc *V_fixture_max = 5.5 |Specified, but not used in this example 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 | |============================================================================= | | PACKAGE MODELING | | The [Package Model] keyword is optional. If more than the default RLC | package model is desired, use the [Define Package Model] keyword. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... | [End Package Model] keywords for each package model that is defined. For | reference, these keywords are listed below. Full descriptions follow. | Simulators that do not support these keywords will ignore all entries between | the [Define Package Model] and [End Package Model] keywords. | | [Define Package Model] Required if the [Package Model] keyword is used |* [Manufacturer] (note 1) |* [OEM] (note 1) |* [Description] (note 1) |* [Number of Pins] (note 1) |* [Pin Numbers] (note 1) |* [Model Data] (note 1) | [Resistance Matrix] Optional |* [Inductance Matrix] (note 1) |* [Capacitance Matrix] (note 1) | [Bandwidth] Required (for Banded_matrix matrices only) |* [Row] (note 1) |* [End Model Data] (note 1) |* [End Package Model] (note 1) | |* (note 1) Required when the [Define Package Model] keyword is used | | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | | USAGE RULES FOR THE .PKG FILE | | Package models are stored in a file whose name looks like: | .pkg. | | The provided must adhere to the General Syntax Rules. Use the | ".pkg" extension to identify files containing package models. The .pkg file | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg | file. The .pkg file is for package models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package | model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes | Description: Declares the manufacturer of the package. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of | what kind of package the [Package Model] is representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |============================================================================== | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the package | pins, and to define an ordering of them. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." The pin names can not exceed 5 characters in | length. | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are | pins (as given by the preceding [Number of Pins].) |------------------------------------------------------------------------------ [Pin Numbers] A1 A2 | . | . | . A22 B1 | . | . | . | etc. | |============================================================================== | Keyword: [Model Data] | Required: Yes | Description: Indicates the beginning of the formatted package model data, | which can include the [Resistance Matrix], [Inductance Matrix], | [Capacitance Matrix], [Bandwidth], and [Row] keywords. |------------------------------------------------------------------------------ [Model Data] | |============================================================================== | Keyword: [End Model Data] | Required: Yes | Description: Indicates the end of the formatted model data. | Other Notes: In between the [Model Data] and [End Model Data] keywords is | the package model data itself. The data is a set of 3 | matrices: the resistance (R), inductance (L), and capacitance | (C) matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords below to mark the | beginning of each new matrix. |------------------------------------------------------------------------------ [End Model Data] | |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The sub-parameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the sub-parameters. | After each of these sub-parameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board | (General Syntax Rule #10). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | | For even a modest-sized package, this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | The first row only needs to specify the entries [1,1] through [1,1+B] since | any other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2, 2+B], and so on. In general, for row M | the entries [M,M] through [M,M+B] are given. | | Unlike the Full_matrix, each successive row will typically have the same | number of entries, except for the last few rows. When M + B finally exceeds | the size of the matrix N, then the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | Also, note that it is again necessarily the case that the N'th | row of an N x N matrix has just a single entry (the diagonal entry.) | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | *[IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 *[Date] December 9, 1994 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor | base its data on typical process data, and then derate by voltage and | temperature, and a proprietary "X%" factor. This methodology also has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | 1) V/I curves for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "X%" | max = maximum voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "X%" | max = maximum voltage, max temp deg C, typical process, plus "X%" | | Nominal, min, and max temperature are specified by the manufacturer | of the part. The default range is 50C nom, 0C min, and 100C max | temperatures. | | X% should be statistically determined by the silicon vendor based | on numerous fab lots, test chips, process controls, etc.. The value | of X need not be published in the IBIS file, and may decrease over | time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | As described in the [Pulldown Reference] keyword section, the V/I curve of | the [Pullup] and the [POWER Clamp] structures are 'Vcc relative', using | the equation: Vtable = Vcc - Voutput. | | For example, a device with a 5V power supply voltage should be | characterized between (0 - 5) = -5V and (5 + 5) = 10V; and a | device with a 3.3V power supply should be characterized between | (0 - 3.3) = -3.3V and (3.3 + 3.3) = 6.6V for the pull-down curve. | | When tabulating output data for ECL type devices, the voltage points | must span the range of Vcc to Vcc - 2.2V. This range applies to both the | pull-up and pull-down tables. Note that this range applies ONLY when | characterizing an ECL output. | | These voltage ranges must be spanned by the IBIS data. Data derived | from lab measurements may not be able to span these ranges as such and | so may need to be extrapolated to cover the full range. This data must | not be left for the simulator to provide. | | 3) Ramp Rates: | The following steps assume that the default load resistance of 50 ohms is | used. There may be devices that will not drive a load of only 50 ohms | into any useful level of dynamics. In these cases, use the manufacturer's | suggested (non-reactive) load and add the load sub parameter to the [Ramp] | specification. | | The ramp rate does not include package and parameters; it is the intrinsic | output stage rise and fall time only. | | The ramp rates (listed in AC characteristics below) should be derived | as follows: | | a. If starting with the silicon model, remove all packaging. If starting | with a packaged device, perform the measurements as outlined below then | use whatever techniques are appropriate to derive the actual, unloaded | rise and fall times. | | b. If: The Model_type is one of the following: Output, I/O, or | 3-state (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | | If: The Model_type is Output_ECL or I/O_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either POWER or the vendor- | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either GND or the vendor-suggested | termination voltage. Use this load to derive both the rising | and falling edges. | | c. Due to the resistor, output swings will not make a full transition as | expected. However the pertinent data can still be collected as | follows: | 1) determine the 20% to 80% voltages of the 50 Ohm swing | 2) measure this voltage change as "dV" | 3) measure the amount of time required to make this swing "dt" | d. Post the value as a ratio "dV/dt". The simulation tool vendor | extrapolates this value to span the required voltage swing range in | the final model. | | e. Typ, Min, and Max must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "Y%" | max = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "Y%" | max = maximum voltage, max temp deg C, typical process, plus "Y%" | | where nominal, min, and max temp are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min, and 100C max | temperatures. | | Note that the derate factor, "Y%", may be different than that used | for the V/I curve data. This factor is similar to the X% factor | described above. As in the case of V/I curves, temperatures are | junction temperatures. | | f. During the IV measurements, the driving waveform should have a | rise/fall time fast enough to avoid thermal feedback. The specific | choice of sweep time is left to the modeling engineer. | | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. IBIS SPEC V2.1 12/1/94 DRAFT k:\ibis\spec\ver2_1a.txt Page 10 Printed: 12/1/94 From scott@icx.com Mon Dec 5 11:08:14 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21811; Mon, 5 Dec 94 11:08:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 5 Dec 94 10:50 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 5 Dec 94 11:05 PST Message-Id: To: ibis@vhdl.org Subject: Where is the inbox? Date: Mon, 05 Dec 1994 11:05:11 -0800 From: Scott Aron Bloom I am trying to find the inbox under the pub/ibis directory on vhdl.org. Does one exist? I am trying to post a DOS version of S2IBIS10.ZIP which I was finally able to get compiled. Also, what is the notification method for telling the SysAdmin for the IBIS directory that the file has been posted? Scott From huq@rockie.nsc.com Mon Dec 5 12:18:34 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22691; Mon, 5 Dec 94 12:18:34 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA22762 for ibis@vhdl.org; Mon, 5 Dec 94 12:14:10 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA11500 for ibis@vhdl.org; Mon, 5 Dec 94 12:14:02 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA01732; Mon, 5 Dec 94 12:16:50 PST Date: Mon, 5 Dec 94 12:16:50 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9412052016.AA01732@rockie.nsc.com> To: ibis@vhdl.org Subject: S2IBIS for v2.0 Hi, Is there any work being done to get S2IBIS for v2.0 released ? I think the current S2IBIS supports v1.1. We have a group at National who are willing to convert their NaSPICE model to IBISv2.0. Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Will_Hobbs@ccm2.jf.intel.com Mon Dec 5 13:27:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23095; Mon, 5 Dec 94 13:27:05 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rEkre-000UfPC; Mon, 5 Dec 94 13:22 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rEkre-000tweC; Mon, 5 Dec 94 13:22 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 5 Dec 94 13:22:30 PST Date: Mon, 5 Dec 94 13:22:30 PST From: Will Hobbs Message-Id: <941205132230_8@ccm.jf.intel.com> To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: S2IBIS for v2.0 Text item: Syed, Good question. It goes along with my question about updating the IBIS Overview document and the IBIS Cookbook, both of which were done for IBIS V1.1 as a voluntary effort. I will not have the time to devote to an update of either one in the foreseeable future. l'll add these questions to this week's agenda. Regards, Will Hobbs Intel Corp. Is there any work being done to get S2IBIS for v2.0 released ? I think the current S2IBIS supports v1.1. We have a group at National who are willing to convert their NaSPICE model to IBISv2.0. Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: S2IBIS for v2.0 To: ibis@vhdl.org Message-Id: <9412052016.AA01732@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Mon, 5 Dec 94 12:16:50 PST Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA01732; Mon, 5 Dec 94 12:16:50 PST Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA11500 for ibis@vhdl.org; Mon, 5 Dec 94 12:14:02 -0800 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA22762 for ibis@vhdl.org; Mon, 5 Dec 94 12:14:10 -0800 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22691; Mon, 5 Dec 94 12:18:34 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 5 Dec 94 12: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 5 Dec 94 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rEkLW-000twvC; Mon, 5 Dec 94 12:49 PST From speters@ichips.intel.com Mon Dec 5 13:28:44 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23100; Mon, 5 Dec 94 13:28:44 PST Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Mon, 5 Dec 94 13:22:36 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 5 Dec 94 12:51:55 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 5 Dec 94 12:58:13 PST Message-Id: <9412052058.AA08831@xtg801.intel.com> To: ibis@vhdl.org Cc: jperry@cadence.com Subject: IBIS parser whereabouts Date: Mon, 05 Dec 1994 12:58:12 -0800 From: Stephen Peters Hello John: ftp to the machine vhdl.org (198.31.14.3). The executables are located in "/pub/ibis/ver1.1/exec" Regards, Stephen Peters Intel Corp. From mbs@eos.ncsu.edu Mon Dec 5 13:49:06 1994 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23261; Mon, 5 Dec 94 13:49:06 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA05859; Mon, 5 Dec 1994 16:42:58 -0500 From: mbs@eos.ncsu.edu Message-Id: <9412052142.AA05859@mbs.ece.ncsu.edu> To: huq@rockie.nsc.com (Syed Huq) To: ibis@vhdl.org Subject: Re: S2IBIS for v2.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Dec 94 16:42:58 EST Folks, We (North Carolina State University) are interested in doing this work but it willl require some funding. We are hoping to convince ARPA to get involved but no news yet. (ARPA funded the original vresion 1.1. work which was done along the way to designing/building an MCM system. There are some unresolved issues in S2IBIS version 1.1 we are hoping to address early in the next year. CADENCE has agreed (well almost) to supporting the enhancement of S2IBIS version 1.1 to make it more usable. I am afraid that version 2.0 will have to wait. Michael > Hi, > > Is there any work being done to get S2IBIS for v2.0 released ? > I think the current S2IBIS supports v1.1. > > We have a group at National who are willing to convert their > NaSPICE model to IBISv2.0. > > Regards, > Syed. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Syed B. Huq > Applications Engineer/Data Transmission Products > National Semiconductor > Tel:(408)721-4874; Fax:(408)721-4785 > Internet:huq@rockie.nsc.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ***************************************************************************** Dr. Michael Steer mbs@ncsu.edu Associate Professor 919-515-5191 Electrical and Computer Engineering Department 919-515-5523 (fax) North Carolina State University, Raleigh, NC 27695-7911 From Derrick_Duehren@ccm2.jf.intel.com Mon Dec 5 15:22:40 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23815; Mon, 5 Dec 94 15:22:40 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rEmfY-000UgNC; Mon, 5 Dec 94 15:18 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rEmfW-000twnC; Mon, 5 Dec 94 15:18 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 5 Dec 94 15:18:05 PST Date: Mon, 5 Dec 94 15:18:05 PST From: Derrick Duehren Message-Id: <941205151805_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 12/9/94 Meeting AGENDA Text item: Text_1 IBIS Open Forum Meeting Agenda for 12/9/94 Bridge: Res: (916) 356-9999 406224 All meetings are 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes (and ARs) - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available 8:20 Progress toward enlisting new IC vendors All Golden Parser, 2.1 Hobbs BIRD 23 ratification Ross 8:40 IBIS Spec Rev 2.1 ratification Hobbs 9:30 IBIS General Session/Summit (face-to-face) Hobbs Rev 2.1 updates Hobbs o S2IBIS 2.1? o Cookbook? o Overview? 9:55 Wrap-up, next meeting plans Hobbs From 71436.1314@compuserve.com Tue Dec 6 06:54:19 1994 Return-Path: <71436.1314@compuserve.com> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02617; Tue, 6 Dec 94 06:54:19 PST Received: by arl-img-2.compuserve.com (8.6.9/5.940406sam) id JAA13942; Tue, 6 Dec 1994 09:49:56 -0500 Date: 05 Dec 94 23:05:49 EST From: Kellee Crisafulli <71436.1314@compuserve.com> To: IBIS ALL Subject: IBIS SUMMIT next year, From: Kellee Crisafulli Message-Id: <941206040548_71436.1314_HHB59-1@CompuServe.COM> Bob I saw your Email, and I am also very interested in your items 1 and 4. (1) More details on the diode stored charge effects in clamping circuits and how to model. (4) More details on possible simplified package models with coupling and delay. I feel that the diodes are a very badly needed improvement to the specification. Many of the devices out there don't exhibit the instant turn-on times implied by the present IBIS specification. This has little effect on CMOS output buffers but has dramatic effect on all types of input buffers. Termination effects may be much more pronounced in a real circuit than simulators are showing. I would like to see something very simple to start with. Perhaps a turn on curve of percent ON versus time, where the percent on is relative to the diode current in the table. This could be a simple "turn-on-time". Another approach might be to use more of a real charge storage model. The trick is to make it measurable with device testers, and keep the amount of information that needs to be collected and simulated as small as possible. As IBIS models get larger the simulation speed goes down. Kellee Crisafulli, HyperLynx Inc. From Will_Hobbs@ccm2.jf.intel.com Tue Dec 6 11:56:56 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04739; Tue, 6 Dec 94 11:56:56 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rF5w0-000Uf8C; Tue, 6 Dec 94 11:52 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rF5w0-000txsC; Tue, 6 Dec 94 11:52 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 6 Dec 94 11:52:24 PST Date: Tue, 6 Dec 94 11:52:24 PST From: Will Hobbs Message-Id: <941206115224_2@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Bird 24, on C_comp, ramp rates and waveform tables Text item: Hello All: While exchanging e-mail with Kumar on the subject of waveform tables we realized that the spec makes no mention of the fact that the data for the waveform table is supposed to be taken with C_comp = 0. In fact the spec is not very clear about this with regards to the ramp rate either. Here is a proposed bird to take care of this. I hope we can get this in for ver 2.1 ratification Friday. Regards, Stephen Peters Intel Corp. ************************************************************ BIRD ID#: 24 ISSUE TITLE: C_comp, ramp rates and waveform tables REQUESTOR: Stephen Peters DATE SUBMITTED: Dec, 6, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ********************************************************* ********************************************************* STATEMENT OF THE ISSUE: The spec does not clearly state that the ramp rate numbers and the data in the waveform tables are to be taken with C_comp = 0. ********************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The specification is changed in three places. The first is in the 'NOTES ON DATA DERIVATION METHOD' section under Ramp Rates. The second paragraph is modified to read as follows: "The ramp rate does not include packaging and the C_comp parameter; it is the intrinsic output stage rise and fall time only." In the section of the spec describing the [Ramp] keyword the following statement is added after the first sentence of the description: "The ramp rate is measured with C_comp = 0." Likewise, the section describing the [Rising Waveform], [Falling Waveform] keywords would also be modified to add the following at the end of the first paragraph: "As with the [Ramp] Keyword, the data in the waveform tables is taken with C_comp = 0." ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: While exchanging e-mail with Kumar on the subject of waveform tables we realized that the spec makes no mention of the fact that the data for the waveform table is supposed to be taken with C_comp = 0. In fact the spec is not very clear about this with regards to the ramp rate either. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: Stephen Peters Date: Tue, 06 Dec 1994 09:56:00 -0800 Subject: Bird on C_comp, ramp rates and waveform tables Cc: speters@ichips.intel.com To: Will_Hobbs@ccm2.jf.intel.com Message-Id: <9412061756.AA12600@xtg801.intel.com> Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 6 Dec 94 09:56:01 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 6 Dec 94 09:49:27 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rF47R-000txIC; Tue, 6 Dec 94 09:56 PST From bob@icx.com Tue Dec 6 18:55:38 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07324; Tue, 6 Dec 94 18:55:38 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Dec 94 18:37 PST Message-Id: Date: Tue, 6 Dec 94 18:37 PST From: bob@icx.com ( Bob Ross) To: 71436.1314@compuserve.com, ibis@vhdl.org Subject: Re: IBIS SUMMIT next year, From: Kellee Crisafulli Kellee, I notice that the 1994 Pentium book, a clamping diode is now represented as an equivalent Spice formatted diode with "TT" for transit time. This may be the critical item necessary for correct turn-on specification and it is up to simulator companies to provide the "delayed" reaction in an appropriate manner. However, I am also interested in more discussion for better understanding and to sort out all the options. Bob Ross, Interconnectix, Inc. > Bob I saw your Email, and I am also very interested in your items 1 and 4. > (1) More details on the diode stored charge effects in clamping circuits and > how to model. > (4) More details on possible simplified package models with coupling and > delay. > I feel that the diodes are a very badly needed improvement to the specification. > Many of the devices out there don't exhibit the instant turn-on times implied > by the present IBIS specification. This has little effect on CMOS output buffers > but has dramatic effect on all types of input buffers. Termination effects may be > much more pronounced in a real circuit than simulators are showing. > I would like to see something very simple to start with. Perhaps a turn on curve > of percent ON versus time, where the percent on is relative to the diode current > in the table. This could be a simple "turn-on-time". Another approach might be to > use more of a real charge storage model. The trick is to make it measurable with > device testers, and keep the amount of information that needs to be collected and > simulated as small as possible. As IBIS models get larger the simulation speed goes > down. > Kellee Crisafulli, > HyperLynx Inc. From bob@icx.com Tue Dec 6 19:38:04 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07628; Tue, 6 Dec 94 19:38:04 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Dec 94 19:20 PST Message-Id: Date: Tue, 6 Dec 94 19:20 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD24 COMMENT To Committee: I only agree that there needs to be clarity in IBIS, but I do not support that C_comp = 0 is the mandated test condition for RAMP. I could accept that, but I definitely do not support such a mandate for Waveform Data. My concerns are these: (1) Removing the "effective" C_comp which is USUALLY not obvious cannot and should not be done to any Spice die model. That is a cumbersome process which can introduce unanticipated artifacts and other error. It is also one additional burden on top of a number of complicated processes such as those necessary for encoding Spice models for s2ibis conversions. (2) Responses based on measurements will always contain the effective "C_comp", and IBIS processes should accomodate that situation. So the problem is simple - either data based with C_comp included has to be "transformed" to no-C_comp data, or visa versa. Since C_comp cannot be removed for most cases, inclusion should be the default situation. (3) While I am not able to be specific at this time, I am convinced that the existence of C_comp in the extraction poses no insurmountable technical problem. I believe proper de-embedding techniques can be used, if they are necessary. (4) The Waveform Specification contains the purest form of untampered characterization data which is at the Pin if necessary, or at the Die if the packaging effects can be removed through simulation or die measurement. Under absolutely no condition should this (set of) reference waveforms be corrupted with tampering assumptions such as setting the C_comp to 0. While there may perhaps be inconveniences now, it is the wrong decision for future integrity of IBIS to conclude that such extractions or measurements which include C_comp can not be accurately dealt with in the future. Bob Ross, Interconnectix, Inc. From cpk@Cadence.COM Wed Dec 7 06:32:07 1994 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15684; Wed, 7 Dec 94 06:32:07 PST Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA16011; Wed, 7 Dec 1994 06:27:43 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma015993; Wed Dec 7 06:27:27 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA01900; Wed, 7 Dec 94 06:26:32 -0800 Received: by hot (5.65+/1.5) id AA12235; Wed, 7 Dec 94 09:27:20 -0500 Date: Wed, 7 Dec 94 09:27:20 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9412071427.AA12235@hot> To: ibis@vhdl.org, bob@icx.com Subject: Re: BIRD24 COMMENT This raises an interesting point. How reliable is the value of C_comp itself? Anyway I am not in favor any "implied" quantities associated with waveform tables. Every parasitc associated with that wave should be explicitly stated. So for example C_dut can include the effects of C_comp. While I am at it I also want to raise another point regarding ky word Ramp. That specification includes R_load. But there is no provisison for V_load. If we look at the notes on Ramp rates there are situations in which V_load is vendor specified and there is no place in IBIS models where thie information is carried. > > To Committee: > > I only agree that there needs to be clarity in IBIS, but I do not support > that C_comp = 0 is the mandated test condition for RAMP. I could accept > that, but I definitely do not support such a mandate for Waveform Data. > My concerns are these: > > (1) Removing the "effective" C_comp which is USUALLY not obvious cannot > and should not be done to any Spice die model. That is a cumbersome > process which can introduce unanticipated artifacts and other error. It > is also one additional burden on top of a number of complicated processes > such as those necessary for encoding Spice models for s2ibis conversions. > > (2) Responses based on measurements will always contain the effective > "C_comp", and IBIS processes should accomodate that situation. So the > problem is simple - either data based with C_comp included has to be > "transformed" to no-C_comp data, or visa versa. Since C_comp cannot > be removed for most cases, inclusion should be the default situation. > > (3) While I am not able to be specific at this time, I am convinced > that the existence of C_comp in the extraction poses no insurmountable > technical problem. I believe proper de-embedding techniques can be > used, if they are necessary. > > (4) The Waveform Specification contains the purest form of untampered > characterization data which is at the Pin if necessary, or at the Die if > the packaging effects can be removed through simulation or die measurement. > Under absolutely no condition should this (set of) reference waveforms > be corrupted with tampering assumptions such as setting the C_comp to 0. > While there may perhaps be inconveniences now, it is the wrong decision > for future integrity of IBIS to conclude that such extractions or measurements > which include C_comp can not be accurately dealt with in the future. > > Bob Ross, > Interconnectix, Inc. > > > From Arpad_Muranyi@ccm.fm.intel.com Wed Dec 7 09:16:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16855; Wed, 7 Dec 94 09:16:18 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFPtu-000UhzC; Wed, 7 Dec 94 09:11 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFPtt-000txEC; Wed, 7 Dec 94 09:11 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 09:11:33 PST Date: Wed, 7 Dec 94 09:11:33 PST From: Arpad Muranyi Message-Id: <941207091133_11@ccm.hf.intel.com> To: cpk@Cadence.COM, ibis@vhdl.org, bob@icx.com Subject: Re[2]: BIRD24 COMMENT Text item: You are correct in observing that there is no V_load specified in IBIS2.0 with the key word Ramp. To explain what happened here requires a little history. In IBIS1.1 R_load was a fixed 50 Ohm resistor, which was connected to Vcc or GND. (See "Notes on data derivation method" section of IBIS1.1). In IBIS2.0 we added the sup-parameter R_load to the Ramp keyword, because a ramp measurement with a very weak buffer could result in a very small voltage swing which significantly reduces the accuracy of the measurement. Using a different R_load overcomes this problem. This sub-parameter was added for those who want to continue to use the ramp keyword rather than the [Rising Waveform] and [Falling Waveform] keywords provided by IBIS2.0. However, when using the waveform keywords, which are a superset of the Ramp definition, you can have an arbitrary waveform with any R_load and V_load specified. Since a ramp can be considered a special case of a waveform (or V-T) curve (which replace the Ramp keyword), I do not see any reason to retroactively add a V_load specification for Ramp. Arpad Muranyi Intel Corporation This raises an interesting point. How reliable is the value of C_comp itself? Anyway I am not in favor any "implied" quantities associated with waveform tables. Every parasitc associated with that wave should be explicitly stated. So for example C_dut can include the effects of C_comp. While I am at it I also want to raise another point regarding ky word Ramp. That specification includes R_load. But there is no provisison for V_load. If we look at the notes on Ramp rates there are situations in which V_load is vendor specified and there is no place in IBIS models where thie information is carried. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: BIRD24 COMMENT To: ibis@vhdl.org, bob@icx.com Message-Id: <9412071427.AA12235@hot> From: cpk@cadence.com (C. Kumar) Date: Wed, 7 Dec 94 09:27:20 -0500 Received: by hot (5.65+/1.5) id AA12235; Wed, 7 Dec 94 09:27:20 -0500 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA01900; Wed, 7 Dec 94 06:26:32 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma id sma015993; Wed Dec 7 06:27:27 1994 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA1601 Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15684; Wed, 7 Dec 94 06:32:07 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 7 Dec 94 06: Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFNhb-000twwC; Wed, 7 Dec 94 06:50 PST From Will_Hobbs@ccm2.jf.intel.com Wed Dec 7 09:26:24 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16888; Wed, 7 Dec 94 09:26:24 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFQ3H-000UiEC; Wed, 7 Dec 94 09:21 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFQ3H-000txhC; Wed, 7 Dec 94 09:21 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 09:21:15 PST Date: Wed, 7 Dec 94 09:21:15 PST From: Will Hobbs Message-Id: <941207092115_1@ccm.jf.intel.com> To: bob@icx.com, 71436.1314@compuserve.com, ibis@vhdl.org Subject: Re[2]: IBIS SUMMIT next year, From: Kellee Crisafulli Text item: Kellee, Bob, and others of the soverign IBIS Nation, While we're adding to the future wish list, I would like to throw transmission lines into the package spec. A general discussion on the future growth path of IBIS at the summit would be time well spent. Will Kellee, I notice that the 1994 Pentium book, a clamping diode is now represented as an equivalent Spice formatted diode with "TT" for transit time. This may be the critical item necessary for correct turn-on specification and it is up to simulator companies to provide the "delayed" reaction in an appropriate manner. However, I am also interested in more discussion for better understanding and to sort out all the options. Bob Ross, Interconnectix, Inc. > Bob I saw your Email, and I am also very interested in your items 1 and 4. > (1) More details on the diode stored charge effects in clamping circuits and > how to model. > (4) More details on possible simplified package models with coupling and > delay. > I feel that the diodes are a very badly needed improvement to the specification. > Many of the devices out there don't exhibit the instant turn-on times implied > by the present IBIS specification. This has little effect on CMOS output buffers > but has dramatic effect on all types of input buffers. Termination effects may be > much more pronounced in a real circuit than simulators are showing. > I would like to see something very simple to start with. Perhaps a turn on curve > of percent ON versus time, where the percent on is relative to the diode current > in the table. This could be a simple "turn-on-time". Another approach might be to > use more of a real charge storage model. The trick is to make it measurable with > device testers, and keep the amount of information that needs to be collected and > simulated as small as possible. As IBIS models get larger the simulation speed goes > down. > Kellee Crisafulli, > HyperLynx Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: IBIS SUMMIT next year, From: Kellee Crisafulli To: 71436.1314@compuserve.com, ibis@vhdl.org From: bob@icx.com ( Bob Ross) Date: Tue, 6 Dec 94 18:37 PST Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Dec 94 18:37 PST Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07324; Tue, 6 Dec 94 18:55:38 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 6 Dec 94 19: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 6 Dec 94 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFCrq-000twzC; Tue, 6 Dec 94 19:16 PST From cpk@Cadence.COM Wed Dec 7 09:38:52 1994 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16973; Wed, 7 Dec 94 09:38:52 PST Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA01229; Wed, 7 Dec 1994 09:34:24 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma001215; Wed Dec 7 09:34:18 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA12616; Wed, 7 Dec 94 09:33:21 -0800 Received: by hot (5.65+/1.5) id AA12526; Wed, 7 Dec 94 12:34:10 -0500 Date: Wed, 7 Dec 94 12:34:10 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9412071734.AA12526@hot> To: ibis@vhdl.org, bob@icx.com, Arpad_Muranyi@ccm.fm.intel.com Subject: Re: Re[2]: BIRD24 COMMENT If you have the V_Load then you do not need to have waveform tables and you will be able to model limited data more accurately without incurring the overhead of waveform tables(e.g. if the source of the data is data book ). - kumar > > > Text item: > > You are correct in observing that there is no V_load specified in IBIS2.0 with > the key word Ramp. To explain what happened here requires a little history. > > In IBIS1.1 R_load was a fixed 50 Ohm resistor, which was connected to Vcc or > GND. (See "Notes on data derivation method" section of IBIS1.1). In IBIS2.0 we > added the sup-parameter R_load to the Ramp keyword, because a ramp measurement > with a very weak buffer could result in a very small voltage swing which > significantly reduces the accuracy of the measurement. Using a different R_load > overcomes this problem. This sub-parameter was added for those who want to > continue to use the ramp keyword rather than the [Rising Waveform] and [Falling > Waveform] keywords provided by IBIS2.0. > > However, when using the waveform keywords, which are a superset of the Ramp > definition, you can have an arbitrary waveform with any R_load and V_load > specified. Since a ramp can be considered a special case of a waveform (or V-T) > curve (which replace the Ramp keyword), I do not see any reason to retroactively > add a V_load specification for Ramp. > > Arpad Muranyi > Intel Corporation > > > This raises an interesting point. How reliable is the value of C_comp itself? > > Anyway I am not in favor any "implied" quantities associated with waveform > tables. Every parasitc associated with that wave should be explicitly > stated. So for example C_dut can include the effects of C_comp. > > While I am at it I also want to raise another point regarding ky word Ramp. > That specification includes R_load. But there is no provisison for V_load. > > If we look at the notes on Ramp rates there are situations in which V_load is > vendor specified and there is no place in IBIS models where thie information > is > carried. > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > Subject: Re: BIRD24 COMMENT > To: ibis@vhdl.org, bob@icx.com > Message-Id: <9412071427.AA12235@hot> > From: cpk@cadence.com (C. Kumar) > Date: Wed, 7 Dec 94 09:27:20 -0500 > Received: by hot (5.65+/1.5) > id AA12235; Wed, 7 Dec 94 09:27:20 -0500 > Received: from hot by cadence.Cadence.COM (5.61/3.14) > id AA01900; Wed, 7 Dec 94 06:26:32 -0800 > Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma > id sma015993; Wed Dec 7 06:27:27 1994 > Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA1601 > Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) > id AA15684; Wed, 7 Dec 94 06:32:07 PST > Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 7 Dec 94 06: > Received: from hermes.intel.com by relay.jf.intel.com with smtp > (Smail3.1.28.1 #2) id m0rFNhb-000twwC; Wed, 7 Dec 94 06:50 PST > From Will_Hobbs@ccm2.jf.intel.com Wed Dec 7 09:51:07 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17061; Wed, 7 Dec 94 09:51:07 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFQRg-000UgjC; Wed, 7 Dec 94 09:46 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFQRg-000txMC; Wed, 7 Dec 94 09:46 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 09:46:28 PST Date: Wed, 7 Dec 94 09:46:28 PST From: Will Hobbs Message-Id: <941207094628_6@ccm.jf.intel.com> To: bob@icx.com, ibis@vhdl.org Subject: Re: BIRD24 COMMENT Text item: Bob, and others, On reflection, I tend to agree with Bob. In a pure simulation environment, removing C_Comp is not much of a problem, but for those doing IBIS models by measurement, it it exceedingly difficult. I also agree with Bob's comment about the sanctity of the reference wave form. Maybe what is needed is an additional parameter that says whether or not C_Comp was used. E.g. a boolean: C_Comp_in = 1 or 0 (or T or F, etc.) so the simulator correctly interprets the data. If this parameter were not present, we could have a default vale, tbd by the forum. Will To Committee: I only agree that there needs to be clarity in IBIS, but I do not support that C_comp = 0 is the mandated test condition for RAMP. I could accept that, but I definitely do not support such a mandate for Waveform Data. My concerns are these: (1) Removing the "effective" C_comp which is USUALLY not obvious cannot and should not be done to any Spice die model. That is a cumbersome process which can introduce unanticipated artifacts and other error. It is also one additional burden on top of a number of complicated processes such as those necessary for encoding Spice models for s2ibis conversions. (2) Responses based on measurements will always contain the effective "C_comp", and IBIS processes should accomodate that situation. So the problem is simple - either data based with C_comp included has to be "transformed" to no-C_comp data, or visa versa. Since C_comp cannot be removed for most cases, inclusion should be the default situation. (3) While I am not able to be specific at this time, I am convinced that the existence of C_comp in the extraction poses no insurmountable technical problem. I believe proper de-embedding techniques can be used, if they are necessary. (4) The Waveform Specification contains the purest form of untampered characterization data which is at the Pin if necessary, or at the Die if the packaging effects can be removed through simulation or die measurement. Under absolutely no condition should this (set of) reference waveforms be corrupted with tampering assumptions such as setting the C_comp to 0. While there may perhaps be inconveniences now, it is the wrong decision for future integrity of IBIS to conclude that such extractions or measurements which include C_comp can not be accurately dealt with in the future. Bob Ross, Interconnectix, Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: BIRD24 COMMENT To: ibis@vhdl.org From: bob@icx.com ( Bob Ross) Date: Tue, 6 Dec 94 19:20 PST Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Dec 94 19:20 PST Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07628; Tue, 6 Dec 94 19:38:04 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 6 Dec 94 19: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 6 Dec 94 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFDYG-000tx9C; Tue, 6 Dec 94 20:00 PST From Arpad_Muranyi@ccm.fm.intel.com Wed Dec 7 12:15:32 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18200; Wed, 7 Dec 94 12:15:32 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFShT-000UjmC; Wed, 7 Dec 94 12:10 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFShS-000twpC; Wed, 7 Dec 94 12:10 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 12:10:54 PST Date: Wed, 7 Dec 94 12:10:54 PST From: Arpad Muranyi Message-Id: <941207121054_3@ccm.hf.intel.com> To: Will_Hobbs@ccm2.jf.intel.com, bob@icx.com, ibis@vhdl.org Subject: Re[2]: BIRD24 COMMENT Text item: Will, If we follow the boolean trend, we could use it for other things as well. For example, the debate we had around the negative portion of the I-V curves could have been solved with a boolean: Subtract method used = 1 Subtract method not used = 0 That solution might have kept everyone happy, while clearly defining what a curve represents. For consistency sake, I would either not have options like this in an IBIS file at all, or use options everywhere where it could serve a good purpose. In this particular case, I feel that allowing data to be generated both ways would not solve the problem from a simulation tool vendor's view point, since they would have to be able to interpret the data either way. Because of that, they would have to write an algorythm anyways to reverse engineer the pure data from measured data which includes C_comp to accomodate those IBIS models which require that process. So we might as well just make it a rule that "xxxxxx", that's how it should be, period. Arpad Bob, and others, On reflection, I tend to agree with Bob. In a pure simulation environment, removing C_Comp is not much of a problem, but for those doing IBIS models by measurement, it it exceedingly difficult. I also agree with Bob's comment about the sanctity of the reference wave form. Maybe what is needed is an additional parameter that says whether or not C_Comp was used. E.g. a boolean: C_Comp_in = 1 or 0 (or T or F, etc.) so the simulator correctly interprets the data. If this parameter were not present, we could have a default vale, tbd by the forum. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: BIRD24 COMMENT To: ibis@vhdl.org From: bob@icx.com ( Bob Ross) Date: Tue, 6 Dec 94 19:20 PST Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Dec 94 19:20 PST Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07628; Tue, 6 Dec 94 19:38:04 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 6 Dec 94 19: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 6 Dec 94 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFDYG-000tx9C; Tue, 6 Dec 94 20:00 PST Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: BIRD24 COMMENT To: bob@icx.com, ibis@vhdl.org Message-Id: <941207094628_6@ccm.jf.intel.com> From: Will Hobbs Date: Wed, 7 Dec 94 09:46:28 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 09:46:28 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFQRg-000txMC; Wed, 7 Dec 94 09:46 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFQRg-000UgjC; Wed, 7 Dec 94 09:46 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17061; Wed, 7 Dec 94 09:51:07 PST Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA13997; Wed, 7 Dec 94 10:26:01 PST Received: from SSD.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFR45-000tx7C; Wed, 7 Dec 94 10:26 PST From Arpad_Muranyi@ccm.fm.intel.com Wed Dec 7 12:23:44 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18288; Wed, 7 Dec 94 12:23:44 PST Received: from relay.hf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFSoL-000UjyC; Wed, 7 Dec 94 12:18 PST Received: from ccm.hf.intel.com by relay.hf.intel.com (Smail3.1.28.1 #2) id m0rFSoL-000qDMC; Wed, 7 Dec 94 12:18 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 12:18:00 PST Date: Wed, 7 Dec 94 12:18:00 PST From: Arpad Muranyi Message-Id: <941207121800_1@ccm.hf.intel.com> To: cpk@Cadence.COM, ibis@vhdl.org, bob@icx.com Subject: Re[4]: BIRD24 COMMENT Text item: Kumar, Don't take me wrong, I am not against V_load, I just gave you my view of why it did no happen. I see your point, and if everyone agrees we can add it to IBIS2.0. However, "for more accuracy" I would recommend the V-T tables over ramp rates, which were just an approximation to start out with... Arpad If you have the V_Load then you do not need to have waveform tables and you will be able to model limited data more accurately without incurring the overhead of waveform tables(e.g. if the source of the data is data book ). - kumar Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Re[2]: BIRD24 COMMENT To: ibis@vhdl.org, bob@icx.com, Arpad_Muranyi@ccm.fm.intel.com Message-Id: <9412071734.AA12526@hot> From: cpk@cadence.com (C. Kumar) Date: Wed, 7 Dec 94 12:34:10 -0500 Received: by hot (5.65+/1.5) id AA12526; Wed, 7 Dec 94 12:34:10 -0500 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA12616; Wed, 7 Dec 94 09:33:21 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma id sma001215; Wed Dec 7 09:34:18 1994 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA0122 Received: from mailgate.Cadence.COM by hermes.intel.com (5.65/10.0i); Wed, 7 Dec Received: from hermes.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFQLg-000qDNC; Wed, 7 Dec 94 09:40 PST From Will_Hobbs@ccm2.jf.intel.com Wed Dec 7 12:23:50 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18293; Wed, 7 Dec 94 12:23:50 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFSpi-000Uf9C; Wed, 7 Dec 94 12:19 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFSpe-000twtC; Wed, 7 Dec 94 12:19 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 12:19:22 PST Date: Wed, 7 Dec 94 12:19:22 PST From: Will Hobbs Message-Id: <941207121922_2@ccm.jf.intel.com> To: speters@ichips.intel.com, ibis@vhdl.org Subject: Phase-in of IBIS 2.1 functionality Text item: Text_1 Hello fellow IBISians: At the last IBIS Teleconference I took the A/R to post exactly which features of version 2.1 Intel would like to see simulator vendors implement first to support our immediate needs. I also suggested that Syed and representatives of the other IC vendors do the same. For example, Intel is counting heavily on the non-linear ramp support and I am sure that NSC would like to see differential I/O implemented ASAP. The idea is that if EDA vendors have to phase in 2.1 support over time, this will give some guidance on how to prioritize their (your) activities. Stephen Peters provided the following input to help fullfill the AR (thanks Stephen). Following are the Keywords/parameters we feel are required to support Intel's immediate 2.1 needs: 1. Implement the [Rising Waveform] [Falling Waveform] keywords so as to reproduce the waveshape of the output under various loads. This will include recognizing the R_load and V_load parameters as well. 2. As stated in the spec, any derivative model must include the Copyright text verbatim. The text in the Notes section should also be included. 3. Intel files will also include the [Temperature] keyword (for information only. A simulator does not have to use the keyword, but the IBIS model reader should accept it). Regards, Will Hobbs and Stephen Peters Intel Corp. From bob@icx.com Wed Dec 7 12:29:09 1994 Return-Path: Received: from mail.barrnet.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18347; Wed, 7 Dec 94 12:29:09 PST Received: from icx.com by mail.barrnet.net (8.6.8/BARRNET-8.6.6) id MAA07994; Wed, 7 Dec 1994 12:24:23 -0800 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 7 Dec 94 12:09 PST Message-Id: Date: Wed, 7 Dec 94 12:09 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Re: BIRD24 COMMENT To Arpad, Kumar, Will and everyone I support Arpad's comments concerning "V_load", and can only add that it would really take up to 6 such sub-parameters, 3 for dV/dt_r and 3 for dV/dt_f to cover the V_fixture, V_fixture_min and V_fixture_max options in the [Rising Waveform] and [Falling Waveform] keywords. I believe C_comp is really an "effective" die capacitance. The actual output driver or a COMPETE Spice model of its internal components will contain a number of (non-linear) reactive components, transition times, etc. plus any other internal effects such as metalization which may be lumped as a capacitance. For the large-signal dynamic transitions, the total mathematical characterization would be exceedingling large and complicated. Even the time varying, non-linear resistive elements would produce an effective reactive component in the overall analysis by following the line of reasoning and collecting terms: V(t) = I(t)R(t), dV(t)/dt = R(t)dI(t)/dt + V(t)dR(t)/dt, ... etc. As an IBIS modeling assumption, the total reactive effect is ASSUMED to be dominated by a constant C_comp value. With respect to "golden waveform" extraction, one may think they are being helpful by trying to remove some internal lumped capacitor that is positioned in a C_comp location. I contend that the best model will be produced from data representing the actual device, not from data produced from a transformed model because of some second order interactions such as expressed above. Therefore, I strongly want to discourage the concept of even the boolean parameter C_comp_in = T or F option. Inclusion of such an option would tarnish the waveform. Bob Ross, Interconnectix, Inc. > This raises an interesting point. How reliable is the value of C_comp itself? > Anyway I am not in favor any "implied" quantities associated with waveform tables. Every parasitc associated with that wave should be explicitly stated. So for example C_dut can include the effects of C_comp. > While I am at it I also want to raise another point regarding ky word Ramp. > That specification includes R_load. But there is no provisison for V_load. > If we look at the notes on Ramp rates there are situations in which V_load is > vendor specified and there is no place in IBIS models where thie information is > carried. From huq@rockie.nsc.com Wed Dec 7 13:07:40 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18842; Wed, 7 Dec 94 13:07:40 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA14017 for ibis@vhdl.org; Wed, 7 Dec 94 13:01:58 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA04900 for speters@ichips.intel.com; Wed, 7 Dec 94 13:01:55 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA09100; Wed, 7 Dec 94 13:04:45 PST Date: Wed, 7 Dec 94 13:04:45 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9412072104.AA09100@rockie.nsc.com> To: speters@ichips.intel.com, ibis@vhdl.org, Will_Hobbs@ccm2.jf.intel.com Subject: Re: Phase-in of IBIS 2.1 functionality Hi again IBISgurus: Along with the items that Will Hobbs has pointed out, I would like to stress that Differential I/O capability is a MUST along with Multiple-rail support. The following Keywords are needed: 1) [Diff Pin] 2) [Pullup Reference], [Pulldown Reference], [POWER Clamp Reference] [GND Clamp Reference] I have also got commitment from one of our groups to convert about 30 SPICE models to IBIS. That will depend on S2IBIS availability. I will join Fri's meeting a bit late due to a conflict with other meetings. My apologies.. Best Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From Will_Hobbs@ccm2.jf.intel.com Wed Dec 7 12:51:50 1994 > Date: Wed, 7 Dec 94 12:19:22 PST > From: Will Hobbs > To: speters@ichips.intel.com, ibis@vhdl.org > Subject: Phase-in of IBIS 2.1 functionality > Content-Length: 1390 > > > Text item: Text_1 > > > Hello fellow IBISians: > > At the last IBIS Teleconference I took the A/R to post exactly which features > of version 2.1 Intel would like to see simulator vendors implement first to > support our immediate needs. I also suggested that Syed and representatives > of the other IC vendors do the same. For example, Intel is counting heavily > on the non-linear ramp support and I am sure that NSC would like to see > differential I/O implemented ASAP. > > The idea is that if EDA vendors have to phase in 2.1 support over time, this > will give some guidance on how to prioritize their (your) activities. > Stephen Peters provided the following input to help fullfill the AR (thanks > Stephen). > > Following are the Keywords/parameters we feel are required to support Intel's > immediate 2.1 needs: > > > 1. Implement the [Rising Waveform] [Falling Waveform] keywords so as to > reproduce the waveshape of the output under various loads. This will include > recognizing the R_load and V_load parameters as well. > > 2. As stated in the spec, any derivative model must include the Copyright > text verbatim. The text in the Notes section should also be included. > > 3. Intel files will also include the [Temperature] keyword (for information > only. A simulator does not have to use the keyword, but the IBIS model > reader should accept it). > > > Regards, > > Will Hobbs and > Stephen Peters > Intel Corp. > From jonp@qdt.com Wed Dec 7 17:23:53 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24451; Wed, 7 Dec 94 17:23:53 PST Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQxtib03558; Wed, 7 Dec 1994 20:19:22 -0500 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 7 Dec 1994 20:19:25 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01257; Wed, 7 Dec 94 17:00:06 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27913; Wed, 7 Dec 94 17:01:20 PST Date: Wed, 7 Dec 94 17:01:20 PST From: jonp@qdt.com (Jon Powell) Message-Id: <9412080101.AA27913@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA00822; Wed, 7 Dec 94 17:01:06 PST To: ibis@vhdl.org Subject: C_COMP etc. Ibis type persons, I don't know whether this went out before or not. I had a memory blank. I have been reading the C_COMP arguments and would like to throw one more concern on the fire. The waveform measurements are defined to be time corelated (that is, time 0 is the same on all waveforms). I don't know of a good (or possible) way to do this with physical measurement. We have discussed this before but this implies that the waveforms must be made by a simulator. This means that the ease of removing C_COMP loading is higher. Presumably, if C_COMP is included this means a different waveform for every pin on the chip which would drastically complicated the model creation process. jonp From Derrick_Duehren@ccm2.jf.intel.com Wed Dec 7 18:26:31 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24796; Wed, 7 Dec 94 18:26:31 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFYUc-000UiXC; Wed, 7 Dec 94 18:22 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFYUc-000txMC; Wed, 7 Dec 94 18:22 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 7 Dec 94 18:22:02 PST Date: Wed, 7 Dec 94 18:22:02 PST From: Derrick Duehren Message-Id: <941207182202_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: Time to Update the Roster Text item: Text_1 IBISians, We will likely attach this roster to our press release for Rev 2.1 next week. Please send me any changes that you want made to your section, including your statement of support. - Derrick ============================================================================ IBIS Open Forum Participation Roster As of 12/7/94 (updated periodically) 34 total company/organization listed Submit changes/updates to: Derrick_Duehren@ccm.jf.intel.com (503) 696-4299, Fax (503) 696-4904 ============================================================================ Anacad Contact: Steffen Rochel Email: sr@anacad.de Phone: +49 (731) 9545414, FAX: +49 (731) 9545450 Address: Helmholtzstr.20 89081 Ulm Germany Support: Anacad can translate IBIS descriptions into models using their analog behavioral modeling language HDL-A. Together with Eldo and a VHDL simulator, highly accurate investigations of mixed signal designs are then possible. Tag-line: Ansoft Corporation Contact: Henri Maramis Email: maramis@ansoft.com Phone: (412) 261-3200, Fax: (412) 471-9427 Address: 4 Station Square, Suite 660 Pittsburgh, PA. 15219 Support: The Ansoft Maxwell SI product will support IBIS models/library in native format. Tag-line: Ansoft is a dedicated provider of electromagnetic field simulation software and integrated solutions for signal integrity and EMC/EMI. Atmel Corporation Contact: Dan Terry Email: No internet address -- Pls Fax notices Phone: (408) 436-4346, Fax: (408) 436-4200 Address: Support: Tag-line: Cadence Design Systems, Inc. Contact: C. Kumar Email: cpk@cadence.com Phone: (508) 262-6488, Fax: 508-262-6600 Address: 270 Billerica Rd, Chelmsford, MA 01824 Support: Cadence fully supports IBIS behavior models at the I/O cell and package levels. Cadence's DF/SigNoise product family offers a vendor-specific, IBIS compatible signal integrity library of over 7000 components. Cadence also provides a translator program enabling the conversion of IBIS 1.1 files to Cadence library format. Tag-line: Cadence, one of the world's 10 largest software companies, is the leading supplier of design automation software/services that accelerate and advance the process of designing electronic systems. Contec Microelectronics USA, Inc. Contact: Dileep Divekar, Clark Cochran Email: dileep@contec.com Phone: (408) 434-6767, Fax: (408) 434-6884 Address: 2188 Bering Drive San Jose, CA 95131 Support: A Contec product will support IBIS models in native mode. Tag-line: Digital Equipment Corp. Contact: Barry Katz Email: katz@decsim.enet.dec.com Phone: (508) 568-6016, Fax: Address: 77 Reed Road, HLO2-2/H13 Hudson, MA 01749 Support: Digital will generate IBIS models for its own chip products, including the line of ALPHA AXP microprocessors, as needed, and support IBIS models in in-house simulation tools. Tag-line: Digital, maker of the world's fastest microprocessor, is also a leading developer of computer systems, and networking and communication products, including PCI. Hewlett-Packard/HP EEsof Division Contact: Karl Kachigan Email: karlk@sr.hp.com Phone: (707) 577-3949, Fax: (707) 577-5260 Address: 1400 Fountaingrove Parkway Santa Rosa, CA 94503 Support: None at this time Tag-line: HP EEsof is a leading supplier of high frequency analog (RF/Microwave) design and modeling tools. High Design Technology Contact: Michael Smith Email: Phone: Address: Support: Tag-line: HyperLynx Contact: Kellee Crisafulli Email: 71436.1314@compuserve.com Phone: (206) 869-2320, Fax: (206) 881-1008 Address: P.O. Box 3578 Redmond, WA 98073-3578 Support: The LineSim simulator, an interactive analysis tool, reads IBIS files as part of its native library support. The BoardSim simulator (available in July 1994) is an analysis tool that reads geometric data directly from PCB layout databases; it also natively supports IBIS files. LineSim and BoardSim both ship with a set of IBIS libraries; additional model libraries are available free of charge to customers on HyperLynx's BBS. Tag line: HyperLynx, Inc. is the industry's leading supplier of affordable, accurate, PC-based signal-integrity software. IBM Corp. (unofficially) Contact: Joseph C. (Jay) Diepenbrock Email: jayd@ralvm29.vnet.ibm.com Phone: (919) 543-8804 Address: IBM Network Hdwe. Div. Transceiver Technology Dev't, D63/061 P. O. Box 12195 Research Triangle Park, NC 27709 Support: No formal declaration of support. Tag-line: IBM-Motorola (PowerPC) Contact: Lynn Warriner, Hoa Quoc Email: Phone: Address: Support: Tag-line: INCASES Contact: Werner Rissiek, Olaf Rethmeier Email: wr@cadlab.cadlab.de, olaf@cadlab.cadlab.de Phone: ++49-5251-284-155, ++49-5251-284-222, Fax: ++49-5251-284-105 Address: Siemens Nixdorf Informationssysteme AG Cadlab / Analog System Engineering Bahnhofstrasse 32 D-33102 Paderborn, Germany Support: Siemens Nixdorf uses the simulation program FREACS (Fast REflection And Crosstalk Simulator) for signal integrity analysis within the EMC-Workbench. Siemens Nixdorf can read IBIS Version 1.1 files and translate the IBIS models into FREACS models. Siemens Nixdorf uses an IBIS parser, developed by Siemens Nixdorf, and a semi-automatic process for the parametrization of the FREACS macromodels. The translation of IBIS to FREACS is available as a service for customers. A fully automated process will be developed when there are more IBIS models available. Additionally, so called 'reference lists' are set-up that are used by the interface (XLIN) between the EMC-Workbench and the FREACS macromodel library. These reference lists consist of circuit informations in a special language named HINAC (Hierachical Naming Convention), where macromodel data is assigned to pins of a component using IBIS-informations, as well. In this way a controlled set-up of a library is possible using IBIS-files as basis. Detailed information will be available on request. Tag-line: Siemens Nixdorf (SNI) is the leading European company for information technology. Based on self experiences of hardware and software development, SNI provides the EMC-workbench for advanced analysis of EMC and signal integrity. Integrity Engineering, Inc. Contact: Greg Doyle Email: gdoyle@intgrty.mn.org Phone: (612) 636-6913, Fax: (612) 631-2241 Address: 1306 W. Country Rd. F, Suite 100 St. Paul, MN 55112 Support: The Integrity Simulators and Parasitic Extractor tools, SImnet, SImnet X, and Autospice are shipped with an IBIS2IEI translation program that enables any IBIS file to be directly converted for use with the simulator or SPICE extractor. The next revisions of IEI programs, slated for delivery 2Q '94, will support IBIS models in native mode. A utility will be provided to read, edit, and view IBIS files directly. Tag-line: Intel Corporation Contact: Will Hobbs Email: Will_Hobbs@ccm2.jf.intel.com Phone: (503) 696-4369, Fax: (503) 696-4210 Address: 5200 NE Elam Young Pkwy, JF1-57 Hillsboro, OR 97124 Support: Intel provides IBIS models for some of its components. For a list of supported components, send the following message to archive@vhdl.org: path send pub/ibis/models/intel readme index /pub/ibis/models/intel Tag-line: Intel, the world's largest chip maker, is also a leading manufacturer of personal computer networking and communications products. Interconnectix, Inc. Contact: Bob Ross Email: bob@icx.com Phone: (503) 684-6641, Fax: (503) 639-3469 Address: 10220 S.W. Nimbus Ave., K4 Portland, Oregon 97223 Support: Interconnectix product will be able to read IBIS Version 1.1 models directly (NATIVE MODE). The product will be able to read a text file composed of a library of IBIS models. Tag-line: Intergraph Corp. Contact: Ian Dodd, David Wiens Email: idodd@ingr.com, dwiens@ingr.com Phone: (303) 581-2300 Address: 6101 Lookout Road, Suite A Boulder, CO 80301 Support: Intergraph Electronics fully supports the activities of the IBIS open forum and as such, is ensuring that all signal integrity development is aligned so that our customers will be able to take advantage of IBIS as the standard stabilizes. Tag-line: Intergraph Corporation, a Fortune 500 company, is the world's largest independent NT development site and the world's largest company dedicated to supplying interactive computer graphics systems. Integrated Silicon Systems, Inc. Contact: Eric Bracken Email: bracken@bacon.performance.com Phone: Address: One Northgate Square Greensburg, PA 15601-1341 Support: Tag Line: IntuSoft Contact: Charles Hymowitz Email: Phone: (303) 833-0710 Address: Support: IntuSoft takes a customer's netlist or model and translates it into a Spice model, free of charge. IntuSoft has the Golden Parser source but hasn't, as of yet, automated the process. IntuSoft is waiting until there are more IBIS models available. Tag-line: Mentor Graphics Corp. Contact: Ravender Goyal Email: Ravender_Goyal@mentororg.com Phone: Address: 8005 SW Boeckman Rd. Wilsonville, OR 97070-7777 Support: Mentor supports IBIS by using Quad Design and Intel IBIS models. Tag-line: Meta-Software Contact: John Sliney, Mei Wong Email: johns@metasw.com, mei@metasw.com Phone: (408) 369-5446, (408) 371-5100 Address: 1300 White Oaks Rd. Campbell, CA 95008 Support: Tag-line: MicroSim Corp. Contact: Arthur Wong Email: Phone: (714) 770-3022, FAX: (714) 455-0554 Address: 20 Fairbanks Irvine, CA 92718 Support: MicroSim can automatically generate PSpice models for vendors who provide data in a file format conforming to the IBIS Ver 1.1 specification. The models can then be simulated with PSpice. MicroSim has made IBIS models for Intel's Pentium processor 82430 PCIset available to customers. Tag-line: MicroSim Corp. - The Desktop EDA Company - provides technically sophisticated software for schematic entry, simulation, programmable logic synthesis, and signal integrity analysis. National Semiconductor Corp. Contact: Syed Huq Email: huq@rockie.nsc.com Phone: (408) 721-4874, Fax:(408)721-4785 Address: 2900 Semiconductor Drive M/S E-200 Santa Clara, CA 95052 Support: The Advanced Systems & Interface Product Group(ASIP) of National Semiconductor is willing to create differential IBIS model files and provide IBIS model support to customers. Tag-line: National Semiconductor provides technologies for moving and shaping information. The company focuses on communications, analog, and personal systems markets, and is the fourth largest U.S semiconductor merchant. NEC Corporation Contact: Hiroshi Matsumoto Email: mat@lsi.tmg.nec.co.jp Phone: +81 -44-435-1501(DIR), Fax: +81 -44-435-1887 Address: Design Sys. Dept., System ASIC Div., NEC Corp. 1753 Shimonumabe, Nakahara-ku Kawasaki Japan 211 Support: NEC is willing to write some IBIS models and a model generator for some of its LSI components. Tag-line: North Carolina State University Contact: Michael Steer, Paul Franzon, Steve Lipa Email: mbs@ncsu.edu paulf@ncsu.edu slipa@eos.ncsu.edu Phone: 919-515-5191 919-515-7351 919-515-3947 FAX for all three: 919-515-5523 Address: ECE Dept. Box 7911 NC State Univ. Raleigh, NC 27695-7911 Support: (as of 2/94) A Spice to IBIS converter is being developed. A measurement based procedure is being developed for extracting IBIS models. A yacc/lex parser for IBIS models is being develped. All software and techniques will be put in the public domain. Tag-line: Performance Signal Integrity, Inc. Contact: Eric Bracken Email: bracken@performance.com Phone: (412) 682-7101, Fax: (412) 682-7178 Address: 4618 Henry St. Pittsburgh, PA 15213 Support: PSIBoards will accept IBIS V1.1 (ibis_chk compatible) model files directly. The IBIS files can contain any number of models or components. Instances of these models can be declared in the input deck, along with interconnections, to describe a complete design. Tag-line: Quad Design Technology, Inc. Contact: Jon Powell Email: jonp@qdt.com Phone: (805) 988-8250, Fax: (805) 988-8259 Address: 1385 Del Norte Rd. Camarillo, CA 93010 Support: Quad Design has a translation program that translates from IBIS format to Quad Design .mod format. This translator uses the Golden Parser code with enhancements to warn of malformed (yet legal) models. The translator supports user input to be able to select from the min-typ-max range of IBIS data. This program (IBIS2XTK) is available now and will be generally distributed with the XTK 5.2 release (available in Feb. 1994). Tag-line: Quad Desgin is a leading supplier of Signal Integrity and Timing tools for high speed digital designs. Quantic Laboratories, Inc. Contact: Mike Ventham, Zhen Mu Email: ventham@quantic.mb.ca, mu@quantic.mb.ca Phone: (204) 942-4000, Fax: (204) 957-1158 Address: 12th Floor, 191 Lombard Ave Winnipeg, Manitoba, R3B 0X1 Canada Support: Quantic will be providing an IBIS reader (based on the Golden Parser) that will read IBIS models and automatically generate data files for Phidias (our graphical VI curve device modellor) and database files that associate the component definitions with the pin models. From Phidias, both SPICE models for Greenfield Phyllis (our PHYsical Load and Line Simulator) and models for BoardScan, (our PC board scanner for signal integrity and crosstalk) can be created. The release date has not been set yet. An application note is available regarding using IBIS models with Phidias. Tag-line: Stanford University, Dept of EE, Computer Systems Lab Contact: Randolph E. (Randy) Harr Email: randyh@vhdl.org, rharr@mojave.stanford.edu Phone: (415) 725-3639, Fax (415) 725-6949 Address: Stanford, CA 94305-4070 Support: None at this time Tag-line: N/A Symmetry Design Systems, Inc. Contact: Andy Hughes Email: andy@symmetry.com Phone: (415) 949-9600, Fax: (415)-949-0831 Address: 477 S. San Antonio Rd. #200 Los Altos, Ca. 94022 Support: Symmetry provides IBIS modeling tools and services. Symmetry's modeling tool MODPEX can create IBIS models based on measured device characteristics or data sheet information. MODPEX can translate IBIS models to SPICE descriptions for testing and documentation or translate SPICE models to IBIS. Tag-line: Symmetry is a dedicated supplier of tools and services for creating, testing, and documenting SPICE and IBIS component models for electronic system design. Synopsys Inc. (Logic Modeling Group) Contact: Bill Lattin Email: billl@lmc.synopsys.com Phone: (503) 690-6900, Fax (503) 690-6906 Address: 19500 NW Gibbs Dr. Beaverton, OR 97075 Support: None at this time Tag-line: Texas Instruments Contact: Bob Ward Email: bward@neosoft.com Phone: (713) 274-4146, Fax (713) 274-3911 Address: P.O. Box 1443, M/S 631 Houston, TX 77251 Support: TI has a three-pronged attack on IBIS support. TI is working on a scheme to automatically generate IBIS models from TI Spice simulations (TI's proprietary Spice dialect), on an automatic means to generate C code to be linked in to TI Spice as a User Defined Element from an IBIS model, and an automatic means to create the Spice equivalent of the IBIS model from the IBIS model specification. The latter method differs from the second in that it uses skeletonized Spice primitive elements in the form of a subcircuit, while the second actually generates C code and compiles it for dynamic linking. Tag-line: Thomson-CSF/SCTF Contact: Jean Lebrun Email: Phone: Address: Support: Tag-line: UniCAD Canada Ltd. Contact: Stephen Lum Email: lum@unicad.com Phone: (613) 596-9091 Ext. 321 Address: 2745 Iris Street Pinecrest Office Park Ottawa, Ontario K2C 3V5 Support: UniSolve, a concurrent engineering workbench will support IBIS v1.1 model files in native mode for signal integrity analysis. Tag-line: Zeelan Technology, Inc. Contact: Hiro Moriyasu, George Opsahl Email: zeelan@netcom.com Phone: (503) 520-1000 Address: 10550 SW Allen Blvd. Beaverton, OR 97005 Support: Zeelan Tech. provides a modeling service that characterize and creates models conforming to the IBIS format. Zeelan Tech. MasterModel(TM) models are created from measurements of physical devices using a tightly controlled high-frequency fixture and modeling system. These models closely represent actual device behaviour when used in simulation. Tag-line: Zuken-Redac Contact: John Berrie Email: johnb@redact.co.uk Phone: +44 684 294161, Fax: +44 684 299754 Address: Tewkesbury Gloucestershire GL20 8QL, England Support: Work is in progress to enable use of IBIS models in native format for Redac High-Performance Engineering and EMC Adviser products. In addition, integration with Quad Design and Quantic products provides the stated level of support provided by these companies. Tag-line: Racal-Redac is a world leader in design automation, providing open, leading technology, standards-based CADCAM solutions. From mbs@eos.ncsu.edu Thu Dec 8 05:11:10 1994 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02755; Thu, 8 Dec 94 05:11:10 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA16720; Thu, 8 Dec 1994 08:06:43 -0500 From: mbs@eos.ncsu.edu Message-Id: <9412081306.AA16720@mbs.ece.ncsu.edu> To: ibis@vhdl.org Cc: awglaser@eos.ncsu.edu Subject: Spice_to_ibis Date: Thu, 08 Dec 94 08:06:42 EST Folks, I cannot make the meeting on Friday 12/9/94 as I will be out of town, but I want to update you on spice_to_ibis (S2IBIS --- Thanks DOS, long live Linux). We are beginning to ramp up again to do the following, Improve the documentation. This is the cause of most problems. It will reduce support time involving us (We figure around 100 different groups have contacted us.) and applications engineers at CAE vendors. Boy if you work out the cost savings ... Enhance the error reporting by S2IBIS by providing suggestions as to what to do in the case of errors. There have been a number of problems with S2IBIS using HSpice. We regard that (at least our version of HSpice) has a bug relating to connectivity of nodes through nested subcircuits. This has caused grief with some driver models. We need to work with MetaSoft on this. Some drivers do not have IBISv1.1 models. Mostly this is because of the 50 ohm load specification for ramps. The only way around this is to move to v2.1. Provide limited extensions so that we can produce partial v2.1 models. We will use the priorities that have been floating around on the net for the last few days. Add support for more flavors of Spice. Especially CADENCE's Spectre. We hope to provide an interim release by the end of January. The above is per the kind graces of CADENCE who will fund a student for three months. (Note: the deal is not finalized but the principles are confident.) We are still working on getting ARPA funding but this will be sometime in the future. S2IBIS needs development now. We welcome receiving enhancements that you may have done to S2IBIS for inclusion in future releases. Michael Steer Associate Professor North Carolina State University. From cpk@Cadence.COM Thu Dec 8 07:31:13 1994 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04081; Thu, 8 Dec 94 07:31:13 PST Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id HAA04449 for ; Thu, 8 Dec 1994 07:26:43 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma004433; Thu Dec 8 07:26:26 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA24677; Thu, 8 Dec 94 07:25:11 -0800 Received: by hot (5.65+/1.5) id AA13375; Thu, 8 Dec 94 10:26:18 -0500 Date: Thu, 8 Dec 94 10:26:18 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9412081526.AA13375@hot> To: ibis@vhdl.org Subject: Re: C_COMP etc. Ibisiens: C_comp brings up some issues between measurements and spice generated data. 1. There are two main types of buffer modelling with different requirements. One is the buffer designer who is designing buffers " in to out". This is the type of person who may be extracting buffer info from spice type circuits. The second type is the person who extracts buffer model from measurements. 2. If the v-t is primarily performed by measurement, then the effective parasitics should include both the package and the die parasitic. In this case it makes sense to lump them into smallest set of efffective parameters like c_dut, l_dut etc. Then the v-t data is explicit with all the conditions of its generation specified. There are no implicit quantities like c_comp to account for. 3. Like John Powell points out implicit quantities like c_comp need to be considered only if the measurements are spicetype. In that case it can be excluded or can be explicitly specified by setting c_dut = c_comp for the measurement. - kumar From Arpad_Muranyi@ccm.fm.intel.com Thu Dec 8 11:57:13 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09024; Thu, 8 Dec 94 11:57:13 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFosk-000UgaC; Thu, 8 Dec 94 11:52 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFosk-000txXC; Thu, 8 Dec 94 11:52 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 8 Dec 94 11:52:01 PST Date: Thu, 8 Dec 94 11:52:01 PST From: Arpad Muranyi Message-Id: <941208115201_1@ccm.hf.intel.com> To: jonp@qdt.com, ibis@vhdl.org Subject: Re: C_COMP etc. Text item: Jon, As far as I remember, we said that the measured waveforms could be time correlated by referencing all waveforms to a driving clock common to all edges. Correct me if I am wrong. Arpad Ibis type persons, I don't know whether this went out before or not. I had a memory blank. I have been reading the C_COMP arguments and would like to throw one more concern on the fire. The waveform measurements are defined to be time corelated (that is, time 0 is the same on all waveforms). I don't know of a good (or possible) way to do this with physical measurement. We have discussed this before but this implies that the waveforms must be made by a simulator. This means that the ease of removing C_COMP loading is higher. Presumably, if C_COMP is included this means a different waveform for every pin on the chip which would drastically complicated the model creation process. jonp Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: C_COMP etc. To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA00822; Wed, 7 Dec 94 17:01:06 PST Message-Id: <9412080101.AA27913@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Wed, 7 Dec 94 17:01:20 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27913; Wed, 7 Dec 94 17:01:20 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01257; Wed, 7 Dec 94 17:00:06 PST Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 7 Dec 1994 20:19:25 -0500 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQxtib03558; Wed, 7 Dec 1994 20:19:22 -0500 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24451; Wed, 7 Dec 94 17:23:53 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 7 Dec 94 17: Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFXrT-000txlC; Wed, 7 Dec 94 17:41 PST From Arpad_Muranyi@ccm.fm.intel.com Thu Dec 8 15:14:41 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16200; Thu, 8 Dec 94 15:14:41 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rFryS-000UiGC; Thu, 8 Dec 94 15:10 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rFryQ-000tx8C; Thu, 8 Dec 94 15:10 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 8 Dec 94 15:10:06 PST Date: Thu, 8 Dec 94 15:10:06 PST From: Arpad Muranyi Message-Id: <941208151006_3@ccm.hf.intel.com> To: cpk@Cadence.COM, ibis@vhdl.org Subject: Re[2]: C_COMP etc. Text item: Kumar, You wrote: 2. If the v-t is primarily performed by measurement, then the effective parasitics should include both the package and the die parasitic. In this case it makes sense to lump them into smallest set of efffective parameters like c_dut, l_dut etc. Then the v-t data is explicit with all the conditions of its generation specified. There are no implicit quantities like c_comp to account for. I do not agree completely with this, because you have to consider that some dies come in different packages. The die remains the same (so does C_comp) but the package L,R,C may change drastically, which in turn effects wave forms (V-T) also. For this reason I would keep them separate. Arpad Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: C_COMP etc. To: ibis@vhdl.org Message-Id: <9412081526.AA13375@hot> From: cpk@cadence.com (C. Kumar) Date: Thu, 8 Dec 94 10:26:18 -0500 Received: by hot (5.65+/1.5) id AA13375; Thu, 8 Dec 94 10:26:18 -0500 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA24677; Thu, 8 Dec 94 07:25:11 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma id sma004433; Thu Dec 8 07:26:26 1994 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id HAA0444 Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04081; Thu, 8 Dec 94 07:31:13 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 8 Dec 94 07: Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFl4q-000twfC; Thu, 8 Dec 94 07:48 PST From huq@rockie.nsc.com Thu Dec 8 15:49:29 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16482; Thu, 8 Dec 94 15:49:29 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA13353 for ibis@vhdl.org; Thu, 8 Dec 94 15:45:05 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA22826 for ibis@vhdl.org; Thu, 8 Dec 94 15:45:04 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA14395; Thu, 8 Dec 94 15:47:54 PST Date: Thu, 8 Dec 94 15:47:54 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9412082347.AA14395@rockie.nsc.com> To: ibis@vhdl.org Subject: Ibis Technology makes announcement IBISgurus, Do we have copyright on the IBIS name ? See below... Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----- Begin Included Message ----- From ctwnsc@tevm2.nsc.com Thu Dec 8 15:27:23 1994 From: Todd Nelson Date: Thu, 08 Dec 94 15:26:12 -2400 To: huq@rockie.nsc.com Mime-Version: 1.0 X-Mailer: Mozilla/0.93 beta (Macintosh) Content-Type: multipart/mixed; boundary="-------------------------------28382055424988" text/plain; charset=iso-8859-1 Subject: Ibis Technology makes announcement X-Url: http://sctechlib:80/cgi-bin/next_article.pl/941208/37/60/f Content-Transfer-Encoding: 8bit Content-Length: 5798 Hey, who is this "Ibis" company? > Previous Article[Image] [Image]Next Article > > Return To Topic Page > > Ibis Technology makes announcement > > 12-06-94 > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > > DANVERS, Mass.--(BUSINESS WIRE) via First! -- Ibis Technology Corp., > the leading supplier of SIMOX wafers, announced today that it has been > informed by one of its major military customers, Harris Corp., that > Harris has decided to discontinue its 0.8 micron Silicon-on-Insulator > program targeted to strategic military applications. > > This Harris program in the past had utilized SIMOX wafers supplied by > Ibis and other SIMOX producers. In its communication, Harris cited the > decline in the military market for strategic programs as a principal > factor for terminating the program. > > In recent years, Harris had agreed to purchase a significant number of > SIMOX wafers from Ibis, but had accepted delivery of only a nominal > number of wafers in 1994 due to program difficulties. Accordingly, the > cancellation of this program results in a significant reduction in > Ibis' backlog for SIMOX wafers. However, based on Ibis' inventory > reserve policy for inventory obsolescence, Ibis does not expect to > incur any additional expenses for SIMOX wafers previously manufactured > by Ibis for Harris. > > Commenting on this matter, Jeffrey R. Riskin, Ibis vice president of > marketing and sales, said, "Harris' cancellation of this program and > the reduction in wafer deliveries that preceded it has had a > significant negative impact on our 1994 financial performance. The > Harris decision is a further reflection of the structural shift taking > place in our industry as military programs decline and as commercial > interest in SIMOX increases. Ibis' principal focus continues to be the > development and integration of SIMOX technology in large-volume > commercial applications worldwide." > > Ibis Technology Corp., which is located in Danvers, Mass., is an > advanced materials company which supplies SIMOX wafers to the > semiconductor industry. SIMOX wafers are silicon-on-insulator wafers > which enable the production of integrated circuits with significant > advantages over circuits constructed on conventional bulk silicon or > epitaxial wafers. The company produces SIMOX wafers on an advanced > proprietary oxygen implanter, the Ibis 1000, utilizing proprietary > processing technologies which enable the production of SIMOX wafers to > meet the requirements of high volume commercial applications. > > CONTACT: Ibis Technology Corp. | Jeffrey Riskin, Timothy Burns or > Debra Carroll | 508/777-4247 > > ------------------------------------------------------------------------ > > Copyright1994 by INDIVIDUAL, Inc. > ---------------------------------28382055424988 Content-Type: text/plain Content-Transfer-Encoding: 8bit Previous Article[Image] [Image]Next Article Return To Topic Page Ibis Technology makes announcement 12-06-94 ------------------------------------------------------------------------ ------------------------------------------------------------------------ DANVERS, Mass.--(BUSINESS WIRE) via First! -- Ibis Technology Corp., the leading supplier of SIMOX wafers, announced today that it has been informed by one of its major military customers, Harris Corp., that Harris has decided to discontinue its 0.8 micron Silicon-on-Insulator program targeted to strategic military applications. This Harris program in the past had utilized SIMOX wafers supplied by Ibis and other SIMOX producers. In its communication, Harris cited the decline in the military market for strategic programs as a principal factor for terminating the program. In recent years, Harris had agreed to purchase a significant number of SIMOX wafers from Ibis, but had accepted delivery of only a nominal number of wafers in 1994 due to program difficulties. Accordingly, the cancellation of this program results in a significant reduction in Ibis' backlog for SIMOX wafers. However, based on Ibis' inventory reserve policy for inventory obsolescence, Ibis does not expect to incur any additional expenses for SIMOX wafers previously manufactured by Ibis for Harris. Commenting on this matter, Jeffrey R. Riskin, Ibis vice president of marketing and sales, said, "Harris' cancellation of this program and the reduction in wafer deliveries that preceded it has had a significant negative impact on our 1994 financial performance. The Harris decision is a further reflection of the structural shift taking place in our industry as military programs decline and as commercial interest in SIMOX increases. Ibis' principal focus continues to be the development and integration of SIMOX technology in large-volume commercial applications worldwide." Ibis Technology Corp., which is located in Danvers, Mass., is an advanced materials company which supplies SIMOX wafers to the semiconductor industry. SIMOX wafers are silicon-on-insulator wafers which enable the production of integrated circuits with significant advantages over circuits constructed on conventional bulk silicon or epitaxial wafers. The company produces SIMOX wafers on an advanced proprietary oxygen implanter, the Ibis 1000, utilizing proprietary processing technologies which enable the production of SIMOX wafers to meet the requirements of high volume commercial applications. CONTACT: Ibis Technology Corp. | Jeffrey Riskin, Timothy Burns or Debra Carroll | 508/777-4247 ------------------------------------------------------------------------ Copyright1994 by INDIVIDUAL, Inc. ---------------------------------28382055424988-- ----- End Included Message ----- From uunet!qdt.com!jonp@uunet.uu.net Thu Dec 8 16:52:57 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17788; Thu, 8 Dec 94 16:52:57 PST Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQxtlr03509; Thu, 8 Dec 1994 19:45:38 -0500 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 8 Dec 1994 19:45:47 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01338; Thu, 8 Dec 94 16:41:10 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA24854; Thu, 8 Dec 94 16:42:25 PST Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQxtln26248; Thu, 8 Dec 1994 18:45:06 -0500 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 8 Dec 1994 18:45:14 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01238; Thu, 8 Dec 94 15:19:09 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA24106; Thu, 8 Dec 94 15:20:24 PST Date: Thu, 8 Dec 94 15:20:24 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9412082320.AA24106@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA01320; Thu, 8 Dec 94 15:20:08 PST To: uunet!uunet!ccm.fm.intel.com!Arpad_Muranyi@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Arpad Muranyi's message of Thu, 8 Dec 94 11:52:01 PST <941208115201_1@ccm.hf.intel.com> Subject: C_COMP etc. Text item: >>Jon, >>As far as I remember, we said that the measured waveforms could be time >>correlated by referencing all waveforms to a driving clock common to all edges. >>Correct me if I am wrong. >>Arpad This will certainly work for clocked output or straight feedthrough signals (like buffers). Aren't there lots of other types of signals on, for instance, the Pentinum and 486 chips? If there aren`t, and all signals can be referenced to a know "intiator", then life should be good. jonp From speters@ichips.intel.com Fri Dec 9 10:38:05 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28264; Fri, 9 Dec 94 10:38:05 PST Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 9 Dec 94 10:31:43 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 9 Dec 94 10:29:47 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 9 Dec 94 10:30:19 PST Message-Id: <9412091830.AA26327@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD 24.1 Date: Fri, 09 Dec 1994 10:30:17 -0800 From: Stephen Peters Hello fellow IBISans: As voted on in the Teleconference, here is bird 24.1. Regards, Stephen Peters Intel Corp. ************************************************************ BIRD ID#: 24.1 ISSUE TITLE: C_comp, ramp rates and waveform tables REQUESTER: Stephen Peters DATE SUBMITTED: Dec, 6, 1994 DATE ACCEPTED BY IBIS OPEN FORUM: Passed 12/9/94 ********************************************************* ********************************************************* STATEMENT OF THE ISSUE: The spec fails to specify whether or not the effects of C_comp are to be included in the ramp rate and waveform table data. ********************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The specification is changed in three places. The first is in the 'NOTES ON DATA DERIVATION METHOD' section under Ramp Rates. The second paragraph is modified to read as follows: "The ramp rate does not include packaging but does include the effects of the C_comp parameter; it is the intrinsic output stage rise and fall time only." In the section of the spec describing the [Ramp] keyword the following statement is added after the first sentence of the description: "The ramp rate does not include packaging but does include the effects of the C_comp parameter." Likewise, the section describing the [Rising Waveform], [Falling Waveform] is modified to add the following at the end of the first paragraph: "The data in the waveform table is taken with the effects of the C_comp parameter included." ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: While exchanging e-mail with Kumar on the subject of waveform tables we realized that the spec makes no mention of the fact that the data for the waveform table is supposed to be taken with C_comp = 0. In fact the spec is not very clear about this with regards to the ramp rate either. After the IBIS Teleconference on 12/9 is was decided that the ramp rate and waveform tables SHOULD include the effects of C_comp and so the BIRD was modified and passes at that meeting. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From Will_Hobbs@ccm2.jf.intel.com Fri Dec 9 11:16:01 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28552; Fri, 9 Dec 94 11:16:01 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rGAig-000UepC; Fri, 9 Dec 94 11:11 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rGAif-000txGC; Fri, 9 Dec 94 11:11 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 9 Dec 94 11:11:05 PST Date: Fri, 9 Dec 94 11:11:05 PST From: Will Hobbs Message-Id: <941209111105_1@ccm.jf.intel.com> To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: Ibis Technology makes announcement Text item: Syed, We did a trademark search on IBIS and found it was in such common usage, and no direct conflict with out use, that we weren't in conflict with existing trademarks. We also felt it wasn't worth the effort to register. I just called Jeff Riskin at IBIS Technology and let him know of our existence. They were founded in 1986 or 1987 under that name. As I said, out trademark search did not find them, and Jeff doesn't know if they registered it. He's checking to see if this causes them any problems. The general principle is if there is possibility of confusion in the marketplace due to similarity of products and names, then there is a potential for problems with the names. Since we are a spec and they make semiconductors, I doubt if there would be any confusion. Note that I am not a lawyer and my opinion doesn't count, though. Thanks for bringing this to us. Will IBISgurus, Do we have copyright on the IBIS name ? See below... Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----- Begin Included Message ----- From ctwnsc@tevm2.nsc.com Thu Dec 8 15:27:23 1994 From: Todd Nelson Date: Thu, 08 Dec 94 15:26:12 -2400 To: huq@rockie.nsc.com Mime-Version: 1.0 X-Mailer: Mozilla/0.93 beta (Macintosh) Content-Type: multipart/mixed; boundary="-------------------------------28382055 424988" text/plain; charset=iso-8859-1 Subject: Ibis Technology makes announcement X-Url: http://sctechlib:80/cgi-bin/next_article.pl/941208/37/60/f Content-Transfer-Encoding: 8bit Content-Length: 5798 Hey, who is this "Ibis" company? > Previous Article[Image] [Image]Next Article > > Return To Topic Page > > Ibis Technology makes announcement > > 12-06-94 > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > > DANVERS, Mass.--(BUSINESS WIRE) via First! -- Ibis Technology Corp., > the leading supplier of SIMOX wafers, announced today that it has been > informed by one of its major military customers, Harris Corp., that > Harris has decided to discontinue its 0.8 micron Silicon-on-Insulator > program targeted to strategic military applications. > > This Harris program in the past had utilized SIMOX wafers supplied by > Ibis and other SIMOX producers. In its communication, Harris cited the > decline in the military market for strategic programs as a principal > factor for terminating the program. > > In recent years, Harris had agreed to purchase a significant number of > SIMOX wafers from Ibis, but had accepted delivery of only a nominal > number of wafers in 1994 due to program difficulties. Accordingly, the > cancellation of this program results in a significant reduction in > Ibis' backlog for SIMOX wafers. However, based on Ibis' inventory > reserve policy for inventory obsolescence, Ibis does not expect to > incur any additional expenses for SIMOX wafers previously manufactured > by Ibis for Harris. > > Commenting on this matter, Jeffrey R. Riskin, Ibis vice president of > marketing and sales, said, "Harris' cancellation of this program and > the reduction in wafer deliveries that preceded it has had a > significant negative impact on our 1994 financial performance. The > Harris decision is a further reflection of the structural shift taking > place in our industry as military programs decline and as commercial > interest in SIMOX increases. Ibis' principal focus continues to be the > development and integration of SIMOX technology in large-volume > commercial applications worldwide." > > Ibis Technology Corp., which is located in Danvers, Mass., is an > advanced materials company which supplies SIMOX wafers to the > semiconductor industry. SIMOX wafers are silicon-on-insulator wafers > which enable the production of integrated circuits with significant > advantages over circuits constructed on conventional bulk silicon or > epitaxial wafers. The company produces SIMOX wafers on an advanced > proprietary oxygen implanter, the Ibis 1000, utilizing proprietary > processing technologies which enable the production of SIMOX wafers to > meet the requirements of high volume commercial applications. > > CONTACT: Ibis Technology Corp. | Jeffrey Riskin, Timothy Burns or > Debra Carroll | 508/777-4247 > > ------------------------------------------------------------------------ > > Copyright1994 by INDIVIDUAL, Inc. > ---------------------------------28382055424988 Content-Type: text/plain Content-Transfer-Encoding: 8bit Previous Article[Image] [Image]Next Article Return To Topic Page Ibis Technology makes announcement 12-06-94 ------------------------------------------------------------------------ ------------------------------------------------------------------------ DANVERS, Mass.--(BUSINESS WIRE) via First! -- Ibis Technology Corp., the leading supplier of SIMOX wafers, announced today that it has been informed by one of its major military customers, Harris Corp., that Harris has decided to discontinue its 0.8 micron Silicon-on-Insulator program targeted to strategic military applications. This Harris program in the past had utilized SIMOX wafers supplied by Ibis and other SIMOX producers. In its communication, Harris cited the decline in the military market for strategic programs as a principal factor for terminating the program. In recent years, Harris had agreed to purchase a significant number of SIMOX wafers from Ibis, but had accepted delivery of only a nominal number of wafers in 1994 due to program difficulties. Accordingly, the cancellation of this program results in a significant reduction in Ibis' backlog for SIMOX wafers. However, based on Ibis' inventory reserve policy for inventory obsolescence, Ibis does not expect to incur any additional expenses for SIMOX wafers previously manufactured by Ibis for Harris. Commenting on this matter, Jeffrey R. Riskin, Ibis vice president of marketing and sales, said, "Harris' cancellation of this program and the reduction in wafer deliveries that preceded it has had a significant negative impact on our 1994 financial performance. The Harris decision is a further reflection of the structural shift taking place in our industry as military programs decline and as commercial interest in SIMOX increases. Ibis' principal focus continues to be the development and integration of SIMOX technology in large-volume commercial applications worldwide." Ibis Technology Corp., which is located in Danvers, Mass., is an advanced materials company which supplies SIMOX wafers to the semiconductor industry. SIMOX wafers are silicon-on-insulator wafers which enable the production of integrated circuits with significant advantages over circuits constructed on conventional bulk silicon or epitaxial wafers. The company produces SIMOX wafers on an advanced proprietary oxygen implanter, the Ibis 1000, utilizing proprietary processing technologies which enable the production of SIMOX wafers to meet the requirements of high volume commercial applications. CONTACT: Ibis Technology Corp. | Jeffrey Riskin, Timothy Burns or Debra Carroll | 508/777-4247 ------------------------------------------------------------------------ Copyright1994 by INDIVIDUAL, Inc. ---------------------------------28382055424988-- ----- End Included Message ----- Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Ibis Technology makes announcement To: ibis@vhdl.org Message-Id: <9412082347.AA14395@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Thu, 8 Dec 94 15:47:54 PST Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA14395; Thu, 8 Dec 94 15:47:54 PST Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA22826 for ibis@vhdl.org; Thu, 8 Dec 94 15:45:04 -0800 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA13353 for ibis@vhdl.org; Thu, 8 Dec 94 15:45:05 -0800 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16482; Thu, 8 Dec 94 15:49:29 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 8 Dec 94 16: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 8 Dec 94 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rFznQ-000twxC; Thu, 8 Dec 94 23:31 PST From Derrick_Duehren@ccm2.jf.intel.com Fri Dec 9 13:27:32 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00702; Fri, 9 Dec 94 13:27:32 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rGCmM-000Uh1C; Fri, 9 Dec 94 13:23 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rGCmM-000txqC; Fri, 9 Dec 94 13:23 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 9 Dec 94 13:23:01 PST Date: Fri, 9 Dec 94 13:23:01 PST From: Derrick Duehren Message-Id: <941209132301_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Roster Update : Last Chance Before Publishing Text item: Text_1 IBISians, 12/9/94 Many of you have submitted updates to the IBIS roster, but many still have not. I will be attaching this roster to our press release announcing today's ratification of Rev 2.1, which we intent to publish next week. Many of you still have contact information and support statements that are out of date. Please review the attached file and send any changes to me by Noon 12/13/94 if you want the changes to go out with the Press Release. Also in today's meeting, I took an AR to add a disclaimer to the header of the roster file. I propose the following: NOTE: This roster lists companies and organizations that have participated in defining the IBIS specification. Other than the specific statements of support under each organization's name, no support nor endorsement of the specification is implied. Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ begin 644 roster.txt M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/0T*("`@("`@("`@("`@ M($E"25,@3W!E;B!&;W)U;2!087)T:6-I<&%T:6]N(%)O"`H-3`S*2`V.38M-#DP-`T*/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/0T*3D]413H@5&AIG-T M2!A8V-U#H@*#0P."D@-#,V+30R,#`-"B`@061D#H@*#0T*("`@ M("`@("`@("`@4V%N=&$@4F]S82P@0T$@.30U,#,-"B`@4W5P<&]R=#H@($YO M;F4@870@=&AI7!E7-I2!S=7!P;W)T+B`@5&AE($)O87)D4VEM(`T*("`@ M("`@("`@("`@2`Q.3DT*2!I M7-I2!F7!E"P@26YC+B!I2!$978G="P@1#8S+S`V,0T*("`@("`@ M("`@("`@4"X@3RX@0F]X(#$R,3DU#0H@("`@("`@("`@("!297-E87)C:"!4 M2!T:&5S92!M M;V1E;',@=VEL;"!B92!B87-E9"!U<&]N(&1E2!T:&4@:6YT97)F86-E("A83$E.*2!B M971W965N('1H92!%34,M5V]R:V)E;F-H(&%N9"!T:&4@#0H@("`@("`@("`@ M("!&4D5!0U,@;6%C2!%;F=I;F5E6QE0&EN=&=R='DN;6XN;W)G M#0H@(%!H;VYE.B`@("`H-C$R*2`V,S8M-CDQ,RP@1F%X.B`H-C$R*2`V,S$M M,C(T,0T*("!!9&1R97-S.B`@,3,P-B!7+B!#;W5N=')Y(%)D+B!&+"!3=6ET M92`Q,#`-"B`@("`@("`@("`@(%-T+B!0875L+"!-3B`U-3$Q,@T*("!3=7!P M;W)T.B`@5&AE($EN=&5G2!3:6UU;&%T;W)S(&%N9"!087)A2!)0DE3(&9I;&4@=&\@8F4@9&ER96-T;'D@8V]N=F5R=&5D(&9O M#H@*#4P,RD@-CDV+30R,3`-"B`@061D"P@26YC+@T*("!#;VYT86-T.B`@0F]B(%)O'1E;G-I;VYS(&]F($E"25,@5F5R2`-"B`@ M("`@("`@("`@(&1E=F5L;W!M96YT(&ES(&%L:6=N960@6EN9R!I;G1E7-T96US+"!);F,N#0H@($-O;G1A8W0Z("!%6UO=VET>@T*("!%;6%I;#H@("`@#0H@(%!H;VYE.B`@ M("`H,S`S*2`X,S,M,#6%L#0H@($5M86EL.B`@("!2879E;F1E2`M('!R;W9I9&5S('1E8VAN:6-A;&QY(`T*("`@("`@ M("`@("`@6YT:&5S:7,L(&%N9"!S:6=N86P@:6YT96=R:71Y(&%N86QY65D($(N2'5Q#0H@($5M86EL.B`@("!H=7%`7-T96US("8@26YT97)F86-E(%!R M;V1U8W0@1W)O=7`H05-)4"D@;V8@3F%T:6]N86P-"B`@("`@("`@("`@(%-E M;6EC;VYD=6-T;W(@:7,@=VEL;&EN9R!T;R!C7-T96US(&UA#H@ M*S@Q("TT-"TT,S4M,3@X-R`-"D%D9')E"`W.3$Q(`T*("`@("`@("`@("`@3D,@4W1A M=&4@56YI=BX@#0H@("`@("`@("`@("!286QE:6=H+"!.0R`@,C'1R86-T:6YG(`T*("`@("`@("`@("`@24))4R!M;V1E;',N M("!!('EA8V,O;&5X('!A2P@26YC+@T*("!#;VYT86-T.B`@2F]N M(%!O=V5L;`T*("!%;6%I;#H@("`@:F]N<$!Q9'0N8V]M#0H@(%!H;VYE.B`@ M("`H.#`U*2`Y.#@M.#(U,"P@1F%X.B`H.#`U*2`Y.#@M.#(U.0T*("!!9&1R M97-S.B`@,3,X-2!$96P@3F]R=&4@4F0N#0H@("`@("`@("`@("!#86UA65T(`T*("`@("`@("`@("`@;&5G86PI(&UO9&5L2!G96YE6]U="!T2!T;V]L'1E;F1E9"!T M;R!%;&5C=')O;6%G;F5T:6,@0V]M<&%T:6)I;&ET>2`-"B`@("`@("`@("`@ M("A%34,I('1O;VQS+@T*#0I3=&%N9F]R9"!5;FEV97)S:71Y+"!$97!T(&]F M($5%+"!#;VUP=71E7-T96US($QA8@T*("!#;VYT86-T.B`@4F%N9&]L M<&@@12X@*%)A;F1Y*2!(87)R#0H@($5M86EL.B`@("!R86YD>6A`=FAD;"YO M7-T96US+"!);F,N#0H@($-O;G1A8W0Z("!!;F1Y($AU9VAE4!S>6UM971R>2YC;VT-"B`@4&AO;F4Z("`@("@T,34I M(#DT.2TY-C`P+"!&87@Z("@T,34I+3DT.2TP.#,Q#0H@($%D9')E6UM971R M>2=S(`T*("`@("`@("`@("`@;6]D96QI;F<@=&]O;"!-3T1015@@8V%N(&-R M96%T92!)0DE3(&UO9&5L7-T96T@9&5S:6=N+@T*#0I3 M>6YO<'-Y7,N8V]M#0H@(%!H;VYE.B`@("`H-3`S*2`V.3`M-CDP,"P@1F%X("@U,#,I M(#8Y,"TV.3`V#0H@($%D9')E2!3<&EC92!D:6%L96-T*2P@;VX@86X@875T;VUA=&EC(`T* M("`@("`@("`@("`@;65A;G,@=&\@9V5N97)A=&4@0R!C;V1E('1O(&)E(&QI M;FME9"!I;B!T;R!422!3<&EC92!A'0N(#,R,0T*("!!9&1R97-S.B`@,C2!C;VYT'1U Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04473; Fri, 9 Dec 94 18:04:33 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rGH6R-000UfEC; Fri, 9 Dec 94 18:00 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rGH6Q-000twtC; Fri, 9 Dec 94 18:00 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 9 Dec 94 18:00:02 PST Date: Fri, 9 Dec 94 18:00:02 PST From: Derrick Duehren Message-Id: <941209180002_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: Date/Place for Summit [respond by 1/3/95] Text item: Text_1 IBISians, State your preferences. Please respond by 1/3/95 so I can tally it before our 1/6/95 meeting. When would you like to meet for our face-to-face Summit? Please respond to me with your preferences. Please label the days/places: A (1st choice) PLEASE NOTE: You can have multiples of B (second) each type (i.e., more than one first choice). C (third) I will matrix them to find the appropriate day. X (no can do) Your DATE choices are: Day Date Vote ------------------------- Mon 1/30 __ Tues 1/31 __ Wed 2/1 __ Thur 2/2 __ Fri 2/3 __ Mon 2/6 __ Tues 2/7 __ Wed 2/8 __ Thur 2/9 __ Fri 2/10 __ Your PLACE choices are: City Vote Close to ---------------------------------------------------------------------------- Boston __ CKumar, BarryK, JayD Houston __ BobW Los Angeles __ JonP, KarlK, ArthurW Phoenix __ (no one, Intel facility, sunny) Pittsburgh __ EricB Portland __ WillH, StephenP, DerrickD, BobR, KelleeC, RavenderG, GeorgeO Santa Clara __ SyedH, DileepD, AndyH, ArpadM, DonT Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS: Date for December face-to-face To: IBIS@vhdl.org Message-Id: <941101175508_1@ccm.hf.intel.com> From: Derrick Duehren Date: Tue, 1 Nov 94 17:55:08 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 1 Nov 94 17:55:08 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r2Uur-000twdC; Tue, 1 Nov 94 17:55 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r2Uur-000UdtC; Tue, 1 Nov 94 17:55 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22318; Tue, 1 Nov 94 17:59:20 PST Received: from vhdl.vhdl.org by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r2VAJ-000Ue7C; Tue, 1 Nov 94 18:11 PST Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0r2VAK-000twfC; Tue, 1 Nov 94 18:11 PST From Derrick_Duehren@ccm2.jf.intel.com Mon Dec 12 10:18:29 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10808; Mon, 12 Dec 94 10:18:29 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHFG1-000UmPC; Mon, 12 Dec 94 10:13 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHFBH-000twhC; Mon, 12 Dec 94 10:09 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 12 Dec 94 10:09:03 PST Date: Mon, 12 Dec 94 10:09:03 PST From: Derrick Duehren Message-Id: <941212100903_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: Draft Press Release, Pls comment by 12/13/94 Text item: Text_1 IBISians, Below is my rough-cut draft of a 2.1 press release. Please post comments/suggestions to the reflector by 4:00 pm Tuesday 12/13/94. I will craft a revision and post it for email acceptance Wednesday. Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ For more information contact: IBIS Open Forum For Immediate Release Will Hobbs, (503) 696-4369 Jon Powell, (805) 988-8250 IBIS Press Release DRAFT 12/5/94 Rev 2.1 of IBIS Signal Integrity Model Specification Announced IBIS Standard that Supports Early, Accurate Models for Signal Integrity Simulations of High-speed Digital Systems Now Supports More Functions HILLSBORO, Ore. _ December 9, 1994 _ A group of Electronic Design Automation (EDA) and semiconductor companies today announced the ratification and acceptance of Revison 2.1 of the I/O Buffer Information Specification (IBIS) standard for integrity models. This improved and refined standard adds support for non-linear ramps, differential I/O, __________________, ___________________, and __________________________. IBIS is a consistent format that semiconductor vendors can use to specify the analog characteristics of input and output buffers. This essential information is readily transformed into accurate models by end users and simulation tool vendors. The resulting behavioral models enable users to perform high-speed, accurate signal-integrity simulations of their digital system interconnects. The IBIS Version 2.1 specification was developed through the cooperative efforts of simulator vendors and semiconductor companies who together comprise the IBIS Open Forum (see the attached roster). IBIS Models Available Intel, _______, and _______ have posted public models to the vhdl.org database. Group Plans to Formalize Standard in Early 1995 The IBIS Open Forum believes the specification is sufficiently robust and comprehensive to be taken to the standards community for formal adoption. For More Information For more information about the IBIS Open Forum, send an e-mail request to ibis-info@vhdl.org or call Karen Kirkpatrick, Cadence Design Systems, (508) 262-6448. All of the documents and publicly available models are currently accessible via the public repository of VHDL International's Internet based machine (vhdl.org, 198.31.14.3). FTP, Gopher, and public dial-in access methods are all supported. IBIS Open Forum Contact List (Roster) From Will_Hobbs@ccm2.jf.intel.com Mon Dec 12 10:38:42 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10954; Mon, 12 Dec 94 10:38:42 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHFZf-000UpDC; Mon, 12 Dec 94 10:34 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHFZd-000tymC; Mon, 12 Dec 94 10:34 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 12 Dec 94 10:34:12 PST Date: Mon, 12 Dec 94 10:34:12 PST From: Will Hobbs Message-Id: <941212103412_2@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Ibis Technology update Text item: Text_1 Ibis-ians, I just spoke again with Jeff Riskin at Ibis Technology, and he agrees with our original assessment that sharing the IBIS name with the fifty golf courses, laundries and others, including Ibis Technology, won't cause any problems for anyone. Will From ventham@quantic.mb.ca Mon Dec 12 12:18:33 1994 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12329; Mon, 12 Dec 94 12:18:33 PST Received: by access.mbnet.mb.ca with UUCP id AA06668 (5.67b/IDA-1.4.4 for ibis@vhdl.org); Mon, 12 Dec 1994 13:52:57 -0600 Received: by quantic.mb.ca (4.1/SMI-4.1) id AA28175; Mon, 12 Dec 94 13:52:34 CST From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9412121952.AA28175@quantic.mb.ca> Subject: Re: IBIS: Draft Press Release, Pls comment by 12/13/94 To: Derrick_Duehren@ccm2.jf.intel.com (Derrick Duehren) Date: Mon, 12 Dec 94 13:52:33 CST Cc: ibis@vhdl.org In-Reply-To: <941212100903_1@ccm.hf.intel.com>; from "Derrick Duehren" at Dec 12, 94 10:09 am X-Mailer: ELM [version 2.3 PL11] Inhabitants of IBIS, Here are my humble comments on the press-release. Comments are in parentheses. Greetings for the appropriate religious/capitalist season. Mike > > > Text item: Text_1 > > > IBISians, > > Below is my rough-cut draft of a 2.1 press release. Please post > comments/suggestions to the reflector by 4:00 pm Tuesday 12/13/94. I will > craft a revision and post it for email acceptance Wednesday. > > Derrick Duehren > ------------------------------------------------------------------------------ > XTG TPV Programs Manager, Intel Corp. | > Phone (503) 696-4299 | "Experience is not what happens to > Fax (503) 696-4904 | you; it's what you do with what > Derrick_Duehren@ccm.jf.intel.com | happens to you." > 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley > Hillsboro, OR 97224 | > ------------------------------------------------------------------------------ > > > > For more information contact: > IBIS Open Forum For Immediate Release > Will Hobbs, (503) 696-4369 > Jon Powell, (805) 988-8250 > > IBIS Press Release > DRAFT 12/5/94 > > Rev 2.1 of IBIS Signal Integrity Model Specification Announced > IBIS Standard that Supports Early, Accurate Models for Signal Integrity > Simulations of High-speed Digital Systems Now Supports More Functions > > HILLSBORO, Ore. _ December 9, 1994 _ A group of Electronic Design Automation > (EDA) and semiconductor companies today announced the ratification and > acceptance of Revison 2.1 of the I/O Buffer Information Specification (IBIS) > standard for integrity models. This improved and refined standard adds support ^ signal > for non-linear ramps, differential I/O, __________________, termination components, > ___________________, and __________________________. ECL characteristics improved package models > > IBIS is a consistent format that semiconductor vendors can use to specify the > analog characteristics of input and output buffers. This essential information > is readily transformed into accurate models by end users and simulation tool > vendors. The resulting behavioral models enable users to perform high-speed, > accurate signal-integrity simulations of their digital system interconnects. > > The IBIS Version 2.1 specification was developed through the cooperative > efforts of simulator vendors and semiconductor companies who together comprise > the IBIS Open Forum (see the attached roster). (Do we want to mention the parser?) > > IBIS Models Available > > Intel, _______, and _______ have posted public models to the vhdl.org database. Intel Intel > > Group Plans to Formalize Standard in Early 1995 > > The IBIS Open Forum believes the specification is sufficiently robust and > comprehensive to be taken to the standards community for formal adoption. (I guess we don't want to say how or who at the moment?) This is planned to take place in the first quarter of 1995. > > For More Information > > For more information about the IBIS Open Forum, send an e-mail request to > ibis-info@vhdl.org or call Karen Kirkpatrick, Cadence Design Systems, (508) > 262-6448. All of the documents and publicly available models are currently > accessible via the public repository of VHDL International's Internet based > machine (vhdl.org, 198.31.14.3). FTP, Gopher, and public dial-in access > methods are all supported. (What no multimedia/WWW/Mosaic access ?) > > IBIS Open Forum > Contact List (Roster) > -- +======================================================================+ | Mike Ventham - Vice President Engineering, Quantic Laboratories Inc, | | 12th Floor, 191 Lombard Ave, Winnipeg, Manitoba, Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email: ventham@quantic.mb.ca | +======================================================================+ From Will_Hobbs@ccm2.jf.intel.com Mon Dec 12 15:22:19 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13555; Mon, 12 Dec 94 15:22:19 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHJzv-000Uo7C; Mon, 12 Dec 94 15:17 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHJzv-000twsC; Mon, 12 Dec 94 15:17 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 12 Dec 94 15:17:38 PST Date: Mon, 12 Dec 94 15:17:38 PST From: Will Hobbs Message-Id: <941212151738_9@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, IBIS@vhdl.org Subject: Re: IBIS: Draft Press Release, Pls comment by 12/13/94 Text item: Text_1 IBISers, Will's comments preceded by *. Will Hobbs Intel Corp. IBISians, Below is my rough-cut draft of a 2.1 press release. Please post comments/suggestions to the reflector by 4:00 pm Tuesday 12/13/94. I will craft a revision and post it for email acceptance Wednesday. Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ For more information contact: IBIS Open Forum For Immediate Release Will Hobbs, (503) 696-4369 * (number not to be published) Jon Powell, (805) 988-8250 IBIS Press Release DRAFT 12/5/94 Rev 2.1 of IBIS Signal Integrity Model Specification Announced IBIS Standard that Supports Early, Accurate Models for Signal Integrity Simulations of High-speed Digital Systems Now Supports More Functions HILLSBORO, Ore. _ December 9, 1994 _ A group of Electronic Design Automation (EDA) and semiconductor companies today announced the ratification and acceptance of Revison 2.1 of the I/O Buffer Information Specification (IBIS) standard for integrity models. This improved and refined standard adds support for * ECL, dual-supply buffers, differential I/O, controlled rise-time buffers, much more complete package descriptions, better support for open-side devices (open drain, etc.), support for terminators, reference waveform. IBIS is a consistent * software parsable format that semiconductor vendors can use to specify the analog characteristics of input and output buffers. This essential information is readily transformed into accurate models by end users and simulation tool vendors. The resulting behavioral models enable users to perform high-speed, accurate signal-integrity simulations of their digital system interconnects. The IBIS Version 2.1 specification was developed through the cooperative efforts of simulator vendors and semiconductor companies who together comprise the IBIS Open Forum (see the attached roster). IBIS Models Available Intel, _______, and _______ have posted public models to the vhdl.org database. * Many others are available directly from EDA vendors and IC vendors. Group Plans to Formalize Standard in Early 1995 The IBIS Open Forum believes the specification is sufficiently robust and comprehensive to be taken to the standards community for formal adoption. For More Information For more information about the IBIS Open Forum, send an e-mail request to ibis-info@vhdl.org or call Karen Kirkpatrick, Cadence Design Systems, (508) 262-6448. All of the documents and publicly available models are currently accessible via the public repository of VHDL International's Internet based machine (vhdl.org, 198.31.14.3). FTP, Gopher, and public dial-in access methods are all supported. IBIS Open Forum Contact List (Roster) Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS: Draft Press Release, Pls comment by 12/13/94 To: IBIS@vhdl.org Message-Id: <941212100903_1@ccm.hf.intel.com> From: Derrick Duehren Date: Mon, 12 Dec 94 10:09:03 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 12 Dec 94 10:09:03 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHFBH-000twhC; Mon, 12 Dec 94 10:09 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHFG1-000UmPC; Mon, 12 Dec 94 10:13 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10808; Mon, 12 Dec 94 10:18:29 PST Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Mon, 12 Dec 94 10 Received: from aurora by ichips.intel.com (5.64+/10.0i); Mon, 12 Dec 94 10:43:19 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rHFj5-000twfC; Mon, 12 Dec 94 10:43 PST From Will_Hobbs@ccm2.jf.intel.com Mon Dec 12 15:25:48 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13584; Mon, 12 Dec 94 15:25:48 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHK3V-000UoIC; Mon, 12 Dec 94 15:21 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHK3Q-000txKC; Mon, 12 Dec 94 15:21 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 12 Dec 94 15:21:15 PST Date: Mon, 12 Dec 94 15:21:15 PST From: Will Hobbs Message-Id: <941212152115_1@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, IBIS@vhdl.org Subject: Re: IBIS: Date/Place for Summit [respond by 1/3/95] Text item: Text_1 IBISians, State your preferences. Please respond by 1/3/95 so I can tally it before our 1/6/95 meeting. When would you like to meet for our face-to-face Summit? Please respond to me with your preferences. Please label the days/places: A (1st choice) PLEASE NOTE: You can have multiples of B (second) each type (i.e., more than one first choice). C (third) I will matrix them to find the appropriate day. X (no can do) Your DATE choices are: Day Date Vote ------------------------- Mon 1/30 D__ Tues 1/31 __ Wed 2/1 __ Thur 2/2 __ Fri 2/3 A__ Mon 2/6 C__ Tues 2/7 __ Wed 2/8 __ Thur 2/9 __ Fri 2/10 B__ Your PLACE choices are: City Vote Close to ---------------------------------------------------------------------------- Boston C__ CKumar, BarryK, JayD Houston C__ BobW Los Angeles B__ JonP, KarlK, ArthurW Phoenix D__ (no one, Intel facility, sunny) Pittsburgh D__ EricB Portland B__ WillH, StephenP, DerrickD, BobR, KelleeC, RavenderG, GeorgeO Santa Clara A__ SyedH, DileepD, AndyH, ArpadM, DonT I thought Dallas was still in the running. I would mark it B. -- Will H. Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS: Date for December face-to-face To: IBIS@vhdl.org Message-Id: <941101175508_1@ccm.hf.intel.com> From: Derrick Duehren Date: Tue, 1 Nov 94 17:55:08 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 1 Nov 94 17:55:08 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r2Uur-000twdC; Tue, 1 Nov 94 17:55 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r2Uur-000UdtC; Tue, 1 Nov 94 17:55 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22318; Tue, 1 Nov 94 17:59:20 PST Received: from vhdl.vhdl.org by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r2VAJ-000Ue7C; Tue, 1 Nov 94 18:11 PST Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0r2VAK-000twfC; Tue, 1 Nov 94 18:11 PST Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS: Date/Place for Summit [respond by 1/3/95] To: IBIS@vhdl.org Message-Id: <941209180002_1@ccm.hf.intel.com> From: Derrick Duehren Date: Fri, 9 Dec 94 18:00:02 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 9 Dec 94 18:00:02 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rGH6Q-000twtC; Fri, 9 Dec 94 18:00 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rGH6R-000UfEC; Fri, 9 Dec 94 18:00 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04473; Fri, 9 Dec 94 18:04:33 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 9 Dec 94 18: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Fri, 9 Dec 94 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rGHQG-000tx9C; Fri, 9 Dec 94 18:20 PST From Derrick_Duehren@ccm2.jf.intel.com Mon Dec 12 18:00:27 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14659; Mon, 12 Dec 94 18:00:27 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHMT5-000UhXC; Mon, 12 Dec 94 17:55 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHMT4-000tx1C; Mon, 12 Dec 94 17:55 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 12 Dec 94 17:55:54 PST Date: Mon, 12 Dec 94 17:55:54 PST From: Derrick Duehren Message-Id: <941212175554_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Official IBIS Ver. 2.1 Spec Text item: Text_1 IBISians, Attached (as an ASCII file) and posted to vhdl.org pub\ibis\ver2.1 directory, please find the official, ratified IBIS 2.1 specification. Enjoy - Merry Christmas! Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ Text item: ver2_1.txt 12/12/94 5:46P |============================================================================== | I/O Buffer Information Specification (IBIS) Version 2.1 (12/9/94) | | IBIS is a standard for electronic behavioral specifications of integrated | circuit input/output analog characteristics. |============================================================================== | 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 2.0 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. | | Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility | with Versions 1.0 and 1.1. All new keywords and elements added in Version | 2.0 are optional. A complete list of changes to the specification is in the | IBIS Version 2.0 Release Notes document ("ver2_0.rn"). | | Version 2.1 update. The file "ver2_1.ibs" contains clarification text | changes, corrections, and two additional waveform parameters beyond | Version 2.0. | |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. 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 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 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) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in sub-parameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, Henries, and Seconds.) | The parser looks 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). | | 9) 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. | | 10) Currents are considered positive when their direction is into the | component. | | 11) All temperatures are represented in degrees Celsius. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | 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] 2.1 | Used for template variations | |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character 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 is 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: Specifies 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] ver2_1.ibs | |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is 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] [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: These keywords' arguments can contain blanks, and be of | any format. The [Date] keyword argument is limited to a | maximum of 40 characters. | | Because IBIS model writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools should make this information | available. Derivative models should include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative models verbatim. |------------------------------------------------------------------------------ [Date] 12/09/94 | The latest file revision date | [Source] Put originator and the 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] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | [Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks 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. | | NOTE: Blank characters are not recommended due to usability | issues. |------------------------------------------------------------------------------ [Component] 7403398 MC452 | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies 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] Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines 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: The typical (typ) 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. Use the [Package Model] keyword for more | complex package descriptions. If defined, the [Package Model] | data overrides the values in the [Package] keyword. | Regardless, the data listed under the [Package] keyword must | still contain valid data. |------------------------------------------------------------------------------ [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: Associates 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 | |============================================================================== | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model | Usage Rules: The package model name is limited to 40 characters. | Spaces are allowed in the name. The name should include the | company name or initials to help ensure uniqueness. The | simulator will search for a matching package model name as an | argument to a [Define Package Model] keyword in the current | IBIS file first. If a match is not found, the simulator will | look for a match in an external .pkg file. If the package | model is in a separate .pkg file, it must be kept in the same | directory as the .ibs file. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that part. | The specification permits .ibs files to contain [Define | Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models | that have the same name. |------------------------------------------------------------------------------ [Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Pin Mapping] | Required: No |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. Use the | NC reserved word for entries that are not needed or that follow | the conditions below: | | All entries with identical labels are assumed to be connected. | Each unique entry label must connect to at least one pin whose | model_name is POWER or GRD. | | If a pin has no connection, then both the pulldown_ref | and pullup_ref sub-parameters 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 overridden 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 overridden by a | specification in the power_clamp_ref column. | | The 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 | | When 5 columns are specified, the headings gnd_clamp_ref and | power_clamp_ref must be used. Otherwise, these headings can | be omitted. |--------------------------------------------------------------------------- [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 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 | . 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps | |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and 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 forth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes 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, vdiff is 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 is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | 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 is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is 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, Vmeas, Cref, | Rref, Vref | Usage Rules: Each model type 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. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except | for those model names that 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. | | Model_type must be one of the following: | 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. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl=0.8V and Vinh=2.0V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl=-1.475V and Vinh=-1.165V | are assumed. | | Terminator This model type 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, and | pull-up resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | | 3-state This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | | Open_sink These model types indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = 0mA | for all voltages specified) and the output | SINKS current. Open_drain model type is | retained for backward compatibility. | | Open_source This model type indicates that the | output has an OPEN side (do not use the | [Pulldown] keyword, or if it must be used, | set I = 0mA for all voltages specified) and | the output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | keyword. | | The Model_type and C_comp sub-parameters are required. The | Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref sub- | parameters are optional. C_comp defines the silicon die | capacitance. This value should not include the capacitance of | the package. C_comp is allowed to use "NA" for the min and max | values only. The Polarity sub-parameter can be defined as | either Non-Inverting or Inverting, and the Enable sub- | parameter can be defined as either Active-High or Active-Low. | | The Cref and Rref sub-parameters correspond to the test load | that the manufacturer uses when specifying the propagation | delay and/or output switching time of the device. The Vmeas | sub-parameter is the reference voltage level that the | manufacturer uses for the component. Include Cref, Rref, and | Vmeas information to facilitate board-level timing simulation. | The assumed connections for Cref, Rref, and Vref are shown in | the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one | or more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, | some models may have only a subset of 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. |------------------------------------------------------------------------------ | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V |Reference voltage for timing measurements Cref = 50pF |Timing specification test load capacitance value Rref = 500 |Timing specification test load resistance value Vref = 0 |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== | Keyword: [Temperature Range] | Required: Yes, if other than the preferred 0, 50, 100 degree C range | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various V/I curves and ramp rates were | derived. |------------------------------------------------------------------------------ | variable typ min max [Temperature Range] 27.0 -50 130.0 | |============================================================================== | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], | [POWER Clamp Reference], and [GND Clamp Reference] are not | present |Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the pull-up and [POWER Clamp] V/I data is | referenced. |Usage Rules: Provide actual voltages (not percentages) in the 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: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | pull-up V/I data. |Usage Rules: Provide actual voltages (not percentages) in the 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: Defines a power supply rail other than 0V as the reference | voltage for the pull-down V/I data. If this keyword is not | present, the voltage data points in the pull-down V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the 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 typ, 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: Defines 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: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Refer the "Other Notes" section of the [GND Clamp Reference] | keyword. |--------------------------------------------------------------------------- | 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: Defines 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: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Power Supplies: It is intended 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 pull-up, | pull-down, or clamp structure is referenced to something other | than the default supplies, use the additional 'reference' | keywords. | | 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. |---------------------------------------------------------------------------- | variable typ min max [GND Clamp Reference] 0V 0V 0V | |============================================================================== | 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 pull-down and pull-up structures of an output buffer and | the V/I curves of the clamping diodes connected to the GND and | the POWER pins, respectively. 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: 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. (Note: Under these keywords, all | references to 'Vcc' refer to the voltage rail defined by the | [Voltage range], [Pullup Reference], or [POWER Clamp Reference] | keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5V in the table actually | means 5V above Vcc, which is +10V with respect to ground; | and 10V means 10V below Vcc, which is -5V with respect to | ground. Vcc-relative data is necessary to model a pull-up | structure properly, since the output current of a pull-up | 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. | | When tabulating data for ECL devices, the data in the pull-down | 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 | pull-up 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 of | these cases, the data is referenced to the Vcc supply voltage, | using the equation Vtable = Vcc - Voutput. | | Monotonicity Requirements: | 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. | | An IBIS syntax checking program shall test for non-monotonic | data and provide a maximum of one note per V/I table if | non-montonic data is found. For example: | "NOTE: Line 300, Pulldown V/I table for model DC040403 is | non-monotonic! Most simulators will filter this data | to remove the non-monotonic data." | | It is also recognized that the 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 IBIS Version 2.x syntax checking programs, such | programs will conduct monotonicity testing only on one | V/I table at a time. | | It is assumed that the simulator sums the clamp curves | together with the appropriate pull-up or pull-down 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 pull-up and pull-down 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, with the I/O buffer 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 pull-up and | pull-down 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 can demonstrate a | non-monotonic shape.) This requirement enables 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 cannot be measured alone), the pull-up and | pull-down curves of an IBIS model can 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] | Note: Vtable = Vcc - Voutput | | 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] | Note: Vtable = Vcc - Voutput | | 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 | |============================================================================== | 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 keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max), or the three entries | for 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 coexist with [GND Clamp] | and [POWER Clamp] structures. If the terminator consists | of a series R and C (often referred to as either an AC or RC | terminator), then both [Rac] and [Cac] are required. When | [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the | Model_type must be Terminator. | | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | VI | \ Rpower [Package] Keyword | | | / Sub-parameters | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | VI | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp Ref] | | | | | | | o-------------------o----------------------o | | | o | GND |------------------------------------------------------------------------------ | 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 and terminators | Description: Defines the rise and fall times of a buffer. The ramp rate does | not include packaging but does include the effects of the C_comp | parameter. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. | The ramp rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load sub-parameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 2.20/1.06n 1.92/1.28n 2.49/650p dV/dt_f 2.46/1.21n 2.21/1.54n 2.70/770p R_load = 300ohms | |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, | 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, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | 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. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | 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 specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut Sub-params are analogous to 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 |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- 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. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | sub-parameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example 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 | |============================================================================= | | PACKAGE MODELING | | The [Package Model] keyword is optional. If more than the default RLC | package model is desired, use the [Define Package Model] keyword. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... | [End Package Model] keywords for each package model that is defined. For | reference, these keywords are listed below. Full descriptions follow. | Simulators that do not support these keywords will ignore all entries between | the [Define Package Model] and [End Package Model] keywords. | | [Define Package Model] Required if the [Package Model] keyword is used | [Manufacturer] (note 1) | [OEM] (note 1) | [Description] (note 1) | [Number of Pins] (note 1) | [Pin Numbers] (note 1) | [Model Data] (note 1) | [Resistance Matrix] Optional | [Inductance Matrix] (note 1) | [Capacitance Matrix] (note 1) | [Bandwidth] Required (for Banded_matrix matrices only) | [Row] (note 1) | [End Model Data] (note 1) | [End Package Model] (note 1) | | (note 1) Required when the [Define Package Model] keyword is used | | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | | USAGE RULES FOR THE .PKG FILE | | Package models are stored in a file whose name looks like: | .pkg. | | The provided must adhere to the General Syntax Rules. Use the | ".pkg" extension to identify files containing package models. The .pkg file | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg | file. The .pkg file is for package models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package | model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes | Description: Declares the manufacturer of the package. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of | what kind of package the [Package Model] is representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |============================================================================== | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the package | pins, and to define an ordering of them. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." The pin names can not exceed 5 characters in | length. | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are | pins (as given by the preceding [Number of Pins].) |------------------------------------------------------------------------------ [Pin Numbers] A1 A2 | . | . | . A22 B1 | . | . | . | etc. | |============================================================================== | Keyword: [Model Data] | Required: Yes | Description: Indicates the beginning of the formatted package model data, | which can include the [Resistance Matrix], [Inductance Matrix], | [Capacitance Matrix], [Bandwidth], and [Row] keywords. |------------------------------------------------------------------------------ [Model Data] | |============================================================================== | Keyword: [End Model Data] | Required: Yes | Description: Indicates the end of the formatted model data. | Other Notes: In between the [Model Data] and [End Model Data] keywords is | the package model data itself. The data is a set of 3 | matrices: the resistance (R), inductance (L), and capacitance | (C) matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords below to mark the | beginning of each new matrix. |------------------------------------------------------------------------------ [End Model Data] | |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The sub-parameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the sub-parameters. | After each of these sub-parameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board | (General Syntax Rule #10). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | | For even a modest-sized package, this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | The first row only needs to specify the entries [1,1] through [1,1+B] since | any other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2, 2+B], and so on. In general, for row M | the entries [M,M] through [M,M+B] are given. | | Unlike the Full_matrix, each successive row will typically have the same | number of entries, except for the last few rows. When M + B finally exceeds | the size of the matrix N, then the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | Also, note that it is again necessarily the case that the N'th | row of an N x N matrix has just a single entry (the diagonal entry.) | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 [Date] December 9, 1994 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor | base its data on typical process data, and then derate by voltage and | temperature, and a proprietary "X%" factor. This methodology also has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | 1) V/I curves for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "X%" | max = maximum voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "X%" | max = maximum voltage, max temp deg C, typical process, plus "X%" | | Nominal, min, and max temperature are specified by the manufacturer | of the part. The default range is 50C nom, 0C min, and 100C max | temperatures. | | X% should be statistically determined by the silicon vendor based | on numerous fab lots, test chips, process controls, etc.. The value | of X need not be published in the IBIS file, and may decrease over | time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | As described in the [Pulldown Reference] keyword section, the V/I curve of | the [Pullup] and the [POWER Clamp] structures are 'Vcc relative', using | the equation: Vtable = Vcc - Voutput. | | For example, a device with a 5V power supply voltage should be | characterized between (0 - 5) = -5V and (5 + 5) = 10V; and a | device with a 3.3V power supply should be characterized between | (0 - 3.3) = -3.3V and (3.3 + 3.3) = 6.6V for the pull-down curve. | | When tabulating output data for ECL type devices, the voltage points | must span the range of Vcc to Vcc - 2.2V. This range applies to both the | pull-up and pull-down tables. Note that this range applies ONLY when | characterizing an ECL output. | | These voltage ranges must be spanned by the IBIS data. Data derived | from lab measurements may not be able to span these ranges as such and | so may need to be extrapolated to cover the full range. This data must | not be left for the simulator to provide. | | 3) Ramp Rates: | The following steps assume that the default load resistance of 50 ohms is | used. There may be devices that will not drive a load of only 50 ohms | into any useful level of dynamics. In these cases, use the manufacturer's | suggested (non-reactive) load and add the load sub parameter to the [Ramp] | specification. | | The ramp rate does not include packaging but does include the effects of | the C_comp parameter; it is the intrinsic output stage rise and fall time | only. | | The ramp rates (listed in AC characteristics below) should be derived | as follows: | | a. If starting with the silicon model, remove all packaging. If starting | with a packaged device, perform the measurements as outlined below then | use whatever techniques are appropriate to derive the actual, unloaded | rise and fall times. | | b. If: The Model_type is one of the following: Output, I/O, or | 3-state (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | | If: The Model_type is Output_ECL or I/O_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either POWER or the vendor- | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either GND or the vendor-suggested | termination voltage. Use this load to derive both the rising | and falling edges. | | c. Due to the resistor, output swings will not make a full transition as | expected. However the pertinent data can still be collected as | follows: | 1) determine the 20% to 80% voltages of the 50 Ohm swing | 2) measure this voltage change as "dV" | 3) measure the amount of time required to make this swing "dt" | d. Post the value as a ratio "dV/dt". The simulation tool vendor | extrapolates this value to span the required voltage swing range in | the final model. | | e. Typ, Min, and Max must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "Y%" | max = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "Y%" | max = maximum voltage, max temp deg C, typical process, plus "Y%" | | where nominal, min, and max temp are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min, and 100C max | temperatures. | | Note that the derate factor, "Y%", may be different than that used | for the V/I curve data. This factor is similar to the X% factor | described above. As in the case of V/I curves, temperatures are | junction temperatures. | | f. During the IV measurements, the driving waveform should have a | rise/fall time fast enough to avoid thermal feedback. The specific | choice of sweep time is left to the modeling engineer. | | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. IBIS SPEC V2.1 Ratified 12/9/94 k:\ibis\spec\ver2_1.doc Page 28 Printed: 12/9/94 From Derrick_Duehren@ccm2.jf.intel.com Mon Dec 12 18:04:35 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14680; Mon, 12 Dec 94 18:04:35 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHMXA-000Uh8C; Mon, 12 Dec 94 18:00 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHMX8-000twuC; Mon, 12 Dec 94 18:00 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 12 Dec 94 18:00:04 PST Date: Mon, 12 Dec 94 18:00:04 PST From: Derrick Duehren Message-Id: <941212180004_1@ccm.hf.intel.com> To: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com, IBIS@vhdl.org Subject: IBIS: 12/9/94 Meeting Minutes (2.1 ratification) Text item: Text_1 Date: Dec. 12, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum Meeting 12/9/94 To: AT&T Global Info Systems Dave Moxley Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec Dileep Divkar Digital Equipment Corp. Barry Katz* EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HyperLynx Kellee Crisafulli IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, Hoa Quoc, John Burnett INCASES Werner Rissiek, Olaf Rethmeier Integrated Silicon Systems Eric Bracken Integrity Engineering Greg Doyle Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross*, Scott Bloom Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal Meta-Software Mei Wong, You-Pang Wei, John Sliney NEC Hiroshi Matsumoto MicroSim Arthur Wong National Semiconductor Syed Huq North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn PC Ware Paul Munsey, Ron Neville Quad Design Jon Powell* Quantic Labs Mike Ventham* Racal-Redac John Berrie Stanford University Randy Harr Stree Co. Mon Seng(sp?) Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum* Zeelan Technology George Opsahl, Hiro Moriyasu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # TBD (916) 356-9999 TBD All meetings are 8:00 AM to 10:00 AM PDT (16:00 to 18:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. NOTE: "AR" = Action Required. ------------------------------------------------------------------------------ Check-in, Intros, Announcements There were no new participants. There were no corrections made to last month's minutes. To date eight companies have paid for the Version 2.0. We discussed possible reasons why only 8 companies have purchased the 2.0 parser. Is there little interest in 2.0? Is there little interest in IBIS altogether? Are others just waiting for the final version? For Ver 1.1, 10 companies bought the GP early, 10 bought after ratification. Jon Powell suggested raising the fee to $1,000 in another month to encourage purchases now. After discussion, we decided to keep the price at $500 to help encourage participation. Update: Another company has subscribed. Will is awaiting confirmation. New Agenda Items: BIRD 24, C_comp, ramp rates and waveform tables Press Updates: Derrick started a draft press release. It needs work. Bob Ross suggests keeping it short. We asked for any quotes that anyone cares to volunteer. We decided to approve the press release via the reflector. We will try to get it out within a week. AR All - Send updates of the roster to Derrick. AR Derrick - Add a disclaimer to the public roster document indicating that appearance on the list does not imply active participation and support. [DONE] AR Derrick - Submit a draft press release to the reflector today. [DONE] Note: Derrick will disappear on vacation 12/14 through Jan 1. Progress toward enlisting new IC vendors Xilinx Spice-to-IBIS effort has generated models that Bob Ross has reviewed, commented on, and are being revised. When ready, Xilinx will make them publicly available. Will reported that a 2.0 IBIS model of a yet unannounced Intel processor will be distributed to Intel customers soon (simulator vendors take note). Intel is also working internally to validate Intel's "Simplified Electrical Model" SEM-within-IBIS effort. This leverages the software-parsable nature of IBIS to widely disseminate models that have been evaluated by, and have the stamp of approval of, Intel's division responsible for the Pentium(TM) processor family. Intel also posted two updated chipset models (82434NX, and 82433NX) to vhdl.org. Golden Parser, 2.0 Paul reported that he and Ron have nearly completed their parser development and they expect to finish up next week (Ron has a few final questions). We discussed the naming conventions associated with preliminary releases of the 2.1 parser. We decided to not label the parser "2.1" until it is fully compliant with the ratified 2.1 spec. Versions before that are 2.0a, 2.0b, etc. The next Beta release will be next week. AR Will - Verify that you are using Barry Katz' latest address from the roster. Paul commented that he doesn't expect to roll in the final changes until after the holidays. He will evaluate all the parser changes that are needed to reflect the latest spec changes and submit an estimate to the forum. AR Paul - estimate the cost of bringing the parser up to full 2.1 level. Paul was able to create a component of 3,000 pins with no memory problems, then one with 100 rising waveforms with 100 points, 100 falling, etc. He found he could do 2,000 pins with 5 models, then his editor ran out of steam. It appears that by not saving data that isn't necessary, memory problems no longer exist under DOS 6.02. BIRD 21.1 Ratification Reapproved by consent as printed in draft B of the 2.1 draft spec document. BIRD 23 Ratification Minimum number of waveform points clarification. Numeric entries must be in V/I tables for first and last entries in any column that has numerical data. Approved unanimously. BIRD 24, C_comp, ramp rates and waveform tables, ratification This BIRD was modified (inverted!) and then approved unanimously for Ver 2.1 as follows: STATEMENT OF THE RESOLVED SPECIFICATIONS: The specification is changed in three places. The first is in the 'NOTES ON DATA DERIVATION METHOD' section under Ramp Rates. The second paragraph is modified to read as follows: "The ramp rate does not include packaging but does include the effects of the C_comp parameter; it is the intrinsic output stage rise and fall time only." In the section of the spec describing the [Ramp] keyword the following statement is added after the first sentence of the description: "The ramp rate does not include packaging but does include the effects of the C_comp parameter." Likewise, the section describing the [Rising Waveform], [Falling Waveform] is modified to add the following at the end of the first paragraph: "The data in the waveform table is taken with the effects of the C_comp parameter included." Discussion details: When ramp rate is generated, it is done by dividing dV/dT, with C_Comp = 0, assumed Stephen. We have disagreement in forum on this point, and BIRD 24 proposes we explicitly state our assumption. Arpad says that his original model required C_Comp = 0, but the V1.1 says to measure with package removed, but doesn't mention C_Comp, making C_Comp implicitly included. Measurement is impossible to do without C_Comp. Even Spice has it in. The 50 models published by TI have data that would be nearly impossible to back out C_Comp by playing with the Spice parameters. Jon Powell discussed the difficulty of generating IBIS models to IBIS spec through measurement, especially with regard to package parameters, waveform tables, and probing recommendations. We agreed to discuss, at some future time, enhancements to IBIS that could help those developing models through measurement. It is preferred but not required to extract the waveform with the package parameters removed, but it is not required. If r_dut, c_dut, and l_dut are not included We won't make this change to BIRD 24, since it is already clear in the spec. We made specific changes to the wording of BIRD 24 and we passed it. AR Stephen - Make agreed changes, publish as BIRD 24.1 and put on reflector. [Done] V_load Discussion Bob Ross proposed that the V_Load keyword doesn't need to be added, since 2.0 already allows it using the waveform method. A linear waveform can be used instead of [ramp], stating the conditions explicitly. We decided that it was too complicated to implement... a non issue. IBIS Spec Rev 2.1 Ratification Minor grammatical and typo changes were made, and "Seconds" was added as a scaling factor. VOTE TAKEN, IBIS SPEC REV 2.1 WAS APPROVED UNANIMOUSLY. AR Derrick - Input the changes, publish Ver 2.1 to the reflector, and post it to vhdl.org. [DONE] IBIS General Session/Summit (face-to-face) AR All - Please continue to post topics to the reflector whether or not you think it's hot. For example, your experiences implementing IBIS can be valuable to others. AR - Derrick arrange date/time/place for January meeting Jan 30th - Feb 10th. and city preferences. AR Will - Mail EIA documents to Bob Ross. Rev 2.1 Fallout The following items need to be updated to support/reflect the updated spec. Bob Ross volunteered to help in some way. Will suggested that the Overview document should be first so we're not giving out old information. o Cookbook o Overview o S2IBIS What to do with Existing Models that Don't have the C_Comp Subparameters AR All - Everyone who has created IBIS models should review their models to determine if C_comp is properly represented per the new definition of C_comp. Wrap-up, Next Meeting Plans Our next meeting is 1/6/95. We will determine then what future schedule of meetings we want. ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From Will_Hobbs@ccm2.jf.intel.com Tue Dec 13 08:51:49 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23639; Tue, 13 Dec 94 08:51:49 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rHaIj-000UgNC; Tue, 13 Dec 94 08:42 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rHaIi-000txBC; Tue, 13 Dec 94 08:42 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 13 Dec 94 08:42:08 PST Date: Tue, 13 Dec 94 08:42:08 PST From: Will Hobbs Message-Id: <941213084208_1@ccm.jf.intel.com> To: ventham@quantic.mb.ca, Derrick_Duehren@ccm2.jf.intel.com Cc: ibis@vhdl.org Subject: Re[2]: IBIS: Draft Press Release, Pls comment by 12/13/94 Text item: Mike, Thanks for pointing out the parser omission. I think it should be mentioned. Regarding EIA, until we actually begin the formal affiliation, I would vot not to mention it. What if, for some reason, it doesn't pan out? Regards, Will Hobbs Intel Corp. Inhabitants of IBIS, Here are my humble comments on the press-release. Comments are in parentheses. Greetings for the appropriate religious/capitalist season. Mike > > > Text item: Text_1 > > > IBISians, > > Below is my rough-cut draft of a 2.1 press release. Please post > comments/suggestions to the reflector by 4:00 pm Tuesday 12/13/94. I will > craft a revision and post it for email acceptance Wednesday. > > Derrick Duehren > ----------------------------------------------------------------------------- - > XTG TPV Programs Manager, Intel Corp. | > Phone (503) 696-4299 | "Experience is not what happens to > Fax (503) 696-4904 | you; it's what you do with what > Derrick_Duehren@ccm.jf.intel.com | happens to you." > 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley > Hillsboro, OR 97224 | > ----------------------------------------------------------------------------- - > > > > For more information contact: > IBIS Open Forum For Immediate Release > Will Hobbs, (503) 696-4369 > Jon Powell, (805) 988-8250 > > IBIS Press Release > DRAFT 12/5/94 > > Rev 2.1 of IBIS Signal Integrity Model Specification Announced > IBIS Standard that Supports Early, Accurate Models for Signal Integrity > Simulations of High-speed Digital Systems Now Supports More Functions > > HILLSBORO, Ore. _ December 9, 1994 _ A group of Electronic Design Automation > (EDA) and semiconductor companies today announced the ratification and > acceptance of Revison 2.1 of the I/O Buffer Information Specification (IBIS) > standard for integrity models. This improved and refined standard adds support ^ signal > for non-linear ramps, differential I/O, __________________, termination components, > ___________________, and __________________________. ECL characteristics improved package models > > IBIS is a consistent format that semiconductor vendors can use to specify the > analog characteristics of input and output buffers. This essential information > is readily transformed into accurate models by end users and simulation tool > vendors. The resulting behavioral models enable users to perform high-speed, > accurate signal-integrity simulations of their digital system interconnects. > > The IBIS Version 2.1 specification was developed through the cooperative > efforts of simulator vendors and semiconductor companies who together comprise > the IBIS Open Forum (see the attached roster). (Do we want to mention the parser?) > > IBIS Models Available > > Intel, _______, and _______ have posted public models to the vhdl.org database. Intel Intel > > Group Plans to Formalize Standard in Early 1995 > > The IBIS Open Forum believes the specification is sufficiently robust and > comprehensive to be taken to the standards community for formal adoption. (I guess we don't want to say how or who at the moment?) This is planned to take place in the first quarter of 1995. > > For More Information > > For more information about the IBIS Open Forum, send an e-mail request to > ibis-info@vhdl.org or call Karen Kirkpatrick, Cadence Design Systems, (508) > 262-6448. All of the documents and publicly available models are currently > accessible via the public repository of VHDL International's Internet based > machine (vhdl.org, 198.31.14.3). FTP, Gopher, and public dial-in access > methods are all supported. (What no multimedia/WWW/Mosaic access ?) > > IBIS Open Forum > Contact List (Roster) > -- +======================================================================+ | Mike Ventham - Vice President Engineering, Quantic Laboratories Inc, | | 12th Floor, 191 Lombard Ave, Winnipeg, Manitoba, Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email: ventham@quantic.mb.ca | +======================================================================+ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. X-Mailer: ELM [version 2.3 PL11] In-Reply-To: <941212100903_1@ccm.hf.intel.com>; from "Derrick Duehren" at Dec 12 Cc: ibis@vhdl.org Date: Mon, 12 Dec 94 13:52:33 CST To: Derrick_Duehren@ccm2.jf.intel.com (Derrick Duehren) Subject: Re: IBIS: Draft Press Release, Pls comment by 12/13/94 Message-Id: <9412121952.AA28175@quantic.mb.ca> From: ventham@quantic.mb.ca (Mike Ventham) Received: by quantic.mb.ca (4.1/SMI-4.1) id AA28175; Mon, 12 Dec 94 13:52:34 CST Received: by access.mbnet.mb.ca with UUCP id AA06668 (5.67b/IDA-1.4.4 for ibis@vhdl.org); Mon, 12 Dec 1994 13:52:57 -0600 Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12329; Mon, 12 Dec 94 12:18:33 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 12 Dec 94 13 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 12 Dec 9 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rHMjJ-000txUC; Mon, 12 Dec 94 18:12 PST From bert@ibmoto.com Wed Dec 14 06:47:17 1994 Return-Path: Received: from styx.ibmoto.com ([129.38.252.14]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05621; Wed, 14 Dec 94 06:47:17 PST Received: from lw.ibmoto.com (lw.ibmoto.com [129.38.13.34]) by styx.ibmoto.com (8.6.9/8.6.9) with ESMTP id IAA02251; Wed, 14 Dec 1994 08:42:41 -0600 Received: (bert@localhost) by lw.ibmoto.com (8.6.9/8.6.9) id IAA15548; Wed, 14 Dec 1994 08:42:41 -0600 Message-Id: <199412141442.IAA15548@lw.ibmoto.com> To: Derrick_Duehren@ccm2.jf.intel.com (Derrick Duehren), ventham@quantic.mb.ca (Mike Ventham) Cc: ibis@vhdl.org Subject: Re: IBIS: Draft Press Release, Pls comment by 12/13/94 Date: Wed, 14 Dec 94 08:42:41 -0600 From: Lynn Warriner A couple of points. First I tried calling Karen Kirkpatrick at Cadence, she no longer works there and the person that pick up her job has no idea what IBIS is. I am back in the throws of providing support of IBIS models for IBM. Hoa Quoc is no long doing this task. I am not sure what models we have placed on the servers, how can I check? Thanks, Lynn Warriner IBM @ the Somerset Design Center 512-795-7234 ------- Forwarded Message Received: from erebus.ibmoto.com (erebus.ibmoto.com [129.38.203.1]) by styx.ibmoto.com (8.6.9/8.6.9) with ESMTP id PAA06135 for ; Mon, 12 Dec 1994 15:23:26 -0600 Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by erebus.ibmoto.com (8.6.9/8.6.9) with SMTP id PAA09470 for ; Mon, 12 Dec 1994 15:23:01 -0600 Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12329; Mon, 12 Dec 94 12:18:33 PST Received: by access.mbnet.mb.ca with UUCP id AA06668 (5.67b/IDA-1.4.4 for ibis@vhdl.org); Mon, 12 Dec 1994 13:52:57 -0600 Received: by quantic.mb.ca (4.1/SMI-4.1) id AA28175; Mon, 12 Dec 94 13:52:34 CST From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9412121952.AA28175@quantic.mb.ca> Subject: Re: IBIS: Draft Press Release, Pls comment by 12/13/94 To: Derrick_Duehren@ccm2.jf.intel.com (Derrick Duehren) Date: Mon, 12 Dec 94 13:52:33 CST Cc: ibis@vhdl.org In-Reply-To: <941212100903_1@ccm.hf.intel.com>; from "Derrick Duehren" at Dec 12, 94 10:09 am X-Mailer: ELM [version 2.3 PL11] Inhabitants of IBIS, Here are my humble comments on the press-release. Comments are in parentheses. Greetings for the appropriate religious/capitalist season. Mike > > > Text item: Text_1 > > > IBISians, > > Below is my rough-cut draft of a 2.1 press release. Please post > comments/suggestions to the reflector by 4:00 pm Tuesday 12/13/94. I will > craft a revision and post it for email acceptance Wednesday. > > Derrick Duehren > ------------------------------------------------------------------------------ > XTG TPV Programs Manager, Intel Corp. | > Phone (503) 696-4299 | "Experience is not what happens to > Fax (503) 696-4904 | you; it's what you do with what > Derrick_Duehren@ccm.jf.intel.com | happens to you." > 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley > Hillsboro, OR 97224 | > ------------------------------------------------------------------------------ > > > > For more information contact: > IBIS Open Forum For Immediate Release > Will Hobbs, (503) 696-4369 > Jon Powell, (805) 988-8250 > > IBIS Press Release > DRAFT 12/5/94 > > Rev 2.1 of IBIS Signal Integrity Model Specification Announced > IBIS Standard that Supports Early, Accurate Models for Signal Integrity > Simulations of High-speed Digital Systems Now Supports More Functions > > HILLSBORO, Ore. _ December 9, 1994 _ A group of Electronic Design Automation > (EDA) and semiconductor companies today announced the ratification and > acceptance of Revison 2.1 of the I/O Buffer Information Specification (IBIS) > standard for integrity models. This improved and refined standard adds support ^ signal > for non-linear ramps, differential I/O, __________________, termination components, > ___________________, and __________________________. ECL characteristics improved package models > > IBIS is a consistent format that semiconductor vendors can use to specify the > analog characteristics of input and output buffers. This essential information > is readily transformed into accurate models by end users and simulation tool > vendors. The resulting behavioral models enable users to perform high-speed, > accurate signal-integrity simulations of their digital system interconnects. > > The IBIS Version 2.1 specification was developed through the cooperative > efforts of simulator vendors and semiconductor companies who together comprise > the IBIS Open Forum (see the attached roster). (Do we want to mention the parser?) > > IBIS Models Available > > Intel, _______, and _______ have posted public models to the vhdl.org database. Intel Intel > > Group Plans to Formalize Standard in Early 1995 > > The IBIS Open Forum believes the specification is sufficiently robust and > comprehensive to be taken to the standards community for formal adoption. (I guess we don't want to say how or who at the moment?) This is planned to take place in the first quarter of 1995. > > For More Information > > For more information about the IBIS Open Forum, send an e-mail request to > ibis-info@vhdl.org or call Karen Kirkpatrick, Cadence Design Systems, (508) > 262-6448. All of the documents and publicly available models are currently > accessible via the public repository of VHDL International's Internet based > machine (vhdl.org, 198.31.14.3). FTP, Gopher, and public dial-in access > methods are all supported. (What no multimedia/WWW/Mosaic access ?) > > IBIS Open Forum > Contact List (Roster) > - -- +======================================================================+ | Mike Ventham - Vice President Engineering, Quantic Laboratories Inc, | | 12th Floor, 191 Lombard Ave, Winnipeg, Manitoba, Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email: ventham@quantic.mb.ca | +======================================================================+ ------- End of Forwarded Message From huq@rockie.nsc.com Wed Dec 14 10:32:17 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07030; Wed, 14 Dec 94 10:32:17 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA26309 for ibis@vhdl.org; Wed, 14 Dec 94 10:27:50 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23107 for ibis@vhdl.org; Wed, 14 Dec 94 10:27:48 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA26080; Wed, 14 Dec 94 10:30:43 PST Date: Wed, 14 Dec 94 10:30:43 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9412141830.AA26080@rockie.nsc.com> To: ibis@vhdl.org Subject: General questions Hello IBISgurus: I have been talking about IBIS to different groups at National and some questions regarding IBIS's capability came up. Can IBIS model an output stage with 'gradual turn-on' feature ? For example, products like LV TTL have gradual turn-on ckts on the output stage so if an Octal were to switch, GND bounce would be reduced. I would like to know if anyone has modeled this using IBIS. The other question is, some product line(ex. GTL) have a feedback path from output to input. Is there any limitations with IBIS modeling this type of structure. My feeling is, 'gradual turn-on' or 'feedback' are very device specific features and IBIS simply sees the I/O structure and all else is a black box within the device. I would be curious if anyone is modeling LV TTL or GTL type of devices. Comments...questions.. Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bob@icx.com Wed Dec 14 12:03:52 1994 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07629; Wed, 14 Dec 94 12:03:52 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 14 Dec 94 11:44 PST Message-Id: Date: Wed, 14 Dec 94 11:44 PST From: bob@icx.com ( Bob Ross) To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: General questions Syed: See Below for some comments. Bob Ross, Interconnectix, Inc. > Hello IBISgurus: > I have been talking about IBIS to different groups at National and > some questions regarding IBIS's capability came up. > Can IBIS model an output stage with 'gradual turn-on' feature ? > For example, products like LV TTL have gradual turn-on ckts on the > output stage so if an Octal were to switch, GND bounce would be reduced. > I would like to know if anyone has modeled this using IBIS. YES, THE [RISING WAVEFORM] AND [FALLING WAVEFORM] KEYWORDS IN VERSION 2.1 HANDLE GRADUAL TURN-ON. > The other question is, some product line(ex. GTL) have a feedback path > from output to input. Is there any limitations with IBIS modeling this > type of structure. THE IBIS ARCHITECTURE DOES NOT HANDLE FEEDBACK FROM OUTPUT TO INPUT. THIS WAS DISCUSSED LAST YEAR AT THE IBIS SUMMIT AND MAY AGAIN BE A TOPIC TO DISCUSS FOR POSSIBLE INCLUSION IN IBIS VERSION 3.0 > My feeling is, 'gradual turn-on' or 'feedback' are very device specific > features and IBIS simply sees the I/O structure and all else is a black > box within the device. > I would be curious if anyone is modeling LV TTL or GTL type of devices. > Comments...questions.. > Regards, > Syed. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Syed B. Huq > Applications Engineer/Data Transmission Products > National Semiconductor > Tel:(408)721-4874; Fax:(408)721-4785 > Internet:huq@rockie.nsc.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From uunet!qdt.com!jonp@uunet.uu.net Wed Dec 14 14:21:13 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08612; Wed, 14 Dec 94 14:21:13 PST Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQxuhl27522; Wed, 14 Dec 1994 17:16:24 -0500 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 14 Dec 1994 17:16:27 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01112; Wed, 14 Dec 94 13:45:44 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA13938; Wed, 14 Dec 94 13:47:11 PST Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQxuhj21929; Wed, 14 Dec 1994 16:45:29 -0500 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Wed, 14 Dec 1994 16:45:36 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01042; Wed, 14 Dec 94 12:55:46 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA13839; Wed, 14 Dec 94 12:57:12 PST Date: Wed, 14 Dec 94 12:57:12 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9412142057.AA13839@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA08085; Wed, 14 Dec 94 12:56:50 PST To: uunet!uunet!rockie.nsc.com!huq@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Syed Huq's message of Wed, 14 Dec 94 10:30:43 PST <9412141830.AA26080@rockie.nsc.com> Subject: General questions Syed, I believe that the waveform mechanism can handle many forms of the "gradual turn on" and the "feed back" drivers. In fact, I believe that is what INTEL wanted to use these waveforms for in the first place (so called Rise Time Controlled drivers). The feed back issue is harder since it depends on the speed of the feedback mechanism and that speed is NOT defined (as yet) in the IBIS format. jonp From Will_Hobbs@ccm2.jf.intel.com Wed Dec 14 18:02:59 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10624; Wed, 14 Dec 94 18:02:59 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rI5SU-000UfsC; Wed, 14 Dec 94 17:58 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rI5SU-000txcC; Wed, 14 Dec 94 17:58 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 14 Dec 94 17:58:18 PST Date: Wed, 14 Dec 94 17:58:18 PST From: Will Hobbs Message-Id: <941214175818_1@ccm.jf.intel.com> To: jonp%qdt.com%uunet@uunet.uu.net Cc: ibis@vhdl.org Subject: Re: General questions Text item: Syed, I can't reply in any more detail than what Jon has already stated, or I'd have to shoot the reflector. But Jon is right on. It was due to controlled rise time concerns that we introduced this feature into 2.0, and have found it to work quite well, though developing an underlying model that consumes the data is a challenge, as the EDA vendors reading this no doubt know. Will Syed, I believe that the waveform mechanism can handle many forms of the "gradual turn on" and the "feed back" drivers. In fact, I believe that is what INTEL wanted to use these waveforms for in the first place (so called Rise Time Controlled drivers). The feed back issue is harder since it depends on the speed of the feedback mechanism and that speed is NOT defined (as yet) in the IBIS format. jonp Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: General questions In-Reply-To: Syed Huq's message of Wed, 14 Dec 94 10:30:43 PST <9412141830.AA260 Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net To: uunet!uunet!rockie.nsc.com!huq@uunet.uu.net Received: by f14.qdt.com (4.1/SMI-4.1) id AA08085; Wed, 14 Dec 94 12:56:50 PST Message-Id: <9412142057.AA13839@hal.qdt.com> From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Wed, 14 Dec 94 12:57:12 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA13839; Wed, 14 Dec 94 12:57:12 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01042; Wed, 14 Dec 94 12:55:46 PST Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Wed, 14 Dec 1994 16:45:36 -0500 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQxuhj21929; Wed, 14 Dec 1994 16:45:29 -0500 Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA13938; Wed, 14 Dec 94 13:47:11 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01112; Wed, 14 Dec 94 13:45:44 PST Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 14 Dec 1994 17:16:27 -0500 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQxuhl27522; Wed, 14 Dec 1994 17:16:24 -0500 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08612; Wed, 14 Dec 94 14:21:13 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 14 Dec 94 14 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 14 Dec 9 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rI2Yy-000txmC; Wed, 14 Dec 94 14:52 PST From lfs@Synopsys.COM Fri Dec 23 19:27:33 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29515; Fri, 23 Dec 94 19:27:33 PST Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA13505 (5.65c/IDA-1.4.4); Fri, 23 Dec 1994 19:19:45 -0800 Received: from clotho.synopsys.com (clotho.synopsys.com [146.225.64.24]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id TAA22316; Fri, 23 Dec 1994 19:19:44 -0800 Received: from tahiti-pc.synopsys.com (tahiti-pc.synopsys.com [146.225.82.18]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id TAA05150; Fri, 23 Dec 1994 19:19:41 -0800 Date: Fri, 23 Dec 1994 19:19:41 -0800 Message-Id: <199412240319.TAA05150@clotho.synopsys.com> X-Sender: lfs@po1 (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: huangchi@idtinc.com, westbrook@mms.com, blakkan@mms.com, marnow@mms.com, ting@atb.teradyne.com, concha@el.wpafb.af.mil, craig@idtinc.com, harryw@nchip.com, rjg570@email.sps.mot.com, dietech@vhdl.org, ede@Synopsys.COM, kevinh@Synopsys.COM, jayh@Synopsys.COM, stank@compass-da.com, randy.harr@vhdl.org, 544-6089@mcimail.com, omf@cfi.org, vital@vhdl.org, ibis@vhdl.org, billd@vhdl.com, steve_sherwood@mentorg.com, ross_nelson@mentorg.com, frank_binnendyk@mentorg.com, dan_milliron@mentorg.com, archie_lachner@mentorg.com, greg_seltzer@mentorg.com, sherman@netcad.enet.dec.com, biro@ecadsr.enet.dec.com, bandali@lsil.com, ritag@doc.com, wdb@vhdl.com, cpk@cadence.com, filano@vhdl.lmc.com, graham@cfi.org, Will_Hobbs@ccm2.jf.intel.com, subbu@india.ti.com, mano@india.ti.com, vijay@india.ti.com, geoff@cadence.com, gilman@wash.inmet.com, gurup@ichips.intel.com, hnosrat@scdt.intel.com, marc@ichips.intel.com, pkukkal@ichips.intel.com, sankar@ichips.intel.com, wickart@ichips.intel.com, xwang@ichips.intel.com, vmartin@dtc.hp.com, eeteam@pdesds2.scra.org, julianm@lmc.com, christop@vnet.ibm.com, dave@icx.com, peter@icx.com, wasco@icx.com, bob@icx.com, mick@hpfcla.fc.hp.com, marc.laurent@matramhs.fr, apte@omnivw.com, kahn@cs.man.ac.uk, mick@neptune.fc.hp.com, rstrong@lmc.com, Lauro_Rizzatti@pdxml1.mentorg.com, ajay@icx.com From: lfs@Synopsys.COM (Larry Saunders) Subject: New! DIET FORMAT version 0.95 Cc: billl@Synopsys.COM, plippe@Synopsys.COM X-Mailer: A new and better version of the DIET Format is now available. The new version solves several problems with the 0.9 version and adds several new features. Please take a look at it. Comments are always appreciated. Larry Saunders This document and related information are available from the VHDL International Internet Services machine. Public access and download of files can occur in many ways: Dial-Up access: Dial-up the VHDL.org system at (415) 335-0110. Any baud (up to 14,400), parity, start & stop bits, and v.* settings will do. Login using the "guest" account. Once in, simple UNIX commands such as "cd pub/die", "ls" and "cat" are available. You can download any desired files using "kermit", "xmodem" or "sz" (zmodem). Internet access: Use "ftp VHDL.org" or "telnet VHDL.org" (or "ftp 198.31.14.3") and login as user "anonymous". Use your email address as the password. Remember to set "binary" mode for any binary files you may select. Also, gopher, WWW or Mosaic are available and highly recommended if you have it available. Use "gopher.vhdl.org" or "http://vhdl.org Email access: There is an email FTP archive server on the machine. Send an email message to archive@VHDL.org. The subject is ignored. If a line in the body of the message begins with "help", then a descriptive help file of commands is sent. Basically, you communicate to the server through commands in the mail message body. It then responds to your commands via email. You should always add the command "path " to any message to assure the return address is understood. The following example assumes you have initiated a mail message to archive@VHDL.org. The body of the email message should be:. path lfs@synopsys.com Email address to send results to index pub/diet/latest For a listing of files in this directory send pub/diet/latest/diet0-95.ps For a postscript file of the DIET document send pub/diet/latest/diet0-95.rtf For a RTF file of the DIET document send pub/diet/latest/example.tim For a text file containing format examples send pub/diet/latest/diet0-95.exe For the MS-DOS ZIP'ed version of the entire package send pub/diet/latest/diet0-95.tar.Z For the UNIX tar'ed and compressed version of the entire package Larry Saunders lfs@synopsys.com or lfs@mcimail.com or lfs@seva.com 415-694-1837 408-263-0790 510-249-9085 415-694-4009 (fax) 408-263-0790 (fax) 510-249-9082 (fax) Synopsys, LMG Bldg B SEVA Technologies 700 East Middlefield Rd 1775 Milmont Dr, #C106 200 Brown Rd, #103 Mountain View, CA 94043 Milpitas, CA 95035 Fremont, CA 94539 From bward@Starbase.NeoSoft.COM Wed Dec 28 09:17:45 1994 Return-Path: Received: from Starbase.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23938; Wed, 28 Dec 94 09:17:45 PST Received: (from bward@localhost) by Starbase.NeoSoft.COM (8.6.9/8.6.9) id LAA17106 for ibis@vhdl.org; Wed, 28 Dec 1994 11:13:10 -0600 Date: Wed, 28 Dec 1994 11:13:10 -0600 From: Bob Ward Message-Id: <199412281713.LAA17106@Starbase.NeoSoft.COM> X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 To: ibis@vhdl.org Subject: Meeting locations Hi, fellow ibis watchers! Will mentioned in his note that he also thought Dallas was still in the running for a summit site, and so it is. In fact it might be easier to schedule an appropriate conference room there than here ( Houston ). So if there is interest, let me know, I'll see what I can schedule. The only down side is the possibility of ice storms that time of year, but that is about as imponderable as earthquakes in California. Bob bward@neosoft.com