From cer@Cadence.COM Thu Jun 1 06:01:03 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23706; Thu, 1 Jun 95 06:01:03 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id FAA16164 for ; Thu, 1 Jun 1995 05:55:03 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma016117; Thu Jun 1 05:54:57 1995 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA22078; Thu, 1 Jun 95 05:54:54 -0700 Received: by oahu (5.65+/1.5) id AA02971; Thu, 1 Jun 95 08:54:53 -0400 Date: Thu, 1 Jun 95 08:54:53 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9506011254.AA02971@oahu> To: ibis@vhdl.org Subject: re: Name for new banded matrix structure Bob and all, Thanks for looking up the names for these matrixes. Especially since we already have models that use the [banded] keyword for a truly banded matrix format I think we should define a new keyword [augmented] or [augmented banded]. Otherwise how is a parser to know which matrix type is being used? I think we should make it explicit with a new keyword. Also, in many cases the current [banded] format is sufficient, and is easier to handle in the software, so we should have both keywords. As to where to put the "augmented entries" I prefer putting them on the end of the matrix since that seems somehow more natural to me. The parsers can handle this easily enough so I don't think that is an issue (I know because I wrote the parser Cadence is using). So, I vote for two keywords: [banded] Banded symmetric matrix (current format) [augmented] Augmented banded symmetric matrix as in the recent Bird. Chris Reid From Arpad_Muranyi@ccm.fm.intel.com Thu Jun 1 08:41:29 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25020; Thu, 1 Jun 95 08:41:29 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sHCHG-000UoOC; Thu, 1 Jun 95 08:35 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sHCHF-000twfC; Thu, 1 Jun 95 08:35 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 01 Jun 95 08:35:17 PDT Date: Thu, 01 Jun 95 08:31:00 PDT From: Arpad Muranyi Message-Id: To: bob@icx.com, ibis@vhdl.org Subject: Re: BIRD28 Pkg Extension Comments Text item: Thank you Bob, You actually verbalized one of my thoughts in your comments, so I am not going to restate it. (It was about the usage of the ":" character). Also, I agree with your response based on my first glance at it. You raise a very good point about the extra characters and the comment character issue. Arpad Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: BIRD28 Pkg Extension Comments To: ibis@vhdl.org From: bob@icx.com ( Bob Ross) Date: Tue, 30 May 95 18:52 PDT Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 May 95 18:52 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 30 May 95 18:50 PDT 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: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 30 May 95 18 :52:51 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sGcxo-000txIC; Tue, 30 May 95 18:52 PDT From bob@icx.com Thu Jun 1 10:12:11 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25603; Thu, 1 Jun 95 10:12:11 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 1 Jun 95 10:06 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 1 Jun 95 10:08 PDT Message-Id: Date: Thu, 1 Jun 95 10:08 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: re: BIRD29 Name for new banded matrix structure To IBIS team and commentors: I believe the need for a revised matrix structure which utilizes the "banding" format efficiency is apparent and not being debated. Two issues are emerging: (1) Do we really require another alternative keyword to support "banding" with no end-to-end coupling and "banding" with end-to-end coupling. I would hope not because the original banding method does have the technical format restriction which the revised method would overcome and serve as the proper method. I would hope that any existing implementations could be updated at the "next release" to make the revised version of banding the standard way. (2) The second issue concerns terminology. I believe the existing terminology can also be used for the revised structure by thinking in terms of an augmented matrix structure as Bob Ward and Chris Reid have mentioned: To paraphrase from MATRIX COMPUTATIONS by Golub and Van Loan, pg. 6, "We say that an N x M matrix A has a lower bandwidth of r and an upper bandwidth of s if a(i,j) = 0 whenever i > j + r and j > i + s. If r = s, then A is simply said to have bandwidth r." For package model descriptions what we really want is the matrix of the form Eric presented: 1 2 3 4 5 6 7 8 1 X X X X X 2 X X X X X 3 X X X X X 4 X X X X X 5 X X X X X 6 X X X X X 7 X X X X X 8 X X X X X By augmenting the matrix (by repeating columns 1...B) we enter only the upper triangle data corresponding to this: 1 2 3 4 5 6 7 8 1 2 1 X X X 2 X X X 3 X X X 4 X X X 5 X X X 6 X X X 7 X X X 8 X X X Because a(i,j) = a(j,i), we have from this format all of the information needed to populate the original N x N matrix. Furthermore, this is really a Banded_matrix according to the definition for an N x M matrix when filling in the implied lower-triangle terms which did not need to be entered: 1 2 3 4 5 6 7 8 1 2 1 X X X 2 X X X X 3 X X X X X 4 X X X X X 5 X X X X X 6 X X X X X 7 X X X X X 8 X X X X X So my preference would be to stay with the three matrix formats, but to update the definition. Bob Ross, Interconnectix, Inc. From cer@Cadence.COM Thu Jun 1 10:48:46 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25910; Thu, 1 Jun 95 10:48:46 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA16732 for ; Thu, 1 Jun 1995 10:42:45 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma016709; Thu Jun 1 10:42:33 1995 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA12785; Thu, 1 Jun 95 10:42:28 -0700 Received: by oahu (5.65+/1.5) id AA03200; Thu, 1 Jun 95 13:42:30 -0400 Date: Thu, 1 Jun 95 13:42:30 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9506011742.AA03200@oahu> To: ibis@vhdl.org Subject: re: BIRD29 Name for new banded matrix structure Bob and others, Yes, we could manage without a new keyword, overloading the meaning of [banded], but I think it is better to add a new keyword [augmented], or possibly to add some other notation to the matrix definition to indicate to the parser the intention of augmenting the matix. One of the functions of the parser is to make sure the data is valid, which is partially lost if we start overloading keywords. Tools that do not have strong syntax checking are generally much harder to use than those that do because small errors can be difficult to find without automatic checking. So, I still vote for a new keyword, [augmented]. Chris Reid From mbs@eos.ncsu.edu Thu Jun 1 13:31:34 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 AA27453; Thu, 1 Jun 95 13:31:34 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA18024; Thu, 1 Jun 1995 16:25:32 -0400 From: mbs@eos.ncsu.edu Message-Id: <9506012025.AA18024@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: NEW IBIS MODEL Date: Thu, 01 Jun 95 16:25:32 EDT Announcing a new ibis model It can be found in /pub/ibis/models/national/superI_O pc87306.ibs superI_O 05-25-95 1.0 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int ------------------------- The current contents of the ibis model library a listed below. 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 2537v.ibs cgs 04-17-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) pc87306.ibs superI_O 05-25-95 1.0 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int 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. From Will_Hobbs@ccm2.jf.intel.com Thu Jun 1 14:23:33 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27839; Thu, 1 Jun 95 14:23:33 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sHHcS-000Un0C; Thu, 1 Jun 95 14:17 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sHHcS-000txRC; Thu, 1 Jun 95 14:17 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Thu, 01 Jun 95 14:17:32 PDT Date: Thu, 01 Jun 95 14:14:00 PDT From: Will Hobbs Message-Id: To: cer@Cadence.COM, ibis@vhdl.org Subject: Re: BIRD29: Banded_matrix Text item: Chris, How about one of the following: - feathered matrix - red-breasted matrix Sorry :-) Will 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 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: BIRD29: Banded_matrix To: ibis@vhdl.org Message-Id: <9505301304.AA25980@oahu> From: cer@cadence.com (Chrisopher E. Reid) Date: Tue, 30 May 95 09:04:27 -0400 Received: by oahu (5.65+/1.5) id AA25980; Tue, 30 May 95 09:04:27 -0400 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA20362; Tue, 30 May 95 06:03:23 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma p (V1.0mjr) id sma008206; Tue May 30 06:04:31 1995 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA0821 2 for ; Tue, 30 May 1995 06:04:42 -0700 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 vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 30 May 95 06 :55:11 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 30 May 9 5 06:55:17 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sGRlP-000twiC; Tue, 30 May 95 06:55 PDT From Will_Hobbs@ccm2.jf.intel.com Thu Jun 1 14:27:51 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27849; Thu, 1 Jun 95 14:27:51 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sHHg7-000UnNC; Thu, 1 Jun 95 14:21 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sHHg5-000twVC; Thu, 1 Jun 95 14:21 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Thu, 01 Jun 95 14:21:17 PDT Date: Thu, 01 Jun 95 14:16:00 PDT From: Will Hobbs Message-Id: To: mbs@eos.ncsu.edu, ibis@vhdl.org Subject: Re[2]: Model list Text item: Sounds good to me. Will 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 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***. Date: Tue, 30 May 95 13:25:05 EDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Subject: Re: Model list To: ibis@vhdl.org Message-Id: <9505301725.AA08426@mbs.ece.ncsu.edu> From: mbs@eos.ncsu.edu Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08426; Tue, 30 May 1995 13:25:06 -0400 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: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 30 May 95 11 :10:47 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 30 May 9 5 11:10:58 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sGVkr-000tx6C; Tue, 30 May 95 11:11 PDT From huq@rockie.nsc.com Thu Jun 1 15:02:45 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28163; Thu, 1 Jun 95 15:02:45 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA01593 for ibis@vhdl.org; Thu, 1 Jun 95 14:56:41 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA14649 for ibis@vhdl.org; Thu, 1 Jun 95 14:56:28 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA05707; Thu, 1 Jun 95 14:58:05 PDT Date: Thu, 1 Jun 95 14:58:05 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9506012158.AA05707@rockie.nsc.com> To: ibis@vhdl.org Subject: Re: Re[2]: Model list Mike, Is there any way you can provide some kind of info on 'who' and 'how many times' any models get copied out of the models dir. This information is only for the companies providing the models. We would be very interested to know these kinds of statistics if you can provide them on a monthly basis. Best Regards, Syed. National Semiconductor. > > Text item: > > Sounds good to me. > > Will > > 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 Thu Jun 1 16:12:40 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28591; Thu, 1 Jun 95 16:12:40 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 1 Jun 95 16:06 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 1 Jun 95 16:08 PDT Message-Id: Date: Thu, 1 Jun 95 16:08 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, uunet!qdt.com!jonp@uunet.uu.net Subject: Re: BIRD28 Pkg Extension Comments Jon: I do not have a good answer to the problem you posed, especially when you extend the concept to many pins. However, I would approach this with several uncoupled sections at the beginning and end, and two matrix sections in the middle. The format would be of the form B1 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=0 / Len=0 / B2 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=1 L=x C=x / Len=0 / B3 Len=1 L=y C=y / Len=1 Matrix / Len=1 Matrix / Len=1 L=y C=y / Len=1 L=z C=z / Both Matrix sections would likely be Sparse_matrix types. The first one would describe the B1-B2 section "1" and would have no B3 row/column entries (forcing zero values). The second one would describe the B1-B2-B3 section "2". Allowance is provided for one initial transmission line section and two final transmission line sections for this example. The pins that do not need these sections will have some Len=0 / zero-length sections. The alternative to a description of this detail would be to adopt a different, coupled lumped approach describe B1-B2-B3("2") as one coupled L-C-R value matrix (length would not be needed since the "total" values used would already reflect the length) to capture all of the coupling in. This may not be as accurate an approach, but may have some practical value. Bob Ross, Interconnectix, Inc. > 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 |_____________________________| > __________ x > B3 | ________| > || || > || || > y || || y > || || z > || ||-------- > || |_________ > | 1 | 2 | 3 | > jon From jonp@qdt.com Thu Jun 1 18:18:56 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29491; Thu, 1 Jun 95 18:18:56 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyshw24259; Thu, 1 Jun 1995 21:12:56 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Thu, 1 Jun 1995 21:12:56 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01525; Thu, 1 Jun 95 16:52:44 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA06841; Thu, 1 Jun 95 16:59:45 PDT Date: Thu, 1 Jun 95 16:59:45 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9506012359.AA06841@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA28381; Thu, 1 Jun 95 16:55:43 PDT To: ibis@vhdl.org, bob@icx.com Subject: [uunet!icx.com!bob: Re: BIRD28 Pkg Extension Comments] bob, in the following example, how do the keywords "Matrix" map into the actual specication of the matrices. I guess that I think wee need matrix names to avoid an absolute numbering confusion. Anyway, this is the essence of my problem. jon ******************* attached message ******************** Return-Path: Date: Thu, 1 Jun 95 16:08 PDT From: uunet!icx.com!bob ( Bob Ross) To: uunet!vhdl.org!ibis, uunet!uunet!qdt.com!jonp Subject: Re: BIRD28 Pkg Extension Comments Jon: I do not have a good answer to the problem you posed, especially when you extend the concept to many pins. However, I would approach this with several uncoupled sections at the beginning and end, and two matrix sections in the middle. The format would be of the form B1 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=0 / Len=0 / B2 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=1 L=x C=x / Len=0 / B3 Len=1 L=y C=y / Len=1 Matrix / Len=1 Matrix / Len=1 L=y C=y / Len=1 L=z C=z / Both Matrix sections would likely be Sparse_matrix types. The first one would describe the B1-B2 section "1" and would have no B3 row/column entries (forcing zero values). The second one would describe the B1-B2-B3 section "2". Allowance is provided for one initial transmission line section and two final transmission line sections for this example. The pins that do not need these sections will have some Len=0 / zero-length sections. The alternative to a description of this detail would be to adopt a different, coupled lumped approach describe B1-B2-B3("2") as one coupled L-C-R value matrix (length would not be needed since the "total" values used would already reflect the length) to capture all of the coupling in. This may not be as accurate an approach, but may have some practical value. Bob Ross, Interconnectix, Inc. > 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 |_____________________________| > __________ x > B3 | ________| > || || > || || > y || || y > || || z > || ||-------- > || |_________ > | 1 | 2 | 3 | > jon From mbs@eos.ncsu.edu Thu Jun 1 18:39:43 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 AA29608; Thu, 1 Jun 95 18:39:43 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA18991; Thu, 1 Jun 1995 21:33:42 -0400 From: mbs@eos.ncsu.edu Message-Id: <9506020133.AA18991@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: spice-to-ibis update Date: Thu, 01 Jun 95 21:33:41 EDT Here is an update on our (North Carolina State University) progress on the next spice-to-ibis converter (s2ibis). We are able to undertake this project thanks to the generous support of Cadence. I am putting AR items in the next paragraph so it does not get lost but it may not make much sense until you have read the whole document. AR We are using the golden parser header as distributed some 6 months ago. We AR would very much like to use the current golden parser header file. AR This would be a good topic for the next open forum meeting. The advantage AR of course is maintainability and to ensure that we complete. AR One set of code we are missing and have not started on is code to write an AR *.ibs file from the ibis data structure. Has anyone written this? We have defined a grammar for the s2ibis command input file. We have also written a yacc/lex parser to read this grammar. The Grammar is very similar to the ibis grammar. The basic strategy is to parse an s2ibis input file; set up internal data structures completely; and then initiate analyses. These analyses will be parsed and the results used to set up the internal ibis data structures. Then the *.ibs file will be generated from the data structure. This is a departure from the way version 1 of s2ibis works. This was essentially an interpreter than fired off analyses as the input file was parsed. The new scheme seems to be the only reasonable way to allow a lot of flexibility, to provide meaningful message reporting, and to provide relatively painless future expansion. We estimate that we have put 4 man-weeks in to the coding so far. We are hoping to have a working prototype of the software by June 12. This will, however have many of the desirable features missing but it will run. The whole project is like writing a reverse golden parser. Michael Steer From nirmal@ansoft.com Fri Jun 2 09:13:57 1995 Return-Path: Received: from maxwell.ansoft.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09633; Fri, 2 Jun 95 09:13:57 PDT Received: from viper ([192.149.1.17]) by maxwell.ansoft.com (4.1/SMI-4.1) id AA05753; Fri, 2 Jun 95 12:05:17 EDT Message-Id: <9506021605.AA05753@maxwell.ansoft.com> Received: by viper (1.37.109.4/16.2) id AA03472; Fri, 2 Jun 95 12:04:58 -0400 From: Nirmal Jain Subject: Please include me in your mailing list To: ibis@vhdl.org (IBIS people) Date: Fri, 2 Jun 95 12:04:58 EDT Mailer: Elm [revision: 70.85] Hi, Could you include me in your forum? My address is as follows nirmal@ansoft.com Regards Nirmal Jain -- _______________________________________________________________________________ Nirmal Jain ANSOFT CORPORATION (412) 261-3200 X29 (W) Four Station Sq., Suite 660 (412) 471-9427(FAX) Pittsburgh, PA 15219 _______________________________________________________________________________ Good Judgement comes from experience. Experience comes from bad judgement. -----Jim Horning From floresca@puhi.apple.com Fri Jun 2 10:02:35 1995 Return-Path: Received: from apple.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10095; Fri, 2 Jun 95 10:02:35 PDT Received: from [17.206.18.2] by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA27634; Fri, 2 Jun 95 09:56:24 -0700 for ibis@vhdl.org Received: from [17.206.24.75] by puhi.apple.com.portables (4.1/SMI-4.1) id AA18647; Fri, 2 Jun 95 10:02:37 PDT Date: Fri, 2 Jun 95 10:02:36 PDT Message-Id: <9506021702.AA18647@puhi.apple.com.portables> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: floresca@puhi.apple.com (Fred Floresca) Subject: Please include me on your mail list... Greetings, Please allow me to be a part of your mail list. My address is as follows: floresca@apple.com Thanks, Fred Floresca From speters@ichips.intel.com Fri Jun 2 10:24:11 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10279; Fri, 2 Jun 95 10:24:11 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 2 Jun 95 09:17:31 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 2 Jun 95 09:16:58 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 2 Jun 95 09:16:58 PDT Message-Id: <9506021616.AA19035@xtg801.intel.com> To: jonp@qdt.com Cc: ibis@vhdl.org, bob@icx.com Subject: [uunet!icx.com!bob: Re: BIRD28 Pkg Extension Comments] Date: Fri, 02 Jun 1995 09:16:56 -0700 From: Stephen Peters Hello Jon: For reference, let me repeat your drawing below: ____________________ B1 |___________________| ______________________________ B2 |_____________________________| __________ x B3 | ________| || || || || y || || y || || z || ||-------- || |_________ | 1 | 2 | 3 | Assume for a moment that all we want to describe is just what you have shown (no bondwire or pins). These three pins can be specified as follows in the [Pin Number] statement B1 Len = A Matrix / Len = B Matrix / Len = 0 B2 Len = A Matrix / Len = B Matrix / Len = C C=x L=y B3 Len = A Matrix / Len = B Matrix / Len = Z C=x L=y The first (reading left to right) matrix keyword in the pin specifications says that there is a matrix that describes the coupling between pins B1, B2 and B3 for the vertical slice labled '1' in the above diagram. This vertical slice is 'section 1' and the actual data is put between the '[Model Data] section 1' and '[End Model Data] section 1' keywords. Likewise, the second Matrix keyword says that there is another matrix for vertical slice '2' (section 2) and the parser will know to look for the [Model Data] section 2 / [End Model Data] section 2 keywords. Each possible matrix has a name; it is the section (or vertical slice) number. It occurs to me as I write this that we could explicity name each matrix -- i.e. the [Pin number] statement would look as follows: B1 Len = A Matrix1 / Len = B Matrix2 / Len = 0 B2 Len = A Matrix1 / Len = B Matrix2 / Len = C C=x L=y B3 Len = A Matrix1 / Len = B Matrix2 / Len = Z C=x L=y I don't know if this makes it any easier to understand or deal with. Anyway, I hope I got the jist of your question answered. Best Regards, Stephen Peters bob, in the following example, how do the keywords "Matrix" map into the actual specication of the matrices. I guess that I think wee need matrix names to avoid an absolute numbering confusion. Anyway, this is the essence of my problem. jon ******************* attached message ******************** Return-Path: Date: Thu, 1 Jun 95 16:08 PDT From: uunet!icx.com!bob ( Bob Ross) To: uunet!vhdl.org!ibis, uunet!uunet!qdt.com!jonp Subject: Re: BIRD28 Pkg Extension Comments Jon: I do not have a good answer to the problem you posed, especially when you extend the concept to many pins. However, I would approach this with several uncoupled sections at the beginning and end, and two matrix sections in the middle. The format would be of the form B1 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=0 / Len=0 / B2 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=1 L=x C=x / Len=0 / B3 Len=1 L=y C=y / Len=1 Matrix / Len=1 Matrix / Len=1 L=y C=y / Len=1 L=z C=z / Both Matrix sections would likely be Sparse_matrix types. The first one would describe the B1-B2 section "1" and would have no B3 row/column entries (forcing zero values). The second one would describe the B1-B2-B3 section "2". Allowance is provided for one initial transmission line section and two final transmission line sections for this example. The pins that do not need these sections will have some Len=0 / zero-length sections. The alternative to a description of this detail would be to adopt a different, coupled lumped approach describe B1-B2-B3("2") as one coupled L-C-R value matrix (length would not be needed since the "total" values used would already reflect the length) to capture all of the coupling in. This may not be as accurate an approach, but may have some practical value. Bob Ross, Interconnectix, Inc. > 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 |_____________________________| > __________ x > B3 | ________| > || || > || || > y || || y > || || z > || ||-------- > || |_________ > | 1 | 2 | 3 | > jon From bob@icx.com Fri Jun 2 11:38:55 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11113; Fri, 2 Jun 95 11:38:55 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 2 Jun 95 08:50 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 2 Jun 95 08:53 PDT Message-Id: Date: Fri, 2 Jun 95 08:53 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, jonp@qdt.com Subject: Re: BIRD28 Pkg Extension Comments] Jon: From the original BIRD28, the first matrix group would be defined as a section 2 matrix and the second matrix would be defined as a section 3 matrix. The alignment of matrix components is assumed using this syntax. Thus there are zero-element sections for the purpose of alignment. The syntax is: [Define Package Model] 3_pin_example ... [Unit Length] in [Number of Sections] 5 [Number of Pins] 3 [Pin Numbers] | section 1 section 2 section 3 section 4 section 5 B1 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=0 / Len=0 / B2 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=1 L=x C=x / Len=0 / B3 Len=1 L=y C=y / Len=1 Matrix / Len=1 Matrix / Len=1 L=y C=y / Len=1 L=z C=z / | [Model Data] section 2 [Inductance Matrix] Sparse_Matrix | Sparse matrix is used in this example [Row] B1 | to illustrate the approach for many B1 xx | more pins. B2 xx [Row] B2 B2 xx [Capacitance Matrix] Sparse_Matrix .... [End Model Data] section 2 [Model Data] section 3 [Inductance Matrix] Sparse_Matrix [Row] B1 B1 xx B2 xx B3 xx [Row] B2 B2 xx B3 xx [Row] B3 B3 xx [Capacitance Matrix] Sparse_Matrix .... [End Model Data] section 3 [End Package Model] .... This syntax is based on position within a fixed number of sections. You have a good point that another syntax that relys on matrix names rather than position may be clearer or may produce other efficiencies, but this needs to be defined and tested. Bob Ross Interconnectix, Inc. > bob, > in the following example, how do the keywords "Matrix" map into the > actual specication of the matrices. I guess that I think wee need matrix > names to avoid an absolute numbering confusion. Anyway, this is the > essence of my problem. > jon > Jon: > I do not have a good answer to the problem you posed, especially when you > extend the concept to many pins. However, I would approach this with > several uncoupled sections at the beginning and end, and two matrix sections > in the middle. The format would be of the form > B1 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=0 / Len=0 / > B2 Len=0 / Len=1 Matrix / Len=1 Matrix / Len=1 L=x C=x / Len=0 / > B3 Len=1 L=y C=y / Len=1 Matrix / Len=1 Matrix / Len=1 L=y C=y / Len=1 L=z C=z / > Both Matrix sections would likely be Sparse_matrix types. The first one would > describe the B1-B2 section "1" and would have no B3 row/column entries (forcing > zero values). The second one would describe the B1-B2-B3 section "2". > Allowance is provided for one initial transmission line section and two > final transmission line sections for this example. The pins that do > not need these sections will have some Len=0 / zero-length sections. > The alternative to a description of this detail would be to adopt a different, > coupled lumped approach describe B1-B2-B3("2") as one coupled L-C-R value > matrix (length would not be needed since the "total" values used would > already reflect the length) to capture all of the coupling in. This may > not be as accurate an approach, but may have some practical value. > Bob Ross, > Interconnectix, Inc. > > 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 |_____________________________| > > __________ x > > B3 | ________| > > || || > > || || > > y || || y > > || || z > > || ||-------- > > || |_________ > > | 1 | 2 | 3 | > > jon From uunet!qdt.com!jonp@uunet.uu.net Fri Jun 2 15:34:39 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13018; Fri, 2 Jun 95 15:34:39 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQysld25992; Fri, 2 Jun 1995 18:28:39 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 2 Jun 1995 18:28:38 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01130; Fri, 2 Jun 95 15:05:26 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA11570; Fri, 2 Jun 95 15:12:29 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyslc19334; Fri, 2 Jun 1995 18:01:32 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 2 Jun 1995 18:01:33 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01075; Fri, 2 Jun 95 14:44:43 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA11193; Fri, 2 Jun 95 14:51:46 PDT Date: Fri, 2 Jun 95 14:51:46 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9506022151.AA11193@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA28933; Fri, 2 Jun 95 14:47:42 PDT To: uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: BIRD28 Pkg Extension Comments] OK, Here is my problem. I think that BIRD28 is not very tractible for large problems. below is my textual argument and a word document with a picture. COMMENTS ON BIRD 28 Assume the simple leadframe layout as shown below. Each pin couples to each of its neighbors using 3 separarate coupling matricies. The pins do not significantly couple to anything further away than 1 pin The coupling cross-sections of interest for pin 2 are A B and C. Each of there ould be a separate matrix. I do not think that three 100 entry matrices are the way to go for this kind of discription, espcially since most of the matrix entries will be indentical, since the A coupling above will be the same entry for each 3 set of coupling wires as you go around the package. I believe that we need a mechanism that allows either for small named and re-usable matrices or ONLY allow one matrix and one coupling segment that describes the entire package. Jon Powell, 6/2/95 begin 755 ibis.doc MT,\1X*&Q&N$ .P # /[_"0 & ! M ( $ +P ( #^____ "$ #_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________]____! !0 % "@ 8 ' M" D + & P - #@ \ 0 $0 !( 3 M %0 /[___\6 %P !D #^____&@ !L < '0 !X M ? _O__________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________________________U( ;P!O '0 ( !% M &X = !R 'D M 6 4 __________\# D" # 1@ M (:TBNSM,+H! P $ Q 0!# &\ ;0!P $\ 8@!J M M !( @'_______________\ M 8@ !7 &\ <@!D $0 ;P!C '4 ;0!E &X = M &@ " ?__ M__\, _____P M '< "V#P $\ 8@!J &4 8P!T % ;P!O &P M 6 $! 0 ( $ M "&AUGK[3"Z 8:'6>OM,+H! M 0 /[___\# _O___P4 & !P @ ) "@ M L , #0 X / $ !$ 2 $P !0 5 M%@ !< 8 &0 !H ; ' !T > 'P " A M (@ ", D )0 "8 G * "D #^____*P /[_ M__\M +@ "\ P ,0 #( S - #4 V -P M #@ Y .@ #L \ /0 #X _ 0 $$ !" M0P $0 !% 1@ $< !( 20 $H !+ 3 $T !. M 3P % !1 4@ %, !4 50 %8 !7 6 %D M !: 6P %P != 7@ %\ !@ 80 &( !C 9 M &4 !F 9P &@ !I :@ /[___]L ;0 &X !O M< '$ !R

