From cpk@Cadence.COM Wed Jun 1 11:32:49 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12762; Wed, 1 Jun 94 11:32:49 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id LAA29946 for ; Wed, 1 Jun 1994 11:30:10 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma029770; Wed Jun 1 11:29:11 1994 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA20597; Wed, 1 Jun 94 11:10:04 -0700 Received: by hot (5.65+/1.5) id AA01719; Wed, 1 Jun 94 14:28:59 -0400 Date: Wed, 1 Jun 94 14:28:59 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9406011828.AA01719@hot> To: ibis@vhdl.org Subject: Re: DAC meeting location Cc: las@Cadence.COM, sandeep@Cadence.COM Here is the much awaited announcement. Announcement: DAC Summit Meeting Location ___________________________________________ Date: Thursday, June 9, 1994 Time: 8:00 AM to 5:00 PM Location: Room 19, Mezzanine Level, San Diego Convention Center Misc: Continental Breakfast and coffee breaks will be provided. Lunch is the responsibility of the attendees. Contact: For logistics related information only contact Laurel Stanley at Cadence (las@cadence.com) - Kumar From bward@sugar.NeoSoft.COM Wed Jun 1 12:35:26 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13407; Wed, 1 Jun 94 12:35:26 PDT Received: by sugar.NeoSoft.COM id AA00437 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Wed, 1 Jun 1994 14:32:06 -0500 Message-Id: <199406011932.AA00437@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: A question whose answer runs to ancient times ( I'm sure! ) Date: Wed, 1 Jun 94 14:32:05 CDT Fellow ornithologists - Let me try this again. I am not at all sure if the last attempt to send this sent anything. I hope not since I was not done composing it yet. Aren't networks wonderful? While collecting a number of thoughts ibis, it ocurred to me to wonder what the intention of the file name keyword was. It seems to be one of those benign redundancies that so often happen in the design of a scheme like this, but yet I have the haunting thought that I am missing something, and that it was meant to solve some particular problem. But as I try to figure out just what that problem could be, I realize that it has probably escaped my divination. Anyone care to offer the missing insight to make the purpose clear to me? Thanx, Bob bward@neosoft.com From bward@sugar.NeoSoft.COM Wed Jun 1 12:39:46 1994 Return-Path: Received: from sugar.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13439; Wed, 1 Jun 94 12:39:46 PDT Received: by sugar.NeoSoft.COM id AA00578 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Wed, 1 Jun 1994 14:36:26 -0500 Message-Id: <199406011936.AA00578@sugar.NeoSoft.COM> From: bward@sugar.NeoSoft.Com (Bob Ward) X-Mailer: SCO System V Mail (version 3.2) To: ibis@vhdl.org Subject: BOF at DAC Date: Wed, 1 Jun 94 14:36:24 CDT Just that one last minute reminder that anyone, even those who signed on with me earlier to attend the Birds of a Feather session, should sign up for it at the information desk when registering for DAC. We do need at least ten people to sign up there in order to be quaranteed a room. My previous information that I could pass the names on to the powers that be was in error, we must each sign up separately. Hope to see a dozen or more there! And encourage anyone else to attend as well, but be sure they sign up also. Thanx, Bob bward@neosoft.com From ventham@quantic.mb.ca Wed Jun 1 14:30:15 1994 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14498; Wed, 1 Jun 94 14:30:15 PDT Received: by access.mbnet.mb.ca with UUCP id AA17471 (5.65c/IDA-1.4.4 for ibis@vhdl.org); Wed, 1 Jun 1994 16:28:47 -0500 Received: by quantic.mb.ca (4.1/SMI-4.1) id AA21580; Wed, 1 Jun 94 16:19:40 CDT From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9406012119.AA21580@quantic.mb.ca> Subject: Re: A question whose answer runs to ancient times ( I'm sure! ) To: bward@sugar.NeoSoft.Com (Bob Ward) Date: Wed, 1 Jun 94 16:19:40 CDT Cc: ibis@vhdl.org In-Reply-To: <199406011932.AA00437@sugar.NeoSoft.COM>; from "Bob Ward" at Jun 1, 94 2:32 pm X-Mailer: ELM [version 2.3 PL11] Bob, The reason for it was so that when ibis files are emailed to parts known or areas unknown, the receiver can know what to name it when saved out of the email system into the 'real' world. E.G [Filename] put_in_ibis.bin I hope this clears up an ancient mystery. Mike -- +=============================================================================+ | Mike Ventham Vice President Engineering | | Quantic Laboratories Inc, 1200-191 Lombard Ave, Winnipeg MB Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email ventham@quantic.mb.ca | +=============================================================================+ From speters@ichips.intel.com Wed Jun 1 15:51:01 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14983; Wed, 1 Jun 94 15:51:01 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 1 Jun 94 15:48:19 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 1 Jun 94 15:47:44 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 1 Jun 94 15:48:08 PDT Message-Id: <9406012248.AA04383@xtg801.intel.com> To: ibis@vhdl.org Subject: Draft IBIS 2.0 specification Date: Wed, 01 Jun 1994 15:48:07 -0700 From: Stephen Peters Hello Fellow IBISans -- Following is the Draft IBIS 2.x2 Specification, incorporating comments and rewrites from the 5/27 teleconference. This draft will be discussed and voted on at the IBIS Open Forum Summit, June 9th, at the Design Automation Conference. Best Regards, Derrick Duehren Stephen Peters Intel Corp. Key to right-most column revision marks: ## = Editor Comments (will be removed from the final spec.) $ = Change from Version 1.1 * = Additional changes made at/after 5/27 meeting - ----------------------------------- Cut Here ---------------------------------- |============================================================================== *| I/O Buffer Information Specification (IBIS) Version 2.x2 [DRAFT 6/1/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. A complete list of changes to the specification $| is in the IBIS Version 2.0 Release Notes document ("ver2_0.rn"). $| |============================================================================== | $| 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. | |============================================================================== | 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.0 | 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_0.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: The [Date] information is allowed to contain blanks, and be of $| any format up to 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] 06/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] Component Name | e.g., 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] Manufacturer's Name | e.g., 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 an $| .ibs file, their scope is "local"--they are known only within $| that .ibs file and no other. In addition, within that .ibs $| file, they override any globally defined package models $| that have the same name. *| $|------------------------------------------------------------------------------ *[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. "NC" $| is used for entries which are not needed or which follow $| the conditions below: $| $| If a pin has no connection, then both the "pulldown_ref" $| and "pullup_ref" entries for it will be NC. $| $| GND and POWER pin entries and buses are designated by $| entries in either the "pulldown_ref" or "pullup_ref" columns. $| There is no implied association to any column other than $| through explicit designations in other pins. $| $| For any other type of pin, the "pulldown_ref" column contains $| the power connection for the [Pulldown] table for non-ECL type $| [Models]. This is also the power connection for the [GND Clamp] $| table and the [Rgnd] model unless 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. $| $| 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 used 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 [Diff Pin] column $| contains a non-inverting pin number and the inv_pin column $| always contains the corresponding inverting pin number for $| I/O output. The vdiff column 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 tdelay columns $| contain launch delays of the non-inverting pins relative to $| the inverting pins. The values can be 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 $| ## In following my instructions to turn the usage rules of the [Model] keyword ## into a table showing which sub-parameters are optional or not, I restructured ## the entire usage rules section. - Derrick Duehren |============================================================================== | 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. | An .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except for | those model names 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. *| ## Output, 3-state, and Output_ECL are not defined in the table below. They ## should be added. - Derrick Duehren ## *| 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. *| *| Model types have the following usage rules: *| *| 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=.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 pullup *| resistors. $| *| Open_sink These model type indicate that the output has *| Open_drain 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, Output_ECL, and I/O_ECL model types specify that the *| model represents an ECL type logic that follows 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 as 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 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 = NA |Timing specification test load resistance value $Vref = NA |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: [Temperature Range] also describes the temperature range over $| which the various V/I curves and ramp rates were derived. $|------------------------------------------------------------------------------ $| variable typ min max $[Temperature Range] 27.0C -50C 130.0C | |============================================================================== | 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 pullup 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 $| pullup 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 pulldown V/I data. If this keyword is not $| present, the voltage data points in the pulldown V/I table $| are referenced to 0V. $|Usage Rules: 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 pullup, $| pulldown, 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 pulldown and pullup structures of an output buffer and the | V/I curves of the clamping diodes connected to the GND and the $| POWER pins, respectively. 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 pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND Clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output, if so | desired. | $| When tabulating data for ECL devices, the data in the pulldown $| table is measured with the output in the 'logic low' state. $| In other words, the data in the table represents the V-I $| characteristics of the output when the output is at the most $| negative of its two logic levels. Likewise, the data in the $| pullup table is measured with the output in the 'logic one' $| state and represents the V-I characteristics when the output $| is at the most positive logic level. Note that in BOTH 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. $| $| Note that the above conditions allow the data to be $| non-monotonic in one axis. $| $| It is assumed that the simulator sums the clamp curves $| together with the appropriate pullup or pulldown curve when a $| buffer is driving high or low, respectively. From this $| assumption and the nature of 3-statable buffers, it follows $| that the data in the clamping curve sections are handled as $| constantly present curves and the pullup and pulldown curves $| are used only when needed in the simulation. $| $| The clamp curves of an input or I/O buffer can be measured $| directly with a curve tracer, 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 pullup and $| pulldown curves of an IBIS model must represent the difference $| of the $3-stated and the enabled buffer's curves. (Note that $| the resulting difference curve 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 pullup and $| pulldown 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] | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | $|============================================================================== $| 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 co-exist with [GND Clamp] $| and [POWER Clamp] structures. If an AC terminator is $| specified, then both [Rac] and [Cac] are required. When $| [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the $| Model_type must be Terminator. $| $| |<-------------TERMINATOR Model--------------->| $| *| [Voltage Range] or *| [POWER Clamp Reference] $| o $| | $| POWER_ |---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---| / | $| | | | | *| C_comp === o === Cac C_pkg === *| | GND or | | *| | [GND Clamp Ref] | | $| | | | $| |-------------------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: These parameters describe an ideal slope and can be expressed $| as a ratio of any reasonable voltage and time values as shown $| in the examples. The [Ramp] values can to use "NA" for the $| min and max values only. The R_load sub-parameter is optional $| if the preferred 50 ohm load is used. It is required if a non- $| standard load is used. $|------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 4.2/1.8n 3.5/2.5n 5.0/1.1n dV/dt_f 2.5/1.5n 2.0/2.3n 3.0/0.8n $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, C_fixture, L_fixture, $| R_dut, L_dut, C_dut *| Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword $| introduces a table of time vs. voltage points that $| describe the shape of an output waveform. These $| time/voltage points are taken under the conditions $| specified in the R/L/C/V_fixture and R/L/C_dut $| sub-parameters. The table itself consists of $| one column of time points, then three columns of $| voltage points in the standard typ, min, and max format. $| The four entries must be placed on a single line and $| must be separated by at least one white space or tab $| character. All four columns are required. However, data $| is only required in the typical column. If minimum $| or maximum data is not available, 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. $| $| 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. $|------------------------------------------------------------------------------ *[Rising Waveform] $R_fixture = 500 $V_fixture = 5.0 $C_fixture = 50p $L_fixture = 2n $C_dut = 7p $R_dut = 1m $L_dut = 1n $|Time V(typ) V(min) V(max) $ 0.0ns 0.3 0.5 NA $ 0.5ns 0.3 0.5 NA $ 1.0ns 0.6 0.7 NA $ 1.5ns 0.9 0.9 NA $ 2.0ns 1.5 1.3 NA $ 2.5ns 2.1 1.7 NA $ 3.0ns 3.0 2.7 NA $ 3.5ns 3.2 3.0 NA $| *[Falling Waveform] $R_fixture = 50 $V_fixture = 0 $|Time V(typ) V(min) V(max) $ 10.0ns 3.2 3.0 NA $ 10.5ns 3.0 2.7 NA $ 11.0ns 2.1 1.7 NA $ 11.5ns 1.5 1.3 NA $ 12.0ns 0.9 0.9 NA $ 12.5ns 0.6 0.7 NA $ 13.0ns 0.3 0.5 NA $ 13.5ns 0.3 0.5 NA | |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | ## I reorganized the PACKAGE MODELING section for clarity and cleaner ## organization/flow. I did not tackle rewriting the conversational tone. ## I also moved it here, the first section after the end of the base ## specification. - Derrick Duehren $|============================================================================= $| *| PACKAGE MODELING *| *| 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 may *| also 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 *| [Manufacturer] Required* *| [OEM] Required* *| [Description] Required* *| [Number of Pins] Required* *| [Pin Names] Required* *| [Model Data] Required* *| [Resistance Matrix] Optional *| [Inductance Matrix] Required* *| [Capacitance Matrix] Required* *| [Bandwidth] Required (for Banded_matrix matrices only) *| [Row] Required* *| [End Model Data] Required* *| [End Package Model] 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, e.g., Texas $| Instruments). In addition, each manufacturer must use a $| consistent name in all .ibs files. $| Other Notes: This keyword is useful if the semiconductor vendor sells a *| single IC in packages from different manufacturers. $|------------------------------------------------------------------------------ *[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 integer less than 60 characters $| long. $|------------------------------------------------------------------------------ $[Number of Pins] 128 $| $|============================================================================== $| Keyword: [Pin Names] $| Required: Yes $| Description: Tells the parser the set of names that are used for the package $| pins, and to defines an ordering of them. The first pin name $| given is the "lowest" pin, and the last pin given is the $| "highest." The pin names can not exceed 5 characters in $| length. *| Usage Rules: Following the [Pin Names] 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 Names] $A1 $A2 $| . $| . $| . $A22 $B1 $| . $| . $| . $| etc. $| $|============================================================================== $| Keyword: [Model Data] $| Required: Yes *| Description: Indicates the beginning of the formatted 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] $| ## I did a substantial rewrite of this matrices section to make it fit the style ## of the rest of the spec. - Derrick Duehren *|============================================================================== *| 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 0--------| Pkg |---------0 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 Names] 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". $| *| 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 Names] 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.) $| $| *| 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: Indicate the beginning of a new row of the matrix. $| Usage Rules: The Row_Number field must be a pin name. $|------------------------------------------------------------------------------ $[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 charachters 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. *| $|============================================================================== *| 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 Names] $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] $[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 | | 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.3 V power supply should be characterized between | (0 - 3.3) = -3.3 V and (3.3 + 3.3) = 6.6 V for the pulldown curve. $| $| When tabulating output data for ECL type devices, the voltage points $| must span the range of Vcc to Vcc - 2.2V. This range applies to both the $| pullup and pulldown tables. Note that this range applies ONLY when $| characterizing an ECL output. $| $| These voltage ranges must be spanned by the IBIS data. Data derived $| from lab measurements may not be able to span these ranges as such and $| so may need to be extrapolated to cover the full range. This data must $| not be left for the simulator to provide. | | 3) Ramp Rates: $| The following steps assume that the default load resistance of 50 ohms is $| used. There may be devices that will not drive a load of only 50 ohms $| into any useful level of dynamics. In these cases, use the manufacturer's $| suggested (non-reactive) load and add the load sub parameter to the [Ramp] $| specification. $| $| The ramp rate does not include package and parameters; it is the intrinsic $| output stage rise and fall time only. $| $| The ramp rates (listed in AC characteristics below) should be derived $| as follows: $| $| a. If starting with the silicon model, remove all packaging. If starting $| with a packaged device, perform the measurements as outlined below then $| use whatever techniques are appropriate to derive the actual, unloaded $| rise and fall times. $| $| b. If: The Model_type is one of the following: Output, I/O, or $| 3-state (not open or ECL types); $| Then: Attach a 50 ohm resistor to GND to derive the rising edge $| ramp. Attach a 50 ohm resistor to POWER to derive the $| falling edge ramp. $| $| If: The Model_type is Output_ECL or I/O_ECL; $| Then: Attach a 50 ohm resistor to the termination voltage $| (Vterm = VCC - 2V). Use this load to derive both the $| rising and falling edges. $| $| If: The Model_type is either an Open_sink type or Open_drain type; $| Then: Attach either a 50 ohm resistor or the vendor-suggested $| termination resistance to either POWER or the vendor- $| suggested termination voltage. Use this load to derive both $| the rising and falling edges. $| $| If: The Model_type is an Open_source type; $| Then: Attach either a 50 ohm resistor or the vendor-suggested $| termination resistance to either GND or the vendor-suggested $| termination voltage. Use this load to derive both the rising $| and falling edges. $| $| c. Due to the resistor, output swings will not make a full transition as $| expected. However the pertinent data can still be collected as $| follows: $| 1) determine the 20% to 80% voltages of the 50 Ohm swing $| 2) measure this voltage change as "dV" $| 3) measure the amount of time required to make this swing "dt" $| d. Post the value as a ratio "dV/dt". The simulation tool vendor $| extrapolates this value to span the required voltage swing range in $| the final model. $| $| e. Typ, Min, and Max must all be posted, and are derived at the same $| extremes as the V/I curves, which are: $| $| Ramp rates for CMOS devices: *| typ = 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%" $| $| Ramp rates 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%" $| $| where nominal, min, and max temp are specified by the manufacturer of $| the part. The preferred range is 50C nom, 0C min, and 100C max $| temperatures. $| $| Note that the derate factor, "Y%", may be different than that used $| for the V/I curve data. This factor is similar to the X% factor $| described above. As in the case of V/I curves, temperatures are $| junction temperatures. $| $| f. During the IV measurements, the driving waveform should have a $| rise/fall time fast enough to avoid thermal feedback. The specific $| choice of sweep time is left to the modeling engineer. $| | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. | - -----------------------------------cut here ----------------------------------- |============================================================================== NOTES ON IBIS_CHK PROGRAM (not to be left in the actual specification) $The V/I table DATA SHOULD BE MONOTONIC to insure that most simulators provide $stable simulations. Monotonic data is needed to insure that all data is $single valued. MONOTONIC DATA IS NOT REQUIRED to provide a valid IBIS model. $It is recognized that automated measurement equipment may be used to acquire $this data and as such may include "noise" that causes the data to be non- $monotonic. It is also recognized that some devices may be non-monotonic in $certain regions. Therefore the IBIS specification allows non-monotonic data. $Simulation tools should filter out non-monotonic data if such data causes $instabilities in the simulation results. The IBIS_CHK program tests for non- $monotonic data and provides a maximum of one note per V/I table if non- $montonic data is found. $ $ "NOTE: Line xxx of V/I table yyy for model zzz is non-monotonic! $ Most simulators will filter this data to remove the non-monotonic data." $ $ Where xxx is the line number in the IBIS file. $ Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp. $ Where zzz is the name of the model. $ $*************************************************************************** $Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors. $*************************************************************************** $For each of the following V/I tables: Pullup, Pulldown, POWER_clamp, $GND_clamp $ $ 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. $ $ 2) IF:The current in the TYPICAL column corresponding to Vmax is less than $ the current in the TYPICAL column corresponding to Vmin than $ the table is assumed to have decreasing current. $ ELSE IF:The current in the TYPICAL column corresponding to Vmax $ is greater than the current in the TYPICAL column corresponding to $ Vmin than the table is assumed to have increasing current. $ ELSE: The table is assumed to have equal current." $ $ Note: This works for all cases of discontinuities unless the magnitude of $ discontinuity is such that this model is in all probability $ completely unrealistic. $ $*************************************************************************** $Change 3- Add a header comment statement at the TOP of the IBIS_CHK program $ to insure that new changes to the IBIS_CHK program do not break tests $ that worked in old MAJOR versions. This approach makes the program $ larger however it insures the parser always works the same on older $ versions of IBIS. This approach uses more memory, but has the reward $ of low maintaining costs. The IBIS_CHK program is very small and $ would not be effected by this until many revisions have occurred. $*************************************************************************** $NOTICE TO ANY PERSON MODIFING THIS PROGRAM! $------------------------------------------- $This program SHALL NOT BE MODIFIED unless there is an associated IBIS Buffer $Issue Resolution Document (BIRD). Said BIRD shall be agreed upon by IBIS $committee vote. Only the currently elected IBIS_CHK 'czar and programmer' is $allowed to modify the source code. The present CZAR is Jon Powell (April $1994). The IBIS committee may also hire programmers from time to time to make $major changes to the source code. $ $Note: Source licensees are free to modify their own copies of this source $code in any way they choose. Source licensees shall not redistribute $the source code modified or otherwise. Source licensing is available from the $IBIS open forum. The IBIS open forum is non-profit. $ $The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED $when adding code for the next version of the IBIS specification. Instead $completely new code for all functions and features shall be created. This $may require duplication of numerous functions. $ $Each function shall be preceded by VXX_ where XX is the MAJOR version $of the IBIS specification which is being parsed and tested. A MAJOR version $would for example be 1.x going to 2.x. A MINOR version would for example be $1.1 to 1.2. Functions using the above syntax would look as follows: $V01_GetValue $ $MINOR revisions DO NOT required new code. $ $Startup code shall be provided at the top of the program that reads the $version number from the IBIS file and runs the portion of the program $corresponding to that MAJOR version. Code that is used only by the program $startup function is not duplicated. $ ------- End of Forwarded Message From Derrick_Duehren@ccm2.jf.intel.com Wed Jun 1 16:57:46 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15385; Wed, 1 Jun 94 16:57:46 PDT Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q9076-000MPZC; Wed, 1 Jun 94 16:54 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 1 Jun 94 16:54:24 PST Date: Wed, 1 Jun 94 16:54:24 PST From: Derrick Duehren Message-Id: <940601165424_1@ccm.hf.intel.com> To: IBIS@vhdl.org Cc: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com Subject: IBIS 5/27 Meeting Minutes Text item: Text_1 Date: June 1, 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 5/27/94 To: Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, Chris Reed, Kumar* Contec Maah Sango, Clark Cochran Digital Equipment Corp. Barry Katz High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli IBM Jay Diepenbrock IBM-Motorola alliance Lynn Warriner, Hoa Quoc, John Burnett Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Don Telian, Will Hobbs Arpad Muranyi, Derrick Duehren*, John Keifer*, Robin Rosenbaum* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Mei Wong, Mei-Ling Wei NEC Hiroshi Matsumoto MicroSim Arthur Wong, Jerry Brown, Graham Bell National Semiconductor Syed Huq* North Carolina State U. Paul Franzon, Michael Steer, Steve Lipa Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad Design Jon Powell Quantic Labs Mike Ventham*, Zhen Mu Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier* Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl 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 # 6/09/94 Face-to-face meeting at DAC 6/24/94 TBD All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17: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 and give the bridge operator the reservation number. 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ 5/27/94 Meeting Agenda ---------------------- Check-in Intros of new IBIS participants Duehren Review of previous meeting's minutes Duehren Miscellany/Announcements Duehren Opens for new issues All New models available All IBIS Cookbook Rosenbaum IBIS 2.0 Ratification/DAC/Other 2.0 Issues Duehren - May 20 Editing meeting - Report - Rev 2.0 Ratification Summit Rev 2.0 Review/Discussion/Approval of pending sections All BIRD 14/16, New section for [Model] sub-parameters Keifer BIRD 15, Clarification on usage of the V/I tables Arpad Wrap-up, Next Meeting Plans Duehren 1. Intros of new IBIS participants New participant: None. 2. Review of Pervious Meeting's Minutes There were no corrections made to last month's minutes. 3. Miscellany/Announcements IBIS is mentioned prominently in "Signal Integrity Analysis in ASIC Design" By Tai-Yu Chou in the May 94 issue of System Design. 4. Opens for new issues Golden Parser changes need a formal change process (Parser Change Order). Not discussed. 5. New models available None. 6. IBIS Cookbook Robin Rosenbaum reported that she has some comments rolled in, others have raised technical questions. Stephen has made some updates per Rev2.0. Send email to RobinR@ichips.intel.com to get a copy. Specify Word2.0/Word6.0/ASCII format. We still need examples in it. Kumar will look at it and possibly provide examples. 7. IBIS 2.0 Ratification/DAC - May 20 Editing meeting - Brief report given (see separate minutes) - Rev 2.0 Ratification Summit AR Kumar: Publish meeting location/directions to the reflector. [DONE] Time: 8:00 AM to 5:00 PM Location: Room 19, Mezzanine Level, San Diego Convention Center Misc: Continental Breakfast and coffee breaks will be provided. Lunch is the responsibility of the attendees. Contact: For logistics related information only contact Laurel Stanley at Cadence (las@cadence.com) AR Will: Get cost estimates from Paul before DAC and create the agenda 6/9/94 Summit Agenda Suggestions: Levels of support? What's needed for version 3? Turn IBIS over to standards body? Legal basis of IBIS/Tax ID? IBIS into Pinnacles/SGML (Randy Harr)? Timing information within IBIS? Future of IBIS? Chairmanship? Update of Parser Funding Issues 8. Rev 2.0 Review/Discussion/Approval of pending sections We addressed all Rev 2.0 draft open issues brought up: o Bob Ward: Correction to temp range (typ min max): "NA" is valid for min and max only. o Bob Ross: Eliminate the word "usual" from the spec. o Bob Ross: Eliminate parameters, sub-parameters from General Syntax Rule #1. o Bob Ross: [Component Name] argument can have blank characters. Add recommendation to not use them. o Bob Ward: [End Model Data] keyword is overloaded. Add an [End Package Model] keyword. AR Eric B: Post a note documenting the changes to the package model section of Rev2.0. [DONE] o Move all the various IBIS_CHK program notes to the end, after a "cut" line. o Under the [Model] keyword, make a table specifying which sub-params are required/optional. o Make the wording on power supply specs consistent. o And many more... (See rev2.0x.txt file being posted by Stephen Peters.) AR Stephen: Call Kellee regarding BIRD 8.2 wording. 9. BIRD 14/16, New section for [Model] sub-parameters Bob W. feels it is a nice feature, but Bob does not want this BIRD included in the spec. yet. Until reduction of model size becomes a real issue, he feels this BIRD adds complexity we don't need -- no compelling need now. Kumar agrees. This lead into a discussion of the need to discuss pin-centric vs. model-centric IBIS philosophies. Consensus was that it is a good idea, but we will table this BIRD until there is a real need and possibly add it in Rev 3.0. 10. BIRD 15, Clarification on usage of the V/I tables Consensus to let BIRD 15 stay as is in Rev2.0 draft. 11. Wrap-up, Next Meeting Plans Next meeting is 6/9/94, 8:00 am, at the DAC conference in San Diego. AR Kumar: Post IBIS meeting location details to the reflector Loire Supposki (Kumar). [DONE] The next meeting after DAC is 6/24/94. From speters@ichips.intel.com Wed Jun 1 17:46:06 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15719; Wed, 1 Jun 94 17:46:06 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 1 Jun 94 17:43:26 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 1 Jun 94 17:42:54 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 1 Jun 94 17:43:21 PDT Message-Id: <9406020043.AA04931@xtg801.intel.com> To: ibis@vhdl.org Subject: Change Notes for Draft IBIS 2.0 Specification Date: Wed, 01 Jun 1994 17:43:20 -0700 From: Stephen Peters Hello Fellow IBISans -- Here are the updated change notes. Best Regards, Stephen Peters Intel Corp. IBIS Version 2.0 Change Notes Following is a list of the changes from IBIS version 1.1 to version 2.0. The global changes to the specifications are listed first, then the specific added keywords and changes to existing keywords. The changes are listed in the order they appear in the specification. Only changes related to functionality or meaning are listed; minor changes to spelling, grammar, and syntax are not included. Changes to the IBIS_CHK program (the parser) are captured in a seperate document. Global changes to specification: 1. Underscores and spaces are now equivalent in keywords. For example, the version 1.1 keyword [GND_clamp] can now be typed as [GND clamp] and the parser will accept it. The intent is that all new keywords added to the specification NOT use an underscore character. In addition, it is now explicitly required that sub-parameter names NOT contain spaces. 2. Three new scaling factors have been added: T=tera, G=giga and f=femto 3. The characters "+" and "-" have been added to the list of forbidden comment characters. Specific changes: 4. The keyword [Copyright] has been added. The Usage Rules were updated to state that design automation tools should make the information available, derivative models should include the text in the [Notes], [Source] and [Disclaimer] keywords verbatim, and any text following the [Copyright] keyword must be included verbatim. 5. A note was added to the [Component] keyword description stating that blank characters in component names are not recommended. 6. The other notes section of [Package] keyword was updated to include references to the [Package Model] keyword. The specification now requires that data in the [Package] keyword always be valid even if the [Package Model] keyword is used. 7. The [Package Model] keyword was added per Bird 10.1 with the following added requirement: If the package model is in a separate .pkg file then it must be kept in the same directory as the .ibs file. 8. The [Pin Mapping] keyword was added per Bird 5.4. 9. The [Diff Pin] keyword was added per Bird 6.2. 10. To the [Model] keyword was added the sub-parameters Cref, Vmeas, Rref and Vref per Bird 14.3 The additional model types and explanations per Bird 7.2 were added as well as the terminator model type of Bird 9.2. Bird 2.2 (requiring Vinl and Vinh specification for inputs) was incorporated. 11. The [Temperature range] keyword was added per Bird 13. 12. The [Pullup Reference], [Pulldown Reference], [GND Clamp Reference], and [POWER Clamp Reference] keywords were added per Bird 3. 13. The following changes were made in the "Other Notes:" section of the V/I curve waveform table keywords. A) All references to 'Vcc' were clarified to mean the voltage rail referenced by the [Pullup reference] or [POWER Clamp Reference] keyword. B) Notes on how to tabulate data for ECL type devices were added per Bird 4. B) Bird 8.2 was incorporated by defining monotonic data and stating that non-monotonic data is allowed. C) Bird 15 was incorporated by explicitly stating the assumptions regarding summing of clamp and pullup/pulldown VI curves. The specification also now explicitly allows non-tristatable devices, if needed, to include power and ground clamp data in in the [Pullup] or [Pulldown] table. 14. The [Rgnd], [Rpwer], [Rac] and [Cac] keywords were added per Bird 9.2 along with the terminator Model_type. 15. The [Ramp] keyword now includes the R_load sub-parameter per Bird 13 16. The [Rising Waveform] and [Falling Waveform] keywords were included per Bird 12. 17. Bird 10.3 was incorporated into the specification by creating the PACKAGE MODELING section. 18. The min, typ and max temperature conditions were updated per Bird 13 19. The required voltage range over which an ECL output is characterized is specified per Bird 4. 20. Note on extrapolating full VI table ranges even if using measured data was added per Bird 13. 21. The method used to derive ramp time was updated per Bird 13 and Bird 7.2 ------- changes by BIRD PREVIOUSLY APPROVED BIRDS ADDED TO SPECIFICATION: BIRD SUBJECT ---- ------- 2.2 Requiring VIH VIL thresholds for input devices 3.0 Multiple Power Supplies and References 4.0 ECL Extensions 5.4 Pin Mapping for Ground Bounce Simulation 6.2 Differential Pin Specification 7.2 Open Specification Completion 8.2 Specification of V/I data Monotonicity 9.2 Terminator Specification 10.2 Describing coupling effects in package models 12.1 Non-linear driver waveforms BIRDS APPROVED AT THE EDITING COMMITTEE MEETING: BIRD SUBJECT ---- ------- 13.3 Clarify some conditions of measurements 15.0 Clarification on the usage of V/I tables 14.3 Adding timing measurement parameters From wei@metasw.com Thu Jun 2 17:10:03 1994 Return-Path: Received: from metasw.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28961; Thu, 2 Jun 94 17:10:03 PDT Received: from poseidon.meta ([192.0.3.15]) by metasw.com (4.1/SMI-4.1) id AA13224; Thu, 2 Jun 94 17:07:12 PDT Date: Thu, 2 Jun 94 17:07:12 PDT From: wei@metasw.com (You Pang Wei) Message-Id: <9406030007.AA13224@metasw.com> To: ibis@vhdl.org Subject: IBIS mail list Please add me on your mail list. Thanks ! From bob@icx.com Mon Jun 13 08:59:55 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27102; Mon, 13 Jun 94 08:59:55 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA01276 for ; Mon, 13 Jun 94 11:46:46 -0400 Date: Mon, 13 Jun 94 08:40:43 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03944; Mon, 13 Jun 94 08:40:43 PDT Message-Id: <9406131540.AA03944@icx.com> To: ibis@vhdl.org Subject: THANKS! Thank you Bob Ward and Kumar for hosting some very productive sessions at DAC and to Will Hobbs for the great T-shirts and for guiding us to the successful adoption of IBIS Version 2.0. Its great to be with all of the fine people involved with IBIS. Bob Ross, Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Mon Jun 13 11:22:29 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27972; Mon, 13 Jun 94 11:22:29 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 13 Jun 94 11:19:29 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Mon, 13 Jun 94 11:18:28 -0700 Received: from ccMail by jfsmt2.intel.com id AA771531538 Mon, 13 Jun 94 11:18:58 PDT Date: Mon, 13 Jun 94 11:18:58 PDT From: "Hobbs, Will" Message-Id: <9405137715.AA771531538@jfsmt2.intel.com> To: ibis@vhdl.org, bob@icx.com ( Bob Ross) Cc: Art_Spurrell@ccm2.jf.intel.com Subject: Re: THANKS! While we're passing out thank you's, I'd like to thank Bob Ross, Derrick Duehren and Stephen Peters for their work above and beyond the call of duty in the editing of the V2.0, and of course everyone else involved with creating BIRDs, editing, debating and passing 2.0. It has been an interesting and fulfilling project. Will Hobbs Subject: THANKS! Thank you Bob Ward and Kumar for hosting some very productive sessions at DAC and to Will Hobbs for the great T-shirts and for guiding us to the successful adoption of IBIS Version 2.0. Its great to be with all of the fine people involved with IBIS. Bob Ross, Interconnectix, Inc. From bob@icx.com Mon Jun 13 16:30:07 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29721; Mon, 13 Jun 94 16:30:07 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA16642 for ; Mon, 13 Jun 94 19:05:43 -0400 Date: Mon, 13 Jun 94 16:00:18 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA06407; Mon, 13 Jun 94 16:00:18 PDT Message-Id: <9406132300.AA06407@icx.com> To: mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu Subject: S2IBIS PROJECT Cc: blooms@icx.com, ibis@vhdl.org Steve Lipa, Michael Steer, Paul Franzon I enjoyed meeting you at DAC, Paul. As we discussed, we have hired for this summer Scott Bloom, a graduate student at Oregon State University, to work primarily on expanding the S2IBIS utility for Version 1.1 and for the recently ratified Version 2.0. I would like very much if Scott can work with Steve on this project. Scott's address is blooms@icx.com. Currently Scott is in a familarization phase and is bringing up our version of Berkeley Spice and will be reviewing the S2IBIS work to date. It would be very helpful, Steve, if we could get a copy of the source(s) code developed to date or very shortly if there is some minor cleanup to be done. I expect Scott (and I) to remain in very close colaboration with you on this project. Our objective is to help create public domain S2IBIS utilities to help encourage the semiconductor vendors to produce IBIS models for their components. Consistent with your charter, we expect all of our work to be public domain and posted in the ibis repository. Michael, for you information, Steffen Rochel at Anacad (sr@anacad.de) was very interested in continuing the work in producing a formal grammar (BNF) for IBIS, and I passed on some incomplete work that I had done and also mentioned that he might contact you regarding the work you have done in this area. Bob Ross, Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Mon Jun 13 16:59:42 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29901; Mon, 13 Jun 94 16:59:42 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 13 Jun 94 16:56:50 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Mon, 13 Jun 94 16:55:59 -0700 Received: from ccMail by jfsmt2.intel.com id AA771551803 Mon, 13 Jun 94 16:56:43 PDT Date: Mon, 13 Jun 94 16:56:43 PDT From: "Hobbs, Will" Message-Id: <9405137715.AA771551803@jfsmt2.intel.com> To: ibis@vhdl.org Subject: IBIS V2.0 has been ratified Greetings, For anyone on the reflector that is not aware of this, the IBIS Open Forum met at DAC in San Diego, CA, on 6/9/94 and ratified version 2.0 of the IBIS specification. Final text will be posted to the reflector in a few days. We will be contracting Paul Munsey, the software engineer who wrote the original version of ibis_chk, the IBIS Golden Parser, to update or rewrite the parser for V2.0. With history as our guide, we expect some minor changes to be required to the spec as a result of his efforts. No substantive changes will occur. We will consider his input, and if necessary approve an update, V2.1, very quickly thereafter. Expect this before the end of summer. Many thanks to all the talented and energetic people who put time and effort into getting us to this point. IBIS V2.0 is a significant achievement. We believe V2.0 makes IBIS a very powerful addition to the computer industry's tool set. Best regards, Will Hobbs Intel Corporation From Derrick_Duehren@ccm2.jf.intel.com Thu Jun 16 10:21:14 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03802; Thu, 16 Jun 94 10:21:14 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qEKaN-000MTMC; Thu, 16 Jun 94 09:46 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qEKas-000twcC; Thu, 16 Jun 94 09:47 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 16 Jun 94 09:47:10 PST Date: Thu, 16 Jun 94 09:47:10 PST From: Derrick Duehren Message-Id: <940616094710_5@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: EDN IBIS article accepted! Text item: Text_1 EDN mag. has accepted the IBIS overview article I submitted a few months ago for publishing sometime this year. It is based on the IBIS Overview document. Finally, we'll have a feature story on IBIS in a major publication. - Derrick Duehren From Derrick_Duehren@ccm2.jf.intel.com Thu Jun 16 10:29:01 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03818; Thu, 16 Jun 94 10:29:01 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qEKbH-000MTvC; Thu, 16 Jun 94 09:47 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qEKbm-000twdC; Thu, 16 Jun 94 09:48 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 16 Jun 94 09:48:06 PST Date: Thu, 16 Jun 94 09:48:06 PST From: Derrick Duehren Message-Id: <940616094806_5@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: EDN IBIS article accepted! Text item: Text_1 EDN mag. has accepted the IBIS overview article I submitted a few months ago for publishing sometime this year. It is based on the IBIS Overview document. Finally, we'll have a feature story on IBIS in a major publication. - Derrick Duehren From Derrick_Duehren@ccm2.jf.intel.com Fri Jun 17 21:42:28 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21837; Fri, 17 Jun 94 21:42:28 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qEsAm-000MPpC; Fri, 17 Jun 94 21:38 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qEsBI-000twcC; Fri, 17 Jun 94 21:39 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 17 Jun 94 21:39:00 PST Date: Fri, 17 Jun 94 21:39:00 PST From: Derrick Duehren Message-Id: <940617213900_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Updated Intel IBIS Models Text item: Text_1 The following Intel IBIS files had a minor error corrected. The error was a sign error at a voltage point which does not change the simulation results but might cause non-monotonic errors in simulators. The updated files are listed below. They have been posted to the vhdl.org \models\intel directory. Part/File vhdl.org alpha rev. rev. IBIS name Directory name date level ver. Notes ------------------------------------------------------------------------------ 82425ex.ibs chipset PSC 06-17-94 R0.92 V1.1 Aries chipset 82426ex.ibs chipset IB 06-17-94 R0.92 V1.1 Aries chipset 82374sb.ibs chipset ESC 06-17-94 R0.92 V1.1 PCI-EISA Bridge 82375sb.ibs chipset PCEB 06-17-94 R0.92 V1.1 PCI-EISA Bridge 82378zb.ibs chipset SIOZ 06-17-94 R0.92 V1.1 PCI-ISA Bridge 82433nx.ibs chipset LBX 06-17-94 R0.93 V1.1 Neptune chipset 82434nx.ibs chipset PCMC 06-17-94 R0.93 V1.1 Neptune chipset - Derrick Duehren Intel Corp. From Derrick_Duehren@ccm2.jf.intel.com Fri Jun 17 22:37:24 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22228; Fri, 17 Jun 94 22:37:24 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qEt20-000MPVC; Fri, 17 Jun 94 22:33 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qEt2W-000twcC; Fri, 17 Jun 94 22:34 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 17 Jun 94 22:34:00 PST Date: Fri, 17 Jun 94 22:34:00 PST From: Derrick Duehren Message-Id: <940617223400_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Non-public IBIS files listed on vhdl.org Text item: Text_1 At the Birds of a Feather session at DAC, we recognized that private (nonpublic) IBIS models exist. We agreed that to increase exposure for these models, vendors wanting to sell their IBIS models can post announcement-type ads on vhdl.org. Send your text file to Derrick_Duehren@ccm.jf.intel.com. I will create a subdirectory for your company in the \models directory and post your file. For example, a company (such as Zeelan Tech.) might post a listing of IBIS models for sale, with appropriate contact information. - Derrick Duehren Intel From Derrick_Duehren@ccm2.jf.intel.com Mon Jun 20 14:30:00 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19298; Mon, 20 Jun 94 14:30:00 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qFqqe-000MPzC; Mon, 20 Jun 94 14:25 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qFqrC-000twcC; Mon, 20 Jun 94 14:26 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 20 Jun 94 14:26:18 PST Date: Mon, 20 Jun 94 14:26:18 PST From: Derrick Duehren Message-Id: <940620142618_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 6/24/94 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 6/24/94 Bridge: Res: (916) 356-9999 328519 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17: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 of new IBIS participants Hobbs Review of previous meeting's minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues All Press updates Hobbs/All Progress toward enlisting new IC vendors All New models available All Golden Parser, 2.1 plans Hobbs 8:40 IBIS 2.0 ratification/DAC residual issues? All IBIS Cookbook Peters Levels of support All Spice-to-IBIS Converter Lipa (NCSU) Pending BIRDs (BIRD 16?) Hobbs ** NOTE: Previously tabled until after 2.0 ratification: Formal BNF notation (BIRD?) Reed, Harr High freq. and EMI Goyal, et. al. Phased turn-on/off of multiple devices Powell 9:55 Wrap-up, Next Meeting Plans Hobbs Back to every third week? From Derrick_Duehren@ccm2.jf.intel.com Mon Jun 20 14:45:49 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19426; Mon, 20 Jun 94 14:45:49 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qFr69-000MQNC; Mon, 20 Jun 94 14:41 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qFr6i-000twcC; Mon, 20 Jun 94 14:42 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 20 Jun 94 14:42:19 PST Date: Mon, 20 Jun 94 14:42:19 PST From: Derrick Duehren Message-Id: <940620144219_1@ccm.hf.intel.com> To: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com, IBIS@vhdl.org Subject: IBIS 6/9/94 Meeting and BOF Minutes Text item: Text_1 Date: June 20, 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 Ratification Meeting 6/9/94 To: Anacad Steffen Rochel* Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna*, C. Kumar* Cadlab Ralf Bruning* Contec Maah Sango Digital Equipment Corp. Barry Katz* 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 Integrated Silicon Systems Eric Bracken* Integrity Engineering Greg Doyle Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren*, John Keifer, Robin Rosenbaum Interconnectix, Inc. Bob Ross*, Rick Maiero* 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 OptEM Engineering, Inc. Benny Leveille*, Ken Ehn* Quad Design Jon Powell* Quantic Labs Mike Ventham Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier, Torsten Maeser* Symmetry Martin Walker* Synopsys, Logic Modeling G. Randy Harr* 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 # 6/24/94 (916) 356-9999 328519 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17: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. 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ 6/9/94 Summit Proposed Meeting Agenda ------------------------------------- Opening Remarks Agenda Review Review Voting Process Short Intro/Overview Discussion of Rev 2.0 Ratification Levels of Support Lunch Golden Parser Discussion Future Open Forum , Affiliation, Standards, and Funding/Membership Increasing Participation Discussion/Getting Vendors to Provide Models IBIS Cookbook Future Technical Direction (Rev 3.0) Timing Information within IBIS IBIS into Pinnacles/SGML (Randy Harr) Press Release Opens 1. Opening Remarks Will Hobbs presented opening remarks, including a brief overview of IBIS and the forum. Will announced that Paul Munsey has reviewed the proposed 2.0 spec. He found "a couple of minor things" per a voice-mail message. Eric Bracken of Performance Signal Integrity announced that PSI had been bought by Integrated Silicon Systems. 2. Agenda Review Increasing Participation Discussion/Getting Vendors to Provide Models IBIS Cookbook Press Release Syed: Should technical questions be posted to the reflector? Yes. 3. Review Voting Process Agreed on previously agreed process (reference meeting minutes...) 4. Short Intro/Overview Discussion of Rev 2.0 5. Rev 2.0 Ratification The Rev 2_0.X2 draft spec. that was published to the IBIS reflector on or about June 1, 1994 was unanimously ratified with changes noted. The approved and updated Rev 2.0 spec. has been posted to the /ibis directory of vhdl.org as VER2_0.TXT. Stephen Peter's change notes are in the same directory (VER2_0RN.TXT). No changes other than syntactical changes required by the Golden Parser and possibly levels-of-support changes will be made for Rev 2.1. One key clarification occurred in the ramp rate spec. Several people had interpreted the ramp rate, which is of the form [3.2V]/[2.1nS], as a reducible fraction, defining only a slope. In fact, the number represents three pieces of information: the slope, the voltage spanning the middle 60% (80% - 20%) of the difference between the steady state DC high and low output voltage levels, and the time it takes to traverse that particular 60% of the range. 6. Levels of Support Levels of support were discussed at length, with the idea that 2.0 had enough new functionality that it might be too much for new EDA vendors to take on, acting as a deterrent to them supporting IBIS at all. We found this to be an issue with strongly held opinions both ways, so we chose to table the discussion for the IBIS reflector and future phone conferences. 7. Golden Parser Discussion The forum agreed that the IBIS spec. is no longer assumed to be parsable. We are contracting the original "Golden Parser" engineer, Paul Munsey, to write a new golden parser for 2.0, and fully expect some minor changes to the spec. to occur during this process. Our goal is for this work to be completed by some time in August, at which time we will issue a new press release and the EDA vendors will release new simulators with 2.0 functionality. Jon Powell presented the following list of suggested coding-standard changes to the Golden Parser. These changes will make the parser easier to use and port. 1. struct IBIS*IBIS_CHK(inf) file *inf; 2. structure to be dynamically allocated. 3. All data except comments are to be retained in structure. 4. main code to be built around IBIS_CHK call. 5. structure to be freeable. 6. main.c \ + | not meant to imply actual names other.c / Intent: .C file structure designed to be placed into other programs 7. ANSI C standards 8. Jon Powell to supply Vec_test model. 9. No globals 10. IBIS_Free() to be defined 11. DOS flag for case insensitive argument read 12. Numbers to be "double" and count all units --> 9ns --> 9e-9 as in the IBIS spec. Paul Munsey to take this input and the text at the end of the Rev 2_0.X2 draft. [Sent to Paul 6/20/94] Check for voltage range, issue a warning if it does not meet the spec. 8. Future Open Forum Structure, Affiliation, Standards, and Funding/Membership We discussed the future form of the IBIS Open Forum organization, and agreed to continue this discussion in coming meetings, with the standards organization information factored in. Randy Harr discussed the pros and cons of IEEE and EIA (Electronic Industry Association) groups. The committee decided to pursue EIA affiliation as a first choice. AR Randy H: Try to get EIA (Electronic Industry Association) rep to participate in upcoming meeting. The idea on the table is to seek affiliation after Rev 2.1. 9. Increasing Participation/Getting Vendors to Provide Models We discussed ways to increase participation and model availability for IBIS. TI indicated they were on the verge of officially embracing IBIS, and National Semiconductor said they were just waiting on 2.0. AR Kellee: Contact Xilinx to see if they will publish models created by HyperLynx Five keys to increased model availability and participation were identified: A. Publish the cookbook as it is now Syed H: It is difficult to create models from measurement. Is there any cookbook information? Arpad offered some suggestions. The Cookbook is underway, and will be released soon. Syed Huq of NSC indicated he would add his experiences to the cookbook later this summer, so this will likely be a gradually improving how-to guide. AR Stephen/Arpad, add Arpad's measurement tips to the cookbook. B. Publish press releases We decided to wait for 2.1 for our press release. C. Publish IBIS articles Several magazine article ideas were discussed, and Derrick will pursue getting the overview article he adapted from our IBIS Overview document published, and Bob Ward of TI indicated he would write a technical article on IBIS. AR Derrick: Complete the overview article and get it published. Add Spice-to-IBIS conversion utility and a 2.0 discussion/compatibility. UPDATE: EDN has accepted the article for publication sometime this year. AR Jon : See if a note can be posted to vhdl.org saying something to the effect of "PPC IBIS models are available under non-disclosure agreement". D. Affiliate with a standards organization We discussed standards organization affiliation. Randy Harr of LMG gave us an overview of EIA, EIA-J, IEEE and other standards bodies, and basically said that IEEE is expensive to join, proceeds very slowly, and that EIA and IEEE offer basically the same standards legitimacy world-wide. Randy agreed to invite someone from EIA to our next Open Forum meeting to discuss their organization with us. E. Spice-to-IBIS translation program tested and in use Steve Lipa of North Carolina State University is still working on the Spice to IBIS converter. He was at the Birds of a Feather session, and gave us a progress update-- not done, but making good headway. F. Possibly sponsor one-day IBIS-creation training seminar. G. Publish IBIS notices on vhdl.org that advertise the existence of IBIS models from vendors, including non-public models. 10. IBIS Cookbook Previously discussed. 11. Future Technical Direction (Rev 3.0) A checksum keyword is needed in the next rev to help identify any alterations to an "official" IBIS file. 12. Timing information within IBIS 13. IBIS into Pinnacles/SGML (Randy Harr) Randy told of his experiences turning the DIE spec. into SGML format. It was wholly rejected by the die-spec. committee. Bottom-line, it does not provide sufficient advantages. See pub/die/workshop3 on vhdl.org. 14. Opens Randy Harr described work being done by the die-spec. committee. Data-sheet level data is level zero (optional). See pub/die/workshop4 directory on vhdl.org. ======================================================================== Notes from IBIS Birds of a Feather DAC Session 6/8/94: Attendees: Aspect Development Kenneth Belanger Cadence Design C. Kumar Digital Equipment Corp. Barry Katz HyperLynx Kellee Crisafulli Intel Corporation Stephen Peters, Will Hobbs Arpad Muranyi, Derrick Duehren, Interconnectix, Inc. Bob Ross, Rick Maiero Intergraph Walter Katz, Rob Kelley Integrated Silicon Systems Eric Bracken Meta-Software Bill Guthrei, Les Spruiell National Semiconductor Syed Huq Nikkei Electronics Bus Pub. Ikutaro Kojima North Carolina State U. Paul Fraazer Synopsys, Logic Modeling G. Randy Harr Texas Instruments Bob Ward Vantage Analysis Systems Francoise Martinolle Zeelan Technology Hiro Moriyasu ------------------------------------------------------------------------ Will Hobbs began the meeting with a historical and technical overview of IBIS. The open discussion focused on model availability and possible affiliation with a standards organization. A number of ideas were offered to increase the profile and "legitimacy" of IBIS, which were again discussed at the Thursday session. Ideas logged: o We need to contact the DAC program committee and propose a Signal Integrity/IBIS tutorial at next year's DAC o A tutorial-type article in ASIC and EDA magazine is needed. Bob Ward volunteered to work on this article. o Randy Harr shared the levels of support used by the Die Information Exchange standard: Level 0 = Data book info. Level 1 = Includes sim test and IBIS Ver 1.1 data Level 2 = Includes very specific data such as lot-specific data o Private (non-public) IBIS models exist. We agreed that to increase exposure for these models, vendors wanting to sell their IBIS models can post announcement-type ads on vhdl.org. Send your text file to Derrick_Duehren@ccm.jf.intel.com. Derrick will create a subdirectory for your company in the /models directory and post your file. For example, a company (such as Zeelan Tech.) might post a listing of IBIS models for sale, with appropriate contact information. From mbs@eos.ncsu.edu Tue Jun 21 05:28:12 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 AA27999; Tue, 21 Jun 94 05:28:12 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA11433; Tue, 21 Jun 1994 08:25:07 -0400 From: mbs@eos.ncsu.edu Message-Id: <9406211225.AA11433@mbs.ece.ncsu.edu> To: ibis@vhdl.org Date: Tue, 21 Jun 94 08:25:06 EDT (In response to Bob Ross's mail.) Bob and others, Thanks for your note. I expect Steve Lipa to get back to you shortly with the updated S2IBIS source. We expect it to be copylefted (in the same style as gnu software). I understand that this is required if it is to remain completely free and not to be copyrighted by some other party in the future. It may be an idea to draft a standard IBIS copyleft license and so avoid a plethora of licenses. If I receive a favorable response I will post the gnu standard license with any changes that may be required. Also, I will be posting the source for the yacc and lex (actually gnu's byacc and flex and hence no copyright problems) code for parsing IBIS files before July. I will add as much of version 2.1 as I can in the short period. Michael Steer From Will_Hobbs@ccm2.jf.intel.com Thu Jun 23 10:21:57 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23854; Thu, 23 Jun 94 10:21:57 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 23 Jun 94 10:18:51 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Thu, 23 Jun 94 10:18:09 -0700 Received: from ccMail by jfsmt2.intel.com id AA772391929 Thu, 23 Jun 94 10:18:49 PDT Date: Thu, 23 Jun 94 10:18:49 PDT From: "Hobbs, Will" Message-Id: <9405237723.AA772391929@jfsmt2.intel.com> To: ibis@vhdl.org, randyh@Synopsys.COM, 73053.721@compuserve.com Subject: Urgent!! New IBIS Bridge Number The IBIS bridge number for tomorrow has been changed to accomodate more than 12 callers. Sorry for the late notice. The number has been changed from: Bridge 356-9999 Res. 328519 The number has been changed to: Bridge (415) 904-8800 Res. 788626 There is no way for Teleconferencing to let the people know that the number has been changed if they give the old Res. number. However, if the caller knows that the bridge has been changed to an outside vendor Telecon. can give them the new number. Also, the agenda will be modified to accommodate two guests: at 8:15, a representative of EIA will call in to give us a brief overview of that standards organization, and at ~8:30, Paul Munsey will call in to discuss the golden parser update requirements, schedule, etc. Will From huq@rockie.nsc.com Thu Jun 23 10:36:24 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23936; Thu, 23 Jun 94 10:36:24 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA12887 for ibis@vhdl.org; Thu, 23 Jun 94 10:33:31 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA05327 for ibis@vhdl.org; Thu, 23 Jun 94 10:33:31 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA11161; Thu, 23 Jun 94 10:34:26 PDT Date: Thu, 23 Jun 94 10:34:26 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9406231734.AA11161@rockie.nsc.com> To: ibis@vhdl.org Subject: Bench Measurements questions ... Cc: huq@rockie.nsc.com Hi, I need some clarification on some bench measurements. Let me know if I am correct on the following assumptions. First of all, is it safe to assume that if the device is non-tri statable, then no need to take [GND Clamp], [POWER Clamp] data as these will be included in the [Pulldown] and [Pullup]. So, I specify the voltage value on the 'Voltage' table but put NA on the 'I(typ)' column for both the Clamp measurements. For the [Pulldown], since it's referenced to GND, it's straight forward sweep of Vout from -5V to +10V. Measure the resulting 'I(typ)'. No need to do any modifications to the V/I table. Does that sound right? For the [Pullup], since it's referenced to Vcc, I need to use the formula Vtable = Vcc - Vout. So, I again sweep Vout from -5V to +10 volts. Recalculate the Vtable numbers based on "Vtable = Vcc - Vout". Leave the 'I(typ)' sign( plus to minus) as they are. I am making my measurements not on a curve tracer but using a programmbale power supply and a software on a GPIB Mac that can Force a voltage range and record the 'I(typ)' reading. Regards, Syed huq From speters@ichips.intel.com Thu Jun 23 11:41:42 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24325; Thu, 23 Jun 94 11:41:42 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 23 Jun 94 11:37:07 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 23 Jun 94 11:36:03 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 23 Jun 94 11:36:41 PDT Message-Id: <9406231836.AA14230@xtg801.intel.com> To: huq@rockie.nsc.com Cc: ibis@vhdl.org Subject: Bench Measurements questions ... Date: Thu, 23 Jun 1994 11:36:39 -0700 From: Stephen Peters Hello Syed: In regards to your first question below, there are two ways to handle a device with non tri-stateable outputs. 1. Do not include the [GND clamp] and [POWER clamp] keywords or 2. Include them but the "I" points should all be zero. ^&^^ It is NOT allowed to make the typical column all "NA"s. For the [Pullup] and [Pulldown] keywords your assumtions are correct. Lastly, be sure that the supply is turned on and off very quickly so that you don't get heating effects due to power dissapation. Regards, Stephen Peters Intel Corp. Hi, I need some clarification on some bench measurements. Let me know if I am correct on the following assumptions. First of all, is it safe to assume that if the device is non-tri statable, then no need to take [GND Clamp], [POWER Clamp] data as these will be included in the [Pulldown] and [Pullup]. So, I specify the voltage value on the 'Voltage' table but put NA on the 'I(typ)' column for both the Clamp measurements. For the [Pulldown], since it's referenced to GND, it's straight forward sweep of Vout from -5V to +10V. Measure the resulting 'I(typ)'. No need to do any modifications to the V/I table. Does that sound right? For the [Pullup], since it's referenced to Vcc, I need to use the formula Vtable = Vcc - Vout. So, I again sweep Vout from -5V to +10 volts. Recalculate the Vtable numbers based on "Vtable = Vcc - Vout". Leave the 'I(typ)' sign( plus to minus) as they are. I am making my measurements not on a curve tracer but using a programmbale power supply and a software on a GPIB Mac that can Force a voltage range and record the 'I(typ)' reading. Regards, Syed huq From Derrick_Duehren@ccm2.jf.intel.com Thu Jun 23 13:40:25 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25120; Thu, 23 Jun 94 13:40:25 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qGvVI-000MQFC; Thu, 23 Jun 94 13:36 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qGvVt-000twcC; Thu, 23 Jun 94 13:36 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 23 Jun 94 13:36:45 PST Date: Thu, 23 Jun 94 13:36:45 PST From: Derrick Duehren Message-Id: <940623133645_5@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: New IBIS Bridge Number for 6/24/94 Text item: Text_1 The IBIS Open Forum meeting bridge number for 6/24/94 has been changed. Old Number: Bridge (916) 356-9999 Res. 328519 New Number: Bridge (415) 904-8800 Res. 788626 Please make a note of it. Sorry for the confusion. - Derrick Duehren From blooms@icx.com Mon Jun 27 10:10:50 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02855; Mon, 27 Jun 94 10:10:50 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA09159 for ; Mon, 27 Jun 94 12:48:08 -0400 Date: Mon, 27 Jun 94 09:39:35 PDT From: blooms@icx.com ( Scott Aron Bloom) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA10429; Mon, 27 Jun 94 09:39:35 PDT Message-Id: <9406271639.AA10429@icx.com> To: ibis@vhdl.org Subject: Question on the Sweep range After reading all the ibis specs that are available to me, I can not find this answer anywhere. For the voltage ranges, version 1.1 and 2.0 specs state: 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 Now the question I have is this. When you are sweeping on the non-typical voltage, what is the range. Meaning, if you have a 5 volt power supply, with a minimum voltage of 4.5 volts. Does you sweep for the pullup now go from -4.5 volts to 9 volts? or from -5 to 5 as before? Thanks in advance, Scott Aron Bloom InterConnectiX, Inc. From Arpad_Muranyi@ccm.fm.intel.com Mon Jun 27 10:49:37 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03114; Mon, 27 Jun 94 10:49:37 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qIKjt-000MqOC; Mon, 27 Jun 94 10:45 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qIKkv-000twdC; Mon, 27 Jun 94 10:46 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 27 Jun 94 10:46:05 PST Date: Mon, 27 Jun 94 10:46:05 PST From: Arpad Muranyi Message-Id: <940627104605_1@ccm.hf.intel.com> To: ibis@vhdl.org, blooms@icx.com Subject: Re: Question on the Sweep range Scott, Since there is only one voltage column for the three cases of current columns in the IBIS models, in my mind this rule references the typical voltage range. Therefore my models all have a -5V to +10V range regardless whether the columns are typ., min., or max. This is actually not a very important issue anyway. The lab measurements can not go that far in most cases. The main reason we added this rule was to make sure that all simulators cover the widest possible range correctly, because they do not all extrapolate the same way beyond the last data point. For example, if your last data point is at -1V, one tool might continue with the last slope, another might continue horizontally, and another vertically. If you had a -2V undershoot, you would see very different results. Arpad Muranyi Intel Corporation After reading all the ibis specs that are available to me, I can not find this answer anywhere. For the voltage ranges, version 1.1 and 2.0 specs state: 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 Now the question I have is this. When you are sweeping on the non-typical voltage, what is the range. Meaning, if you have a 5 volt power supply, with a minimum voltage of 4.5 volts. Does you sweep for the pullup now go from -4.5 volts to 9 volts? or from -5 to 5 as before? Thanks in advance, Scott Aron Bloom InterConnectiX, Inc. From jonp@qdt.com Mon Jun 27 11:18:52 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03260; Mon, 27 Jun 94 11:18:52 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP (rama) id QQwwdd27253; Mon, 27 Jun 1994 14:15:56 -0400 Received: from qdt.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Mon, 27 Jun 1994 14:16:05 -0400 Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00772; Mon, 27 Jun 94 10:53:04 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA12788; Mon, 27 Jun 94 10:53:02 PDT Date: Mon, 27 Jun 94 10:53:02 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9406271753.AA12788@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA09620; Mon, 27 Jun 94 10:53:00 PDT To: ibis@vhdl.org path jonp@qdt.com send pub/ibis/models/intel From Will_Hobbs@ccm2.jf.intel.com Mon Jun 27 11:53:56 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03442; Mon, 27 Jun 94 11:53:56 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 27 Jun 94 11:51:00 -0700 Received: from jfsmt2 by ichips.intel.com (5.64+/10.0i); Mon, 27 Jun 94 11:49:03 -0700 Received: from ccMail by jfsmt2.intel.com id AA772743052 Mon, 27 Jun 94 11:50:52 PDT Date: Mon, 27 Jun 94 11:50:52 PDT From: "Hobbs, Will" Message-Id: <9405277727.AA772743052@jfsmt2.intel.com> To: ibis@vhdl.org, blooms@icx.com ( Scott Aron Bloom) Subject: Re: Question on the Sweep range Scott, The soon-to-be-released IBIS Modeling Cookbook says the following: Note: The IBIS specification calls for the pullup and power clamp diode I-V data to be referenced to VCC. To put the data into a table format properly, adjust the sweep voltage along with VCC. For example, the sweep voltage for a 5V part under typical conditions would range from -5V to +10V. For minimum conditions, where the VCC was adjusted to 4.75V, the sweep voltage would also have to be adjusted -0.25V (i.e., sweep from -5.25v to +9.75v). Likewise, for maximum conditions, adjust the sweep voltage positive along with the VCC. Will Hobbs Intel Corp. After reading all the ibis specs that are available to me, I can not find this answer anywhere. For the voltage ranges, version 1.1 and 2.0 specs state: 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 Now the question I have is this. When you are sweeping on the non-typical voltage, what is the range. Meaning, if you have a 5 volt power supply, with a minimum voltage of 4.5 volts. Does you sweep for the pullup now go from -4.5 volts to 9 volts? or from -5 to 5 as before? Thanks in advance, Scott Aron Bloom InterConnectiX, Inc. From Derrick_Duehren@ccm2.jf.intel.com Tue Jun 28 14:59:01 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15596; Tue, 28 Jun 94 14:59:01 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qIl6O-000MQgC; Tue, 28 Jun 94 14:54 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qIl7R-000twcC; Tue, 28 Jun 94 14:55 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 28 Jun 94 14:55:05 PST Date: Tue, 28 Jun 94 14:55:05 PST From: Derrick Duehren Message-Id: <940628145505_3@ccm.hf.intel.com> To: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com, 73053.721@compuserve.com, IBIS@vhdl.org Subject: IBIS 6/24/94 Meeting Minutes Text item: Text_1 Date: June 28, 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 6/24/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 Maah Sango 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 Integrated Silicon Systems Eric Bracken* Integrity Engineering Greg Doyle Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren*, John Keifer Interconnectix, Inc. Bob Ross, Rick Maiero, Scott Bloom* Intergraph Ian Dodd*, David Wiens* IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal Meta-Software Mei Wong, You-Pang Wei, John Sliney, Les Spruiell* NEC Hiroshi Matsumoto MicroSim Arthur Wong* National Semiconductor Syed Huq* North Carolina State U. Steve Lipa OptEM Engineering, Inc. Benny Leveille, Ken Ehn PC Ware Paul Munsey* Quad Design Jon Powell* Quantic Labs Mike Ventham Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier, Symmetry Martin Walker Synopsys, Logic Modeling G. Randy Harr* 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 # 7/8/94 (916) 356-9999 361301 (GP discussion) 7/15/94 (415) 904-8944 792456 (General Meeting) All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17: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. 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ Meeting Agenda -------------- Check-in Intros of new IBIS participants Hobbs Treasurer's report Hobbs Review of previous meeting's minutes Hobbs Miscellany/Announcements Hobbs Opens for new issues All Golden Parser, 2.1 plans Hobbs EIA Presentation/Discussion Usher Press updates Hobbs/All Progress toward enlisting new IC vendors All New models available All IBIS 2.0 ratification/DAC residual issues? All IBIS Cookbook Peters Levels of support All Spice-to-IBIS Converter Lipa (NCSU) Pending BIRDs (BIRD 16?) Hobbs Previously tabled until after 2.0 ratification: Formal BNF notation (BIRD?) Reed, Harr High freq. and EMI Goyal, et. al. Phased turn-on/off of multiple devices Powell Wrap-up, Next Meeting Plans Hobbs Intros of new IBIS participants Dave Moxley of AT&T Global Info Systems. He is a model user interested in IBIS models of ASICs and other components. Treasurer's report The current balance is $4,191.64. All income is from Golden parser license sales and $10 interest. Review of previous meeting's minutes There were no corrections made to last month's minutes. Miscellany/Announcements None. Opens for new issues None. Golden Parser, 2.1 Paul Munsey estimates that the 2.1 Golden Parser work will be 2x the 1.1 parser effort. Paul plans to work with another programmer. They will each work on it part-time. He expects the work to be 6 weeks full time. He could have a Beta version mid September. Then, another month for testing, and 2 weeks for final S/W, final release in October. Jon Powell wants the parser by the end of August/early Sept. After discussion, we agreed to have Paul write a short proposal with detailed schedule. Paul may consider hiring another programmer to get the work done earlier. We will review the proposal at a special phone conference on 7/8/94. AR Derrick: Send approved 2.0 spec. to Paul. DONE. AR Paul: Write 1 to 2 page proposal and post it to the reflector (ibis@vhdl.org). AR Derrick: Secure a bridge number for the 7/8 review meeting. EIA Presentation/Discussion Patty Usher, director of the EIA Electronic Information Group, presented an overview of the EIA (Electronics Industry Association) organization. EIA is company-based standards organization. Her group is an "ideal niche" for IBIS. We'd be a working group/sub-committee under her group. This would give us the umbrella of a recognized standards organization. There would probably be a committee fee to cover the administration of the balloting, press releases, meetings and such, estimated at $100 per company. We would retain control over sale of the spec. and licensing of the Golden Parser, we would set the costs, depending on how much revenue stream we need to operate. Although the EIA would own the copyright on the spec., we would retain near autonomous control with support service from the EIA, which is funded by the member corporations. The EIA offers two options for ratifying a standard, an "interim standard" with a two-year life (one month limited ballot) and a "proposed standard" with a 60-day public ballot. We would be required to answer all negative ballots, resolve them to the best of our ability, then it would go to ANSI. The process takes at least 100 days. The EIA uses one-company, one-vote balloting. Jon P. expressed concern over the cost of EIA affiliation because of the cost of EDIF. Randy says that EDIF committee set those costs. and that we wouldn't have to set ours nearly as high. If we decide to enroll with EIA, we need to send Patty a letter of intent to get the process started. She will forward it to EIA Legal and then would set us up as a committee. A decision by this body is possible at the next meeting. Press updates A press release is planned for Ver. 2.1. Progress toward enlisting new IC vendors We are executing the 7-part plan discussed at DAC (see 6/9/94 minutes). New models available As was decided at DAC, companies can post notices of model availability even if they are not posting the models themselves. Contact Derrick Duehren for posting details. Randy Harr expressed some concern about control of the vhdl.org directories. Consensus is that control is sufficient for now (write access is limited to Randy and Derrick). Jon P. expressed concern that the models are not policed (verified against the Golden Parser) before posting to vhdl.org. He wants a formal IBIS Librarian position established, possibly rotating among participants. We will add a discussion of an IBIS Librarian with duties and responsibilities, who, etc. to next meeting's agenda. Jon reported that Motorola is reevaluating their decision to release PowerPC IBIS models. No other semi vendors were on-line to report. IBIS 2.0 ratification/DAC residual issues? None. IBIS Cookbook Stephen reported that all comments received to date have been incorporated and Stephen added the ramp rate and ground/power clamp 2.0 issues. Stephen will publish it as a 0.9 draft on vhdl.org in a variety of formats. Stephen was elected to be the Cookbook Czar. AR Stephen: Post the cookbook ASAP. Levels of Support Much discussion brought out several strong opinions on various sides of this issue. Some good suggestions were aired: o Simulator vendors need to communicate to the customers what level of support they provide. o An app note could be written to address what information a user needs to do good simulation, or such things could be in the model itself. Any volunteers? o Dave M. suggested that the GP output a table of 2.0+ (beyond 1.1) keywords and display all the notes and copyright information (on screen). AR Paul M: Add beyond 1.1 keyword display to the requirements list for the 2.0 Golden Parser. Spice-to-IBIS Converter Scott : The interface works well, but it has some problems and only supports Pspice and V1.1, not Berkeley spice. A copyleft statement will be included to keep it non-proprietary. Pending BIRDs (BIRD 16?) Not discussed. Formal BNF notation (BIRD?) Not discussed. High freq. and EMI Not discussed. Phased turn-on/off of multiple devices Not discussed. Wrap-up, Next Meeting Plans A Golden Parser discussion meeting will be held 7/8/94, and the next general open forum meeting is will be held 7/15/94. Bridge numbers will be posted to the reflector.