From owner-ibis Tue Sep 2 09:25:58 1997 Received: from ormail.intel.com (root@ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA10725 for ; Tue, 2 Sep 1997 09:25:58 -0700 (PDT) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.6/8.8.5) with ESMTP id JAA10678 for ; Tue, 2 Sep 1997 09:25:45 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id JAA02016 for ibis@vhdl.org; Tue, 2 Sep 1997 09:24:27 -0700 (PDT) Received: by ccm.hf.intel.com (ccmgate 3.2 #8) Tue, 02 Sep 97 09:24:27 PDT Date: Tue, 02 Sep 97 09:03:00 PDT From: Arpad Muranyi Message-ID: To: vchang@memh.ti.com_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org Subject: Re: package. Text item: Vincent, 1) The I-V curves can be measured with the package around the die, because this measurement is usually so slow that the effects of the package will not alter your data. 2) Since you didn't say what causes you confusion about RLC_pgk and RLC_pin I am not sure how to answer. The RLC_pkg are the global package numbers which are in effect when nothing else is specified at the pin list. If you know the RLC numbers for individual pins you can use the RLC_pin numbers which override the RLC_pkg defaults. 3) Again you were not very specific with your question on the I/O pins. I don't know what your confusion is, so I will just say something general. Get I-V curves for it when it is driving (pullup and pulldown) and get I-V curves when it is 3-stated (Power and GND clamp). The first will represent it when it is an output, the second when it is an input. 4) Regarding your previous EMAIL, you didn't answer my question. You stated that "In ibis model, the package is not be used on simulation. Why?" and I asked where you got this idea from. When you simulate with an IBIS model you will use the package. It is another story that you may need to remove the package from a SPICE simulation when you are generating the V-t curves for an IBIS model. In general, please be more precise and specific with your questions if you want to get more meaningful help. This way we can only guess what your problems could be. Also, most of my responses are described in the IBIS specification. It is a good thing to read the spec first (carefully) and then post questions to the reflector if you still don't understand something. As they say "If all else fails, read the manual"... Of course, the spec is not something that is very entertaining, but there are a lot of good things in it. I hope this helps, Arpad =============================================================================== Arpad, In the COOK book, it states, =============================================================================== To behaviorally represent any such buffer requires the following information: the I-V characteristics of the power clamp or ESD diodes the input or output capacitance of the buffer the characteristics of the package (the values of the lead inductance, resistance, and capacitance) Output and I/O buffer representations also require: the current vs. voltage (I-V) characteristics of the buffer in both low and high states the rise and fall time of the buffer when switching =============================================================================== Are the I-V characteristics of the buffer been measured with package(R,L,C)? Also, I am confused with RLC_pgk and RLC_pin. Oh, do you know how to handle Bi-direction pin(I/O pins)? I am not very clear on how to model this type of pins. Please help me to clear these confusions. Call me if you want. Thank you in advance. -- Best Regards, Vincent Chang ======================================================================= * Vincent Chang TI MSG ID: hui8 * * Design Automation mailto:vchang@memh.ti.com * * Memory Products Design http://www.memh.ti.com/~mcad * * Texas Instruments Inc. MS 657 Phone: (281) 274-3167 * * PO Box 1443, Houston, TX 77251 Fax: (281) 274-2067 * ======================================================================= Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: package. To: Arpad_Muranyi@ccm.fm.intel.com Mime-Version: 1.0 X-Mailer: Mozilla 3.01Gold (X11; U; HP-UX B.10.20 9000/780) From: Vincent Chang Date: Fri, 29 Aug 1997 15:49:53 -0500 Message-Id: <340735F1.2831@memh.ti.com> Sender: vchang@memh.ti.com Received: from r2d2 (localhost [127.0.0.1]) by r2d2.memh.ti.com with SMTP (8.7.1 /8.7.1) id PAA01979 for ; Fri, 29 Aug 1997 15:49 :53 -0500 (CDT) Received: from r2d2.memh.ti.com by happy.memh.ti.com with ESMTP (1.37.109.16/16.2) id AA158487837; Fri, 29 Aug 1997 15:50:37 -0500 Received: from happy.memh.ti.com ([158.218.36.100]) by jester.ti.com (8.8.5) wit h ESMTP id PAA01987 for ; Fri, 29 Aug 1997 15:50 :38 -0500 (CDT) Received: from jester.ti.com by thalia.fm.intel.com (8.8.6/10.0i); Fri, 29 Aug 1 997 20:57:16 GMT Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fmm ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id NAA26732 for ; Fri, 29 Aug 1997 13:54:09 -0700 (PDT) Return-Path: vchang@memh.ti.com From owner-ibis Fri Sep 5 12:26:00 1997 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA15887 for ; Fri, 5 Sep 1997 12:25:59 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id MAA17245 for ; Fri, 5 Sep 1997 12:24:04 -0700 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (V2.0) id mqueue/xma017229; Fri, 5 Sep 97 12:23:48 -0700 Received: from mailserver.tempe.vlsi.com (mailserver.tempe.vlsi.com [134.27.128.5]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/101195) with ESMTP id MAA00402 for ; Fri, 5 Sep 1997 12:23:46 -0700 Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA17414 for ; Fri, 5 Sep 1997 12:23:45 -0700 Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Message-ID: <34105C41.376EA4ED@tempe.vlsi.com> Date: Fri, 05 Sep 1997 12:23:45 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: IBIS Mailing list Subject: BIRD 42.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As long ago promised, here's a talking case for BIRD42.3 For simplicity, I've restricted the case to a very simple falling-edge behavioral model. The driver in question is a 50-ohm switched resistor, with the following time/conductance tables. The pulldown driver is common, but there are two different pullup responses: All listed conductances are piecewise linear. Time | Pulldown | Pullup #1 | Pullup #2 | | Conductance | Conductance | Conductance | --------+-------------+-------------+-------------+ 0 ps | 0 mS | 20 mS | 20 mS | 500 ps | 0 mS | 20 mS | 20 mS | 1000 ps | 0 mS | 10 mS | 20 mS | 1500 ps | 0 mS | 0 mS | 0 mS | 2000 ps | 10 mS | 0 mS | 0 mS | 2500 ps | 20 mS | 0 mS | 0 mS | 3000 ps | 20 mS | 0 mS | 0 mS | As is typical for real-world drivers, these are break-before-make. *IF* the load had time to settle completely to zero current before the next edge, there would be no difference between them; however, in real high-speed switching even unterminated lines take too long to settle and thus the pullup is still sourcing current when this schedule starts. Obviously, a terminated line is even worse; either way the turnoff of the pullup has important consequences. IMNSHO, this effect is far more important than the (extremely rare) case of major crowbar current, and any solution to this will necessarily also take care of those few instances where crowbar current is actually significant. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Fri Sep 5 14:42:22 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA16625 for ; Fri, 5 Sep 1997 14:42:21 -0700 (PDT) From: MIKL%mimi@magic.itg.ti.com Received: from alfred.itg.ti.com ([157.170.188.38]) by jester.ti.com (8.8.5) with ESMTP id QAA29365 for ; Fri, 5 Sep 1997 16:40:25 -0500 (CDT) Received: from itg.ti.com (magic.itg.ti.com [172.25.2.76]) by alfred.itg.ti.com (8.8.5/8.8.5) with SMTP id QAA08773 for ; Fri, 5 Sep 1997 16:40:25 -0500 (CDT) Received: by itg.ti.com (4.1/ITG-1.1) id AA21723; Fri, 5 Sep 97 16:40:24 CDT Date: Fri, 5 Sep 97 16:40:24 CDT Message-Id: <9709052140.AA21723@itg.ti.com> To: ibis@vhdl.org Subject: IBIS Representation for Branching Conductors From: MIKE LAMSON MIKL Subj: IBIS Representation for Branching Conductors An IBIS question: I have a package that has a power distribution bus over the chip that is connected to two external pins. The bus also has many points where it is wire bonded to the chip. There is also a similar ground bus in the same package. This is a common lead frame design used in DRAM memories. Can this be readily represented by an IBIS format? A SPICE file can be easily generated for this. Can this be converted to IBIS? Thanks and regards, Mike Lamson m-lamson@ti.com From owner-ibis Mon Sep 8 08:46:15 1997 Received: from ganymede.or.intel.com (root@ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA15534 for ; Mon, 8 Sep 1997 08:46:14 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id IAA09958; Mon, 8 Sep 1997 08:46:55 -0700 (PDT) Received: from mh-relay by ichips.intel.com (8.7.4/jIIIa) id IAA02465; Mon, 8 Sep 1997 08:44:46 -0700 (PDT) Message-Id: <199709081544.IAA02465@ichips.intel.com> To: MIKL%mimi@magic.itg.ti.com Cc: ibis@vhdl.org Subject: IBIS Representation for Branching Conductors Date: Mon, 08 Sep 1997 08:44:46 -0700 From: Stephen Peters Hello Mike: The short answer to your question is yes -- but in not a great amount of detail. The [Pin Mapping] keyword allows one to specify which buffers are connected to which power and ground pin(s) on a package, thereby allowing the user to "create" common power or ground bus in a package. The power and ground pins themselves can be given a lumped L/R/C value via the [Pin] keyword. However, the IBIS description does not allow one to describe the distributed L/R/C of the power distribution grid itself. For a detailed network type description of the package one would need to use a SPICE representation. Regards, Stephen Peters Intel Corp. >On Fri, 5 Sep 97 16:40:24 CDT Mike Lamson wrote: From: MIKE LAMSON MIKL Subj: IBIS Representation for Branching Conductors An IBIS question: I have a package that has a power distribution bus over the chip that is connected to two external pins. The bus also has many points where it is wire bonded to the chip. There is also a similar ground bus in the same package. This is a common lead frame design used in DRAM memories. Can this be readily represented by an IBIS format? A SPICE file can be easily generated for this. Can this be converted to IBIS? Thanks and regards, Mike Lamson m-lamson@ti.com From owner-ibis Tue Sep 9 09:22:46 1997 Received: from ganymede.or.intel.com (root@ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA12357 for ; Tue, 9 Sep 1997 09:22:45 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id JAA18579 for ; Tue, 9 Sep 1997 09:23:31 -0700 (PDT) Received: from mh-relay by ichips.intel.com (8.7.4/jIIIa) id JAA08435; Tue, 9 Sep 1997 09:21:15 -0700 (PDT) Message-Id: <199709091621.JAA08435@ichips.intel.com> To: ibis@vhdl.org Subject: IBIS Open Forum Teleconference Minutes 9/5 Date: Tue, 09 Sep 1997 09:21:15 -0700 From: Stephen Peters DATE: September 9, 1997 SUBJECT: 9/5/97 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1997 PARTICIPANTS LIST: AMP Jeff Walden Applied Simulation Technology [Dileep Divekar], Norio Matsui, Raj Raghuram*, Fred Balistreri Cadence Design & UniCAD C. Kumar, Don Telian, Cameron Seitz Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu High Design Technology (Razvan Ene) HyperLynx Kellee Crisafulli, Steve Kaufer, Matthew Flora* INCASES Olaf Rethmeier*, Werner Rissiek Intel Corporation Stephen Peters*, Arpad Muranyi, Henry Maramis, Will Hobbs, Frank Kern* Interconnectix Bob Ross* Mitsubushi Tam Cao, Hoang Nguyen Motorola [Ahmed Omer], Michael Desiderio, Paul Bolden, Tom Myers, Rob Wenzel National Semiconductor Syed Huq*, Cheng-Yang Kao, Mike Bristol, Peter Laflamme, Kevin Smith NCR Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto) Quantic EMC (Mike Ventham) Texas Instruments Thomas Fisher Thomson-CSF/SCTF (Jean LeBrun) Viewlogic Jon Powell, Chris Rokusek*, Peivand Tehrani Graham Bell* VeriBest Ian Dodd*, William Bell, Dave Wien* VLSI Technology Harish Patel, D.C. Sessions* OTHER PARTICIPANTS IN 1997: 3M [Fran Hart] Actel Scott Schlachter Acuson & Free Model Foundation Richard Munden Alcatel John Fitzpatrick Ansoft Eric Bogatin Apteq Design Systems Dan FitzPatrick Compaq Weston Beal, Mark Leonard Dell Computer Dave Baranauskas, Doug Wallace EIA Patti Rusher* EMC Fabrizio Zanella Hewlett Packard, EEsof Karl Kachigan, Henry Wu Hewlett Packard, France Jean-Christophe Pautrat Hitachi Saburo Hojo, Yasushi Ogawa IBM Brad Herrman Interface Technology Dan Waterloo Micron Technology Brian Johnson Molex Gus Panella North Carolina State U. (Michael Steer) S3, Inc. Porsh Shih, Sarathy Sribhashyam Symmetry Andy Hughes TRW Ray Steele Ultratest International Charles Im Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode September 9 (916) 356-9200 1-178721 5387488 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 AND MEETING QUORUM The following new participants introduced themselves: Raj Raghuram is taking over the Applied Simulation Technology representation. While most of his involvement has been at his current company, he has also been involved with Syed Huq at National Semiconductor doing IBIS model development. Graham Bell from Viewlogic, Fremont, CA is interested in the modeling problem for marketing support for some of Viewlogic's signal integrity products. Dave Wien of Veribest is involved in marketing their signal integrity products and related IBIS issues. MEMBERSHIP UPDATE AND TREASURER'S REPORT Patti Rusher did not have a current membership or treasurer's report. (The last report was $5,272.) Bob Ross and Patti had carried out an off line discussion concerning budget and membership status, but the questions still need to be resolved. REVIEW OF MINUTES AND AR'S Matthew Flora's written name was corrected from Matt Flora, although he goes by both Matt or Matthew in conversation. Patti Rusher's name was corrected from Pattie in a few locations. Stephen Peters reviewed the AR's. D.C Sessions has completed his AR (explaining the best way to modify a SPICE transistor model to get realistic power and ground clamp curves) and Bob Ross has supplied both his text examples for the cookbook. The major outstanding A/Rs are examples for the Cookbook and BIRDs and will be carried forward. MISCELLANY/ANNOUNCEMENTS Bob Ross announced that he will use one of the accepted aliases "eda.org" in place of "vhdl.org" as the site location for IBIS documents and mailing addresses. This nomenclature is more representative of the EIA/IBIS Open Forum since IBIS has no technical association with VHDL. D.C. Sessions noted that VLSI Logic annual technical center training will include a session on IBIS taught by D.C. PRESS AND WEB PAGE UPDATES Syed Huq has made some roster updates. Also, a member company plans to submit a logo for the poster page after going through the authorization steps. Bob Ross reported that Syed's Open tutorial on "Understanding and Using IBIS Models for Signal Integrity Analysis" is listed in the High-level Electronic System Design Conference (HESDC '97) insert that has appeared in several magazines. It is scheduled October 7-9, 1997 in San Jose, CA. Bob also noted that the "HyperLynx Upgrades HyperSuite" in EE Times, p. 63, August 25, 1997 mentions IBIS. Bob noted that the final column in Howard Johnson's Straight Talk for Serious Digital Designers titled "The Real Truth About Crosstalk" in Electronic Design, August 18, 1997, pg. 115, mentions IBIS at the end. Finally, Bob noted that two references to IBIS exist in the September, 1997 issue of Printed Circuit Design. The IBIS Version 3.0 press release is given on page 9, and Shelly Nielsen's writeup on the PCB Design Conference East, in Boston, September 15-19, 1997, references Bob's course on "Practical Issues with IBIS Models". NEW MODELS AVAILABLE, LIBRARY UPDATE D.C. Sessions states that VLSI Technology has pulled their IBIS models from their web page. He had written on the reflector that they represented obsolete products and that they are discussing how to deal with future IBIS models (whether by Web site or by CD ROM). He also indicated later that some new features of IBIS Version 3.0 would have been useful even for these models. He will make available IBIS model with new features for testing. Bob Ross noted that IBM Microelectronics is offering downloadable IBIS models to registered users at: http://www.cips.ibm.com/products/memory/selguide/modelmenu.html Jon Powell has updated the EIA/IBIS Web page models section with the above changes. Syed reported that National has placed two new SuperI/O IBIS models on their Web page. OPENS FOR NEW ISSUES Matthew Flora on reporting ibischk2+ problems Dave Wien on s2ibis for NT status INTERNATIONAL PROGRESS - 93/46/NP (IBIS Version 2.1) - Patti Rusher reported that the US Technical Advisorary Group (TAG) is tracing the documentation associated with this effort. Patti expects more details after the Tokyo IEC meeting in September, 1997 concerning the status and response to 93/46/NP. - 93/60/NP (IBIS Models and EMC Simulation) - Patti reported that the US TAG has conditionally voted yes, pending a better definition of the scope of this effort. She should have more information after the Tokyo IEC meeting. - EIAJ III (I/O Interface Model for ICs) - Patti reports that this proposal has been forwarded to the WG3. The EIAJ subcommittee has been invited to give at presentation at an industrial forum at the IEC meeting. EAST COAST IBIS USERS GROUP Bob Ross reported that Dr. Ed Sayre of North East Systems Associates (NESA) has set up an East Coast IBIS Users meeting in Stow, Massachusetts on Thursday, September 18, 1997 from 2 p.m. onward. Ed expects about 25 people at the initial meeting. Information has been posted on the ibis-users reflector. More details are expected to be posted soon. The agenda of this first meeting will also cover organizational details. In addition, Ed expects to have several presentations. Bob also noted that he is having some very preliminary discussion separately on a possible IBIS meeting associated with EuroDAC in France in February, 1998. S2IBIS FOR NT Dave Wiens plans to post the improved s2ibis_ver1.3 for NT on the VeriBest Web site where links already exist from the EIA/IBIS Web page and other sites. Work still exists to create the latest s2ibis2_ver2.1 files. Bob Ross did not want the earlier version posted since there have been several significant changes, even though, according to Ian Dodd, the number of file differences are small. So partial compliance with the AR is expected soon. AR - Ian Dodd put s2ibis_ver1.3 and s2ibis_ver2.1 for Windows on the VeriBest Web site. EDITING COMMITTEE Stephen Peters reported that he and Bob Ross met to go over some issues. They developed an outline for sectioning the document. The outline included an introduction section which will give more scope and detail. Also after review Stephen and Bob agreed to some of the terms proposed by Ogawa-san of the EIAJ subcommittee. Some additional detail to clarify "required" keywords was discussed since they provide only a minimal set. Some non-required keywords are really technically required if they are applicable. Perhaps a table will be added for this as in the Cookbook. Bob and Stephan still plan a first pass to be put in the work in progress directory (wip). The existing ARs are still in effect. AR - Bob Ross generate and post a BNF for IBIS Version 3.0 (and IBIS Version 3.0 ratification AR). AR - Stephen Peters and Bob Ross generate an editorial revision of Version 3.0 and place it in the eda.org/pub/ibis/wip directory. BIRD44 - INTERPRETATION OF MIN/MAX/WEAK/STRONG DATA Per the discussion of last meeting, Bob Ross has moved BIRD44 discussion into the Editing Committee Area since BIRD44 relates to an editorial issue. It proposes changing the min and max column headings to weak and strong, where applicable under the [Model] keyword. BIRD44 will be considered more closely at a later time as part of the the Version 3.0 editorial activity. VERSION 2.1 PARSER (& S2IBIS) BUG REPORTING Matthew Flora opened the discussion on this new item. He has discovered some bugs with the existing ibischk2+ code and wanted to know how to report them. One bug was that a [Pullup] or [Pulldown] table with no data was not flagged, and another involved a crash after a keyword was positioned after the [End] statement. Matthew is aware of the /pub/ibis/bugs directory under eda.org where ibischk bug information and a report form is stored and is also aware of the email address ibischk-bug@eda.org. His major concern is that the process is not documented on from the EIA/IBIS Web site or as a Frequently Asked Question (FAQ). D.C. Sessions suggested an FTP site where bug test could be sent. They could be used for subsequent testing. After some discussion, Matthew will work with Syed Huq concerning providing process information. AR - Matthew Flora work with Syed Huq regarding generating an FAQ and also an informative link from the EIA/IBIS Open Forum Web page on how to report bugs on ibischk parsers. Chris Rokusek asked whether a help switch could be added to the ibischk2+ parser that would generate a bug report form. The consensus was that this would be a good idea. Chris also noted that the nomenclature should have been version 2.114 rather than 2.14. Bob Ross stated that if changes are made, the parser should be nomenclated as 2.115. Bob also noted that anyone who has purchased the source code license for ibischk2 can get the source code for these newer versions. Syed confirmed that ibischk2+ provides its version number, in response to a question by Matthew. The question arose where to report s2ibis bugs. They are to be handled by the EIA/IBIS Open Forum, rather than by NCSU. After some discussion Bob agreed to create a bug form and set up another directory for s2ibis bugs. AR - Bob Ross set up a bug directory for s2ibis bugs, and create a bug form. Bob will also work out a bug reporting process. VERSION 3.1 PARSER Bob Ross reported that one bid has come in and we are waiting for others. Bob also noted that in the past the source code licenses cost $500 each for ibis_chk and ibischk2. This covered the contracted development cost with some margin since several purchases were made after the code had been developed. Over 20 companies have paid for licenses for ibischk2. The benefit for many companies is simply to help the development expense for the common benefit of all and also to get an early view as the code is being developed. In some cases, they can perform early checks for IBIS models under development with the newer features before the official parser is considered complete and is released. The bids are expected to be higher than in the past. In anticipation of this Bob wanted to get a sense of how much companies are willing to pay to share the cost of ibischk3. Bob was probing the $2000 to $5000 range for each company (with the expectation that fewer companies would join in to license the source code.) If you are interested in licensing the source code, please respond privately to Bob Ross regarding about how much you would be willing pay to share the ibischk3 development expense. (Bob will also phone around to get a sense of commitment level.) Based on some preliminary discussion, the $2,000 to @2,500 range seemed tolerable. Bob indicated that a payment commitment that covers the total cost will be needed before we can accept any bid. Bob also raised the idea that individual companies such as Interconnectix may consider using internal staff to develop such a parser. Other companies that might consider this include Hyperlynx, Viewlogic, VeriBest and Cadence, since they already have IBIS experience and need such a parser. Consistent with the existing licensing policy, some fee would be set for licensing the source code. With this arrangement, the company could get at least partial compensation for the internal effort. Bob's main question was if anyone objected to pursuing this option. No objections were raised. Chris Rokusek commented that if a company did the development, they would have to maintain the code indefinitely. Bob commented that after the parser is released and accepted the company could expect to be compensated for additional work, especially if it involved a lot of effort. We have paid for additional work for ibischk2 fixes (and enhancements) in the past. Ian Dodd commented that some of the Version 3.0 enhancements are very easy to add. Others, such as series switches, are difficult to understand and therefore may be costly to include. Bob stated that this is one of the major benefits of developing the ibischk3 parser - discover and resolve the ambiguous areas of IBIS Version 3.0. This has worked well in the past leading to IBIS Version 1.1 and IBIS Version 2.1 documents. Bob asked Chris to join him, Jon Powell, Syed Huq and Stephen Peters on the ibischk3 proposal review committee. LEGAL IBIS VERSION 3.0 FILES Bob Ross reported that some "legal" concerns were raised at the last meeting regarding issuing IBIS Version 3.0 that have not been validated using the non-existent ibischk3 parser. Jon Powell initiated some further discussion on the ibis reflector, without resolution. Stephen Peters felt that the IBIS model should be corrupted in some manner (issued as a .txt file or have the [IBIS Ver] designation "preliminary" so that the earlier releases would be guaranteed to fail ibischk3) until formally checked. Bob felt that some method was needed, but that the existing comments and disclaimer methods and [File Rev] control were sufficient without introducing corruption. There is now a "chicken and egg" situation where companies are now including IBIS Version 3.0 features that require uncorrupted IBIS Version 3.0 models. The user could introduce error while undoing the corruption. Bob also stated that "legal" was not a good term since it implies compliance to a (copyright) law, whereas he understood the intended meaning to be "in (legal) compliance with the documented IBIS Version 3.0 syntax. Stephen suggested that the committee take a position on this, and Bob suggested a general statement that we can all agree to - while each company will decide their own IBIS model release policy with IBIS Version 3.0 features, we strongly suggest that the models be clearly documented at the top with the statement that it is released without having been checked with the (to be developed) ibischk3 syntax checker and is therefore subject to error. A subsequent release of the model when the ibischk3 checker is available may contain syntactical corrections. COOKBOOK Stephen Peters reported that D.C. Sessions and Bob Ross have provided him write ups and an example per ARs. D.C. provided the writeup on getting realistic clamping information, and Bob provided a section on diode transit time and a series switch example. Other AR's remain in effect. Stephen will make some additions and work with Bob to put the cookbook into the work in progress directory (/pub/ibis/wip) in eda.org. The document Version Number will be used to document new version. After some discussion and reviewing what we agreed to at the last meeting, Syed Huq will provide a link from the official EIA/IBIS Web page to this document. He will include the appropriate warnings that the Cookbook is just a preliminary version that will undergo revision. The Version Number of any Cookbook document needs to be checked with the posted document to assure that the latest Cookbook Document is being used. AR - The following people have volunteered to supply examples Steve Kaufer/Hyperlynx -- Example 1 (Version 1.1 basic model) Arpad Muranyi - Example 2 Stephen Peters - Example 3 AR - Syed Huq. Review and expand (if necessary) Section 3.3. on "Obtaining I/V and Switching Information via Lab Measurement". AR - Stephen Peters with Bob Ross put a copy of the Cookbook in the eda.org/pub/ibis/wip directory after appropriate Version Number and preliminary disclaimers are added. AR - Syed Huq provide a link to access the Cookbook document from the official EIA/IBIS Web Site after the Cookbook is uploaded. BIRD42.3 - MODELING CURRENT WAVEFORMS D.C. Sessions has not gotten together with C. Kumar regarding some technical discussion on where rising and falling waveform table do not produce the correct response. Instead, D.C. plans to put the discussion on the IBIS reflector. So the AR now reflects this change. AR - D.C. Sessions provide an example on the IBIS reflector showing where the rising and falling waveform tables do not result in correct results [Done]. SWITCHING TERMINATORS No Report. MISCELLANEOUS DISCUSSION Frank Kern asked if CAE Vendors are adding Version 3.0 features. Bob Ross and Dave Wien responded that Interconnectix and VeriBest will have some IBIS Version 3.0 features in their next releases. Bob then asked what the semiconductor vendors view as the most important IBIS Version 3.0 features for inclusion by CAE Vendors. A similar discussion occurred during the Version 2.1 development and helped CAE Vendors prioritize their development activities. This discussion will be added to next meetings agenda. D.C. Sessions indicated that VLSI really requires the buffer selection addition [Model Selector]. Even older IBIS models needed this. Frank Kern suggested that this be a discussion topic at the next meeting since he needs to research this question. Syed Huq wanted all of the features since he felt that excluding any feature gave permission for CAE Vendors never to implement it. From a user's perspective, Dave Moxley did not have any specific need beyond Version 2.1. However, he could use series switches if its implementation is realistic and not too cumbersome. NEXT MEETING: The next meeting is on Friday, September 26, 1997, 8:00 A.M. to 9:55 A.M. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 SECRETARY: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Tue Sep 9 16:41:53 1997 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA23784 for ; Tue, 9 Sep 1997 16:41:52 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.8.5/8.8.5) id QAA06372; Tue, 9 Sep 1997 16:40:21 -0700 (PDT) Message-Id: <3.0.32.19970909164036.00d7c948@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 09 Sep 1997 16:40:38 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Testing the V3.0 IBIS golden parser. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi All, It has occurred to me that we should make a priority out of releasing golden parser test models. Whom ever develops the golden parser will need test models to verify it is working. For example: - The new IC package format (Intel) - The new R,C package information (Interconnectix) - The new connector information (Interconnectix) etc.... It seems to me that it is a waste of effort to launch a development effort if we don't have a few beta models for the parser developer to test with. Is anyone willing to give a some of the more unusual 3.0 models to the parser development team to test with. I believe we should start a sub-directory for some beta models to test with. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Wed Sep 10 15:29:12 1997 Received: from fw.icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id PAA23254 for ; Wed, 10 Sep 1997 15:29:11 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Wed, 10 Sep 1997 15:27:38 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Wed, 10 Sep 1997 15:27:27 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Wed, 10 Sep 1997 05:51:35 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Wed, 10 Sep 1997 05:51:35 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@eda.org, kellee@hyperlynx.com Subject: Re: Testing the V3.0 IBIS golden parser. Kellee and IBIS Committee: Thank you for your suggestion. Any test case with Version 3.0 extensions are welcome. Stephen Peters is collecting some samples as part of the Cookbook update project. So I would suggest sending them to Stephen. Also in response to your suggestion and to elaborate regarding ibischk issues in general, I have these points: (1) I have created a new eda.org/pub/samples subdirectory with areas for ver1.1, ver2.1, and ver3.1 samples. I seeded the ver3.0 directory with a cbt.ibs sample for a Series Switch part. It contains a disclaimer that it has not been checked with the ibischk3 parser (which is to be developed.) (2) Matthew Flora of Hyperlynx has submitted through the ibischk-bug@eda.org reflector BUGS 9 through 13 on ibischk2, etc. They will be discussed at the next meeting. They are located at eda.org/pub/ibis/bugs. (3) Matthew also compiled a 32 bit version of ibischk2+ for DOS systems. The executable is located under eda.org/pub/ibis/ibschk2+/dos32. (4) Finally, Stephen and I plan to extend the Version 2.1 Test Matrix used to define the functional elements of the standard to Version 3.0 functionality. This will also be used to define the tested features of ibischk3. Bob Ross Interconnectix > Date: Tue, 09 Sep 1997 16:40:38 -0700 > To: ibis@vhdl.org > From: Kellee Crisafulli > Subject: Testing the V3.0 IBIS golden parser. > Hi All, > It has occurred to me that we should make a priority out of > releasing golden parser test models. Whom ever develops the golden > parser will need test models to verify it is working. > For example: > - The new IC package format (Intel) > - The new R,C package information (Interconnectix) > - The new connector information (Interconnectix) > etc.... > It seems to me that it is a waste of effort to launch a development effort if we > don't have a few beta models for the parser developer to test with. > Is anyone willing to give a some of the more unusual 3.0 models to the parser > development team to test with. I believe we should start a sub-directory > for some beta models to test with. > > ------------------------------------------------------------------------- > Have a great day... > Kellee Crisafulli at HyperLynx > kellee@hyperlynx.com http://www.hyperlynx.com > ------------------------------------------------------------------------- From owner-ibis Fri Sep 12 13:49:20 1997 Received: from usr.com (mailgate.usr.com [149.112.20.2]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA08890 for ; Fri, 12 Sep 1997 13:49:17 -0700 (PDT) From: mohali@usr.com Received: from robogate2.usr.com by usr.com (8.7.5/3.1.090690-US Robotics) id PAA27917; Fri, 12 Sep 1997 15:35:09 -0500 (CDT) Received: from ccMail by robogate2.usr.com (IMA Internet Exchange 2.02 Enterprise) id 419ACFD0; Fri, 12 Sep 97 15:58:37 -0500 Mime-Version: 1.0 Date: Thu, 11 Sep 1997 15:29:42 -0500 Message-ID: <419ACFD0.3000@usr.com> Subject: SPICE simulator To: ibis@vhdl.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I am looking for an inexpensive unix-based SPICE simulator that I can use as the back-end engine of my s2ibis converter. The only tool I know is HSPICE from Meta Software. But it is very expensive. Does anybody has any info on this? Mohammad Ali, Ph.D. 3Com Corpration Email: mohali@usr.com From owner-ibis Fri Sep 12 17:13:03 1997 Received: from ole.cdac.com (ole.cdac.com [199.5.216.26]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA12254 for ; Fri, 12 Sep 1997 17:13:02 -0700 (PDT) Received: from ember.cdac.com (fwuser@cascade.cdac.com [199.5.216.206]) by ole.cdac.com (8.8.5/8.7.1) with ESMTP id RAA00376; Fri, 12 Sep 1997 17:11:32 -0700 (PDT) Received: from quark.cdac.com (quark.cdac.com [10.0.10.112]) by ember.cdac.com (8.7.1/8.7.1) with ESMTP id RAA05941; Fri, 12 Sep 1997 17:10:38 -0700 (PDT) From: Lynne Green Received: (from lgreen@localhost) by quark.cdac.com (8.7.1/8.7.1) id RAA17753; Fri, 12 Sep 1997 17:10:38 -0700 (PDT) Date: Fri, 12 Sep 1997 17:10:38 -0700 (PDT) Message-Id: <199709130010.RAA17753@quark.cdac.com> To: mohali@usr.com Subject: Re: SPICE simulator Cc: ibis@vhdl.org Dr. Ali - Try SPICE 2G6 - it is in the public domain. It does lack a few features, like a decent postprocessor. But you can buy separate postprocessors that work off the spice output files. Since it is in FORTRAN, you can compile it on any machine, including UNIX. - Lynne Green From owner-ibis Wed Sep 17 01:23:34 1997 Received: from mailer.via.com.tw ([203.70.217.165]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id BAA26865 for ; Wed, 17 Sep 1997 01:23:33 -0700 (PDT) Received: from JUSTINE.VIA.COM.TW ([203.70.217.209]) by mailer.via.com.tw (Netscape Mail Server v1.1) with ESMTP id AAA165 for ; Wed, 17 Sep 1997 16:30:45 +0800 Message-ID: <341F93FC.5EAA2AC2@via.com.tw> Date: Wed, 17 Sep 1997 16:25:32 +0800 From: Justine Yu Organization: VIA TECH X-Mailer: Mozilla 4.01 [tw] (Win95; I) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Subcription! X-Priority: ¤@¯ë) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Sir: I wanna subscribe as a member. My email address is justine_yu@via.com.tw. Sincerely, Justine From owner-ibis Wed Sep 17 12:18:11 1997 Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA08495 for ; Wed, 17 Sep 1997 12:18:10 -0700 (PDT) Received: from uucp1.UU.NET by relay7.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.39]) id QQdhkv21227; Wed, 17 Sep 1997 15:16:37 -0400 (EDT) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 17 Sep 1997 15:16:38 -0400 Received: from hal.UUCP by qdt.viewlogic.com (4.1/SMI-4.1) id AA25402; Wed, 17 Sep 97 12:07:17 PDT Received: from awacs.qdt.com by qdt.com (4.1/SMI-4.1) id AA00415; Wed, 17 Sep 97 12:06:04 PDT Date: Wed, 17 Sep 97 12:06:04 PDT Message-Id: <9709171906.AA00415@qdt.com> Received: by awacs.qdt.com (4.1/SMI-4.1) id AA05507; Wed, 17 Sep 97 12:05:59 PDT From: Chris Rokusek To: ibis@vhdl.org Subject: length Hi All, I have a Question on the [Path Description] section in Ver 3.x of .ibs... How do we convert the "Len"'s to physical lengths--what are the "units" (meters?). -Chris Rokusek Viewlogic/MTS |============================================================================= | Keyword: [Path Description] | Required: Yes | Description: This keyword allows the user to describe the connection | between the user accessible pins of a part and the pins of the | ICs mounted on that part. Each pin to node connection is | divided into one or more cascaded "sections", where each | section is described in terms of it's L/R/C per unit length. | The Fork and Endfork subparameters allow the path to branch to | multiple nodes, or another pin. A path description is | required for each pin whose signal name is not "GND", "POWER" | or "NC". | | Board Description and IC Boundaries: | | In any system, each part interfaces with another part at some | boundary. Every part model must contain the components | necessary to represent the behavior of the part being modeled | within its boundaries. The boundary definition depends upon | the parts being represented by the model. | | For CARD EDGE CONNECTIONS such as a SIMM or a PC Daughter | Card plugged into a SIMM Socket or Edge Connector, the | boundary should be at the end of the board card edge pads as | they emerge from the connector. | | For any THROUGH-HOLE MOUNTED PART, the boundary will be at the | surface of the board on which the part is mounted. | | SURFACE MOUNTED PART models end at the outboard end of their | recommended surface mount pads. | | If the board level component contains an UNMATED CONNECTOR, | the unmated connector will be described in a separate file, | with its boundaries being as described above for the | through-hole or surface mounted part. | | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node | Usage Rules: Each individual connection path (user pin to node(s)) | description begins with the [Path Description] keyword and a | path name, followed by the subparameters used to describe the | path topology and the electrical characteristics of each | section of the path. The path name must not exceed 40 | characters, blanks are not allowed, and each occurrence of the | [Path Description] keyword must be followed by a unique path | name. Every signal pin (pins other than POWER, GND or NC) | must appear in one and only one path description per [Begin | Board Description]/[End Board Description] pair. Pin names do | not have to appear in the same order as listed in the [Pin | List] table. The individual subparameters are broken up into | those that describe the electrical properties of a section, | and those that describe the topology of a path. | | Section Description Subparameters: | | The Len, L, R, and C subparameters specify the length, the | series inductance and resistance and the capacitance to ground | of each section in a path description. | | Len The physical length of a section. Lengths are given | in terms of arbitrary 'units'. Any non-zero length | requires that the parameters that follow must be | interpreted as distributed elements by the simulator. | L The series inductance of a section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0 nH and the length of | the section is 2 'units', the inductance would be | listed as L = 1.5 nH (i.e. 3.0 / 2). | C The capacitance to ground of a section, in terms of | capacitance per unit length. | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. | | Topology Description Subparameters: | | The Fork and Endfork subparameters denote branches from the | main pin-to-node or pin-to-pin connection path. The Node | subparameter is used to reference the pin of a component or | board as defined in a .ibs or .ebd file. The Pin subparameter | is used to indicate the point at which a path connects to a | user visible pin. | | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main connection path. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a branch. | For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no | arguments. | Node reference_designator.pin | This subparameter is used when the connection path | connects to a pin of another, externally defined part. | The arguments of the Node subparameter indicate the | pin and reference designator of the external | component. The pin and reference designator portions | of the argument are separated by a period ("."). The | reference designator is mapped to an external | component description (another .ebd file or .ibs file) | by the [Reference Designator Map] Keyword. Note that | a Node MUST reference a model of a passive or active | component. A Node is not an arbitrary connection | point between two elements or paths. | Pin This subparameter is used to mark the point at which | a path description connects to a user accessible pin. | Every path description must contain at least one | occurrence of the Pin subparameter. It may also | contain the reserved word NC. The value of the Pin | subparameter must be one of the pin names listed in | the [Pin List] section. | | Using The Subparameters to Describe Paths: | | A section description begins with the Len subparameter and | ends with the slash (/) character. The value of the Len, L, | R, and C subparameters and the subparameter itself are | separated by an equals sign (=); whitespace around the equals | sign is optional. The Fork, Endfork, Node and Pin | subparameters are placed between section descriptions (i.e., | between the concluding slash of one section and the 'Len' | parameters that starts another). The arguments of the Pin and | Node subparameter are separated by white space. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total for | that section. If a non-zero length is specified, then the | total L/R/C for a section is calculated by multiplying the | value of the Len subparameter by the value of the L, R, or C | subparameter. However, as noted below, if a non-zero length | is specified, that section MUST be interpreted as distributed | elements. | | Legal Subparameter Combinations for Section Descriptions: | | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C | subparameters represent lumped elements. If the Len | subparameter is non-zero, then the L/R/C subparameters | represent distributed elements and both L and C must be | specified, R is optional. | | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a Node, | another pin or the reserved word, NC. | | Dealing With Series Elements: | | A discrete series R or L component can be included in a path | description by defining a section with L=0 and the proper R or | L value. A discrete series component can also be included in | a path description by writing two back to back node statements | that reference the same component (see the example below). | Note that both ends of a discrete, two terminal component MUST | be contained in a single [Path Description]. Connecting two | separate [Path Description] with a series component is not | allowed. |----------------------------------------------------------------------------- | | An Example Path For a SIMM Module: | [Path Description] CAS_2 Pin J25 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u21.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u22.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u23.15 | | A Description Using The Fork and Endfork Subparameters: | [Path Description] PassThru1 Pin B5 Len = 0 L=2.0n / Len = 2.1 L=6.0n C=2.0p / Fork Len = 1.0 L = 1.0n C= 2.0p / Node u23.15 Endfork Len = 1.0 L = 6.0n C=2.0p / Pin A5 | | A Description Including a Discrete Series Element: | [Path Description] sig1 Pin B27 Len = 0 L=1.6n / Len = 1.5 L=6.0n C=2.0p / Node R2.1 Node R2.2 Len = 0.25 L=6.0n C=2.0p / Node U25.6 | |============================================================================= From owner-ibis Thu Sep 18 04:12:02 1997 Received: from exchange2.via.com.tw (exchange2.via.com.tw [203.70.217.249]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id EAA24863 for ; Thu, 18 Sep 1997 04:12:01 -0700 (PDT) Received: by exchange2.via.com.tw with Internet Mail Service (5.0.1457.3) id ; Thu, 18 Sep 1997 19:13:50 +0800 Message-ID: <8ED69558A10CD111978D00A0C92BD8A0020FCA@exchange2.via.com.tw> From: Gloria Shen To: "'ibis@vhdl.org'" Date: Thu, 18 Sep 1997 19:13:47 +0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain subscribe gloria_shen@via.com.tw From owner-ibis Fri Sep 19 16:14:01 1997 Received: from fw.icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id QAA01427 for ; Fri, 19 Sep 1997 16:13:59 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Fri, 19 Sep 1997 16:12:29 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 19 Sep 1997 16:12:16 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Fri, 19 Sep 1997 16:12:22 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 19 Sep 1997 16:12:22 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@eda.org Subject: IBIS MEETING 9/26/97 IBIS Open Forum Meeting Agenda for 9/26/97 Bridge Number Reservation # Passcode (916) 356-9200 1-178721 5387488 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Peters - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions International Progress Rusher/Ross - 93/46/NP (IBIS Version 2.1) - 93/60/NP (IBIS Models and EMC Simulation) - EIAJ III (I/O Interface Model for ICs) East Coast IBIS Users Meeting Report Ross s2ibis for NT Status Dodd/Wiens Editing Committee Ross/Peters BIRD44 Interpretation of Min/Max/Weak/Strong Data Ross ibischk2+ Status Rokusek/Ross - DOS32 Version Version 3.1 Parser Ross/Peters - Status on Bids and Actions - Funding and Budget - Test Matrix - Samples Cookbook Status Peters - Examples Version 3.0 Feature Priority Discussion Ross New Administrative Issues All 9:15 Technical Discussion New ibischk bugs Flora BUG9 Crash if Keyword Associated with [Model] Comes First BUG10 Crash if Parser Encounters Empty V/I Table BUG11 Parser Continues after [End] Keyword BUG12 Lines Greater than 1024 Characters Cause Wrong Line Numbers BUG13 Parser Crashes if Error in Line Longer than 256 Characters BUG14 Long Illegal Keyword Prints Meaningless Message BIRD42.3 Modeling Current Waveforms Kumar/Ross Switched Terminators Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Fri Sep 19 17:23:42 1997 Received: from ganymede.or.intel.com (root@ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA02635 for ; Fri, 19 Sep 1997 17:23:42 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id RAA14821 for ; Fri, 19 Sep 1997 17:25:48 -0700 (PDT) Received: from mh-relay by ichips.intel.com (8.7.4/jIIIa) id RAA00832; Fri, 19 Sep 1997 17:22:10 -0700 (PDT) Message-Id: <199709200022.RAA00832@ichips.intel.com> To: ibis@vhdl.org Subject: length Date: Fri, 19 Sep 1997 17:22:10 -0700 From: Stephen Peters Hello Chris: Mmmm....intresting question. The "Len" parameter is really just a pure number that is used when calculating the delay thru a section. It does not favor a particular system of measurement. Regards, Stephehn >On Wed, 17 Sep 97 12:06:04 PDT Chris Rokusek wrote: Hi All, I have a Question on the [Path Description] section in Ver 3.x of .ibs... How do we convert the "Len"'s to physical lengths--what are the "units" (meters?). -Chris Rokusek Viewlogic/MTS |============================================================================= | Keyword: [Path Description] | Required: Yes | Description: This keyword allows the user to describe the connection | between the user accessible pins of a part and the pins of the | ICs mounted on that part. Each pin to node connection is | divided into one or more cascaded "sections", where each | section is described in terms of it's L/R/C per unit length. | The Fork and Endfork subparameters allow the path to branch to | multiple nodes, or another pin. A path description is | required for each pin whose signal name is not "GND", "POWER" | or "NC". | | Board Description and IC Boundaries: | | In any system, each part interfaces with another part at some | boundary. Every part model must contain the components | necessary to represent the behavior of the part being modeled | within its boundaries. The boundary definition depends upon | the parts being represented by the model. | | For CARD EDGE CONNECTIONS such as a SIMM or a PC Daughter | Card plugged into a SIMM Socket or Edge Connector, the | boundary should be at the end of the board card edge pads as | they emerge from the connector. | | For any THROUGH-HOLE MOUNTED PART, the boundary will be at the | surface of the board on which the part is mounted. | | SURFACE MOUNTED PART models end at the outboard end of their | recommended surface mount pads. | | If the board level component contains an UNMATED CONNECTOR, | the unmated connector will be described in a separate file, | with its boundaries being as described above for the | through-hole or surface mounted part. | | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node | Usage Rules: Each individual connection path (user pin to node(s)) | description begins with the [Path Description] keyword and a | path name, followed by the subparameters used to describe the | path topology and the electrical characteristics of each | section of the path. The path name must not exceed 40 | characters, blanks are not allowed, and each occurrence of the | [Path Description] keyword must be followed by a unique path | name. Every signal pin (pins other than POWER, GND or NC) | must appear in one and only one path description per [Begin | Board Description]/[End Board Description] pair. Pin names do | not have to appear in the same order as listed in the [Pin | List] table. The individual subparameters are broken up into | those that describe the electrical properties of a section, | and those that describe the topology of a path. | | Section Description Subparameters: | | The Len, L, R, and C subparameters specify the length, the | series inductance and resistance and the capacitance to ground | of each section in a path description. | | Len The physical length of a section. Lengths are given | in terms of arbitrary 'units'. Any non-zero length | requires that the parameters that follow must be | interpreted as distributed elements by the simulator. | L The series inductance of a section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0 nH and the length of | the section is 2 'units', the inductance would be | listed as L = 1.5 nH (i.e. 3.0 / 2). | C The capacitance to ground of a section, in terms of | capacitance per unit length. | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. | | Topology Description Subparameters: | | The Fork and Endfork subparameters denote branches from the | main pin-to-node or pin-to-pin connection path. The Node | subparameter is used to reference the pin of a component or | board as defined in a .ibs or .ebd file. The Pin subparameter | is used to indicate the point at which a path connects to a | user visible pin. | | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main connection path. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a branch. | For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no | arguments. | Node reference_designator.pin | This subparameter is used when the connection path | connects to a pin of another, externally defined part. | The arguments of the Node subparameter indicate the | pin and reference designator of the external | component. The pin and reference designator portions | of the argument are separated by a period ("."). The | reference designator is mapped to an external | component description (another .ebd file or .ibs file) | by the [Reference Designator Map] Keyword. Note that | a Node MUST reference a model of a passive or active | component. A Node is not an arbitrary connection | point between two elements or paths. | Pin This subparameter is used to mark the point at which | a path description connects to a user accessible pin. | Every path description must contain at least one | occurrence of the Pin subparameter. It may also | contain the reserved word NC. The value of the Pin | subparameter must be one of the pin names listed in | the [Pin List] section. | | Using The Subparameters to Describe Paths: | | A section description begins with the Len subparameter and | ends with the slash (/) character. The value of the Len, L, | R, and C subparameters and the subparameter itself are | separated by an equals sign (=); whitespace around the equals | sign is optional. The Fork, Endfork, Node and Pin | subparameters are placed between section descriptions (i.e., | between the concluding slash of one section and the 'Len' | parameters that starts another). The arguments of the Pin and | Node subparameter are separated by white space. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total for | that section. If a non-zero length is specified, then the | total L/R/C for a section is calculated by multiplying the | value of the Len subparameter by the value of the L, R, or C | subparameter. However, as noted below, if a non-zero length | is specified, that section MUST be interpreted as distributed | elements. | | Legal Subparameter Combinations for Section Descriptions: | | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C | subparameters represent lumped elements. If the Len | subparameter is non-zero, then the L/R/C subparameters | represent distributed elements and both L and C must be | specified, R is optional. | | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a Node, | another pin or the reserved word, NC. | | Dealing With Series Elements: | | A discrete series R or L component can be included in a path | description by defining a section with L=0 and the proper R or | L value. A discrete series component can also be included in | a path description by writing two back to back node statements | that reference the same component (see the example below). | Note that both ends of a discrete, two terminal component MUST | be contained in a single [Path Description]. Connecting two | separate [Path Description] with a series component is not | allowed. |----------------------------------------------------------------------------- | | An Example Path For a SIMM Module: | [Path Description] CAS_2 Pin J25 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u21.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u22.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u23.15 | | A Description Using The Fork and Endfork Subparameters: | [Path Description] PassThru1 Pin B5 Len = 0 L=2.0n / Len = 2.1 L=6.0n C=2.0p / Fork Len = 1.0 L = 1.0n C= 2.0p / Node u23.15 Endfork Len = 1.0 L = 6.0n C=2.0p / Pin A5 | | A Description Including a Discrete Series Element: | [Path Description] sig1 Pin B27 Len = 0 L=1.6n / Len = 1.5 L=6.0n C=2.0p / Node R2.1 Node R2.2 Len = 0.25 L=6.0n C=2.0p / Node U25.6 | |============================================================================= From owner-ibis Tue Sep 23 15:16:02 1997 Received: from fw.icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id PAA07831 for ; Tue, 23 Sep 1997 15:16:02 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Tue, 23 Sep 1997 15:14:29 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Tue, 23 Sep 1997 15:14:21 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Tue, 23 Sep 1997 15:14:22 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Tue, 23 Sep 1997 15:14:22 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@eda.org Subject: IEC Approval of IBIS To All: I received word from Patti Rusher, Director of the Electornic Information Group in EIA that IBIS Version 2.1 (also known as ANSI/EIA-656 was ratified at the IEC meeting in Tokyo as an international standard. It will be designated as IEC 62014-1. Thank you Patti for promoting this for us though the IEC channels. Bob Ross Interconnectix From owner-ibis Tue Sep 23 16:58:45 1997 Received: from bingnet1.cc.binghamton.edu (bingnet1.cc.binghamton.edu [128.226.1.11]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA09626 for ; Tue, 23 Sep 1997 16:58:44 -0700 (PDT) From: jzhao@ee1-gw.ee.binghamton.edu Received: from ee1-gw.ee.binghamton.edu (ee1-gw.ee.binghamton.edu [128.226.171.73]) by bingnet1.cc.binghamton.edu (8.8.5/8.6.9) with SMTP id TAA27260 for ; Tue, 23 Sep 1997 19:57:10 -0400 (EDT) Received: by ee1-gw.ee.binghamton.edu (AIX 3.2/UCB 5.64/4.03) id AA20506; Tue, 23 Sep 1997 19:59:06 -0400 Date: Tue, 23 Sep 1997 19:59:06 -0400 Message-Id: <9709232359.AA20506@ee1-gw.ee.binghamton.edu> To: ibis@vhdl.org Subject: Add My Name on the LIST PLEASE. Please add my name on the list. Thanks. My email address are: jzhao@emlab1.ee.binghamton.edu jzhao@binghamton.edu From owner-ibis Wed Sep 24 12:07:54 1997 Received: from fw.icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA29552 for ; Wed, 24 Sep 1997 12:07:53 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Wed, 24 Sep 1997 12:06:20 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Wed, 24 Sep 1997 12:06:10 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Wed, 24 Sep 1997 12:06:13 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Wed, 24 Sep 1997 12:06:13 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@eda.org Subject: IBIS AND S2IBIS BUGS To IBIS Committee: ibischk bugs 9-18 have been submitted for discussion at the Friday meeting. The reports are located in eda.org under /pub/ibis/bugs/ibischk/. Please review them if you wish to participate in this discussion. Three new directories have been created for s2ibis, s2ibis2 and s2iplt bug reports. The bug report forms are stored as the .txt files. Use the same ibischk-bug@eda.org for submitting bugs in these areas. Bob Ross Interconnectix Below is the bug.dir for ibischk bugs to summarize the list of bugs. LIST OF BUGS (FIXED FOR FOLLOWING VERSION) FOR IBIS_CHK YES NO Version 2.1.10 X BUG1 Multiple Disclaimers X BUG2 Package Model Warning Message for Legal Suffixes X BUG3 Incorrect [Model] Sub-parameter Syntax Not Reported X BUG4 Printout Version No. Version 2.1.11 BUG5 Additional Value Checking BUG6 Output Control BUG7 Check of VI Curves Against Waveforms Version 3.XXX Plan: BUG8 Reserved Words Used as Pin Numbers Generate Errors New Bugs for Consideration: BUG9 Crash if Keyword Associated with [Model] Comes First BUG10 Crash if Parser Encounters Empty V/I Table BUG11 Parser Continues after [End] Keyword BUG12 Lines Greater than 1024 Characters Cause Wrong Line Numbers BUG13 Parser Crashes if Error in Line Longer than 256 Characters BUG14 Long Illegal Keyword Prints Meaningless Message BUG15 "Program Bug" for Version 1.1 Files with more than 512 Pins BUG16 [Package] Argument Does Not Give Error BUG17 Incomplete [Pin] L_pin, C_pin, R_pin Error Message BUG18 Other Order R_pin, L_pin, C_pin Columns Not Correctly Read From owner-ibis Fri Sep 26 09:05:53 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id JAA17265 for ; Fri, 26 Sep 1997 09:05:52 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id JAA05252 for ; Fri, 26 Sep 1997 09:04:18 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma004967; Fri, 26 Sep 97 09:04:02 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07647 for ibis@vhdl.org; Fri, 26 Sep 97 09:03:47 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA27169; Fri, 26 Sep 97 09:05:10 PDT Date: Fri, 26 Sep 97 09:05:10 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9709261605.AA27169@rockie.nsc.com> To: ibis@vhdl.org Subject: NEW SuperI/O IBIS model from National Cc: huq@rockie.nsc.com IBIS fans, National Semiconductor's Personal Systems Group has released the following Super I/O IBIS models on it's web site: pc97338.ibs The URL is: http://www.national.com/models Select 'IBIS' and then 'SuperI/O' Best Regards, Syed Vice-Chair ANSI/EIA-656 National Semiconductor Corp. From owner-ibis Fri Sep 26 10:18:17 1997 Received: from fw.icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id KAA18701 for ; Fri, 26 Sep 1997 10:18:15 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Fri, 26 Sep 1997 10:16:32 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 26 Sep 1997 10:16:19 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Fri, 26 Sep 1997 10:16:26 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 26 Sep 1997 10:16:26 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@eda.org Subject: IBISCHK3 FUNDING To IBIS Committee: We are contracting the development of the ibischk3 parser for IBIS Version 3.1. We need to have the funds committed before we start the development. Similar to the funding efforts of the previous ibischk development projects, we are sharing the cost among many companies. The funding committment will be in the form of a purchase order sent to Jeanne Warner as follows: EIA/Electronic Information Group 2500 Wilson Blvd Arlington, VA 22201 Attn: Jeanne Warner (703) 907-7539 FAX: (703) 907-7501 Purchase Order for IBISCHK3 Source Code and Licence Not to EXCEED $2,500 (Two Thousand and Five Hundred Dollars) Once we get the level of committment in place to pay for the development, we will start the project. The actual invoices will be issued against the purchase orders at a time to be decided (approximately around December, 1997) based on actual cost divided by the N companies participating. Please inform (or send a copy of the purchase order) to Bob Ross so we can track the participation in this shared development expense: Bob Ross Interconnectix 10220 S.W. Nimbus Ave., K4 Portland, OR 97223 (503) 603-2523 FAX: (503) 639-3469 Thank you Bob Ross Interconnectix From owner-ibis Sat Sep 27 10:08:54 1997 Received: from localhost.localdomain (root@ppp-206-171-248-34.vntrcs.pacbell.net [206.171.248.34]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA12873 for ; Sat, 27 Sep 1997 10:08:52 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.8.5/8.8.5) with SMTP id KAA01213 for ; Sat, 27 Sep 1997 10:06:15 -0700 Sender: root@localhost.localdomain Message-ID: <342D3D07.2C99572C@pacbell.net> Date: Sat, 27 Sep 1997 10:06:15 -0700 From: jon powell Organization: viewlogic X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Model Web Page Update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The IBIS model web page has been update with several new links including AMTEL and FAIRCHILD. take a look. as always, please refer and problems or new sites to me. thanks jon