From kellee@nwlink.com Mon May 1 13:09:15 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05249; Mon, 1 May 95 13:09:15 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id NAA10646; Mon, 1 May 1995 13:02:20 -0700 Date: Mon, 1 May 1995 13:02:20 -0700 Message-Id: <199505012002.NAA10646@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Comment on Egg regarding package support with T lines Hi IBIS all, I had an opportunity to speak with Steven Peters at the WinEDA conference. I now understand what Steven is proposing and find that I like it. The way Steven explained it to me is that there are several layers of packaing information surrounding the die. Each layer can be lumped components (R,L,C) or T-line, or Matrix. Steven will be submitting an updated egg with a couple of changes we talked about. The changes that we discussed are as follows: 1) Provide a mechanism to extend information from one line to the next. 2) To differentiate the 3 types of layers as above: a) Each layer's data is separated by a comma. b) Each layer can have L,R,C or Matrix, not both. c) If a layer has a length than it is a T-line instead of lumped elements. d) The L,R,C have units of length that is the same as the length specifier if the lenght specifier is present. e) The word Matrix is used between the comma's on the pin line to indicate that a matrix is to be used for that layer Steven agreed to re-issue the Egg with these changes. I believe this is very consistant with the method we have been using already and I am therefore very much in favor of the concept. Kellee Crisafulli Have a great day...Kellee Crisafulli, HyperLynx Inc. From Derrick_Duehren@ccm2.jf.intel.com Mon May 1 16:29:46 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11991; Mon, 1 May 95 16:29:46 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s64ot-000UqyC; Mon, 1 May 95 16:24 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s64ot-000twuC; Mon, 1 May 95 16:24 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 1 May 95 16:24:03 PST Date: Mon, 1 May 95 16:24:03 PST From: Derrick Duehren Message-Id: <950501162403_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Open Forum 5/5/95 Meeting Agenda IBIS Open Forum Meeting Agenda for 5/5/95 Bridge: Res: (916) 356-9999 461609 All meetings are 8:00 AM to 10:00 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes (and ARs) - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available EIA Status Hobbs - Membership update Progress toward enlisting new IC vendors All 8:30 Golden Parser 2.1 status Hobbs Plans for IBIS Meeting at DAC (June12-16) Hobbs Rev 2.1 updates Hobbs o S2IBIS 2.1 o Cookbook o Overview 9:00 Diode Transit Times Tim Schreyer BIRD 26 - Tab chars discouraged in .ibs files (revote) Hobbs BIRD 27 - New keyword for differential I/O Ward Enhancements to the timing spec Peters EGG - Transmission line package models Peters SGML/HTML support Huq/Duehren 9:55 Wrap-up, next meeting plans Hobbs From jonp@qdt.com Tue May 2 15:13:15 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29991; Tue, 2 May 95 15:13:15 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyoai28628; Tue, 2 May 1995 16:13:13 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Tue, 2 May 1995 16:13:08 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00817; Tue, 2 May 95 12:30:24 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA06869; Tue, 2 May 95 12:36:27 PDT Date: Tue, 2 May 95 12:36:27 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505021936.AA06869@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA23492; Tue, 2 May 95 12:33:05 PDT To: ibis@vhdl.org Subject: IBIS placards Hello IBIS users, I am in the process of making up standing placards for display at DAC (or any other show) that indicate a companies support of IBIS. It looks like they will cost between $10 and $20 a piece. They will be high quality color prints mounted with easles(sp?). I will bankrole them initially but would like the people who want them to buy them from me. Please let me know how many you would like and I will send them to you in the very near future. I will also provide the computer ready art on floppy to anyone who wants it. regards and talk to you Friday, jon From Derrick_Duehren@ccm2.jf.intel.com Wed May 3 12:10:47 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16816; Wed, 3 May 95 12:10:47 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s6jjL-000UpkC; Wed, 3 May 95 12:05 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s6jjL-000txTC; Wed, 3 May 95 12:05 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 03 May 95 12:05:03 PDT Date: Wed, 03 May 95 12:03:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: Who has IBIS models? IBISians, We know that IBIS models besides those posted to vhdl.org exist (E.g. PowerPC). If you have 'private' IBIS models for sale, or models that require nondisclosure agreements to receive, etc., please submit to me a text file description of what you have to be posted to vhdl.org. Each company can then update their text file whenever they want by sending an update to the IBIS Secretary (or this could become a Librarian task). This is free publicity. I envision something to the effect of: vhdl.org pub/ibis/models/your_company_name/00readme Where 00readme is a text file similar to the following. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Your_company_name IBIS models Your_company_name, the greatest purveyor of zyw chips in the universe, is now offering IBIS I/O models for the following components under special licensing/under nondisclosure. Call 1-800-222-1234 or send email to Marketing@Your_company_name.com for more information. Part_name IBIS rev Notes -------------------------------------------------------------------------- AlphPowPentHachip 2.1 fee and NDA Megamem64 1.1 fee 322323bd 1.1 fee +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 264-4299, Fax (503) 264-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 From speters@ichips.intel.com Thu May 4 15:29:26 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01182; Thu, 4 May 95 15:29:26 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Thu, 4 May 95 14:38:32 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 4 May 95 14:38:09 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 4 May 95 14:38:21 PDT Message-Id: <9505042138.AA05330@xtg801.intel.com> To: ibis@vhdl.org Cc: samie@ichips.intel.com Subject: Clarifing example for Packaging EGG Date: Thu, 04 May 1995 14:38:19 -0700 From: Stephen Peters Hello Fellow IBISains: As promised, here is a (I hope) clarifying example of how one would describe a package using the proposed xmission line package concept. In this example I've listed the rules for describing 'sections', and I've also added a [Unit Length] keyword. Why? Read on..... Suppose you have a package with the following pinout: ____ |-------- Pin1 sig1 |-------- Pin2 sig2 |-------- Pin3 GND |-------- Pin5 sig5 |-------- Pin6 sig6 |-------- Pin7 sig7 |-------- Pin8 PWR |-------- Pin9 sig9 |-------- Pin10, sig10 ____| Each package stub (for the signals) is modeled as follows: DIE--@@@@@@@@--ZZZZZZZZZZZZZZZZZ--zzzzzzz bondwire Trace Pin (lumped L) (coupled xmission (uncoupled xmission line) line) Also assume that the GND and PWR connections are modeled as a lumped 2.0n inductance. This package would be described as follows: ----- content of .pkg file -------- [IBIS Ver] 2.1 [File name] example.pkg . . . [Define Package Model] 10pin_pkg . . . | First, I believe a [Unit Length] keyword is needed. I realize that | as long as all the L/R/C parameters are given in terms of | unit length, and the physical length is specified in that same, consistent | unit (inches, cm, etc.) one can calculate the propagation velocity or | time delay of the section. However, the | user is going to be integrating this package description into the | boards netlist or topology. Therefore, the user has to know what units | the package description is in so the board extraction can use the same. | Permissible values are 'in', 'cm', 'ft'. | [Unit Length] in | | [Number of Pins] 10 | | [Number of Sections] 3 | | In the example above each package stub has three sections. | The sections are in series and represent the following elements; the | bondwire (modeled as a lumped inductor), the trace between the bondwire | and the external pin (modeled as a coupled transmission line), and the | external pin (modeled as a non-coupled transmission line). The pin | number keyword is used to describe each section. | | For reference, here are the rules for section descriptions and using | the the Len:, C:, L:, R: and Matrix arguments (Thanks to Kellee | Crisafulli for suggesting the Matrix argument.) | 1. Each section description is separated by a comma | 2. The legal argument combinations are | a) If the [Number of Sections] keyword is absent, then NO arguments to | the [Pin] keyword are permitted. It is assumed that there | is one section of lumped elements whose values are listed under | the [Matrix] keyword. This is the backwards compatibility option. | a) Len: and a single 'Matrix' argument. The L, R and C values are | listed in the Matrix description of that section. | b) Len: and any combination of the L:, C: and R: arguments. This | option is for modeling uncoupled transmission lines. | c) No Len: and any combination of the L:, C: and R: arguments. This | option is for modeling lumped elements. | d) Specifying a length of zero (i.e. Len:0) is permitted. | 3. When a non zero length is specified then L:, R: and C: must be expressed | in terms of unit length. | 4. A consistent unit of length (i.e. inches, cm, feet, etc.) must | be used throughout the package file. | | [Pin Number] Pin1 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 Pin2 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 Pin3 Len:0 L:0n , Len:1.2 Matrix, Len:0 L:0 Pin4 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 Pin5 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 Pin6 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 Pin7 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 Pin3 Len:0 L:0n , Len:1.2 Matrix, Len:0 L:0 Pin9 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 Pin10 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 | | The bondwire is described as 'Len:0 L:1.2n' -- a 1.2nH lumped | inductance. The package trace (section 2) is a coupled transmission line | so is described using the Len: and Matrix format. Section 3, the | actual pin, is described as 'Len:0.47 L:0.835n C:3.34' -- an | uncoupled transmission line 0.47 'units' long with | 8.35nh/unit_length of inductance and 3.34pF/unit_length of capacitance. | Also, note the power and ground connections (pins 3 and 7). | As mentioned above these stubs are modeled as a lumped inductor. | To keep it simple, section 2 MUST still use the 'Matrix' word. | I have chosen to lump all the inductance into the 'self L' term in | the matrix and "zero out" the rest of the sections. | Setting all the values in a section to zero is legal. | | Now comes the matrix description. It is assumed that pins 1 and 2 are | isolated (by the GND connection) from pins 4, 5, 6 and 7, which are in | turn isolated (by the PWR connection) from pins 9 and 10. A sparse | Matrix format is used. To save typing I am only going to show the C | matrix. | [Model Data] section 2 [Capacitance Matrix] Sparse_matrix [Row] 1 1 1.0p 2 1.5p [Row] 2 2 1.7p [Row] 3 3 0.0p | the L matrix would show the self inductance of the stub 3 [Row] 4 4 5.2p 5 3.7p 6 1.1p 7 0.1p [Row] 5 5 2.7p 6 1.0p 7 0.9p [Row] 6 6 2.1p 7 1.1p [Row] 7 7 3.3 [Row] 8 8 0.0p | again, use the L matrix to show self inductance [Row] 9 9 1.0p 10 1.5p [Row] 10 10 1.7p | | | Then follows the Inductance matrix (and R matrix if needed). | I hope this example clarifies my proposal. Hope to hear from everyone Friday. Best Regards, Stephen From jonp@qdt.com Thu May 4 16:46:54 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01698; Thu, 4 May 95 16:46:54 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyoig15729; Thu, 4 May 1995 19:41:09 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 4 May 1995 19:41:09 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00993; Thu, 4 May 95 16:22:53 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA16617; Thu, 4 May 95 16:29:00 PDT Date: Thu, 4 May 95 16:29:00 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505042329.AA16617@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA02295; Thu, 4 May 95 16:25:35 PDT To: ibis@vhdl.org Subject: IBIS Placard for Dac I currently have only 3 companies requesting IBIS placards. I need more to justify bothering. IBIS SPOKEN HERE at just 3 booths isn't very interesting. (Where are those MENTOR and CADENCE guys?) that pushy sob, jon From uunet!qdt.com!jonp@uunet.uu.net Thu May 4 17:51:35 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02053; Thu, 4 May 95 17:51:35 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyoik26481; Thu, 4 May 1995 20:44:32 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 4 May 1995 20:44:32 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01023; Thu, 4 May 95 16:38:03 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA16659; Thu, 4 May 95 16:44:09 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyoig15722; Thu, 4 May 1995 19:41:08 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 4 May 1995 19:41:08 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00987; Thu, 4 May 95 16:19:52 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA16614; Thu, 4 May 95 16:25:59 PDT Date: Thu, 4 May 95 16:25:59 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505042325.AA16614@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA02293; Thu, 4 May 95 16:22:34 PDT To: uunet!uunet!ichips.intel.com!speters@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!ichips.intel.com!samie@uunet.uu.net In-Reply-To: Stephen Peters's message of Thu, 04 May 1995 14:38:19 -0700 <9505042138.AA05330@xtg801.intel.com> Subject: A note on: Clarifing example for Packaging EGG I find the recommended methodology quite appropriate (in fact it is amazing like the coupling file used in XTK, I guess function does define form). There is one situation we want to make sure and plan for and that is where there are a hundred pins each of which couples to its immediate neighbors but doesn't really couple to pins a few pins away. (I think the propose format covers this syntactically but we want to be ready to simulate it also). 1 2 3 4 5 6 7 8 9 so 123 couple 234 couple 345 couple 567 couple etc. This is important because it allows the database to be partitioned into simulation segments that overlap but are smaller than simulating the entire pin coupling set. (which is essential for efficient simulation). jon From cpk@Cadence.COM Fri May 5 13:00:12 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17632; Fri, 5 May 95 13:00:12 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA05259; Fri, 5 May 1995 12:08:23 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma005244; Fri May 5 12:08:06 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA17487; Fri, 5 May 95 12:05:06 -0700 Received: by hot (5.65+/1.5) id AA01711; Fri, 5 May 95 15:08:01 -0400 Date: Fri, 5 May 95 15:08:01 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9505051908.AA01711@hot> To: ibis@vhdl.org, speters@ichips.intel.com Subject: Re: Clarifing example for Packaging EGG Cc: samie@ichips.intel.com Here is an example of "spice" description of the package > ____ > |-------- Pin1 sig1 > |-------- Pin2 sig2 > |-------- Pin3 GND > |-------- Pin5 sig5 > |-------- Pin6 sig6 > |-------- Pin7 sig7 > |-------- Pin8 PWR > |-------- Pin9 sig9 > |-------- Pin10, sig10 > ____| The top level subckt is a black box of external terminals > ________ >Die1 --- | |-------- Pin1 sig1 >Die2-----| |-------- Pin2 sig2 >Die3-----| |-------- Pin3 GND >Die5---- | |-------- Pin5 sig5 >Die6---- | |-------- Pin6 sig6 >Die7---- | |-------- Pin7 sig7 >Die8---- | |-------- Pin8 PWR >Die9---- | |-------- Pin9 sig9 Die10--- | |-------- Pin10, sig10 >_ |___ ____| The subcircuit called "package" has the following form: .subckt Package Die1......Die10 Pin1....Pin10 [Subcircuit description] .ends Package the subciruit is simply a black box with external terminals. The [Subcircuit description] can in turn be composed of hierarchichal subcircuits. The key points here are 1 - We are borrowing a way of describing networks in the form of subcircuits from spice which is elegant, simple and completely flexible. 2. IBIS does not and probably should not mandate what is contained inside the subcircuits. The subcircuit descriptions can be as complex or simple and it is totally left to the model developer. 3. The only convention the subcircuit has to obey is the EXTERNAL terminals naming convention. For example the names Pin1 and Die1 has to mean something in IBIS. 4. I want to emphasize it is not even necessary for us to invent a coupled transmission line description. Because the model developer can create a equivalent coupled transmission line description using sectioned lines containing mutual inductors and capacitors. However it may be nice if an acceptable coupled line description can be standardized. Let us follow an example of the subcircuit. Let us say that the pins are described like in the example shown by Stephen DIE--@@@@@@@@--ZZZZZZZZZZZZZZZZZ--zzzzzzz Let us assume Pins 1-3 are coupled and all other pins are simple lumped inductances Top Level: The package subcircuit completely describes this package .subckt Package Die1......Die10 Pin1....Pin10 X1 Die1 Die2 Die3 Pin1 Pin2 Pin3 SingleAndCoupledLines L4 Die4 Pin4 4.2nh ...... L10 Die10 Pin10 4.2nh .ends Package .subckt SingleAndCoupledLines Die1 Die2 Die3 Pin1 Pin2 Pin3 * Single transmission lines T11 Die1 0 1 0 td=0.5n z0=50 T22 Die2 0 2 0 td=0.45n z0=70 T33 Die3 0 3 0 td=0.4n z0=100 * coupled line X 1 2 3 Pin1 Pin2 Pin3 CoupledLine .ends SingleAndCoupledLines .subckt CoupledLine A B C Pin1 Pin2 Pin3 * sample coupled line TCoupled A 0 B 0 C 0 Pin1 0 Pin2 0 Pin3 0 Rlgc=3lineRlgcData Length=0.001m ,Data RLGC 3lineRlgcData .RMATRIX 4.0 0 0 0 4.0 0 0 0 4.0 .LMATRIX 420nh 10n 0.8n --- --- .CMATRIX --- -- .end Data RLGC .ends CoupledLine An alternate form of coupled line uses mutual inductances and capacitances .subckt AlternateCoupledLine 11 21 31 Pin1 Pin2 Pin3 * 3 sections of line X1 11 21 31 12 22 32 CoupledSection X2 12 22 32 13 23 33 CoupledSection X3 13 23 33 Pin1 Pin2 Pin3 CoupledSection .ends AlternateCoupledLine .subckt CoupledSection 1 2 3 1out 2out 3out r1 1 11 0.001 l1 11 1out 1.2n k 1 2 0.02 cmut 1 2 0.3p ..... .ends CoupledSection > > Hello Fellow IBISains: > > As promised, here is a (I hope) clarifying example of how one would > describe a package using the proposed xmission line package concept. > In this example I've listed the rules for describing 'sections', and > I've also added a [Unit Length] keyword. Why? Read on..... > > Suppose you have a package with the following pinout: > > ____ > |-------- Pin1 sig1 > |-------- Pin2 sig2 > |-------- Pin3 GND > |-------- Pin5 sig5 > |-------- Pin6 sig6 > |-------- Pin7 sig7 > |-------- Pin8 PWR > |-------- Pin9 sig9 > |-------- Pin10, sig10 > ____| > > > Each package stub (for the signals) is modeled as follows: > > DIE--@@@@@@@@--ZZZZZZZZZZZZZZZZZ--zzzzzzz > bondwire Trace Pin > (lumped L) (coupled xmission (uncoupled xmission > line) line) > > Also assume that the GND and PWR connections are modeled as a > lumped 2.0n inductance. > > > This package would be described as follows: > > ----- content of .pkg file -------- > > [IBIS Ver] 2.1 > [File name] example.pkg > . > . > . > [Define Package Model] 10pin_pkg > . > . > . > | First, I believe a [Unit Length] keyword is needed. I realize that > | as long as all the L/R/C parameters are given in terms of > | unit length, and the physical length is specified in that same, consistent > | unit (inches, cm, etc.) one can calculate the propagation velocity or > | time delay of the section. However, the > | user is going to be integrating this package description into the > | boards netlist or topology. Therefore, the user has to know what units > | the package description is in so the board extraction can use the same. > | Permissible values are 'in', 'cm', 'ft'. > | > [Unit Length] in > | > | > [Number of Pins] 10 > | > | > [Number of Sections] 3 > | > | In the example above each package stub has three sections. > | The sections are in series and represent the following elements; the > | bondwire (modeled as a lumped inductor), the trace between the bondwire > | and the external pin (modeled as a coupled transmission line), and the > | external pin (modeled as a non-coupled transmission line). The pin > | number keyword is used to describe each section. > | > | For reference, here are the rules for section descriptions and using > | the the Len:, C:, L:, R: and Matrix arguments (Thanks to Kellee > | Crisafulli for suggesting the Matrix argument.) > | 1. Each section description is separated by a comma > | 2. The legal argument combinations are > | a) If the [Number of Sections] keyword is absent, then NO arguments to > | the [Pin] keyword are permitted. It is assumed that there > | is one section of lumped elements whose values are listed under > | the [Matrix] keyword. This is the backwards compatibility option. > | a) Len: and a single 'Matrix' argument. The L, R and C values are > | listed in the Matrix description of that section. > | b) Len: and any combination of the L:, C: and R: arguments. This > | option is for modeling uncoupled transmission lines. > | c) No Len: and any combination of the L:, C: and R: arguments. This > | option is for modeling lumped elements. > | d) Specifying a length of zero (i.e. Len:0) is permitted. > | 3. When a non zero length is specified then L:, R: and C: must be expressed > | in terms of unit length. > | 4. A consistent unit of length (i.e. inches, cm, feet, etc.) must > | be used throughout the package file. > | > | > [Pin Number] > Pin1 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > Pin2 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > Pin3 Len:0 L:0n , Len:1.2 Matrix, Len:0 L:0 > Pin4 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > Pin5 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > Pin6 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > Pin7 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > Pin3 Len:0 L:0n , Len:1.2 Matrix, Len:0 L:0 > Pin9 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > Pin10 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 > | > | The bondwire is described as 'Len:0 L:1.2n' -- a 1.2nH lumped > | inductance. The package trace (section 2) is a coupled transmission line > | so is described using the Len: and Matrix format. Section 3, the > | actual pin, is described as 'Len:0.47 L:0.835n C:3.34' -- an > | uncoupled transmission line 0.47 'units' long with > | 8.35nh/unit_length of inductance and 3.34pF/unit_length of capacitance. > | Also, note the power and ground connections (pins 3 and 7). > | As mentioned above these stubs are modeled as a lumped inductor. > | To keep it simple, section 2 MUST still use the 'Matrix' word. > | I have chosen to lump all the inductance into the 'self L' term in > | the matrix and "zero out" the rest of the sections. > | Setting all the values in a section to zero is legal. > | > | Now comes the matrix description. It is assumed that pins 1 and 2 are > | isolated (by the GND connection) from pins 4, 5, 6 and 7, which are in > | turn isolated (by the PWR connection) from pins 9 and 10. A sparse > | Matrix format is used. To save typing I am only going to show the C > | matrix. > | > [Model Data] section 2 > [Capacitance Matrix] Sparse_matrix > [Row] 1 > 1 1.0p > 2 1.5p > [Row] 2 > 2 1.7p > [Row] 3 > 3 0.0p | the L matrix would show the self inductance of the stub 3 > [Row] 4 > 4 5.2p > 5 3.7p > 6 1.1p > 7 0.1p > [Row] 5 > 5 2.7p > 6 1.0p > 7 0.9p > [Row] 6 > 6 2.1p > 7 1.1p > [Row] 7 > 7 3.3 > [Row] 8 > 8 0.0p | again, use the L matrix to show self inductance > [Row] 9 > 9 1.0p > 10 1.5p > [Row] 10 > 10 1.7p > | > | > | Then follows the Inductance matrix (and R matrix if needed). > | > > I hope this example clarifies my proposal. Hope to hear from > everyone Friday. > > Best Regards, > Stephen > > > From mtovey@epic.com Fri May 5 14:46:46 1995 Return-Path: Received: from epic.com (gate-g.epic.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18435; Fri, 5 May 95 14:46:46 PDT Received: from lotus.epic (lotus.epic.com) by epic.com (4.1/JMA.3) id AA11181; Fri, 5 May 95 14:50:05 PDT Received: by lotus.epic (4.1/SMI-4.1) id AA27169; Fri, 5 May 95 14:41:06 PDT Date: Fri, 5 May 95 14:41:06 PDT From: mtovey@epic.com (Maria Tovey) Message-Id: <9505052141.AA27169@lotus.epic> To: ibis@vhdl.org Subject: IBIS Documentation Hello, This is a request for documentation regarding the IBIS specification. Basically - any information would be grand. Thanks, Maria Tovey From mtovey@epic.com Fri May 5 14:59:35 1995 Return-Path: Received: from epic.com (gate-g.epic.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18475; Fri, 5 May 95 14:59:35 PDT Received: from lotus.epic (lotus.epic.com) by epic.com (4.1/JMA.3) id AA11223; Fri, 5 May 95 15:02:56 PDT Received: by lotus.epic (4.1/SMI-4.1) id AA27193; Fri, 5 May 95 14:53:57 PDT Date: Fri, 5 May 95 14:53:57 PDT From: mtovey@epic.com (Maria Tovey) Message-Id: <9505052153.AA27193@lotus.epic> To: ibis@vhdl.org Subject: IBIS spec ----- Begin Included Message ----- From Mailer-Daemon@gate.epic.com Fri May 5 14:41:51 1995 Date: Fri, 5 May 1995 14:40:42 -0700 From: Mail Delivery Subsystem Subject: Returned mail: Host unknown (Name server: /usr/bin/uux: no data known) To: Content-Length: 1423 The original message was received at Fri, 5 May 1995 14:40:41 -0700 from nova.unix.portal.com [156.151.1.101] ----- The following addresses had delivery problems ----- (unrecoverable error) Hello, This is a request for documentation regarding the IBIS specification. Basically - any information would be grand. Thanks, Maria Tovey From jonp@qdt.com Fri May 5 15:53:14 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18855; Fri, 5 May 95 15:53:14 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyolv21246; Fri, 5 May 1995 18:47:28 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 5 May 1995 18:47:28 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00946; Fri, 5 May 95 14:48:18 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20613; Fri, 5 May 95 14:54:27 PDT Date: Fri, 5 May 95 14:54:27 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505052154.AA20613@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA04934; Fri, 5 May 95 14:51:01 PDT To: ibis@vhdl.org In-Reply-To: C. Kumar's message of Fri, 5 May 95 15:08:01 -0400 <9505051908.AA01711@hot> Subject: Clarifing example for Packaging EGG Here is a counter-example that shows that SPICE-like connectivity descriptions are probably not sufficient. ---+ |- PIN 1 |- PIN 2 |- PIN 3 |- PIN 4 |- PIN 5 |- PIN 6 |- PIN 7 |- PIN 8 |- PIN 9 |- PIN 10 |- PIN 11 |- PIN 12 |- PIN 13 |- PIN 14 |- PIN 15 |- PIN 16 |- PIN 17 |- PIN 18 |- PIN 19 |- PIN 20 |- PIN 21 |- PIN 22 |- PIN 23 |- PIN 24 |- PIN 25 |- PIN 26 |- PIN 27 |- PIN 28 ---+ All adjacent pins couple significantly. All pins further that two away do not couple in any measureable manner. A circuit that demands the simulation of all 28 pins (and therefor all 28 nets connecting to these pins) at the same time is not acceptable. A mechanism that allows overlapping and redundant coupling descriptions is needed. I do not believe that the SPICE SUBCKT concept will handle this situation. I think this (by the way) will be the rule, rather than the exception. jon From jonp@qdt.com Fri May 5 15:53:16 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18860; Fri, 5 May 95 15:53:16 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyolv21257; Fri, 5 May 1995 18:47:31 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 5 May 1995 18:47:31 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00962; Fri, 5 May 95 14:54:32 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20650; Fri, 5 May 95 15:00:42 PDT Date: Fri, 5 May 95 15:00:42 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505052200.AA20650@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA05177; Fri, 5 May 95 14:57:15 PDT To: ibis@vhdl.org Subject: re: previous counter example I hope everyone saw the analogy between the package and the tree frog we discussed at the ibis meeting. As with the tree frog, the only significant coupling is with immediately adjacent members. jon :) From Will_Hobbs@ccm2.jf.intel.com Fri May 5 16:44:35 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19142; Fri, 5 May 95 16:44:35 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s7WxI-000UuMC; Fri, 5 May 95 16:38 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s7WxG-000twVC; Fri, 5 May 95 16:38 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Fri, 05 May 95 16:38:42 PDT Date: Fri, 05 May 95 16:36:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org, jonp@qdt.com Subject: Re[2]: previous counter example Text item: For those that didn't phone in to the conference, see what you missed? I refuse to clarify the remark about frogs for anyone that didn't attend, although we can do so at the next phone conference on 4/26. See you then. And don't forget about the rooster's rib. Will I hope everyone saw the analogy between the package and the tree frog we discussed at the ibis meeting. As with the tree frog, the only significant coupling is with immediately adjacent members. jon :) Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: re: previous counter example To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA05177; Fri, 5 May 95 14:57:15 PDT Message-Id: <9505052200.AA20650@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Fri, 5 May 95 15:00:42 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20650; Fri, 5 May 95 15:00:42 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00962; Fri, 5 May 95 14:54:32 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 5 May 1995 18:47:31 -0400 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyolv21257; Fri, 5 May 1995 18:47:31 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18860; Fri, 5 May 95 15:53:16 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 5 May 95 16: 21:06 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Fri, 5 May 95 16:21:01 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0s7WgQ-000twVC; Fri, 5 May 95 16:21 PDT From Tim_A_Schreyer@ccm.jf.intel.com Fri May 5 16:49:55 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19205; Fri, 5 May 95 16:49:55 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s7X2W-000UuNC; Fri, 5 May 95 16:44 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s7X2W-000twVC; Fri, 5 May 95 16:44 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Fri, 05 May 95 16:44:08 PDT Date: Fri, 05 May 95 16:39:00 PDT From: Tim A Schreyer Message-Id: To: jonp@qdt.com, ibis@vhdl.org Subject: Re[2]: previous counter example Text item: And since they live in trees, the topic was appropriate for this group. By the way Jon, does this mean you'd prefer that we support the fully branched package model? Or should we just leave it alone? (sorry) Tim I hope everyone saw the analogy between the package and the tree frog we discussed at the ibis meeting. As with the tree frog, the only significant coupling is with immediately adjacent members. jon :) Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: re: previous counter example To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA05177; Fri, 5 May 95 14:57:15 PDT Message-Id: <9505052200.AA20650@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Fri, 5 May 95 15:00:42 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20650; Fri, 5 May 95 15:00:42 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00962; Fri, 5 May 95 14:54:32 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 5 May 1995 18:47:31 -0400 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyolv21257; Fri, 5 May 1995 18:47:31 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18860; Fri, 5 May 95 15:53:16 PDT Received: from [198.31.14.3] by hermes.intel.com (5.65/10.0i); Fri, 5 May 95 15: 51:03 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0s7WDA-000twWC; Fri, 5 May 95 15:51 PDT From cpk@Cadence.COM Mon May 8 08:19:00 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22933; Mon, 8 May 95 08:19:00 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA25135 for ; Mon, 8 May 1995 08:13:12 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma025050; Mon May 8 08:12:54 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA01359; Mon, 8 May 95 07:27:26 -0700 Received: by hot (5.65+/1.5) id AA02492; Mon, 8 May 95 10:26:56 -0400 Date: Mon, 8 May 95 10:26:56 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9505081426.AA02492@hot> To: ibis@vhdl.org Subject: Re: Clarifing example for Packaging EGG I thank Jon for the quick response. Let me make my arguements clearer. The arguements John put forward are precisely the ones which the spice subcircuit defintions solve in a clean and elegant fashion . A subcircuit defintion is highly flexible. It can be designed for any LEVEL of granularity. A subcircuit can represent single pins as well as any ARBITRARY grouping of pins. A package model may consists of a COLLECTON of these subcircuits. Say in Jon's example PIN 1 and 2 are uncoupled while 3 and 4 are coupled. Then the package subcircuits may have the form. .subckt pin1defintion buf1 pin1 .. .ends .subckt pin2defintion buf2 pin2 .. .ends .subckt pin3pin4defintion buf3 buf 4 pin3 pin4 ... .ends There is nothing in these subcircuit defintions which "demands" the simulation of all 28 pins. The role of IBIS may then be to offer GUIDELINES as to the granularity and the number of subcircuits that should represent the package model. > > Here is a counter-example that shows that SPICE-like connectivity descriptions are > probably not sufficient. > > ---+ > |- PIN 1 > |- PIN 2 > |- PIN 3 > |- PIN 4 > |- PIN 5 > |- PIN 6 > |- PIN 7 > |- PIN 8 > |- PIN 9 > |- PIN 10 > |- PIN 11 > |- PIN 12 > |- PIN 13 > |- PIN 14 > |- PIN 15 > |- PIN 16 > |- PIN 17 > |- PIN 18 > |- PIN 19 > |- PIN 20 > |- PIN 21 > |- PIN 22 > |- PIN 23 > |- PIN 24 > |- PIN 25 > |- PIN 26 > |- PIN 27 > |- PIN 28 > ---+ > > All adjacent pins couple significantly. All pins further that two away do not couple in any measureable manner. > A circuit that demands the simulation of all 28 pins (and therefor all 28 nets connecting to these pins) at the > same time is not acceptable. A mechanism that allows overlapping and redundant coupling descriptions is needed. > I do not believe that the SPICE SUBCKT concept will handle this situation. > > I think this (by the way) will be the rule, rather than the exception. > > > jon > From Will_Hobbs@ccm2.jf.intel.com Mon May 8 08:25:44 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23041; Mon, 8 May 95 08:25:44 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s8Ua3-000Ul9C; Mon, 8 May 95 08:18 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s8Ua2-000twVC; Mon, 8 May 95 08:18 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Mon, 08 May 95 08:18:42 PDT Date: Mon, 08 May 95 08:17:00 PDT From: Will Hobbs Message-Id: To: Tim_A_Schreyer@ccm.jf.intel.com, jonp@qdt.com, ibis@vhdl.org Subject: Re[3]: previous counter example Text item: Tim, and others, Actually, the comment about trees reminds me of a thought I had after the meeting last Friday. Graph theory, a branch of mathematics, has notation conventions that might be of some service in this problem. It deals with connectivity between arcs and nodes, similar to nodes and nets. If I remember, I'll dig out my old text book when I get home. Will And since they live in trees, the topic was appropriate for this group. By the way Jon, does this mean you'd prefer that we support the fully branched package model? Or should we just leave it alone? (sorry) Tim I hope everyone saw the analogy between the package and the tree frog we discussed at the ibis meeting. As with the tree frog, the only significant coupling is with immediately adjacent members. jon :) Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: re: previous counter example To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA05177; Fri, 5 May 95 14:57:15 PDT Message-Id: <9505052200.AA20650@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Fri, 5 May 95 15:00:42 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20650; Fri, 5 May 95 15:00:42 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00962; Fri, 5 May 95 14:54:32 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 5 May 1995 18:47:31 -0400 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyolv21257; Fri, 5 May 1995 18:47:31 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18860; Fri, 5 May 95 15:53:16 PDT Received: from [198.31.14.3] by hermes.intel.com (5.65/10.0i); Fri, 5 May 95 15: 51:03 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0s7WDA-000twWC; Fri, 5 May 95 15:51 PDT Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re[2]: previous counter example To: jonp@qdt.com, ibis@vhdl.org Message-Id: From: Tim A Schreyer Date: Fri, 05 May 95 16:39:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Fri, 05 May 95 16:44:08 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s7X2W-000twVC; Fri, 5 May 95 16:44 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s7X2W-000UuNC; Fri, 5 May 95 16:44 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19205; Fri, 5 May 95 16:49:55 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 5 May 95 17: 15:18 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Fri, 5 May 95 17:15:12 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0s7XWq-000twVC; Fri, 5 May 95 17:15 PDT From bracken@kevily.ece.cmu.edu Mon May 8 08:45:23 1995 Return-Path: Received: from kevily.ece.cmu.edu ([128.2.236.48]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23195; Mon, 8 May 95 08:45:23 PDT Received: from localhost (bracken@localhost) by kevily.ece.cmu.edu (8.6.11/8.6.4) with SMTP id LAA11560 for ; Mon, 8 May 1995 11:39:32 -0400 Message-Id: <199505081539.LAA11560@kevily.ece.cmu.edu> X-Authentication-Warning: kevily.ece.cmu.edu: Host localhost didn't use HELO protocol To: ibis@vhdl.org Subject: Who's the primary IBIS info contact? Date: Mon, 08 May 1995 11:39:30 -0400 From: J Eric Bracken Mighty IBISians, Hello! I've been fairly inactive for a while, so I thought I'd ask: who is now the primary IBIS information contact? Is it somebody at EIA? I'm giving a little tutorial on signal integrity at DAC, and I wanted to mention IBIS. That's why I'd like to be able to give people this pointer. Of course I'll mention the vhdl.org site too, but some people just want to talk to a human being (the primitives! :-) ) Thanks for any info, --Eric __________________________________________________________________ ________ ________ __ ________ /\_______\ /\_______\ /\_\ /\_______\ J. Eric Bracken, Ph.D. / / ______// / ____ // / // / ______/ Visiting Lecturer, Dept. of ECE / / /__\ / / /__\/ // / // / / Carnegie Mellon University / / ____/ / / ___ _// / // / /___ Pittsburgh, PA 15213 / / /____\ / / / \/ / / / // / /____\ (412) 268-8944 FAX (412) 268-3204 \/_______/ \/_/ \/_/ \/_/ \/_______/ eric.bracken@ece.cmu.edu __________________________________________________________________ From bracken@kevily.ece.cmu.edu Mon May 8 09:13:56 1995 Return-Path: Received: from kevily.ece.cmu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23350; Mon, 8 May 95 09:13:56 PDT Received: from localhost (bracken@localhost) by kevily.ece.cmu.edu (8.6.11/8.6.4) with SMTP id MAA03446 for ; Mon, 8 May 1995 12:08:09 -0400 Message-Id: <199505081608.MAA03446@kevily.ece.cmu.edu> X-Authentication-Warning: kevily.ece.cmu.edu: Host localhost didn't use HELO protocol To: ibis@vhdl.org Subject: Re: Clarifing example for Packaging EGG Date: Mon, 08 May 1995 12:08:08 -0400 From: J Eric Bracken Hi again, Jon Powell's comment is totally accurate: >> A circuit that demands the simulation of all 28 pins (and therefor all >> 28 nets connecting to these pins) at the same time is not >> acceptable. A mechanism that allows overlapping and redundant >> coupling descriptions is needed. But I disagree that a SPICE-like description, or, for that matter, any RLC matrix-based description, is unusable because of this. We all know that to get ULTIMATE accuracy requires very rigorous analysis. In principal that means all 28 pins fully coupled. Anything less than that is just an approximation. But that's fine if the approximation is a good one. And it's even better if the approximation makes the analysis run a lot faster. I would assume that the simulation vendor would do something internally to simplify the model with lots of coupling between pins, so that they could get results in a reasonable length of time. How they go about doing it is their business (literally.) I don't think we want to force them to do it in any particular way. So, basically, I don't see why SPICE is not sufficiently "overlapping and redundant." It's a lot MORE information than the simulator will probably ever need. The existing matrix descriptions are probably equally expressive, since they permit "full" or "sparse" coupling as needed. The one thing I _do_ worry about here is how the model MAKERS will go about producing the coupling information...using field solver software? Doing cut-and-try on measured data? With a dart board? This could really affect the accuracy of results, particularly when different vendors are doing their own thing. --Eric __________________________________________________________________ ________ ________ __ ________ /\_______\ /\_______\ /\_\ /\_______\ J. Eric Bracken, Ph.D. / / ______// / ____ // / // / ______/ Visiting Lecturer, Dept. of ECE / / /__\ / / /__\/ // / // / / Carnegie Mellon University / / ____/ / / ___ _// / // / /___ Pittsburgh, PA 15213 / / /____\ / / / \/ / / / // / /____\ (412) 268-8944 FAX (412) 268-3204 \/_______/ \/_/ \/_/ \/_/ \/_______/ eric.bracken@ece.cmu.edu __________________________________________________________________ From cer@Cadence.COM Mon May 8 10:11:09 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23752; Mon, 8 May 95 10:11:09 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA09526 for ; Mon, 8 May 1995 10:05:22 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma009511; Mon May 8 10:05:09 1995 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA15029; Mon, 8 May 95 10:05:34 -0700 Received: by oahu (5.65+/1.5) id AA03066; Mon, 8 May 95 13:05:05 -0400 Date: Mon, 8 May 95 13:05:05 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9505081705.AA03066@oahu> To: ibis@vhdl.org Subject: Re: Clarifing example for Packaging EGG Hello, I agree with Eric and Kumar. Spice syntax is the way to go for package models because it is flexibile and sufficient. Any circuit at all can be represented in SPICE. The only thing we need to add is a standard syntax for transmission lines and matricies, both of which I can propose if there is interest in this direction. We must also define a standard such as Kumar proposes on terminal naming plus a convention that makes it easy for automatic software to recognize mutual parasitics that can be edited out of the circuit based on some coupling criteria (which is up to the software). It is very important that Ibis support a broad, flexibile standard, not a narrow and restricted one. It is also important to recognize where the analysis software should do the work rather than the modeler (such as removing small couplings). Chris Reid From schumach@flare.convex.com Mon May 8 11:00:18 1995 Return-Path: Received: from convex.convex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24119; Mon, 8 May 95 11:00:18 PDT Received: from flare.convex.com by convex.convex.com (8.6.4.2/1.35) id MAA04284; Mon, 8 May 1995 12:53:47 -0500 Received: from localhost by flare.convex.com (8.6.4/1.28) id MAA19062; Mon, 8 May 1995 12:48:19 -0500 Date: Mon, 8 May 1995 12:48:19 -0500 From: schumach@flare.convex.com (Richard A. Schumacher) Message-Id: <199505081748.MAA19062@flare.convex.com> To: bracken@kevily.ece.cmu.edu, ibis@vhdl.org Subject: Re: Clarifing example for Packaging EGG J Eric Bracken writes: The one thing I _do_ worry about here is how the model MAKERS will go about producing the coupling information...using field solver software? Doing cut-and-try on measured data? With a dart board? This could really affect the accuracy of results, particularly when different vendors are doing their own thing. Aye, there's the rub. Package effects (crosstalk, ground/power bounce, etc.) often dominate or determine the device behavior, so a discretionary approach to packages can make the models useless if the modeller is not careful. Drivers and receivers cannot be modelled correctly without their packaging, unless the packaging is so good that its effects are negligible. Maybe vendors should put more effort into making their packaging "invisible"... Until that happens, for IBIS to be useful it must include a prescription for package modelling. In my experience, the only useful models are based on measured _AC_ data from actual parts. No 2-1/2D or 3D modeller I know of gives accurate results to useful precision in reasonable time, and quasi-DC I-V curves do not reveal package effects. Richard Schumacher From Will_Hobbs@ccm2.jf.intel.com Mon May 8 11:03:13 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24131; Mon, 8 May 95 11:03:13 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s8X3Y-000UlYC; Mon, 8 May 95 10:57 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s8X3W-000twVC; Mon, 8 May 95 10:57 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Mon, 08 May 95 10:57:18 PDT Date: Mon, 08 May 95 10:54:00 PDT From: Will Hobbs Message-Id: To: bracken@kevily.ece.cmu.edu, ibis@vhdl.org Subject: Re: Who's the primary IBIS info contact? Text item: Eric, Point poeple toward ibis-info@vhdl.org for the machine-like responder. It actually aliases to me for now, but I just cut and paste standard text into the reply mail that tells people where to get more information. If people have specific questions they need answered and can't get it from the cookbook, the overview, etc., which I reference in my standard ibis-info reply, they can post their questions to the reflector. The stalwart members of the Royal Order of IBIS, i.e., anyone on the reflector that chooses to respond, will answer their questions. So far, this has worked pretty well. Thanks for the plug adn good luck with your presentation. Will Mighty IBISians, Hello! I've been fairly inactive for a while, so I thought I'd ask: who is now the primary IBIS information contact? Is it somebody at EIA? I'm giving a little tutorial on signal integrity at DAC, and I wanted to mention IBIS. That's why I'd like to be able to give people this pointer. Of course I'll mention the vhdl.org site too, but some people just want to talk to a human being (the primitives! :-) ) Thanks for any info, --Eric __________________________________________________________________ ________ ________ __ ________ /\_______\ /\_______\ /\_\ /\_______\ J. Eric Bracken, Ph.D. / / ______// / ____ // / // / ______/ Visiting Lecturer, Dept. of ECE / / /__\ / / /__\/ // / // / / Carnegie Mellon University / / ____/ / / ___ _// / // / /___ Pittsburgh, PA 15213 / / /____\ / / / \/ / / / // / /____\ (412) 268-8944 FAX (412) 268-3204 \/_______/ \/_/ \/_/ \/_/ \/_______/ eric.bracken@ece.cmu.edu __________________________________________________________________ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: J Eric Bracken Date: Mon, 08 May 1995 11:39:30 -0400 Subject: Who's the primary IBIS info contact? To: ibis@vhdl.org X-Authentication-Warning: kevily.ece.cmu.edu: Host localhost didn't use HELO pro tocol Message-Id: <199505081539.LAA11560@kevily.ece.cmu.edu> Received: from localhost (bracken@localhost) by kevily.ece.cmu.edu (8.6.11/8.6.4 ) with SMTP id LAA11560 for ; Mon, 8 May 1995 11:39:32 -0400 Received: from kevily.ece.cmu.edu ([128.2.236.48]) by vhdl.vhdl.org (4.1/SMI-4.1 /BARRNet) id AA23195; Mon, 8 May 95 08:45:23 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 8 May 95 09: 24:06 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 8 May 95 10:13:17 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0s8WND-000twXC; Mon, 8 May 95 10:13 PDT From uunet!qdt.com!jonp@uunet.uu.net Mon May 8 12:52:00 1995 Return-Path: Received: from relay3.UU.NET ([192.48.96.8]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25049; Mon, 8 May 95 12:52:00 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyowk25850; Mon, 8 May 1995 15:43:18 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 8 May 1995 15:43:18 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00957; Mon, 8 May 95 11:53:40 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27733; Mon, 8 May 95 11:59:53 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyowh17509; Mon, 8 May 1995 14:56:05 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Mon, 8 May 1995 14:56:06 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00796; Mon, 8 May 95 11:20:26 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27288; Mon, 8 May 95 11:26:40 PDT Date: Mon, 8 May 95 11:26:40 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505081826.AA27288@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA09156; Mon, 8 May 95 11:23:10 PDT To: uunet!uunet!cadence.com!cpk@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: C. Kumar's message of Mon, 8 May 95 10:26:56 -0400 <9505081426.AA02492@hot> Subject: Clarifing example for Packaging EGG kumar, you are missing my point. give me an example where: pin 1 couples to pin 99 and 2. pin 2 couples to pin 1 and 3. pin 3 couples to pin 2 and 4. pin 4 couples to pin 3 and 5. pin 5 couples to pin 5 and 6. ... case a: all 3 pin groupings couple with exactly the same 3 element matrix. case b: all 3 pin groupings couple with different 3 element matrices. From uunet!qdt.com!jonp@uunet.uu.net Mon May 8 12:53:21 1995 Return-Path: Received: from relay3.UU.NET ([192.48.96.8]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25051; Mon, 8 May 95 12:53:21 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyowk25834; Mon, 8 May 1995 15:43:16 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 8 May 1995 15:43:16 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00945; Mon, 8 May 95 11:53:32 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27726; Mon, 8 May 95 11:59:46 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyowh17499; Mon, 8 May 1995 14:56:03 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Mon, 8 May 1995 14:56:03 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00786; Mon, 8 May 95 11:14:29 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27241; Mon, 8 May 95 11:20:43 PDT Date: Mon, 8 May 95 11:20:43 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505081820.AA27241@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA09154; Mon, 8 May 95 11:17:13 PDT To: uunet!uunet!kevily.ece.cmu.edu!bracken@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: J Eric Bracken's message of Mon, 08 May 1995 12:08:08 -0400 <199505081608.MAA03446@kevily.ece.cmu.edu> Subject: Clarifing example for Packaging EGG >> So, basically, I don't see why SPICE is not sufficiently "overlapping >>and redundant." It's a lot MORE information than the simulator will >>probably ever need. The existing matrix descriptions are probably equally >>expressive, since they permit "full" or "sparse" coupling as needed. I want to use a format that "lends" itself to easy partioning. If people believe that a 100 element SUBCKT does this, then we should use it. If however, people feel that a different format would be either easier to create or easier to interpret, then we should use that. >> Jon Powell's comment is totally accurate: but thanks for agreeing with me, I think. jon From Arpad_Muranyi@ccm.fm.intel.com Mon May 8 16:11:12 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26486; Mon, 8 May 95 16:11:12 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s8bri-000UnEC; Mon, 8 May 95 16:05 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s8brh-000twVC; Mon, 8 May 95 16:05 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Mon, 08 May 95 16:05:25 PDT Date: Mon, 08 May 95 15:59:00 PDT From: Arpad Muranyi Message-Id: To: ibis@vhdl.org Subject: keyword order Hello everyone, I just stumbled on an error message generated by the 2.1 beta parser when I put the keyword [Manufacturer] after the [Source] (and other) keywords in an IBIS file I just made. However, if I put it after the keyword [Component], it will pass with flying colors. As far as I understand, there are no ordering requirements for keywords. If this is true, the parser should be fixed. Am I wrong? Arpad From kellee@nwlink.com Mon May 8 17:05:27 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27024; Mon, 8 May 95 17:05:27 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id QAA21619; Mon, 8 May 1995 16:59:33 -0700 Date: Mon, 8 May 1995 16:59:33 -0700 Message-Id: <199505082359.QAA21619@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: New package model proposal by Steven Peters From: Kellee Crisafulli, HyperLynx Inc. I feel the last several emails are drifting off the central point. Steven has presented an egg which appears to provided the data needed, and do so in a fashion which is a direct extension from the original IBIS work. We already support both the discrete and matrix approaches the Steven suggested. Steven has simply suggested extending this to allow multiple levels. In terms of providing a more advanced simulation. I believe that the next IBIS modeling standard after the simple extension suggested by Steven Peters should include a physical representation. Why create yet another method of describing the package when we have a method ala Steven that extends what we alredy have and performs the job very nicely. Am I missing something here? Keep it Simple is usually the best approach and it seems to me that Steven has obseved the KISS principle. Have a great day...Kellee Crisafulli, HyperLynx Inc. From bob@icx.com Mon May 8 18:33:49 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27914; Mon, 8 May 95 18:33:49 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 8 May 95 18:25 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 8 May 95 18:27 PDT Message-Id: Date: Mon, 8 May 95 18:27 PDT From: bob@icx.com ( Bob Ross) To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: Re: keyword order Arpad: I believe the parser is operating correctly. The description states: "Clarifies the component's manufacturer." which means that [Manufacturer] is associated with the [Component] above and is required for every [Component] keyword. Also, IBIS_CHK for Version 1.1 produces the same error message. While typically [Manufacturer] is put following each [Component], it could also be positioned further down in the "component" section after the [Package] subparameters or after the [Pin] numbers portion. Bob Ross, Interconnectix, Inc. > Hello everyone, > I just stumbled on an error message generated by the 2.1 beta parser > when I put the keyword [Manufacturer] after the [Source] (and other) > keywords in an IBIS file I just made. > However, if I put it after the keyword [Component], it will pass with > flying colors. > As far as I understand, there are no ordering requirements for keywords. > If this is true, the parser should be fixed. Am I wrong? > Arpad From cer@Cadence.COM Tue May 9 06:27:09 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06443; Tue, 9 May 95 06:27:09 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA01377 for ; Tue, 9 May 1995 06:21:22 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma001371; Tue May 9 06:21:14 1995 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA25301; Tue, 9 May 95 06:21:32 -0700 Received: by oahu (5.65+/1.5) id AA03571; Tue, 9 May 95 09:21:08 -0400 Date: Tue, 9 May 95 09:21:08 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9505091321.AA03571@oahu> To: Ibis@vhdl.org Subject: Re: New package model proposal by Steven Peters Hello, Kellee makes a good point: > Why create yet another method of describing the package when we have a > method ala > Steven that extends what we alredy have and performs the job very nicely. > Am I missing something here? The problem as I see it is that the Egg proposes one way to model an MCM which may do for some particular part, but may be inadequate for some other part. We do not want to add to Ibis a plethora of syntaxes to support many different package model options. The matrix package models for pin parasitics are sufficient for traditional packages. For anything more complicated a different approach is needed. In general an MCM can be as complicated as a board and requires its own modeling tool. If such is available then it should be used along with the models for traces on the board (Cadence SigNoise for example is currently used in such cases). Lacking the actual MCM models or the capability of mixing them with the board models then some other technique is needed. But, that technique should be as general as possible so that no further extensions in this direction are required. One possibility is to use the pin parasitics type package models (the matrix approach) for the actual pins of a package and use spice subcircuits with a naming convention to define what pins they attach to. Such an approach would be perfectly generic, would NOT force unneeded pins into the circuit, and would never need extension. The Spice elements used could be restricted to passive elements. The advantages to this approach are: 1) Everyone understands the SPICE syntax, 2) With only passive SPICE elements there are no questions about models, 3) Extensions would NEVER be needed for any package since every possible package could be described in this syntax, 4) Automatic software would prune the matrix of pin parasitics to model only those pins that are needed, 5) SPICE subcircuits that are not needed are simply ignored by the simulator. Chris Reid From Will_Hobbs@ccm2.jf.intel.com Tue May 9 09:23:57 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07824; Tue, 9 May 95 09:23:57 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s8rz7-000UkAC; Tue, 9 May 95 09:18 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s8rz6-000twWC; Tue, 9 May 95 09:18 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Tue, 09 May 95 09:18:08 PDT Date: Tue, 09 May 95 09:15:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Subject: Beta 5 of Golden Parser on way. IBIS Parser licensees, Paul has given us a new version of the Beta parser, which I will send out today and tomorrow. According to Paul, "Ron is still working on one or two things, but I wanted to get my updates to you for testing. The fixes this one has are: 1) the waveform typical column handling NA's like the V/I curves. 2) the casing of filenames working across platforms. I did what I thought was appropriate for the file casing, and tested it to the best of my ability, however I don't have a UNIX or NT system, so my testing was only partial. Please do what you can to see if it's correct. Also, please see if it behaves as expected for a '.pkg' file." Regards, Will From gil_b@ird.scitex.com Wed May 10 02:05:06 1995 Return-Path: Received: from ird.scitex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16425; Wed, 10 May 95 02:05:06 PDT Received: by ird.scitex.com (AIX 3.2/UCB 5.64/4.03) id AA05995; Wed, 10 May 1995 12:01:12 +0300 From: "Gil Bellaiche" Message-Id: <9505101201.ZM45673@ird.scitex.com.> Date: Wed, 10 May 1995 12:01:12 +0000 X-Mailer: Z-Mail (3.2.0 06sep94) To: ibis@vhdl.org Subject: Information about ibis models Cc: moshe_n@ird.scitex.com, gil_b@ird.scitex.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Where can I get information about the vendors that supply IBIS models ? Is there anywhere a list of components that have IBIS models ? Thanks, -- Gil Bellaiche ECAD System Manager SCITEX Corpotation LTD. P.O. BOX 330 HERZLYIA B 46103 ISRAEL TEL : 972-9-597778 FAX : 972-9-502922 Email : gil_b@ird.scitex.com From speters@ichips.intel.com Wed May 10 09:32:06 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23543; Wed, 10 May 95 09:32:06 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Wed, 10 May 95 09:26:16 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 10 May 95 09:25:54 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 10 May 95 09:26:10 PDT Message-Id: <9505101626.AA28755@xtg801.intel.com> To: Ibis@vhdl.org Subject: Re[2]: New package model proposal by Steven Peters Date: Wed, 10 May 1995 09:26:09 -0700 From: Stephen Peters Hello Chris, Kumar, Kellee and others: On 5/9 Chris Reed wrote: >The problem as I see it is that the Egg proposes one way to model >an MCM which may do for some particular part, but may be inadequate for >some other part. We do not want to add to Ibis a plethora of syntaxes >to support many different package model options. My proposal was never intended to model MCMs, SIMs, etc. and I belive we should take a long, hard look before we start trying to describe what amounts to complex circuit boards. IBIS is a standard describing *I/O buffers*; we are concerned about the packaging only is as much as its effects are inseperable from the actual silicon characteristics. Also, this proposal is an attempt to refine what has already been defined, not come up with a whole new scheme. It does cover existing DIP/SOIC/ PQFP/BGA/PGA/TAB packages -- basicly any package where the leadframe can be represented as multipule elements in series, with coupling between any set of arbitary elements. This may be a bit of a philosophical discussion, but consider this: users, given half a chance, would take a '.pkg' file that allows general descriptions and use it to describe an entire motherboards net topology. This may be a 'great and wonderful' thing, but is that the intent of IBIS? Regards, Stephen Peters From fvance@FirePower.COM Wed May 10 10:40:59 1995 Return-Path: Received: from FirePower.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24123; Wed, 10 May 95 10:40:59 PDT Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA25497; Wed, 10 May 95 10:35:11 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA06079; Wed, 10 May 95 10:35:10 -0700 From: Fred Vance Message-Id: <9505101735.AA06079@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02159; Wed, 10 May 95 10:35:09 -0700 Date: Wed, 10 May 95 10:35:09 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: Ibis@vhdl.org Subject: New package model proposal by Steven Peters Hi, I want to put in a word as an IBIS model user. First, I must admit that I haven't reviewed Steven's Egg carefully. I have only scanned it cursorily. I don't believe that anyone would seriously propose providing IBIS models that are package dependent. Package information is desireable to the user. The more the better as long as it can be separated from the die information if necessary. Am I wrong in thinking that some of the more complex packages like 200+ pin BGAs and PGAs are actualy circuit boards? If they are, then there are a lot of similarities with SIMMs. If Steven's Egg will allow manufacturers to provide package information for SIMMs, I want to nominate him for IBISian of the year, even if that wasn't his intention. If the Egg won't allow for that level of package information, why not make it so that it will (provided the user can separate die and package information when necessary). It may be difficult or impossible for anyone to convince SIMM manufacturers to provide SIMM package information, but I would like to leave the door open for them to do so. I suspect that packaging information will become more and more important with time and that packaging will become more complex rather than less. Please keep the IBIS standard open to the future. Regards, Fred Vance FirePower Systems, Inc. Begin forwarded message: To: Ibis@vhdl.org Subject: Re[2]: New package model proposal by Steven Peters Date: Wed, 10 May 1995 09:26:09 -0700 From: Stephen Peters Hello Chris, Kumar, Kellee and others: On 5/9 Chris Reed wrote: >The problem as I see it is that the Egg proposes one way to model >an MCM which may do for some particular part, but may be inadequate for >some other part. We do not want to add to Ibis a plethora of syntaxes >to support many different package model options. My proposal was never intended to model MCMs, SIMs, etc. and I belive we should take a long, hard look before we start trying to describe what amounts to complex circuit boards. IBIS is a standard describing *I/O buffers*; we are concerned about the packaging only is as much as its effects are inseperable from the actual silicon characteristics. Also, this proposal is an attempt to refine what has already been defined, not come up with a whole new scheme. It does cover existing DIP/SOIC/ PQFP/BGA/PGA/TAB packages -- basicly any package where the leadframe can be represented as multipule elements in series, with coupling between any set of arbitary elements. This may be a bit of a philosophical discussion, but consider this: users, given half a chance, would take a '.pkg' file that allows general descriptions and use it to describe an entire motherboards net topology. This may be a 'great and wonderful' thing, but is that the intent of IBIS? Regards, Stephen Peters From kellee@nwlink.com Wed May 10 11:15:11 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24397; Wed, 10 May 95 11:15:11 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id LAA14415; Wed, 10 May 1995 11:09:11 -0700 Date: Wed, 10 May 1995 11:09:11 -0700 Message-Id: <199505101809.LAA14415@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: New pkg (reply to Steven Peters) I completely agree with Steven. His egg is a very good extension of the format already specified. To add support for MCM's another approach is needed. I still firmly believe the next new format (after Steven's egg) should be a physical discription of the layout. This should be the easiest for the the IC vendors to impliment by long ways. They already have the physical description in order to build the package. Have a great day...Kellee Crisafulli, HyperLynx Inc. From Arpad_Muranyi@ccm.fm.intel.com Wed May 10 13:20:54 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25449; Wed, 10 May 95 13:20:54 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s9I9x-000UjsC; Wed, 10 May 95 13:15 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s9I9w-000twVC; Wed, 10 May 95 13:15 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 10 May 95 13:15:04 PDT Date: Wed, 10 May 95 13:09:00 PDT From: Arpad Muranyi Message-Id: To: ibis@vhdl.org, fvance@FirePower.COM Subject: Re: New package model proposal by Steven Peters Text item: Fred, Do I understand you correctly? Are you suggesting that the PCB portion of SIMMs should be described as if they were packages? Even though I see the similarities between PCBs and MCMs or other types of packages, I strongly disagree with your wish to be able to handle SIMMs as if they were packages. SIMMs are clearly printed circuit boards with multiple components on them and they should be handled as such. The best way of doing so is to make full-board simulation tools understand multiple board situations, so that a motherboard with a SIMM (or more) could be simulated as two or more PCBs connected together. As Stephen said, IBIS is a component modeling format and not a PCB description language. The question in my mind is whether MCMs and the like should be handled as PCBs, because from a user's point of view, an MCM package is one piece of something and from the outside it looks like a single component. It is true, that vendors have a hard time to release models of their SIMMs. If you were a SIMM vendor, which format would use to create a model? Quad, xSPICE, Interconnectix, EDIF, etc...? As I see it, a generic interconnect description language standard is missing here, which could be used by any simulation tool. This standard should have the capabilities to describe PCBs as well as packages, and then it could be used for SIMMs, motherboards, MCMs, complex packages, etc... Arpad Muranyi Intel Corporation, Folsom, CA ------------------------------------------------------------------------------- Hi, ... Am I wrong in thinking that some of the more complex packages like 200+ pin BGAs and PGAs are actualy circuit boards? If they are, then there are a lot of similarities with SIMMs. If Steven's Egg will allow manufacturers to provide package information for SIMMs, I want to nominate him for IBISian of the year, even if that wasn't his intention. If the Egg won't allow for that level of package information, why not make it so that it will (provided the user can separate die and package information when necessary). ... Regards, Fred Vance FirePower Systems, Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: New package model proposal by Steven Peters To: Ibis@vhdl.org Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Wed, 10 May 95 10:35:09 -0700 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02159; Wed, 10 May 95 10:35:09 -0700 Message-Id: <9505101735.AA06079@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA06079; Wed, 10 May 95 10:35:10 -0700 Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA25497; Wed, 10 May 95 10:35:11 -0700 Received: from FirePower.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24123; Wed, 10 May 95 10:40:59 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 10 May 95 10 :37:12 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0s9GM8-000twYC; Wed, 10 May 95 11:19 PDT From cjshi@analogy.com Wed May 10 14:18:43 1995 Return-Path: Received: from tiny.sprintlink.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25918; Wed, 10 May 95 14:18:43 PDT Received: from analogy.com (analogy.analogy.com [149.117.1.1]) by tiny.sprintlink.net (8.6.9/8.6.9) with SMTP id RAA10809; Wed, 10 May 1995 17:12:51 -0400 Received: from miller.analogy.com by analogy.com (4.1/Shared_Spool_1.3) id AA21602; Wed, 10 May 95 14:13:27 PDT Received: from cheetah.analogy.com by miller.analogy.com (4.1/SMI-3.2) id AA18327; Wed, 10 May 95 14:13:27 PDT Received: by cheetah.analogy.com (5.0/SMI-SVR4) id AA21281; Wed, 10 May 1995 14:13:26 -0700 From: cjshi@analogy.com (Richard Shi) Message-Id: <9505102113.AA21281@cheetah.analogy.com> Subject: Re: New package model proposal by Steven Peters To: Arpad_Muranyi@ccm.fm.intel.com (Arpad Muranyi) Date: Wed, 10 May 1995 14:13:25 -0700 (PDT) Cc: ibis@vhdl.org, fvance@FirePower.COM In-Reply-To: from "Arpad Muranyi" at May 10, 95 01:09:00 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 338 > It is true, that vendors have a hard time to release models of their SIMMs. If > you were a SIMM vendor, which format would use to create a model? Quad, xSPICE, > Interconnectix, EDIF, etc...? > Any interest in using VHDL-A, Analog VHDL, currently being defined by IEEE 1076.1? Best regards, Richard Shi cjshi@analogy.com From speters@ichips.intel.com Wed May 10 14:33:02 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25998; Wed, 10 May 95 14:33:02 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Wed, 10 May 95 14:27:14 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 10 May 95 14:26:48 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 10 May 95 14:27:04 PDT Message-Id: <9505102127.AA00147@xtg801.intel.com> To: ibis@vhdl.org Subject: New package model proposal: Date: Wed, 10 May 1995 14:27:03 -0700 From: Stephen Peters Hello All: >Even though I see the similarities between PCBs and MCMs or other types of >packages, I strongly disagree with your wish to be able to handle SIMMs as if >they were packages. SIMMs are clearly printed circuit boards with multiple >components on them and they should be handled as such. Thank you, Arpad and Fred, for so clearly defining the bounds of the problem. Once your beyond the I/O bufer and its immediate mechanical housing, your into a different problem space, so to speak.... Best Regards, Stephen Peters Intel Corp. P.S. Thank you Fred for your IBISain of the year nomination. I just hesitate to think what the prize might be . From fvance@FirePower.COM Wed May 10 14:54:27 1995 Return-Path: Received: from FirePower.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26122; Wed, 10 May 95 14:54:27 PDT Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA26756; Wed, 10 May 95 14:44:00 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14074; Wed, 10 May 95 14:43:45 -0700 From: Fred Vance Message-Id: <9505102143.AA14074@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02222; Wed, 10 May 95 14:43:43 -0700 Date: Wed, 10 May 95 14:43:43 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: Arpad Muranyi Subject: Re: New package model proposal by Steven Peters Cc: ibis@vhdl.org Arpad, Yes you understand me correctly. How else am I going to model a DRAM SIMM connected to and loading my main logic board? Without having the vendor's PCB design database, I have to guess how long each control, address, or data line is and what the impedance and delay characteristics are, and I have to assume that there is no coupling between traces. If the SIMM were treated as a package it would be possible to define the minimum and maximum delay and loading for each signal. This would allow the vendor to provide information about his SIMM without revealing his PCB design. From my point of view, a 72 pin SIMM is no different than a 100 pin PGA. Unless I want to dissect the package, I only know what the vendor tells me. If I were a SIMM vendor, I would use IBIS to describe my SIMMs if possible. If IBIS allows bond wires and lead frames to be described and if Steven Peters' Egg will enable IBIS to add coupled or uncoupled transmission lines to the package description or some equivalent matrix, it seems to me that it would be possible for a SIMM vendor to provide the information that I need without revealing his PCB design. Where do we draw the line between components and circuit boards? My car has an air flow sensor circuit board with two die on it. I have read in news reports, that the P6 has two die in one package. I believe the difference lies only in the need for a person to successfully design the part into an application. If the success of the design depends on knowning the I/O buffer and package characteristics, to me at least, it is a component. Regards, Fred Vance Begin forwarded message: Date: Wed, 10 May 95 13:09:00 PDT From: Arpad Muranyi To: ibis@vhdl.org, fvance@FirePower.COM Subject: Re: New package model proposal by Steven Peters Fred, Do I understand you correctly? Are you suggesting that the PCB portion of SIMMs should be described as if they were packages? Even though I see the similarities between PCBs and MCMs or other types ofpackages, I strongly disagree with your wish to be able to handle SIMMs as ifthey were packages. SIMMs are clearly printed circuit boards with multiplecomponents on them and they should be handled as such. The best way of doing so is to make full-board simulation tools understand multiple board situations, sothat a motherboard with a SIMM (or more) could be simulated as two or more PCBsconnected together. As Stephen said, IBIS is a component modeling format and not a PCB descriptionlanguage. The question in my mind is whether MCMs and the like should be handled as PCBs,because from a user's point of view, an MCM package is one piece of somethingand from the outside it looks like a single component. It is true, that vendors have a hard time to release models of their SIMMs. Ifyou were a SIMM vendor, which format would use to create a model? Quad, xSPICE, Interconnectix, EDIF, etc...? As I see it, a generic interconnect description language standard is missinghere, which could be used by any simulation tool. This standard should have the capabilities to describe PCBs as well as packages, and then it could be used for SIMMs, motherboards, MCMs, complex packages, etc... Arpad Muranyi Intel Corporation, Folsom, CA From bob@icx.com Wed May 10 20:27:49 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28388; Wed, 10 May 95 20:27:49 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 10 May 95 20:21 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 10 May 95 20:24 PDT Message-Id: Date: Wed, 10 May 95 20:24 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Package Model Arguments To IBIS Committee: The three approaches to the package model extension problem are being discussed: (1) physical extension based on mechanical layout, (2) electrical extension based on Spice Subcircuit methodology, and (3) electrical extension based on IBIS format extension. (1) The physical extension seems to be for future consideration since it requires development and agreement on a whole new approach within IBIS or adoption of another standardized approach. (2) I believe that the Subcircuit extension provides sufficient functionality and I would be interested in it being developed more formally into a BIRD. In this way some additional format detail issues and constraints may then surface. (3) Good work and refinement has already gone into the IBIS format extension proposal, and it appears ready for a BIRD. Here are some arguments in support of the IBIS format extension approach: (a) It provides a very robust, neutrally formatted feature set compatible with all simulator communities. It is probably easier to develop translation utilities to convert this format to variations of Spice than it is to convert general nodal formatted data into formats used by several simulator companies which use IBIS directly. (b) I believe the matrix data formats are already more compact than Spice syntax structures. (c) The structure lends itself to validating correct topologies via syntax checking extensions to IBIS_CHK. The advantage of flexability and extensibility of the nodal appoach is actually a disadvantage for checking. (d) It avoids the issue of which maximally compatible subset of Spice syntax to use, or what (incompatible) extensions to propose. I still remain open on this issue. I would like to see some completely filled out numerical examples for small sized PGA and flatpack packages with coupled matrix sections using the proposed IBIS format extension. I would also like to see proposed Spice formatted structures to represent the same data. Bob Ross Interconnectix, Inc. From kellee@nwlink.com Wed May 10 20:48:03 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28583; Wed, 10 May 95 20:48:03 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id UAA08822; Wed, 10 May 1995 20:41:58 -0700 Date: Wed, 10 May 1995 20:41:58 -0700 Message-Id: <199505110341.UAA08822@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: New package model (Fred, Arpad, Steven) Hi guys, I have to agree with Fred completely. My customers do consider SIMM modules to be IC's. They treat them as a single unit. They don't make the circuit boards for them themselves. Different vendors have completely different layouts for the boards. This is exactly! what I have been talking about relative to using physical PCB descriptions for the packaging. So to respond to Arpad's statement, a SIMM module is considered an IC by the customers like Fred that use them. If Intel made SIMM modules you would hear this from your customers. I would like to repeat the point I have been trying to make for several months. 1) for more advanced packaging like (SIMM,s PGA's, and MCM's) I believe a physical format similar to a PCB layout should be added to IBIS. 2) For the more intermediate packaging needs like what Steven is working with on the P6 the proposal that Steven has offered gives us a very nice extension to the existing standard. These two extensions together should satisify most (not all) packaging needs for many years to come. Have a great day...Kellee Crisafulli, HyperLynx Inc. From kellee@nwlink.com Wed May 10 21:18:13 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28752; Wed, 10 May 95 21:18:13 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id VAA10518; Wed, 10 May 1995 21:12:19 -0700 Date: Wed, 10 May 1995 21:12:19 -0700 Message-Id: <199505110412.VAA10518@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Adding a PCB like format to IBIS From: Kellee Hi again, I agree with Bob Ross that Steven's proposal is ready to be a BIRD. The issue of modules like SIMM's has been broached by Fred and I think it is worth additional comment. 1) We should discuss at the next meeting support of modules (YES/NO) 2) If we decide yes than the next questions is how. Any company that can layout a PCB for a SIMM module could provide a PCB description. I submit that most company's would not be willing to create a SPICE format file. It requires tools that are not widely available, or are expensive. Or alternately converting to spice format or even matrix format's by hand for a SIMM module would be a mighty big ugly job. Have a great day...Kellee Crisafulli, HyperLynx Inc. From uunet!qdt.com!jonp@uunet.uu.net Wed May 10 22:24:51 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29166; Wed, 10 May 95 22:24:51 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQypfh12468; Thu, 11 May 1995 01:16:45 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 11 May 1995 01:16:44 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01141; Wed, 10 May 95 15:37:20 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA07312; Wed, 10 May 95 15:43:39 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQypeg24057; Wed, 10 May 1995 18:37:24 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 10 May 1995 18:37:08 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00998; Wed, 10 May 95 14:40:43 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA06968; Wed, 10 May 95 14:47:01 PDT Date: Wed, 10 May 95 14:47:01 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505102147.AA06968@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA12046; Wed, 10 May 95 14:43:27 PDT Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!FirePower.COM!fvance@uunet.uu.net In-Reply-To: Arpad Muranyi's message of Wed, 10 May 95 13:09:00 PDT Subject: New package model proposal by Steven Peters I must agree with Fred Vance. The description of the PCB portion of a SIMM is an IBIS issue. If INTEL was putting the P7 on a SIMM I sure everyone at INTEL would agree. ;) Of course, whether or not we need to address this issue with this current EGG is a very good question. jon From Arpad_Muranyi@ccm.fm.intel.com Fri May 12 09:05:06 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00218; Fri, 12 May 95 09:05:06 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0s9x7V-000UlAC; Fri, 12 May 95 08:59 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0s9x7T-000twWC; Fri, 12 May 95 08:59 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Fri, 12 May 95 08:59:15 PDT Date: Fri, 12 May 95 08:45:00 PDT From: Arpad Muranyi Message-Id: To: ibis@vhdl.org Subject: MCMs and SIMMs, etc... in IBIS Hi IBIS gurus, I am trying to attempt to summarize my reactions to the responses my last EMAIL generated. For one thing, Stephen Peters' recommendation does not involve branching and the like. This in itself prevents it from being a true SIMM and MCM package description. If our goal is to extend Stephen's EGG to cover all those devices, we might as well take an advantage of the already available PCB extraction and field solver tools which do a pretty good job in this area. As far as I understand, these tools use geometrical descriptions provided by layout editors. There is no need to reinvent the wheel by describing the same stuff with a different syntax or behaviorally in IBIS. All we need is a simulator which understands multiple boards, have board descriptions of PCBs, SIMMs and MCMs, and have the IBIS models for the chips (and dies) that are put on the PCBs, SIMMs and MCMs. This is all possible today and I heard that it is also being done in some places already. It is another story to invent (or find) a common and general PCB, SIMM and MCM description language which enables all the tools to get data from a single file format like IBIS does it with buffer models. To Fred, I would like to respond with saying that it is not enough to have delay and loading information only for a SIMM or similar device. You also need topological information to be able to figure out reflections, cross talk and similar effects. To Jon I have a question: What makes SIMMs and MCMs an IBIS issue? If Intel were to put the "P999" die(s) not on a SIMM, (as you suggested), but an MCM and gave you a PCB-like description of the MCM substrate (which you could process with your field solver) along with IBIS models for the die(s), would you need anything else? The IBIS model(s) of the die(s) could be referenced by the MCM description file which could be referenced by the motherboard (as if it were an other PCB or component). To sum it up, I see two opposite IBIS bird migration paths here. (And I myself am not sure which one is the right one). 1) {To be... } Include geometric or behavioral interconnect descriptions in IBIS (.pkg-like files) for SIMMs, MCMs, etc... In the case of geometric descriptions we will have to reinvent the wheel and provide syntax for all this stuff and convince everyone (layout and simulation tool vendors) to start using it. If we decide to use behavioral interconnect descriptions in IBIS, people who make the models will have to buy their own field solvers, network analyzer and TDR machines, etc... to be able to put together the matrixes required by the more ambitious model users. Both of these would be a vaste, since these functionalities are already available and running in the board extractors and field solvers of the simulations tools on the market. 2) {... or not to be?} Exclude all PCB-like descriptions from IBIS and provide a referencing mechanism to layout tool output files for SIMMs, MCMs and the like. In this case we could make use of the already available field solvers and board extraction tools of simulators and we would only have to convince SIMM and MCM vendors to provide data about their designs from their layout tools. {... This is the question}, as I see it. This PCB-like description of MCMs might be conflicting with my concern I expressed earlier about revealing possible manufacturing secrets, but I have a feeling that SIMM and MCM layouts would not be such a big secret to anyone. Points 1 and 2 are actually not much different, as I think about it. The question is, does the geometric board (SIMM & MCM...) description exists inside or outside IBIS. If it is inside, it becomes a duplicate of a layout tool output file possibly in a different syntax format. If it is outside, it might be directly read from the layout tool, which most simulators can do anyway. If we are talking behavioral descriptions in IBIS, the model maker will have to duplicate the work of the field solvers up front. Any comments? Arpad Muranyi Intel Corporation From jayd@VNET.IBM.COM Fri May 12 10:07:54 1995 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00755; Fri, 12 May 95 10:07:54 PDT Message-Id: <9505121707.AA00755@vhdl.vhdl.org> Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0682; Fri, 12 May 95 13:01:45 EDT Date: Fri, 12 May 95 12:52:49 EDT From: "J. C. (Jay) Diepenbrock ((919)-543-8804)" X-Addr: Communications Transceiver Dev't, D63/061 IBM Network Hdwe. Div. P. O. Box 12195 Research Triangle Park, NC 27709 To: ibis@vhdl.org Subject: MCMs, SIMMs, and such I agree heartily with Arpad. I see no advantage, and plenty of disadvan- tages to extending IBIS to include PCB-like packages. Since the existing tools handle such assemblies very nicely, why re-invent the wheel while making the IBIS model hopelessly complicated? I like Stephen's concept of allowing the model provider to use either lumped or matrix form as he/ she deems appropriate, but would much prefer to see the IBIS model used as the lowest level of a hierarchical model, with what we refer to as the "first level package" above it. In the case of a SIMM or MCM, the chip level model is used with a different higher level package model that is provided by the designer of the MCM, SIMM card, etc. with all the appro- priate trace lengths, etc. Now, as for Stephen's proposal itself, I may have missed something. If I understand it correctly, Stephen proposes that self-inductance would be in the inductance matrix, but he described "zeroing out" the mutual terms. Was this just for a specific example, I hope, or is this to say that all coupling terms are always to be capacitive? If the latter, I would suggest that the model is inadequate. I do like other aspects of the proposal, especially the physical correspondence of the framework. Jay Diepenbrock From speters@ichips.intel.com Fri May 12 12:52:29 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02057; Fri, 12 May 95 12:52:29 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 12 May 95 12:46:39 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 12 May 95 12:46:16 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 12 May 95 12:46:34 PDT Message-Id: <9505121946.AA07954@xtg801.intel.com> To: ibis@vhdl.org Subject: MCMs, SIMMs, and such Date: Fri, 12 May 1995 12:46:33 -0700 From: Stephen Peters Hello All: On 5/12 Jay Diepenbrock wrote: >Now, as for Stephen's proposal itself, I may have missed something. If >I understand it correctly, Stephen proposes that self-inductance would >be in the inductance matrix, but he described "zeroing out" the mutual >terms. Was this just for a specific example, I hope, or is this to say >that all coupling terms are always to be capacitive? If the latter, I >would suggest that the model is inadequate. No, matrixes are provided for capactiace, resistance and inductance. In other words, between the [Model data] and [End model data] keywords one can put... [Resistance Matrix] matrix_type . . . [Capacitance Matrix] matrix_type . . . [Inductance Matrix] matrix_type . . . When I wrote of 'zeroing out' the mutuals I was refering to that specific example where there was insiginifact mutual coupling for that section. Good question though. Regards, Stephen Peters Intel Corp. From speters@ichips.intel.com Fri May 12 18:20:22 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04924; Fri, 12 May 95 18:20:22 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 12 May 95 18:14:33 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 12 May 95 18:14:11 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 12 May 95 18:14:29 PDT Message-Id: <9505130114.AA08900@xtg801.intel.com> To: ibis@vhdl.org Subject: Transmission Line Package Proposal Date: Fri, 12 May 1995 18:14:27 -0700 From: Stephen Peters Hello Fellow IBISians: First, thanks to eveyone for your comments. I will be issuing a bird soon, but I wanted to add my thoughts on the discussion so far. I agree with Fred that SIMs or MCM modules ideally should be able to be treated as just another component for board level simulation. The real crux of the problem (as Arpad so artfully pointed out) is that simulator vendors must be able to seamlessly integrate multipule board topologies/netlists together into one simulation netlist. I am not opposed to IBIS being used as the vehical for solving the information transfer (MCM/SIM routing) part of this problem -- it's just that my proposal (as I have pointed out) set out to solve a different problem, mainly that of describing DIP/QFP/PGA packages with long stubs. I do belive we can (and should) consider the current EGG seperately from the issue of being able to describe SIM and MCM board routing. 'Nuff said. Best Regards, Stephen Peters Intel Corp. From jonp@qdt.com Mon May 15 13:53:15 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21172; Mon, 15 May 95 13:53:15 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQypwl21562; Mon, 15 May 1995 16:47:24 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 15 May 1995 16:47:23 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00940; Mon, 15 May 95 12:31:15 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA21168; Mon, 15 May 95 12:37:44 PDT Date: Mon, 15 May 95 12:37:44 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505151937.AA21168@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA15476; Mon, 15 May 95 12:34:04 PDT To: ibis@vhdl.org Subject: DAC placards Hey there, I have the IBIS SPOKEN HERE placards for DAC. Some people say they want them right away for other shows. OK. send me your address and I will send a maximum of 2 per company to anyone who wants them. People who want to pick them up in pristine condition at DAC can do that also. Let me know, jonp@qdt.com From mikep@efficient.com Mon May 15 15:54:06 1995 Return-Path: Received: from ns2.efficient.com ([198.211.94.10]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06278; Mon, 15 May 95 15:54:06 PDT Received: from efficient.com (mailhost.efficient.com [198.211.94.140]) by ns2.efficient.com (8.6.10/8.6.10) with SMTP id RAA23889 for ; Mon, 15 May 1995 17:57:29 -0500 Received: from manowar.efficient.com by efficient.com (4.1/SMI-4.1) id AA03733; Mon, 15 May 95 17:48:37 CDT Date: Mon, 15 May 95 17:48:37 CDT From: mikep@efficient.com (Mike Phillips) Message-Id: <9505151747.ZM3848@manowar> X-Mailer: Z-Mail (3.2.0 06sep94) To: ibis@vhdl.org Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii subscribe From fang@cadence.com Tue May 16 09:38:14 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22765; Tue, 16 May 95 09:38:14 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA03214 for ; Tue, 16 May 1995 09:32:23 -0700 Received: from cds9278.cadence.com(158.140.16.219) by mailgate.cadence.com via smap (V1.0mjr) id sma003200; Tue May 16 09:32:16 1995 Received: (from fang@localhost) by cds9278.Cadence.COM (8.6.8/8.6.8) id JAA02774 for ibis@vhdl.org; Tue, 16 May 1995 09:32:09 -0700 Date: Tue, 16 May 1995 09:32:09 -0700 From: Tze-Ting Fang Message-Id: <199505161632.JAA02774@cds9278.Cadence.COM> To: ibis@vhdl.org Subject: join Please add fang@cadence.com to your email ist. Thank you very much. Tze-Ting Fang From wolf_e@mucsun.sps.mot.com Tue May 16 09:40:27 1995 Return-Path: Received: from spsgate.sps.mot.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22790; Tue, 16 May 95 09:40:27 PDT Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA13626 for ibis@vhdl.org; Tue, 16 May 95 09:34:35 MST Received: from emailmesa by mogate (4.1/SMI-4.1/Email-2.0) id AA08311; Tue, 16 May 95 09:34:34 MST Received: from tarawa.suedsee by mucsun.suedsee (4.1/SMI-4.1) id AA29166; Tue, 16 May 95 18:38:44 +0200 Date: Tue, 16 May 95 18:38:44 +0200 From: wolf_e@mucsun.sps.mot.com (Wolfgang Eisenmann) Message-Id: <9505161638.AA29166@mucsun.suedsee> To: ibis@vhdl.org Subject: IBIS I wish to join the IBIS open forum. Regards, Wolfgang From heinz@live.engr.sgi.com Tue May 16 10:00:50 1995 Return-Path: Received: from sgi.sgi.com (SGI.COM) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22957; Tue, 16 May 95 10:00:50 PDT Received: from live.engr.sgi.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:ibis@vhdl.org> id JAA05868; Tue, 16 May 1995 09:54:57 -0700 Received: by live.engr.sgi.com (931110.SGI/940406.SGI.AUTO) for @sgi.sgi.com:ibis@vhdl.org id AA12358; Tue, 16 May 95 09:54:47 -0700 From: heinz@live.engr.sgi.com (Heinz Blennemann) Message-Id: <9505160954.ZM12356@live.engr.sgi.com> Date: Tue, 16 May 1995 09:54:47 -0700 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: ibis@vhdl.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Please add me to your subscription list. Thanks, Heinz -- ------------------------------------------------------------------------------- HEINZ BLENNEMANN Silicon Graphics heinz@sgi.com (415) 390-4236 ------------------------------------------------------------------------------- From hong@berlioz.nsc.com Tue May 16 10:06:00 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22982; Tue, 16 May 95 10:06:00 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA11391 for ibis@vhdl.org; Tue, 16 May 95 10:00:08 -0700 Received: from berlioz.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23871 for ibis@vhdl.org; Tue, 16 May 95 10:00:05 -0700 Received: from buckeye.nsc.com by berlioz.nsc.com (4.1/SMI-4.1) id AA08400; Tue, 16 May 95 09:56:56 PDT Date: Tue, 16 May 95 09:56:56 PDT From: hong@berlioz.nsc.com (Hong You) Message-Id: <9505161656.AA08400@berlioz.nsc.com> To: ibis@vhdl.org Please include me in your mailing list. Thanks. Hong You hong@berlioz.nsc.com From heinz@live.engr.sgi.com Tue May 16 10:29:11 1995 Return-Path: Received: from xr1.atlas.fr by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23096; Tue, 16 May 95 10:29:11 PDT X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 16 May 1995 19:22:37 +0200 X400-Received: by mta xr1.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 16 May 1995 19:22:37 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Tue, 16 May 1995 19:21:58 +0200 X400-Received: by /PRMD=THOMSON/ADMD=ATLAS/C=FR/; Relayed; Tue, 16 May 1995 18:24:19 +0200 Date: Tue, 16 May 1995 18:24:19 +0200 X400-Originator: heinz@live.engr.sgi.com X400-Recipients: Admin@SCTF.thomson.fr, Admin@SCTF.thomson.fr, ibis@vhdl.org X400-Mts-Identifier: [/PRMD=THOMSON/ADMD=ATLAS/C=FR/;950516162419] X400-Content-Type: P2-1984 (2) Content-Identifier: CSI NC V3.0 Alternate-Recipient: Allowed From: " (Heinz Blennemann)" Message-Id: <"00016410.MAI*/RFC-822=heinz(a)live.engr.sgi.com/PRMD=INTERNET/ADMD=ATLAS/C=FR/"@MHS> To: "P=INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=ibis(a)vhdl.org" , "Admin, * *." , "Admin, * *." Subject: subscribe ------------------------------ Start of body part 1 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 ------------------------------ Start of body part 2 Attached Files: BDY71.TXT 43 octets BDY72.TXT 317 octets ------------------------------ Start of body part 3 Attached Files: BDY63.TXT 317 octets ------------------------------ Start of body part 4 Please add me to your subscription list. Thanks, Heinz -- ------------------------------------------------------------------------------- HEINZ BLENNEMANN Silicon Graphics heinz@sgi.com (415) 390-4236 ------------------------------------------------------------------------------- ------------------------------ End of body part 4 From ventham@quantic.mb.ca Tue May 16 14:00:15 1995 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24683; Tue, 16 May 95 14:00:15 PDT Received: by access.mbnet.mb.ca with UUCP id AA11604 (5.67b/IDA-1.4.4 for ibis@vhdl.org); Tue, 16 May 1995 15:54:18 -0500 Received: by quantic.mb.ca (4.1/SMI-4.1) id AA13378; Tue, 16 May 95 15:09:51 CDT From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9505162009.AA13378@quantic.mb.ca> Subject: Model list - current To: ibis@vhdl.org (IBIS Forum) Date: Tue, 16 May 95 15:09:49 CDT X-Mailer: ELM [version 2.3 PL11] I thought people might be interested in the current list of models availably via ftp from vhdl.org in the pub/ibis/models directory. This saves everyone having to look it it up every time. I would suggest that this list be sent out once a month so users will know when to download any new or modified. It is also obvious from this we have a long way to go with providing sufficient models for a user to analyse a typical board using just IBIS models for the IC's. This list was obtained using the ftp command "ls -lR model_list" to create a local file called model_list. total 11 -rw-rw-r-- 1 165 494 Feb 21 19:40 00readme -rw-rw-r-- 1 165 510 Jan 5 10:07 DISCLAIM.TXT -rw-r--r-- 1 root 199 May 9 04:00 Index -rw-rw-r-- 1 165 5612 Apr 24 09:41 PROTOCOL.TXT drwxrwxr-x 5 138 512 May 9 04:00 intel drwxrwxr-x 4 165 512 Apr 19 04:00 national intel: total 6 -rw-rw-r-- 1 138 1532 Apr 5 22:55 00readme -rw-r--r-- 1 root 156 May 9 04:00 Index drwxrwxr-x 2 138 512 May 9 04:00 chipset drwxrwxr-x 2 138 512 May 8 08:22 cpu drwxr-xr-x 2 165 512 Feb 15 04:00 pentium intel/chipset: total 1625 -rw-r--r-- 1 165 1305 May 8 08:19 00readme -rw-r--r-- 1 165 87188 Jan 5 11:12 82374eb.ibs -rw-r--r-- 1 165 149023 May 8 08:19 82374sb.ibs -rw-r--r-- 1 165 64359 May 8 08:19 82375eb.ibs -rw-r--r-- 1 165 104839 May 8 08:19 82375sb.ibs -rw-r--r-- 1 165 48916 May 8 08:19 82378ib.ibs -rw-r--r-- 1 165 136357 May 8 08:19 82378zb.ibs -rw-r--r-- 1 165 49580 May 8 08:19 82423tx.ibs -rw-r--r-- 1 165 105692 May 8 08:19 82424zx.ibs -rw-r--r-- 1 165 158549 May 8 08:19 82425ex.ibs -rw-r--r-- 1 165 139354 May 8 08:19 82426ex.ibs -rw-r--r-- 1 165 63569 May 8 08:19 82433lx.ibs -rw-r--r-- 1 165 130043 May 8 08:19 82433nx.ibs -rw-r--r-- 1 165 108511 May 8 08:19 82434lx.ibs -rw-r--r-- 1 165 204433 May 8 08:19 82434nx.ibs -rw-r--r-- 1 root 562 May 9 04:00 Index -rw-r--r-- 1 165 249 May 8 08:19 tmp intel/cpu: total 31 -rw-rw-r-- 1 138 1282 Feb 7 19:01 00readme -rw-r--r-- 1 root 132 Feb 8 04:00 Index -rw-r--r-- 1 165 28228 Jan 5 12:08 dx4pga.ibs intel/pentium: total 77 -rw-r--r-- 1 root 85 Feb 15 04:00 Index -rw-rw-r-- 1 165 33967 Feb 14 12:31 pp100sem.ibs -rw-rw-r-- 1 165 42894 Feb 14 12:31 pp66sem.ibs national: total 6 -rw-rw-r-- 1 165 2980 Apr 18 08:26 00readme -rw-r--r-- 1 root 132 Apr 19 04:00 Index drwxr-xr-x 2 165 1024 Apr 19 04:00 cgs drwxr-xr-x 2 165 512 Mar 27 08:44 interface national/cgs: total 2272 -rw-rw-r-- 1 165 58462 Apr 13 11:19 2534v.ibs -rw-rw-r-- 1 165 42354 Apr 13 11:20 2535v.ibs -rw-rw-r-- 1 165 42263 Apr 13 11:20 2536v.ibs -rw-rw-r-- 1 165 58568 Apr 18 08:23 2537v.ibs -rw-rw-r-- 1 165 32720 Mar 23 03:52 700v.ibs -rw-rw-r-- 1 165 32794 Apr 13 11:21 701v.ibs -rw-r--r-- 1 root 1123 Apr 19 04:00 Index -rw-rw-r-- 1 165 21601 Apr 13 11:21 b2525m.ibs -rw-rw-r-- 1 165 21603 Apr 13 11:21 b2525n.ibs -rw-rw-r-- 1 165 121460 Apr 13 11:23 b2528m.ibs -rw-rw-r-- 1 165 121431 Apr 13 11:25 b2528n.ibs -rw-rw-r-- 1 165 121792 Apr 13 11:26 b2528v.ibs -rw-rw-r-- 1 165 134193 Apr 13 11:27 b2529v.ibs -rw-rw-r-- 1 165 111177 Apr 13 11:29 b303m.ibs -rw-rw-r-- 1 165 111178 Apr 13 11:31 b303n.ibs -rw-rw-r-- 1 165 111609 Apr 13 11:33 b303v.ibs -rw-rw-r-- 1 165 111253 Apr 13 11:36 b304m.ibs -rw-rw-r-- 1 165 111248 Apr 13 11:37 b304n.ibs -rw-rw-r-- 1 165 111617 Apr 13 11:39 b304v.ibs -rw-rw-r-- 1 165 111234 Apr 13 11:41 b305m.ibs -rw-rw-r-- 1 165 111231 Apr 13 11:42 b305n.ibs -rw-rw-r-- 1 165 111601 Apr 13 11:44 b305v.ibs -rw-rw-r-- 1 165 16487 Apr 13 11:44 c2525m.ibs -rw-rw-r-- 1 165 16485 Apr 13 11:45 c2525n.ibs -rw-rw-r-- 1 165 24492 Apr 13 11:45 c2526m.ibs -rw-rw-r-- 1 165 24500 Apr 13 11:45 c2526n.ibs -rw-rw-r-- 1 165 49161 Apr 13 11:46 ct2524m.ibs -rw-rw-r-- 1 165 49157 Apr 13 11:47 ct2524n.ibs -rw-rw-r-- 1 165 16419 Apr 13 11:47 ct2525m.ibs -rw-rw-r-- 1 165 16420 Apr 13 11:48 ct2525n.ibs -rw-rw-r-- 1 165 24497 Apr 13 11:48 ct2526m.ibs -rw-rw-r-- 1 165 24521 Apr 13 11:49 ct2526n.ibs -rw-rw-r-- 1 165 16808 Apr 13 11:49 ct2527v.ibs -rw-rw-r-- 1 165 37748 Apr 13 11:49 lct2524m.ibs -rw-rw-r-- 1 165 37750 Apr 13 11:49 lct2524n.ibs national/interface: total 43 -rw-r--r-- 1 root 143 Mar 23 04:00 Index -rw-rw-r-- 1 165 21946 Feb 21 19:25 ds26c31.ibs -rw-rw-r-- 1 165 19653 Feb 21 19:38 ds26c32.ibs Regards Mike +======================================================================+ | Mike Ventham - Vice President Engineering, Quantic Laboratories Inc, | | 12th Floor, 191 Lombard Ave, Winnipeg, Manitoba, Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email: ventham@quantic.mb.ca | +======================================================================+ From myl@awam.com.au Tue May 16 21:41:40 1995 Return-Path: Received: from warrane.connect.com.au by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00259; Tue, 16 May 95 21:41:40 PDT Received: (from root@localhost) by warrane.connect.com.au with UUCP id OAA03646 (8.6.11/IDA-1.6 for ibis@vhdl.org); Wed, 17 May 1995 14:35:45 +1000 Received: from sun2.sunnet (sun2) by sun1.awam.com.au with SMTP id AA28427 (5.67b/IDA-1.5 for ); Wed, 17 May 1995 13:21:56 +1000 Date: Wed, 17 May 1995 13:21:56 +1000 From: "Raymond Leung (AWA MicroElectronics)" Message-Id: <199505170321.AA28427@sun1.awam.com.au> To: ibis@vhdl.org Subject: subscribe Hi, Please add my name and address on the mailing list of the ibis discussion forum. Thanks very much. Raymond Leung AWA Microelectronics email: myl@awam.com.au From dmccal@teleport.com Tue May 16 23:41:49 1995 Return-Path: Received: from desiree.teleport.com ([192.108.254.11]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00927; Tue, 16 May 95 23:41:49 PDT Received: from ip-pdx2-23.teleport.com (ip-pdx2-23.teleport.com [204.119.60.55]) by desiree.teleport.com (8.6.10/8.6.9) with SMTP id XAA19036 for ; Tue, 16 May 1995 23:35:24 -0700 Date: Tue, 16 May 1995 23:35:24 -0700 Message-Id: <199505170635.XAA19036@desiree.teleport.com> X-Sender: dmccal@mail.teleport.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: dmccal@teleport.com (Dennis McCal) Subject: IBIS open forum X-Mailer: I would like to be added to the IBIS open forum mailing list. Thankyou. Sincerely, Dennis McCal From nihat@mucsun.sps.mot.com Wed May 17 00:41:57 1995 Return-Path: Received: from spsgate.sps.mot.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01346; Wed, 17 May 95 00:41:57 PDT Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA24012 for ibis@vhdl.org; Wed, 17 May 95 00:36:05 MST Received: from emailmesa by mogate (4.1/SMI-4.1/Email-2.0) id AA21557; Wed, 17 May 95 00:36:05 MST Received: from nihoa.suedsee by mucsun.suedsee (4.1/SMI-4.1) id AA00827; Wed, 17 May 95 09:40:17 +0200 Date: Wed, 17 May 95 09:40:17 +0200 From: nihat@mucsun.sps.mot.com (Nihat Cabuk) Message-Id: <9505170740.AA00827@mucsun.suedsee> To: ibis@vhdl.org Subject: Subscribe Hi, I would like to join the IBIS forum. Thanks, Nihat _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ _/ Nihat Çabuk _/ _/ _/ Sen. Staff Eng. _/ Tel.: +49 89 92 103 399 _/ _/ Motorola GmbH _/ Fax.: +49 89 92 103 150 _/ _/ ASIC _/ _/ _/ Schatzbogen 7 _/ e-mail: nihat@mucsun.sps.mot.com _/ _/ 81829 Muenchen _/ or ttg538@email.sps.mot.com _/ _/ Germany _/ _/ _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From rcline@asic.sc.ti.com Wed May 17 06:38:23 1995 Return-Path: Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08853; Wed, 17 May 95 06:38:23 PDT Received: from kadet.asic.sc.ti.com ([156.117.203.118]) by gate.ti.com (8.6.10/) with ESMTP id IAA29980 for ; Wed, 17 May 1995 08:32:31 -0500 Received: from sho.asic.sc.ti.com (sho.asic.sc.ti.com [156.117.203.148]) by kadet.asic.sc.ti.com (8.6.7/8.6.6) with ESMTP id IAA08310; Wed, 17 May 1995 08:32:57 -0500 Received: from localhost (rcline@localhost) by sho.asic.sc.ti.com (8.6.4/8.6.4) id IAA13844; Wed, 17 May 1995 08:32:56 -0500 Date: Wed, 17 May 1995 08:32:56 -0500 From: Roger Cline Message-Id: <199505171332.IAA13844@sho.asic.sc.ti.com> To: ibis@vhdl.org Subject: IBIS list Cc: rcline@asic.sc.ti.com Please add me to the IBIS list. Thanks. Roger A. Cline Senior Member, Technical Staff Application Specific Products Semiconductor Group Texas Instruments, Inc. From Derrick_Duehren@ccm2.jf.intel.com Wed May 17 11:30:09 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11031; Wed, 17 May 95 11:30:09 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sBnlT-000UkCC; Wed, 17 May 95 11:24 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sBnlT-000twVC; Wed, 17 May 95 11:24 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 17 May 95 11:24:11 PDT Date: Wed, 17 May 95 11:22:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: Heinz subscribe message repeat problem FYI, I am working with Silicon Graphics to fix this endlessly repeating subscribe message. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 264-4299, Fax (503) 264-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 From hoang@msai.com Wed May 17 13:51:05 1995 Return-Path: Received: from reggae.ncren.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11972; Wed, 17 May 95 13:51:05 PDT Received: from msaifw.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA13947; Wed, 17 May 95 16:44:46 -0400 Received: from sbedrock.msai.com (shared) by msaifw.msai.com (4.1/fw-version 2.7) id AA14521; Wed, 17 May 95 16:34:54 EDT Received: from mercury.msaiasic by sbedrock.msai.com (4.1/mh-version 2.4) id AA27657; Wed, 17 May 95 16:34:53 EDT Date: Wed, 17 May 95 16:34:53 EDT From: hoang@msai.com (Hoang Nguyen) Message-Id: <9505172034.AA27657@sbedrock.msai.com> To: ibis@vhdl.org Subject: s2ibis - help! Hello all, I'm trying to run s2ibis program, using the sample file "tryme". I got the following messages saying that spice jobs aborted. We have Spice3, and I have it in my path. Would you suggest anything else. Thanks a lot. Hoang Nguyen Mitsubishi Semiconductor America, Inc. 919-479-3479 hoang@msai.com From hoang@msai.com Wed May 17 15:18:54 1995 Return-Path: Received: from reggae.ncren.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12607; Wed, 17 May 95 15:18:54 PDT Received: from msaifw.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA18822; Wed, 17 May 95 18:11:28 -0400 Received: from sbedrock.msai.com (shared) by msaifw.msai.com (4.1/fw-version 2.7) id AA15995; Wed, 17 May 95 18:00:35 EDT Received: from mercury.msaiasic by sbedrock.msai.com (4.1/mh-version 2.4) id AA28676; Wed, 17 May 95 18:00:34 EDT Date: Wed, 17 May 95 18:00:34 EDT From: hoang@msai.com (Hoang Nguyen) Message-Id: <9505172200.AA28676@sbedrock.msai.com> To: ibis@vhdl.org Subject: s2ibis - help! re-sent Hello all, I'm trying to run s2ibis program, using the sample file "tryme". I got the following messages saying that spice jobs aborted. We have Spice3, and I have it in my path. Would you suggest anything else. Thanks a lot. Hoang Nguyen Mitsubishi Semiconductor America, Inc. 919-479-3479 hoang@msai.com ---------Begin included text---------------- /home/memhdl/IBIS/s2ibis/bin/s2ibis.sparc tryme tryme.ibis s2ibis: Version 1.0 North Carolina State University s2ibis: Using input file named tryme s2ibis: Using output file named tryme.ibis s2ibis: Specified simulator: Berkeley SPICE 3. s2ibis: SPICE job pdtthree.spi aborted. Output in pdtthree.out. s2ibis: SPICE job pdnthree.spi aborted. Output in pdnthree.out. s2ibis: SPICE job pdxthree.spi aborted. Output in pdxthree.out. s2ibis: SPICE job putthree.spi aborted. Output in putthree.out. s2ibis: SPICE job punthree.spi aborted. Output in punthree.out. s2ibis: SPICE job puxthree.spi aborted. Output in puxthree.out. s2ibis: SPICE job rutthree.spi aborted. Output in rutthree.out. s2ibis: Please Note: [Ramp] table will not meet IBIS specification. s2ibis: SPICE job runthree.spi aborted. Output in runthree.out. s2ibis: SPICE job ruxthree.spi aborted. Output in ruxthree.out. s2ibis: SPICE job rdtthree.spi aborted. Output in rdtthree.out. s2ibis: Please Note: [Ramp] table will not meet IBIS specification. s2ibis: SPICE job rdnthree.spi aborted. Output in rdnthree.out. s2ibis: SPICE job rdxthree.spi aborted. Output in rdxthree.out. s2ibis: SPICE job gctfour.spi aborted. Output in gctfour.out. s2ibis: SPICE job gcnfour.spi aborted. Output in gcnfour.out. s2ibis: SPICE job gcxfour.spi aborted. Output in gcxfour.out. s2ibis: SPICE job pctfour.spi aborted. Output in pctfour.out. --------------End included text------------------ ----- End Included Message ----- From Derrick_Duehren@ccm2.jf.intel.com Wed May 17 20:36:55 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14580; Wed, 17 May 95 20:36:55 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sBwIh-000UjNC; Wed, 17 May 95 20:31 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sBwIg-000twVC; Wed, 17 May 95 20:31 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 17 May 95 20:31:02 PDT Date: Wed, 17 May 95 20:28:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: repeated message problem IBISians, Sorry about the many messages that have been sent in the last 24 hours! Derrick Duehren, the Forum secretary, myself, and many others here at Silicon Graphics have been looking into what is causing the repeated-message problem. The initial message that caused this problem is attached below. I incorrectly sent it to the ibis forum, whereas I should have sent it to ibis-request@vhdl.org. However, this does not explain why the message keeps getting repeated. As soon as I find the cause of the problem, I will let you know, so this problem will not continue or re-occur! Thanks for your understanding, Heinz ATTACHMENT: ORIGINAL NOTE: =============================================================================== To: ibis@vhdl.org Please add me to your subscription list. Thanks, Heinz -- ------------------------------------------------------------------------------- HEINZ BLENNEMANN Silicon Graphics heinz@sgi.com (415) 390-4236 ------------------------------------------------------------------------------- =============================================================================== -- ------------------------------------------------------------------------------- HEINZ BLENNEMANN Silicon Graphics heinz@sgi.com (415) 390-4236 ------------------------------------------------------------------------------- From Will_Hobbs@ccm2.jf.intel.com Thu May 18 16:44:00 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27227; Thu, 18 May 95 16:44:00 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sCF8m-000UkuC; Thu, 18 May 95 16:38 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sCF8l-000twYC; Thu, 18 May 95 16:38 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Thu, 18 May 95 16:38:03 PDT Date: Thu, 18 May 95 16:36:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Subject: BIRD 28 -- enhanced package models ---------------------------- Forwarded with Changes --------------------------- From: Stephen Peters at JFCCM3 Date: 5/18/95 12:38PM To: Will Hobbs at JFCCM2 Subject: BIRD XXX -- enhanced package models ------------------------------------------------------------------------------- Text item: Buffer Issue Resolution Document (BIRD) BIRD ID#: 28 ISSUE TITLE: Enhancement To The Package Model (.pak file) Specification REQUESTER: Stephen Peters DATE SUBMITTED: May 18, 1995 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current package model specification describes each pin on a package using lumped L/R/C parameters. Coupling between pins also assumes lumped electrical parameters. However, these description are inadequate when the electrical length of the package elements are greater than ~1/6 of the I/O buffers' rise time. This bird enhances the package description by allowing package elements to be described in terms of length and L, R and C per unit length; i.e. a transmission line representation. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Following are the specific changes to the specification. 1. The keywords [Number of Sections] and [Unit Length] are added to the specification after the Description keyword |============================================================================== | Keyword: [Number of Sections] | Required: No |Description: Defines the maximum number of sections that make up a 'package | stub'. A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. |Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. |----------------------------------------------------------------------------- [Number of Sections] 3 | |============================================================================= | Keyword: [Unit Length] | Required: Yes, if [Number of Sections] keyword is used |Description: Defines the units used for the Len:, L:, C:, and R: subparameters | of the [Pin Number] keyword. |Usage Rules: Permissible arguments are 'in' (inches), 'cm' (centimeters), | and 'ft' (feet). This keyword, if used, must appear in the | specification before the [Pin Numbers] keyword. ------------------------------------------------------------------------------ [Unit Length] in | 2. The current [Pin Numbers] keyword description is replaced by the following: |============================================================================= | Keyword: [Pin Numbers] | Required: Yes |Description: Tells the parser the set of names that are used for the package | pins and also defines pin ordering. If the [Number of Sections] | keyword is present it also lists the elements for each section | of a pin's die to pin connection. | Sub-Params: Len:, L:, R:, C:, Matrix |Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number of Pins] keyword). Pin names | can not exceed 5 characters in length. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." If the [Number of Sections] keyword is used then | each pin names must be followed by one or more of the legal | subparameter combinations listed below. If the [Number of | Sections] keyword is not present then subparameter usage is | NOT allowed. | | Subparameters: | The subparameters specify the length, inductance, capacitance | and resistance of each section for each stub on a package. If | a particular section exhibits coupling to an adjacent (same | numbered) section of a different package stub then the Matrix | subparameter is used. These subparameters are defined as | follows: | Len: The physical length of a package stub section. Length | is in the units specified by the [Unit Length] keyword. | L: The inductance of a package stub section, in terms of | 'inductance/unit length'. For example, if [Unit Length] | was defined as in, then L: 2.5n would be 2.5nH/in. | C: The capacitance of a package stub section, in terms of | capacitance per unit length. | R: The DC (ohmic) resistance of a package stub section, in | terms of ohms per unit length. | Matrix Use of this subparameter means that this section's | electrical parameters are described by use of a | matrix description. The matrix is included between | the [Model Data]/[End Model Data] keyword pairs as | described below. | | Specifying a length or L/R/C value of zero is allowed. If | Len:0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specifed, then | the total L/R/C for a section is calculated by multiplying | the value of the Len: subparameter by the value of the L:, | R: or C: subparameter. | | Using The Subparameters to Describe Package Stub Sections: | Each section description of a package stub is separated | by a comma. All package stub descriptions must contain the same | number of sections however, a particular section description | can contain no data (i.e. the description is a space | delimited by a pair of commas. See the example below). | The left most section in a package stub description is | defined as section 1. | | The legal subparameter combinations are | A) A pair of commas separated by whitespace. This option | is used for describing a package stub that does not contain | (or does not need to be described using) the same number of | sections as the others. | B) Len: and a single 'Matrix' subparameter. The Len: sub- | parameter specifies the length of that section while the Matrix | subparameter indicates that the electrical characteristics | of that sections are described using the matrix description | ([Model Data]/[End Model Data] keyword pair). The matrix | description must include both the 'self' inductance/capacitance/ | resistance (as required) of a section as well as the mutual | coupling terms. If one section is described using the the Matrix | subparameter then the corresponding (same numbered) sections | on ALL other package stubs must use the Matrix subparameter. | C) Len:, L: and C: subparameters (with an optional R: | subparameter). This combination is for modeling a section as a | transmission line. | D) No Len: parameters and any combination of L:, R: and C: | sub-parameters. This combination is for modeling a section | as lumped elements. | | Line Continuation: | If a package stub description extends beyond the 80 character | limit, end the line with a backslash character ("\") and | continue with the description on the next line. | | In the example below pin A1 uses a Len: of zero for the first | section (describing a lumped 1.2nH inductor). Pin A2 also | describes the first section as a 1.2nH inductor. Pin A3 is | an example of the comma notation for leaving a section | unspecified while pin A4 shows a line continuation. All pins | use the matrix subparameter for section 2. |----------------------------------------------------------------------------- [Pin Number] A1 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 A2 L:1.2n, Len:0.7 Matrix, Len:0.47 L: 6.21n C:3.34p R:0.01 A3 , , Len:1.3 Matrix, , A4 Len:0 L:1.2n, Len:1.0 Matrix, Len:0.47 L: 8.35n \ C:3.34p R:0.01 A5 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 | . | . | . A10 Lne:0.1 1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:2.2p R:0.01 3. The current [Model Data] and [End Model Data] keyword descriptions are | replaced by the following |============================================================================= | Keyword: [Model Data] | Required: Yes, if any of the sections in a package stub description | use the 'Matrix' subparameter or if the [Number of Sections] | keyword is not used. |Description: Indicates the beginning of the matrix data used to describe | a package stub section. |Usage Rules: If the [Number of Sections] keyword is used then the [Model | Data] keyword must be followed by the word 'section' and the | section number the matrix data applies to. There must be a | [Model Data] keyword for every section in a package stub | description that uses the Matrix keyword. Note that if the | [Number of Sections] keyword is used but no package stub | sections use the Matrix subparameter then the [Model Data] | and [End Model Data] keyword are not required. |----------------------------------------------------------------------------- [Model Data] section 2 | |============================================================================= | Keyword: [End Model Data] | Required: Yes, if the [Model Data] keyword is present. |Description: Indicates the end of the matrix data used to describe | a package stub section. |Usage Rules: In between the [Model Data] and [End Model Data] keywords is | the matrix data itself. The data is a set of three matrices: | the resistance (R) , inductance (L) , and capacitance (C), | matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords to mark the | beginning of each matrix. As with the [Model Data] keyword | the [End Model Data] keyword is followed by the word 'section' | and the section number. |----------------------------------------------------------------------------- [End Model Data] section 2 | |============================================================================= 3. The following paragraph is added to the section entitled "RLC MATRIX NOTES" (place after the first paragraph). There are two different ways to extract the coefficients that are reported in the the capacitance and inductance matrices. For the purposes of this specification, the coefficients reported in the capacitance matrices shall be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. The Maxwell capacitance Kij is defined as the charge induced on conductor "j" when conductor "i" is held at 1 volt and all other conductors are held at zero volts. Note that Kij ( when i /= j) will be a negative number. By convention, drop the negative sign before entering this value into the matrix. Likewise, for the inductance matrix the coefficients for Lij are defended as the voltage induced on conductor "j" when conductor "i"'s current is changed by 1amp/sec and all other conductors have no current change. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This bird proposes three fundamental enhancement to the current package specification. They are: 1. The connection between the pad on the die and the external package pin (referred to in this bird as the package 'stub') is now considered to be composed of a number of elements, or sections, in series. 2. Each of these elements can have a non-zero length, thus enabling one to model each section as having a time delay -- i.e. as a transmission line 3. The current matrix description can now be applied to individual section of the package stub, and there can be more than one [Model data] and [End Model Data] keyword pair per package model description. The purpose of this bird is to enable IBIS to describe the connection between the pad and pin of a package in greater detail. Specifically, with this bird one will now be able to model the effect of long package traces and also the effects when one package trace couples with another. The author has found that this level of detail is vital for accurately modeling the effects of large PGA packages and/or packages that have no ground plane and exhibit coupling between package traces. With these enhancement, the .pkg file should be able to accurately describe the great majority of DIP/SOIC/PGA/BGA/PQFP packages. It is NOT the purpose of this bird to describe a generalized topology suitable for describing MCM and SIM modules. In addition to the enhancements required to better describe packages, the capacitance and inductance coefficients used for the matrix data elements are defined. I believe that even if this bird is not accepted, this portion should be adopted in order to make the current matrix format usable. ANY OTHER BACKGROUND INFORMATION: For a much more detailed description of Maxwell capacitances refer to the paper by Robert Canright entitled "Capacitance: Relationships and Measurements" available from the IEEE (Thanks to Bob Ward at Texas Instruments for supplying me with this paper). I would also like to thanks Samie Samaan at Intel for his review of this bird and for bringing the whole issue of matrix data coefficients to my attention. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: Stephen Peters Date: Thu, 18 May 1995 12:38:24 -0700 Subject: BIRD XXX -- enhanced package models To: Will_Hobbs@ccm2.jf.intel.com Message-Id: <9505181938.AA00856@xtg801.intel.com> Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 18 May 95 12:38:2 5 PDT Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 18 May 95 12:38:25 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sCBOw-000twVC; Thu, 18 May 95 12:38 PDT From mellitz@eagle.ColumbiaSC.NCR.COM Fri May 19 04:58:09 1995 Return-Path: Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05808; Fri, 19 May 95 04:58:09 PDT From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Message-Id: <9505190757.ZM26174@eagle> Date: Fri, 19 May 1995 07:57:44 -0400 In-Reply-To: Will Hobbs "BIRD 28 -- enhanced package models" (May 18, 4:36pm) References: X-Mailer: Z-Mail (2.1.4 02apr93) To: Will Hobbs , ibis@vhdl.org Subject: Re: BIRD 28 -- enhanced package models Content-Type: text Content-Length: 552 All, In lieu of large packages this sound like a needed feature. Does anyone know if any commercial tools will or are planning to support these enhanced package models? --------------------------------------------------------------------- Richard Mellitz | AT&T | Global Information Solutions | richard.mellitz@columbiasc.attgis.com 3325 Platt Spring Road | Phone: (803)-939-6240 West Columbia, SC 29170 | Fax: (803)-939-7317 --------------------------------------------------------------------- From idpt31@tpts1.seed.net.tw Fri May 19 05:03:06 1995 Return-Path: Received: from tpts1.seed.net.tw by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05892; Fri, 19 May 95 05:03:06 PDT Received: from idpt31 ([192.72.61.48]) by tpts1.seed.net.tw (4.1/SMI-4.1) id AA22259; Fri, 19 May 95 20:01:03 CST Date: Fri, 19 May 95 20:01:01 CST Message-Id: <9505191201.AA22259@tpts1.seed.net.tw> X-Sender: idpt31@tpts1.seed.net.tw (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: idpt31@tpts1.seed.net.tw (Maojet Technology Corp.) Subject: The specifications of IBIS We like to study the format of IBIS to create model for signal integrity tools. Could you plese send whole set of IBIS document to us by email ? Best Regards, Ted Tsai Maojet Technology Corp. Tel: 886-2-567-7643 Fax: 886-2-561-0756 Email: idpt31@tpts1.seed.net.tw Ted Tsai Maojet Tech Corp. Tel : 886-2-5677643 Fax : 886-2-5610756 From jonp@qdt.com Fri May 19 08:17:08 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07083; Fri, 19 May 95 08:17:08 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyqki12083; Fri, 19 May 1995 11:11:15 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 19 May 1995 11:11:15 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00354; Fri, 19 May 95 07:29:02 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA12538; Fri, 19 May 95 07:35:37 PDT Date: Fri, 19 May 95 07:35:37 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505191435.AA12538@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA21143; Fri, 19 May 95 07:31:53 PDT To: ibis@vhdl.org Subject: BOF pres at DAC IBIS type persons, I am working on the 30 minute presentation for the BOF session at DAC. If anyone has any specific presentation materials that they would like me to include please send them to me (prefreably in some WINDOWS readable format). Also, I would like to have a slide that has everyones LOGO on it (perhaps entitled, "Look who's doin the bird"...... not). If you wish to be included on this slide please send me your LOGO via: 1) email with uuencode pcx bmp tiff or targa files, color is good. 2) DOS floppy with pcx bmp tiff or targa files, color is good. or 3) Scannable Quality LOGO proof sheet via physical mail. (color is still good) TIME IS OF THE ESSENCE !! The presentation will be color overheads formatted with some sort of IBIS like logo border. My plan is to only mention any participant companies on the one logo collage slide. Be aware that if you send me your logo you are preporting some sort of IBIS support. thanks guys, that is all. jon From uunet!qdt.com!jonp@uunet.uu.net Fri May 19 10:19:13 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08150; Fri, 19 May 95 10:19:13 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyqkq15300; Fri, 19 May 1995 13:11:41 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 19 May 1995 13:11:42 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00431; Fri, 19 May 95 08:08:14 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA12643; Fri, 19 May 95 08:14:50 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyqki12074; Fri, 19 May 1995 11:11:14 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 19 May 1995 11:11:14 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00343; Fri, 19 May 95 07:21:06 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA12530; Fri, 19 May 95 07:27:41 PDT Date: Fri, 19 May 95 07:27:41 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505191427.AA12530@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA21142; Fri, 19 May 95 07:23:57 PDT To: uunet!uunet!ccm2.jf.intel.com!Will_Hobbs@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Will Hobbs's message of Thu, 18 May 95 16:36:00 PDT Subject: Comments on BIRD 28 -- enhanced package models Stephen, It is unclear to me how one would specify more than one matrix. Are you supposed to be able to? Perhaps a more detailed example? jon From uunet!qdt.com!jonp@uunet.uu.net Fri May 19 10:47:53 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08355; Fri, 19 May 95 10:47:53 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQyqks23542; Fri, 19 May 1995 13:41:58 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 19 May 1995 13:41:58 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00629; Fri, 19 May 95 10:10:40 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA13242; Fri, 19 May 95 10:17:15 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyqkq15360; Fri, 19 May 1995 13:11:51 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 19 May 1995 13:11:52 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00578; Fri, 19 May 95 10:00:25 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA13126; Fri, 19 May 95 10:07:01 PDT Date: Fri, 19 May 95 10:07:01 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505191707.AA13126@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA21372; Fri, 19 May 95 10:03:16 PDT To: uunet!uunet!eagle.ColumbiaSC.NCR.COM!mellitz@uunet.uu.net Cc: uunet!uunet!ccm2.jf.intel.com!Will_Hobbs@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: uunet!eagle.ColumbiaSC.NCR.COM!mellitz's message of Fri, 19 May 1995 07:57:44 -0400 <9505190757.ZM26174@eagle> Subject: BIRD 28 -- enhanced package models I think that most commercial simulators do (and have) supported this type of data but since it hasn't been available it has been a moot point. jon From speters@ichips.intel.com Fri May 19 12:47:44 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09989; Fri, 19 May 95 12:47:44 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 19 May 95 12:41:51 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 19 May 95 12:41:45 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 19 May 95 12:41:44 PDT Message-Id: <9505191941.AA04415@xtg801.intel.com> To: ibis@vhdl.org Cc: Samie_Samaan@ccm2.jf.intel.com Subject: Comments on BIRD 28 Date: Fri, 19 May 1995 12:41:43 -0700 From: Stephen Peters Hello Fellow IBISans: On 5/19 Jon Powell wrote >Stephen, >It is unclear to me how one would specify more than one matrix. >Are you supposed to be able to? >Perhaps a more detailed example? > >jon If the question is 'can more than one section in a package stub description use the matrix subparameter', the answer is yes. For example, if the pin statement is as follows: [Pin Number] A1 L: 1.0n, Len: 0.5 Matrix, Len: 0.7 Matrix, C: 0.5pf . . . A5 L: 1.0n, Len: 0.4 Matrix, Len: 0.6 Matrix, C: 0.5pf . . . You would use the [Model Data]/[End Model Data] keywords as shown to denote the two matrices. [Model Data] section 2 . . . [End Model Data] section 2 [Model Data] section 3 . . . [End Model Data] section 3 If one wants to group a section from a specific group of pins (package stubs) into their own matrix seperate from others, it is possible; it's just not done explicitly in the spec. The existing matrix definition does contain all the data needed to create 'sub-matrices' (is that the correct word?) for specific groups of pins. In one of my previous e-mails I gave the following example in which pins 1 and 2 couple, 5, 6 and 7 couple, and 9 and 10 couple. ____ |-------- Pin1 sig1 |-------- Pin2 sig2 |-------- Pin3 GND (sorry, don't know what happened to pin 4) |-------- Pin5 sig5 |-------- Pin6 sig6 |-------- Pin7 sig7 |-------- Pin8 PWR |-------- Pin9 sig9 |-------- Pin10, sig10 ____| By using the sparce matrix description one can specify explicitly which pins effect the other. From the data in that section's matrix a user can create individual matrices containing pins 1/2, 5/6/7, and pins 9/10. For Jon's example where each pin on a package couples to to the two adjacent pins only, the banded matrix description fits the data quite nicely. I hope this answers the question Best Regards, Stephen From Derrick_Duehren@ccm2.jf.intel.com Fri May 19 13:46:57 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10418; Fri, 19 May 95 13:46:57 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sCYr2-000UkuC; Fri, 19 May 95 13:41 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sCYr1-000twWC; Fri, 19 May 95 13:41 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Fri, 19 May 95 13:41:03 PDT Date: Fri, 19 May 95 13:37:00 PDT From: Derrick Duehren Message-Id: To: idpt31@tpts1.seed.net.tw_at_smtpgate@ccm.hf.intel.com Cc: IBIS@vhdl.org Subject: Re: The specifications of IBIS Text item: >We like to study the format of IBIS to create model for signal integrity tools. >Could you plese send whole set of IBIS document to us by email ? I/O Buffer Information Specification (IBIS) Open Forum Electronic Industry Association/Electronic Information Group An Introduction (as of 4/95) Thank you for your interest in IBIS. There is an IBIS overview (~22 pages long, with waveforms, etc.) that discusses IBIS in detail. It is available electronically over Internet, as described below. If you cannot access the information over the Internet, send me your mail (physical mail, not e-mail) address, and I will send you hardcopy of the Overview. It also contains the IBIS specification V1.1 and a partial list of simulation vendors that support the standard. You can also send your email address to ibis-request@vhdl.org (198.31.14.3) to get on the IBIS reflector, which is a mail group used by the IBIS Open Forum for exchange of ideas and data. The vhdl.org file server also contains information you may find interesting. You can FTP anonymous to vhdl.org to access files. Access mechanisms (both Internet or dial-up via 408-945-4170) Access Mechanism Account (login) name Password ------------------------------------------------------------------------------ Telnet / Dial-up Guest Your email address FTP Anonymous Your email address Gopher (none) (not applicable) Email archive@vhdl.org (not applicable) In all cases, the password is optional. Just hit (return, etc.) at the password prompt, if desired. Look in /pub/ibis/ for IBIS files. A partial directory listing is attached below. The IBIS Open Forum meets once every 3 weeks (Friday's, 8-10am Pacific time) via a conference call. Send email to ibis-request@vhdl.org and ask for instructions (you can also request to be added to the IBIS reflector. The reflector averages about 10 messages per week.) All meetings and material is open freely to anyone except the source code for the Golden Parser (fee involved). To become a voting member of the forum, send $500 annual dues to: EIA/Electronic Information Group c/o Patti Rusher 2500 Wilson Blvd. Arlington, VA 22201 (703) 907-7545 Fax: (703) 907-7501 Email: prusher@eia.org The source code to the Golden Parser is available for $500 (or $250 for voting members). Send requests for the parser to Patti Rusher at the EIA. IBIS 2.1, passed at DAC in June, 1994 and further refined and finalized in December `94, has added a number of capabilities that increase both IBIS model's accuracy and the number of devices that can be modeled by IBIS. For example, ECL, dual-supply buffers, differential I/O devices, and controlled rise-time buffers can now be handled. Much more complete package descriptions, better support for open-side devices (open drain, etc.), and terminators are now supported. It also enables a reference waveform to be included with the model file, allowing customers to judge whether their simulator is capable of producing the correct results. We also have completed our 2.1 version of the "Golden Parser" that checks syntax and creates data structures from model data that simulators can use. Several IC vendors have already prepared IBIS 2.1 models, and some of the simulator vendors are beta testing and expect to begin announcing products supporting 2.1. In February we formalized our relationship with EIA, a standards body, and are moving towards formal balloting of IBIS as a recognized international standard. -------------------------- ATTACHEMENT (VHDL.ORG) ---------------------------- IBIS Directory Contents: pub/ibis/ birds/ Buffer Issue Resolution Document's (BIRD's) documents/ Overview, cookbook, EIA charter, and other IBIS documents email.archive 1995 discussions on the IBIS reflector email93/ 1993 reflector discussion archive email94/ 1994 reflector discussion archive minutes copies of meeting minutes models/ IBIS models available pressrel.dir/ IBIS Press Releases directory roster.txt Roster of IBIS Open Forum Participants s2ibis/ SPICE to IBIS converter (from N.C.State) summit93/ Nov 1993 IBIS Summit ver1.0/ IBIS specification Version 1.0 directory ver1.1/ IBIS specification Version 1.1 directory ver2.0/ IBIS specification Version 2.0 directory ver2.1/ IBIS specification Version 2.1 directory Contents: pub/ibis/ver2.1/ ver2_1.txt IBIS version 2.1 specification (ASCII) ver2_1.wfw IBIS version 2.1 (Word for Windows 6.0) (pub/ibis/ver1.1/exec/ contains executable versions of the Ver 1.1 Golden Parser.) Contents: pub/ibis/docs/ cookbk.wfw IBIS cookbook (Microsoft WORD 2.0) cookbk.txt IBIS cookbook (ASCII text file) cookbk.rtf IBIS cookbook (Rich Text Format) overview.wfw Overview document (Microsoft WORD 2.0) overview.ps Overview document (Postscript Print File) overview.rtf Overview document (Rich Text Format) overview.z Overview document (UNIX Z compressed RTF) eia_org.txt Charter for converting the Open Forum to become a part of the Electronic Industry Ass. ibispost.cgm IBIS poster Contents: pub/ibis/models/ This directory is provided by VHDL International as a free service for IBIS users. All the files within this directory are provided as is. The user assumes all responsibility for using these files. DISCLAIM.TXT Disclaimer text PROTOCOL.TXT Instructions for posting IBIS files intel/ Intel's directory of IBIS models national/ National Semiconductor Corp's IBIS models Contents: pub/ibis/models/intel/ Intel Corporation IBIS Files on vhdl.org as of 2/15/95 Part/File vhdl.org alpha rev. rev. IBIS name Directory name date level ver. Notes -------------------------------------------------------------------------------- 82425ex.ibs chipset PSC 06-17-94 R0.93 V1.1 Aries chipset 82426ex.ibs chipset IB 06-17-94 R0.93 V1.1 Aries chipset 82374eb.ibs chipset ESC 05-13-94 R2.11 V1.1 PCI-EISA Bridge 82374sb.ibs chipset ESC 06-17-94 R0.93 V1.1 PCI-EISA Bridge 82375eb.ibs chipset PCEB 05-13-94 R2.11 V1.1 PCI-EISA Bridge 82375sb.ibs chipset PCEB 06-17-94 R0.93 V1.1 PCI-EISA Bridge 82378ib.ibs chipset SIO 05-13-94 R2.11 V1.1 PCI-ISA Bridge 82378zb.ibs chipset SIOZ 06-17-94 R0.93 V1.1 PCI-ISA Bridge 82433lx.ibs chipset LBX 05-13-94 R2.11 V1.1 Mercury chipset 82434lx.ibs chipset PCMC 05-13-94 R2.11 V1.1 Mercury chipset 82433nx.ibs chipset LBX 06-17-94 R0.94 V1.1 Neptune chipset 82434nx.ibs chipset PCMC 06-17-94 R0.94 V1.1 Neptune chipset 82423tx.ibs chipset DPU 05-13-94 R2.11 V1.1 Saturn chipset 82424zx.ibs chipset CDC 05-13-94 R2.11 V1.1 Saturn chipset dx4pga.ibs cpu DX4 05-04-94 R2.0 V1.1 IntelDX4(TM) uP pp66sem.ibs pentium PP66 10-16-94 R3.0 V1.1 66MHz Pentium* pp100sem.ibs pentium PP100 10-15-94 R3.0 V1.1 100MHz Pentium* * Translated from an Intel Simplified Electrical Model. Contents: pub/ibis/models/national/ National Semiconductor Corporation - Advanced Systems & Interface Product Group IBIS Files on vhdl.org as of 4/13/95 Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes -------------------------------------------------------------------------------- ds26c31.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Drvr ds26c32.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Recvr lct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr lct2524n.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524n.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr c2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2525m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) c2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2527v.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2528m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2528n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2528v.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2529v.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) 2534v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Commercial) 2535v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) 2536v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) b303m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr 701v.ibs cgs 04-05-95 1.0 1.1 Low Skew PLL 1to8 CMOS Clk Drvr Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes ------------------------------------------------------------------------------- ds26c31.ibs interface 2/09/95 R1.0 V2.1 RS-422 Quad Diff Line Driver ds26c32.ibs interface 2/09/95 R1.0 V2.1 RS-422 Quad Diff Line Receiver lct2524m.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clk Driver lct2524n.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clk Driver ct2524m.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clk Driver ct2524n.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clk Driver c2525m.ibs cgs 04-05-85 1.0 1.1 1 to 8 Min. Skew Clk Driver (CMOS) c2525n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (CMOS) ct2525m.ibs cgs 04-05-85 1.0 1.1 1 to 8 Min. Skew Clk Driver (TTL Compa) ct2525n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (TTL Compa) b2525m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (Bipolar) b2525n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (Bipolar) c2526m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (CMOS) c2526n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (CMOS) ct2526m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (TTL Compa) ct2526n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (TTL Compa) ct2527v.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (TTL Compa) b2528m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (Bipolar) b2528n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (Bipolar) b2528v.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (Bipolar) b2529v.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew Clk Driver (Bipolar) 2534v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Driver (Commercial) 2535v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Driver (Industrial) 2536v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Driver (Industrial) b303m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b303n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b303v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b304m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b304n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b304v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b305m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b305n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver b305v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Driver 701v.ibs cgs 04-05-95 1.0 1.1 Low Skew PLL 1to8 CMOS Clk Driver Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 264-4299, Fax (503) 264-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 ______________________________ Reply Separator _________________________________ Subject: The specifications of IBIS Author: idpt31@tpts1.seed.net.tw at SMTPGATE Date: 5/19/95 8:01 PM We like to study the format of IBIS to create model for signal integrity tools. Could you plese send whole set of IBIS document to us by email ? Best Regards, Ted Tsai Maojet Technology Corp. Tel: 886-2-567-7643 Fax: 886-2-561-0756 Email: idpt31@tpts1.seed.net.tw Ted Tsai Maojet Tech Corp. Tel : 886-2-5677643 Fax : 886-2-5610756 Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: The specifications of IBIS From: idpt31@tpts1.seed.net.tw (Maojet Technology Corp.) To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 1.4.4 X-Sender: idpt31@tpts1.seed.net.tw (Unverified) Message-Id: <9505191201.AA22259@tpts1.seed.net.tw> Date: Fri, 19 May 95 20:01:01 CST Received: from idpt31 ([192.72.61.48]) by tpts1.seed.net.tw (4.1/SMI-4.1) id AA22259; Fri, 19 May 95 20:01:03 CST Received: from tpts1.seed.net.tw by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05892; Fri, 19 May 95 05:03:06 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 19 May 95 05 :13:23 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sCQvm-000twVC; Fri, 19 May 95 05:13 PDT From mac@libtech.com Fri May 19 20:41:21 1995 Return-Path: Received: from scruz.net (nic.scruz.net) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01099; Fri, 19 May 95 20:41:21 PDT Received: from libtech.com by scruz.net (8.6.9/1.34) id UAA24482; Fri, 19 May 1995 20:35:26 -0700 Received: from keklik.libtech by libtech.com (4.1/SMI-4.1) id AA00768; Fri, 19 May 95 20:37:56 PDT Date: Fri, 19 May 95 20:37:56 PDT From: mac@libtech.com (mehmet cirit) Message-Id: <9505200337.AA00768@libtech.com> To: IBIS@vhdl.org Subject: Re: The specifications of IBIS Is it possible to include postscript version of all documents along with .wfw versions. PostScript is more portable. It is easier to read the formatted versions, if you don't want to use MS-word, or don't have it. ******** SolutionWare(TM) for ASIC Library Development ******** Dr. Mehmet A. Cirit Phone: (408) 741-1214 Director, Advanced Development Fax : (408) 741-1214 Library Technologies, Inc. Email: mac@libtech.com 18837 Casa Blanca Lane Saratoga, CA 95070 From mbs@eos.ncsu.edu Sat May 20 09:38:41 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09632; Sat, 20 May 95 09:38:41 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA18502; Sat, 20 May 1995 12:32:47 -0400 From: mbs@eos.ncsu.edu Message-Id: <9505201632.AA18502@mbs.ece.ncsu.edu> To: ibis@vhdl.org Date: Sat, 20 May 95 12:32:47 EDT Hoang Nguyen wrote that he was having trouple with s2ibis and the sample file. I have just got back from a trip anmd will look into it. Michael Steer IBIS Librarian From bob@icx.com Sat May 20 10:13:55 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09817; Sat, 20 May 95 10:13:55 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 20 May 95 10:07 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 20 May 95 10:09 PDT Message-Id: Date: Sat, 20 May 95 10:09 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, mbs@eos.ncsu.edu Michael: I believe the issue has been resolved and was related to a Berkeley Spice3 intallation problem. Check with Hoang first. Bob Ross, Interconnectix, Inc. > Hoang Nguyen wrote that he was having trouple with s2ibis and the sample > file. I have just got back from a trip anmd will look into it. > Michael Steer > IBIS Librarian From jonp@qdt.com Mon May 22 10:01:29 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04837; Mon, 22 May 95 10:01:29 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyqvr09923; Mon, 22 May 1995 12:55:29 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Mon, 22 May 1995 12:55:32 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00384; Mon, 22 May 95 08:48:45 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20838; Mon, 22 May 95 08:55:26 PDT Date: Mon, 22 May 95 08:55:26 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505221555.AA20838@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA23227; Mon, 22 May 95 08:51:37 PDT To: ibis@vhdl.org Subject: LOGOs for BOF Logos are starting to come in. The uuencoded tiff is working OK most of the time. I have National Incases Zuken-Redac (Quad Design) The UNICAD logo was corrupted and needs re-transmission. sorry I deleted your return address before I saw the problem. jon From jonp@qdt.com Mon May 22 10:01:36 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04843; Mon, 22 May 95 10:01:36 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyqvr09984; Mon, 22 May 1995 12:55:37 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Mon, 22 May 1995 12:55:40 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00447; Mon, 22 May 95 09:39:17 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA21021; Mon, 22 May 95 09:45:57 PDT Date: Mon, 22 May 95 09:45:57 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505221645.AA21021@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA23265; Mon, 22 May 95 09:42:08 PDT To: ibis@vhdl.org Subject: LOGOS again (new message) could the reps for incases and zuken send me email so I can correspond with you. I have been foolishly deleting return address. jon From huq@rockie.nsc.com Mon May 22 10:37:14 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05190; Mon, 22 May 95 10:37:14 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA08110 for ibis@vhdl.org; Mon, 22 May 95 10:31:12 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA14295 for ibis@vhdl.org; Mon, 22 May 95 10:31:09 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA03503; Mon, 22 May 95 10:32:38 PDT Date: Mon, 22 May 95 10:32:38 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9505221732.AA03503@rockie.nsc.com> To: ibis@vhdl.org, jonp@qdt.com Subject: Re: LOGOs for BOF Hey Jon, If you make National's Logo the biggest on that poster..Lunch is on me at DAC. Syed. > > Logos are starting to come in. The uuencoded tiff is working > OK most of the time. > > I have > > National > Incases > Zuken-Redac > (Quad Design) > > > The UNICAD logo was corrupted and needs re-transmission. sorry I deleted > your return address before I saw the problem. > > > jon > From Derrick_Duehren@ccm2.jf.intel.com Mon May 22 11:48:21 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05893; Mon, 22 May 95 11:48:21 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sDcQp-000UniC; Mon, 22 May 95 11:42 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sDcQo-000twgC; Mon, 22 May 95 11:42 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Mon, 22 May 95 11:42:22 PDT Date: Mon, 22 May 95 11:37:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: IBIS Open Forum 5/26/95 Meeting Agenda NOTE: I will publish the minutes from the last meeting soon. - Derrick IBIS Open Forum Meeting Agenda for 5/26/95 Bridge: Res: (916) 356-9999 485256 All meetings are 8:00 AM to 10:00 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes (and ARs) - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available EIA Status Hobbs - Membership update Progress toward enlisting new IC vendors All 8:30 Golden Parser 2.1 status Hobbs Plans for IBIS Meeting at DAC (June12-16) Hobbs Rev 2.1 updates Hobbs o S2IBIS 2.1 o Cookbook o Overview 9:00 BIRD 26 - Tab chars discouraged in .ibs files (revote) Hobbs BIRD 27 - New keyword for differential I/O Ward BIRD 28 - Package model extension Peters Support of MCMs and SIMMs? If yes, how? Crisafulli 9:55 Wrap-up, next meeting plans Hobbs From Derrick_Duehren@ccm2.jf.intel.com Mon May 22 12:18:07 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06117; Mon, 22 May 95 12:18:07 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sDctg-000UjnC; Mon, 22 May 95 12:12 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sDctg-000twfC; Mon, 22 May 95 12:12 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Mon, 22 May 95 12:12:12 PDT Date: Mon, 22 May 95 12:08:00 PDT From: Derrick Duehren Message-Id: To: mac@libtech.com_at_smtpgate@ccm.hf.intel.com, IBIS@vhdl.org Subject: Re[2]: The specifications of IBIS cookbk.prn IBIS cookbook (Postscript Print File) overview.prn Overview document (Postscript Print File) posted to vhdl.org \pub\ibis\documents. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 264-4299, Fax (503) 264-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 ______________________________ Reply Separator _________________________________ Subject: Re: The specifications of IBIS Author: mac@libtech.com at SMTPGATE Date: 5/19/95 8:37 PM Is it possible to include postscript version of all documents along with .wfw versions. PostScript is more portable. It is easier to read the formatted versions, if you don't want to use MS-word, or don't have it. ******** SolutionWare(TM) for ASIC Library Development ******** Dr. Mehmet A. Cirit Phone: (408) 741-1214 Director, Advanced Development Fax : (408) 741-1214 Library Technologies, Inc. Email: mac@libtech.com 18837 Casa Blanca Lane Saratoga, CA 95070 From Derrick_Duehren@ccm2.jf.intel.com Tue May 23 10:09:52 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19188; Tue, 23 May 95 10:09:52 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sDxN4-000UnQC; Tue, 23 May 95 10:03 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sDxE7-000txbC; Tue, 23 May 95 09:54 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Tue, 23 May 95 09:54:39 PDT Date: Tue, 23 May 95 09:51:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: Minutes: 5/5/95 EIA IBIS Open Forum Meeting DATE: May 23, 1995 SUBJECT: 5/5/95 EIA IBIS Open Forum Meeting Minutes PARTICIPANTS: (Voting members are indicated by [M].) ARPA Randy Harr AT&T Global Info Solutions Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design [M] Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec [M] Dileep Divekar* Digital Equipment Corp. Barry Katz EIA Patty Rusher* High Design Technology Michael Smith, Dr. Ing. Cosso HP Palo Alto Tom Langdorf HP EESof Karl Kachigan, Henry Wu HyperLynx [M] Kellee Crisafulli IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, John Burnett INCASES [M] Werner Rissiek, Olaf Rethmeier Integrated Silicon Systems Eric Bracken Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren*, Tim Schreyer* Interconnectix, Inc. [M] Bob Ross* Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei, John Sliney MicroSim Arthur Wong National Semiconductor [M] Syed Huq*, Raj Raghuraum, Atul Agarwal NEC [M] Hiroshi Matsumoto North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Quad Design Jon Powell* Quantic Labs [M] Mike Ventham Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments [M] Bob Ward Thomson-CSF/SCTF [M] Jean Lebrun UniCAD Canada Ltd. [M] Stephen Lum Zuken-Redac [M] John Berrie Zeelan Technology George Opsahl, Hiro Moriyasu In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # 5/26/95 (916) 356-9999 485256 All meetings are 8:00 AM to 10:00 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- CHECK-IN, INTROS, ANNOUNCEMENTS, TREASURE'S REPORT There were no corrections made to last month's minutes. There were no new participants. The spec and a press release will go out for ballot Monday. [Update: Ballots sent.] NEW AGENDA ITEMS: None. PRESS UPDATES: April 17 Electronic Press, older press release April, Computer Design, big article NEW MODELS AVAILABLE: Derrick's mail to get models listed that aren't public got 2 good responses, yet no actual data yet. EIA IBIS MEMBERSHIP UPDATE: Patti reported that there are 12 voting members, $4,700 in the bank, plus $1,400 from our old account. Patti will be sending out the IBIS 2.1 ballot to DAD and the roster, and some of the JEDEC committee, as well as EDIF and DIE, hard copy. Went through a roll call to see who should be receiving the parser as a double-check. Contec has not received theirs, but has subscribed. [Update: Will has now updated all recipients of the Parser.] PROGRESS TOWARD ENLISTING NEW IC VENDORS None. GOLDEN PARSER 2.1 PROGRESS AND RELEASE DATE Will polled those present to ensure everyone who should have the latest parser (Beta4) has it. Arpad recommends that Paul fix the extra LF CRs (BIRD? ) It is not in the parser. This would be a separate utility. [Update: Beta5 and Beta6 have been distributed since the 5/5/95 meeting.] Decided: We want the librarian to ensure that all files posted to ibis/models are in UNIX LF CR notation format. AR Jon -- Communicate this message to Michael Steer. PLANS FOR IBIS MEETING AT DAC (JUNE 2ND - 16TH) We will have a face-to-face meeting at DAC to elect officers and conduct other business Thurs. 6/15/95. We decided to move the IBIS meeting to 1:00 pm to 5:00 pm. Cadence volunteered to host the meeting room for Thursday. Topics: Election of officers Package Issues Status of balloting We discussed the possibility of creating a simple IBIS data sheet and decided to purchase reprints of the EDN article on IBIS. AR Derrick -- Send order info to Pattie, get 2,000 color copies (approx. $2K). [Done] Placards. We decided to have Jon order 40 and send the invoice to Pattie Rusher (the IBIS Committee will pay for them). They can be used at DAC and other future events. EIA, VITAL, CFI, etc., are in a booth at DAC (#935). The booth theme will be a standards roadmap. Article reprints will be available at the booth. REV 2.1 UPDATES o S2IBIS 2.1 No discussion. o Cookbook No discussion. o Overview No discussion. DIODE TRANSIT TIMES Diode transit time: Tim hasn't had a chance to post his work to the reflector yet, but Jon Powell discussed his work modeling diodes via a voltage dependence capacitance ("Semiconductor Device Modeling with Spice", by McGraw-Hill). He found extremely good correlation between this work and Spice simulations. He feels that in addition to the stored charge effect, the turn-off of the diode creates an impedance discontinuity that adds to the spike. Kumar suggests we represent this as a C/V curve, but Jon feels this is a single number uniquely determined by the transit time, so a table is not necessary. Both Arpad and Syed disagree, feeling there are 3 contributors to it. Arpad described a method using a curve tracer to derive the forward biased and reverse biased capacitance. Dileep says you need to measure the stored charge, by forward biasing the diode for awhile, then letting it discharge and measuring the current. After 15 minutes of discussion, we decided to continue the discussion on the reflector. BIRD 26 - TAB CHARACTERS DISCOURAGED IN .IBS FILES We do not have quorum. `Official (quorum) vote' delayed again. BIRD 27 - NEW KEYWORD FOR DIFFERENTIAL I/O Bob Ward not present to defend his idea. Tabled until he can comment. EGG - TRANSMISSION LINE PACKAGE MODELS There has been lively discussion on the reflector. Stephen gave an overview. There is not agreement on the scope of the proposal. Jon and Kumar feel that the approach is good, but in six months we will want to have something more extensible, particularly for MCM or PCB type applications. Forks, intermediate loads, etc., when there are multiple chips/loads in the package, are a problem not addressed by the Egg. Kumar proposes using Spice terminology, with coupled transmission lines added. Stephen suggested we call it a "node-based description" to avoid the straight jacket of Spice. We will continue the discussion on the reflector. AR Kumar -- Post an EGG with your proposals and an example. AR Stephen -- Jon did not get your package models. Please follow up. SGML/HTML SUPPORT (WWW) Syed volunteered to provide some materials for an IBIS WWW home page. Suggestions: FAQ, general pointers, articles, maybe the EDN article, previous DAC presentations. Contact Cecilia Fleming (703) 907-7554, cfleming@eia.org. WRAP-UP, NEXT MEETING PLANS Our next meeting is a teleconference 5/26/95. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 Will_Hobbs@ccm.jf.intel.com Modeling Manager, Intel Corp., Chairperson, EIA IBIS Open Forum 5200 NE Elam Young Pkwy M/S JF1-50, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 JonP@qdt.com 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Derrick Duehren (503) 264-4299, fax (503) 264-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager To become a voting member of the EIA IBIS Open Forum, send email to ibis-info@vhdl.org for instructions. If you want to join the e-mail reflector (ibis@vhdl.org), send e-mail to the IBIS secretary at ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From Derrick_Duehren@ccm2.jf.intel.com Tue May 23 17:14:33 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22722; Tue, 23 May 95 17:14:33 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sE406-000UoOC; Tue, 23 May 95 17:08 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sE405-000txGC; Tue, 23 May 95 17:08 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Tue, 23 May 95 17:08:37 PDT Date: Tue, 23 May 95 17:05:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: EIA IBIS Committee Participation Roster IBISians, PLEASE PROVIDE ADDITIONS/CHANGES! I have had few changes in the last year. Thanks, Derrick ============================================================================ EIA IBIS Committee Participation Roster As of 5/23/95 (updated periodically) 32 company/organizations listed Submit changes/updates to: Derrick_Duehren@ccm.jf.intel.com (503) 264-4299, Fax (503) 264-4904 ============================================================================ NOTE: This roster lists companies and organizations that have either participated in creating the IBIS spec or are creating/distributing IBIS models. Other than the specific statements of support under each organization's name, no support nor endorsement of the specification is implied. ============================================================================ Anacad EES Contact: Steffen Rochel Email: steffen@anacad.com Phone: (408) 954 0600 Fax: (408) 954 8884 Address: 1900 McCarthy Blvd. #310 Milpitas, CA 95035 Support: Anacad can translate IBIS descriptions into models using their analog behavioral modeling language HDL-A. Together with Eldo and a VHDL simulator, highly accurate investigations of mixed signal designs are possible. Tag-line: Ansoft Corporation Contact: Henri Maramis Email: maramis@ansoft.com Phone: (412) 261-3200, Fax: (412) 471-9427 Address: 4 Station Square, Suite 660 Pittsburgh, PA. 15219 Support: The Ansoft Maxwell SI product will support IBIS models/library in native format. Tag-line: Ansoft is a dedicated provider of electromagnetic field simulation software and integrated solutions for signal integrity and EMC/EMI. AT&T Global Information Solutions Contact: Dave Moxley Email: David.Moxley@columbiasc.ncr.com Phone: Address: Support: Tag-line: Atmel Corporation Contact: Dan Terry Email: No internet address -- Pls Fax notices Phone: (408) 436-4346, Fax: (408) 436-4200 Address: Support: Tag-line: Cadence Design Systems, Inc. Contact: C. Kumar Email: cpk@cadence.com Phone: (508) 262-6488, Fax: 508-262-6600 Address: 270 Billerica Rd, Chelmsford, MA 01824 Support: Cadence fully supports IBIS models. Cadence's DF/SigNoise product family offers a vendor-specific, IBIS compatible signal integrity library of over 7000 components. Cadence also provides a translator program enabling the conversion of IBIS 1.1 and 2.1 files to Cadence library format. Tag-line: Cadence, the worldwide leader in electronic design automation, combines leading-edge technology and a complementary set of services to accelerate and advance the overall performance engineering of high-speed electronic systems. Contec Microelectronics USA, Inc. Contact: Dileep Divekar, Clark Cochran Email: dileep@contec.com Phone: (408) 434-6767, Fax: (408) 434-6884 Address: 2188 Bering Drive San Jose, CA 95131 Support: A Contec product will support IBIS models in native mode. Tag-line: Digital Equipment Corp. Contact: Stephen C. Thierauf Email: thierauf@pasta.enet.dec.com Phone: (508) 568-4475, Fax: (508) 568-4367 Address: 77 Reed Road, HLO2-3/G13 Hudson, MA 01749 Support: Digital will generate IBIS models for its own chip products, including the line of ALPHA AXP microprocessors, as needed, and support IBIS models in in-house simulation tools. Tag-line: Digital, maker of the world's fastest microprocessor, is also a leading developer of computer systems, and networking and communication products, including PCI. Hewlett-Packard/HP EEsof Division Contact: Karl Kachigan Email: karlk@sr.hp.com Phone: (707) 577-3949, Fax: (707) 577-5260 Address: 1400 Fountaingrove Parkway Santa Rosa, CA 94503 Support: None at this time Tag-line: HP EEsof is a leading supplier of high frequency analog (RF/Microwave) design and modeling tools. High Design Technology Contact: Maria Teresia Cosso (HDT,Italy), Wence Coron (Anacad EES,US) Email: wence@anacad.com Phone: +39 11 33 84 34 (408) 954-0600 Fax: +39 11 385 99 67 Fax: (408) 954-8884 Address: HDT Anacad EES Via Beaulard, 64 1900 McCarthy Blvd. #310 10139 Torino, Italy Milpitas, CA 95035 Support: An interface to IBIS is in preparation and will be available Q2/95. Tag-line: HDT offers a sophisticated toolset for signal integrity analysis and EMI investigation. In connection with a TDR based modeling technique, accurate and fast analysis of complete PCB's is provided. HyperLynx Contact: Kellee Crisafulli Email: 71436.1314@compuserve.com Phone: (206) 869-2320, Fax: (206) 881-1008 Address: P.O. Box 3578 Redmond, WA 98073-3578 Support: Several signal integrity analysis tools are available: LineSim: A simulator using schematic data input, reads IBIS files as part of its native library support. Ships with a set of IBIS libraries. BoardSim: A simulator using PCB geometry data input from numerous PCB layout packages, also natively supports IBIS files. Ships with a set of IBIS libraries. Additional model libraries are available free of charge to customers on HyperLynx's BBS. Tag line: HyperLynx, Inc. is the industry's leading supplier of affordable, accurate, PC-based signal-integrity software. IBM Corp. (unofficially) Contact: Joseph C. (Jay) Diepenbrock Email: jayd@ralvm29.vnet.ibm.com Phone: (919) 543-8804 Address: IBM Network Hdwe. Div. Transceiver Technology Dev't, D63/061 P. O. Box 12195 Research Triangle Park, NC 27709 Support: No formal declaration of support. Tag-line: INCASES Contact: Werner Rissiek, Olaf Rethmeier Email: wr@cadlab.cadlab.de, olaf@cadlab.cadlab.de Phone: ++49-5251-284-155, ++49-5251-284-222, Fax: ++49-5251-284-105 Address: INCASES Engineering GmbH Vattmannstrasse 3 D-33100 Paderborn, Germany Support: INCASES uses the simulation program FREACS (Fast REflection And Crosstalk Simulator) for signal integrity analysis within the EMC-Workbench. INCASES can read IBIS Version 1.1 files and translate the IBIS models into FREACS models. INCASES uses an IBIS parser and an automatic process for the parametrization of the FREACS macromodels. Additionally, so called 'reference lists' are set-up that are used by the interface (XLIN) between the EMC-Workbench and the FREACS macromodel library. These reference lists consist of circuit information in a special language named HINAC (Hierachical Naming Convention), where macromodel data is assigned to pins of a component using IBIS-information, as well. In this way a controlled set-up of a library is possible using IBIS-files as basis. Detailed information is available on request. Tag-line: INCASES Engineering, GmbH, Germany, founded on November 1, 1994, is a supplier of design automation software and consulting services to the electronic design automation (EDA) market, focusing on EMC and 'Design for Manufacturability'. INCASES develops, sells, and supports two major product lines: THEDA, acquired from Computervision Corporation and EMC-Workbench, acquired from Siemens Nixdorf Informationssysteme AG. Intel Corporation Contact: Will Hobbs Email: Will_Hobbs@ccm2.jf.intel.com Phone: (503) 696-4369, Fax: (503) 696-4210 Address: 5200 NE Elam Young Pkwy, JF1-57 Hillsboro, OR 97124 Support: Intel provides IBIS models for some of its components. For a list of supported components, send the following message to archive@vhdl.org: path send pub/ibis/models/intel readme index /pub/ibis/models/intel Tag-line: Intel, the world's largest chip maker, is also a leading manufacturer of personal computer networking and communications products. Interconnectix, Inc. Contact: Bob Ross Email: bob@icx.com Phone: (503) 684-6641, Fax: (503) 639-3469 Address: 10220 S.W. Nimbus Ave., K4 Portland, Oregon 97223 Support: The Interconnect Synthesis (IS) product supports the major extensions of IBIS Version 2.1. Interface extensions for component and model selection and termination generation allow IBIS formatted data to be used in "what if" investigations and automatic synthesis operations. Tag-line: The leading Interconnect Synthesis Company Intergraph Corp. Contact: Rob Kelley Email: rkelley@ingr.com Phone: (205) 730-8978 Address: One Madison Industrial Park Huntsville, AL 35894-0001 Support: Intergraph Electronics fully supports the activities of the IBIS open forum and as such, is ensuring that all signal integrity development is aligned so that our customers will be able to take advantage of IBIS as the standard stabilizes. Tag-line: Intergraph Corporation, a Fortune 500 company, is the world's largest independent NT development site and the world's largest company dedicated to supplying interactive computer graphics systems. Integrated Silicon Systems, Inc. Contact: Eric Bracken Email: bracken@isscad.com Phone: (412) 832-9627 Address: One Northgate Square Greensburg, PA 15601-1341 Support: PSIBoards accepts IBIS model files directly. The IBIS files can contain any number of models or components. Instances of these models can be declared in the program's input deck, along with interconnections, to describe a complete design. Tag-line: Integrated Silicon Systems, Inc. is a leading supplier of hierarchical layout verification products. IntuSoft Contact: Charles Hymowitz Email: Phone: (303) 833-0710 Address: Support: IntuSoft takes a customer's netlist or model and translates it into a Spice model, free of charge. IntuSoft has the Golden Parser source but hasn't, as of yet, automated the process. IntuSoft is waiting until there are more IBIS models available. Tag-line: Mentor Graphics Corp. Contact: Greg Seltzer, Greg Doyle Email: Greg_Seltzer@mentororg.com, Greg_Doyle@mentororg.com Phone: (503) 685-1198, Fax: (503) 685-7991 Address: 8005 SW Boeckman Rd. Wilsonville, OR 97070-7777 Support: Mentor supports IBIS by using Quad Design and Intel IBIS models. Tag-line: Meta-Software Contact: John Sliney, Mei Wong Email: johns@metasw.com, mei@metasw.com Phone: (408) 369-5446, Fax: (408) 371-5100 Address: 1300 White Oaks Rd. Campbell, CA 95008 Support: Tag-line: MicroSim Corp. Contact: Arthur Wong Email: Phone: (714) 770-3022, FAX: (714) 455-0554 Address: 20 Fairbanks Irvine, CA 92718 Support: MicroSim can automatically generate PSpice models for vendors who provide data in a file format conforming to the IBIS Ver 1.1 specification. The models can then be simulated with PSpice. MicroSim has made IBIS models for Intel's Pentium processor 82430 PCIset available to customers. Tag-line: MicroSim Corp. - The Desktop EDA Company - provides technically sophisticated software for schematic entry, simulation, programmable logic synthesis, and signal integrity analysis. National Semiconductor Corp. Contact: Syed B.Huq Email: huq@rockie.nsc.com Phone: (408) 721-4874, Fax:(408)721-4785 Address: 2900 Semiconductor Drive, M/S A-2595 Santa Clara, CA 95052 Support: The Advanced Systems & Interface Product Group(ASIP) of National Semiconductor is willing to create IBIS model files and provide IBIS model support to customers. Tag-line: National Semiconductor provides technologies for moving and shaping information. The company focuses on communications, analog, and personal systems markets, and is the fourth largest U.S semiconductor merchant. NEC Corporation Contact: Hiroshi Matsumoto Email: mat@lsi.tmg.nec.co.jp Phone: +81 -44-435-1501(DIR), Fax: +81 -44-435-1887 Address: Design Sys. Dept., System ASIC Div., NEC Corp. 1753 Shimonumabe, Nakahara-ku Kawasaki Japan 211 Support: NEC is willing to write some IBIS models and a model generator for some of its LSI components. Tag-line: North Carolina State University Contact: Michael Steer, Paul Franzon, Steve Lipa Email: mbs@ncsu.edu paulf@ncsu.edu slipa@eos.ncsu.edu Phone: 919-515-5191 919-515-7351 919-515-3947 FAX for all three: 919-515-5523 Address: ECE Dept. Box 7911 NC State Univ. Raleigh, NC 27695-7911 Support: (as of 2/94) A Spice to IBIS converter is being developed. A measurement based procedure is being developed for extracting IBIS models. A yacc/lex parser for IBIS models is being develped. All software and techniques will be put in the public domain. Tag-line: Quad Design Technology, Inc. Contact: Jon Powell Email: jonp@qdt.com Phone: (805) 988-8250, Fax: (805) 988-8259 Address: 1385 Del Norte Rd. Camarillo, CA 93010 Support: Quad Design has a translation program that translates from IBIS format to Quad Design .mod format. This translator uses the Golden Parser code with enhancements to warn of malformed (yet legal) models. The translator supports user input to be able to select from the min-typ-max range of IBIS data. This program (IBIS2XTK) is available now and is distributed with XTK Crosstalk and transmission line simulation tool kit. Tag-line: Quad Desgin is a leading supplier of Signal Integrity and Timing tools for high speed digital designs. Quantic Laboratories, Inc. Contact: Mike Ventham Email: ventham@quantic.mb.ca Phone: (204) 942-4000, Fax: (204) 957-1158 Address: 12th Floor, 191 Lombard Ave Winnipeg, Manitoba, R3B 0X1 Canada Support: Quantic provides an IBIS reader (based on the Golden Parser) that will read IBIS models and automatically generate data files for Phidias (our graphical VI curve device modellor) and database files that associate the component definitions with the pin models. From Phidias, both SPICE models for PCB Greenfield (our pre and post layout transmission line simulator) and models for BoardScan, (our PC board screener for signal integrity and crosstalk problems) can be created. This is available now for Quantic customers. Tag-line: Quantic Laboratories Ltd has been the leading supplier of field solvers and signal integrity tools since 1983. This expertise has now been extended to Electromagnetic Compatibility (EMC) tools. Symmetry Design Systems, Inc. Contact: Andy Hughes Email: andy@symmetry.com Phone: (415) 949-9600, Fax: (415)-949-0831 Address: 477 S. San Antonio Rd. #200 Los Altos, Ca. 94022 Support: Symmetry provides IBIS modeling tools and services. Symmetry's modeling tool MODPEX can create IBIS models based on measured device characteristics or data sheet information. MODPEX can translate IBIS models to SPICE descriptions for testing and documentation or translate SPICE models to IBIS. Tag-line: Symmetry is a dedicated supplier of tools and services for creating, testing, and documenting SPICE and IBIS component models for electronic system design. Synopsys Inc. (Logic Modeling Group) Contact: Bill Lattin Email: billl@lmc.synopsys.com Phone: (503) 690-6900, Fax (503) 690-6906 Address: 19500 NW Gibbs Dr. Beaverton, OR 97075 Support: None at this time Tag-line: Texas Instruments Contact: Bob Ward Email: bward@neosoft.com Phone: (713) 274-4146, Fax (713) 274-3911 Address: P.O. Box 1443, M/S 631 Houston, TX 77251 Support: TI has a three-pronged attack on IBIS support. TI is working on a scheme to automatically generate IBIS models from TI Spice simulations (TI's proprietary Spice dialect), on an automatic means to generate C code to be linked in to TI Spice as a User Defined Element from an IBIS model, and an automatic means to create the Spice equivalent of the IBIS model from the IBIS model specification. The latter method differs from the second in that it uses skeletonized Spice primitive elements in the form of a subcircuit, while the second actually generates C code and compiles it for dynamic linking. Tag-line: Thomson-CSF/SCTF Contact: Jean Lebrun Email: Phone: Address: Support: Tag-line: UniCAD Canada Ltd. Contact: Stephen Lum Email: lum@unicad.com Phone: (613) 596-9091 Ext. 321 Address: 2745 Iris Street Pinecrest Office Park Ottawa, Ontario K2C 3V5 Support: UniSolve, a concurrent engineering workbench currently supports IBIS v1.1 model files in native mode for signal integrity analysis. Support for IBIS v2.1 is planned for early 1995. Tag-line: UniCAD, INC. provides software used in the layout and analysis of printed circuits and multichip modules. It provides the only available concurrent Computer Aided Analysis (CAA) environment used to simultaneously monitor Emissions, Digital Signal Integrity, Analog Signal Integrity, Thermal, and Reliability throughout the design layout process. Zeelan Technology, Inc. Contact: Hiro Moriyasu, George Opsahl Email: zeelan@netcom.com Phone: (503) 520-1000 Address: 10550 SW Allen Blvd. Beaverton, OR 97005 Support: Zeelan Tech. provides a modeling service that characterize and creates models conforming to the IBIS format. Zeelan Tech. MasterModel(TM) models are created from measurements of physical devices using a tightly controlled high-frequency fixture and modeling system. These models closely represent actual device behaviour when used in simulation. Tag-line: Zuken-Redac Contact: John Berrie Email: johnb@redact.co.uk Phone: +44 684 294161, Fax: +44 684 299754 Address: Tewkesbury Gloucestershire GL20 8QL, England Support: Work is in progress to enable use of IBIS models in native format for Redac High-Performance Engineering and EMC Adviser products. In addition, integration with Quad Design and Quantic products provides the stated level of support provided by these companies. Tag-line: Zuken-Redac is a world leader in design automation, providing open, leading technology, standards-based CADCAM solutions. ============================================================================ EIA/Electronic Information Group Contact: Patti Rusher Email: Prusher@eia.org Phone: (703) 907-7545. Fax: (703) 907-7501 Address: 2500 Wilson Blvd. Arlington, VA 22201 From Derrick_Duehren@ccm2.jf.intel.com Wed May 24 10:28:00 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04353; Wed, 24 May 95 10:28:00 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sEK8D-000UdiC; Wed, 24 May 95 10:22 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sEK8B-000tytC; Wed, 24 May 95 10:22 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 24 May 95 10:22:03 PDT Date: Wed, 24 May 95 10:20:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: repeated message problem IBISians, After a week of discussing the repeated message problem with several networking experts, we believe the cause of the problem was a server automatically replying to ibis. The most likely scenario is that the original note (see addendum) was correctly reflected by the IBIS reflector. It was received by the Thomson company in France at an unfortunate time, when Thomson's machine was set up to automatically reply to IBIS. IBIS, in turn, automatically sent the note back to Thomson. And so on. The machine responsible for the automated replies is located at Admin@SCTF.thomson.fr This can be seen from the "TO:" list of the repeated messages. Every time Thomson's machine sent an automatic reply to ibis, it "cc:"'ed itself, expanding the TO: list by adding its name. As can be seen below, the To: list grew as more Thomson addresses were added. To: "P=INTERNET; DDA.TYPE=RFC-822; DDA.VALUE=ibis(a)vhdl.org" , "Admin, * *." , "Admin, * *." , "Admin, * *." , "Admin, * *." , "Admin, * *." , "Admin, * *." It is unclear to me why only my message was singled out and ping-ponged. I repeatedly have tried contacting Admin@SCTF.thomson.fr, but they do not seem to understand the problem. I will pursue the issue, to ensure that this was an isolated incident that won't reoccur! Thanks for your understanding, Heinz ---------------------------------------------------------------------------- ORIGINAL NOTE: =============================================================================== To: ibis@vhdl.org Please add me to your subscription list. Thanks, Heinz ------------------------------------------------------------------------------- HEINZ BLENNEMANN Silicon Graphics heinz@sgi.com (415) 390-4236 ------------------------------------------------------------------------------- =============================================================================== ------------------------------------------------------------------------------- HEINZ BLENNEMANN Silicon Graphics heinz@sgi.com (415) 390-4236 ------------------------------------------------------------------------------- From Will_Hobbs@ccm2.jf.intel.com Wed May 24 11:50:43 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04950; Wed, 24 May 95 11:50:43 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sELQF-000UjnC; Wed, 24 May 95 11:44 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sELQD-000twxC; Wed, 24 May 95 11:44 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Wed, 24 May 95 11:44:45 PDT Date: Wed, 24 May 95 11:40:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Subject: GP2.0 Licensees IBISers, The following is a list of companies who have licensed the Golden Parser 2.0 in the Beta time frame. If you feel this list is in error, please let me know as soon as possible. Regards, Will Hobbs Intel Corp. and IBIS Chair Alcatel Sel AG Anacad AT&T GIS Cadence Contec DEC HP EEsof Div. Hyperlynx Incases Engineering GmbH Intel Corp. Interconnectix, Inc. Intergraph Electronics Meta Software, Inc National Semiconductor Corp. Quad Design Quantic Labs Symmetry Design Systems, Inc UniCAD Canada Ltd. From bob@icx.com Thu May 25 11:38:44 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10260; Thu, 25 May 95 11:38:44 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 25 May 95 11:31 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 25 May 95 11:34 PDT Message-Id: Date: Thu, 25 May 95 11:34 PDT From: bob@icx.com ( Bob Ross) To: 73053.721@compuserve.com, 75123.3477@compuserve.com, ibis@vhdl.org Subject: IBIS Test Matrix for IBISCHK2 Beta 6 Update Hello Fellow IBISans, Paul and Ron: Much progress has been made and nearly all of the PACKAGE problems are fixed. Four issues are listed below: (1) One crash related to [Number of Pins] missing data has been fixed. Another crash occurs if the entry is incorrectly given as "1" (several other numbers may also produce a crash). You get "mtx.c323: assertion failed. Abnormal program termination." I get similar results on DOS. Also, I got a Segmentation fault on a Unix system in one case. So there are problem still some pointer problems which will lead to crashes. (2) For "Banded_matrix" choices, the Specification states that the last row entries contain successively fewer columns. The parser operates successfully, but I believe the Specification is wrong. (3) For "Sparse_matrix" choices, some problem are related to not accepting alpha-numeric indicies in the "Index" column of the Row data line. (4) There is an omission in the Specification regarding the correlation of actual [Pin] entries and number of entries with those required in [Pin Numbers]. Attached at the end is an IBIS file illustrating these points. Otherwise, the IBISCHK2 works well at testing the major features at a very robust level, and is converging on handling the Version 2.1 package model extensions very well. This is required for dealing with any extensions such as those of BIRD28. Good Work Ron and Paul! Bob Ross Interconnectix, Inc. A TEST MATRIX FOR IBIS VERSION 2e (Beta 6) DATE: 10/31/94, 12/2/94, 1/26/95, 3/4/95, 3/8/95 5/25/95 SPECIFICATION TESTED PASS Comments/who tested --------------------------------------+-----+-----------------------------+ Test that the parser only | | | accepts 1.0, 1.1, 2.0, 2.1 as | | | valid arguments to the [IBIS Ver] | yes | Stephen Peters | keyword. | | | | | | Tab character warning | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Scaling Factors: | | | | | | Test that the parser recognizes | | | "T", "G" and "f" as valid scaling | yes | No indication either way | factors. | | Bob Ross - this is proper | | | operation | Test that the parser does not | | | recognize "t", "g" and "F" as | yes | No indication either way | Valid scaling factors. | | Bob Ross - proper operation | | | | --------------------------------------+-----+-----------------------------+ Keywords rules: | | | | | | Test that the parser recognizes | | | the [GND clamp] and [PWR clamp] | yes | Stephen Peters | keywords without the underscore. | | | Test Underscore rule for 3-word | yes | Bob Ross | Keyoreds - all 4 cases. | | | | | | Test that the parser issues an | | | error if a keyword does not begin | yes | Stephen Peters | in column 1. | | | | | | Test case insensitivity of all | | | keywords, reserved words and | yes | Pin mapping keyword does not| sub-parameters | | recognize "power" and "gnd" | | | Bob Ross - OK, should be | | | "pulldown_ref", "pullup_ref,| | | "gnd_clamp_ref", and | | | "power_clamp_ref" | | | | --------------------------------------+-----+-----------------------------+ Comments and Notes: | | | | | | Test that the parser does not | | | accept "+" and "-" as valid | yes | Stephen Peters | comment characters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Copyright] keyword. | | | | | | | | | --------------------------------------+-----+-----------------------------+ Component keyword related: | | | | | | Test that the parser issues an | | | error if the [Component] keyword | yes | Stephen Peters | has no component name after it. | | | | | | Test that the parser issues a warning | | | if the component name contains blanks | yes | Stephen Peters | | | | Test the component name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | " | parser fails if name > 40 characters | yes | " | | | | Test that the parser issues an | | | error if the [Manufacture] keyword | yes | Stephen Peters | has no Manufactures name after it. | | | | | | Test the Manufactures name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | Stephen Peters | parser fails if name > 40 characters | yes | Stephen Peters | | | | Test that an .ibs file can contain | yes | Bob Ross | more than one [Component] keyword | | | and component description. | | | | | | --------------------------------------+-----+-----------------------------+ Pin keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin] keyword. | | | | | | Test that the parser issues a | | | error when every model_name does | yes | Bob Ross | not have a corresponding model | | (I don't see the problem) | defined. | | | | | | Test the "3 column or 6 column" | | | rule. | yes | Stephen Peters | | | | Test that the parser issues an error | | | when non-numeric data is in the pin | yes | Stephen Peters | data columns | | | --------------------------------------+-----+-----------------------------+ Package Model related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Package Model] keyword. | | | | | | Test the package model name length | yes | Bob Ross | rules | | Fixed: | parser accepts name < 40 characters | yes | Name is taken as a DOS file | parser accepts name = 40 characters | yes | name and not as argument to | parser fails if name > 40 characters | yes | the [Define Package Model] | | | keyword | Verify that the parser issues an | | | error if it cannot find: | | | | | | 1. A [Define Package Model] keyword | | | that has the same argument as the | yes | Bob Ross | [Package Model] keyword or | | | | | | 2. An external .pkg file that has | yes | Bob Ross | a [Define Package Model] keyword | | | with has the same argument as the | | | [Package Model] keyword. | | | | | | 3. Test that the parser recognizes | | | all keywords in the package model | | | description and operation below: | | | (1) Error if Missing | | | (2) Error if Duplicate | | | (3) Error if Wrong Argument | | | [Define Package Model] 1,2,3 | yes | Bob Ross | [Manufacturer] 1,2,3 | yes | | [OEM] 1,2,3 | yes | | [Description] 1,2,3 | yes | | [Number of Pins] 1,2,3-fails | NO | MAY CRASH if wrong number | [Pin Numbers] 1,2,3 | yes | | [Model Data] 1,2 | yes | | [Resistance Matrix] 2,3 | yes | | [Inductance Matrix] 1,2,3 | yes | | [Capacitance Matrix] 1,2,3 | yes | | [Bandwidth] 1,2,3 | yes | fixed | [Row] 1,2,3-fails | NO | (problems below) | [End Model Data] 1,2 | yes | Bob Ross | [End Package Data] 1,2 | yes | " | | | | | | | 4. Full_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] number entry (all rows entered) | yes | fixed | [Row] format (upper triange matrix) | yes | fixed | [Row] format (excessive data) | yes | | [Row] format (missing data) | yes | fixed | | | | 5. Banded_matrix Tests | | Bob Ross | [Bandwidth] req'd test | yes | fixed | [Bandwidth] argument req'd | yes | | [Bandwidth] argument value | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] format (excessive data) | yes | | [Row] format (missing data) | yes | fixed | [Row] format last rows SPEC ISSUE | NO | NEEDS TO BE RESOLVED | | | | 6. Sparse_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | NO | | [Row] index match | yes | | [Row] index (alpha string) | NO | | [Row] format (excessive data) | yes | fixed | [Row] format (missing data) | yes | fixed | | | | --------------------------------------+-----+-----------------------------+ Pin Mapping keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin Mapping] keyword. | | | | | | Test that the parser issues an | | | error if every pin listed in the | yes | Bob Ross - fixed | [Pin] keyword does not have an | | | entry in the [Pin Mapping] table | | | | | | Test the "3 column or 5 column" | yes | Stephen Peters | rule. | | | | | | Test that NC is a valid entry | | | in a column. | yes | Stephen Peters | | | | Test that each unique entry label | | | must connect to at least one pin | | | whose model name is POWER or GND | yes | Stephen Peters | | | | Test that NA is NOT a valid | | | column entry | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Diff Pin keyword related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Diff Pin] keyword. | | | | | | Test that the parser recognizes | yes | Bob Ross | the 5 associated sub-parameters | | | | | | Test the "4 column or 6 column" | yes | Bob Ross | rule. | | | | | | Test that NC is NOT a valid | yes | Bob Ross | column entry. | | | | | | Test that NA is a valid column | yes | Bob Ross | entry. | | | | | | Reports error for duplicate pin | yes | Bob Ross | numbers. | | | | | | --------------------------------------+-----+-----------------------------+ [Model] keyword: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Model] keyword. | | | | | | Test that the parser recognizes | | | each Model_type: | | | Input | yes | Bob Ross | Output | yes | | I/O | yes | | 3-state | yes | | Open_drain | yes | | I/O_open_drain | yes | | Open_sink | yes | | I/O_open_sink | yes | | Open_source | yes | | I/O_open_source | yes | | Input_ECL | yes | | Output_ECL | yes | | I/O_ECL | yes | | Terminator | yes | | | | | Test that the parser issues | | | a warning if an input type model | yes | Stephen Peters | does not have Vinh or Vinl defined. | | | For All I/O_* cases. | yes | Bob Ross | | | | | | | Test that the parser issues an | | | error if the Model_type or C_comp | yes | Stephen Peters | sub-parameters are missing. | | | | | | Test that the parser accepts a | | | [Model] description with only the | | | Model_type and C_comp sub-params | yes | Stephen Peters | defined. | | | | | | Test that the parser allows NA in | | | the min and max columns only of the | yes | Stephen Peters | C_Comp sub-parameter. | | | | | | Test that the parser allows only | | | Non-inverting and Inverting as | yes | Stephen Peters | choices for the Polarity sub-param | | | | | | Test that the parser allows only | | | Active-High and Active-Low as | yes | Stephen Peters | choices for the Enable sub-param | | | | | | Test that the parser recognizes | | | the Vmeas, Cref, Rref and Vref | yes | Stephen Peters | sub-parameters. | | | | | | --------------------------------------+-----+-----------------------------+ Temperature keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Temperature Range] keyword | | | | | | --------------------------------------+-----+-----------------------------+ Power supply rail related: | | | | | | Test that the parser recognizes | | | the supply rail keywords | | | [Voltage Range] | yes | Stephen Peters | [Pullup Reference] | " | | [Pulldown Reference] | " | | [POWER Clamp Reference] | " | | [GND Clamp Reference] | " | | | | | Test that the parser issues an | | | error if the [Voltage Range] | | | keyword is absent and all four of | | | the other supply rail keywords are | yes | Stephen Peters | NOT present. | | | | | | --------------------------------------+-----+-----------------------------+ I/V table related: | | | | | | Test that the parser recognizes | | | the [Pullup], [Pulldown], [GND | yes | Stephen Peters | Clamp] and [Power Clamp] keywords. | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | Test that the parser issues an | yes | Bob Ross | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Stephen Peters | than two points. | | | | | | Test that the parser issues a | yes | Bob Ross | warning if non-monotonic data | | | is found. | | | Test for One Warning per Column | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Terminator related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Rgnd], [Rpower], [Rac] and | | | [Cac] keywords. | | | | | | Test if [Rac], then [Cac] req'd. | yes | Bob Ross | | | | Test if [Cac], then [Rac] req'd. | yes | Bob Ross | | | | Test if parser issues an error with | | | above keywords AND Model_type is NOT | yes | Bob Ross | Terminator. | | | | | | Test that parser DOES NOT issue an | yes | Bob Ross | error if above models are NOT | | | defined. (Clamps or no components | | | can also be "Terminators") | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | --------------------------------------+-----+-----------------------------+ Ramp keyword related: | | | | | | Test that the parser recognizes | | | the [Ramp] keyword and the | yes | Stephen Peters | dv/dt_r and dv/dt_f sub-parameters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the R_load sub-parameter. | | | | | | Test that the R_load sub-parameter | yes | Stephen Peters | is optional. | | | | | | --------------------------------------+-----+-----------------------------+ Waveform Related: | | | | | | Test that the parser recognizes | | | the [Rising Waveform] and [Falling | yes | Bob Ross | Waveform] keywords. | | | | | | Test that the parser recognizes | | | the sub-parameters: | | | R_fixture | yes | Bob Ross | V_fixture | yes | | V_fixture_max | yes | | V_fixture_min | yes | | C_fixture | yes | | L_fixture | yes | | R_dut | yes | | L_dut | yes | | C_dut | yes | | | | | Test that the parser issues an | | | error if the R_fixture and | yes | Bob Ross | V_fixture sub-parameters are not | | | present. | | | | | | Test that the parser issues an | | | error if a column contains over | yes | Bob Ross | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Bob Ross | than two points. | | | | | | Test NA permitted in typical column | yes | Bob Ross | --------------------------------------+-----+-----------------------------+ |*************************************************************** | [IBIS Ver] 2.1 [File Name] pkg.ibs [File Rev] 0.1 [Date] May 25, 1995 [Source] Interconnectix Inc. [Disclaimer] Provided for modeling purposes only. Results are not guaranteed. | |*************************************************************** | [Component] PACKAGE-TEST [Manufacturer] Test File [Package] | variable typ min max R_pkg 0.0m NA NA L_pkg 0.0nH NA NA C_pkg 0.0pF NA NA | |*************************************************************** | [Pin] signal_name model_name R_pin L_pin C_pin A1 P_1 NC 2 P_2 NC 5 P_3 NC A4 P_4 NC | There is nothing stated in the | 3 P_5 NC | Spec regarding correlating | [Pin] entries and [Pin Numbers] | entries by number of pins or by | actual pin number correlation. | NO error is reported. | I assume the order can differ. [Package Model] test [Define Package Model] test [Manufacturer] anyone [OEM] this file shows [Description] some failed test cases [Number of Pins] 5 | get CRASH if changed to 1 [Pin Numbers] A1 2 3 4 5 [Model Data] [Inductance Matrix] Banded_matrix | Success! [Bandwidth] 2 [Row] A1 .01 .01 .01 [Row] 2 .01 .01 .01 [Row] 3 .01 .01 .01 [Row] 4 .01 .01 | I did not expect this triangle matrix for the last [Row] 5 | terms, but this is correct according to the Spec. .01 | Otherwise, parser will give an error. | | However, I believe the Spec is wrong. There is no | way, for example, to describe the coupling of a | 100 pin Quad Flat Pack with from pins 99 and 100 to | pin 1 (and visa-versa) when using a bandwidth of 2 | and pin 1 is centered on one edge. [Capacitance Matrix] Full_matrix | Success! [Row] A1 .01 .01 .01 .01 .01 [Row] 2 .01 .01 .01 .01 [Row] 3 .01 .01 .01 [Row] 4 .01 .01 [Row] 5 .01 [Resistance Matrix] Sparse_matrix [Row] A1 A1 .01 | Get Failure here, but if A1 changed to 1, get 2 .01 | an Incorrect Success. [Row] 2 3 .01 [Row] 3 5 .01 3 .01 6 .01 | Error Message text is not correct here. [End Model Data] [End Package Model] | [End] From bward@phoenix.net Sat May 27 08:04:19 1995 Return-Path: Received: from phoenix.net (phoenix.phoenix.net) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08268; Sat, 27 May 95 08:04:19 PDT Received: from synecdoche.phoenix.net (dial17.Phoenix.NET [199.3.234.48]) by phoenix.net (8.6.10/8.6.6) with SMTP id JAA03911 for ; Sat, 27 May 1995 09:51:13 -0500 Message-Id: Date: Sat, 27 May 95 09:55:03 CDT Reply-To: bward@phoenix.net (Bob Ward) From: bward@phoenix.net (Bob Ward) To: ibis@vhdl.org Subject: test - please ignore I have changed internet providers and am just checking the end to end connections for completeness and correctnes. Thanks for your patience. Bob Ward bward@phoenix.net From bob@icx.com Sat May 27 12:26:57 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10007; Sat, 27 May 95 12:26:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 27 May 95 12:20 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 27 May 95 12:23 PDT Message-Id: Date: Sat, 27 May 95 12:23 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD29 Banded_matrix Correction IBIS Members: In IBIS Version 2.1 under the Package Model description, the text contains a format restriction on the Banded_matrix description which is technically incorrect. BIRD29 suggests text changes to correct the problem. This issue relates to a correction to Version 2.1 and is also necessary to be resolved for proper IBISCHK2 functionality since IBISCHK2 checks for the incorrect restriction. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 29 ISSUE TITLE: Banded_matrix Correction REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 26 May 1995 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: In the Package Model description in IBIS Version 2.1, the Banded_matrix format needs to be corrected to remove a technically incorrect restriction. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The relevant portion of the original Specification is given along with edited remarks or deletion comments are designate by "|*" lines. | 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. | |**** Reword the Above 5 Paragraphs with Changes Shown: ********************* | 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 except when entering data in the last rows to define the |* coupling to the first rows. | | The first row only needs to specify the entries [1,1] through [1,1+B] since |* all 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. For row M |* the entries [M,M] through [M,M+B] are given when M+B is less than or |* equal to the size of the matrix N. | |* When M+B exceeds N, the last entries specify the coupling to the first |* rows, wrapping around and continuing in ascending order. For row M, the |* entries [M,M] ... [M,N] [M,1] ...[M,K] are given where K = mod(M+B-1,N)+1. | |* For the Banded_matrix, all rows will contain B+1 entries. | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | |**************************************************************************** | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | Also, note that it is again necessarily the case that the N'th | row of an N x N matrix has just a single entry (the diagonal entry.) | |**** Reword the Above Sentence: ******************************* | |* With this convention note that it is necessarily the case, for example, | that the N'th |* row of an N x N matrix has just a single entry (the diagonal entry). | |**************************************************************** |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION In order to reduce the size of the symmetrical matricies, there are several statements describing data entries only ON or ABOVE the main diagonal. That was the intention of the banded-matrix description. However the format prevented entering the coupling between the last pins and the first pins. A simple 4-pin example with a bandwidth of 1 illustrates the problem. The "data" entries are the two digit subscripts of the matrix entries and are shown using quote marks "". Version 2.1 does not allow defining the coupling between pin 4 and 1: [Inductance Matrix] Banded_matrix [Bandwidth] 1 [Row] 1 "11" "12" [Row] 2 "22" "23" [Row] 3 "33" "34" [Row] 4 "44" One possible solution is to augment the Banded_matrix format for the first rows by the entries that could not be entered in the last rows. This would preserve the ABOVE the diagonal convention. [Inductance Matrix] Banded_matrix [Bandwidth] 1 [Row] 1 "11" "12" "14" [Row] 2 "22" "23" [Row] 3 "33" "34" [Row] 4 "44" However, the solution proposed here is to keep the number of colums the same and to wrap around the entries for the last rows as needed. Technically the entries are BELOW the main diagonal. The "41" entry would really be entered as "14" in the reduced upper-triangle matrix data structure. [Inductance Matrix] Banded_matrix [Bandwidth] 1 [Row] 1 "11" "12" [Row] 2 "22" "23" [Row] 3 "33" "34" [Row] 4 "44" "41" This problem does not occur in the Sparse_matrix format. So the restriction text has a minor change in that portion of the Specification. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION From bob@icx.com Mon May 29 11:11:01 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04111; Mon, 29 May 95 11:11:01 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 May 95 11:04 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 May 95 11:06 PDT Message-Id: Date: Mon, 29 May 95 11:06 PDT From: bob@icx.com ( Bob Ross) To: bracken@kevily.ece.cmu.edu, ibis@vhdl.org Subject: Re: BIRD29 Banded_matrix Correction Eric: Thank you very much for your comments that are attached below. Since you were the originator of the coupling matrix extension to IBIS, your assessment of any change is critical. I interpret your response that you would favor such an "expansion" to IBIS. I will provide a revision to BIRD29 per your comments. It would be helpful to me if you could review some wording changes (and/or provide alternative text) to correctly deal with the Banded_matrix designation in IBIS. PROPOSED ADDITIONAL TEXTS DESIGNATED BY "|*" : | 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 Banded_matrix format conforms to this definition, except that it also |* allows for the off-diagonal entries to describe coupling between the first |* and last pins. The Banded_matrix format supports a constant-sized band |* of entries for each row and is not limited to be in strict compliance with |* the traditional mathematical definition. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== The BIRD29 issue is not one of mathematical purity, but of practical reality. One of the main applications is for a simple user interface format for flat pack package configurations, especially those with high pin counts and small spacing. Often pin 1 is centered along one side and next to the highest numbered pin. Even flat pack configurations for the standard logic families have pin 1 centered along one edge. I think that the "Banded_matrix" format is the natural and appropriate format, and it should be defined to support the actual coupling between adjacent pins. There is no value and there is actually harm to wait for Version 3.0 to make the technical inclusion proposed in BIRD29 because the IBISCHK2 parser would test and enforce a non-practical restriction while IBISCHK3 would operate in a different manner. Bob Ross, Interconnectix, Inc. *************************************************************************** > Date: Sun, 28 May 1995 09:20:58 -0400 > From: J Eric Bracken > Status: RO > I have two comments on the BIRD: > Comment 1: > --------- > This BIRD is more of an expansion in functionality than a "correction." > I think it's highly useful--especially for PGA's, where the pins are laid > out in a "circle" that closes back on itself. Please note, however, that > the resulting matrix is no longer "banded" in the traditional sense of > the word, because the pattern of entries will be something like this: > XX X <-- this is not present in a "banded" matrix > XXX > XXX > XXX > XXX > XXX > XXX > XXX > X XX > ^ > | > nor is this > That's why the original spec is the way it is--I thought people would > use a Sparse Matrix for this type of structure. Incidentally, this is > a simple form of a "bordered block diagonal" matrix. > Could we add a phrase or two to the spec which clarifies that the New > and Improved "banded matrix" is a generalization of the concept that's > used in most of the world's literature? This might help to avoid some > confusion with terminology. > Comment 2: > --------- > I don't like the rewording of the comment on the last paragraph of > the Sparse Matrix description. Particularly, the "for example" seems > clumsy. How about: > ** With this convention, please note that the N'th row of an > ** N x N matrix has just a single entry (the diagonal entry.) > __________________________________________________________________ > ________ ________ __ ________ > /\_______\ /\_______\ /\_\ /\_______\ J. Eric Bracken, Ph.D. > / / ______// / ____ // / // / ______/ Visiting Lecturer, Dept. of ECE > / / /__\ / / /__\/ // / // / / Carnegie Mellon University > / / ____/ / / ___ _// / // / /___ Pittsburgh, PA 15213 > / / /____\ / / / \/ / / / // / /____\ (412) 268-8944 FAX (412) 268-3204 > \/_______/ \/_/ \/_/ \/_/ \/_______/ eric.bracken@ece.cmu.edu > http://www.ece.cmu.edu/afs/ece/usr/bracken/.home-page.html > __________________________________________________________________ From bob@icx.com Mon May 29 13:08:27 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04759; Mon, 29 May 95 13:08:27 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 May 95 13:02 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 29 May 95 13:04 PDT Message-Id: Date: Mon, 29 May 95 13:04 PDT From: bob@icx.com ( Bob Ross) To: bward@phoenix.com, ibis@vhdl.org Subject: Bird27 revision proposal To Bob Ward: We discussed BIRD27 at the May 26, 1995 Forum, and one action item was to suggest text changes to couple explicitly the [Diff_Threshold] proposal with some [Diff_Pin] format simplifications, as intended. Here is a cut at some modifications. At this time I do not necessarily endorse this change because it does add some parsing complication to get some (non-essential) benefit. However, the intention is very good and worthy of real consideration for Version 3.0. Please review these changes and with your input send out BIRD27.1 Bob Ross, Interconnectix, Inc. Buffer Issue Resolution Document (BIRD) BIRD ID#: 27.1 ISSUE TITLE: Propose new keyword to specify default diffrential threshold REQUESTOR: Bob Ward Texas Instruments DATE SUBMITTED: 03APR95 DATE MODIFIED: 29MAY95 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The proposal is made to include a new keyword [diff_threshold] to set the default value of differential threshold voltage. This is similar in spirit to the use of Lpkg, Rpkg, and Cpkg to set default values for pins. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) An Optional keyword is defined after each [Component] along with the [Manufacturer] and [Package] keywords where component or package defaults are collected. |========================================================================= | Keyword: [Diff_Threshold] | | Required: No | | Description: Specifies the default value for the differential threshold | voltage of a differential input pin pair. If thresholds | are set on individual pin pairs, these override the default | specifed here. | | Usage Rules: This keyword is to be specified only if diffential pin | pairs are specified, although no harm will come from | specifying it otherwise. | |* Delete this (redundant) sentence. |* If diff pins are then not |* specified, only some redundant work is done since an unused |* default is all that is changed and so no harm is done. | |------------------------------------------------------------------------- [Diff_Threshold] 420mv | Set default differential threshold to .420 V | (2) The [Diff_Pin] keyword is modified with changes shown by "|*" : |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The forth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh and | Vinl. | | If vdiff is not defined for a pin that is defined as requiring a | Vinh by its [Model] type, vdiff is set to the default value of | 200mV. | |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | one [Model] to be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | |* Each line must contain two, four or six columns. Only the |* inv_pin header needs to be listed if only two columns are |* entered. The vdiff values use the [Diff_Threshold] value |* if defined and 200mV if not defined for all differential input |* thresholds of Input and I/O pins, and 0V otherwise. All |* tdelay values are set to 0ns. |* |* If four columns are entered, the vdiff and tdelay_typ headers |* must be listed. If six columns are entered, the tdelay_min |* and tdelay_max headers must be listed. |* | 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. {sentence deleted} |* Remove this sentence: |* 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 |* 25 24 | Illustrates a two column format using |* | [Diff_Threshold] value | |============================================================================== ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: We have a differential switch matrix chip for telecom switching ( yes, it is digital! ) which has rather larger threshold than the 200mv provided as a default by the present spec. It also has a large number, several tens, of input pin pairs. It would be desireable to be able to set this threshold without having to specify it on each pin pair. It could still be specified per pin pair, and that specification would override this default. This keyword only specifies a default value other than the fixed value stated in the present spec. This keyword is in exactly the same spirit as the default package parasitics keywords. A [Diff_Pin] two-column format extension is proposed since that will conform to many practical applications, especially with the [Diff_Threshold] default entry method. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: It is conceivable that this keyword could specify typ, min, and max values, but this is not seen as necessary at this time. From cer@Cadence.COM Tue May 30 06:10:41 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15428; Tue, 30 May 95 06:10:41 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA08212 for ; Tue, 30 May 1995 06:04:42 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma008206; Tue May 30 06:04:31 1995 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA20362; Tue, 30 May 95 06:03:23 -0700 Received: by oahu (5.65+/1.5) id AA25980; Tue, 30 May 95 09:04:27 -0400 Date: Tue, 30 May 95 09:04:27 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9505301304.AA25980@oahu> To: ibis@vhdl.org Subject: BIRD29: Banded_matrix Hello, Eric's comments on this Bird are very good. The proper choice of terms for the syntax is very important to make the meaning more clear to future users. Since "banded matrix" has a widely understood meaning that does not include the extensions envisioned in Bird 29 I vote for changing the name. Eric suggests (indirectly) using "bordered_block". I'm not sure this is the best word for it. Any other suggestions? Chris Reid From bob@icx.com Tue May 30 09:19:01 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16763; Tue, 30 May 95 09:19:01 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 May 95 09:12 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 May 95 09:15 PDT Message-Id: Date: Tue, 30 May 95 09:15 PDT From: bob@icx.com ( Bob Ross) To: 75123.3477@compuserve.com, ibis@vhdl.org Subject: Re: Open parser issues Cc: 73053.721@compuserve.com Ron: Commenting out the [Pin Numbers] entries is one way to get Segmentation faults on a Sun Unix system. The same file is attached, but with pin 5 commented out. Bob Ross, Interconnectix, Inc. > Hello Bob, > Thanks for the feedback. > A couple of open issues: > [1] Fixed bug when Number_of_Pins < actual Pin_Numbers list count > (mtx.c:323:assertion failed). However, you also mentioned a > segmentation fault not associated with an assertion. I have so > far been unable to locate (still looking, Bounds Checker is not as > slick as Purify). If you have an ibs file that demos this > failure, I would appreciate a copy of the relevant section. > [2] "Banded_matrix last rows must contain fewer entries" - Please let me > know if you get consensus on a change to this area. > [3] "Pin" to "Pin_Numbers" correlation - Again, please let me know if > consensus is achieved on a change. > thanx, ron |*************************************************************** | [IBIS Ver] 2.1 [File Name] pkg.ibs [File Rev] 0.1 [Date] May 25, 1995 [Source] Interconnectix Inc. [Disclaimer] Provided for modeling purposes only. Results are not guaranteed. | |*************************************************************** | [Component] PACKAGE-TEST [Manufacturer] Test File [Package] | variable typ min max R_pkg 0.0m NA NA L_pkg 0.0nH NA NA C_pkg 0.0pF NA NA | |*************************************************************** | [Pin] signal_name model_name R_pin L_pin C_pin A1 P_1 NC 2 P_2 NC 5 P_3 NC A4 P_4 NC | There is nothing stated in the | 3 P_5 NC | Spec regarding correlating | [Pin] entries and [Pin Numbers] | entries by number of pins or by | actual pin number correlation. | NO error is reported. | I assume the order can differ. [Package Model] test [Define Package Model] test [Manufacturer] anyone [OEM] this file shows [Description] some failed test cases [Number of Pins] 5 | get CRASH if changed to 1 [Pin Numbers] A1 2 3 4 | 5 | Commenting out [Pin Numbers] | entries can produce Segmentation | faults [Model Data] [Inductance Matrix] Banded_matrix | Success! [Bandwidth] 2 [Row] A1 .01 .01 .01 [Row] 2 .01 .01 .01 [Row] 3 .01 .01 .01 [Row] 4 .01 .01 | I did not expect this triangle matrix for the last [Row] 5 | terms, but this is correct according to the Spec. .01 | Otherwise, parser will give an error. | | However, I believe the Spec is wrong. There is no | way, for example, to describe the coupling of a | 100 pin Quad Flat Pack with from pins 99 and 100 to | pin 1 (and visa-versa) when using a bandwidth of 2 | and pin 1 is centered on one edge. [Capacitance Matrix] Full_matrix | Success! [Row] A1 .01 .01 .01 .01 .01 [Row] 2 .01 .01 .01 .01 [Row] 3 .01 .01 .01 [Row] 4 .01 .01 [Row] 5 .01 [Resistance Matrix] Sparse_matrix [Row] A1 A1 .01 | Get Failure here, but if A1 changed to 1, get 2 .01 | Incorrect Success. [Row] 2 3 .01 [Row] 3 5 .01 3 .01 6 .01 | Error Message text is not correct here. [End Model Data] [End Package Model] | [End] From mbs@eos.ncsu.edu Tue May 30 10:31:11 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17289; Tue, 30 May 95 10:31:11 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08426; Tue, 30 May 1995 13:25:06 -0400 From: mbs@eos.ncsu.edu Message-Id: <9505301725.AA08426@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: Re: Model list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 May 95 13:25:05 EDT Recently it was proposed that a list of IBIS models be posted every month. Currently I post any new models as I put them in the library. Until the number of models becomes very large I will attach a listing of all models to the new model posting. Michael Steer IBIS model librarian From bob@icx.com Tue May 30 18:56:40 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27891; Tue, 30 May 95 18:56:40 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 May 95 18:50 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 May 95 18:52 PDT Message-Id: Date: Tue, 30 May 95 18:52 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD28 Pkg Extension Comments Stephen Peters and IBIS team: I believe BIRD28 is very good. I do have a few points for consideration and improvement and simplification. (1) I am wondering whether the [Unit Length] keyword is necessary. It opens up the door to specifying which units are to be acceptable. It is unclear who would use this feature since the representation is already in terms of electrical parameters. (2) As a comment, there is no limit to the number of sections, just as there is no limit to the matrix size. At this time, it may be premature to provide any limits since package sizes and complexity are increasing. (3) The syntax for [Model Data] section xxx and [End Model Data] section xxx contains the word "section" which seems unnecessary. Some other keywords in IBIS ([Bandwidth] xxx, [File Rev] xxx, [Manufacturer] yyyy, etc.), which do not convey header information are based on a single parameter following the keyword or other types of data structures composed totally of data and no "subparameter" text. To maintain some syntactical consistency, it might be better to introduce [Section Data] xxx and [End Section Data] xxx and not create a dual mode way of defining [Model Data] and [End Model Data] with an unneeded subparameter. (4) The main comment I have concerns some syntactical refinements to the [Pin Numbers] format. The example in the BIRD is used as a basis for comments: |----------------------------------------------------------------------------- [Pin Numbers] A1 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 A2 L:1.2n, Len:0.7 Matrix, Len:0.47 L: 6.21n C:3.34p R:0.01 A3 , , Len:1.3 Matrix, , A4 Len:0 L:1.2n, Len:1.0 Matrix, Len:0.47 L: 8.35n \ C:3.34p R:0.01 A5 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01 | . | . | . A10 Len:0.1 1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:2.2p R:0.01 (a) Three new characters are introduced ("," ":" and "\") all of which can exist as [Comment Char] choices. To introduce these would also require an exclusion of these as comment character choices. (b) The line continuation method using "\" is inconsistent with the method used for [Full_matrix] and [Banded_matrix] data. Since the number of sections is known, it would be more consistent to rely on a similar counting method. This can be achieved through a termination character for each section. I would propose using "/" since it is already disallowed as a comment character in place of "," and also at the end of the last section. The extended line ends when all of the "/" entries are encountered. (c) Based on the example, there is implication that no white space is permitted after the subparameters "Len:", "L:", "C:", "R:". Is ":" part of the subparameter or is it a separator. Is Len : 0 acceptable?. Is Len:123 acceptable where there is no space between the subparameter and the data? I would propose using "=" in place of ":" and permit white space or no white space on either side of "=" in the familiar manner that "=" is used. (d) The syntactical flexibility using ", ," to zero out a section creates parsing complication and encourages some formatting sloppiness with no necessary technical benefit. I would encourage a fixed, more rigid structure such that each section must start with "Len" and end with "/". Shorted, zero-length sections would still require the Len=xxx or Len=0, but contain no other entries. Similarly, lumped element begins with Len=0 and per unit length elements begin with Len=xxx as the designate beginning. The "/" always terminates each section. With these comments, the revised example may look like this: |----------------------------------------------------------------------------- [Pin Numbers] A1 Len=0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / A2 Len=0 L=1.2n / Len=0.7 Matrix / Len=0.47 L= 6.21n C=3.34p R=0.01 / A3 Len=0 / Len=1.3 Matrix / Len=0 / A4 Len=0 L=1.2n / Len=1.0 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / A5 Len=0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / | Another possible grouping | . | . | . A10 Len=0.1 1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=2.2p R=0.01 / (e) Also the syntax should support one of "L", "C" and "R" in any order and with any or all of these optional. This is consistent with the order flexability of L_pkg, C_pkg and R_pkg and of L_pin, C_pin, and R_pin. (5) As a final note, there is a practical, technical trap associated with Matrix and Len. A primary assumption with respect to matricies of parameters per unit length is that the coupling matrix applies to physical, parallel sections that are of the SAME length. Suppose this is a portion of the package layout: ____________________ B1 |___________________| ______________________________ B2 |_____________________________| __________ B3 |_________| | 1 | 2 | 3 | The specification might be: B1 ... Len=2 Matrix / ... B2 ... Len=3 Matrix / ... B3 ... Len=1 Matrix / ... An APPROXIMATE way to handle the analysis at B2 is to assume ALL nearby sections are of equal length, Len=2. The matricies reference by Matrix would be scaled by 2 assuming that they are derived using the cross section topology at "1". You do not scale rows or columns of "Matrix" matricies individually by the respective actual lengths. A more accurate way of handing this would be to use Len=1 and the "Matrix" matricies for the first parallel segment, derive a DIFFERENT cross-section "Matrix" set, scale by Len=1 to be cascaded. Unfortunately, I understand that the "Matrix" set for the second section cannot be derived from the original "Matrix" set. The third section would be treated as a single, uncoupled line, using another set of parameters that are NOT available from the original "Matrix" set. So, even though there is individual length resolution, the information provided is not sufficient to exactly process these individual differences. An AVERAGE Len for the nearby topology should give a very good approximation when the lengths are approximately the same, and be less accurate when there are significant differences. Bob Ross, Interconnectix, Inc. From uunet!qdt.com!jonp@uunet.uu.net Wed May 31 09:51:43 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09105; Wed, 31 May 95 09:51:43 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyscx03651; Wed, 31 May 1995 12:45:29 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 31 May 1995 12:45:29 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00478; Wed, 31 May 95 08:37:20 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28556; Wed, 31 May 95 08:44:18 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyscs12997; Wed, 31 May 1995 11:41:08 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 31 May 1995 11:41:07 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00405; Wed, 31 May 95 08:08:34 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28397; Wed, 31 May 95 08:15:33 PDT Date: Wed, 31 May 95 08:15:33 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505311515.AA28397@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA26345; Wed, 31 May 95 08:11:32 PDT To: uunet!uunet!icx.com!bob@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: (uunet!icx.com!bob) Subject: Re: BIRD28 Pkg Extension Comments I must agree with everything that Bob said. In addition, I would appreciate a clarifying example that indicated how one would represent the following structure: This may be the same as Bobs, though it seems that a segment that starts after the other segments is a problem. I think the gist of it is I don't see how to specify more that one matrix. ____________________ B1 |___________________| ______________________________ B2 |_____________________________| __________ B3 | ________| || || || || || || || || || ||-------- || |_________ | 1 | 2 | 3 | jon From sandeep@Cadence.COM Wed May 31 11:03:42 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09812; Wed, 31 May 95 11:03:42 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA04447; Wed, 31 May 1995 10:57:23 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma004434; Wed May 31 10:57:13 1995 Received: from gda by cadence.Cadence.COM (5.61/3.14) id AA24190; Wed, 31 May 95 10:57:10 -0700 Received: from [158.140.113.1] by gda (5.65+/1.5) id AA00827; Wed, 31 May 95 13:56:45 -0400 Date: Wed, 31 May 95 13:56:45 -0400 Message-Id: <9505311756.AA00827@gda> To: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) From: sandeep@cadence.com (Sandeep Khanna) X-Sender: sandeep@gda Subject: The IBIS Placard Cc: ibis@vhdl.org Hi Jon, I remember from a while ago there was some talk about IBIS Placards at DAC in everyone's booth. Did something come of it. Are the various companies supporting it... If so who is distributing them? Thanks and best regards, Sandeep From uunet!qdt.com!jonp@uunet.uu.net Wed May 31 14:48:00 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12195; Wed, 31 May 95 14:48:00 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQysdq17775; Wed, 31 May 1995 17:41:54 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 31 May 1995 17:41:52 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00984; Wed, 31 May 95 13:38:52 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA29920; Wed, 31 May 95 13:45:51 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQysdm03303; Wed, 31 May 1995 16:41:38 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 31 May 1995 16:41:36 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00869; Wed, 31 May 95 12:43:50 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA29783; Wed, 31 May 95 12:50:49 PDT Date: Wed, 31 May 95 12:50:49 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9505311950.AA29783@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA26871; Wed, 31 May 95 12:46:48 PDT To: uunet!uunet!cadence.com!sandeep@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!qdt.com!jonp@uunet.uu.net In-Reply-To: <9505311756.AA00827@gda> (uunet!cadence.com!sandeep) Subject: Re: The IBIS Placard Sandeep, I have been making numerous announcements over the reflector about the availability of the placards. I have also been asking for computer ready Logos from companies for the IBIS BOF presentation. Candence has been absent from all replies. I need a pcx or bmp logo right away. The placards you can pick up at DAC. jon From jonp@qdt.com Wed May 31 17:51:02 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14364; Wed, 31 May 95 17:51:02 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQysed23334; Wed, 31 May 1995 20:45:04 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 31 May 1995 20:45:02 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01184; Wed, 31 May 95 15:47:27 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA00924; Wed, 31 May 95 15:54:26 PDT Date: Wed, 31 May 95 15:54:26 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9505312254.AA00924@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA26894; Wed, 31 May 95 15:50:25 PDT To: ibis@vhdl.org Subject: LOGO at DAC I have received printable logos from the following companies: Hyperlynx Zuken-Redac National Semi Incases ATT GIS Zeelan META Software CONTEC QUANTIC UNICAD Intergraph Mentor Graphics Intergraph Electronics Interconnectix Quad Design If your name is not on this list and you want it to be (or think it should be) you need to contact me soonest. I recommend email to jonp@qdt.com The ideal art is PCX or BMP, uuencoded and emailed to jonp@qdt.com This is a cool slide that could easily turn into a poster and you REALLY want to participate. (now, if only I could figure how to make the Quad Design logo smaller .... ) jon From bward@phoenix.net Wed May 31 19:50:43 1995 Return-Path: Received: from phoenix.net (phoenix.phoenix.net) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15161; Wed, 31 May 95 19:50:43 PDT Received: from synecdoche.phoenix.net (dial21.phoenix.net [199.3.234.56]) by phoenix.net (8.6.10/8.6.6) with SMTP id VAA04196 for ; Wed, 31 May 1995 21:45:34 -0500 Message-Id: Date: Wed, 31 May 95 21:33:25 CDT Reply-To: bward@phoenix.net (Bob Ward) From: bward@phoenix.net (Bob Ward) To: ibis@vhdl.org Subject: re: Name for new banded matrix structure All - I have looked in several books on matrix topics and find that there are two names used for matrices structured as this one turns out. One is the bordered block banded form Eric mentioned, and one is augmented banded. In either case what we end up here is a slightly degenerate form of the real thing, but it would seem to work in practice for what we want to accomplish by it. It would not be used in the stated form for computation, but must be transformed by the paerser to a "more correct" form for computation in any case. But one question occurs to me ... would it not make the parse a little simpler if the entries were augmented into the first rows rather than the last, to avoid having to reverse the subscripts when placing the values? What I am afraid of is another situation like the Vdd relative pullup IV table, correct but confusing, especially to newcomers to ibis. I can make the argument that there is a special case to be handled in either case, but the first row approach seems more like seeing what you get. All the best, Bob Ward bward@phoenix.net