From owner-ibis Tue Sep 3 17:18:06 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 RAA19315 for ; Tue, 3 Sep 1996 17:18:04 -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 RAA01631 for ; Tue, 3 Sep 1996 17:07:47 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id RAA17532; Tue, 3 Sep 1996 17:04:54 -0700 (PDT) Message-Id: <199609040004.RAA17532@ichips.intel.com> To: ibis@vhdl.org Subject: bird 37.1 Date: Tue, 03 Sep 1996 17:07:48 -0700 From: Stephen Peters Hello All: I posted this a few weeks back, but seeing that it's been 6 weeks between meeting I thought I'd post it again as a refresher. We will vote on this Friday. Regards, Stephen Peters Intel Corp. ============================================================================= 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 Tue Sep 3 17:46:54 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 RAA19566 for ; Tue, 3 Sep 1996 17:46:53 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 3 Sep 96 17:36 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 3 Sep 96 17:36 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 3 Sep 96 17:38 PDT Message-Id: Date: Tue, 3 Sep 96 17:38 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD37.1 COMMENT Stephen: BIRD37.1 looks good to me. My only comments are with respect to some typos in the example - there are some missing units in some of the text (L = 1.0 instead of 1.0n, and C=2.5 instead of 2.5p. Bob Ross Interconnectix, Inc. From owner-ibis Thu Sep 5 08:44:07 1996 Received: from alcatel.fr (news2.alcatel.fr [194.133.58.131]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id IAA09776 for ; Thu, 5 Sep 1996 08:43:58 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id QAA04978 for ; Thu, 5 Sep 1996 16:33:39 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id RAA04291 for ; Thu, 5 Sep 1996 17:32:34 +0200 (METDST) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA02986; Thu, 5 Sep 96 17:33:56 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00783; Thu, 5 Sep 96 17:33:55 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <322EF2E2.1B37ADEA@ln.cit.alcatel.fr> Date: Thu, 05 Sep 1996 17:33:54 +0200 From: FITZPATRICK John Organization: Alcatel Telecom, 22304 Lannion, France X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Bird38 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, Since proposing bird 38, I have received little comment. As I was not able to attend the last two meetings, this is probably my fault. This bird is closely associated with egg12 i.e. it is a specification addition. Bird38 is basically a way to specify under- and overshoot limits. A simplification of this bird would be to just give two numbers, max_undershoot and max_overshoot. This is what a lot of simulators do, and there is a place to stick these numbers into a RAIL file. But in this case, over what time span is the over/undershoot allowed to be present. I have read through the RAIL doc, but cannot find an answer to this question. What do people out there understand by over/undershoot limits, as used in present simulators? All feedback appreciated. Cheers, John -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 From owner-ibis Thu Sep 5 13:09:24 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 NAA11975; Thu, 5 Sep 1996 13:09:15 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 5 Sep 96 12:58 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 5 Sep 96 12:58 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 5 Sep 96 13:01 PDT Message-Id: Date: Thu, 5 Sep 96 13:01 PDT From: bob@icx.com ( Bob Ross) To: John.Fitzpatrick@ln.cit.alcatel.fr, ibis@vhdl.org, omera@trailblazer.sps.mot.com Subject: Re: Bird38 Cc: rail@vhdl.org John and Ahmed: We have all had a "vacation" from IBIS committee discussions and need to get restarted in our discussions. I do not have answers to your questions, but this will be subject for discussion at the Friday Meeting. Along with Egg12, Ahmed Omera also submitted a dynamic noise proposal a long while ago which also in in the Specification enhancement category. Jon Powell had proposed a Specification sub-committee to consider all proposals together, but we have not acted on this yet. My preference is that any enhancement be simple. While some of the proposals involve tables, I suspect that the practical reality is that (1) there is too much data for anyone to really specify, and (2) very few vendors will consider processing that specific enhancement. Also, I favor consistency with the existing conventions and structure rather than adding very specific, special purpose,"warts". By this, any extension needs to work with all of the technologies and be meaningful for all of the columns. Anyway, this is what we can consider on Friday. Bob Ross, Interconnectix, Inc. > To: ibis@vhdl.org > Subject: Bird38 > Hello all, > Since proposing bird 38, I have received little comment. As I was not > able to attend the last two meetings, this is probably my fault. > This bird is closely associated with egg12 i.e. it is a > specification addition. > Bird38 is basically a way to specify under- and overshoot limits. > A simplification of this bird would be to just give two numbers, > max_undershoot and max_overshoot. This is what a lot of simulators > do, and there is a place to stick these numbers into a RAIL file. > But in this case, over what time span is the over/undershoot allowed > to be present. I have read through the RAIL doc, but cannot find an > answer to this question. > What do people out there understand by over/undershoot limits, as > used in present simulators? > All feedback appreciated. > > Cheers, > John > > -- > John Fitzpatrick > Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France > Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 From owner-ibis Thu Sep 5 14:09:19 1996 Received: from typhoon.dial.pipex.net (typhoon.dial.pipex.net [158.43.128.46]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA12559 for ; Thu, 5 Sep 1996 14:09:14 -0700 (PDT) Received: from henty by typhoon.dial.pipex.net (8.7.5/) id VAA00856; Thu, 5 Sep 1996 21:58:32 +0100 (BST) Message-ID: <322F3F1D.1FED@quantic.mb.ca> Date: Thu, 05 Sep 1996 21:59:09 +0100 From: Mike Ventham Reply-To: ventham@quantic.mb.ca Organization: Quantic Laboratories X-Mailer: Mozilla 3.0b5a (WinNT; I) MIME-Version: 1.0 To: FITZPATRICK John CC: ibis@vhdl.org Subject: Re: Bird38 References: <322EF2E2.1B37ADEA@ln.cit.alcatel.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FITZPATRICK John wrote: > > > Bird38 is basically a way to specify under- and overshoot limits. > > A simplification of this bird would be to just give two numbers, > max_undershoot and max_overshoot. This is what a lot of simulators > do, and there is a place to stick these numbers into a RAIL file. > > But in this case, over what time span is the over/undershoot allowed > to be present. I have read through the RAIL doc, but cannot find an > answer to this question. > > What do people out there understand by over/undershoot limits, as > used in present simulators? > > All feedback appreciated. > Our simulator will look at high and low overshoots as well as high and low reflections, settling time and steady state values. We don't look for a specific time span, as the wave forms are also available for viewing and measurement. Regards Mike -- +======================================================================+ | Mike Ventham - Vice President Engineering, Quantic Laboratories Inc, | | 12th Floor, 191 Lombard Ave, Winnipeg, Manitoba, Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email: ventham@quantic.mb.ca | | Brookside House, The Street, Chilcompton, Bath, Avon, England BA3 4HB| | Tel: (0) 1761 232191 Fax: Same Email: quantic@dial.pipex.com | +======================================================================+ From owner-ibis Thu Sep 5 16:32:35 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 QAA14060 for ; Thu, 5 Sep 1996 16:32:30 -0700 (PDT) Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbfxl17431; Thu, 5 Sep 1996 19:20:57 -0400 (EDT) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 5 Sep 1996 19:20:57 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01911; Thu, 5 Sep 96 16:21:49 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA06952; Thu, 5 Sep 96 16:21:49 PDT Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbfxk13638; Thu, 5 Sep 1996 19:09:11 -0400 (EDT) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 5 Sep 1996 19:09:11 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01743; Thu, 5 Sep 96 15:23:01 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA06442; Thu, 5 Sep 96 15:23:02 PDT Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <322F52C5.493F66A8@qdt.com> Date: Thu, 05 Sep 1996 15:23:01 -0700 From: Jon Powell X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Stephen Peters Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!qdt.com!jonp@uunet.uu.net Subject: Re: bird 37.1 References: <199609040004.RAA17532@ichips.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I see two issues with bird 37.1 that I think we should conciously address. Not to say that we shouldn't pass this bird, but we should only pass it if we are willing to live with these limitations: 1) This only describes point to point connections. It cannot be used for SIMMS or connectors that use multiple connections. It cannot be used for any package that might (for instance) route two ground pads to the same pin). 2) It can only be used to describe packages that are single layer. While it could describe some multi-layer packages I can give a few quick counter examples of easy to imagine scenarios that can only occur (and probably would occur) with 2 level packageing. Here is one: (these lines don't touch but the verticle lines do couple) ______________ _|___________ | | | |___________ ____________| If you think that you can represent this then think about the following and how it would be Different: (once again, only the verticle lines coupled) __________________ ________________ | | | | | | |___________ |_____________ I think that the bird37.1 description of these two examples would be the same circuit even though they are clearly electrically different. The question of whether we want to "go ahead" and do this even though it has some basic limitations is I think what we need to decide. regards, jon From owner-ibis Fri Sep 6 04:55:01 1996 Received: from alcatel.fr (news2.alcatel.fr [194.133.58.131]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id EAA05927; Fri, 6 Sep 1996 04:54:57 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.7.3/8.7.3) with ESMTP id MAA12571; Fri, 6 Sep 1996 12:48:07 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id NAA18778; Fri, 6 Sep 1996 13:44:35 +0200 (METDST) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA11703; Fri, 6 Sep 96 13:45:55 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00882; Fri, 6 Sep 96 13:45:38 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <32300EE1.5E652F78@ln.cit.alcatel.fr> Date: Fri, 06 Sep 1996 13:45:37 +0200 From: FITZPATRICK John Organization: Alcatel Telecom, 22304 Lannion, France X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: Bob Ross Cc: ibis@vhdl.org, omera@trailblazer.sps.mot.com, rail@vhdl.org Subject: Re: Bird38 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, I agree that any specification enhancement should be simple and consistent. A very simplified version of bird 38, which would satisfy most needs would give an entries similar to the following: example a: [Over/undershoot] |Time Max_overshoot Max_undershoot 0 0.5 -0.5 example b: [Over/undershoot] |Time Max_overshoot Max_undershoot 20ns 2.0 -2.0 20.1ns 0.5 0.5 Example a) would cover the case where the dynamic and static overshoots and undershoots are the same as the dynamic values. Example b) shows much more realistic and useful values. The dynamic overshoot is 2.0V above Vcc. This is the value that might be transferred into a RAIL file. I'm not familiar enough with IBIS to understand what you mean by: - "existing conventions" (what is wrong with tables?) - "technologies" (simulator technology or semiconductor technology?) - "meaningful for all columns" Talk to you later, John Bob said: > My preference is that any enhancement be simple. While some of the > proposals involve tables, I suspect that the practical reality is > that (1) there is too much data for anyone to really specify, and > (2) very few vendors will consider processing that specific > enhancement. > Also, I favor consistency with the existing conventions > and structure rather than adding very specific, special > purpose,"warts". > By this, any extension needs to work with all of the technologies and > be meaningful for all of the columns. > -- John Fitzpatrick Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 From owner-ibis Fri Sep 6 07:09:49 1996 Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id HAA07046 for ; Fri, 6 Sep 1996 07:09:48 -0700 (PDT) Received: from mailgate.Cadence.COM by relay6.UU.NET with SMTP (peer crosschecked as: mailgate.Cadence.COM [158.140.2.1]) id QQbfzr15659; Fri, 6 Sep 1996 09:58:10 -0400 (EDT) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA07355; Fri, 6 Sep 1996 06:58:07 -0700 Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma842018282.007338; Fri Sep 6 06:58:02 1996 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id JAA17135; Fri, 6 Sep 1996 09:58:46 -0400 Date: Fri, 6 Sep 1996 09:58:46 -0400 From: "C. Kumar" Message-Id: <199609061358.JAA17135@hot> To: uunet!uunet!ichips.intel.com!speters@uunet.uu.net, uunet!qdt.com!jonp@uunet.uu.net Subject: Re: bird 37.1 Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net X-Sun-Charset: US-ASCII I will add a third issue to BIRD 37.1 3. Given the coupled line scheme in the bird, extracting circuits for simultaneous switching will be practically impossible. I think a more realizable goal is to be less ambitious and restrict large packages to "parmeterized" interconnects which is applicable to selected packages and may be even do first order modelling for a class of packages. By parameterized I mean to put specific limits on the number of sections and the type of circuit elements included in them. Also exclude coupling which in a simple scheme will add to confusion rather than to modelling benefit. Regards - Kumar From owner-ibis Fri Sep 6 08:02:44 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 IAA07483 for ; Fri, 6 Sep 1996 08:02:41 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 6 Sep 96 07:52 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 6 Sep 96 07:52 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 6 Sep 96 07:54 PDT Message-Id: Date: Fri, 6 Sep 96 07:54 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Forwarded: Re: EDIF Version 4 0 0 changes Date: Fri, 6 Sep 1996 12:23:55 +0100 From: Alan R Williams Message-Id: <199609061123.MAA05664@cheetah.cs.man.ac.uk> To: bob@icx.com Subject: Re: EDIF Version 4 0 0 changes > From bob@icx.com Fri Aug 30 18:49:19 1996 > Date: Fri, 30 Aug 96 10:01 PDT > From: bob@icx.com ( Bob Ross) > To: alanrw@cs.man.ac.uk > Subject: Re: EDIF Version 4 0 0 changes > Cc: bob@icx.com > > Alan: > > I reviewed your inclusion of the IBIS files within EDIF 4 0 0 > and am very satisfied with the thoroughness. Thanks for your response. EDIF Version 4 0 0 has now been sent off to the EIA. > My only coment is that "pcbIBISFileInformationNameCaseSesitive" > appears orphaned - there is no other reference. It is within a libraryHeader and/or edifHeader. Thanks again, Alan > Bob Ross > Interconnectix, Inc. > (EIA/IBIS Chair.) > -------- End of Forwarded Message From owner-ibis Fri Sep 6 10:59:15 1996 Received: from newsgw.mentorg.com (newsgw.mentorg.com [137.202.128.5]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA08834 for ; Fri, 6 Sep 1996 10:59:13 -0700 (PDT) Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.8.1/CF5.22R) id KAA02571; Fri, 6 Sep 1996 10:48:55 -0700 Received: from em-wv03.wv.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id KAA27894; Fri, 6 Sep 1996 10:48:54 -0700 Received: from kaui.MENTORG.COM by em-wv03.wv.mentorg.com (8.6.8.1/CF5.23H) id KAA27023; Fri, 6 Sep 1996 10:49:52 -0700 From: kim_owen@MENTORG.COM (Kim Owen) Received: by kaui.MENTORG.COM (SMI-8.6/CF3.4) id KAA01214; Fri, 6 Sep 1996 10:48:53 -0700 Date: Fri, 6 Sep 1996 10:48:53 -0700 Message-Id: <9609061048.ZM1212@kaui> To: ibis@vhdl.org Subject: IBIS Conference Call Hold Reminder X-Mailer: Z-Mail (3.2.1 10apr95) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii All, This is a friendly reminder to anyone attending the IBIS conference calls. Please do not go on "HOLD" as that can disrupt the conference with background music, etc. If you have to go on HOLD, please notify the group or disable the music feature. Regards, Kim Owen -- ------------------------------------------------------------------- Kim L. Owen, LMS Customer Support | Email: kim_owen@mentorg.com Mentor Graphics Corporation | Phone: 800-547-4303 8005 SW Boeckman Road | Fax: (503)685-1599 Wilsonville, OR 97070-7777 | SupportNet: 137.202.128.4 MGC SupportNet-Web http://supportnetweb.mentorg.com ------------------------------------------------------------------- From owner-ibis Tue Sep 10 12:27:08 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 MAA15082 for ; Tue, 10 Sep 1996 12:27:02 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 10 Sep 96 12:16 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 10 Sep 96 12:16 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 10 Sep 96 12:18 PDT Message-Id: Date: Tue, 10 Sep 96 12:18 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 9/6/96 DATE: September 10, 1996 SUBJECT: 9/6/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann*, Tim Minnick, Russ Moser, Ray Ziesse* Cadence Design C. Kumar* Contec CAE, Ltd. Dileep Divekar*, Norio Matsui, Antonis Orphanou Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier*, Ralf Bruening Intel Corporation Stephen Peters*, Will Hobbs, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, [Donald Telian], Jim Kruchowski Interconnectix, Inc. Bob Ross*, Chris Reid Meta-Software (Sanjay Gangal) Mitsubushi Tam Cao, Hoang Nguyen Motorola Ahmed Omer* National Semiconductor Syed Huq*, Donald Snyder, Chune-Sin Yeh, Bill Aronson NCR (formerly ATT-GIS) Dave Moxley, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell*, Chris Rokusek* Quantic Laboratories (Mike Ventham) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia Veribest Ian Dodd, David Wiens VLSI Technology Dick Ulmer, Sung Oh*, Swami Gangadharan, Daniel Kim, Tom Dockery, D.C. Sessions*, Hrish Patel* Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: Alcatel John Fitzpatrick* Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu* EIA Patti Rusher IC Works Eric Chen Mentor Graphics Kim Owen* Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella* North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Philips Semiconductor Mike Magdaluyo Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Symmetry Andy Hughes Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison VTC, Inc. Bob Ward Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Participants who have joined another organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 9/27/96 (916) 356-9200 3-54604 9558683 10/18/96 (916) 356-9200 3-54605 8249548 All meetings are 8:00 AM to 9:55 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 and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Ray Ziesse of AMP joined to get familiar with the committee. Eventually he will be taking over representation from Hank Herrmann. Kim Owen of Mentor Graphics is involved with model support and his main concern is model availability. EIA MEMBERSHIP AND TREASURER'S REPORT Bob Ross reported that Veribest joined per minutes correction below, and Quantic Laboratories is listed again as a member since the payment issue has been resolved. Bob received the July report which shows $9,285 after DAC expenses. The June report was $10,468. The August report is not yet available. MINUTES REPORT, MISC. No corrections were reported, but the following two corrections have been made to the July 19, 1996 minutes per e-mail communication: Ian Dodd reported that Veribest was changed to full voting member status because payment had been received. Patti Rusher corrected "EIA Server Corp" to "Electronic Industries Service Corporation" and stated she said she expected a draft proposal in two weeks instead of next week regarding DARPA funding. All AR's have been completed with the exception that Bob Ross has not issued BIRD35.2. MISCELLANY/ANNOUNCEMENTS None. PRESS UPDATES Syed Huq reported "SPICE and IBIS Modeling Kits The Basis for Signal Integrity Analysis" by Roland H.G. Cuny in the EMC: Silicon to Systems Symposium Record by the IEEE EMC Society, 1996. In Electronic Engineering Times, September 2, 1996, four articles mention IBIS: (1) "Part 3: Physical Design EDA TOOLS", Richard Goering, pg. 41. (2) "Workstation Board Pushes SI Envelope", Alex Pappas and Phil Treen, pg. 46. (3) "Signal-integrity Tools Deliver for MP Servers", Richard Mellitz and David Moxley, pg. 48. (4) "IBIS Standard Provides I/O Buffer Models", Bob Ross, Syed Huq, and Jon Powell, pg. 52. WEB PAGE UPDATES Jon Powell reported adding links from the official EIA/IBIS Home page to publicly available IBIS models. He requests people to report new sites and any out of date or better links. Jon updates the page weekly. (Not reported - the EIA site also links to the contacts.txt document which also gets updated regularly.) Bob Ross reported that Quality Semiconductor has IBIS Models on http://www.qualitysemi.com/devices.htm The Micron link was changed to the site reported at the last meeting, and the Model Request Form link appears inactive. Syed Huq looked into URL promotion on www.submit-it or www.postmaster of the EIA/IBIS website. Both locations support various search engines, but require a fee. Jon suggested to try Alta Vista or Yahoo which he thinks does not require a fee. The sense of the Committee is not to pay for registration. NEW MODELS Bob Ross reported that Motorola has some Fast SRAM models available via e-mail and Motorola also plans to put them on a Web page. OPENS FOR NEW ISSUES Hank Herrmann - AMP patent Bob Ross - EDIF 4 0 0 Bob Ross - Design SuperCon97 AMP PATENT Hank Herrmann alerted the EIA/IBIS Committee regarding a patent held by AMP: AMP holds a patent that relates to the current IBIS work on coupled multi-line connector models (BIRD36: Electrical Board Description). It covers the process of using a coupled multi-line connector model with a simulator in order to optimize the wiring configuration of the interconnection. Hank advises anyone interested to obtain a copy and review it. The patent specifics are as follows: Patent # 5,081,602 Title: Computer Simulator for Electrical Connectors Inventor: Douglas W. Glover Assignee: AMP Incorporated Hank adds that AMP Incorporated has not yet decided on their position regarding this patent. A position statement is owed to the IBIS Open Forum. If there are any questions regarding this patent, they should be directed to: Mr. Bruce Wolstoncroft The Whitaker Corporation Phone: (302) 633-2745 EIA/JAPAN - IBIS WORKING GROUP Jon Powell reported that EIAJ appears to be attempting to form a group for a new standard. They want one that includes SSO and coupled packaging effects. IEC EXPRESS FUNDING PROGRESS No report. IBIS Version 2.1 has been forwarded to IEC. EE TIMES ARTICLE As Bob Ross noted, above the Electrical Engineering Times article on IBIS has been published. The IBIS committee officers served as the co-authors on on behalf of the committee, but Bob wishes to thank C. Kumar, Stephen Peters and Patti Rusher for providing review and feedback. AR - Bob Ross seek permission (if necessary) and post to submitted draft text of the EE Times article on vhdl.org. EDIF 4 0 0 Bob Ross reported that Alan Williams of the University of Manchester provided the syntax for inclusion of IBIS models and for reporting passive R, L, C element values to simulators, per the official IBIS Committee technical comment. Bob concurred with the proposed syntax, and Alan Williams has forwarded EDIF 4 0 0 to EIA. DESIGN SUPERCON97 Bob Ross asked whether we should plan for a face-to-face meeting with Design SuperCon97 in San Jose at the end of January. Last year, it worked well to have the meeting on Monday prior to Design SuperCon96. The consensus was yes. Syed Huq indicated that National Semiconductor would be glad to host the meeting again. Other companies can also volunteer to host the meeting. Bob indicated that the IBIS Committee could probably assist in the funding. S2IBIS2 Per ibis-users reflector discussion, Syed Huq noted that s2ibis version 2.091 had a different syntax than s2ibis version 1.3, and he had some questions. He received a several public and private responses. Syed proposed compiling a list of workarounds. He feels more complete documentation is needed. Meanwhile, he is still relying on s2ibis Version 1.3 BIRD37.1 - ENHANCEMENT OT THE PACKAGE MODEL SPECIFICATION Bob Ross moved the BIRD37.1 discussion next since it was being considered for vote. Bob and Stephen Peters reaffirmed that it was a technical extension to the already approved BIRD28.3 to add Begin Fork and End Fork syntax for "stubs" in packages. Jon Powell cautioned that while he did not object to BIRD37.1, we should understand the technical limitations of this extension with respect to coupling. C. Kumar also felt that the single line extension was useful, but felt that the coupling mechanism did not support SSO effects because the matrices were not constructed to take this into consideration. Furthermore, the format may not support processing for SSO. Bob and others did not fully understand nor agree with the technical nature of this objection since detailed technical discussion is difficult during conference telephone meetings. Kumar also advocated a simpler and less ambitious goal consistent with "first order" modeling including limiting the number of stages. Hank Herrmann indicated that properly extracted global matrices can be processed, and algorithms exist to reduce them for single line processing. Hank also indicated that as a result of symmetrical matrix assumptions, analysis information was available for coupling. Technical discussions continued. Since we traditionally have accepted technical BIRDs by unanimous vote, we decided not to vote on BIRD37.1. Bob stated that there have been no publicly reported models that have coupled matrices (per IBIS Version 2.1), nor coupled matrix sections (per BIRD28.3). The committee recommended that BIRD37.2 be produced to remove reference to coupled matrix sections (while still containing the single coupled matrix for Version 2.1 compatibility). The single line extensions were viewed as important. Bob noted that the approval of such a modification to BIRD37.2 would supersede the matrix section extensions approved in BIRD28.3. AR - Stephen Peters provide BIRD37.2 which removes the matrix section portions of BIRD37.1 while still maintaining compatibility with Version 2.1. BIRD36 - ELECTRICAL BOARD DESCRIPTION Because of the relationship with BIRD37.1, Bob Ross moved the discussion of BIRD36 next. Stephen Peters questioned whether we were still bound by the matrix coupling mechanisms described in BIRD36 (which are identical to BIRD37.1). Without detailed discussions, the coupling mechanisms could be revisited. Gus Panella suggested that nodal syntax be considered. Bob indicated that this was a valid suggestion, but cut the discussion off since the topic has been extensively discussed, and it would consume valuable time to re-open the discussion here. Bob indicated that BIRD36 could also be applied to complicated, single packages, filling in for the functionality dropped in the future BIRD37.2. Bob also noted that the Committee really has three choices with respect to the coupling issue: (1) come to a consensus with respect to a coupled matrix extension, (2) do nothing with respect to coupling and let the simulator companies deal with coupling using their own, unique approaches, i.e., chose not to extend the Standard in this direction at this time, and (3) provide an alternative proposal which reaches consensus. Hank Herrmann inquired whether comments since June had been included. Stephen Peters noted that there was no general objection to the comments. Bob noted that since BIRD36.1 has not been issued, the comments have not formally been included. BIRD34.1 - STORED CHARGE EFFECT Bob Ross reaffirmed that the proposed TT mechanism was intended only to provide a first order method to mimic a known stored charge effect. An alternative is to provide a capacitance versus voltage table so that the format is in place for future effects as technology evolves. Bob felt this is too detailed for the intended application, would be too cumbersome to populate thereby rendering it as a virtually useless extension, and would be inconsistent with some simplifying assumptions already embedded within the IBIS model architecture regarding where a the series resistance is modeled. Dileep Divekar added that such a table would could be in error because of the conservation of charge issues related to how algorithms would be forced to process this information. Dileep noted that the proposed TT parameter allowed ways to process this information while preserving conservation of charge. D.C. Sessions inquired whether the TT parameter was intended just for the entire dynamic voltage range. Bob intended it to be used just for the clamping regions. Because BIRD34.1 has been out for quite a while with no formal objections nor counter proposals, we plan to vote on it at the next meeting. BIRD35.1 - MULTI-STAGED OUTPUTS Bob Ross just received Jon Powell's sample syntax and intends to produce BIRD35.2 to be consistent with the IBIS syntax and conventions and supportive of Jon's application. This may not be done by next meeting. AR - Bob Ross produce BIRD35.2. BIRD38 - ABSOLUTE MAXIMUM VOLTAGE AND EGG12 - SPECIFICATION ADDITIONS As time ran out Bob Ross followed up on Jon Powell's previous suggestion to set up a committee to handle all specification enhancement issues off-line. Members consist of John Fitzpatrick, Ahmed Omer, Jon Powell, and Bob. Anyone else can join. A telephone conference meeting was scheduled on Tuesday, September 24, 1996 at 8 A.M.. AR - Bob Ross set up telephone conference meeting and notify committee members of details. [Done] Date Bridge Number Reservation # Passcode 9/24/96 (916) 356-9200 3-54603 8565793 EGG10 - PARSER ADDITIONS FOR NUMERICAL CHECKING No discussion. NEXT MEETING: The next meeting is on Friday, September 27, 1996, 8:00 A.M. to 9:55 A.M. BIRD34.1 is scheduled for vote. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.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 e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Mon Sep 16 10:18:42 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 KAA27738; Mon, 16 Sep 1996 10:18:41 -0700 (PDT) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id KAA02632; Mon, 16 Sep 1996 10:08:17 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id KAA24722; Mon, 16 Sep 1996 10:08:14 -0700 (PDT) Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Mon, 16 Sep 96 10:08:14 PDT Date: Mon, 16 Sep 96 09:56:00 PDT From: John M Keifer Message-ID: To: John.Fitzpatrick@ln.cit.alcatel.fr_at_smtpgate@ccm.hf.intel.com, omera@trailblazer.sps.mot.com_at_smtpgate@ccm.hf.intel.com, IBIS@vhdl.org, RAIL@vhdl.org Subject: Re[2]: Bird38 Text item: Bob, An enhancement needs to be made to RAIL. I propose we simply add a width column to [Budgets] and a width parameter to [Clocks] that has a max of 6 characters. The WIDTH parameter would simply state the maximum time a signal could overshoot high or low at the already specified level. Would you like me to type up another ROAD? John Keifer John and Ahmed: We have all had a "vacation" from IBIS committee discussions and need to get restarted in our discussions. I do not have answers to your questions, but this will be subject for discussion at the Friday Meeting. Along with Egg12, Ahmed Omera also submitted a dynamic noise proposal a long while ago which also in in the Specification enhancement category. Jon Powell had proposed a Specification sub-committee to consider all proposals together, but we have not acted on this yet. My preference is that any enhancement be simple. While some of the proposals involve tables, I suspect that the practical reality is that (1) there is too much data for anyone to really specify, and (2) very few vendors will consider processing that specific enhancement. Also, I favor consistency with the existing conventions and structure rather than adding very specific, special purpose,"warts". By this, any extension needs to work with all of the technologies and be meaningful for all of the columns. Anyway, this is what we can consider on Friday. Bob Ross, Interconnectix, Inc. > To: ibis@vhdl.org > Subject: Bird38 > Hello all, > Since proposing bird 38, I have received little comment. As I was not > able to attend the last two meetings, this is probably my fault. > This bird is closely associated with egg12 i.e. it is a > specification addition. > Bird38 is basically a way to specify under- and overshoot limits. > A simplification of this bird would be to just give two numbers, > max_undershoot and max_overshoot. This is what a lot of simulators > do, and there is a place to stick these numbers into a RAIL file. > But in this case, over what time span is the over/undershoot allowed > to be present. I have read through the RAIL doc, but cannot find an > answer to this question. > What do people out there understand by over/undershoot limits, as > used in present simulators? > All feedback appreciated. > > Cheers, > John > > -- > John Fitzpatrick > Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France > Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 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***. Cc: rail@vhdl.org Subject: Re: Bird38 To: John.Fitzpatrick@ln.cit.alcatel.fr, ibis@vhdl.org, omera@trailblazer.sps.mot.com From: bob@icx.com ( Bob Ross) Date: Thu, 5 Sep 96 13:01 PDT Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 5 Sep 96 13:01 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 5 Sep 96 12:58 PDT Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 5 Sep 96 12:58 PDT 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 NAA11975; Thu, 5 Sep 1996 13:09:15 -0700 (PDT) Received: from vhdl.vhdl.org (VHDL.VHDL.ORG [198.31.14.3]) by mailbag.jf.intel.c om (8.7.4/8.7.3) with ESMTP id OAA04146; Thu, 5 Sep 1996 14:55:21 -0700 (PDT) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by fmmail.fm.intel.com (8.7.4/8.7.3) with ESMTP id OAA18904; Thu, 5 Sep 1996 14: 56:27 -0700 (PDT) Return-Path: owner-rail@vhdl.vhdl.org From owner-ibis Mon Sep 16 12:27:35 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 MAA28517; Mon, 16 Sep 1996 12:27:27 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 16 Sep 96 12:16 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 16 Sep 96 12:16 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 16 Sep 96 12:19 PDT Message-Id: Date: Mon, 16 Sep 96 12:19 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, rail@vhdl.org Subject: Forwarded: Re: Re[2]: Bird38 (Forgot to copy the various committees on this.) Bob Ross Inteconnectix, Inc. Date: Mon, 16 Sep 96 12:05 PDT From: bob@icx.com ( Bob Ross) To: John_M_Keifer@ccm.fm.intel.com Subject: Re: Re[2]: Bird38 Status: R John: Another Road would be appropriate. I not given any consideration with respect of overshoot proposals in IBIS and positioning within RAIL (e.g., RAIL would be the practical design override) of any given IBIS device specification if given (currently IBIS has nothing). The time duration would be an additional parameter which IBIS may consider. Anyway, a ROAD would be appropriate and also be useful for an IBIS "Specification" committee meeting on Sept 24. Bob > Date: Mon, 16 Sep 96 09:56:00 PDT > From: John M Keifer > Message-ID: > To: John.Fitzpatrick@ln.cit.alcatel.fr_at_smtpgate@ccm.hf.intel.com, > omera@trailblazer.sps.mot.com_at_smtpgate@ccm.hf.intel.com, > IBIS@vhdl.org, RAIL@vhdl.org > Subject: Re[2]: Bird38 > Status: R > Text item: > Bob, > An enhancement needs to be made to RAIL. I propose we simply add a width > column to [Budgets] and a width parameter to [Clocks] that has a max of 6 > characters. The WIDTH parameter would simply state the maximum time a signal > could overshoot high or low at the already specified level. Would you like me > to type up another ROAD? > John Keifer > John and Ahmed: > We have all had a "vacation" from IBIS committee discussions and > need to get restarted in our discussions. I do not have answers > to your questions, but this will be subject for discussion at the > Friday Meeting. Along with Egg12, Ahmed Omera also submitted > a dynamic noise proposal a long while ago which also in in the > Specification enhancement category. > Jon Powell had proposed a Specification sub-committee to consider > all proposals together, but we have not acted on this yet. > My preference is that any enhancement be simple. While some of the > proposals involve tables, I suspect that the practical reality is > that (1) there is too much data for anyone to really specify, and > (2) very few vendors will consider processing that specific > enhancement. Also, I favor consistency with the existing conventions > and structure rather than adding very specific, special purpose,"warts". > By this, any extension needs to work with all of the technologies and > be meaningful for all of the columns. > Anyway, this is what we can consider on Friday. > Bob Ross, > Interconnectix, Inc. > > To: ibis@vhdl.org > > Subject: Bird38 > > Hello all, > > Since proposing bird 38, I have received little comment. As I was not > > able to attend the last two meetings, this is probably my fault. > > This bird is closely associated with egg12 i.e. it is a > > specification addition. > > Bird38 is basically a way to specify under- and overshoot limits. > > A simplification of this bird would be to just give two numbers, > > max_undershoot and max_overshoot. This is what a lot of simulators > > do, and there is a place to stick these numbers into a RAIL file. > > But in this case, over what time span is the over/undershoot allowed > > to be present. I have read through the RAIL doc, but cannot find an > > answer to this question. > > What do people out there understand by over/undershoot limits, as > > used in present simulators? > > All feedback appreciated. > > > > Cheers, > > John > > > > -- > > John Fitzpatrick > > Alcatel CIT, 4 rue de Broglie, 22304 Lannion, France > > Tel: (+33)96.04.79.33 Fax: (+33)96.04.85.09 -------- End of Forwarded Message From owner-ibis Fri Sep 20 11:47:07 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 LAA03333 for ; Fri, 20 Sep 1996 11:47:00 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 20 Sep 96 11:36 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 20 Sep 96 11:36 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 20 Sep 96 11:38 PDT Message-Id: Date: Fri, 20 Sep 96 11:38 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA 9/27/96 IBIS Open Forum Meeting Agenda for 9/27/96 Bridge Number Reservation # Passcode (916) 356-9200 3-54604 9558683 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:20 Administrative and Project Discussions EIA/Japan - IBIS Working Group? Ross IEC Progress and Express Funding Progress Rusher New Administrative Issues All 8:35 Technical Discussion BIRD34.1 - STORED CHARGE EFFECT (Vote) Ross SPECIFICATION COMMITTEE REPORT Powell, All EGG10 - PARSER TESTS 1-5 Rokusek BIRD36 - ELECTRICAL BOARD DESCRIPTION Peters BIRD37.1 - ENHANCEMENT TO THE PACKAGE MODEL SPEC. Peters (BIRD37.2 PENDING) BIRD35.1 - MULTI-STAGED OUTPUTS Ross (BIRD35.2 PENDING) New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Fri Sep 20 12:27:38 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 MAA03576 for ; Fri, 20 Sep 1996 12:27:35 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 20 Sep 96 12:17 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 20 Sep 96 12:17 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 20 Sep 96 12:19 PDT Message-Id: Date: Fri, 20 Sep 96 12:19 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD34.1 for Voting To IBIS Members: BIRD34.1 is being sent out again since it is on the agenda for voting at the next IBIS Open Forum meeting. Bob Ross Interconnectix, Inc. Date: Fri, 22 Mar 96 08:25 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD34.1 Stored Charge Effects Status: R To IBIS Members: BIRD34.1 is submitted in partial response to the verbal comments in the March 8, 1996 meeting. The main comment was that the extraction section was not understandable. This is now illustrated. An alternative method is also illustrated in the ANALYSIS section. The writeup has been modified slightly. Changes are noted by "|*" lines. There are still fundamental concerns about the approach which need to be validated. The following text introduces BIRD34.1 as it did for BIRD34. Because of stored charge, a clamping diode will not release instanteously from the clamped mode as predicted by IBIS models. There will be a delay while the diode is turning off. This creates a glitch which itself can propogate up and down a line. This glitch is significant enough that IBIS needs to include a way to model it. The major contributor to the effect is the TT parameter which produces a non-linear transit time capacitance when a diode is conducting. The proposal here is to add effective parameters defined by [TTgnd] and [TTpower] keywords to the [Model] keyword description. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 34.1 ISSUE TITLE: Stored Charge Effects REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 3/5/96, 3/22/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The effect of transit time capacitances is not currently handled in the IBIS format, yet its effects are important for certain simulations. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords [TTgnd] and [TTpower] provide effective transit time parameters for modeling the ground clamp and the power clamp transit time capacitances independently. Approximation equations are included in the description. The additional keywords are described after the [Model] keyword as follows. |============================================================================== | Keywords: [TTgnd], [TTpower] | Required: No | Description: The data for these keywords enters the transist time parameters |* to estimate the transit time capacitances or develop transit |* time capacitance tables for the [Gnd Clamp] | and [Power Clamp] tables. | Usage Rules: For each of these keywords, the three columns hold the transit | values corresponding to the typical, minimum and maximum | [Gnd Clamp] or [Power Clamp] tables, respectively. The | entries for TT(typ), TT(min), and TT(max) must be placed on | a single line and must be separated by at least one white | space or tab or tab character. All three columns are | required under these keywords. However, data is required | only in the typical column. If minimum and/or maximum values | are not available, the reserved word "NA" must be used | indicating the TT(typ) value by default. | Other Notes: The transit time capacitance is added to C_comp. It is | in a Spice reference model as Ct = TT * d(Id)/d(Vd) where | d(Id)/d(Vd) defines the DC conductance at the incremental | DC operating point of the diode, and TT is the transit time. | This expression does not include any series resistance |* component. Such a component is assumed to be negligible in |* practice. Assume that the internal diode current (Id) - | voltage (Vd) relationship is Id = Is * (exp(q(Vd)/kT) - 1) | where Is is the saturation current, q is electron charge, k is | Boltzmann's constant, and T is temperature in degrees Kelvin. | Then d(Id)/d(Vd) is approximately (q/kT) * Id when the diode | is conducting, and zero otherwise. This yields the simplifi- | cation Ct = TT * (q/kT) * Id. The Id is found from the | [Gnd Clamp] and [Power Clamp] operating points, and the cor- | responding TTgnd or TTpower is used to calculate the Ct value. | If the [Temperature] keyword is not defined, then use the | default "typ" temperature for all Ct calculations. | | The effective TT parameter values are intended to APPROXIMATE | the effects. They may be different from the values found in | the Spice diode equations. Refer to the NOTES ON DATA | DERIVATION METHOD for extracting the effective values. |------------------------------------------------------------------------------ | variable TT(typ) TT(min) TT(max) [TTgnd] 10n 12n 9n [TTpower] 12n NA NA | |============================================================================== Add Section (4) to NOTES ON DATA DERIVATION METHOD: | 4) Transit Time Extractions: | The transit time parameter is indirectly derived to be the value that | produces the same effect as that extracted by the reference measurement | or reference simulation. | | The test circuit consists of the following: | a) A pulse source (10 ohms, 1 ns at full duration ramp) or equivalent |* and transitioning between Vcc and 0 V, | b) A 50 ohm, 1 ns long trace or transmission line, | c) A 500 ohm termination to the ground clamp reference voltage for TTgnd | extraction and to the power clamp reference voltage for TTpower | extraction (to provide a convenient, minimum loading 450 ohm - | 50 ohm divider for high-speed sampling equipment observation | of the device under test), and |* d) The device under test (DUT). | |* DUT with [Gnd Clamp] |* ____________ | /| |* o---/\/\/\--O____________)---o--|< |--o GND |* 10 ohms Z0 = 1 nS | | \| | |* TD = 50 ohms | | |* |-/\/\/\-| |* | 500 ohm Load for Probing |* Vcc ---\ ------\ | |* \ \ o /--\ |* 0 V \------ \ / \------- |* | | \---------/ |* 1 nS |<----------->| |* 1 nS, 10 ohm Choose TTgnd that matches the measured |* Source Signal delay with the IBIS model simulation delay |* |* Example of TTgnd Extraction Setup |* | The TTgnd extraction will be done only if a [Gnd Clamp] table exists. | A high to low transition that produces a positive "glitch", perhaps | several nanoseconds later indicates a stored charge in the ground | clamp circuit. The test circuit is simulated using the complete | IBIS model with C_comp and the Ct model defined under the [TTgnd] and | [TTpower] keywords. An effective TTgnd value that produces a "glitch" | with the same delay is extracted. | | Similarily, the TTpower extraction will be done only if a [Power Clamp] | table exists. A low to high transition that produces a negative | "glitch", perhaps several nanoseconds later indicates a stored charge | in the power clamp circuit. An effective TTpower value that produces a | glitch with the same delay is extracted. | | It is preferred to do the extractions with the package parameters | removed. However, if the extraction is done from measurements, then | the package model should be included in the IBIS based simulation. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Refer to Spice diode reference information concerning the complete equations. The emission coefficient (N) is assumed to be 1. For measured values or cases where N is not 1, use the effective TT values. So the TT values may not be the exact values used in a Spice model. The Spice diode and transistor models differs slightly from the IBIS Clamp models. The definition and position of the capacitances is different. Furthermore, the IBIS table combines the diode and resistor, but can support more complex non-linear characteristics. Intrinsic RS Diode +-----+ |\ | ----> Id | | ----> Id o---/\/\/\--+--| >|--+----o +-----|Clamp|-----+ | |/ | | | | | | | | o----| +-----+ |----o | | | | | | | | +---| |--+ +-------| |-------+ | | | | Cj + Ct C_comp + Ct Fixed values of C_comp serve to estimate voltage dependent non-linear junction capacitance plus other metalization effects. Note, while shown here across the diode, the C_comp and Ct term would be lumped as capacitances between the terminal and ground to provide an equivalent AC circuit. Methods to connect capacitance contributions to each of the voltage rails are not available in the IBIS model. Note, this example illustrates one diode. It can be connected to the ground reference voltage (usually ground) or to the power reference voltage (usually Vcc) serving as either a [Gnd Clamp] or a [Power Clamp]. In practice, both clamps can exist and C_comp would contain the effects of both diodes and metalization. The Ct value is a function of absolute temperature. As an approximation, the default typical temperature is sufficient if [Temperature] is not specified. It is recommended to include the [Temperature] keyword when TT is specified to remove ambiguity regarding minimum and maximum transit time calculations for CMOS versus Bipolar technologies. An underlying assumption is that the equations will be applied only to the Clamping data, not the combined data that includes [Pulldown] and [Pullup] data. So when this detail is needed for Output models, the clamping data needs to be derived, if not provided. Because of these differences and possible missing details, the simplified equation and approximation approach is justified to capture the dominant behavioral effects. So the TT values may be the effective values that are consistent with the IBIS model and data. There are several formatting choices to describe transit time: (1) A [Model] subparameter similar to Vinl and Vinh, e.g., TTgnd = 12n TTpower = 10n This was not chosen because minimum and maximum process Spice models may have different values. (2) A [Model] subparameter similar to C_comp, e.g., TTgnd 10n 12n 9n TTpower 12n NA NA This was not chosen because the rules for minimum and maximum columns for C_comp are based on magnitude, whereas the rules for TT are based on process extremes. This may be confusing if they are similarly formatted. However, this is the second choice since TTgnd, TTpower and C_comp all relate to capacitances. (3) A [Gnd Clamp] and [Power Clamp] subparameter similar to C_comp, e.g [Gnd Clamp] TT 10n 12n 9n This was not chosen because it can cause unnecessary [Gnd Clamp] and [Power Clamp] table complexity and it can make the TT parameters hard to locate. (4) A [Model] keyword modifier similar to [Temperature] and other keywords which are a function of typical, minimum and maximum process and measurement conditions. e.g., [TTgnd] 10n 12n 9n [TTpower] 12n NA NA Since these keywords are related to the [Gnd Clamp] and [Power Clamp] tables and to the conditions under which they were derived, this format was chosen. BIRD34 also includes in its description a proposed extraction method. The method is based on using the typical input signal transitions. It is also designed so that it can be done under actual measurement conditions since the "real" effect may not be accurately modeled in Spice. An alternative which does not closely reflect actual conditions would be to measure the delay forward biased (perhaps by one volt) clamp diode takes to turn off when the bias voltage is removed or reverse biased. This approach has not been fully simulated. However, it is expected to be very sensitive to the selected bias voltages and not necessarily mimic actual operating conditions. DUT with [Gnd Clamp] 50 ohms | /| Pulse Source o---/\/\/\----o--|< |--o GND -2 V to Vcc | | \| | | | |-/\/\/\-| | 50 ohm Probe Load Vcc/2 /----- /------- / / Without DUT -> / / <- With DUT ___/------/ -1 V | | Choose TTgnd such that measured delay equals IBIS model simulation delay Example of TTgnd Extraction ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: BIRD34 expands EGG9 and adds more detail on modifying IBIS. It also expands on the mathematical basis as requested by Kellee Crisafulli. It also adds some comments based on EGG9 response from Stephen Peters and others on the positioning of C_comp in the ANALYSIS PATH section. ****************************************************************************** From owner-ibis Fri Sep 20 13:39:54 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 NAA04003 for ; Fri, 20 Sep 1996 13:39:53 -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 NAA09228 for ; Fri, 20 Sep 1996 13:29:27 -0700 (PDT) Received: from pdx819.intel.com by ichips.intel.com (8.7.4/jIII) id NAA00067; Fri, 20 Sep 1996 13:29:14 -0700 (PDT) Received: by pdx819.intel.com (4.1/SW1.11) id AA26557; Fri, 20 Sep 96 13:29:27 PDT Message-Id: <9609202029.AA26557@pdx819.intel.com> Subject: IBIS BIRD34.1 To: ibis@vhdl.org Date: Fri, 20 Sep 1996 13:29:27 -0700 (PDT) From: "David Fogel" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bob, Please correct the impedance and delay numbers in the lines below. They are switched around. David Fogel * ____________ | /| |* o---/\/\/\--O____________)---o--|< |--o GND |* 10 ohms Z0 = 1 nS | | \| | |* TD = 50 ohms | | |* |-/\/\/\-| From owner-ibis Fri Sep 20 14:17:08 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 OAA04287 for ; Fri, 20 Sep 1996 14:17:08 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 20 Sep 96 14:04 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 20 Sep 96 14:04 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 20 Sep 96 14:06 PDT Message-Id: Date: Fri, 20 Sep 96 14:06 PDT From: bob@icx.com ( Bob Ross) To: dfogelx@ichips.intel.com, ibis@vhdl.org Subject: Re: IBIS BIRD34.1 David: Thank you. You can assume that your correction and any others that are discovered will be folded into the final version of BIRD34. Bob Ross Interconnectix, Inc. > Subject: IBIS BIRD34.1 > To: ibis@vhdl.org > Date: Fri, 20 Sep 1996 13:29:27 -0700 (PDT) > From: "David Fogel" > Bob, > Please correct the impedance and delay numbers in the lines below. > They are switched around. > David Fogel > * ____________ | /| > |* o---/\/\/\--O____________)---o--|< |--o GND > |* 10 ohms Z0 = 1 nS | | \| | > |* TD = 50 ohms | | > |* |-/\/\/\-| From owner-ibis Mon Sep 23 08:45: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 IAA09456 for ; Mon, 23 Sep 1996 08:45: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 IAA21338 for ; Mon, 23 Sep 1996 08:34:43 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA05319; Mon, 23 Sep 1996 08:34:06 -0700 (PDT) Message-Id: <199609231534.IAA05319@ichips.intel.com> To: ibis@vhdl.org Subject: Bird 37.2 Date: Mon, 23 Sep 1996 08:34:44 -0700 From: Stephen Peters Hello All: As promised, here is the revised Bird 37, dealing with the enhanced package model. As discussed at the last meeting, Bird 37 has been revised to drop the Matrix subparameter that was introduced by Bird 28. My hope is that once the forum can agree on a matrix format that it can be included in a later upgrade of the package description. Regards, Stephen ============================================================================= Buffer Issue Resolution Document (BIRD) BIRD ID#: 37.2 ISSUE TITLE: Enhancement To The Package Model (.pak file) Specification REQUESTER: Stephen Peters DATE SUBMITTED: Sept 23, 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'. This bird also eliminates the Matrix description format (as introduced by Bird28.3) from the package description. ****************************************************************************** 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, 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. | 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 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. However, 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 examples added by Bird 28.3 are replaced by the following | |A three section package stub description that includes a bond wire |(lumped inductance), a trace (treated as a transmission line with DC |resistance), and a pin modeled as a lumped L/C element. | [Pin Number] A1 Len=0 L=1.2n/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0/ | |Pin A2 below has an section with no data | A2 Len=0 L=1.2/ Len=0/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0/ | |A section description using the Fork and Endfork subparameters. Note |that the indentation of the Fork and Endfork 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 |4. The [Model Data] and [End Model Data] keywords revert back to | there former (pre bird 28.3) definitions. ****************************************************************************** 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. REVISIONS FOR 37.2 Until the forum can agree on a method to describe coupling, the 'Matrix' subparameter has been removed from the package description. Hopefully, it will be reintroduced when a common matrix description format had been agreed upon. From owner-ibis Tue Sep 24 15:46:18 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 PAA05657 for ; Tue, 24 Sep 1996 15:46:17 -0700 (PDT) Received: from uucp2.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQbipm00253; Tue, 24 Sep 1996 18:35:50 -0400 (EDT) Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Tue, 24 Sep 1996 18:35:50 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01643; Tue, 24 Sep 96 15:26:10 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA03059; Tue, 24 Sep 96 15:26:10 PDT Sender: jonp@qdt.com Message-Id: <32486001.102F11D5@qdt.com> Date: Tue, 24 Sep 1996 15:26:09 -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: Pulse Width Table Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is for people who wish to be up on the "input parameters" subcommittee. I have been looking at the pulse width graphs that Ahmed Omer sent around and I have the following question. Very seldom are the waveshapes that get to the receiver square pulses. They usually look more like sine waves and as such it is hard to guess how to interpret this table. It seems like you almost need more of a total energy limit (the area of the non-square pulse). comments? jon From owner-ibis Thu Sep 26 11:15:43 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 LAA26771 for ; Thu, 26 Sep 1996 11:15:42 -0700 (PDT) Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbiwe09634; Thu, 26 Sep 1996 14:05:11 -0400 (EDT) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 26 Sep 1996 14:05:12 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00928; Thu, 26 Sep 96 11:00:17 PDT Received: from awacs.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA18051; Thu, 26 Sep 96 11:00:16 PDT Date: Thu, 26 Sep 96 11:00:16 PDT Message-Id: <9609261800.AA18051@hal.qdt.com> Received: by awacs.qdt.com (4.1/SMI-4.1) id AA01220; Thu, 26 Sep 96 11:00:09 PDT From: Chris Rokusek To: ibis@vhdl.org Subject: EGG 10 Parameters. Hi All, As you may recall, here are the original enhancement checks proposed in EGG 10. 1) Current direction reversed over 50% of points in table. 2) Waveform "DC" points do not match VI curve for specified load. 3) Extreme currents in VI curve. (Generally found shunt curves) 4) Very few transition points in VI curve. 5) Ridiculous values for some parameters. Comments on 1: Appears to already be handled sufficiently. No need for change. Comments on 2: Involves combining VI curves and interpolation which results in programming costs and debugging and testing and qa'ing etc.... I have alreadly developed most of the subroutines necc. to implement this here at Quad into our translator and also have a good set of files to test it on. I feel the most efficient way to implement this is for me to do it here, test it, propose the alogorithm used, and upon acceptance by the ibis committee, "donate" the code to the ibis forum. Since this improves overall quality of the ibis models Quad Design has no objections to this. Drawbacks to this are that I MAY not be able to tackle this for a few months. Another way to handle this if there is immediate interest is to hash out exactly what it needs to do and hand it off to programmers. Additionally, the test should also check that a driver is able to drive through the Vref Rref parms specified for the "time to "measurement" voltage. Comments on 3: Shunt Currents Exceeding 10.0Amps @ -1.5 Volts This appears to be a good voltage to check since the shunt will be on very strong at 1.5Volts. Interpolation is neccessary to get this value. Example message... WARNING (line 45) - Extreme shunt currents present in GND_Clamp. Comments on 4: This one received quite a bit of resistance and would be trickier and more time consuming to implement properly and handle all cases (esp raw lab data). I would like to axe this proposed test for the time being. * As a side note, it sounds to me that ibis model developers using raw lab data to generate the VI curves are in need of utility program that post-processes the data to smooth out any "jitter" data so it is both monotonic and linearized. By linearized I mean that there contains JUST ENOUGH points to get the shape of the curve w/o providing "redundant" points. The linearization part of the utility could also be applied to post process simulation data in order to reduce the size of VI tables within .ibs files w/o a loss of accuracy. Comments on 5: From the tables included below, I propose the following values as top end limits for these parameters. This is easy to implement and could be handed off to programmers immediately upon approval. C_comp 50 pF Pin C 50 pF Pin L 50 nH Pin R 5 Ohms Ramp Times 10 nSec Example Message... WARNING (line 43) - Excessive capacitance value for C_comp. * The data used to determine these values concludes this mail. This issue is on the agenda for the meeting tomorrow morning. Regards, -Chris Rokusek Quad Design DATA used to come up with values for #5: SHUNT CURRENT at V = -0.50 (GND CLAMP) PERCENT (of 307) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.0019 |********** 0.0039 |********* 0.0058 |** 0.0078 |* 0.0097 |* 0.0116 |* 0.0136 |* 0.0155 |* 0.0175 |* 0.0194 |* 0.0214 |* 0.0233 |* 0.0252 |* 0.0272 |* 0.0291 |* 0.0311 |* 0.0330 |* 0.0349 |* 0.0369 |* 0.0388 |* 0.0408 |* 0.0427 |* 0.0446 |* 0.0466 |* 0.0485 |* 0.0505 |* 0.0524 |* 0.0544 |* 0.0563 |* 0.0582 |* 0.0602 |* 0.0621 |* 0.0641 |* 0.0660 |* 0.0679 |* 0.0699 |* 0.0718 |* 0.0738 |* 0.0757 |* SHUNT CURRENT at V = -0.50 (POWER CLAMP) PERCENT (of 303) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.0259 |* 0.0517 |* 0.0776 |* 0.1034 |* 0.1293 |* 0.1551 |* 0.1810 |* 0.2068 |* 0.2327 |* 0.2586 |* 0.2844 |* 0.3103 |* 0.3361 |* 0.3620 |* 0.3878 |* 0.4137 |* 0.4396 |* 0.4654 |* 0.4913 |* 0.5171 |* 0.5430 |* 0.5688 |* 0.5947 |* 0.6205 |* 0.6464 |* 0.6723 |* 0.6981 |* 0.7240 |* 0.7498 |* 0.7757 |* 0.8015 |* 0.8274 |* 0.8532 |* 0.8791 |* 0.9050 |* 0.9308 |* 0.9567 |* 0.9825 |* 1.0084 |* SHUNT CURRENT at V = -1.00 (GND CLAMP) PERCENT (of 307) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.7575 |*** 1.5150 |** 2.2725 |** 3.0300 |** 3.7875 |** 4.5450 |* 5.3025 |* 6.0600 |* 6.8175 |* 7.5750 |* 8.3325 |* 9.0900 |* 9.8475 |* 10.6050 |* 11.3625 |* 12.1200 |* 12.8775 |* 13.6350 |* 14.3925 |* 15.1500 |* 15.9075 |* 16.6650 |* 17.4225 |* 18.1800 |* 18.9375 |* 19.6950 |* 20.4525 |* 21.2100 |* 21.9675 |* 22.7250 |* 23.4825 |* 24.2400 |* 24.9975 |* 25.7550 |* 26.5125 |* 27.2700 |* 28.0275 |* 28.7850 |* 29.5425 |* SHUNT CURRENT at V = -1.00 (POWER CLAMP) PERCENT (of 303) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.2109 |************ 0.4218 |******* 0.6327 |***** 0.8436 |** 1.0544 |* 1.2653 |* 1.4762 |* 1.6871 |* 1.8980 |* 2.1089 |* 2.3198 |* 2.5307 |* 2.7415 |* 2.9524 |* 3.1633 |* 3.3742 |* 3.5851 |* 3.7960 |* 4.0069 |* 4.2178 |* 4.4286 |* 4.6395 |* 4.8504 |* 5.0613 |* 5.2722 |* 5.4831 |* 5.6940 |* 5.9049 |* 6.1158 |* 6.3266 |* 6.5375 |* 6.7484 |* 6.9593 |* 7.1702 |* 7.3811 |* 7.5920 |* 7.8029 |* 8.0137 |* 8.2246 |* SHUNT CURRENT at V = -1.50 (GND CLAMP) PERCENT (of 307) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.7575 |************* 1.5150 |******** 2.2725 |*** 3.0300 |** 3.7875 |** 4.5450 |** 5.3025 |** 6.0600 |** 6.8175 |** 7.5750 |** 8.3325 |** 9.0900 |** 9.8475 |** 10.6050 |** 11.3625 |** 12.1200 |** 12.8775 |** 13.6350 |* 14.3925 |* 15.1500 |* 15.9075 |* 16.6650 |* 17.4225 |* 18.1800 |* 18.9375 |* 19.6950 |* 20.4525 |* 21.2100 |* 21.9675 |* 22.7250 |* 23.4825 |* 24.2400 |* 24.9975 |* 25.7550 |* 26.5125 |* 27.2700 |* 28.0275 |* 28.7850 |* 29.5425 |* SHUNT CURRENT at V = -1.50 (POWER CLAMP) PERCENT (of 303) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.7575 |*********** 1.5150 |******* 2.2725 |** 3.0300 |* 3.7875 |* 4.5450 |* 5.3025 |* 6.0600 |* 6.8175 |* 7.5750 |* 8.3325 |* 9.0900 |* 9.8475 |* 10.6050 |* 11.3625 |* 12.1200 |* 12.8775 |* 13.6350 |* 14.3925 |* 15.1500 |* 15.9075 |* 16.6650 |* 17.4225 |* 18.1800 |* 18.9375 |* 19.6950 |* 20.4525 |* 21.2100 |* 21.9675 |* 22.7250 |* 23.4825 |* 24.2400 |* 24.9975 |* 25.7550 |* 26.5125 |* 27.2700 |* 28.0275 |* 28.7850 |* 29.5425 |* SHUNT CURRENT at V = -2.00 (GND CLAMP) PERCENT (of 307) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.7575 |********************* 1.5150 |*********** 2.2725 |******** 3.0300 |**** 3.7875 |*** 4.5450 |** 5.3025 |** 6.0600 |** 6.8175 |** 7.5750 |** 8.3325 |** 9.0900 |** 9.8475 |** 10.6050 |** 11.3625 |** 12.1200 |** 12.8775 |** 13.6350 |** 14.3925 |** 15.1500 |** 15.9075 |** 16.6650 |** 17.4225 |** 18.1800 |** 18.9375 |** 19.6950 |** 20.4525 |** 21.2100 |** 21.9675 |** 22.7250 |* 23.4825 |* 24.2400 |* 24.9975 |* 25.7550 |* 26.5125 |* 27.2700 |* 28.0275 |* 28.7850 |* 29.5425 |* SHUNT CURRENT at V = -2.00 (POWER CLAMP) PERCENT (of 303) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.7575 |************ 1.5150 |*********** 2.2725 |******* 3.0300 |***** 3.7875 |** 4.5450 |* 5.3025 |* 6.0600 |* 6.8175 |* 7.5750 |* 8.3325 |* 9.0900 |* 9.8475 |* 10.6050 |* 11.3625 |* 12.1200 |* 12.8775 |* 13.6350 |* 14.3925 |* 15.1500 |* 15.9075 |* 16.6650 |* 17.4225 |* 18.1800 |* 18.9375 |* 19.6950 |* 20.4525 |* 21.2100 |* 21.9675 |* 22.7250 |* 23.4825 |* 24.2400 |* 24.9975 |* 25.7550 |* 26.5125 |* 27.2700 |* 28.0275 |* 28.7850 |* 29.5425 |* SHUNT CURRENT at V = -2.50 (GND CLAMP) PERCENT (of 307) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.7575 |*********************** 1.5150 |************* 2.2725 |*********** 3.0300 |******** 3.7875 |***** 4.5450 |**** 5.3025 |*** 6.0600 |*** 6.8175 |** 7.5750 |** 8.3325 |** 9.0900 |** 9.8475 |** 10.6050 |** 11.3625 |** 12.1200 |** 12.8775 |** 13.6350 |** 14.3925 |** 15.1500 |** 15.9075 |** 16.6650 |** 17.4225 |** 18.1800 |** 18.9375 |** 19.6950 |** 20.4525 |** 21.2100 |** 21.9675 |** 22.7250 |** 23.4825 |** 24.2400 |** 24.9975 |** 25.7550 |** 26.5125 |** 27.2700 |** 28.0275 |** 28.7850 |** 29.5425 |** SHUNT CURRENT at V = -2.50 (POWER CLAMP) PERCENT (of 303) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 I(Amps)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.7575 |************ 1.5150 |*********** 2.2725 |******* 3.0300 |******* 3.7875 |******* 4.5450 |**** 5.3025 |* 6.0600 |* 6.8175 |* 7.5750 |* 8.3325 |* 9.0900 |* 9.8475 |* 10.6050 |* 11.3625 |* 12.1200 |* 12.8775 |* 13.6350 |* 14.3925 |* 15.1500 |* 15.9075 |* 16.6650 |* 17.4225 |* 18.1800 |* 18.9375 |* 19.6950 |* 20.4525 |* 21.2100 |* 21.9675 |* 22.7250 |* 23.4825 |* 24.2400 |* 24.9975 |* 25.7550 |* 26.5125 |* 27.2700 |* 28.0275 |* 28.7850 |* 29.5425 |* C_comp Values PERCENT (of 488) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 C(pF)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.4318 |*********************************************** 0.8636 |***************************** 1.2953 |************************ 1.7271 |************************ 2.1589 |*********************** 2.5907 |*********************** 3.0224 |********************* 3.4542 |******************* 3.8860 |**************** 4.3177 |************ 4.7495 |*********** 5.1813 |******** 5.6131 |******** 6.0448 |**** 6.4766 |**** 6.9084 |**** 7.3402 |** 7.7720 |* 8.2037 |* 8.6355 |* 9.0673 |* 9.4991 |* 9.9308 |* 10.3626 |* 10.7944 |* 11.2262 |* 11.6579 |* 12.0897 |* 12.5215 |* 12.9532 |* 13.3850 |* 13.8168 |* 14.2486 |* 14.6804 |* 15.1121 |* 15.5439 |* 15.9757 |* 16.4074 |* 16.8392 |* PIN C Values PERCENT (of 1684) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 C(pF)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 2.5250 |************ 5.0500 |** 7.5750 |* 10.1000 |* 12.6250 |* 15.1500 |* 17.6750 |* 20.2000 |* 22.7250 |* 25.2500 |* 27.7750 |* 30.3000 |* 32.8250 |* 35.3500 |* 37.8750 |* 40.4000 |* 42.9250 |* 45.4500 |* 47.9750 |* 50.5000 |* 53.0250 |* 55.5500 |* 58.0750 |* 60.6000 |* 63.1250 |* 65.6500 |* 68.1750 |* 70.7000 |* 73.2250 |* 75.7500 |* 78.2750 |* 80.8000 |* 83.3250 |* 85.8500 |* 88.3750 |* 90.9000 |* 93.4250 |* 95.9500 |* 98.4750 |* PIN L Values PERCENT (of 1684) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 L(nH)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 2.5250 |****************************************** 5.0500 |*************************** 7.5750 |******************** 10.1000 |***************** 12.6250 |******* 15.1500 |* 17.6750 |* 20.2000 |* 22.7250 |* 25.2500 |* 27.7750 |* 30.3000 |* 32.8250 |* 35.3500 |* 37.8750 |* 40.4000 |* 42.9250 |* 45.4500 |* 47.9750 |* 50.5000 |* 53.0250 |* 55.5500 |* 58.0750 |* 60.6000 |* 63.1250 |* 65.6500 |* 68.1750 |* 70.7000 |* 73.2250 |* 75.7500 |* 78.2750 |* 80.8000 |* 83.3250 |* 85.8500 |* 88.3750 |* 90.9000 |* 93.4250 |* 95.9500 |* 98.4750 |* PIN R Values PERCENT (of 1684) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 R(Ohms)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.0992 |************************* 0.1985 |***** 0.2977 |**** 0.3969 |**** 0.4962 |**** 0.5954 |**** 0.6946 |**** 0.7939 |**** 0.8931 |** 0.9923 |** 1.0916 |** 1.1908 |** 1.2900 |* 1.3893 |* 1.4885 |* 1.5877 |* 1.6870 |* 1.7862 |* 1.8854 |* 1.9847 |* 2.0839 |* 2.1831 |* 2.2823 |* 2.3816 |* 2.4808 |* 2.5800 |* 2.6793 |* 2.7785 |* 2.8777 |* 2.9770 |* 3.0762 |* 3.1754 |* 3.2747 |* 3.3739 |* 3.4731 |* 3.5724 |* 3.6716 |* 3.7708 |* 3.8701 |* Ramp Times PERCENT (of 2184) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 t(ns)|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.1174 |*********************************************** 0.2348 |****************************************** 0.3522 |************************************* 0.4697 |********************************** 0.5871 |******************************** 0.7045 |************************** 0.8219 |****************** 0.9393 |************* 1.0567 |********** 1.1741 |********* 1.2915 |****** 1.4090 |**** 1.5264 |*** 1.6438 |** 1.7612 |** 1.8786 |* 1.9960 |* 2.1134 |* 2.2308 |* 2.3483 |* 2.4657 |* 2.5831 |* 2.7005 |* 2.8179 |* 2.9353 |* 3.0527 |* 3.1701 |* 3.2876 |* 3.4050 |* 3.5224 |* 3.6398 |* 3.7572 |* 3.8746 |* 3.9920 |* 4.1094 |* 4.2269 |* 4.3443 |* 4.4617 |* 4.5791 |* Ramp Volts PERCENT (of 2184) EXCEEDING -> 0 10 20 30 40 50 60 70 80 90 100 Volts|----|----|----|----|----|----|----|----|----|----| 0.0000 |************************************************** 0.1161 |*********************************************** 0.2323 |*********************************************** 0.3485 |*********************************************** 0.4646 |*********************************************** 0.5807 |*********************************************** 0.6969 |********************************************** 0.8130 |********************************************** 0.9292 |********************************************* 1.0453 |******************************************** 1.1615 |******************************************* 1.2776 |**************************************** 1.3938 |************************************ 1.5100 |********************************** 1.6261 |***************************** 1.7422 |*************************** 1.8584 |*********************** 1.9746 |******************** 2.0907 |******************* 2.2069 |***************** 2.3230 |*************** 2.4392 |************* 2.5553 |********* 2.6714 |******** 2.7876 |**** 2.9037 |**** 3.0199 |*** 3.1360 |* 3.2522 |* 3.3684 |* 3.4845 |* 3.6007 |* 3.7168 |* 3.8329 |* 3.9491 |* 4.0652 |* 4.1814 |* 4.2976 |* 4.4137 |* 4.5299 |* From owner-ibis Fri Sep 27 13:22: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 NAA26207 for ; Fri, 27 Sep 1996 13:22:17 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id NAA28231 for ; Fri, 27 Sep 1996 13:11:46 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id NAA09624; Fri, 27 Sep 1996 13:10:34 -0700 (PDT) Message-Id: <199609272010.NAA09624@ichips.intel.com> To: ibis@vhdl.org Subject: IBIS packaging sub committee Date: Fri, 27 Sep 1996 13:11:47 -0700 From: Stephen Peters Hello all: As per the suggestion in this mornings IBIS open forum phone discussion, it's time to reactive the IBIS packaging subcommitte. I've reserved a phone bridge as follows: Date: Thursday, Oct. 3 Time: 8:30 to 10:00 Bridge Number: (916) 356-9200 Reservation #: 4-24806 Passcode: 8497337 The purpose of the subcommittee is to finish what we started in the way of formulating a Bird or Birds that covers electrical board descriptions, connectors, and coupling. Committe members (from last time) are Stephen Peters, Bob Ross, Jon Powell, Kumar, Olaf Rethmeier, and Hank Herman. Others with an interest are more than welcome to join in. Regards, Stephen Peters From owner-ibis Fri Sep 27 14:37:40 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 OAA26911 for ; Fri, 27 Sep 1996 14:37:39 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id OAA11545 for ; Fri, 27 Sep 1996 14:27:04 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id OAA15415; Fri, 27 Sep 1996 14:25:52 -0700 (PDT) Message-Id: <199609272125.OAA15415@ichips.intel.com> To: ibis@vhdl.org Subject: Packaging Subcommittee Date: Fri, 27 Sep 1996 14:27:05 -0700 From: Stephen Peters Hello All: A couple of participants cannot make the Thursday morning phone conference as planned, and I have been requested to move it. I've blocked out a couple of time -- Indicate your preference below. Sorry for the change in plans.... Regards, Stephen Time Can be there? ----- ------------- Wednesday 10/2 8:30 - 10:00 ------ Friday 10/4 8:30 - 10:00 ------ From owner-ibis Mon Sep 30 12:47:37 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 MAA16819 for ; Mon, 30 Sep 1996 12:47:36 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id MAA26731 for ; Mon, 30 Sep 1996 12:37:00 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id MAA19628; Mon, 30 Sep 1996 12:35:23 -0700 (PDT) Message-Id: <199609301935.MAA19628@ichips.intel.com> To: ibis@vhdl.org Subject: IBIS packaging committee -- new day Date: Mon, 30 Sep 1996 12:37:02 -0700 From: Stephen Peters Hello All: Based on the feedback I've received so far, Friday seems to be the best time to meet. I've changed the phone bridge reservaton to Friday 10/4, with the reservation #, passcode and time the same as before. To reiterate: Meeting Day : Friday, 10/4 Meeting Time : 08:30 to 9:55, PDT Dial In Number : (916) 356-9200 Resv. No. : 4-24806 Passcode : 8497337 Thanks, and I'll talk to you all on Friday Stephen From owner-ibis Mon Sep 30 16:55:21 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 QAA18937 for ; Mon, 30 Sep 1996 16:55:14 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 30 Sep 96 16:44 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 30 Sep 96 16:44 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 30 Sep 96 16:46 PDT Message-Id: Date: Mon, 30 Sep 96 16:46 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD34.2 To IBIS Members: BIRD34.2 contains a few editorial changes designated by "|**" lines in reponse to a written comment and to comments made during the September 27, 1996 meeting during which it was approved. The /pub/ibis/wip/ver3_0c.ibs has BIRD34.2 rolled in along with other approved BIRDs for a moving draft of Version 3.0 of IBIS. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 34.2 ISSUE TITLE: Stored Charge Effects REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 3/5/96, 3/22/96, 9/27/96 DATE ACCEPTED BY IBIS OPEN FORUM: September 27, 1996 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The effect of transit time capacitances is not currently handled in the IBIS format, yet its effects are important for certain simulations. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords [TTgnd] and [TTpower] provide effective transit time parameters for modeling the ground clamp and the power clamp transit time capacitances independently. Approximation equations are included in the description. The additional keywords are described after the [Model] keyword as follows. |============================================================================== | Keywords: [TTgnd], [TTpower] | Required: No |** Description: These keywords specify the transist time parameters used |* to estimate the transit time capacitances or develop transit |* time capacitance tables for the [Gnd Clamp] | and [Power Clamp] tables. | Usage Rules: For each of these keywords, the three columns hold the transit | values corresponding to the typical, minimum and maximum | [Gnd Clamp] or [Power Clamp] tables, respectively. The | entries for TT(typ), TT(min), and TT(max) must be placed on | a single line and must be separated by at least one white | space or tab or tab character. All three columns are | required under these keywords. However, data is required | only in the typical column. If minimum and/or maximum values | are not available, the reserved word "NA" must be used | indicating the TT(typ) value by default. | Other Notes: The transit time capacitance is added to C_comp. It is | in a Spice reference model as Ct = TT * d(Id)/d(Vd) where | d(Id)/d(Vd) defines the DC conductance at the incremental | DC operating point of the diode, and TT is the transit time. | This expression does not include any series resistance |* component. Such a component is assumed to be negligible in |* practice. Assume that the internal diode current (Id) - | voltage (Vd) relationship is Id = Is * (exp(q(Vd)/kT) - 1) | where Is is the saturation current, q is electron charge, k is | Boltzmann's constant, and T is temperature in degrees Kelvin. | Then d(Id)/d(Vd) is approximately (q/kT) * Id when the diode | is conducting, and zero otherwise. This yields the simplifi- | cation Ct = TT * (q/kT) * Id. The Id is found from the | [Gnd Clamp] and [Power Clamp] operating points, and the cor- | responding TTgnd or TTpower is used to calculate the Ct value. | If the [Temperature] keyword is not defined, then use the | default "typ" temperature for all Ct calculations. | | The effective TT parameter values are intended to APPROXIMATE | the effects. They may be different from the values found in | the Spice diode equations. Refer to the NOTES ON DATA | DERIVATION METHOD for extracting the effective values. |------------------------------------------------------------------------------ | variable TT(typ) TT(min) TT(max) [TTgnd] 10n 12n 9n [TTpower] 12n NA NA | |============================================================================== Add Section (4) to NOTES ON DATA DERIVATION METHOD: | 4) Transit Time Extractions: | The transit time parameter is indirectly derived to be the value that | produces the same effect as that extracted by the reference measurement | or reference simulation. | | The test circuit consists of the following: | a) A pulse source (10 ohms, 1 ns at full duration ramp) or equivalent |* and transitioning between Vcc and 0 V, | b) A 50 ohm, 1 ns long trace or transmission line, | c) A 500 ohm termination to the ground clamp reference voltage for TTgnd | extraction and to the power clamp reference voltage for TTpower | extraction (to provide a convenient, minimum loading 450 ohm - | 50 ohm divider for high-speed sampling equipment observation | of the device under test), and |* d) The device under test (DUT). | |* DUT with [Gnd Clamp] |* ____________ | /| |* o---/\/\/\--O____________)---o--|< |--o GND |** 10 ohms Z0 = 50 ohm | | \| | |** TD = 1 ns | | |* |-/\/\/\-| |* | 500 ohm Load for Probing |* Vcc ---\ ------\ | |* \ \ o /--\ |* 0 V \------ \ / \------- |* | | \---------/ |** 1 ns |<----------->| |** 1 ns, 10 ohm Choose TTgnd that matches the measured |* Source Signal delay with the IBIS model simulation delay |* |* Example of TTgnd Extraction Setup |* | The TTgnd extraction will be done only if a [Gnd Clamp] table exists. | A high to low transition that produces a positive "glitch", perhaps | several nanoseconds later indicates a stored charge in the ground | clamp circuit. The test circuit is simulated using the complete | IBIS model with C_comp and the Ct model defined under the [TTgnd] and | [TTpower] keywords. An effective TTgnd value that produces a "glitch" | with the same delay is extracted. | | Similarily, the TTpower extraction will be done only if a [Power Clamp] | table exists. A low to high transition that produces a negative | "glitch", perhaps several nanoseconds later indicates a stored charge | in the power clamp circuit. An effective TTpower value that produces a | glitch with the same delay is extracted. | | It is preferred to do the extractions with the package parameters | removed. However, if the extraction is done from measurements, then | the package model should be included in the IBIS based simulation. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Refer to Spice diode reference information concerning the complete equations. The emission coefficient (N) is assumed to be 1. For measured values or cases where N is not 1, use the effective TT values. So the TT values may not be the exact values used in a Spice model. The Spice diode and transistor models differs slightly from the IBIS Clamp models. The definition and position of the capacitances is different. Furthermore, the IBIS table combines the diode and resistor, but can support more complex non-linear characteristics. Intrinsic RS Diode +-----+ |\ | ----> Id | | ----> Id o---/\/\/\--+--| >|--+----o +-----|Clamp|-----+ | |/ | | | | | | | | o----| +-----+ |----o | | | | | | | | +---| |--+ +-------| |-------+ | | | | Cj + Ct C_comp + Ct Fixed values of C_comp serve to estimate voltage dependent non-linear junction capacitance plus other metalization effects. Note, while shown here across the diode, the C_comp and Ct term would be lumped as capacitances between the terminal and ground to provide an equivalent AC circuit. Methods to connect capacitance contributions to each of the voltage rails are not available in the IBIS model. Note, this example illustrates one diode. It can be connected to the ground reference voltage (usually ground) or to the power reference voltage (usually Vcc) serving as either a [Gnd Clamp] or a [Power Clamp]. In practice, both clamps can exist and C_comp would contain the effects of both diodes and metalization. The Ct value is a function of absolute temperature. As an approximation, the default typical temperature is sufficient if [Temperature] is not specified. It is recommended to include the [Temperature] keyword when TT is specified to remove ambiguity regarding minimum and maximum transit time calculations for CMOS versus Bipolar technologies. An underlying assumption is that the equations will be applied only to the Clamping data, not the combined data that includes [Pulldown] and [Pullup] data. So when this detail is needed for Output models, the clamping data needs to be derived, if not provided. Because of these differences and possible missing details, the simplified equation and approximation approach is justified to capture the dominant behavioral effects. So the TT values may be the effective values that are consistent with the IBIS model and data. There are several formatting choices to describe transit time: (1) A [Model] subparameter similar to Vinl and Vinh, e.g., TTgnd = 12n TTpower = 10n This was not chosen because minimum and maximum process Spice models may have different values. (2) A [Model] subparameter similar to C_comp, e.g., TTgnd 10n 12n 9n TTpower 12n NA NA This was not chosen because the rules for minimum and maximum columns for C_comp are based on magnitude, whereas the rules for TT are based on process extremes. This may be confusing if they are similarly formatted. However, this is the second choice since TTgnd, TTpower and C_comp all relate to capacitances. (3) A [Gnd Clamp] and [Power Clamp] subparameter similar to C_comp, e.g [Gnd Clamp] TT 10n 12n 9n This was not chosen because it can cause unnecessary [Gnd Clamp] and [Power Clamp] table complexity and it can make the TT parameters hard to locate. (4) A [Model] keyword modifier similar to [Temperature] and other keywords which are a function of typical, minimum and maximum process and measurement conditions. e.g., [TTgnd] 10n 12n 9n [TTpower] 12n NA NA Since these keywords are related to the [Gnd Clamp] and [Power Clamp] tables and to the conditions under which they were derived, this format was chosen. BIRD34 also includes in its description a proposed extraction method. The method is based on using the typical input signal transitions. It is also designed so that it can be done under actual measurement conditions since the "real" effect may not be accurately modeled in Spice. An alternative which does not closely reflect actual conditions would be to measure the delay forward biased (perhaps by one volt) clamp diode takes to turn off when the bias voltage is removed or reverse biased. This approach has not been fully simulated. However, it is expected to be very sensitive to the selected bias voltages and not necessarily mimic actual operating conditions. DUT with [Gnd Clamp] 50 ohms | /| Pulse Source o---/\/\/\----o--|< |--o GND -2 V to Vcc | | \| | | | |-/\/\/\-| | 50 ohm Probe Load Vcc/2 /----- /------- / / Without DUT -> / / <- With DUT ___/------/ -1 V | | Choose TTgnd such that measured delay equals IBIS model simulation delay Example of TTgnd Extraction ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: BIRD34 expands EGG9 and adds more detail on modifying IBIS. It also expands on the mathematical basis as requested by Kellee Crisafulli. It also adds some comments based on EGG9 response from Stephen Peters and others on the positioning of C_comp in the ANALYSIS PATH section. BIRD34.2 contains some editorial corrections. ****************************************************************************** From owner-ibis Mon Sep 30 17:03:50 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 RAA19027 for ; Mon, 30 Sep 1996 17:03:46 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 30 Sep 96 16:53 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 30 Sep 96 16:53 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 30 Sep 96 16:55 PDT Message-Id: Date: Mon, 30 Sep 96 16:55 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS 9/27/96 MINUTES DATE: September 30, 1996 SUBJECT: 9/27/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann*, Tim Minnick, Russ Moser, Ray Ziesse* Applied Simulation Technology Dileep Divekar*, Norio Matsui, Antonis Orphanou (formerly Contec) Cadence Design C. Kumar Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier, Ralf Bruening Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, [Donald Telian], Jim Kruchowski Interconnectix, Inc. Bob Ross*, Chris Reid Meta-Software (Sanjay Gangal) Mitsubushi Tam Cao, Hoang Nguyen Motorola Ahmed Omer* National Semiconductor Syed Huq*, Donald Snyder, Chune-Sin Yeh, Bill Aronson NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell*, Chris Rokusek* Quantic Laboratories (Mike Ventham) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia* Veribest Ian Dodd, David Wiens VLSI Technology Dick Ulmer, Sung Oh, Swami Gangadharan, Daniel Kim, Tom Dockery, D.C. Sessions, Hrish Patel Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: 3M Fran Hart* Alcatel John Fitzpatrick Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu* EIA Patti Rusher* IC Works Eric Chen Mentor Graphics Kim Owen Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Philips Semiconductor Mike Magdaluyo Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Symmetry Andy Hughes Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison VTC, Inc. Bob Ward Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Participants who have joined another organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 10/18/96 (916) 356-9200 3-54605 8249548 All meetings are 8:00 AM to 9:55 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 and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Fran Hart from 3M joined. She is in the Electrical Products Group in Texas working with connectors, cables, and flex circuits. She provides the Spice models of connectors and cables, chip carriers and interconnects. Her current interest is in ground plane analysis. She is investigating IBIS is concerned about too much variation between the Spices. Dileep Divekar announced that Contec now has become Applied Simulation Technology, but remains the same. The roster and attendees list has been updated. EIA MEMBERSHIP AND TREASURER'S REPORT Jeff Chu reported that the DEC membership payment is progressing internally. Bob Ross reported receiving Patti Rusher's August 1996 IBIS ledger report. It shows $9,285, not change from last month. Patti indicated that some shared EIA expenses will be deducted before the end of the year. MINUTES REPORT, MISC. No corrections. All AR's were completed. MISCELLANY/ANNOUNCEMENTS None. PRESS and WEB PAGE UPDATES Jon Powell reported the EDN, September 26, 1996, pp. 97-104, has and article "Solving signal-integrity problems in high-speed digital systems" which gives several references to IBIS. This article (minus a few paragraphs) was taken from Jon's presentation at Design SuperCon96 (co-sponsored by EDN). (Also, Greg Edlund wrote in EDN, July 18, 1996, pp. 111-124, " Noise budgets help maintain signal integrity in low-voltage systems" and advocated IBIS and Spice models. This article was also adapted from Greg's presentation at Design SuperCon96.) Bob Ross has put a Word Version of the final draft (before editorial revision) of the EE Times article (September 2, 1996) "IBIS standards provides I/O buffer models" on vhdl.org as /pub/ibis/documents/eet96.doc for downloading. Permission has been granted to do this. Syed Huq plans to convert the EE Times article into HTML and provide access through the EIA/IBIS home page. Fran Hart wanted access to the BIRD documents. Syed Huq plans to provide a link to the bird directory from the EIA/IBIS home page. There already is access directly from the http://vhdl.org/pub/ibis/birds. Arpad Muranyi and Bob worked on downloading some older document files (overview.*) and found some of them corrupted with ^M data. This included the *.ps, *.rtf and .wfw files. John Powell indicated that file uploading is very dependent on what OS was being used. He will investigate the document files and work with Bob if any change is needed (revise or remove). Bob also reports that the contacts.txt document is updated whenever new information or changes are received. Similarly the roster.txt is updated immediately. Now is a good time to review your entry and submit updates (or new roster information) to Bob. The address is at the top of the roster. NEW MODELS Arpad Muranyi will work with Jon Powell concerning an Intel update on the readme file for three new models under NDA. Stephen Peters also submits Intel readme information, but only for his area (PentiumPro, etc.). OPENS FOR NEW ISSUES Patti Rusher regarding DAC97 planning. DAC97 PLANNING (AND OTHER MEETINGS) Patti Rusher will be sending out letters to the heads of the various groups within EIA regarding participation plans for the Design Automation conference in June, 1997 in Anaheim, California. This discussion will be put of the agenda for the next meeting. National has offered to host the Design SuperCon97 IBIS meeting in Santa Clara California in late January 1997 on the Monday prior the conference. Other companies are welcome to offer hosting (or co-hosting) the event. It was very successful with about 45 very top-level participants. Will Hobbs indicated that it would be fair to hold some East Coast meetings since nearly all of the IBIS meetings have been on the West Coast. Fran Hart from Austin Texas thought that central USA might be a nice compromise! EIA/JAPAN - IBIS WORKING GROUP Bob Ross reported making contact with Hideki Fukuda of Hitachi who is in the Semiconductor Standardization Committee in EIAJ. The task group is surveying I/O interface models from the IC supplier's point of view. Bob has provided IBIS information, Hideki plans to keep Bob informed of the activities. Jon Powell and Arpad Muranyi reported other possible individuals. Patti Rusher works with higher level EIAJ individuals who would be aware of any serious new I/O buffer standardization efforts. EIAJ works with EIA, and EIA has international membership. IBIS is proceeding in the International arena, and Patti sees no serious parallel effort. IEC EXPRESS FUNDING PROGRESS Patti Rusher reports that IBIS has been submitted as a work item in IEC (International Electrotechnical Commission) in TC-93. She will receive confirmation that it has been accepted next week. The next step is for ANSI/EIA-656 (IBIS Version 2.1) to be forwarded to the standards bodies in of each member nation for formal voting. So funding for an Express format of IBIS is not needed at this time. Patti is working on a larger proposal to submit to DARPA related to a component information management system where users can select information from a component database. Standardized models could be part of the database. So any future funding proposals may reside within this larger proposal. Consequently, she is not pursuing the smaller standards cleanup proposal. BIRD34.1 - STORED CHARGE EFFECT (Vote) Bob Ross summarized that BIRD34.1 introduces two new optional keywords [TTgnd] and [TTpower] under [Model]. These allow a first order approximation of the stored charge glitch seen in practice. It is also seen in Spice simulations of unterminated, clamped transmission lines when the optional TT parameter is in in the Spice clamping diode modle. The new keywords are associated with [Gnd Clamp] and [Power Clamp] tables, respectively. Stephen Peters provided a minor editorial change. Bob received a correction regarding Zo and TD values. Arpad Muranyi wanted "nS" changed to "ns" to be consistent with the rest of IBIS. Arpad also reported that some of the "txt" figures were misaligned. Dileep Divekar questioned whether the test circuit in BIRD34.1 actually forward biased the diode to produce the effect. Bob confirmed that it did based on the impedance mismatches and corresponding reflections, and also based on actual Spice simulation. BIRD34.1 was approved by unanimous vote with the above changes. AR - Bob Ross issue approved BIRD34.2 containing the above corrections and upgrade the "work in progress" version of IBIS in the /pub/ibis/wip directory to include BIRD34.2. SPECIFICATION COMMITTEE REPORT Jon Powell reported on the first meeting. The mission is to deal with any parameter that does not effect actual performance of signal integrity or timing simulations. Thus the thresholds Vinh, Vinl and the timing references fall within the Specification domain. This group is discussing pulse width noise immunity, input threshold extensions including hysteresis, overshoot extensions including research on overshoot vs. time specification and other areas. This group consisting of Jon Powell, Jon Fitzpatrick, Ahmed Omer, and Bob Ross already has BIRD38 and other proposals. It expects to come to agreement and issue one or more specification BIRDs for IBIS Committee consideration. Arpad Muranyi and Jon raised the question regarding how IBIS pending specifications on overshoot relate to those in RAIL. Ahmed Omer and felt that RAIL related to the net specification, whereas IBIS is related to the part itself. Bob felt that the RAIL specification might override and IBIS specification in processing, but the actual handling would be simulator dependent - e.g., report an error or have one override the other. However, the designer might purposely specify tighter rules in RAIL corresponding to the weakest device rather than rely on device limits in IBIS. Thus the consensus was that there is no conflict. IBIS should proceed to consider including all relevant device related specification parameters. EGG10 - PARSER ADDITIONS FOR NUMERICAL CHECKING Bob Ross started the discussion by going over Chris Rukusek's suggestions that he mailed. Suggestion 5 related to setting Ramp, package, and C_comp value limits which would trigger flags. Arpad Muranyi and others felt that some of the limits were too tight based on some non-typical, but practical applications of IBIS. One suggestion is to increase the trigger values by three or six orders of magnitudes related to someone forgetting to put in units or for putting in extreme values. Will Hobbs and others suggested considering a configuration table or some other method so that the user could adjust the limits depending on the application. Bob stated that the proposal could be for ibis_chk (Version 1.1), ibischk2 (Version 2.1 which also includes the complete copy of ibis_chk for Version 1.1 checking). or a future ibischk3.x for future IBIS. One could also consider a separate utility for reality checking rather than work the logistics of retrofitting these older versions. The revised values for approximately three orders of magnitude are: C_comp 1 nF Pin C 1 nF Pin L 1 uH Pin R 1 k Ramp Times 1 ms Suggestion 3 related to defining when a diode has suspiciously large to warrant a warning message. The 10A, 1.5V limit seemed reasonable. Chis reported that he had seen this limit exceeded in only several IBIS files on vhdl.org, and these curves were suspicious. This setting would also fall within the configuration discussion. Suggestion 2 related to testing the waveform data endpoints with the I/V table data to assure consistency. There was general agreement to do this. Suggestion 1 related to a robust testing of I/V table polarities. Chris felt that the intent of the test was already being handled sufficiently by ibischk2 since it will issue a report based on endpoint polarity difference errors. Suggestion 4 related to some number of points and curvature detection test so that unstable numerical artifacts are flagged. There was much resistance to this because of the trickiness to determine the proper values. Plus, different simulators using different algorithms may have their unique sensitivities. So this suggestion is dropped. Bob and others thru discussion indicated that the next step is for Chris to work through the PARSER BUG REPORT process to take the results of this discussion and put forth a proposal for changing the parser. The BIRD process is used for actual specification changes. The items in EGG10 relate to ibischk parser enhancements and relate to issuing warning messages. AR - Chris Rokusek submit a proposal capturing the above directions in one or more IBIS GOLDEN PARSER BUG REPORT FORMs - as enhancement requests. For now, it should relate only to the golden parser. In the proposal, it is Chris' option whether to consider configuration tables or some other universal method, or just propose hard coded values since the Forum did not indicate any preference during the discussion. BIRD37.2 - ENHANCEMENT OT THE PACKAGE MODEL SPECIFICATION Stephen Peters recently issued BIRD37.2. It basically changes the approved BIRD28.3 by adding Fork and End Fork statements. It also removes the controversial Matrix extensions - thereby amending and superseding BIRD28.3. This is based on last meetings guidance that a controversial extension was worse than no extension. This does not prohibit considering cascaded sections in the future based on further understanding and agreement. Bob Ross had some minor editorial changes that do not effect the content of BIRD37.2. A vote on BIRD37.2 is planned at the next meeting. BIRD36 - ELECTRICAL BOARD DESCRIPTION Steve Peters felt that BIRD36 is stalled for a number of reasons. It also contains the cascaded Matrix extensions that were dropped in BIRD37.2. Plus there may be discomfort with the extensive syntax. Stephen proposed reconvening the Package Committee task group to reconsider BIRD36. The same members are expected to join. Also Fran Hart and Ahmed Omer indicated interest in joining. Everyone is welcome to join. AR - Stephen Peters get the telephone bridge numbers and send out a message on vhdl.org announcing the details of the Package Committee meetings. BIRD35.1 - MULTI-STAGED OUTPUTS Bob Ross still plans to produce BIRD35.2 taking into account Jon Powell's sample syntax and IBIS syntax. AR - Bob Ross produce BIRD35.2 before next meeting. NEXT MEETING: The next meeting is on Friday, October 18, 1996, 8:00 A.M. to 9:55 A.M. BIRD37.2 is scheduled for vote. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.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 e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ==============================================================================