From owner-ibis Fri Aug 9 14:44:36 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA08447 for ; Fri, 9 Aug 1996 14:44:35 -0700 (PDT) Received: from uucp5.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp5.UU.NET [192.48.96.36]) id QQbcbm25091; Fri, 9 Aug 1996 17:34:34 -0400 (EDT) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Fri, 9 Aug 1996 17:34:34 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01792; Fri, 9 Aug 96 13:44:36 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA16565; Fri, 9 Aug 96 13:44:37 PDT Sender: jonp@qdt.com Message-Id: <320BA334.345BF651@qdt.com> Date: Fri, 09 Aug 1996 13:44:36 -0700 From: Jon Powell X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: IBIS MEETING Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IBIS Meeting 8/16/96 Date: Fri, 09 Aug 1996 11:30:12 -0700 From: Jon Powell To: ibis@vhdl.org IBIS Open Forum Meeting Agenda for 8/16/96 Bridge Number Reservation # Passcode (916) 356-9200 2-88344 6838524 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions IEC Express Funding Progress Rusher EE Times Article Ross New Administrative Issues All 8:35 Technical Discussion BIRD34.1 - STORED CHARGE EFFECT Ross BIRD35.1 - MULTI-STAGED OUTPUTS Ross BIRD36 - ELECTRICAL BOARD DESCRIPTION Peters BIRD37.1 - ENHANCEMENT TO THE PACKAGE MODEL SPEC. Peters (Vote) BIRD38 - ABSOLUTE MAXIMUM VOLTAGE Fitzpatrick EGG12 - SPECIFICATION ADDITIONS Ross, All EGG10 - PARSER TESTS 1-5 Rokusek New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Fri Aug 9 16:31:17 1996 Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA09497 for ; Fri, 9 Aug 1996 16:31:16 -0700 (PDT) Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA19313 for ibis@vhdl.org; Fri, 9 Aug 96 16:21:13 MST Received: from emailmesa by mogate (4.1/SMI-4.1/Email-2.0) id AA26586 for ibis@vhdl.org; Fri, 9 Aug 96 16:21:12 MST Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA25463; Fri, 9 Aug 1996 18:23:29 -0500 Date: Fri, 9 Aug 1996 18:23:29 -0500 From: omera@trailblazer.sps.mot.com (Ahmed Omer) Message-Id: <9608092323.AA25463@trailblazer.aisl.aus> To: ibis@vhdl.org Subject: Dynamic Noise Immunity Spec. X-Sun-Charset: US-ASCII Hello Everyone Below is my AR from the last meeting. ... STATEMENT OF THE ISSUE Currently, IBIS specifies input logic "low/high" DC voltages for input and I/O model-types (i.e. Vinl and Vinh). This information does not specify the required time for a signal to stay at Vinl or Vinh before an input is sufficiently disturbed to cause a level switch. Therefore, pulse amplitude Vs pulse width data is needed to complete the specification. Figure 1 shows a generic plot of such data. ^ PULSE | * | A | M | * P | L | * Sufficient I | Energy T | * U | * D | E | * | * (V) | * | Insufficient * * * * * <- DC value | | |-----+-----+-----+-----+-----+---------> 0 Tr 2Tr 3Tr 4Tr 5Tr PULSE WIDTH (ns) Figure 1: Receiver Noise Tolerance ---------------------------------- This is also referred to as dynamic noise immunity curve. To summarize the plot: - Pulses with widths of 5 rise times (Tr) or more, DC value will causes a receiver switch. - Pulses with widths of less than 5Tr, amplitudes of larger than DC value are necessary to cause switch. - In the region below the curve, the receiver will not switch. - In the region above the curve, the receiver will switch. SUGGESTED SPECIFICATION SUGGESTION A - Combine with Vinl and Vinh A table of at least five data points should be provided with each Vinl and with each Vinh. Each point is a pair of time and voltage values in the form (t, v) where Tr < t < 5Tr. Suggested format is shown below. Vinl= xx.xx; Table: (tl1, vl1) (tl2, vl2) (tl3, vl3) (tl4, vl4) (tl5, vl5) Vinh= xx.xx; Table: (th1, vh1) (th2, vh2) (th3, vh3) (th4, vh4) (th5, vh5) SUGGESTION B - Use separate keyword Keyword: [Dynamic Noise Immunity] This keyword defines a table of voltage versus time points. The table contains three columns: 1- time 2- low voltage rise (volts above Ground) 3- high voltage drop (Volts below Power) Regards, Ahmed |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| From owner-ibis Fri Aug 9 18:04:42 1996 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id SAA10148 for ; Fri, 9 Aug 1996 18:04:42 -0700 (PDT) Received: from relayhost.tempe.vlsi.com (anubis.tempe.vlsi.com [134.27.128.1]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id RAA02902 for ; Fri, 9 Aug 1996 17:54:10 -0700 Received: from tempepop.tempe.vlsi.com (devious.tempe.vlsi.com [134.27.128.5]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/101195) with ESMTP id RAA20423 for ; Fri, 9 Aug 1996 17:54:09 -0700 Received: from witsend (witsend.tempe.vlsi.com [134.27.133.12]) by tempepop.tempe.vlsi.com (8.6.9/Hub-Perlotto/010296) with SMTP id SAA21645 for ; Fri, 9 Aug 1996 18:01:50 -0700 Sender: dc.sessions@tempe.vlsi.com Message-ID: <320BDDB0.25D4@tempe.vlsi.com> Date: Fri, 09 Aug 1996 17:54:08 -0700 From: "D.C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.4 sun4m) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Lies wrt clamp currents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Harish Patel (who is generating IBIS models for VLSI's standard cell products) raised an interesting point. The clamp currents that we extact or extrapolate from lab data go to totally irrelevant values at +2Vdd or -Vdd, and probably aren't very accurate anyway. Not that it really matters, since multi-amp currents will never happen in a circuit that expects to remain functional -- the actual maxima are more like Vdd/z0, or perhaps 100mA in most cases. SO -- since we're engaging in fiction anyway it may as well be a PLEASANT fiction. What lies can we tell that will best suit simulator convergence algorithms? Presumably simulators start out with the Thevenin voltages on the line and converge to actual terminator currents; the shape of the clamp V/I curve would affect convergence time. How do we optimize this process outside of realistic operating ranges? -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Sun Aug 11 12:22:35 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA02119 for ; Sun, 11 Aug 1996 12:22:34 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.7.4/8.7.3) id MAA00660; Sun, 11 Aug 1996 12:12:25 -0700 (PDT) Message-Id: <2.2.32.19960811190832.006deb30@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Aug 1996 12:08:32 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: lies wrt clamp currents To IBIS and D.C. Sessions >SO -- since we're engaging in fiction anyway it may as well >be a PLEASANT fiction. What lies can we tell that will best >suit simulator convergence algorithms? Presumably simulators >start out with the Thevenin voltages on the line and converge >to actual terminator currents; the shape of the clamp V/I >curve would affect convergence time. >How do we optimize this process outside of realistic operating >ranges? We have had this topic opened for debate at least 100 times. It really isn't that hard to extrapolate. Just pick what you think is the largest reasonable values and use them at 2Vdd and -Vdd. You don't need to fill in any of the data between what you believe the last reasonable point and 2Vdd or -Vdd. --------------------------------------------------------------- Have a great day...Kellee Crisafulli, HyperLynx Inc. --------------------------------------------------------------- From owner-ibis Mon Aug 12 08:53:31 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id IAA13646 for ; Mon, 12 Aug 1996 08:53:30 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id IAA28487 for ; Mon, 12 Aug 1996 08:43:26 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA17905; Mon, 12 Aug 1996 08:41:45 -0700 (PDT) Message-Id: <199608121541.IAA17905@ichips.intel.com> To: ibis@vhdl.org Subject: Bird 37.1 Date: Mon, 12 Aug 1996 08:43:26 -0700 From: Stephen Peters Hello All: Here is the latest version of Bird 37, the enhancement to the package description. Specific changes are: REVISIONS FOR 37.1: Based on comments received, removed backslash ("/") from the Fork and Endfork syntax, added a description of the package stub boundaries, and added two examples. I also added a recommendation that non-zero length section descriptions be treated as distributed elements. Please review and get your comments back to me by Thursday so we can discuss and vote on this bird Friday. Thanks, Stephen ============================================================================= Buffer Issue Resolution Document (BIRD) BIRD ID#: 37.1 ISSUE TITLE: Enhancement To The Package Model (.pak file) Specification REQUESTER: Stephen Peters DATE SUBMITTED: August 12, 1996 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current package model electrical description, (as proposed in Bird 28.3 and accepted by the forum) has the restriction that all the sections of a package stub connect in a series fashion, with no branches or stubs allowed. This limits the usefulness of the description when trying to describe BGA or other packages where branches or forks off the main package stub may be present. This BIRD corrects this deficiency by adding two new subparameters to the [Pin Numbers] keyword called 'Fork' and 'Endfork' ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Following are the specific changes to the specification (spec as amended by Bird 28.3). 1. The Sub-params list of the [Pin Numbers] keyword is changed to that shown below |Sub-Params: Len, L, R, C, Matrix, Fork, Endfork 2. The text following the first paragraph of the Usage Rules section of the [Pin Numbers] keyword is replaced by the following: | | Subparameters: | The Len, L, R, and C subparameters specify the length, | inductance, capacitance and resistance of each section of | each stub on a package. If a particular section | exhibits coupling to an adjacent (same numbered) section of | a different package stub then the Matrix subparameter is used. | The Fork and Endfork subparameters are used to denote branches | from the main package stub. | Len The of a package stub section. Lengths are given | in terms of arbitrary 'units'. | L The inductance of a package stub section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0nH and the | length of the section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). | C The capacitance of a package stub section, in terms of | capacitance per unit length. | R The DC (ohmic) resistance of a package stub section, in | terms of ohms per unit length. | Matrix Use of this subparameter means that this package stub | sections electrical parameters are presented as part of | a coupling matrix. The data for the matrix is included | between the [Model Data]/[End Model Data] keyword pairs | as described below. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main package stub. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a | branch. For every Fork subparameter there must be | a corresponding Endfork subparameter. As with the | Fork subparameter, the Endfork subparameter has no | arguments. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. However, if a non-zero length section | is specified, the L and C for that section should be treated | as distributed elements. | | Using The Subparameters to Describe Package Stub Sections: | A section description begins with the Len subparameter and | end with the backslash (/) character. The value of the Len, L, | R and C subparameters and the subparameter itself are | separated by an equals sign (=); whitespace around the equals | sign is optional. The Fork and Endfork subparameters | are placed between section descriptions (i.e. between the | concluding backslash of one section and the 'Len' parameters | that starts another). All package stub descriptions must | contain the same number of sections however, a particular | section description can contain no data (i.e. the description | is given as 'Len = 0 /'). | | Legal Subparameter Combinations for Section Descriptions: | A) A single Len = 0 subparameter, followed by a slash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | backslash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. The matrix description must include both the 'self' | inductance/capacitance/resistance (as required) of a section | as well as the mutual coupling terms. If one section is | described using the the Matrix subparameter then the | corresponding (same numbered) sections on ALL other package | stubs must use the Matrix subparameter. | | C) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | D) Single Fork or Endfork subparameter. Normally, a package | stub is described as several sections, with the Fork and Endfork | subparameters surrounding a group of sections in the middle of | the complete package stub description. However, it is legal | for the Fork/Endfork subparameters to appear at the end of a | section description. The package pin is connected to the | last section of a package stub description not surrounded by | a Fork/Endfork statements. See the examples below. | | Package Stub Boundaries: | A package stub description starts at the connection to | the die and ends at the point at which the package pin | interfaces with the board or substrate the IC package | is mounted on. Note that in the case of a component | with thru-hole pins, the package stub description should | include only the portion of the pin not physically | inserted into the board or socket. It is legal for | a package stub description to include both the component | and socket together if this is how the component is | intended to be used. | 3. The following examples are added to the examples for bird 28.3 | |A section description using the Fork and Endfork subparameters. Note |that the indentation of the Fork and Enfork subparameters are for |readability and are not required. | A1 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5 / | first section Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch Len=0.5 L=1.0 C=2.5/ | second section Len=0.0 L=1.5n / | pin | |Here is an example where the Fork/Endfork subparameters are at the |end of a package stub description | B13 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5 / | first section Len=0.5 L=1.0 C=2.5/ | second section, pin connects here Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This bird grew out of the need to describe a particular structure found in BGA type packages. In these packages, the trace that connects the die pad to the via for the 'ball' does not stop there. For manufacturing reasons the trace continues out to the edge of the board and thus forms a 'stub' or branch off the main pad to ball (or pin) connection. Because of the need to stick with the existing section based description, the fork and Endfork subparameters were chosen. REVISIONS FOR 37.1: Based on comments received, removed backslash ("/") from the Fork and Endfork syntax, added a description of the package stub boundaries, and added two examples. I also added a recommendation that non-zero length section descriptions be treated as distributed elements. From owner-ibis Mon Aug 12 10:44:32 1996 Received: from bhole.cae.ca (CAE.CA [142.39.200.50]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA14509 for ; Mon, 12 Aug 1996 10:44:31 -0700 (PDT) Received: from CAE_Montreal-Message_Server by wpgate.cae.ca with Novell_GroupWise; Mon, 12 Aug 1996 13:31:45 -0400 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 12 Aug 1996 13:30:56 -0400 From: Real Mongrain To: ibis@vhdl.org Subject: IBIS Specification Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Hi everybody, I was wondering if there's some documentation other than the "I/O Buffer Information Specification (IBIS) Version x.x". I know that most of people in this group are very familiar with IBIS, but i am not. Maybe somebody has already created a more explicit documentation on IBIS? Regards, Real Mongrain. From owner-ibis Mon Aug 12 12:06:18 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA15328 for ; Mon, 12 Aug 1996 12:06:17 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id LAA03344 for ; Mon, 12 Aug 1996 11:56:13 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id LAA06396; Mon, 12 Aug 1996 11:54:31 -0700 (PDT) Message-Id: <199608121854.LAA06396@ichips.intel.com> To: ibis@vhdl.org Subject: IBIS Specification Date: Mon, 12 Aug 1996 11:56:13 -0700 From: Stephen Peters Hello Real: I'm not sure exactly what you are looking for, but there is available both an artical written for EDN magazine, and a cookbook for version 1.1 models. They are both available on the web page: http://www.eia.org/eig/ibis/ibis.htm Regards, Stephen Peters Intel Corp. Hi everybody, I was wondering if there's some documentation other than the "I/O Buffer Information Specification (IBIS) Version x.x". I know that most of people in this group are very familiar with IBIS, but i am not. Maybe somebody has already created a more explicit documentation on IBIS? Regards, Real Mongrain. From owner-ibis Mon Aug 12 12:24:14 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA15449 for ; Mon, 12 Aug 1996 12:24:14 -0700 (PDT) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbcme28779; Mon, 12 Aug 1996 15:14:10 -0400 (EDT) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 12 Aug 1996 15:14:10 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01218; Mon, 12 Aug 96 11:47:16 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA08034; Mon, 12 Aug 96 11:47:17 PDT Sender: jonp@qdt.com Message-Id: <320F7C33.41C67EA6@qdt.com> Date: Mon, 12 Aug 1996 11:47:15 -0700 From: Jon Powell X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Postpone Meeting? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ibisians, There seem to be a lot of people (including Bob and Syed) who cannot make the meeting this friday. We were scheduled to vote on some things that were rather important. How do people feel about postponing the meeting for 1 or 2 weeks? Jon (Please Respond). From owner-ibis Mon Aug 12 16:02:12 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA17220 for ; Mon, 12 Aug 1996 16:02:11 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id PAA17290 for ; Mon, 12 Aug 1996 15:52:06 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id PAA04073; Mon, 12 Aug 1996 15:50:23 -0700 (PDT) Message-Id: <199608122250.PAA04073@ichips.intel.com> To: ibis@vhdl.org Subject: Postpone Meeting? Date: Mon, 12 Aug 1996 15:52:06 -0700 From: Stephen Peters Hello Jon: It's OK by me. Regards, Stephen Ibisians, There seem to be a lot of people (including Bob and Syed) who cannot make the meeting this friday. We were scheduled to vote on some things that were rather important. How do people feel about postponing the meeting for 1 or 2 weeks? Jon (Please Respond). From owner-ibis Mon Aug 12 18:02:46 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id SAA18206 for ; Mon, 12 Aug 1996 18:02:42 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.4/10.0i); Tue, 13 Aug 1996 00:52:30 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id RAA13627 for ibis@vhdl.org; Mon, 12 Aug 1996 17:52:35 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Mon, 12 Aug 96 17:52:35 PDT Date: Mon, 12 Aug 96 12:59:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: Postpone Meeting? Text item: It is OK with me, but watch out for the Labor-day weekend, many people (including me) might take off early. Arpad ========================================================================= Ibisians, There seem to be a lot of people (including Bob and Syed) who cannot make the meeting this friday. We were scheduled to vote on some things that were rather important. How do people feel about postponing the meeting for 1 or 2 weeks? Jon (Please Respond). Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: Postpone Meeting? To: ibis@vhdl.org Mime-Version: 1.0 X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) From: Jon Powell Date: Mon, 12 Aug 1996 11:47:15 -0700 Message-Id: <320F7C33.41C67EA6@qdt.com> Sender: jonp@qdt.com Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA08034; Mon, 12 Aug 96 11:47:17 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01218; Mon, 12 Aug 96 11:47:16 PDT Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 12 Aug 1996 15:14:10 -0400 Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbcme28779; Mon, 12 Aug 1996 15:14:10 -0400 (EDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8. 7.3/8.7.3) with ESMTP id MAA15449 for ; Mon, 12 Aug 1996 12:24:14 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.7.4/8.7.3) with ESMTP id MAA07373; Mon, 12 Aug 1996 12:22:22 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id MAA11294; Mon, 12 Aug 1996 12:22:32 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Aug 13 02:53:44 1996 Received: from ds9.Dortmund.loca.net (root@ds9.Dortmund.loca.net [194.39.202.133]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id CAA21972 for ; Tue, 13 Aug 1996 02:53:41 -0700 (PDT) From: olaf@pad.incases.com Received: (from bin@localhost) by ds9.Dortmund.loca.net (8.7.5/8.7.3) id JAA02140 for ; Tue, 13 Aug 1996 09:45:10 +0200 (MET DST) X-Authentication-Warning: ds9.Dortmund.loca.net: bin set sender to using -f Received: from isdn.pad.incases.com(194.64.13.226) by ds9.Dortmund.loca.net via smap (V1.3) id sma002132; Tue Aug 13 09:44:58 1996 Received: from pluto.incases.com by mail.pad.incases.com with smtp (Smail3.1.28.1 #3) id m0uqE7z-00045QC; Tue, 13 Aug 96 09:43 MET DST Received: by pluto.incases.com (4.1) id AA00681; Tue, 13 Aug 96 09:40:03 +0200 Message-Id: <9608130740.AA00681@pluto.incases.com> Subject: Postpone Meeting? To: ibis@vhdl.org Date: Tue, 13 Aug 1996 09:40:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Hello Jon, It's OK by me. Best Regards, Olaf > Ibisians, > > There seem to be a lot of people (including Bob and Syed) who cannot > make the meeting this friday. We were scheduled to vote on some things > that were rather important. How do people feel about postponing the > meeting for 1 or 2 weeks? > > Jon > (Please Respond). -- ------------------------------------------------------------------------------- INCASES Engineering GmbH * Vattmannstr. 3 * D-33100 Paderborn * Germany Olaf Rethmeier * Tel/Fax +49-5251-150-625/-700 * Email olaf@pad.incases.com ------------------------------------------------------------------------------- From owner-ibis Tue Aug 13 08:28:59 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id IAA08391 for ; Tue, 13 Aug 1996 08:28:58 -0700 (PDT) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbcph14322; Tue, 13 Aug 1996 11:18:49 -0400 (EDT) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Tue, 13 Aug 1996 11:18:50 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00234; Tue, 13 Aug 96 08:05:42 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA00613; Tue, 13 Aug 96 08:23:47 PDT Sender: jonp@qdt.com Message-Id: <32109E00.2781E494@qdt.com> Date: Tue, 13 Aug 1996 08:23:44 -0700 From: Jon Powell X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Meeting Postponed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ibisans, I guess the end of the summer is a bad time to try and get people together. I got lots of responses saying that people were planning to lay out by the pool that morning and not even think about diode saturation curves. Oh Well. From the responses and the untimely death of summer (ie. Labor Day weekend). I hereby cancel this weeks meeting and tentatively re-schedule for the 6th of September. Bob and Syed should be back by then. Have a nice vacation everyone. Jon From owner-ibis Tue Aug 13 08:36:43 1996 Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA08503 for ; Tue, 13 Aug 1996 08:36:41 -0700 (PDT) Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA29434 for ibis@vhdl.org; Tue, 13 Aug 96 07:33:16 MST Received: from emailmesa by mogate (4.1/SMI-4.1/Email-2.0) id AA20018 for ibis@vhdl.org; Tue, 13 Aug 96 07:33:12 MST Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA29938; Tue, 13 Aug 1996 09:35:25 -0500 Date: Tue, 13 Aug 1996 09:35:25 -0500 From: omera@trailblazer.sps.mot.com (Ahmed Omer) Message-Id: <9608131435.AA29938@trailblazer.aisl.aus> To: ibis@vhdl.org, jonp@qdt.com Subject: Re: Postpone Meeting? X-Sun-Charset: US-ASCII Jon, 8/23 is good for me. Regards, Ahmed From vhdl.vhdl.org!owner-ibis Tue Aug 13 12:39:01 1996 Received: from pacific.mea.com (pacific.mea.com [140.237.7.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA11330 for ; Tue, 13 Aug 1996 12:54:35 -0700 (PDT) Received: from gatekeeper.msai.mea.com by pacific.mea.com with SMTP (1.38.193.4/16.2) id AA18688; Tue, 13 Aug 1996 15:43:54 -0400 Received: (from uucp@localhost) by gatekeeper.msai.mea.com (8.6.12/8.6.12) id PAA08281 for ; Tue, 13 Aug 1996 15:29:41 -0400 Received: from unknown(198.28.5.20) by gatekeeper.msai.mea.com via smap (V1.3) id sma008271; Tue Aug 13 15:29:33 1996 Received: from sbedrock.msai.mea.com (shared [192.65.252.62]) by msai.mea.com (8.6.12/8.6.12) with SMTP id PAA16692 for ; Tue, 13 Aug 1996 15:45:20 -0400 Received: from sfred.msaiasic by sbedrock.msai.mea.com (4.1/mh-version 2.4) id AA04243; Tue, 13 Aug 96 15:43:09 EDT Date: Tue, 13 Aug 96 15:43:09 EDT From: hoang@msai.mea.com (Hoang Nguyen) Message-Id: <9608131943.AA04243@sbedrock.msai.mea.com> To: ibis@vhdl.org Subject: process parameters Status: RO Hello All, I have the following questions regarding process parameters. 1. If a process file supplies all three sets: TYP, BEST, WORST, should I provide in the model the process corner for typ, min, max according to the following conditions: (for rise, fall, pullup, pulldown tables) ? typ: typ VCC, TYPICAL process parameters min: min VCC, WORST process parameters max: max VCC, BEST process parameters The conditions above provide the best process corner information, without having to generate three separate models, each for a TYP/BEST/WORST process. 2. If a process file supplies only TYP parameters, then typ: typ VCC, TYPICAL process parameters min: min VCC, TYPICAL process parameters max: max VCC, TYPICAL process parameters as recommended in the cookbook. Even for item 1 above, I could use only TYPICAL process parameters as in item 2, but I'm afraid this won't have as much accuracy. Please comment. Thanks, Hoang Nguyen From vhdl.vhdl.org!owner-ibis Wed Aug 14 09:26:03 1996 Return-Path: Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA05211 for ; Wed, 14 Aug 1996 09:40:39 -0700 (PDT) Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbcte27769; Wed, 14 Aug 1996 12:30:28 -0400 (EDT) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 14 Aug 1996 12:30:28 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00711; Wed, 14 Aug 96 09:18:22 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA10711; Wed, 14 Aug 96 09:18:21 PDT Sender: jonp@qdt.com Message-Id: <3211FC4C.31DFF4F5@qdt.com> Date: Wed, 14 Aug 1996 09:18:20 -0700 From: Jon Powell X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: EIA Japan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO A source of mine in Japan informs me that "EIA Japan" has established an "IBIS Standarded working group" who are going to establish a standard format for IO models. Has anyone heard anything about this? Patti?? regards, jon From vhdl.vhdl.org!owner-ibis Wed Aug 14 10:11:51 1996 Return-Path: Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA05641 for ; Wed, 14 Aug 1996 10:30:49 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.4/10.0i); Wed, 14 Aug 1996 17:20:42 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id KAA28178 for ibis@vhdl.org; Wed, 14 Aug 1996 10:20:45 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 14 Aug 96 10:20:45 PDT Date: Wed, 14 Aug 96 10:07:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: EIA Japan Status: RO Text item: Jon, What do you mean by "establish a standard format for IO models"? Another standrad, different from IBIS, or are they working on making IBIS a standard in Japan? Arpad =========================================================================== A source of mine in Japan informs me that "EIA Japan" has established an "IBIS Standarded working group" who are going to establish a standard format for IO models. Has anyone heard anything about this? Patti?? regards, jon Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: EIA Japan To: ibis@vhdl.org Mime-Version: 1.0 X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) From: Jon Powell Date: Wed, 14 Aug 1996 09:18:20 -0700 Message-Id: <3211FC4C.31DFF4F5@qdt.com> Sender: jonp@qdt.com Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA10711; Wed, 14 Aug 96 09:18:21 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00711; Wed, 14 Aug 96 09:18:22 PDT Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 14 Aug 1996 12:30:28 -0400 Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbcte27769; Wed, 14 Aug 1996 12:30:28 -0400 (EDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8. 7.3/8.7.3) with ESMTP id JAA05211 for ; Wed, 14 Aug 1996 09:40:39 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.7.4/8.7.3) with ESMTP id JAA18364; Wed, 14 Aug 1996 09:34:53 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id JAA20805; Wed, 14 Aug 1996 09:34:52 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org From vhdl.vhdl.org!owner-ibis Tue Aug 20 11:34:07 1996 Return-Path: Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA07329 for ; Tue, 20 Aug 1996 11:43:14 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 20 Aug 96 11:32 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 20 Aug 96 11:32 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 20 Aug 96 11:34 PDT Message-Id: Date: Tue, 20 Aug 96 11:34 PDT From: bob@icx.com ( Bob Ross) To: hoang@msai.mea.com, ibis@vhdl.org Subject: Re: process parameters Status: RO Hoang: This is in response to last weeks question. The corner models should be based on best and worst process conditions as outlined in "1.". The temperature should be varied as well. You are correct that this may be inconsistent with other corner models based on only typical processes. IBIS allows further adjustment of data based on factors "X%" and "Y%", but I think this is rarely used. Other inconsistencies also exist. Some devices are specified with lower Vcc tolerances (e.g. 5% versus 10%) and different temperature ranges. Bipolar min/max temperatures are low/high, whereas CMOS technology temperatures are high/low. The net effect is that the corner data models may be further off and perhaps have larger temperature based deviations from each other than would be seen in practice. So this all adds up to the fact that corner analysis may serve as a valuable indication of sensitivies in design, but should not be relied upon as a predictor of preformance without understanding the assumptions of all models in the net and actual power supply and temperature assumptions for the design. Bob Ross Interconnectix, Inc. > Date: Tue, 13 Aug 96 15:43:09 EDT > From: hoang@msai.mea.com (Hoang Nguyen) > Message-Id: <9608131943.AA04243@sbedrock.msai.mea.com> > To: ibis@vhdl.org > Subject: process parameters > Status: RO > Hello All, > I have the following questions regarding process parameters. > 1. If a process file supplies all three sets: TYP, BEST, WORST, should I > provide in the model the process corner for typ, min, max according to > the following conditions: (for rise, fall, pullup, pulldown tables) ? > typ: typ VCC, TYPICAL process parameters > min: min VCC, WORST process parameters > max: max VCC, BEST process parameters > The conditions above provide the best process corner information, without > having to generate three separate models, each for a TYP/BEST/WORST process. > 2. If a process file supplies only TYP parameters, then > typ: typ VCC, TYPICAL process parameters > min: min VCC, TYPICAL process parameters > max: max VCC, TYPICAL process parameters > > as recommended in the cookbook. > Even for item 1 above, I could use only TYPICAL process parameters as in item 2, > but I'm afraid this won't have as much accuracy. Please comment. > Thanks, > Hoang Nguyen From owner-ibis Wed Aug 28 18:04:33 1996 Received: from chronos.synopsys.com (chronos.synopsys.com [146.225.8.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA02045 for ; Wed, 28 Aug 1996 18:04:32 -0700 (PDT) Received: from icx.com (fw.icx.com) by chronos.synopsys.com with SMTP id AA06184 (5.65c/IDA-1.4.4 for ); Wed, 28 Aug 1996 17:54:22 -0700 Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 28 Aug 96 17:53 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Aug 96 16:22 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Aug 96 16:25 PDT Message-Id: Date: Wed, 28 Aug 96 16:25 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: test message 1 Please Disregard From owner-ibis Wed Aug 28 18:04:30 1996 Received: from chronos.synopsys.com (chronos.synopsys.com [146.225.8.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA02042 for ; Wed, 28 Aug 1996 18:04:29 -0700 (PDT) Received: from icx.com (fw.icx.com) by chronos.synopsys.com with SMTP id AA06180 (5.65c/IDA-1.4.4 for ); Wed, 28 Aug 1996 17:54:19 -0700 Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 28 Aug 96 17:53 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Aug 96 16:05 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Aug 96 16:07 PDT Message-Id: Date: Wed, 28 Aug 96 16:07 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: test message Please Disregard From owner-ibis Wed Aug 28 18:05:15 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA02040 for ; Wed, 28 Aug 1996 18:03:49 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 28 Aug 96 17:53 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Aug 96 13:34 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Aug 96 13:36 PDT Message-Id: Date: Wed, 28 Aug 96 13:36 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Forwarded: EDIF Version 4 0 0 changes To IBIS Committee: Does anyone have any comments or concerns about this? Bob Ross Interconnectix, Inc. Date: Tue, 27 Aug 1996 13:39:51 +0100 From: Alan R Williams Message-Id: <199608271239.NAA04794@cheetah.cs.man.ac.uk> To: bob@icx.com Subject: EDIF Version 4 0 0 changes Hello Bob, As part of finishing the EIA balloting process, we are notifying all reviewers of the changes which were made as a result of their comments. With regard to the interfacing with IBIS files, the main change has been the introduction on pcbPartCharacteristic for EDIF parts. The pcbPartCharacteristic can be either a pcbPassivePartCharacteristic (RLC values) or a pcbIbisPartCharacteristic which specifies the IBIS file, the IBIS component within that file and matches up the terminals of the EDIF part to the pins of the IBIS component. I am enclosing the changes in the syntax which were made as a result of your comment. Could you please confirm by c.o.b. Friday 31st August that you are satisfied with the outcome? If we do not hear otherwise, we will assume that you are satisfied with the changes which have been made. Alan Williams -- --------------------------------------------------------------------------- Alan Williams, Room IT301, Department of Computer Science, University of Manchester, Oxford Road, Manchester, M13 9PL, U.K. Tel: +44 161 275 6270 Fax: +44 161 275 6280 e-mail: alanrw@cs.man.ac.uk pcbIbisComponentIdentification ::= '(' 'pcbIbisComponentIdentification' stringToken ')' pcbIbisFileIdentification ::= '(' 'pcbIbisFileIdentification' stringToken ')' pcbIbisFileInformation ::= '(' 'pcbIbisFileInformation' pcbIbisFileInformationNameDef pcbIbisFileIdentification { | property } ')' pcbIbisFileInformationNameCaseSensitive ::= '(' 'pcbIbisFileInformationNameCaseSensitive' booleanToken ')' pcbIbisFileInformationNameDef ::= nameDef pcbIbisPartCharacteristic ::= '(' 'pcbIbisPartCharacteristic' pcbIbisFileInformation pcbIbisComponentIdentification { pcbIbisPinBinding } ')' pcbIbisPinBinding ::= '(' 'pcbIbisPinBinding' pcbIbisPinBindingNameDef ( pcbElectricalPartTerminalRef | pcbJumperPartTerminalRef | pcbConnectorPartTerminalRef ) pcbIbisPinIdentification { property } ')' pcbIbisPinBindingNameDef ::= nameDef pcbIbisPinIdentification ::= '(' 'pcbIbisPinIdentification' stringToken ')' pcbJumperPart ::= '(' 'pcbJumperPart' libraryObjectNameDef pcbPartHeader ( pcbPinPackageRef | pcbBallPackageRef | externalNoData ) { pcbJumperPartTerminal | } ')' pcbPackagedConnectorPart ::= '(' 'pcbPackagedConnectorPart' libraryObjectNameDef pcbPartHeader ( pcbPinPackageRef | pcbBallPackageRef | externalNoData ) ( pcbSocket | pcbDiscreteConnector ) { pcbPackagedConnectorPartTerminal | } ')' pcbPackagedElectricalPart ::= '(' 'pcbPackagedElectricalPart' libraryObjectNameDef pcbPartHeader ( pcbPinPackageRef | pcbBallPackageRef | externalNoData ) pcbPackagedElectricalPartType { } ')' pcbPartCharacteristic ::= '(' 'pcbPartCharacteristic' ( pcbPassivePartCharacteristic | pcbIbisPartCharacteristic ) ')' pcbPassivePartCapacitance ::= '(' 'pcbPassivePartCapacitance' capacitanceValue ')' pcbPassivePartCharacteristic ::= '(' 'pcbPassivePartCharacteristic' { | | } ')' pcbPassivePartInductance ::= '(' 'pcbPassivePartInductance' tolerancedInductanceValue ')' pcbPassivePartResistance ::= '(' 'pcbPassivePartResistance' tolerancedResistanceValue ')' pcbPrintedConnectorPart ::= '(' 'pcbPrintedConnectorPart' libraryObjectNameDef pcbPartHeader { | pcbPrintedConnectorPartTerminal | pcbPrintedPartSymbol } ')' pcbPrintedElectricalPart ::= '(' 'pcbPrintedElectricalPart' libraryObjectNameDef pcbPartHeader pcbPrintedElectricalPartType { | pcbPrintedPartSymbol } ')' -------- End of Forwarded Message From owner-ibis Fri Aug 30 14:57:52 1996 Received: from chronos.synopsys.com (chronos.synopsys.com [146.225.8.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA00230 for ; Fri, 30 Aug 1996 14:57:51 -0700 (PDT) Received: from icx.com (fw.icx.com) by chronos.synopsys.com with SMTP id AA08935 (5.65c/IDA-1.4.4 for ); Fri, 30 Aug 1996 11:26:38 -0700 Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 30 Aug 96 11:24 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 30 Aug 96 11:24 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 30 Aug 96 11:27 PDT Message-Id: Date: Fri, 30 Aug 96 11:27 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MEETING 9/6/96 (Resuming operation after a 6 week vacation!) IBIS Open Forum Meeting Agenda for 9/6/96 Bridge Number Reservation # Passcode (916) 356-9200 2-88345 4511183 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions EIA/Japan - IBIS Working Group? Powell/Rusher IEC Express Funding Progress Rusher EE Times Article Ross New Administrative Issues All 8:35 Technical Discussion s2ibis2 QUESTIONS Huq BIRD34.1 - STORED CHARGE EFFECT Ross BIRD35.1 - MULTI-STAGED OUTPUTS Ross BIRD36 - ELECTRICAL BOARD DESCRIPTION Peters BIRD37.1 - ENHANCEMENT TO THE PACKAGE MODEL SPEC. Peters (Vote) BIRD38 - ABSOLUTE MAXIMUM VOLTAGE Fitzpatrick EGG12 - SPECIFICATION ADDITIONS Ross, All EGG10 - PARSER TESTS 1-5 Rokusek New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Sat Aug 31 21:26:31 1996 Received: from desiree.teleport.com (desiree.teleport.com [192.108.254.21]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id VAA27274 for ; Sat, 31 Aug 1996 21:26:30 -0700 (PDT) Received: from linda.teleport.com (zeelan@linda.teleport.com [192.108.254.12]) by desiree.teleport.com (8.7.5/8.7.3) with ESMTP id VAA22947 for ; Sat, 31 Aug 1996 21:15:02 -0700 (PDT) Received: (from zeelan@localhost) by linda.teleport.com (8.7.5/8.7.3) id VAA20170; Sat, 31 Aug 1996 21:14:59 -0700 (PDT) Date: Sat, 31 Aug 1996 21:14:59 -0700 (PDT) From: Zeelan Technology X-Sender: zeelan@linda.teleport.com To: ibis@vhdl.org Subject: Zeelan Technology's Email address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please change Zeelan Technology's information to the new Email, phone numbers and address george@zeelan.com FAX: 503-685-1001 Telephone: 503-685-1000 Zeelan Technology 8005 SW Boeckman Road Wilsonville, Oregon 97070 Thank you. Sincerely, George Opsahl |-----------------------------------------------------------| | Zeelan Technology Email: info@zeelan.com | | 8005 SW Boeckman Road FAX: 503-685-1001 | | Wilsonville, Oregon 97070 Telephone: 503-685-1000 | |-----------------------------------------------------------|