From bioconjp@inet.uni-c.dk Mon Apr 3 07:31:22 1995 Return-Path: Received: from inet.uni-c.dk by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28135; Mon, 3 Apr 95 07:31:22 PDT Received: from 130.225.242.67 (arhppp3.uni-c.dk [130.225.242.67]) by inet.uni-c.dk (8.6.9/8.6.9) with SMTP id QAA24156 for ; Mon, 3 Apr 1995 16:25:00 +0200 Date: Mon, 3 Apr 1995 16:25:00 +0200 Message-Id: <199504031425.QAA24156@inet.uni-c.dk> From: bioconjp@inet.uni-c.dk Subject: bird and temperature To: ibis@vhdl.org X-Mailer: AIR Mail 3.X (SPRY, Inc.) We are looking for informations concerning external temperature of ducks. If anyone have informations concerning this subject please contact us. From Will_Hobbs@ccm2.jf.intel.com Mon Apr 3 13:32:26 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00694; Mon, 3 Apr 95 13:32:26 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rvsiB-000UiAC; Mon, 3 Apr 95 13:26 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rvsiA-000txhC; Mon, 3 Apr 95 13:26 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 3 Apr 95 13:26:58 PST Date: Mon, 3 Apr 95 13:26:58 PST From: Will Hobbs Message-Id: <950403132658_3@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Bird #27, Differential Threhold Text item: Buffer Issue Resolution Document (BIRD) BIRD ID#: 27 ISSUE TITLE: Propose new keyword to specify default diffrential threshold REQUESTOR: Bob Ward Texas Instruments DATE SUBMITTED: 03APR95 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The proposal is made to include a new keyword [diff_threshold] to set the default value of differential threshold voltage. This is similar in spirit to the use of Lpkg, Rpkg, and Cpkg to set default values for pins. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: |========================================================================= | Keyword: [Diff_Threshold] | | Required: No | | Description: Specifies the default value for the differential threshold | voltage of a differential input pin pair. If thresholds | are set on individual pin pairs, these override the default | specifed here. | | Usage Rules: This keyword is to be specified only if diffential pin | pairs are specified, although no harm will come from | specifying it otherwise. If diff pins are then not | specified, only some redundant work is done since an unused | default is all that is changed and so no harm is done. | |------------------------------------------------------------------------- [Diff_Threshold] 420mv | Set default differential threshold to .420 V | ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: We have a differential switch matrix chip for telecom switching ( yes, it is digital! ) which has rather larger threshold than the 200mv provided as a default by the present spec. It also has a large number, several tens, of input pin pairs. It would be desireable to be able to set this threshold without having to specify it on each pin pair. It could still be specified per pin pair, and that specification would override this default. This keyword only specifies a default value other than the fixed value stated in the present spec. This keyword is in exactly the same spirit as the default package parasitics keywords. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: It is conceivable that this keyword could specify typ, min, and max values, but this is not seen as necessary at this time. *******************************************************************************  <<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>> ~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~ .---. .----------- | Bob Ward / \ __ / ------ | bward@ti.com / / \( )/ ----- | ////// ' \/ ` --- | Restore freedom to America ... //// / // : : --- | Abolish RICO! /> // / / /` '-- | Restore the right to bear arms! /< // //..\\ | Sink the Clipper! @\\\\\\|*|==============UU====UU============-| \< '//||\\` | If PRO and CON are opposites, \> ''`` | consider CONGRESS. ~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~ 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: Bird on Differential Threhold To: will_hobbs@ccm2.jf.intel.com Message-Id: <9504031515.AA12741@leviathan.micro.ti.com> From: bward@leviathan.micro.ti.com (Bob Ward) Date: Mon, 3 Apr 95 10:15:33 CDT Received: by leviathan.micro.ti.com (4.1/SMI-4.1) id AA12741; Mon, 3 Apr 95 10:15:33 CDT Received: from leviathan.micro.ti.com by micro.ti.com (4.1/SMI-4.1-941013) id AA18928; Mon, 3 Apr 95 10:15:34 CDT Received: from micro.ti.com (wotangate.micro.ti.com) by itg.ti.com (4.1/ITG-1.1) id AA19734; Mon, 3 Apr 95 10:14:48 CDT Received: from itg.ti.com ([128.247.93.50]) by gate.ti.com (8.6.10/) with SMTP i d KAA21683 for ; Mon, 3 Apr 1995 10:15:30 -0500 Received: from news.ti.com by hermes.intel.com (5.65/10.0i); Mon, 3 Apr 95 08:20 :11 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 3 Apr 95 08:20:19 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rvnvR-000tyyC; Mon, 3 Apr 95 08:20 PDT From uunet!qdt.com!jonp@uunet.uu.net Mon Apr 3 19:48:08 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02861; Mon, 3 Apr 95 19:48:08 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyjyg18274; Mon, 3 Apr 1995 22:42:38 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 3 Apr 1995 22:42:38 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01687; Mon, 3 Apr 95 19:18:08 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA06351; Mon, 3 Apr 95 19:23:14 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyjxy23775; Mon, 3 Apr 1995 20:42:02 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 3 Apr 1995 20:42:02 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01589; Mon, 3 Apr 95 17:28:33 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA06165; Mon, 3 Apr 95 17:33:39 PDT Date: Mon, 3 Apr 95 17:33:39 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9504040033.AA06165@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA09009; Mon, 3 Apr 95 17:30:56 PDT To: uunet!uunet!inet.uni-c.dk!bioconjp@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: uunet!inet.uni-c.dk!bioconjp's message of Mon, 3 Apr 1995 16:25:00 +0200 <199504031425.QAA24156@inet.uni-c.dk> Subject: bird and temperature >>We are looking for informations concerning external temperature of ducks. If >>anyone have informations concerning this subject please contact us. There is a rather good treatment of this in Rogers et al. "Psyhcological effects of Thermonuclear Blasts on North American Water Fowl" (MIT Press 1988). In general, they model external temperature in a behavioral fashion using a matrix of quack vs. temperature (in millions of degrees kelvin). The main problem they had was that the combust time of your CMOS (California Mallard Or Swan) when subjected to even a kiloton level nuclear blast is in the sub-nanoseconds, making correlation of measurements to simulation somewhat suspect. jon powell Quad Design From rwon@actel.com Tue Apr 4 11:16:59 1995 Return-Path: Received: from actel.com ([204.33.233.254]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11794; Tue, 4 Apr 95 11:16:59 PDT Received: from niner.sun_net ([192.9.202.209]) by actel.com (4.1/SMI-4.1) id AA20118; Tue, 4 Apr 95 11:13:16 PDT Received: by niner.sun_net (4.1/SMI-4.1) id AA16281; Tue, 4 Apr 95 11:13:07 PDT Date: Tue, 4 Apr 95 11:13:07 PDT From: rwon@actel.com (Raymond Won) Message-Id: <9504041813.AA16281@niner.sun_net> To: ibis@vhdl.org Subject: How to get more information on IBIS? I am interested in getting more information on IBIS, how can I do that? Raymond Won e-mail rwon@actel.com From Will_Hobbs@ccm2.jf.intel.com Tue Apr 4 12:52:58 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12350; Tue, 4 Apr 95 12:52:58 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rwEZV-000UgaC; Tue, 4 Apr 95 12:47 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rwEZV-000twqC; Tue, 4 Apr 95 12:47 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 4 Apr 95 12:47:28 PST Date: Tue, 4 Apr 95 12:47:28 PST From: Will Hobbs Message-Id: <950404124728_1@ccm.jf.intel.com> To: rwon@actel.com, ibis@vhdl.org Subject: Re: How to get more information on IBIS? Text item: Raymond, The usual mechanism is to send a request to ibis-info@vhdl.org. I have sent you the information you requested. Regards, Will Hobbs Chair, IBIS Open Forum and XTG Modeling Manager Intel Corp. I am interested in getting more information on IBIS, how can I do that? Raymond Won e-mail rwon@actel.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: How to get more information on IBIS? To: ibis@vhdl.org Message-Id: <9504041813.AA16281@niner.sun_net> From: rwon@actel.com (Raymond Won) Date: Tue, 4 Apr 95 11:13:07 PDT Received: by niner.sun_net (4.1/SMI-4.1) id AA16281; Tue, 4 Apr 95 11:13:07 PDT Received: from niner.sun_net ([192.9.202.209]) by actel.com (4.1/SMI-4.1) id AA20118; Tue, 4 Apr 95 11:13:16 PDT Received: from actel.com ([204.33.233.254]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNe t) id AA11794; Tue, 4 Apr 95 11:16:59 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 4 Apr 95 11: 44:32 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 4 Apr 95 11:45:01 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rwDbA-000twoC; Tue, 4 Apr 95 11:45 PDT From bob@icx.com Thu Apr 6 11:09:49 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06826; Thu, 6 Apr 95 11:09:49 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 6 Apr 95 11:04 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 6 Apr 95 11:06 PDT Message-Id: Date: Thu, 6 Apr 95 11:06 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD27 [Diff Threshold] Comments Bob Ward and IBIS Committee: At this time I am undecided regarding BIRD27 for adding the [Diff Threshold] keyword. The choices are: (1) Do nothing - simplicity, but inconvenience (2) Accept the BIRD as is - convenience (3) Expand to allow for two [Diff Pin] columns - more convenience, but with more rules to handle. A fundamental consideration is that it is technically not necessary. This does not add any capablility that can be already handled by the existing Spec. Yet it would add to the growing list of keywords to process. However, the real practical value of this keyword is to allow in one place the setting of all of the [Diff Pin] thresholds. Then we can use "NA" (which is currently permitted) for each pin-pair. Where do you intend to position the [Diff Threshold] keyword? I assume that it is another [Component] modifier similar to [Package]. An attractive possibility is to include provisions in the BIRD for allowing the [Diff Pin] table to contain just the first two columns with tdelay subparameters assumed 0ns. This could make the [Diff Pin] processing rules more complicated, however. For me the tradeoff is between complication and convenience. Bob Ross, Interconnectix, Inc. From speters@ichips.intel.com Thu Apr 6 16:10:53 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12519; Thu, 6 Apr 95 16:10:53 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Thu, 6 Apr 95 16:05:20 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 6 Apr 95 16:05:10 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 6 Apr 95 16:05:10 PDT Message-Id: <9504062305.AA20045@xtg801.intel.com> To: ibis@vhdl.org Cc: speters@ichips.intel.com Subject: Enhanced Package Models Date: Thu, 06 Apr 1995 16:05:08 -0700 From: Stephen Peters Hello Fellow IBISans: I have been tossing around ideas for enhancing package model descriptions by describing package pins as a series of transmission lines. In some cases a package modeled as a series of uncoupled transmission lines is adequate, in others a series of coupled transmission lines is required. I was thinking about enhancing the existing '.pkg' description to include both pin length info and the idea of each 'pin' (package stub) as having different sections. I've also spoken with Kellee Crisafulli at Hyperlynx about this and he has offered the idea of describing the package at a physical level using some sort of a PCB like description. His points in brief: 1. Simulator companies support coupled transmission line simulation by reading in PCB information. By treating the package as a 'PCB' we have a 'natural' way of getting package info into a simulator. 2. With this enhancement IBIS could then handle things like SIM modules, MCMs, etc. Some problems/questions: 1. Do we have to create a standard 'PCB' like description? There is an EDIF PCB standard, but does anybody support it? What would it take to create our own? 2. Getting CAD companies to output such a format (There is a company called Router Solutions whose business is to write reader/ writers from any format to another). 3. Presently, packages are usually described in a purely mechanical way without the required dielectric info, layer stack up, etc. How can the user get this mechanical info into our description. 4. Are there possible proprietary issues involved with giving out physical package (construction) info? An alternative method is to supply the user with the electrical information only. For simple packages that can be represented by a series of uncoupled transmission lines it's a relatively straight forward, simple enhancement to the '.pkg' description. For coupled transmission lines it's a more complicated matrix style description, but doable. Points in brief: 1. It's a 'behavioral' description, which is consistent with what IBIS is all about. 2. For the matrix description there are several ways of extracting and presenting the coefficients in the matrix. The forum will have to decide on a consistent methodology. 3. For well behaved packages (i.e. ones that can be described with uncoupled transmission lines) a direct description for each pin would be simple and quick to implement, and for simulator companies to use. Of course, we can do both, or some combination of the two. I'd like to discuss this more at the meeting tomorrow, with an eye towards getting somthing concrete going. Best Regards, Stephen Peters Intel Corp. From cpk@Cadence.COM Fri Apr 7 08:45:02 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23299; Fri, 7 Apr 95 08:45:02 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA16258; Fri, 7 Apr 1995 08:39:32 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma016145; Fri Apr 7 08:39:02 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA23106; Fri, 7 Apr 95 08:36:44 -0700 Received: by hot (5.65+/1.5) id AA12216; Fri, 7 Apr 95 11:38:57 -0400 Date: Fri, 7 Apr 95 11:38:57 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9504071538.AA12216@hot> To: ibis@vhdl.org, speters@ichips.intel.com Subject: Re: Enhanced Package Models IBISens: I have a major concern regarding PCB type description of packages. 1) A PCB description is open ended. i.e. it is not a parameterized model. In that sense it cannot be a conventional model. 2)If a "standard" PCB description is desired for Package model, it becomes a problem of a. Making sure companies support "standard" description like EDIF b. Make sure standards like EDIF can include IBIS buffer descriptions. In this case there is no "modelling" work need to be done by the IBIS committee and the problem becomes one of acceptence standards like EDIF by CAD companies. > > Hello Fellow IBISans: > > I have been tossing around ideas for enhancing package model > descriptions by describing package pins as a series of transmission > lines. In some cases a package modeled as a series of uncoupled transmission > lines is adequate, in others a series of coupled transmission lines > is required. I was thinking about enhancing the existing '.pkg' > description to include both pin length info and the idea of each > 'pin' (package stub) as having different sections. I've also spoken > with Kellee Crisafulli at Hyperlynx about this and he has offered the > idea of describing the package at a physical level using some sort of > a PCB like description. His points in brief: > > 1. Simulator companies support coupled transmission line simulation > by reading in PCB information. By treating the package as a > 'PCB' we have a 'natural' way of getting package info into a simulator. > 2. With this enhancement IBIS could then handle things like SIM modules, > MCMs, etc. > > Some problems/questions: > 1. Do we have to create a standard 'PCB' like description? There is an EDIF PCB > standard, but does anybody support it? What would it take > to create our own? > 2. Getting CAD companies to output such a format (There is > a company called Router Solutions whose business is to write reader/ > writers from any format to another). > 3. Presently, packages are usually described in a purely mechanical > way without the required dielectric info, layer stack up, etc. > How can the user get this mechanical info into our description. > 4. Are there possible proprietary issues involved with giving out > physical package (construction) info? > > > An alternative method is to supply the user with the electrical > information only. For simple packages that can be represented by > a series of uncoupled transmission lines it's a relatively > straight forward, simple enhancement to the '.pkg' description. For > coupled transmission lines it's a more complicated matrix style > description, but doable. Points in brief: > > 1. It's a 'behavioral' description, which is consistent with what IBIS > is all about. > > 2. For the matrix description there are several ways of extracting > and presenting the coefficients in the matrix. The forum will have > to decide on a consistent methodology. > > 3. For well behaved packages (i.e. ones that can be described with > uncoupled transmission lines) a direct description for each > pin would be simple and quick to implement, and for simulator > companies to use. > > > Of course, we can do both, or some combination of the two. I'd like > to discuss this more at the meeting tomorrow, with an eye towards getting > somthing concrete going. > > Best Regards, > Stephen Peters > Intel Corp. > > > > From kellee@nwlink.com Fri Apr 7 13:13:16 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11425; Fri, 7 Apr 95 13:13:16 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id NAA10674; Fri, 7 Apr 1995 13:07:18 -0700 Date: Fri, 7 Apr 1995 13:07:18 -0700 Message-Id: <199504072007.NAA10674@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Enhanced package modeling for V3 IBIS My proposal is to add a PCB (like) specification to IBIS. I am think it would be an attached file like .pkg is already. Since there really is no PCB standard, it seems to me we could provide a simplified format that is an IBIS connection layer specification. None of the major groups have yet to get a PCB standard accepted. It seems the major problem is that the PCB companies don't want it. Only the users want it. EDIF and IPC both have "standards that are not used. The EDIF PCB group is also working on an MCM specification to add on to EDIF PCB. There may be some overlap with this effort and IBIS. So it isn't clear that there is any advantage to using an existing standard except that it is debugged. The requirements are that it be an ASCII format that can be released to the public domain. I will follow up by getting a copy of what the EDIF PCB group is working on for MCM's. The advantages for the IBIS community of a PCB like specification are: - MCM supported as a chip - Hypbirds supported as a chip - Chip modules (like CPU's with cache) supported as a chip. - SIMM modules supported as a chip. - Packaging like PGA's with ground planes could be nicely supported. - Easily available design data for IC vendors. No need to convert mechanical data into behavioral data. The disadvantages are: - Some vendors may not want to disclose packaging designs - Availability of translators. Another idea is to enlist Router Solutions to create an output generator in whatever format we decide on. Then anyone that needs to output this format could simply call Router Solutions and order a translator from their format to the IBIS format. Router Solutions already supports about every PCB and mechanical package on the planet Earth. We would probably need to pay them to develop the writer portion to create IBIS. I haven't talked to them yet but I will. Have a great day...Kellee Crisafulli, HyperLynx Inc. From Arpad_Muranyi@ccm.fm.intel.com Fri Apr 7 13:46:23 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11674; Fri, 7 Apr 95 13:46:23 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rxKpq-000UkPC; Fri, 7 Apr 95 13:40 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rxKpp-000twoC; Fri, 7 Apr 95 13:40 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 7 Apr 95 13:40:53 PST Date: Fri, 7 Apr 95 13:40:53 PST From: Arpad Muranyi Message-Id: <950407134053_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Parser issues Hi All, I just spoke with Paul about the last set of parser changes. He told me that they will send a response to the reflector about the changes requested by the middle of next week. The issues seem to be clear, but if they run into problems they will contact us with more questions. Arpad From Will_Hobbs@ccm2.jf.intel.com Fri Apr 7 17:32:47 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13485; Fri, 7 Apr 95 17:32:47 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rxOMN-000UjMC; Fri, 7 Apr 95 17:26 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rxOMN-000twoC; Fri, 7 Apr 95 17:26 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 7 Apr 95 17:26:43 PST Date: Fri, 7 Apr 95 17:26:43 PST From: Will Hobbs Message-Id: <950407172643_3@ccm.jf.intel.com> To: kellee@nwlink.com, ibis@vhdl.org Subject: Re: Enhanced package modeling for V3 IBIS Text item: IBIS-folk, Just a thought, how does DIE handle traces in their MCM description? Are we trying to reinvent a wheel? Will My proposal is to add a PCB (like) specification to IBIS. I am think it would be an attached file like .pkg is already. Since there really is no PCB standard, it seems to me we could provide a simplified format that is an IBIS connection layer specification. None of the major groups have yet to get a PCB standard accepted. It seems the major problem is that the PCB companies don't want it. Only the users want it. EDIF and IPC both have "standards that are not used. The EDIF PCB group is also working on an MCM specification to add on to EDIF PCB. There may be some overlap with this effort and IBIS. So it isn't clear that there is any advantage to using an existing standard except that it is debugged. The requirements are that it be an ASCII format that can be released to the public domain. I will follow up by getting a copy of what the EDIF PCB group is working on for MCM's. The advantages for the IBIS community of a PCB like specification are: - MCM supported as a chip - Hypbirds supported as a chip - Chip modules (like CPU's with cache) supported as a chip. - SIMM modules supported as a chip. - Packaging like PGA's with ground planes could be nicely supported. - Easily available design data for IC vendors. No need to convert mechanical data into behavioral data. The disadvantages are: - Some vendors may not want to disclose packaging designs - Availability of translators. Another idea is to enlist Router Solutions to create an output generator in whatever format we decide on. Then anyone that needs to output this format could simply call Router Solutions and order a translator from their format to the IBIS format. Router Solutions already supports about every PCB and mechanical package on the planet Earth. We would probably need to pay them to develop the writer portion to create IBIS. I haven't talked to them yet but I will. Have a great day...Kellee Crisafulli, HyperLynx Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Enhanced package modeling for V3 IBIS From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Message-Id: <199504072007.NAA10674@washington.nwlink.com> Date: Fri, 7 Apr 1995 13:07:18 -0700 Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id NA A10674; Fri, 7 Apr 1995 13:07:18 -0700 Errors-To: Derrick_Duehren@ccm.jf.intel.com Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA11425; Fri, 7 Apr 95 13:13:16 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 7 Apr 95 13: 48:40 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Fri, 7 Apr 95 13:50:26 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rxKzA-000twpC; Fri, 7 Apr 95 13:50 PDT From skaufer@ix.netcom.com Sun Apr 9 23:12:05 1995 Return-Path: Received: from ix4.ix.netcom.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08861; Sun, 9 Apr 95 23:12:05 PDT Received: from by ix4.ix.netcom.com (8.6.12/SMI-4.1/Netcom) id XAA11071; Sun, 9 Apr 1995 23:06:11 -0700 Date: Sun, 9 Apr 1995 23:06:11 -0700 Message-Id: <199504100606.XAA11071@ix4.ix.netcom.com> From: skaufer@ix.netcom.com (Steve Kaufer) Subject: Opportunity to tout your signal-integrity efforts/skills To: si-list@siserver.eng.sun.com To: ibis@vhdl.org If you are located in the Santa Clara area or will be attending the upcoming WinEDA conference AND are interested in an opportunity to share publicly some of your work in the areas of signal integrity and high-speed design, read on... A high-speed design session at the WinEDA conference (April 26 & 27 in Santa Clara, CA) has just had a paper cancellation. As session chair, I'm looking for another presenter to fill the spot. The paper (to be presented on April 27) is to cover an application of high-speed design methodology, with particular emphasis on signal integrity. Because the conference has a Windows focus, work done at least partially on the PC is preferred (but not essential). ***There is no need to produce a written paper; only a 15-minute overhead-slide presentation is needed. No "formal" preparation is required.*** If you think that some work you have done in this area is noteworthy and want to share it with other engineers, this is an excellent opportunity to "toot your horn." I will give preference to "users" over "vendors," but am willing to discuss any topic/presenter that would be of potential interest to the attendees. (If you are a consultant who does work in this area, this is an opportunity tailor-made for you: excellent exposure to potential clients.) If you are at all interested in this offer, please contact me immediately by phone at 206-869-2320, or e-mail at skaufer@ix.netcom.com. Steve Kaufer HyperLynx, Inc. From kellee@nwlink.com Mon Apr 10 13:47:42 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19771; Mon, 10 Apr 95 13:47:42 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id NAA19561; Mon, 10 Apr 1995 13:41:45 -0700 Date: Mon, 10 Apr 1995 13:41:45 -0700 Message-Id: <199504102041.NAA19561@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Re: Enhanced package modeling for V3 IBIS >To: Will Hobbs >From: kellee@nwlink.com >Subject: Re: Enhanced package modeling for V3 IBIS > >> >> >>Just a thought, how does DIE handle traces in their MCM description? Are we >>trying to reinvent a wheel? >> >>Will >> > >Good question. Any ideas on who to ask? Do you know how to get ahold of Randy? > >I am following up with the EIA folks and have contacted Patty about getting a copy >of the PCB format so I can report to the group about what the MCM people at EDIF >are doing. > >Perhaps someone else would be interested in following up with the DIE spec. > > Have a great day...Kellee Crisafulli, HyperLynx Inc. From bward@micro.ti.com Wed Apr 12 08:06:10 1995 Return-Path: Received: from gate.ti.com (news.ti.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15134; Wed, 12 Apr 95 08:06:10 PDT Received: from itg.ti.com ([128.247.93.50]) by gate.ti.com (8.6.10/) with SMTP id KAA21794 for ; Wed, 12 Apr 1995 10:00:35 -0500 Received: from micro.ti.com (wotangate.micro.ti.com) by itg.ti.com (4.1/ITG-1.1) id AA29272; Wed, 12 Apr 95 09:59:52 CDT Received: from leviathan.micro.ti.com by micro.ti.com (4.1/SMI-4.1-941013) id AA19173; Wed, 12 Apr 95 10:00:30 CDT Received: by leviathan.micro.ti.com (4.1/SMI-4.1) id AA08178; Wed, 12 Apr 95 10:00:30 CDT Date: Wed, 12 Apr 95 10:00:30 CDT From: bward@micro.ti.com (Bob Ward) Message-Id: <9504121500.AA08178@leviathan.micro.ti.com> To: ibis@vhdl.org Subject: Request for a presentation Hi, Ibis Guys! I have an opportunity for someone, cleverly disguised as a task. I am looking for someone to come in to TI in Houston to give about an hours presentation on their ibis capabilities, how they support ibis in their simulation offerings, and if they have it, any support for making ibis models. Also, any overview of the state of support industry wide would be appreciated. The presentation is to a modelling steering team here in TI, and is to quite a receptive audience, and one which carries some little weight in the overall decision process here. The presentation would be followed by a time of discussion to last as long as anyone feels they still want to discuss. Typically these things have gone on for about an hour to two hours total. Our meeting is to be 04 MAY 1995 here in Houston. Could probably be rescheduled if that would be an enabler for you. Any of you EDA vendors interested? Please contact me directly for more detail, if so. Thanks! Bob Ward bward@ti.com or bward@neosoft.com From mbs@eos.ncsu.edu Thu Apr 13 11:50:47 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 AA00170; Thu, 13 Apr 95 11:50:47 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA17917; Thu, 13 Apr 1995 14:45:14 -0400 From: mbs@eos.ncsu.edu Message-Id: <9504131845.AA17917@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: NEW IBIS MODELS Date: Thu, 13 Apr 95 14:45:13 EDT The models can be found in /pub/ibis/models/national/cgs Michael Steer --- IBIS librarian Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes ------------------------------------------------------------------------------- lct2524m.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clock Driver lct2524n.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clock Driver ct2524m.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clock Driver ct2524n.ibs cgs 04-05-95 1.0 1.1 1 to 4 Min. Skew 3V Clock Driver c2525m.ibs cgs 04-05-85 1.0 1.1 1 to 8 Min. Skew Clock Driver (CMOS) c2525n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (CMOS) ct2525m.ibs cgs 04-05-85 1.0 1.1 1 to 8 Min. Skew Clock Driver (TTL Compa) ct2525n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (TTL Compa) b2525m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (Bipolar) b2525n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (Bipolar) c2526m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (CMOS) c2526n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (CMOS) ct2526m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (TTL Compa) ct2526n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (TTL Compa) ct2527v.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (TTL Compa) b2528m.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (Bipolar) b2528n.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (Bipolar) b2528v.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (Bipolar) b2529v.ibs cgs 04-05-95 1.0 1.1 1 to 8 Min. Skew CLock Driver (Bipolar) 2534v.ibs cgs 04-05-95 1.0 1.1 Quad Memory Array Clock Driver (Commercial) 2535v.ibs cgs 04-05-95 1.0 1.1 Quad Memory Array Clock Driver (Industrial) 2536v.ibs cgs 04-05-95 1.0 1.1 Quad Memory Array Clock Driver (Industrial) b303m.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b303n.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b303v.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b304m.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b304n.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b304v.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b305m.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b305n.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver b305v.ibs cgs 04-05-95 1.0 1.1 Octal Divide-by-2 Skew Clock Driver 701v.ibs cgs 04-05-95 1.0 1.1 Low Skew PLL 1to8 CMOS Clock Driver From Will_Hobbs@ccm2.jf.intel.com Thu Apr 13 13:28:54 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00739; Thu, 13 Apr 95 13:28:54 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rzVPV-000Ui1C; Thu, 13 Apr 95 13:22 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rzVNe-000u0wC; Thu, 13 Apr 95 13:20 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 13 Apr 95 13:20:46 PST Date: Thu, 13 Apr 95 13:20:46 PST From: Will Hobbs Message-Id: <950413132046_2@ccm.jf.intel.com> To: mbs@eos.ncsu.edu, ibis@vhdl.org Subject: Re: NEW IBIS MODELS Text item: Way to go, Syed!!!! Will The models can be found in /pub/ibis/models/national/cgs Michael Steer --- IBIS 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: Thu, 13 Apr 95 14:45:13 EDT Subject: NEW IBIS MODELS To: ibis@vhdl.org Message-Id: <9504131845.AA17917@mbs.ece.ncsu.edu> From: mbs@eos.ncsu.edu Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA17917; Thu, 13 Apr 1995 14:45:14 -0400 Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4 .1/SMI-4.1/BARRNet) id AA00170; Thu, 13 Apr 95 11:50:47 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 13 Apr 95 12 :21:43 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 13 Apr 9 5 12:21:54 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rzUSj-000tzQC; Thu, 13 Apr 95 12:21 PDT From satishp@lsil.com Thu Apr 13 14:29:29 1995 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01504; Thu, 13 Apr 95 14:29:29 PDT Received: from lsi.lsil.com by relay1.UU.NET with SMTP id QQylij19455; Thu, 13 Apr 1995 17:23:54 -0400 Received: from mhost.lsil.com by lsi.lsil.com with SMTP id AA15521 (5.67a/IDA-1.4.4 for ); Thu, 13 Apr 1995 14:02:13 -0700 Received: from mc10 by mhost.lsil.com (4.1/SMI-4.1) id AA14276; Thu, 13 Apr 95 14:02:07 PDT Received: by mc10 (4.1/SMI-4.1) id AA09782; Thu, 13 Apr 95 13:58:40 PDT Date: Thu, 13 Apr 95 13:58:40 PDT From: satishp@lsil.com (Satish Pratapneni) Message-Id: <9504132058.AA09782@mc10> To: ibis@vhdl.org Subject: Re: iinstallation of s2ibis Cc: jjong%wms1@lsil.com Hello everyone! I was trying to get familiar with "s2ibis" tool. When I tried the "tryme" case given in S2IBIS/test directory I got following message, my command: s2ibis tryme tryme.ibs message: s2ibis: Version 1.0 North Carolina State University s2ibis: Using input file named tryme s2ibis: Using output file named tryme.ibs s2ibis: Specified simulator: HSPICE. s2ibis: Starting HSPICE job, input file pdtthree.spi. sh: hspice: not found s2ibis: unable to open spice deck output file pdtthree.out s2ibis: SPICE job pdtthree.spi aborted. Output in pdtthree.out. s2ibis: Starting HSPICE job, input file pdnthree.spi. ...... and it keeps doing for all files. Why am I not able lto open *.out files. Thank you in advance, -Satish LSI Logic Corp. Milpitas, CA From scott@icx.com Thu Apr 13 14:40:03 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01614; Thu, 13 Apr 95 14:40:03 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 13 Apr 95 14:34 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 13 Apr 95 14:36 PDT Message-Id: To: satishp@lsil.com (Satish Pratapneni) Cc: ibis@vhdl.org, jjong%wms1@lsil.com, scott@icx.com Subject: Re: iinstallation of s2ibis In-Reply-To: Your message of "Thu, 13 Apr 1995 13:58:40 PDT." <9504132058.AA09782@mc10> Date: Thu, 13 Apr 1995 14:36:47 -0700 From: Scott Aron Bloom > > Hello everyone! > > I was trying to get familiar with "s2ibis" tool. > > When I tried the "tryme" case given in S2IBIS/test directory > I got following message, > > my command: s2ibis tryme tryme.ibs > message: > s2ibis: Version 1.0 North Carolina State University > s2ibis: Using input file named tryme > s2ibis: Using output file named tryme.ibs > s2ibis: Specified simulator: HSPICE. > s2ibis: Starting HSPICE job, input file pdtthree.spi. > sh: hspice: not found ^^^^^^^^^^^^^^^^^^^^^^^^ > s2ibis: unable to open spice deck output file pdtthree.out > s2ibis: SPICE job pdtthree.spi aborted. Output in pdtthree.out. > s2ibis: Starting HSPICE job, input file pdnthree.spi. > ...... > and it keeps doing for all files. Why am I not able lto open *.out files. > > Thank you in advance, > > -Satish > LSI Logic Corp. > Milpitas, CAS Satish, the problem is that you do not have HSPICE in your path. If you read the man pages, you will find that there is a section on selecting a spice type, yours is set to H for hspice. Fix that and the rest should work out for you. Scott Interconnectix, Inc From Derrick_Duehren@ccm2.jf.intel.com Thu Apr 13 16:10:12 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15347; Thu, 13 Apr 95 16:10:12 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rzXwB-000UglC; Thu, 13 Apr 95 16:04 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rzXsO-000u1HC; Thu, 13 Apr 95 16:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 13 Apr 95 16:00:40 PST Date: Thu, 13 Apr 95 16:00:40 PST From: Derrick Duehren Message-Id: <950413160040_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Minutes from EIA IBIS Meeting 4/7/95 DATE: April 13, 1995 FROM: 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, Hillsboro, OR 97124 USA and Derrick Duehren (503) 264-4299, fax (503) 264-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager, IBIS Secretary SUBJECT: Minutes from EIA IBIS Open Forum Meeting 4/7/95 PARTICIPANTS: ARPA Randy Harr AT&T Global Info Solutions Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec [M] Dileep Divekar* Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HP Palo Alto Tom Langdorf HP EESof Karl Kachigan, Henry Wu HyperLynx [M] Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, John Burnett INCASES [M] Werner Rissiek, Olaf Rethmeier* Integrated Silicon Systems Eric Bracken Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren*, Tim Schreyer Interconnectix, Inc. [M] Bob Ross* Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei, John Sliney MicroSim Arthur Wong National Semiconductor [M] Syed Huq, Raj Raghuraum, Atul Agarwal NEC [M] Hiroshi Matsumoto North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Quad Design Jon Powell* Quantic Labs [M] Mike Ventham Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments [M] Bob Ward Thomson-CSF/SCTF [M] Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zuken-Redac [M] John Berrie Zeelan Technology George Opsahl, Hiro Moriyasu In the list above, attendees at the meeting are indicated by *. Voting members are indicated by [M]. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # 5/5/95 (916) 356-9999 461609 5/26/95 (916) 356-9999 485256 All meetings are 8:00 AM to 10:00 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- CHECK-IN, INTROS, ANNOUNCEMENTS There were no corrections made to last month's minutes. New participant: David Johnson (BrianJohnson@vax.micron.com), of Micron Technology, applications engineering. Micron Technology is supplying Spice models to customers and wants to send IBIS models instead for greater accuracy and so they don't have to worry about intellectual property issues. AR Derrick -- Publish an explanation of how to join the EIA IBIS group. [Done -- below] To become a voting member of the forum, send $500 annual dues to: EIA/Electronic Information Group c/o Patti Rusher 2500 Wilson Blvd. Arlington, VA 22201 (703) 907-7545 Fax: (703) 907-7501 Email: prusher@eia.org The source code to the Golden Parser is available for $500 (or $250 for voting members). Send requests for the parser to Patti Rusher. EIA IBIS MEMBERSHIP UPDATE: The following companies have become voting members of the EIA IBIS Open Forum. Contec Microelectronics $750.00 (licensed parser) HyperLynx $250.00 (licensed parser) INCASES Engineering GmbH $250.00 (licensed parser) Interconnectix $250.00 (licensed parser) National Semiconductor $250.00 (licensed parser) NEC Corporation $500.00 Quantic Labs $250.00 (licensed parser) Texas Instruments $500.00 Thomson-CSF $0 (DAD Member) Zuken-Redac $500.00 Intel appears to have lost its membership letter. Pattie is sending a replacement. FYI: The IBIS ANSI Project Number is 3527. That will also be its Standards Proposal number. NEW AGENDA ITEMS: None. PRESS UPDATES: The March 16 EDN Magazine has a feature article on IBIS by Derrick, Will, Arpad, and Robin Rosenbaum. NEW MODELS AVAILABLE: Arpad will be posting some models soon. Micron Technology has some preliminary IBIS models for 32-bit cache SRAMs for Pentium(R) processors that they are willing to post. David Johnson will work with Kellee and Bob Ross to get his files checked and posted to vhdl.org. PROGRESS TOWARD ENLISTING NEW IC VENDORS Will has been getting three times the requests on ibis-info since the EDN article came out. GOLDEN PARSER 2.1 PROGRESS AND RELEASE DATE Stephen reported a GP error with N/As in the typ. column. GP Release date: Will recommended that we release the GP `now' (with know bugs fixed), rather than continuing to do turns. Paul Munsey was not available to comment. AR Arpad -- Contact Paul, determine status of the release, and post it to the reflector. [Update: Paul and Ron want another beta with all previously paid-for fixes incorporated. After verification, they will add the subsequent changes, such as case and ^M.] EIA AFFILIATION STATUS Eight companies have joined the EIA IBIS subcommittee (10 as of 4/12/95). We decided to allow Design Automation Div. members to waive the $500 dues. They will get the same discount on purchasing the GP source code as other paid members. Derrick pointed out that the Design Automation Div., as our parent organization, insures our finances, so it's not such a bad deal. We need a Press Release announcing our EIA affiliation and Spec balloting. Derrick is putting the boilerplate fluff around the spec so it meets the EIA's voting standards, due 4/10 to Pattie Rusher [Done 4/13/95], with an expected quick turnaround for balloting. AR Derrick -- Talk to Pattie Rusher. [Done] o Clarify DAD parser licensing ($250), non-member GP licensing ($500), and the fee for DAD membership. [DAD membership is $1,000 - $15,000 depending on size of company.] o Clarify process/schedule for the vote on IBIS 2.1 Spec. [Spec will go out for ballot about 1 week after Pattie receives the "fluffed" spec from Derrick. We will need to decide how we will process responses/change requests. Do we need a subcommittee?] o Inform her of the need for a Press Release. [Pattie will do.]] o Does EIA have a WWW home page? We'd like to have one. [YES. Contact Cecilia Fleming (703) 907-7554, cfleming@eia.org.] o Best way to roll in our passed BIRDs into the election. Should we ballot on a Version 2.2? [Pattie recommends keeping it as 2.1 with erratta calling out the updates. Derrick will implement this in his "fluffed": spec.] 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, 8:30 - 1:00. Jon has drafted an "IBIS Spoken Here" placard. He asked for feedback on how fancy they should be. Consensus was something in the $25 range (8.5" x 11" on foamboard backing). Each participant will pay for their own placard. Kellee wants to use the placard design at WinEDA. AR Jon -- Send placard file to Derrick for posting to vhdl.org. Birds of Feather. Jon Powell will put together a BOF poster following the same motif as the placards. He also volunteered to present some overview foils (30 min.) to get the BOF conversation going. AR Jon -- Sign us up for a BOF session and prepare the foils. REV 2.1 UPDATES o S2IBIS 2.1 No discussion. o Cookbook Kelley and Bob Ross have done very little, but expect to work on it in the coming weeks. o Overview No discussion. SGML/HTML SUPPORT? Syed was not present to comment, although we briefly discussed our desire to have a WWW home page. Derrick will follow up with Pattie Rusher. BIRD 26 - TAB CHARACTERS DISCOURAGED IN .IBS FILES Vote taken, BIRD 26 APPROVED UNANIMOUSLY. (Unofficially, since only 4 `official' membership companies were present -- we need 5. We will reconfirm at the next meeting when more companies have officially joined the EIA IBIS subcommittee.) BIRD 27 - NEW KEYWORD FOR DIFFERENTIAL I/O BIRD 27 adds a capability that is already there. It is a convenience only. The forum agrees that we should not add things just for convenience and recommends not approving BIRD 27 at this point. DIODE TRANSIT TIMES Tim Schreyer will attend the next meeting to discuss this topic. ENHANCEMENT TO THE TIMING SPEC Stephen lead a discussion on how to model packages with transmission line effects. Two ways proposed: Stephen suggested we use the existing matrix methodology with extensions, and Kellee suggested using a PCB type of description. Kellee suggested allowing bonding pad to board rlc and board to pin rlc for bonding wires and PCB description for the in-package board. Jon said that many off-shore ASIC vendors hand draw the circuit boards, so there is no path in those cases for getting this data. Jon does like the PCB description because it improves the ability to discern crosstalk between the traces and wires, etc. MCMs, SIMMs, complex packages, multi-cavity packages, hybrids, etc. can all be described with PCB approach. This may be revealing proprietary info, and eliminates level 1 modeling capability in those cases. Some had concerns that many semiconductor companies won't be willing to put this level of package details in the models. After a lengthy discussion, we acknowledged that the existing capabilities in the spec are better than nothing. Kellee wants to keep the number of new descriptions to a minimum, since we already have 3 descriptions. (single rlc, rlc per pin, rlgc). The question is, do we need 2 additional descriptions (1. transmission line segment description or coupled rlgc matrix 2. full PCB description.) or will one additional description suffice? Any vendor that would like to experiment with Intel's complex package models, send a request to speters@ichips.intel.com (Jon, Kellee, Bob R.). AR Derrick/Stephen: Send the complex package models to Jon, Kellee, Bob R. [Done] David J. informed us that a Jedec package measurement spec (JCB-95-10) is being voted on now that may give us some ideas. AR Stephen -- Evaluate the Jedec proposal. WRAP-UP, NEXT MEETING PLANS Our next meeting is a teleconference 5/5/95 (pushed out one week due to WinEDA and other events that week). ============================================================================== NOTES 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 kellee@nwlink.com Thu Apr 13 18:00:52 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26700; Thu, 13 Apr 95 18:00:52 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id RAA00387; Thu, 13 Apr 1995 17:54:50 -0700 Date: Thu, 13 Apr 1995 17:54:50 -0700 Message-Id: <199504140054.RAA00387@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Way to go National (Syed) You get the award for the most models in one batch. *** *** () () o { WOW } Have a great day...Kellee Crisafulli, HyperLynx Inc. From kellee@nwlink.com Thu Apr 13 18:13:51 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03673; Thu, 13 Apr 95 18:13:51 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id SAA01017; Thu, 13 Apr 1995 18:07:55 -0700 Date: Thu, 13 Apr 1995 18:07:55 -0700 Message-Id: <199504140107.SAA01017@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: IBIS Version 2.x COOKBOOK (HELP) Hello in IBIS land, I am the present editor/text masher for the cookbook. I am looking for a few good souls to help create materials for the new IBIS cookbook. Anyone that has experience creating 2.0 models is invited to send me a whole article or even just bits and pieces to include in the new article. What works good. What melted my device. Slick methods. Fixture ideas/problems. Editing hints. It is possible to take the Version 1.x cookbook put version 2.x on the cover and add a few paragraphs. It would be nice to add more meat than this from IC vendors that are creating models. HELP Have a great day...Kellee Crisafulli, HyperLynx Inc. From bob@icx.com Thu Apr 13 18:25:24 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14053; Thu, 13 Apr 95 18:25:24 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 13 Apr 95 18:19 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 13 Apr 95 18:21 PDT Message-Id: Date: Thu, 13 Apr 95 18:21 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS PROGRESS To Members: For interest, here is an index showing the expansion and modification of IBIS. Bob Ross, Interconnectix, Inc. YES NO VERSION 1.0 1993 VERSION 1.1 8/20/93 X BIRD1 ECL Extensions X BIRD2.2 Requiring VIH VIL Thresholds for Input Devices X BIRD3 Multiple Power Supplies and References X BIRD4 ECL Extensions X BIRD5.4 Pin Mapping for Ground Bounce Simulation X BIRD6.2 Differential Pin Specification X BIRD7.2 Open Specification Completion X BIRD8.2 Specification of V/I data Monotonicity X BIRD9.3 Terminator Specification X BIRD10.2 Describing Coupling Effects in Package Models X BIRD11.2 Improving Common Error Detection in IBIS_CHK Program X BIRD12.2 Non-Linear Driver Waveforms X BIRD13.2 Clarify Some Conditions of Measurements X BIRD14.3 Adding Four New Sub-parameters to [Model] X BIRD15 Clarification on the Usage of the V/I Tables VERSION 2.0 6/9/94 X BIRD16 Adding Four New Sub-parameters to [Model] X BIRD17 Number of Points X BIRD18.2 [Diff Pin] Parameter Order X BIRD19.1 V_fixture Subparameter Min/Max Additions X BIRD20.1 Error Correction Regarding Monotonicity Statement X BIRD21 Waveform Table Minimum Number of Entries X BIRD22 Sub-Parameter Case Sensitivity X BIRD23 Waveform Table Minimum Number of Numerical Entries X BIRD24.1 C_comp, Ramp Rates and Waveform Tables VERSION 2.1 12/9/94 X BIRD25.3 Data Derivation Expansion X BIRD26 General Syntax Rules and Guidelines on TAB Character BIRD27 New Keyword to Specify Default Differential Threshold From cpk@Cadence.COM Fri Apr 14 06:57:47 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12815; Fri, 14 Apr 95 06:57:47 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA03097; Fri, 14 Apr 1995 06:52:11 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma003016; Fri Apr 14 06:51:51 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA09274; Fri, 14 Apr 95 06:48:27 -0700 Received: by hot (5.65+/1.5) id AA15124; Fri, 14 Apr 95 09:51:46 -0400 Date: Fri, 14 Apr 95 09:51:46 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9504141351.AA15124@hot> To: IBIS@vhdl.org, Derrick_Duehren@ccm2.jf.intel.com Subject: Re: Minutes from EIA IBIS Meeting 4/7/95 > From Derrick_Duehren@ccm2.jf.intel.com Thu Apr 13 19:12:06 1995 > Return-Path: > From: Derrick Duehren > To: IBIS@vhdl.org > Subject: Minutes from EIA IBIS Meeting 4/7/95 > Content-Length: 12025 > X-Lines: 289 > > > Some had concerns that many semiconductor companies won't be willing to put > this level of package details in the models. After a lengthy discussion, we > acknowledged that the existing capabilities in the spec are better than > nothing. Kellee wants to keep the number of new descriptions to a minimum, > since we already have 3 descriptions. (single rlc, rlc per pin, rlgc). The > question is, do we need 2 additional descriptions (1. transmission line segment > description or coupled rlgc matrix 2. full PCB description.) or will one > additional description suffice? > A transmission line description is a rlgc description plus length. The only difference between lumped RLGC and transmission line RLGC is the RLGC in transmission line are per unit length parameters. RLGC per unit length + length of the transmission line is a complete description. From huq@rockie.nsc.com Fri Apr 14 10:19:26 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14041; Fri, 14 Apr 95 10:19:26 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA17060 for ibis@vhdl.org; Fri, 14 Apr 95 10:13:52 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA19668 for ibis@vhdl.org; Fri, 14 Apr 95 10:13:51 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA15073; Fri, 14 Apr 95 10:14:51 PDT Date: Fri, 14 Apr 95 10:14:51 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9504141714.AA15073@rockie.nsc.com> To: ibis@vhdl.org Subject: In Search of an IBIS HomePage Cc: huq@rockie.nsc.com Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 33 Hi IBISfans, Here at National, we have created an IBIS HomePage for Netscape(Mosaic) with all kinds of information on IBIS including articles, Press Release information, Golden Parser Status, List of available models, IBIS Industry News and on and on..We intend to spread info on IBIS to as much of a wider audience within National as possible. (use xv or other tool to view the .gif files) Unfortunately because of Firewall, the outside industry cannot access this HomePage presently. I am just attaching two .gif files to give you a flavor of what a typical IBIS HomePage may look like. I seriously believe we should set one up and allow anyone and everyone to visit the IBIS HomePage. We can include presentation materials, Training information with Graphics, plots, waveforms, articles and all kinds of goodies.. Let's talk more about this.. By the way, the IBIS models coming out of National is a team effort and I thank TCAD(Technology CAD) and all others for their support. Stay tuned for more IBIS models from National within the coming months. Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------- X-Sun-Data-Type: gif-file X-Sun-Data-Name: ibis2.gif X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 215 begin 600 ibis2.gif M1TE&.#=A,0(< O4 /__S,# P &]O;^?GY_^9 ,QF,S-F9LS,S/_,S,S_ M_\S,_V9F9C-FF?___\S_S/_,_V:99IEF,__, &:9F9F9S)F9F?__F?_,FF4F!EEI%3J/@*?1+[G++X'!1K<:BWV9K&SZ&+^MLNSZ^ MO^/%8GEK4%I;@(5_=5Y'@GF-?'V+CX.05GN)5YE'0IJ=;8A[?;9FM;-EBFFX<;:ROI/$@I3!:*Z!S8Q.J7Z4 M2+I?OI? T973HK6FS,_%HYWH0YSII4_,RL)7R->2;[SR\6>_[HK1UI#B0KVB M0V<.0&^D!@ZZIQ">-'T'!>Z[EFT?M7Z+Y)$[0^X3MV\334ETEC ?.R/K3O:3 M)2D]]\PCR9\@M%4E6?:AR4UE4%+7":M5M'BR(WM"B=0OH7$Q=.EG1 MHG?.U;^UM*"M3?H6;*R^;-V\!8:HV&!D?]56PZ:7YRK#5!MCIIJT[JC-@@TO M;FPWT.ANE.6B5@S6KLZCE]M:$[VW-5G H?%&AJLRY=G?P(,+'T[\[+_BR),K M7\Z;N?/GP(]#GTZ]>@#?UK-KWYZ1N_?OZ:2#'S]D[GV\)U# MBT\?7/W[T-7CW\^_O___ 8H(#OZ#6C@@0@FJ.""#!91H'9Y4MU? MQ%7X&VZE_GF6W'L:=>>)AN65]1Z(F:#8X(KIL3>;5"V1R*)\9%VEG(S-A1>? M8SC:.../VCWXH8XP*>2AB>T,>:%PQ[U(8H]'XH-DE.#Q>))50&:9G9 IAG;3 M8IT)!F,HXN'B)9B/);:7;)^]-LY=,;WY&4]Q9H2E5O:-1HUN869FYBD\BE8G M-GV"!JANV?!"TTV,=3B?EI 2QV6*N7CV5)LKF;.14WTNU5(D^O@4:EV#167I MIYX:D\^EFV8%*E&*@MI5I+0*-ZF4$<9EI*Y.1998/7;"J:HJ6+7#E:_!'@)F M9\J*LHU8HY;SHE<._>%24;5F.]RMQA;4;;0_!*NK:K ML+P3VWN/FM+@"Z]$%'_D[\>: "RL.&C.9I5F>A[:I,JI<<;8HH55YIJ>;,X' MF)]T$H9*S#([^B?)FI$,]&L1!GV7H;L9'!B'D E[F)^UQ5Q:OR!G*;*/56>M M=898;^TU=5=3^?789"=)==EHGQ3VHVFW33;;;L<-7-ARUVWWW7BC0W?>?/?M M=]E[_RWXX(1#&GCAB">NN("'+^[XXY"CUWCDE%=NN7.37Z[YYIP3V/GGH(>^ MK>BDEVZZ6:>GKGKGF:_N^NMHMP[[_NRT@RQ[[;CG;K7NO/<.N._ !V^[\,07 MK^7:-Y=';D[1N9ODC>N=;1QM3??5#WU,W_BF+48.:&F:25["?73!J& N:!SG($A6)4'Z(*1D&5U,H M#)GFA>!HW_)6*TTII$C8?'A42#(2#?"QX**=*09.W:P5;H2 MCU4D5+H.LJZ(G$Q2^"Z/G5*/ MN#H5*P/9,"U6*QRJM"2JJO7%,:FIE=JLA%'4XK Y=LDR-D38#PU82&-& IEE MA$JXMAC/=K8'>9IZ6IS8PL\)S0,Q0P-C8,(D*$/!YI\BM(_09H:H;RYM96R2 M3+ZE5&4/%R MTPGQM; MXTI7K\ZUKG@MWEWSRE??[;6O@,7=7P-+V-<-MK"(/=UA$\O8T"VVL9#=W&,C M2UG*3;:RF%UJ9C>;UA^,P#0&M=O!!CN68I[W.;>+;FV$JUSIRLW MZ 8G; ,@@':WR]WN>O>[X VO>,=+_M[RFO>\Z$VO>M?+WO:Z][WPC:]\YTO? M^MKWONY5+G7W:SK/\O>_6?,O@ ?\+P(;6+('3O!5EU, QP 0EXL (BC( % M !"& A2 ,H^,,L:EV##V#A!B# 0@X LC( &,(##!6@PB&>\H,R- M. $/.$ "%' !BP@PP=0\0)B;( BT_C(!YK!AI>4,I",#WYI4TV4P8U;, M,H11(^R*@6/:F?=':X ">@SGV/<9TDW^,^8 M;C.9"&W2_D(WKWXG4AZ7&YV[1P. A6P0 56O6I5 ^#210YTK#4=9Y%&E(5U M+AGWH*KKE>HZI7GQ)U))'=KA0+H" $C !1!P 64G( $!N+2L,:T1DU&(A#)- M6A$5>D[.X"97!,7RMI%(;-*9F@+.!@ &DKWN:&<:T(+F-DEE-J%Y=T^?M;ZW MO7TM47Y#LMS])4X!,%"!9J\[ 1AX@++=7>0,6%D#\88S9>CM4@[)I=[R;AG& M_1)LGOG[D0 OW:,W8(%GJQL &TAYR@NP 0ZDW N5_D&JITGF&X<13=?69DJ MKD^.5]3G1PNYR(F3<@Z+US[NF+_E[Y<2> M\FHW_O)W_RUW\-2&T0F(&9\&@8 M8'T3( 'P-X'3!G'VIX$FZ" "]VH*V&"65G\N>((P>!WM-X'^-W^8QF80%X,P M:&K\QX(4F %5YG EJ(,G>( 4: =0(%$AH-L1H0Z:&HQ!H(^V(.P-H!.J(%& M:&E[5F57Z(2-(X#3UH57*&!BB']D6(;K=X9HZ'UJN(;/AUW!%8=R.(=T6(=V M>(=XF(=ZN(=\F%OZI1+,Y88$:%UF15R"6("$^!O8=8B#^((F8F(F:N(F<^%Z.R(B@&(&A.(JB2(JFN(&GF(I7T(:J2&JLV(IV]HJP MB&2R.(LT_E:+M@ABN)B+"K:+O'A@OOB+!!:,P@A@Q%B,_'6,R$A=RKB,SM6, MSGAB-VL$ ( "$6 =V[B-X\A7 M;V6.#@ #F".T.$!(7 [-B.>;56(, \2B/\@@"S[&.'Z"/[E@=_?B/\?B/ M#* <][B-%H"/!KF/U(&."[F0\N@ (" "PR&1 ;".(T "'CF1=,54($ !_@B0 M\E@"R 8 ""0P(&/W/B1^(@ $2F.)%E70&6. (F1%5 "&(F.O^&1'O !)# " M-SF3.5F2SF$"*:F2/]F20"4[/(F1_O'XDV )D#") M#E B< MFD,@DT>YCI5IF;_QE6,) %$9EZS)DG0ICPUY!=NXE1X0FBE0 :$9FBIPFA09 MF*ZYD(:9F0XPEW6YF$00C@%P BN0E6J)D[ZIDY>ID>>8D@XPG/_8F0!@ 82Y MD+-I!.*(E<^IG-'9E<$!ER# AB DMV)G2LYEHKYG40@DWV9EN7YFZDYCR5 M @Q@ A30D^ZYF6&)F(L) L^)E"- _IGWB9]G 9<4( (D4 (E\)6P&8\5^IK= M^9T">0*2B: B"9T+:I[ 88[[60(L0 +^Z9*=Z9[RR)V):8XB@([XJ)N@*9HA M2H[!$:,L4 (M,*%PN9 76I="^I(1$*$>4*+[20$W"EB!TY_[>99B*F9XNL*9LNJ82BIQ?"E>W M\Z,M>IB:"9NR20%M^@(P$ ,P\ (R, ,NX*5Q*J?,89U3ZIXG":$NX .L*8Q M< (P0 ,P4 .66J@BJAQTBJ882I8,L)^-^J@N ,GX*H",<"F.-"F?CH#IZJJYYI6-46G%) #_=F/^[FE$^H")R # MSLJF@1JME%H#CKFO9U537\D (T"Q)9 #12JA_>D"?#JOD/JGT8JO#KNJ$"M7 MST$!Z'FQ+)D")L"M&""0HQJI( L#^#JN,F"I-1 #)6NRSY&2_1B2&;:?W[FF MIVJP?IJJECH#.;NS/-NS#I ".0"U*0 ") "E1+"FJJJJ(SNR_C# M$W['/VX M F "" ?UY!" +J/BJMC+@M5_['!: CB=)J$.@J^4J ^.ZJR_@MF3UC7P; M/'[[MWXEN(T6N(3K:(<+9H:;N+6SN(P[.X[[N(8EN3,6N92K.I9[N8JEN;W( MN0F6N9XK.J ;NJ SNJ1+>\2A SHP'*K;NMS1NJNK'*Y['K ;N[4[NT-0NT4 MNP$0NZ>K#L6!N\ AO-I!O*FKNNLAO+.KO,A+!,O;O+][.+PK',;;";[+NM!+ MOG[&^NKOM[+'.UKO>0+O>,; MOMP;OYX;.,@+OKD[O\]KN_:KNZY[_K_>V[_-R[O3^[\%?+O@B[\"K+^WN[T M7+\03,$4K+_1R[K;:P0.K,$&O,#^F\ "G,'WR\ 83,(7_+\LS,"Z>P3,V\(P M;,$HC,$F_+LH0;TK7,/K>\+HN\,_O+LJ',1$3,0!W,(^?,1&G+Y)S,06O, U M;,(:S+E[<\#7J\0SO,(^',5+O+I8K,3&V\01S,-.K,5E+,0[7+TOO,'!\<%F M#,(#/,9<[+]!_,5#7,0VW,5D+,<>',=-C,=1#,9WK,:*3,E73,.+/,.$3#<2/,GM*\: 3,<-S,>2'+^@[,B6;,.I M',IWC+Y]_KS)AGP%I9S(B(S"?(S$%QS")SS$7CS ,BS(*8S+M(S&>;S%\ZNY M5[/&;HS Y4O "BS&^4N\HYS!BSS"(AS"/]S)E_S)T_O!:)S V3S%5$S(R6C( MRWS.Z)S.ZKS.[-S.[OS.\!S/4&R^Y+Q?IEO/EH7/TW7/^OPX_-S/F@70QO7/ M HTX!%W0A'/0""TX"KW0Q>;0=P;1F=70$HTW%%W1=G/1&"TW&KW1Y./1D-71 M(!T[$70_Z]1MZ3-GVO,_*$-U-W72/S1L)X4]$/4=_4)5RU%#)B(3&C)LBG9= M)3T=.$)4+[% 3.)-,'0E;Q0]444I.@5 _>/4\\-+$%(=@8,G_M $/XM622X4 M304D0(BT*Q7":5!=24$-UNCQTDN2U3*]U2)BU!/4U@'$?D>M*#4M(2I$)A/G M,XW2UVTD!_DD1&XA(>8"2"9$V(;G>+1A28>440"U45"#0S1C:(SB02MU%9,] M9R7D4!RW0FU!4$M3"IM!)YU]04BT)J6-;9[]1)0=5D==,?+T2>2T2!XCVTJA M3M/$/%[6+(O6)/722T#Q$E=D17#DU,,-3O("3W4D*[DT1M0$W&3$3<^Q-[+7 M*X1T0"!7,93$VZ,$T\G W+QB*;]4T[E$3$+Q9?]61N#F2W+T2"8$1]N]#-+" MW;:-VTS!1-DD3H"T0M\M%(9=V^U=_M3)0=UAC=RSQ$>S9! )?MLY<]QFXTC# M%"6UQ-,3$RO&?49^I T;@VC%S1=^D4H5'DN7 "B][=SU4M_7U$WT--U9;3&H MP@<84^"PA.)XY. $XSXX5".8X-SL7>+^'4O7W4$1SDH[D2FN(N3E9$L%@=5< M5"Q,[FT=3N,28T_*@4^DMT2+O=LVET]&PU$F$U"CQ#:MX24ZXVW40R%3TSV) MC==\K5&FLD\+]>52@S,])WEP8E!ECC(@I>=N5U*ETN<>)=EO#E"4Y^4]0RIX M31EAK2"87CD<#7 __FT=. TAJS[1(\U8G1[K7W,[KVX%D1(QYX3 M8F(J4NXNW'3KW;X>WU[MF*T_I:3?#[[BZ)WN-$7M"5[D233;LTW<\7Y,W$[O MY&'L;-3H7!Y$.21N(-1(L8=0(P7P]0XIH_[O#M\?IAOQI#[QT^[I5M7J&/\? ML][QA@/R;B7RZ$KR:/7Q)C\C*)_R*[+R+,\@+O_R"A+S,H\@-%_S!G+S.)_Q M.Z]5.M_S'@_T/O]IWU;T1H_N0J\U^'3T3 \+.[ #2=\W2]_T_DR_ T@?]<-3 M551_]$]O]:B.]3-/]%K@J(ZZ]5K@]5X5O^-.S M%GS/]WX/^8./8A8 ^80_^21]^'JO]Y=OF'X?^84 ^)(/^J%?^8BO]XN_^#:9 M^7-?]*Q/^3L-"X9)^HF_^%M_^VV3]Z,/^XF/ (&?^48/_&DC_!@6^'L?^*9_ M],K?^KD/"S;9^:3O_!A6 O]HC/ !8P M_KR?^!6 $"9_NI?[.RO!>7O_M"__O?G/_] X! ,B8+ $9E4+IE-YQ,:E4ZI M5>L5F]5NN5WO%QP6C\E2 +:81C L["$"7D&4X,*TL9S7[_E]_Q\P4'"0<.KL MZHYHK:UMR&(.0>[1KJC0\A(S4W.3L]/3$$V-P9&M]*V"+JZ$ UTT@$NX1@349.UM[FWM[F2H1 MH9>4<50@M:3BNIN]W?T=ON][*E&:P90(^M1A/=[_'V! @?.DU),F+IK!1 (9 M-G3X4*5+F=82RJ39/:E3J>+CV11K5JV# MGF[U^A4LLJYAR98URVGL6;5KV>Y)VQ9N7+E7WLZU>Q=O@+IY^?8UN]=O8,%8 M 0\V?+AF8<2+&=]L_!AR3\61*5<.:AESYH:3-7?V_(KS9]&CE9$V?9I6:-2K M68O9R)WRM=/>5YV\>'2 MKX)WC]RY &7J#@_V[#L0(OR7=0126^T8!$]"0.L#L0;G;3-01&/3!)+L98T\L4NISR2QN^FR^_),O01!DK M5-%&LV+4T4B5@E322FVBU-),[].44[8P[134!$,=%:Q/23W5'U-17;4=55E] M51M789WU&%EIO35/7'7ER-9=??6DUU^%S60O+KW ,92"3&1SQ@MC!,38H9 U M:=KPXH/-1V=;&K-'0KH];$W ^_.TD7H!%%)<9A_D%P]V"!WLM73E) M-)/%:^7EMMTBZ80XW7G/;))C]SQ>.<@WA3S8XRY-E%D^"JF4MT6 ?6SVYH^_ M37EC;D\6KV%T3Z9998=#%I+*G_]C$V4O?SZW.-> M-D[KE+&6N.RN#SZ;;;"YWCKMN#/V^CJUM1[8[K8++FELN/6&&&RY\_[[Z[0# M+\MJO&V.V463\UY;<<@!!])OQP4'\O&]+[>2Y!_5!8YCT*\^&NW,I9S;=,D+ M[YE,QLM>_EV\O_D[W63#C8Z=+*OK1EMG>V&&_76)#S]W;I_O^P=-WOLP*W;Z^=\WSG_(L1S;Y*8UJ4"+8Z Q7NLTY[DT A%]\ M-*:68LWN2Z737H>:-3/X,(Y+#AH0A\+VI6O-['-)6QS-0,BY$WYP8AEL4M"6 M%1Z->7 ]3UN6,++%POG4K7'R:U.<&O2S_9BP9"!\89P05ZF%<4-ZM'CB:8+% MFBEN(XJSN"*?(G6E?YPH%F!43A6'54:NF!&-\"!C&MFHAS6V_A&.8GAC'.G8 MA3G6$8]8N&,>^0B*/O[1%7L$Y""5($A"'M*0AQQD(A7Y1T8VDH^/A"0>)3E) M.E;2DG#$Y!)TT,D =!*4.C@"*$?I25$B(92>]$(J3\G)5H+AE4X@92E%.4LE MQ#*3HK*$&)/02E^>$IBHC.4OOT!,)N"2"\ALPC _B\,9WAW.9%[]G1>L*3_IWY#*<^'SK/E/:2GA4E*3EO>5"/?G27 MN NH/$G*S)J>%*9!%:@O?^I3E8ZTJ#.-J$F9>M-SYO1=1+5G1>/YTZ$&TZ)( M16I5F\G5CA;45K2M::4F&Y5 MZ%7A:E64-K2N:!V(8 EKA4TBE)6)5>QB&=M8QSX6LI&5[&1C6MA661:S4#AL M9E^U6VI6L?I7"/KEI5KJ.]+:L;K7V#;U"64E T]Q6=;?ZI8F(#4H1TE[4I?ZL[BPA6Y\8;VN:N.*4=R6U[L: B\UM2K5](9RIAH%;#\C M:EYM E>[HG5N1N-+T(*^=JON3:][_PO68?HWNC;5)D2S"E;L%C@@=T0P?Q,* M7_5^U:?=I#"!NVK5" MUOQ5>,(;3.@O\HOBE\=0K?P,;U!?3\ZXL;2DS<5Q5 MKVXTM2S^KI )NUG*'AG)25;RDD]+Y'B$ULF1@G*4&S5E*B<*RF\-EZYS+J4PTI]D=O$6PEB6//]#N?0ML7-E_-RN'I6],7USBNW\WGTZ&K>Y_CTT.Q+=6P5[ MV,$>_C.$^_OF&CN3J/<5]5DWS>GY>AK4#/VTA64]:!.+N+D85355QWOG5B=# MSUX<\()W76%;#WC6MO7GJBTL5E__NA@:%K:S8\UL8^26])TUJM<@:SNC'JYGS*NZY;!K:9Z0]+(3-;WOOF-Y'M?YM^( M#+C ![Y(6C3YFYJ^<,$!Y=II9[H,W7TVP\,2['4)=PLGAO-L 3%QBD?DU:]M MIY:->>Z_XIKDY^;N7]>]\)=RN+K9/?7'M>2M\#Y3HJ'>]5"M'>MK%[O:AJ8Y MR&VN://>6+0K1G:QA9OJ!S<4K\3V_OC0/V'Q*$S:MTE5+;=#O=41+UNVHS6J M;:=.]4U(.ZHB]O:CP3[J60.=VH/V,M3ES&JSI^;@?M8X7>7A96W47;%9S@6_9;\Y"F?^,=7_2Z6O[Q&&+_Y['3>\V,,/1I! M/WK=E-[TK$%]ZE&S>M:;QO6O'TWL9?\9VM>^,[?'?69TOWO+]-[WE %^\"$S M?.(WQOC'7TSRE0^NYK.*^<_GC?11M9]_'_SA%__XR5]^ M\Y\?_>E7__K9WW[WOQ_^\9?__.G/_BU8GP#YU__^^=]___\? -0 >0 O0 M \0 1-0_@$7D $;T $?$ (C4 (GD (KT (;\/ZH[U2B3P/Y@@,[4#M ,%0^ M4 3G@@1+T#P&H0=Z 5;(UA\H =@$ 9;L/7^8 5O$ =I$/;\( 9[T =]0 >Y MB ]N$ E@, >#T/;Z@ 638 5E< F1,/?"X F9< F,D BA, J_X J+< J/ =G M$ LU0S5\\ E7D F,T C#4 RU\ ;!T G(L O5,#)"HPF_\ G:T PWXN&R80_# MH \]BC/@, W?T KCL#U:9XN@YQ"MY0]9AWJ@9T;69V348V^J160,J!&'9L-( MAQZFS5\4;2(VS!+EHU_$YBX"L0[Q\ WK$ B5!1'1YUW )('&_B4];F9Q^F9E MZJ066Z)V'A$1=C$1F8%<]M!FMH1W;$A:!"01BY$3JX8+4M$)MY )X5!9:M%8 M0*>'1B@;=Q%EB$.%=J9F *=[^,=&!LA)/.AI;DB)= 88TV-L**@8?PB(I 2% M:JA&*(ATO+&WCF@>[W%D<$9 FE%[,E$K)@,'#]()JQ /#9%L;K%U0 8B5Z@> MZ26%4 ADZ*,#&TF1?G*H>KB&%+=Q-?D&*U%R&VMS M,GD&..'#2Y)3-ARP H9U"[]\P@I]/>R(!49 M4CU3D4,=U$+KL@F $@U'E$2OX"?Q,@ 0U$55U/E8M!"C8"%EM$/3TP=/5"AC M%$<-8R^H<0GR,$-_-$=9M =;D0F5U$BS\ KF,@G9W1>+Z9>#2,( [ end ---------- X-Sun-Data-Type: gif-file X-Sun-Data-Name: ibis1.gif X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 531 begin 600 ibis1.gif M1TE&.#=A,0(< O0 ,# P/___\S,S&9F9IF9F0 )G,S,R9S&:9F69FF9F9 M9O_,S&:99LS__YEFF9F9S)EF9LS_S/_,____S,S,_\S,F9G,FK_@L'A,+IO/ MZ+1ZS6Z[W_"X/!FHV^_XO'[/[_O_@(&"@X2%AH>(B8J+C(V.BW-LCY.4E9:7 MF)F:FYR=D6N=H:*CI*6FIZB"GVJIK:ZOL+&RIJMI> *WN7>XN[IVO+^^=<## MP@'$Q\;(R\K-O<_!T,72R=3,UL[1VM/;U=W7W]GKGZ^D!M6BS M\O/T]?;S\&=[R'G\QOU^_%$#V$=@-X)\#))#N"^@PX(/$T9L"+&B1(L4+VK, MR%&/0G4,O>4S<_"?R8$G_DNB7*FRY<*4+UG&= D29DV9-VE^W#G18\^00&WR M!#2RS+VC2),J78JH*)D_0S?ZQ#A5:E"<43M>U?E3:%>L7[E2W3JS;$ZS68DZ M%4/VK-NT;>%Z'3O7:EVM=ZOB!4N7KUV_>\5NY+>6+=/#B!,KA@6LXE.4"_IR7CV,PH5-KKLQY,V;6KT5W!KU:MFO2HVFW M=JOG]!?/GDT)>33V^>T'8NA+Z+G^]\O/K[[>77IQ]^O_^]O!C$RWM;['8><@@> M_J@@>^CIU]^#ZSD8H7TV]46@%MAEJ.&&B'W4VX58<,//B/Q-6")^#?XT $% MM%B 0?\9Z*,*";(H(W/\68:B%=PZ*,>!"#@8@$">/CCD9>0: >//0XBD$(2 MUKA@E/\,:>65+E*8XHGY:8EC1$;ZP:05E(U%C)(+G>>TN#9IYY_\KF-GX,"&@B;2XY)Q7HT(2G*E;L(4*>=CE;*2)B) M*BI%=X=:.@JD=A@@Z:0%>&IJ?(4,J.FFJ9Z*RI!%DDJJJ[3JB-.JK"KB#S"[ MEL1K5;V^]"M"P=8TK"]/VC&DJ+)..DZQT (K+;'3_B);+3314JNMM=O&A.E! MN$9A8*M<;DFC<"T2D, =S=99)(12WCBEE_.F$BX4C9[U;:U0L5L @KXV^Z5 M AC +X??#FODO4\ E>S!F QLY1WJQCIQ'0M O.&^V3#LA"7'8GNM-MER:[+( MW8K8A\1#4LR Q2W;T<#(*J=<\\DDT^Q-R2CC?'//.?<+V1\>-Z&Q+++6$7.Z M ^0!ZM%0JU6T$GTA>JZY\*:45=(!+%V P@X??&,66--]MDU0IGO:%,OX1+' M40]"9Y!@*^TBS'<_8/?3 60<]X\\Y]$VU8B@Z6:@B! M+XX**R]TUC&SYHW?V?GA_HHG[KCHGB]>.NGZ=OK(X'14^+<@"JW(]QX.,)!Y MUUB^?I215J/Z#NM'_ 2WI1Q'4 ?8L^N! (NYXYX\QKJ'4BRC- (?_"("_@/Z MZ*%WS_WW\@8@P3$&S#W E0DHT"+E+>(-JM]W;&[' O*W.=#VIWN?/_CX]W__ M_]F!'?6L9P0;X01BR["4,EL MVMO#E8)4AR"!JD4(< $!88E=<4/?GT+0/WT0#]ZA>^#7TH$7#J8*0T&X1'9 M.Q+)41)R3N&B9%V\AH* M(;"'(TJ,C7AXI>:4.4DY>A&$O;RDCLZAR3+5 9>=U",ZI&D2M55R:'R@G^2& M%"2\L5!=+&M>'V8XOCJT4V:2G!\;9TG'LEE2$[TSEB^PZ0-0)LD0."R+D6IH MAP>6<0#F)&.+&-# =!X2$CYS7"4+$R_Q -.8>M26'0EH_HQ$SK!%$*A!56<$GQ<00\)*;WB(HE3':LVV MJ&ZFFVSJ#<[JR98NQH'$O.I6LZI59Q$"F 2K %%K%3)\FBFM:JW!SZ8(/@R& M QMH_>D 4@E!DI*43F)[3[D]M#,"%\YN )*[SCHL5G)U>(! N&I>_=82H/FZ MH$("3(-=DJNS-@RDU]0+@><2J6!>C?"5%) ^&[=(5(]H0'T+Z@ SUJ$"P,@N MW\AJT0Y)A<4S**\V7RP].V#XIY?C&E:%2K <-U(/$YAD'K*K85>V:V5CX^Y! ME JF1$!9!AAMZ\XXD:-!O')97A[C[:Y$6Q)K> \,,M#M^5"2.?H'/>.??Q)+BST-R[VR)0; #$."(!!#Q,56= MX%7'\YVG_H-N:6T'V=:.I7)61*YU#;+4XF:U7]SP'3"\[#O(3L\/M>L=ALS, M02Q68@43= )LYZ+TP8ABZS6QON-<3<+J\G?;9H$CZ@Q$RD@@T*@F=&WQ_>4O M;WF-J=9#.^L;4?D5&=XQLL/%RY@ 31L1TS$>9+\+#AFX!;P%U.XN>:DLB%$_ MW,'(:*>Z%3["5OOASW]N0$GI1F%5VB&ZFF9EDT6;_M'^>MN?+SVY"OXK&VIF MTB8'5[7+1=BL>%MZX32WDFXC6MV]>KVD/%YB2>]P7P& M;Z(EDH5)3WEU"I] M!08L,(K_>X@R;YC3,U]W "9HL3_D7>A[8/"W^.X09 MX>&H$2YN49.1 )BNZLTY70@2IYK,K72@ TY!TB*E$+)@-06XO5OKKIB<]:TO M.IM]S5:!O!/X%B:CL(D8UV3ZZ]YCX5L#L!^ 1X:TC QH!. '(5L!'&#T=Q/ MH$OL;UM'&M(@@7[T)['V_ONW_ ]39S>']U#B4U\.ER_I8G/E9PBP=G/))0%" M)CZ; X$+R'D!0 &O!(&/='V:]R\$P$*9%U"1QVC\5W_1H'\F<$ '-G"(D'"V M%P@+Y6,1-E%RQ6@H]$1L-&3C8WX:EWZ*D(&!(&:V962;-H-%Y4T<]'I2!E@H M:!%UED]E0@P!R&R5-VIY1U3O!'&G)H1X<(!WD%UB-F@[>($5&'@057EW<'Q: M-WP1E#[C=P_]MS]I0G0]A(( 8(+X9VL! @@9A@ GR M0U]\X'+P=VT1=$3VE'+V-W<3H7A,9870'N;5X#N-&1K)#^#MB(* M_M9U%NAL@,"#># S.^B*7I=@&YA9Y%>()=1SE#-M;&)S5UJ#5]@S@< MX'ATX 6,QY51<",05R9N'.B'S49U7#5UID9&$K57[K=&SBAH"M9*K"B+L)2- ML31Q0<@'ZP>/I.)^=+9R0;%XY *,(D""Z1B.B.!RJ+:.($B _RAQFY-YWK=W MH[*/7TB%-0@(;Y21K;A*\?..S39_!CDI0,:%"@E(U'96J-4Y8N*0-H-ZO&@1 MT^B.?H"!0$5#ADAU/Q5%+A@S'%9Q+"1?G\>1?\"2_JDX?QHVA9I8C0"(9LX(1V*6>3"YC^^4EF6$ .\T>!#D>:D(3RZH M3&UYDIR#E_5X!WV69F3(B=TFD8-)#5^98DAG>H8P:N]DD2;9@9E7D!*7C'RP M.1&U6(3(!Z^TC>BV1MBG3/75DRM)DGW 0%H&E3L)D=9DB73HE3C)?"6HC/_' MAZGX/$,6@1V)1OD5DA%' '&5CQF)/&F6CUQHF:L&DQHF9F\XBP$ ?[Y'B8J) M$JRIF)ARF+&GB=XSEE8FDN/F!RXW0^2D@&#V9W]H-U:GCV-&E#(3;8:64T22 M?'X BX6H3&[4D=/HE T'_IAR!VDC!YVZ(FG6V8N.T)/MR)N:284.A(-7:: 1 MUSX9QVP1]4K@:806N)&U56';F8K9)95[A9IAUEJ*!$?YV4AO>([[I9KV5Y,! M.DVAU4$*D5Q4.6X%O=-V0,::*+-@@KN@D7]0228BH M"5=!:@C0)@AV9VB#QYZ9&4%U,Y/4AQ%<*:6.4*6%%9UP$Z.$P&[^X@>@F9)Z MAT@\]H'<&4-=^E,3QU7/>9QUF5GL27&$JI>W^&6F:81]9Y=MQA' ]9\R245' M_F>=O$85+CJ96]JF6QI/EJI(,C.&@$*<0 L%J7$[I"HJB?04F7ODJ% MJHJ,$XB>V/A.QC1&LI4'$P2-3^>+,9F3U_2:SHH2?GISQ*J/HLF2DT27F76, MMJB&9NFE9)1(!1JI1=H'&YJD=G*/_])]$11ZTWH2">,)TAHO/H.EW@E+6AH_ M[5@_HKE.9XI9E5J&R:IJRO2H3,.JA?5SI8[E&O3BAECIFA_B9)E5/7;H/V2O SA<;9 MJM;(-ZB(L274-&6*.\>J!Y*)0HCJ?H=(A48V0Z\DF4%KLDN)J#Z[0D][G:C0 M77]$6N98F,V*KPRJM09[K@N:D5P'F11Z=>A:A&:8AKEG)\H$?H&:J)&*JA&E MAA D4@T6GS+ZK,"Q@DJX,*_9GVUE$"([LCY9F;R)HZ0):%\W,8-6/TXILI)KFJ,/^HZ[*@RH MN:QD9':-6[N/FYY<"%T(]9%D5+&!5Y'DF,%UZG_:X+&G@+]\FP>HB9L@BJJQ M>)4/*S;K*XA>YX)=ZQ%+FJ:NVJTZAE]".'\XVZ0R/++RX[\AO(DTXKGW.K\8 M91 4B:J!]H#)VYTF[+AKNZ.':XLEN;=6 !!6R@ M'F?(W+S->->NXHNQ\^>,M=.DC9249/E='%R3:CR"Y$#$_#:ZM.G#&5JN[VAY M [N7\U5YN*G)13B*MK4\!1G&+<*4[Z*< 7 ,R"$^%NTR@=*'NQ6L_K#C'#+"2<_0/E3E!K*E4>IUSI7#)R-^6EHBS0J M9O32"ZJD$MV^,6.*N&Q&!%"U*R1T:P2N>C!X*61U_I(KKLS:FHUR401&I4B+ M"5,WQWEPTEI,H)L3$CEQ"]S=5,)!GGE IV4DM41$IF MA&M4L'E@ 0)0.YH&?P8*0U39=)&V1<_WQJ\7K$P,P",;M<@$FE7;TKEIF7^& MFK[;GH-;2.@UN9.,!S@[PW>6Q<,TPQ;:#P(@7]<;R+9E-P85,U,IAX(,"0Q[^%[(#G')I(/O4@*/=\RN$8' M8 %I%'J95]-Z=9634MI"%<:4*=-D!$SIW,.B3%-#X]W^>8F S7CEZLNQ+9+H M;(&?G+\/;KGK5N$=%G'^RJ-%PI08*C$-1B?GM@\"P-/A2X%K5#&\,(!>DP=) M?0>9:M9SM4P&O(A O,8:3#11W0<6Z;])/-BS:=[8>)MC7'Z.O*"G;+JBBVIS MY'*3-\L2E-8#\$,N4G0><27;,L]^[:[6;O'QGKD^[ M_EB'36BTC8#:^QH(+JCGNFVI)>JGD02$H\0U7ZS4AGS /[J^FTT(=L4W7I,^ MWGK,J=W&61D1#+ZWHIEP]"S2A5BBG"/8[XA=B6V+&4C*7&WD1+7+P81UKVO( M(BK@%1S1RZWM#U[KPSGM+.Z%]56FH4NWHO#KJRJ;;_[CZ9X'C@F5KS2H&#[C MSBX(4[S5[#L^<]-04:Z?H3;K$S<^#1C-$9:^'A8D[@H5I,30!$[!,2.9CKUF M!,'.:3YI-[GC-;ZJ?AJZTPA'+$GN=RZIR532@GQS+-F3=,)C0T+H_BZP5:SM M%N>#+^Z1*[0YQV;!?T!;$MVD"APSJJZ(4\F"V#F,_J[YQB^JR2 LNBYWRO5% MZO)>ZK2[LY;YQ'?@-RQ-=7C3[S!+, O=ZN*;>41-VNZJ; 7 E/HN5 K<>S6, M7G\P]1CKU_[5;VG!X/N:]/=LK7ME>64F9D,JDB2?SGZ?VU2/SU=;.4,2N^R5 MN CYS^CV]4*E3'*][9&2@#1Q]DJD!D_L/25EU8;Y+G96W"4].HEZ7P3RZ)2 ML 5[@# [/LL*JVG?G)#,_GL11816]\)@KEX@]Z>@=3,_1['OT@ M$(@C&43C68I3,TY!JP923+YT\(I2J1O"2X.!Y&B!E&I%.A5_/W(7Y\(0*'A(6*B MXB)CH^,C9*3D)&7BX,Y/2I!FWB7FIU#/2*?H:*A,#.F,J0I130"%CZH+7LYJ MT"P#097 ::NE968&0P)<('9%Y%3 H$9 8*:@(!#= #S+C*06E$PT.NI9Y^@ M>+F?2F6Z^CI[N_MC2:>FRCR)1#T]2BMJ"3BKBK].+>RLV$'0Q"T5+_P5E.&# M_N&=$;6*[<,4;)H**L$V.D&#(!LK.M."H>%H\HP"-=Y$4)#V@([**[=XO&CY M#PDYM)Q M TD#@A>EE#AVL@H!)B#CR#0@@&2VLU:8Q(0YPLE(F76U*9'Z+P!/$8&3_"$G MR'"0PTF&,F[LV#&N$IQ0S"HW+ZO#5V$C2A97N:BG5Z1HP@K=IXH#!G;ELFZ] M$1K'O'+1D.BR9:5&B7T89AW\P[6$6G&99-2(W*A(6T$,EC+@4X3I=\Z/ HYY%"2 MJ8+99\)%]LD-WQ7Q4#\$?D9*!*I4J)N 4T%H2QX332B#62FJ$*9Y[*4(!P(I M!2#?BP4HX)%9.($-IMA.^2E!)*"!KO,C$=?UF)"A$^K@80[B M-2E#=D6D$DY#NVU9G1WT/;=2,E"@:"(=>/FBHFQGI'&77H"AN%<4:N"H0C-V M53HK*U7^R).212B9DZ"]_OH*CQ&FG)!'HL+N)E4+GVW5BH4_0C5$EIRYLF.T MVUQ%*:JRJNB$F:#*Q.T?3ASP:9W6Q$2"F7N-JX:=8\K(TI*EZ7$/";GJZBQ@ M0?RZ+[^&X"M.L3B PB.$^.BH#VGZE&-'AD[QPT.#$'DG@Z8_\/* &"R>!)NW M)I7J1&HF6BQ,/P(Y++&/_^:['R']NMRK#/0JIP>2/%X[LX!7)B%P7^8T0-]F MU'%UISU^.9S=4I[PPE-':IZ47L>>YD!VG!!EM!SY)!G()8D#6V\?+ M90,JV"4(_B.S$O:9(]TK/M@J1%+\#+RS@Z88'55%?"L\L5\BN46.2 +8%C7B M_B8V@U$ L8HY='=7;0F(RHFA8S;F_W6VC]I]+(=DA0RA;,Z55 K8B81M;\[S MI'HTJT+%-42:K385C#OJN8 =0&;BO6_,@ 8K[D6<\NN @XXQ/[MB;V6XZ=O MYM$?%^\F?12*591/0;OHZ?O(PJ@X$%7,?8_(8J()^*-?15!>(DQM)XOBB.@[ M_7 D/R_7,3,OMO,]2?__8PYE,YH1K8 _L%+/_)&Z03Q**P[;F0)1EK #%>_Q#U0= ^DWMA2N#^T.0N +BP2= AF0)Q1\$G1 M"@^6E$"AYZCO?BO@6; <(D33Y/ 2VN)8!R%PN)/D_LEPZAFAQX0W1 Q:I4%' MP5=.'88A(J=45%)@%(.(48M%\SB2I-* MUIQ2)8(!R A&'T1 G#QA@ ,HH(]0M +C-'2*Z.@/>Y6KG!V"-.P> M"5(PC_S9C8S6>B,C#Q4QO3E(?6QK9+ .-C'F(% A/#C#44 1M3 ML1 ,E85X;.G#U&C9/-IYJUT4$9BC+M0G/>Q*A5GTQ##C&8DDU*-8!+J;Y#YY ML\EE4I\]29VF@*@E@,CM_H1U"((VFWFMCIR*&"/@HQ%!U:I!H 605INBM)ZE M&[!0CH6/["47Y2E21<1P>9^8C+.01ZO99123J_P&'5V'T2!2\Z#3%(-[7@&' M-ABS4^;I142=P$>1^9-6^+2@L\:IPL6,M*F(^-LI]5/'DN4-GT*KX=Y8(:$C MU,<4$F,(,P4XE>U$LZI) -]>2-)0$FA*+*P9F5")Q\9MO:8+AJ1#95IW";>9 MU)?K?!Y(+^?4P1;P>ISK&V94Z94?QNV3"I1.]KQJ5&X>%13*_"'?NH1!:!D$ MCT@M2![D8L[(WG)&>82114M)3BLHX(],/"=GK:50.8)&FL%A60 &JUM/\/,[ M_KQLU&Z"^\:75FM6.@-N$6LP5QADU:9?ZNUK22L1'OB1(] XC4F4* +'<61A M^HSF[.!X+\#V;[R!#:EN1;JYZNE/09A0Y26FHYN 1E8T&Z+M(LNH68-.]DMB MQ:="<\372T:7H@40H:FPRQ$<(;A&?IM745%(WK^6(U?I=6H14-K/O9ZUF&:] MY&>+BH305?9A_(WC/4?1L#D^27W=O0-7([0*N22R%<6:7VMJ+%QXZ9!)1QJ$ M4O5SX:9:MK@7O*HCN8)'SU+Q4/1M:45LF1"]#NVR$]1.B5'A-B9;SZ=Z# *- MR=*3!GO, +VU;7QM?*L)3Y@X0U:O<^S9G0OYA2#[_HVP;(M80!)'SB]+(,E!FN!=-Y[ MNURBN9AHZ$4X*SW<*F)+*E+Q&JG]%.0_F3J>>/+O554QNRM7)'6D.-AO.QP* M\M7-;B$.\#;0+8I0?[BT[Z7K7JX[T\A8LU.4UI9,BWTHU'UTA8*MMB3QAL]' M;Q2A_FVDT9X,8,@^2-P%_P%+$:K.2LW"OBU5=T)"J^S6[!'TC,]I2_Y0J%KY*(;T.\>V(CW[LDH[]V&]>VO1JL,8OBF]0E( M_+(]G$YXS&99!#@V?1FRI#5)01 3S5VYU_-4!,8W/E[RV!%:66_N:^*WUSHG M[N2GZ]QE[U>@BO3J0=1^\.C4X"0*>"+J)^O>I$4$T'-%\&B)5NZY0_AT<6==Z6T1BHEGA)PC*1- M6P^4U38=5VW94CM%6ZFIWPNM38IA4PG,5?[QUL$-G\C=P=M]E]1YAQ5E5=#= M5.I8GI'AV5_XW5LQ4$^=H%F%!2D@C3&H1WI8 .[X ]OES?CA5T,H"P'VCP1. M(#V]36'!6+,90?2EG3\-6I=Y6(C9QQ#HS*"97C4W;*EV0IL MSPBT53E\&^RDGI$A()^4P!"Z4&T]B YNF-C12F6T1+@1EPW@G#AL'NVIX-#I MAX[?W:$==EY/F=)48-R.F$_>&!TMZ,8CRJ'6 M]1LX)!N=.)@1=D?FW1<)1$IOR1K%%,.S-$DFF$.A-<1KJ!TH1*29>#ZD"(H:,H';0$MR@$X*!P[ZAG=T%ST[1#$X)#6 M&<\".:2^U8%T\-L5 =8:+MX[8D[Y>=+$T8KQ\=@%R:+0E4^U\%^6Q5]7.%PH M]5E&C@#':%"!R=TI$(2A_F%)*YU\PW- B2/=0@7=^Q)WB M#/#F5D:<#HDF2/%):9;-#B031ZMT-H*WD$\Z:;7XEM?P<3#CFUW_> MATK^H_S=0@.%I4L2%)B9EF"0B^UQ!2AV&M'(UR >SS]Q!DSNXQBNFLV-HRBP ME'/B'O3@)[\X!_\)I%4(YU1V8&VD(F>J#T@" S* W<8YV_JQ,Q]R1V&'%() M75GUEJ[UEABUG03H':=T5CRX64=Q"94 M5H5W"ASH51"M#=V(1B"?]BEJ7E[/!)%40B,5":?J!0VE9"ESH5DT7>1??)6U M8*'G>=F99DUX'MR1CH)\A1JMRI\T1J@%$A<+Y%4.X4.3L,]YR<"H_LK=2$RR M.L5^L>CJ76/Y&=RCC-B1\F$)T*"I)J&7%I[/P)6#TI4RY%GHD9_1*:@#'6NN MTMZG&B@9X2)5_HLE1BNIQ@.N)J9_J>A%SIXXIEQM08A]5J L[B<*;>EH4 C$ M@L)$\%&IG%ZGQ(]F3% G?%J MIN:#LVO]EKRX1<M1%2D 0B&GMILT_AT>HK:G"'3!U"P=''00"#E+'2EBW\"JR0YFOG4> MK"YL0&"'.UT"R[:L/WW:B2UL^ K:9&"H5'=;&V#=V[JO"KJ=F)KO=*DNM:B M%>"(+8('SK:;5 Q>9@XKHU(11QH?UB+7,W9FITKMU)Y-1.RHC=KMVYJ0O%(* MUK;J_ UKWAP,1 C$9;$47_UI9P5C@X:*%=B)K#!@2=H'XT*9LR&>3L2?:@Y? M)XCK%P(3J;G9WPZ)?@IB9LA=MY;A\(6@<3UEW1S$)_IAL_X-03!GE,C1-LD1 M*:S$KNH%Z^ I8O; ?60'":Y >*4EC98NE/U#8P5?]L"ID+6NZY[CV[*"_WW8 M_D38 ?DBZF::D5MR*N3R(B>*Y1Y2BO$JFRV6PH+.UV+^!<+6KG,1+&$^B;(" M*DJRW-=QKY#LY8HB:Y.FD8H-C--I;[S4F=V]K2H(95\)G?""[?$M6DQ @Q*5 MRM&*$OF\3J5";57^(HLBG0A3+T483O!:@P> M"F9*"^G=WE%^%)B.A],(6S4HP - Z*U^V$RV95X6%748;M8^T'W S:GB5NZQ MH0QKSOL1ZQ]N*2FUV(DI%ULML;G)6@8JX!W,%<.U\,O0L9J&'O)+ M35LB*W(!I<)R#+%8#9C$ $TX<,?'TO#]HF$1"0RMNLT"B7"P!>VWC$&) )6% MKN8"@R4_-%?H;3"N@# ME>\ZKQ(\SUM6)D%YT,DQC+*1Z@&%9+*K"J2Q58P R#E(I4CCVM0^F3JD15_G9G[7=GQ:HQZAJ\EW? T9YPP_W+Y M_6I\J=.@S6H1B2N355)=_C*T<10S1-_NG@7$ N%!0QZNQT:E#=7"<9'T^_;C MM5B>9N'H\:9)(99Q(>-?$S89V?X7Y(F8OAV!Z'#;,)-6.(NJ34/&'*EJ";]E M"JI1+A83SZY;I=Y9AGB(0"H3-1)D0ASO%##:X[ O'LY9K,X;-&4S+5P6%4YJ MWRAG\4SS3+9K_W)"/81U<6#(E,#PQ'#'U/&E!QK4;^V-E_1NC)JNI9[E,J<* M'(0)]*;F)P4R!?F#IHQ/%U*P">[(!$5Z/2I 2HH'ZE M_M E"A'8MEC?J8&"0\2I=AG1ZO *LO52"@7;Z240M;4\(BLFZN7FM;LE&8*B M*7A2:[H5 3F"<9,.[B#4(W!=Y$N'YB<.#ZV=YPFI3% M " W1T'A31<2^8"7PX[#4+@.73-%DR.2'5W.BM4J=6C4F^C)H/OI#.HHCWZ[ M&LB8"QU57Z5]LREF9G^ZY[2AX(?_H;9*%KW]\M.._F^98^*7 T7:D%]T\*_2 MVB9J3]Y$"*HSC9MW@*MVD_ W&.U:0VJ"V;.D-B(155WC&JQ&&K)1R1QFOV<. MJ=X"[XUPY,&B!X4^:?HS[:P*2"XO,6LG'34S&FUE#+0R6U#S 9Z3#$TSO$F= M'AH=(/@0 ;=A#R;(73%/8EPE];.KSN?GIF144+JN75\7P%0WM:UX\K-E&_"1?R$^WREO-VKG#[ @Z>J1YT8Q "M0ZNF[-[N[JO M/B_IH,+K5'3%/Z,_B0?#_K^#]Y:1#M;SM1AJ&#-;5>1?'LBMEG@R5'M"4<9[ MA_\B.!1J]LP>GLO*C^M!Q425:;L2N]'LI=\\D8XPLZ4PC'6ER_0]@+*>N;%_02JAL4/.(L":=TP^E)/8\ MP$^'SK8:Q.N#[4'C!#?7)M5XFS+C)?>6<*3XVS$3A(!JE*_-Y5KFD)BS^)!$\Q4=VVAN%)#M%E2_2[5U' M,O-[]M@\F8*OB@O?E=%$$G\\W4%YK0*U'3Q !6BP/6:WGH4EIOM:0@-V?"-! M_E; _J!X!TO!]PQDA9PZ+1]W:/3HH3_[ ;DX MM:000FL7$T:&H]]M98 MW=>H !@(2.7EA].DE1<@R!@XQH+'I?CBDKAE=^,R$1FP0)?7U65IF+7)E!BI MI+K*VNKZ2G1V.,G)]%4[VB=[:^.9.RGB>X-5J[O[-04)3,8,C-A+' MSKU\^R:YMJ;/T9Y/-OZ%NW_F)N^F&CV&&B7.T;PA9MQQN(DAW!E$V067??C0*IB))=>&P% X%L MY)='8++45R59OQ7):*-#Z*F9H9H116-D,\8$G4^)2$$""B[)5>%S.H9J Y1C M_GCV8#9MTDFGB1"4QVJLCPCZ7FSA24*7,7V(D@88M YZF"6.#DOL#H0Q)*EH M>(Q6V(K#(#HEJ1!2NJD<%"W'&*Y446E-@CK:%(XP'#:"9JS9'/!AFN:VJ&&7 M6'"#')^]-N4C.UHXQ,\:[B3;7%>8=5%LP(T6!^EV0>YV [8-;3L)@P=5&M4U MEMEX4B3&-$*> ["NRW$!Y.D)9*D^.?1NIA".ZIM^>9D2+#Y#D7R2P#(/6544 M(YAZ)84%>X&7IYAQ&Q,Q:@ 6%,45QK"**B@NDK.M1N47?9FOLUWZ[268(S M==UF*\;2H@JULEAS;1>H+OP03EL-"40=*]6PWZYGO6+JK/3=7)M@#*)7HYW# MYL;S=+?H2=TF&S-U7XCAZ _[73!%-+6K@K_XH232:1WCGK 8$XV_2" .,+ N M=RPH/"IMT$/_]:T66Q%E57+".N04J<=2CBT!V_G3A8:2V*>3F(6#2I *UDK&!6_P)03FLHV]X'; M'L](NCV*@(R45 +VDE<]1EK'(/W0I-^8UQW8"8J'#ZP#G6#TH1 Y C\LD%H! MWN$$<6$P M?3SB>Q2!^&I8ARDO!1T-!FD$H*TPC3NQ OM\,C2%ZB;DOYG\[> M44CES.M/WCJ#,B$#%::HT8G0@-&9HO8%5](H"A,,(?CB1(UP&,2!_6CGI)8A M_ATH30:3DQRF/8,0*0%QY$;U,Z(RA\<5F<3Q5$8+*.82XQ%(PNTRM>3G"- % M'M6L,@41/0N-N&23V#LI#7V0Y:""?<@JG5!4L2ECH#0Z"I>V89=C MSLBFAS(B?_HU3N>P=*LZF ]+\. Z#'II!+24PX3 DLA0[5&2[>(36R_[!'/ M&HZ='W-(:HFXBH 56.17<5#5<19"D=J)80-M]C,_DL]Q$?:I,X>9A,?==83 ML?C&=6749'>3IYUF^/P+7$OT1KS1,.H M=7WE")0X!@%$ Z8!N$ J+=.(5[W@=TN#F6 +! QQG9$E 6G?WLQZUS;2=J4> MU6=L#Z$]AJ'0EF_;Q6NEQT-+*&R&UJ-7,$[JI,-,P$/2M2YU/>O@]OQQ#-,= M 4D(P #,- )$>I(B2OM&7(!JJTH3M%OC@*)?M&ET!/.M[8@5\53+UG>RQL5F MB2V&2"LLL$88;"_LS),"$QVR?&V2:)GR-%=!"+E#[JFB#3P$(C:M*7 =4H^( M\2B_.W84Q3L2+/N*\]^[_LC3;RVV)S((6+#^,2YL6,QKUO:#I+RL=1L##A60 MKZO=B;(( 8,<5X=<$P '1(W!'7K =(A"DO-Q-LIILI.B$,6RA=(J?C@N9NIP MPZ<://70BBCS,!][4H=%AE#HA&,O\VG0:0IWBT]ZV1P"M6F&K<%#"4!? 49T MB5/2\WT/J,!7RM3DOZ7@ 3$BR7JZN5_JL5$24 KNJ=NWJPTQA*.%FY&GA=FP MYKW78/W3TP>[[3*$'896E::139L-A1)<.$T@^@B[WL()0C?X16>V;WL$8 $S MN4?78]AT&HGW5:&.&0?XVMK./&DZZ5R[DDBKCZ6\G#Z@BDB+E]!R M_EFR!Y;;62A2:U>NBSP5;@T#$O "! Q@$FFI4[ SR @DBKS"RC/Q'-U&*5J1 M4C3-LA3.]FH?E2Z44@Z)G'B@&J#+( '-!G01L' M!?(.!+UG3-4-TTYJ4"$I272!4844MFU! M5<15L#QCP<8=,8>=>PNU#:RF.!!GI/V?QOM+-#3[0WJA#\!364" L8]\ !Y* MB^'!0Z?9,8=.1(WP>,'2=9K[61 $.$V? 4%U(.N*_K(ULZUGV%Z5L;;^Q=[A M?F:@9/K3@YXB/K8[]ZX$P^($KXL1BYP9FL8J[.( RJIL?AZ>Z*(\*]$L)(=- M7&G^)XCW;M[C=2\'80((5$H1'P>"%+=%4M,7%KEE51)(,.''0G2 +3IW4E0U M4ZA%/(:!3NYU,K'R=?/W38"@,?=G7=E0?/1F%M'G?ZSR&H7$3;JV04<63JMT M9V6E#PM%8\;T0'*$)1'T9I,%5BQF@?EC4>VS=&=TC44H1)Y>#QD=0.Q MQC)A=7,4EQGJE'3O T(UX!"V2!EQI8;0,#@:D@V$)H#XAXP%>(S(]AK#^&3[ MMHEG%@Z"('Q>V!.0$TM/AQRF(X2P)2$_%12G6%RW$ ZNJ(?" VV .,"'EQ 6'V M9XU/V&7+-!@F\ROO8F)$U F6EF#5A(?F2#9U9UOO-(X_](-BXY&%,P&J0GFH M_I20-[!D,T!EC$2DEAAJM*%"BDM@!"&$39D"5@P)N,PNV.4 MX )-3\>1FE-S-Q0[MN1 \X0VS)-WSJ)T6@@(!AD Q1>4SUAALQ,K7 D-^(@Q M&18 -YB/G15(0)F/D%A[A %]JI23JW1[B2)CR0:$N]8\XBB5ND@]1C-02UDV M\1%K8^5%?153V!2."LAFEZ$24Y!6GV%\@9:2 2!>P)"0+L=\8&AK.'.V>$L\=%V28L@CDSL&@W/K)##7AW MJ>@,)?9VH9$R%R(=]CB96LEAF!F- BB6:V)78OF9_BV8)S^9>#BI9[8G"W/) MG9.9*ZOI-C3D'3Z(CI:1BT@Q3[ E=[@I,TLHG'[9=_X%/GTY0Z!X&4-FG[V0 M F 9<\_W;L#&?PD H%>89VN)@E1G:SY9F68!(EG963()F@:@? ZJF@ZY#5V8#7.U#)_IDP*:?XSF MIM9%-4>J@A?D36R2@]6E_H_@!FH]$E5:DS5 9PD*PBUL^&&W>:7$XJ2DTIM4 MH';=$'%Z4TX6 F1:D@(SRF?+R%EN,Z<$V BM 36@*G6;-6@&6%V?M94"P) 2 M55U*JB.9=G.)4JA\-25O!&US R\]=0.+6BRZN2 8Y&%[")QV%ZC/0)H,@"[A ML:-31P"XTW6Y]R;@T29 JJ!1AVQ4])G-JHR=D%EZQAXJ\DLZE@5?IC)7=I>H MJ">^RJC7("7-XF'U06YQH NIE57;D@UL0F_KT*.QPI!2:@-B235X4J#1>!I4 M!YT%@+"7^(]L.7/]&@B,&'D5B@YQ1IY"M1)3B'IWJ)BCHA&=A(3L.C!0)90_ M_D=P9)%@ZLB8"A06! *A=3)AD_"RA[36= Y)=2H5(,@FASHV"DH EH>[BU234C M JDG&L29=**5BJB/N.:S=G6&.MJU5,"+F/ \O06EI9@I?)-VUW6AN_@%3CNR M8/.>)8E:&FH-PYJB6,DJ:CLCW/J9(R*V& 0,LV.S>,8F&C.Y#X9*\D>A6LJ M4J&!574D2?DI5G(U?LLHP.HU3L 43(%N07&$4/&8MOF;&A(&-B6;:]LB/1NV M!3NG"KJLKP>YEX!A$ON,(T(UE\LB088G25J9"(0/_OE5.HWJE[<;9\6I6.MI MNC1C51Y48R))M#C I?[0FIV[#-;Y;IPPFF_Z!?37N^TK=5H9O*0!B"/92;A@ MM4_JCJKE58>1O43R"9\;-V_'L1?KO/$; )38F5]@OIMJ@E_KO@^<#:6Y= 9\ M,A<+)B$UO5AC'U7P;26Z+09R$_T+(.TB27[Z7/'('$/.'JHI0PS6\ONG2,6P:6K-X)4/1.HF2(:3%"=D!@A*GB^/*&^DY M"2(\PL7J1ABE4 1B=M$1>R FA,_5+-[[O7>:IC6IB:YDO!!0;(PH ,06L]?5 MQI-@(B:2%G+\QO>&P/[:_EF[\1BZ*I09&;\LZFSOM'WP60*Q)L7_ 7?:\2LP MA,(J2Q5'85+H&9\8(D36P+B2Q[#,%V5O,K,03+-)"<>II*?:R)=KAXC!<[7; MYH-Q)C+-P:$-8B&'[!\01X4A=,&I0ZQQ&%-2BL&* +'D4K;]>;QR[,">O)([ MDVAHLG(J'*FX(,38\7Y4*GL3*$)V8ZZ8),MF

