From owner-ibis Wed Oct 1 01:14:14 1997 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id BAA00939 for ; Wed, 1 Oct 1997 01:14:08 -0700 (PDT) Received: from eede.ericsson.se (eede.eede.ericsson.se [164.48.127.16]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id KAA04883 for ; Wed, 1 Oct 1997 10:10:21 +0200 (MET DST) Received: from aachen5.eu (aachen5.eede.ericsson.se) by eede.ericsson.se (4.1/SMI-4.1) id AA19051; Wed, 1 Oct 97 09:13:08 +0100 Date: Wed, 1 Oct 97 09:13:08 +0100 From: eedhodi@eede.ericsson.se (Holger Dierks) Message-Id: <9710010813.AA19051@eede.ericsson.se> To: ibis@vhdl.org Subject: REQUEST Cc: eedhodi@eede.ericsson.se From owner-ibis Wed Oct 1 09:35:34 1997 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA10630 for ; Wed, 1 Oct 1997 09:35:33 -0700 (PDT) Received: from mrohub2.mro.dec.com (mrohub2.mro.dec.com [16.34.192.32]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA22582 for ; Wed, 1 Oct 1997 12:26:57 -0400 (EDT) Received: by mrohub2.mro.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35) id <01BCCE65.4FF11670@mrohub2.mro.dec.com>; Wed, 1 Oct 1997 12:26:58 -0400 Message-ID: From: Jason Pritchard To: "'ibis@vhdl.org'" Subject: subscribe Date: Wed, 1 Oct 1997 12:22:12 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please place me on your mailing list. Thanks, Jason Pritchard Alpha Server Signal Integrity Digital Equipment Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (508) 493-2654 voice (508) 493-0941 FAX pritchard@eng.pko.dec.com __o _`\<,_ (_)/ (_) ~~~~~~~~~~ From owner-ibis Wed Oct 1 10:10:39 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 KAA11282; Wed, 1 Oct 1997 10:10:38 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.8.5/8.8.5) id KAA21855; Wed, 1 Oct 1997 10:09:00 -0700 (PDT) Message-Id: <3.0.32.19971001100903.0070df10@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 01 Oct 1997 10:09:04 -0700 To: Celso Faia , ibis@vhdl.org, ibis-users@vhdl.org From: Kellee Crisafulli Subject: Re: Real World Measurements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Cesco At 09:51 AM 10/1/97 -0400, Celso Faia wrote: >Greetings, > >Has anyone out there in IBIS LAND ever create an ibis model >from direct IC measurements. If so could you provide a detailed >explanation as to how and what measuring equipment was used. >Are there any issues associated with this method of ibis model >extraction. Their is a very nice write up from Intel on the IBIS site on this subject called the IBIS cookbook. They are working on a new version as well. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Wed Oct 1 06:46:15 1997 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA07160; Wed, 1 Oct 1997 06:46:14 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id GAA08126; Wed, 1 Oct 1997 06:44:38 -0700 (PDT) Received: from hi-av1.cadence.com(158.140.128.31) by mailgate.cadence.com via smap (V1.0mjr) id sma875713477.008123; Wed Oct 1 06:44:37 1997 Received: from unihsa0.Cadence.COM (unihsa0 [158.140.95.36]) by mailhub.Cadence.COM (8.8.5/8.7.3) with SMTP id GAA28869; Wed, 1 Oct 1997 06:43:31 -0700 (PDT) Received: from unipna3 by unihsa0.Cadence.COM (1.38.193.4) id AA19686; Wed, 1 Oct 1997 09:38:21 -0400 Message-Id: <34325557.2534@cadence.com> Date: Wed, 01 Oct 1997 09:51:19 -0400 From: Celso Faia Organization: Cadence Design Systems X-Mailer: Mozilla 3.01 (WinNT; I) Mime-Version: 1.0 To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Real World Measurements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings, Has anyone out there in IBIS LAND ever create an ibis model from direct IC measurements. If so could you provide a detailed explanation as to how and what measuring equipment was used. Are there any issues associated with this method of ibis model extraction. Thanks, Celso -- ****************************************************************** * Celso Faia * Phone: 613-596-9091 x337 * * Cadence Design Systems Ltd * Fax: 613-596-9080 * * Ottawa, Ontario, Canada * Email: celso@cadence.com * ****************************************************************** From owner-ibis Wed Oct 1 11:52:40 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 LAA13188; Wed, 1 Oct 1997 11:52:40 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA09113; Wed, 1 Oct 1997 11:51:02 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma008885; Wed, 1 Oct 97 11:50:50 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA08594 for ibis@vhdl.org; Wed, 1 Oct 97 11:50:35 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA14681; Wed, 1 Oct 97 11:52:03 PDT Date: Wed, 1 Oct 97 11:52:03 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9710011852.AA14681@rockie.nsc.com> To: ibis@vhdl.org, ibis-users@vhdl.org, celso@cadence.com Subject: Re: Real World Measurements Celso, The Electronic Design Article on the IBIS webpage titled 'Ease System Simulation With IBIS Device Models' lists a variety of vendors/instruments make/model that National uses for IBIS modeling based on measurements. Regards, Syed. National Semiconductor Corp. > > Greetings, > > Has anyone out there in IBIS LAND ever create an ibis model > from direct IC measurements. If so could you provide a detailed > explanation as to how and what measuring equipment was used. > Are there any issues associated with this method of ibis model > extraction. > > Thanks, > > Celso > > -- > ****************************************************************** > * Celso Faia * Phone: 613-596-9091 x337 * > * Cadence Design Systems Ltd * Fax: 613-596-9080 * > * Ottawa, Ontario, Canada * Email: celso@cadence.com * > ****************************************************************** > From owner-ibis Thu Oct 2 00:05:29 1997 Received: from s1.fh-landshut.de (s1.fh-landshut.de [193.175.141.54]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id AAA26067 for ; Thu, 2 Oct 1997 00:05:26 -0700 (PDT) Received: from s10.fh-landshut.de by s1.fh-landshut.de with SMTP (1.38.193.4/16.2) id AA00888; Thu, 2 Oct 1997 09:02:16 +0200 Sender: schwa1@fh-landshut.de Message-Id: <343346F7.1FD1@fh-landshut.de> Date: Thu, 02 Oct 1997 09:02:15 +0200 From: Schneider Walter Organization: Fachhochschule Landshut X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX A.09.07 9000/715) Mime-Version: 1.0 To: ibis@vhdl.org Subject: questions on ibis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello! After creating some ibis-modells and simulating with them, I have now some questions: 1) Does anyone know, what voltage step (u/i-tables) is normally used? I had the problem that by taking a step of 0.1V some oscillations occured when simulating a transmission line. By increasing the step up to 0.5V these oscillations disappeared. What can be the reason for this? 2) The ibis-specification defines what voltages, temperatures and process parameters have to be used for simulating worst/best case conditions only for TTL- and CMOS-technologies? What should be used for ABT (advanced BICMOS technology) or BCT (BICMOS technology)? 3) By creating the u/i-tables from actual silicon measurements the voltage sweep (-VCC ... +2VCC) must be reduced. To cover the recommended region the specification says to make an extrapolation. Has anyone ever made such an extrapolation and compared the simulation results with an ibis-modell without the extrapolation (i.e. reduced u/i-tables) ? I hope I hear from you soon! Thank you very much! email: schwa1@fh-landshut.de mail: Walter Schneider Muehlweg 25 94513 Schoenberg Germany phone: 08554/3916 From owner-ibis Thu Oct 2 15:19:12 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 PAA12706 for ; Thu, 2 Oct 1997 15:19:11 -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 PAA09785 for ; Thu, 2 Oct 1997 15:22:55 -0700 (PDT) Received: from mh-relay by ichips.intel.com (8.7.4/jIIIa) id PAA24430; Thu, 2 Oct 1997 15:17:34 -0700 (PDT) Message-Id: <199710022217.PAA24430@ichips.intel.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Minutes 9/26 Date: Thu, 02 Oct 1997 15:17:33 -0700 From: Stephen Peters DATE: October 2, 1997 SUBJECT: 9/26/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 Wiens 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 10/17/97 (916) 356-9200 4-120224 5819441 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 No new participants. Patti Rusher and Chris Rokusek could not attend this meeting. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross did not have any updates. The last treasurer's report is $5,272. We are still following up on one member's payment. REVIEW OF MINUTES AND AR'S Bob Ross reported that Dave Wiens name was corrected in several places from Wien. The next meeting Date was corrected in the Passcode section. Stephen Peters indicated that a number of AR's had been fulfilled and this will be discussed during the meeting. Other AR's will be carried forward. MISCELLANY/ANNOUNCEMENTS Bob Ross has been investigating slow eda.org IBIS reflector responses. At this time he does not know if this is something associated with eda.org and the network in general or is a problem with his site. PRESS AND WEB PAGE UPDATES Syed Huq updated us on progress. The next Web page update will contain a revised link to s2ibis2 on eda.org since the NCSU link did not have the fixed code. He has added to the FAQ information regarding filing bug reports for ibischk. However, because Bob Ross moved the location under eda.org to /pub/ibis/bugs/ibischk, the answer needs to be revised. Syed also added H.A.S. Electric to the roster and changed the membership status of some other entries. Syed is still pursuing adding the logo of AMP to the Poster Page. [Done]. Syed will add a link to the interim updated IBIS Cookbook under development for downloading. It is located as: ftp://ftp.eda.org/pub/ibis/wip/ckbkwfw3.doc Bob reported that he received permission to post his paper "Practical Issues with IBIS Models" given at the PCB Design Conference East in September 1997, and it is available for downloading at: ftp://ftp.eda.org/pub/ibis/docs/pcbeas97.doc Syed will convert it to html format for the EIA/IBIS Web site linking. Syed has received permission and will also provide a link to his open tutorial presentation "Understanding and Using IBIS Models for Signal Integrity Analysis" at the Electronic System Design Conference (HESDC '97) in October 1997. Bob added after the meeting that "SPICE and IBIS" were discussed in a Commentary by Charles Small in Computer Design, September, 1997, pg. 44, titled "Taking the Drudgery out of Component Selection". NEW MODELS AVAILABLE, LIBRARY UPDATE Arpad Muranyi reported that there are some updates to some Intel IBIS models available under NDA. Raj Raghuram questioned why models needed to be under NDA, contrary to the non-proprietary nature of the IBIS format. Stephen Peters defended the NDA policy for devices that have not been officially released. However, Arpad indicated that these models were for already released devices. So this is an internal Intel policy. Bob Ross reported that Matthew Flora discovered that Atmel has a site for IBIS models at: http://www.atmel.com/atmel/products/prod173.htm Bob reported that the National GTL models are now at Fairchild Semiconductor at: http://www.fairchildsemi.com/models/Ibis/Gtl/index.html The National Clock Generation and Support Models are also at Fairchild at: http://www.fairchildsemi.com/models/Ibis/Cgs/index.html Bob also reported more IDT models and that Motorola has removed an empty models directory for FSRAM. OPENS FOR NEW ISSUES None. INTERNATIONAL PROGRESS - 93/46/NP (IBIS Version 2.1) - Bob Ross reports that ANSI/EIA-656 has been approved as an international standard at the Tokyo meeting on September 16- 18, 1997 according to Patti Rusher. Its number is IEC 62014-1. There was an objection based on the existence of IBIS Version 3.0, but that objection was withdrawn after it was revealed that Version 3.1 is planned for the formal standardization processes. IBIS has passed these stages: Committee Draft for Comment (CDC) and Committee Draft for Vote (CDV). Once the voting report is officially approved at the IEC headquarters in Geneva, IEC 62014-1 will be official. Patti will then issue a press release. - 93/60/NP (IBIS Models and EMC Simulation) - Bob reports that no document exists backing this proposal. It looks like this proposal is being withdrawn. An investigation committee on EMI and EMC is being set up in IEC. - EIAJ III (I/O Interface Model for ICs) - The EIAJ subcommittee gave its presentation and showed Version 0.0. (This is the same document presented at the IBIS subgroup meeting in March 1997 in Santa Clara.) The proposal has been accepted as a new work item under IEC TC93. This along with other related activities above have been moved from WG3 to WG6. Patti recommends that there be coordination with the Compact Modeling Council (for Spice BSIM3 Version 3.1 standardization) and IBIS. Bob also discussed some of the Compact Modeling Council activities and its structure under EIA. EAST COAST IBIS USERS GROUP REPORT (ALSO PCBEAST) Bob Ross reported that a very successful initial IBIS East Users Group meeting hosted by Dr. Ed Sayre of North East Systems Associates (NESA) was held in Foxboro, Massachusetts on Thursday, September 18, 1997. About 42 people attended including several West coast people. The discussion concerned general topics related to IBIS models, accuracy, applicability, and availability. Ed plans to continue having monthly user group meetings. Participants in the meeting who were online today included Jeff Chu, Arpad Muranyi, Graham Bell, and Bob Ross. All gave positive comments. Arpad asked if presentations would be published. Bob thought probably not. They involved updated information from Bob's IBIS Summit presentation (which can be posted separately) and a general presentation by Gary Husted of Intel on Intel's handling of IBIS models. S2IBIS FOR NT Bob Ross reports Dave Wiens has posted s2ibis_ver1.3 on the VeriBest Web site. s2ibis_ver2.1 is still under development so that part of the AR remains. AR - Ian Dodd put s2ibis_ver2.1 for Windows on the VeriBest Web site. EDITING COMMITTEE Stephen Peters reported no further work. The existing AR's are still in effect. Bob plans to comply with them within weeks since he now has some time. Stephen reported that Bob posted an unofficial tree diagram for IBIS Version 3.0 in eda.org under /pub/ibis/wip/tree3_0.txt. This was and extension of Ogawa-san's earlier work and is provided for information. 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 Bob Ross indicated that the processing of BIRD44 will be deferred until we have a revised Version 3.0 draft to work with. Jeff Chu asked for a clarification of min and max, as it related to this issue. A discussion followed, pointing to information in the Notes on Data Derivation Section at the end of the IBIS document. VERSION 2.1 PARSER (& S2IBIS) BUG REPORTING Bob Ross reported that Matthew Flora generated an NT version of ibischk2+ which also works under Windows95. It is stored on eda.org as /pub/ibis/ibschk2+/dos32/ibischk2.exe. The dos32 directory is used for 32 bit DOS. The utility does not work with 16 bit DOS systems. There already exists an ibischk2.exe under the ibischk2 subdirectory for all DOS systems. The AR regarding an additional FAQ has been done (although it now needs revision as previously discussed because the ibischk information has been moved to a newly created subdirectory /pub/ibis/bugs/ibischk). Stephen Peters questioned Bob about the AR concerning s2ibis bugs. That AR has also been completed. Under eda.org/pub/ibis/bugs, there exists three new subdirectories (along with the ibischk subdirectory) of /pub/ibis/bugs/s2ibis, /pub/ibis/bugs/s2ibis2, /pub/ibis/bugs/s2iplt. Bug report forms exist in each of these subdirectories (the .txt document). Sent all bug reports to ibischk-bug@eda.org. A separate e-mail address for the Spice related bugs is not planned. (Note, this process is also documented at the end of these Minutes.) VERSION 3.1 PARSER DEVELOPMENT Bob Ross reported that a committee reviewed the bids and options and selected a contractor. The contractor, based in India, has an excellent track record working with several IBIS member companies on IBIS and modeling projects. The committee also proposed a funding method (thanks to the suggestion by Chris Rokusek) that purchase orders be issued for the IBISCHK3 Source Code and License not to exceed $2,500. This will allow sharing the development costs among several companies. Once the bid price is reached through purchase order commitments, the contractor can start. The actual invoice will then be the total cost divided by the number of companies participating. Bob estimates that the actual invoice may be about $1,500 per company. The IBIS Open Forum agreed to proceed with this plan. Bob will sent out the information for generating the purchase orders. Bob polled the members and got indications of solid commitments from seven companies. Bob also knows of likely commitments from three more. The IBIS forum will still be seeking others commit to this joint development project to drive down the cost for each company. Bob estimates the invoices will be issued around December, 1997. Once the invoices are issued, the ibischk3 parser price will be established as that price for future purchases (to be fair to the original group). AR - Bob Ross send out on the IBIS reflector information for generating purchase order. [Done] Bob mentioned that per a reflector e-mail from Kellee Chrisafulli, he has created a directory on eda.org under /pub/ibis/samples for files to be used for testing. There are subdirectories for ver1.1, ver2.1 and ver3.0 samples. Bob currently has the cbt.ibs for a 74CBT3383 series switch device under ver3.0. Also the test matrix for Version 3.0 tests needs to be extended from the older Version 2.1 test matrix. With an external contractor doing the ibischk3 development, we can focus on the testing and validation portion of the project. COOKBOOK As previously mentioned Stephen Peters has supplied the interim ckbkwfw3.doc posted in eda.org under /pub/ibis/wip. It will be updated regularly. Bob Ross commented that the last section still contains an e-mail access method that needs to be deleted. Stephen welcomes review and comments. The previous ARs are carried forward. Syed Huq has completed the link to the Cookbook document from the EIA/IBIS Web page, and it should be in place at the next Web page update. The other ARs carried forward are as follows: 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". VERSION3.0 PRIORITIES DISCUSSION Per the discussion of last meeting, Bob Ross opened the meeting to discussion of semiconductor vendor priorities concerning Version 3.0 features. Frank Kern and Stephen Peters added some priorities to the previous discussion to prioritize from a list of general features. (Some other members had to leave the meeting.) The list below shows the highest priority features: [Model Selector] [Driver Schedule] Electrical Board Description Package Model Extensions (for lines) Features lower on the priority list included: Diode kickback ([TTgnd], [TTpower] Series Elements Series Switches [Model Spec] and [Component] test point subparameters Frank also reinforced the need for some Verion 2.1 features missing in some simulators including the independent voltage reference selections. NEW IBISCHK BUGS Bob Ross opened the subject of recently reported bugs. Matthew Flora had just submitted bugs against the existing ibischk2 and ibischk2+ parsers. The purpose was to decide the severity, priority and further action. The general action will be to provide a version 2.115 upgrade of ibischk2+. That will provide a better baseline to begin the ibischk3 development project. Matthew was able to isolate the source and cause of most of the bugs and is available to do the upgrade. Most of the fixes are minor. Bob and Matthew review the bugs with this format: (Severity, Priority, Action, Notes). When a file has [IBIS Ver] 1.1, the ibischk2+ parser uses the original ibis_chk code developed for Version 1.1 files. So when the note refers to Version 1.1 files, it means that the bug was introduced during the ibischk2 development project. BUG9 Crash if Keyword Associated with [Model] Comes First (Severe, High, Fix, Does not crash for Version 1.1 files) BUG10 Crash if Parser Encounters Empty V/I Table (Severe, High, Fix, Does not crash for Version 1.1 files) BUG11 Parser Continues after [End] Keyword (Moderate, Medium, Fix, Works properly for Version 1.1 files) BUG12 Lines Greater than 1024 Characters Cause Wrong Line Numbers (Annoying, Low, Fix, Cause identified) BUG13 Parser Crashes if Error in Line Longer than 256 Characters (Annoying, Low, Fix, Cause identified) BUG14 Long Illegal Keyword Prints Meaningless Message (Annoying, Low, Fix - A Version 1.1 problem that is not a problem with Version 2.1 files) BUG15 "Program Bug" for Version 1.1 Files with more than 512 Pins (Moderate, Medium, Fix, an old Version 1.1 defect that does not exist with Version 2.1 files) BUG16 [Package] Argument Does Not Give Error (Moderate, Medium, Fix, Works properly for Version 1.1 files) BUG17 Incomplete [Pin] L_pin, C_pin, R_pin Error Message (Annoying, Low, Fix, Works properly for Version 1.1 files) BUG18 Other Order R_pin, L_pin, C_pin Columns Not Correctly Read (Moderate, Medium, Chris Rokusek Fix? - This is related to some incorrect warnings in ibischk2+ when the columns are legally interchanged.) In addition, the ibischk2+ version number will be incremented to 2.115. Also, Bob and Matthew will deal off-line on putting in an error report switch as discussed at the last meeting. Bob feels this is of lower priority than getting the code itself fixed. BIRD42.3 - MODELING CURRENT WAVEFORMS Bob Ross mentioned D.C. Sessions wrote a comment on BIRD42.3. However, the general discussion was deferred due to lack of time. SWITCHING TERMINATORS No Report. NEXT MEETING: The next meeting is on Friday, October 17, 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/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. 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 Thu Oct 2 13:34: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 NAA10780; Thu, 2 Oct 1997 13:34:52 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Thu, 2 Oct 1997 13:33:14 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Thu, 2 Oct 1997 13:33:03 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Thu, 2 Oct 1997 13:33:08 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Thu, 2 Oct 1997 13:33:08 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org, ibis@eda.org Subject: Re: questions on ibis Cc: schwa1@fh-landshut.de Walter: You raised some good questions. I have some comments in your questions which may help. Best Regards Bob Ross Interconnectix >Date: Thu, 02 Oct 1997 09:02:15 +0200 >From: Schneider Walter >Organization: Fachhochschule Landshut >To: ibis@vhdl.org >Subject: questions on ibis > >Hello! > >After creating some ibis-modells and simulating with them, I have >now some questions: > >1) Does anyone know, what voltage step (u/i-tables) is normally used? > I had the problem that by taking a step of 0.1V some oscillations > occured when simulating a transmission line. By increasing the > step up to 0.5V these oscillations disappeared. > What can be the reason for this? I would have to see the test circuit, results, and full model to figure out what is expected and how bad the results are. This could also be dependent on what simulator is used and its internal algorithms. There could be a numerical processing issue related to internal time steps that may induce or kill the oscillation. In general, I would expect that you would get better results with more data points if they are continous-like in nature. > >2) The ibis-specification defines what voltages, temperatures and > process parameters have to be used for simulating worst/best case > conditions only for TTL- and CMOS-technologies? > What should be used for ABT (advanced BICMOS technology) or > BCT (BICMOS technology)? Still use low voltage, slow-weak process for the min column, and the opposite for the max column. The real issue what temperature to use. My first approach was to base the temperature on the output stage technology. However, when I tried this, it did not give me the fastest or slowest responses. So I now try both temperature extremes and take the temperature which gives me the slowest rise and fall times for the min column, and fastest rise and fall times for the max column. In one ABT case this worked out to be the highest temperature for the min column, and lowest temperature for the max column. > >3) By creating the u/i-tables from actual silicon measurements > the voltage sweep (-VCC ... +2VCC) must be reduced. > To cover the recommended region the specification says to make > an extrapolation. > Has anyone ever made such an extrapolation and compared the > simulation results with an ibis-modell without the extrapolation > (i.e. reduced u/i-tables) ? Many behavioral simulators automatically do extrapolation of the VI table endpoints. So the results should be the same even if the extrapolated data is not provided. However, when tranforming the IBIS data into a Spice syntax using table based controlled voltage or controlled current sources, there will be a difference. Most Spice simulators will truncate the tables to the endpoint current values if the voltages are outside of the table range. So if a reflected signal actually causes a voltage outside of the table value, the result should be different. IBIS contains the range requirements so that all types of simulators will process the same set of data. > > >I hope I hear from you soon! > >Thank you very much! > > > >email: schwa1@fh-landshut.de > >mail: Walter Schneider > Muehlweg 25 > 94513 Schoenberg > Germany > phone: 08554/3916 > From owner-ibis Thu Oct 2 17:53:25 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 RAA15357 for ; Thu, 2 Oct 1997 17:53:24 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Thu, 2 Oct 1997 17:51:37 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Thu, 2 Oct 1997 17:51:26 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Thu, 2 Oct 1997 17:51:31 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Thu, 2 Oct 1997 17:51:31 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: dc.sessions@tempe.vlsi.com, ibis@eda.org Subject: Re: BIRD 42.3 DC: I have been considering your response for quite a while. Here are some of my comments: (1) You have provided an interesting demonstration case where a two-waveform based IBIS model may be needed. If you terminate the load to Vcc, then there will be no difference in theory. However, if you terminate the output to some other voltage, you will see a difference. (2) It is also interesting that you pose the problem in terms of conductance variations (which could be implied by the IBIS architecture.) It could have been presented in terms of resistance variations. However, there would be an implied difference. Pulldown one, for example goes linearly from 0 to 20 mS conductance. If it were expressed as resistance, it would go non-linearly from infinite to 100 ohms to 50 ohms resistance. (3) I understand that there are other real world effects that can enter into the bounce analysis that may not show up in the IBIS model processing. I would still think that a delta current could still be used for some of these effects that are caused just by the device switching itself. Bob Ross Inteconnectix Date: Fri, 05 Sep 1997 12:23:45 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. To: IBIS Mailing list Subject: BIRD 42.3 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 Oct 3 09:04:47 1997 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA00959 for ; Fri, 3 Oct 1997 09:04:46 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id JAA15091; Fri, 3 Oct 1997 09:03:06 -0700 (PDT) Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma875885225.000320; Fri Oct 3 06:27:05 1997 Received: (from cpk@localhost) by hot.Cadence.COM (8.7.3/8.7.3) id JAA10440; Fri, 3 Oct 1997 09:28:39 -0400 (EDT) Date: Fri, 3 Oct 1997 09:28:39 -0400 (EDT) From: "C. Kumar" Message-Id: <199710031328.JAA10440@hot.Cadence.COM> To: dc.sessions@tempe.vlsi.com, ibis@eda.org, bob@icx.com Subject: Re: BIRD 42.3 Cc: cpk@hot.Cadence.COM X-Sun-Charset: US-ASCII DC: I have not also had time to respond to bird 42.3. Your one specific example of zero current does not detract away the utility of the original contention for current waveforms in bird 42.3. IBIS metholody is a general black box methodology and should not be confined to the vagaries of specific technologies. Adding the current waveforms is relatively minor matter since during the spice runs the data is easily available. Redundacy in some cases does just not justify keeping out the data. - kumar > From owner-ibis@server.vhdl.org Fri Oct 3 00:44 EDT 1997 > From: bob@icx.com ( Bob Ross) > To: dc.sessions@tempe.vlsi.com, ibis@eda.org > Subject: Re: BIRD 42.3 > Content-Type: text > Content-Length: 2935 > X-Lines: 83 > > DC: > > I have been considering your response for quite a while. > Here are some of my comments: > > (1) You have provided an interesting demonstration > case where a two-waveform based IBIS model may be needed. > > If you terminate the load to Vcc, then there will be > no difference in theory. However, if you terminate the > output to some other voltage, you will see a difference. > > (2) It is also interesting that you pose the problem > in terms of conductance variations (which could > be implied by the IBIS architecture.) It could > have been presented in terms of resistance > variations. However, there would be an implied > difference. Pulldown one, for example goes > linearly from 0 to 20 mS conductance. If it > were expressed as resistance, it would go > non-linearly from infinite to 100 ohms to 50 ohms > resistance. > > (3) I understand that there are other real world > effects that can enter into the bounce analysis > that may not show up in the IBIS model processing. > I would still think that a delta current could > still be used for some of these effects that > are caused just by the device switching itself. > > Bob Ross > Inteconnectix > > Date: Fri, 05 Sep 1997 12:23:45 -0700 > From: "D. C. Sessions" > Organization: VLSI Technology Inc. > > To: IBIS Mailing list > Subject: BIRD 42.3 > > > 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 Oct 3 12:27:14 1997 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA04677 for ; Fri, 3 Oct 1997 12:27:13 -0700 (PDT) Received: from valencia.rsn.hp.com (valencia.rsn.hp.com [15.99.50.121]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id MAA03160; Fri, 3 Oct 1997 12:25:35 -0700 (PDT) Received: (from schumach@localhost) by valencia.rsn.hp.com (8.7.1/8.7.1) id OAA12107; Fri, 3 Oct 1997 14:25:24 -0500 (CDT) From: "Richard A. Schumacher" Message-Id: <199710031925.OAA12107@valencia.rsn.hp.com> Subject: Re: BIRD 42.3 To: cpk@cadence.com Date: Fri, 03 Oct 1997 14:25:23 CDT Cc: dc.sessions@tempe.vlsi.com, ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM In-Reply-To: <199710031328.JAA10440@hot.Cadence.COM>; from "C. Kumar" at Oct 3, 97 9:28 am X-Mailer: Elm [revision: 212.2] In other words, different applications require different device models. Even one given circuit will require different models depending, as in the example, on whether the time between output transitions is greater than or less than the settling time. True? > > (1) You have provided an interesting demonstration > > case where a two-waveform based IBIS model may be needed. > > > > If you terminate the load to Vcc, then there will be > > no difference in theory. However, if you terminate the > > output to some other voltage, you will see a difference. > > > > (2) It is also interesting that you pose the problem > > in terms of conductance variations (which could > > be implied by the IBIS architecture.) It could > > have been presented in terms of resistance > > variations. However, there would be an implied > > difference. Pulldown one, for example goes > > linearly from 0 to 20 mS conductance. If it > > were expressed as resistance, it would go > > non-linearly from infinite to 100 ohms to 50 ohms > > resistance. > > > > (3) I understand that there are other real world > > effects that can enter into the bounce analysis > > that may not show up in the IBIS model processing. > > I would still think that a delta current could > > still be used for some of these effects that > > are caused just by the device switching itself. > > > > > > 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. From owner-ibis Fri Oct 3 13:11:07 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 NAA05399 for ; Fri, 3 Oct 1997 13:11:06 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id MAA27356 for ; Fri, 3 Oct 1997 12:56:35 -0700 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (V2.0) id xma027249; Fri, 3 Oct 97 12:56:19 -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 MAA14149 for ; Fri, 3 Oct 1997 12:56:17 -0700 Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA14946; Fri, 3 Oct 1997 12:56:15 -0700 Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Message-ID: <34354DDF.C69CC504@tempe.vlsi.com> Date: Fri, 03 Oct 1997 12:56:15 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: "C. Kumar" CC: ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM Subject: Re: BIRD 42.3 References: <199710031328.JAA10440@hot.Cadence.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit C. Kumar wrote: > Bob Ross wrote [attribution restored -- dcs]: > > D. C. Sessions wrote [attribution restored -- dcs] > I have not also had time to respond to bird 42.3. Your one specific example of zero current does not detract away the utility of the original contention for current waveforms in bird 42.3. Speaking as an I/O designer, we work *very* hard to avoid crowbar current. This is not just a matter of a specific example; it's the majority case. IMNSHO, an extension to the standard which *only* addresses cases with major crowbar current is best described as "one specific example." Parsimony dictates that we *not* extend the standard willy-nilly; if there are two possible extensions, one of which is only marginally applicable to a rare condition and another which addresses both that *and* the majority case, the latter is always to be preferred. > IBIS metholody is a general black box methodology and should not be confined to the vagaries of specific technologies. True enough, but its relevance escapes me.. > Adding the current waveforms is relatively minor matter since during the spice runs the data is easily available. Redundacy in some cases does just not justify keeping out the data. I could name a thousand "minor matters" which might be nice to have in one-of-a-kind situations. We're not adding them because their net impact on the usefulness of the standard is *negative*. Repeating what I wrote in the first place: > > 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. Real-world, IMMEDIATE applications such as SSTL can't be properly modeled right now without addressing the case I presented. (look back at the time-domain behavior and see what it implies when applied to a line terminated to Vddq/2) This isn't something we can blow off by pretending it's a rare case. We *need* to address the issue. When we have, we'll also have a solution to the (rare) crowbar-current problem as a freebie. So what are we going to do? -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Fri Oct 3 13:16:26 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 NAA05572 for ; Fri, 3 Oct 1997 13:16:26 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id NAA28284 for ; Fri, 3 Oct 1997 13:14:19 -0700 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (V2.0) id xma028273; Fri, 3 Oct 97 13:14:16 -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 NAA14426 for ; Fri, 3 Oct 1997 13:14:14 -0700 Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA15618; Fri, 3 Oct 1997 13:14:13 -0700 Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Message-ID: <34355215.DD28A101@tempe.vlsi.com> Date: Fri, 03 Oct 1997 13:14:13 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Bob Ross CC: ibis@eda.org Subject: Conductance (was: BIRD 42.3) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Ross wrote: > (2) It is also interesting that you pose the problem > in terms of conductance variations (which could > be implied by the IBIS architecture.) It could > have been presented in terms of resistance > variations. However, there would be an implied > difference. Pulldown one, for example goes > linearly from 0 to 20 mS conductance. If it > were expressed as resistance, it would go > non-linearly from infinite to 100 ohms to 50 ohms > resistance. In general I dislike dividing by zero; I'd much rather deal with tens of siemens at one end of the scale than (fictitious) millions of ohms at the other. Also, it turns out to be a more-nearly-realistic time-domain process with the output device ramping up its conductivity as its controls change state. ("Hello, students, can you say 'transconductance'?" Sorry -- Friday.) > (3) I understand that there are other real world > effects that can enter into the bounce analysis > that may not show up in the IBIS model processing. > I would still think that a delta current could > still be used for some of these effects that > are caused just by the device switching itself. I've been dealing with conductivity modulation in output devices for more than a year and don't see a clean solution short of full SPICE simulation. Life just isn't fair sometimes. Until someone smarter than me comes up with a solution, we'll have to deal with the sort-of-linear model that's implied by IBIS. It's really not all that bad in principle but there are all sorts of uglies hiding in the details. If we're going to get serious about doing SSO analysis in an IBIS context the biggest obstacle isn't crowbar current (sorry; cheap shot) it's the lack of useful power-distribution information. Supply connections are extremely local, so it's not helpful to know the total number of power and ground contacts on a part -- you have to know which ones feed which pins and their relationship to other supplies less near. Once we have *that* we can make a pretty good guess about the rail potential changes and IBIS v/i curves do a fair job from there. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Fri Oct 3 13:25:22 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 NAA05605 for ; Fri, 3 Oct 1997 13:25:22 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id NAA28659 for ; Fri, 3 Oct 1997 13:23:15 -0700 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (V2.0) id xma028646; Fri, 3 Oct 97 13:22:45 -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 NAA14559 for ; Fri, 3 Oct 1997 13:22:43 -0700 Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA15867; Fri, 3 Oct 1997 13:22:42 -0700 Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Message-ID: <34355411.995F94FD@tempe.vlsi.com> Date: Fri, 03 Oct 1997 13:22:42 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: "Richard A. Schumacher" CC: ibis@eda.org Subject: Re: BIRD 42.3 References: <199710031925.OAA12107@valencia.rsn.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard A. Schumacher wrote: > > In other words, different applications require different > device models. Even one given circuit will require > different models depending, as in the example, on whether > the time between output transitions is greater than or less > than the settling time. True? That's one way. (For those joining late: Mr. Schumacher refers to the problem where an output is still sourcing current into an unsettled line when it switches LOW. The pullup turnoff will produce one output step, followed some time later by the pulldown turnon step.) Far more serious, I would tink, is the situation in terminated lines (eg, SSTL) where the line NEVER quiesces to a zero-current state. For a whole lot of reasons, the output will almost always do a two-step: first to the OFF state and then to the reverse state. The difference between this and the academic smooth-transition model is pretty significant. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Fri Oct 3 14:58:39 1997 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA07211 for ; Fri, 3 Oct 1997 14:58:38 -0700 (PDT) Received: from fmmail.fm.intel.com (fmmail.fm.intel.com [198.175.75.69]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id OAA19906; Fri, 3 Oct 1997 14:56:33 -0700 (PDT) Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.8.5/8.7.3) id OAA10837; Fri, 3 Oct 1997 14:52:10 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 03 Oct 97 14:52:10 PDT Date: Fri, 03 Oct 97 14:14:00 PDT From: Arpad Muranyi Message-ID: To: cpk@cadence.com cc: ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM Subject: Re[2]: BIRD 42.3 Text item: All, I have been following this discussion, but didn't reply for a while because it wasn't entirely clear what the real issue was (is). Now it seems that D. C. Sessions' example really addresses the issue of modeling the turn-off characteristics of a transistor. This is important - as he says - when the signal didn't settle yet, or when there are DC currents through resistive terminations of some sort. In the days when we were working on the 2.0 specification and were discussing the usage and implementation of V-t curves in the Open Forum meetings I brought up something that may apply to this issue. In those days we decided not to put it into the spec for various reasons, but now it seems that we probably should have addressed the issue somehow. My goal was to use the V-t curves for characterizing both the turn-on and turn-off behavior of the transistors. Starting with the assumption that designers try to avoid crowbar currents like a plague, one can see why transistors get usually turned off much quicker than turned on. Now, if I generate a rising V-t curve with a resistor to GND, I will get the turn-on characteristics of the pullup transistor. However, if I generate a rising V-t curve with a resistor to Vcc, I will get the turn off characteristics of the pulldown transistor (because the resistor will pull the voltage high before the pullup transistor even started to turn on). This is why my IBIS models have four V-t curves for a CMOS buffer and two for a GTL buffer. With the appropriate combinations of Vfixture and Rfixture values I am describing the turn-on and turn-off characteristics of the transistors. In my behavioral HSPICE I/O buffer model this is how I use the V-t curves, and I get the kind of results one would get in real life. If I have a resistive termination to Vcc/2, I would normally see a quick edge to Vcc/2 and then a bit later a slower edge towards the opposite rail. If all simulators used these V-t curves the way I intended them to be used, I believe this discussion wouldn't be taking place now. Now, the question is why doesn't the spec describe all this? As I mentioned above, we talked about it, but decided not to write it down. The reason was that there are always exceptions (as this discussion is also alluding to it) and we didn't want to impose a possible limitation in the future by writing something this down. It is very difficult to write a spec which is general enough and does not get outdated as technology evolves. Would it be appropriate to add some clarifications to the spec? Sincerely, Arpad Muranyi Intel Corporation ============================================================================= C. Kumar wrote: > Bob Ross wrote [attribution restored -- dcs]: > > D. C. Sessions wrote [attribution restored -- dcs] > I have not also had time to respond to bird 42.3. Your one specific example of zero current does not detract away the utility of the original contention for current waveforms in bird 42.3. Speaking as an I/O designer, we work *very* hard to avoid crowbar current. This is not just a matter of a specific example; it's the majority case. IMNSHO, an extension to the standard which *only* addresses cases with major crowbar current is best described as "one specific example." Parsimony dictates that we *not* extend the standard willy-nilly; if there are two possible extensions, one of which is only marginally applicable to a rare condition and another which addresses both that *and* the majority case, the latter is always to be preferred. > IBIS metholody is a general black box methodology and should not be confined to the vagaries of specific technologies. True enough, but its relevance escapes me.. > Adding the current waveforms is relatively minor matter since during the spice runs the data is easily available. Redundacy in some cases does just not justify keeping out the data. I could name a thousand "minor matters" which might be nice to have in one-of-a-kind situations. We're not adding them because their net impact on the usefulness of the standard is *negative*. Repeating what I wrote in the first place: > > 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. Real-world, IMMEDIATE applications such as SSTL can't be properly modeled right now without addressing the case I presented. (look back at the time-domain behavior and see what it implies when applied to a line terminated to Vddq/2) This isn't something we can blow off by pretending it's a rare case. We *need* to address the issue. When we have, we'll also have a solution to the (rare) crowbar-current problem as a freebie. So what are we going to do? -- D. C. Sessions dc.sessions@tempe.vlsi.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii References: <199710031328.JAA10440@hot.Cadence.COM> Subject: Re: BIRD 42.3 CC: ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM To: "C. Kumar" MIME-Version: 1.0 X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m) Organization: VLSI Technology Inc. From: "D. C. Sessions" Date: Fri, 03 Oct 1997 12:56:15 -0700 Message-ID: <34354DDF.C69CC504@tempe.vlsi.com> Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA14946; Fri, 3 Oct 1997 12:56:15 -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 MAA141 49 for ; Fri, 3 Oct 1997 12:56:17 -0700 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap ( V2.0) id xma027249; Fri, 3 Oct 97 12:56:19 -0700 Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050 895) id MAA27356 for ; Fri, 3 Oct 1997 12:56:35 -0700 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by server.vhd l.org (8.8.5/8.8.3) with ESMTP id NAA05399 for ; Fri, 3 Oct 1997 1 3:11:06 -0700 (PDT) Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id NAA18598; Fri, 3 Oct 1997 13:33:52 -0700 (PDT) Received: from hebe.or.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0xHERU-000qDSC; Fri, 3 Oct 97 13:35 PDT From owner-ibis Sun Oct 5 04:43:56 1997 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id EAA14523 for ; Sun, 5 Oct 1997 04:43:55 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id EAA11447; Sun, 5 Oct 1997 04:42:11 -0700 (PDT) Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma876051730.011443; Sun Oct 5 04:42:10 1997 Received: (from cpk@localhost) by hot.Cadence.COM (8.7.3/8.7.3) id HAA11923; Sun, 5 Oct 1997 07:43:57 -0400 (EDT) Date: Sun, 5 Oct 1997 07:43:57 -0400 (EDT) From: "C. Kumar" Message-Id: <199710051143.HAA11923@hot.Cadence.COM> To: Arpad_Muranyi@ccm.fm.intel.com Subject: Re: Re[2]: BIRD 42.3 Cc: ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM X-Sun-Charset: US-ASCII Arpad: This is very important and should be added. This is the same reason I believe Dileep of Contec was saying about the multiple way of interpolating v-t curves. The problem is that even though you can provide many v-t tables there is no single unique mathematical solution. While IBIS on the one hand gives the notion of a black box. it certainly is not when it comes to v-t curves where it is subject to severe qualifying assumptions. IBIS spec does not specify clearly the reason for the 4 v-t (not 10 or 100) curves. It should abd the qualifying assumptions should be put on the table unambiguousely. You can have problems with this assumption. Does the crow bar current assumption applies to ECL? Thanx for clarification - kumar > From Arpad_Muranyi@ccm.fm.intel.com Fri Oct 3 17:58 EDT 1997 > From: Arpad Muranyi > To: cpk > cc: ibis@eda.org, bob@icx.com, cpk > Subject: Re[2]: BIRD 42.3 > Content-Type: text > Content-Length: 6830 > X-Lines: 149 > > > Text item: > > All, > > I have been following this discussion, but didn't reply for a while because it > wasn't entirely clear what the real issue was (is). Now it seems that D. C. > Sessions' example really addresses the issue of modeling the turn-off > characteristics of a transistor. This is important - as he says - when the > signal didn't settle yet, or when there are DC currents through resistive > terminations of some sort. > > In the days when we were working on the 2.0 specification and were discussing > the usage and implementation of V-t curves in the Open Forum meetings I brought > up something that may apply to this issue. In those days we decided not to put > it into the spec for various reasons, but now it seems that we probably should > have addressed the issue somehow. > > My goal was to use the V-t curves for characterizing both the turn-on and > turn-off behavior of the transistors. Starting with the assumption that > designers try to avoid crowbar currents like a plague, one can see why > transistors get usually turned off much quicker than turned on. Now, if I > generate a rising V-t curve with a resistor to GND, I will get the turn-on > characteristics of the pullup transistor. However, if I generate a rising V-t > curve with a resistor to Vcc, I will get the turn off characteristics of the > pulldown transistor (because the resistor will pull the voltage high before the > pullup transistor even started to turn on). > > This is why my IBIS models have four V-t curves for a CMOS buffer and two for a > GTL buffer. With the appropriate combinations of Vfixture and Rfixture values I > am describing the turn-on and turn-off characteristics of the transistors. > > In my behavioral HSPICE I/O buffer model this is how I use the V-t curves, and I > get the kind of results one would get in real life. If I have a resistive > termination to Vcc/2, I would normally see a quick edge to Vcc/2 and then a bit > later a slower edge towards the opposite rail. > > If all simulators used these V-t curves the way I intended them to be used, I > believe this discussion wouldn't be taking place now. > > Now, the question is why doesn't the spec describe all this? As I mentioned > above, we talked about it, but decided not to write it down. The reason was > that there are always exceptions (as this discussion is also alluding to it) and > we didn't want to impose a possible limitation in the future by writing > something this down. It is very difficult to write a spec which is general > enough and does not get outdated as technology evolves. > > Would it be appropriate to add some clarifications to the spec? > > Sincerely, > > Arpad Muranyi > Intel Corporation > ============================================================================= > > > C. Kumar wrote: > > Bob Ross wrote [attribution restored -- dcs]: > > > D. C. Sessions wrote [attribution restored -- dcs] > > > I have not also had time to respond to bird 42.3. Your one specific > example of zero current does not detract away the utility of the > original contention for current waveforms in bird 42.3. > > Speaking as an I/O designer, we work *very* hard to avoid crowbar > current. > This is not just a matter of a specific example; it's the majority case. > IMNSHO, an extension to the standard which *only* addresses cases with > major crowbar current is best described as "one specific example." > > Parsimony dictates that we *not* extend the standard willy-nilly; > if there are two possible extensions, one of which is only marginally > applicable to a rare condition and another which addresses both that > *and* the majority case, the latter is always to be preferred. > > > IBIS metholody is a general black box methodology and should not > be confined to the vagaries of specific technologies. > > True enough, but its relevance escapes me.. > > > Adding the current waveforms is relatively minor matter since during > the spice runs the data is easily available. Redundacy in some cases > does just not justify keeping out the data. > > I could name a thousand "minor matters" which might be nice to have in > one-of-a-kind > situations. We're not adding them because their net impact on the > usefulness of the > standard is *negative*. Repeating what I wrote in the first place: > > > > 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. > > Real-world, IMMEDIATE applications such as SSTL can't be properly > modeled right now without addressing the case I presented. (look > back at the time-domain behavior and see what it implies when > applied to a line terminated to Vddq/2) This isn't something we > can blow off by pretending it's a rare case. We *need* to > address the issue. When we have, we'll also have a solution to > the (rare) crowbar-current problem as a freebie. > > So what are we going to do? > > -- > D. C. Sessions > dc.sessions@tempe.vlsi.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-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=us-ascii > References: <199710031328.JAA10440@hot.Cadence.COM> > Subject: Re: BIRD 42.3 > CC: ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM > To: "C. Kumar" > MIME-Version: 1.0 > X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m) > Organization: VLSI Technology Inc. > From: "D. C. Sessions" > Date: Fri, 03 Oct 1997 12:56:15 -0700 > Message-ID: <34354DDF.C69CC504@tempe.vlsi.com> > Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) > Received: from tempe.vlsi.com ([134.27.133.12]) > by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) > with ESMTP id AAA14946; Fri, 3 Oct 1997 12:56:15 -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 MAA141 > 49 for ; Fri, 3 Oct 1997 12:56:17 -0700 > Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap ( > V2.0) > id xma027249; Fri, 3 Oct 97 12:56:19 -0700 > Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050 > 895) id MAA27356 for ; Fri, 3 Oct 1997 12:56:35 -0700 > Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by server.vhd > l.org (8.8.5/8.8.3) with ESMTP id NAA05399 for ; Fri, 3 Oct 1997 1 > 3:11:06 -0700 (PDT) > Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) > by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id NAA18598; > Fri, 3 Oct 1997 13:33:52 -0700 (PDT) > Received: from hebe.or.intel.com by relay.hf.intel.com with smtp > (Smail3.1.28.1 #2) id m0xHERU-000qDSC; Fri, 3 Oct 97 13:35 PDT > From owner-ibis Mon Oct 6 07:22:31 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 HAA11288 for ; Mon, 6 Oct 1997 07:22:31 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id HAA05016 for ; Mon, 6 Oct 1997 07:20:16 -0700 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (V2.0) id xma005010; Mon, 6 Oct 97 07:20:10 -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 HAA25893 for ; Mon, 6 Oct 1997 07:20:09 -0700 Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA13369 for ; Mon, 6 Oct 1997 07:20:08 -0700 Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Message-ID: <3438F398.47B5DF70@tempe.vlsi.com> Date: Mon, 06 Oct 1997 07:20:08 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ibis@eda.org Subject: Re: BIRD 42.3 References: <199710051143.HAA11923@hot.Cadence.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit C. Kumar wrote: > IBIS spec does not specify clearly the reason for the 4 v-t (not 10 or 100) curves. > It should abd the qualifying assumptions should be put on the table unambiguousely. > > You can have problems with this assumption. Does the crow bar current assumption applies to ECL? ECL outputs are open-emitter so there's no possible path for crowbar current. The entire "switchover from pullup to pulldown and back" question (including crowbar current) only comes up when there are both pullup and pulldown. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Mon Oct 6 07:28:40 1997 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA11422 for ; Mon, 6 Oct 1997 07:28:40 -0700 (PDT) Received: from valencia.rsn.hp.com (valencia.rsn.hp.com [15.99.50.121]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id HAA06470; Mon, 6 Oct 1997 07:26:54 -0700 (PDT) Received: (from schumach@localhost) by valencia.rsn.hp.com (8.7.1/8.7.1) id JAA16386; Mon, 6 Oct 1997 09:26:50 -0500 (CDT) From: "Richard A. Schumacher" Message-Id: <199710061426.JAA16386@valencia.rsn.hp.com> Subject: Re: BIRD 42.3 To: dc.sessions@tempe.vlsi.com Date: Mon, 06 Oct 1997 9:26:50 CDT Cc: cpk@cadence.com, ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM In-Reply-To: <34354DDF.C69CC504@tempe.vlsi.com>; from "D. C. Sessions" at Oct 03, 97 12:56 (noon) X-Mailer: Elm [revision: 212.2] > > In other words, different applications require different > > device models. Even one given circuit will require > > different models depending, as in the example, on whether > > the time between output transitions is greater than or less > > than the settling time. True? > > That's one way. (For those joining late: Mr. Schumacher refers > to the problem where an output is still sourcing current into > an unsettled line when it switches LOW. The pullup turnoff > will produce one output step, followed some time later by the > pulldown turnon step.) > > Far more serious, I would tink, is the situation in terminated > lines (eg, SSTL) where the line NEVER quiesces to a zero-current > state. For a whole lot of reasons, the output will almost > always do a two-step: first to the OFF state and then to the > reverse state. The difference between this and the academic > smooth-transition model is pretty significant. So, to get a correct IBIS driver model for a given situation, a user must either (a) ask the device vendor to run the vendor's SPICE model driving the user's desired circuit at the desired switching rate, capture the i-v curve for that circuit and package the curve as an IBIS model, or (b) ask a model developer to attach a real device to the desired circuit, switch it at the desired rate, capture the i-v curve, and package the curve as an IBIS model. If best- and worst-case temp/process/SSO models are desired then the above must be repeated for each condition. Repeat the above for each additional desired switching rate of the circuit; and again for each new circuit which the device might be used to drive. That entire family of curves then becomes one IBIS model for one user. A user might have the vendor/developer capture the waveforms at all the pins of the circuit and save himself the trouble of repeating the simulation/measurement. Prudence requires executing an NDA with the device supplier/third party model developer before handing over circuit designs and operating conditions. From owner-ibis Mon Oct 6 07:46:12 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 HAA11818 for ; Mon, 6 Oct 1997 07:46:12 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id HAA06007 for ; Mon, 6 Oct 1997 07:44:04 -0700 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (V2.0) id xma006001; Mon, 6 Oct 97 07:43:50 -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 HAA26125 for ; Mon, 6 Oct 1997 07:43:48 -0700 Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA13734; Mon, 6 Oct 1997 07:43:47 -0700 Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Message-ID: <3438F923.17199D1B@tempe.vlsi.com> Date: Mon, 06 Oct 1997 07:43:47 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: "Richard A. Schumacher" CC: ibis@eda.org Subject: Re: BIRD 42.3 References: <199710061426.JAA16386@valencia.rsn.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard A. Schumacher wrote: > > > > In other words, different applications require different > > > device models. Even one given circuit will require > > > different models depending, as in the example, on whether > > > the time between output transitions is greater than or less > > > than the settling time. True? > > > > That's one way. (For those joining late: Mr. Schumacher refers > > to the problem where an output is still sourcing current into > > an unsettled line when it switches LOW. The pullup turnoff > > will produce one output step, followed some time later by the > > pulldown turnon step.) > > > > Far more serious, I would tink, is the situation in terminated > > lines (eg, SSTL) where the line NEVER quiesces to a zero-current > > state. For a whole lot of reasons, the output will almost > > always do a two-step: first to the OFF state and then to the > > reverse state. The difference between this and the academic > > smooth-transition model is pretty significant. > > So, to get a correct IBIS driver model for a given situation, > a user must either > > (a) ask the device vendor to run the vendor's SPICE model > driving the user's desired circuit at the desired switching > rate, capture the i-v curve for that circuit and package the > curve as an IBIS model, or > > (b) ask a model developer to attach a real device to the > desired circuit, switch it at the desired rate, capture > the i-v curve, and package the curve as an IBIS model. > > If best- and worst-case temp/process/SSO models are desired then > the above must be repeated for each condition. Repeat the above > for each additional desired switching rate of the circuit; and > again for each new circuit which the device might be used to > drive. That entire family of curves then becomes one IBIS model > for one user. > > A user might have the vendor/developer capture the waveforms > at all the pins of the circuit and save himself the trouble > of repeating the simulation/measurement. Prudence requires > executing an NDA with the device supplier/third party model > developer before handing over circuit designs and operating > conditions. The problem isn't with the v/i curves, it's with the time-domain behavior. Actually, performing the v/t curve capture with the output terminated to vddq/2 would solve most of the problems, since that way you get to see the transition from pullup to pulldown and back again. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Mon Oct 6 08:57:06 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 IAA13186 for ; Mon, 6 Oct 1997 08:57:05 -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 JAA05748; Mon, 6 Oct 1997 09:01:17 -0700 (PDT) Received: from mh-relay by ichips.intel.com (8.7.4/jIIIa) id IAA07532; Mon, 6 Oct 1997 08:55:26 -0700 (PDT) Message-Id: <199710061555.IAA07532@ichips.intel.com> To: Arpad_Muranyi@ccm.fm.intel.com Cc: ibis@eda.org Subject: Re[2]: BIRD 42.3 Date: Mon, 06 Oct 1997 08:55:25 -0700 From: Stephen Peters Hello Arpad, all: In your comments below you ask if it would be appropriate to add some clarification (regarding including four v-t curves in a CMOS model) to the spec. The latest edition of the cookbook does explicitly make this recomendtion. In general I'm in favor of making specific modeling recomendations in the cookbook, and not the spec itself. Regards, Stephen Peters Intel Corp. ====================================================================== On Fri, 03 Oct 97 14:52:05 Arpad Muranyi wrote: Text item: All, I have been following this discussion, but didn't reply for a while because it wasn't entirely clear what the real issue was (is). Now it seems that D. C. Sessions' example really addresses the issue of modeling the turn-off characteristics of a transistor. This is important - as he says - when the signal didn't settle yet, or when there are DC currents through resistive terminations of some sort. In the days when we were working on the 2.0 specification and were discussing the usage and implementation of V-t curves in the Open Forum meetings I brought up something that may apply to this issue. In those days we decided not to put it into the spec for various reasons, but now it seems that we probably should have addressed the issue somehow. My goal was to use the V-t curves for characterizing both the turn-on and turn-off behavior of the transistors. Starting with the assumption that designers try to avoid crowbar currents like a plague, one can see why transistors get usually turned off much quicker than turned on. Now, if I generate a rising V-t curve with a resistor to GND, I will get the turn-on characteristics of the pullup transistor. However, if I generate a rising V-t curve with a resistor to Vcc, I will get the turn off characteristics of the pulldown transistor (because the resistor will pull the voltage high before the pullup transistor even started to turn on). This is why my IBIS models have four V-t curves for a CMOS buffer and two for a GTL buffer. With the appropriate combinations of Vfixture and Rfixture values I am describing the turn-on and turn-off characteristics of the transistors. In my behavioral HSPICE I/O buffer model this is how I use the V-t curves, and I get the kind of results one would get in real life. If I have a resistive termination to Vcc/2, I would normally see a quick edge to Vcc/2 and then a bit later a slower edge towards the opposite rail. If all simulators used these V-t curves the way I intended them to be used, I believe this discussion wouldn't be taking place now. Now, the question is why doesn't the spec describe all this? As I mentioned above, we talked about it, but decided not to write it down. The reason was that there are always exceptions (as this discussion is also alluding to it) and we didn't want to impose a possible limitation in the future by writing something this down. It is very difficult to write a spec which is general enough and does not get outdated as technology evolves. Would it be appropriate to add some clarifications to the spec? Sincerely, Arpad Muranyi Intel Corporation ============================================================================= C. Kumar wrote: > Bob Ross wrote [attribution restored -- dcs]: > > D. C. Sessions wrote [attribution restored -- dcs] > I have not also had time to respond to bird 42.3. Your one specific example of zero current does not detract away the utility of the original contention for current waveforms in bird 42.3. Speaking as an I/O designer, we work *very* hard to avoid crowbar current. This is not just a matter of a specific example; it's the majority case. IMNSHO, an extension to the standard which *only* addresses cases with major crowbar current is best described as "one specific example." Parsimony dictates that we *not* extend the standard willy-nilly; if there are two possible extensions, one of which is only marginally applicable to a rare condition and another which addresses both that *and* the majority case, the latter is always to be preferred. > IBIS metholody is a general black box methodology and should not be confined to the vagaries of specific technologies. True enough, but its relevance escapes me.. > Adding the current waveforms is relatively minor matter since during the spice runs the data is easily available. Redundacy in some cases does just not justify keeping out the data. I could name a thousand "minor matters" which might be nice to have in one-of-a-kind situations. We're not adding them because their net impact on the usefulness of the standard is *negative*. Repeating what I wrote in the first place: > > 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. Real-world, IMMEDIATE applications such as SSTL can't be properly modeled right now without addressing the case I presented. (look back at the time-domain behavior and see what it implies when applied to a line terminated to Vddq/2) This isn't something we can blow off by pretending it's a rare case. We *need* to address the issue. When we have, we'll also have a solution to the (rare) crowbar-current problem as a freebie. So what are we going to do? -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Fri Oct 10 08:39:50 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id IAA25181; Fri, 10 Oct 1997 08:39:49 -0700 (PDT) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 10 Oct 1997 08:38:10 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 10 Oct 1997 08:37:56 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Fri, 10 Oct 1997 08:37:49 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 10 Oct 1997 08:37:49 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org, ibis@eda.org, si-list@silab.eng.sun.com Subject: EUROPE IBIS SUMMIT MEETING Cc: bob@icx.com To All: Please respond if you are interested in an IBIS Summit Meeting in Europe. There exists a lot of IBIS work in Europe related to model development, IBIS usage, model validation, translation to/from Spice, EMC extensions and IBIS needs. We are considering setting up an IBIS Summit meeting for the primary purpose sharing your experiences and communicating your needs. Similar to some of the other IBIS Summit Meetings, we would request that the presentations be available in an electronic format so that they can be made available to anyone who cannot attend. See http://www.eda.org/pub/ibis/summits for other IBIS Summit presentations. We are considering holding the IBIS Summit Meeting in Paris associated with the DATE98 (Design Automation and Test in Europe) Conference (the merger of several conferences including EuroDAC) in February, 1998. This is similar to the IBIS Summit meeting that is held along with the Design Automation Conference (DAC) in the U.S. A 2-hour "Fringe" meeting (Similar to the DAC "Birds of the Feather" meeting) is already being planned. The IBIS Summit under consideration would be for 1/2 to 1 day and devoted to presentations and possible group discussion topics. To find out the level of interest, please respond to me regarding: What dates can you attend and prefer (DATE98 is February 23-26, 1998): Sunday, February 22, 1998 before DATE98? This could be officially affilated with DATE98 Thursday, February 26, 1998 after the trade show portion? This is similar to DAC Other Dates? Would you plan to attend the meeting? Would you plan to prepare a presentation (~15-30 minutes or even longer)? Do you have any suggestions for the Summit Meeting or its topics? Please respond to me as soon as possible since we need to make some committments soon based on your interest. Thank you Bob Ross Interconnectix bob@icx.com or bobross@eda.com From owner-ibis Fri Oct 10 09:37:30 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id JAA26441 for ; Fri, 10 Oct 1997 09:37:29 -0700 (PDT) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 10 Oct 1997 09:35:49 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 10 Oct 1997 09:35:36 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Fri, 10 Oct 1997 09:35:29 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 10 Oct 1997 09:35:29 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@eda.org Subject: IBIS MEETING 10/17/97 IBIS Open Forum Meeting Agenda for 10/17/97 Bridge Number Reservation # Passcode (916) 356-9200 4-120224 5819441 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 - IEC 62014-1 (IBIS Version 2.1) - EIAJ III (I/O Interface Model for ICs) DesignCon98 IBIS Summit Meeting Huq DATE98 (Design Automation and Test in Europe - Ross formerly EuroDAC) IBIS Meeting s2ibis for NT Status Dodd/Wiens s2ibis3 Project Ross Editing Committee Ross/Peters BIRD44 Interpretation of Min/Max/Weak/Strong Data Ross IBISCHK2+ (Ver 2.115) PROGRESS Flora/Rokusek Version 3.1 Parser Development Ross/Peters - Funding - Test Matrix - Samples Cookbook Status Peters - Examples New Administrative Issues All 9:15 Technical Discussion 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 Wed Oct 15 13:55:43 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 NAA05200 for ; Wed, 15 Oct 1997 13:55:43 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id NAA21889 for ; Wed, 15 Oct 1997 13:53:42 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma021686; Wed, 15 Oct 97 13:53:04 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23757 for ibis@vhdl.org; Wed, 15 Oct 97 13:51:50 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA24562; Wed, 15 Oct 97 13:53:00 PDT Date: Wed, 15 Oct 97 13:53:00 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9710152053.AA24562@rockie.nsc.com> To: ibis@vhdl.org Subject: New additions to the IBIS web site IBISfans, We have just added a paper from Bob Ross presented at the PCB Design Conference East titled: 'Practical Issues with IBIS models' This is available under 'Articles'. We have also added the Cookbook for v2.1 (downloadable Word Doc) under the 'Tools' section. This is a 'work in progress' document and will be updated periodically. Best Regards, Syed National Semiconductor Corp. From owner-ibis Thu Oct 16 17:48:50 1997 Received: from newsgw.mentorg.com (newsgw.mentorg.com [137.202.128.5]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id RAA04652 for ; Thu, 16 Oct 1997 17:48:50 -0700 (PDT) Received: from emperor.sje.MENTORG.COM by newsgw.mentorg.com (8.6.8.1/CF5.22R) id RAA14298; Thu, 16 Oct 1997 17:47:08 -0700 Received: from sun_pcb25 by emperor.sje.MENTORG.COM (8.6.8.1/CF5.24R) id RAA15717; Thu, 16 Oct 1997 17:48:50 -0700 From: chimin_yen@MENTORG.COM (Chimin Yen @ ADL x3054) Received: by sun_pcb25 (4.1/CF5.24L) id AA13716; Thu, 16 Oct 97 17:38:09 PDT Date: Thu, 16 Oct 97 17:38:09 PDT Message-Id: <9710170038.AA13716@sun_pcb25> To: ibis@vhdl.org From owner-ibis Fri Oct 17 06:38:32 1997 Received: from kaw.com ([206.155.177.89]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id GAA18572 for ; Fri, 17 Oct 1997 06:38:31 -0700 (PDT) Received: by kaw.com; id AA20546; Fri, 17 Oct 97 09:38:18 EDT Received: from omni.kaw.com(192.168.200.83) by explorer via smap (V3.1) id xma020544; Fri, 17 Oct 97 09:38:06 -0400 Received: from blazer.kaw.com (blazer [192.168.200.90]) by kaw.com (8.7.5/8.7.3) with SMTP id JAA22636; Fri, 17 Oct 1997 09:37:06 -0400 (EDT) Date: Fri, 17 Oct 1997 09:37:06 -0400 (EDT) Received: by blazer.kaw.com (SMI-8.6/SMI-SVR4) id JAA02182; Fri, 12 Sep 1997 09:34:31 -0400 From: dan@kaw.com (Dan Aleksandrowicz) Message-Id: <199709121334.JAA02182@blazer.kaw.com> To: chenxy@huawei.co.cn Subject: Re: How to deal with analog devices? Cc: ibis@vhdl.org X-Sun-Charset: US-ASCII Hi Chen. Your question is valid and important, however the answer depends on your goal. If you are interested in analyzing all signals, including analog signals and power plane/traces, you will need more than IBIS models. IBIS modeling is mainly for analyzing digital signals between digital components. Though most EDA tools support some level of discretes and diodes, there might not be support for transistors in your PCB signal integrity tool. The solution for analog signal simulation lays in spice simulation. As for mixing digital IC's IBIS models and "analog" components (i.e. diodes, transistors and active bus tremination) the are spice tools that can do it. But, getting the model for the above components to fit an analog tool might be tricky. I personally, in each SI project, take a hard look into the needs of the system and define the signal list to be simulated. And then I can define which component models are needed. Usually, I do not really need analog models for signal integrity purposes. Good luck. Dan Aleksandrowicz Engineering Solutions Specialist e-mail: dan@kaw.com 39 Simon Street Nashua, NH 03060 From owner-ibis Fri Oct 17 07:33:02 1997 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA19683 for ; Fri, 17 Oct 1997 07:33:01 -0700 (PDT) Received: from lss2117.lss.emc.com (lss2117.lss.emc.com [168.159.50.117]) by emcmail.lss.emc.com (8.8.7/8.7.3) with ESMTP id KAA19631; Fri, 17 Oct 1997 10:36:50 -0400 (EDT) Received: (from fawn@localhost) by lss2117.lss.emc.com (8.7.1/8.6.9) id KAA19141; Fri, 17 Oct 1997 10:21:56 -0400 (EDT) Date: Fri, 17 Oct 1997 10:21:56 -0400 (EDT) From: Fawn Engelmann Message-Id: <199710171421.KAA19141@lss2117.lss.emc.com> To: chenxy@huawei.co.cn Subject: Re: How to deal with analog devices? Cc: ibis@vhdl.org Hi Chen, Here is my take. There are three major classifications for models to get into a board level signal integrity evaluation. First, IBIS models for buffer modelling. Second, analog and jelly bean parts such as resistors, capacitors, switches, etc. are typically modelled as very small spice like models. (Each vendor has their own little language parsers) Third, connectors. Since IBIS support is supposedly on the way, the signal integrity engine providers have to currently offer their own language modelling support. It is usually a primary RLC matrix with mutual inductance and mutual capacitance specifications for the pins. Good question! Thanks, Fawn _/ Fawn Engelmann _/ _/ email: fawn@emc.com _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 x-1171 _/ _/_/ _/_/ _/ _/ Fax: (508) 497-8741 _/_/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ EMC Corporation _/_/_/_/ _/ _/ _/_/_/ 171 South Street Hopkinton, MA 01748-9103 _/"THE Storage Architects"_/ http://www.emc.com From owner-ibis Mon Oct 20 08:47:56 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 IAA04532 for ; Mon, 20 Oct 1997 08:47:56 -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 IAA11022 for ; Mon, 20 Oct 1997 08:53:54 -0700 (PDT) Received: from mh-relay by ichips.intel.com (8.7.4/jIIIa) id IAA06094; Mon, 20 Oct 1997 08:46:11 -0700 (PDT) Message-Id: <199710201546.IAA06094@ichips.intel.com> To: ibis@eda.org Subject: IBIS Meeting Minutes, Oct 17, 1997 Date: Mon, 20 Oct 1997 08:46:10 -0700 From: Stephen Peters DATE: October 20, 1997 SUBJECT: 10/17/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* Hewlett Packard, EEsof Karl Kachigan, Henry Wu 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 Wiens 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, Boise Paul Gregory* 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 Tandem Mark Simpson* 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 11/7/97 (916) 356-9200 3-159555 4855377 12/05/97 (916) 356-9200 3-159556 6788873 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 Mark Simpson from Tandem is interested in IBIS to off load nets that do not need detailed HSPICE analysis. Paul Gregory of Hewlett Packard, Boise is interested in IBIS modeling techniques for high frequency design. MEMBERSHIP UPDATE AND TREASURER'S REPORT Hewlett Packard is being moved back to full membership status since the issue about the invoices is being resolved. Bob Ross does not know of any expenses since the last report of $5,272. REVIEW OF MINUTES AND AR'S No corrections were reported. The AR's will be dealt with during the meeting. Arpad Muranyi reported that the Minutes are coming in as an attachment - a minor inconvenience. MISCELLANY/ANNOUNCEMENTS It looks like the slow IBIS reflector response that Bob Ross discussed at the last meeting turned out to be a local issue only. This has been fixed. Bob will move the mail system over to Majordomo since all of the major groups on eda.org are using this system. PRESS AND WEB PAGE UPDATES Syed Huq reported several changes to the EIA/IBIS Web Site. The Home page format is modular. Bob Ross' article "Practical Issues with IBIS Models" presented at the PCB Design Conference East in September 1997 is now in HTML format under the Articles section. A link to the new IBIS Cookbook has been added for downloading only in the Tools section. The document is located on eda.org under /pub/ibis/wip since it is expected to be updated at various times. A missing dV/dt definition in the Cookbook Version 1.1 has been added per a comment by Matt Flora. Some Roster changes and updates have been made for several companies. Syed plans to provide an FAQ on reporting bugs. Bob reported that Eric Blomberg has written "IBIS "Models" Come of Age" in Printed Circuit Design, October 1997, pp. 19-21. Bob also reported a brief mention of IBIS in "New Paradigms Ensure High- Performance PCBs" in the October issue of Computer Design, pp. 60-69. NEW MODELS AVAILABLE, LIBRARY UPDATE Syed Huq reported that he had sent out a message regarding a new SuperI/O model available from the National Semiconductor IBIS Site. Bob Ross reported that International Microcircuits, Inc. has an FTP site with password protected IBIS models at: ftp://ftp.best.com/pub.i/imiweb8/ibis A marketing contact is listed in the contacts.txt file to obtain the passwords to unlock the files. Also one can go to the http://www.imicorp.com location to get more information about any part and how to contact the company. Bob Ross reported that Quicklogic has an IBIS library under development. There was a copyright confusion mistake which has been cleared up according to Matthew Flora. The link is: http://www.quicklogic.com/techinfo/techinfo.htm OPENS FOR NEW ISSUES Arpad Muranyi on some IBIS models with stair step tables. INTERNATIONAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - As previously reported, Bob Ross stated that the vote report needs to be approved before Patti Rusher will issue the press release. - 93/60/NP (IBIS Models and EMC Simulation) - This work item has been dropped as previously reported. - EIAJ III (I/O Interface Model for ICs) - Bob understands that this is now a formal work item under IEC. He does not have its number. DESIGNCON98 IBIS SUMMIT Syed Huq volunteered that National would be willing to host the annual IBIS Summit meeting held with DesignCon98 (formerly Design SuperCon) in Santa Clara, California. If others Bay Area companies want to volunteer as Host, they are welcome to submit their request. Bob Ross stated that unless we hear of any requests we will assume that National will serve as host. Syed plans to send out information regarding the meeting. Like last year, we plan some technical presentations and discussions related to IBIS issues and IBIS usage. The meeting is planned on Monday, January 26, 1998, the day before DesignCon98 begins. Arpad Muranyi commented that high-frequency modeling might be an interesting topic based on the discussion raised by Paul Gregory. Arpad is concurrently trying to resolve delay differences with Spice transmission line models. Bob indicated that there are three IBIS related presentations submitted to DesignCon98 which extends from Tuesday through Thursday, January 27-29, 1997. Also, there may be a modeling panel session. Bob is suggesting that these activities occur on Tuesday, the day after the IBIS Summit. DATE98 (DESIGN AUTOMATION AND TEST IN EUROPE) IBIS SUMMIT Bob had received an initial suggestion from High Design Technology of Italy regarding an IBIS meeting along with DATE98 Conference in February, 1998 in Paris. After some followup with several individuals and after sending out an inquiry on the IBIS reflectors, there does seem to be interest in such a meeting. Bob has followed up with the French Mentor Graphics field office regarding logistics of cost and scheduling of such a meeting. Bob indicated that he would welcome other European companies or European field offices to join in hosting the meeting. Based on the response, there appears initial interest from HDT, Alcatel, Siemens, Thomson, and HP France. Also several U.S. IBIS members expressed interest in attending. Several people plan to do presentations, and others suggested a variety of interesting topics to be sent out later. Several people did not want a Sunday meeting. So the only dates now being investigated are Thursday, February 26, 1998 and possibly Monday, February 23, 1998 at hotels at or nearby the DATE98 conference. The sense of the committee was to proceed. Everyone thought it was a good especially since IBIS now is an IEC standard. Bob indicated that we need to firm up commitments by the end of October. He will work with several IBIS officers to help make some of the decisions. (Added later: the DATE Conference is the continuation of EuroDAC (with EuroVHDL) and ED&TC (EDAC, ETC, and EuroASIC). More information is available at http://www.date-conference.com). S2IBIS FOR NT Bob Ross reported that s2ibis_v1.3 for NT has been posted on the Veribest Web site. s2ibis2_v2.1 is still under development so that part of the AR remains. Arpad Muranyi had raised as a new issue the concern that some IBIS models have stair step tables. Bob responded that this was a result of a known problem with s2ibis2_v2.1 that does not have the s2ibis2_fix code. Without the fix, the table resolution can be as low as two digits in a manner that can cause up to a 10% discontinuity. The EIA/IBIS Home page now points to a directory where s2ibis2_fix exists. The VeriBest conversion should have the fix code included. AR - Ian Dodd put s2ibis_ver2.1 for Windows on the VeriBest Web site. S2IBIS3 PROJECT Bob Ross reported that R. Sanjeev (who also goes by Presi) is planning to work on s2ibis3 after looking into some bug fixes for s2ibis2. He is a Masters degree student at the Indian Institute of Technology, Madras India. He has done IBIS model development while working at Cadence using s2ibis. EDITING COMMITTEE Bob Ross reported that he has made the editing pass to simplify and reduce the variations on the terms used in IBIS Version 3.0. He still has not broken it into manageable sections. When this is done, this will be put into the work in progress directory. The AR is still in effect. Stephen Peters asked and Bob responded that the BNF AR still needs to be done. 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 No discussion. IBISCHK2+ (VER 2.115) PROGRESS Bob Ross reported that Matthew Flora plans to implement the bug fixes reported at the last meeting as part of an ibischk2+ version 2.115. This correction will serve as a new base line for ibischk3 development. AR - Matthew Flora implement the bug fixes needed to produce ibischk2 version 2.115. VERSION 3.1 PARSER DEVELOPMENT After last meeting, Bob Ross sent out the request for purchase orders to support the ibischk3 parser development. So far, has either copies of purchase orders of commitments to generate purchase orders from: Applied Simulation Technology Incases Interconnectix Hyperlynx At the meeting, Frank Kern indicated that the Intel purchase order was being signed off. Syed Huq indicated that National Semiconductor's purchase order should be expected next week. Bob indicated that the EIA IBIS Open Forum will own the source code. The license owner will have the right to use the source code or to modify it to generate utilities and products for sale. The license is for the entire corporation, consistent with the membership rules of EIA - one vote per entire company. The source code itself is not to be redistributed. Several individuals raised questions on these points, and Bob plans to work with Ken Willis of Cadence to craft the appropriate wording. This is needed for Cadence to issue a purchase order. Bob indicated that based on some private e-mail, several other companies were moving forward on issuing purchase orders. COOKBOOK Stephen Peters indicated that there is no further progress. Frank Kern still may do an introductory section, but is currently involved in company projects. All the ARs are carried forward. 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". BIRD42.3 - MODELING CURRENT WAVEFORMS Bob Ross noted that there was reflector discussion on issues related to BIRD42.3. Arpad Muranyi asked how the discussion related to ground and power bounce. Bob Ross felt that from one point of view, BIRD42.3 provided extra information for giving more accurate answers for the buffer only. Stephen Peters thought that the thrust of BIRD42.3 was to describe a 3-terminal device. From another point of view, it could be used for a more accurate analysis. In conjunction with the [Pin Mapping] keyword, the buffer details for bounce can be described with greater first-order accuracy. Bob also noted that there are other signals such as internal clock networks that add to the internal bounce effect through internal feedback. These can be as significant as the bounce contributed by the buffers themselves. These effects could be added though another method. Bob commented that one of the threads in the BIRD42.3 discussion related to DC Sessions example itself. The example implied a need for using two waveforms to describe the independent action of the top and bottom transistors. Bob modeled it in Spice, but did not have time to finish it for distribution. Bob feels that a necessary element in the discussion is the algorithms used to process the information. Raj Raghuram suggested that some formal academic research might be helpful in resolving the modeling of bounce effects. He will contact some individuals regarding such a project. Bob and Raj also commented on the EIAJ III proposal that gives a more detailed description of the internal chip power distribution and uses table based transistor models. This description contains more information that is useful for buffer bounce analysis. Except for this general discussion, BIRD42.3 is not moving forward. A next step may be a minor revision to map it in with the current Version 3.0 text. At some future time we will consider this issue for resolution. SWITCHING TERMINATORS Arpad Muranyi reported that he will work with Bob Ross concerning describing the characteristics so that its features can be formulated into a BIRD. Bob reported that he has a rough idea of what is needed for simulation. However, he has some interaction type questions to best fit the functionality into the IBIS format. Some of these relate to which rail sources or sinks the current to be compatible for future bounce analysis. NEXT MEETING: The next meeting is on Friday, November 7, 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/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. 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 Fri Oct 24 13:28:53 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id NAA19250; Fri, 24 Oct 1997 13:28:52 -0700 (PDT) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 24 Oct 1997 13:27:06 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 24 Oct 1997 13:26:53 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis-users@eda.org; Fri, 24 Oct 1997 13:26:53 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 24 Oct 1997 13:26:53 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org, ibis@eda.org Subject: IBIS Reflector Usage Cc: bob@icx.com To All: This note is to inform people on IBIS reflector usage as reminder of some previous discussions on this subject and also to communicate to the many newer reflector participants of our discussion restrictons. We request all COMMERCIAL PRODUCT related discussions or reponses to questions to be handled PRIVATELY OFF LINE. These types of discussions, even if they relate to tools that use IBIS or translate IBIS data, are best handled on the signal integrity reflector. It is OK to INFORM people of FREE PRODUCTS and FREE IBIS MODELS that are available. We do provide links/information on some companies on the EIA IBIS Web Site through the Poster selection and also through the Roster and Model Provider selections. We allow and even encourage information about IBIS related products in the Support or Tag-Line fields of the Roster, and this is open to any company. There are several reasons for the relfector discussion restriction. The EIA IBIS Open Forum is formally affiliated with EIA, and it is the EIA policy is to forbid Commercial discussion. In addition, the EIA IBIS Open Forum consists of individuals particpating as company representatives, and many companies are providing financial support for their participation and financial support to the EIA IBIS Open Forum through EIA IBIS Open Forum membership fees and contributions. Therefore it is NOT appropriate to put individuals in the position of having to promote or defend their own products when their real charter is work together on IBIS issues. So any IBIS discussion is appropriate as long as it does not relate to Commercial Products. Please use another reflector and/or respond PRIVATELY if you have any product information that may be helpful someone. Bob Ross Interconnectix Chair. EIA IBIS Open Forum From owner-ibis Fri Oct 24 15:59:44 1997 Received: from alabama.nwlink.com (alabama.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA21708 for ; Fri, 24 Oct 1997 15:59:44 -0700 (PDT) Received: (from kellee@localhost) by alabama.nwlink.com (8.8.7/8.8.7) id PAA20422; Fri, 24 Oct 1997 15:57:58 -0700 (PDT) Message-Id: <3.0.32.19971024155802.00d73ff4@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 24 Oct 1997 15:58:03 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: How to subscribe to the Signal Integrity group Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBIS Land, I have had several requests in the last 2 days for the reflector address for the SI group. Here it is for anyone that wants it. The address to subscribe is: si-admin@silab.Eng.Sun.COM All that's required is "subscribe" in the subject line. For general discussions on tools, and techniques associated with signal integrity this is the place. ------------------------------------------------------------------------- Live long and prosper ... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Mon Oct 27 08:53:46 1997 Received: from sa.infonet.com ([192.157.130.21]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA27487 for ; Mon, 27 Oct 1997 08:53:46 -0800 (PST) Received: (from m400@localhost) by sa.infonet.com (8.8.5/8.6.12) id QAA00879 for ibis@vhdl.org; Mon, 27 Oct 1997 16:29:57 GMT Date: 27 Oct 97 17:23 GMT X400-Trace: us*infonet*powermail; Arrival 27 Oct 97 17:23 GMT Action: Relayed X400-Trace: us*infonet*ccmail88; Arrival 27 Oct 97 17:23 GMT Action: Relayed X400-Trace: us*infonet*; Arrival 27 Oct 97 16:29 GMT Action: Relayed Priority: normal P1-Message-ID: us*infonet*powermail;0877969794/1933151160/1 Original-Encoded-Information-Types: IA5-Text P1-Recipients: ibis@vhdl.org From: psd To: ibis@vhdl.org Message-ID: <@x400gw.infonet.com> Subject: Some information Dear Sir, I think that the IBIS mainly is something useful for the designers. But why we do not make something which is some how similar to the IBIS but will help the Tester Eng. to test the board after being assembled so the test Eng. can get the data from the IBIS and then generate a test for the digital IC's in his board. In the production line of the electronic boards for different purposes we made an automatic testing for the electronic board so in the IC's testing we just want to know if it is connected to the board normally or it has problems but we do not care about the functionality of the IC's because normally it works fine or the probability that there is a defected IC is very small. I mean if the PCB was assembled then the components were soldered on the PCB so you have different IC's connected to another different IC's. I made some thing similar but as you know this is a complete circuit so I did not power the circuit because I will have the circuit working and I do not want this but I made IV C/S for the output pins and input pins by Ramp signal within 1200mV with freq. of 1KHz and it was stable for a lot of different IC's ,so if you have a PCB and you want to test the IC's are normally connected this detects the following failures (misoriented, IC GND pin not connected, Cold solder point) this if you make your measurements with respect to the GND pin. and (misoriented, IC VCC pin not connected, Cold solder point) this if you made your measurements with respect to the VCC pin. If you need more information I can give you the DOC's the curves and the shape of the boards I made the testing for them. Best regards. Hany Gad. Senior of HW Dept. in an Automatic testing company. From owner-ibis Mon Oct 27 09:33:04 1997 Received: from gatekeeper2.nsc.com (natsemi3-bh.nsc.com [205.227.60.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id JAA28276 for ; Mon, 27 Oct 1997 09:33:04 -0800 (PST) Received: (from uucp@localhost) by gatekeeper2.nsc.com (8.6.12/8.6.11) id JAA02700 for ; Mon, 27 Oct 1997 09:31:16 -0800 Received: from nsc.nsc.com by natsemi3-bh.nsc.com via smap (3.2) id xma002475; Mon, 27 Oct 97 09:30:50 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA28879 for ibis@vhdl.org; Mon, 27 Oct 97 09:30:47 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA02371; Mon, 27 Oct 97 09:32:22 PST Date: Mon, 27 Oct 97 09:32:22 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9710271732.AA02371@rockie.nsc.com> To: ibis@vhdl.org Subject: if you need a IBIS-to-SPICE converter Hi, If you are in need of a IBIS-to-SPICE converter, this may be a great time to talk to your SPICE tool vendor BEFORE you renew the annual maintenance fee or purchase more copies of the tool. There is only a 'few' SPICE vendors that do not support this IBIS-to-SPICE conversion and it is only the 'customers'(yourself) of these vendor that can do the convincing/'arm twisting'... The non-SPICE simulator vendors have been supporting IBIS since it's birth...which is great! I doubt any university or the IBIS forum will create such a translator in the near future. Regards, Syed National Semiconductor Corp. From owner-ibis Mon Oct 27 19:16:12 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id TAA08396 for ; Mon, 27 Oct 1997 19:16:06 -0800 (PST) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Mon, 27 Oct 1997 19:14:17 -0800 (PST) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Mon, 27 Oct 1997 19:14:08 -0800 (PST) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Mon, 27 Oct 1997 19:14:00 -0800 (PST) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Mon, 27 Oct 1997 19:14:00 -0800 (PST) From: bob@icx.com (Bob Ross) To: ibis@eda.org Subject: IBIS TO SPICE DISCUSSION Cc: bob@icx.com To All: To help in doing the IBIS to Spice transformation, I am sharing with you a PROTOTYPE configuration and set of Spice decks which I used to examine some waveform processing algorithms. This was never completed into a self-contained Spice implementation of IBIS. However, the decomposed form can be used to illustrate the algorithm and examine how it performs. The figure below illustrates the assumed Spice (and IBIS) topology. The PULLUP, PULLDOWN, POWER_CLAMP and GND_CLAMP tables are all made relative to their respective reference voltage nodes PWR, GRD, PWRC, and GNDC. These tables along with the RISING AND FALLING WAVEFORMS for given DUT and FIXTURE conditions can all be representated as subcircuits using piecewise linear voltage controlled current sources (for the IV tables) and properly scaled voltage controlled voltage sources (for the VT tables). The algorithm theory is straight-forward. From the IBIS model information including its waveform table, it is possible to determine from circuit theory both the voltage at the DIE and the corresponding currents flowing through R_DUT and C_COMP. It is also possible to determine the currents supplied by the four IV tables which are summed up at the DIE. The PULLDOWN and PULLUP multipliers Kd(t) and Ku(t) transition between 1 and 0 (0 and 1) for the RISING WAVEFORM, and visa-versa for the FALLING WAVEFORM. So one algorithm is to derive the multiplier tables that will produce the original WAVEFORM table A one-waveform implementation would (arbitrarily) ASSUME some relationship between Ku(t) and Kd(t) such as Ku(t) = 1 - Kd(t). If the multipliers themselves are ramp tables, the output is not necessarily a ramp for a given test load. This prototype illustrates an approach in which some form of internal adjustment or scaling is done for processing waveform based IBIS models. The processing of any IBIS model is just a mathematical process where the response to any load is just the mathematical blending of specified responses based on the assumed topology. There are other things to be learned such as numerical sensitivities to the DUT parameters, resolution of the IV tables, etc. Like Spice transistor models with the .option controls for convergence, there is numerical sensitivity to some data that deviates from ideal theorical processing which assumes that the data and their derivatives are continuous. PWR PWRC o o | | | POWER_ | PULLUP | CLAMP | |---o---| |---o---| | Iu(V) | | | | | |Ipc(V) | WAVEFORM | Ku(t) | | | DIE PIN TABLE |---o---| |---o---| | | | | | | | | | | V v R_DUT L_DUT v L_FIXTURE v o-------------o--------o--/\/\/\--UUUUU--o---UUUUU--o-----o | | | R_PKG L_PKG | | | | | | | | | |---o---| |---o---| | | | | | Id(V) | | | | C_COMP C_DUT | C_PKG | \ | | |Igc(V) | --- --- --- / | Kd(t) | | | --- --- --- \ |---o---| |---o---| | | C_ | / R_ PULLDOWN | GND_ | | | FIXTURE | | FIXTURE | CLAMP | | | | | | | | | | | o o o o o o GRD GNDC GND GND GND V_FIXTURE Below are 5 files: sim2.sp: The IBIS processing algorithm which loads ibismod.lib and ibiscal.lib. It uses the HSPICE equation format for clarity rather than a more general polynomial multiply. The model itself is driven by the the VPULSE control to produce the actual rising and falling responses in a manner that sets the pulse width and period. A more complicated stimulus could be used. One implementation constraint here is that the pulse widths must be greater than the Waveform table time lengths. Also the actual simulation load including transmission line loads can be added here for testing. ibismod.lib: The IBIS model parmeters including supply voltages, package values, IV tables and VT tables are inserted into this file for each IBIS model by cut-and-paste. Zero-valued parameters are given neglibable values rather than "0" to prevent some Spice error messages. ibiscal.lib: The multiplying tables are inserted here for the rising and falling responses by cut-and-paste. ext2r.sp: A two-waveform extraction circuit for generation the KUR(t) and KDR(t) tables. The files that are printed are cut-and- pasted in ibiscal.lib. ext2f.sp: A two-waveform extraction circuit for generating the KUF(t) and KDF(t) tables. A simple example originally given by DC Sessions is embedded into the example. As originally proposed, the KU(t) and KD(t) tables are piecewise linear. However, if the response itself were piecewise linear, then different KU(t) and KD(t) tables could be derived to match the reponse in the ibismod.lib file. DC's example is interesting because it illustrates that the IBIS architecture can work with the pullup and pulldown stage turn-on control and turn-off control phased differently: "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." Below, Pullup #1 is illustrated as a Falling edge, and Pullup #2 is illustrated as a rising edge (by taking the mirror image conditions). The KU and KD multipliers are used to shape the conductance from the 50 ohms (20 mS) given in the PULLUP and PULLDOWN tables. Some linear ramp tables are provided in the RISING and FALLING WAVEFORM tables of ibismod.lib. Bob Ross Interconnectix sim2.ps * TWO WAVEFORM SIMULATION * .INCLUDE IBISCAL.LIB $................. VVVVVVVV .INCLUDE IBISMOD.LIB $......... VVVVVVVV * * SUPPLIES XPWR VCC GRD PWRC GNDC SUPPLIES * * INPUT CONTROL GON ON GRD STEP GRD -1 VON ON GRD 0 * XRAMP STEP GRD RMPR RMPF RAMPS XKUR RMPR GRD NKUR KUR VKUR NKUR GRD 0 XKUF RMPF GRD NKUF KUF VKUF NKUF GRD 0 * XKDR RMPR GRD NKDR KDR VKDR NKDR GRD 0 XKDF RMPF GRD NKDF KDF VKDF NKDF GRD 0 * * HIGH SIDE XUP OUT1 VCC NU1 PULLUP VUP NU1 VCC 0 GUP OUT1 VCC CUR='-I(VUP)*(I(VKUR)*I(VON)+I(VKUF)*(1-I(VON)))' XPC OUT1 VCC POWER_CLAMP * * LOW SIDE XDN OUT1 GRD ND1 PULLDOWN VDN ND1 GRD 0 GDN OUT1 GRD CUR='-I(VDN)*(I(VKDR)*I(VON)+I(VKDF)*(1-I(VON)))' XGC OUT1 GNDC GND_CLAMP * * C_COMP AND DUT PACKAGE XCAP OUT1 GRD C_COMP XPKG OUT1 GRD PIN1 PACKAGE * * LOAD ** Test Against Original Loads. XLOAD1 PIN1 GRD LOADR1 *XLOAD2 PIN1 GRD LOADR2 *XLOAD3 PIN1 GRD LOADF1 *XLOAD4 PIN1 GRD LOADF2 RPIN1 PIN1 GRD 1E9 ** Some Actual Sample Loads *RLOAD PIN1 VOL 50 *VOL VOL GRD 2.5 *COL PIN1 GRD 10p *TLOAD PIN1 GRD PIN9 GRD Z0=50 TD=1N *R9 PIN9 GND 50G ** Voltage width and period control VPULSE STEP GRD 0 PULSE (1 0 0P 1P 1P 5N 10N) .TRAN 0.2N 10N 0 0.02n .OPTION POST .END ibismod.lib *========================================================================== * CMOS1 IBIS FORMATTED TABLE AND WAVEFORM SUBCIRCUITS *========================================================================== *========================================================================== * IBIS FORMATTED TABLE AND WAVEFORM SUBCIRCUITS *========================================================================== * * LIBRARY OF SUBCIRCUITS * * IBISMOD.LIB Copy of IBIS Data fromatted into a Subcircuit * Data Library for Inclusion. * IBISCAL.LIB Copy of Simulation Tables and Data for Calculations * for Inclusion. * * SUBCIRCUIT CONTENTS * * SUPPLIES IBIS Reference Power Supplies * C_COMP IBIS C_comp * PACKAGE IBIS L_pkg, R_pkg, C_pkg (also L_dut, R_dut, C_dut) * * PULLUP IBIS PULLUP Table * POWER_CLAMP IBIS POWER CLAMP Table * PULLDOWN IBIS PULLDOWN Table * PULLDOWN_ECL IBIS PULLDOWN Table with ECL Polarity Convention * GND_CLAMP IBIS GND_CLAMP Table * * RISINGn IBIS RISING WAVEFORM Table Number "n". * LOADRn IBIS Load for Rising Waveform Table "n". * FALLINGn IBIS FALLING WAVEFORM Table Number "n". * LOADFn IBIS Load for Falling Waveform Table "n". * * NOTES: * (1) V/I and Waveform tables consisting of the first column and * any of the remaining columns may be copied directly into * the corresponding subcircuit data tables below, but with the * insertion of the continuation character "+" as the first * character of each line. Notes (2) and (3) contain data * table limitations. The polarity conventions of IBIS are * followed in formulating the subcircuit tables. Delete * rows which consist of "" data. * (2) All Voltage entries must be ordered in ascending order for * the PULLUP, PULLDOWN, GND_CLAMP and POWER_CLAMP tables. * (3) All Waveform tables must be ordered in ascending order and * each of the Rising and Falling transitions should be referenced * to an implied pulse waveform relative time = 0ns for the * beginning of that specific transition. The time = 0ns could * be an input transition point that is common to all of the * tables of similar transition direction. * *========================================================================== * IBIS POWER SUPPLY TABLE *-------------------------------------------------------------------------- .SUBCKT SUPPLIES 200 100 400 300 * | | | | * | | | Ground Clamp Ref Voltage (Usually Gnd) * | | Power Clamp Ref Voltage (Usually Vcc) * | Pulldown Reference Voltage (Usually Gnd) * Pullup Reference Voltage (Usually Vcc) *-------------------------------------------------------------------------- * Enter the Supply Values Here VPULLUP 201 0 5.0 Rpullup 200 201 1e-5 VPULLDOWN 101 0 0.0 Rpulldown 100 101 1e-5 VPOWERCLAMP 401 0 5.0 Rpowerclamp 400 401 1e-5 VGNDCLAMP 301 0 0 Rgndclamp 300 301 1e-5 .ENDS *========================================================================== *========================================================================== * IBIS C_COMP *-------------------------------------------------------------------------- .SUBCKT C_COMP 1 100 * | | * | Pulldown Reference Voltage (Usually Gnd) * Die *-------------------------------------------------------------------------- * Enter the Supply Values Here C_comp 1 100 1e-15 .ENDS *========================================================================== *========================================================================== * IBIS PACKAGE *-------------------------------------------------------------------------- .SUBCKT PACKAGE 1 100 2 * | | | * | | Pin * | Pulldown Reference Voltage (Usually Gnd) * Die *-------------------------------------------------------------------------- * Enter the Supply Values Here L_pkg 1 3 1e-12 R_pkg 3 2 1e-6 C_pkg 2 100 1e-15 .ENDS *========================================================================== *========================================================================== * IBIS PULLUP TABLE *-------------------------------------------------------------------------- .SUBCKT PULLUP 1 200 2 * | | | * | | Current Source Output * | Reference Voltage (Usually Pullup Ref. or Vcc) * Output Sense Voltage (Usually at Vout of die) *-------------------------------------------------------------------------- GPULLUP_HS 2 200 PWL(1) 200 1 + -5.00V 100m + 0 0 + 5 -100m + 10.00V -200m .ENDS *========================================================================== * IBIS PULLDOWN TABLE *-------------------------------------------------------------------------- .SUBCKT PULLDOWN 1 100 2 * | | | * | | Current Source Output * | Reference Voltage (Usually Pulldown Ref. or GND) * Output Sense Voltage (Usually at Vout of die) *-------------------------------------------------------------------------- GPULLDOWN_HS 2 100 PWL(1) 1 100 + -5.00V -100m + 0 0 + 5 100m + 10.00V 200m .ENDS *========================================================================== * IBIS PULLDOWN_ECL TABLE *-------------------------------------------------------------------------- .SUBCKT PULLDOWN_ECL 1 200 2 * | | | * | | Current Source Output * | Reference Voltage (Usually Pullup Ref. or Vcc) * Output Sense Voltage (Usually at Vout of die) *-------------------------------------------------------------------------- GPULLDOWN_ECL_HS 2 200 PWL(1) 200 1 + 0.000E+00 0.0 + 1.000E-01 0.0 .ENDS *========================================================================== * IBIS POWER_CLAMP TABLE *-------------------------------------------------------------------------- .SUBCKT POWER_CLAMP 1 200 * | | * | Reference Voltage (Usually Pullup Ref. or Vcc) * Output Voltage (Usually at Vout of die) *-------------------------------------------------------------------------- * Enter 0.0 for no clamp * GPWR_CLAMP_HS 1 200 PWL(1) 200 1 + -5.00V 0mA + 10.00V 0mA .ENDS *========================================================================== * IBIS GND_CLAMP TABLE *-------------------------------------------------------------------------- .SUBCKT GND_CLAMP 1 100 * | | * | Reference Voltage (Usually GND clamp Ref. or GND) * Output Voltage (Usually at Vout of die) *-------------------------------------------------------------------------- * Enter 0.0 for no clamp * GGND_CLAMP_HS 1 100 PWL(1) 1 100 + -5.00V 0mA + 10.00V 0mA .ENDS *========================================================================== *========================================================================== * IBIS RISING WAVEFORM1 TABLE *-------------------------------------------------------------------------- .SUBCKT LOADR1 1 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Pin Connection *-------------------------------------------------------------------------- L_FIXTURE 1 3 1e-12 C_FIXTURE 3 100 1e-15 R_FIXTURE 3 4 50 V_FIXTURE 4 100 0 .ENDS *-------------------------------------------------------------------------- .SUBCKT RISING1 2 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Output Serving as PWL Voltage Source to Input Connection *-------------------------------------------------------------------------- VIN 2 100 PWL + 0. 0.0 + 1.5n 0.0 + 2.5n 2.5 .ENDS *========================================================================== *========================================================================== * IBIS RISING WAVEFORM2 TABLE *-------------------------------------------------------------------------- .SUBCKT LOADR2 1 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Pin Connection *-------------------------------------------------------------------------- L_FIXTURE 1 3 1e-12 C_FIXTURE 3 100 1e-15 R_FIXTURE 3 4 50 V_FIXTURE 4 100 5 .ENDS *-------------------------------------------------------------------------- .SUBCKT RISING2 2 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Output Serving as PWL Voltage Source to Input Connection *-------------------------------------------------------------------------- VIN 2 100 PWL + 0.0 2.5 + 1.0n 2.5 + 1.5n 5.0 .ENDS *========================================================================== *========================================================================== * IBIS FALLING WAVEFORM1 TABLE *-------------------------------------------------------------------------- .SUBCKT LOADF1 1 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Pin Connection *-------------------------------------------------------------------------- L_FIXTURE 1 3 1e-12 C_FIXTURE 3 100 1e-15 R_FIXTURE 3 4 50 V_FIXTURE 4 100 0 .ENDS *-------------------------------------------------------------------------- .SUBCKT FALLING1 2 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Output Serving as PWL Voltage Source to Input Connection *-------------------------------------------------------------------------- VIN 2 100 PWL + 0.0 2.5 + 0.5n 2.5 + 1.5n 0.0 .ENDS *========================================================================== *========================================================================== * IBIS FALLING WAVEFORM2 TABLE *-------------------------------------------------------------------------- .SUBCKT LOADF2 1 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Pin Connection *-------------------------------------------------------------------------- L_FIXTURE 1 3 1e-12 C_FIXTURE 3 100 1e-15 R_FIXTURE 3 4 50 V_FIXTURE 4 100 5 .ENDS *-------------------------------------------------------------------------- .SUBCKT FALLING2 2 100 * | | * | Reference Voltage (Usually Pulldown Ref. or GND) * Output Serving as PWL Voltage Source to Input Connection *-------------------------------------------------------------------------- VIN 2 100 PWL + 0.0 5 + 1.5n 5 + 2.5n 2.5 .ENDS *========================================================================== ibiscal.lib *========================================================================== * IBIS CALCULATED TABLE AND WAVEFORM SUBCIRCUITS *========================================================================== * * LIBRARY OF SUBCIRCUITS * * IBISMOD.LIB Copy of IBIS Data formatted into a Subcircuit * Data Library for Inclusion. * IBISCAL.LIB Copy of Simulation Tables and Data for Calculations * for Inclusion. * * SUBCIRCUIT CONTENTS * * RAMPS Simutaneous Ramps for Rising and Falling Sources * * KUR Pullup Rising Wavefrom VI Table Multiplier * KDR Pulldown Rising Wavefrom Time VI Table Multiplier * * KUF Pullup Falling Waveform Time VI Table Multiplier * KDF Pulldown Falling Waveform Time VI Table Multiplier * * NOTES: * (1) The Kxx tables are scaled 1nV = 1ns so that Spice Time * data is inserted directly after inserting "+ " for the * continuation of the table. These tables could be used * directly as PWL current sources. * (2) The ramp data is in the order of 10V maximum, but is scaled * by 1e-9 for ramp VCCS tables to correspond to typical * "nanosecond" time scaling. * *========================================================================== *========================================================================== * TIMERAMP *-------------------------------------------------------------------------- .SUBCKT RAMPS 1 100 2 3 * | | | | * | | | Output Falling Voltage Ramp * | | Output Rising Voltage Ramp * | Reference Voltage (Usually Pulldown Ref. or GND) * Input Pulse Voltage *-------------------------------------------------------------------------- * Enter Scaled Ramp Duration Here in 1nV = 1nS * vvv VTIME 4 100 3.00N * RTIME 4 100 1E9 ETIMEG 5 100 4 100 1E9 RIN 1 100 1E9 GRAMPR 7 100 1 6 -2 CRAMP 7 100 1E-9 ERAMPR 2 100 7 100 1E-9 RRAMPR 2 100 1E9 ERAMPF 3 100 4 2 1 RRAMPF 3 100 1E9 DMAX 7 5 DIDEAL DMIN 100 7 DIDEAL VHALF 6 100 0.5 RHALF 6 100 1E9 .MODEL DIDEAL D (N=0.001) .ENDS *========================================================================== *========================================================================== * PULLUP TABLE RISING WAVEFORM MULTIPIER VCCS *-------------------------------------------------------------------------- .SUBCKT KUR 1 100 2 * | | | * | | Current Source Output * | Reference Voltage (Usually Pulldown Ref. or GND) * Input Sense Voltage (Usually at ramp output) *-------------------------------------------------------------------------- GDR_HS 100 2 PWL(1) 1 100 + 0. 0 + 1.5n 0 + 2.0n 0.5 + 2.5n 1.0 .ENDS *========================================================================== * PULLDOWN TABLE RISING WAVEFORM MULTIPIER VCCS *-------------------------------------------------------------------------- .SUBCKT KDR 1 100 2 * | | | * | | Current Source Output * | Reference Voltage (Usually Pulldown Ref. or GND) * Input Sense Voltage (Usually at ramp output) *-------------------------------------------------------------------------- GDF_HS 100 2 PWL(1) 1 100 + 0. 1 + 1n 1 + 1.5n 0.0 .ENDS *========================================================================== *========================================================================== * PULLUP TABLE FALLING WAVEFORM MULTIPIER VCCS *-------------------------------------------------------------------------- .SUBCKT KUF 1 100 2 * | | | * | | Current Source Output * | Reference Voltage (Usually Pulldown Ref. or GND) * Input Sense Voltage (Usually at ramp output) *-------------------------------------------------------------------------- GUF_HS 100 2 PWL(1) 1 100 + 0. 1 + 0.5n 1 + 1.0n 0.5 + 1.5n 0 .ENDS *========================================================================== *========================================================================== * PULLDOWN TABLE FALLING WAVEFORM MULTIPIER VCCS *-------------------------------------------------------------------------- .SUBCKT KDF 1 100 2 * | | | * | | Current Source Output * | Reference Voltage (Usually Pulldown Ref. or GND) * Input Sense Voltage (Usually at ramp output) *-------------------------------------------------------------------------- GDF_HS 100 2 PWL(1) 1 100 + 0. 0 + 1.5n 0 + 2.0n 0.5 + 2.5n 1 .ENDS *========================================================================== ext2r.sp * EXTRACT 2 WAVEFORM RISING CALIBRATION * .INCLUDE IBISMOD.LIB $......... VVVVVVVV * * SUPPLIES XPWR VCC GND PWRC GNDC SUPPLIES * * INPUT WAVEFORM 1 AND DUMMY LOAD XVIN1 IN1 GND RISING1 RIN1 IN1 GND 1E6 * * INPUT WAVEFORM 2 AND DUMMY LOAD XVIN2 IN2 GND RISING2 RIN2 IN2 GND 1E6 * * HIGH SIDE 1 XUP1 OUT1 VCC NU1 PULLUP VUP1 NU1 VCC 0 GUP1 OUT1 VCC CUR='-I(VUP1)*I(VKUR)' XPC1 OUT1 PWRC POWER_CLAMP * * LOW SIDE 1 XDN1 OUT1 GND ND1 PULLDOWN VDN1 ND1 GND 0 GDN1 OUT1 GND CUR='-I(VDN1)*I(VKDR)' XGC1 OUT1 GNDC GND_CLAMP * * C_COMP AND DUT PACKAGE 1 XCAP1 OUT1 GND C_COMP XPKG1 OUT1 GND PIN1 PACKAGE * * LOAD 1 XLOAD1 PIN1 GND LOADR1 RPIN1 PIN1 GND 1E9 * * HIGH SIDE 2 XUP2 OUT2 VCC NU2 PULLUP VUP2 NU2 VCC 0 GUP2 OUT2 VCC CUR='-I(VUP2)*I(VKUR)' XPC2 OUT2 PWRC POWER_CLAMP * * LOW SIDE 2 XDN2 OUT2 GND ND2 PULLDOWN VDN2 ND2 GND 0 GDN2 OUT2 GND CUR='-I(VDN2)*I(VKDR)' XGC2 OUT2 GNDC GND_CLAMP * * C_COMP AND DUT PACKAGE 2 XCAP2 OUT2 GND C_COMP XPKG2 OUT2 GND PIN2 PACKAGE * * LOAD 2 XLOAD2 PIN2 GND LOADR2 RPIN2 PIN2 GND 1E9 * * FEEDBACK TABLE ADJUSTMENT .............................. VVV GDET NDET GND CUR='(I(VDN2)*I(VUP1)-I(VDN1)*I(VUP2))/(1E4)' VDET NDET GND 0 * GKUR NKU GND + CUR='((V(IN2)-V(PIN2))*I(VDN1)-(V(IN1)-V(PIN1))*I(VDN2))/I(VDET)' VKUR NKU GND 0 * GKDR NKD GND + CUR='((V(IN1)-V(PIN1))*I(VUP2)-(V(IN2)-V(PIN2))*I(VUP1))/I(VDET)' VKDR NKD GND 0 * .TRAN 0.2n 10n .PRINT TRAN I(VKUR) .PRINT TRAN I(VKDR) * .OPTION POST .END ext2f.sp * EXTRACT 2 WAVEFORM FALLING CALIBRATION * .INCLUDE IBISMOD.LIB $......... VVVVVVVV * * SUPPLIES XPWR VCC GND PWRC GNDC SUPPLIES * * INPUT WAVEFORM 1 AND DUMMY LOAD XVIN1 IN1 GND FALLING1 RIN1 IN1 GND 1E6 * * INPUT WAVEFORM 2 AND DUMMY LOAD XVIN2 IN2 GND FALLING2 RIN2 IN2 GND 1E6 * * HIGH SIDE 1 XUP1 OUT1 VCC NU1 PULLUP VUP1 NU1 VCC 0 GUP1 OUT1 VCC CUR='-I(VUP1)*I(VKUF)' XPC1 OUT1 PWRC POWER_CLAMP * * LOW SIDE 1 XDN1 OUT1 GND ND1 PULLDOWN VDN1 ND1 GND 0 GDN1 OUT1 GND CUR='-I(VDN1)*I(VKDF)' XGC1 OUT1 GNDC GND_CLAMP * * C_COMP AND DUT PACKAGE 1 XCAP1 OUT1 GND C_COMP XPKG1 OUT1 GND PIN1 PACKAGE * * LOAD 1 XLOAD1 PIN1 GND LOADF1 RPIN1 PIN1 GND 1E9 * * HIGH SIDE 2 XUP2 OUT2 VCC NU2 PULLUP VUP2 NU2 VCC 0 GUP2 OUT2 VCC CUR='-I(VUP2)*I(VKUF))' XPC2 OUT2 PWRC POWER_CLAMP * * LOW SIDE 2 XDN2 OUT2 GND ND2 PULLDOWN VDN2 ND2 GND 0 GDN2 OUT2 GND CUR='-I(VDN2)*I(VKDF)' XGC2 OUT2 GNDC GND_CLAMP * * C_COMP AND DUT PACKAGE 2 XCAP2 OUT2 GND C_COMP XPKG2 OUT2 GND PIN2 PACKAGE * * LOAD 2 XLOAD2 PIN2 GND LOADF2 RPIN2 PIN2 GND 1E9 * * FEEDBACK TABLE ADJUSTMENT .............................. VVV GDET NDET GND CUR='(I(VDN2)*I(VUP1)-I(VDN1)*I(VUP2))/(1E7)' VDET NDET GND 0 * GKUF NKU GND + CUR='((V(IN2)-V(PIN2))*I(VDN1)-(V(IN1)-V(PIN1))*I(VDN2))/I(VDET)' VKUF NKU GND 0 * GKDF NKD GND + CUR='((V(IN1)-V(PIN1))*I(VUP2)-(V(IN2)-V(PIN2))*I(VUP1))/I(VDET)' VKDF NKD GND 0 * .TRAN 0.2n 10n .PRINT TRAN I(VKUF) .PRINT TRAN I(VKDF) .OPTION POST .END From owner-ibis Fri Oct 31 11:52:54 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA12045 for ; Fri, 31 Oct 1997 11:52:47 -0800 (PST) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 31 Oct 1997 11:50:43 -0800 (PST) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 31 Oct 1997 11:50:28 -0800 (PST) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Fri, 31 Oct 1997 11:50:30 -0800 (PST) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 31 Oct 1997 11:50:30 -0800 (PST) From: bob@icx.com (Bob Ross) To: ibis@eda.org Subject: IBIS AGENDA 11/7/97 IBIS Open Forum Meeting Agenda for 11/7/97 Bridge Number Reservation # Passcode (916) 356-9200 3-159555 4855377 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 - IEC 62014-1 (IBIS Version 2.1) - EIAJ III (I/O Interface Model for ICs) DesignCon98 IBIS Summit Meeting Huq DATE98 (Design Automation and Test in Europe - Ross formerly EuroDAC) IBIS Meeting s2ibis for NT Status Dodd/Wiens Editing Committee Ross/Peters BIRD44 Interpretation of Min/Max/Weak/Strong Data Ross IBISCHK2+ (Ver 2.115) PROGRESS Flora/Rokusek Version 3.1 Parser Development Ross/Peters - Funding - Test Matrix - Samples Cookbook Status Peters - Examples New Administrative Issues All 9:15 Technical Discussion 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 Oct 31 18:11:07 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA18669 for ; Fri, 31 Oct 1997 18:10:59 -0800 (PST) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 31 Oct 1997 18:08:56 -0800 (PST) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 31 Oct 1997 18:08:41 -0800 (PST) Received: by hpc110_5.icx.com via sendmail with stdio id for ibis@eda.org; Fri, 31 Oct 1997 18:08:54 -0800 (PST) (Smail-3.2.0.92 1997-Feb-9 #4 built 1997-Jun-4) Message-Id: Date: Fri, 31 Oct 1997 18:08:54 -0800 (PST) From: neven@icx.com (Neven Orhanovic) To: IBIS Reflector Subject: BIRD 45 Here is a proposal in response to a new clamping structure that needs to be modeled. Regards, Neven ****************************************************************************** ****************************************************************************** BIRD ID#: 45 ISSUE TITLE: Dynamic Clamps REQUESTER: Neven Orhanovic and Bob Ross, Interconnectix DATE SUBMITTED: 10/31/97 DATE ACCEPTED BY IBIS OPEN FORUM: ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: A novel type of termination technique is used in today's integrated circuits. The termination consists of a pair of built in dynamic clamps whose V-I curves change with time. The clamp is switched "on" when needed and switched "off" otherwise (to conserve power). When the clamp is switched "on" its V-I curve provides more clamping than a regular static clamp and when it is turned "off" it behaves like a normal clamp. The "on" switching of the dynamic clamps can be triggered by an input signal crossing a triggering threshold or by some external clock. The "off" switching can be triggered by a built in timer or an external clock. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Dynamic GND Clamp] and [Dynamic POWER Clamp] keywords are introduced under the [Model] keyword to describe dynamic ground and power clamps, respectively. |============================================================================== | Keywords: [Dynamic GND Clamp], [Dynamic POWER Clamp] | Required: No. | Description: Describes ground and power clamps that are switched on and off | dynamically. | | Subparameters: V_trigger, V_offset, | T_delay, T_on, T_width, T_off. | | Usage Rules: The [Dynamic GND Clamp] specification consists of a set of | subparameters describing the switching characteristics of | the clamp and a V-I curve (table). The V-I table describes | the dynamic clamp in its "off" state. The voltages in it | are referenced to the corresponding rail voltage (using | the same rules as the regular ground and power clamps, | [GND_clamp] and [POWER_clamp]). When the clamp is in its | "on" state, the V-I curve is offset by the offset voltage | amplitude, V_offset, described below. The switching | characteristics are described by the following | subparameters. | | V_trigger - input threshold voltage at which the dynamic | clamp turns on. This voltage is expressed | relative to the corresponding rail voltage. | | V_offset - the voltage by which the V-I curve is shifted | in its on state. | | T_delay - delay time from the input crossing V_trigger | to the beginning of the clamp turn "off" to | "on" transition. | | T_on - the time it takes the clamp to transition from | "off" to "on". | | T_off - the time it takes the clamp to transition from | "on" to "off". | | T_width - the time during which the clamp is in its "on" | state. | | These subparameters are and the resulting V-I characteristics | of the dynamic clamp are illustrated below. | | | Clamp input voltage vs. time. | | o o o o o | o | o | o ------- | o| ^ | o | | V_trigger | o | v time | o o | ------- --------> | | | | | | Clamp offset voltage vs. time. | | | | T_width | | |<----------->| | | | | o o o o o o o o --- | | o o ^ | | o o | | | o o | V_offset | | o o | | | o o v time | o o o o o o o o o o --------> | | T_delay | |<----->| T_on T_off | |<--->| |<--->| | | | Clamp V-I characteristics (e.g., [Dynamic GND Clamp]): | | ^ I | | | | | | | | | o o o o---x-x-x---------------> V | o x | o x | | o x <--Clamp V-I curve when in "on" state | | o <-- Clamp V-I curve when in "off" state | |------------------------------------------------------------------------------ | | Example: | [Dynamic GND Clamp] | V_trigger = 0.4 V V_offset = 0.9 V T_delay = 0.5 ns T_on = 1 ns T_width = 6 ns T_off = 1 ns | | Voltage I(typ) I(min) I(max) | -5.000 -3.300e+01 -3.000e+01 -3.500e+01 -4.000 -2.300e+01 -2.200e+01 -2.400e+01 -3.000 -1.300e+01 -1.200e+01 -1.400e+01 -2.000 -3.000e+00 -2.300e+00 -3.700e+00 -1.900 -2.100e+00 -1.500e+00 -2.800e+00 -1.800 -1.300e+00 -8.600e-01 -1.900e+00 -1.700 -6.800e-01 -4.000e-01 -1.100e+00 -1.600 -2.800e-01 -1.800e-01 -5.100e-01 -1.500 -1.200e-01 -9.800e-02 -1.800e-01 -1.400 -7.500e-02 -7.100e-02 -8.300e-02 -1.300 -5.750e-02 -5.700e-02 -5.900e-02 -1.200 -4.600e-02 -4.650e-02 -4.550e-02 -1.100 -3.550e-02 -3.700e-02 -3.450e-02 -1.000 -2.650e-02 -2.850e-02 -2.500e-02 -0.900 -1.850e-02 -2.100e-02 -1.650e-02 -0.800 -1.200e-02 -1.400e-02 -9.750e-03 -0.700 -6.700e-03 -8.800e-03 -4.700e-03 -0.600 -3.000e-03 -4.650e-03 -1.600e-03 -0.500 -9.450e-04 -1.950e-03 -3.650e-04 -0.400 -5.700e-05 -2.700e-04 -5.550e-06 -0.300 -1.200e-06 -1.200e-05 -5.500e-08 -0.200 -3.000e-08 -5.000e-07 0.000e+00 -0.100 0.000e+00 0.000e+00 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 5.000 0.000e+00 0.000e+00 0.000e+00 | | [Dynamic POWER Clamp] | V_trigger = -0.4 V V_offset = -0.9 V T_delay = 0.5 ns T_on = 1 ns T_width = 6 ns T_off = 1 ns | | Voltage I(typ) I(min) I(max) | -5.000 1.150e+01 1.100e+01 1.150e+01 -4.000 7.800e+00 7.500e+00 8.150e+00 -3.000 4.350e+00 4.100e+00 4.700e+00 -2.000 1.100e+00 8.750e-01 1.300e+00 -1.900 8.000e-01 6.050e-01 1.000e+00 -1.800 5.300e-01 3.700e-01 7.250e-01 -1.700 2.900e-01 1.800e-01 4.500e-01 -1.600 1.200e-01 6.850e-02 2.200e-01 -1.500 3.650e-02 2.400e-02 6.900e-02 -1.400 1.200e-02 1.100e-02 1.600e-02 -1.300 6.300e-03 6.650e-03 6.100e-03 -1.200 4.200e-03 4.750e-03 3.650e-03 -1.100 2.900e-03 3.500e-03 2.350e-03 -1.000 1.900e-03 2.450e-03 1.400e-03 -0.900 1.150e-03 1.600e-03 7.100e-04 -0.800 5.500e-04 9.150e-04 2.600e-04 -0.700 1.200e-04 4.400e-04 5.600e-05 -0.600 5.400e-05 1.550e-04 1.200e-05 -0.500 1.350e-05 5.400e-05 1.300e-06 -0.400 8.650e-07 7.450e-06 4.950e-08 -0.300 6.250e-08 7.550e-07 0.000e+00 -0.200 0.000e+00 8.400e-08 0.000e+00 -0.100 0.000e+00 0.000e-08 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The proposal is designed to retain as much of the existing IBIS clamp syntax as possible. The dynamic clamp V-I curve tables follow all of the conventions of the existing V-I tables. The overall structure is to connect a dynamic clamp to the same rail voltage as its corresponding regular clamp. The dynamic clamps V-I curve is shifted according to the offset voltage pulse. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ******************************************************************************