0 'H ![ M ? 'T !^ ?P ( ! /[_ PH /____\ "0( , M !&' $UI8W)O < 6 M!"$ M@$$ )D!! (! 0 $ +0$! T R"@4 F0$! 0 !P" M: %# !$ ! (! 0 $ )P'__P0 M 0 P ____________ M_______________________0SQ'@H;$:X0 [ , M_O\) 8 $ ! $ _O\#"@ _____P$) @ M P $8; 36EC0&R$!(0$ "@ " M /___P#___\ 0 !0 P $!$3 $ )@"@%[ < 0!! @ M0 ( H @ L "P P $!## $ )@ &] =@00! M " ! "@ L "P P $!$# $ )@" %A @ M 0D! "0 "@ L "P P $!#S $ )@"0 M&_ >\0,! #P P "@ L "P P $!#C $ M)@ &_ >D0"1 D "0 "@ L "P P $!#3 M $ )@" %H ?@00! " ! "@ L "P P $! M"S $ )@!P&M =D0 A 0 ( &0 "@ L "P P M $!"C $ )@" %O >\0,! #P P "@ L "P M P $!"3 $ )@ &[ <@00! " ! "@ L "P M P $!"# $ )@#@&; <(0&Q 0 L $@ 0 "@ L "P M P $!!S $ )@" %F >80,! !@ P "@ L M "P P $!!C $ )@ &Y ;@00! " ! "@ M L "P P $!!3 $ )@!0&9 ;L0%! @ 0 *P 0 M "@ L "P P $!!# $ )@" %M =T0(! #0 @ M "@ L "P P $! S $ )@ &W :@00! " M! "@ L "P P $! C $ )@# &' :00+1 @ MT ) @ "@ L "P P $! 3 $ )@" %D =00(! M ! @ "@ L "P P $! # , )@!P$; < M$04Q!@ H ____ /___P ! T,\1X*&Q&N$ M .P # /[_"0 & ! 0 ____ M____________________________________________________________ M_____________________P # 7 P & , "(# C P AP< /D #W M M M M M M M M M M M G4! MU 40$ &$ ! % , !@# : P M&P, !T# > P ( , "$# B P (P, /X > 0\ #^ 'H / _@ M /X 7@!\ #^ _@ !Z #P /X #^ _@ !X!#P M M M M M M M M M M $ D. \ " ! $L #P &@ 0/'_ @ : 9.;W)M86P @ , M80D$ "( 04#R_Z$ (@ 61&5F875L="!087)A M9W)A<&@@1F]N= , & "0 P M(P 4 (P, , _____P$ !"#__P$ ", P AP< M 0 , ",# % ! @ , $ !0 8 ' M" D * "P P - #@ \ 0 $0 !( 3 M % !4 6 (P #$# ! &,# ),# ! ,4# /4# M ! "<$ %<$ (<$ +<$ .<$ !<% $<% M '<% *<% -<% <& #<& &<& )<& ,<& M /<& "<' %<' /] 2% @4&%I;G1*970@6$P 3%!4,3H M4$%)3E1*150 2% @4&%I;G1*970@6$P * PP# M1 !, -N " $ ' !315)6 0 " ;0 @ ! +0 0#V *SV3 ", @ #0 < "8 ! -P M ( $ P D 0 "P $@! - ; $ \ "0 0 $ M +0! * V $ !( #\ 0 #@ " " ) 1 ( !, !H @ M_____________________________________________________QX ? M 0SI<5TE.5T]21%Q414U03$%415Q.3U)-04PN1$]4 M '@ H !$97-I(%%U860 M '@ H !$97-I(%%U860 M0 (8YNF;L,+H! 0 M 0 (;=33WM,+H! M P M P M0 !>T+( '@ !, !- M:6-R;W-O9G0@5V]R9" V+C P M '@ ( R M P MT,\1X P 1X*&Q&N$ .P # /[_"0 & M ! 0 $ @# _O___Z "A H@ *, M "D I0 *8 "G J *D "J JP *P "M K@ M *\ "P L0 +( "S M +4 "V MP +@ "Y MN@ +L "\ O0 +X "_ P ,$ #" PP ,0 #^ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M__________________\ # :@ M , !J :@P !J# &H, :@P !J# M% )0, E P "4# )0, E P "4 M# "@ )X, * E P \#@ ,0 *@, 6 O@P M "^# +X, O@P "^# +X, O@P M #># @ . , X P #@# '@ /X, "0 MC@T ) >#@ '@ &T. !4 P0X /4 \#@ M !J# +X, $ 4 0 ! +X, MO@P O@P "^# #P. M O@P !J# &H, O@P M J P "^# +X, O@P "^# M &H, O@P !J# +X, W@P M ?@P @ "&# #@ &H, :@P !J M# &H, O@P #># +X, @ O@P M M $%S M"!E;G1R:65S('=I;&P@8F4@:6YD96YT:6-A;"P@ M2!F;W(@96%C:" S('-E="!O9B!C;W5P;&EN9R!W:7)E%-T & P7S!O #0R%#2T 30R%#0 M !8 P@( M /_______________[H!AD771NTPN@'@ M 4\B &@"3R(@,A0T( $@,O[_ #"@ M $ #@A9_R^4]H$*N1" K)[/9, ' # . M !P )@ " W 0 # 0 " .0! , " ( L M L @ #0 % " / = ( ! "8 @ "@ +P" 2 X ( M X $ P "0 "@# 3 3 , /__________________________ M________________'@ !\ !#.EQ724Y73U)$7%1%35!,051%7$Y/4DU! M3"Y$3U0 > T $%S M "@ M $1E "@ $1E $P $UI8W)O @ M #$ # M #0SQ'@H;$:X0 [ M , _O\) /__________________________________________________ M__________________________________\ M M M M M M M M M P S@, ,\# #F P YP, .@# #I P %08 !D& #]]_WM MYO?]Y M M M M M M M M M "=0$ #74!1 3SCWDS8Q@ 2P$2=0%$!/./>3-A 1C& !V M 4L! MU 40$ &,8 -C& " # #J P ZP, &(% !C!0 %08 M /X$_\ AJ W^ ' (1@!_@ %P"$8 ?X < A& '^ / (1@! M M M M M M M M M M ! %#@ / @ M 0!+ \ !H $#Q_P( &@ &3F]R;6%L ( # &$)! M B $% \O^A "( %D1E9F%U;'0@4&%R86=R87!H($9O;G0 M 5 P P#_____!0#_____ 0 $(/__ 0 %0, M # 9!@ ! P %08 4 S@ .8 #H %0, !,Z M%/\5A" "41E6UB;VP "R:0 0 07)I86P (@ $ $(B!@ - " !H M 0 !D$_:E9!/VI0 ! 0 @Q M #$B]0 ,]!2!C;W5P;&4@=&\@86YY=&AI;F<@9G5R=&AE0 M !8 !0#_ M_________P, "0( , !& AH\(&^XP MN@$# P"< ! $, ;P!M ' 3P!B &H M $@ " ?__________ M_____P !B M %< ;P!R &0 1 !O &, =0!M &4 ;@!T M : (!_____PP #_____ M )@ (40 M3P!B &H 90!C '0 4 !O &\ ; M !8 0$! @ 0 M (:'6>OM,+H!AH=9Z^TPN@$ #_________ M______\% _____P8 ' " D + (@ P - M#@ \ 0 $0 !( 3 %0 /____\6 %P "4 #_ M_______________^_________________________S #]_____O____[_ M__\; ) "< H *0 "H K + "T N _O__ M_R, * ________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________P4 4P!U &T ;0!A '( >0!) &X 9@!O '( ;0!A '0 :0!O M &X !4,5\OR00 !@$7S H ( ________________ M%#0 !$,10TP )$,10T7R\ D * # #^ M__________[__________O_________^__________[__________O______ M___^__________[___]<,5\P $ #_______________]4,30R: !4 M,6 R7R_.! P ,# $\ 8@!J $D ;@!F &\ !N &8 ;P!R &T 80!T &D M;P!N U#$4-%\OG#%?,&@"7S#8+5\P 0!%>%-T$@ 7#%?,'@P7S M !?+U0Q%#3@ 50Q /_______________]@M7S ! $5X4W0 M8#!?,&\ -#(4-+0!-#(4- M %@#" @ M ________________N@&&1==&[3"Z > !3R( M : )/(B R%#0@ 2 R________________________ M____________________________________________________________ M_Y$ "2 DP )0 "5 E@ )< "8 F0 )H "; MG )T "> _O__________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M__________________________________________________________]D M !X * 1&5S:2!1=6%D M $ "&]5K,[3"Z 0 M $ $ "&@>$3 M[C"Z 0 , M , M $ C(9' M !X 3 36EC"AL1KA #L P#^_PD ____ M____________________________________________________________ M______________________[_ #"@ $ #@ MA9_R^4]H$*N1" K)[/9, ' # . !P )@ " W 0 M # 0 " .0! , " ( L L @ #0 % " / = ( M ! "8 @ "@ +P" 2 X ( X $ P "0 "@# 3 M3 , '@ !\ !# M.EQ724Y73U)$7%1%35!,051%7$Y/4DU!3"Y$3U0 M > T $%S "@ $1E < T ) #@ D M ) . > / \ %0 "0#P ]0 *X. != M &H, , T 0 !0 ! $ , T P#0 M P#0 # - K@X P#0 M &H, :@P P#0 : M#0 # - , T P#0 # - :@P M P#0 &H, , T !0#0 M !^# " (8, . :@P !J# &H, M:@P P#0 % - , T " P#0 M M 07-S=6UE('1H M92!S:6UP;&4@;&5A9&9R;VUA(&QA>6]U71H:6YG(&9U2!T:&%N(#$@('!I;B 3($5-0D5$(%=O2!M871R:6-E2!T;R!G;R!F;W(@=&AI3-A M 1C& !V 4L! MU 40$ &,8 -C& "P # #J P ZP, &(% !C M!0 %08 "T& N!@ +P8 # & Q!@ ,@8 #,& !'!@ _@3_P"&H M#?X < A& '^ 7 (1@!_@ !P"$8 ?X \ A& '^ ' (1@!_@ !P"$8 ?X M < A& '^ ' (1@!_@ !P"$8 ?X \ A& '^ ' (1@!_@ !P"$8 0 M M M M M M M M ! - M#@ / @ 0!+ \ !H $#Q_P( &@ &3F]R;6%L ( # &$)! M B $% \O^A "( %D1E9F%U;'0@4&%R86=R87!H M($9O;G0 !# P P#_____ P#_____ 0 $(/__ 0 M 0P, 4 %0 !8 7 & 'H" ![ @ M+0, "X# !" P 0P, !P"$8 0 !P"$8 0 !P"$8 0 !P"$8 0 !P"$8 M 03_P"&H#0 !P"$8 0 #P"$8 0 !P"$8 0 !P"$8 0 !P"$8 0 # !'!@ M! P 1P8 4 Y@ /X 0 0P, !,Z%/\5A" "41E6UB;VP "R:0 0 07)I86P (@ $ $(B!@ - " !H 0 !D$_:E9A/V MI0 " ( 0 @Q M #$B]0 ,]!2!C M;W5P;&4@=&\@86YY=&AI;F<@9G5R=&AE 'P " A M (@ ", D )0 "8 G * "D #^____*P /[_ M__\M +@ "\ P ,0 #( S - #4 V -P M #@ Y .@ #L \ /0 #X _ 0 $$ !" M0P $0 !% 1@ $< !( 20 $H !+ 3 $T !. M 3P % !1 4@ %, !4 50 %8 !7 6 %D M !: 6P %P != 7@ %\ !@ 80 &( !C 9 M &4 !F 9P &@ !I :@ /[___]L ;0 &X !O M< '$ !R

Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26232; Mon, 5 Jun 95 18:40:51 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 5 Jun 95 18:34 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 5 Jun 95 18:37 PDT Message-Id: Date: Mon, 5 Jun 95 18:37 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD29.1 Banded_matrix Extension IBIS Members: BIRD29.1 is offered as a compromise proposal that supports the existing Banded_matrix functionality under IBIS Versions 2.0 and 2.1. The definitions were extended to overcome the technical limitations in a manner that two types of Banded_matrix formats can be supported by that designation. Normally it is not desirable to overload a parser with multiple definitions, but exception is made here because of the minor but important difference, the ease in which this can be done, and the eventual preference of the using extended definition for *.pkg libraries over the original definition. The technical limitation that this proposal overcomes is significant enough to be considered for the EIA proposed standard of Version 2.1. Yet the functionality changes are done with minimal clarification additions and no keyword or subparameter nomenclature changes. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 29.1 ISSUE TITLE: Banded_matrix Extension REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 26 May 1995 DATE REVISED: 5 June 1995 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 extended to remove a technical limitation. ****************************************************************************** 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 Text with Changes Shown: ********************* | 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 x M, 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 is used to specify the coupling effects up to B pins |* on either side. Two variations are supported. One allows for the coupling |* to circle back on itself. This is technically a simple form of a bordered |* block diagonal matrix. However, its data can be completely specified in |* in terms of a Banded_matrix for an N x M matrix consisting of N rows |* and M = N + B columns. The second variation is just in terms of an N x N |* matrix where no circle back coupling needs to be specified. |* | 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. | |* For case where coupling can circle back on itself, consider a matrix of |* N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B. | 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 K |* the entries [K,K] through [K,K+B] are given when K + B is less than or |* equal to the size of the matrix N. When K + B exceeds N, the entries in the |* last columns 1 ... B specify the coupling to the first rows. For row K, the |* entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = |* mod(K + B - 1, N) + 1. All rows will contain B + 1 entries. |* |* For the case where coupling does not circle back on itself, the process is |* modified. Only N columns need to be considered. When K + B finally exceeds |* the size of the matrix N, the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | |**************************************************************************** | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | Also, note that it is again necessarily the case that the N'th | row of an N x N matrix has just a single entry (the diagonal entry.) | |**** Reword the Above Sentence: ******************************* | |* With this convention, please note 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 columns 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" BIRD29.1 provides another way looking at the formating. The "41" entry can now be viewed as an upper-triangle entry of the original matrix augmented by repeating columns 1 ... B. Using symmetry, this format gives all of the information needed to describe all coupling by the B adjacent pins. Commentors on BIRD29 discussed nomenclature (banded, bandwidth, bordered block diagonal matrix) and proposed other terms. One concern was whether to retain the existing definition and add another term (such as Augmented_matrix) to handle the wrap around situation. The revised data entry format can still be referred to as banded when the first N columns are augmented by repeating existing columns 1 ... B. For compatibility reasons, support of the existing Banded_matrix format was desireable. The proposed new format was only a slight variation on the existing format, so it did not seem appropriate to introduce new nomenclature for the change. The solution proposed in BIRD29.1 is to accept simutaneously both format options. The intent is allow the technically robust functionality within the existing nomenclature, and to allow the technically limited descriptions be supported where wrap around coupling is of no concern. This works because the terms missing in the existing format are zero in the more robust format. The old format should be phased out rather than endorsed by separate notation which must be supported indefinitely because it would allow technically incomplete package model libraries. This is a compromise position between those who would like the original format definition deleted and those who would like to see both formats supported using different terminology. The parser definition will be overloaded, but for this situation, this is not a significant complication. 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 jonp@qdt.com Tue Jun 6 08:51:02 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06234; Tue, 6 Jun 95 08:51:02 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQysyw16116; Tue, 6 Jun 1995 11:44:57 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Tue, 6 Jun 1995 11:44:58 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00416; Tue, 6 Jun 95 08:39:05 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA21395; Tue, 6 Jun 95 08:46:15 PDT Date: Tue, 6 Jun 95 08:46:15 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9506061546.AA21395@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA00381; Tue, 6 Jun 95 08:42:06 PDT To: ibis@vhdl.org Subject: LAST CHANCE FOR LOGOS Wednesday, June 7, 1995 is the absolute LAST CHANCE to deliver logos to me for DAC IBIS poster/slide I have logos from the following companies. If you are not here and want to be (or think I left you off). contact me immediately at 805 988 8250. EIA Hyperlynx Zuken-Redac Incases ATT GIS National META Quantic INTEL Zeelan UNICAD CONTEC INTERGRAPH MENTOR Symmetry QUAD Interconnnectix MSC ANACAD And that is all. There is an obvious absense of companies whose initials are CADENCE. (in the words of shakespeare:) ACT NOW !!!!! jon From martin_goetz@worltek.com Wed Jun 7 12:27:27 1995 Return-Path: Received: from bastion.worltek.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20828; Wed, 7 Jun 95 12:27:27 PDT Received: from ccgate.worltek.com by bastion.worltek.com (8.6.9/SMI-4.1) id MAA11076; Wed, 7 Jun 1995 12:22:16 -0700 Received: from ccMail by ccgate.worltek.com (IMA Internet Exchange 1.04b) id fd5fc0d0; Wed, 7 Jun 95 12:20:45 -0700 Mime-Version: 1.0 Date: Wed, 7 Jun 1995 12:21:51 -0700 Message-Id: From: martin_goetz@worltek.com Subject: Include in Distribution To: IBIS@vhdl.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part To whom it may concern: I am the chairman of the JEDEC JC-15 committee on electronic package characterization techniques. Please include any pertinent information on ibis which may interest our committee's activities. Thank you. Martin P. Goetz ASAT, Inc. 415-969-1141 From Derrick_Duehren@ccm2.jf.intel.com Wed Jun 7 13:13:08 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21142; Wed, 7 Jun 95 13:13:08 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sJRNZ-000UsaC; Wed, 7 Jun 95 13:07 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sJRNY-000twmC; Wed, 7 Jun 95 13:07 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 07 Jun 95 13:07:04 PDT Date: Wed, 07 Jun 95 13:00:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes DATE: May 7, 1995 SUBJECT: 5/26/95 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS: AT&T Global Info Solutions Dave Moxley* Cadence Design Sandeep Khanna, C. Kumar* Contec Dileep Divekar* HyperLynx Kellee Crisafulli INCASES Werner Rissiek, Olaf Rethmeier* Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross* Motorola Ron Werner National Semiconductor Syed Huq*, Atul Agarwal NEC Hiroshi Matsumoto Quad Design Jon Powell Quantic Labs Mike Ventham* Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zuken-Redac John Berrie OTHER PARTICIPANTS: ARPA Randy Harr Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadlab Ralf Bruning Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso Hewlett Packard Tom Langdorf, Karl Kachigan, Henry Wu IBM Jay Diepenbrock Integrated Silicon Systems Eric Bracken 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 North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin 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 # 6/14/95 Birds of the Feather meeting at DAC 6/15/95 General session meeting at DAC 1:00 - 5:00 p.m. 7/7/95 (916) 356-9999 _______ 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. NEW AGENDA ITEMS: None. PRESS UPDATES: Electronic Design April 17 and May 1 issues have articles referencing IBIS. Derrick received over 30 new requests for additions to the IBIS reflector after Jon Powell advertised the IBIS open forum while answering a question from someone in Germany regarding the SI mail list. We now have 185 interested persons on the reflector. NEW MODELS AVAILABLE: National sent a "SuperI/O" model to Michael for posting. [Update: it is now posted to vhdl.org.] EIA IBIS MEMBERSHIP UPDATE: We now have 16 paid members (indicated in the participant list above). PROGRESS TOWARD ENLISTING NEW IC VENDORS Many of the IBIS members are IC vendors. We decided to remove this as a regular meeting topic. GOLDEN PARSER 2.1 STATUS Beta 5 and Beta 6 were dispersed. Bob Ross went through the test matrix and found four issues in the Beta 6 parser: 1. The parser crashes in certain conditions like invalid pin counts. 2. On banded matrix, the parser and spec agree, but ignore symmetry. It confuses banded and triangular matrix forms. This needs a BIRD. AR Bob -- Post your banded matrix correction as BIRD29. AR Bob -- Work with Ron and Paul to correct these in the parser. 3. Sparse matrix problem with alphanumerics (a fundamental problem for PGAs) gives wrong results. 4. Correlation between pin numbers in .ibs files and those in the .pkg file. Bob posted a test case that demonstrates this problem. Bob feels the parser needs another spin before we release it, but it is getting very close. We discussed treating Paul and Ron fairly through extra compensation. AR Will -- Contact Paul and Ron. Negotiate a fair compensation for their additional work. Arpad and Bob have checked some of the case sensitivity changes, and it seems to function under Windows, DOS, and UNIX. By consensus, we decided to roll all pending BIRDs into the ballot-review process. We also agreed that any changes proposed through the ballot process will be reviewed via the BIRD process. SPEC BALLOTT STATUS After some confusion, the IBIS spec is out for EIA ballot. IBIS spec ballots went out to the general EIA mailing list last week, mailings to the IBIS roster list were sent this week. 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, 1:00 pm to 5:00 pm, Marriott Hotel, tentatively "Pacific 1" room (check the hotel register for confirmation). Topics: Election of officers Status of balloting Support of MCMs and SIMMs (if we have time) Package Issues (if we have time) AR Will -- Send Jon your "history of IBIS" foils. [Update: Patty Rusher will attend the face-to-face.] Placards. Jon had 40 placards made. 2,000 EDN article reprints have been ordered and will be available at the EIA booth. REV 2.1 UPDATES o S2IBIS 2.1 Bob Ross reported that very little has occurred. o Cookbook Bob has plans for some submissions. o Overview No discussion. BIRD 26 - TAB CHARACTERS DISCOURAGED IN .IBS FILES Voted and approved unanimously (8 members voting). BIRD 27 - NEW KEYWORD FOR DIFFERENTIAL I/O Bob Ward explained his BIRD. TI has a chip that switches a lot of differential pairs. This BIRD removes redundancy by adding keyword to override the default differential threshold V_diff value (currently 200 mV) and make it the subsequent default value instead of having to repeatedly override the default. Bob Ross pointed out that the BIRD would not result in smaller files, and he made some suggested enhancements to the BIRD to eliminate columns and save data. We will continue this discussion after DAC. AR Bob Ross -- Send your ideas for altering BIRD27 to Bob Ward (BWard@phoenix.net). BIRD 28 - PACKAGE MODEL EXTENSION Stephen led a lively discussion on this Bird. Stephen has made changes suggested by various people, notably Kellee Crisafulli. Lots of discussion, sorting out how this BIRD addresses relatively simple packages and is not intended to address SIMMs and MCMs. There is a lot of interest in MCM and SIMM support, so the question is, should we create a format to describe SIMMs and MCMs, and if so, does this Bird become redundant? We will continue to discuss it over the reflector. NOTE: This BIRD does not currently address MCMs. SUPPORT OF MCMS AND SIMMS? IF YES, HOW? Concepts for handling MCMs were tossed around. Anyone is welcome to post EGG proposals for handling MCMs. Mike Ventham pointed out that adding more scope to the spec can make it more complicated/intimidating for prospective model writers. We need to better communicate what is and is not required ============================================================================== 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 Will_Hobbs@ccm2.jf.intel.com Wed Jun 7 17:49:09 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23277; Wed, 7 Jun 95 17:49:09 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sJVgD-000Uo8C; Wed, 7 Jun 95 17:42 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sJVgD-000twpC; Wed, 7 Jun 95 17:42 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Wed, 07 Jun 95 17:42:37 PDT Date: Wed, 07 Jun 95 17:40:00 PDT From: Will Hobbs Message-Id: To: jonp@qdt.com Cc: ibis@vhdl.org Subject: Re: [uunet!berlioz.nsc.com!hong: IBIS meeting at DAC'95] Text item: Jon, Thanks for the prompting. The IBIS general session will be held in the Pacific 1 room of the Marriott, which is where DAC is being held. It will be on Thursday afternoon, 1 - 5 PM, June 15. Will will, perhaps you could send out on the reflector the time and place for the IBIS meeting? (I don't even know where it is but I think it is thursday sometime). jon Return-Path: Date: Wed, 7 Jun 95 11:08:50 PDT From: uunet!berlioz.nsc.com!hong (Hong You) To: uunet!qdt.com!jonp Subject: IBIS meeting at DAC'95 Hi, My name is Hong You and our group provides IBIS support at National Semiconductor. I was told that there will be an IBIS meeting/forum during the upcoming DAC, would you by any chance have more information on that? Thanks a lot. Hong You (408)721-5515 hong@berlioz.nsc.com Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: [uunet!berlioz.nsc.com!hong: IBIS meeting at DAC'95] To: Will_Hobbs@ccm2.jf.intel.com Received: by f14.qdt.com (4.1/SMI-4.1) id AA09013; Wed, 7 Jun 95 11:55:33 PDT Message-Id: <9506071859.AA27209@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Wed, 7 Jun 95 11:59:44 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27209; Wed, 7 Jun 95 11:59:44 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00832; Wed, 7 Jun 95 11:52:32 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 7 Jun 1995 16:41:47 -0400 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQytdi26849; Wed, 7 Jun 1995 16:42:02 -0400 Received: from relay3.UU.NET by hermes.intel.com (5.65/10.0i); Wed, 7 Jun 95 13: 43:04 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 7 Jun 95 13:43:13 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sJRwa-000twtC; Wed, 7 Jun 95 13:43 PDT From Derrick_Duehren@ccm2.jf.intel.com Thu Jun 8 18:23:45 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04521; Thu, 8 Jun 95 18:23:45 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sJsh5-000UhKC; Thu, 8 Jun 95 18:17 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sJsh5-000twfC; Thu, 8 Jun 95 18:17 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 08 Jun 95 18:17:02 PDT Date: Thu, 08 Jun 95 18:14:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply ---------------------------- Forwarded with Changes --------------------------- From: hsin-huei.lin%relay.medtronic.com%medtron@uunet.uu.net at SMTPGATE Date: 6/8/95 5:20PM To: Derrick Duehren at JFCCM2 Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply ------------------------------------------------------------------------------- Text item: Anyone know how Hsin-Huei can get a copy of Electronic Design, April 17 and May 1 issues? - Derrick ______________________________ Forward Header __________________________________ Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply Author: hsin-huei.lin%relay.medtronic.com%medtron@uunet.uu.net at SMTPGATE Date: 6/8/95 5:20 PM Derrick, Do you know how I can get a copy of publication mentioned in the minutes? Thank you. Hsin-Huei Lin Medtronic, Inc. Hsin-Huei.Lin@medtronic.com >>> Derrick Duehren 06/07 3:00 pm >>> DATE: May 7, 1995 SUBJECT: 5/26/95 EIA IBIS Open Forum Meeting Minutes ******************* PRESS UPDATES: Electronic Design April 17 and May 1 issues have articles referencing IBIS. 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***. Content-Length: 403 Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply To: Derrick_Duehren@ccm2.jf.intel.com From: Hsin-Huei Lin Date: Thu, 08 Jun 1995 17:20:07 -0500 X-Mailer: Novell GroupWise 4.1 Message-Id: Received: from MSPEOS-Message_Server by eos.cis.corp.medtronic.COM with Novell_GroupWise; Thu, 08 Jun 1995 17:18:09 -0500 Received: from eos.cis.corp.medtronic.COM by mspeos.cis.corp.medtronic.COM (5.0/ SMI-SVR4) id AA20105; Thu, 8 Jun 1995 17:18:09 -0500 Received: from mspeos.cis.corp.medtronic.COM (eos.cis.corp.medtronic.COM) by med tron.medtronic.COM with SMTP id AA29313 (5.65c/IDA-1.4.4 for ); Thu, 8 Jun 1995 17: 18:49 -0500 Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA29317 (5.65c/IDA-1.4.4 for ); Thu, 8 Jun 1995 17: 18:51 -0500 Received: from medtron.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 8 Jun 1995 18:19:55 -0400 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQythh27366; Thu, 8 Jun 1995 18:19:40 -0400 Received: from relay3.UU.NET by hermes.intel.com (5.65/10.0i); Thu, 8 Jun 95 15: 21:13 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 8 Jun 95 15:21:19 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sJpx4-000twiC; Thu, 8 Jun 95 15:21 PDT From Arpad_Muranyi@ccm.fm.intel.com Fri Jun 9 12:40:20 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14812; Fri, 9 Jun 95 12:40:20 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sK9oj-000UjqC; Fri, 9 Jun 95 12:34 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sK9oj-000twzC; Fri, 9 Jun 95 12:34 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Fri, 09 Jun 95 12:34:05 PDT Date: Fri, 09 Jun 95 12:31:00 PDT From: Arpad Muranyi Message-Id: To: Derrick_Duehren@ccm2.jf.intel.com, IBIS@vhdl.org Subject: Re: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply Text item: ---------------------------- Forwarded with Changes --------------------------- From: hsin-huei.lin%relay.medtronic.com%medtron@uunet.uu.net at SMTPGATE Date: 6/8/95 5:20PM To: Derrick Duehren at JFCCM2 Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply ------------------------------------------------------------------------------- Text item: My first guess is to go to a (technical) library at a University or similar place... Arpad ----------------------------------------------------------------------- Anyone know how Hsin-Huei can get a copy of Electronic Design, April 17 and May 1 issues? - Derrick ______________________________ Forward Header _________________________________ _ Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply Author: hsin-huei.lin%relay.medtronic.com%medtron@uunet.uu.net at SMTPGATE Date: 6/8/95 5:20 PM Derrick, Do you know how I can get a copy of publication mentioned in the minutes? Thank you. Hsin-Huei Lin Medtronic, Inc. Hsin-Huei.Lin@medtronic.com >>> Derrick Duehren 06/07 3:00 pm >>> DATE: May 7, 1995 SUBJECT: 5/26/95 EIA IBIS Open Forum Meeting Minutes ******************* PRESS UPDATES: Electronic Design April 17 and May 1 issues have articles referencing IBIS. 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***. Content-Length: 403 Subject: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply To: Derrick_Duehren@ccm2.jf.intel.com From: Hsin-Huei Lin Date: Thu, 08 Jun 1995 17:20:07 -0500 X-Mailer: Novell GroupWise 4.1 Message-Id: Received: from MSPEOS-Message_Server by eos.cis.corp.medtronic.COM with Novell_GroupWise; Thu, 08 Jun 1995 17:18:09 -0500 Received: from eos.cis.corp.medtronic.COM by mspeos.cis.corp.medtronic.COM (5.0/ SMI-SVR4) id AA20105; Thu, 8 Jun 1995 17:18:09 -0500 Received: from mspeos.cis.corp.medtronic.COM (eos.cis.corp.medtronic.COM) by med tron.medtronic.COM with SMTP id AA29313 (5.65c/IDA-1.4.4 for ); Thu, 8 Jun 1995 17: 18:49 -0500 Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA29317 (5.65c/IDA-1.4.4 for ); Thu, 8 Jun 1995 17: 18:51 -0500 Received: from medtron.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 8 Jun 1995 18:19:55 -0400 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQythh27366; Thu, 8 Jun 1995 18:19:40 -0400 Received: from relay3.UU.NET by hermes.intel.com (5.65/10.0i); Thu, 8 Jun 95 15: 21:13 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 8 Jun 95 15:21:19 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sJpx4-000twiC; Thu, 8 Jun 95 15:21 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: 5/26/95 EIA IBIS Open Forum Meeting Minutes - Reply To: IBIS@vhdl.org Message-Id: From: Derrick Duehren Date: Thu, 08 Jun 95 18:14:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 08 Jun 95 18:17:02 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sJsh5-000twfC; Thu, 8 Jun 95 18:17 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sJsh5-000UhKC; Thu, 8 Jun 95 18:17 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04521; Thu, 8 Jun 95 18:23:45 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 8 Jun 95 18: 19:46 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sJsjj-000twzC; Thu, 8 Jun 95 18:19 PDT From mbs@eos.ncsu.edu Tue Jun 13 13:26:32 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 AA24823; Tue, 13 Jun 95 13:26:32 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA10663; Tue, 13 Jun 1995 16:20:24 -0400 From: mbs@eos.ncsu.edu Message-Id: <9506132020.AA10663@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: New IBIS models Date: Tue, 13 Jun 95 16:20:23 EDT Announcing new IBIS models Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes -------------------------------------------------------------------------------- g612mea.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL SSOP 56 Lead g612mtd.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL TSSOP 56 Lead gp612mea.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL SSOP 56 Lead gp612mtd.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL TSSOP 56 Lead These are in /pub.ibis/models/national/gtl ----------- Currently the IBIS library contains the following models 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 2537v.ibs cgs 04-17-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) pc87306.ibs superI_O 05-25-95 1.0 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int g612mea.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL SSOP 56 Lead g612mtd.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL TSSOP 56 Lead gp612mea.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL SSOP 56 Lead gp612mtd.ibs gtl 6/6/95 1.0 1.1 18-Bit CMOS GTL TSSOP 56 Lead 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. From mbs@eos.ncsu.edu Tue Jun 13 13:48:56 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 AA24935; Tue, 13 Jun 95 13:48:56 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA10741; Tue, 13 Jun 1995 16:42:48 -0400 From: mbs@eos.ncsu.edu Message-Id: <9506132042.AA10741@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: vacation Date: Tue, 13 Jun 95 16:42:48 EDT Your IBIS librarian is going on a long vacation to the new country (Australia). I will not be back until July 12. IBIS models should be sent to slipa@eos.ncsu.edu (Steve Lipa.) His telephone number is 919-515-3947. My email and mail will be checked every now and again but security measures prevent automatic forwarding of, and response to, mail. Michael Steer From Will_Hobbs@ccm2.jf.intel.com Tue Jun 13 16:53:54 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27505; Tue, 13 Jun 95 16:53:54 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sLffr-000UrfC; Tue, 13 Jun 95 16:47 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sLffq-000twVC; Tue, 13 Jun 95 16:47 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Tue, 13 Jun 95 16:47:09 PDT Date: Tue, 13 Jun 95 16:45:00 PDT From: Will Hobbs Message-Id: To: mbs@eos.ncsu.edu, ibis@vhdl.org Subject: Re: vacation Text item: Thanks for letting us know and have a nice vacation. G'day! Will Your IBIS librarian is going on a long vacation to the new country (Australia). I will not be back until July 12. IBIS models should be sent to slipa@eos.ncsu.edu (Steve Lipa.) His telephone number is 919-515-3947. My email and mail will be checked every now and again but security measures prevent automatic forwarding of, and response to, mail. Michael Steer 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***. Date: Tue, 13 Jun 95 16:42:48 EDT Subject: vacation To: ibis@vhdl.org Message-Id: <9506132042.AA10741@mbs.ece.ncsu.edu> From: mbs@eos.ncsu.edu Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA10741; Tue, 13 Jun 1995 16:42:48 -0400 Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4 .1/SMI-4.1/BARRNet) id AA24935; Tue, 13 Jun 95 13:48:56 PDT Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Tue, 13 Jun 95 14 :28:07 -0700 Received: from aurora.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 13 Jun 9 5 14:28:18 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sLdVV-000tyBC; Tue, 13 Jun 95 14:28 PDT From mkphilli@netcom.com Fri Jun 16 08:28:58 1995 Return-Path: Received: from netcom.netcom.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25718; Fri, 16 Jun 95 08:28:58 PDT Received: by netcom.netcom.com (8.6.12/Netcom) id IAA25173; Fri, 16 Jun 1995 08:15:00 -0700 Date: Fri, 16 Jun 1995 08:15:00 -0700 From: mkphilli@netcom.com (Mike Phillips) Message-Id: <199506161515.IAA25173@netcom.netcom.com> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From jonp@qdt.com Fri Jun 16 15:48:01 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27715; Fri, 16 Jun 95 15:48:01 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyukw09604; Fri, 16 Jun 1995 18:41:48 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 16 Jun 1995 18:41:52 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00859; Fri, 16 Jun 95 12:47:13 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA29500; Fri, 16 Jun 95 12:54:42 PDT Date: Fri, 16 Jun 95 12:54:42 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9506161954.AA29500@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA12113; Fri, 16 Jun 95 12:50:19 PDT To: ibis@vhdl.org Subject: Logo Poster hey guys, The Logo viewgraph of supporting customers was very well received at DAC. There was general agreement that such a poster would be beneficial for use on: 1) a WWW page for IBIS (hit to connect to company home page) 2) an IBIS poster for use by all companies at trade shows etc. It was also felt that the above uses could not occur without express written permission from each participant. Patty Rusher will be sending out official EIA request for Logo use, this is an early warning so you can find out what you need to do if interested. I will also be asking some people for art updates since some of the art I received was to low resolution to look good on a poster. comments welcome, jon :) From Derrick_Duehren@ccm2.jf.intel.com Mon Jun 19 10:59:14 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24218; Mon, 19 Jun 95 10:59:14 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sNl0S-000UqjC; Mon, 19 Jun 95 10:53 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sNl0R-000txNC; Mon, 19 Jun 95 10:53 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Mon, 19 Jun 95 10:53:03 PDT Date: Mon, 19 Jun 95 10:47:00 PDT From: Derrick Duehren Message-Id: To: IBIS@vhdl.org Subject: 6/15/95 EIA IBIS Open Forum Meeting Minutes IBISians, Thank you all for the thank-you plaque and letter. I have very much enjoyed serving as secretary to this august body. I wish you all the best and I am confident that Bob Ross (bob@icx.com) will be a good replacement. 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 ------------------------------------------------------------------------------- DATE: June 19, 1995 SUBJECT: 6/15/95 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS: AT&T Global Info Solutions Dave Moxley Cadence Design Sandeep Khanna, C. Kumar* Contec Dileep Divekar* HyperLynx Kellee Crisafulli INCASES Werner Rissiek*, Olaf Rethmeier Intel Corporation Stephen Peters, Will Hobbs*, Arpad Muranyi, Derrick Duehren* Interconnectix, Inc. Bob Ross* Meta-software Les Spruiell* Motorola Ron Werner National Semiconductor Syed Huq*, Atul Agarwal, Cheng-Yang Kao* NEC Hiroshi Matsumoto Quad Design Jon Powell* Quantic Labs Mike Ventham Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean LeBrun* UniCAD Canada Ltd. Stephen Lum* Zuken-Redac John Berrie OTHER PARTICIPANTS: ARPA Randy Harr Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadlab Ralf Bruning Digital Equipment Corp. Barry Katz EIA Patti Rusher* High Design Technology Michael Smith, Dr. Ing. Cosso Hewlett Packard Tom Langdorf, Karl Kachigan, Henry Wu IBM Jay Diepenbrock Integrated Silicon Systems Eric Bracken Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz LSI Logic Corp. Satish Pratadneni* Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei, John Sliney MicroSim Arthur Wong North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin 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 # Passcode 6/30/95 (916) 356-9999 1-3145 3815654 7/21/95 (916) 356-9999 1-3147 7221442 8/11/95 (916) 356-9999 1-3150 8492193 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 ------------------------------------- INTRODUCTIONS, ANNOUNCEMENTS Everyone introduced themselves and stated their involvement/interest in IBIS. Jean LeBrun went into some detail on his activities in the European CAD Standards Initiative group working on modeling standards. Two years ago he learned of IBIS just as he was about to launch a similar activity in Europe, and chose to monitor the progress of IBIS instead, to see if it met their needs. It has. He has also been applying IBIS to EMC simulation and has found it very accurate. He also discussed some of the thermal modeling work he has been engaged in, in a similar approach to IBIS. We had 14 attendees at the IBIS Birds of the Feather session the previous evening. Jon Powell lead the discussion, as Will Hobbs was leading the OMF discussion across the hall. EIA IBIS MEMBERSHIP UPDATE We now have 17 paid members (indicated in the participant list above). 10 were present to vote. PUBLIC RELATIONS Jon and Patti will be creating a poster of participant companies' logos. Everyone likes the concept. Patti will send letters on EIA letterhead asking for official permission to use of the logos on the poster. Jon will also get another 40 "IBIS Spoken Here" placards made. Send email to Jon (JonP@qdt.com) if you want one. Patti published a press release just before DAC. We will wait until the end of the balloting process before issuing another press release. Syed reported on National's internal WWW page. NSC has a variety of IBIS information files posted internally. Syed and Patti are working to set up an EIA home page for IBIS. Content suggestions: o EDN article (we still own the rights) o Frequently asked questions, or FAQ o Presentation materials from conferences, etc. o IBIS overview (2.1 Update needed) o EDA/Semiconductor company home page links o Links to publicly available models A link to the vhdl.org library is possible via ftp. Jon motioned that all submissions to the WWW home page be approved by a majority vote of the members present. The motion was passed. Syed volunteered to be the "Web Master". Syed also discussed his successful efforts within NSC to propagate IBIS. AR Syed - Post to the reflector a summary of your efforts to promote IBIS within NSC. ELECTION OF OFFICERS Chair: Will Hobbs Vice Chair: Jon Powell Secretary: Bob Ross Librarian: Michael Steer (not present - has option to decline) Having only one person nominated to each position, all positions were elected by acclamation, effective next meeting. STATUS OF IBIS SPEC BALLOTING So far, Patti has received about five positive responses to the ballot, with no comments that require response from the committee. 8/22/95 is the deadline for ballot responses. We will then have 5 working days to finish responding to the comments (we can respond to the comments as they arrive). All comments must have a response. Any substantive technical changes must go out for a second 30-day ballot. Once it is approved as an EIA standard, EIA656, Patti will present it to ANSI in Sept./Oct. to become a National standard, then on to the international community to make it an international standard. Jean LeBrun pointed out that to be approved internationally the spec must have a clear statement of the scope and purpose. GOLDEN PARSER UPDATE Will received an update from Paul Munsey before leaving for DAC but has yet to distribute it. Paul believes that this is the "final" version. But Bob Ross would like us to contract Paul to make changes to the banded matrix section (see BIRD 29 discussion). INCREASING MODEL AVAILABILTIY Bob Ross presented a letter that Brock Hannibal, Tektronix, has written to his purchasing dept. It directs them to ask a series of questions of Tek's semiconductor suppliers, expressing preference for IBIS models and grilling them on their strategies for providing I/O models. We discussed the need for companies that have non-public IBIS models to advertise them on vhdl.org. We agreed that companies should be able to post lists of IBIS files that are available only under NDA to Michael Steer, using a similar approval/signature process as normal IBIS files. Michael could then post the file list to the companies' vhdl.org directory as a text file (models.nda?). BIRD 29.1, BANDED MATRICES Bob Ross summarized BIRD 29.1, which he posted 2 days ago (less than the 14 days required before a vote can be taken). The forum decided to have Paul Munsey roll BIRD 29.1 into the Golden Parser. We can formally approve the BIRD at our next meeting. ============================================================================== 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 2111 NE 28th 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. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From drucker@cellerity.com Mon Jun 19 13:39:43 1995 Return-Path: Received: from vgreen.cellerity.com (ivgreen.cellerity.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25309; Mon, 19 Jun 95 13:39:43 PDT Received: by vgreen.cellerity.com; id AA16294; Mon, 19 Jun 1995 16:33:32 -0400 Message-Id: <9506192033.AA16294@vgreen.cellerity.com> To: ibis@vhdl.org Reply-To: drucker@cellerity.com Return-Receipt-To: drucker@cellerity.com Subject: unsubscribe Date: Mon, 19 Jun 95 16:33:31 -0400 From: drucker@cellerity.com X-Mts: smtp suscription e-mail address: kevin.drucker@amp.com From huq@rockie.nsc.com Mon Jun 19 16:14:43 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26251; Mon, 19 Jun 95 16:14:43 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA14675 for ibis@vhdl.org; Mon, 19 Jun 95 16:08:33 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA21245 for ibis@vhdl.org; Mon, 19 Jun 95 16:08:32 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA21641; Mon, 19 Jun 95 16:10:22 PDT Date: Mon, 19 Jun 95 16:10:22 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9506192310.AA21641@rockie.nsc.com> To: ibis@vhdl.org Subject: How to promote IBIS within your org Cc: huq@rockie.nsc.com SORRY IF YOU ARE RECEIVING THIS TWICE.. > > AR Syed - Post to the reflector a summary of your efforts to promote IBIS > within NSC. > > Hi IBISgurus, One of my AR item from the last meeting was to share with the forum as to how one can possible promote IBIS across his/her own company. This is based on my experience with National and I am sure can be applied to most other companies as well. 1)If your site support the Web, create an IBIS homepage. This will serve as a common ground for all IBIS related information that you can tell your new user to go and browse. 2)Next, you need to publicise the URL(Uniform Resource Locator). If you have xvnews or other form of 'news' through E-mail, post a short description of IBIS along with the URL. This gives different usergroups to visit the homepage and find more info. 3)If your company publishes internal News Letters, find out how many there are and which ones are local/international etc. Write a brief 'Intro to IBIS' and publish. Make sure you mention the URL again. 4)If your company supports Multi-Media displays(ex. TV's with slide shows about the Industry, Your company Event etc etc), create a few slides about IBIS and display that thru the system for a week or two. 5)Create a set of 'An Introduction to IBIS' presentation foils and talk to different Product lines. Most product groups have Brown Bag lunches etc.. 6)If you have a central CAD group that supports all CAD/Design issues for the corporation, get them involved.. 7)Start creating your own IBIS distribution list on E-mail and always copy everyone on the list of all interesting events about IBIS. 8)Product lines involved in simulation/SPICE..make the initial contact with them and add those key people in your IBIS distribution list. 9)Generate training materials and send out copies. Make sure you also publish any training material on IBIS on the Web. If you are part of a product line, offer IBIS Model generation Training to the Test/Product/Design community.. I think I have given enough hints. It's a tough thing to do but once you get the ball rolling...you will know. Any questions, comments, let me know.. Best Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Interface Applications Engineer National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----- End Included Message ----- From huq@rockie.nsc.com Wed Jun 21 09:41:56 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16964; Wed, 21 Jun 95 09:41:56 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20322 for ibis@vhdl.org; Wed, 21 Jun 95 09:35:40 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA16444 for slipa@eos.ncsu.edu; Wed, 21 Jun 95 09:35:39 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA25958; Wed, 21 Jun 95 09:37:30 PDT Date: Wed, 21 Jun 95 09:37:30 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9506211637.AA25958@rockie.nsc.com> To: slipa@eos.ncsu.edu Subject: Help from the IBIS Librarian Cc: ibis@vhdl.org Steve, I while back I had asked this question with no response. Can you comment on this ? Regards, Syed. National Semiconductor > From huq@rockie.nsc.com Thu Jun 1 15:21:30 1995 > Date: Thu, 1 Jun 95 14:58:05 PDT > From: huq@rockie.nsc.com (Syed Huq) > To: ibis@vhdl.org > Subject: Re: Re[2]: Model list > Content-Length: 716 > > Mike, > > Is there any way you can provide some kind of info on 'who' and > 'how many times' any models get copied out of the models dir. > > This information is only for the companies providing the models. > We would be very interested to know these kinds of statistics if > you can provide them on a monthly basis. > > Best Regards, > Syed. > National Semiconductor. > From slipa@eos.ncsu.edu Wed Jun 21 10:56:29 1995 Return-Path: Received: from mw7.ece.ncsu.edu (c11049-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17260; Wed, 21 Jun 95 10:56:29 PDT Received: by mw7.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA11425; Wed, 21 Jun 1995 13:50:15 -0400 From: slipa@eos.ncsu.edu Message-Id: <9506211750.AA11425@mw7.ece.ncsu.edu> To: ibis@vhdl.org Cc: slipa@eos.ncsu.edu Subject: RE: Help from the IBIS Librarian Date: Wed, 21 Jun 95 13:50:14 EDT Syed: Hi. The hostname, filenames, and dates of transfers can all be logged. The information typed in at the Password prompt can be logged but depends on the honesty and accuracy of the typing of the person who is ftp'ing. Given the hostname you can use the whois service to figure out what company the host is associated with. Thus it is possible to log which companies are downloading which models and when. However, there are costs associated with this. I am just filling in temporarily for Michael and am not in a position to make any policy decisions or offer any new services. I will remind Michael to get back to you about this when he gets back. Steve To: slipa@eos.ncsu.edu Subject: Help from the IBIS Librarian Cc: ibis@vhdl.org Steve, I while back I had asked this question with no response. Can you comment on this ? Regards, Syed. National Semiconductor > From huq@rockie.nsc.com Thu Jun 1 15:21:30 1995 > Date: Thu, 1 Jun 95 14:58:05 PDT > From: huq@rockie.nsc.com (Syed Huq) > To: ibis@vhdl.org > Subject: Re: Re[2]: Model list > Content-Length: 716 > > Mike, > > Is there any way you can provide some kind of info on 'who' and > 'how many times' any models get copied out of the models dir. > > This information is only for the companies providing the models. > We would be very interested to know these kinds of statistics if > you can provide them on a monthly basis. > > Best Regards, > Syed. > National Semiconductor. > From Derrick_Duehren@ccm2.jf.intel.com Thu Jun 22 15:48:26 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29443; Thu, 22 Jun 95 15:48:26 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sOuwq-000Ut0C; Thu, 22 Jun 95 15:42 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sOuwp-000txMC; Thu, 22 Jun 95 15:42 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 22 Jun 95 15:42:06 PDT Date: Thu, 22 Jun 95 15:36:00 PDT From: Derrick Duehren Message-Id: To: PattiR@EIA.org, IBIS@vhdl.org Subject: IBIS Open Forum 6/30/95 Meeting Agenda IBIS Open Forum Meeting Agenda for 6/30/95 Bridge Number Reservation # Passcode (916) 356-9999 1-3145 3815654 All meetings are 8:00 AM to 9:55 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, library update o Tracking usage EIA Status Rusher - Membership update - Balloting issues/update 8:30 Golden Parser 2.1 status Hobbs Rev 2.1 updates Hobbs o S2IBIS 2.1 o Cookbook o Overview 9:00 BIRD 27 - New keyword for differential I/O Ward BIRD 28 - Package model extension Peters BIRD 29 - Banded Matrices Ross Vote to be taken (already recommended at 6/15 meeting) Support of MCMs and SIMMs? If yes, how? Crisafulli 9:55 Wrap-up, next meeting plans Hobbs From brianjohns@micron.com Mon Jun 26 15:21:43 1995 Return-Path: Received: from microndns.micron.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07409; Mon, 26 Jun 95 15:21:43 PDT Received: from mailsrv1.micron.com by microndns.micron.com (AIX 3.2/UCB 5.64/4.03) id AA27956; Mon, 26 Jun 1995 16:08:30 -0600 Received: from novmail01 (gateway1) by micron.com (5.0/SMI-SVR4) id AA06459; Mon, 26 Jun 1995 16:15:39 +0700 Received: by novmail01 with Microsoft Mail id <2FEF341F@novmail01>; Mon, 26 Jun 95 16:26:39 MDT From: Brian Johnson To: 'ibis' Subject: Golden Parser Date: Mon, 26 Jun 95 16:14:00 MDT Message-Id: <2FEF341F@novmail01> Encoding: 7 TEXT X-Mailer: Microsoft Mail V3.0 Content-Length: 177 If I were to FTP the IBIS.CHK program, where can I find it. I looked through the FTP area in the VHDL/IBIS area and could not find it. Thanks, Brian Johnson Micron Technology From scott@icx.com Mon Jun 26 15:41:35 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07480; Mon, 26 Jun 95 15:41:35 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 26 Jun 95 15:35 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 26 Jun 95 15:38 PDT Message-Id: To: Brian Johnson Cc: 'ibis' , scott@icx.com Subject: Re: Golden Parser In-Reply-To: Your message of "Mon, 26 Jun 1995 16:14:00 MDT." <2FEF341F@novmail01> Date: Mon, 26 Jun 1995 15:38:20 -0700 From: Scott Aron Bloom If you look in "/pub/ibis/ver1.1/exec" you will find a host of directories containing the golden parser for different platforms. Scott Interconnectix > > If I were to FTP the IBIS.CHK program, where can I find it. I looked > through the FTP area in the VHDL/IBIS area and could not find it. > > Thanks, > Brian Johnson > Micron Technology From Will_Hobbs@ccm2.jf.intel.com Tue Jun 27 14:16:28 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17789; Tue, 27 Jun 95 14:16:28 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sQhte-000UttC; Tue, 27 Jun 95 14:10 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sQhtd-000twVC; Tue, 27 Jun 95 14:10 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Tue, 27 Jun 95 14:10:13 PDT Date: Tue, 27 Jun 95 14:06:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Subject: Beta 7 Golden Parser info Folks, Through an act of Murphy, one of the files of the Beta 7 2.1 IBIS Golden Parser was omitted from the disk. I will re-send the disk with the file on it to all parser source licensees, but in the mean time you may reply to this message and I will send the file to you via e-mail. The omitted file was called ramp.c. I apologize for the inconvenience. Will Hobbs Chair, EIA IBIS Committee and XTG Modeling Manager Intel Corp. From speters@ichips.intel.com Wed Jun 28 16:58:03 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29034; Wed, 28 Jun 95 16:58:03 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Wed, 28 Jun 95 16:51:41 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 28 Jun 95 16:51:32 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 28 Jun 95 16:51:31 PDT Message-Id: <9506282351.AA27428@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD 28.1 (Xmission line package models) Date: Wed, 28 Jun 1995 16:51:30 -0700 From: Stephen Peters Hello GentleIBIS persons: I've updated Bird 28 with the sugestions from Bob Ross and reissued it as 28.1. In brief, I've eliminated the 'Unit Length' keyword, and added the syntax changes regarding backslash and the = sigh. I've also added the requirement that if two or more package stubs couple (i.e. have a section that uses the matrix description) then the sections that couple must be reported as having the same length. My justification for this will follow. Happy reading... Best Regards, Stephen Peters Intel Corp. ------------------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 28.1 ISSUE TITLE: Enhancement To The Package Model (.pak file) Specification REQUESTER: Stephen Peters DATE SUBMITTED: June 26, 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 keyword [Number of Sections] is 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 | |============================================================================= 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 name 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 of 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. The subparameters are defined as | follows: | Len The length of a package stub section. Lengths are given | in terms of arbitrary 'units'. | L The inductance of a package stub section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a package stub section is 3.0nH and the | length of this section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). | 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 package stub | sections electrical parameters are presented as part of | a coupling matrix. The data for 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 specified, 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 must begin with the Len subparameter and | ends with the backslash (/) character. The value of a sub- | parameter and the subparameter itself are separated by an equals | sign (=); whitespace around the equals sign is optional. 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 given as 'Len = 0 /'. See the | example below). | | Legal Subparameter Combinations: | A) A single Len = 0 subparameter, followed by a backslash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | backslash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. 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. Also note that | if two or more package stubs are coupled together, the | sections that couple MUST be reported as having the same | length (please refer to the NOTE below). | | C) Len, and any combination of L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | | In the example below the first section is a lumped inductor, | the second section is described using a matrix, and the third | section is modeled using distributed elements. Pin A3 shows | an example of sections with no data. Pins A4 and A5 illustrate | how a section description can be broken across multiple lines | and how each section description is delimited by the backslash. |----------------------------------------------------------------------------- [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 Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 / A3 Len = 0 / Len = 1.2 Matrix / Len = 0 / A4 Len = 0 L=1.2n / Len = 1.2 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 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=2.2p R=0.01 / | | NOTE ON VARYING LENGTH COUPLED SECTIONS | As specified above, sections that couple to one another must | be reported as having the same length. To illustrate, refer | to the example below. | | package stub 1 -------------------- (signal) | package stub 2 --------------------- (signal) | package stub 3 ---------------------- (signal) | package stub 4 ----------------------- (gnd) | package stub 5 ----------- (signal) | package stub 6 ------------ (signal) | | Assume package stubs 1,2 and 3 couple to each other, while 5 and 6 | couple to one another. Stubs 1,2 and 3 must be reported as | having the same length. Stubs 5 and 6 must also be reported | as having the same length (although this length is, of | course, different than the length reported for stubs 1, 2 and | 3). If this is not acceptable then the extra length of the | longer package stubs should be reported as additional | sections. Be wary however; very sort sections may cause | convergence or other simulation problems. | 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. Changes 6/28 Per the suggestions of Bob Ross (email on May 30) I have removed the 'Unit Length' keyword and incorporated his syntax suggestions regarding backslash delimiters and the '=' sign. 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. From fvance@FirePower.COM Thu Jun 29 09:45:08 1995 Return-Path: Received: from FirePower.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07693; Thu, 29 Jun 95 09:45:08 PDT Received: from oahu by FirePower.COM (NX5.67e/NX4.0Mhb.0b) id AA06935; Thu, 29 Jun 95 09:33:51 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA20371; Thu, 29 Jun 95 09:35:39 -0700 From: Fred Vance Message-Id: <9506291635.AA20371@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02329; Thu, 29 Jun 95 09:35:33 -0700 Date: Thu, 29 Jun 95 09:35:33 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: ibis@vhdl.org Subject: unsubscribe / subscribe: updating domain name unsubscribe fvance@powerhouse.com subscribe fvance@firepower.com Thanks Fred