1A:F61GI[$B<^9 ;#FK%J M4*\\9P;KDQ?56JTG4:?&[,FUEJ,:\RIYK,-F0A(/\#1P"GF11;Z)23I+.%E4 M2Q H "4MW+39W!=!B P/YQQ2N5A&FUSNV<4578B(>,8,O Q]!,\03 T&0#D M_O$JSH@6!E !,<(F_+F2$*UYT+N 5#BF#Q>WP/,S M&NDZZB"$(8S3"\UQXI&-C!52W"ML=Z0I: 0O T*5O0%--@VYR;QH"J!HSER^(])\!* :RQ"I%81*7O4E:,;K6FAY6>7>G-:8YW3-T#.Q;0.M0I? M8*$@RP:?K,QF [33%&(1L0MZ2&W:IEV*Q\$-4OBAG@N%\-+-W+@"0:4+DDW6 M$0T1K0>B=(T[3OALD1#:ED-P>Q2O^%6;D;H,O'W:_E,U3K6P#@7G?;C4O:(4 MLK:-/)R60%22NI95#HNUU;5;SA9J7)B2E^R5KM<+0JMI,D-]!WO%@^X!1TV0 M?LL-6F/ZQ1])PJO6)X6P:>=IE700E?]CW7M!HME7U/B;?:ULT;3!3+<"HAZ, M9?.$V'-PN'\#FZ<]X:9-$WR2##X=23G#7$[6&)%Q GDW-]A',>4XX-?-5I($ ML"HLCN1*(80K@GQ#C@,$=,C]'IRQ!'8EK@6 $^ MXZ%#;CU4RB,YJR2)/RN>$Y=1!YA2#A/17&=PT#1FJ +=2.$CURVCC>M8(5+( MQ78#L.^CW%:S;>D*LC3(_@?@X-R(';@C?A!.*$#2HA$);>7R$*R*8>.2S$@G MRHD&EN.HHQC2P7:C]+P#7'3N0SE'H>.0>>8/D<2!V$9:?,H G92B5M!TA#A2 M%>,1$>@XP;%#GCLEN1;Y&[6Q,0KL#4&7$-Q/JGTSC1C=/8@K2IN2-8M(3 ZR MN32OY\0)$" M^SFM#F]<5N)DNAAGI=_K?M4>F5#:03E\[NPD*Q]U4U" 4L)X4.WT4!#Q!1]] M&4H 5L#M)QU#\^Z"A>+ -:N$JFK^()PB5I3F)@)L$TW:AI1M'8K@^^N->4EI M_D,EK?=PYL2--[WOL,!0WAY:ZT#C.%)B%AO=[J/@7=&!]" MDGI)CM1/7X[+*CH#OOW?F4Y6D]K5Z=3V6W^(+R7C0ZBNDXQJ4_ZG]L$01/PS M&J%;C?I6>[7H,]):Q9X4=F_RP>M8LM6A)D9"&CJ1^HW"[]+U'GL6&KKDU7$V M@;PXLR*_!.'S88PP@>+MX@V<-!#FA9\B7P/P>0#=_J!O#QC?\2_F.!I,]I"; M6O--&1)>N!Q/IH8"_'E1_##MW/*3&QI[S1N!Z%2<"YR=5IDNZB9Z-M@_!LCO M"N*I L@BIKV4BZ-7KR;S/%]U.%(B0T_LZ;4" H$H-N,TBI)9HJT[LF<;CY*< MDH$:L#FLOWQ!T0VU,Q9K0QQ3N!S2=#WEB.(ZSI;)(+89V+IN@#&Y;#ZCT^HU MN^U^P^/R]M%;. M'./RWJ(NUF5MR1Q).^?)_H :8MXAURYM'VK"2N8ICI^'G4;MF"17I@H)NXCTON&RY$%#.() B MTZ9!4[I55"QWHHT_%'6X;AV M,]D2%0<1%R:<7QK&8^LIC NN0%%H9'FQ9]IZ2P\C3BS'HE:Z? I_Z8(IFSF7 M/T)I:6I/X4^B41:!9 6MBLU3)YCU9%FHR\ZHQ@2?,[0CHCA+(BM3EGLIU\J3 M_BYV=FIV^I_BXL:/O]Z+=BWLV(WY&OI/;EIJEA";YXN4DCU6UP\+"#U;$ M5F&C=A4>EZ/4C;JO1VU8/5$ZS'39RWYR?#]_IK;:049-3GWUA4AA("TDT8 I M0'8./+6<]X@5V8&GD'MW<-=6 ';!!)=[K?VQT55#A>A#(S5L(9DA))+3#DUW MK35%?S/26!!0N5W6U#97\2 3;(\U)Q@F,7780H;NJ()2:;U=^%H8GPSWHV_. MV4?$/$0\0E9S>7D8"T@L.DA@9CXM&4DK2099QU$ULMGF&Z"!H^5)>N1F!X^E ML6#;E.R!68=T[J6U"5[OB5EHB>NQ!*!DS#F!D'4'_KIFG8A\L<.++@(.P:%# M6;86V#EN@AHJ'<_9D0]\A@Z8IS7@%)'>7Y*^15H*I:*S312\N'H1B'O^.0)P M%?7H2EQTUC,;=+>L9F%E3>P8I)+*.A=I5*)2&^J"?^%X;7*42BJ$L47=-\EM MTB+Z0FN8I>9$6,&1@"LW@ );FVY;5!5K"X-<*BY8LYCZGC_6C!N$*HY6V,QD MB4S!$!/5,LQF;+'ZTVI+92F,F4>G+HA(:I2==]8]SR[K#FK0;5SEMOCE$>,( MFD9;<+D4-?'(KBU[TV1<9ZZ<\YXBS-Q"PS_WQRRY?+U$0;+ ;H4>D[')]T0/ M]G&R5YCA=!DGEB>9#-6Q_I'QQAA&6TDCGLZ!:L+,=Y8]>NK3)FHS6C(; 1VW M<:B4]/4W)F>+LCE^S"?%<^/$,XJ.-2E(^'9+'+G(OVFRV'',*==L]M!N)?&K MTU$&Y2X.!/?\9,*CB2&WZ(>%#&U":U_S5]18[VGO?Z\/QBXJ)C'HM22%3+A' M+5DA2W,N)FTS79I=;SA.TN\97;AHIK]EMT$<>KO56 MLY+*3F^D]1E<3ZM]]L6H9TNR[C?O?V32T/B.S2+1P4; M7()=EXARO0,*)%J.8-XL),:8P@#09G?J5GZLH37S?8-0((/6E1@SG"0(3WA- M_L%4Z2IXH2-HJG.),MFWP(2_,:DO;9- ( UMM!['48A0!EO@,V1PI!C:*3H8 MB6"3 O:N8#F#&9V!F6YHXQ2G'0IM9LG!\9CFMLU<\',[$X63).$Z&)' %&GA MS@894\,S_F(&!$M0 1FHPSV142_EHYK.RL8%5?'P/*^ 4LWFA;I711$N69(= M(&/Q'HGU:C!5.QP=2<##]5$08VGY%@GE)Q@T8C(.7>03H50EJ?>1Y&);"B#[ M6@;!2+9'6)!,(8WS7 MV*H>.%%!()09J4H)YDY$DI+/4(K2S?Q'<"*BIIV PSNQTV8.=I"0_E#G2^TR&!VJVT:I7W:(N [E/AF:/ M5Y4Y45HIN!KTE;24NNL:_HD6]2*2DL-3@A*/@,X&2G=U#IH9ON6U7E+%S+6,7DO<#0\:JSW..]BJ# M6@&*-K5%X/H2M0\EJV2UV:QUU*Q5D$*:)P4X01^Q4D\6^9S47.#=>B;D17U4 M7TB))P)/P6=F9\LK2YM1EN>AH#5BT^UB^??%;KR"2W:MR D2IUQK#A4*1_ 4 M $=KNSXE:'47Y8U%Q;&- Q?SH\#$;4X"9@<#H=:V.K3I3N=[O\N]K)G>Z*^) M_@)*8=+>E"6Q9*=3U/>T7-WNN.PL#Q3KZF*3XCB3?60E>)>4-PF8"9V4<-FP M'@B?X+SE&'PKK5PP6P\0!7&(J^IR(O=U,J%DMTCJ?$\,>SA/ZE('7,/[7R35 M)X,PB_D/ZW#NF,VS6@CW&+'1])C '$R(.=L./M+=97W]M292X4F2CIPMX!!,[[AW: UNT=I!K-,X/#%5RIEG=Z%PL M-PK1K9XO-,68ZMP:\B8V>HSKDWV1Z$UTW&Y!5MMLK"8IJV8SSG%OOO<@F+!)([II?#XUW ME .0^$#.82.1*Z0- =FZ),4A)=^19.-+N3\E6O)(G8O$C8A8$%Z2E=E>.2%H M1R"GH7F(EVOTZ!J^B*VJ#1<,GX.0FUS21]:6S7M@6MOGC*PZ1>GL:9PR9P3= M&S)#5G=FH@#LCU7H+5@ MD,A"E$1>;S #B^T>3OG<$.K;17#(BQ0:VWS.]] @*OD@_X4(P=C'PO4"$ 8A M_J<52O#<2"[D4":,3&/5TFD-U--M&<+8 E]AAS)D4"79T?RM4UH@ET2IV^K= M@EW43;;9W&VIUB<(8O>5S@"RX25B8B9JXB9R8B=ZXB>"8BB*XBB28BF:XBFB M8BJJXBJR8BNZXBO"8BS*XBS28BW:XBWB8B[JXB[R8B_ZXB\"8S *XS 28S$: MXS$B8S(JXS(R8S,ZXS-"8S1*XS128S5:XS5B8S9J(R860#=Z(P!X8S>"8SBF M 3EFDCG.03@6P!BHXS>2@3J6 3FNXQG (SNB(V*THSAN8S::XSWJ8SG^(R:Y MHR\,Y#C.8T$BI#X6Y#L&I$$>ASLNY#Y2XT B)!M$_F1_S*,<9*1#_D)"9B1% M_F-"HL%"7N12@.1&2N0T]F-(HB0]-B1&MF0;!&1)NH%',N1'LB1*QB1)ON1A MG&1*6N-*?J09H*-'YB1.BB-$-N0]VF-17F0[-B5'WF1,2J54_F134F4\+N5, MGN0Z*J5.EN15UB-6?F56 F4MBJ56VF-41J5"'B12>N4W@N1:$B57TF5=;F0^ MXN1=:F5>NJ5? F9/WB1>,N1=RJ-)E3Y:F<"KG;O:F;XZD9;9E:LXF M;2:E00(F<'8F9VJG;#XG4CJG%HDV)F>4XG M+@KE=8)F::G8"XF>,IF2[*G:?:G;N(F0 HH:])G?/)B6?(G M>IJG>MXG@D+H@TJH&I#G#*H+-IE?<:E=[JE8;)F M:!+F>PXH.(KHBA*G?O[G7'8G<=(H?N8D9(ZF= +ICI8H+9[H<:;H4=HF:EKG MDI)ECDXEAOZE>\)E@I:E/_:C=5+E6&II5QXIDV*I:\:H9;[F:0YIF9:I<9II M_IJJ:6%RZ)JZJ9D>Z)O**8,.YYS:Z9WB:9[JZ9[R:9_ZZ9\":J *ZJ 2:J$: MZJ$B:J(JZJ(R:J,ZZJ-":J1*ZJ12:J5:ZJ5B:J9JZJ9R:J=ZZJ>":JB*ZJB2 M:JDZ(XF::JH*)*JJ:JO^S)B2J:O**L-" M:[B*Z[B2:[F:Z[FB:[JJZ[JR:[NZZ[O":[S*Z[S2:[W:Z[WB:[[JZ[[R:[\2 MI'W"07X"0ZPN*:O*I'\2 \'Z:R"=2 M/&61!H/ #@/(RN3%0EIOHJK% D3'ZN3HB.P:H"S)GJ.7!B9OUJG,2NR6[F3$ M1BF/!!FAB;BB62JC.;B5='N:TVBB-'J53 MXFQQMB> LFA<'NWU\"8[?BC/?FB*_JW?&NY^NBS51JC=CFC9'N[=]NB$ M#J[HS.S8\BWD[J1+EF?F9J?COBV$_NC&FFWEONIQ8B[H:NYSUF7GJN[GAB[; M*JN-4J[I @V5DF5MXNCD_E9IZ>)H9B+N8%HMZ?8HE_ZD9L+HQMKN[;YDS_XF MSDZIS1[I:4ZOD7[IU-:IT$8OUNIGBC[IPV+MRR[O^))O^9KO^:)O^JKO^K)O M^[KO^\)O_,KO_-)O_=KO_>)O_NKO_O)O__KO_P)P OP !-P 1OP ;\!!BCP M C-P SOP T-P!$OP!%-P!5OP!6-P!FOP!G-P!WOP!X-P"(OP")-P"9OP"7_P M?F N]C!J@P"V^C"Q_'"L-P-LJP<6! !NCP#O-P#_OP#P-Q$ OQ$!-Q$1OQ M$2-Q$BOQ$C-Q$SOQ$T-Q%$OQ%%-Q%5OQ%3MQ#6OQ%G-Q%WOQ%X-Q&(OQ&.^' M_EZ>K/B68\C&@4)J).$>+,>.9(TL9;+";1QS[L%.;^@*J#W5<;4N\29;;CH&Q"0S M,ARWR2*O;"2/K"DS\A\_\BJC$2C[L87NL8SN[(96;],VK6!J,E;J,B#OI=1N M*2]WY];2LM>2J5U"Y? .\HY:*2]G+S&+)),Z;^O*\H+>Z[5DLS*;'K9C4RNO2O9&:W8V_[11HW)F!_9>3S9&0W9I+_9"VS1F M:W4L8[1F[W0OYS)ITW1>_B?V1_=U6!,U8_,U58]V:^>S)*LU6I.T:1_W;A_T M0#/W <4F@'KO\'KO:P\W= LO[XYI8=*L+W/S=?3>X<3PVQ$8XC<1U@TYN&:.QL!)$ MC'[RB.\I@G,LBI-QB[LX,;%S(VMDSDXW3;+X'8\RKEKX>JYQ'=\XA^/XXN:Q MU M_I93^(Q@^6\S[TSO>$<"I&%V>28[MTE>,B=G]2E[,IRW>673N5)[=IOGLBA; MLD\6LH*?;EQ'*=-V]RW'^4A;LU_ZLH]Z+!M';3J7\WO6-SQ+:9=6)Y-#NDR' MI%H>>L%Z;. V.J)SMVB?Z#KSI-8R;I,3.EEWLU*C>>%^GS5M=[:NUS:.0WJ;FGS/S_;/GS9?TSQP/WQU4WK6B_QR+SW#\_O8>WGR MNC;$V[%N7_VXTW6Y'WVEV_S:2[V(P[IX9S=CIK>Q/[BO _YZ$_YX%B^3A_ET MS_DQ,_Z7 BU](^^!!_[5?OIM*J[A=[JLE_WDSS?E2W/C SCB#SECCJ>2_OMY M9NBTUOA>;O?G%WN!B_>Q_ILQ+"?HR--I+XIYF.V^N/8^PZ;B[W\KL)^BBE^B M\;]X\BM_GR:N>F8YH*=YG9\XY@OZB6ML]:\YE/?X8%^_KW+[VW]W\2-VR7]R MDJLYJ$2ZG(\U78ME*\)\09YLN'PYF\6,4HC<*JIJ&%;[#'QJRG MZ5.G#YU%=\S*/+3EKY['CR!#[KH725U =\F(\9,X<=Q%@AM;94H8L1VY@S$M MLM0)L^&F>S,5]KR63Z31HTB-0DM6!8F88SNJO+GR[D:V;_^:1MT"K:M4'ES- M<5N6X<3 M*U[,N#%$QY C2^XU>++ERY@E#\O,N?/DI9Y#BQY=_@\TZ=.H4ZM>S;JUZ]>P M8\N>3;NV[=NX<^O>S;NW[]_ @PL?3KRX\>/(DRM?SKRY\^?0HTN?3KVZ]>O8 MLVO?SKV[]^_@PXL?3[Z\^?/HTZM?S[Z]^_?PX\N?3[^^_?OX?>NMC,=(23\& MS<$?@(<-.-)6?W%1V1>A3;5'$4V- 19E!@IH&C#_@'<.+AG^4F&%RIW4#G\@ M0D8&8@LQM"$O)8H1B1TM5A]B"(PE!5XU&:HD%C8AP)ZT]]-*@JI2XP, MECCC=#R6D=4/9(0%%Q%05615@@/5Y9]>;3 (Y1DG,L(E6TY=E65&$P5CS5)A MEB5856$"YE470CRI!2%V_AE3Y"5HF%G'G#F <@:8;H;C19M4?NEF6>&8X1HW MJ70(U% YN83)I! )I-)+.F$JZ4I1"IIG3IAJ0E(I"PI*DER#CFIAEJ*DT1]52I3I&2U=&M513VV4YD7L9FL7$0^Y&M% M%B8*QDXK>D,*J!'&ZLHZ+A5*[:9J-()NKZDQ^ZRGE-YZK+SBTJNNKFT8&Z!) M5O+S*;<=V7@.42SM^1.V-.'3K[5#TAM74 5G&N0SV.R#KVKN B3NMP[/>^JO M#*];C2L<=2QRAY)0@FU&36T^25F\&U+>I8X M/(O3L5GAXK6J6^.84>Z+Y?>R"GEZ%\K6^:Z8'QAZW9N7;OKIJ*>N^NJLM^[Z KZ[#'+OOLM-=N^^VXYZ[[[KSW[OOOP Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14145; Fri, 14 Apr 95 10:32:41 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 14 Apr 95 10:26 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 14 Apr 95 10:29 PDT Message-Id: To: huq@rockie.nsc.com (Syed Huq) Cc: ibis@vhdl.org, scott@icx.com Subject: Re: In Search of an IBIS HomePage In-Reply-To: Your message of "Fri, 14 Apr 1995 10:14:51 PDT." <9504141714.AA15073@rockie.nsc.com> Date: Fri, 14 Apr 1995 10:29:14 -0700 From: Scott Aron Bloom Vhdl.org has a www home page. And it appears that the DIE group has a sub-page. Is there any reason why an IBIS page could not be placed under the VHDL page. Also, VHDL does have a gopher setup. We may want to look into setting up the IBIS file area under the VHDL gopher system to allow easier downloading of the IBIS models. This is going to be an even bigger concern as more models get placed on-line. Scott Interconnectix, Inc > X-Sun-Data-Type: text > X-Sun-Data-Description: text > X-Sun-Data-Name: text > X-Sun-Content-Lines: 33 > > Hi IBISfans, > > Here at National, we have created an IBIS HomePage for Netscape(Mosaic) > with all kinds of information on IBIS including articles, Press Release > information, Golden Parser Status, List of available models, IBIS Industry > News and on and on..We intend to spread info on IBIS to as much of a > wider audience within National as possible. > (use xv or other tool to view the .gif files) > > Unfortunately because of Firewall, the outside industry cannot access this > HomePage presently. I am just attaching two .gif files to give you a > flavor of what a typical IBIS HomePage may look like. > > I seriously believe we should set one up and allow anyone and everyone > to visit the IBIS HomePage. We can include presentation materials, Training > information with Graphics, plots, waveforms, articles and all kinds of goodies.. > > Let's talk more about this.. > > By the way, the IBIS models coming out of National is a team effort and I > thank TCAD(Technology CAD) and all others for their support. > > Stay tuned for more IBIS models from National within the coming months. > > Regards, > Syed. From bward@Starbase.NeoSoft.COM Fri Apr 14 12:19:38 1995 Return-Path: Received: from Starbase.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14757; Fri, 14 Apr 95 12:19:38 PDT Received: (from bward@localhost) by Starbase.NeoSoft.COM (8.6.10/8.6.10) id OAA16140 for ibis@vhdl.org; Fri, 14 Apr 1995 14:14:04 -0500 Date: Fri, 14 Apr 1995 14:14:04 -0500 From: Bob Ward Message-Id: <199504141914.OAA16140@Starbase.NeoSoft.COM> X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 To: ibis@vhdl.org Subject: Bird 27 discussion Ibis folks - In reading through the minutes of the last meeting, and looking at the response I got about it, I think part of the point of BIRD 27 was missed, and that in fact I did an inadequate job of making it in the first place. This added keyword is more than a mere convenience for the model maker, although it adds that convenience as well. Bear with me through a little reasoning here. We had laid down a ground rule that ibis files should be e-mail friendly and in fact that has generated a lot of follow up discussion. Recall the discussions that ensued about the 80 character line length limits when we were pursuing the package model data. And that has arisen a couple of times since. We have jumped through a number of hoops to make sure that the file remained e-mail friendly. Well, most if not all mailers, and virtually all mail relays, impose a limit on the size of an e-mail file as well as line limits. Left to themselves, partial file deliveries are not that unheard of through SMTP mail. I have received several mailings that were not all there ( and I don't mean the thinking behind them;-)). The limit is somewhere around 60k bytes, which for any one model would not be a problem. BUT when I try to package several models which are intimately related to each other, such as a chip set, for example, I can push that limit quite easily. The use of an abbreviated form such as I am proposing removes the mandate otherwise present in the spec to include redundancy which is only for the conveience of the parser writer. Specifying the same numbers over and over again on the pin mapping lines is redundant and only serves to make the parser a LITTLE easier to write. The further rules imposed are already imposed by the Lpkg, Cpkg, and Rpkg keywords, which accomplish the same thing in their domain. So we DO have the precedent for doing as I suggest. The further rules are not very involved at all for a properly structured parser to handle. And any such redundancy I can remove is the more content bearing data I can include in the file without getting e-mail burps. We would not have to include NA on all lines, unless we want to specifically force data to be defaulted, but we could simply leave these columns out as we do with Lpin, Cpin, and Rpin now. NA would say we really do not have the data. Since that capability is already there, we already have the rule that says a default can be used, and all I am adding is a new place the default might come from. There was some question about where I would position the new keyword. I can make a case in my own mind for it to be a modifer on [component], and I can similarly make a case for it to be a modifer on [pin]. I am not greatly vested in either one just now ( or somewhere other, for that matter ), and am open to discussion of that as an implementation matter if the fundamental priciple is agreed to. I lean toward [pin], but not with any great conviction. So I hope to revisit this at the next meeting, possibly briefly, and bring it to rest at that time. Sorry I could not be at the last meeting to make this defense at the moment, but the conflict I had was unavoidable. All the best, Bob Ward bward@neosoft.com From nijjar@icssj.com Mon Apr 17 18:44:27 1995 Return-Path: Received: from netcomsv.netcom.com (uucp13.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22787; Mon, 17 Apr 95 18:44:27 PDT Received: by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id SAA14263; Mon, 17 Apr 1995 18:33:51 -0700 Received: from cc:Mail by ss670mp.icssj.com id AA798167458 Mon, 17 Apr 95 18:10:58 Date: Mon, 17 Apr 95 18:10:58 From: "nijjar" Message-Id: <9503177981.AA798167458@ss670mp.icssj.com> To: ibis@vhdl.org Cc: nijjar@icssj.com Subject: IBIS Questions??? Hello, I have couple questions regarding IBIS modeling. I would appreciate if someone could help me to get going. First question I have is about 'Model Libraries'. I have about 70-80 ICs to be modeled. For all these ICs, there are only 6-7 different I/O pin models. So, I'm wondering if its possible to have one big file which has only the pin models. The IBIS model for each IC then references this big file for the pin model information. It would save me some disk space. It would also give me much less frequent headaches, when comes the library maintenance. The other question I have is about C_comp (silicon die capacitance). Is it different than Input/output pin capacitance given in the Data Books? Is it same as gate/diffusion capacitance? Thanks in advance, Gurjit S. Nijjar Integrated Circuit Systems, Inc. (408)925-9431 From mbs@eos.ncsu.edu Tue Apr 18 08:28:19 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 AA01611; Tue, 18 Apr 95 08:28:19 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08111; Tue, 18 Apr 1995 11:22:42 -0400 From: mbs@eos.ncsu.edu Message-Id: <9504181522.AA08111@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: NEW IBIS MODEL Date: Tue, 18 Apr 95 11:22:41 EDT From National Semiconductor in /pub/ibis/models/national/cgs 2537v.ibs cgs 04-17-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) From bob@icx.com Tue Apr 18 10:52:57 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02720; Tue, 18 Apr 95 10:52:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 18 Apr 95 10:47 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 18 Apr 95 10:49 PDT Message-Id: Date: Tue, 18 Apr 95 10:49 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, nijjar@icssj.com Subject: Re: IBIS Questions??? Gurjit: To be IBIS compatible, it is required to have all the models that are called by a pin model to reside in the same file. It is permissible to for the file to contain models that are not referenced by the pin models, but not visa-versa. Since you are dealing with only 6 or 7 I/O pin models, you should be able to add them to the pin model file or else split the pin model file into several files, each containing the same set of I/O pin models. Regarding C_comp, most data books describe the Cin and Cout paramters as the device or die capacitance. This is the same as C_comp. Actually, C_comp can be viewed as an effective or equivalent die capacitance which is the summation of all possible contributions including diffusion capacitances and metalization. Based on theory, the actual capacitance can vary with voltage and operating conditions, but an effective fixed capacitance such as found in data books or obtained by using some extraction method provides the C_comp for IBIS models. Bob Ross, Interconnectix, Inc. (503) 603-2523 > To: ibis@vhdl.org > Cc: nijjar@icssj.com > Subject: IBIS Questions??? > Status: RO > Hello, > I have couple questions regarding IBIS modeling. I would > appreciate if someone could help me to get going. > First question I have is about 'Model Libraries'. I have > about 70-80 ICs to be modeled. For all these ICs, there are > only 6-7 different I/O pin models. So, I'm wondering if its > possible to have one big file which has only the pin models. > The IBIS model for each IC then references this big file for > the pin model information. It would save me some disk > space. It would also give me much less frequent headaches, > when comes the library maintenance. > The other question I have is about C_comp (silicon die > capacitance). Is it different than Input/output > pin capacitance given in the Data Books? Is it same as > gate/diffusion capacitance? > Thanks in advance, > Gurjit S. Nijjar > Integrated Circuit Systems, Inc. > (408)925-9431 From mbs@eos.ncsu.edu Thu Apr 20 08:07:19 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 AA28310; Thu, 20 Apr 95 08:07:19 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA16257; Thu, 20 Apr 1995 11:01:43 -0400 From: mbs@eos.ncsu.edu Message-Id: <9504201501.AA16257@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: GETTING MODELS FROM THE IBIS LIBRARY Date: Thu, 20 Apr 95 11:01:43 EDT I have had several enquiries about getting models from the ibis model library. You must ftp to vhdl.org, login as anonymous, enter your email address as password and then change directory to the models directory. Go to the appropriate directory and get the model you want. An example follows. Michael > ftp vhdl.org Connected to vhdl.org. 220 vhdl.vhdl.org FTP server (Version wu-2.1c(9) Tue Mar 15 12:14:53 PST 1994) . Name (vhdl.org:mbs): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-Please read the file 00README 230- it was last modified on Thu Dec 1 23:27:21 1994 - 140 days ago 230 Guest login ok, access restrictions apply. ftp> cd /pub/ibis/models 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. intel 00readme Index PROTOCOL.TXT DISCLAIM.TXT national 226 Transfer complete. 62 bytes received in 0.012 seconds (5.2 Kbytes/s) ftp> cd national/interface 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. ds26c31.ibs ds26c32.ibs Index 226 Transfer complete. 33 bytes received in 0.0039 seconds (8.3 Kbytes/s) ftp> get ds26c31.ibs 200 PORT command successful. 150 Opening ASCII mode data connection for ds26c31.ibs (21946 bytes). 226 Transfer complete. local: ds26c31.ibs remote: ds26c31.ibs 22402 bytes received in 2.1 seconds (10 Kbytes/s) ftp> quit 221 Goodbye. From speters@ichips.intel.com Fri Apr 21 23:06:38 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19620; Fri, 21 Apr 95 23:06:38 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 21 Apr 95 16:47:32 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 21 Apr 95 16:46:34 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 21 Apr 95 16:46:37 PDT Message-Id: <9504212346.AA26732@xtg801.intel.com> To: ibis@vhdl.org Cc: samie@ichips.intel.com Subject: EGG for Transmision Line Package Models Date: Fri, 21 Apr 1995 16:46:35 -0700 From: Stephen Peters Hello All: In this egg I am proposing a method of describing the electrical characteristics of the connection between the die pad and the PCB or other medium the package is mounted to. Specifically, I would like to describe this connection (referred to as the package 'stub') as one or more elements in series. These elements include lumped inductances/ capacitances/resistances, uncoupled transmission lines, or coupled transmission lines. Refer to figure 1 below (it will be used as an example throughout this discussion). Bondwire Package Trace ----------------@@@@@@@@--ZZZZZZZZZZZZZZZZZZZZZZZ | DIE | || -------------- || Pin || Fig 1 -- A Simple(?) Package There are a couple of things to note about the typical package as shown in Figure 1. The most obvious is that a package stub is made up of several different elements, and these elements can be modeled in different ways. For example, the bondwire can be represented by a lumped inductor or a high impedance transmission line segment. The package trace itself is analogous to a PCB trace and can be described using the same parameters (length, Zo, trace velocity) as a PCB trace. In addition, depending on package construction or the absence of a ground plane in the package, package traces may exhibit significant coupling between themselves and nearby traces. Likewise, the pin itself can be represented as a lumped inductor or capacitor. As the IBIS spec stands now it cannot describe the above package stub as anything other than a lumped L, R and C. Without any length (or L and C per unit length) information the delay and Zo characteristics of the stub cannot be modeled. Furthermore, even though the IBIS '.pkg' file does allow one to describe the coupling between pins, it is (again) lumped information without regard to length or the fact that different sections have different coupling. The proposed expansion of the '.pkg' file description allows both 1) a package stub to be described as a series of sections made up of different types of electrical elements and 2) a per unit length description of the L and C information of each section. The proposed changes also allow the complete elimination of the matrix information if coupling descriptions are not required. SECTION AND LENGTH INFORMATION: 1. The first enhancement is to add the keyword [Number of Sections]. This keyword occurs before the [Pin number] keyword, and describes the number of sections (or elements) a package stub is divided into. It is a positive integer greater than zero. Using figure 1 above as an example: [Number of Sections] 3 2. The second change is to the [Pin number] keyword. Currently, this keyword simply denotes a list of pins numbers and their order. [Pin Number] A1 A2 . . . A10 The proposal is to add to the pins listed by this keyword the per unit length L/R/C information for each section of the package stub. This information would be listed as follows. [Pin Number] A1 Len:0 L: 1.5n, Len: 0.7 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p A2 Len:0 L: 1.5n, Len: 0.4 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p . . . A10 Len:0 L: 1.5n, Len: 1.0 L: 6.0n C: 2.5p R: 1.8, Len:0 C:2.0p After each pin number comes the physical length of the first section (Len:), then the section's per unit length L/R/C. The Len: parameter is optional, as well as the L/R/C parameters (you'll see why in a moment). If the Len: parameter is missing or it's value is '0', then treat the listed L/R/C as a lumped element. Each section description is separated by a comma. At this point we have all the information required to describe our simple package example (assume for the moment we are not concerned about coupling between pins or package traces). In our example the bond wire is described as a lumped inductor, the package trace is described as a transmission line with DC loss, and the pin is described as a capacitor. Note that the information is presented in a straight forward and 'natural' form; length and the basic parameters of L, R and C. And, since the matrix description is not required... 3. The matrix information now becomes optional. In other words, the [Model Data], [End Model Data] and the keywords in between are now optional and the package description can end with the [Pin Number] keyword. This may seem radical, but for most IBIS users this makes the whole '.pkg' file concept a lot friendlier and usable. COUPLING: Suppose now we DO wish to describe the coupling between package traces. The matrix format is used, but we need some way to let the simulator know that it applies to section 2 of our stub. The proposal is to add a 'section' argument to the [Model Data] keyword. [Model Data] Section 2 The section argument is followed by a positive integer that refers to one of the sections defined in the [Pin Number] keyword above. Note also that, once a particular section of stub is described using a matrix, the 'self' L/R/C values are included in the matrix and do not need to be repeated in the [Pin Number] statement. This is why the L/R/C values in the [Pin Number] statement are optional even if a Len: is specified. All the matrix types that have been defined so far are used as needed -- the only difference is that now they apply to a section of specific length, and the values in the matrix are given as per unit length. There can be multiple [Model Data]/[End Model Data] keyword per package description. SUMMARY: In summary, the enhancements are as follows: 1. Adding the keyword [Number of Sections] 2. Adding Length and L/R/C info to each pin in the [Pin Number] keyword 3. Making the matrix information optional 4. Adding the argument 'Section' to the [Model Data] keyword There is one more issue that may arise. If one has a lot of sections in a package stub, the description for each pin could run over the 80 character limit. Because of the difficultly distinguishing between a pin number and parameter value, simply allowing a carriage return in the middle of a line may not work. I propose adding the requirement that pin numbers MUST start in column one. If a line is long enough to require a continuation line then the continuation line begins with whitespace. Since this is an egg, (and a big one at that) I did not try and formally describe each keyword and the exact rules for usage. Also, there are some fundamental technical points about deriving the data for the matrixes that need to be defined by the forum. I am saving that topic for a second egg, after this one has had a chance to digest. Best Regards, Stephen Peters Intel Corp. From cpk@Cadence.COM Tue Apr 25 08:30:08 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07258; Tue, 25 Apr 95 08:30:08 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA08934; Tue, 25 Apr 1995 08:24:27 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma008896; Tue Apr 25 08:24:09 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA26774; Tue, 25 Apr 95 08:22:45 -0700 Received: by hot (5.65+/1.5) id AA23578; Tue, 25 Apr 95 11:24:03 -0400 Date: Tue, 25 Apr 95 11:24:03 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9504251524.AA23578@hot> To: ibis@vhdl.org, speters@ichips.intel.com Subject: Re: EGG for Transmision Line Package Models Cc: samie@ichips.intel.com I have problem with this type of extension to IBIS format . Here we have open ended circuit information and we are trying to reinvent a circuit format. The best way to include open ended package information , in my view is in the form of a spice sub circuit. Once you have defined the external terminals and there is a mapping of these terminals to buffer output and device pins, the spice circuit allows you to put any number of transmission line sections, inductances , capacitances and or combination of lumped and transmission line elements. An extension to coupled transmission line sis RLGC matrixes with non zero length. > > > Hello All: > > In this egg I am proposing a method of describing the electrical > characteristics of the connection between the die pad and the PCB or > other medium the package is mounted to. Specifically, I would like to > describe this connection (referred to as the package 'stub') as one or > more elements in series. These elements include lumped inductances/ > capacitances/resistances, uncoupled transmission lines, or coupled > transmission lines. Refer to figure 1 below (it will be used as an > example throughout this discussion). > > > > Bondwire Package Trace > ----------------@@@@@@@@--ZZZZZZZZZZZZZZZZZZZZZZZ > | DIE | || > -------------- || Pin > || > > Fig 1 -- A Simple(?) Package > > > > There are a couple of things to note about the typical package as shown > in Figure 1. The most obvious is that a package stub is made up of several > different elements, and these elements can be modeled in different ways. > For example, the bondwire can be represented by a lumped inductor or a > high impedance transmission line segment. The package trace itself is > analogous to a PCB trace and can be described using the same parameters > (length, Zo, trace velocity) as a PCB trace. In addition, depending on > package construction or the absence of a ground plane in the package, > package traces may exhibit significant coupling between themselves and > nearby traces. Likewise, the pin itself can be represented as a lumped > inductor or capacitor. > As the IBIS spec stands now it cannot describe the above package > stub as anything other than a lumped L, R and C. Without any > length (or L and C per unit length) information the delay and Zo > characteristics of the stub cannot be modeled. Furthermore, even though > the IBIS '.pkg' file does allow one to describe the coupling between pins, > it is (again) lumped information without regard to length or the fact that > different sections have different coupling. The proposed expansion > of the '.pkg' file description allows both 1) a package stub to be > described as a series of sections made up of different types of electrical > elements and 2) a per unit length description of the L and C information of > each section. The proposed changes also allow the complete elimination of the > matrix information if coupling descriptions are not required. > > SECTION AND LENGTH INFORMATION: > 1. The first enhancement is to add the keyword [Number of Sections]. This > keyword occurs before the [Pin number] keyword, and describes the > number of sections (or elements) a package stub is divided into. It is > a positive integer greater than zero. Using figure 1 above as an example: > > [Number of Sections] 3 > > > 2. The second change is to the [Pin number] keyword. Currently, this > keyword simply denotes a list of pins numbers and their order. > > [Pin Number] > A1 > A2 > . > . > . > A10 > > The proposal is to add to the pins listed by this keyword the per unit > length L/R/C information for each section of the package stub. This > information would be listed as follows. > > [Pin Number] > A1 Len:0 L: 1.5n, Len: 0.7 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p > A2 Len:0 L: 1.5n, Len: 0.4 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p > . > . > . > A10 Len:0 L: 1.5n, Len: 1.0 L: 6.0n C: 2.5p R: 1.8, Len:0 C:2.0p > > After each pin number comes the physical length of the first > section (Len:), then the section's per unit length L/R/C. The Len: > parameter is optional, as well as the L/R/C parameters (you'll see why > in a moment). If the Len: parameter is missing or it's value is '0', then > treat the listed L/R/C as a lumped element. Each section description is > separated by a comma. > At this point we have all the information required to describe our > simple package example (assume for the moment we are not concerned about > coupling between pins or package traces). In our example the bond wire > is described as a lumped inductor, the package trace is described as a > transmission line with DC loss, and the pin is described as a capacitor. > Note that the information is presented in a straight forward and 'natural' > form; length and the basic parameters of L, R and C. And, since the matrix > description is not required... > > 3. The matrix information now becomes optional. In other words, > the [Model Data], [End Model Data] and the keywords in between are now > optional and the package description can end with the [Pin Number] keyword. > This may seem radical, but for most IBIS users this makes the whole > '.pkg' file concept a lot friendlier and usable. > > COUPLING: > Suppose now we DO wish to describe the coupling between package > traces. The matrix format is used, but we need some way to let > the simulator know that it applies to section 2 of our stub. The > proposal is to add a 'section' argument to the [Model Data] keyword. > > [Model Data] Section 2 > > The section argument is followed by a positive integer that refers to > one of the sections defined in the [Pin Number] keyword above. Note also > that, once a particular section of stub is described using a matrix, the > 'self' L/R/C values are included in the matrix and do not need to be > repeated in the [Pin Number] statement. This is why the L/R/C values in > the [Pin Number] statement are optional even if a Len: is specified. > All the matrix types that have been defined so far are used as > needed -- the only difference is that now they apply to a section of > specific length, and the values in the matrix are given as per unit length. > There can be multiple [Model Data]/[End Model Data] keyword per package > description. > > > SUMMARY: > > In summary, the enhancements are as follows: > > 1. Adding the keyword [Number of Sections] > 2. Adding Length and L/R/C info to each pin in the [Pin Number] > keyword > 3. Making the matrix information optional > 4. Adding the argument 'Section' to the [Model Data] keyword > > There is one more issue that may arise. If one has a lot of sections > in a package stub, the description for each pin could run over the 80 > character limit. Because of the difficultly distinguishing between a pin > number and parameter value, simply allowing a carriage return in the > middle of a line may not work. I propose adding the requirement that > pin numbers MUST start in column one. If a line is long enough to require > a continuation line then the continuation line begins with whitespace. > > > Since this is an egg, (and a big one at that) I did not try and > formally describe each keyword and the exact rules for usage. Also, > there are some fundamental technical points about deriving the data for > the matrixes that need to be defined by the forum. I am saving that topic > for a second egg, after this one has had a chance to digest. > > > Best Regards, > Stephen Peters > Intel Corp. > > > From speters@ichips.intel.com Tue Apr 25 09:53:02 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07798; Tue, 25 Apr 95 09:53:02 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Tue, 25 Apr 95 09:47:18 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 25 Apr 95 09:46:59 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 25 Apr 95 09:47:04 PDT Message-Id: <9504251647.AA19734@xtg801.intel.com> To: cpk@cadence.com Cc: ibis@vhdl.org, speters@ichips.intel.com, samie@ichips.intel.com Subject: Re: EGG for Transmision Line Package Models Date: Tue, 25 Apr 1995 09:47:03 -0700 From: Stephen Peters Hello Kumar: Thanks for your comments. You are correct -- what we are trying to describe is a open ended circuit topology and by incorporating a full (perhaps SPICE?) netlist description of the interconnection into the .pkg file we would have a general solution. However, I am unsure on one point. How do you describe coupling between transmission lines using just a topological description of the circuit? Does the user have to build a circuit where L's and C's are added between all the coupled nodes (and does this really represent the coupling in the form the simulator tools need and use) or are the matrixes still required? If they are required, how do you indicate which circuit elements the matrix is trying to describe the coupling between? Just some food for thought..... Regards, Stephen >Kumar Writes: > >I have problem with this type of extension to IBIS format . Here we have open >ended circuit information and we are trying to reinvent a circuit format. >The best way to include open ended package information , in my view is in >the form of a spice sub circuit. Once you have defined the external terminals >and there is a mapping of these terminals to buffer output and device pins, the >spice circuit allows you to put any number of transmission line sections, >inductances , capacitances and or combination of lumped and transmission line >elements. An extension to coupled transmission line sis RLGC matrixes with non >zero length. From cpk@Cadence.COM Tue Apr 25 10:20:19 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07997; Tue, 25 Apr 95 10:20:19 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA27154; Tue, 25 Apr 1995 10:12:24 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma027093; Tue Apr 25 10:12:13 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA03127; Tue, 25 Apr 95 10:10:48 -0700 Received: by hot (5.65+/1.5) id AA24143; Tue, 25 Apr 95 13:12:08 -0400 Date: Tue, 25 Apr 95 13:12:08 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9504251712.AA24143@hot> To: speters@ichips.intel.com Subject: Re: EGG for Transmision Line Package Models Cc: ibis@vhdl.org, samie@ichips.intel.com I alluded to the problem of coupled lines when I said we may need an extension to spice to represent them. The only sure way to represent coupled lines in standard spice today is to break them into sections and represent these sections in terms of circuit capacitances and mutual inductances. This is very unpalatable. However if we are willing to add a coupled line extension to spice, we can represnt these lines is in terms of their short circuit per unit length rlgc matrices.These matrices provide the most compact representation of coupled lines and also many field solvers directly generate these matrices. Following is an example of the essense of this representation. The IBIS contribution will then be the extension to spice to represent coupled lines!! NTL 1 2 0 3 4 0 L=0.002 rlgc_name=twolines .data rlgc twolines .r matrix 4.01 0 0 4.01 .l matrix ... .g matrix ... .c matrix .. .end data rlgc twolines Here the key word "NTL" identifies the description as a coupled line . The nodes 1 and 2 represent the input terminals, 3 and 4 rperesent the output and 0 is the refernce terminal. (In this case it is the ground). L=0.002 represent the length. The example here assumes fixed unit (meter for example). The rlgc data immediately follows the transmission line description. > > Hello Kumar: > > Thanks for your comments. You are correct -- what we are trying > to describe is a open ended circuit topology and by incorporating > a full (perhaps SPICE?) netlist description of the interconnection into > the .pkg file we would have a general solution. However, I am > unsure on one point. How do you describe coupling between transmission > lines using just a topological description of the circuit? Does the user have > to build a circuit where L's and C's are added between all the coupled nodes (and > does this really represent the coupling in the form the simulator tools need > and use) or are the matrixes still required? If they are required, how do > you indicate which circuit elements the matrix is trying to describe the coupling > between? Just some food for thought..... > > Regards, > Stephen > > > >Kumar Writes: > > > >I have problem with this type of extension to IBIS format . Here we have open > >ended circuit information and we are trying to reinvent a circuit format. > >The best way to include open ended package information , in my view is in > >the form of a spice sub circuit. Once you have defined the external terminals > >and there is a mapping of these terminals to buffer output and device pins, the > >spice circuit allows you to put any number of transmission line sections, > >inductances , capacitances and or combination of lumped and transmission line > >elements. An extension to coupled transmission line sis RLGC matrixes with non > >zero length. > > > > > From jonp@qdt.com Tue Apr 25 10:58:14 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08255; Tue, 25 Apr 95 10:58:14 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQynad04801; Tue, 25 Apr 1995 13:52:20 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Tue, 25 Apr 1995 13:52:33 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00493; Tue, 25 Apr 95 09:22:24 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA23556; Tue, 25 Apr 95 09:28:13 PDT Date: Tue, 25 Apr 95 09:28:13 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9504251628.AA23556@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA15433; Tue, 25 Apr 95 09:25:00 PDT To: ibis@vhdl.org In-Reply-To: C. Kumar's message of Tue, 25 Apr 95 11:24:03 -0400 <9504251524.AA23578@hot> Subject: EGG for Transmision Line Package Models >>I have problem with this type of extension to IBIS format . Here we >>have open ended circuit information and we are trying to reinvent a >>circuit format. The best way to include open ended package information >>, in my view is in the form of a spice sub circuit. Once you have >>defined the external terminals and there is a mapping of these >>terminals to buffer output and device pins, the spice circuit allows >>you to put any number of transmission line sections, inductances , >>capacitances and or combination of lumped and transmission line >>elements. An extension to coupled transmission line sis RLGC matrixes >>with non zero length. In general, I do not find that SPICE subcircuits address the issues sufficiently. I would be happy to see some good counter-examples however. jon From contec!contec.contec.COM!dileep@netcom.com Tue Apr 25 11:46:15 1995 Return-Path: Received: from netcomsv.netcom.com (uucp12.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08772; Tue, 25 Apr 95 11:46:15 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id LAA03190; Tue, 25 Apr 1995 11:39:23 -0700 Received: from contec13.contec.COM ([192.9.200.182]) by contec.COM (4.1/SMI-4.1) id AA11927; Tue, 25 Apr 95 11:35:55 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA00443; Tue, 25 Apr 1995 11:38:11 +0800 Date: Tue, 25 Apr 1995 11:38:11 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9504251838.AA00443@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: EGG for Transmision Line Package Models Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 225 I agree with Kumar that there is no need to reinvent another format. If IBIS sepcification can make a provision for specifying a spice subcircuit name to be attached to a pin or a group of pins, that may solve this problem. From mbs@eos.ncsu.edu Thu Apr 27 07:01:15 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 AA07979; Thu, 27 Apr 95 07:01:15 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA16258; Thu, 27 Apr 1995 09:55:34 -0400 From: mbs@eos.ncsu.edu Message-Id: <9504271355.AA16258@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: s2ibis Date: Thu, 27 Apr 95 09:55:33 EDT Folks, There is a bug in s2ibis which causes a segmentation fault on hp workstations. Scott Bloom and I are working on the problem and we should post an update within 24 hrs along with a hp executable. Sorry for the problems. We (NCSU) have begun work on the s2ibis for ver 2.1 . Exams are starting here so we are on hold for 2 weeks. When we have a better idea of when the code will be relesed I will post a schedule. Michael Steer From mbs@eos.ncsu.edu Thu Apr 27 13:31:40 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 AA10922; Thu, 27 Apr 95 13:31:40 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA17424; Thu, 27 Apr 1995 16:25:59 -0400 From: mbs@eos.ncsu.edu Message-Id: <9504272025.AA17424@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: Spice-to-ibis Date: Thu, 27 Apr 95 16:25:59 EDT A new version of spice-to-ibis has been posted. It is in /pub/ibis/s2ibis. There are no new features. This version fixed bugs relating to strings which caused segmentation faults on a hp workstation. It could have cuased problems in other environmenst also. There are hp, sun, dec, rs600 executables for s2ibis11. These executables have been verified on their respective machines. There are dos and windows executables only for s2ibis10. If someone can compile s2ibis11 on dos and/or windows please email a uuencoded or mmencoded file to mbs@ncsu.edu. The files you want are in s2ibis.zip Michael Steer From KARL_KACHIGAN@HP5300.desk.hp.com Thu Apr 27 17:43:45 1995 Return-Path: Received: from relay.hp.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13228; Thu, 27 Apr 95 17:43:45 PDT Received: from opnmail4.corp.hp.com by relay.hp.com with SMTP (1.37.109.15/15.5+ECS 3.3) id AA180779483; Thu, 27 Apr 1995 17:38:03 -0700 Received: from by opnmail4.corp.hp.com with SMTP (1.37.109.8/15.5+ECS 3.4 Openmail) id AA03718; Thu, 27 Apr 1995 17:38:02 -0700 From: KARL_KACHIGAN@HP5300.desk.hp.com X-Openmail-Hops: 2 Date: Thu, 27 Apr 95 17:35:00 -0700 Message-Id: <"d0fBvn:000000000*"@MHS> Subject: Pkg Model Sender: KARL_KACHIGAN%HP5300.desk.hp.com@opnmail4.corp.hp.com To: ibis@vhdl.org Hi I have been following Stephen's proposed package model enhancment to IBIS. I support it in theory, however let's make sure that we either: 1. just use the Spice model equivalent or 2. make sure the model can be easily mapped into a simulator I would prefer the non-Spice approach as long as each line element is uniquely specified. In Stephen's case, you could easily map the bond wire, trace, and pin into distinct models in any system, but without any coupling. The PCB approach would give you a more exact representation to provide additional TL information and coupling, but I wonder if this is overkill. Could we generate a few examples in order to determine how well the proposed addition works? If we make an enhancement, I would prefer that it be long lasting rather than be the third in a sequence of many interations. Regards, Karl Kachigan HP EEsof From uunet-in!uui-cal!livewire.uunet.in!atula@uunet.uu.net Fri Apr 28 11:25:08 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24936; Fri, 28 Apr 95 11:25:08 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQynlh03024; Fri, 28 Apr 1995 14:19:15 -0400 Received: from uunet-in.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 28 Apr 1995 14:19:16 -0400 Received: by relay.UUNET.IN (Smail-N3.28-UUI) Message Id: ; Fri, 28 Apr 95 23:43 IST Received: by uui-cal.UUNET.IN (Smail-N3.28-UUI) Message Id: ; Fri, 28 Apr 95 15:12 IST Received: by livewire.uunet.in (wcGATE v4) id 34418W Fri, 28 Apr 1995 09:55:38 GMT From: atula@livewire.uunet.in (Atul Agarwal) Subject: Please add me to the IBIS reflector Date: Fri, 28 Apr 1995 07:21:10 GMT Message-Id: <950428152538399@livewire.uunet.in> Organization: LiveWire BBS! First Public Access BBS in India +91-33-2481356 To: ibis@vhdl.org Please add me to the IBIS reflector. thanks atul agarwal atula@livewire.uunet.in