From 75671.3443@compuserve.com Wed Aug 2 14:06:27 1995 Return-Path: <75671.3443@compuserve.com> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16708; Wed, 2 Aug 95 14:06:27 PDT Received: by arl-img-2.compuserve.com (8.6.10/5.950515) id QAA03502; Wed, 2 Aug 1995 16:59:49 -0400 Date: 02 Aug 95 16:54:36 EDT From: dean wallace <75671.3443@compuserve.com> To: IBIS Subject: MAILING LIST Message-Id: <950802205436_75671.3443_FHN28-1@CompuServe.COM> Would you add me to the email list DEAN WALLACE (75671.3443@COMPUSERVE.COM) LINFINITY MICROELECTRONICS From Will_Hobbs@ccm2.jf.intel.com Wed Aug 2 14:33:16 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16859; Wed, 2 Aug 95 14:33:16 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sdlJI-000UexC; Wed, 2 Aug 95 14:26 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sdlJH-000txRC; Wed, 2 Aug 95 14:26 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Wed, 02 Aug 95 14:26:39 PDT Date: Wed, 02 Aug 95 14:22:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Subject: Response to Ballot comments Text item: Text_1 To IBIS Members Here are comments from Dr. Alan Williams of the University of Manchester, who provides valuable review of EIA documents. Bob Ross drafted the response, and he and I have reviewed the comments, which are attached. You are welcome to consider the comments and you may prefer a different response. Please inform Bob and myself directly or reply through the reflector if you see any issues with the response. We particularly want input from interested Voting Members and people who were closely involved in the writing of IBIS Version 2.1. Based on comments and possible revisions, we plan to discuss and vote on this document at the August 11 Open Forum meeting. Will Hobbs Intel Corp., in cooperation with Bob Ross Interconnectix, Inc. Response Document follows: ----------------------------------------------------------------------------- Dr. Alan Williams Dept. of Computer Science University of Manchester Oxford Road Manchester M13 9PL United Kingdom Dear Dr. Williams: On behalf of the EDA IBIS Subcommittee, thank you very much for your detailed review and valuable comments. Our Committee response based on a review and vote of approval at the IBIS OPEN FORUM meeting of August 11, 1995 is given as the attachment "EIA IBIS COMMITTEE RESPONSE TO UNIVERSITY OF MANCHESTER COMMENTS TO STANDARDS PROPOSAL NO. 3527. Sincerely, Will Hobbs Chairman, EIA IBIS Open Forum EIA IBIS COMMITTEE RESPONSE TO UNIVERSITY OF MANCHESTER COMMENTS TO STANDARDS PROPOSAL NO. 3527 University of Manchester : 1 Editorial Page 2 (first one i.e. Notice), Line 10 Delete Copyright symbol Response: The approved version of EIA-656 will contain a copyright notice symbol in compliance with EIA format conventions. University of Manchester : 2 Editorial Page 2 (second one i.e. Contents) Correct the page numbers Response: The page numbering will be corrected in compliance with EIA format conventions in the approved version of EIA-656. University of Manchester : 3 Editorial Page 1 (Preface, first paragraph, first line Add a noun after "(EDA)" Response: The text will be corrected to read "The IBIS Open Forum, a group of some 34 electronic design automation (EDA) companies, semiconductor companies, and other interested organizations, ...". University of Manchester : 4 Editorial Page 1 (Preface), fifth paragraph, first line Delete "also" from "Forum also created" Response: This change will be made as requested. University of Manchester : 5 Editorial Page 1 (Scope), second paragraph, third line Change "With IBIS, vendors" to "Within the IBIS format, vendors" Response: This change will be made as requested. University of Manchester : 6 Editorial Page 3, line 2 Change "12/9/94" to "9th December 1994" Response: A change will be made to "August 22, 1995" to reflect the date of letter ballot conclusion and (hopefully) approval of the EIA version of IBIS 2.1 and to differentiate it from any prior published IBIS Standards designated as Version 2.1 University of Manchester : 7 Editorial Page 5, line 1 Delete "degrees" Reason: "degrees" should only be used with Centigrade and Farenheit Response: No change will be made. Reason: We note that in the EIA Engineering Publication (1990) Style Manual for Standards of EIA, TIA, and JEDEC, EP-7, Appendix C (Abbreviations), page 26, both "degree Celsius" and "degree Fahrenheit" are listed as "Unit or Term". However, we will use the accepted terminology if this is in error. University of Manchester : 8 Editorial Page 5, line 3 Change "supplimental" to "supplemental" Response: This change will be made as requested. University of Manchester : 9 Editorial Page 7, line 4 (Should be Page 6) Change "These keywordsF arguments" to "The keyword arguments" Response: This change will be made as requested. University of Manchester : 10 Technical Page 6, line 5 Change ", and be of any format" to ", and, apart from the Date, be of any format". Reason: Although it is difficult to standardize the format and semantics of concepts such as a Disclaimer, the format of the Date should be standardized and should be in UTC. The example file illustrates this as the date is open to two possible interpretations: 12th of September 1994 and 9th of December 1994. The exact meaning of the day will also vary according to the time zone. Response: Some Editorial clarifications will be made. Page 6, lines 4-6 will be changed (including comment 9) to read: " Usage Rules: The keyword arguments can contain blanks, and be of any format. The [Date] keyword argument is limited to a maximum of 40 characters, and the month should be spelled out for clarity." Page 6, line 15 will be changed from 12/9/94 to "August 22, 1995" Page 27, line 51 will be changed from "December 9, 1994" to "August 22, 1995". Reason: The syntax such as 12/9/95 has been used in all versions of IBIS files. While there may be an advantage to standardizing the date/time format, there really is not sufficient need to make it a requirement. The [Date] keyword is optional, so data provided is informational. Instead, A clarification comment and change of examples should be sufficient. University of Manchester : 11 Technical Page 7, line 4 Issue: It is not clear if the minimum <= typical <= maximum. Response: No change will be made. Reason: The IBIS standard does not apply rigid restrictions on most data, but does give guidance. The example for the sub-parameters R_pkg, L_pkg, and C_pkg indicates that entries are placed in the "typ", "min" and "max" columns by magnitude. The expected entries for "typ", "min" and "max" columns for all keywords and sub-parameters are collected in the section NOTES ON DATA DERIVATION METHOD. Paragraph 5 on page 31 would apply, for example, to the R_pkg, L_pkg, and C_pkg sub-parameters. University of Manchester : 12 Technical Page 7, lines 38 and 39 Change "If "NA" is in columns 4 through 6, the default packaging values must be used" to "NA cannot be specified for all three values in columns 4 through 6". Reason: As currently specified, two alternative mechanisms are available for assuming the default values i.e. stating nothing or stating "NA NA NA". In a standard, such multiple mechanisms are liable to lead to confusion. In addition, the semantics of NA are subtly altered from "Not available" to "Take default". Response: No change will be made. Reason: While the point is valid, the semantics in most cases where "NA" is used is "the data is not available, so an appropriate alternative is suitable." In some cases the default alternative is explicitly specified, such as with the [Package] sub-parameters. In other cases, it is implicitly specified, such as with tdelay_typ. In still other cases, another column of data or processed data value is appropriate such as with NA entries in "max" and "min" columns of VI tables and of VT tables. The simulator will act in an appropriate manner consistent with it's capabilities and the type of problem it is solving. The redundant syntax "NA NA NA" and null choices are already implemented in Version 1.1 parsers, in ibis_chk, in ibis_chk2 (under development), in commercial products, and in existing IBIS files. There is not sufficient reason to exclude the redundancy at this time and violate the dedication to backward compatibility. University of Manchester : 13 Editorial Page 8, line 40 Change "terminator is connected" to "terminator is connected to" Response. This change will be made as requested. University of Manchester : 14 Editorial Page 11, lines 35 and 36 Delete "the parser issues a warning and" Reason: The specification of a transfer standard should not depend upon the functionality of a 'golden parser'. If this phrase is intended to constrain the functionality of an IBIS checker then this should be specified in a separate section, preferably in a separate document. Response: No change will be made. Reason: While reference to the parser has been argued as inappropriate, an important exception is conveyed by the specific reference. A violation of a stated requirement in this case is not considered serious enough that an error message is generated. In previous Version 1.1 of IBIS, the requirement did not exist. So for backward compatibility, this statement and this weaker treatment of an error condition is made. Also, the parser has been viewed by some as a practical, defacto implementation of the standard. University of Manchester : 15 Editorial Page 11, lines 41 and 42 Delete: "the parser issues a warning and" Reason: The specification of a transfer standard should not depend upon the functionality of a 'golden parser'. If this phrase is intended to constrain the functionality of an IBIS checker then this should be specified in a separate section, preferably in a separate document. Response: No change will be made. Reason: Same as response to comment 14 University of Manchester : 16 Editorial Page 13, line 14 Change: "degree C" to "C" Reason: See comment 7 Response: The change will be made to "degree Celsius". Reason: Same as response to comment 7 University of Manchester : 17 Editorial Page 13, lines 41-46 Delete the paragraph Reason: This paragraph appears to repeat information stated elsewhere. In addition its presence under the "GND Clamp Reference" keyword is confusing. Response: This part of Other Notes will be deleted here as requested and restated in the [Voltage Range] keyword description, page 13: "Other Notes: If the [Voltage Range] keyword is not present, then all four of these keywords described below must be present: [Pullup Reference], [Pulldown Reference], [POWER Clamp Reference], and [GND Clamp Reference]. If the [Voltage Range] is present, the other keywords are optional and may or may not be used as required. It is legal (although redundant) for an optional keyword to specify the same voltage as specified by the [Voltage Range] keyword." University of Manchester : 18 Editorial Page 16, lines 8-13 Delete the paragraph Reason: See comment 15 Response: No change will be made. Reason: There are few data restrictions on IBIS. However, the issue of monotonic data is very important as it relates to the algorithms used to process the IBIS data. While reference to the parser has been argued as inappropriate, an exception is made here because of the need to identify non-monotonic data. University of Manchester : 19 Editorial Page 22, line 36 Change: "in all .ibs files" to "in all .ibs and .pkg files" Response: This change will be made as requested. University of Manchester : 20 Editorial Page 22, line 46 Change "in all .ibs files" to "in all .ibs and .pkg files" Response" This change will be made as requested. From kellee@washington.nwlink.com Wed Aug 2 19:42:56 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19082; Wed, 2 Aug 95 19:42:56 PDT Received: (from kellee@localhost) by washington.nwlink.com (8.6.11/8.6.11) id TAA23548; Wed, 2 Aug 1995 19:37:05 -0700 Date: Wed, 2 Aug 1995 19:37:05 -0700 Message-Id: <199508030237.TAA23548@washington.nwlink.com> X-Sender: kellee@nwlink.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@hyperlynx.com Subject: Comments on EIA ballot Good job Will an Bob. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. From bob@icx.com Fri Aug 4 10:37:00 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15306; Fri, 4 Aug 95 10:37:00 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 4 Aug 95 10:30 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 4 Aug 95 10:32 PDT Message-Id: Date: Fri, 4 Aug 95 10:32 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA AUG 11, 1995 IBIS Open Forum Meeting Agenda for 8/11/95 Bridge Number Reservation # Passcode (916) 356-9999 1-3150 8492193 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 Hobbs - Intros of New IBIS Participants Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press Updates All - New Models Available, Library Update All - Opens for New Issues All 8:15 EIA IBIS Status - Membership Update and Treasurers Report Rusher/Hobbs - Balloting Issues/Update Rusher/Hobbs o Comment Resolution (Vote) Hobbs o Ballot Comment Resolution Meeting August 25, 1995 Hobbs 8:30 Administrative and Project Discussions Company Logos Permission Letter from EIA Powell/Rusher Roster Update Ross Web Project Update Huq New Web Documents Approval (Vote) Huq Model Usage Tracking on vhdl.org Huq/Steer Models Under NDA Process Huq/Steer Golden Parser 2.1 status Hobbs S2IBIS 1.2 Update Ross S2IBIS 2.1 Status Kumar/Steer Version 2.1 Cookbook and Overview Chrisafulli/Ross New Administrative Issues All 9:00 Technical Discussions BIRD 27.1 - New Keyword for Differential I/O (defer) Ross BIRD 28.2 - Package Model Extension Peters Physical Package Description Discussion Crisafulli Pin Programmable Buffer Strengths Muranyi New Technical Issues All 9:50 Wrap-up, Next Meeting Plans Hobbs 9:55 Sign Off From contec!contec.contec.COM!dileep@netcom.com Mon Aug 7 15:50:45 1995 Return-Path: Received: from netcomsv.netcom.com (uucp6.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24954; Mon, 7 Aug 95 15:50:45 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA08517; Mon, 7 Aug 1995 15:38:45 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA21666; Mon, 7 Aug 95 15:04:13 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA21827; Mon, 7 Aug 1995 15:07:18 +0800 Date: Mon, 7 Aug 1995 15:07:18 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9508072207.AA21827@contec13.contec.COM> To: ibis@vhdl.org Subject: Comments about IBIS (EIA-656) specification Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 1168 Comment about keyword [Model] (Page 12): If I look at the explanation of model types Open_drain and Open_source from the point of view of the output stage being a cmos inverter, then I can understand it. But if I look at the type Open_sink from the point of view of the output stage sourcing or sinking current, then the explanation seems backwards. Generally, the top device (pullup) sources current and the bottom device (pulldown) sinks current. Therefore, I would have thought that Open_sink model type will not have the Pulldown table, but the explanation says not to use Pullup table. One possible solution is instead of introducing the new keyword Open_sink, it may be more intuitive if new keywords Open_pullup and Open_pulldown are introduced, Other: Are blank lines allowed in ibis files? For nonblank lines, is it necessary to have a non white space character as the first character? ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From contec!contec.COM!raghu@netcom.com Mon Aug 7 15:51:08 1995 Return-Path: Received: from netcomsv.netcom.com (uucp6.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24962; Mon, 7 Aug 95 15:51:08 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA08506; Mon, 7 Aug 1995 15:38:39 -0700 Received: from contec10.contec.COM by contec.COM (4.1/SMI-4.1) id AA21644; Mon, 7 Aug 95 14:51:42 PDT Received: by contec10.contec.COM (5.x/SMI-SVR4) id AA20232; Mon, 7 Aug 1995 14:46:37 -0700 Date: Mon, 7 Aug 1995 14:46:37 -0700 From: raghu@contec.COM (Raj Raghuram) Message-Id: <9508072146.AA20232@contec10.contec.COM> To: ibis@vhdl.org Subject: Commnets on IBIS FAQ X-Sun-Charset: US-ASCII Thanks to Syed for putting together the IBIS FAQ. When I first started looking into IBIS, such a thing would have definitely been very useful to me. I had a few suggestions on the FAQ. Here they are: 1. Item 1 mentions that IBIS "can be used to model almost 99% of all semiconductor". I think we could just make it "most semiconductors". 2. Item 6 regarding SSO could mention the advantages of using Ver 2.1 models over Ver 1.1. The use of a matrix for the inductance accounts for the "loop" inductance i.e. the mutuals between the pins are considered. Usually the mutuals help in reducing the net inductance. Moreover, Ver 2.1 contains information on which driver/receiver is connected to which GND/VCC pin. This information is vital for SSO simulations. Most of the models in the IBIS library are Version 1.1 models and users must understand the limitations of these models from a SSO viewpoint. 3. The need to sweep from -VCC to 2VCC is not related to SPICE convergence. SPICE will have no problems converging with 0 to VCC sweep models. The main reason is that reflections caused by improper terminations can produce voltages at the driver/receiver terminals from -VCC to 2VCC. The drivers and receivers, therefore, need to be modeled over this entire range. 4. Some clarifications on the use and origin of C_comp would be very helpful. 5. There is considerable confusion on the use of IBIS models versus SPICE. Some clarifications and comparison would be useful. It is not a IBIS vs SPICE issue as much as a IBIS versus transistor model issue. Many SPICE vendors themselves directly take in IBIS models and can simulate them along with other SPICE elements. Where transistor models are available,it may still be best to use them. ****************************** Raj Raghuram Contec CAE, 2188 Bering Drive, San Jose, CA-95131. Tel: (408) 434-6767 ext.131 Fax: (408) 434-6884 e-mail: raghu@contec.com ****************************** From medtron!relay.medtronic.com!hsin-huei.lin@uunet.uu.net Tue Aug 8 11:44:32 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07129; Tue, 8 Aug 95 11:44:32 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzbxy17864; Tue, 8 Aug 1995 14:37:53 -0400 Received: from medtron.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Tue, 8 Aug 1995 14:37:46 -0400 Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA02830 (5.65c/IDA-1.4.4 for ); Tue, 8 Aug 1995 13:36:29 -0500 Received: from mspeos.cis.corp.medtronic.COM (eos.cis.corp.medtronic.COM) by medtron.medtronic.COM with SMTP id AA02826 (5.65c/IDA-1.4.4 for ); Tue, 8 Aug 1995 13:36:28 -0500 Received: from eos.cis.corp.medtronic.COM by mspeos.cis.corp.medtronic.COM (5.x/SMI-SVR4) id AA12866; Tue, 8 Aug 1995 13:36:15 -0500 Received: from MSPEOS-Message_Server by eos.cis.corp.medtronic.COM with Novell_GroupWise; Tue, 08 Aug 1995 13:36:14 -0500 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 08 Aug 1995 13:36:38 -0500 From: Hsin-Huei Lin To: raghu@contec.com Cc: ibis@vhdl.org Subject: Commnets on IBIS FAQ - Reply Hi, I have one question about item 1 below. I always think IBIS is the modeling format for Digital devices only, but the following statement did not call out Digital specifically. Does that mean I can use IBIS to model discrete component like Res, Cap, Diode and Analog component like opamp? If this is correct then which part of the IBIS definition address these? Hsin-Huei Lin Medtronic, Inc. >>> Raj Raghuram 08/07 4:46 pm >>> 1. Item 1 mentions that IBIS "can be used to model almost 99% of all semiconductor". I think we could just make it "most semiconductors". From Will_Hobbs@ccm2.jf.intel.com Tue Aug 8 12:19:01 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07336; Tue, 8 Aug 95 12:19:01 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sfu4I-000UdOC; Tue, 8 Aug 95 12:12 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sfu4I-000txBC; Tue, 8 Aug 95 12:12 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Tue, 08 Aug 95 12:12:02 PDT Date: Tue, 08 Aug 95 12:08:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Cc: huq@rockie.nsc.com Subject: Re: IBIS FAQ for the homepage Text item: Syed, Thanks a lot for putting this together. I have a couple of changes to suggest. My comments appear below. I've deleted those things for which I didn't have comments. I also added a question about monotonic data and one about becoming an active IBIS participant. Will 2.0 What is the "Golden Parser" ? * The "Golden Parser" is a program called ibis_chk that parses the model file to verify that the file conforms to the IBIS specification. All model files must pass the parser before a model can be released on the Internet. 3.0 Where can I find the IBIS Golden Parser ? The parser is freely available in object code format for many platforms, and can be downloaded via anonymous ftp from the vhdl.org BBS (198.31.14.3). It resides under the /pub/ibis/ibis_chk directory. The Golden Parser source code is also available from the EIA IBIS committee for a fee. In addition to checking syntax, it creates data structures from model data that simulators can use. There are three options for licensing the IBIS Golden Parser source code, V2.1, depending on your membership status in the IBIS committee of EIA: 1) If you are a current member of the IBIS committee, you can license the parser source for an additional $250.00 2) If you are not a member, but would like to be, you can join the committee and license the parser source for a total of $750 3) If you are not a member, and do not wish to become a member, you can license the source for $500. In any case, submit a request to: EIA 2500 Wilson Blvd. Arlington, VA 22201 (703) 907-7545 (phone) (703) 907-7501 (fax) Enclose a check in the appropriate amount made out to EIA. EIA will take care of distributing the source. 7.0 Why do we need to sweep to 2Vcc ? >>> In addition to comments already submitted on this item, I would add: Simulation accuracy is greatly enhanced by the "beyond-the-rail" data. Overshoot and undershoot generally fall within this range, and the range encompasses the forward-biased regions of protection diodes often used on buffers. 8.0 Can IBIS model GTO(Gradual Turn On) or Slew rate controlled outputs ? IBISv2.1 can model RTC(Rise Time Controlled), GTO(Gradual Turn on) or Slew rate controlled outputs. These are defined under [Rising Waveform] and [Falling Waveform] keywords. See IBISv2.1 specification for more details. Add: The waveform tables can also serve as "golden waveforms" to check simulator accuracy, since the load conditions that produced the tables are specified. That is, the simulator should produce these waveforms when the model is connected to the specified loads. 10.0 Can IBIS provide timing information? E.g., propagation delays, skew, etc.? 11.0 Can IBIS model be used to measure propagation delays through IC's? IBISv2.1 does not support measurement of propagation delays. IBIS is mainly used to simulate transmission lines and analyze signal integrity issues. >> A space is needed before Possibly in the middle of the second paragraph below. 16.0 The standard does not explicity specify the nature of the input ramp in obtaining ramp rates. What should be the input rise time as well as the high and low values of the input pulse? IBIS does not provide an Input pulse specification for deriving Ramp rates (and Waveform Tables). A reasonable guideline is to mimic actual conditions for which the device would be used. Therefore it is probably better not to mandate a specific condition. The voltage swing should be appropriate for the technology, e.g., 0 to 5V for CMOS and about 0 to 3V for TTL. A signal faster than the expected Ramp rates is my preference, although a case could be made to provide a response that mimics the data book input ramps specified for timing tests. Possibly a 50 Ohm series resistance approximating the pulser source impedance and trace environment to the device input should be included. However, since the actual thresholds are narrow (several 100 mV), the Ramp rates and Waveform tables should not differ significantly for any reasonable, appropriate Input. 17.0 Can IBIS handle devices whose output is non-monotonic? IBIS can handle non-monotonic data. The parser will detect such data and issue a warning in the possibility the data is in error, but will correctly parse the data. Whether a given simulator will treat the data correctly is a question left to simulator vendors to answer. For problems in modeling I/O buffers that IBIS doesn't adequately handle, the IBIS Open Forum (a.k.a. the EIA IBIS Committee) is always trying to extend IBIS to be more useful and has developed an excellent track record and set of processes to move the standard forward without harming backward compatibility. 18.0 How do I become an active participant in IBIS activities? To participate in IBIS discussions, send your email address to ibis-request@vhdl.org (198.31.14.3). You will be added to the IBIS reflector, which is a mail group used by IBIS partipants to exchange ideas and data. Notices of upcoming teleconferences, agendas, and meeting minutes are also distributed through the IBIS reflector. 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: huq@rockie.nsc.com Subject: IBIS FAQ for the homepage To: ibis@vhdl.org Message-Id: <9507261820.AA18207@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Wed, 26 Jul 95 11:20:15 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA18207; Wed, 26 Jul 95 11:20:15 PDT Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA02475 for ibis@vhdl.org; Wed, 26 Jul 95 11:17:58 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20157 for ibis@vhdl.org; Wed, 26 Jul 95 11:17:59 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04120; Wed, 26 Jul 95 11:24:30 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 26 Jul 95 12 :38:07 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 26 Jul 9 5 12:40:44 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sbCK0-000twhC; Wed, 26 Jul 95 12:40 PDT From Arpad_Muranyi@ccm.fm.intel.com Tue Aug 8 12:28:44 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07387; Tue, 8 Aug 95 12:28:44 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sfuE2-000UddC; Tue, 8 Aug 95 12:22 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sfuE2-000tx9C; Tue, 8 Aug 95 12:22 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Tue, 08 Aug 95 12:22:06 PDT Date: Tue, 08 Aug 95 12:19:00 PDT From: Arpad Muranyi Message-Id: To: ibis@vhdl.org Subject: Report on talk with Raj Mittra Hi IBIS people, I had an AR to talk with professor Raj Mittra at the University of Illinois about the issues involving packaging information exchange formats in IBIS files. I had three questions to ask him: 1) What input formats do they use for their field solver software? I could not get a specific answer to this question. He mentioned the Autocad format several times as the preferred format to which they could link their tool easily. (This link is not available yet). I tried to find out what format they are using now, but I received only a general answer "we take a drawing or an ASCII file". There seems to be no standard yet in this area, since there are not too many package manufacturers on the world. 2) What are the outputs of their field solver tools? The tools generate full RLGC matrixes from the geometrical data. The point he made is that their tool takes the whole package into consideration not just portions of it as some commercial simulators do for speed improvement. However, in the case of MCMs, the situation is somewhat different. They model MCMs with lumped circuits with mutual elements. 3) Is EDIF usable to exchange geometrical description? Answer: "Should be explored. We need geometry and material description". In addition, I asked him if he would be available and interested in joining our Open Forum teleconference on Friday. He said he would. I told him that I would call him when we get to the technical discussions and switch him in. This would be a good opportunity to ask him questions directly, if I missed a point during my converstion with him. Arpad Muranyi Intel Corporation From bob@icx.com Tue Aug 8 13:00:04 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07595; Tue, 8 Aug 95 13:00:04 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 8 Aug 95 12:52 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 8 Aug 95 12:55 PDT Message-Id: Date: Tue, 8 Aug 95 12:55 PDT From: bob@icx.com ( Bob Ross) To: dileep@contec.contec.COM, ibis@vhdl.org Subject: Re: Comments about IBIS (EIA-656) specification Dileep: The way the names "Open_sink" and "Open_source" should be viewed is open AND sink (top side is open and the device sinks current) open AND source (bottom side is open and device sources current) Your are correct that there could be confusion, but we adopted the above convention after much discussion (E-mail and direct) and considered many alternatives including your suggestion. Here are some of the points. (1) We wanted terminology that was technology independent. We wanted to avoid requiring Open_drain for TTL devices and also to avoid enumerating technology dependent alternatives (e.g., Open_collector). (2) With CMOS, some ASIC data books have used Open_drain and Open_source pair. (3) The terminology "sink" and "source" have been used in products and have appeared in at least one data book. (4) While "pullup" and "pulldown" match the IBIS terminology, they could be confused within the context of an ASIC model when you consider the option of an internal "pullup resistor" or "pulldown resistor". After much discussion, "Open_sink" and "Open_source" emerged as the consensus choice. Regarding your other questions, blank lines are allowed (they are not prohibited). Except for keywords, the white space characters (tab, space) are allowed as the first character of any line. For example, columns of numbers can be indented and aligned at the decimal point. Bob Ross, Interconnectix, Inc. > Comment about keyword [Model] (Page 12): > If I look at the explanation of model types Open_drain and Open_source > from the point of view of the output stage being a cmos inverter, then > I can understand it. But if I look at the type Open_sink from the > point of view of the output stage sourcing or sinking current, then > the explanation seems backwards. Generally, the top device (pullup) > sources current and the bottom device (pulldown) sinks current. > Therefore, I would have thought that Open_sink model type will > not have the Pulldown table, but the explanation says not to use > Pullup table. > One possible solution is instead of introducing the new keyword > Open_sink, it may be more intuitive if new keywords Open_pullup > and Open_pulldown are introduced, > Other: > Are blank lines allowed in ibis files? > For nonblank lines, is it necessary to have a non white space > character as the first character? > ------------------------------------------------------------ > Dileep Divekar > Contec CAE, Ltd. > 2188 Bering Drive > San Jose, CA 95131 > Phone - (408)-434-6767 x 126 > Fax - (408)-434-6884 > Email - dileep@contec.com > ------------------------------------------------------------ From contec!contec.COM!raghu@netcom.com Tue Aug 8 15:10:48 1995 Return-Path: Received: from netcomsv.netcom.com (uucp13.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08768; Tue, 8 Aug 95 15:10:48 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA29303; Tue, 8 Aug 1995 14:49:13 -0700 Received: from contec10.contec.COM by contec.COM (4.1/SMI-4.1) id AA02975; Tue, 8 Aug 95 13:53:45 PDT Received: by contec10.contec.COM (5.x/SMI-SVR4) id AA21141; Tue, 8 Aug 1995 13:48:41 -0700 Date: Tue, 8 Aug 1995 13:48:41 -0700 From: raghu@contec.COM (Raj Raghuram) Message-Id: <9508082048.AA21141@contec10.contec.COM> To: hsin-huei.lin@medtronic.com Subject: Re: Commnets on IBIS FAQ - Reply Cc: ibis@vhdl.org X-Sun-Charset: US-ASCII This is in response to your question on the use of IBIS as a modeling format for Analog Devices. My immediate thoughts on this are given below. I am sure you will get other responses as well. IBIS evolved from the need to describe Digtial Drivers and Receivers without having to give away proprietary transistor level models and circuits. But the general principles should apply to all devices. The package information is relevant (for example) even for a simple 2-terminal capacitor. There is definitely a need to model opamps for use in Signal Integrity simulations. Crosstalk from a "digital" line (or trace or pin) onto an analog line is often of great concern. It may be possible to model certain opamps in the IBIS format even now. The input would be differential (Version 2.1 format may be necessary). The output does have the protection diodes and could be described by a Output type model format. However, other functional attributes of an opamp would not be modeled. IBIS is not intended for a functional simulation in any case. Certain other opamps may require a new model type (i.e such as Input, Output, I/O, or tristate) not already defined in IBIS. ************************************************************************ Raj Raghuram Home address: Contec CAE, 1483 Eddington Place 2188 Bering Drive, San Jose, CA-95129 San Jose, CA-95131. Tel: (408) 252-1285 Tel: (408) 434-6767 ext.131 Fax: (408) 434-6884 e-mail: raghu@contec.com ************************************************************************ >> Included message Hi, I have one question about item 1 below. I always think IBIS is the modeling format for Digital devices only, but the following statement did not call out Digital specifically. Does that mean I can use IBIS to model discrete component like Res, Cap, Diode and Analog component like opamp? If this is correct then which part of the IBIS definition address these? Hsin-Huei Lin Medtronic, Inc. >>> Raj Raghuram 08/07 4:46 pm >>> 1. Item 1 mentions that IBIS "can be used to model almost 99% of all semiconductor". I think we could just make it "most semiconductors". From esayre@nesa.com Wed Aug 9 14:39:37 1995 Return-Path: Received: from wile.nesa.com ([204.240.29.34]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22737; Wed, 9 Aug 95 14:39:37 PDT Date: Wed, 9 Aug 1995 17:32:41 -0400 Message-Id: <199508092132.RAA08508@wile.nesa.com> Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma008506; Wed Aug 9 17:32:22 1995 X-Sender: esayre@mail.nesa.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: esayre@nesa.com (Dr. Edward P. Sayre) Subject: Re: Open Forum teleconference X-Mailer: I would be interested in the Open Forum teleconference. I am an early developed with Roger Harrington of Method of Moments (1968) and have worked and used the same for many years. I am particularily interested in an efficient way to get geometrical described packages into field solvers. I am also interested in knowing how people decide on the number of subsections to use in their field solvers. We have developed scaling laws at NESA which take into account risetime and the electrical size of the network. Like to hear what others have to say about time domain scaling based on circuit time constants, risetime etc. Dr. Edward P. Sayre, NESA Chief Engineer From Will_Hobbs@ccm2.jf.intel.com Wed Aug 9 16:22:07 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23398; Wed, 9 Aug 95 16:22:07 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sgKKn-000UhFC; Wed, 9 Aug 95 16:14 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sgKEF-000tyFC; Wed, 9 Aug 95 16:08 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Wed, 09 Aug 95 16:08:03 PDT Date: Wed, 09 Aug 95 16:05:00 PDT From: Will Hobbs Message-Id: To: esayre@nesa.com, ibis@vhdl.org Subject: Re[2]: Open Forum teleconference Text item: Dr. Sayre, Below is the agenda for the upcoming teleconference, with instructions on phoning in. Feel free to join us. Regards, Will Hobbs Chair, IBIS Open Forum IBIS Open Forum Meeting Agenda for 8/11/95 Bridge Number Reservation # Passcode (916) 356-9999 1-3150 8492193 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 Hobbs - Intros of New IBIS Participants Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press Updates All - New Models Available, Library Update All - Opens for New Issues All 8:15 EIA IBIS Status - Membership Update and Treasurers Report Rusher/Hobbs - Balloting Issues/Update Rusher/Hobbs o Comment Resolution (Vote) Hobbs o Ballot Comment Resolution Meeting August 25, 1995 Hobbs 8:30 Administrative and Project Discussions Company Logos Permission Letter from EIA Powell/Rusher Roster Update Ross Web Project Update Huq New Web Documents Approval (Vote) Huq Model Usage Tracking on vhdl.org Huq/Steer Models Under NDA Process Huq/Steer Golden Parser 2.1 status Hobbs S2IBIS 1.2 Update Ross S2IBIS 2.1 Status Kumar/Steer Version 2.1 Cookbook and Overview Chrisafulli/Ross New Administrative Issues All 9:00 Technical Discussions BIRD 27.1 - New Keyword for Differential I/O (defer) Ross BIRD 28.2 - Package Model Extension Peters Physical Package Description Discussion Crisafulli Pin Programmable Buffer Strengths Muranyi New Technical Issues All 9:50 Wrap-up, Next Meeting Plans Hobbs 9:55 Sign Off I would be interested in the Open Forum teleconference. I am an early developed with Roger Harrington of Method of Moments (1968) and have worked and used the same for many years. I am particularily interested in an efficient way to get geometrical described packages into field solvers. I am also interested in knowing how people decide on the number of subsections to use in their field solvers. We have developed scaling laws at NESA which take into account risetime and the electrical size of the network. Like to hear what others have to say about time domain scaling based on circuit time constants, risetime etc. Dr. Edward P. Sayre, NESA Chief Engineer 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***. X-Mailer: Subject: Re: Open Forum teleconference From: esayre@nesa.com (Dr. Edward P. Sayre) To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Sender: esayre@mail.nesa.com Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma008506; Wed Aug 9 17:32:22 1995 Message-Id: <199508092132.RAA08508@wile.nesa.com> Date: Wed, 9 Aug 1995 17:32:41 -0400 Received: from wile.nesa.com ([204.240.29.34]) by vhdl.vhdl.org (4.1/SMI-4.1/BAR RNet) id AA22737; Wed, 9 Aug 95 14:39:37 PDT Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA13312; Wed, 9 Aug 95 15:19:13 PDT Received: from ssd.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 9 Aug 95 15 :19:17 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sgJT5-000twZC; Wed, 9 Aug 95 15:19 PDT From Will_Hobbs@ccm2.jf.intel.com Wed Aug 9 17:13:17 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23764; Wed, 9 Aug 95 17:13:17 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sgL8w-000UjtC; Wed, 9 Aug 95 17:06 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sgL8v-000twVC; Wed, 9 Aug 95 17:06 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Wed, 09 Aug 95 17:06:37 PDT Date: Wed, 09 Aug 95 17:05:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Subject: Response to Ballot comments from Interconnectix Text item: Text_1 To IBIS Members, Here are two comments from Bob Ross of Interconnectix on the EIA-656 draft. Bob, of course, is our Secretary. I have read his comments, which are minor and I approve them as stated. I have drafted a formal response in keeping with the protocol established earlier. It is attached. As before, you are welcome to consider the comments and you may prefer a different response. Please inform Bob and myself directly or reply through the reflector if you see any issues with the response. We particularly want input from interested Voting Members and people who were closely involved in the writing of IBIS Version 2.1. Based on comments and possible revisions, we plan to discuss and vote on this document at the August 11 Open Forum meeting. Will Hobbs Intel Corp. =========================================================================== Bob Ross Interconnectix, Inc. 10220 S.W. Nimbus Ave., K4 Portland, Oregon 97223 Dear Mr. Ross: On behalf of the EDA IBIS Subcommittee, thank you very much for your review and comments. Our Committee response based on a review and vote of approval at the IBIS OPEN FORUM meeting of August 11, 1995 is given as the attachment "EIA IBIS COMMITTEE RESPONSE TO INTERCONNECTIX, INC. COMMENTS TO STANDARDS PROPOSAL NO. 3527. Sincerely, Will Hobbs Chairman, EIA IBIS Open Forum EIA IBIS COMMITTEE RESPONSE TO INTERCONNECTIX, INC. COMMENTS TO STANDARDS PROPOSAL NO. 3527 ------------------------------------------------------------------------- Interconectix, Inc: Comment 1 Type of Comment: Editorial Reference: Page 20, line 12 Suggested Change: Change "Sub-param" to "sub-parameters" Reason: Consistency Response: This change will be made as requested. Interconnectix, Inc: Comment 2 Type of Comment: Editorial Reference: Page 24, line 16 Suggested Change: Change "(General Syntax Rule #10)" to "(General Syntax Rule #11)". Reason: By adding rule "10)" according to BIRD 26 on page 37, as rule "10)" on page 4, the subsequent rules were renumbered. The old reference was not updated on page 24. Response: This change will be made as requested. From jonp@qdt.com Wed Aug 9 17:43:25 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23979; Wed, 9 Aug 95 17:43:25 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzcco06165; Wed, 9 Aug 1995 20:36:47 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 9 Aug 1995 20:36:49 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01227; Wed, 9 Aug 95 17:26:12 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA25016; Wed, 9 Aug 95 17:26:12 PDT Date: Wed, 9 Aug 95 17:26:12 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9508100026.AA25016@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA10342; Wed, 9 Aug 95 17:26:11 PDT To: ibis@vhdl.org Subject: EGG ? Dear IBIS guys, Hey will, I need you to assign me an egg number for this. Here is a word file that has IV curve families for CMOS and TTL to start the CMOS and TTL keyword egg discussion. Please send name and fax number direct to jonp@qdt.com if you want me to fax you a hardcopy. jon #------ cut here ------ cut here ------ cut here ------ #!/bin/csh -f # a shar file for an entire directory # To recreate: # 1) cut at the line above # 2) cd to destination directory # 3) run this file as follows: # csh cat << \SOURCE_END_BIG_LONG_STRING | uudecode begin 666 SOURCE_FILE M'YV08]J\F4.'#AL79-Z, <"PH<.'$"-*G$BQHL6*(#+>J%$#!(",(&3$Z/@Q M8PP:-#R"-'D#ADL8&6W B"%#!@T;-D2"M#&#AHR/%X,*'4JTJ-&C2),J7//JW46:'B@X5B&"!HV:!B6 MH8*&"QHR:/BCH8^&#QJF91BAH82&$QI2:%BAH86&%QIB:)BAH8:&&QIR:-BA MH8>&'QIZ9!BBH8B&(QJ2:%BBH8F&)QJB:)BBH8J&*QJR:-BBH8N&+QK":!BC MX4^&,QK2:%BCH8V&-QKB:)BCH8Z&6S'$0T,]1/:66__ T5 0#0G1T! -$=%0 M$0T9T= 1#2'14!(-*='0$@TQT5 3#3G1T!,-0=%0% U)T= 4#5'14!4-6='0 M%0UAT5 6#6G1T!8-<=%0%PUYT= 7#8'14!@-B='00@R1T5 9#9G1T!D-H=%0 M&@VIT= :#;'14!L-N='0&P;^$T=#46AF MG&WF =50MTUV5U>40,!!96)$A("@QCQUFZ!( H@ <=Q#94&()ID*HNBD MEX,6]9H >Q5ZD1.0H0CFFU**2&:"\U))I5_KCK1;ZC.]1I#<^FJ74.@. "1 MJ !X2>5"<:JH)P!B"DO1;0%4VY"B $"6E"$'X (-I99RZRVX9U%4+H((:NN5 M7) M0^4Q=!Y#Z3&T'D/M,?0> /$Q-!]#]3%T'T/Y,;0?0_TQ]!]#+*[\3X%2ER8U M@@XR!"%#$C)$(4.. H A0QHRQ"%#'C($(D,B,D0B0R8RA")#*DKM(D,P,B0C M0S0R9"-#.#*D(T,\,N0C0T R)"1#1#)D)$-(,J0D0TPRU"H 4 (@)4-4,F0E M0U@RI"5#7#)$*@!@,A0M &0R9"9#:#*D($-K,M0F0V\R%"=#L^&2[ ;S[Z=+AP-(!MD# 1'D M$(;@ 0"')M@A %(1Q"&NY1,-Z00 RG(7B)0%4\!ZRT/DLD4"LO",9AG-%/) MD#*0J2N* !0\(& $.$00/3()GDDM@[VD*ZHB$-;:V517AF R8V <#!**;F M-4T0(AFZDAF&H& "! *A90C -$$X_YO&:I- 6# J585 %<%J@) 0-2A(G6H8)UI M%8=0!6]:E:L=&5!+ 5J6R-JUCI2E:I4@>O:-5K4$_1UU\, *F.%>Q< MZ]H0D^IT+:#0*PP&\%/)UI2P!K3L -8"!0) 0 "EA8XU%HFE8$"P.#5 I3+1L%5 "0,P-9R<2A@ ! N+ Z M5%H.H0E/F ((DF %$(RA#G*P0QE 8(8PM"$-;,B#; 60EG(<$/V0>$* M-\3!^'#(@P\ %WYL&,(2!H (%5C"H)S0?Y6G-?K-SV0" ISSIJ1U\ZI.?_@2- *Z4]$4]* )-8Z R^U0LT14C!-EGD4Q MJJZ-=M0R!%8+1*D-@..8%*4J+>E#?DLO@ ^6LOHZ+$\5*U2B*C6I766JRR=; M6+L>-J]858!6 9 KB+UJSO_+,SE6C+$IC6H;"6Z6P< UZ1#M>>B^7EB@\Y7 MHO]U (&U^EC+JO6G*X"Q1'FL+$=Q&! 3UO:]OR=-?GPVWN,=5N>.7V]P-H=OQTZWN@["K7>YZ M%[SB):]YT:O>";/WS.^-KP#FFW@RK9;Q^BUPXT\J "[^[=EV>]9%)Q@!+^E MP1N.L'LK;&&&8%C##N[PAX7O7J8D>8%5[@HW2D&E%@ C >H"M$40-0IM%:LH MH^ V5.9U.@"0OTOK0S]$U)!^T[4_6?.B)27>/W^(U/\A]W=(_AMR__5Y8E[K MLW\,80_WXDBH,"_;P1#0\'X+"!$-^! /Z! 1B&0,^'X,4"_8X@"4U! :"!$= M" O P X4"_04%GW4H(,@0WW@C$GD"][ P![D"\EMH80001I, ??-0=SD 9OX 8@@#T@ M<%W9!0)AX ;?0P54P 0@L 9ED =WT#W?$P9D0 9I0 =T:(=FT#W;U5W?%5YE M, <@D 9VF 1"D 13X (-H 1U" )0\ 9W4 9LP 8@@ ,OD .M6 ,-, 9OT ;G MDSZ82 =O )J4(=P 1Q0 ;Y(XMMT #$B 1E( ?C]89\*'KGE5YW: :3^'F6 MB(F1* =YR'E\Z(<@ (A,X +;B :7.%YA@(P@0 ?@J$1#((WBA8EY\ 9U )G M4 ;:$P;LZ([>A09]&(_E>(YB0(_C90=OP 9T$ ;ZB +TN(_C10=,Y 9S2!"2 M2 ?@Q9!W:(>2B#UFD +>F 3:HXQIT 9PT#T#F3[EF(MKX :F" )W@ ;4@P8@ M, ?R^(S16(GKN(Q$D(XRF8R8> 9OH(EG,)+ER$1CL :92)'>(JI"(H3 )%T 1"4 1$ )$%F0900$!4 '$>)59N95= M^95&%I9CV0 '\'PE=A$G5D!# 9=+AF)8!A'$9!8!D!F$D( 5$&GXH#"G,&I" M 4( @)A+89?1AY&600.!4C M!'TF9F4/9"Y:EDI_EFAL.!&\E&?"$B 0$O%! "W! "YA P]0 U!0 5!X 1$ M$ 120 1<, 504 1#0 52$ 1,P 4JX +?(03$*9U+P4M356/!(BT#PC8184P M@$P H$RO*1'-)$G/)"T!:0]9@&MQEOEU@8&L!:QT15 , !P,0O]XPD0 !=" M<"GM1D; T*7>%&_A%$;Y!DY1)J9?JF]1QF_J%',W^DYS17#F% " $ "PH #V M8 #_) !S.J<#)0!V4 PD DQ5!]"0 /=7%PD7$511DP0P=$@ KP#Q_&JA[&@ )" "IBC;9 M9J0BMC@284 0049WLJMX 4R\^JO!!*S"&JS#^JN^6JR+<:S(FAC*NJR'T:S. M6AC0&JV#,:W4&AC6>JU_D:W:VA?\ ^.(:WG MBAC\ZJ\ NPT#6[".X0/_@"#F>BR?[L L0 MNPWX\ ?_N@L&NP_?@ _X ^.\148*QA%VQ?WL W^V@\J^Q9W\ U.>[$*FZ\->QCWP T[ \> MP 0;=Y"[AW*[AU M2[AR:[CEBKCBJKC@RKC=ZKC::JWWT!<+RQ=#NQ??$*YX,0_C, _SH!?P@ ?\ MT+9XP0\.\ .HJQ>'\ C/\ Q]BQ?M< _MT YZT0_]L ][<+EVX1A^X V9FQ=[ M\ VW< NO>Q<)ZPT)FQ>.<0^W8+-X\17]T [OH!?XN@=[4+QV<;S)BQ?+V[QZ M\0/1.[UY4;W7VZM[^P_:6[O_P+S.BQ??$+YZ<0Q+6[[2EA?IJ[SKZ[UY\0[P MN[_SB[UU<;]X40_YV[Z[R[_2JQ>3:[T 3!>TVPJTFQ?Y<*^YJ[SOX ^^2[W_ M,+P-/!>?.PN?B[^CJQ?^ *^IFQ=2VKH=3!<&S+?9VL*!>[YO <.#*\/_0,.% M:\,X?+@Z[+?6MA<[G+@][,/$FA=!O+A#[,,O3,1%C!='W+A)[+=+3,13K,11 M[,(RS%],7,52;,./L,4V/ A@O!> ,,9Z 0@_0,4V# @/H,9D+*56O!>P@)Y8 MO!>( "Z6\-[(0L D,9=O!>, !M_,=Z<0M<$<=ZD0N,@LAYX0OPT,>$;,0# M,L@QO!>L&Z61C!<@# DV3*W9R@O\P YX7,=Z\0L_\!/P6LFE_ W,P,:D;,3G M, ^'K,I&O _]L,BT[,3\X \*XLP_\0 Z0/,UO M(H/2Z[5_ _8K-$W_!9L^\BI?,]R<8=&>G,29.P_(D#%%[<1RD;G\( _%C,0NW1F\1G3=6C_--,/<__P _V8-5PC=4U+1?]0=07_=5?^Q8QK=91 M[=<(<@_;!-7+6L4(D@_@8-=K#;IT/+3^,#Q\?:U(,V6'<7M>P[GU-= M[=%RL0_H\-:;[=?_\+MSS=4A/=BAG=)ST0> 4-G1RL5G_1:> 2"G=A1?-LI MS"L-LZ'<70_0^? )E?-JO M';7GH U@X-/.W=UTD0_D G'C:Q<;+(,DP]DT-S5C=KL+1<^ '4+:SKW<+? M0 BF/=YQ+?@ F.K=Y7[-OM; [N4MLA7A?SD ^:'=]T$(7^P?K@>' "DS5?,W9;,YT<=TS;*HLS> %#='^W,)(CM:R/- L M_A;GX.3QW,)1^Q;H3.-5#@YHL,_D;.1SL>7S/!] SJM"+N9O@- 2S3"[^P_) MT-55GM)L_LYO?M0Q_@_R P+OJO = _VH-&#/N@P;-%?P0\@<-]W DSX,,$F M/<$P3,,EFQDU7M9U0<,V6X)IWNA7G-IV8;/JO.1J_ND'GM7WNN+&:NIV,;W\ M$ PY/:[R3>%T<=8P 2=GJR?ON%SH;3, .D[NFS+N)YS><)5>=W\0EU0>Q> MJ[#3C>QVH>PM?AO,:L/;?N3=KN09KA?CKMQW M\;OW %47NI[0;QT8>:@7M+$$.MP&^]U0>_BZP_CL,ZKOA>[8!=0O>$X @$ MKNL"3_!V<=O, )_'NZ0'>H-+Q=3SN1ZT0L4O^QRP0]>#N@VK/%U<>H(/A>] M'.0V[ MV0?)R_19:%.P2KQ\+A?0[0Y$\.Z,D:TS3Q M8 2,SO9E_?/T?NKG$ G]G>TZ;/AW4?/[ Y 0/>$'^J.W^H.SMP@#\3,#M7$ M[@<1+NREW/D5S\(-+?I&S.PTS.//H T S_A _/6KO^SD@/"H[\2R;Q<\3F%@ ML/=$7\I?S_)(W@_\@%NW7]91+OS[_@=2LO:_W^LLG/Q0'^H>3OE22Z[^@,S* MS,S.W >8C_4C3^(PC[<'8@]$KLW<;.8_W^QT\0WY HZ7_7X[.3F;.;,/M_4 M[ ](,/C/_P_NP.9;(,O9/VI'\_Z!+5!["N\M@ ,W "-W-/#>W)A1"PY.4#0L#_MA6YHFN$ MCJ/9+*^W[KB=/\@*SD\$ECE(!^DZFMNK@7[O/U@_%^C2?N#W4W?_(*"%0+ZP MQ$@>OP-_YP -Q#_RA]6O$T"")1A+>M@;-'LL["VX S#0 IE@#U-]<##3O30/ MQ_3\H$L#A'>O_=4TK'P \N[?BYM *; OS;/G $P M&'^&D*9)0T$8"?'5/8 !=/!'1<- ./)"H6/(!_E)_C&U#0@$RQR<\P>R3!WB M-79X!.>"9 MK:*SR<4.+]O;NH,GZ!F &[9"H,8,16%=N%PVZQS\%'V8!SL@ M-:QU>,]F[0-1QA"[((!SAV#0(HJV?B#+6*$X!&I?\.HU1%#GM*ZA+<1K(5$7 M2D(*YP/@@"_47$R-Y4&U4RB^O@$NZ(,?D:GY0R1H$&5A2G,&BT\' K6=:/.. MX%GS9L]0*.K$:?@0J1F,6U\>3R#6+Z &"3$B1$2!D\LE4L%N5Q7AG$A<6/B* MF&W%CP?F#YNA/^>U M#5X7_@-PX =Z8_L"C/5P-3I%DO@/E)IT? L0+0/JN4AX%4>B^!)??X"KY< ? M]M#X&9Z[CHFP/&I$GX@>^4$CM(P%S0[$0$.G'56C2)P+JNVLG36;!0*D(GM\ M"R0MTKTX&$;O3J'2.FN9JQ,J1;SF$!MD:I1K2BMSV0..R3>^Y#Q,40NK(4UN6;<$#R0%'+]T3#4^-=8Y%NHA/@QM,G(Z2<2W8); M4%K8 "=6L1T9"M^BCRQV)&X]5K&V6"2?8K/#BPCN/@[$N,8D#R(>9&_5[BWP M W 0 I?DA;2+Y'%HBZUV?;&<211MZVM# MKD4*61L+FJ-TCN)K'^2#,L@%Y>1OO(*144 ZQWW@#\#!$%1L(#)$SD=1Z1,= M P[8>UP,._Y'5(<"'Z1RY ;\+U:FR AX(966KSQJM'#MZ4KR^!8M)0I$BS-L M'TC)G$@A*^1=T),K$NC]@BU)]2Y;DRR*FO"O04G1A@<&'Q=+B8F15RK')^D4 M?4%CA)&;$4422P\X+A4CK_P&H(#R?4MA.">=))9DD_CJ'2"#B,?%B*1_+)9# MJTXZ!MC(Z/KEEVR.DA' 9<;UM0^*HXG]ZE#/L*XA%D;D9HQP'9'GM"V5N. WX#8HC%_N4 MH6VL6D"^M-5LI'6ND3?R58^P7YP#5BS!2(Z)[E$51:T=(#Y)'7K35W62Q3()@-FR9M>T6RW92MIIRKEI,3$ MFG024BZO]<4H,)RV&YH>S5_*!7W0*.M=O\M^)>V1-;=LM=W$I<];?R2/;V[' MG7D@_($_<%G\P)O4!<*INVP9S5M_;P"87:X0-@W>P@1["Q;KBUF-#^#;"*=/ MLUUU(1ZLOSL S-K7PNH&[=(8_(//]0T8Q0 HG9>1+LC% V&OYEW\PP-YC*(- M,G^0QKR!'TME+6MDG8,,LT7LUES0?CG.F96GB. \Y4)L+')_8-Y,3P)2/=L9 M/WMR'B9<.L>W23;[YMCTB=W$YWU/ ;@7:9T&XPOTKGNFM.]IY&P8++R2>2%^ MHDL,: *'P=J[GRJ1A#G&^6G0Y%DX>&(2S@+NQXXF#ES7*_.<):T',K&'.4&! MYA;,915T:690^;E!.6@'39\?=')>4(<60CUH8/!MA;/>X06>^1WOPCT(!O\@ M'(0#;W /@ 'Z\@:^ !B,@_550]%7,! 'WN <1$#D-4.#@3<0!SLT&(R#<# 7 M[<(ZF%S(JQNL@\R%O'S!-YA<]^ >4-&QY0UV*)?K!E'T'G@#;H!%Q6@3K0M/ M-+5Y@VTP16^H%>5R6A1]B='MM;X0UC?8!G/4 ^I/ENE$)]*,\=(LBKU[J#=J!+,VC_T"(LCQ%J4UA:!'-H>AK'L#3 M?W!-J&@PF*%S 1 $@WE01+T!$Y6%I+2%EE#(Q=U**+H/#!2 M E+PI0CT0P$H #D 'I@ P H,X"H$0 ,"(*[B&;T05S>&#-"KR" A 2]:@?X@288 P=@ MSP0%Z3EQC)(48$VK! (&@! : " H0$ B(8H3(?,,!X" !! E! B5RB-: $ M7E(,D DP8 @LFG]Q%Z3 %V 03 *4($8\#28 FEL2D<%9NDKGD2'T]!]^ %AX#7.I-<$!9D%__;IMTA2ECFN02:G(R M6>9(/835L!:^0JYA0E^5(8"#0O )Y$$^> )H *L@DB0&5; "9@%V6!G !8 M@"@XB'OQ<&(5 ' #C>(0%(5)(0&*8JH@ 45!2=B HA@UD$!1U!A:H"C^!390 M%.N#'RB*@0$"2FR$0!2-1@HRA((! !@!HN!5&$-CZ"8=P 6N0!)P E?@"10G M+D %LA(44%!=E@LX 2W+H+H1$7@"+\@I8 PB98S(D3(* \R(], DSW.3J)$D MTD/:I0_]H4#DC:@ .'))?(@WH'<6C>52/WM$8P$=N0!\- M6A#0CP M0!)(!&F\&*1;=(X4$E1Z0[C(&D$D.2"11E%%,@,7*2-M)$S4D3Z2 M' A)V@,7#2*3= >T6^3P2R@@,(FH 4"BN(RHRB%M*F.0*Q?E-F"4C9%1FZE& M01$<-5=V% #H47&KSP0I-1-@9I6"I57=!@"TGB75I A&_\!D (!*=04KA:6T MU!@1(R"UI983C=I-R,F],5/N=M]D$X_:3J2(P!DB<,J;R"DZ9:?PE,)I57UJ M50DJB4.H*@X!052&*E$L*DO2J%K*H_(H(8>L4"J)8ZD80J.YJ*/EW,*%3O6I MZ , ^+5#@%0! %,EJV(5G0!4":!5O2J3JP1F56Z!!K8J(N JC9M0E]I"C:C( MK>:2-81J5AGJ!L6YEX[GFE6@"^)Z+M&%=B'TZ)Z[Q9"NUE6[>E?Q:E[5JY8W M%@_#Q@)8 NL?$"R#A;":8C$=#%?7:DTL@_4/+-8>': .JU]Q+(\%LBC6R!): M%9$P'"V U;)>5LR:634K[@Z&N9NT+M8^Z%D_*VC%0H%Z&/BNTF):70MJR]C,[VM-_;FA?NW*_'">ERG)O2E=:X0AA="UPC+"Z8+=8&[ MU:7"^"+LDET1C'O=K@K&O?Y![\*];R%X<3#C:[QNJ/IB7_E3826P\?6_J&_V MLK[X"_OF!?"U??$"^>J4 NPN=*\C]K[*[UV07PS,^P8P\-M\Q2]>0& %+;% M7SXZ%]*O72!@]O> ]:\5VGWYKUQX8,GW+DPPW(7M^L$%RV#<=_H:X)?V#T"8 M^OJ]S\N$@;L4YD GL-M\H)L1!#-%A1J",>@(MKDEF(0V2Q&\)UGPQG3!\S&3 MI6 2?()W;@LVP3=8!<]@%%R#2V_OY9 2];7!8+GPQ=R87A!C1C@OI- A_!;R M(2/#"[N3"=/3]OEZ\\(<2\)XX8Z5R)R[QQPFZK4+@.!).']Y0675O&03:1%M@-!V3*RV\1LG_@;_[?.]MG><+H<;:5M(,.^ MUZ;:MAI"=L6;D=?)MG"XAC>C;\MM0+@F0T#?]@Z FTF&@,0-(S/CC*G<--]0 MAH#0S1](MYRLAULF7V]<^07G ML?K&E!]Q"M1O_$TE+]ZS3!<$W$NVQROXU"4X<2R58S VG6L0KBSKW0[X\RR< M-]YY5^SG=;BW3)!;,+%[!R2.)J]EPXSB5)P^+H7%L@/R.!GW\5RQ)HZ>.V[Y M_3AV'(K/'YF#FZO1W-4X5/SDUJ64"\F;3RYPZV*Q!7[!#[&B<3B2OX+LLS$:==B[!+"]S--D-RO'93]X=C YVN%//6?MUO%5Q@OI MSEYJQ&\7H.M"@@9Z#5$TH[R]\* G;[UK=^3YZVZP:PDI\\&]:]!T0=Z=3PKG M[_[R7AYX5C);'CQX7)[M HHFG^SR'SP\X^QYZ8(6R\&W[>)-Z(S'%&\;;-[/ M=D'D$WH1I8S;U[.6])LN$E[,*$'IK\PM)TBGYI:4\MH]U,5Q!C<#JC M@&&:$-?>#I@#])Z1#G4D[^V=NL#7G#OE#+M\Y3# *3XY;:AO&*)FCO=*\K%H MPLO"'K6Q['A&&3!SOJL9H^4"Z"O4'GB&D;[^_ M.GZ8>?4R1];D^JSPI&7&J MIGW+$C+COE?=XO9![SO37; N@F:%5?Q M0@%8M)O5S[.YG>J(_,O"-;_J/1[:_]Y>AL1 9]:]6@ R0?LJS+@V?)2">UL,7D)^)1WIX@R>7/0"!:Y@$ MND<3R*^M,[Y:@;X:1L+ 8^P#!S2DA'XWT$!3WO8&G26=0Q34=T\('FA,5Z?; MYE]3@AN;XH%+C^T6HF"WKLX6<62/3Z^8!5UO$^30]UG/C4%.N9CS(%'LU.-Q M#4[J1MW-.#4E9I-RD$:K9YIVLW\V2MN#"7N)=<7RV1_G 2&4U9AN:4_>W]4/ M&.'.#M4=36H'Z^P'IO>R1$32DW?#<<*3G7NUHZYNEY?Z#Y!"LRP(SS:9CM&J MT E[[;#M%@UG?I7&]1FK0488_;;> 2\DVR#T%N;,6-BWBR'IM5;)4%U?1*PY MN9PAJQ[:1JU2?F!JB*^L(7TNV\),-!%TALR\W>W$IH)^ MV#7Q)C[O_EBT(>-1!(IJ>8J5;Z/8SIPW]]YX>G-7T[H'&16K;D.4VMO05F[O MB)9+'DK4T,[KXAY&PTG6HQFCWN*$?!U33:AI&&CSU/,;9]N_QRI,W0$ M']Q",TLJX_?-#34F?(9N6?(?,,:!/,7V]@?7B"4+BUSM8X49(;3AM,X8:S)^ M1M\,3$:CL[YVD_?^I<0U>0^4YG>$C9[9-RIN[HRQ_.0^T(W\>WW1YM -J=DD M;KQ7Q-$J Y/CB*[1]O?NW4Z\)GXMNKP6J2-M'LZ@TCR*MJ]@CG.D7 B/)M") MRV_I'3.=8WJ4V)#[%0_L-RRG>.XI!S3Y.:B%GC O=@H3959)5$DA,#$P2 M9 ]L7\H[5:I06PGJ$F6KCH@PVT&B0 W)(:N8]V;:X]-H3B\26:-'XB6GV\7. M1KK(3CX?X[<+C]%1\ZQU;7:*]TSYVT:?1U*N!4E2+B==>>B.Y0LK29IQ"KG M7_G;PN51$AY[2='-MYMC"*>6NQPQ]G(P/A['9((PDTG,@T]N-=D9WX*;?.21 M49IO;M=<)YV7-R#,/O VI?-#E0X[/E]$5IDI2^6I3&),W'7+259YUEPEK(QB M=?R%$TVC>=:^ J[$YS$XHN/LAVTTW]9"D]C#4GQB\OE=[-[6+U"6UL]:)NLK MON&B9N6:EER2E>_)1%Y[6SH%YY;>,HI%;QH9RQ&$US30\_)-B_3;AB!"N"R$ ME_)2I_ML)N[,AU:^W)<\6Z%O' 5F2KOG6-N (5Z[!PVST]DV ML,W, 5P[_PH6$^8EMV@-GXMXQSQJ(-,7KG6\.=4OU\D9[/*V92Z?&>R"YIX.Y+72*2)-'Q['0W#35.0;#FH" M/3\ZV1JCU13J\MM'C\O'Z0%_.MAL<*#=BI=/9^Z\\F5:5)LVC&UB\>M)\ZR0:<"9-+A[.Z2E=!\Y(^K=3.,9YL1PGY)23CM0N9L<9OS+73.DP8Z_X'H9 BD$W/3T].)Y%2G76"=+=,Q704_3J%ZOC>[6:$%< M>V[/ '^NK&/XE-\W^VS71E^%'--?^\R_5UQ;RU];;#_[0N==Z7O=>QZT_OD_ M/7Q?.+L4?H[;K ,J@PN='[=9#50&.^//:<98+^R]\38^Q]_<] RB&RJ/!]*" M 86:S^4MO3%Z*8VA,[2'5E$=RD-MZ"4%HD*4RQ'12WI$D^@2U=!I-(JVT6X* M2N4H-^BB$1",GM,Q6D;I:#+OHVJ4C5)1'&I(Q:DBM:-X=)S*PK,;XN]"&OVC M@31S#=)""D>W:"+MI8STEW*#2#KG-?0QO:29=)-VTD\:3KOC*.VEIA25JE(L M^@]::1*_"X<^F?Z#6GI+<^DAU:**%'G]TF":2_\!,;WT=B'3S])*STR=Z:>/ MIE)^FMZ#:CJYKBGTQ=K;](:R>?3U3=N\')7S4MZ<5E(YKTXUM"]PIY<4GGH# M>4I*ZZD/Q:=R09_R4RK_3R=70*7E&33T5NG/N^-EKXY/O=Z^V^/X'5]1,6Y& MU9[KA*.NJ72_3=*M2&44)?6DIM25JFYM2SFAMOR&6-V>FOI%/&Y.G3@\]1_P MGM\#5%V 4"6J1A6I.J6EVE2?:E0M U/U$4VD?815WQ !N/@8/^-K_(VO\;>J M@>VJ"+;/7-LM@W7.A9#2N-$J):VDEO22\!"=!3V'%LX6VIN4B7+23HJT/LG3 M!J6A=(>*DJC-14A)*3&EI)J0%M(<@@H88WT0@4N4!D! %*@#BL@H)/T(P?2= M/M3?'$2!LQJ"(L ,B$&L20KSM51H?:[O]2N%^"$*U 0JI/VG$/8'!<9@LIGI MV&P/1 0^Q =%6/MJ]EJX!Z> ]T,(:2(Q=RF%>'R+<&)22%Z:-B,_K);\-%%6 M>Z[C?_QF$%'H 6VQ![2%(M 6BT!;, )MT0BTQ2/0%I! 6WP"[Z,M0H&V$ 7: MHOLPA%2@+?I!IGH'Z. >N'X ZR0::Z!@4^]^O^W<_[>[^=$0!UH"PT@.!/ M! C #_@"TV &C('=L 0"P ,@_L8?^<\ )D$ [$ :/[#/P 4_WW0!9+_\@< MS?_Y:W\"P/V3/_6W_LU_ 4!_A_#]!\#W_S>(8@@@BBJ *-P HG@#B,(E,H3) MSQ <@>=/_=H"<10 ,AP*(C !* !N 6@0 & =@ <@ *H .('%$ "R #2 6 MX T@ F@[Z,( M0<)$P $LB1%0A^P.%T'XH8/X$.1*[@$"O 6YA10H$2 *K)\.0FVH?AF%'G 6 M* )G 2-P%CP"9\$G!%C@!Z 4P#]0 0 ";V <. <." G TC>'6'V* MB 4P!%!95A:6I649)W@6-^*@# %Y8-7W]"DB#D 00&45@GS6F34$_ .O56RE M!])6MA5NE8X, 0%)]S %S("O%@ 07 U7_P%LA9SX5@P";"5;S0&8H/9P6[D$ MFV G* =\@N,(%.@9 !($@(2P"' %[P(/DF54!M 1K=(:E 6<55F #!1&,51 MX NN"ND!? $LP%TDQUH054R#9<3,Y9Y !-)@&?%% "&JX"586[F"FF >(@O2 M@J&@0Z X(*Z("]H1H@?90$P&$SD%L-@IL 6'(/_0#)H%"R#I4(SJ"B8+"5+ M-%@-_H.^H#4(5F6#ON"+P6+,*=05[$ 91!F 0)TA$;0'%8 %8'@ %1 1W)H M.0%E0*TE!U9.1^*$5*9;)1VT9>)!? M;"@;SH8[W@=H&]Z&N&%NJ!ONAKQA;^@;_H; 87 H'-J&>0)UQ2>$)]*5:55= M 0"" AM2*,0M8 1%89D\#Q8!I" ID N8@J;09W@9H,)\DBRH5Z="KK1,7 X. MP:NP',H*U%6M\&7@"LHAF;%H^ IIAKVW*KPJW\=#D%8M"\JALT!=K0Z>1B11 M+F +V8=1("Y\"V;?@/CU15CK0KND+B ([8)[85(T&NL#)3%5C!H<1(WQ+T 7 M P.314LD#&E"P^ ; ?" 7$@<8!WRD%#X#&PA"&#=$ =6 ?809K0,H @X(%X M0!Z8!^B!>L >['WP@7S@<1D-^(%^P!_X!RM"FD U)(C_@-5 )&(-#T*$,"%4 M"!="AF!YH T?0H@P(I0()T**D";<#=I6C# CU @W0HZP(_0(/T*0,"04"4=" MDK D- E/0D. ];$2GP, $#H *-#=M4E? EAPIA0)IP)#<'L #4#LLA[@ G MR ET0D-P9 P/4L-BT&(8A,J# 6%J #0PXA@;,PHVL/\4/>-#^5#+:(^_!CS M _S &@(.B$C]4"GB#_K#0X :AGR('ZU"EP0A?Q^5P54Y)A3!7N(0U!IPPP61 M06P010%BHI@H!:;A1# J'G[78)%2:[P0,031D6O4$#H(#I&B !PLBL G;+PH M0T2,HIG0*,F&C0( R!0YBA4! & 1/$JT\:.X)].6?$A&6%NFHA>1I( ;_<.X M 0#0$>9&'I%N]!$!![M!:4KS!+?"6X27>42O!\O$4V8%-N) ML#!,1(S'!$4XGO1^YXELHBM$$],$1."E7!,N59E";YPI9 J[-4[8&_)6.N%O MU%MNRF>1;]T3^<0^T4_D*0Q'GV)0(!2#2D/04"1%SR(UF!]J1 *@= T!D47 Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03805; Thu, 10 Aug 95 08:25:47 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sgZNw-000UfiC; Thu, 10 Aug 95 08:19 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sgZNw-000txhC; Thu, 10 Aug 95 08:19 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Thu, 10 Aug 95 08:19:04 PDT Date: Thu, 10 Aug 95 08:14:00 PDT From: Will Hobbs Message-Id: To: jonp@qdt.com, ibis@vhdl.org Subject: Re: EGG ? Text item: Jon, We've had Eggs 1.0, 2.0, 3.0 and 5.3. The 5.3 number was self-assigned by Bob Ross to refer to Bird 5.3. There never was an official numbering system for Eggs, but: "Hear ye, hear ye, The new Egg is hereby assigned the number 6 and from hence and forever more, Eggs will be assigned a unique sequential number greater than 6. There has never been, nor will there ever be, an Egg with the numbers 4.0 or 5.0." How's that for formality? Will Dear IBIS guys, Hey will, I need you to assign me an egg number for this. Here is a word file that has IV curve families for CMOS and TTL to start the CMOS and TTL keyword egg discussion. Please send name and fax number direct to jonp@qdt.com if you want me to fax you a hardcopy. jon #------ cut here ------ cut here ------ cut here ------ #!/bin/csh -f # a shar file for an entire directory # To recreate: # 1) cut at the line above # 2) cd to destination directory # 3) run this file as follows: # csh cat << \SOURCE_END_BIG_LONG_STRING | uudecode Text item: \SOURCE_END_BIG_LONG_STRING cat SOURCE_FILE | uncompress -c | tar xf - unalias rm rm -f SOURCE_FILE exit ( 0 ) Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: EGG ? To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA10342; Wed, 9 Aug 95 17:26:11 PDT Message-Id: <9508100026.AA25016@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Wed, 9 Aug 95 17:26:12 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA25016; Wed, 9 Aug 95 17:26:12 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01227; Wed, 9 Aug 95 17:26:12 PDT Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 9 Aug 1995 20:36:49 -0400 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzcco06165; Wed, 9 Aug 1995 20:36:47 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23979; Wed, 9 Aug 95 17:43:25 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 9 Aug 95 18: 15:20 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 9 Aug 95 18:15:32 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sgMDe-000twrC; Wed, 9 Aug 95 18:15 PDT From jeffbatt@mdhost.cse.TEK.COM Thu Aug 10 10:26:06 1995 Return-Path: Received: from inet1.tek.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04653; Thu, 10 Aug 95 10:26:06 PDT Received: by inet1.tek.com id ; Thu, 10 Aug 1995 10:19:38 -0700 Received: from tektronix.tek.com(134.62.48.24) by inet1 via smap (V1.3) id sma017865; Thu Aug 10 10:19:16 1995 Received: from mdhost.cse.tek.com (tekadm1.cse.tek.com) by tektronix.TEK.COM (4.1/8.2) id AA10926; Thu, 10 Aug 95 10:18:12 PDT Received: from cauvery.CSE.TEK.COM by mdhost.cse.tek.com (4.1/8.1) id AA06646; Thu, 10 Aug 95 10:18:50 PDT Received: from localhost.TEK by cauvery.CSE.TEK.COM (4.1/8.0) id AA08624; Thu, 10 Aug 95 10:18:49 PDT Message-Id: <9508101718.AA08624@cauvery.CSE.TEK.COM> From: jeffbatt@mdhost.cse.TEK.COM To: ibis@vhdl.org Subject: Birds & Eggs Date: Thu, 10 Aug 95 10:18:49 PDT Sender: jeffbatt@mdhost.cse.TEK.COM Gentlemen, Would someone please explain the references to bird and egg versions? Regards, Jeff Battles jeffbatt@mdhost.cse.tek.com battlej@holmes.ece.orst.edu Tektronix, Inc / From jonp@qdt.com Thu Aug 10 10:43:05 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04774; Thu, 10 Aug 95 10:43:05 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzcfe02475; Thu, 10 Aug 1995 13:36:26 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 10 Aug 1995 13:36:18 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00557; Thu, 10 Aug 95 10:09:52 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27974; Thu, 10 Aug 95 10:09:52 PDT Date: Thu, 10 Aug 95 10:09:52 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9508101709.AA27974@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA10842; Thu, 10 Aug 95 10:09:50 PDT To: ibis@vhdl.org Subject: EGG Half Dozen More Argument on EGG Half Dozen. Hopefully by now people have the hardcopy in hand and can look at the two IV curve groups. If we have no argument on how they look (at least, in general appearance) then my problem is this: As the "control" voltage changes on the CMOS gate only the IV curve strength changes. The zero millamp point stays constant (at ~VCC) this makes sense as all we are doing is making the CMOS gate more resistive. The TTL gate, however, changes its zero milliamp point, it being a totem pole arrangement and all. The point is, at risetime/2, what is the proper thevinin equivalent for the driver? You have to know if it is CMOS or TTL. If there is a fool proof way to determine this form the IV curve alone, they we are done, else I would like a new (optional?) KEYWORD. regards, jon (I hope I got this HALF-DOZEN joke out before bob or will). (If you still need hardcopy, let me know. Won't it be nice when I can just post HTML to a WWW EGG discussion page?). From speters@ichips.intel.com Thu Aug 10 10:54:55 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04873; Thu, 10 Aug 95 10:54:55 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 10 Aug 95 10:47:06 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 10 Aug 95 10:46:33 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 10 Aug 95 10:46:32 PDT Message-Id: <9508101746.AA05851@xtg801.intel.com> To: jeffbatt@mdhost.cse.TEK.COC Cc: ibis@vhdl.org Subject: Birds & Eggs Date: Thu, 10 Aug 1995 10:46:31 -0700 From: Stephen Peters Hello Jeff: Bird stands for Buffer Issue Resolution Document; it is a formal, written proposal to change the specification. An Egg is the informal proposal or idea for discussion that (usually) procceds a bird. For an idea of what Birds look like ftp to the vhdl.org, go to the /pub/ibis area and look in the bird directory. Hope this helps. Best Regards, Stephen Peters Intel Corp. Gentlemen, Would someone please explain the references to bird and egg versions? Regards, Jeff Battles jeffbatt@mdhost.cse.tek.com battlej@holmes.ece.orst.edu Tektronix, Inc / From mbs@eos.ncsu.edu Thu Aug 10 13:39:12 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06178; Thu, 10 Aug 95 13:39:12 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA15517; Thu, 10 Aug 1995 16:32:31 -0400 From: mbs@eos.ncsu.edu Message-Id: <9508102032.AA15517@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS v2.1 update Date: Thu, 10 Aug 95 16:32:31 EDT S2IBIS v2.1 is coming along. As projected two weeks ago we (NC State University) expect to make a beta release in two weeks. That will be August 24. Virtually all v2.1 features that can be supported by S2IBIS will be included in the release. A big feature is that a yacc/lex input parser is used. Thus future upgrades should be relatively painless. We were able to reuse the analysis routines from S2IBIS v1.1 We do not use the current Golden Parser header files as they had changed fairly radically from the initial release of the header files. Too much time would have been required to modify the S2IBIS code. Thus we will not be able to distribute routines to write a *.ibs from the Golden Parser data structures. After the S2IBISv2.1 beta has been released and verified we can modify the S2IBIS code apropriately and support data structure-to-*.ibs conversion. Thanks for your patience. S2IBIS development team Alan Glaser Steve Lipa Michael Steer Paul Franzon North Carolina State University Electronics Research Laboratory From huq@rockie.nsc.com Thu Aug 10 14:41:01 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06632; Thu, 10 Aug 95 14:41:01 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA14013 for ibis@vhdl.org; Thu, 10 Aug 95 14:34:20 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23579 for ibis@vhdl.org; Thu, 10 Aug 95 14:34:19 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA26795; Thu, 10 Aug 95 14:36:46 PDT Date: Thu, 10 Aug 95 14:36:46 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9508102136.AA26795@rockie.nsc.com> To: ibis@vhdl.org Subject: EIA/IBIS FAQ - Rev2 IBISgurus, I would like to thank all of you who have sent me comments and suggestions and changes for the FAQ. I am only sending you the items that I got feedback on. Each FAQ follows with the original answer and the suggested changes. I would like us to vote on this tomorrow and move towards the next step of publishing this on the Web. By default, I will assume that the rest of the FAQ's are 'ok' by the forum. Best Regards, Syed. National Semoconductor. ----------------------------------------------------------------------------- 1.0 What is this IBIS stuff anyhow ? IBIS(Input Output Buffer Information Specification) is a method of providing the Input/Output device characteristics through V/I data without disclosing any circuit/process information. It can be thought of as an Analog Behavioral Modeling Specification that can be used to model almost 99% of any semiconductor in the Industry today. IBIS is mostly used for transmission line analysis as well as Signal Integrity analysis. Raj(Contec): > "can be used to model almost 99% of all semiconductor". I think we could > just make it "most semiconductors". > 2.0 What is the "Golden Parser" ? The "Golden Parser" is a shareware used to parse the model file to check if the file conforms to the IBIS specification. All model files need to pass the parser before a model can be released on the Internet. Will(Intel) & Bob(ICX): > * The "Golden Parser" is a program called ibis_chk that parses the model file to > verify that the file conforms to the IBIS specification. It is free, publically >available executable code developed by contractors for the IBIS Open Forum. All model >files must pass the parser before a model can be released on the Internet. 3.0 Where can I find the IBIS Golden Parser ? You may download a copy of the executable directly from vhdl.org(anonymous ftp site) under /pub/ibis/ibis_chk. To obtain a copy of the source code, send E-mail to: ?? Will(Intel): > The parser is freely available in object code format for many platforms, and can > be downloaded via anonymous ftp from the vhdl.org BBS (198.31.14.3). It resides > under the /pub/ibis/ibis_chk directory. > > The Golden Parser source code is also available from the EIA IBIS committee for > a fee. In addition to checking syntax, it creates data structures from model > data that simulators can use. > > There are three options for licensing the IBIS Golden Parser source code, > V2.1, depending on your membership status in the IBIS committee of EIA: > > 1) If you are a current member of the IBIS committee, you can license the > parser source for an additional $250.00 > 2) If you are not a member, but would like to be, you can join the committee > and license the parser source for a total of $750 > 3) If you are not a member, and do not wish to become a member, you can > license the source for $500. > > In any case, submit a request to: > > EIA > 2500 Wilson Blvd. > Arlington, VA 22201 > (703) 907-7545 (phone) > (703) 907-7501 (fax) > > Enclose a check in the appropriate amount made out to EIA. EIA will take > care of distributing the source. 6.0 Can IBIS model SSO(Simultaneous Switching Output) ? IBIS as a model, has all the parameters required to model an SSO event. These are mainly the package inductance parameters and other associated parasitics. Modeling an SSO event is more of a simulator issue than IBIS. Raj(Contec): > .....regarding SSO could mention the advantages of using Ver 2.1 models > over Ver 1.1. The use of a matrix for the inductance accounts for the "loop" > inductance i.e. the mutuals between the pins are considered. Usually > the mutuals help in reducing the net inductance. Moreover, Ver 2.1 contains > information on which driver/receiver is connected to which GND/VCC pin. > This information is vital for SSO simulations. > 7.0 Why do we need to sweep to 2Vcc ? IBIS models are meant to work on any simulator platform, SPICE or non-SPICE. But on a SPICE platform, the simulation might not converge if the end points are not specified. Most non-SPICE based simulators will do their own extrapolation to get to the end point. So, to make the IBIS model function on all platforms, that data needs to sweep to the full IBIS range, for example 2Vcc. Raj(Contec): > ............ reflections caused by improper terminations can produce > voltages at the driver/receiver terminals from -VCC to 2VCC. The drivers > and receivers, therefore, need to be modeled over this entire range. > Will(Intel): > Simulation accuracy is greatly enhanced by the "beyond-the-rail" data. > Overshoot and undershoot generally fall within this range, and the range > encompasses the forward-biased regions of protection diodes often used on > buffers. 8.0 Can IBIS model GTO(Gradual Turn On) or Slew rate controlled outputs ? IBISv2.1 can model RTC(Rise Time Controlled), GTO(Gradual Turn on) or Slew rate controlled outputs. These are defined under [Rising Waveform] and [Falling Waveform] keywords. See IBISv2.1 specification for more details. Will(Intel): > Add: The waveform tables can also serve as "golden waveforms" to check > simulator accuracy, since the load conditions that produced the tables are > specified. That is, the simulator should produce these waveforms when the model > is connected to the specified loads. New Additions to the FAQ: Will(Intel): > 17.0 Can IBIS handle devices whose output is non-monotonic? > > IBIS can handle non-monotonic data. The parser will detect such data and issue > a warning in the possibility the data is in error, but will correctly parse the > data. Whether a given simulator will treat the data correctly is a question > left to simulator vendors to answer. > > For problems in modeling I/O buffers that IBIS doesn't adequately handle, the > IBIS Open Forum (a.k.a. the EIA IBIS Committee) is always trying to extend IBIS > to be more useful and has developed an excellent track record and set of > processes to move the standard forward without harming backward compatibility. > > 18.0 How do I become an active participant in IBIS activities? > > To participate in IBIS discussions, send your email address to > ibis-request@vhdl.org (198.31.14.3). You will be added to the IBIS reflector, > which is a mail group used by IBIS partipants to exchange ideas and data. > Notices of upcoming teleconferences, agendas, and meeting minutes are also > distributed through the IBIS reflector. END From huq@rockie.nsc.com Thu Aug 10 14:46:10 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06698; Thu, 10 Aug 95 14:46:10 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA14279 for ibis@vhdl.org; Thu, 10 Aug 95 14:39:29 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23838 for ibis@vhdl.org; Thu, 10 Aug 95 14:39:27 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA26805; Thu, 10 Aug 95 14:41:55 PDT Date: Thu, 10 Aug 95 14:41:55 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9508102141.AA26805@rockie.nsc.com> To: ibis@vhdl.org, mbs@eos.ncsu.edu Subject: Re: S2IBIS v2.1 update Hi S2IBIS team, I am not sure how beta sites are chosen but National would very much like to be a beta site if possible. Regards, Syed. National Semiconductor. > > > S2IBIS v2.1 is coming along. As projected two weeks ago we (NC State > University) expect to make a beta release in two weeks. That will be August 24. > Virtually all v2.1 features that can be supported by S2IBIS will be included > in the release. A big feature is that a yacc/lex input parser is used. Thus > future upgrades should be relatively painless. We were able to reuse the > analysis routines from S2IBIS v1.1 > > We do not use the current Golden Parser header files as they had changed > fairly radically from the initial release of the header files. Too much > time would have been required to modify the S2IBIS code. Thus > we will not be able to distribute routines to write a *.ibs from the > Golden Parser data structures. After the S2IBISv2.1 beta has been released > and verified we can modify the S2IBIS code apropriately and support > data structure-to-*.ibs conversion. > > Thanks for your patience. > > > S2IBIS development team > > Alan Glaser > Steve Lipa > Michael Steer > Paul Franzon > > North Carolina State University > Electronics Research Laboratory > > From Will_Hobbs@ccm2.jf.intel.com Thu Aug 10 18:03:46 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08401; Thu, 10 Aug 95 18:03:46 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sgiOO-000UhWC; Thu, 10 Aug 95 17:56 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sgiON-000twjC; Thu, 10 Aug 95 17:56 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Thu, 10 Aug 95 17:56:07 PDT Date: Thu, 10 Aug 95 17:51:00 PDT From: Will Hobbs Message-Id: To: ibis@vhdl.org Cc: Arpad_Muranyi@ccm.fm.intel.com, jonp@qdt.com, bob@icx.com Subject: BIRD 30: Programmable Buffers Text item: Text_1 BIRD ID#: 30 ISSUE TITLE: Programmable buffers in IBIS models REQUESTOR: Arpad Muranyi DATE SUBMITTED: 8-10-95 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current IBIS specification (2.1) does not provide a selection mechanism for buffers which can change characteristics based on configuration options in a component (programmable buffers). This BIRD is being written to provide a solution to this problem. Using this feature of the IBIS models simulator tools can implement a mode selection user interface for programmable buffers. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword shall be introduced in the IBIS specification to provide a user friendly buffer mode selection mechanism for components which use programmable buffers. The proposed keyword [Model selector] shall have a unique model selector name on its right with the same syntax rules which apply to the model name used with the [Model] keyword. The model selector name is used in the [Pin] list in place of the buffer name for pins which have programmable buffers. Under the [Model selector] keyword a list of those model names should appear which can be used by the pin referencing this model selector name. The default buffer can be defined by a sub-parameter, such as Default. ============================================================================== | Keyword: [Model selector] | Required: No. | Description: Used to pick a [Model] from a list of [Model]s for a pin which | uses a programmable buffer. | Sub-Params: Default (?required if keyword used?) | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Models] must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] keyword and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] keyword. | | The sub-parameter Default is used to point to a default [Model] | to be used on the pin(s) calling this [Model selector]. | | The operation of this selection mechanism implies that a group | of pins which use the same programmable buffer (i.e. model | selector name) will be switched together from one [Model] to | another. Therefore, if two groups of pins, for example an | address bus and a data bus, use the same programmable buffer, | the user must have the capability to configure them | independently. One can use two [Model selector] keywords | with unique names and the same list of [Model] keywords; | however, the usage of the [Model selector] is not limited to | these examples. Many other combinations are possible. | | [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF 2 EN1# Input1 NA 6.3nH NA 3 A0 3-state 4 D0 Progbuffer2 5 D1 Progbuffer2 320.0m 3.1nH 2.2pF 6 D2 Progbuffer2 7 RD# Input2 310.0m 3.0nH 2.0pF | . | . | . 18 Vcc3 POWER | | [Model selector] Progbuffer1 ABCD0123456789ABCDE0 ABCD0123456789ABCDE1 Default ABCD0123456789ABCDE2 ABCD0123456789ABCDE3 ABCD0123456789ABCDE4 | [Model selector] Progbuffer2 ABCD0123456789ABCDE0 Default ABCD0123456789ABCDE3 ABCD0123456789ABCDE4 ABCD0123456789ABCDE5 ABCD0123456789ABCDE6 ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Problem statement Some components have programmable I/O buffers which can be configured for different operating modes. Their strength or slew rate (and maybe other characteristics) can be changed during operation by some mechanism. Currently, the IBIS buffer modeling syntax provides keywords to describe a buffer model in only one configuration or mode. Even though there are ways to work around this problem in the present form of IBIS, there is a definite need to provide an easier and more user friendly selection mechanism for the various configuration modes of programmable buffers. Possible solutions (1) Currently it is NOT illegal to have more [Model] keywords in the IBIS models than what the pin list section calls for. Therefore, the writer of an IBIS model can make as many [Model] sections as many are needed to describe the various modes of the programmable buffers. The user of the IBIS model can change the model names of the programmable buffers in the [Pin] list section with a text editor to select the desired buffer mode. Instructions about these edits can be placed in the Notes section and/or behind the comment charater for the user. The main problem with this metod is that it requires tedious manual editing of the IBIS file. (2) A slightly different solution would use the same amount of [Model] sections as described above, but repeat each pin description in the [Pin] list as many times as many configurations a buffer associated with that pin has. This method is not allowed in the current IBIS specification, but could be made to work if the repeated pin descriptions are preceeded with a comment character. This way the user could uncomment the line(s) which contain the model name with the desired buffer mode. This editing is much less tedious and error prone than the one described in (1) above, but it can be cumbersome. If the repeated pin description was legal in IBIS without the use of the comment characters, the simulation tool could pick up the various model choises from the [Pin] list section and provide a dialog box showing a list of the available buffer modes for that pin. The main problem with this method is that the pin list can grow very long due to the repetitions. (3) Use #Define syntax to compile the IBIS model beforehand with the proper buffers based on a model with multiple choices. There are various C tools that can do this. One issue is if models can be changed dynamically such as might be done to optimize a driver for a certain net. This method has the advantage that it does not require a new keyword, therefore it can be used immediately. However, it requires an extra compilation step before the IBIS model can be used. This contradicts one of the main goals of the IBIS specification which was to provide simulation tools with models which can be used directly. This method could be used as an interim solution untill the new keywords are defined in the next IBIS revision. (4) A similar method to the one described in the STATEMENT OF THE RESOLVED SPECIFICATIONS section would introduce a new keyword or sub parameter to be used under the [Model] keyword. This means that a [Model] could have many complete sets of I-V and V-t curves which describe the various operating modes of the buffer. For example, one set of keywords describing a buffer in one mode could come after the sub-parameter called [mode1], the next set of keywords describing the buffer in another mode could reside under the sub-parameter called [mode2], and so on, till all of the modes of the buffer are dharacterised. The default buffer could be defined with another sub-parameter, such as Default. The only difference between this method and the suggested one in the main section of this document is that the selection mechanism is inside the [Model] keyword and not outside. However, this minor difference imposes some limitations and might make an IBIS file unnecessarily larger. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From uunet!qdt.com!jonp@uunet.uu.net Fri Aug 11 08:43:09 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17428; Fri, 11 Aug 95 08:43:09 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzcio06925; Fri, 11 Aug 1995 11:36:16 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 11 Aug 1995 11:36:19 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00407; Fri, 11 Aug 95 08:07:06 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02712; Fri, 11 Aug 95 08:07:06 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQzcim27541; Fri, 11 Aug 1995 11:06:31 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 11 Aug 1995 11:06:32 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00368; Fri, 11 Aug 95 07:40:55 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02678; Fri, 11 Aug 95 07:40:56 PDT Date: Fri, 11 Aug 95 07:40:56 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9508111440.AA02678@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA11472; Fri, 11 Aug 95 07:40:55 PDT To: uunet!uunet!rockie.nsc.com!huq@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: <9508102136.AA26795@rockie.nsc.com> (uunet!rockie.nsc.com!huq) Subject: Re: EIA/IBIS FAQ - Rev2 > 17.0 Can IBIS handle devices whose output is non-monotonic? > No, IBIS cannot handle non-montonic devices. Though non-monotonic data can be entered the feed back delay is not specified and so the IBIS mechanism cannot accurately guarantee to provide the necessary data for proper simulation. To some degree assumptions made by the simulation vendor can address this but the IBIS data cannot be said to be accurate for feedback times ranging from instantaneous to DC. jon --- I actually think we should just leave this question off. From twisto!galois.eng.hou.compaq.com!rampton@wotan.compaq.com Fri Aug 11 09:50:50 1995 Return-Path: Received: from wotan.compaq.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17873; Fri, 11 Aug 95 09:50:50 PDT Received: from twisto by wotan.compaq.com with uucp (Smail3.1.28.1 #12) id m0sgwyo-0009sFC; Fri, 11 Aug 95 11:30 CDT Received: from galois.eng.hou.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0sgwyd-000uXKC; Fri, 11 Aug 95 11:30 CDT Received: by galois.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0sgwyc-0002P1C; Fri, 11 Aug 95 11:30 CDT Message-Id: From: rampton@galois.eng.hou.compaq.com (Malan Rampton) Subject: Re: BIRD 30: Programmable Buffers To: Will_Hobbs@ccm2.jf.intel.com (Will Hobbs) Date: Fri, 11 Aug 95 11:30:30 CDT Cc: ibis@vhdl.org, Arpad_Muranyi@ccm.fm.intel.com, jonp@qdt.com, bob@icx.com In-Reply-To: ; from "Will Hobbs" at Aug 10, 95 05:51:00 pm X-Mailer: ELM [version 2.4dev PL11] Dear Ibisians, I applaud the intent of BIRD 30 to provide IBIS models with the capability to handle programmable buffers in a more user friendly manner. However, I do not believe that BIRD 30 takes this issue far enough. In my experience as a signal integrity engineer most instances of programmable buffers have been encountered in the context of the chip as a whole, or some subsection thereof, being programmable. A simple example of this would be an ASIC that can be programmed to function at either 5V or 3.3V levels. It therefore seems to me that what needs to be provided is a method within IBIS to cleanly handle instances such as this: where a number of signals (likely involving a number of different types of programmable buffer) need to have correct buffer models selected based upon some characteristic, or set of characteristics. I have provided below a first pass at a sample syntax structure that should suffice to provide the above capability. This is based upon the sample provided within the text of BIRD 30 and makes use of the "Model selector" syntax that is laid out therein. The example displays the selection of 3volt high drive buffers for a set of target nets from two distinct programmable buffers and their corresponding configuration sets. In addition to the [Model selector] keyword I have added a [Signal selector] keyword. This has syntax that is similar to that of [Model selector] but provides a listing of nets that are programmed as a set. A name for the net grouping also needs to be provided and a default set of characteristics can be specified. An optional sub-parameter "Classes" has also been added to [Model]. This allows the specification of the programmable state of a given model. A set of program classes are listed, i.e., voltage and drive strength, and selection criteria values are assigned to them, i.e., 5V or 3V and H or L. An open-ended number of classes may be specified. In the example I have intentionally provided that the models of Progbuffer1 are programmable for voltage and drive while the models of Progbuffer2 are programmable only for voltage. In-spite of this they have been grouped into the same [Signal selector] grouping. In a case such as this, model selection should occur based upon what information is present. If it is specified that 3volt high drive models are to be selected for Progsection1 then the 3V H model from Progbuffer1 will be used in conjunction with the 3V buffer from Progbuffer2. Some miscellaneous notes: membership in more than one [Signal selector] group for a net should be prohibited; also the selection specifications MUST yield a unique model selection from each involved [Model selector]; I have used signal names for the [Signal selector] listing rather than pin names to provide for an easier conversion among package types. I believe that the additional functionality that this would provide is probably worth the slightly greater complexity. I will brace myself to hear otherwise, however. **************************Begin Example***************************** ============================================================================== | Keyword: [Model selector] | Required: No. | Description: Used to pick a [Model] from a list of [Model]s for a pin which | uses a programmable buffer. | Sub-Params: Default (?required if keyword used?) | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Models] must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] keyword and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] keyword. | | The sub-parameter Default is used to point to a default [Model] | to be used on the pin(s) calling this [Model selector]. | | The operation of this selection mechanism implies that a group | of pins which use the same programmable buffer (i.e. model | selector name) will be switched together from one [Model] to | another. Therefore, if two groups of pins, for example an | address bus and a data bus, use the same programmable buffer, | the user must have the capability to configure them | independently. One can use two [Model selector] keywords | with unique names and the same list of [Model] keywords; | however, the usage of the [Model selector] is not limited to | these examples. Many other combinations are possible. | | [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF 2 EN1# Input1 NA 6.3nH NA 3 A0 3-state 4 D0 Progbuffer2 5 D1 Progbuffer2 320.0m 3.1nH 2.2pF 6 D2 Progbuffer2 7 RD# Input2 310.0m 3.0nH 2.0pF | . | . | . 18 Vcc3 POWER | | [Model selector] Progbuffer1 | voltage drive Default ABCD0123456789ABCDE0 | 3V H ABCD0123456789ABCDE1 | 3V L ABCD0123456789ABCDE2 | 5V H ABCD0123456789ABCDE3 | 5V L | [Model selector] Progbuffer2 WXYZ9876543210WXYZE0 | 3V Default WXYZ9876543210WXYZE1 | 5V | [Signal selector] ProgSection1 Default:voltage=3V;drive=H RAS0#,D0,D1,D2 | | | [Model] ABCD0123456789ABCDE0 Model_type I/O Classes voltage=3V;drive=H | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE1 Model_type I/O Classes voltage=3V;drive=L | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE2 Model_type I/O Classes voltage=5V;drive=H | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE3 Model_type I/O Classes voltage=5V;drive=L | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] WXYZ9876543210WXYZE0 Model_type I/O Classes voltage=3V | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] WXYZ9876543210WXYZE1 Model_type I/O Classes voltage=5V | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | ****************************************************************************** regards, Malan Rampton Signal Integrity Group Compaq Computer Corporation phone: (713)374-6800 email: rampton@twisto.compaq.com From bob@icx.com Fri Aug 11 11:12:15 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18409; Fri, 11 Aug 95 11:12:15 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 11 Aug 95 11:05 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 11 Aug 95 11:07 PDT Message-Id: Date: Fri, 11 Aug 95 11:07 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Roster List Update IBIS Committee: Thank you for your updates to the roster of participants. Attached are changes which have been submitted so far. Please review your company's entry and submit any additional changes and updates. The roster.txt file resides in vhdl.org under /pub/ibis. It will be updated as new information comes in. However, every several months I will send the request for people to provide updated information. Bob Ross, Interconnectix, Inc. ============================================================================ EIA IBIS Committee Participation Roster As of 8/11/95 (updated periodically) 35 company/organizations listed Submit changes/updates to: bob@icx.com (503) 603-2523, Fax (503) 639-3469 ============================================================================ NOTE: This roster lists companies and organizations that have either participated in creating the IBIS spec or are creating/distributing IBIS models. Other than the specific statements of support under each organization's name, no support nor endorsement of the specification is implied. Companies designated by * are members of the EIA IBIS Open Forum. ============================================================================ Anacad EES Contact: Steffen Rochel Email: steffen@anacad.com Phone: (408) 954 0600 Fax: (408) 954 8884 Address: 1900 McCarthy Blvd. #310 Milpitas, CA 95035 Support: Anacad can translate IBIS descriptions into models using their analog behavioral modeling language HDL-A. Together with Eldo and a VHDL simulator, highly accurate investigations of mixed signal designs are possible. Tag-line: Ansoft Corporation Contact: Henri Maramis Email: maramis@ansoft.com Phone: (412) 261-3200, Fax: (412) 471-9427 Address: 4 Station Square, Suite 660 Pittsburgh, PA. 15219 Support: The Ansoft Maxwell SI product will support IBIS models/library in native format. Tag-line: Ansoft is a dedicated provider of electromagnetic field simulation software and integrated solutions for signal integrity and EMC/EMI. * AT&T Global Information Solutions Contact: Dave Moxley Email: David.Moxley@columbiasc.ncr.com Phone: (803) 939-6495 Address: 3325 Platt Springs Rd. W. Columbia, SC 29170 Support: AT&T GIS supports the developing IBIS standard as a user of IBIS models. Tag-line: Atmel Corporation Contact: Dan Terry Email: No internet address -- Pls Fax notices Phone: (408) 436-4346, Fax: (408) 436-4200 Address: Support: Tag-line: * Cadence Design Systems, Inc. Contact: C. Kumar Email: cpk@cadence.com Phone: (508) 262-6488, Fax: 508-262-6600 Address: 270 Billerica Rd, Chelmsford, MA 01824 Support: Cadence fully supports IBIS models. Cadence's DF/SigNoise product family offers a vendor-specific, IBIS compatible signal integrity library of over 7000 components. Cadence also provides a translator program enabling the conversion of IBIS 1.1 and 2.1 files to Cadence library format. Tag-line: Cadence, the worldwide leader in electronic design automation, combines leading-edge technology and a complementary set of services to accelerate and advance the overall performance engineering of high-speed electronic systems. * Contec CAE, Ltd. Contact: Dileep Divekar Email: dileep@contec.com Phone: (408) 434-6767, Fax: (408) 434-6884 Address: 2188 Bering Drive San Jose, CA 95131 Support: Contec tools support IBIS models. Tag-line: Contec offers accurate, state of the art signal integrity, EMI / EMC and circuit simulation tools. Digital Equipment Corp. Contact: Stephen C. Thierauf Email: thierauf@pasta.enet.dec.com Phone: (508) 568-4475, Fax: (508) 568-4367 Address: 77 Reed Road, HLO2-3/G13 Hudson, MA 01749 Support: Digital will generate IBIS models for its own chip products, including the line of ALPHA AXP microprocessors, as needed, and support IBIS models in in-house simulation tools. Tag-line: Digital, maker of the world's fastest microprocessor, is also a leading developer of computer systems, and networking and communication products, including PCI. Hewlett-Packard/HP EEsof Division Contact: Karl Kachigan Email: karlk@sr.hp.com Phone: (707) 577-3949, Fax: (707) 577-5260 Address: 1400 Fountaingrove Parkway Santa Rosa, CA 94503 Support: Support IBIS models in HP 85240 Picosecond Interconnect Modeling Suite for interconnect model development and analysis. Tag-line: HP EEsof is a leading supplier of high frequency analog (RF/Microwave) design and modeling tools. High Design Technology Contact: Maria Teresia Cosso (HDT,Italy), Wence Coron (Anacad EES,US) Email: wence@anacad.com Phone: +39 11 33 84 34 (408) 954-0600 Fax: +39 11 385 99 67 Fax: (408) 954-8884 Address: HDT Anacad EES Via Beaulard, 64 1900 McCarthy Blvd. #310 10139 Torino, Italy Milpitas, CA 95035 Support: An interface to IBIS is in preparation and will be available Q2/95. Tag-line: HDT offers a sophisticated toolset for signal integrity analysis and EMI investigation. In connection with a TDR based modeling technique, accurate and fast analysis of complete PCB's is provided. * HyperLynx Contact: Kellee Crisafulli Email: 71436.1314@compuserve.com Phone: (206) 869-2320, Fax: (206) 881-1008 Address: P.O. Box 3578 Redmond, WA 98073-3578 Support: Several signal integrity analysis tools are available: LineSim: A simulator using schematic data input, reads IBIS files as part of its native library support. Ships with a set of IBIS libraries. BoardSim: A simulator using PCB geometry data input from numerous PCB layout packages, also natively supports IBIS files. Ships with a set of IBIS libraries. Additional model libraries are available free of charge to customers on HyperLynx's BBS. Tag line: HyperLynx, Inc. is the industry's leading supplier of affordable, accurate, PC-based signal-integrity software. * IBM Corp. Contact: Shafiq-Ur-Rahman Joseph C. (Jay) Diepenbrock Email: shafiq@austin.ibm.com jayd@ralvm29.vnet.ibm.com Phone: (512) 838-6443 (919) 543-8804 Fax: (512) 838-7004 Address: Department 66DS/045-3 IBM Network Hdwe. Div. Internal Zip 4329 Transceiver Technology Dev't, D63/061 11400 Burnet Road P.O. Box 12195 Austin, TX 78758 Research Triangle Park, NC 27709 Support: Tag-line: * INCASES Contact: Werner Rissiek, Olaf Rethmeier Email: wrissiek@pad.incases.com, orethmeier@pad.incases.com Phone: ++49-5251-150-620, ++49-5251-150-625, Fax: ++49-5251-150-700 Address: INCASES Engineering GmbH Vattmannstrasse 3 D-33100 Paderborn, Germany Support: INCASES uses the simulation program FREACS (Fast REflection And Crosstalk Simulator) for signal integrity analysis within the EMC-Workbench. INCASES can read IBIS Version 1.1 files and translate the IBIS models into FREACS models. INCASES uses an IBIS parser and an automatic process for the parametrization of the FREACS macromodels. Additionally, so called 'reference lists' are set-up that are used by the interface (XLIN) between the EMC-Workbench and the FREACS macromodel library. These reference lists consist of circuit information in a special language named HINAC (Hierachical Naming Convention), where macromodel data is assigned to pins of a component using IBIS-information, as well. In this way a controlled set-up of a library is possible using IBIS-files as basis. Detailed information is available on request. Tag-line: INCASES Engineering, GmbH, Germany, founded on November 1, 1994, is a supplier of design automation software and consulting services to the electronic design automation (EDA) market, focusing on EMC and 'Design for Manufacturability'. INCASES develops, sells, and supports two major product lines: THEDA, acquired from Computervision Corporation and EMC-Workbench, acquired from Siemens Nixdorf Informationssysteme AG. * Intel Corporation Contact: Will Hobbs Email: Will_Hobbs@ccm2.jf.intel.com Phone: (503) 696-4369, Fax: (503) 696-4210 Address: 5200 NE Elam Young Pkwy, JF1-57 Hillsboro, OR 97124 Support: Intel provides IBIS models for some of its components. For a list of supported components, send the following message to archive@vhdl.org: path send pub/ibis/models/intel readme index /pub/ibis/models/intel For information on models of unannounced products, contact your local Intel field sales office. Tag-line: Intel, the world's largest chip maker, is also a leading manufacturer of personal computer networking and communications products. * Interconnectix, Inc. Contact: Bob Ross Email: bob@icx.com Phone: (503) 684-6641, Fax: (503) 639-3469 Address: 10220 S.W. Nimbus Ave., K4 Portland, Oregon 97223 Support: The Interconnect Synthesis (IS) product supports the major extensions of IBIS Version 2.1. Interface extensions for component and model selection and termination generation allow IBIS formatted data to be used in "what if" investigations and automatic synthesis operations. Tag-line: The leading Interconnect Synthesis Company Intergraph Corp. Contact: Rob Kelley Email: rkelley@ingr.com Phone: (205) 730-8978 Address: One Madison Industrial Park Huntsville, AL 35894-0001 Support: Intergraph Electronics fully supports the activities of the IBIS open forum and as such, is ensuring that all signal integrity development is aligned so that our customers will be able to take advantage of IBIS as the standard stabilizes. Tag-line: Intergraph Corporation, a Fortune 500 company, is the world's largest independent NT development site and the world's largest company dedicated to supplying interactive computer graphics systems. Integrated Silicon Systems, Inc. Contact: Email: Phone: (800)-422-3585 Address: P.O Box 13665 Research Triangle Park, NC 27713 Support: PSIBoards accepts IBIS model files directly. The IBIS files can contain any number of models or components. Instances of these models can be declared in the program's input deck, along with interconnections, to describe a complete design. Tag-line: Integrated Silicon Systems, Inc. is a leading supplier of hierarchical layout verification products. IntuSoft Contact: Charles Hymowitz Email: Phone: (303) 833-0710 Address: Support: IntuSoft takes a customer's netlist or model and translates it into a Spice model, free of charge. IntuSoft has the Golden Parser source but hasn't, as of yet, automated the process. IntuSoft is waiting until there are more IBIS models available. Tag-line: Mentor Graphics Corp. Contact: Griff Derryberry, Greg Doyle Email: Griff_Derryberry@mentororg.com, Greg_Doyle@mentororg.com Phone: (503) 685-1198, Fax: (503) 685-7991 Address: 8005 SW Boeckman Rd. Wilsonville, OR 97070-7777 Support: Mentor supports IBIS by using Quad Design and Intel IBIS models. Tag-line: * Meta-Software Contact: John Sliney, Mei Wong Email: johns@metasw.com, mei@metasw.com Phone: (408) 369-5446, Fax: (408) 371-5100 Address: 1300 White Oaks Rd. Campbell, CA 95008 Support: Tag-line: MicroSim Corp. Contact: Arthur Wong Email: Phone: (714) 770-3022, FAX: (714) 455-0554 Address: 20 Fairbanks Irvine, CA 92718 Support: MicroSim can automatically generate PSpice models for vendors who provide data in a file format conforming to the IBIS Ver 1.1 specification. The models can then be simulated with PSpice. MicroSim has made IBIS models for Intel's Pentium processor 82430 PCIset available to customers. Tag-line: MicroSim Corp. - The Desktop EDA Company - provides technically sophisticated software for schematic entry, simulation, programmable logic synthesis, and signal integrity analysis. * Motorola Contact: Ron Werner Email: Phone: Address: Support: Tag-line: * National Semiconductor Corp. Contact: Syed B.Huq Email: huq@rockie.nsc.com Phone: (408) 721-4874, Fax:(408)721-4785 Address: 2900 Semiconductor Drive, M/S A-2595 Santa Clara, CA 95052 Support: National Semiconductor provides IBISv1.1 and IBISv2.1 models for selected product lines. Refer to /pub/ibis/models/national for the latest available models. Tag-line: National Semiconductor provides technologies for moving and shaping information. The company focuses on communications, analog, and personal systems markets, and is the fourth largest U.S semiconductor merchant. * NEC Corporation Contact: Hiroshi Sakuma Email: sakuma@lsi.tmg.nec.co.jp Phone: +81 -44-435-1501(DIR), Fax: +81 -44-435-1887 Address: Design Sys. Dept., System ASIC Div., NEC Corp. 1753 Shimonumabe, Nakahara-ku Kawasaki Japan 211 Support: NEC is willing to write some IBIS models and a model generator for some of its LSI components. Tag-line: North Carolina State University Contact: Michael Steer, Paul Franzon, Steve Lipa Email: mbs@ncsu.edu paulf@ncsu.edu slipa@eos.ncsu.edu Phone: 919-515-5191 919-515-7351 919-515-3947 FAX for all three: 919-515-5523 Address: ECE Dept. Box 7911 NC State Univ. Raleigh, NC 27695-7911 Support: (as of 2/94) A Spice to IBIS converter is being developed. A measurement based procedure is being developed for extracting IBIS models. A yacc/lex parser for IBIS models is being develped. All software and techniques will be put in the public domain. Tag-line: * Quad Design Technology, Inc. Contact: Jon Powell Email: jonp@qdt.com Phone: (805) 988-8250, Fax: (805) 988-8259 Address: 1385 Del Norte Rd. Camarillo, CA 93010 Support: Quad Design has a translation program that translates from IBIS format to Quad Design .mod format. This translator uses the Golden Parser code with enhancements to warn of malformed (yet legal) models. The translator supports user input to be able to select from the min-typ-max range of IBIS data. This program (IBIS2XTK) is available now and is distributed with XTK Crosstalk and transmission line simulation tool kit. Tag-line: Quad Desgin is a leading supplier of Signal Integrity and Timing tools for high speed digital designs. * Quantic Laboratories, Inc. Contact: Mike Ventham Email: ventham@quantic.mb.ca Phone: (204) 942-4000, Fax: (204) 957-1158 Address: 12th Floor, 191 Lombard Ave Winnipeg, Manitoba, R3B 0X1 Canada Support: Quantic provides an IBIS reader (based on the Golden Parser) that will read IBIS models and automatically generate data files for Phidias (our graphical VI curve device modellor) and database files that associate the component definitions with the pin models. From Phidias, both SPICE models for PCB Greenfield (our pre and post layout transmission line simulator) and models for BoardScan, (our PC board screener for signal integrity and crosstalk problems) can be created. This is available now for Quantic customers. Tag-line: Quantic Laboratories Ltd has been the leading supplier of field solvers and signal integrity tools since 1983. This expertise has now been extended to Electromagnetic Compatibility (EMC) tools. Symmetry Design Systems, Inc. Contact: Andy Hughes Email: andy@symmetry.com Phone: (415) 949-9600, Fax: (415)-949-0831 Address: 477 S. San Antonio Rd. #200 Los Altos, Ca. 94022 Support: Symmetry provides IBIS modeling tools and services. Symmetry's modeling tool MODPEX can create IBIS models based on measured device characteristics or data sheet information. MODPEX can translate IBIS models to SPICE descriptions for testing and documentation or translate SPICE models to IBIS. Tag-line: Symmetry is a dedicated supplier of tools and services for creating, testing, and documenting SPICE and IBIS component models for electronic system design. Synopsys Inc. (Logic Modeling Group) Contact: Bill Lattin Email: billl@lmc.synopsys.com Phone: (503) 690-6900, Fax (503) 690-6906 Address: 19500 NW Gibbs Dr. Beaverton, OR 97075 Support: None at this time Tag-line: Tanner Research, Inc. Contact: Peter Parrish, Ed Miller, Scott Wedge Email: peter@tanner.com, miller@tanner.com, wedge@tanner.com Phone: (818) 792-3000 FAX: (818) 792-0300 Address: 180 North Vinedo Avenue Pasadena, CA 91107 Support: Tanner Research is currently developing IBIS model support for its MCM design tools. Tag-line: Affordable ASIC, MCM, and MEMS design tools from Tanner Research offer high performance and easy to use CAE solutions for PCs, Macintoshes, and UNIX workstations. Tanner Tools provide a complete design solution including schematic capture, circuit and gate level simulation, signal integrity analysis, auto place and route, layout editing and layout verification. * Texas Instruments Contact: Roger Cline Ben Andresen Email: rcline@asic.sc.ti.com andresen@asic.sc.ti.com Phone: (214) 997-2962 (214) 997-5443 Fax: (214) 997-5083 Address: P.O. Box 655303 Dallas, TX 75265 Support: TI has a three-pronged attack on IBIS support. TI is working on a scheme to automatically generate IBIS models from TI Spice simulations (TI's proprietary Spice dialect), on an automatic means to generate C code to be linked in to TI Spice as a User Defined Element from an IBIS model, and an automatic means to create the Spice equivalent of the IBIS model from the IBIS model specification. The latter method differs from the second in that it uses skeletonized Spice primitive elements in the form of a subcircuit, while the second actually generates C code and compiles it for dynamic linking. Tag-line: * Thomson-CSF/SCTF Contact: Jean Lebrun Email: Phone: Address: Support: Tag-line: * UniCAD Canada Ltd. Contact: Stephen Lum Email: lum@unicad.com Phone: (613) 596-9091 Ext. 321 Address: 2745 Iris Street Pinecrest Office Park Ottawa, Ontario K2C 3V5 Support: UniSolve, a concurrent engineering workbench currently supports IBIS v1.1 model files in native mode for signal integrity analysis. Support for IBIS v2.1 is planned for early 1995. Tag-line: UniCAD, INC. provides software used in the layout and analysis of printed circuits and multichip modules. It provides the only available concurrent Computer Aided Analysis (CAA) environment used to simultaneously monitor Emissions, Digital Signal Integrity, Analog Signal Integrity, Thermal, and Reliability throughout the design layout process. * VLSI Technology Contact: Richard Ulmer Email: dick.ulmer@tempe.vlsi.com Phone: (602) 752-6252 Fax: (602) 752-6002 Address: 8375 South River Parkway Tempe, AZ 85284 Support: Tag-line: Zeelan Technology, Inc. Contact: Hiro Moriyasu, George Opsahl Email: zeelan@netcom.com Phone: (503) 520-1000 Address: 10550 SW Allen Blvd. Beaverton, OR 97005 Support: Zeelan Tech. provides a modeling service that characterize and creates models conforming to the IBIS format. Zeelan Tech. MasterModel(TM) models are created from measurements of physical devices using a tightly controlled high-frequency fixture and modeling system. These models closely represent actual device behaviour when used in simulation. Tag-line: * Zuken-Redac Contact: John Berrie Email: johnb@redact.co.uk Phone: +44 684 294161, Fax: +44 684 299754 Address: Tewkesbury Gloucestershire GL20 8QL, England Support: Work is in progress to enable use of IBIS models in native format for Redac High-Performance Engineering and EMC Adviser products. In addition, integration with Quad Design and Quantic products provides the stated level of support provided by these companies. Tag-line: Zuken-Redac is a world leader in design automation, providing open, leading technology, standards-based CADCAM solutions. ============================================================================ EIA/Electronic Information Group Contact: Patti Rusher Email: Prusher@eia.org Phone: (703) 907-7545. Fax: (703) 907-7501 Address: 2500 Wilson Blvd. Arlington, VA 22201 From Will_Hobbs@ccm2.jf.intel.com Fri Aug 11 16:25:56 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20642; Fri, 11 Aug 95 16:25:56 PDT Received: from ormail.intel.com by relay3.UU.NET with SMTP id QQzcjt07110; Fri, 11 Aug 1995 19:19:15 -0400 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sh3MA-000UiUC; Fri, 11 Aug 95 16:19 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sh3MA-000txgC; Fri, 11 Aug 95 16:19 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Fri, 11 Aug 95 16:19:14 PDT Date: Fri, 11 Aug 95 16:12:00 PDT From: Will Hobbs Message-Id: To: jonp%qdt.com%uunet@uunet.uu.net, uunet!uunet!rockie.nsc.com!huq@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re[2]: EIA/IBIS FAQ - Rev2 Text item: It clearly requires more discussion, so it should be left off for now, IMHO. Will > 17.0 Can IBIS handle devices whose output is non-monotonic? > No, IBIS cannot handle non-montonic devices. Though non-monotonic data can be entered the feed back delay is not specified and so the IBIS mechanism cannot accurately guarantee to provide the necessary data for proper simulation. To some degree assumptions made by the simulation vendor can address this but the IBIS data cannot be said to be accurate for feedback times ranging from instantaneous to DC. jon --- I actually think we should just leave this question off. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: EIA/IBIS FAQ - Rev2 In-Reply-To: <9508102136.AA26795@rockie.nsc.com> (uunet!rockie.nsc.com!huq) Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net To: uunet!uunet!rockie.nsc.com!huq@uunet.uu.net Received: by f14.qdt.com (4.1/SMI-4.1) id AA11472; Fri, 11 Aug 95 07:40:55 PDT Message-Id: <9508111440.AA02678@hal.qdt.com> From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Fri, 11 Aug 95 07:40:56 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02678; Fri, 11 Aug 95 07:40:56 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00368; Fri, 11 Aug 95 07:40:55 PDT Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 11 Aug 1995 11:06:32 -0400 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQzcim27541; Fri, 11 Aug 1995 11:06:31 -0400 Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02712; Fri, 11 Aug 95 08:07:06 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00407; Fri, 11 Aug 95 08:07:06 PDT Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 11 Aug 1995 11:36:19 -0400 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzcio06925; Fri, 11 Aug 1995 11:36:16 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17428; Fri, 11 Aug 95 08:43:09 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 11 Aug 95 09 :21:52 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Fri, 11 Aug 9 5 09:22:00 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sgwqR-000tx6C; Fri, 11 Aug 95 09:22 PDT From Arpad_Muranyi@ccm.fm.intel.com Tue Aug 15 10:48:17 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07684; Tue, 15 Aug 95 10:48:17 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0siPzX-000UjiC; Tue, 15 Aug 95 10:41 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0siPzX-000twsC; Tue, 15 Aug 95 10:41 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Tue, 15 Aug 95 10:41:30 PDT Date: Tue, 15 Aug 95 10:36:00 PDT From: Arpad Muranyi Message-Id: To: ibis@vhdl.org Subject: Re: Malan's comments on BIRD30 Malan and all other BIRD watchers, Thank you for your comments on BIRD 30, Malan. Here is my response to your comments. If I am not mistaken, your comments revolve mainly around the selection by characteristics problem vs. selection by [Model] name, which I proposed in the BIRD. I agree with you, I personally would also like to know the [Model] characteristics when I am prompted to make a choice between the various [Model]s. However, this issue didn't occur to me at the time I wrote the BIRD, because our 20-digit [Model] naming convention is designed to describe the characteristics of the buffer in a fairly unique way across all of our products. Providing a selection mechanism by the [Model] name seemed to be the right thing to do, since our [Model] names are meaningful in terms of the [Model]'s characteristics. The only extension to the existing naming convention I had to make with BIRD 30 was to say that one [Model] represents only one mode of a programmable buffer and each of the modes of a buffer must have a different [Model] with a unique name. With this principle I did not see any need for inventing more keywords and sub-parameters to describe the characteristics of the buffer modes or [Model]s. The only problem I see here is that not all of the vendors use the same [Model] naming convention. To solve this problem we might ask the question: would it be a good idea to standardize a [Model] naming convention to reflect the characteristics of a [Model]? I see some problems with that. An engineer might simulate with models from various vendors. In order to make his work easier, the buffer characterization has to be meaningful across all of the models he is using. For example, the famous mA numbers which describe the buffer strength come to my mind. One vendor calls the PCI buffer 6/12 mA another calls it 12/21 mA. Yet the I-V curves of these two buffers are about the same! I don't see that we could influence all vendors (or IBIS model makers) to use the same kind of characterization technique. Until then, we might as well call our [Model]s "blue", "square", "liquid", "garble" etc... The engineer will have to associate these names with what he knows about the buffer, just like I have to know today that a 6/12 is the same thing as a 12/21 mA buffer, a PCI buffer. He might know that "blue" is a 5 volt buffer, "square" is a 3.3 volt buffer, "garble" is twice as strong as "square" and "liquid" is faster than "blue". If he doesn't know this, he can look up the keyword [Voltage Range] in the [Model] to find out which [Model] is a 3.3 volt model, look at the I-V curves to find out which one is stronger than the other, or look at the [Ramp] keyword to find out which one is the fastest. However, a user always wants quick information with the least amount of work. You are right, the "Classes" sub-parameter would provide that. My main problem is that most of the time it would merely duplicate the information which is already present in the data, therefore it is redundant. Redundancies make things more error prone. (What would you do as a user, if the [Voltage Range] keyword said it was a 5.0 volt buffer, but the "Class" sub-parameter would say it was a 3.3 volt buffer? These kind of mistakes might happen very easily.) Also, in some cases the IBIS model maker might want to describe the model in non-engineering terms, such as "use this [Model] for XX MBytes of DRAMs". In my mind, the best way to give the user quick information (without redundancy) on [Model] names under the [Model selector] keyword is to use comments. The user interface of a simulation tool can display these comments for the convenience of the user. I know, comments are usually ignored by the simulators and parsers. This could be an exception which makes sense logically. Every comment after the [Model] name inside the [Model selector] keyword could be treated as a "meaningful comment" to be used in a user interface dialog box. I don't understand the benefit of the additional [Signal selector] keyword you suggested. I stated it clearly (I thought), that all pins using the same Progbuffer name will be grouped by that name automatically. This is the same as what you are saying: > In addition to the [Model selector] keyword I have added a [Signal > selector] keyword. This has syntax that is similar to that of [Model > selector] but provides a listing of nets that are programmed as a > set. A name for the net grouping also needs to be provided and a > default set of characteristics can be specified. The additional rules you described in the "miscellaneous notes" are only necessary because of the redundant nature of the additional [Signal selector] keyword. If there is no redundancy, there is no need for these rules. > Some miscellaneous notes: membership in more than one [Signal selector] > group for a net should be prohibited; also the selection > specifications MUST yield a unique model selection from each involved > [Model selector]; I have used signal names for the [Signal selector] > listing rather than pin names to provide for an easier conversion > among package types. There is no need for the sub-parameter "Classes", as I see it. All of the information is already present in the various sections of the [Model]. There is no need for duplicate descriptions (redundancy). An IBIS model is simple enough and human readable, so that an engineer can easily get this kind of information out of it. These are my comments. Please let me know if I misunderstood some of your writings. Sincerely, Arpad Muranyi Intel Corporation *********************************************************************** > An optional sub-parameter "Classes" has also been added to > [Model]. This allows the specification of the programmable state of a > given model. A set of program classes are listed, i.e., voltage and > drive strength, and selection criteria values are assigned to them, > i.e., 5V or 3V and H or L. An open-ended number of classes may be > specified. > > In the example I have intentionally provided that the models of > Progbuffer1 are programmable for voltage and drive while the models of > Progbuffer2 are programmable only for voltage. In-spite of this they > have been grouped into the same [Signal selector] grouping. In a case > such as this, model selection should occur based upon what information > is present. If it is specified that 3volt high drive models are to be > selected for Progsection1 then the 3V H model from Progbuffer1 will be > used in conjunction with the 3V buffer from Progbuffer2. > > I believe that the additional functionality that this would provide is > probably worth the slightly greater complexity. I will brace myself to > hear otherwise, however. **************************Begin Example***************************** ============================================================================== | Keyword: [Model selector] | Required: No. | Description: Used to pick a [Model] from a list of [Model]s for a pin which | uses a programmable buffer. | Sub-Params: Default (?required if keyword used?) | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Models] must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] keyword and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] keyword. | | The sub-parameter Default is used to point to a default [Model] | to be used on the pin(s) calling this [Model selector]. | | The operation of this selection mechanism implies that a group | of pins which use the same programmable buffer (i.e. model | selector name) will be switched together from one [Model] to | another. Therefore, if two groups of pins, for example an | address bus and a data bus, use the same programmable buffer, | the user must have the capability to configure them | independently. One can use two [Model selector] keywords | with unique names and the same list of [Model] keywords; | however, the usage of the [Model selector] is not limited to | these examples. Many other combinations are possible. | | [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF 2 EN1# Input1 NA 6.3nH NA 3 A0 3-state 4 D0 Progbuffer2 5 D1 Progbuffer2 320.0m 3.1nH 2.2pF 6 D2 Progbuffer2 7 RD# Input2 310.0m 3.0nH 2.0pF | . | . | . 18 Vcc3 POWER | | [Model selector] Progbuffer1 | voltage drive Default ABCD0123456789ABCDE0 | 3V H ABCD0123456789ABCDE1 | 3V L ABCD0123456789ABCDE2 | 5V H ABCD0123456789ABCDE3 | 5V L | [Model selector] Progbuffer2 WXYZ9876543210WXYZE0 | 3V Default WXYZ9876543210WXYZE1 | 5V | [Signal selector] ProgSection1 Default:voltage=3V;drive=H RAS0#,D0,D1,D2 | | | [Model] ABCD0123456789ABCDE0 Model_type I/O Classes voltage=3V;drive=H | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE1 Model_type I/O Classes voltage=3V;drive=L | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE2 Model_type I/O Classes voltage=5V;drive=H | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE3 Model_type I/O Classes voltage=5V;drive=L | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] WXYZ9876543210WXYZE0 Model_type I/O Classes voltage=3V | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] WXYZ9876543210WXYZE1 Model_type I/O Classes voltage=5V | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | ****************************************************************************** regards, Malan Rampton Signal Integrity Group Compaq Computer Corporation phone: (713)374-6800 email: rampton@twisto.compaq.com From bob@icx.com Tue Aug 15 14:13:12 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09291; Tue, 15 Aug 95 14:13:12 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 15 Aug 95 14:06 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 15 Aug 95 14:08 PDT Message-Id: Date: Tue, 15 Aug 95 14:08 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: ROADMAP COMMENT Ron: Concerning your recommendations regarding IBIS in your Roadmap project, IBIS Versions 2.0 and above do support Slew Controlled Drivers. The [Rising Waveform] and [Falling Waveform] keywords give more detailed resolution of the output waveshape for signal integrity and timing calculations. These standards also support describing the test load under which the timing measurements are obtained for better interface with delay specifications. The IBIS activity is now operating as a committee under EIA. Version 2.1 is undergoing public review as part of the process of becoming EIA-656. Bob Ross IBIS Open Forum Secretary Phone (503) 603-2523, Fax (503) 639-3469 bob@icx.com Interconnectix, Inc., 10220 S.W. Nimbus Ave., K4, Portland, OR 97223 > -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- > Please subscribe me to the IBIS reflector. > Name: Ronald J. Christoher > I am working as an independent with CFI, EDAC, and Sematech on a 10 > year roadmap for electronic CAD standards. Our work is described on > the WWW at http://www.cfi.org/roadmap/roadMap-eii-report.html. > Thanks > Ron Christopher From twisto!galois.eng.hou.compaq.com!rampton@wotan.compaq.com Tue Aug 15 15:11:12 1995 Return-Path: Received: from wotan.compaq.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09670; Tue, 15 Aug 95 15:11:12 PDT Received: from twisto by wotan.compaq.com with uucp (Smail3.1.28.1 #12) id m0siTvr-0009syC; Tue, 15 Aug 95 16:53 CDT Received: from galois.eng.hou.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0siTv5-000uYZC; Tue, 15 Aug 95 16:53 CDT Received: by galois.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0siTv3-0002OzC; Tue, 15 Aug 95 16:53 CDT Message-Id: From: rampton@galois.eng.hou.compaq.com (Malan Rampton) Subject: Re: Malan's comments on BIRD30 To: Arpad_Muranyi@ccm.fm.intel.com (Arpad Muranyi) Date: Tue, 15 Aug 95 16:53:08 CDT Cc: ibis@vhdl.org In-Reply-To: ; from "Arpad Muranyi" at Aug 15, 95 10:36:00 am X-Mailer: ELM [version 2.4dev PL11] Arpad, Thank you for reviewing my comments on BIRD 30. Here is my response to your response to my comments on your BIRD. Whew . . . I am aware that my comments on BIRD 30 would add complexity to the models as well as possibly providing opportunity for errors to creep in. Engineering is in many respects the art of balance and compromise and I feel that the added functionality and flexibility that my comments would also provide produces a net positive. I was perhaps not sufficiently clear in my statement of my overall purpose. I will therefore try to provide some additional clarification. I will begin by stating what my purpose is not. It is NOT to merely provide the user with another set of data when he looks at a particular I/O buffer model. Information that in all likely hood is redundant (as you mentioned) to what is already stated in the I/O buffer model name. My purpose is to provide information for the various simulation tools to enable them to help automate the selection of appropriate and valid buffer models for signals with programmable pads. As a user I wish to avoid having to make model assignments for a chip on a pin by pin basis. As a simple example (and one that I mentioned previously) take an ASIC that has been designed for either 5volt or 3.3volt use. Let us assume that each buffer on the chip can be programmed to operate at either 5volts or at 3.3volts. Note that the operation voltage is the measure of commonality here; there are a number of different types of buffers present with possibly different drive strengths and slew rates. Assume that the chip is to be programmed for 3.3volt operation. We wish to provide the means to select all of the 3.3volt buffers for the chip irrespective of the fact that some of them are bi-directional and others are output and some are input, as well as the existence of differences in drive strength and slew rate (this becomes the problem of allowing selection across multiple [Model selector]s based upon some instance(s) of commonality). I have defined the sub-parameter "Classes" to provide for the specification of characteristics of commonality. As you mentioned this information is generally present in the model name itself but that there is no standard naming convention followed from vendor to vendor. These names are therefore of little use to the tool vendors who might wish to extract the information contained in that name. The specification of the programmable characteristics of a buffer can most often be represented as something akin to 5V or 3.3V, high or low, fast or slow. For selection purposes more detail than this is really not required. The chip example that I mentioned above is somewhat simplistic and it may not showcase sufficiently well the desirability of automating the programmable buffer selection process (more than just automating, this provides a mechanism for the programmable configurations of a chip to be specified in the IBIS model; this will reduce the need for the engineer to attempt to find and transfer this data from the data-book to the IBIS model manually; from personal experience this can be an error prone process). If we take the example from above and break the chip into a non-programmable section, and a section programmable by voltage and drive strength or only drive strength as allowed by the model, we then have a somewhat more realistic situation. Given the following pin list let us say that the following signal is programmable by voltage and drive strength: RAS0#. The signals D[2:0] are programmable only by voltage and the signals EN1#, A0, RD# are not programmable. [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF 2 EN1# Input NA 6.3nH NA 3 A0 Input 4 D0 Progbuffer2 5 D1 Progbuffer2 320.0m 3.1nH 2.2pF 6 D2 Progbuffer2 7 RD# Input 310.0m 3.0nH 2.0pF | . | . | . 18 Vcc3 POWER Let us show these models as the following: [Model] ABCD0123456789ABCDE0 Model_type I/O Classes voltage=3V;drive=H | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE1 Model_type I/O Classes voltage=3V;drive=L | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE2 Model_type I/O Classes voltage=5V;drive=H | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] ABCD0123456789ABCDE3 Model_type I/O Classes voltage=5V;drive=L | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] WXYZ9876543210WXYZE0 Model_type I/O Classes voltage=3V | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] WXYZ9876543210WXYZE1 Model_type I/O Classes voltage=5V | optional parameter Polarity Non-Inverting Enable Active-Low | . | . | . | [Model] Input Model_type Input | . | . | . | The sub-parameter "Classes" provides easily parsable information on the programmable state of a particular model. We have the following types of programmable buffers and use [Model selector] to group them: [Model selector] Progbuffer1 | voltage drive Default ABCD0123456789ABCDE0 | 3V H ABCD0123456789ABCDE1 | 3V L ABCD0123456789ABCDE2 | 5V H ABCD0123456789ABCDE3 | 5V L | [Model selector] Progbuffer2 WXYZ9876543210WXYZE0 | 3V Default WXYZ9876543210WXYZE1 | 5V The [Signal selector] keyword is used to group those nets that are part of a common program group together. This will allow models to be selected for them as a group EVEN THOUGH different buffer types represented by different [Model selector]s exist in the same group. For example the [Model selector] Progbuffer1 is obviously not the same beast as [Model Selector] Progbuffer2. All the same we can group them together: [Signal selector] ProgSection1 Default:voltage=3V;drive=H RAS0#,D0,D1,D2 Note that RAS0# is of type Progbuffer1 while D[2:0] is of type Progbuffer2 (look at pin list). Hopefully at this point we have provided sufficient information in an easy to use format for the designer of a simulation tool to allow us to view the program groupings of a given chip model. From there we would highlight the selection criteria that we wish to use for model selection for this particular program group. I choose 3V and H (for high drive). The tool will then go and select the [3V H] model from Progbuffer1 and the [3V] buffer from Progbuffer2 and these will be used everywhere that their respective [Model selector]s are assigned in the specified [Signal selector] grouping. In brief my principle concern is not that of selection by model characteristic versus selection by model name. Rather it is that of manual selection by the user (pin by pin) versus automatic selection by the tool (programmable chip section by programmable chip section) based upon user input. I hope that I have removed some of the fog from what I wrote earlier rather that mearly adding to it. regards, Malan Rampton Signal Integrity Group Compaq Computer Corporation phone: (713)374-6800 email: rampton@twisto.compaq.com > > Malan and all other BIRD watchers, > > Thank you for your comments on BIRD 30, Malan. Here is my response > to your comments. > > If I am not mistaken, your comments revolve mainly around the > selection by characteristics problem vs. selection by [Model] name, > which I proposed in the BIRD. I agree with you, I personally would > also like to know the [Model] characteristics when I am prompted to > make a choice between the various [Model]s. > > However, this issue didn't occur to me at the time I wrote the BIRD, > because our 20-digit [Model] naming convention is designed to describe > the characteristics of the buffer in a fairly unique way across all of > our products. Providing a selection mechanism by the [Model] name > seemed to be the right thing to do, since our [Model] names are > meaningful in terms of the [Model]'s characteristics. The only > extension to the existing naming convention I had to make with BIRD 30 > was to say that one [Model] represents only one mode of a programmable > buffer and each of the modes of a buffer must have a different [Model] > with a unique name. With this principle I did not see any need for > inventing more keywords and sub-parameters to describe the > characteristics of the buffer modes or [Model]s. > > The only problem I see here is that not all of the vendors use the > same [Model] naming convention. To solve this problem we might ask > the question: would it be a good idea to standardize a [Model] naming > convention to reflect the characteristics of a [Model]? I see some > problems with that. An engineer might simulate with models from > various vendors. In order to make his work easier, the buffer > characterization has to be meaningful across all of the models he is > using. For example, the famous mA numbers which describe the buffer > strength come to my mind. One vendor calls the PCI buffer 6/12 mA > another calls it 12/21 mA. Yet the I-V curves of these two buffers > are about the same! I don't see that we could influence all vendors > (or IBIS model makers) to use the same kind of characterization > technique. > > Until then, we might as well call our [Model]s "blue", "square", > "liquid", "garble" etc... The engineer will have to associate these > names with what he knows about the buffer, just like I have to know > today that a 6/12 is the same thing as a 12/21 mA buffer, a PCI > buffer. He might know that "blue" is a 5 volt buffer, "square" is a > 3.3 volt buffer, "garble" is twice as strong as "square" and "liquid" > is faster than "blue". If he doesn't know this, he can look up the > keyword [Voltage Range] in the [Model] to find out which [Model] is a > 3.3 volt model, look at the I-V curves to find out which one is > stronger than the other, or look at the [Ramp] keyword to find out > which one is the fastest. > > However, a user always wants quick information with the least amount > of work. You are right, the "Classes" sub-parameter would provide > that. My main problem is that most of the time it would merely > duplicate the information which is already present in the data, > therefore it is redundant. Redundancies make things more error prone. > (What would you do as a user, if the [Voltage Range] keyword said it > was a 5.0 volt buffer, but the "Class" sub-parameter would say it was > a 3.3 volt buffer? These kind of mistakes might happen very easily.) > Also, in some cases the IBIS model maker might want to describe the > model in non-engineering terms, such as "use this [Model] for XX > MBytes of DRAMs". In my mind, the best way to give the user quick > information (without redundancy) on [Model] names under the [Model > selector] keyword is to use comments. The user interface of a > simulation tool can display these comments for the convenience of the > user. I know, comments are usually ignored by the simulators and > parsers. This could be an exception which makes sense logically. > Every comment after the [Model] name inside the [Model selector] > keyword could be treated as a "meaningful comment" to be used in a > user interface dialog box. > > I don't understand the benefit of the additional [Signal selector] > keyword you suggested. I stated it clearly (I thought), that all pins > using the same Progbuffer name will be grouped by that name automatically. > This is the same as what you are saying: > > > In addition to the [Model selector] keyword I have added a [Signal > > selector] keyword. This has syntax that is similar to that of [Model > > selector] but provides a listing of nets that are programmed as a > > set. A name for the net grouping also needs to be provided and a > > default set of characteristics can be specified. > > The additional rules you described in the "miscellaneous notes" are > only necessary because of the redundant nature of the additional > [Signal selector] keyword. If there is no redundancy, there is no > need for these rules. > > > Some miscellaneous notes: membership in more than one [Signal selector] > > group for a net should be prohibited; also the selection > > specifications MUST yield a unique model selection from each involved > > [Model selector]; I have used signal names for the [Signal selector] > > listing rather than pin names to provide for an easier conversion > > among package types. > > There is no need for the sub-parameter "Classes", as I see it. All of > the information is already present in the various sections of the > [Model]. There is no need for duplicate descriptions (redundancy). > An IBIS model is simple enough and human readable, so that an engineer > can easily get this kind of information out of it. > > These are my comments. Please let me know if I misunderstood some of > your writings. Sincerely, > > Arpad Muranyi > Intel Corporation > *********************************************************************** > > An optional sub-parameter "Classes" has also been added to > > [Model]. This allows the specification of the programmable state of a > > given model. A set of program classes are listed, i.e., voltage and > > drive strength, and selection criteria values are assigned to them, > > i.e., 5V or 3V and H or L. An open-ended number of classes may be > > specified. > > > > In the example I have intentionally provided that the models of > > Progbuffer1 are programmable for voltage and drive while the models of > > Progbuffer2 are programmable only for voltage. In-spite of this they > > have been grouped into the same [Signal selector] grouping. In a case > > such as this, model selection should occur based upon what information > > is present. If it is specified that 3volt high drive models are to be > > selected for Progsection1 then the 3V H model from Progbuffer1 will be > > used in conjunction with the 3V buffer from Progbuffer2. > > > > I believe that the additional functionality that this would provide is > > probably worth the slightly greater complexity. I will brace myself to > > hear otherwise, however. > **************************Begin Example***************************** > ============================================================================== > | Keyword: [Model selector] > | Required: No. > | Description: Used to pick a [Model] from a list of [Model]s for a pin which > | uses a programmable buffer. > | Sub-Params: Default (?required if keyword used?) > | Usage Rules: A programmable buffer must have an individual [Model] section > | for each one of its modes used in the .ibs file. The names of > | these [Models] must be unique and can be listed under the > | [Model selector] keyword and/or pin list. The name of the > | [Model selector] keyword must match the corresponding model > | name listed under the [Pin] keyword and must not contain more > | than 20 characters. A .ibs file must contain enough [Model > | selector] keywords to cover all of the model selector names > | specified under the [Pin] keyword. > | > | The sub-parameter Default is used to point to a default [Model] > | to be used on the pin(s) calling this [Model selector]. > | > | The operation of this selection mechanism implies that a group > | of pins which use the same programmable buffer (i.e. model > | selector name) will be switched together from one [Model] to > | another. Therefore, if two groups of pins, for example an > | address bus and a data bus, use the same programmable buffer, > | the user must have the capability to configure them > | independently. One can use two [Model selector] keywords > | with unique names and the same list of [Model] keywords; > | however, the usage of the [Model selector] is not limited to > | these examples. Many other combinations are possible. > | > | > [Pin] signal_name model_name R_pin L_pin C_pin > | > 1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF > 2 EN1# Input NA 6.3nH NA > 3 A0 Input > 4 D0 Progbuffer2 > 5 D1 Progbuffer2 320.0m 3.1nH 2.2pF > 6 D2 Progbuffer2 > 7 RD# Input 310.0m 3.0nH 2.0pF > | . > | . > | . > 18 Vcc3 POWER > | > | > [Model selector] Progbuffer1 | voltage drive > Default ABCD0123456789ABCDE0 | 3V H > ABCD0123456789ABCDE1 | 3V L > ABCD0123456789ABCDE2 | 5V H > ABCD0123456789ABCDE3 | 5V L > | > [Model selector] Progbuffer2 > WXYZ9876543210WXYZE0 | 3V > Default WXYZ9876543210WXYZE1 | 5V > | > [Signal selector] ProgSection1 Default:voltage=3V;drive=H > RAS0#,D0,D1,D2 > | > | > | > [Model] ABCD0123456789ABCDE0 > Model_type I/O > Classes voltage=3V;drive=H | optional parameter > Polarity Non-Inverting > Enable Active-Low > | . > | . > | . > | > [Model] ABCD0123456789ABCDE1 > Model_type I/O > Classes voltage=3V;drive=L | optional parameter > Polarity Non-Inverting > Enable Active-Low > | . > | . > | . > | > [Model] ABCD0123456789ABCDE2 > Model_type I/O > Classes voltage=5V;drive=H | optional parameter > Polarity Non-Inverting > Enable Active-Low > | . > | . > | . > | > [Model] ABCD0123456789ABCDE3 > Model_type I/O > Classes voltage=5V;drive=L | optional parameter > Polarity Non-Inverting > Enable Active-Low > | . > | . > | . > | > [Model] WXYZ9876543210WXYZE0 > Model_type I/O > Classes voltage=3V | optional parameter > Polarity Non-Inverting > Enable Active-Low > | . > | . > | . > | > [Model] WXYZ9876543210WXYZE1 > Model_type I/O > Classes voltage=5V | optional parameter > Polarity Non-Inverting > Enable Active-Low > | . > | . > | . > | > > ****************************************************************************** > > > regards, > > Malan Rampton > Signal Integrity Group > Compaq Computer Corporation > phone: (713)374-6800 > email: rampton@twisto.compaq.com > > > From bob@icx.com Wed Aug 16 10:33:25 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21261; Wed, 16 Aug 95 10:33:25 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Aug 95 10:26 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Aug 95 10:29 PDT Message-Id: Date: Wed, 16 Aug 95 10:29 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Minutes Aug 11, 1995 DATE: August 16, 1995 SUBJECT: 8/11/95 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS: AT&T Global Info Solutions Dave Moxley Cadence Design Sandeep Khanna, C. Kumar* Contec CAE, Ltd. Dileep Divekar* HyperLynx Kellee Crisafulli IBM Jay Diepenbrock INCASES Werner Rissiek, Olaf Rethmeier* Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, Derrick Duehren Interconnectix, Inc. Bob Ross* Meta-Software Les Spruiell, Mei Wong, You-Pang Wei, John Sliney Motorola Ron Werner National Semiconductor Syed Huq*, Atul Agarwal, Cheng-Yang Kao NEC Hiroshi Matsumoto Quad Design Jon Powell* Quantic Labs Mike Ventham Texas Instruments Roger Cline*, Ben Andresen* Thomson-CSF/SCTF Jean LeBrun UniCAD Canada Ltd. Stephen Lum VLSI Technology Dick Ulmer, Sung Oh Zuken-Redac John Berrie OTHER PARTICIPANTS: ARPA Randy Harr Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadlab Ralf Bruning Digital Equipment Corp. Barry Katz EIA Patti Rusher High Design Technology Michael Smith, Dr. Ing. Cosso Hewlett Packard Tom Langdorf, Karl Kachigan, Henry Wu Integrated Silicon Systems Eric Bracken Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz LSI Logic Corp. Satish Pratadneni Mentor Graphics Ravender Goyal, Greg Doyle Micron Technology Brian Johnson MicroSim Arthur Wong North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Univ. of Illinois, Urbana Raj Mittra* Zeelan Technology George Opsahl, Hiro Moriyasu (Independent) Bob Ward In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 8/25/95 (916) 356-9200 1-13824 8492193 9/15/95 (916) 356-9200 1-16347 127231 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, ANNOUNCEMENTS Ben Andresen and Roger Cline joined as new Texas Representatives from an I/O group in Dallas and are seeking addition representation from the Design Automation group. Dr. Raj Mittra joined later from the Univerity of Illinois to participate in the package model discussion MINUTES REPORT, MISC. Minutes of 7/21/95 to correct repeated "command" under s2ibis 2.1. OPENS FOR NEW ISSUES The cmosttl issue (Egg 6) was put on the list. PRESS UPDATES A Japanese publication Nikkei Electronics (similar to EDN) has published an extensive article on signal integrity including prominent mention of IBIS in the July 31, 1995 issue, pp. 171-184. Will Hobbs supplied IBIS information for the article and is having it translated into English. NEW MODELS Arpad Muranyi updated the entire Intel model library and has supplied and has supplied some new models including some under "nda" to Michael Steer. EIA MEMBERSHIP AND TREASURER'S REPORT IBM and VLSI have officially become members and have purchased the parser. Tanner Research, Inc. has purchased the parser. A treasurer's report was not available. EIA BALLOT COMMENTS (VOTES) To date, all ballots with comments are being addressed. There are no known negative ballots. The known comments and responses were discussed. The response to Interconnectix, Inc. editorial comments were approved. The response to the University of Manchester editorial and technical comments were approved. AR - Will Hobbs submit the approved response letters to the commentors. AR - Bob Ross roll the changes into a revised Version 2.1 Specification including those of the EIA IBIS committee BIRD29.2 response. Send this rolled up version with changes noted to reflector for discussion at the August 25 IBIS Open Forum Meeting for final ratification discussion. Bob also set up the Agenda to include this topic. Response to Comments by Dileep Divekar of Contec submitted on the reflector were considered satisfactory. These will not be submitted as formal letter ballot comments. Reminder, the Deadline for Comments to EIA-656 is August 22, 1995. AR - Those who have not commented, submit your comment to EIA. A strong showing of support is helpful. LOGO PERMISSION LETTERS Jon Powell needs permission letters from each company to use logos on placards and foils. Not everyone has received the letter from EIA. Jon has received permission letters and logos from National Semiconductor, UniCad, and Quad Design, and has received logos only from Contec and Zuken-Redac. Permission letters can be obtained from Patti Rusher at prusher@eia.org and returned to her. Company logos should be sent to Jon Powell - Email and address at the end. ROSTER UPDATE Based on responses, the roster has been updated. The roster is maintained on vhdl.org and continuously updated as new information arrives. Periodically a request will be made for everyone to review their company's entry and provide update information. AR - Bob Ross put the updated roster on vhdl.org [DONE] and send to the reflector the roster.txt along with a request to review the changes and submit updates and corrections. [DONE] WEB UPDATE Syed Huq reported that the IBIS Web page under EIA (www.eia.org/eng) is expected to be operational August 18 (at the earliest). Search links to "ibis" or to "EIA-656" are not in place yet. Syed will follow up on this. The home page will have a hypertext link to /pub/ibis on vhdl.org to connect to the top level of all posted information. Links will also be to - All models at the /pub/ibis/models - All Standards with links to ver1.0, ver1.1, ver2.0, ver2.1 - Roster Listing The FAQ (Frequently Asked Questions) will be maintained on the Web and will be entered as approved. Also, comments/problems/suggestions selections will be provided. Jon Powell suggested links to companies' IBIS pages. Names could be entered now, and company logos entered later. This could be pursued later. FAQ VOTE Except for Questions 6, 7, and 17, all were approved as written or per posted modification. The answer to Q1 was modified to read "IBIS (Input Output Buffer Information) is a method of providing the Input/Output device characteristics through V/I data without disclosing any circuit process information. It can be thought of as a behavioral modeling specification suitable for transmission line simulation of digital systems and applicable to most digital components." The answer to Q2 was modified to read "... All model files must pass the parser before a model can be released to vhdl.org. ..." Other changes have been submitted to the reflector. Q6 regarding SSO needs rewording. Q7 regarding -VCC to 2Vcc regarding data needed for undershoot and overshoot needs to be resubmitted. Ben Andresen of Texas Instruments raised the point that such a range is destructive to forward biased diodes. Will Hobbs' Q17 regarding non-monotonic data was incomplete. Jon Powell indicated that more information was required for the model to be simulate properly in the non-monotonic regions. AR - Jon Powell post a response to Q17 on the reflector - [Done]. Further discussion on Q6, Q7, and Q17 will occur on the reflector, and these will be on the agenda for next meeting. MODEL TRACKING Syed Huq reported no progress in this area. MODELS UNDER NDA NDA style models including those from National should be listed in the 00readme file and also should exist by name with an extension such as .nda. Information on whom to contact should be provided. GOLDEN PARSER UPDATE Arpad Muranyi has a "final" version of the parser, although it has a reference to "Beta". There is also some residual files on the disk. The disk is being sent to Will Hobbs for distribution. This should be (hopefully) the final validation check before the executables are generated and posted on vhdl.org. AR - Arpad Muranyi check with Paul Munsey on extra files. AR - Will Hobbs distribute new parser files to licensees [DONE] S2IBIS 1.2 A correction/enhansement release has been posted on vhdl.org as S2IBIS12.*. This version corrects for an incorrect extrapolation problem involving the [Pullup] table. It also adds several parameters including one which will allow separate "min" of slow-weak, "typ" or nominal, and "max" or strong-fast Spice used for these columns. S2IBIS 2.1 Michael Steer reported on the s2ibis version 2.0 progress through Email. C. Kumar reported August 24 as the target date. The contents would be posted on vhdl.org where anyone who wants to review it can get access to it. This will be a beta version, but this process will avoid attempting to distribute it privately. COOKBOOK AND OVERVIEW UPDATE Bob Ross indicated that Kellee Chrisafulli and Bob received the cleansed document from Syed Huq of the National Semiconductor cookbook for developing IBIS models based on measurements. AR - Syed can send Bob a Framemaker formatted version for conversion to Word. BIRD27 NEW KEYWORD FOR DIFFERENTIAL I/O This will be deferred until after the EIA IBIS ballot is completed since this is a Version 3.0 issue for the future. AR - Bob Ross submit BIRD27.1 (after EIA IBIS ballot resolution) BIRD28.1 PACKAGE MODEL EXTENSION / PHYSICAL EXTENSIONS Steven Peters summarized the issue and indicated that actual length should be included for each pin. It is up the the simulator companies to process this information. Stephen still plans to submit a BIRD28.2 revision. Arpad Muranyi has summitted on the reflector a summary of Raj Mittra's comments, and Raj Mittra from the University of Illinois, Urbana joined the discussion. He indicated that the Pads format seems to be favored, but it is not a standard. Raj indicated the preference for Spice style syntax by simulator vendors, particularly for transmission lines. Jon Powell indicated that several vendors can handle coupled transmission line segments directly. There is a distinction between transmission lines that exist on well defined ground planes versus package and bond wire routing. Raj gave these fundamental sources for package models: (1) Derivable from measurements (could be a bundle of pins within power/ ground groupings (2) For EMI modeling tools a PEEC (partial equivalent electrical circuit) is used as a good approximation using smaller quivalent lumped sections. (3) S-parameter extraction. Any model should relate to the above. These processes assume defining beforehand the ground/power pins and terminating the other (in-between) pins appropriately to extract the parameters. This whole issue is subject to more technical discussion in which Raj is invited to participate. AR - Stephen Peters submit BIRD28.2 and also supply Raj Mittra directly with any graphical information for review at rmittra@decwa.ece.uiuc.edu. AR - Bob Ross add Dr. Mittra to reflector - [Done] PIN PROGRAMMABLE BUFFER STRENGTHS Arpad Muranyi submitted BIRD30 proposing a [Multiple Model] keyword. Discussion will occur on the reflector. One quick comment was that if the buffers have selections from different power rails (e.g., a 3.3V buffer and a 5V buffer), there may be some interaction with the [Pin Mapping] keyword which defines the connectivity of groupings of power and gnd rails to various buffer models. TTL DRIVERS Egg 6 has been started from Jon Powell, but there was no time for discussion. NEXT MEETING: It is set on Friday, August 25 1995. Final Ratification of EIA IBIS response to comments is expected. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Modeling Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com 10220 SW Nimbus Ave, K4, Portland, OR 97223 To become a voting member of the EIA IBIS Open Forum, send email to ibis-info@vhdl.org for instructions. If you want to join the e-mail reflector (ibis@vhdl.org), send e-mail to the IBIS secretary at ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From bob@icx.com Wed Aug 16 19:16:49 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24356; Wed, 16 Aug 95 19:16:49 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Aug 95 19:09 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Aug 95 19:12 PDT Message-Id: Date: Wed, 16 Aug 95 19:12 PDT From: bob@icx.com ( Bob Ross) To: 73053.721@compuserve.com, 75123.3477@compuserve.com, ibis@vhdl.org Subject: IBISCHK2 TESTMATRIX UPDATE Hello Fellow IBISans, Paul and Ron: I checked IBISCHK2, Version 8 and found the following: (1) The "Banded_matrix" works correctly most of the time based on BIRD29.2. However, there are a few cases which are not caught and which appear to create pointer problems. If I discover other cases, I will report them directly. The attached pkg2.ibs shows some of the problems. This appears to be the only problem area remaining. (2) The Sparse matrix problems previously reported: - ALL FIXED (3) Finally, an additional test on each [Component]'s [Pin] list is needed if it has a [Package Model] keyword. The [Define Package Model] section contains a [Pin Numbers] list that must match the entries of the [Pin] list both in content and quantity. The order can be different. This added comparison test should be done for each [Component] even if they refer to the same [Package Model] because the order and content of each [Component] [Pin] list can differ. FIXED Again, Great Job Ron and Paul! Bob Ross Interconnectix, Inc. A TEST MATRIX FOR IBIS VERSION 2h (Beta 8) DATE: 10/31/94, 12/2/94, 1/26/95, 3/4/95, 3/8/95 5/25/95 7/6/95, 8/16/95 SPECIFICATION TESTED PASS Comments/who tested --------------------------------------+-----+-----------------------------+ Test that the parser only | | | accepts 1.0, 1.1, 2.0, 2.1 as | | | valid arguments to the [IBIS Ver] | yes | Stephen Peters | keyword. | | | | | | Tab character warning | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Scaling Factors: | | | | | | Test that the parser recognizes | | | "T", "G" and "f" as valid scaling | yes | No indication either way | factors. | | Bob Ross - this is proper | | | operation | Test that the parser does not | | | recognize "t", "g" and "F" as | yes | No indication either way | Valid scaling factors. | | Bob Ross - proper operation | | | | --------------------------------------+-----+-----------------------------+ Keywords rules: | | | | | | Test that the parser recognizes | | | the [GND clamp] and [PWR clamp] | yes | Stephen Peters | keywords without the underscore. | | | Test Underscore rule for 3-word | yes | Bob Ross | Keyoreds - all 4 cases. | | | | | | Test that the parser issues an | | | error if a keyword does not begin | yes | Stephen Peters | in column 1. | | | | | | Test case insensitivity of all | | | keywords, reserved words and | yes | Pin mapping keyword does not| sub-parameters | | recognize "power" and "gnd" | | | Bob Ross - OK, should be | | | "pulldown_ref", "pullup_ref,| | | "gnd_clamp_ref", and | | | "power_clamp_ref" | | | | --------------------------------------+-----+-----------------------------+ Comments and Notes: | | | | | | Test that the parser does not | | | accept "+" and "-" as valid | yes | Stephen Peters | comment characters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Copyright] keyword. | | | | | | | | | --------------------------------------+-----+-----------------------------+ Component keyword related: | | | | | | Test that the parser issues an | | | error if the [Component] keyword | yes | Stephen Peters | has no component name after it. | | | | | | Test that the parser issues a warning | | | if the component name contains blanks | yes | Stephen Peters | | | | Test the component name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | " | parser fails if name > 40 characters | yes | " | | | | Test that the parser issues an | | | error if the [Manufacture] keyword | yes | Stephen Peters | has no Manufactures name after it. | | | | | | Test the Manufactures name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | Stephen Peters | parser fails if name > 40 characters | yes | Stephen Peters | | | | Test that an .ibs file can contain | yes | Bob Ross | more than one [Component] keyword | | | and component description. | | | | | | --------------------------------------+-----+-----------------------------+ Pin keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin] keyword. | | | | | | Test that the parser issues a | | | error when every model_name does | yes | Bob Ross | not have a corresponding model | | (I don't see the problem) | defined. | | | | | | Test the "3 column or 6 column" | | | rule. | yes | Stephen Peters | | | | Test that the parser issues an error | | | when non-numeric data is in the pin | yes | Stephen Peters | data columns | | | | | | Test that [Pin] entries agree with | yes | Bob Ross | [Pin Numbers] entries if the [Package | | Fixed | Model] keyword is used. | | | | | | --------------------------------------+-----+-----------------------------+ Package Model related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Package Model] keyword. | | | | | | Test the package model name length | yes | Bob Ross | rules | | Fixed: | parser accepts name < 40 characters | yes | Name is taken as a DOS file | parser accepts name = 40 characters | yes | name and not as argument to | parser fails if name > 40 characters | yes | the [Define Package Model] | | | keyword | Verify that the parser issues an | | | error if it cannot find: | | | | | | 1. A [Define Package Model] keyword | | | that has the same argument as the | yes | Bob Ross | [Package Model] keyword or | | | | | | 2. An external .pkg file that has | yes | Bob Ross | a [Define Package Model] keyword | | | with has the same argument as the | | | [Package Model] keyword. | | | | | | 3. Test that the parser recognizes | | | all keywords in the package model | | | description and operation below: | | | (1) Error if Missing | | | (2) Error if Duplicate | | | (3) Error if Wrong Argument | | | [Define Package Model] 1,2,3 | yes | Bob Ross | [Manufacturer] 1,2,3 | yes | | [OEM] 1,2,3 | yes | | [Description] 1,2,3 | yes | | [Number of Pins] 1,2,3 | yes | fixed | [Pin Numbers] 1,2,3 | yes | | [Model Data] 1,2 | yes | | [Resistance Matrix] 2,3 | yes | | [Inductance Matrix] 1,2,3 | yes | | [Capacitance Matrix] 1,2,3 | yes | | [Bandwidth] 1,2,3 | yes | fixed | [Row] 1,2,3-fails | NO | (problems below) | [End Model Data] 1,2 | yes | Bob Ross | [End Package Data] 1,2 | yes | " | | | | | | | 4. Full_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] number entry (all rows entered) | yes | fixed | [Row] number entry (ascending order) | yes | | [Row] format (upper triange matrix) | yes | fixed | [Row] format (excessive data) | yes | | [Row] format (missing data) | yes | fixed | | | | 5. Banded_matrix Tests | | Bob Ross | [Bandwidth] req'd test | yes | fixed | [Bandwidth] argument req'd | yes | | [Bandwidth] argument value | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] number entry (all rows entered) | yes | | [Row] number entry (ascending order) | yes | | [Row] format (excessive data) | yes | | [Row] format (missing data) | yes | fixed | [Row] format non-circular coupling | yes | | [Row] format circular coupling (cc) | NO | BIRD29.2 | [Row] format bandwidth limits (cc) | yes | BIRD29.2 fixed | | | | 6. Sparse_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] number entry (all rows entered) | yes | fixed | [Row] number entry (ascending order) | yes | fixed | [Row] index match | yes | | [Row] index upper-triangle | yes | fixed | [Row] index repeated | yes | | [Row] index (alpha string) | yes | Fixed | [Row] format (excessive data) | yes | fixed | [Row] format (missing data) | yes | fixed | | | | --------------------------------------+-----+-----------------------------+ Pin Mapping keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin Mapping] keyword. | | | | | | Test that the parser issues an | | | error if every pin listed in the | yes | Bob Ross - fixed | [Pin] keyword does not have an | | | entry in the [Pin Mapping] table | | | | | | Test the "3 column or 5 column" | yes | Stephen Peters | rule. | | | | | | Test that NC is a valid entry | | | in a column. | yes | Stephen Peters | | | | Test that each unique entry label | | | must connect to at least one pin | | | whose model name is POWER or GND | yes | Stephen Peters | | | | Test that NA is NOT a valid | | | column entry | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Diff Pin keyword related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Diff Pin] keyword. | | | | | | Test that the parser recognizes | yes | Bob Ross | the 5 associated sub-parameters | | | | | | Test the "4 column or 6 column" | yes | Bob Ross | rule. | | | | | | Test that NC is NOT a valid | yes | Bob Ross | column entry. | | | | | | Test that NA is a valid column | yes | Bob Ross | entry. | | | | | | Reports error for duplicate pin | yes | Bob Ross | numbers. | | | | | | --------------------------------------+-----+-----------------------------+ [Model] keyword: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Model] keyword. | | | | | | Test that the parser recognizes | | | each Model_type: | | | Input | yes | Bob Ross | Output | yes | | I/O | yes | | 3-state | yes | | Open_drain | yes | | I/O_open_drain | yes | | Open_sink | yes | | I/O_open_sink | yes | | Open_source | yes | | I/O_open_source | yes | | Input_ECL | yes | | Output_ECL | yes | | I/O_ECL | yes | | Terminator | yes | | | | | Test that the parser issues | | | a warning if an input type model | yes | Stephen Peters | does not have Vinh or Vinl defined. | | | For All I/O_* cases. | yes | Bob Ross | | | | | | | Test that the parser issues an | | | error if the Model_type or C_comp | yes | Stephen Peters | sub-parameters are missing. | | | | | | Test that the parser accepts a | | | [Model] description with only the | | | Model_type and C_comp sub-params | yes | Stephen Peters | defined. | | | | | | Test that the parser allows NA in | | | the min and max columns only of the | yes | Stephen Peters | C_Comp sub-parameter. | | | | | | Test that the parser allows only | | | Non-inverting and Inverting as | yes | Stephen Peters | choices for the Polarity sub-param | | | | | | Test that the parser allows only | | | Active-High and Active-Low as | yes | Stephen Peters | choices for the Enable sub-param | | | | | | Test that the parser recognizes | | | the Vmeas, Cref, Rref and Vref | yes | Stephen Peters | sub-parameters. | | | | | | --------------------------------------+-----+-----------------------------+ Temperature keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Temperature Range] keyword | | | | | | --------------------------------------+-----+-----------------------------+ Power supply rail related: | | | | | | Test that the parser recognizes | | | the supply rail keywords | | | [Voltage Range] | yes | Stephen Peters | [Pullup Reference] | " | | [Pulldown Reference] | " | | [POWER Clamp Reference] | " | | [GND Clamp Reference] | " | | | | | Test that the parser issues an | | | error if the [Voltage Range] | | | keyword is absent and all four of | | | the other supply rail keywords are | yes | Stephen Peters | NOT present. | | | | | | --------------------------------------+-----+-----------------------------+ I/V table related: | | | | | | Test that the parser recognizes | | | the [Pullup], [Pulldown], [GND | yes | Stephen Peters | Clamp] and [Power Clamp] keywords. | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | Test that the parser issues an | yes | Bob Ross | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Stephen Peters | than two points. | | | | | | Test that the parser issues a | yes | Bob Ross | warning if non-monotonic data | | | is found. | | | Test for One Warning per Column | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Terminator related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Rgnd], [Rpower], [Rac] and | | | [Cac] keywords. | | | | | | Test if [Rac], then [Cac] req'd. | yes | Bob Ross | | | | Test if [Cac], then [Rac] req'd. | yes | Bob Ross | | | | Test if parser issues an error with | | | above keywords AND Model_type is NOT | yes | Bob Ross | Terminator. | | | | | | Test that parser DOES NOT issue an | yes | Bob Ross | error if above models are NOT | | | defined. (Clamps or no components | | | can also be "Terminators") | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | --------------------------------------+-----+-----------------------------+ Ramp keyword related: | | | | | | Test that the parser recognizes | | | the [Ramp] keyword and the | yes | Stephen Peters | dv/dt_r and dv/dt_f sub-parameters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the R_load sub-parameter. | | | | | | Test that the R_load sub-parameter | yes | Stephen Peters | is optional. | | | | | | --------------------------------------+-----+-----------------------------+ Waveform Related: | | | | | | Test that the parser recognizes | | | the [Rising Waveform] and [Falling | yes | Bob Ross | Waveform] keywords. | | | | | | Test that the parser recognizes | | | the sub-parameters: | | | R_fixture | yes | Bob Ross | V_fixture | yes | | V_fixture_max | yes | | V_fixture_min | yes | | C_fixture | yes | | L_fixture | yes | | R_dut | yes | | L_dut | yes | | C_dut | yes | | | | | Test that the parser issues an | | | error if the R_fixture and | yes | Bob Ross | V_fixture sub-parameters are not | | | present. | | | | | | Test that the parser issues an | | | error if a column contains over | yes | Bob Ross | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Bob Ross | than two points. | | | | | | Test NA permitted in typical column | yes | Bob Ross | --------------------------------------+-----+-----------------------------+ |*************************************************************** | [IBIS Ver] 2.1 [File Name] pkg2.ibs [File Rev] 0.1 [Date] August 16, 1995 [Source] Interconnectix Inc. [Disclaimer] Provided for modeling purposes only. Results are not guaranteed. | |*************************************************************** | [Component] PACKAGE-TEST [Manufacturer] Test File [Package] | variable typ min max R_pkg 0.0m NA NA L_pkg 0.0nH NA NA C_pkg 0.0pF NA NA | |*************************************************************** | [Pin] signal_name model_name R_pin L_pin C_pin A1 P_1 NC 2 P_2 NC 5 P_3 NC 4 P_4 NC 3 P_5 NC [Package Model] test [Define Package Model] test [Manufacturer] anyone [OEM] this file has [Description] BIRD29.2 tests [Number of Pins] 5 [Pin Numbers] A1 2 3 4 5 [Model Data] [Inductance Matrix] Banded_matrix | Should Fail [Bandwidth] 2 [Row] A1 .01 .01 .01 | .01 | Adding another column here reports correct error [Row] 2 .01 .01 .01 [Row] 3 .01 .01 .01 | .01 | Adding another column creates "PROGRAM BUG" [Row] 4 .01 .01 | Needs 3 entries for circle-back case. [Row] 5 .01 .01 .01 | .01 | Adding another column here reports correct error [Capacitance Matrix] Banded_matrix | [Bandwidth] 2 | Get "PROGRAM BUG" if [Bandwidth] [Row] A1 | missing or has wrong argument .01 .01 .01 .01 | such as 0, 1, 2 [Row] 2 .01 .01 .01 .01 [Row] 3 .01 .01 .01 .01 [Row] 4 .01 .01 .01 .01 [Row] 5 .01 .01 .01 .01 [Resistance Matrix] Banded_matrix [Bandwidth] 1 [Row] A1 .01 .01 [Row] 2 .01 .01 [Row] 3 .01 .01 [Row] 4 .01 .01 | .01 | Adding another columm here creates "PROGRAM BUG" [Row] 5 .01 .01 [End Model Data] [End Package Model] | [End] From EGJJ77A@mail.prodigy.com Thu Aug 17 09:02:30 1995 Return-Path: Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18685; Thu, 17 Aug 95 09:02:30 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.prodigy.com (8.6.10/8.6.9) with SMTP id KAA22884; Thu, 17 Aug 1995 10:20:31 -0400 Date: Thu, 17 Aug 1995 10:18:59 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.09997113.EGJJ77A@prodigy.com> To: ibis@vhdl.org, roadmap-eii@cfi.org -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- I am working as an independent with CFI, EDAC, and Sematech on a 10 year roadmap for electronic CAD standards. Our work is described on the WWW at http://www.cfi.org/roadmap/roadMap-eii-report.html. Our 10 year roadmap should show how we are going to do delay above the chip. I thought we would be able to state IBIS, but it doesn't handle the basic CMOS IV .5um IBM ASIC drivers. Bob Ward says Version 2.x does not handle all the TI drivers either. Can we establish some steps in the IBIS group to correct this which we could refer to in our roadmap? Will Hobbs said, " IBIS can handle non-monotonic data. The parser will detect such data and issue a warning in the possibility the data is in error, but will correctly parse the data. Whether a given simulator will treat the data correctly is a question that should be posed to the forum at large, as it will generate a good discussion, as well as answers to your concerns." Is it really just the parser when both Bob Ward and my IBM contacts say Version 2.1 will not handle the non monotonic drivers? Is there a way to prove that Version 2.1 of IBIS will truly handle the non monotonic case as in the IBM CMOS IV drivers? If IBIS 2.1 can handle it, perhaps these circuits should be part of a certification plan. Ron Christopher From Arpad_Muranyi@ccm.fm.intel.com Thu Aug 17 10:37:08 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04187; Thu, 17 Aug 95 10:37:08 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sj8lp-000UgVC; Thu, 17 Aug 95 10:30 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sj8lo-000txLC; Thu, 17 Aug 95 10:30 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 17 Aug 95 10:30:20 PDT Date: Thu, 17 Aug 95 10:21:00 PDT From: Arpad Muranyi Message-Id: To: EGJJ77A@mail.prodigy.com, ibis@vhdl.org, roadmap-eii@cfi.org Subject: Re: Text item: Ron, There are many aspects to non-monotonic data. For example, some non-monotonic data could be caused by noise, others by the behavior of the device. The former case can be solved by filtering, but the latter case is more complicated. In order to tell you what IBIS can or cannot do, I would like to have a little more description on those devices that you are referring to. Can you tell me how they are non-monotonic? Arpad Muranyi Intel Corporation ================================================================================ -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- I am working as an independent with CFI, EDAC, and Sematech on a 10 year roadmap for electronic CAD standards. Our work is described on the WWW at http://www.cfi.org/roadmap/roadMap-eii-report.html. Our 10 year roadmap should show how we are going to do delay above the chip. I thought we would be able to state IBIS, but it doesn't handle the basic CMOS IV .5um IBM ASIC drivers. Bob Ward says Version 2.x does not handle all the TI drivers either. Can we establish some steps in the IBIS group to correct this which we could refer to in our roadmap? 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***. To: ibis@vhdl.org, roadmap-eii@cfi.org Message-Id: <013.09997113.EGJJ77A@prodigy.com> X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Thu, 17 Aug 1995 10:18:59 EDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.pr odigy.com (8.6.10/8.6.9) with SMTP id KAA22884; Thu, 17 Aug 1995 10:20:31 -0400 Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18685; Thu, 17 Aug 95 09:02:30 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 17 Aug 95 09 :02:08 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sj7OV-000twpC; Thu, 17 Aug 95 09:02 PDT From Will_Hobbs@ccm2.jf.intel.com Thu Aug 17 10:45:02 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05691; Thu, 17 Aug 95 10:45:02 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sj8tJ-000UgMC; Thu, 17 Aug 95 10:38 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sj8tI-000twZC; Thu, 17 Aug 95 10:38 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Thu, 17 Aug 95 10:38:04 PDT Date: Thu, 17 Aug 95 10:33:00 PDT From: Will Hobbs Message-Id: To: EGJJ77A@mail.prodigy.com, ibis@vhdl.org, roadmap-eii@cfi.org Subject: Re: Text item: Ron, We've discussed this further in the Forum, and Jon Powell of Quad Design correctly points out that non-monotonic data implies some form of feedback, which IBIS doesn't handle. Thus, though it is possible to specify non-monotonic data in an IBIS file, there is not enough information in the current version to support accurate simulation of buffers whose output is non-monotonic. I would be very happy to see IBIS expanded to handle this problem. Regards, Will Hobbs -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- I am working as an independent with CFI, EDAC, and Sematech on a 10 year roadmap for electronic CAD standards. Our work is described on the WWW at http://www.cfi.org/roadmap/roadMap-eii-report.html. Our 10 year roadmap should show how we are going to do delay above the chip. I thought we would be able to state IBIS, but it doesn't handle the basic CMOS IV .5um IBM ASIC drivers. Bob Ward says Version 2.x does not handle all the TI drivers either. Can we establish some steps in the IBIS group to correct this which we could refer to in our roadmap? Will Hobbs said, " IBIS can handle non-monotonic data. The parser will detect such data and issue a warning in the possibility the data is in error, but will correctly parse the data. Whether a given simulator will treat the data correctly is a question that should be posed to the forum at large, as it will generate a good discussion, as well as answers to your concerns." Is it really just the parser when both Bob Ward and my IBM contacts say Version 2.1 will not handle the non monotonic drivers? Is there a way to prove that Version 2.1 of IBIS will truly handle the non monotonic case as in the IBM CMOS IV drivers? If IBIS 2.1 can handle it, perhaps these circuits should be part of a certification plan. Ron Christopher 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***. To: ibis@vhdl.org, roadmap-eii@cfi.org Message-Id: <013.09997113.EGJJ77A@prodigy.com> X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Thu, 17 Aug 1995 10:18:59 EDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.pr odigy.com (8.6.10/8.6.9) with SMTP id KAA22884; Thu, 17 Aug 1995 10:20:31 -0400 Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18685; Thu, 17 Aug 95 09:02:30 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 17 Aug 95 09 :42:38 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 17 Aug 9 5 09:42:53 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sj81w-000twpC; Thu, 17 Aug 95 09:42 PDT From uunet!qdt.com!jonp@uunet.uu.net Thu Aug 17 11:17:04 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15723; Thu, 17 Aug 95 11:17:04 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzdfc21949; Thu, 17 Aug 1995 14:08:56 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 17 Aug 1995 14:10:07 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00584; Thu, 17 Aug 95 10:09:40 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA25180; Thu, 17 Aug 95 10:09:40 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzdey04987; Thu, 17 Aug 1995 13:08:53 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 17 Aug 1995 13:08:44 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00523; Thu, 17 Aug 95 09:49:16 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA25096; Thu, 17 Aug 95 09:49:16 PDT Date: Thu, 17 Aug 95 09:49:16 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9508171649.AA25096@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA16015; Thu, 17 Aug 95 09:49:15 PDT To: uunet!uunet!prodigy.com!EGJJ77A@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!cfi.org!roadmap-eii@uunet.uu.net In-Reply-To: <013.09997113.EGJJ77A@prodigy.com> (uunet!prodigy.com!EGJJ77A) The problem isn't that IBIS cannot handle non-monotonic drivers. The problem is more that the silicon vendors have not yet supplied the necessary information about their devices that would let anyone figure out how to model them. Detailed SPICE models that reliably predict behavior would be necessary in order for the IBIS committe to come up with an acceptable methodology to perform behavioral modeling. Current versions of these drivers are so secret that we are not even sure we can admit that we know they are secret. jon powell Quad Design From medtron!relay.medtronic.com!hsin-huei.lin@uunet.uu.net Thu Aug 17 14:14:31 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03188; Thu, 17 Aug 95 14:14:31 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzdfo13909; Thu, 17 Aug 1995 17:07:48 -0400 Received: from medtron.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 17 Aug 1995 17:07:39 -0400 Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA23740 (5.65c/IDA-1.4.4 for ); Thu, 17 Aug 1995 16:05:14 -0500 Received: from mspeos.cis.corp.medtronic.COM (eos.cis.corp.medtronic.COM) by medtron.medtronic.COM with SMTP id AA23736 (5.65c/IDA-1.4.4 for ); Thu, 17 Aug 1995 16:05:12 -0500 Received: from eos.cis.corp.medtronic.COM by mspeos.cis.corp.medtronic.COM (5.x/SMI-SVR4) id AA02875; Thu, 17 Aug 1995 16:04:47 -0500 Received: from MSPEOS-Message_Server by eos.cis.corp.medtronic.COM with Novell_GroupWise; Thu, 17 Aug 1995 16:04:47 -0500 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 17 Aug 1995 16:05:20 -0500 From: Hsin-Huei Lin To: ibis@vhdl.org Subject: Error in running ibis_chk Hi, I tried to run ibis_chk v1.1 and get the following message: ERROR (line 28) - Second Pin Subparameter Must Be 'signal_name' Errors : 1 Could someone tell me what's wrong with my .ibs file? Hsin-Huei Lin Medtronic, Inc. -------------------ntest.ibs---------------------------- |******************************************************************************* | * ntest.ibs * IBIS 1.1 Model for D3 l1870a3 |******************************************************************************* | [IBIS Ver] 1.1 [Comment char] |_char [File name] ntest.ibs [Date] Thu Aug 10 16:42:16 1995 [File Rev] 1.0 [Source] s2ibis Version 1.2 SPICE to IBIS converter [Notes] The L_pkg and C_pkg are estimation from people in the Industry. [Disclaimer] This model is used for Allegro SNA only. | |******************************************************************************* | COMPONENT: D3 l1870a3 |******************************************************************************* | [Component] D3 l1870a3 [Manufacturer] Rice Creek [Package] | variable typ min max R_pkg 58.1m 38.8m 77.5m L_pkg 3nH 2nH 4nH C_pkg 0.5pF 0.3pF 0.7pF | |******************************************************************************* | [Pin] Signal_name model_name R_pin L_pin C_pin 1 ntest Input1 5 GND GND 6 PWR POWER | |******************************************************************************* | MODEL Input1 |******************************************************************************* | [Model] Input1 Model_type Input | C_comp 0.908pF NA NA | |******************************************************************************* | [Voltage range] 2.800 2.600 2.800 | |******************************************************************************* | [GND_clamp] | Voltage I(typ) I(min) I(max) | -2.800 -3.374e+07 -2.897e+07 -4.030e+07 -2.700 -3.151e+07 -2.705e+07 -3.767e+07 -2.600 -2.929e+07 -2.512e+07 -3.504e+07 -2.500 -2.707e+07 -2.319e+07 -3.241e+07 -2.400 -2.485e+07 -2.127e+07 -2.978e+07 -2.300 -2.262e+07 -1.934e+07 -2.715e+07 -2.200 -2.040e+07 -1.742e+07 -2.452e+07 -2.100 -1.818e+07 -1.549e+07 -2.189e+07 -2.000 -1.595e+07 -1.357e+07 -1.926e+07 -1.900 -1.373e+07 -1.164e+07 -1.663e+07 -1.800 -1.151e+07 -9.723e+06 -1.400e+07 -1.700 -9.289e+06 -7.798e+06 -1.137e+07 -1.600 -7.066e+06 -5.873e+06 -8.747e+06 -1.500 -4.843e+06 -3.948e+06 -6.117e+06 -1.400 -2.620e+06 -2.023e+06 -3.488e+06 -1.300 -4.326e+05 -2.670e+05 -8.582e+05 -1.200 -1.192e+04 -1.190e+04 -1.301e+04 -1.100 -3.287e+02 -5.311e+02 -1.859e+02 -1.000 -9.065e+00 -2.369e+01 -2.657e+00 -0.900 -2.511e-01 -1.058e+00 -3.883e-02 -0.800 -7.551e-03 -4.818e-02 -8.403e-04 -0.700 -4.009e-04 -2.613e-03 -3.888e-05 -0.600 -2.842e-05 -2.521e-04 -2.426e-06 -0.500 -1.469e-06 -2.301e-05 -4.431e-07 -0.400 -7.119e-08 -1.208e-06 -1.463e-08 -0.300 -2.026e-09 -5.633e-08 -1.608e-10 -0.200 -5.094e-11 -2.480e-09 -1.945e-12 -0.100 -1.337e-12 -1.079e-10 -3.185e-14 0.000 -1.338e-14 -2.515e-12 -5.603e-15 0.100 1.595e-14 -4.848e-13 -4.535e-15 0.200 1.877e-14 -8.318e-14 -3.823e-15 0.300 2.084e-14 2.454e-13 -3.116e-15 0.400 2.289e-14 5.708e-13 -2.410e-15 0.500 2.493e-14 8.958e-13 -1.702e-15 0.600 2.697e-14 1.221e-12 -9.963e-16 0.700 2.901e-14 1.546e-12 -2.896e-16 0.800 3.104e-14 1.871e-12 4.163e-16 0.900 3.307e-14 2.195e-12 1.124e-15 1.000 3.510e-14 2.520e-12 1.831e-15 1.100 3.618e-14 2.537e-12 2.536e-15 1.200 3.726e-14 2.554e-12 3.241e-15 1.400 3.941e-14 2.587e-12 4.656e-15 1.600 4.154e-14 2.620e-12 6.066e-15 1.800 4.365e-14 2.766e-12 7.487e-15 2.000 4.607e-14 2.911e-12 8.887e-15 2.200 4.847e-14 3.055e-12 1.030e-14 2.400 5.084e-14 3.203e-12 1.171e-14 2.600 5.320e-14 5.264e-12 1.311e-14 2.800 6.301e-14 1.255e-09 1.454e-14 | [POWER_clamp] | Voltage I(typ) I(min) I(max) | -2.800 2.081e+07 1.794e+07 2.475e+07 -2.700 1.947e+07 1.679e+07 2.317e+07 -2.600 1.814e+07 1.563e+07 2.159e+07 -2.500 1.680e+07 1.447e+07 2.001e+07 -2.400 1.546e+07 1.332e+07 1.843e+07 -2.300 1.413e+07 1.216e+07 1.685e+07 -2.200 1.279e+07 1.100e+07 1.527e+07 -2.100 1.146e+07 9.849e+06 1.369e+07 -2.000 1.012e+07 8.692e+06 1.211e+07 -1.900 8.789e+06 7.535e+06 1.053e+07 -1.800 7.453e+06 6.378e+06 8.953e+06 -1.700 6.117e+06 5.221e+06 7.372e+06 -1.600 4.781e+06 4.065e+06 5.792e+06 -1.500 3.445e+06 2.908e+06 4.211e+06 -1.400 2.109e+06 1.751e+06 2.631e+06 -1.300 7.738e+05 5.942e+05 1.050e+06 -1.200 3.020e+04 3.015e+04 3.295e+04 -1.100 8.325e+02 1.345e+03 4.708e+02 -1.000 2.295e+01 5.999e+01 6.725e+00 -0.900 6.328e-01 2.676e+00 9.622e-02 -0.800 1.755e-02 1.195e-01 1.426e-03 -0.700 5.194e-04 5.412e-03 2.459e-05 -0.600 1.695e-05 2.664e-04 3.985e-07 -0.500 4.949e-07 1.367e-05 8.803e-09 -0.400 1.408e-08 6.261e-07 1.571e-10 -0.300 3.926e-10 2.800e-08 2.510e-12 -0.200 1.113e-11 1.255e-09 5.948e-14 -0.100 3.720e-13 5.881e-11 1.606e-14 -0.000 6.301e-14 5.264e-12 1.454e-14 | [End] From bob@icx.com Thu Aug 17 14:32:02 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03320; Thu, 17 Aug 95 14:32:02 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 17 Aug 95 14:25 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 17 Aug 95 14:27 PDT Message-Id: Date: Thu, 17 Aug 95 14:27 PDT From: bob@icx.com ( Bob Ross) To: hsin-huei.lin@medtronic.com, ibis@vhdl.org Subject: Re: Error in running ibis_chk Hsin-Huei Lin: Change "Signal_name" to all lower case "signal_name", and ibis_chk gives 0 errors. Bob Ross, Interconnectix, Inc. > From: Hsin-Huei Lin > To: ibis@vhdl.org > Subject: Error in running ibis_chk > Status: R > Hi, > I tried to run ibis_chk v1.1 and get the following message: > ERROR (line 28) - Second Pin Subparameter Must Be 'signal_name' > Errors : 1 > Could someone tell me what's wrong with my .ibs file? > Hsin-Huei Lin > Medtronic, Inc. From Arpad_Muranyi@ccm.fm.intel.com Thu Aug 17 14:39:56 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03361; Thu, 17 Aug 95 14:39:56 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sjCXd-000UgLC; Thu, 17 Aug 95 14:31 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sjCXd-000twVC; Thu, 17 Aug 95 14:31 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 17 Aug 95 14:31:57 PDT Date: Thu, 17 Aug 95 14:26:00 PDT From: Arpad Muranyi Message-Id: To: medtron!relay.medtronic.com!hsin-huei.lin@uunet.uu.net, ibis@vhdl.org Subject: Re: Error in running ibis_chk Text item: Try it lower-case: "signal_name"! Arpad Muranyi =============================================================================== Hi, I tried to run ibis_chk v1.1 and get the following message: ERROR (line 28) - Second Pin Subparameter Must Be 'signal_name' Errors : 1 Could someone tell me what's wrong with my .ibs file? Hsin-Huei Lin Medtronic, Inc. -------------------ntest.ibs---------------------------- |****************************************************************************** * | * ntest.ibs * IBIS 1.1 Model for D3 l1870a3 |****************************************************************************** * | [IBIS Ver] 1.1 [Comment char] |_char [File name] ntest.ibs [Date] Thu Aug 10 16:42:16 1995 [File Rev] 1.0 [Source] s2ibis Version 1.2 SPICE to IBIS converter [Notes] The L_pkg and C_pkg are estimation from people in the Industry. [Disclaimer] This model is used for Allegro SNA only. | |****************************************************************************** * | COMPONENT: D3 l1870a3 |****************************************************************************** * | [Component] D3 l1870a3 [Manufacturer] Rice Creek [Package] | variable typ min max R_pkg 58.1m 38.8m 77.5m L_pkg 3nH 2nH 4nH C_pkg 0.5pF 0.3pF 0.7pF | |****************************************************************************** * | [Pin] Signal_name model_name R_pin L_pin C_pin 1 ntest Input1 5 GND GND 6 PWR POWER | |****************************************************************************** * | MODEL Input1 |****************************************************************************** * | [Model] Input1 Model_type Input | C_comp 0.908pF NA NA | |****************************************************************************** * | [Voltage range] 2.800 2.600 2.800 | |****************************************************************************** * | [GND_clamp] | Voltage I(typ) I(min) I(max) | -2.800 -3.374e+07 -2.897e+07 -4.030e+07 -2.700 -3.151e+07 -2.705e+07 -3.767e+07 -2.600 -2.929e+07 -2.512e+07 -3.504e+07 -2.500 -2.707e+07 -2.319e+07 -3.241e+07 -2.400 -2.485e+07 -2.127e+07 -2.978e+07 -2.300 -2.262e+07 -1.934e+07 -2.715e+07 -2.200 -2.040e+07 -1.742e+07 -2.452e+07 -2.100 -1.818e+07 -1.549e+07 -2.189e+07 -2.000 -1.595e+07 -1.357e+07 -1.926e+07 -1.900 -1.373e+07 -1.164e+07 -1.663e+07 -1.800 -1.151e+07 -9.723e+06 -1.400e+07 -1.700 -9.289e+06 -7.798e+06 -1.137e+07 -1.600 -7.066e+06 -5.873e+06 -8.747e+06 -1.500 -4.843e+06 -3.948e+06 -6.117e+06 -1.400 -2.620e+06 -2.023e+06 -3.488e+06 -1.300 -4.326e+05 -2.670e+05 -8.582e+05 -1.200 -1.192e+04 -1.190e+04 -1.301e+04 -1.100 -3.287e+02 -5.311e+02 -1.859e+02 -1.000 -9.065e+00 -2.369e+01 -2.657e+00 -0.900 -2.511e-01 -1.058e+00 -3.883e-02 -0.800 -7.551e-03 -4.818e-02 -8.403e-04 -0.700 -4.009e-04 -2.613e-03 -3.888e-05 -0.600 -2.842e-05 -2.521e-04 -2.426e-06 -0.500 -1.469e-06 -2.301e-05 -4.431e-07 -0.400 -7.119e-08 -1.208e-06 -1.463e-08 -0.300 -2.026e-09 -5.633e-08 -1.608e-10 -0.200 -5.094e-11 -2.480e-09 -1.945e-12 -0.100 -1.337e-12 -1.079e-10 -3.185e-14 0.000 -1.338e-14 -2.515e-12 -5.603e-15 0.100 1.595e-14 -4.848e-13 -4.535e-15 0.200 1.877e-14 -8.318e-14 -3.823e-15 0.300 2.084e-14 2.454e-13 -3.116e-15 0.400 2.289e-14 5.708e-13 -2.410e-15 0.500 2.493e-14 8.958e-13 -1.702e-15 0.600 2.697e-14 1.221e-12 -9.963e-16 0.700 2.901e-14 1.546e-12 -2.896e-16 0.800 3.104e-14 1.871e-12 4.163e-16 0.900 3.307e-14 2.195e-12 1.124e-15 1.000 3.510e-14 2.520e-12 1.831e-15 1.100 3.618e-14 2.537e-12 2.536e-15 1.200 3.726e-14 2.554e-12 3.241e-15 1.400 3.941e-14 2.587e-12 4.656e-15 1.600 4.154e-14 2.620e-12 6.066e-15 1.800 4.365e-14 2.766e-12 7.487e-15 2.000 4.607e-14 2.911e-12 8.887e-15 2.200 4.847e-14 3.055e-12 1.030e-14 2.400 5.084e-14 3.203e-12 1.171e-14 2.600 5.320e-14 5.264e-12 1.311e-14 2.800 6.301e-14 1.255e-09 1.454e-14 | [POWER_clamp] | Voltage I(typ) I(min) I(max) | -2.800 2.081e+07 1.794e+07 2.475e+07 -2.700 1.947e+07 1.679e+07 2.317e+07 -2.600 1.814e+07 1.563e+07 2.159e+07 -2.500 1.680e+07 1.447e+07 2.001e+07 -2.400 1.546e+07 1.332e+07 1.843e+07 -2.300 1.413e+07 1.216e+07 1.685e+07 -2.200 1.279e+07 1.100e+07 1.527e+07 -2.100 1.146e+07 9.849e+06 1.369e+07 -2.000 1.012e+07 8.692e+06 1.211e+07 -1.900 8.789e+06 7.535e+06 1.053e+07 -1.800 7.453e+06 6.378e+06 8.953e+06 -1.700 6.117e+06 5.221e+06 7.372e+06 -1.600 4.781e+06 4.065e+06 5.792e+06 -1.500 3.445e+06 2.908e+06 4.211e+06 -1.400 2.109e+06 1.751e+06 2.631e+06 -1.300 7.738e+05 5.942e+05 1.050e+06 -1.200 3.020e+04 3.015e+04 3.295e+04 -1.100 8.325e+02 1.345e+03 4.708e+02 -1.000 2.295e+01 5.999e+01 6.725e+00 -0.900 6.328e-01 2.676e+00 9.622e-02 -0.800 1.755e-02 1.195e-01 1.426e-03 -0.700 5.194e-04 5.412e-03 2.459e-05 -0.600 1.695e-05 2.664e-04 3.985e-07 -0.500 4.949e-07 1.367e-05 8.803e-09 -0.400 1.408e-08 6.261e-07 1.571e-10 -0.300 3.926e-10 2.800e-08 2.510e-12 -0.200 1.113e-11 1.255e-09 5.948e-14 -0.100 3.720e-13 5.881e-11 1.606e-14 -0.000 6.301e-14 5.264e-12 1.454e-14 | [End] Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Error in running ibis_chk To: ibis@vhdl.org From: Hsin-Huei Lin Date: Thu, 17 Aug 1995 16:05:20 -0500 X-Mailer: Novell GroupWise 4.1 Message-Id: Received: from MSPEOS-Message_Server by eos.cis.corp.medtronic.COM with Novell_GroupWise; Thu, 17 Aug 1995 16:04:47 -0500 Received: from eos.cis.corp.medtronic.COM by mspeos.cis.corp.medtronic.COM (5.x/ SMI-SVR4) id AA02875; Thu, 17 Aug 1995 16:04:47 -0500 Received: from mspeos.cis.corp.medtronic.COM (eos.cis.corp.medtronic.COM) by med tron.medtronic.COM with SMTP id AA23736 (5.65c/IDA-1.4.4 for ); Thu, 17 Aug 1995 16:05:12 -0500 Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA23740 (5.65c/IDA-1.4.4 for ); Thu, 17 Aug 1995 16:05:14 -0500 Received: from medtron.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 17 Aug 1995 17:07:39 -0400 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzdfo13909; Thu, 17 Aug 1995 17:07:48 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03188; Thu, 17 Aug 95 14:14:31 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 17 Aug 95 14 :10:00 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sjCCP-000tx3C; Thu, 17 Aug 95 14:10 PDT From Arpad_Muranyi@ccm.fm.intel.com Thu Aug 17 17:03:27 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04272; Thu, 17 Aug 95 17:03:27 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sjEng-000UgMC; Thu, 17 Aug 95 16:56 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sjEnf-000txAC; Thu, 17 Aug 95 16:56 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 17 Aug 95 16:56:39 PDT Date: Thu, 17 Aug 95 16:46:00 PDT From: Arpad Muranyi Message-Id: To: jonp@qdt.com, ibis@vhdl.org Subject: Re: EGG Half Dozen Text item: Jon, I have an idea that might do the thing without an extra keyword. (I didn't spend much time on this, though, so I am not sure if this is fool proof). The I-V curves of bipolar pulldown structures usually cross the voltage axis above 0 volt, in other words, zero current is at approximately 0.15 V on those I-V curves. On the other hand, the I-V curves of CMOS pulldowns would go through the origin, since the channel behaves more like a voltage controlled resistor (i.e. no voltage, no current). If the I-V curve in an IBIS file is accurate enough to detect this difference, I think you can just look for the voltage at zero current, and if it is not zero, you could assume a bipolar device. Do you think this will work? Arpad =============================================================================== More Argument on EGG Half Dozen. Hopefully by now people have the hardcopy in hand and can look at the two IV curve groups. If we have no argument on how they look (at least, in general appearance) then my problem is this: As the "control" voltage changes on the CMOS gate only the IV curve strength changes. The zero millamp point stays constant (at ~VCC) this makes sense as all we are doing is making the CMOS gate more resistive. The TTL gate, however, changes its zero milliamp point, it being a totem pole arrangement and all. The point is, at risetime/2, what is the proper thevinin equivalent for the driver? You have to know if it is CMOS or TTL. If there is a fool proof way to determine this form the IV curve alone, they we are done, else I would like a new (optional?) KEYWORD. regards, jon (I hope I got this HALF-DOZEN joke out before bob or will). (If you still need hardcopy, let me know. Won't it be nice when I can just post HTML to a WWW EGG discussion page?). Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: EGG Half Dozen To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA10842; Thu, 10 Aug 95 10:09:50 PDT Message-Id: <9508101709.AA27974@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Thu, 10 Aug 95 10:09:52 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27974; Thu, 10 Aug 95 10:09:52 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00557; Thu, 10 Aug 95 10:09:52 PDT Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 10 Aug 1995 13:36:18 -0400 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzcfe02475; Thu, 10 Aug 1995 13:36:26 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04774; Thu, 10 Aug 95 10:43:05 PDT Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, 10 Aug 95 10 :39:38 -0700 Received: from aurora.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sgbZz-000twZC; Thu, 10 Aug 95 10:39 PDT From bob@icx.com Thu Aug 17 19:07:19 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05028; Thu, 17 Aug 95 19:07:19 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 17 Aug 95 19:00 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 17 Aug 95 19:03 PDT Message-Id: Date: Thu, 17 Aug 95 19:03 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD30 Comment To Arpad, Malan, IBIS Committee: I have been following the discussion regarding BIRD30 and have these additional comments. Eventually, I will be concerned about some syntax details, but at this time I am more concerned about the concepts and capabilities. The suggestion of providing selection of programmable buffers by some attribute method is very nice and would support some practical applications. However, at this time my position is to focus on the simpler selection by name method because (1) It captures the alternatives with the [Component] description for IBIS file default settings in one location rather than requiring inserting additional "Classes" information in [Model]s throughout the IBIS file. (2) Selection by name is consistent with existing selection methods for [Component], [Model], and [Package Model]. Names for alternative models could be descriptive, although this is not required. For ASIC models, the names are reasonably descriptive. (3) Simulators can extend any existing selection method most easily by named alternatives rather than by characteristics (even though there is some attractiveness to this approach). Setting up the IBIS file defaults or initial selections is one level. Ideally, simulators would have a corresponding mechanism to override the selection and support components configured differently in different locations. (4) It does not involve standardizing the "Classes" list of attributes. It does not involve establishing a new set of rules, restrictions, and possibly more defaults. Here are some possible areas where the [Model Selector] method could be used: (1) Configurable Components. As discussed, components are being offered with pins having programable buffer strengths and having 3.3 and 5.0 levels. Many other possiblilies exist. (2) ASIC Design Configurations. Groups of Pins can be selected for driving busses from a subset of model selections based on attributes such as buffer strength and slew rate limits. The user would be responsible for setting up the [Model Selector] keywords for each ASIC component (3) Specific Usage of Standard Parts. Some users may standardize on bi-directional components and use them also for input only or output only configurations. Under these conditions, the [Component] model which the contains I/O [Model](s) would be extended by the user for internal usage to include, for example, Input and Output (or 3-state) [Model] alternatives of the I/O [Model](s). The [Model Selector] syntax would list these alternatives. The simulator checking could be reduced with proper model selections when the bi-directional component is used in single direction applications. (4) Dynamically configurable buffers. I do not know whether on the fly buffer modification for various modes of operation is often being done. To do this requires the simulator to have a selection/reconfiguration mechanism for complete support. I look forward to more discussion on this at the Forum meetings and on the reflector. Bob Ross, Interconnectix, Inc. From erniem@mdhost.cse.TEK.COM Fri Aug 18 08:10:32 1995 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13873; Fri, 18 Aug 95 08:10:32 PDT Received: from inet1.tek.com by relay1.UU.NET with SMTP id QQzdii12190; Fri, 18 Aug 1995 11:03:11 -0400 From: erniem@mdhost.cse.TEK.COM Received: by inet1.tek.com id ; Fri, 18 Aug 1995 08:03:23 -0700 Received: from tektronix.tek.com(134.62.48.24) by inet1 via smap (V1.3) id sma021597; Fri Aug 18 08:02:58 1995 Received: from mdhost.cse.tek.com (tekadm1.cse.tek.com) by tektronix.TEK.COM (4.1/8.2) id AA24570; Fri, 18 Aug 95 08:01:43 PDT Received: from cauvery.CSE.TEK.COM by mdhost.cse.tek.com (4.1/8.1) id AB10307; Fri, 18 Aug 95 08:02:27 PDT Received: from localhost.TEK by cauvery.CSE.TEK.COM (4.1/8.0) id AA07894; Fri, 18 Aug 95 08:02:27 PDT Message-Id: <9508181502.AA07894@cauvery.CSE.TEK.COM> To: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Cc: uunet!uunet!prodigy.com!EGJJ77A@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!cfi.org!roadmap-eii@uunet.uu.net, erniem@mdhost.CSE.TEK.COM In-Reply-To: Your message of Thu, 17 Aug 95 09:49:16 -0700. <9508171649.AA25096@hal.qdt.com> Date: Fri, 18 Aug 95 08:02:26 PDT Sender: erniem@mdhost.cse.TEK.COM >The problem isn't that IBIS cannot handle non-monotonic drivers. The problem is >more that the silicon vendors have not yet supplied the necessary information about >their devices that would let anyone figure out how to model them. Detailed SPICE >models that reliably predict behavior would be necessary in order for the IBIS committe >to come up with an acceptable methodology to perform behavioral modeling. Current versions >of these drivers are so secret that we are not even sure we can admit that we know they >are secret. >jon powell >Quad Design The secrecy evidenced by silicon vendors is paralleled by the vendors of design tools using IBIS data. The mathematical usage of IBIS data is shrouded in mystery. Indeed, no part of the IBIS standard indicates how the data is to be used to insure that an adequate analytic representation of the silicon is made during signal integrity simulation. "Methodology" above refers to the acquisition of data, not modeling in the sense that occurs for circuit simulation such as with Spice. In the realm of Spice simulation, the design community, academia and CAD software suppliers debate at great length the analytic adequacy of representative equations. Strategies for mathematical representation lie at the core of model evolution. Within IBIS, public strategies appear to be data focused, generating great arguments concerning what measurements to make and how to format these for general distribution. In such an arena, engineers cannot decide whether the IBIS data contains the information and the tools contain the analytic horsepower to lead to a successful prediction of system performance. For CFI, EDAC orSematech to fashion a meaningful roadmap for addressing signal integrity issues for the next ten years I would suggest the move to the analytic focus that has proven so fruitful for integrated circuit design. Assemble university representatives, designers and suppliers of tools to debate a suitable mathematical representation for behavioral modeling of interconnect, packaging and silicon drivers and receivers. From fvance@FirePower.COM Fri Aug 18 10:07:09 1995 Return-Path: Received: from FirePower.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14886; Fri, 18 Aug 95 10:07:09 PDT Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA16087; Fri, 18 Aug 95 10:00:05 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA16569; Fri, 18 Aug 95 10:00:02 -0700 From: Fred Vance Message-Id: <9508181700.AA16569@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA04751; Fri, 18 Aug 95 10:00:00 -0700 Date: Fri, 18 Aug 95 10:00:00 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Subject: CFI, EDAC, and Sematech Cc: ibis@vhdl.org Ron, At the expense of advertising my ignorance, what are CFI, EDAC, and Sematech? I can make a good guess at the EDAC acronym, but I would appreciate someone telling me what they are and what is their charter. Thanks, Fred From fvance@FirePower.COM Fri Aug 18 10:31:05 1995 Return-Path: Received: from FirePower.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15083; Fri, 18 Aug 95 10:31:05 PDT Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA16179; Fri, 18 Aug 95 10:24:15 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA17966; Fri, 18 Aug 95 10:23:52 -0700 From: Fred Vance Message-Id: <9508181723.AA17966@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA04763; Fri, 18 Aug 95 10:23:50 -0700 Date: Fri, 18 Aug 95 10:23:50 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: erniem@mdhost.cse.TEK.COM Subject: Secrecy Cc: ibis@vhdl.org Ernie, You and Jon are sounding almost paranoid. Lighten up you two. I'm a runner, my wife's a horse rider. We share the same mountain trails. One day I approached a couple of guys walking their horses and hailed them from behind to let them know I was overtaking them. They looked back and set their mounts to canter. I ate dust for a quarter of a mile before they slowed to a walk again and I went past them. Later I complained to my wife about horse riders. She thought about it for a minute and explained that they were training their horses for endurance rides and were on a schedule of canter/walk repetetions and started their canter a little early to avoid having to pass me on the trail. Try looking at the situation from the other guy's perspective. Engineers modeling devices for Silicon vendors, those building tools, and those of us using them are all busier than we should be. We're all working hard and are frustrated because someone else is slowing us down. If you would like to discuss the use of IBIS models and how best to use a specific simulator with an IBIS model I'll be pleased to carry on a dialog on- or off-line as my schedule permits. BTW, I use HSPICE and XTK though I don't doubt that other simulators are quite good. Regards, Fred PS. If all you IBISians don't hear from me for a week, it's because I'm on vacation. B{) From bob@icx.com Fri Aug 18 14:04:15 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16580; Fri, 18 Aug 95 14:04:15 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 18 Aug 95 13:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 18 Aug 95 13:59 PDT Message-Id: Date: Fri, 18 Aug 95 13:59 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MEETING AGENDA FOR AUG 25, 1995 IBIS Open Forum Meeting Agenda for 8/25/95 Bridge Number Reservation # Passcode (916) 356-9200 1-13824 9778278 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 Hobbs - Intros of New IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Rusher/Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press Updates All - New Models Available, Library Update All - Opens for New Issues All 8:10 EIA IBIS Ratification - Review of Changes Hobbs - Ballot Issues That Need Discussion Hobbs - Final Resolution Hobbs - Vote EIA IBIS Members - Action Items / Time Table for Final Draft Hobbs - Press Release Discussion Hobbs/Rusher ????? Agenda for Remaining Items Based on Time Remaining Hobbs 8:30 Administrative and Project Discussions Web Project Update Huq New Web Documents Approval (Vote) Huq Model Usage Tracking on vhdl.org Huq/Steer Golden Parser 2.1 Status Hobbs S2IBIS 2.1 Status Kumar/Steer Version 2.1 Cookbook and Overview Chrisafulli/Ross New Administrative Issues All 9:00 Technical Discussions BIRD 30 - Pin Programmable Buffer Strengths Muranyi Egg 6 - CMOS and TTL Data Powell BIRD 27.1 - New Keyword for Differential I/O (defer) Ross BIRD 28.2 - Package Model Extension Peters Physical Package Description Discussion Crisafulli New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From bob@icx.com Fri Aug 18 14:12:40 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16617; Fri, 18 Aug 95 14:12:40 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 18 Aug 95 14:05 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 18 Aug 95 14:08 PDT Message-Id: Date: Fri, 18 Aug 95 14:08 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Response to Intel Comments To IBIS Members: Attached is a response to be considered and voted on at the IBIS Open Forum meeting regarding Intel's letter ballot comments. Bob Ross, Interconnectix, Inc. ----------------------------------------------------------------------- Mr. Will Hobbs Intel Corporation M/S JF1-57 2111 NE 28th Hillsboro, OR 97214 Dear Mr. Hobbs: On behalf of the EDA IBIS Subcommittee, thank you very much for your detailed review and valuable comments. Our Committee response based on a review and vote of approval at the IBIS OPEN FORUM meeting of August 25, 1995 is given as the attachment "EIA IBIS COMMITTEE RESPONSE TO INTEL OF COMMENTS TO STANDARDS PROPOSAL NO. 3527. Sincerely, Bob Ross Secretary, EIA IBIS Open Forum cc: Jeanne Warner, Patti Rusher EIA IBIS COMMITTEE RESPONSE TO INTEL COMMENTS TO STANDARDS PROPOSAL NO. 3527 Comments to Standards Proposal No. 3527 I vote to approve the the proposed standard, as amended by the responses to University of Manchester and Interconnectix, Inc. and by approved BIRDs 25.3, 26 and 29.2. The specific changes initiated by the Birds are described below. Intel Corporation Comment 1 Type of Comment: Editorial Reference: Section entitled "Notes on Data Derivation" Suggested Change: Change Adopt Bird 25.3 Reason: Clarifies the usage of various IBIS terms, such as min, typ and max in various places in the specification. It also specifically clarifies the impact of the C_Comp keyword and it makes the [Rising_Waveform] and [Falling_Waveform] keywords clearer with respect to the [Ramp] sub-parameter. Response: This change will be adopted as requested. Intel Corporation Comment 2 Type of Comment: Editorial Reference: Section on General syntx rules and guidelines Suggested Change: Change Adopt Bird 26 Reason: Strongly recommends against use of TABs in IBIS files, and presents the rationale behind that recommendation. Response: This change will be adopted as requested. Intel Corporation Comment 3 Type of Comment: Editorial, Technical Reference: Banded_matrix description Suggested Change: Change Adopt Bird 29.2 Reason: Clarifies the use of banded matrix representation for pin to pin coupling, correcting an oversight in the original specification. Response: This change will be adopted as requested. From bob@icx.com Fri Aug 18 17:31:58 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17701; Fri, 18 Aug 95 17:31:58 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 18 Aug 95 17:25 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 18 Aug 95 17:27 PDT Message-Id: Date: Fri, 18 Aug 95 17:27 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS VERSION 2.1 ROLL-UP To IBIS Members: This is a draft document showing the rollup of approved changes to Version 2.1 per resolution of letter ballot comments. This document or revisions to it will be subject to discussion and vote on the August 25, 1995 IBIS Open Forum meeting. Bob Ross, Interconnectix, Inc. |***************************************************************************** |* THIS DOCUMENT IS AN UPDATE BASED ON EIA COMMENTS FROM UNIVERSITY OF |* MANCHESTER, INTERCONNECTIX, INC. AND BIRD29.2 (FROM THE IBIS COMMITTEE). |* |* CHANGES BASED ON BIRD25.3 AND BIRD26, WHICH WERE INCLUDED IN THE LETTER |* BALLOT COPY ARE INCLUDED, BUT NOT SHOWN. |* |* CHANGES ARE DESIGNATED BY |* LINES. |***************************************************************************** |============================================================================== |* I/O Buffer Information Specification (IBIS) Version 2.1 (August 22, 1995) | | IBIS is a standard for electronic behavioral specifications of integrated | circuit input/output analog characteristics. |============================================================================== | Statement of Intent: | | In order to enable an industry standard method to electronically transport | IBIS Modeling Data between silicon vendors, simulation software vendors, and | end customers, this template is proposed. The intention of this template is | to specify a consistent format that can be parsed by software, allowing each | simulation vendor to derive models compatible with their own product. | | One goal of this template is to represent the current state of IBIS data, | while allowing a growth path to more complex models / methods (when deemed | appropriate). This would be accomplished by a revision of the base | template, and possibly the addition of new keywords or categories. | | Another goal of this template is to ensure that it is simple enough for | silicon vendors and customers to use and modify, while ensuring that it is | rigid enough for software simulation vendors to write reliable parsers. | | Finally, this template is meant to contain a complete description of the I/O | elements on an entire component. Consequently, several models will need to | be defined in each file, as well as a table that equates the appropriate | buffer to the correct pin and signal name. | | Version 2.0 of this electronic template was finalized by an industry-wide | group of simulation experts representing various companies and interests. | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | ASCII file format. It represents the minimum amount of I/O buffer | information required to create an accurate IBIS model of common CMOS and | bipolar I/O structures. Future revisions of the ASCII file will add items | considered to be "enhancements" to Version 1.0 to allow accurate modeling | of new, or other, I/O buffer structures. Consequently, all future | revisions will be considered super sets of Version 1.0, allowing backward | compatibility. In addition, as modeling platforms develop support for | revisions of the IBIS ASCII template, all previous revisions of the | template must also be supported. | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | comments have been added for further clarification. | | Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility | with Versions 1.0 and 1.1. All new keywords and elements added in Version | 2.0 are optional. A complete list of changes to the specification is in the | IBIS Version 2.0 Release Notes document ("ver2_0.rn"). | | Version 2.1 update. The file "ver2_1.ibs" contains clarification text | changes, corrections, and two additional waveform parameters beyond | Version 2.0. | |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. File names must be all lower case. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved model name, used with power supply pins, | GND - reserved model name, used with ground pins, | NC - reserved model name, used with no-connect pins, | NA - used where data not available. | | 3) File names used in the file must only have lower case characters to | enhance UNIX compatibility and must conform to DOS rules. (The length of | a file name should not exceed eight plus three characters and it must | not contain special characters which are illegal in DOS). | | 4) The file must have no more than 80 characters per line. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment char] to any other character. The [Comment char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. | | 7) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in sub-parameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, Henries, and Seconds.) | The parser looks at only one alphabetic character after a numerical | entry, therefore it is enough to use only the prefixes to scale the | parameters. However, for clarity, it is allowed to use full | abbreviations for the units. (e.g., pF, nH, mA, mOhm). In addition, | scientific notation IS allowed (e.g., 1.2345e-12). | | 9) The V/I data tables should use enough data points around sharply curved | areas of the V/I curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. | | 10) The usage of TAB characters is legal, but they should be avoided as far | as possible. This is to eliminate possible complications which might | arise in situations when TAB characters are automatically converted to | multiple spaces by text editing, file transfering and similar software. | In cases like that, lines might become longer than 80 characters which | is illegal in IBIS files. | | 11) Currents are considered positive when their direction is into the | component. | | 12) All temperatures are represented in degrees Celsius. | |* 13) Important supplemental information is contained in the last section, | "NOTES ON DATA DERIVATION METHOD", concerning how data values are | derived. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | present in the file. | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | normally on the first line of the file, but can be preceded | by comment lines that must begin with a "|". |------------------------------------------------------------------------------ [IBIS Ver] 2.1 | Used for template variations | |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character to be defined must be followed by | the underscore character and the letters "char". For example: | "|_char" redundantly redefines the comment character to be | the pipe character. The new comment character is in effect | only following the [Comment char] keyword. The following | characters can NOT be used: A B C D E F G H I J K L M N O P | Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u | v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = + - | Other Notes: The [Comment char] keyword can be used throughout the file, as | desired. |------------------------------------------------------------------------------ [Comment char] |_char | |============================================================================== | Keyword: [File name] | Required: Yes | Description: Specifies the name of the IBIS file, "filename.ibs". | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | and no characters that are illegal in DOS). In addition, it | must be all lower case, and use the extension ".ibs". |------------------------------------------------------------------------------ [File name] ver2_1.ibs | |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is set at the discretion of the engineer | defining the file. The following guidelines are recommended: | 0.x silicon and file in development | 1.x pre-silicon file data from silicon model only | 2.x file correlated to actual silicon measurements | 3.x mature product, no more changes likely |------------------------------------------------------------------------------ [File Rev] 1.0 | Used for .ibs file variations | |============================================================================== | Keywords: [Date] [Source] [Notes] [Disclaimer] [Copyright] | Required: No | Description: Optionally clarifies the file. |* Usage Rules: The keyword arguments can contain blanks, and be of | any format. The [Date] keyword argument is limited to a |* maximum of 40 characters, and the month should be spelled |* out for clarity. | | Because IBIS model writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools should make this information | available. Derivative models should include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative models verbatim. |------------------------------------------------------------------------------ |* The date has been changed below: [Date] August 22, 1995 | The latest file revision date | [Source] Put originator and the source of information here. For example: From silicon level SPICE model at Intel. From lab measurement at IEI. Compiled from manufacturer's data book at Quad Design, etc... | [Notes] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | [Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks the beginning of the IBIS description of the integrated | circuit named after the keyword. | Usage Rules: If the .ibs file contains data for more than one component, | each section must begin with a new [Component] keyword. The | length of the Component Name must not exceed 40 characters, | and blank characters are allowed. | | NOTE: Blank characters are not recommended due to usability | issues. |------------------------------------------------------------------------------ [Component] 7403398 MC452 | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies the component's manufacturer. | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines a range of values for the default packaging resistance, | inductance, and capacitance of the component pins. | Sub-Params: R_pkg, L_pkg, C_pkg | Usage Rules: The typical (typ) column must be specified. If data for the | other columns are not available, they must be noted with "NA". | Other Notes: If RLC parameters are available for individual pins, they can | be listed in columns 4-6 under keyword [Pin]. The values | listed in the [Pin] description section override the default | values defined here. Use the [Package Model] keyword for more | complex package descriptions. If defined, the [Package Model] | data overrides the values in the [Package] keyword. | Regardless, the data listed under the [Package] keyword must | still contain valid data. |------------------------------------------------------------------------------ [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF | |============================================================================== | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pins and signal names. | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, associates the I/O model for that | pin. Each model_name must have a [Model] keyword below, | unless it is a reserved model name (POWER, GND, or NC). | | Each line must contain either three or six columns. A pin | line with three columns only associates the pin's signal and | model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin | must be listed. If "NA" is in columns 4 through 6, the | default packaging values must be used. | | Column length limits are: | [Pin] 5 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |------------------------------------------------------------------------------ [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF | |============================================================================== | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model | Usage Rules: The package model name is limited to 40 characters. | Spaces are allowed in the name. The name should include the | company name or initials to help ensure uniqueness. The | simulator will search for a matching package model name as an | argument to a [Define Package Model] keyword in the current | IBIS file first. If a match is not found, the simulator will | look for a match in an external .pkg file. If the package | model is in a separate .pkg file, it must be kept in the same | directory as the .ibs file. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that part. | The specification permits .ibs files to contain [Define | Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models | that have the same name. |------------------------------------------------------------------------------ [Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Pin Mapping] | Required: No |Description: Used to indicate which power and ground buses a given driver, |* receiver, or terminator is connected to. | Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref |Usage Rules: Each power and ground bus is given a unique name which must | not exceed 15 characters. The first column contains a pin | number. Each pin number must match one of the pin numbers | declared previously in the [Pin] section of the IBIS file. | The second column, pulldown_ref, designates the ground bus | connections for that pin. Here the term ground bus can | also mean another power bus. The third column pullup_ref | designates the power bus connection. The forth and fifth | columns gnd_clamp_ref and power_clamp_ref contain | entries, if needed, to specify different ground bus | and power bus connections than those previously specified. | | If the [Pin Mapping] keyword is present, then the bus | connections for EVERY pin listed in the [Pin] section must | be given. | | Each line must contain either three or five columns. Use the | NC reserved word for entries that are not needed or that follow | the conditions below: | | All entries with identical labels are assumed to be connected. | Each unique entry label must connect to at least one pin whose | model_name is POWER or GND. | | If a pin has no connection, then both the pulldown_ref | and pullup_ref sub-parameters for it will be NC. | | GND and POWER pin entries and buses are designated by | entries in either the pulldown_ref or pullup_ref columns. | There is no implied association to any column other than | through explicit designations in other pins. | | For any other type of pin, the pulldown_ref column contains | the power connection for the [Pulldown] table for non-ECL type | [Models]. This is also the power connection for the [GND Clamp] | table and the [Rgnd] model unless overridden by a specification | in the gnd_clamp_ref column. | | Also, the pullup_ref column contains the power connection | for the [Pullup] table and, for ECL type models, the [Pulldown] | table. This is also the power connection for the [POWER Clamp] | table and the [Rpower] model unless overridden by a | specification in the power_clamp_ref column. | | The column length limits are: | [Pin Mapping] 5 characters max | pulldown_ref 15 characters max | pullup_ref 15 characters max | gnd_clamp_ref 15 characters max | power_clamp_ref 15 characters max | | When 5 columns are specified, the headings gnd_clamp_ref and | power_clamp_ref must be used. Otherwise, these headings can | be omitted. |--------------------------------------------------------------------------- [Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref | 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP 5 GNDBUS2 PWRBUS2 NC PWRCLAMP 6 GNDBUS2 PWRBUS2 GNDCLMP NC | Some possible clamping connections | . | are shown above for illustration | . | purposes | . 11 GNDBUS1 NC | One set of ground connections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. | . 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC | . 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. | . 41 NC PWRBUS2 | Second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 | . 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps | |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The forth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh and | Vinl. | | If vdiff is not defined for a pin that is defined as requiring a | Vinh by its [Model] type, vdiff is set to the default value of | 200mV. | |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | one [Model] to be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tdelay_typ, or tdelay_min columns, its | entry is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is interpreted as the | tdelay_typ value. When using six columns, the headers | tdelay_min and tdelay_max must be listed. Entries for the | tdelay_min column are based on minimum magnitudes; and | tdelay_max column, maximum magnitudes. One entry of vdiff, | regardless of its polarity, is used for difference magnitudes. |--------------------------------------------------------------------------- [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V | |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes. | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref, | Rref, Vref | Usage Rules: Each model type must begin with the keyword [Model]. | The model name must match the one that is listed under | the [Pin] keyword and must not contain more than 20 characters. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except | for those model names that use reserved words (POWER, GND and | NC). Model names with reserved words are an exception and they | do not have to have a corresponding [Model] keyword. | | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl=0.8V and Vinh=2.0V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl=-1.475V and Vinh=-1.165V | are assumed. | | Terminator This model type is an input-only device that | can have analog loading effects on the | circuit being simulated but has no digital | logic thresholds. Examples of Terminators | are: capacitors, termination diodes, and | pull-up resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | | 3-state This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | | Open_sink These model types indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = 0mA | for all voltages specified) and the output | SINKS current. Open_drain model type is | retained for backward compatibility. | | Open_source This model type indicates that the | output has an OPEN side (do not use the | [Pulldown] keyword, or if it must be used, | set I = 0mA for all voltages specified) and | the output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | keyword. | | The Model_type and C_comp sub-parameters are required. The | Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref sub- | parameters are optional. C_comp defines the silicon die | capacitance. This value should not include the capacitance of | the package. C_comp is allowed to use "NA" for the min and max | values only. The Polarity sub-parameter can be defined as | either Non-Inverting or Inverting, and the Enable sub- | parameter can be defined as either Active-High or Active-Low. | | The Cref and Rref sub-parameters correspond to the test load | that the manufacturer uses when specifying the propagation | delay and/or output switching time of the device. The Vmeas | sub-parameter is the reference voltage level that the | manufacturer uses for the component. Include Cref, Rref, and | Vmeas information to facilitate board-level timing simulation. | The assumed connections for Cref, Rref, and Vref are shown in | the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one | or more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, | some models may have only a subset of these keywords. For | example, an input structure normally only needs the | [Voltage Range], [GND Clamp], and possibly the [POWER Clamp] | keywords. If one or more of [Rgnd], [Rpower], [Rac], and [Cac] | keywords are used, then the Model_type must be Terminator. |------------------------------------------------------------------------------ | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V |Reference voltage for timing measurements Cref = 50pF |Timing specification test load capacitance value Rref = 500 |Timing specification test load resistance value Vref = 0 |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== | Keyword: [Temperature Range] |* Required: Yes, if other than the preferred 0, 50, 100 degree Celsius |* range | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various V/I curves and ramp rates were | derived. |------------------------------------------------------------------------------ | variable typ min max [Temperature Range] 27.0 -50 130.0 | |============================================================================== | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], | [POWER Clamp Reference], and [GND Clamp Reference] are not | present |Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the pull-up and [POWER Clamp] V/I data is | referenced. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |* Other Notes: If the [Voltage Range] keyword is not present, then all four |* of these keywords described below must be present: [Pullup |* Reference], [Pulldown Reference], [POWER Clamp Reference], |* and [GND Clamp Reference]. If the [Voltage Range] is present, |* the other keywords are optional and may or may not be used as |* required. It is legal (although redundant) for an optional |* keyword to specify the same voltage as specified by the |* [Voltage Range] keyword. |--------------------------------------------------------------------------- | variable typ min max [Voltage Range] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [Pullup Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | pull-up V/I data. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_r values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pullup Reference] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [Pulldown Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a power supply rail other than 0V as the reference | voltage for the pull-down V/I data. If this keyword is not | present, the voltage data points in the pull-down V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the typ, min, and max dV/dt_f values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pulldown Reference] 0V 0V 0V | |============================================================================== | Keyword: [POWER Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | [POWER Clamp] V/I data. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Refer the "Other Notes" section of the [GND Clamp Reference] | keyword. |--------------------------------------------------------------------------- | variable typ min max [POWER Clamp Reference] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [GND Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a power supply rail other than 0V as the reference | voltage for the [GND Clamp] V/I data. If this keyword is not | present, the voltage data points in the [GND Clamp] V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Power Supplies: It is intended that standard TTL and CMOS | devices be specified using only the [Voltage Range] keyword. | However, in cases where the output characteristics of a device | depend on more than a single supply and ground, or a pull-up, | pull-down, or clamp structure is referenced to something other | than the default supplies, use the additional 'reference' | keywords. |---------------------------------------------------------------------------- | variable typ min max [GND Clamp Reference] 0V 0V 0V | |============================================================================== | Keywords: [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves of | the pull-down and pull-up structures of an output buffer and | the V/I curves of the clamping diodes connected to the GND and | the POWER pins, respectively. Currents are considered positive | when their direction is into the component. | | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | | Other Notes: The V/I curve of the [Pullup] and the [POWER Clamp] structures | are 'Vcc relative', meaning that the voltage values are | referenced to the Vcc pin. (Note: Under these keywords, all | references to 'Vcc' refer to the voltage rail defined by the | [Voltage range], [Pullup Reference], or [POWER Clamp Reference] | keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5V in the table actually | means 5V above Vcc, which is +10V with respect to ground; | and 10V means 10V below Vcc, which is -5V with respect to | ground. Vcc-relative data is necessary to model a pull-up | structure properly, since the output current of a pull-up | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND Clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output, if so | desired. | | When tabulating data for ECL devices, the data in the pull-down | table is measured with the output in the 'logic low' state. | In other words, the data in the table represents the V/I | characteristics of the output when the output is at the most | negative of its two logic levels. Likewise, the data in the | pull-up table is measured with the output in the 'logic one' | state and represents the V/I characteristics when the output | is at the most positive logic level. Note that in BOTH of | these cases, the data is referenced to the Vcc supply voltage, | using the equation Vtable = Vcc - Voutput. | | Monotonicity Requirements: | To be monotonic, the V/I table data must meet any one of the | following 8 criteria: | 1- The CURRENT axis either increases or remains constant as | the voltage axis is increased. | 2- The CURRENT axis either increases or remains constant as | the voltage axis is decreased. | 3- The CURRENT axis either decreases or remains constant as | the voltage axis is increased. | 4- The CURRENT axis either decreases or remains constant as | the voltage axis is decreased. | | 5- The VOLTAGE axis either increases or remains constant as | the current axis is increased. | 6- The VOLTAGE axis either increases or remains constant as | the current axis is decreased. | 7- The VOLTAGE axis either decreases or remains constant as | the current axis is increased. | 8- The VOLTAGE axis either decreases or remains constant as | the current axis is decreased. | | An IBIS syntax checking program shall test for non-monotonic | data and provide a maximum of one note per V/I table if | non-montonic data is found. For example: | "NOTE: Line 300, Pulldown V/I table for model DC040403 is | non-monotonic! Most simulators will filter this data | to remove the non-monotonic data." | | It is also recognized that the data may be monotonic if | currents from both the output stage and the clamp diode are | added together as most simulators do. To limit the complexity | of the IBIS Version 2.x syntax checking programs, such | programs will conduct monotonicity testing only on one | V/I table at a time. | | It is assumed that the simulator sums the clamp curves | together with the appropriate pull-up or pull-down curve when | a buffer is driving high or low, respectively. From this | assumption and the nature of 3-statable buffers, it follows | that the data in the clamping curve sections are handled as | constantly present curves and the pull-up and pull-down curves | are used only when needed in the simulation. | | The clamp curves of an input or I/O buffer can be measured | directly with a curve tracer, with the I/O buffer 3-stated. | However, sweeping enabled buffers results in curves that are | the sum of the clamping curves and the output structures. | Based on the assumption outlined above, the pull-up and | pull-down curves of an IBIS model must represent the | difference of the 3-stated and the enabled buffer's curves. | (Note that the resulting difference curve can demonstrate a | non-monotonic shape.) This requirement enables the simulator | to sum the curves, without the danger of double counting, and | arrive at an accurate model in both the 3-stated and enabled | conditions. | | Since in the case of a non 3-statable buffer, this difference | curve cannot be generated through lab measurements (because | the clamping curves cannot be measured alone), the pull-up and | pull-down curves of an IBIS model can contain the sum of the | clamping characteristics and the output structure. In this | case, the clamping curves must contain all zeroes, or the | keywords must be omitted. |------------------------------------------------------------------------------ [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | |============================================================================== | Keywords: [Rgnd], [Rpower], [Rac], [Cac] | Required: Yes, if they exist in the device | Description: The data for these keywords define the resistance values of | Rgnd and Rpower connected to GND and the POWER pins, | respectively. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max), or the three entries | for C(typ), C(min), and C(max) must be placed on a single line | and must be separated by at least one white space or tab | character. All three columns are required under these | keywords. However, data is only required in the typical | column. If minimum and/or maximum values are not available, | the reserved word "NA" must be used indicating the R(typ) or | C(typ) value by default. | Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and | [Rgnd] is connected to 'GND'. However, [GND Clamp Reference] | voltages, if defined, apply to [Rgnd]. [POWER Clamp Reference] | voltages, if defined, apply to [Rpower]. Either or both [Rgnd] | and [Rpower] may be defined and may coexist with [GND Clamp] | and [POWER Clamp] structures. If the terminator consists | of a series R and C (often referred to as either an AC or RC | terminator), then both [Rac] and [Cac] are required. When | [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the | Model_type must be Terminator. | | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | VI | \ Rpower [Package] Keyword | | | / Sub-parameters | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | VI | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp Ref] | | | | | | | o-------------------o----------------------o | | | o | GND |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator [Rpower] 220Ohm 200Ohm NA | [Rac] 30Ohm NA NA | | variable C(typ) C(min) C(max) | AC terminator [Cac] 50pF NA NA | |============================================================================== | Keyword: [Ramp] | Required: Yes, except for inputs and terminators | Description: Defines the rise and fall times of a buffer. The ramp rate | does not include packaging but does include the effects of the | C_comp parameter. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. | The ramp rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load sub-parameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 2.20/1.06n 1.92/1.28n 2.49/650p dV/dt_f 2.46/1.21n 2.21/1.54n 2.70/770p R_load = 300ohms | |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' sub-parameters specify the loading | conditions under which the waveform is taken. The R_dut, |* C_dut, and L_dut sub-parameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used, its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | sub-parameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | |============================================================================= | | PACKAGE MODELING | | The [Package Model] keyword is optional. If more than the default RLC | package model is desired, use the [Define Package Model] keyword. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... | [End Package Model] keywords for each package model that is defined. For | reference, these keywords are listed below. Full descriptions follow. | Simulators that do not support these keywords will ignore all entries between | the [Define Package Model] and [End Package Model] keywords. | | [Define Package Model] Required if the [Package Model] keyword is used | [Manufacturer] (note 1) | [OEM] (note 1) | [Description] (note 1) | [Number of Pins] (note 1) | [Pin Numbers] (note 1) | [Model Data] (note 1) | [Resistance Matrix] Optional | [Inductance Matrix] (note 1) | [Capacitance Matrix] (note 1) | [Bandwidth] Required (for Banded_matrix matrices only) | [Row] (note 1) | [End Model Data] (note 1) | [End Package Model] (note 1) | | (note 1) Required when the [Define Package Model] keyword is used | | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | | USAGE RULES FOR THE .PKG FILE | | Package models are stored in a file whose name looks like: | .pkg. | | The provided must adhere to the General Syntax Rules. Use the | ".pkg" extension to identify files containing package models. The .pkg file | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg | file. The .pkg file is for package models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package | model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a |* consistent name in all .ibs and .pkg files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes | Description: Declares the manufacturer of the package. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each |* manufacturer must use a consistent name in all .ibs and .pkg |* files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of | what kind of package the [Package Model] is representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |============================================================================== | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the package | pins, and to define an ordering of them. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." The pin names can not exceed 5 characters in | length. | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are | pins (as given by the preceding [Number of Pins].) |------------------------------------------------------------------------------ [Pin Numbers] A1 A2 | . | . | . A22 B1 | . | . | . | etc. | |============================================================================== | Keyword: [Model Data] | Required: Yes | Description: Indicates the beginning of the formatted package model data, | which can include the [Resistance Matrix], [Inductance Matrix], | [Capacitance Matrix], [Bandwidth], and [Row] keywords. |------------------------------------------------------------------------------ [Model Data] | |============================================================================== | Keyword: [End Model Data] | Required: Yes | Description: Indicates the end of the formatted model data. | Other Notes: In between the [Model Data] and [End Model Data] keywords is | the package model data itself. The data is a set of 3 | matrices: the resistance (R), inductance (L), and capacitance | (C) matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords below to mark the | beginning of each new matrix. |------------------------------------------------------------------------------ [End Model Data] | |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The sub-parameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the sub-parameters. | After each of these sub-parameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board |* (General Syntax Rule #11). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | | For even a modest-sized package, this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known |* as the "bandwidth." Let the matrix size be N x M, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. |* |* The Banded_matrix is used to specify the coupling effects up to B pins |* on either side. Two variations are supported. One allows for the coupling |* to circle back on itself. This is technically a simple form of a bordered |* block diagonal matrix. However, its data can be completely specified in |* in terms of a Banded_matrix for an N x M matrix consisting of N rows |* and M = N + B columns. The second variation is just in terms of an N x N |* matrix where no circle back coupling needs to be specified. |* | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | |* For case where coupling can circle back on itself, consider a matrix of |* N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B. | The first row only needs to specify the entries [1,1] through [1,1+B] since |* all other entries are guaranteed to be zero. The second row will need to |* specify the entries [2,2] through [2,2+B], and so on. For row K |* the entries [K,K] through [K,K+B] are given when K + B is less than or |* equal to the size of the matrix N. When K + B exceeds N, the entries in the |* last columns 1 ... B specify the coupling to the first rows. For row K, the |* entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = |* mod(K + B - 1, N) + 1. All rows will contain B + 1 entries. To avoid |* redundant entries, the bandwidth is limited to B <= int((N - 1) / 2). |* |* For the case where coupling does not circle back on itself, the process is |* modified. Only N columns need to be considered. When K + B finally exceeds |* the size of the matrix N, the number of entries in each row starts to |* decrease; the last row (row N) has only 1 entry. This construction |* constrains the bandwidth to B < N. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | |* With this convention, please note that the N'th row of an |* N x N matrix has just a single entry (the diagonal entry). | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 [Date] August 22, 1995 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. It describes certain | assumed parameter and table extraction conditions if they are not | explicitly specified. It also describes the allocation of data into | the "typ", "min", and "max" columns under variations of voltage, | temperature, and process. | | The required "typ" column for all data represents typical operating | conditions. For most [Model] keyword data, the "min" column describes | slow, weak performance, and the "max" column describes the fast, strong | performance. It is permissible to use slow, weak devices or models to | derive the data for the "min" column, and to use fast, strong devices or | models to derive the data in the "max" columns under the corresponding | voltage and temperature derating conditions for these columns. It is also | permissible to use typical devices or models derated by voltage and | temperature and optionally apply proprietary "X%" and "Y%" factors | described later for further derating. This methodology has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | The voltage and temperature keywords and optionally the process models | control the conditions which define the "typ", "min", and "max" column | entries for all V/I table keywords [Pulldown], [Pullup], [Gnd Clamp], | and [Power Clamp]; all [Ramp] sub-parameters dV/dt_r and dV/dt_f; and | all waveform table keywords and sub-parameters [Rising Waveform], | [Falling Waveform], V_fixture, V_fixture_min, and V_fixture_max. | | The voltage keywords which control the voltage conditions are [Voltage | Range], [Pulldown Reference], [Pullup Reference], [Gnd Clamp Reference], | and [Power Clamp Reference]. The entries in the "min" columns | contain the smallest magnitude voltages, and the entries in the "max" | columns contain the largest magnitude voltages. | | The optional [Temperature] keyword will contain the temperature | which causes or amplifies the slow, weak conditions in the "min" column | and the temperature which causes or amplifies the fast, strong | conditions in the "max" column. Therefore, the "min" column for | [Temperature] will contain the lowest value for bipolar devices (TTL | and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. | | The "min" and "max" columns for all remaining keywords and sub-parameters | will contain the smallest and largest magnitude values. This applies | to the [Model] sub-parameter C_comp as well even if the correlation | to the voltage, temperature, and process variations are known because | information about such correlation is not available in all cases. | | C_comp is considered an independent variable. This is because C_comp | includes bonding pad capacitance, which does not necessarily track | fabrication process variations. The conservative approach to using IBIS | data will associate large C_comp values with slow, weak models, and the | small C_comp values with fast, strong models." | | The default temperatures under which all V/I tables are extracted are | provided below. The same defaults also are stated for the [Ramp] | sub-parameters, but they also apply for the waveform keywords. | | The stated voltage ranges for V/I tables cover the most common, single | supply cases. When multiple supplies are specified, the voltages shall | extend similarly to values which handle practical extremes in reflected | wave simulations. | | For the [Ramp] sub-parameters, the default test load and voltages are | provided. However, the test load can be entered directly by the R_load | sub-parameter. The allowable test loads and voltages for the waveform | keywords are stated by required and optional sub-parameters; no defaults | are needed. Even with waveform keywords, the [Ramp] keyword continues | to be required so that the IBIS model remains functional in situations | which do not support waveform processing. | | The following discussion lists test details and default conditions. | | 1) V/I curves for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "X%" | max = maximum voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "X%" | max = maximum voltage, max temp deg C, typical process, plus "X%" | | Nominal, min, and max temperature are specified by the manufacturer | of the part. The default range is 50C nom, 0C min, and 100C max | temperatures. | | X% should be statistically determined by the silicon vendor based | on numerous fab lots, test chips, process controls, etc.. The value | of X need not be published in the IBIS file, and may decrease over | time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | As described in the [Pulldown Reference] keyword section, the V/I curve of | the [Pullup] and the [POWER Clamp] structures are 'Vcc relative', using | the equation: Vtable = Vcc - Voutput. | | For example, a device with a 5V power supply voltage should be | characterized between (0 - 5) = -5V and (5 + 5) = 10V; and a | device with a 3.3V power supply should be characterized between | (0 - 3.3) = -3.3V and (3.3 + 3.3) = 6.6V for the pull-down curve. | | When tabulating output data for ECL type devices, the voltage points | must span the range of Vcc to Vcc - 2.2V. This range applies to both the | pull-up and pull-down tables. Note that this range applies ONLY when | characterizing an ECL output. | | These voltage ranges must be spanned by the IBIS data. Data derived | from lab measurements may not be able to span these ranges as such and | so may need to be extrapolated to cover the full range. This data must | not be left for the simulator to provide. | | 3) Ramp Rates: | The following steps assume that the default load resistance of 50 ohms is | used. There may be devices that will not drive a load of only 50 ohms | into any useful level of dynamics. In these cases, use the manufacturer's | suggested (non-reactive) load and add the load sub parameter to the [Ramp] | specification. | | The ramp rate does not include packaging but does include the effects of | the C_comp parameter; it is the intrinsic output stage rise and fall time | only. | | The ramp rates (listed in AC characteristics below) should be derived | as follows: | | a. If starting with the silicon model, remove all packaging. If starting | with a packaged device, perform the measurements as outlined below then | use whatever techniques are appropriate to derive the actual, unloaded | rise and fall times. | | b. If: The Model_type is one of the following: Output, I/O, or | 3-state (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | | If: The Model_type is Output_ECL or I/O_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either POWER or the vendor- | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either GND or the vendor-suggested | termination voltage. Use this load to derive both the rising | and falling edges. | | c. Due to the resistor, output swings will not make a full transition as | expected. However the pertinent data can still be collected as | follows: | 1) determine the 20% to 80% voltages of the 50 Ohm swing | 2) measure this voltage change as "dV" | 3) measure the amount of time required to make this swing "dt" | d. Post the value as a ratio "dV/dt". The simulation tool vendor | extrapolates this value to span the required voltage swing range in | the final model. | | e. Typ, Min, and Max must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "Y%" | max = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "Y%" | max = maximum voltage, max temp deg C, typical process, plus "Y%" | | where nominal, min, and max temp are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min, and 100C max | temperatures. | | Note that the derate factor, "Y%", may be different than that used | for the V/I curve data. This factor is similar to the X% factor | described above. As in the case of V/I curves, temperatures are | junction temperatures. | | f. During the IV measurements, the driving waveform should have a | rise/fall time fast enough to avoid thermal feedback. The specific | choice of sweep time is left to the modeling engineer. | | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. From EGJJ77A@mail.prodigy.com Mon Aug 21 07:18:09 1995 Return-Path: Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20163; Mon, 21 Aug 95 07:18:09 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.prodigy.com (8.6.10/8.6.9) with SMTP id KAA136878 for ; Mon, 21 Aug 1995 10:01:40 -0400 Date: Mon, 21 Aug 1995 10:00:03 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00149640.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Re: CFI, EDAC, and Sematech -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Fred, My answers reflect my understanding and may not be precise. CFI stands for CAD (Computer Aided Design) Framework Initiative. It is a consortium of design automation companies. CFI coordinates development of standards in design automation. They started out in frameworks but then spread into design representation. They have a WWW home page at www.cfi.org for a lot more information. EDAC stands for Engineering Design Automation Companies and is made up of those companies. Sematech is a consortium of companies and partly funded by the government (or used to be) to advance the computer manufacturing capabilities and now branching into the computer aided design area because the computer aided design capabilities are not keeping up with the technology advances. Ron Christopher -------- REPLY, Original message follows -------- > Date: Friday, 18-Aug-95 01:22 PM > > From: Fred Vance \ Internet: (fvance@firepower.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: CFI, EDAC, and Sematech > > Ron, > > At the expense of advertising my ignorance, what are CFI, EDAC, and > Sematech? I can make a good guess at the EDAC acronym, but I would > appreciate someone telling me what they are and what is their charter. > > Thanks, > Fred > > > -------- REPLY, End of original message -------- From Samie_Samaan@ccm2.jf.intel.com Mon Aug 21 11:32:19 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21827; Mon, 21 Aug 95 11:32:19 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0skbX0-000UffC; Mon, 21 Aug 95 11:25 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0skbX0-000txAC; Mon, 21 Aug 95 11:25 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Mon, 21 Aug 95 11:25:06 PDT Date: Mon, 21 Aug 95 11:22:00 PDT From: Samie Samaan Message-Id: To: ibis@vhdl.org Subject: GND Plane Bounce Question Text item: Text_1 All IBISians (SI experts by Default !!) I would like to pose the following SI question, and solicit help from those who actually know the answer or have a very good idea of how to estimate it by scaling from previous experience: Assume one GND and one power plane in a PCB separated by say 10 mil, with a dielectric constant of say 4. assume that the power plane has a via opening where current is injected thru the via down to the GND plane. Let's say that the current is 10 Amps. with a riserime of 1 ns. Assume nominal via diameter. The drawing below shows the structure: | Vcc ---------------- | ------------------ | GND 10 mil, Er=4 -----------------|------------------- What I would like to hear from anybody who actually has experienced GND plane bounce, is: *howmuch do you expect the GND plane (not the via stem) to bounce up (locally) given the above assumptions, and *howfar away from the via (radially) do you expect the bounce to drop to 10% of the peak which occurs right where the via meets the plane ? I would apprciate a good guess (and Why: perhaps from previous experience), or direction as to "who ?" you think could answer such a question. I know that I might need to do a 3-D or radial transmission line analysis of the system, but I'm really just looking for a quick answer. Thanks for taking the time to read or answer this question. Samie Samaan Intel Corp. From nirmal@ansoft.com Mon Aug 21 13:11:47 1995 Return-Path: Received: from maxwell.ansoft.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22396; Mon, 21 Aug 95 13:11:47 PDT Received: from cobra.ansoft.com by maxwell.ansoft.com (4.1/SMI-4.1) id AA06323; Mon, 21 Aug 95 16:04:17 EDT Received: by cobra.ansoft.com; Mon, 21 Aug 95 16:10:03 -0400 From: Nirmal Jain Message-Id: <9508212010.AA14903@cobra.ansoft.com> Subject: Re: GND Plane Bounce Question To: Samie_Samaan@ccm2.jf.intel.com Date: Mon, 21 Aug 95 16:10:01 EDT Cc: si-list@silab.eng.sun.com (SI List), ibis@vhdl.org In-Reply-To: ; from "Samie Samaan" at Aug 21, 95 11:22 am Mailer: Elm [revision: 66.33] > > >Text item: Text_1 > > > All IBISians (SI experts by Default !!) > > I would like to pose the following SI question, and solicit help from > those who actually know the answer or have a very good idea of how to > estimate it by scaling from previous experience: > > > Assume one GND and one power plane in a PCB separated by say 10 mil, > with a dielectric constant of say 4. assume that the power plane has a > via opening where current is injected thru the via down to the GND > plane. Let's say that the current is 10 Amps. with a riserime of 1 ns. > Assume nominal via diameter. The drawing below shows the structure: > > > | Vcc > ---------------- | ------------------ > | GND 10 mil, Er=4 > -----------------|------------------- > > > What I would like to hear from anybody who actually has experienced > GND plane bounce, is: > > *howmuch do you expect the GND plane (not the via stem) to bounce up > (locally) given the above assumptions, and > > *howfar away from the via (radially) do you expect the bounce to drop > to 10% of the peak which occurs right where the via meets the plane ? > > I would apprciate a good guess (and Why: perhaps from previous > experience), or direction as to "who ?" you think could answer such a > question. I know that I might need to do a 3-D or radial transmission > line analysis of the system, but I'm really just looking for a quick > answer. The ground bounce depends on the inductance presented to the path of current. The correct approach is to treat the plane as multi-terminal conductor and solve for L matrix for all those current paths. So in the above fig you have to have another terminal or terminals on the GND plane which would define the current path and hence ground bounce. So we need the information about how the current flows on the gnd plane. If you have more current terminals onthe GND plane your effective inductance will be lower and hence GND bounce. Best regards Nirmal > > > Thanks for taking the time to read or answer this question. > > Samie Samaan > Intel Corp. _______________________________________________________________________________ Nirmal Jain ANSOFT CORPORATION (412) 261-3200 X29 (W) Four Station Sq., Suite 660 (412) 471-9427(FAX) Pittsburgh, PA 15219 _______________________________________________________________________________ From speters@ichips.intel.com Mon Aug 21 14:15:49 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22850; Mon, 21 Aug 95 14:15:49 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 21 Aug 95 12:58:23 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 21 Aug 95 12:58:09 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 21 Aug 95 12:58:07 PDT Message-Id: <9508211958.AA11986@xtg801.intel.com> To: ibis@vhdl.org Subject: Bird 28.2 Date: Mon, 21 Aug 1995 12:58:06 -0700 From: Stephen Peters Hello Fellow IBISains: Here is the updated Bird28.2, posted for discussion In this updated the requirement that "if two or more package stubs are coupled together the sections that couple MUST be reported as having the same length" is dropped. I hope to discuss this bird further at the phone meeting Friday. Regards, Stephen Peters Intel Corp. ----------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 28.2 ISSUE TITLE: Enhancement To The Package Model (.pak file) Specification REQUESTER: Stephen Peters DATE SUBMITTED: August 21, 1995 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current package model specification describes each pin on a package using lumped L/R/C parameters. Coupling between pins also assumes lumped electrical parameters. However, these description are inadequate when the electrical length of the package elements are greater than ~1/6 of the I/O buffers' rise time. This bird enhances the package description by allowing package elements to be described in terms of length and L, R and C per unit length; i.e. a transmission line representation. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Following are the specific changes to the specification. 1. The keyword [Number of Sections] is added to the specification after the Description keyword |============================================================================== | Keyword: [Number of Sections] | Required: No |Description: Defines the maximum number of sections that make up a 'package | stub'. A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. |Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. |----------------------------------------------------------------------------- [Number of Sections] 3 | |============================================================================= 2. The current [Pin Numbers] keyword description is replaced by the following: |============================================================================= | Keyword: [Pin Numbers] | Required: Yes |Description: Tells the parser the set of names that are used for the package | pins and also defines pin ordering. If the [Number of Sections] | keyword is present it also lists the elements for each section | of a pin's die to pin connection. | Sub-Params: Len, L, R, C, Matrix |Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number of Pins] keyword). Pin names | can not exceed 5 characters in length. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." If the [Number of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number of | Sections] keyword is not present then subparameter usage is | NOT allowed. | | Subparameters: | The subparameters specify the length, inductance, capacitance | and resistance of each section of each stub on a package. If | a particular section exhibits coupling to an adjacent (same | numbered) section of a different package stub then the Matrix | subparameter is used. The subparameters are defined as | follows: | Len The length of a package stub section. Lengths are given | in terms of arbitrary 'units'. | L The inductance of a package stub section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a package stub section is 3.0nH and the | length of this section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). | C The capacitance of a package stub section, in terms of | capacitance per unit length. | R The DC (ohmic) resistance of a package stub section, in | terms of ohms per unit length. | Matrix Use of this subparameter means that this package stub | sections electrical parameters are presented as part of | a coupling matrix. The data for the matrix is included | between the [Model Data]/[End Model Data] keyword pairs | as described below. | | Specifying a length or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. | | Using The Subparameters to Describe Package Stub Sections: | Each section description must begin with the Len subparameter and | ends with the backslash (/) character. The value of a sub- | parameter and the subparameter itself are separated by an equals | sign (=); whitespace around the equals sign is optional. All | package stub descriptions must contain the same number of | sections however, a particular section description can contain | no data (i.e. the description is given as 'Len = 0 /'. See the | example below). | | Legal Subparameter Combinations: | A) A single Len = 0 subparameter, followed by a backslash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | backslash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. The matrix description must include both the 'self' | inductance/capacitance/resistance (as required) of a section | as well as the mutual coupling terms. If one section is | described using the the Matrix subparameter then the | corresponding (same numbered) sections on ALL other package | stubs must use the Matrix subparameter. | | C) Len, and any combination of L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | | In the example below the first section is a lumped inductor, | the second section is described using a matrix, and the third | section is modeled using distributed elements. Pin A3 shows | an example of sections with no data. Pins A4 and A5 illustrate | how a section description can be broken across multiple lines | and how each section description is delimited by the backslash. |----------------------------------------------------------------------------- [Pin Number] A1 Len = 0 L=1.2n / Len = 1.3 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01 / A2 Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 / A3 Len = 0 / Len = 1.1 Matrix / Len = 0 / A4 Len = 0 L=1.2n / Len = 1.0 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01/ A5 Len = 0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / | | Note that the actuall length for each section is reported, even for | those sections that use the Matrix subparameter. | 3. The current [Model Data] and [End Model Data] keyword descriptions are replaced by the following |============================================================================= | Keyword: [Model Data] | Required: Yes, if any of the sections in a package stub description | use the 'Matrix' subparameter or if the [Number of Sections] | keyword is not used. |Description: Indicates the beginning of the matrix data used to describe | a package stub section. |Usage Rules: If the [Number of Sections] keyword is used then the [Model | Data] keyword must be followed by the word 'section' and the | section number the matrix data applies to. There must be a | [Model Data] keyword for every section in a package stub | description that uses the Matrix keyword. Note that if the | [Number of Sections] keyword is used but no package stub | sections use the Matrix subparameter then the [Model Data] | and [End Model Data] keyword are not required. |----------------------------------------------------------------------------- [Model Data] section 2 | |============================================================================= | Keyword: [End Model Data] | Required: Yes, if the [Model Data] keyword is present. |Description: Indicates the end of the matrix data used to describe | a package stub section. |Usage Rules: In between the [Model Data] and [End Model Data] keywords is | the matrix data itself. The data is a set of three matrices: | the resistance (R) , inductance (L) , and capacitance (C), | matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords to mark the | beginning of each matrix. As with the [Model Data] keyword | the [End Model Data] keyword is followed by the word 'section' | and the section number. |----------------------------------------------------------------------------- [End Model Data] section 2 | |============================================================================= 4. The following paragraph is added to the section entitled "RLC MATRIX NOTES" (place after the first paragraph). There are two different ways to extract the coefficients that are reported in the the capacitance and inductance matrices. For the purposes of this specification, the coefficients reported in the capacitance matrices shall be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. The Maxwell capacitance Kij is defined as the charge induced on conductor "j" when conductor "i" is held at 1 volt and all other conductors are held at zero volts. Note that Kij ( when i /= j) will be a negative number. By convention, drop the negative sign before entering this value into the matrix. Likewise, for the inductance matrix the coefficients for Lij are defined as the voltage induced on conductor "j" when conductor "i"'s current is changed by 1amp/sec and all other conductors have no current change. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This bird proposes three fundamental enhancement to the current package specification. They are: 1. The connection between the pad on the die and the external package pin (referred to in this bird as the package 'stub') is now considered to be composed of a number of elements, or sections, in series. 2. Each of these elements can have a non-zero length, thus enabling one to model each section as having a time delay -- i.e. as a transmission line 3. The current matrix description can now be applied to individual section of the package stub, and there can be more than one [Model data] and [End Model Data] keyword pair per package model description. The purpose of this bird is to enable IBIS to describe the connection between the pad and pin of a package in greater detail. Specifically, with this bird one will now be able to model the effect of long package traces and also the effects when one package trace couples with another. The author has found that this level of detail is vital for accurately modeling the effects of large PGA packages and/or packages that have no ground plane and exhibit coupling between package traces. With these enhancement, the .pkg file should be able to accurately describe the great majority of DIP/SOIC/PGA/BGA/PQFP packages. It is NOT the purpose of this bird to describe a generalized topology suitable for describing MCM and SIM modules. In addition to the enhancements required to better describe packages, the capacitance and inductance coefficients used for the matrix data elements are defined. I believe that even if this bird is not accepted, this portion should be adopted in order to make the current matrix format usable. Changes 6/28 Per the suggestions of Bob Ross (email on May 30) I have removed the 'Unit Length' keyword and incorporated his syntax suggestions regarding backslash delimiters and the '=' sign. Changes 8/21 The previous change on 6/28 included the requirement that the same length for each coupled stub in a section be reprted as the same length. This requeirement has been deamed unfeasable and is dropped. ANY OTHER BACKGROUND INFORMATION For a much more detailed description of Maxwell capacitances refer to the paper by Robert Canright entitled "Capacitance: Relationships and Measurements" available from the IEEE (Thanks to Bob Ward at Texas Instruments for supplying me with this paper). I would also like to thanks Samie Samaan at Intel for his review of this bird and for bringing the whole issue of matrix data coefficients to my attention. From huq@rockie.nsc.com Mon Aug 21 15:31:20 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23337; Mon, 21 Aug 95 15:31:20 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA00142 for ibis@vhdl.org; Mon, 21 Aug 95 15:24:35 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA06128 for ibis@vhdl.org; Mon, 21 Aug 95 15:24:33 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA27399; Mon, 21 Aug 95 15:27:09 PDT Date: Mon, 21 Aug 95 15:27:09 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9508212227.AA27399@rockie.nsc.com> To: ibis@vhdl.org Subject: FAQ #6 and #7 revised.... IBISfans, As mentioned in the last IBIS Minutes (Aug11th'95), the last two FAQ that need to be re-worded were #6 and #7. I am attaching the revised answers based on some inputs I received. Pls post your comment/changes/suggestions on the reflector and we shall vote on this on the Aug25th meeting. Regards, Syed. National Semiconductor. -------------------------------------------------------------------------- 6.0 Can IBIS model SSO(Simultaneous Switching Output) ? IBIS as a model, has all the parameters required to model an SSO event. These are mainly the package inductance parameters and other associated parasitics. IBIS specifies R, L and C in matrix format and the use of a matrix for the inductance accounts for the "loop"inductance i.e. the mutuals between the pins. Specifying the mutual inductance is necessary to account for SSO event simulation. Modeling an SSO event is more of a simulator issue than IBIS. 7.0 Why do we need to sweep -Vcc to 2Vcc ? Simulation accuracy is greatly enhanced by the "beyond-the-rail" data. Overshoot and undershoot generally fall within this range, and the range encompasses the forward-biased regions of protection diodes often used on buffers. Also, reflections caused by improper terminations can produce voltages at the driver/receiver terminals from -Vcc to 2Vcc. The drivers and receivers, therefore, need to be modeled over this entire range. Since measurement of diodes over the entire range is often not possible, measurement over a reasonable range and extrapolation of data to the end-point values is permitted to produce IBIS models. Most non-SPICE based simulators will do their own extrapolation to get to the end point. Most Spice simulators truncate data to the table end-points. The -Vcc to 2Vcc range ensures consistent performance for both types of simulators. ----------------------------------------------------------------------------- From iniewski@procyon.pmc-sierra.bc.ca Mon Aug 21 16:27:00 1995 Return-Path: Received: from procyon (procyon.pmc-sierra.bc.ca) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23633; Mon, 21 Aug 95 16:27:00 PDT Received: by procyon (5.57/Ultrix3.0-C) id AA01439; Mon, 21 Aug 95 16:18:27 -0700 Message-Id: Date: 21 Aug 1995 16:24:18 -0800 From: "iniewski" Subject: Re: FAQ #6 and #7 revised... To: "Syed Huq" , "ibis vhdl.org" X-Mailer: Mail*Link SMTP-QM 3.0.2 Reply to: RE>FAQ #6 and #7 revised.... I still have a problem with understanding why ibis requires -Vdd to 2*Vdd sweeps and how to generate data for ibis (FAQ #7, I am a good test case since I started reading IBIS stuff a couple of days ago). For Vout=-5V (or worse case -5.5V) it basically means very heavy forward biasing of n+/p diode (in a standard output inverter configuration), which might lead to diode destruction. Also Vout=+10V (or even +11V) could lead to latchup or oxide breakdown. I believe this applies to most CMOS buffers manufactured in submicron processes. If I reduce these voltage limits then I can extrapolate to -Vdd and to 2*Vdd. The problem is that I get very different answers depending what voltage I chose (6,7 or 8V for example) as the last point measured and used for further extrapolation. Extrapolation seems to imply that I-V characteristics is linear, in fact it is not (avalanche multiplication effect for positive voltages and forward diode conduction for negative voltages). The bottom line is that depending how I do measurements or perform simulation I will get different results at -Vdd/2*Vdd limits (as much as by a factor of 2). Hoping to get some clarification on this... Kris Iniewski PMC-Sierra Inc. -------------------------------------- Date: 8/21/95 4:01 PM To: iniewski From: Syed Huq IBISfans, As mentioned in the last IBIS Minutes (Aug11th'95), the last two FAQ that need to be re-worded were #6 and #7. I am attaching the revised answers based on some inputs I received. Pls post your comment/changes/suggestions on the reflector and we shall vote on this on the Aug25th meeting. Regards, Syed. National Semiconductor. -------------------------------------------------------------------------- 6.0 Can IBIS model SSO(Simultaneous Switching Output) ? IBIS as a model, has all the parameters required to model an SSO event. These are mainly the package inductance parameters and other associated parasitics. IBIS specifies R, L and C in matrix format and the use of a matrix for the inductance accounts for the "loop"inductance i.e. the mutuals between the pins. Specifying the mutual inductance is necessary to account for SSO event simulation. Modeling an SSO event is more of a simulator issue than IBIS. 7.0 Why do we need to sweep -Vcc to 2Vcc ? Simulation accuracy is greatly enhanced by the "beyond-the-rail" data. Overshoot and undershoot generally fall within this range, and the range encompasses the forward-biased regions of protection diodes often used on buffers. Also, reflections caused by improper terminations can produce voltages at the driver/receiver terminals from -Vcc to 2Vcc. The drivers and receivers, therefore, need to be modeled over this entire range. Since measurement of diodes over the entire range is often not possible, measurement over a reasonable range and extrapolation of data to the end-point values is permitted to produce IBIS models. Most non-SPICE based simulators will do their own extrapolation to get to the end point. Most Spice simulators truncate data to the table end-points. The -Vcc to 2Vcc range ensures consistent performance for both types of simulators. ----------------------------------------------------------------------------- ------------------ RFC822 Header Follows ------------------ Received: by pmcmac.pmc-sierra.bc.ca with SMTP;21 Aug 1995 16:00:59 -0800 Received: by procyon (5.57/Ultrix3.0-C) id AA01293; Mon, 21 Aug 95 15:52:19 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23337; Mon, 21 Aug 95 15:31:20 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA00142 for ibis@vhdl.org; Mon, 21 Aug 95 15:24:35 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA06128 for ibis@vhdl.org; Mon, 21 Aug 95 15:24:33 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA27399; Mon, 21 Aug 95 15:27:09 PDT Date: Mon, 21 Aug 95 15:27:09 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9508212227.AA27399@rockie.nsc.com> To: ibis@vhdl.org Subject: FAQ #6 and #7 revised.... From sung.oh@tempe.vlsi.com Mon Aug 21 17:12:52 1995 Return-Path: Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23925; Mon, 21 Aug 95 17:12:52 PDT Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id RAA07842; Mon, 21 Aug 1995 17:13:37 -0700 From: sung.oh@tempe.vlsi.com Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id RAA02413; Mon, 21 Aug 1995 17:12:40 -0700 Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id RAA23459; Mon, 21 Aug 1995 17:10:50 -0700 Received: by sedona id AA16445; Mon, 21 Aug 95 17:12:36 MST Date: Mon, 21 Aug 95 17:12:36 MST Message-Id: <9508220012.AA16445@sedona> To: huq@rockie.nsc.com Subject: Re: FAQ #6 and #7 revised.... Cc: ibis@vhdl.org Syed, I have been thinking about the possibility of IBIS model providing any SSO noise estimation. I was trying to set it aside until I have an alternative suggestion. However, I decide it is better to issue the problem before we spread a propaganda. I am afraid that SSO noise prediction might not be possible with present IBIS format. The reason is that the present format doesn't have rise/fall time informations at the input of output buffers. Generally, the SSO noise is determined by the input transition time and the maximum current of output driver (not the output transition time). An I/V characteristic of output buffers may provide the maximum current. But the input transition time is still missing. Also the on-chip decoupling capacitor would make the noise characteristics different, which is not yet included in the format. In conclusion, I am suggesting we might drop out this QA until we have better understanding/solution to it. Regards, Sung Oh VLSI Technology, Inc. >>From huq@rockie.nsc.com Mon Aug 21 15:43 MST 1995 >>Date: Mon, 21 Aug 95 15:27:09 PDT >>From: huq@rockie.nsc.com (Syed Huq) >>To: ibis@vhdl.org >>Subject: FAQ #6 and #7 revised.... >>Content-Type >>: >>text >> >>Content-Length: 1937 >>X-Lines: 44 >> >>IBISfans, >> >>As mentioned in the last IBIS Minutes (Aug11th'95), the last two >>FAQ that need to be re-worded were #6 and #7. >> >>I am attaching the revised answers based on some inputs I received. >> >>Pls post your comment/changes/suggestions on the reflector and we >>shall vote on this on the Aug25th meeting. >> >>Regards, >>Syed. >>National Semiconductor. >> >>-------------------------------------------------------------------------- >>6.0 Can IBIS model SSO(Simultaneous Switching Output) ? >> >>IBIS as a model, has all the parameters required to model an SSO event. These >>are mainly the package inductance parameters and other associated parasitics. >>IBIS specifies R, L and C in matrix format and the use of a matrix for the >>inductance accounts for the "loop"inductance i.e. the mutuals between the >>pins. Specifying the mutual inductance is necessary to account for SSO event >>simulation. Modeling an SSO event is more of a simulator issue than IBIS. >> >>7.0 Why do we need to sweep -Vcc to 2Vcc ? >> >>Simulation accuracy is greatly enhanced by the "beyond-the-rail" data. >>Overshoot and undershoot generally fall within this range, and the range >>encompasses the forward-biased regions of protection diodes often used on >>buffers. Also, reflections caused by improper terminations can produce >>voltages at the driver/receiver terminals from -Vcc to 2Vcc. The drivers >>and receivers, therefore, need to be modeled over this entire range. >> >>Since measurement of diodes over the entire range is often not possible, >>measurement over a reasonable range and extrapolation of data to the >>end-point values is permitted to produce IBIS models. >> >>Most non-SPICE based simulators will do their own extrapolation to get to >>the end point. Most Spice simulators truncate data to the table >>end-points. >> >>The -Vcc to 2Vcc range ensures consistent performance for both types of >>simulators. >>----------------------------------------------------------------------------- >> From Arpad_Muranyi@ccm.fm.intel.com Mon Aug 21 17:28:31 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24008; Mon, 21 Aug 95 17:28:31 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0skh5w-000Ug5C; Mon, 21 Aug 95 17:21 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0skh5w-000tx4C; Mon, 21 Aug 95 17:21 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Mon, 21 Aug 95 17:21:32 PDT Date: Mon, 21 Aug 95 17:08:00 PDT From: Arpad Muranyi Message-Id: To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: FAQ #6 and #7 revised.... Text item: Syed, I would combine the very last two paragraphs into one (in #7). Regarding #6, I was expecting to read something about the [Pin Mapping] keyword. To be able to do good GND bounce simulations one must know how many buffers are getting their supply current through the same power and GND pins. Your answer does not address this side of the issue, only the L,R,C part. Could you add this to it? Arpad =============================================================================== IBISfans, As mentioned in the last IBIS Minutes (Aug11th'95), the last two FAQ that need to be re-worded were #6 and #7. I am attaching the revised answers based on some inputs I received. Pls post your comment/changes/suggestions on the reflector and we shall vote on this on the Aug25th meeting. Regards, Syed. National Semiconductor. -------------------------------------------------------------------------- 6.0 Can IBIS model SSO(Simultaneous Switching Output) ? IBIS as a model, has all the parameters required to model an SSO event. These are mainly the package inductance parameters and other associated parasitics. IBIS specifies R, L and C in matrix format and the use of a matrix for the inductance accounts for the "loop"inductance i.e. the mutuals between the pins. Specifying the mutual inductance is necessary to account for SSO event simulation. Modeling an SSO event is more of a simulator issue than IBIS. 7.0 Why do we need to sweep -Vcc to 2Vcc ? Simulation accuracy is greatly enhanced by the "beyond-the-rail" data. Overshoot and undershoot generally fall within this range, and the range encompasses the forward-biased regions of protection diodes often used on buffers. Also, reflections caused by improper terminations can produce voltages at the driver/receiver terminals from -Vcc to 2Vcc. The drivers and receivers, therefore, need to be modeled over this entire range. Since measurement of diodes over the entire range is often not possible, measurement over a reasonable range and extrapolation of data to the end-point values is permitted to produce IBIS models. Most non-SPICE based simulators will do their own extrapolation to get to the end point. Most Spice simulators truncate data to the table end-points. The -Vcc to 2Vcc range ensures consistent performance for both types of simulators. ----------------------------------------------------------------------------- Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: FAQ #6 and #7 revised.... To: ibis@vhdl.org Message-Id: <9508212227.AA27399@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Mon, 21 Aug 95 15:27:09 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA27399; Mon, 21 Aug 95 15:27:09 PDT Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA06128 for ibis@vhdl.org; Mon, 21 Aug 95 15:24:33 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA00142 for ibis@vhdl.org; Mon, 21 Aug 95 15:24:35 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23337; Mon, 21 Aug 95 15:31:20 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 21 Aug 95 15 :27:03 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0skfae-000txEC; Mon, 21 Aug 95 15:45 PDT From mellitz@eagle.ColumbiaSC.NCR.COM Tue Aug 22 06:06:25 1995 Return-Path: Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02717; Tue, 22 Aug 95 06:06:25 PDT From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Content-Length: 4001 Content-Type: text Message-Id: <9508220858.ZM10596@eagle> Date: Tue, 22 Aug 1995 08:58:20 -0400 In-Reply-To: ansoft.com!nirmal (Nirmal Jain) "Re: GND Plane Bounce Question" (Aug 21, 4:10pm) References: <9508212010.AA14903@cobra.ansoft.com> X-Mailer: Z-Mail (2.1.4 02apr93) To: nirmal@ansoft.com (Nirmal Jain), Samie_Samaan@ccm2.jf.intel.com Subject: Re: GND Plane Bounce Question Cc: si-list@silab.Eng.Sun.COM (SI List), ibis@vhdl.org On Aug 21, 4:10pm, Nirmal Jain wrote: > Subject: Re: GND Plane Bounce Question > > > > > >Text item: Text_1 > > > > > > All IBISians (SI experts by Default !!) > > > > I would like to pose the following SI question, and solicit help from > > those who actually know the answer or have a very good idea of how to > > estimate it by scaling from previous experience: > > > > > > Assume one GND and one power plane in a PCB separated by say 10 mil, > > with a dielectric constant of say 4. assume that the power plane has a > > via opening where current is injected thru the via down to the GND > > plane. Let's say that the current is 10 Amps. with a riserime of 1 ns. > > Assume nominal via diameter. The drawing below shows the structure: > > > > > > | Vcc > > ---------------- | ------------------ > > | GND 10 mil, Er=4 > > -----------------|------------------- > > > > > > What I would like to hear from anybody who actually has experienced > > GND plane bounce, is: > > > > *howmuch do you expect the GND plane (not the via stem) to bounce up > > (locally) given the above assumptions, and > > > > *howfar away from the via (radially) do you expect the bounce to drop > > to 10% of the peak which occurs right where the via meets the plane ? > > > > I would apprciate a good guess (and Why: perhaps from previous > > experience), or direction as to "who ?" you think could answer such a > > question. I know that I might need to do a 3-D or radial transmission > > line analysis of the system, but I'm really just looking for a quick > > answer. > > The ground bounce depends on the inductance presented to the path of > current. The correct approach is to treat the plane as multi-terminal > conductor and solve for L matrix for all those current paths. > > So in the above fig you have to have another terminal or terminals > on the GND plane which would define the current path and hence > ground bounce. So we need the information about how the current > flows on the gnd plane. If you have more current terminals onthe GND > plane your effective inductance will be lower and hence GND bounce. > > > Best regards > > Nirmal > I agree. You don't just have 10 amps. Its got to come from somewhere and go to somewhere. (Remember Kirchhoff?). Sometimes you can SWAG what happeneing if you know the major components (capacitors, inductors, connectors, loads, power supplies, etc.) and their frequency characteristics. The first step is determine an equivelent circuit. Sometimes a simple circuit will lend answers that are acceptable. However, many times this may not be acceptable, ergo a 3-D circuit synthesis -> SPICE might be inorder. Without more details I can't tell if a simple analysis will lend "good enough" results. Best regards, Rich > > > > > > Thanks for taking the time to read or answer this question. > > > > Samie Samaan > > Intel Corp. > > > _______________________________________________________________________________ > Nirmal Jain ANSOFT CORPORATION > (412) 261-3200 X29 (W) Four Station Sq., Suite 660 > (412) 471-9427(FAX) Pittsburgh, PA 15219 > _______________________________________________________________________________ > >-- End of excerpt from Nirmal Jain --------------------------------------------------------------------- Richard Mellitz | AT&T | Global Information Solutions | richard.mellitz@columbiasc.attgis.com 3325 Platt Spring Road | Phone: (803)-939-6240 West Columbia, SC 29170 | Fax: (803)-939-7317 --------------------------------------------------------------------- From nirmal@ansoft.com Tue Aug 22 07:54:43 1995 Return-Path: Received: from maxwell.ansoft.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03403; Tue, 22 Aug 95 07:54:43 PDT Received: from cobra.ansoft.com by maxwell.ansoft.com (4.1/SMI-4.1) id AA01236; Tue, 22 Aug 95 10:47:12 EDT Received: by cobra.ansoft.com; Tue, 22 Aug 95 10:53:01 -0400 From: Nirmal Jain Message-Id: <9508221453.AA19424@cobra.ansoft.com> Subject: Re: Re[2]: GND Plane Bounce Question To: Samie_Samaan@ccm2.jf.intel.com Date: Tue, 22 Aug 95 10:53:01 EDT Cc: si-list@ansoft.com, ibis@vhdl.org In-Reply-To: ; from "Samie Samaan" at Aug 21, 95 2:23 pm Mailer: Elm [revision: 66.33] Samie > > >Text item: > > > > Nirmal, > > Thank you for the help. I do not think that knowing the source and where > its retrun is are crucial to answering the question as I posed it ! > > Simply assume that I magically could inject 10 amps in 1 ns to the GND > plane thru the via, my question is what voltage spike would you see on that > plane ?? > The above would be the case if the ground plane in your design is an ideal GND plane and is sinking all the current. Then the Leff would be due to the via only and the SSN would be Vssn = Lvia * 10A/1ns If the above plane is NIGP ( Non-ideal Gnd plane ) then the current flow is going to depend on how this GND plane is connected to other reference GNDs in the design. The L due to the NIGP would depend upon this current flow. If you have more terminal on the GND plane your L due to GND plane will be lower ( becos now you have more number of current paths). Hope it makes sense. If it does not we can discuss it further or may be you can call me at (412-261-3200 X29). Regards Nirmal ANSOFT > Am I missing something ? Does one really have to know the rest of teh > topology to answer the question ? > > Thanks again > > Samie Samaan > >______________________________ Reply Separator _________________________________ >Subject: Re: GND Plane Bounce Question >Author: nirmal@ansoft.com at SMTPGATE >Date: 8/21/95 4:10 PM > > >> >> >>Text item: Text_1 >> >> >> All IBISians (SI experts by Default !!) >> >> I would like to pose the following SI question, and solicit help from >> those who actually know the answer or have a very good idea of how to >> estimate it by scaling from previous experience: >> >> >> Assume one GND and one power plane in a PCB separated by say 10 mil, >> with a dielectric constant of say 4. assume that the power plane has a >> via opening where current is injected thru the via down to the GND >> plane. Let's say that the current is 10 Amps. with a riserime of 1 ns. >> Assume nominal via diameter. The drawing below shows the structure: >> >> >> | Vcc >> ---------------- | ------------------ >> | GND 10 mil, Er=4 >> -----------------|------------------- >> >> >> What I would like to hear from anybody who actually has experienced >> GND plane bounce, is: >> >> *howmuch do you expect the GND plane (not the via stem) to bounce up >> (locally) given the above assumptions, and >> >> *howfar away from the via (radially) do you expect the bounce to drop >> to 10% of the peak which occurs right where the via meets the plane ? >> >> I would apprciate a good guess (and Why: perhaps from previous >> experience), or direction as to "who ?" you think could answer such a >> question. I know that I might need to do a 3-D or radial transmission >> line analysis of the system, but I'm really just looking for a quick >> answer. > > The ground bounce depends on the inductance presented to the path of > current. The correct approach is to treat the plane as multi-terminal > conductor and solve for L matrix for all those current paths. > > So in the above fig you have to have another terminal or terminals > on the GND plane which would define the current path and hence > ground bounce. So we need the information about how the current > flows on the gnd plane. If you have more current terminals onthe GND > plane your effective inductance will be lower and hence GND bounce. > > > Best regards > > Nirmal > >> >> >> Thanks for taking the time to read or answer this question. >> >> Samie Samaan >> Intel Corp. > > >_______________________________________________________________________________ >Nirmal Jain ANSOFT CORPORATION >(412) 261-3200 X29 (W) Four Station Sq., Suite 660 >(412) 471-9427(FAX) Pittsburgh, PA 15219 >_______________________________________________________________________________ From mbs@eos.ncsu.edu Tue Aug 22 08:47:09 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03734; Tue, 22 Aug 95 08:47:09 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08141; Tue, 22 Aug 1995 11:40:24 -0400 From: mbs@eos.ncsu.edu Message-Id: <9508221540.AA08141@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: IBIS model update Date: Tue, 22 Aug 95 11:40:22 EDT From your IBIS librarian ... (2 days to beta release of S2IBIS2.1) Note, there are no new models to be processed. If you think that you have submitted inew models to be included in the library then you need to mail me at mbs@ncsu.edu as I do not have them. I suspect that there is one batch of models that have got lost. Michael Steer ============ Intel has updated the following ibis models: 82374eb.ibs 82374sb.ibs 82375eb.ibs 82375sb.ibs 82378ib.ibs 82378zb.ibs 82423tx.ibs 82424zx.ibs 82425ex.ibs 82426ex.ibs 82433lx.ibs 82433nx.ibs 82434lx.ibs 82434nx.ibs has submitted a new model 82379ab.ibs and is providing the following with a nondisclosure agreement. (See the /pub/ibis/models/intel/00readme for more info.) 82371fb.ibs 82371mb.ibs 82437fx.ibs 82437mx.ibs 82437vx.ibs 82438fx.ibs 82438mx.ibs 82438vx.ibs All the models are IBIS1.1 ======================== The IBIS library contains the following models Intel Corporation IBIS Files on vhdl.org as of 8/22/95 Part/File vhdl.org alpha rev. rev. IBIS name Directory name date level ver. Notes -------------------------------------------------------------------------------- 82371fb.ibs chipset PIIX 08-09-95 R1.21 V1.1 Triton (NDA only)** 82371mb.ibs chipset MPIIX 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82374eb.ibs chipset ESC 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82374sb.ibs chipset ESC 08-09-95 R1.03 V1.1 PCI-EISA Bridge** 82375eb.ibs chipset PCEB 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82375sb.ibs chipset PCEB 08-09-95 R1.01 V1.1 PCI-EISA Bridge** 82378ib.ibs chipset SIO 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82378zb.ibs chipset SIO 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82379ab.ibs chipset SIO.A 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82423tx.ibs chipset DPU 08-09-95 R2.13 V1.1 Saturn** 82424zx.ibs chipset CDC 08-09-95 R2.13 V1.1 Saturn** 82425ex.ibs chipset PSC 08-09-95 R0.94 V1.1 Aries** 82426ex.ibs chipset IB 08-09-95 R0.94 V1.1 Aries** 82433lx.ibs chipset LBX 08-09-95 R2.13 V1.1 Mercury** 82433nx.ibs chipset LBX 08-09-95 R2.01 V1.1 Neptune** 82434lx.ibs chipset PCMC 08-09-95 R2.13 V1.1 Mercury** 82434nx.ibs chipset PCMC 08-09-95 R2.01 V1.1 Neptune** 82437fx.ibs chipset TSC 08-09-95 R1.21 V1.1 Triton (NDA only)** 82437mx.ibs chipset MTSC 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82437vx.ibs chipset TVX 08-09-95 R1.00 V1.1 Triton VX (NDA only)** 82438fx.ibs chipset TDP 08-09-95 R1.21 V1.1 Triton (NDA only)** 82438mx.ibs chipset MTDP 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82438vx.ibs chipset TDX 08-09-95 R1.00 V1.1 Triton (NDA only)** dx4pga.ibs cpu DX4 05-04-94 R2.0 V1.1 IntelDX4(TM) uP pp66sem.ibs pentium PP66 10-16-94 R3.0 V1.1 66MHz Pentium* pp100sem.ibs pentium PP100 10-15-94 R3.0 V1.1 100MHz Pentium* * Translated from an Intel Simplified Electrical Model. ** submitted by Name of Person Submitting: Arpad Muranyi Address: 1900 Prairie City Road Folsom, CA 95630 Affiliation: Intel Corporation E-Mail: arpad_muranyi@ccm.fm.intel.com Telephone Number: (916) 356-2558 Fax Number: (916) 356-3162 (NDA only) Non disclosure agreement required to obtain model. Contact submitter. ======================== National Semiconductor Corporation - Advanced Systems & Interface Product Group IBIS Files on vhdl.org as of 8/22/95 Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes -------------------------------------------------------------------------------- ds26c31.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Drvr ds26c32.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Recvr lct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524n.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr c2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2525m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) c2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2527v.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2528m.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528n.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2529v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) 2534v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Commercial) 2535v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) 2536v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) b303m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr 701v.ibs cgs 04-05-95 1.0 1.1 Low Skew PLL 1to8 CMOS Clk Drvr 2537v.ibs cgs 04-17-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) pc87306.ibs superI_O 05-25-95 1.0 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int g612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead g612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead gp612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead gp612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead dp8440vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver dp8441vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver From Samie_Samaan@ccm2.jf.intel.com Tue Aug 22 08:53:58 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03757; Tue, 22 Aug 95 08:53:58 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0skvWs-000UgxC; Tue, 22 Aug 95 08:46 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0skvWs-000txEC; Tue, 22 Aug 95 08:46 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Tue, 22 Aug 95 08:46:18 PDT Date: Tue, 22 Aug 95 08:43:00 PDT From: Samie Samaan Message-Id: To: ibis@vhdl.org, fyuan%qdt.com%uunet@uunet.uu.net, uunet!uunet!ccm2.jf.intel.com!Samie_Samaan@uunet.uu.net Cc: uunet!qdt.com!jonp@uunet.uu.net, uunet!qdt.com!fyuan@uunet.uu.net Subject: Re[2]: GND Plane Bounce Question Text item: Frank, Thank you very much for taking the time to address this problem. In fact I would like to know more about this tool, if you can send me some info on it. My address is with Quad, and also at the bottom. The numbers you give me are a big help. With a formula provided by someone else, I will have a good idea of what to expect. I would like to comment on this whole issue a bit, and address what prompted my question in the first place:- Some of the colleagues who answered my inquiry, correctly indicated that I should designate the source of the current and not just its sink. So I answered one of them by saying the following: Assume that I can magically inject the current into the GND plane thru the via...etc. The reason I say that is because I was really interested in local bounce, with the closest discontinuity to the GND plane being a few inches away. Such a case arises when you are dealing with, say, open collector buffers, where the collector is tied to a signal trace on the top layer of my hypothetical board, while the emitter pumps the GND plane thru the via. The source of the current has to tie back to the plane at some distant point, but that is not very relevant (in my opinion) during the first few 100 ps's of the transient around the via. The real reason I asked the above question has not been stated by me yet. Well, here it goes: If one is trying to measure Clk-out delay (Tco) of a buffer using a scope, and places the scope ground near my via, while placing the scope's active lead at the bit of interest, then, I believe, that if many bits are switching, that the waveform seen by the scope would be distorted by the GND plane bounce. Say you have a falling edge (while many bits toggle down), then since the GND bounces up, the scope would read a smaller voltage (its gnd lead is moving up too), and show the edge to be just as fast as when a single bit switches (or nearly so) even though the edge has --in reality-- slowed down due to SSO. So one has to be more clever as to where to measure Tco is such situations. Do others agree with my assesment ?? Sincerely, Samie Samaan Intel 2111 NE 25th Ave Hillsboro, OR 97124. ______________________________ Reply Separator _________________________________ Subject: Re: GND Plane Bounce Question Author: fyuan%qdt.com%uunet@uunet.uu.net at SMTPGATE Date: 8/21/95 6:31 PM Hi, Samie, I did some quick and simple simulations for your GND plane bounce problem using the power/ground plane simulation tool we have at Quad Design. The PCB is same as yours, and the size is 10x10 inch. Assume the current is 10 mA (instead of 10 Amps in your message), and there are no de-caps or other loads between the power/ground plane, the local ground bound is about 8 ~ 10 mV, assuming the current source has a 50 ohm internal resistance. The ground noise propagates all over the plane, so the bounce away from the via is lower but not too much than that at the vis. Depending on location, the bounce is 2 ~ 6 mV. The location of the via also have some effects on bounce, but is usually small. Note that if you really have a 10 Amps current, the bounce would be 8 ~ 10 volts. That will be a truly unusual or extrame situation. The above results assuming the power/ground planes are open (or no other terminations), This usually gives higher estimate of GND bounce because of the resonance of the plane. From my experice, the things affect the ground bounce mostly are your loads, especially decoupling capacitors. Proper placement of de-caps of 10~100 nf can significantly reduce the GND bounce in the above situation, by 5 ~ 10 times. Resistive loads have little effects on the GND bounce unless it is really small ( about 0.1 ohm for the above example). Our tool can do a much better job in extimating GND bounce if you have more information about the geometry, the ternimation or load conditions, and the source or device characteristics. Hope this is useful for you. Regards Frank Yuan Quad Design Technology (805) 988-8250 > From uunet!ccm2.jf.intel.com!Samie_Samaan Mon Aug 21 13:11:20 1995 > Date: Mon, 21 Aug 95 11:22:00 PDT > From: Samie Samaan > To: uunet!vhdl.org!ibis > Subject: GND Plane Bounce Question > Content-Length: 1709 > > > Text item: Text_1 > > > All IBISians (SI experts by Default !!) > > I would like to pose the following SI question, and solicit help from > those who actually know the answer or have a very good idea of how to > estimate it by scaling from previous experience: > > > Assume one GND and one power plane in a PCB separated by say 10 mil, > with a dielectric constant of say 4. assume that the power plane has a > via opening where current is injected thru the via down to the GND > plane. Let's say that the current is 10 Amps. with a riserime of 1 ns. > Assume nominal via diameter. The drawing below shows the structure: > > > | Vcc > ---------------- | ------------------ > | GND 10 mil, Er=4 > -----------------|------------------- > > > What I would like to hear from anybody who actually has experienced > GND plane bounce, is: > > *howmuch do you expect the GND plane (not the via stem) to bounce up > (locally) given the above assumptions, and > > *howfar away from the via (radially) do you expect the bounce to drop > to 10% of the peak which occurs right where the via meets the plane ? > > I would apprciate a good guess (and Why: perhaps from previous > experience), or direction as to "who ?" you think could answer such a > question. I know that I might need to do a 3-D or radial transmission > line analysis of the system, but I'm really just looking for a quick > answer. > > > Thanks for taking the time to read or answer this question. > > Samie Samaan > Intel Corp. > 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: uunet!qdt.com!jonp@uunet.uu.net, uunet!qdt.com!fyuan@uunet.uu.net Subject: Re: GND Plane Bounce Question To: uunet!uunet!ccm2.jf.intel.com!Samie_Samaan@uunet.uu.net Message-Id: <9508220131.AA09604@hal.qdt.com> From: uunet!qdt.com!fyuan@uunet.uu.net (Frank Yuan) Date: Mon, 21 Aug 95 18:31:04 PDT Received: from miata.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09604; Mon, 21 Aug 95 18:31:04 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01350; Mon, 21 Aug 95 18:31:04 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 21 Aug 1995 21:37:05 -0400 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQzdva25699; Mon, 21 Aug 1995 21:37:06 -0400 Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09634; Mon, 21 Aug 95 18:37:40 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01366; Mon, 21 Aug 95 18:37:40 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 21 Aug 1995 22:07:40 -0400 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQzdvc01112; Mon, 21 Aug 1995 22:07:34 -0400 Received: from relay3.UU.NET by hermes.intel.com (5.65/10.0i); Mon, 21 Aug 95 19 :09:03 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 21 Aug 9 5 19:09:25 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0skimO-000twhC; Mon, 21 Aug 95 19:09 PDT From contec!contec.contec.COM!dileep@netcom.com Tue Aug 22 09:20:54 1995 Return-Path: Received: from netcomsv.netcom.com (uucp2.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03926; Tue, 22 Aug 95 09:20:54 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id JAA24037; Tue, 22 Aug 1995 09:05:29 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA13873; Tue, 22 Aug 95 08:51:16 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA15627; Tue, 22 Aug 1995 08:54:03 +0800 Date: Tue, 22 Aug 1995 08:54:03 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9508221554.AA15627@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Bird 28.2 - Comments and Suggestions Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 942 Editorial Comment: The character used to separate the section information is a slash (/) and not a backslash (\) as mentioned. Comment: It would be helpful to clarify if ALL of L/R/C have to be specified. That is, is any of the following allowed? /Len=1.3 L=1.3n/ /Len=2.5 L=3n C=0 R=0/ Suggestion: I think the off diagonal entries in the C matrix should be specified as negative numbers, if they are indeed negative, as they are in this case, instead of making them positive. Suggestion: For the sake of completeness and generality, the specification should allow an optional G specification which is a conductance in parallel with C, similar to R in series with L. ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From sung.oh@tempe.vlsi.com Tue Aug 22 13:44:18 1995 Return-Path: Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05835; Tue, 22 Aug 95 13:44:18 PDT Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id NAA01104; Tue, 22 Aug 1995 13:45:09 -0700 From: sung.oh@tempe.vlsi.com Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id NAA09271; Tue, 22 Aug 1995 13:44:03 -0700 Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id NAA28163; Tue, 22 Aug 1995 13:42:12 -0700 Received: by sedona id AA16981; Tue, 22 Aug 95 13:43:59 MST Date: Tue, 22 Aug 95 13:43:59 MST Message-Id: <9508222043.AA16981@sedona> To: Samie_Samaan@ccm2.jf.intel.com Subject: Re: Re[2]: GND Plane Bounce Question Cc: ibis@vhdl.org Samie, I agree. However, it is not a matter of where you measure. As soon as your prober touches the bit of interest, SSO noise will be reduced because of the current through the prober capacitor to the ground plane. In that case, true Tco will be in question. Regards, Sung Oh VLSI Technology, Inc. >>From Samie_Samaan@ccm2.jf.intel.com Tue Aug 22 09:11 MST 1995 >>Date: Tue, 22 Aug 95 08:43:00 PDT >>From: Samie Samaan >>To: ibis@vhdl.org, fyuan%qdt.com%uunet@uunet.uu.net, >> uunet!uunet!ccm2.jf.intel.com!Samie_Samaan@uunet.uu.net >>Cc: uunet!qdt.com!jonp@uunet.uu.net, uunet!qdt.com!fyuan@uunet.uu.net >>Subject: Re[2]: GND Plane Bounce Question >>Content-Type >>: >>text >> >>Content-Length: 7935 >>X-Lines: 181 >> >> >>Text item: >> >> Frank, >> >> Thank you very much for taking the time to address this problem. In >> fact I would like to know more about this tool, if you can send me >> some info on it. My address is with Quad, and also at the bottom. The >> numbers you give me are a big help. With a formula provided by someone >> else, I will have a good idea of what to expect. >> >> >> I would like to comment on this whole issue a bit, and address what >> prompted my question in the first place:- >> >> Some of the colleagues who answered my inquiry, correctly indicated >> that I should designate the source of the current and not just its >> sink. So I answered one of them by saying the following: Assume that I >> can magically inject the current into the GND plane thru the >> via...etc. The reason I say that is because I was really interested in >> local bounce, with the closest discontinuity to the GND plane being a >> few inches away. Such a case arises when you are dealing with, say, >> open collector buffers, where the collector is tied to a signal trace >> on the top layer of my hypothetical board, while the emitter pumps the >> GND plane thru the via. The source of the current has to tie back to >> the plane at some distant point, but that is not very relevant (in my >> opinion) during the first few 100 ps's of the transient around the >> via. >> >> The real reason I asked the above question has not been stated by me >> yet. Well, here it goes: If one is trying to measure Clk-out delay >> (Tco) of a buffer using a scope, and places the scope ground near my >> via, while placing the scope's active lead at the bit of interest, >> then, I believe, that if many bits are switching, that the waveform >> seen by the scope would be distorted by the GND plane bounce. Say you >> have a falling edge (while many bits toggle down), then since the GND >> bounces up, the scope would read a smaller voltage (its gnd lead is >> moving up too), and show the edge to be just as fast as when a single >> bit switches (or nearly so) even though the edge has --in reality-- >> slowed down due to SSO. So one has to be more clever as to where to >> measure Tco is such situations. >> >> Do others agree with my assesment ?? >> >> Sincerely, >> >> Samie Samaan >> Intel >> 2111 NE 25th Ave >> Hillsboro, OR 97124. From contec!contec.contec.COM!dileep@netcom.com Tue Aug 22 16:19:31 1995 Return-Path: Received: from netcomsv.netcom.com (uucp5.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06774; Tue, 22 Aug 95 16:19:31 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA10811; Tue, 22 Aug 1995 15:53:33 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA17083; Tue, 22 Aug 95 15:50:25 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA16021; Tue, 22 Aug 1995 15:53:12 +0800 Date: Tue, 22 Aug 1995 15:53:12 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9508222253.AA16021@contec13.contec.COM> To: ibis@vhdl.org Subject: IBIS models under NDA Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 716 I am confused by the fact that the semiconductor companies ask for NDA for providing IBIS models. The whole purpose of IBIS is to make it possible for the semiconductor companies to provide models without disclosing proprietary information. I can understand if they want people to ask them for models instead of having the models on the ibis reflector. But requiring NDA for IBIS models defeats the purpose of IBIS. Am I missing something here? ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From dla@pyramid.com Tue Aug 22 16:50:18 1995 Return-Path: Received: from bertha.pyramid.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06976; Tue, 22 Aug 95 16:50:18 PDT Received: from pyrnoevil.or.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA07873; Tue, 22 Aug 95 23:43:32 GMT Received: by pyrnoevil.or.pyramid.com (5.61/OSx5.1) id AA12243; Tue, 22 Aug 95 16:43:31 -0700 From: dla@pyramid.com (Don Abernathey) Message-Id: <9508221643.ZM12241@pyrnoevil.or.pyramid.com> Date: Tue, 22 Aug 1995 16:43:30 -0700 In-Reply-To: dileep@contec.contec.COM (Dileep Divekar) "IBIS models under NDA" (Aug 22, 3:53pm) References: <9508222253.AA16021@contec13.contec.COM> X-Mailer: Z-Mail (2.1.2 11jan93) To: dileep@contec.contec.COM (Dileep Divekar), ibis@vhdl.org Subject: Re: IBIS models under NDA On Aug 22, 3:53pm, Dileep Divekar wrote: > Subject: IBIS models under NDA > I am confused by the fact that the > semiconductor companies ask for NDA for providing > IBIS models. The whole purpose of IBIS is to make > it possible for the semiconductor companies to > provide models without disclosing proprietary > information. I can understand if they want people > to ask them for models instead of having the > models on the ibis reflector. But requiring NDA > for IBIS models defeats the purpose of IBIS. > Am I missing something here? > ------------------------------------------------------------ > Dileep Divekar > Contec CAE, Ltd. > 2188 Bering Drive > San Jose, CA 95131 > > Phone - (408)-434-6767 x 126 > Fax - (408)-434-6884 > Email - dileep@contec.com > ------------------------------------------------------------ > >-- End of excerpt from Dileep Divekar Hello! IBIS is at best in it's infancy, at worst a joke. The NDA issue can be viewed as proof either way. A list could be started with similar "facts". In my opinion, IBIS is not yet usefull for much of anything, but it has potential. Thank you Don Abernathey From speters@ichips.intel.com Tue Aug 22 17:44:57 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07283; Tue, 22 Aug 95 17:44:57 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 22 Aug 95 17:38:08 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 22 Aug 95 17:38:03 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 22 Aug 95 17:38:02 PDT Message-Id: <9508230038.AA15893@xtg801.intel.com> To: ibis@vhdl.org Subject: Models under NDA Date: Tue, 22 Aug 1995 17:38:00 -0700 From: Stephen Peters Hello Dileep, Don: The fact that an IBIS model for a particular device is available only under NDA may simply mean that the part is not publicly available yet. Think how a manufacture treates an advanced product specification or pinlist -- they are made available only under NDA, and the IBIS model is just another piece of information of that type. The core thing to remember is that after a part is released an IBIS model can be made public (just like the final data sheet) and the manufacture does not have to worry about giving away his/her I/O buffer design and process. Regards, Stephen Peters Intel Corp. On Aug 22, 3:53pm, Dileep Divekar wrote: > Subject: IBIS models under NDA > I am confused by the fact that the > semiconductor companies ask for NDA for providing > IBIS models. The whole purpose of IBIS is to make > it possible for the semiconductor companies to > provide models without disclosing proprietary > information. I can understand if they want people > to ask them for models instead of having the > models on the ibis reflector. But requiring NDA > for IBIS models defeats the purpose of IBIS. > Am I missing something here? > ------------------------------------------------------------ > Dileep Divekar > Contec CAE, Ltd. > 2188 Bering Drive > San Jose, CA 95131 > > Phone - (408)-434-6767 x 126 > Fax - (408)-434-6884 From Will_Hobbs@ccm2.jf.intel.com Tue Aug 22 17:57:48 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07360; Tue, 22 Aug 95 17:57:48 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sl41A-000UgBC; Tue, 22 Aug 95 17:50 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sl41A-000twoC; Tue, 22 Aug 95 17:50 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Tue, 22 Aug 95 17:50:08 PDT Date: Tue, 22 Aug 95 17:45:00 PDT From: Will Hobbs Message-Id: To: dileep%contec.contec.COM%contec@netcom.com, ibis@vhdl.org Cc: dileep@contec.contec.COM Subject: Re: IBIS models under NDA Text item: Dileep, The models we generally require an NDA for are products which are not yet formally announced. The P6 is a good example, as are new chipsets. All information on these components is tightly controlled, including specs, models, performance numbers, availability, etc. Such control is necessary for an effective launch of a new product. I/O models, being in essence executable specifications, fall under that umbrella. The purpose of even mentioning them in a public place like the vhdl.org machine is to inform people that the models exist and to point people in the right direction to obtain them. Another case where an NDA is desirable is in the case of early models of a component that haven't been validated, the I/O characteristics are subject to change, etc. In such cases, the IC vendors want to control distribution so that people don't design their products to the wrong spec. NDAs provide trackability. Regards, Will Hobbs Intel Corp. I am confused by the fact that the semiconductor companies ask for NDA for providing IBIS models. The whole purpose of IBIS is to make it possible for the semiconductor companies to provide models without disclosing proprietary information. I can understand if they want people to ask them for models instead of having the models on the ibis reflector. But requiring NDA for IBIS models defeats the purpose of IBIS. Am I missing something here? ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Length: 716 X-Sun-Charset: US-ASCII Cc: dileep@contec.contec.COM Subject: IBIS models under NDA To: ibis@vhdl.org Message-Id: <9508222253.AA16021@contec13.contec.COM> From: dileep@contec.contec.COM (Dileep Divekar) Date: Tue, 22 Aug 1995 15:53:12 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA16021; Tue, 22 Aug 1995 15:53:12 +0800 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA17083; Tue, 22 Aug 95 15:50:25 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA10811; Tue, 22 Aug 1995 15:53:33 -0700 Received: from netcomsv.netcom.com (uucp5.netcom.com) by vhdl.vhdl.org (4.1/SMI- 4.1/BARRNet) id AA06774; Tue, 22 Aug 95 16:19:31 PDT Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA14089; Tue, 22 Aug 95 17:04:27 PDT Received: from ssd.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 22 Aug 95 1 7:04:50 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sl3JO-000twtC; Tue, 22 Aug 95 17:04 PDT From uunet!qdt.com!fyuan@uunet.uu.net Tue Aug 22 20:44:46 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08256; Tue, 22 Aug 95 20:44:46 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzdza27080; Tue, 22 Aug 1995 23:36:13 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Tue, 22 Aug 1995 23:36:05 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01624; Tue, 22 Aug 95 20:08:06 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA14925; Tue, 22 Aug 95 20:08:06 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQzdyy24453; Tue, 22 Aug 1995 23:07:26 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 22 Aug 1995 23:07:27 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01595; Tue, 22 Aug 95 19:52:01 PDT Received: from p51.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA14887; Tue, 22 Aug 95 19:52:01 PDT Date: Tue, 22 Aug 95 19:52:01 PDT From: uunet!qdt.com!fyuan@uunet.uu.net (Frank Yuan) Message-Id: <9508230252.AA14887@hal.qdt.com> To: uunet!uunet!ccm2.jf.intel.com!Samie_Samaan@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!silab.Eng.Sun.COM!si-list@uunet.uu.net Subject: Re: Re[2]: GND Plane Bounce Question Cc: uunet!qdt.com!jonp@uunet.uu.net, uunet!qdt.com!fyuan@uunet.uu.net Samie, I agree with your assesment. Also, if you only care about the bounce during the first few 100 ps's of the transient around the via, I have the following numbers you might be interested. 2 - 3 inch away from the via, the bounces are about 1.0 mV, 1.5 mV and 2.0 mV at 100 ps, 200 ps, and 400 ps, respectively. 5 - 6 inch away from the via, they are 0.1 mV, 0.4 mV and 1.0 mV, respectively, and about 10 inch away, the bounce is less than 0.1 mV at 400 ps. (all assuming 10 mA current). I will also send you some information about our power/ground simulation tool later (the tool is still under development and has not been released jet). Regards, Frank > From uunet!ccm2.jf.intel.com!Samie_Samaan Tue Aug 22 09:16:17 1995 > Date: Tue, 22 Aug 95 08:43:00 PDT > From: Samie Samaan > To: uunet!vhdl.org!ibis, uunet!fyuan%qdt.com%uunet, > uunet!uunet!uunet!ccm2.jf.intel.com!Samie_Samaan > Cc: uunet!uunet!qdt.com!jonp, uunet!uunet!qdt.com!fyuan > Subject: Re[2]: GND Plane Bounce Question > Content-Length: 7935 > > > Text item: > > Frank, > > Thank you very much for taking the time to address this problem. In > fact I would like to know more about this tool, if you can send me > some info on it. My address is with Quad, and also at the bottom. The > numbers you give me are a big help. With a formula provided by someone > else, I will have a good idea of what to expect. > > > I would like to comment on this whole issue a bit, and address what > prompted my question in the first place:- > > Some of the colleagues who answered my inquiry, correctly indicated > that I should designate the source of the current and not just its > sink. So I answered one of them by saying the following: Assume that I > can magically inject the current into the GND plane thru the > via...etc. The reason I say that is because I was really interested in > local bounce, with the closest discontinuity to the GND plane being a > few inches away. Such a case arises when you are dealing with, say, > open collector buffers, where the collector is tied to a signal trace > on the top layer of my hypothetical board, while the emitter pumps the > GND plane thru the via. The source of the current has to tie back to > the plane at some distant point, but that is not very relevant (in my > opinion) during the first few 100 ps's of the transient around the > via. > > The real reason I asked the above question has not been stated by me > yet. Well, here it goes: If one is trying to measure Clk-out delay > (Tco) of a buffer using a scope, and places the scope ground near my > via, while placing the scope's active lead at the bit of interest, > then, I believe, that if many bits are switching, that the waveform > seen by the scope would be distorted by the GND plane bounce. Say you > have a falling edge (while many bits toggle down), then since the GND > bounces up, the scope would read a smaller voltage (its gnd lead is > moving up too), and show the edge to be just as fast as when a single > bit switches (or nearly so) even though the edge has --in reality-- > slowed down due to SSO. So one has to be more clever as to where to > measure Tco is such situations. > > Do others agree with my assesment ?? > > Sincerely, > > Samie Samaan > Intel > 2111 NE 25th Ave > Hillsboro, OR 97124. > > ______________________________ Reply Separator _________________________________ > Subject: Re: GND Plane Bounce Question > Author: fyuan%qdt.com%uunet@uunet.uu.net at SMTPGATE > Date: 8/21/95 6:31 PM > > > Hi, Samie, > > I did some quick and simple simulations for your GND plane bounce problem > using the power/ground plane simulation tool we have at Quad Design. > The PCB is same as yours, and the size is 10x10 inch. Assume the current > is 10 mA (instead of 10 Amps in your message), and there are no de-caps or > other loads between the power/ground plane, the local ground bound is about > 8 ~ 10 mV, assuming the current source has a 50 ohm internal resistance. > The ground noise propagates all over the plane, so the bounce away from the > via is lower but not too much than that at the vis. Depending on location, > the bounce is 2 ~ 6 mV. The location of the via also have some effects on > bounce, but is usually small. > > Note that if you really have a 10 Amps current, the bounce would be 8 ~ 10 > volts. That will be a truly unusual or extrame situation. > > The above results assuming the power/ground planes are open (or no other > terminations), This usually gives higher estimate of GND bounce because of > the resonance of the plane. From my experice, the things affect the ground > bounce mostly are your loads, especially decoupling capacitors. Proper > placement of de-caps of 10~100 nf can significantly reduce the GND bounce > in the above situation, by 5 ~ 10 times. Resistive loads have little > effects on the GND bounce unless it is really small ( about 0.1 ohm for > the above example). > > Our tool can do a much better job in extimating GND bounce if you have > more information about the geometry, the ternimation or load conditions, > and the source or device characteristics. Hope this is useful for you. > > Regards > > Frank Yuan > Quad Design Technology > (805) 988-8250 > > > > From uunet!ccm2.jf.intel.com!Samie_Samaan Mon Aug 21 13:11:20 1995 > > Date: Mon, 21 Aug 95 11:22:00 PDT > > From: Samie Samaan > > To: uunet!vhdl.org!ibis > > Subject: GND Plane Bounce Question > > Content-Length: 1709 > > > > > > Text item: Text_1 > > > > > > All IBISians (SI experts by Default !!) > > > > I would like to pose the following SI question, and solicit help from > > those who actually know the answer or have a very good idea of how to > > estimate it by scaling from previous experience: > > > > > > Assume one GND and one power plane in a PCB separated by say 10 mil, > > with a dielectric constant of say 4. assume that the power plane has a > > via opening where current is injected thru the via down to the GND > > plane. Let's say that the current is 10 Amps. with a riserime of 1 ns. > > Assume nominal via diameter. The drawing below shows the structure: > > > > > > | Vcc > > ---------------- | ------------------ > > | GND 10 mil, Er=4 > > -----------------|------------------- > > > > > > What I would like to hear from anybody who actually has experienced > > GND plane bounce, is: > > > > *howmuch do you expect the GND plane (not the via stem) to bounce up > > (locally) given the above assumptions, and > > > > *howfar away from the via (radially) do you expect the bounce to drop > > to 10% of the peak which occurs right where the via meets the plane ? > > > > I would apprciate a good guess (and Why: perhaps from previous > > experience), or direction as to "who ?" you think could answer such a > > question. I know that I might need to do a 3-D or radial transmission > > line analysis of the system, but I'm really just looking for a quick > > answer. > > > > > > Thanks for taking the time to read or answer this question. > > > > Samie Samaan > > Intel Corp. > > From huq@rockie.nsc.com Tue Aug 22 21:34:58 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08566; Tue, 22 Aug 95 21:34:58 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA28634 for ibis@vhdl.org; Tue, 22 Aug 95 21:28:10 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA29465 for ibis@vhdl.org; Tue, 22 Aug 95 21:28:05 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA06463; Tue, 22 Aug 95 21:30:42 PDT Date: Tue, 22 Aug 95 21:30:42 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9508230430.AA06463@rockie.nsc.com> To: ibis@vhdl.org, dileep@contec.contec.COM Subject: Re: IBIS models under NDA Majority of all models are available for FREE as products are already released to the public. Only a few are under NDA and those are mainly products under development. I am sure models for FREE or under NDA is better than 'No models available'. Regards, Syed National Semiconductor From Arpad_Muranyi@ccm.fm.intel.com Wed Aug 23 08:41:16 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16485; Wed, 23 Aug 95 08:41:16 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0slHnf-000UfaC; Wed, 23 Aug 95 08:33 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0slHnf-000txoC; Wed, 23 Aug 95 08:33 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 23 Aug 95 08:33:07 PDT Date: Wed, 23 Aug 95 08:29:00 PDT From: Arpad Muranyi Message-Id: To: dla@pyramid.com, dileep@contec.contec.COM, ibis@vhdl.org Subject: Re[2]: IBIS models under NDA Text item: This must be a really bad joke... Arpad =============================================================================== Hello! IBIS is at best in it's infancy, at worst a joke. The NDA issue can be viewed as proof either way. A list could be started with similar "facts". In my opinion, IBIS is not yet usefull for much of anything, but it has potential. Thank you Don Abernathey Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: IBIS models under NDA To: dileep@contec.contec.COM (Dileep Divekar), ibis@vhdl.org X-Mailer: Z-Mail (2.1.2 11jan93) References: <9508222253.AA16021@contec13.contec.COM> In-Reply-To: dileep@contec.contec.COM (Dileep Divekar) "IBIS models under NDA" (Aug 22, 3:53pm) Date: Tue, 22 Aug 1995 16:43:30 -0700 Message-Id: <9508221643.ZM12241@pyrnoevil.or.pyramid.com> From: dla@pyramid.com (Don Abernathey) Received: by pyrnoevil.or.pyramid.com (5.61/OSx5.1) id AA12243; Tue, 22 Aug 95 16:43:31 -0700 Received: from pyrnoevil.or.pyramid.com by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway) id AA07873; Tue, 22 Aug 95 23:43:32 GMT Received: from bertha.pyramid.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06976; Tue, 22 Aug 95 16:50:18 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 22 Aug 95 16 :46:11 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sl6X5-000tx8C; Tue, 22 Aug 95 20:31 PDT From Samie_Samaan@ccm2.jf.intel.com Wed Aug 23 08:54:57 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16579; Wed, 23 Aug 95 08:54:57 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0slI1U-000UgeC; Wed, 23 Aug 95 08:47 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0slI1T-000txuC; Wed, 23 Aug 95 08:47 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Wed, 23 Aug 95 08:47:23 PDT Date: Wed, 23 Aug 95 08:43:00 PDT From: Samie Samaan Message-Id: To: dileep%contec.contec.COM%contec@netcom.com, ibis@vhdl.org Cc: dileep@contec.contec.COM Subject: Re: IBIS models under NDA Text item: Dileep, Though IBIS protects circuit topologies, some companies may still want to protect their driver strength and package model data, at least during development and prior to public product launch, while still being able to interact with a few other firms. This would be done in order not to prime the competition on what the next technological step is toward meeting some bus frequency or signal integrity goal. The second reason is that some people/companies do, and will, make a living making driver models and selling libraries. To them IBIS is just a format or language, and they need to protect their product like any other SW company. Sincerely, Samie Samaan Intel Corp. ______________________________ Reply Separator _________________________________ Subject: IBIS models under NDA Author: dileep%contec.contec.COM%contec@netcom.com at SMTPGATE Date: 8/22/95 3:53 PM I am confused by the fact that the semiconductor companies ask for NDA for providing IBIS models. The whole purpose of IBIS is to make it possible for the semiconductor companies to provide models without disclosing proprietary information. I can understand if they want people to ask them for models instead of having the models on the ibis reflector. But requiring NDA for IBIS models defeats the purpose of IBIS. Am I missing something here? ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Length: 716 X-Sun-Charset: US-ASCII Cc: dileep@contec.contec.COM Subject: IBIS models under NDA To: ibis@vhdl.org Message-Id: <9508222253.AA16021@contec13.contec.COM> From: dileep@contec.contec.COM (Dileep Divekar) Date: Tue, 22 Aug 1995 15:53:12 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA16021; Tue, 22 Aug 1995 15:53:12 +0800 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA17083; Tue, 22 Aug 95 15:50:25 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA10811; Tue, 22 Aug 1995 15:53:33 -0700 Received: from netcomsv.netcom.com (uucp5.netcom.com) by vhdl.vhdl.org (4.1/SMI- 4.1/BARRNet) id AA06774; Tue, 22 Aug 95 16:19:31 PDT Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA14089; Tue, 22 Aug 95 17:04:27 PDT Received: from ssd.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 22 Aug 95 1 7:04:50 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sl3JO-000twtC; Tue, 22 Aug 95 17:04 PDT From Arpad_Muranyi@ccm.fm.intel.com Wed Aug 23 10:29:07 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17154; Wed, 23 Aug 95 10:29:07 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0slJVI-000Ui6C; Wed, 23 Aug 95 10:22 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0slJVH-000txPC; Wed, 23 Aug 95 10:22 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Wed, 23 Aug 95 10:22:15 PDT Date: Wed, 23 Aug 95 10:14:00 PDT From: Arpad Muranyi Message-Id: To: sung.oh@tempe.vlsi.com, Samie_Samaan@ccm2.jf.intel.com Cc: ibis@vhdl.org Subject: Re[4]: GND Plane Bounce Question Text item: Sung, I have a hard time to believe that an active probe with a few tenths of pF will have an effect like that. On the other hand, the GND lead of the probe might give an extra path to the GND currents, which might reduce the bounce some. Arpad =============================================================================== Samie, I agree. However, it is not a matter of where you measure. As soon as your prober touches the bit of interest, SSO noise will be reduced because of the current through the prober capacitor to the ground plane. In that case, true Tco will be in question. Regards, Sung Oh VLSI Technology, Inc. >>From Samie_Samaan@ccm2.jf.intel.com Tue Aug 22 09:11 MST 1995 >>Date: Tue, 22 Aug 95 08:43:00 PDT >>From: Samie Samaan >>To: ibis@vhdl.org, fyuan%qdt.com%uunet@uunet.uu.net, >> uunet!uunet!ccm2.jf.intel.com!Samie_Samaan@uunet.uu.net >>Cc: uunet!qdt.com!jonp@uunet.uu.net, uunet!qdt.com!fyuan@uunet.uu.net >>Subject: Re[2]: GND Plane Bounce Question >>Content-Type >>: >>text >> >>Content-Length: 7935 >>X-Lines: 181 >> >> >>Text item: >> >> Frank, >> >> Thank you very much for taking the time to address this problem. In >> fact I would like to know more about this tool, if you can send me >> some info on it. My address is with Quad, and also at the bottom. The >> numbers you give me are a big help. With a formula provided by someone >> else, I will have a good idea of what to expect. >> >> >> I would like to comment on this whole issue a bit, and address what >> prompted my question in the first place:- >> >> Some of the colleagues who answered my inquiry, correctly indicated >> that I should designate the source of the current and not just its >> sink. So I answered one of them by saying the following: Assume that I >> can magically inject the current into the GND plane thru the >> via...etc. The reason I say that is because I was really interested in >> local bounce, with the closest discontinuity to the GND plane being a >> few inches away. Such a case arises when you are dealing with, say, >> open collector buffers, where the collector is tied to a signal trace >> on the top layer of my hypothetical board, while the emitter pumps the >> GND plane thru the via. The source of the current has to tie back to >> the plane at some distant point, but that is not very relevant (in my >> opinion) during the first few 100 ps's of the transient around the >> via. >> >> The real reason I asked the above question has not been stated by me >> yet. Well, here it goes: If one is trying to measure Clk-out delay >> (Tco) of a buffer using a scope, and places the scope ground near my >> via, while placing the scope's active lead at the bit of interest, >> then, I believe, that if many bits are switching, that the waveform >> seen by the scope would be distorted by the GND plane bounce. Say you >> have a falling edge (while many bits toggle down), then since the GND >> bounces up, the scope would read a smaller voltage (its gnd lead is >> moving up too), and show the edge to be just as fast as when a single >> bit switches (or nearly so) even though the edge has --in reality-- >> slowed down due to SSO. So one has to be more clever as to where to >> measure Tco is such situations. >> >> Do others agree with my assesment ?? >> >> Sincerely, >> >> Samie Samaan >> Intel >> 2111 NE 25th Ave >> Hillsboro, OR 97124. 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: ibis@vhdl.org Subject: Re: Re[2]: GND Plane Bounce Question To: Samie_Samaan@ccm2.jf.intel.com Message-Id: <9508222043.AA16981@sedona> Date: Tue, 22 Aug 95 13:43:59 MST Received: by sedona id AA16981; Tue, 22 Aug 95 13:43:59 MST Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vl si.com (8.6.9/Hub-Perlotto/032095) with SMTP id NAA28163; Tue, 22 Aug 1995 13:42 :12 -0700 Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by re layhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id NAA09271; Tue, 22 Aug 1995 13:44:03 -0700 From: sung.oh@tempe.vlsi.com Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8 .6.12/Hub-Perlotto/050895) with ESMTP id NAA01104; Tue, 22 Aug 1995 13:45:09 -07 00 Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4. 1/BARRNet) id AA05835; Tue, 22 Aug 95 13:44:18 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 22 Aug 95 13 :43:30 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sl4jG-000twwC; Tue, 22 Aug 95 18:35 PDT From sung.oh@tempe.vlsi.com Wed Aug 23 10:52:45 1995 Return-Path: Received: from relayhost.vlsi.com ([134.27.20.23]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17306; Wed, 23 Aug 95 10:52:45 PDT Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id KAA22911; Wed, 23 Aug 1995 10:52:17 -0700 From: sung.oh@tempe.vlsi.com Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id KAA13740; Wed, 23 Aug 1995 10:51:03 -0700 Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id KAA03037; Wed, 23 Aug 1995 10:49:13 -0700 Received: by sedona id AA17953; Wed, 23 Aug 95 10:51:00 MST Date: Wed, 23 Aug 95 10:51:00 MST Message-Id: <9508231751.AA17953@sedona> To: Arpad_Muranyi@ccm.fm.intel.com Subject: Re: Re[4]: GND Plane Bounce Question Cc: ibis@vhdl.org Arpad, Actually, it depends on the parasitic inductance and capacitance between the driver ground and ground plane. Not only the maximum magnitude of the ground bounce but also the pulse duration is dependent on the parasitics. However, if you are using an active probe and the capacitance is small compared to the parasitic capacitance, the probing effect can be safely ignored. Sung >>From Arpad_Muranyi@ccm.fm.intel.com Wed Aug 23 10:27 MST 1995 >>Date: Wed, 23 Aug 95 10:14:00 PDT >>From: Arpad Muranyi >>To: sung.oh@tempe.vlsi.com, Samie_Samaan@ccm2.jf.intel.com >>cc: ibis@vhdl.org >>Subject: Re[4]: GND Plane Bounce Question >>Content-Type >>: >>text >> >>Content-Length: 4987 >>X-Lines: 116 >> >> >>Text item: >> >>Sung, >> >>I have a hard time to believe that an active probe with a few tenths of pF will >>have an effect like that. On the other hand, the GND lead of the probe might >>give an extra path to the GND currents, which might reduce the bounce some. >> >>Arpad >>=============================================================================== >> >>Samie, >> >>I agree. However, it is not a matter of where you measure. >>As soon as your prober touches the bit of interest, SSO noise will >>be reduced because of the current through the prober capacitor >>to the ground plane. In that case, true Tco will be in question. >> >>Regards, >> >>Sung Oh >>VLSI Technology, Inc. >> >> >>From Samie_Samaan@ccm2.jf.intel.com Tue Aug 22 09:11 MST 1995 >> >>Date: Tue, 22 Aug 95 08:43:00 PDT >> >>From: Samie Samaan >> >>To: ibis@vhdl.org, fyuan%qdt.com%uunet@uunet.uu.net, >> >> uunet!uunet!ccm2.jf.intel.com!Samie_Samaan@uunet.uu.net >> >>Cc: uunet!qdt.com!jonp@uunet.uu.net, uunet!qdt.com!fyuan@uunet.uu.net >> >>Subject: Re[2]: GND Plane Bounce Question >> >>Content-Type >>: >>text >> >> >>Content-Length: 7935 >> >>X-Lines: 181 >> >> >> >> >> >>Text item: >> >> >> >> Frank, >> >> >> >> Thank you very much for taking the time to address this problem. In >> >> fact I would like to know more about this tool, if you can send me >> >> some info on it. My address is with Quad, and also at the bottom. The >> >> numbers you give me are a big help. With a formula provided by someone >> >> else, I will have a good idea of what to expect. >> >> >> >> >> >> I would like to comment on this whole issue a bit, and address what >> >> prompted my question in the first place:- >> >> >> >> Some of the colleagues who answered my inquiry, correctly indicated >> >> that I should designate the source of the current and not just its >> >> sink. So I answered one of them by saying the following: Assume that I >> >> can magically inject the current into the GND plane thru the >> >> via...etc. The reason I say that is because I was really interested in >> >> local bounce, with the closest discontinuity to the GND plane being a >> >> few inches away. Such a case arises when you are dealing with, say, >> >> open collector buffers, where the collector is tied to a signal trace >> >> on the top layer of my hypothetical board, while the emitter pumps the >> >> GND plane thru the via. The source of the current has to tie back to >> >> the plane at some distant point, but that is not very relevant (in my >> >> opinion) during the first few 100 ps's of the transient around the >> >> via. >> >> >> >> The real reason I asked the above question has not been stated by me >> >> yet. Well, here it goes: If one is trying to measure Clk-out delay >> >> (Tco) of a buffer using a scope, and places the scope ground near my >> >> via, while placing the scope's active lead at the bit of interest, >> >> then, I believe, that if many bits are switching, that the waveform >> >> seen by the scope would be distorted by the GND plane bounce. Say you >> >> have a falling edge (while many bits toggle down), then since the GND >> >> bounces up, the scope would read a smaller voltage (its gnd lead is >> >> moving up too), and show the edge to be just as fast as when a single >> >> bit switches (or nearly so) even though the edge has --in reality-- >> >> slowed down due to SSO. So one has to be more clever as to where to >> >> measure Tco is such situations. >> >> >> >> Do others agree with my assesment ?? >> >> >> >> Sincerely, >> >> >> >> Samie Samaan >> >> Intel >> >> 2111 NE 25th Ave >> >> Hillsboro, OR 97124. >> >>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: ibis@vhdl.org >>Subject: Re: Re[2]: GND Plane Bounce Question >>To: Samie_Samaan@ccm2.jf.intel.com >>Message-Id: <9508222043.AA16981@sedona> >>Date: Tue, 22 Aug 95 13:43:59 MST >>Received: by sedona id AA16981; Tue, 22 Aug 95 13:43:59 MST >>Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vl >>si.com (8.6.9/Hub-Perlotto/032095) with SMTP id NAA28163; Tue, 22 Aug 1995 13:42 >>:12 -0700 >>Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by re >>layhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id NAA09271; Tue, >>22 Aug 1995 13:44:03 -0700 >>From: sung.oh@tempe.vlsi.com >>Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8 >>.6.12/Hub-Perlotto/050895) with ESMTP id NAA01104; Tue, 22 Aug 1995 13:45:09 -07 >>00 >>Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4. >>1/BARRNet) >> id AA05835; Tue, 22 Aug 95 13:44:18 PDT >>Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 22 Aug 95 13 >>:43:30 -0700 >>Received: from hermes.intel.com by relay.jf.intel.com with smtp >> (Smail3.1.28.1 #2) id m0sl4jG-000twwC; Tue, 22 Aug 95 18:35 PDT >> From dla@pyramid.com Wed Aug 23 13:10:37 1995 Return-Path: Received: from gossip.pyramid.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18182; Wed, 23 Aug 95 13:10:37 PDT Received: from pyrnoevil.or.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA01346; Wed, 23 Aug 95 13:03:47 -0700 Received: by pyrnoevil.or.pyramid.com (5.61/OSx5.1) id AA06477; Wed, 23 Aug 95 11:05:09 -0700 From: dla@pyramid.com (Don Abernathey) Message-Id: <9508231105.ZM6475@pyrnoevil.or.pyramid.com> Date: Wed, 23 Aug 1995 11:05:08 -0700 In-Reply-To: Will Hobbs "Re[2]: IBIS models under NDA" (Aug 22, 5:57pm) References: X-Mailer: Z-Mail (2.1.2 11jan93) To: ibis@vhdl.org Subject: Re: Re[2]: IBIS models under NDA Cc: dla@pyrnoevil.or.pyramid.com Hello! I appologize for the following inflamatory note I blurted out to the group. I am not in the business of flame-baiting, but I can see that the note sure looks like bait. There is some rationale behind those very blunt statements. Please feel free to contact me directly for a discussion, which I won't post to the group reflector. Again sorry, Don Abernathey dla@pyramid.com > > Hello! > > IBIS is at best in it's infancy, at worst a joke. > > The NDA issue can be viewed as proof either way. > > A list could be started with similar "facts". > > In my opinion, IBIS is not yet usefull for much of anything, but it has > potential. > > Thank you > Don Abernathey From speters@ichips.intel.com Wed Aug 23 13:41:01 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18393; Wed, 23 Aug 95 13:41:01 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 23 Aug 95 13:34:13 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 22 Aug 95 11:16:43 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 22 Aug 95 11:16:43 PDT Message-Id: <9508221816.AA15114@xtg801.intel.com> To: ibis@vhdl.org Subject: Bird 30 / Model selection Date: Tue, 22 Aug 1995 11:16:42 -0700 From: Stephen Peters Hello All: I've been following the exchange between Malan and Arpad regarding the "alternate model selection" process and I have an observation. With the [Model Selection] keyword (and the enhnacments suggested by Malan) the focus is on manipulating a pre-determined group of buffers AS A GROUP. As bird 30 states: "The operation of this selection mechanism implies that a group of pins which use the same programmable buffer (i.e. model selector name) will be switched together from one [Model] to another." It seems that the intent is for the simulation tool to provide a diaglog box that says "for buffer group XYZ pick buffer A, B or C". This is OK if all one wants to do is set the buffer type for each group of pins, but suppose one wants to overide the default selection on a pin by pin basis? I am thinking about FPGA's, complex PLD's, etc. where all the I/O pins have the same buffer choices, but the individual pins are not put into functional 'groups' until the chips is designed. The user is most likly going to select a default, then override this default as needed -- pin by pin. We should keep this usage model in mind as we debate this Bird. Also, regarding model and model selector names....as you can see from the dialog box example above, it greatly behoves the model maker to pick intellagable names. I would hate to see a question like "For buffer group 'Progbuffer1' pick buffer ABCD123456789ABCDE0, ABCD123456789ABCDE2, ABCD123456789ABCDE3 or ABCD123456789ABCDE4". I don't quite know how one enforces something like 'good nameing' in a specification, but at least we can make clear to the model maker how the information may be used. Regards, Stephen Peters Intel Corp. From speters@ichips.intel.com Thu Aug 24 09:20:31 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00267; Thu, 24 Aug 95 09:20:31 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 24 Aug 95 09:13:44 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 24 Aug 95 09:13:39 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 24 Aug 95 09:13:38 PDT Message-Id: <9508241613.AA05660@xtg801.intel.com> To: ibis@vhdl.org Cc: dileep@contec.contec.COM Subject: Re: Bird 28.2 - Comments and Suggestions Date: Thu, 24 Aug 1995 09:13:37 -0700 From: Stephen Peters Hello Dileep: Thanks for taking the time to review the Bird and offor your comments and suggestions. My answers are below, prefixed by >>>. Best regards, Stephen Peters Intel Corp. ----------------- On Tue, 22 Aug, Dileep Divekar at Contec wrote Editorial Comment: The character used to separate the section information is a slash (/) and not a backslash (\) as mentioned. >>> Will fix Comment: It would be helpful to clarify if ALL of L/R/C have to be specified. That is, is any of the following allowed? /Len=1.3 L=1.3n/ /Len=2.5 L=3n C=0 R=0/ >>> Paragraph three of the usage rules states >>> the following: "Specifying a length or L/R/C value >>> of zero is allowed." Paragraph C) under Legal >>> Subparameter Combinations does say the 'any combination' >>> of L, R and C are allowed, but I will clarify the >>> statement to indicate that all three are not required >>> to be specified. Suggestion: I think the off diagonal entries in the C matrix should be specified as negative numbers, if they are indeed negative, as they are in this case, instead of making them positive. >>> When I looked at the acadimic and technical >>> papers on the subject (not to mention the software >>> we use in house) the off-diagonal elements are >>> always positive quanities. For what ever reason >>> this seems to be the convention and I don't see a need >>> to do it differently. Suggestion: For the sake of completeness and generality, the specification should allow an optional G specification which is a conductance in parallel with C, similar to R in series with L. >>> Good point. I did not include a 'G' parameter >>> because the current IBIS 2.1 Matrix descriptions >>> do not include one and I was trying to limit the >>> scope of the bird. If the committe did want >>> to add the a conductance parameter it could be >>> in a seperate proposal. >>> ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From contec!contec.contec.COM!dileep@netcom.com Thu Aug 24 12:56:40 1995 Return-Path: Received: from netcomsv.netcom.com (uucp12.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01790; Thu, 24 Aug 95 12:56:40 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA00653; Thu, 24 Aug 1995 12:30:29 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA04383; Thu, 24 Aug 95 11:44:14 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA22471; Thu, 24 Aug 1995 11:46:59 +0800 Date: Thu, 24 Aug 1995 11:46:59 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9508241846.AA22471@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Bird 28.2 - Comments and Suggestions Cc: dileep@contec.contec.COM, speters@ichips.intel.com X-Sun-Charset: US-ASCII Content-Length: 1925 My response to Stephen Peter's comments: >>> When I looked at the acadimic and technical >>> papers on the subject (not to mention the software >>> we use in house) the off-diagonal elements are >>> always positive quanities. For what ever reason >>> this seems to be the convention and I don't see a need >>> to do it differently. There is no standard convention. I can give many references published in technical journals, in which off-diagonal elements of the C matrix are given as negative numbers. Following are few examples: Colin Gordon, Thomas Blazeck and Raj Mittra, "Time-Domain Simulation of Multiconductor Transmission Lines with Frequency-Dependent Losses", pp. 1372-1387, IEEE Trans. on Computer-Aided Design, Vol. 11, No. 11, November 1992. Tak Tang, Michel Nakhla and Richard Griffith, "Analysis of Lossy Multiconductor Lines using the Asymptotic Waveform Evaluation Technique", IEEE Trans. of Microwave Theory and Techniques, pp. 2107-2116, Vol. 39, No. 12, December 1991. A.J.Gruodis and C.S.Chang, "Coupled Lossy Transmission Line Characterization and Simulation", IBM Journal of Res. Develop., pp. 25-41, Vol. 25, No. 1, January 1981. In my opinion, why hide the fact that they are negative ? Why not just specify them as they are ? >>> Good point. I did not include a 'G' parameter >>> because the current IBIS 2.1 Matrix descriptions >>> do not include one and I was trying to limit the >>> scope of the bird. If the committe did want >>> to add the a conductance parameter it could be >>> in a seperate proposal. >>> Why add more delay and more paperwork ? ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From mbs@eos.ncsu.edu Thu Aug 24 19:11:07 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04091; Thu, 24 Aug 95 19:11:07 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA17842; Thu, 24 Aug 1995 22:04:21 -0400 From: mbs@eos.ncsu.edu Message-Id: <9508250204.AA17842@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS v2.0 delay Date: Thu, 24 Aug 95 22:04:21 EDT The beta release of S2IBISv2.0 will be delayed. It works but there is a memory leakage problem that we must resolve before we can release it. The s2ibis directory structure on vhdl.org has been changed anticipating the new release. The version of s2ibis has not been changed. One part of the system is being released. This is a IBIS v2.1 plotting utility. It can be found in vhdl.org::/pub/ibis/s2ibis/s2ibis_plot_v1.0 (This will become part of the distribution for s2ibisv2.0) At the end of this message is the readme file for this utility S2IBIS team North Carolina Sate University Steve Lipa Alan Glaser Michael Steer Paul Franzon #s2iplt v1.0 Steven Lipa, North Carolina State Univ. 8/24/95 # # Usage: s2iplt filename # # s2iplt reads through an IBIS v2.1 or lower model file, # calling gnuplot to plot out each [Pullup], [Pulldown], # [Power_Clamp], [GND_Clamp], [Rising_Waveform], and # [Falling_Waveform] table that it comes across. Each # table is labeled with the [Model] name and table name. # Once a table has been plotted, s2iplt waits until a # carriage return has been entered to go on to the next # table. # # s2iplt is a perl script. If your perl executable is not # in /usr/local/bin/perl you will need to modify s2iplt # slightly to point to the right place. If you don't have # perl you can get it for free from several archive sites, # such as # http://www1.cis.ufl.edu/perl/ # # The gnuplot executable simply has to be somewhere in # your path. If you don't have gnuplot you can get it for # free from Dartmouth at # # http://www.cs.dartmouth.edu/gnuplot_info.html # From bob@icx.com Fri Aug 25 17:09:09 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16197; Fri, 25 Aug 95 17:09:09 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 25 Aug 95 17:02 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 25 Aug 95 17:04 PDT Message-Id: Date: Fri, 25 Aug 95 17:04 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: SECOND ROLLUP OF IBIS VERSION 2.1 To IBIS members: This document shows the changes through August 25, 1995 that are intended to be included in EIA-656. The final version will have the change bar comments designated by "1*" lines removed. Bob Ross, Interconnectix, Inc. |***************************************************************************** |* THIS DOCUMENT IS AN UPDATE BASED ON EIA COMMENTS FROM UNIVERSITY OF |* MANCHESTER, INTERCONNECTIX, INC. AND BIRD29.2 (FROM THE IBIS COMMITTEE). |* |* CHANGES PER THE INTEGRATED DEVICE TECHNOLOGY, INC. COMMENTS REPSPONSE |* OF AUGUST 25, 1995 ARE INCLUDED. |* |* EDITORIAL CHANGES PER THE AUGUST 25, 1995 IBIS OPEN FORUM MEETING ARE |* INCLUDED. |* |* CHANGES BASED ON BIRD25.3 AND BIRD26, WHICH WERE INCLUDED IN THE LETTER |* BALLOT COPY ARE INCLUDED, BUT NOT SHOWN. |* |* |* CHANGES ARE DESIGNATED BY |* LINES. |***************************************************************************** |============================================================================== |* I/O Buffer Information Specification (IBIS) Version 2.1 (August 22, 1995) | | IBIS is a standard for electronic behavioral specifications of integrated | circuit input/output analog characteristics. |============================================================================== | Statement of Intent: | | In order to enable an industry standard method to electronically transport | IBIS Modeling Data between silicon vendors, simulation software vendors, and | end customers, this template is proposed. The intention of this template is | to specify a consistent format that can be parsed by software, allowing each | simulation vendor to derive models compatible with their own product. | | One goal of this template is to represent the current state of IBIS data, | while allowing a growth path to more complex models / methods (when deemed | appropriate). This would be accomplished by a revision of the base | template, and possibly the addition of new keywords or categories. | | Another goal of this template is to ensure that it is simple enough for | silicon vendors and customers to use and modify, while ensuring that it is | rigid enough for software simulation vendors to write reliable parsers. | | Finally, this template is meant to contain a complete description of the I/O | elements on an entire component. Consequently, several models will need to | be defined in each file, as well as a table that equates the appropriate | buffer to the correct pin and signal name. | | Version 2.0 of this electronic template was finalized by an industry-wide | group of simulation experts representing various companies and interests. | "IBIS Open Forum" meetings were held biweekly to accomplish this task. | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | ASCII file format. It represents the minimum amount of I/O buffer | information required to create an accurate IBIS model of common CMOS and | bipolar I/O structures. Future revisions of the ASCII file will add items | considered to be "enhancements" to Version 1.0 to allow accurate modeling | of new, or other, I/O buffer structures. Consequently, all future |* revisions will be considered supersets of Version 1.0, allowing backward | compatibility. In addition, as modeling platforms develop support for | revisions of the IBIS ASCII template, all previous revisions of the | template must also be supported. | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as | the 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | comments have been added for further clarification. | | Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility | with Versions 1.0 and 1.1. All new keywords and elements added in Version | 2.0 are optional. A complete list of changes to the specification is in the | IBIS Version 2.0 Release Notes document ("ver2_0.rn"). | | Version 2.1 update. The file "ver2_1.ibs" contains clarification text | changes, corrections, and two additional waveform parameters beyond | Version 2.0. | |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. File names must be all lower case. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved model name, used with power supply pins, | GND - reserved model name, used with ground pins, | NC - reserved model name, used with no-connect pins, | NA - used where data not available. | | 3) File names used in the file must only have lower case characters to | enhance UNIX compatibility and must conform to DOS rules. (The length of | a file name should not exceed eight plus three characters and it must | not contain special characters which are illegal in DOS). | | 4) The file must have no more than 80 characters per line. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment char] to any other character. The [Comment char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. | | 7) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in sub-parameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, Henries, and Seconds.) | The parser looks at only one alphabetic character after a numerical | entry, therefore it is enough to use only the prefixes to scale the | parameters. However, for clarity, it is allowed to use full | abbreviations for the units. (e.g., pF, nH, mA, mOhm). In addition, | scientific notation IS allowed (e.g., 1.2345e-12). | | 9) The V/I data tables should use enough data points around sharply curved | areas of the V/I curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. | | 10) The usage of TAB characters is legal, but they should be avoided as far | as possible. This is to eliminate possible complications which might | arise in situations when TAB characters are automatically converted to | multiple spaces by text editing, file transfering and similar software. | In cases like that, lines might become longer than 80 characters which | is illegal in IBIS files. | | 11) Currents are considered positive when their direction is into the | component. | | 12) All temperatures are represented in degrees Celsius. | |* 13) Important supplemental information is contained in the last section, | "NOTES ON DATA DERIVATION METHOD", concerning how data values are | derived. | |============================================================================== | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | present in the file. | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | normally on the first line of the file, but can be preceded | by comment lines that must begin with a "|". |------------------------------------------------------------------------------ [IBIS Ver] 2.1 | Used for template variations | |============================================================================== | Keyword: [Comment char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character to be defined must be followed by | the underscore character and the letters "char". For example: | "|_char" redundantly redefines the comment character to be | the pipe character. The new comment character is in effect | only following the [Comment char] keyword. The following |* characters CANNOT be used: A B C D E F G H I J K L M N O P | Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u | v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = + - | Other Notes: The [Comment char] keyword can be used throughout the file, as | desired. |------------------------------------------------------------------------------ [Comment char] |_char | |============================================================================== | Keyword: [File name] | Required: Yes | Description: Specifies the name of the IBIS file, "filename.ibs". | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | and no characters that are illegal in DOS). In addition, it | must be all lower case, and use the extension ".ibs". |------------------------------------------------------------------------------ [File name] ver2_1.ibs | |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is set at the discretion of the engineer | defining the file. The following guidelines are recommended: | 0.x silicon and file in development | 1.x pre-silicon file data from silicon model only | 2.x file correlated to actual silicon measurements | 3.x mature product, no more changes likely |------------------------------------------------------------------------------ [File Rev] 1.0 | Used for .ibs file variations | |============================================================================== | Keywords: [Date] [Source] [Notes] [Disclaimer] [Copyright] | Required: No | Description: Optionally clarifies the file. |* Usage Rules: The keyword arguments can contain blanks, and be of | any format. The [Date] keyword argument is limited to a |* maximum of 40 characters, and the month should be spelled |* out for clarity. | | Because IBIS model writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools should make this information | available. Derivative models should include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative models verbatim. |------------------------------------------------------------------------------ |* The date has been changed below: [Date] August 22, 1995 | The latest file revision date | [Source] Put originator and the source of information here. For example: From silicon level SPICE model at Intel. From lab measurement at IEI. Compiled from manufacturer's data book at Quad Design, etc... | [Notes] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | [Copyright] Copyright 1994, XYZ Corp., All Rights Reserved | |============================================================================== | Keyword: [Component] | Required: Yes | Description: Marks the beginning of the IBIS description of the integrated | circuit named after the keyword. | Usage Rules: If the .ibs file contains data for more than one component, | each section must begin with a new [Component] keyword. The | length of the Component Name must not exceed 40 characters, | and blank characters are allowed. | | NOTE: Blank characters are not recommended due to usability | issues. |------------------------------------------------------------------------------ [Component] 7403398 MC452 | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Clarifies the component's manufacturer. | Usage Rules: The length of the Manufacturer's Name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |------------------------------------------------------------------------------ [Manufacturer] Intel Corp. | |============================================================================== | Keyword: [Package] | Required: Yes | Description: Defines a range of values for the default packaging resistance, | inductance, and capacitance of the component pins. | Sub-Params: R_pkg, L_pkg, C_pkg | Usage Rules: The typical (typ) column must be specified. If data for the | other columns are not available, they must be noted with "NA". | Other Notes: If RLC parameters are available for individual pins, they can | be listed in columns 4-6 under keyword [Pin]. The values | listed in the [Pin] description section override the default | values defined here. Use the [Package Model] keyword for more | complex package descriptions. If defined, the [Package Model] | data overrides the values in the [Package] keyword. | Regardless, the data listed under the [Package] keyword must | still contain valid data. |------------------------------------------------------------------------------ [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF | |============================================================================== | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pins and signal names. | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, associates the I/O model for that | pin. Each model_name must have a [Model] keyword below, | unless it is a reserved model name (POWER, GND, or NC). | | Each line must contain either three or six columns. A pin | line with three columns only associates the pin's signal and | model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin | must be listed. If "NA" is in columns 4 through 6, the | default packaging values must be used. | | Column length limits are: | [Pin] 5 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |------------------------------------------------------------------------------ [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF | |============================================================================== | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model | Usage Rules: The package model name is limited to 40 characters. | Spaces are allowed in the name. The name should include the | company name or initials to help ensure uniqueness. The | simulator will search for a matching package model name as an | argument to a [Define Package Model] keyword in the current | IBIS file first. If a match is not found, the simulator will | look for a match in an external .pkg file. If the package | model is in a separate .pkg file, it must be kept in the same | directory as the .ibs file. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that part. | The specification permits .ibs files to contain [Define | Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models | that have the same name. |------------------------------------------------------------------------------ [Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Pin Mapping] | Required: No |Description: Used to indicate which power and ground buses a given driver, |* receiver, or terminator is connected to. | Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref |Usage Rules: Each power and ground bus is given a unique name which must | not exceed 15 characters. The first column contains a pin | number. Each pin number must match one of the pin numbers | declared previously in the [Pin] section of the IBIS file. | The second column, pulldown_ref, designates the ground bus | connections for that pin. Here the term ground bus can | also mean another power bus. The third column pullup_ref |* designates the power bus connection. The fourth and fifth | columns gnd_clamp_ref and power_clamp_ref contain | entries, if needed, to specify different ground bus | and power bus connections than those previously specified. | | If the [Pin Mapping] keyword is present, then the bus | connections for EVERY pin listed in the [Pin] section must | be given. | | Each line must contain either three or five columns. Use the | NC reserved word for entries that are not needed or that follow | the conditions below: | | All entries with identical labels are assumed to be connected. | Each unique entry label must connect to at least one pin whose | model_name is POWER or GND. | | If a pin has no connection, then both the pulldown_ref | and pullup_ref sub-parameters for it will be NC. | | GND and POWER pin entries and buses are designated by | entries in either the pulldown_ref or pullup_ref columns. | There is no implied association to any column other than | through explicit designations in other pins. | | For any other type of pin, the pulldown_ref column contains | the power connection for the [Pulldown] table for non-ECL type | [Models]. This is also the power connection for the [GND Clamp] | table and the [Rgnd] model unless overridden by a specification | in the gnd_clamp_ref column. | | Also, the pullup_ref column contains the power connection | for the [Pullup] table and, for ECL type models, the [Pulldown] | table. This is also the power connection for the [POWER Clamp] | table and the [Rpower] model unless overridden by a | specification in the power_clamp_ref column. | | The column length limits are: | [Pin Mapping] 5 characters max | pulldown_ref 15 characters max | pullup_ref 15 characters max | gnd_clamp_ref 15 characters max | power_clamp_ref 15 characters max | | When 5 columns are specified, the headings gnd_clamp_ref and | power_clamp_ref must be used. Otherwise, these headings can | be omitted. |--------------------------------------------------------------------------- [Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref | 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP 5 GNDBUS2 PWRBUS2 NC PWRCLAMP 6 GNDBUS2 PWRBUS2 GNDCLMP NC | Some possible clamping connections | . | are shown above for illustration | . | purposes | . 11 GNDBUS1 NC | One set of ground connections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. | . 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC | . 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. | . 41 NC PWRBUS2 | Second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 | . 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps | |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only |* differential pins, the vdiff entry is 0V. The fourth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh and | Vinl. | | If vdiff is not defined for a pin that is defined as requiring a | Vinh by its [Model] type, vdiff is set to the default value of | 200mV. | |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | one [Model] to be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tdelay_typ, or tdelay_min columns, its | entry is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is interpreted as the | tdelay_typ value. When using six columns, the headers | tdelay_min and tdelay_max must be listed. Entries for the | tdelay_min column are based on minimum magnitudes; and | tdelay_max column, maximum magnitudes. One entry of vdiff, | regardless of its polarity, is used for difference magnitudes. |--------------------------------------------------------------------------- [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V | |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes. | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref, | Rref, Vref | Usage Rules: Each model type must begin with the keyword [Model]. | The model name must match the one that is listed under | the [Pin] keyword and must not contain more than 20 characters. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except | for those model names that use reserved words (POWER, GND and | NC). Model names with reserved words are an exception and they | do not have to have a corresponding [Model] keyword. | | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl=0.8V and Vinh=2.0V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl=-1.475V and Vinh=-1.165V | are assumed. | | Terminator This model type is an input-only device that | can have analog loading effects on the | circuit being simulated but has no digital | logic thresholds. Examples of Terminators | are: capacitors, termination diodes, and | pull-up resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | | 3-state This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | | Open_sink These model types indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = 0mA | for all voltages specified) and the output | SINKS current. Open_drain model type is | retained for backward compatibility. | | Open_source This model type indicates that the | output has an OPEN side (do not use the | [Pulldown] keyword, or if it must be used, | set I = 0mA for all voltages specified) and | the output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | keyword. | | The Model_type and C_comp sub-parameters are required. The | Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref sub- | parameters are optional. C_comp defines the silicon die | capacitance. This value should not include the capacitance of | the package. C_comp is allowed to use "NA" for the min and max | values only. The Polarity sub-parameter can be defined as | either Non-Inverting or Inverting, and the Enable sub- | parameter can be defined as either Active-High or Active-Low. | | The Cref and Rref sub-parameters correspond to the test load | that the manufacturer uses when specifying the propagation | delay and/or output switching time of the device. The Vmeas | sub-parameter is the reference voltage level that the | manufacturer uses for the component. Include Cref, Rref, and | Vmeas information to facilitate board-level timing simulation. | The assumed connections for Cref, Rref, and Vref are shown in | the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one | or more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, | some models may have only a subset of these keywords. For | example, an input structure normally only needs the | [Voltage Range], [GND Clamp], and possibly the [POWER Clamp] | keywords. If one or more of [Rgnd], [Rpower], [Rac], and [Cac] | keywords are used, then the Model_type must be Terminator. |------------------------------------------------------------------------------ | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V |Reference voltage for timing measurements Cref = 50pF |Timing specification test load capacitance value Rref = 500 |Timing specification test load resistance value Vref = 0 |Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== | Keyword: [Temperature Range] |* Required: Yes, if other than the preferred 0, 50, 100 degree Celsius |* range | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various V/I curves and ramp rates were | derived. |------------------------------------------------------------------------------ | variable typ min max [Temperature Range] 27.0 -50 130.0 | |============================================================================== | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], | [POWER Clamp Reference], and [GND Clamp Reference] are not | present |Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the pull-up and [POWER Clamp] V/I data is | referenced. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |* Other Notes: If the [Voltage Range] keyword is not present, then all four |* of these keywords described below must be present: [Pullup |* Reference], [Pulldown Reference], [POWER Clamp Reference], |* and [GND Clamp Reference]. If the [Voltage Range] is present, |* the other keywords are optional and may or may not be used as |* required. It is legal (although redundant) for an optional |* keyword to specify the same voltage as specified by the |* [Voltage Range] keyword. |--------------------------------------------------------------------------- | variable typ min max [Voltage Range] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [Pullup Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | pull-up V/I data. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_r values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pullup Reference] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [Pulldown Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a power supply rail other than 0V as the reference | voltage for the pull-down V/I data. If this keyword is not | present, the voltage data points in the pull-down V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the typ, min, and max dV/dt_f values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pulldown Reference] 0V 0V 0V | |============================================================================== | Keyword: [POWER Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a voltage rail other than that defined by the | [Voltage Range] keyword as the reference voltage for the | [POWER Clamp] V/I data. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Refer the "Other Notes" section of the [GND Clamp Reference] | keyword. |--------------------------------------------------------------------------- | variable typ min max [POWER Clamp Reference] 5.0V 4.5V 5.5V | |============================================================================== | Keyword: [GND Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. |Description: Defines a power supply rail other than 0V as the reference | voltage for the [GND Clamp] V/I data. If this keyword is not | present, the voltage data points in the [GND Clamp] V/I table | are referenced to 0V. |Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. |Other Notes: Power Supplies: It is intended that standard TTL and CMOS | devices be specified using only the [Voltage Range] keyword. | However, in cases where the output characteristics of a device | depend on more than a single supply and ground, or a pull-up, | pull-down, or clamp structure is referenced to something other | than the default supplies, use the additional 'reference' | keywords. |---------------------------------------------------------------------------- | variable typ min max [GND Clamp Reference] 0V 0V 0V | |============================================================================== | Keywords: [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves of | the pull-down and pull-up structures of an output buffer and | the V/I curves of the clamping diodes connected to the GND and | the POWER pins, respectively. Currents are considered positive | when their direction is into the component. | | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | | Other Notes: The V/I curve of the [Pullup] and the [POWER Clamp] structures | are 'Vcc relative', meaning that the voltage values are | referenced to the Vcc pin. (Note: Under these keywords, all | references to 'Vcc' refer to the voltage rail defined by the | [Voltage range], [Pullup Reference], or [POWER Clamp Reference] | keywords, as appropriate.) The voltages in the data tables are | derived from the equation: Vtable = Vcc - Voutput. | | Therefore, for a 5V component, -5V in the table actually | means 5V above Vcc, which is +10V with respect to ground; | and 10V means 10V below Vcc, which is -5V with respect to | ground. Vcc-relative data is necessary to model a pull-up | structure properly, since the output current of a pull-up | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND Clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output, if so | desired. | | When tabulating data for ECL devices, the data in the pull-down | table is measured with the output in the 'logic low' state. | In other words, the data in the table represents the V/I | characteristics of the output when the output is at the most | negative of its two logic levels. Likewise, the data in the | pull-up table is measured with the output in the 'logic one' | state and represents the V/I characteristics when the output | is at the most positive logic level. Note that in BOTH of | these cases, the data is referenced to the Vcc supply voltage, | using the equation Vtable = Vcc - Voutput. | | Monotonicity Requirements: | To be monotonic, the V/I table data must meet any one of the | following 8 criteria: | 1- The CURRENT axis either increases or remains constant as | the voltage axis is increased. | 2- The CURRENT axis either increases or remains constant as | the voltage axis is decreased. | 3- The CURRENT axis either decreases or remains constant as | the voltage axis is increased. | 4- The CURRENT axis either decreases or remains constant as | the voltage axis is decreased. | | 5- The VOLTAGE axis either increases or remains constant as | the current axis is increased. | 6- The VOLTAGE axis either increases or remains constant as | the current axis is decreased. | 7- The VOLTAGE axis either decreases or remains constant as | the current axis is increased. | 8- The VOLTAGE axis either decreases or remains constant as | the current axis is decreased. | | An IBIS syntax checking program shall test for non-monotonic | data and provide a maximum of one note per V/I table if | non-montonic data is found. For example: | "NOTE: Line 300, Pulldown V/I table for model DC040403 is | non-monotonic! Most simulators will filter this data | to remove the non-monotonic data." | | It is also recognized that the data may be monotonic if | currents from both the output stage and the clamp diode are | added together as most simulators do. To limit the complexity | of the IBIS Version 2.x syntax checking programs, such | programs will conduct monotonicity testing only on one | V/I table at a time. | | It is assumed that the simulator sums the clamp curves | together with the appropriate pull-up or pull-down curve when | a buffer is driving high or low, respectively. From this | assumption and the nature of 3-statable buffers, it follows | that the data in the clamping curve sections are handled as | constantly present curves and the pull-up and pull-down curves | are used only when needed in the simulation. | | The clamp curves of an input or I/O buffer can be measured | directly with a curve tracer, with the I/O buffer 3-stated. | However, sweeping enabled buffers results in curves that are | the sum of the clamping curves and the output structures. | Based on the assumption outlined above, the pull-up and | pull-down curves of an IBIS model must represent the | difference of the 3-stated and the enabled buffer's curves. | (Note that the resulting difference curve can demonstrate a | non-monotonic shape.) This requirement enables the simulator | to sum the curves, without the danger of double counting, and | arrive at an accurate model in both the 3-stated and enabled | conditions. | | Since in the case of a non 3-statable buffer, this difference | curve cannot be generated through lab measurements (because | the clamping curves cannot be measured alone), the pull-up and | pull-down curves of an IBIS model can contain the sum of the | clamping characteristics and the output structure. In this | case, the clamping curves must contain all zeroes, or the | keywords must be omitted. |------------------------------------------------------------------------------ [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | |============================================================================== | Keywords: [Rgnd], [Rpower], [Rac], [Cac] | Required: Yes, if they exist in the device | Description: The data for these keywords define the resistance values of | Rgnd and Rpower connected to GND and the POWER pins, | respectively. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max), or the three entries | for C(typ), C(min), and C(max) must be placed on a single line | and must be separated by at least one white space or tab | character. All three columns are required under these | keywords. However, data is only required in the typical | column. If minimum and/or maximum values are not available, | the reserved word "NA" must be used indicating the R(typ) or | C(typ) value by default. | Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and | [Rgnd] is connected to 'GND'. However, [GND Clamp Reference] | voltages, if defined, apply to [Rgnd]. [POWER Clamp Reference] | voltages, if defined, apply to [Rpower]. Either or both [Rgnd] | and [Rpower] may be defined and may coexist with [GND Clamp] | and [POWER Clamp] structures. If the terminator consists | of a series R and C (often referred to as either an AC or RC | terminator), then both [Rac] and [Cac] are required. When | [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the | Model_type must be Terminator. | | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | VI | \ Rpower [Package] Keyword |* | | / Sub-parameters * | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | VI | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp Ref] | | | | | | | o-------------------o----------------------o | | | o | GND |* |* * Note: More advanced package parameters are available |* within this standard, including more detailed |* power and ground net descriptons. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [Rgnd] 330Ohm 300Ohm 360Ohm | Parallel Terminator [Rpower] 220Ohm 200Ohm NA | [Rac] 30Ohm NA NA | | variable C(typ) C(min) C(max) | AC terminator [Cac] 50pF NA NA | |============================================================================== | Keyword: [Ramp] | Required: Yes, except for inputs and terminators | Description: Defines the rise and fall times of a buffer. The ramp rate | does not include packaging but does include the effects of the | C_comp parameter. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. | The ramp rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load sub-parameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ min max dV/dt_r 2.20/1.06n 1.92/1.28n 2.49/650p dV/dt_f 2.46/1.21n 2.21/1.54n 2.70/770p R_load = 300ohms | |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' sub-parameters specify the loading | conditions under which the waveform is taken. The R_dut, |* C_dut, and L_dut sub-parameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used, its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | sub-parameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | |============================================================================= | | PACKAGE MODELING | | The [Package Model] keyword is optional. If more than the default RLC | package model is desired, use the [Define Package Model] keyword. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... | [End Package Model] keywords for each package model that is defined. For | reference, these keywords are listed below. Full descriptions follow. | Simulators that do not support these keywords will ignore all entries between | the [Define Package Model] and [End Package Model] keywords. | | [Define Package Model] Required if the [Package Model] keyword is used | [Manufacturer] (note 1) | [OEM] (note 1) | [Description] (note 1) | [Number of Pins] (note 1) | [Pin Numbers] (note 1) | [Model Data] (note 1) | [Resistance Matrix] Optional | [Inductance Matrix] (note 1) | [Capacitance Matrix] (note 1) | [Bandwidth] Required (for Banded_matrix matrices only) | [Row] (note 1) | [End Model Data] (note 1) | [End Package Model] (note 1) | | (note 1) Required when the [Define Package Model] keyword is used | | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | | USAGE RULES FOR THE .PKG FILE | | Package models are stored in a file whose name looks like: | .pkg. | | The provided must adhere to the General Syntax Rules. Use the | ".pkg" extension to identify files containing package models. The .pkg file | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg | file. The .pkg file is for package models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package | model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a |* consistent name in all .ibs and .pkg files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes | Description: Declares the manufacturer of the package. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each |* manufacturer must use a consistent name in all .ibs and .pkg |* files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of | what kind of package the [Package Model] is representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |============================================================================== | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the package | pins, and to define an ordering of them. The first pin name | given is the "lowest" pin, and the last pin given is the |* "highest." The pin names cannot exceed 5 characters in | length. | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are | pins (as given by the preceding [Number of Pins].) |------------------------------------------------------------------------------ [Pin Numbers] A1 A2 | . | . | . A22 B1 | . | . | . | etc. | |============================================================================== | Keyword: [Model Data] | Required: Yes | Description: Indicates the beginning of the formatted package model data, | which can include the [Resistance Matrix], [Inductance Matrix], | [Capacitance Matrix], [Bandwidth], and [Row] keywords. |------------------------------------------------------------------------------ [Model Data] | |============================================================================== | Keyword: [End Model Data] | Required: Yes | Description: Indicates the end of the formatted model data. | Other Notes: In between the [Model Data] and [End Model Data] keywords is | the package model data itself. The data is a set of 3 | matrices: the resistance (R), inductance (L), and capacitance | (C) matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords below to mark the | beginning of each new matrix. |------------------------------------------------------------------------------ [End Model Data] | |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The sub-parameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the sub-parameters. | After each of these sub-parameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board |* (General Syntax Rule #11). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | | For even a modest-sized package, this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known |* as the "bandwidth." Let the matrix size be N x M, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. |* |* The Banded_matrix is used to specify the coupling effects up to B pins |* on either side. Two variations are supported. One allows for the coupling |* to circle back on itself. This is technically a simple form of a bordered |* block diagonal matrix. However, its data can be completely specified |* in terms of a Banded_matrix for an N x M matrix consisting of N rows |* and M = N + B columns. The second variation is just in terms of an N x N |* matrix where no circle back coupling needs to be specified. |* | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | |* For case where coupling can circle back on itself, consider a matrix of |* N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B. | The first row only needs to specify the entries [1,1] through [1,1+B] since |* all other entries are guaranteed to be zero. The second row will need to |* specify the entries [2,2] through [2,2+B], and so on. For row K |* the entries [K,K] through [K,K+B] are given when K + B is less than or |* equal to the size of the matrix N. When K + B exceeds N, the entries in the |* last columns 1 ... B specify the coupling to the first rows. For row K, the |* entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = |* mod(K + B - 1, N) + 1. All rows will contain B + 1 entries. To avoid |* redundant entries, the bandwidth is limited to B <= int((N - 1) / 2). |* |* For the case where coupling does not circle back on itself, the process is |* modified. Only N columns need to be considered. When K + B finally exceeds |* the size of the matrix N, the number of entries in each row starts to |* decrease; the last row (row N) has only 1 entry. This construction |* constrains the bandwidth to B < N. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs.) | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | |* With this convention, please note that the N'th row of an |* N x N matrix has just a single entry (the diagonal entry). | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 [Date] August 22, 1995 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ibs file. |------------------------------------------------------------------------------ [End] | |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. It describes certain | assumed parameter and table extraction conditions if they are not | explicitly specified. It also describes the allocation of data into | the "typ", "min", and "max" columns under variations of voltage, | temperature, and process. | | The required "typ" column for all data represents typical operating | conditions. For most [Model] keyword data, the "min" column describes | slow, weak performance, and the "max" column describes the fast, strong | performance. It is permissible to use slow, weak devices or models to | derive the data for the "min" column, and to use fast, strong devices or | models to derive the data in the "max" columns under the corresponding | voltage and temperature derating conditions for these columns. It is also | permissible to use typical devices or models derated by voltage and | temperature and optionally apply proprietary "X%" and "Y%" factors | described later for further derating. This methodology has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | The voltage and temperature keywords and optionally the process models | control the conditions which define the "typ", "min", and "max" column | entries for all V/I table keywords [Pulldown], [Pullup], [Gnd Clamp], | and [Power Clamp]; all [Ramp] sub-parameters dV/dt_r and dV/dt_f; and | all waveform table keywords and sub-parameters [Rising Waveform], | [Falling Waveform], V_fixture, V_fixture_min, and V_fixture_max. | | The voltage keywords which control the voltage conditions are [Voltage | Range], [Pulldown Reference], [Pullup Reference], [Gnd Clamp Reference], | and [Power Clamp Reference]. The entries in the "min" columns | contain the smallest magnitude voltages, and the entries in the "max" | columns contain the largest magnitude voltages. | | The optional [Temperature] keyword will contain the temperature | which causes or amplifies the slow, weak conditions in the "min" column | and the temperature which causes or amplifies the fast, strong | conditions in the "max" column. Therefore, the "min" column for | [Temperature] will contain the lowest value for bipolar devices (TTL | and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. | | The "min" and "max" columns for all remaining keywords and sub-parameters | will contain the smallest and largest magnitude values. This applies | to the [Model] sub-parameter C_comp as well even if the correlation | to the voltage, temperature, and process variations are known because | information about such correlation is not available in all cases. | | C_comp is considered an independent variable. This is because C_comp | includes bonding pad capacitance, which does not necessarily track | fabrication process variations. The conservative approach to using IBIS | data will associate large C_comp values with slow, weak models, and the | small C_comp values with fast, strong models." | | The default temperatures under which all V/I tables are extracted are | provided below. The same defaults also are stated for the [Ramp] | sub-parameters, but they also apply for the waveform keywords. | | The stated voltage ranges for V/I tables cover the most common, single | supply cases. When multiple supplies are specified, the voltages shall | extend similarly to values which handle practical extremes in reflected | wave simulations. | | For the [Ramp] sub-parameters, the default test load and voltages are | provided. However, the test load can be entered directly by the R_load | sub-parameter. The allowable test loads and voltages for the waveform | keywords are stated by required and optional sub-parameters; no defaults | are needed. Even with waveform keywords, the [Ramp] keyword continues | to be required so that the IBIS model remains functional in situations | which do not support waveform processing. | | The following discussion lists test details and default conditions. | | 1) V/I curves for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "X%" | max = maximum voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "X%" | max = maximum voltage, max temp deg C, typical process, plus "X%" | | Nominal, min, and max temperature are specified by the manufacturer | of the part. The default range is 50C nom, 0C min, and 100C max | temperatures. | | X% should be statistically determined by the silicon vendor based | on numerous fab lots, test chips, process controls, etc.. The value | of X need not be published in the IBIS file, and may decrease over | time as data on the I/O buffers and silicon process increases. | | Temperatures are junction temperatures. | | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | | As described in the [Pulldown Reference] keyword section, the V/I curve of | the [Pullup] and the [POWER Clamp] structures are 'Vcc relative', using | the equation: Vtable = Vcc - Voutput. | | For example, a device with a 5V power supply voltage should be | characterized between (0 - 5) = -5V and (5 + 5) = 10V; and a | device with a 3.3V power supply should be characterized between | (0 - 3.3) = -3.3V and (3.3 + 3.3) = 6.6V for the pull-down curve. | | When tabulating output data for ECL type devices, the voltage points | must span the range of Vcc to Vcc - 2.2V. This range applies to both the | pull-up and pull-down tables. Note that this range applies ONLY when | characterizing an ECL output. | | These voltage ranges must be spanned by the IBIS data. Data derived | from lab measurements may not be able to span these ranges as such and | so may need to be extrapolated to cover the full range. This data must | not be left for the simulator to provide. | | 3) Ramp Rates: | The following steps assume that the default load resistance of 50 ohms is | used. There may be devices that will not drive a load of only 50 ohms | into any useful level of dynamics. In these cases, use the manufacturer's | suggested (non-reactive) load and add the load sub parameter to the [Ramp] | specification. | | The ramp rate does not include packaging but does include the effects of | the C_comp parameter; it is the intrinsic output stage rise and fall time | only. | | The ramp rates (listed in AC characteristics below) should be derived | as follows: | | a. If starting with the silicon model, remove all packaging. If starting | with a packaged device, perform the measurements as outlined below then | use whatever techniques are appropriate to derive the actual, unloaded | rise and fall times. | | b. If: The Model_type is one of the following: Output, I/O, or | 3-state (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | | If: The Model_type is Output_ECL or I/O_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either POWER or the vendor- | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either GND or the vendor-suggested | termination voltage. Use this load to derive both the rising | and falling edges. | | c. Due to the resistor, output swings will not make a full transition as | expected. However the pertinent data can still be collected as | follows: | 1) determine the 20% to 80% voltages of the 50 Ohm swing | 2) measure this voltage change as "dV" | 3) measure the amount of time required to make this swing "dt" | d. Post the value as a ratio "dV/dt". The simulation tool vendor | extrapolates this value to span the required voltage swing range in | the final model. | | e. Typ, Min, and Max must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "Y%" | max = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "Y%" | max = maximum voltage, max temp deg C, typical process, plus "Y%" | | where nominal, min, and max temp are specified by the manufacturer of | the part. The preferred range is 50C nom, 0C min, and 100C max | temperatures. | | Note that the derate factor, "Y%", may be different than that used | for the V/I curve data. This factor is similar to the X% factor | described above. As in the case of V/I curves, temperatures are | junction temperatures. | | f. During the IV measurements, the driving waveform should have a | rise/fall time fast enough to avoid thermal feedback. The specific | choice of sweep time is left to the modeling engineer. | | It is expected that this data will be created from silicon vendor | proprietary silicon-level models, and later correlated with actual device | measurement. From bracken@kevily.ece.cmu.edu Mon Aug 28 07:54:18 1995 Return-Path: Received: from kevily.ece.cmu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19250; Mon, 28 Aug 95 07:54:18 PDT Received: from localhost (bracken@localhost) by kevily.ece.cmu.edu (8.6.11/8.6.4) with SMTP id KAA21686 for ; Mon, 28 Aug 1995 10:46:10 -0400 Message-Id: <199508281446.KAA21686@kevily.ece.cmu.edu> X-Authentication-Warning: kevily.ece.cmu.edu: Host localhost didn't use HELO protocol To: ibis@vhdl.org Subject: Re: Bird 28.2 - Comments and Suggestions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <27570.809621169.1@kevily.ece.cmu.edu> Date: Mon, 28 Aug 1995 10:46:09 -0400 From: J Eric Bracken Howdy, EIA/IBIS folks: I have a couple of comments on some earlier posts: Point 1: [Regarding the signs of the off-diagonal C matrix entries] ---------------------------------------------------------------- One interpretation of the capacitance matrix is that it relates the charges Q1, Q2, ... Qn on a set of n conductors to the potentials V1, V2, ... Vn on those same conductors. For two conductors, we'd have Q1 = C11 * V1 + C12 * V2 Q2 = C12 * V1 + C22 * V2 (This is just writing out the "matrix" multiplication [Q] = [C][V].) The simplest two-conductor situation is a parallel plate capacitor C. In this case, we know that the charge on the top plate (conductor 1) is Q1 = C*(V1 - V2); and so expanding the equation out, C11 = C and C12 = -C. The charge on the bottom plate is Q2=-C(V1-V2), so everything is consistent if the off-diagonal terms are assigned a negative sign. To think of it another way, suppose that we connect conductor 1 to a constant voltage source, and then we raise the potential on a second nearby conductor. Additional NEGATIVE charge will appear on conductor 1 in order to terminate the extra field lines coming from the second conductor. Many field solvers actually compute "charges", and so it is natural for them to report the off-diagonal entries as negative. Footnote: The situation is rather different for INDUCTANCE matrices. In this case, we can arbitrarily assign a certain direction as being "positive" for current flow. Depending on the orientations of the currents in two neighboring wires, the mutual inductances between them could have either positive or negative sign. Point 2: [Regarding the need for G matrices] ---------------------------------------------------------------- Here's the problem that I have with specifying the G matrix: suppose we conduct the measurement of G at DC. Chances are that the dielectrics used in the package are so good that G is immeasurably low; all the entries of the G matrix are then zero. You _can_ run into nonzero G values at high frequencies. This occurs because the poor little atoms in the dielectrics can't spin fast enough (they have some mass) to reorient themselves to the rapidly changing electric fields. The lag causes some very frequency-DEPENDENT losses. So, at what frequency do you specify G? And is data from just one frequency point good for a transient analysis? Another footnote: certainly the R and L matrices can change due to skin effect as we increase the frequency. But the changes in L are very minor (usu. less than 10%); changes in R are much more substantial, but at least there is a well-defined non-zero DC value for R that's easy to measure. --Eric From bob@icx.com Tue Aug 29 18:07:22 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05928; Tue, 29 Aug 95 18:07:22 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 29 Aug 95 18:00 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 29 Aug 95 18:03 PDT Message-Id: Date: Tue, 29 Aug 95 18:03 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 8/25/95 DATE: August 29, 1995 SUBJECT: 8/25/95 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS: AT&T Global Info Solutions Dave Moxley* Cadence Design Sandeep Khanna, C. Kumar Contec CAE, Ltd. Dileep Divekar* HyperLynx Kellee Crisafulli IBM Jay Diepenbrock INCASES Werner Rissiek, Olaf Rethmeier* Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, Derrick Duehren Interconnectix, Inc. Bob Ross* Meta-Software Les Spruiell, Mei Wong, You-Pang Wei, John Sliney Motorola Ron Werner National Semiconductor Syed Huq*, Atul Agarwal, Cheng-Yang Kao NEC Hiroshi Matsumoto, Eldar Yazbashevz* Quad Design Jon Powell Quantic Labs Mike Ventham Texas Instruments Roger Cline, Ben Andresen Thomson-CSF/SCTF Jean LeBrun UniCAD Canada Ltd. Stephen Lum VLSI Technology Dick Ulmer*, Sung Oh* Zuken-Redac John Berrie OTHER PARTICIPANTS: ARPA Randy Harr Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadlab Ralf Bruning Digital Equipment Corp. Barry Katz EIA Patti Rusher High Design Technology Michael Smith, Dr. Ing. Cosso Hewlett Packard Tom Langdorf, Karl Kachigan, Henry Wu Integrated Silicon Systems Eric Bracken Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz LSI Logic Corp. Satish Pratadneni Mentor Graphics Ravender Goyal, Greg Doyle Micron Technology Brian Johnson MicroSim Arthur Wong North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Univ. of Illinois, Urbana Raj Mittra* Zeelan Technology George Opsahl, Hiro Moriyasu (Independent) Bob Ward In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 9/15/95 (916) 356-9200 1-16347 127231 10/6/95 (303)-633-2197 1-308636 No pass code 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, ANNOUNCEMENTS Eldar Yazbashevz from NEC joined us as an interested user of IBIS models. EIA MEMBERSHIP AND TREASURER'S REPORT No Treasurer's report was available. There is some off-line discussion regarding whether additional money has been sent from Anacad and received by EIA for Anacad to become a voting member. MINUTES REPORT, MISC. Minutes of 8/11/95 corrections: Dave Moxeley of ATT attended. Intel "Chipsets" library has been updated. The Passcode number was incorrect for the 8/25/95 meeting on the minutes, and we hope that did not cause any problems. It was correct on the agenda. PRESS UPDATES None. NEW MODELS None. OPENS FOR NEW ISSUES Possible discussions are Models under NDA, the Roadmap project and the ground plane analysis issue, all which have been discussed on the reflector. EIA IBIS RATIFICATION (VOTES) The letter ballot closed as of August 22, 1995. There were no negative ballots. A draft Version 2.1 revision was posted with the already approved changes per the August 11, 1995 meeting. Most of the meeting was devoted to the Version 2.1 comments and revision. Will Hobbs of Intel supplied some grammatical and spelling corrections based on a technical writer review: Pg. 3, line 38: Change "super sets" to "supersets. Pg. 5, line 28: Change "can NOT" to "CANNOT". Pg. 23, line 17: Change "can not" to "cannot". On the revised draft, Remove the redundant "in" in the BIRD29.2 inclusion. Dave Moxley provided these spelling corrections: Pg. 8, line 48: Change "forth" to "fourth". Pg. 10, line 23: Change "forth" to "fourth". The proposed response to Intel's editorial comments that were sent on the reflector were approved by Membership vote. AR - Bob Ross send the response to Intel and copy EIA. Sung-Ki Min of Integrated Device Technology, Inc. submitted comments and the response to IDT, Inc. was discussed. The main issue was how to describe the fact that IBIS does take into account the package parameters for ground and power pins without creating a cluttered figure. After much discussion, this response was proposed: "Recommendation for SP3527 (IBIS) It is recommended that high frequency effects be modeled into IBIS. - The Modeling of transmission line effect at the I/O. - Lead inductances should be modeled in the power and the ground to model L*(di/dt) effect at the output (Figure in page 18). Thank you." IDT, Inc.: Comment 1 Type of Comment: Editorial Reference: None Suggested Change: It is recommended that high frequency effects be modeled into IBIS. - The Modeling of transmission line effect at the I/O. Response: No change will be made. Reason: Transmission line effects in packages are being considered and actively discussed for the next future extension of IBIS. Buffer Issue Resolution Document No. 28.2 (BIRD28.2) is the current proposal. Your participation in this work is welcomed. IDT, Inc.: Comment 2 Type of Comment: Editorial Reference: Terminator model figure on page 18. Suggested Change: It is recommended that high frequency effects be modeled into IBIS. - Lead inductances should be modeled in the power and the ground to model L*(di/dt) effect at the output (Figure in page 18). Response: On the figure the "[Package] Keyword Sub-parameters" will be changed to "[Package] Keyword Sub-parameters *" and a note at the bottom will be added: "* Note: More advanced package parameters are available within this standard, including more detailed power and ground net descriptions. Reason: You have a valid concern regarding the reference model and its relationship to ground and power inductances. The IBIS format actually supports a variety of package models of increasing detail. To describe them in detail in a figure would detract from the main point showing the terminator model elements. Often for terminator elements shown in the figure on page 18, the ground and power package elements are not needed. The terminator values are already dominant for the frequency range of interest. So the picture remains valid. However, a note is added to convey that the application and usage of IBIS models can be extended to a higher level of detail based on simulator functionality and the analysis being addressed. In general the [Pin Mapping] keyword is available to describe the power and ground L*(di/dt) effects for a particular set of buffer or terminator models. The above response was approved by Membership vote. AR - Will Hobbs send the response to Integrated Device Technology and copy EIA. Michael G. Wahl of the University of Siegen submitted some comments. The response to University of Siegen was discussed. Will checked with Jeanne Warner of EIA and verified that we had all of the documents that EIA had received. The proposed response to the University of Siegen comments was: "General Comment: * An Information Model in Express would make the introduction of the Standard to the STEP activitiy easier. * I have missed an extended example. * Short Remarks on pages: 6, 7, 12" University of Siegen: Comment 1 Type of Comment: Editorial Reference: None Suggested Change: * An Information Model in Express would make the introduction of the Standard to the STEP activitiy easier. Response: No change will be made. Reason: We will consider your suggestion for future IBIS activity. University of Siegen: Comment 2 Type of Comment: Editorial Reference: None Suggested Change: * I have missed an extended example. Response: No change will be made. Reason: IBIS modles are publically available to serve as examples in the /pub/ibis/models directory on vhdl.org. An information package is attached. University of Siegen: Comment 3 Type of Comment: Editorial Reference: Pages 6, 7, 12 Suggested Change: * Short Remarks on pages: 6, 7, 12 Response: No change will be made. Reason: We did not receive the pages with remarks. We cannot consider these remarks at this time. The above response was approved by Membership vote. AR - Will Hobbs send the response to Integrated Device Technology and cop EIA. AR - Will Hobbs submit copies of previous responses to EIA. AR - Bob Ross roll the changes into a revised Version 2.1 Specification. Send changes to the reflector by September 1, 1995. Send changes to EIA. The Version 2.1 document was put to a vote with the grammar and spelling changes and with the letter ballot changes above. It was approved by Membership vote. Will Hobbs indicated that this is a major milestone. The next step is to submit these comments and results to EIA and work with them toward final ratification of EIA-656. Also, EIA will generate a press release. AR - Will Hobbs communicate with EIA on the next step to final ratification of EIA-656 and a press release. WEB UPDATE Will Hobbs stated that he can submit IBIS information internally at Intel similar to what Syed Huq has done at National. He recommends that people in other companies do the same. Syed Huq reported that the EIA home page is going through some changes and the IBIS and EIA-656 access has not been set up yet. The search utility is currently disabled. Syed has translated the IBIS material into html, so the documents are ready. Syed will continue to work with EIA. FAQ VOTE Q6 and Q7 had been resubmitted to the reflector for consideration. Based on responses questions were considered here. Q6: Can IBIS model SSO (Simultaneous Switching Output) ? Sung Oh raised the issue that gate modulation feedback effects can change di/dt and qre not modeled. Arpad Muranyi argued that some of the modulation effects can be obtained by looking at all of the tables (min, typ, and max). Will Hobbs indicated that several IBIS formatted models could be provided for SSO simulation for a sequence of 1 driver, 2 drivers, etc. Also, the [Pin Mapping] keyword gives some useful information. Arpad indicated that decoupling on the die can be a significant factor. The general consensus was that some level of SSO is supported, but it is dangerous to imply SSO is completely covered. AR - Syed Huq post a reworded answer for further reflector discussion. Q7: Why do we need to sweep -Vcc to 2Vcc ? There was discussion concerning the need and validity of the clamping currents at the end of the range. The concensus was that extrapolated values were sufficiently accurate and that high currents do not occur in signal integrity applications in actual simulations. So the answer was basically correct. The last two paragraphs were combined. The committee voted to approve the response. MODELS UNDER NDA The comment on the reflector by Dileep Divekar on NDA models may be resolved by a FAQ of the form: Are models freely available? The response is that some models are available under NDA because the part has not been released and also some models are generated for sale as part of a model generation business. Will Hobbs will send Syed Huq the reflector discussion. AR - Will Hobbs send Syed Huq the reflector discussion regarding models under NDA. AR - Syed Huq formulate a question and answer for review and voting. GOLDEN PARSER UPDATE Version 8 has been distributed. Arpad Muranyi has received Version 9 correcting a Banded_matrix bug. He is sending it to Will Hobbs for distribution. This should be the final Beta version. BIRD30 - PIN PROGRAMMABLE BUFFER STRENGTHS There was no time for discussion, but Bob Ross indicated that maybe there was a more consistent syntax which will eliminate the floating "Default" and may allow some attributes. NEXT MEETING: It is set on Friday, September 15 1995. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Modeling Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com 10220 SW Nimbus Ave, K4, Portland, OR 97223 To become a voting member of the EIA IBIS Open Forum, send email to ibis-info@vhdl.org for instructions. If you want to join the e-mail reflector (ibis@vhdl.org), send e-mail to the IBIS secretary at ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From EGJJ77A@mail.prodigy.com Wed Aug 30 13:13:42 1995 Return-Path: Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18216; Wed, 30 Aug 95 13:13:42 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.prodigy.com (8.6.10/8.6.9) with SMTP id QAA29598; Wed, 30 Aug 1995 16:03:52 -0400 Date: Wed, 30 Aug 1995 16:13:59 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00580144.EGJJ77A@prodigy.com> To: ibis@vhdl.org, roadmap-eii@cfi.org Subject: Non Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Will Hobbs, I recommend a teleconference call be set up just on this subject. One suggestion would be the first hour of your 9/15 meeting, or it could be a separate teleconference call, but all those participating on the reflector must be committed to be present. I see in the discussion insufficient user request to justify the necessary study, but I also see a whole foundry not supporting IBIS because of this problem. This seems inconsistent. Users can get around the problem today with SPICE models and NDA agreements, but this will not be adequate as reuse and interoperability of signal integrity tools increases. Ron Christopher From Will_Hobbs@ccm2.jf.intel.com Wed Aug 30 16:32:09 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24641; Wed, 30 Aug 95 16:32:09 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0snwUJ-000UgIC; Wed, 30 Aug 95 16:24 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0snwUI-000tx3C; Wed, 30 Aug 95 16:24 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Wed, 30 Aug 95 16:24:06 PDT Date: Wed, 30 Aug 95 16:20:00 PDT From: Will Hobbs Message-Id: To: EGJJ77A@mail.prodigy.com, ibis@vhdl.org, roadmap-eii@cfi.org Subject: Re: Non Monotonic Drivers Text item: Ron, I am OK with making it part of the second half of the 9/15 meeting. This discussion would be even better handled at one of our face to face IBIS summits, though your message indicates enough urgency that it probably can't wait until the next one, which will likely be in December '95, or January '96. The reflector has over a hundred names, however, so I seriously doubt you'll see full participation from reflector people. Bob Ross and I will discuss how much time to set aside for it, but a full hour seems both too short and too long-- too short to reach a consensus and too long in relation to other things on the agenda, such as better package models. How many drivers have non-monotonic behavior as part of their basic design? It is not an overwhelming percentage. An alternative is a 3 hour meeting, with the entire third hour devoted to this subject. My preference is to get more technical meat into the reflector discussions and set aside ~1/2 hour in the regular portion of the 9/15 meeting for the verbal discussion. Other opinions? Will -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Will Hobbs, I recommend a teleconference call be set up just on this subject. One suggestion would be the first hour of your 9/15 meeting, or it could be a separate teleconference call, but all those participating on the reflector must be committed to be present. I see in the discussion insufficient user request to justify the necessary study, but I also see a whole foundry not supporting IBIS because of this problem. This seems inconsistent. Users can get around the problem today with SPICE models and NDA agreements, but this will not be adequate as reuse and interoperability of signal integrity tools increases. Ron Christopher Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Non Monotonic Drivers To: ibis@vhdl.org, roadmap-eii@cfi.org Message-Id: <013.00580144.EGJJ77A@prodigy.com> X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Wed, 30 Aug 1995 16:13:59 EDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.pr odigy.com (8.6.10/8.6.9) with SMTP id QAA29598; Wed, 30 Aug 1995 16:03:52 -0400 Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18216; Wed, 30 Aug 95 13:13:42 PDT Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Wed, 30 Aug 95 14 :24:25 -0700 Received: from aurora.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 30 Aug 9 5 14:24:56 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0snud0-000txaC; Wed, 30 Aug 95 14:24 PDT From bob@icx.com Wed Aug 30 17:26:05 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24939; Wed, 30 Aug 95 17:26:05 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 30 Aug 95 17:18 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 30 Aug 95 17:21 PDT Message-Id: Date: Wed, 30 Aug 95 17:21 PDT From: bob@icx.com ( Bob Ross) To: EGJJ77A@prodigy.com, ibis@vhdl.org, roadmap-eii@cfi.org Subject: Re: Non Monotonic Drivers Ron: I am planning to put a Monotonicity discussion on the September 15, 1995 meeting at 9 AM. I would estimate that it should take about 20 minutes as a soft limit, unless you have a more detailed agenda to follow for that discussion. Our normal methodology is to use the telephone meetings to introduce topics or to discuss issues with respect to solid proposals (BIRDs). Normally a substantial amount of discusson is done on the reflector. So if you would like, you can start the process at this time by telling is specifically (1) What you mean by monotonicity (VI tabless?), (VT tables?). (2) What is the specific concern with respect to IBIS? (3) What are your concerns with respect to simulation of IBIS models? (4) Is there a class of devices which exhibits frequent non-monotonic behaviour? I would like to point out that monotonicity has been discussed extensively in the past and there are several statements and warning messages documented in IBIS Version 2.1 that were produced as a result of this discussion. There has been further discussion that pullup or pulldown tables which have non-monotonic behavior region can be combined with the clamping tables to produce an overall monotonic response. Simulators usually have no problem with this situation, even though the parser will issue a warning message. I would further like to clarify that IBIS itself as a data file for a model allows including non-monotonic data. It tabulates the raw data based on measurement or simulation. Warning messages do alert the user that some simulators may encounter numerical problems when processing the non-monotonic data. So the perception by a foundry that IBIS requires only monotonic data is wrong. We need to get to the real issue or concern. Bob Ross, Interconnectix, Inc. > -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- > Will Hobbs, > I recommend a teleconference call be set up just on this subject. One > suggestion would be the first hour of your 9/15 meeting, or it could be > a separate teleconference call, but all those participating on the > reflector must be committed to be present. > I see in the discussion insufficient user request to justify the > necessary study, but I also see a whole foundry not supporting IBIS > because of this problem. This seems inconsistent. Users can get > around the problem today with SPICE models and NDA agreements, but this > will not be adequate as reuse and interoperability of signal integrity > tools increases. > Ron Christopher From Arpad_Muranyi@ccm.fm.intel.com Thu Aug 31 08:52:29 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04447; Thu, 31 Aug 95 08:52:29 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0soBjH-000UeqC; Thu, 31 Aug 95 08:40 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0soBjH-000twYC; Thu, 31 Aug 95 08:40 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 31 Aug 95 08:40:34 PDT Date: Thu, 31 Aug 95 08:35:00 PDT From: Arpad Muranyi Message-Id: To: EGJJ77A@mail.prodigy.com, ibis@vhdl.org, roadmap-eii@cfi.org Subject: Re: Non Monotonic Drivers Text item: To all, I think we should keep this topic (non-monotonic stuff) whithin the IBIS Open Forum and not take it outside. Though not many might be interested in this subject today (even thogh I question that), it has surfaced enough times that all participants involved in the meetings should hear the discussion. I also feel that this is another major area (besides broader package descriptions) which IBIS 3.0 might have to address. Arpad ================================================================================ -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Will Hobbs, I recommend a teleconference call be set up just on this subject. One suggestion would be the first hour of your 9/15 meeting, or it could be a separate teleconference call, but all those participating on the reflector must be committed to be present. I see in the discussion insufficient user request to justify the necessary study, but I also see a whole foundry not supporting IBIS because of this problem. This seems inconsistent. Users can get around the problem today with SPICE models and NDA agreements, but this will not be adequate as reuse and interoperability of signal integrity tools increases. Ron Christopher Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Non Monotonic Drivers To: ibis@vhdl.org, roadmap-eii@cfi.org Message-Id: <013.00580144.EGJJ77A@prodigy.com> X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Wed, 30 Aug 1995 16:13:59 EDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.pr odigy.com (8.6.10/8.6.9) with SMTP id QAA29598; Wed, 30 Aug 1995 16:03:52 -0400 Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18216; Wed, 30 Aug 95 13:13:42 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 30 Aug 95 13 :20:06 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0snyer-000twvC; Wed, 30 Aug 95 18:43 PDT From EGJJ77A@mail.prodigy.com Thu Aug 31 08:52:01 1995 Return-Path: Received: from maily2.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04446; Thu, 31 Aug 95 08:52:01 PDT Received: from mail.prodigy.com (mail [199.4.137.13]) by maily2.prodigy.com (8.6.10/8.6.9) with SMTP id KAA40412 for ; Thu, 31 Aug 1995 10:58:09 -0400 Date: Thu, 31 Aug 1995 11:08:12 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00622895.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: Re: Re[4]: Non-Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Forwarding to the reflector. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Wednesday, 23-Aug-95 09:11 PM > > From: Jon Powell \ Internet: > (uunet!qdt.com!jonp@uunet.uu.net) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re: Re[4]: Non-Monotonic Drivers > > Arpad tongue in cheek comments aside, the point with non-monotonic > waveforms that I have been stressing is that non-monotonicity implies > negative resistance, this implies feedback, this implies time delay. It > also implies a possible capacitive charge pumping effect. We need to know > that delay. We need to know how it effects the IV curve. Ignoring this > effect will not help. If we don't put the delay into IBIS then the > simulator companies can make assumptions but cannot guarantee that those > assumptions will be right. > > If anyone does not agree with this bit about a delay, then speak up and > lets have a discussion. If you don't understand it, give me a call and > lets discuss it that way. > 805 988 8250 > > > by the way, Are we having this discussion between the four of us on > purpose, or did you guys do the same thing I did and just hit "reply"? > > cheers, > jon > > > ------- FORWARD, End of original message ------- From EGJJ77A@mail.prodigy.com Thu Aug 31 08:55:39 1995 Return-Path: Received: from maily2.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04457; Thu, 31 Aug 95 08:55:39 PDT Received: from mail.prodigy.com (mail [199.4.137.13]) by maily2.prodigy.com (8.6.10/8.6.9) with SMTP id KAA30003 for ; Thu, 31 Aug 1995 10:59:04 -0400 Date: Thu, 31 Aug 1995 11:09:07 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00622931.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: Re: Non-Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Forwarding to the reflector. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Tuesday, 22-Aug-95 09:32 PM > > From: Arpad Muranyi \ Internet: > (arpad_muranyi@ccm.fm.intel.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re: Non-Monotonic Drivers > > Text item: > > John, > > Thanks for the graphical response to my question. This is the kind of > response I really wanted to get. I have a question, though. Is this I-V > curve a function of the voltage on the output pin, or time. I mean, is > "translating between two Vgs curves" done with a feedback circuit by > monitoring the output voltage, or is it a function of time as slew rate > controlled devices usually do it? > > If the answer is time, IBIS can definitely do it, but if it is voltage (as > in feedback), IBIS would not be able to help you at this time. However, > the open forum committee did consider this issue in meetings before, and > I don't think that it would be impossible to incorporate features that > can model it. > > Arpad > ======================================================================= == > ===== > Arpad, > > The drivers Ron refers to have the following IV curve shape... > > Ids * * > * * > * * > * * > * **************** > * > * > * > * Vds > > > Instead of the normal transistor curve shape like... > > Ids * *********************** > * > * > * > * > * > * > * > * Vds > > > The top curve comes about because we are manipulating the gate voltage to > control di/dt noise in the maximum Vds region of the large output device. > Essentially we are translating between two Vgs curves for the output > transistor. Hence the non-monotonicity is real and not noise related. > Clamp diodes would add another bend in the curve and create 3 current > values for 1 voltage value. > > The simulation tools we looked at would "correct" the data by making the > top curve look like the bottom. We saw some extreme differences in > benchmark nets after this manipulation from the full transistor > simulation. Since there is no standard on how to "correct" the above > curve, we would not know how various simulation vendors would treat the > model. > > The above and the time schedule of IBIS 2.1 and CMOS 4 makes supporting > the IBIS modeling strategy unattractive for our CMOS 4 products. > > Thanks, > John Brennan > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Tue, 22 Aug 1995 13:34:03 -0400 > Subject: Non-Monotonic Drivers > To: EGJJ77A@prodigy.com, arpad_muranyi@ccm.fm.intel.com, jonp@qdt.com > Message-Id: <9508221734.AA33207@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA33207; Tue, 22 Aug 1995 13:34:05 -0400 > Received: from eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Tue, 22 Aug 1995 13:34:10 -0400 > Received: by BTV (XAGENTA 4.0) id 3245; Tue, 22 Aug 1995 13:35:23 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7677; > Tue, 22 Aug 95 13:38:48 EDT > Received: from vnet.ibm.com by aurora.intel.com (5.65/10.0i); Tue, 22 Aug > 95 10: > 38:52 -0700 > Received: from aurora.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0skxGs-000aoAC; Tue, 22 Aug 95 10:37 PDT > > > ------- FORWARD, End of original message ------- From EGJJ77A@mail.prodigy.com Thu Aug 31 08:56:06 1995 Return-Path: Received: from maily2.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04459; Thu, 31 Aug 95 08:56:06 PDT Received: from mail.prodigy.com (mail [199.4.137.13]) by maily2.prodigy.com (8.6.10/8.6.9) with SMTP id KAA40408 for ; Thu, 31 Aug 1995 10:58:06 -0400 Date: Thu, 31 Aug 1995 11:08:00 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00622887.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: Non-Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Forwarding following to the reflector with permission. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Tuesday, 22-Aug-95 01:38 PM > > From: John Brennan \ Internet: (jbrennan@vnet.ibm.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Non-Monotonic Drivers > > Arpad, > > The drivers Ron refers to have the following IV curve shape... > > Ids * * > * * > * * > * * > * **************** > * > * > * > * Vds > > > Instead of the normal transistor curve shape like... > > Ids * *********************** > * > * > * > * > * > * > * > * Vds > > > The top curve comes about because we are manipulating the gate voltage to > control di/dt noise in the maximum Vds region of the large output device. > Essentially we are translating between two Vgs curves for the output > transistor. Hence the non-monotonicity is real and not noise related. > Clamp diodes would add another bend in the curve and create 3 current > values for 1 voltage value. > > The simulation tools we looked at would "correct" the data by making the > top curve look like the bottom. We saw some extreme differences in > benchmark nets after this manipulation from the full transistor > simulation. Since there is no standard on how to "correct" the above > curve, we would not know how various simulation vendors would treat the > model. > > The above and the time schedule of IBIS 2.1 and CMOS 4 makes supporting > the IBIS modeling strategy unattractive for our CMOS 4 products. > > Thanks, > John Brennan > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > ------- Forwarded Message > > Date: Tue, 22 Aug 1995 10:48:35 -0400 > From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) > To: jbrennan@VNET.IBM.COM > Subject: Fwd: Re: > > - -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- > > John, > > This is the one that needs a technical answer on the IBIS forum. > > Thanks > Ron Christopher > - ------- FORWARD, Original message follows ------- > > > Date: Thursday, 17-Aug-95 01:32 PM > > > > From: Arpad Muranyi \ Internet: > > (arpad_muranyi@ccm.fm.intel.com) > > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > > > Subject: Re: > > > > Text item: > > > > Ron, > > > > There are many aspects to non-monotonic data. For example, some > > non-monotonic data could be caused by noise, others by the behavior > of > > the device. The former case can be solved by filtering, but the > latter > > case is more complicated. In order to tell you what IBIS can or > cannot > > do, I would like to have a little more description on those devices > that > > you are referring to. Can you tell me how they are non-monotonic? > > > > Arpad Muranyi > > Intel Corporation > > > ======================================================================= > == > > ====== > > > > -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- > > > > I am working as an independent with CFI, EDAC, and Sematech on a 10 > year > > roadmap for electronic CAD standards. Our work is described on the > WWW at > > http://www.cfi.org/roadmap/roadMap-eii-report.html. > > > > Our 10 year roadmap should show how we are going to do delay above > the > > chip. I thought we would be able to state IBIS, but it doesn't > handle the > > basic CMOS IV .5um IBM ASIC drivers. Bob Ward says Version 2.x does > not > > handle all the TI drivers either. Can we establish some steps in the > IBIS > > group to correct this which we could refer to in our roadmap? > > > > 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***. > > > > To: ibis@vhdl.org, roadmap-eii@cfi.org > > Message-Id: <013.09997113.EGJJ77A@prodigy.com> > > X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] > > >From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) > > Date: Thu, 17 Aug 1995 10:18:59 EDT > > Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by > > inetgate.pr > > odigy.com (8.6.10/8.6.9) with SMTP id KAA22884; Thu, 17 Aug 1995 10: > 20:31 > > -0400 > > Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI- > 4.1/BARRNet) > > id AA18685; Thu, 17 Aug 95 09:02:30 PDT > > Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, > 17 Aug > > 95 09 > > :02:08 -0700 > > Received: from hermes.intel.com by relay.jf.intel.com with smtp > > (Smail3.1.28.1 #2) id m0sj7OV-000twpC; Thu, 17 Aug 95 09:02 PDT > > > > > ====================================================================== > > This e-mail is from the "roadmap-eii@cfi.org" mailing list. Please > contact > > us at "roadmap-eii-request@cfi.org" for any changes, additions, > deletions > > or adjustments that you might need. Thank you very much. > > > ====================================================================== > > > > > > > > - ------- FORWARD, End of original message ------- > > > > > > ------- End of Forwarded Message > > > ------- FORWARD, End of original message ------- From EGJJ77A@mail.prodigy.com Thu Aug 31 08:56:00 1995 Return-Path: Received: from maily2.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04458; Thu, 31 Aug 95 08:56:00 PDT Received: from mail.prodigy.com (mail [199.4.137.13]) by maily2.prodigy.com (8.6.10/8.6.9) with SMTP id KAA42011 for ; Thu, 31 Aug 1995 10:58:54 -0400 Date: Thu, 31 Aug 1995 11:08:55 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00622924.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: Re: Non-Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Forwarding to the reflector. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Wednesday, 23-Aug-95 09:34 AM > > From: John Brennan \ Internet: (jbrennan@vnet.ibm.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re: Non-Monotonic Drivers > > Arpad, > > Each point on the curve is what you would get if you put a battery DC > voltage at the output of the driver and measured the current through the > pad with all other operating conditions constant. The curves were > generated with multiple DC analysis using ASX(the IBM SPICE program). I do > not think IBIS can handle this today. Specifically, simulation programs > will try to alter the DC curves, and there is nothing that tells them how > to do this(I believe the correct thing to do would be to not alter the > curve). > > Thanks, > John > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > ------------------ Referenced E-Mail ---------------------------- > > Date: Tue, 22 Aug 1995 15:47:55 PST > To: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com > cc: Will_Hobbs@ccm2.jf.intel.com > From: Arpad Muranyi > Subject: Re: Non-Monotonic Drivers > Message-Id: <950822154755_9@ccm.fm.intel.com> > > Text item: > > John, > > Thanks for the graphical response to my question. This is the kind of > response I really wanted to get. I have a question, though. Is this I-V > curve a function of the voltage on the output pin, or time. I mean, is > "translating between two Vgs curves" done with a feedback circuit by > monitoring the output voltage, or is it a function of time as slew rate > controlled devices usually do it? > > If the answer is time, IBIS can definitely do it, but if it is voltage (as > in feedback), IBIS would not be able to help you at this time. However, > the open forum committee did consider this issue in meetings before, and I > don't think that it would be impossible to incorporate features that can > model it. > > Arpad > ======================================================================= == > ===== > Arpad, > > The drivers Ron refers to have the following IV curve shape... > > Ids * * > * * > * * > * * > * **************** > * > * > * > * Vds > > > Instead of the normal transistor curve shape like... > > Ids * *********************** > * > * > * > * > * > * > * > * Vds > > > The top curve comes about because we are manipulating the gate voltage to > control di/dt noise in the maximum Vds region of the large output device. > Essentially we are translating between two Vgs curves for the output > transistor. Hence the non-monotonicity is real and not noise related. > Clamp diodes would add another bend in the curve and create 3 current > values for 1 voltage value. > > The simulation tools we looked at would "correct" the data by making the > top curve look like the bottom. We saw some extreme differences in > benchmark nets after this manipulation from the full transistor > simulation. Since there is no standard on how to "correct" the above > curve, we would not know how various simulation vendors would treat the > model. > > The above and the time schedule of IBIS 2.1 and CMOS 4 makes supporting > the IBIS modeling strategy unattractive for our CMOS 4 products. > > Thanks, > John Brennan > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Tue, 22 Aug 1995 13:34:03 -0400 > Subject: Non-Monotonic Drivers > To: EGJJ77A@prodigy.com, arpad_muranyi@ccm.fm.intel.com, jonp@qdt.com > Message-Id: <9508221734.AA33207@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA33207; Tue, 22 Aug 1995 13:34:05 -0400 > Received: from eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Tue, 22 Aug 1995 13:34:10 -0400 > Received: by BTV (XAGENTA 4.0) id 3245; Tue, 22 Aug 1995 13:35:23 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7677; > Tue, 22 Aug 95 13:38:48 EDT > Received: from vnet.ibm.com by aurora.intel.com (5.65/10.0i); Tue, 22 Aug > 95 10 > : > 38:52 -0700 > Received: from aurora.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0skxGs-000aoAC; Tue, 22 Aug 95 10:37 PDT > > > ------- FORWARD, End of original message ------- From EGJJ77A@mail.prodigy.com Thu Aug 31 08:58:13 1995 Return-Path: Received: from maily2.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04468; Thu, 31 Aug 95 08:58:13 PDT Received: from mail.prodigy.com (mail [199.4.137.13]) by maily2.prodigy.com (8.6.10/8.6.9) with SMTP id KAA36877 for ; Thu, 31 Aug 1995 10:58:42 -0400 Date: Thu, 31 Aug 1995 11:08:38 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00622913.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: Re[2]: Non-Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Forwarding to the reflector. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Wednesday, 23-Aug-95 03:43 PM > > From: Arpad Muranyi \ Internet: > (arpad_muranyi@ccm.fm.intel.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re[2]: Non-Monotonic Drivers > > Text item: > > John, > > Thanks again for your reply. I have mixed feelings about what to say now. > > 1) This kind of a behavior is most likely caused by a feedback circuit in > the buffer. It is true, IBIS currently does not have provisions to > describe buffers with feedback. However, we had discussions on this > subject in the open forum meetings before, and we could pick it up again > if there is a real need for modeling such buffers in IBIS. > > 2) On the other hand, I am not sure if IBIS is to blame for the situation > that you described, that simulators alter the curve this and that way. I > imagined how I would use this data in my HSPICE behavioral (=IBIS) > models. I am using piecewise linear (PWL) sources for the I-V curves. > If I make the voltage values the independent variable, and current the > dependent variable, it will work no problem, because each voltage value > is assigned only one current value. (It doesn't matter whether the > current values are repeated). If I turned it around, however, to have > current values as the independent variable and voltage the dependent one, > it would not work, because the simulator would have to pick between two > or more voltages for one current value. What I am trying to say here is > that this kind of a curve should work, as far as IBIS is concerned (as it > does in my HSPICE behavioral models). It depends on what the simulator > tool does with it. > > Arpad > ======================================================================= == > ==== > Arpad, > > Each point on the curve is what you would get if you put a battery DC > voltage at the output of the driver and measured the current through the > pad with all other operating conditions constant. The curves were > generated with multiple DC analysis using ASX(the IBM SPICE program). I do > not think IBIS can handle this today. Specifically, simulation programs > will try to alter the DC curves, and there is nothing that tells them how > to do this(I believe the correct thing to do would be to not alter the > curve). > > Thanks, > John > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: > > John, > > Thanks for the graphical response to my question. This is the kind > of response > I really wanted to get. I have a question, though. Is this I-V curve a > function of the voltage on the output pin, or time. I mean, is > "translating > between two Vgs curves" done with a feedback circuit by monitoring the > output > voltage, or is it a function of time as slew rate controlled devices > usually do > it? > > If the answer is time, IBIS can definitely do it, but if it is voltage (as > in feedback), IBIS would not be able to help you at this time. However, > the open forum committee did consider this issue in meetings before, and I > don't think that it would be impossible to incorporate features that can > model it. > > Arpad > ======================================================================= == > ===== > > Arpad, > > The drivers Ron refers to have the following IV curve shape... > > Ids * * > * * > * * > * * > * **************** > * > * > * > * Vds > > > Instead of the normal transistor curve shape like... > > Ids * *********************** > * > * > * > * > * > * > * > * Vds > > > The top curve comes about because we are manipulating the gate voltage to > control di/dt noise in the maximum Vds region of the large output device. > Essentially we are translating between two Vgs curves for the output > transistor. Hence the non-monotonicity is real and not noise related. > Clamp diodes would add another bend in the curve and create 3 current > values for 1 voltage value. > > The simulation tools we looked at would "correct" the data by making the > top curve look like the bottom. We saw some extreme differences in > benchmark nets after this manipulation from the full transistor > simulation. Since there is no standard on how to "correct" the above > curve, we would not know how various simulation vendors would treat the > model. > > The above and the time schedule of IBIS 2.1 and CMOS 4 makes supporting > the IBIS modeling strategy unattractive for our CMOS 4 products. > > Thanks, > John Brennan > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Tue, 22 Aug 1995 13:34:03 -0400 > Subject: Non-Monotonic Drivers > To: EGJJ77A@prodigy.com, arpad_muranyi@ccm.fm.intel.com, jonp@qdt.com > Message-Id: <9508221734.AA33207@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA33207; Tue, 22 Aug 1995 13:34:05 -0400 > Received: from eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Tue, 22 Aug 1995 13:34:10 -0400 > Received: by BTV (XAGENTA 4.0) id 3245; Tue, 22 Aug 1995 13:35:23 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7677; > Tue, 22 Aug 95 13:38:48 EDT > Received: from vnet.ibm.com by aurora.intel.com (5.65/10.0i); Tue, > 22 Aug 95 10 > : > 38:52 -0700 > Received: from aurora.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0skxGs-000aoAC; Tue, 22 Aug 95 10:37 PDT > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Wed, 23 Aug 1995 09:01:18 -0400 > In-Reply-To: Your message of Tue, 22 Aug 1995 15:47:55 PST. > <950822154755_9@ccm.fm.intel.com> > Subject: Re: Non-Monotonic Drivers > Cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > To: Arpad Muranyi > Message-Id: <9508231301.AA12722@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA12722; Wed, 23 Aug 1995 09:01:19 -0400 > Received: from eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Wed, 23 Aug 1995 09:01:20 -0400 > Received: by BTV (XAGENTA 4.0) id 3602; Wed, 23 Aug 1995 09:36:15 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2183; > Wed, 23 Aug 95 09:36:24 EDT > Received: from vnet.ibm.com by hermes.intel.com (5.65/10.0i); Wed, 23 Aug > 95 06: > 40:31 -0700 > Received: from hermes.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0slG1j-000algC; Wed, 23 Aug 95 06:39 PDT > > > ------- FORWARD, End of original message ------- From EGJJ77A@mail.prodigy.com Thu Aug 31 08:58:17 1995 Return-Path: Received: from maily2.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04469; Thu, 31 Aug 95 08:58:17 PDT Received: from mail.prodigy.com (mail [199.4.137.13]) by maily2.prodigy.com (8.6.10/8.6.9) with SMTP id KAA36592 for ; Thu, 31 Aug 1995 10:58:25 -0400 Date: Thu, 31 Aug 1995 11:08:16 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00622900.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: Re[4]: Non-Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Forwarding to the reflector. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Wednesday, 23-Aug-95 07:26 PM > > From: Arpad Muranyi \ Internet: > (arpad_muranyi@ccm.fm.intel.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re[4]: Non-Monotonic Drivers > > Text item: > > John, > > I see your point in suggesting a spec on how to handle the I-V curves. > However, I am afraid that this will never happen. We had similar, or even > more important issues surface up in previous Open Forum meetings, yet > these discussions ended with the conclusion that the software tool vendor > should not be told how to do things. That is their specialty, and that > is how they differentiate on the market. Each one of them knows > everything better than the other, so they wouldn't listen anyway. :-) > > You, the user must decide which tool suits your needs the best. > > Arpad > ======================================================================= == > ===== > Arpad, > > I agree 100% with your point #2. In fact non-monoticity was a non- issue > with our ASX simulator because we knew ahead of time that these waveforms > were non-standard. Our ASX analysis did not match up that well because the > Vout vs. Time waveforms were not symmetric about the center voltage, the > shape of the waveform assumed by the vendor tool was different from > actual. IBIS has addressed this in ver 2.1. > > Thus we analyzed the VI cureves and did what you said in #2. The problem > is ofcourse that the standard does not tell one writing a simulation > program how to handle these IV curves. Current programs that I looked at > changed the data to be monotonic, I beleive so they could calculate > impedances. I would imagine different programs would do different things. > I suspect you have seen other non-monotonic drivers that are non- monotonic > for other reasons that may need to be treated different yet. A challenge > would be to write the spec to handle all of the known cases. > > We are not getting sufficient demand for CMOS 4 IBIS models to justify any > lengthy studies on how to model these drivers. > > John > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > ------------------ Referenced E-Mail ---------------------------- > > Date: Wed, 23 Aug 1995 10:46:08 PST > cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > From: Arpad Muranyi > Subject: Re[2]: Non-Monotonic Drivers > Message-Id: <950823104608_4@ccm.fm.intel.com> > > Text item: > > John, > > Thanks again for your reply. I have mixed feelings about what to say now. > > 1) This kind of a behavior is most likely caused by a feedback circuit in > the > buffer. It is true, IBIS currently does not have provisions to describe > buffer > s > with feedback. However, we had discussions on this subject in the open > forum > meetings before, and we could pick it up again if there is a real need for > modeling such buffers in IBIS. > > 2) On the other hand, I am not sure if IBIS is to blame for the situation > that > you described, that simulators alter the curve this and that way. I > imagined > how I would use this data in my HSPICE behavioral (=IBIS) models. I am > using > piecewise linear (PWL) sources for the I-V curves. If I make the > voltage value > s > the independent variable, and current the dependent variable, it will work > no > problem, because each voltage value is assigned only one current value. > (It > doesn't matter whether the current values are repeated). If I turned > it around > , > however, to have current values as the independent variable and voltage > the dependent one, it would not work, because the simulator would have to > pick between two or more voltages for one current value. What I am trying > to say here is that this kind of a curve should work, as far as IBIS is > concerned (as it does in my HSPICE behavioral models). It depends on what > the simulator tool does with it. > > Arpad > ======================================================================= == > ==== > Arpad, > > Each point on the curve is what you would get if you put a battery DC > voltage at the output of the driver and measured the current through the > pad with all other operating conditions constant. The curves were > generated with multiple DC analysis using ASX(the IBM SPICE program). I do > not think IBIS can handle this today. Specifically, simulation programs > will try to alter the DC curves, and there is nothing that tells them how > to do this(I believe the correct thing to do would be to not alter the > curve). > > Thanks, > John > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: > > John, > > Thanks for the graphical response to my question. This is the kind > of response > I really wanted to get. I have a question, though. Is this I-V curve a > function of the voltage on the output pin, or time. I mean, is > "translating > between two Vgs curves" done with a feedback circuit by monitoring the > output > voltage, or is it a function of time as slew rate controlled devices > usually do > it? > > If the answer is time, IBIS can definitely do it, but if it is voltage (as > in feedback), IBIS would not be able to help you at this time. However, > the open forum committee did consider this issue in meetings before, and I > don't think that it would be impossible to incorporate features that can > model it. > > Arpad > ======================================================================= == > ===== > > > Arpad, > > The drivers Ron refers to have the following IV curve shape... > > Ids * * > * * > * * > * * > * **************** > * > * > * > * Vds > > > Instead of the normal transistor curve shape like... > > Ids * *********************** > * > * > * > * > * > * > * > * Vds > > > The top curve comes about because we are manipulating the gate voltage to > control di/dt noise in the maximum Vds region of the large output device. > Essentially we are translating between two Vgs curves for the output > transistor. Hence the non-monotonicity is real and not noise related. > Clamp diodes would add another bend in the curve and create 3 current > values for 1 voltage value. > > The simulation tools we looked at would "correct" the data by making the > top curve look like the bottom. We saw some extreme differences in > benchmark nets after this manipulation from the full transistor > simulation. Since there is no standard on how to "correct" the above > curve, we would not know how various simulation vendors would treat the > model. > > The above and the time schedule of IBIS 2.1 and CMOS 4 makes supporting > the IBIS modeling strategy unattractive for our CMOS 4 products. > > Thanks, > John Brennan > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Tue, 22 Aug 1995 13:34:03 -0400 > Subject: Non-Monotonic Drivers > To: EGJJ77A@prodigy.com, arpad_muranyi@ccm.fm.intel.com, jonp@qdt.com > Message-Id: <9508221734.AA33207@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA33207; Tue, 22 Aug 1995 13:34:05 -0400 Received: from > eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Tue, 22 Aug 1995 13:34:10 -0400 > Received: by BTV (XAGENTA 4.0) id 3245; Tue, 22 Aug 1995 13:35:23 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7677; > Tue, 22 Aug 95 13:38:48 EDT > Received: from vnet.ibm.com by aurora.intel.com (5.65/10.0i); Tue, 22 Aug > 95 10 > : > 38:52 -0700 > Received: from aurora.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0skxGs-000aoAC; Tue, 22 Aug 95 10:37 PDT > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Wed, 23 Aug 1995 09:01:18 -0400 > In-Reply-To: Your message of Tue, 22 Aug 1995 15:47:55 PST. > <950822154755_9@ccm.fm.intel.com> > Subject: Re: Non-Monotonic Drivers > Cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > To: Arpad Muranyi > Message-Id: <9508231301.AA12722@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA12722; Wed, 23 Aug 1995 09:01:19 -0400 Received: from > eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Wed, 23 Aug 1995 09:01:20 -0400 > Received: by BTV (XAGENTA 4.0) id 3602; Wed, 23 Aug 1995 09:36:15 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2183; > Wed, 23 Aug 95 09:36:24 EDT > Received: from vnet.ibm.com by hermes.intel.com (5.65/10.0i); Wed, 23 Aug > 95 06 > : > 40:31 -0700 > Received: from hermes.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0slG1j-000algC; Wed, 23 Aug 95 06:39 PDT > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Wed, 23 Aug 1995 16:22:17 -0400 > In-Reply-To: Your message of Wed, 23 Aug 1995 10:46:08 PST. > <950823104608_4@ccm.fm.intel.com> > Subject: Re: Re[2]: Non-Monotonic Drivers > Cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > To: Arpad Muranyi > Message-Id: <9508232022.AA27032@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA27032; Wed, 23 Aug 1995 16:22:19 -0400 Received: from > eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Wed, 23 Aug 1995 16:23:16 -0400 > Received: by BTV (XAGENTA 4.0) id 3950; Wed, 23 Aug 1995 16:29:18 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1866; > Wed, 23 Aug 95 16:29:25 EDT > Received: from vnet.ibm.com by hermes.intel.com (5.65/10.0i); Wed, 23 Aug > 95 13: > 29:31 -0700 > Received: from hermes.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0slMPX-000altC; Wed, 23 Aug 95 13:28 PDT > > > ------- FORWARD, End of original message ------- From EGJJ77A@mail.prodigy.com Thu Aug 31 09:16:40 1995 Return-Path: Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04745; Thu, 31 Aug 95 09:16:40 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by inetgate.prodigy.com (8.6.10/8.6.9) with SMTP id KAA54242 for ; Thu, 31 Aug 1995 10:57:54 -0400 Date: Thu, 31 Aug 1995 11:07:32 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.00622865.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: Re[6]: Non-Monotonic Drivers -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Forwarding to the reflector. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Thursday, 24-Aug-95 11:31 AM > > From: Will Hobbs \ Internet: > (will_hobbs@ccm2.jf.intel.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Re[6]: Non-Monotonic Drivers > > Text item: > > John, > > Thet V/T curves with reference load in IBIS 2.1 address the problem of > simulator accuracy by providing actual expected results under known > conditions. Multiple such curve/load pairs can be included in the model > file and can be used by the end customer to check the simulator's > handling of the data. > > Will > > Arpad, > > Yes, and that is exactly what we did... CMOS 4 SI tool was IBM ANDAP (we > already had the models done). Since we are ASIC library suppliers, we > actually let our customers decide which tool where practical. > > Ofcourse we could as a silicon vendor just put the IBIS data out there > and give the user enough rope to hang themselves(user beware), or put the > burden on the Simulation vendor to handle. Sounds like that's what they > are asking for by keeping it out of the spec. Generating IBIS data is > easy, making sure it simulates right is another story. > > Thanks, > John > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > ------------------ Referenced E-Mail ---------------------------- > > Date: Wed, 23 Aug 1995 14:54:11 PST > cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > From: Arpad Muranyi > Subject: Re[4]: Non-Monotonic Drivers > Message-Id: <950823145411_1@ccm.fm.intel.com> > > Text item: > > John, > > I see your point in suggesting a spec on how to handle the I-V curves. > However > , > I am afraid that this will never happen. We had similar, or even more > importan > t > issues surface up in previous Open Forum meetings, yet these discussions > ended > with the conclusion that the software tool vendor should not be told how > to do > things. That is their specialty, and that is how they differentiate on > the > market. Each one of them knows everything better than the other, so they > wouldn't listen anyway. :-) > > You, the user must decide which tool suits your needs the best. > > Arpad > ======================================================================= == > ===== > Arpad, > > I agree 100% with your point #2. In fact non-monoticity was a non- issue > with our ASX simulator because we knew ahead of time that these waveforms > were non-standard. Our ASX analysis did not match up that well because the > Vout vs. Time waveforms were not symmetric about the center voltage, the > shape of the waveform assumed by the vendor tool was different from > actual. IBIS has addressed this in ver 2.1. > > Thus we analyzed the VI cureves and did what you said in #2. The problem > is ofcourse that the standard does not tell one writing a simulation > program how to handle these IV curves. Current programs that I looked at > changed the data to be monotonic, I beleive so they could calculate > impedances. I would imagine different programs would do different things. > I suspect you have seen other non-monotonic drivers that are non- monotonic > for other reasons that may need to be treated different yet. A challenge > would be to write the spec to handle all of the known cases. > > We are not getting sufficient demand for CMOS 4 IBIS models to justify any > lengthy studies on how to model these drivers. > > John > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > ------------------ Referenced E-Mail ---------------------------- > > Date: Wed, 23 Aug 1995 10:46:08 PST > cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > From: Arpad Muranyi > Subject: Re[2]: Non-Monotonic Drivers > Message-Id: <950823104608_4@ccm.fm.intel.com> > > Text item: > > John, > > Thanks again for your reply. I have mixed feelings about what to say now. > > 1) This kind of a behavior is most likely caused by a feedback circuit in > the > buffer. It is true, IBIS currently does not have provisions to describe > buffer > s > with feedback. However, we had discussions on this subject in the open > forum > meetings before, and we could pick it up again if there is a real need for > modeling such buffers in IBIS. > > 2) On the other hand, I am not sure if IBIS is to blame for the situation > that > you described, that simulators alter the curve this and that way. I > imagined > how I would use this data in my HSPICE behavioral (=IBIS) models. I am > using > piecewise linear (PWL) sources for the I-V curves. If I make the > voltage value > s > the independent variable, and current the dependent variable, it will work > no > problem, because each voltage value is assigned only one current value. > (It > doesn't matter whether the current values are repeated). If I turned > it around > , > however, to have current values as the independent variable and voltage > the dependent one, it would not work, because the simulator would have to > pick between two or more voltages for one current value. What I am trying > to say here is that this kind of a curve should work, as far as IBIS is > concerned (as it does in my HSPICE behavioral models). It depends on what > the simulator tool does with it. > > Arpad > ======================================================================= == > ==== > Arpad, > > Each point on the curve is what you would get if you put a battery DC > voltage at the output of the driver and measured the current through the > pad with all other operating conditions constant. The curves were > generated with multiple DC analysis using ASX(the IBM SPICE program). I do > not think IBIS can handle this today. Specifically, simulation programs > will try to alter the DC curves, and there is nothing that tells them how > to do this(I believe the correct thing to do would be to not alter the > curve). > > Thanks, > John > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: > > John, > > Thanks for the graphical response to my question. This is the kind > of response > I really wanted to get. I have a question, though. Is this I-V curve a > function of the voltage on the output pin, or time. I mean, is > "translating > between two Vgs curves" done with a feedback circuit by monitoring the > output > voltage, or is it a function of time as slew rate controlled devices > usually do > it? > > If the answer is time, IBIS can definitely do it, but if it is voltage (as > in feedback), IBIS would not be able to help you at this time. However, > the open forum committee did consider this issue in meetings before, and I > don't think that it would be impossible to incorporate features that can > model it. > > Arpad > ======================================================================= == > ===== > > > Arpad, > > The drivers Ron refers to have the following IV curve shape... > > Ids * * > * * > * * > * * > * **************** > * > * > * > * Vds > > > Instead of the normal transistor curve shape like... > > Ids * *********************** > * > * > * > * > * > * > * > * Vds > > > The top curve comes about because we are manipulating the gate voltage to > control di/dt noise in the maximum Vds region of the large output device. > Essentially we are translating between two Vgs curves for the output > transistor. Hence the non-monotonicity is real and not noise related. > Clamp diodes would add another bend in the curve and create 3 current > values for 1 voltage value. > > The simulation tools we looked at would "correct" the data by making the > top curve look like the bottom. We saw some extreme differences in > benchmark nets after this manipulation from the full transistor > simulation. Since there is no standard on how to "correct" the above > curve, we would not know how various simulation vendors would treat the > model. > > The above and the time schedule of IBIS 2.1 and CMOS 4 makes supporting > the IBIS modeling strategy unattractive for our CMOS 4 products. > > Thanks, > John Brennan > > *********************************************************************** > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > G77V/862-1 Tel: 802-769-6982 (Tie-Line: 446) > Burlington, VT Fax: 802-769-5882 (Tie-Line: 446) > *********************************************************************** > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Tue, 22 Aug 1995 13:34:03 -0400 > Subject: Non-Monotonic Drivers > To: EGJJ77A@prodigy.com, arpad_muranyi@ccm.fm.intel.com, jonp@qdt.com > Message-Id: <9508221734.AA33207@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA33207; Tue, 22 Aug 1995 13:34:05 -0400 Received: from > eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Tue, 22 Aug 1995 13:34:10 -0400 > Received: by BTV (XAGENTA 4.0) id 3245; Tue, 22 Aug 1995 13:35:23 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7677; > Tue, 22 Aug 95 13:38:48 EDT > Received: from vnet.ibm.com by aurora.intel.com (5.65/10.0i); Tue, 22 Aug > 95 10 > : > 38:52 -0700 > Received: from aurora.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0skxGs-000aoAC; Tue, 22 Aug 95 10:37 PDT > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Wed, 23 Aug 1995 09:01:18 -0400 > In-Reply-To: Your message of Tue, 22 Aug 1995 15:47:55 PST. > <950822154755_9@ccm.fm.intel.com> > Subject: Re: Non-Monotonic Drivers > Cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > To: Arpad Muranyi > Message-Id: <9508231301.AA12722@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA12722; Wed, 23 Aug 1995 09:01:19 -0400 Received: from > eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Wed, 23 Aug 1995 09:01:20 -0400 > Received: by BTV (XAGENTA 4.0) id 3602; Wed, 23 Aug 1995 09:36:15 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2183; > Wed, 23 Aug 95 09:36:24 EDT > Received: from vnet.ibm.com by hermes.intel.com (5.65/10.0i); Wed, 23 Aug > 95 06 > : > 40:31 -0700 > Received: from hermes.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0slG1j-000algC; Wed, 23 Aug 95 06:39 PDT > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Wed, 23 Aug 1995 16:22:17 -0400 > In-Reply-To: Your message of Wed, 23 Aug 1995 10:46:08 PST. > <950823104608_4@ccm.fm.intel.com> > Subject: Re: Re[2]: Non-Monotonic Drivers > Cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > To: Arpad Muranyi > Message-Id: <9508232022.AA27032@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA27032; Wed, 23 Aug 1995 16:22:19 -0400 Received: from > eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Wed, 23 Aug 1995 16:23:16 -0400 > Received: by BTV (XAGENTA 4.0) id 3950; Wed, 23 Aug 1995 16:29:18 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1866; > Wed, 23 Aug 95 16:29:25 EDT > Received: from vnet.ibm.com by hermes.intel.com (5.65/10.0i); Wed, 23 Aug > 95 13 > : > 29:31 -0700 > Received: from hermes.intel.com by fmmail.fm.intel.com with smtp > (Smail3.1.28.1 #2) id m0slMPX-000altC; Wed, 23 Aug 95 13:28 PDT > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > From: "John Brennan" > Date: Thu, 24 Aug 1995 09:47:13 -0400 > In-Reply-To: Your message of Wed, 23 Aug 1995 14:54:11 PST. > <950823145411_1@ccm.fm.intel.com> > Subject: Re: Re[4]: Non-Monotonic Drivers > Cc: jbrennan@VNET.IBM.COM, EGJJ77A@prodigy.com, jonp@qdt.com, > Will_Hobbs@ccm2.jf.intel.com > To: Arpad Muranyi > Message-Id: <9508241347.AA19141@btv.ibm.com> > Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) > id AA19141; Thu, 24 Aug 1995 09:47:14 -0400 Received: from > eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) > id ; Thu, 24 Aug 1995 09:47:16 -0400 > Received: by BTV (XAGENTA 4.0) id 4274; Thu, 24 Aug 1995 09:47:23 - 0400 > Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2142; > Thu, 24 Aug 95 09:47:29 EDT > Received: from vnet.ibm.com by hermes.intel.com (5.65/10.0i); Thu, 24 Aug > 95 06: > 49:32 -0700 > Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 24 > Aug 9 > 5 06:49:41 -0700 > Received: from ichips.intel.com by relay.jf.intel.com with smtp > (Smail3.1.28.1 #2) id m0slcfA-000twiC; Thu, 24 Aug 95 06:49 PDT > > > ------- FORWARD, End of original message ------- From contec!contec.contec.COM!dileep@netcom.com Thu Aug 31 15:28:04 1995 Return-Path: Received: from netcomsv.netcom.com (uucp5.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08072; Thu, 31 Aug 95 15:28:04 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA22714; Thu, 31 Aug 1995 14:47:24 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA12087; Thu, 31 Aug 95 14:19:33 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA02476; Thu, 31 Aug 1995 14:22:07 +0800 Date: Thu, 31 Aug 1995 14:22:07 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9508312122.AA02476@contec13.contec.COM> To: ibis@vhdl.org Subject: Non-Monotonic Drivers Cc: EGJJ77A@prodigy.com, jbrennan@vnet.ibm.com, dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 1728 My understanding of the non-monotonic behavior being discussed here is as follows. An I-V table is specified, where I is the dependent variable and V is the independent variable. V values are strictly monotonically increasing. The corresponding I values are non-monotonic i.e., for a certain range of V, I decreases as V increases; but the I values are unique i.e., for each V value, there is only one I value. I do not see why such a table cannot be used. As far as the Golden Parser is concerned, it will issue a warning, but it will not prevent the user from specifying such data. As far as the simulators are concerned, the simulator I work on, will be able to use that data without any problems. I think that some other simulators give "error" messages or "correct" such a data because they assume that such a device does not exist and therefore, the user may have made a mistake in specifying that information. If they know that the specification is intentional, then they may be able to use that data with very minor modifications to the simulator. Of course, it is possible to connect such a device in some topologies where the circuit will be unstable or may have multiple stable points. Then, the simulations will have problems. But if the device is connected so that the circuit has a well defined behavior, then it will be possible to simulate the circuit. This will be the case for most of the signal integrity applications. Dileep Divekar ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From Arpad_Muranyi@ccm.fm.intel.com Thu Aug 31 16:27:28 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08412; Thu, 31 Aug 95 16:27:28 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0soIu3-000Ug2C; Thu, 31 Aug 95 16:20 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0soIu3-000txZC; Thu, 31 Aug 95 16:20 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 31 Aug 95 16:20:11 PDT Date: Thu, 31 Aug 95 16:06:00 PDT From: Arpad Muranyi Message-Id: To: ibis@vhdl.org Cc: dileep@contec.contec.COM Subject: Re: Non-Monotonic Drivers Text item: Dileep, I tend to agree. I am just curious which tool you are referring to. Would you be able to disclose that info to us? Arpad ========================================================================== My understanding of the non-monotonic behavior being discussed here is as follows. An I-V table is specified, where I is the dependent variable and V is the independent variable. V values are strictly monotonically increasing. The corresponding I values are non-monotonic i.e., for a certain range of V, I decreases as V increases; but the I values are unique i.e., for each V value, there is only one I value. I do not see why such a table cannot be used. As far as the Golden Parser is concerned, it will issue a warning, but it will not prevent the user from specifying such data. As far as the simulators are concerned, the simulator I work on, will be able to use that data without any problems. I think that some other simulators give "error" messages or "correct" such a data because they assume that such a device does not exist and therefore, the user may have made a mistake in specifying that information. If they know that the specification is intentional, then they may be able to use that data with very minor modifications to the simulator. Of course, it is possible to connect such a device in some topologies where the circuit will be unstable or may have multiple stable points. Then, the simulations will have problems. But if the device is connected so that the circuit has a well defined behavior, then it will be possible to simulate the circuit. This will be the case for most of the signal integrity applications. Dileep Divekar ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Length: 1728 X-Sun-Charset: US-ASCII Cc: EGJJ77A@prodigy.com, jbrennan@vnet.ibm.com, dileep@contec.contec.COM Subject: Non-Monotonic Drivers To: ibis@vhdl.org Message-Id: <9508312122.AA02476@contec13.contec.COM> From: dileep@contec.contec.COM (Dileep Divekar) Date: Thu, 31 Aug 1995 14:22:07 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA02476; Thu, 31 Aug 1995 14:22:07 +0800 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA12087; Thu, 31 Aug 95 14:19:33 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA22714; Thu, 31 Aug 1995 14:47:24 -0700 Received: from netcomsv.netcom.com (uucp5.netcom.com) by vhdl.vhdl.org (4.1/SMI- 4.1/BARRNet) id AA08072; Thu, 31 Aug 95 15:28:04 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 31 Aug 95 15 :23:16 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soI14-000tx7C; Thu, 31 Aug 95 15:23 PDT From bob@icx.com Thu Aug 31 17:19:33 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08844; Thu, 31 Aug 95 17:19:33 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 31 Aug 95 17:12 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 31 Aug 95 17:14 PDT Message-Id: Date: Thu, 31 Aug 95 17:14 PDT From: bob@icx.com ( Bob Ross) To: 73053.721@compuserve.com, 75123.3477@compuserve.com, ibis@vhdl.org Subject: IBIS TEST MATRIX BETA 9 Hello Fellow IBISans, Paul and Ron: The problems I reported for Beta 8 have been checked and are fixed. For the record, the perfect Test Matrix documents what has been tested. I think the parser is really excellent for serving as a thorough checking tool. It also serves well as the defacto interpretion for some of the fine points of IBIS Version 2.1. Assuming no problems surface in the next week(s), the release copy of ibischk2 (no longer a Beta copy) can be produced. Then the executables for various machines can be made available on vhdl.org under /pub/ibis/ibischk2. Thank you Ron and Paul! Bob Ross Interconnectix, Inc. A TEST MATRIX FOR IBIS VERSION 2i (Beta 9) DATE: 10/31/94, 12/2/94, 1/26/95, 3/4/95, 3/8/95 5/25/95 7/6/95, 8/16/95 8/31/95 SPECIFICATION TESTED PASS Comments/who tested --------------------------------------+-----+-----------------------------+ Test that the parser only | | | accepts 1.0, 1.1, 2.0, 2.1 as | | | valid arguments to the [IBIS Ver] | yes | Stephen Peters | keyword. | | | | | | Tab character warning | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Scaling Factors: | | | | | | Test that the parser recognizes | | | "T", "G" and "f" as valid scaling | yes | No indication either way | factors. | | Bob Ross - this is proper | | | operation | Test that the parser does not | | | recognize "t", "g" and "F" as | yes | No indication either way | Valid scaling factors. | | Bob Ross - proper operation | | | | --------------------------------------+-----+-----------------------------+ Keywords rules: | | | | | | Test that the parser recognizes | | | the [GND clamp] and [PWR clamp] | yes | Stephen Peters | keywords without the underscore. | | | Test Underscore rule for 3-word | yes | Bob Ross | Keyoreds - all 4 cases. | | | | | | Test that the parser issues an | | | error if a keyword does not begin | yes | Stephen Peters | in column 1. | | | | | | Test case insensitivity of all | | | keywords, reserved words and | yes | Pin mapping keyword does not| sub-parameters | | recognize "power" and "gnd" | | | Bob Ross - OK, should be | | | "pulldown_ref", "pullup_ref,| | | "gnd_clamp_ref", and | | | "power_clamp_ref" | | | | --------------------------------------+-----+-----------------------------+ Comments and Notes: | | | | | | Test that the parser does not | | | accept "+" and "-" as valid | yes | Stephen Peters | comment characters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Copyright] keyword. | | | | | | | | | --------------------------------------+-----+-----------------------------+ Component keyword related: | | | | | | Test that the parser issues an | | | error if the [Component] keyword | yes | Stephen Peters | has no component name after it. | | | | | | Test that the parser issues a warning | | | if the component name contains blanks | yes | Stephen Peters | | | | Test the component name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | " | parser fails if name > 40 characters | yes | " | | | | Test that the parser issues an | | | error if the [Manufacture] keyword | yes | Stephen Peters | has no Manufactures name after it. | | | | | | Test the Manufactures name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | Stephen Peters | parser fails if name > 40 characters | yes | Stephen Peters | | | | Test that an .ibs file can contain | yes | Bob Ross | more than one [Component] keyword | | | and component description. | | | | | | --------------------------------------+-----+-----------------------------+ Pin keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin] keyword. | | | | | | Test that the parser issues a | | | error when every model_name does | yes | Bob Ross | not have a corresponding model | | (I don't see the problem) | defined. | | | | | | Test the "3 column or 6 column" | | | rule. | yes | Stephen Peters | | | | Test that the parser issues an error | | | when non-numeric data is in the pin | yes | Stephen Peters | data columns | | | | | | Test that [Pin] entries agree with | yes | Bob Ross | [Pin Numbers] entries if the [Package | | Fixed | Model] keyword is used. | | | | | | --------------------------------------+-----+-----------------------------+ Package Model related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Package Model] keyword. | | | | | | Test the package model name length | yes | Bob Ross | rules | | Fixed: | parser accepts name < 40 characters | yes | Name is taken as a DOS file | parser accepts name = 40 characters | yes | name and not as argument to | parser fails if name > 40 characters | yes | the [Define Package Model] | | | keyword | Verify that the parser issues an | | | error if it cannot find: | | | | | | 1. A [Define Package Model] keyword | | | that has the same argument as the | yes | Bob Ross | [Package Model] keyword or | | | | | | 2. An external .pkg file that has | yes | Bob Ross | a [Define Package Model] keyword | | | with has the same argument as the | | | [Package Model] keyword. | | | | | | 3. Test that the parser recognizes | | | all keywords in the package model | | | description and operation below: | | | (1) Error if Missing | | | (2) Error if Duplicate | | | (3) Error if Wrong Argument | | | [Define Package Model] 1,2,3 | yes | Bob Ross | [Manufacturer] 1,2,3 | yes | | [OEM] 1,2,3 | yes | | [Description] 1,2,3 | yes | | [Number of Pins] 1,2,3 | yes | fixed | [Pin Numbers] 1,2,3 | yes | | [Model Data] 1,2 | yes | | [Resistance Matrix] 2,3 | yes | | [Inductance Matrix] 1,2,3 | yes | | [Capacitance Matrix] 1,2,3 | yes | | [Bandwidth] 1,2,3 | yes | fixed | [Row] 1,2,3 | yes | (problems below) | [End Model Data] 1,2 | yes | Bob Ross | [End Package Data] 1,2 | yes | " | | | | | | | 4. Full_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] number entry (all rows entered) | yes | fixed | [Row] number entry (ascending order) | yes | | [Row] format (upper triange matrix) | yes | fixed | [Row] format (excessive data) | yes | | [Row] format (missing data) | yes | fixed | | | | 5. Banded_matrix Tests | | Bob Ross | [Bandwidth] req'd test | yes | fixed | [Bandwidth] argument req'd | yes | | [Bandwidth] argument value | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] number entry (all rows entered) | yes | | [Row] number entry (ascending order) | yes | | [Row] format (excessive data) | yes | | [Row] format (missing data) | yes | fixed | [Row] format non-circular coupling | yes | | [Row] format circular coupling (cc) | yes | BIRD29.2 fixed | [Row] format bandwidth limits (cc) | yes | BIRD29.2 fixed | | | | 6. Sparse_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | yes | fixed | [Row] number entry (repeated) | yes | fixed | [Row] number entry (all rows entered) | yes | fixed | [Row] number entry (ascending order) | yes | fixed | [Row] index match | yes | | [Row] index upper-triangle | yes | fixed | [Row] index repeated | yes | | [Row] index (alpha string) | yes | Fixed | [Row] format (excessive data) | yes | fixed | [Row] format (missing data) | yes | fixed | | | | --------------------------------------+-----+-----------------------------+ Pin Mapping keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin Mapping] keyword. | | | | | | Test that the parser issues an | | | error if every pin listed in the | yes | Bob Ross - fixed | [Pin] keyword does not have an | | | entry in the [Pin Mapping] table | | | | | | Test the "3 column or 5 column" | yes | Stephen Peters | rule. | | | | | | Test that NC is a valid entry | | | in a column. | yes | Stephen Peters | | | | Test that each unique entry label | | | must connect to at least one pin | | | whose model name is POWER or GND | yes | Stephen Peters | | | | Test that NA is NOT a valid | | | column entry | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Diff Pin keyword related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Diff Pin] keyword. | | | | | | Test that the parser recognizes | yes | Bob Ross | the 5 associated sub-parameters | | | | | | Test the "4 column or 6 column" | yes | Bob Ross | rule. | | | | | | Test that NC is NOT a valid | yes | Bob Ross | column entry. | | | | | | Test that NA is a valid column | yes | Bob Ross | entry. | | | | | | Reports error for duplicate pin | yes | Bob Ross | numbers. | | | | | | --------------------------------------+-----+-----------------------------+ [Model] keyword: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Model] keyword. | | | | | | Test that the parser recognizes | | | each Model_type: | | | Input | yes | Bob Ross | Output | yes | | I/O | yes | | 3-state | yes | | Open_drain | yes | | I/O_open_drain | yes | | Open_sink | yes | | I/O_open_sink | yes | | Open_source | yes | | I/O_open_source | yes | | Input_ECL | yes | | Output_ECL | yes | | I/O_ECL | yes | | Terminator | yes | | | | | Test that the parser issues | | | a warning if an input type model | yes | Stephen Peters | does not have Vinh or Vinl defined. | | | For All I/O_* cases. | yes | Bob Ross | | | | | | | Test that the parser issues an | | | error if the Model_type or C_comp | yes | Stephen Peters | sub-parameters are missing. | | | | | | Test that the parser accepts a | | | [Model] description with only the | | | Model_type and C_comp sub-params | yes | Stephen Peters | defined. | | | | | | Test that the parser allows NA in | | | the min and max columns only of the | yes | Stephen Peters | C_Comp sub-parameter. | | | | | | Test that the parser allows only | | | Non-inverting and Inverting as | yes | Stephen Peters | choices for the Polarity sub-param | | | | | | Test that the parser allows only | | | Active-High and Active-Low as | yes | Stephen Peters | choices for the Enable sub-param | | | | | | Test that the parser recognizes | | | the Vmeas, Cref, Rref and Vref | yes | Stephen Peters | sub-parameters. | | | | | | --------------------------------------+-----+-----------------------------+ Temperature keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Temperature Range] keyword | | | | | | --------------------------------------+-----+-----------------------------+ Power supply rail related: | | | | | | Test that the parser recognizes | | | the supply rail keywords | | | [Voltage Range] | yes | Stephen Peters | [Pullup Reference] | " | | [Pulldown Reference] | " | | [POWER Clamp Reference] | " | | [GND Clamp Reference] | " | | | | | Test that the parser issues an | | | error if the [Voltage Range] | | | keyword is absent and all four of | | | the other supply rail keywords are | yes | Stephen Peters | NOT present. | | | | | | --------------------------------------+-----+-----------------------------+ I/V table related: | | | | | | Test that the parser recognizes | | | the [Pullup], [Pulldown], [GND | yes | Stephen Peters | Clamp] and [Power Clamp] keywords. | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | Test that the parser issues an | yes | Bob Ross | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Stephen Peters | than two points. | | | | | | Test that the parser issues a | yes | Bob Ross | warning if non-monotonic data | | | is found. | | | Test for One Warning per Column | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Terminator related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Rgnd], [Rpower], [Rac] and | | | [Cac] keywords. | | | | | | Test if [Rac], then [Cac] req'd. | yes | Bob Ross | | | | Test if [Cac], then [Rac] req'd. | yes | Bob Ross | | | | Test if parser issues an error with | | | above keywords AND Model_type is NOT | yes | Bob Ross | Terminator. | | | | | | Test that parser DOES NOT issue an | yes | Bob Ross | error if above models are NOT | | | defined. (Clamps or no components | | | can also be "Terminators") | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | --------------------------------------+-----+-----------------------------+ Ramp keyword related: | | | | | | Test that the parser recognizes | | | the [Ramp] keyword and the | yes | Stephen Peters | dv/dt_r and dv/dt_f sub-parameters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the R_load sub-parameter. | | | | | | Test that the R_load sub-parameter | yes | Stephen Peters | is optional. | | | | | | --------------------------------------+-----+-----------------------------+ Waveform Related: | | | | | | Test that the parser recognizes | | | the [Rising Waveform] and [Falling | yes | Bob Ross | Waveform] keywords. | | | | | | Test that the parser recognizes | | | the sub-parameters: | | | R_fixture | yes | Bob Ross | V_fixture | yes | | V_fixture_max | yes | | V_fixture_min | yes | | C_fixture | yes | | L_fixture | yes | | R_dut | yes | | L_dut | yes | | C_dut | yes | | | | | Test that the parser issues an | | | error if the R_fixture and | yes | Bob Ross | V_fixture sub-parameters are not | | | present. | | | | | | Test that the parser issues an | | | error if a column contains over | yes | Bob Ross | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Bob Ross | than two points. | | | | | | Test NA permitted in typical column | yes | Bob Ross | --------------------------------------+-----+-----------------------------+ From bob@icx.com Thu Aug 31 18:03:28 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09114; Thu, 31 Aug 95 18:03:28 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 31 Aug 95 17:56 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 31 Aug 95 17:59 PDT Message-Id: Date: Thu, 31 Aug 95 17:59 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: On Non-Monotonic Drivers To All: Based on the discussions and clarifications, I would conclude that (1) IBIS Version 2.1 provides a format which can legally characterize the IV curves. It also could characterize resulting waveforms for given test loads, although I have not seen details on the dynamic switching characteristics and possible artifacts. (2) From what has been stated, some simulation approaches would not have have difficulty with the VI non-monotonicity. The real concerns are: (1) Different simulators may take different approaches including filtering the data to produce significantly different simulations. (However, if we do not have access to source data, we cannot validate that any of the approaches will produce an acceptable simulation.) (2) There exists a well-defined feedback reason for producing this type of non-monotonicity. So the correct simulation MAY depend on knowing exactly the mechanism. The simulators may have to include the mechanism, and IBIS may need to be extended to characterize it by its parameters. The questions I have are: (1) Is there a way to accurately characterize the mechanism without revealing the proprietary details from a black box point of view? What are its critical parameters? (2) Because there exists a negative resistance region, are there any load constraints associated with the technology (e.g., an impedance range)? (3) Could a simplified Spice test case be revealed which illustrates the effect, and from which simulation approaches could be checked? Bob Ross, Interconnectix, Inc. From uunet!qdt.com!jonp@uunet.uu.net Thu Aug 31 18:15:30 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09232; Thu, 31 Aug 95 18:15:30 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzffw04984; Thu, 31 Aug 1995 21:08:33 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 31 Aug 1995 21:08:34 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01233; Thu, 31 Aug 95 17:07:41 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA23469; Thu, 31 Aug 95 17:07:41 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzffs24861; Thu, 31 Aug 1995 20:06:29 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 31 Aug 1995 20:06:30 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01197; Thu, 31 Aug 95 16:57:17 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA23431; Thu, 31 Aug 95 16:57:18 PDT Date: Thu, 31 Aug 95 16:57:18 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9508312357.AA23431@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA24907; Thu, 31 Aug 95 16:57:16 PDT To: uunet!uunet!contec.contec.COM!dileep@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!prodigy.com!EGJJ77A@uunet.uu.net, uunet!uunet!vnet.ibm.com!jbrennan@uunet.uu.net, uunet!uunet!contec.contec.COM!dileep@uunet.uu.net In-Reply-To: <9508312122.AA02476@contec13.contec.COM> (uunet!contec.contec.COM!dileep) Subject: Re: Non-Monotonic Drivers >>As far as the simulators are concerned, the >>simulator I work on, will be able to use that >>data without any problems. I think that some >>other simulators give "error" messages or >>"correct" such a data because they assume that >>such a device does not exist and therefore, the >>user may have made a mistake in specifying that >>information. If they know that the specification >>is intentional, then they may be able to use that >>data with very minor modifications to the simulator. I disagree with this accessment. Unless the feedback speed of the path is known an accurate guess cannot be made as to how to simulate the device. Of course, if the feedback path just doesn't matter then it doesn't so much matter what you guess. I would like us to explore a mechanism for behaviorally defining this feedback path/speed. At the very outside, I have seen two different devices that had non-monotonic IV curves that looked approximately the same at DC. One had a feedback path that was 20ns (it was only used for changing the long term DC operating point of the device) and another had a feedback path that was "instantaneous". It is my claim that these two devices would have different simulations even though they would have identical IBIS models. that is all. jon From fvance@FirePower.COM Thu Aug 31 19:13:34 1995 Return-Path: Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09553; Thu, 31 Aug 95 19:13:34 PDT Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA15088; Thu, 31 Aug 95 19:05:26 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14506; Thu, 31 Aug 95 19:05:23 -0700 From: Fred Vance Message-Id: <9509010205.AA14506@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA00780; Thu, 31 Aug 95 19:05:21 -0700 Date: Thu, 31 Aug 95 19:05:21 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: bob@icx.com ( Bob Ross) Subject: Re: On Non-Monotonic Drivers Cc: ibis@vhdl.org, si-list@silab.eng.sun.com Bob, One non-monotonic model that I have seen, was the result of the output buffer being tri-stated during its transition. The VI curves for the output device looked normal and I was tempted to use them in an IBIS model, taking a guess at the "real" rise/fall times. The vendor however assured me that the device actually behaved this way and that with typical loading, the transition would become monotonic (which it did). I suppose that this would not be too difficult to model if the timing and duration of the tri-state condition were known. However, I'm sure that there are other reasons for non-monotonic behavior. Anyone who has worked with power FETs would assure us that non-monotonic edges are common due to the Miller effect, when switching high voltages or when switching highly inductive loads. I'm not sure where I would start to try to model this type of behavior in an IBIS model. Maybe this type on non-monotonicity is only a problem with power circuits and we don't need to worry about it. Does anyone else have an example of a non-monotonic output buffer? Fred Vance Begin forwarded message: Date: Thu, 31 Aug 95 17:59 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: On Non-Monotonic Drivers To All: Based on the discussions and clarifications, I would conclude that (1) IBIS Version 2.1 provides a format which can legally characterize the IV curves. It also could characterize resulting waveforms for given test loads, although I have not seen details on the dynamic switching characteristics and possible artifacts. (2) From what has been stated, some simulation approaches would not have have difficulty with the VI non-monotonicity. The real concerns are: (1) Different simulators may take different approaches including filtering the data to produce significantly different simulations. (However, if we do not have access to source data, we cannot validate that any of the approaches will produce an acceptable simulation.) (2) There exists a well-defined feedback reason for producing this type of non-monotonicity. So the correct simulation MAY depend on knowing exactly the mechanism. The simulators may have to include the mechanism, and IBIS may need to be extended to characterize it by its parameters. The questions I have are: (1) Is there a way to accurately characterize the mechanism without revealing the proprietary details from a black box point of view? What are its critical parameters? (2) Because there exists a negative resistance region, are there any load constraints associated with the technology (e.g., an impedance range)? (3) Could a simplified Spice test case be revealed which illustrates the effect, and from which simulation approaches could be checked? Bob Ross, Interconnectix, Inc.