From owner-ibis Mon Jun 2 08:44:59 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 IAA10688 for ; Mon, 2 Jun 1997 08:44:55 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 2 Jun 97 08:43 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 2 Jun 97 08:43 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 2 Jun 97 08:43 PDT Message-Id: Date: Mon, 2 Jun 97 08:43 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 5/30/97 DATE: June 2, 1997 SUBJECT: 5/30/97 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1997 PARTICIPANTS LIST: AMP Jeff Walden Applied Simulation Technology Dileep Divekar*, Norio Matsui, Raj Raghuram Cadence Design & UniCAD C. Kumar*, Don Telian Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu Hewlett Packard, EEsof Karl Kachigan, Henry Wu High Design Technology (Razvan Ene) HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier* Intel Corporation Stephen Peters*, Arpad Muranyi, Henry Maramis Interconnectix Bob Ross* Mitsubushi Tam Cao Motorola Ahmed Omer National Semiconductor Syed Huq*, Cheng-Yang Kao, Mike Bristol, Peter Laflamme, Kevin Smith NCR Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto) Quad Design/Viewlogic Jon Powell, Chris Rokusek Quantic EMC (Mike Ventham) Texas Instruments Thomas Fisher Thomson-CSF/SCTF (Jean LeBrun) VeriBest Ian Dodd, William Bell VLSI Technology Harish Patel, D.C. Sessions Zuken-Redac (John Berrie) 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 EIA Patti Rusher* EMC Fabrizio Zanella Micron Technology Brian Johnson Molex Gus Panella North Carolina State U. (Michael Steer) S3, Inc. Porsh Shih, Sarathy Sribhashyam 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 6/12/97 IBIS SUMMIT at Anaheim, CA - No Telephone Bridge 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. MEMBERSHIP UPDATE AND TREASURER'S REPORT Patti Rusher will provide a full report by next meeting. Several companies will be billed again. UniCAD is now moved to the Cadence line as a result of a recent merger with CCT. REVIEW OF MINUTES AND AR'S No corrections. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Bob Ross reported that Dr. Howard Johnson gave liberal references to IBIS in his Straight Talk for Serious Digital Designers column "Planning for Signal Integrity" in Electronic Design, May 12, 1997, pp. 135-136. Bob also reported an article "AMP Offers EDA Software" in Electronic Engineering Times, May 19, 1997, pp. 56-57 which mentions an IBIS-to AmpSpice converter. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported that Integrated Device Technology IBIS models are now downloadable at: http://www.idt.com/cross_pl/models. Under DOWNLOADABLE MODELS, hit search, and select Model Type "IBIS". AR - Jon Powell add this link to the EIA/IBIS Web site Model list. OPENS FOR NEW ISSUES Bob Ross - BIRD43 Bob Ross - BIRD31.3 and BIRD32 close-out DESIGN AUTOMATION CONFERENCE (DAC) 1997 IBIS MEETING PLANNING Syed Huq reported on the planned agenda for the EIA/IBIS Summit meeting on Thursday, June 12, 1997 in Anaheim, California at the Marriott Hotel. This will be next door to the Convention Center. The agenda will be posted after the meeting, pending resolution of some BIRDs. Patti Rusher has reserved Suite 312, and this will also be noted in the lobby as an EIA/IBIS meeting. She plans for 25 people with a continental breakfast starting at 8:30 A.M. Lunch will also be provided. An overhead projector, screen, podium, and flip chart will be available. Syed requested that Patti bring blank foils and color markers for overheads. Syed requests that presenters bring 25 copies of their presentations to the meeting to distribute. This will save on logistics to copy the presentations. Bob Ross mentioned that there is no teleconferencing for this meeting since the expense is very high. AR - Syed Huq send out the Meeting Agenda [Done]. INTERNATIONAL PROGRESS Patti Rusher reported on a USTAG group meeting which voted to approve a new work item proposal "IBIS Models and EMC Simulation" from France. This is for IEC TC93, and the proposal is referenced as 93/60/NP. Bob Ross is listed as the US contact and will be copied on all activity. Bob stated that US EDA vendors are interested in the proposal, so the Committee may want to become actively be involved. Patti stated that IBIS Version 2.1 is a separate approved new work item proposal 93/46/NP. Bob reported that Japanese EIAJ activity will be one of the IBIS Summit presentations. This should give us an update on the I/O Interface Model for Integrated Circuits proposal. IBISCHK2+ REPORT Bob Ross reported that Chris Rokusek has fixed a problem where some [Rising Waveform] and [Falling Waveform] tables were not fully tested for correct starting and ending values for Open_* Models. Bob has put an updated version of ibischk2+ on vhdl.org under /pub/ibis/ibschk2+ for downloading. Bob recommends this version as the utility to use for checking because it helps detect situations where the time window may not have been long enough for waveform table generation. IBIS COOKBOOK PROGRESS Stephen Peters has set some time to work on the Cookbook for IBIS Version 2.1. It will also reference a few IBIS Version 3.0 features. Stephen will have copies available at the IBIS Summit meeting for review. This copy is public and it has expanded and updated sections. It also has answered many of the IBIS reflector questions. Stephen has not included the preferred vendor test loads, nor has he included a section on measurement techniques. S2IBIS2 ISSUES AND NT Bob Ross has posted an interim fix for a s2ibis2 resolution problem. The fix has columns printed with four decimal digits. Bob also noted continued IBIS reflector questions, and there may be some other bugs lurking in regions that have not been exercised thoroughly, such as ECL model processing. BIRD41.6 - MODELING SERIES SWITCHABLE DEVICES Bob Ross reported that he sent out a PSpice netlist to test the approach to model series switches. BIRD41.6 has gone through successive modifications to and now includes a change so the [Model Selector] keyword also applies to Series and Series_switch models. (Dave Moxley indicated before the meeting started that he uses series switches for 5 V to 3.3 V interface applications. He currently needs to use discrete series elements as an approximation.) Stephen Peters asked if BIRD41.6 includes the series resistor element, and Bob reported that it did in a manner that should be compatible with BIRD36.3. Bob has found a few editorial mistakes and plans to issue a correction BIRD41.7. John Fitzpatrick commented at the end of the meeting that he agreed with the work in BIRD41.6. AR - Bob Ross issue BIRD41.7 with corrections [Done]. BIRD42.1 - MODELING CURRENT WAVEFORMS Kumar agreed with the implementation that the [GND Current] and [POWER Current] tables be positioned under the [Rising Waveform] and [Falling Waveforml tables. Bob Ross also has also added to the [Rising Waveform] Waveform] sections some suggested practices concerning what subparameters should not be used, if possible, to produce the best models for simulation. He also changed the examples so that they represented better fixture loads. The Waveform tables are derived from the same Spice model used for generating the [GND Current] and [Power Current] tables. Stephen Peters commented that the new Waveform tables contain some non-monotonic points at the beginning and wondered if this would be a problem with simulators. Bob and Kumar responded that this would not be a problem for some simulators, but if it is, the simulators can filter the data. IBIS should capture the actual data. Kumar commented that the C_comp de-embedding mathematics can contribute to numerical problems - getting the C_comp current from the derivative of voltage across C_comp. A note should be put in to warn about this. Stephen Peters asked if BIRD42.1 is intended for a more accurate model or for SSO bounce problems, and Kumar responded that it is for both. The current distribution information is needed for more accurate representation in large ASICs with, say 1000, pins, and is also information for SSO. The current tables can help in interpolation and fitting the response to the existing loads. AR - Bob Ross issue BIRD41.2 with a C_comp note [Done]. BIRD43 - COMPONENT TEST POINT SUBPARAMETERS Bob Ross introduced BIRD43 which adds two subparameters to [Component] in a manner similar to Polarity and Enable for [Model]. The Si_location and Timing_location subparameters give the location of the SI or Timing test points. The choices are Die or Pin. The default (without subparameters) is the Pin. Some ASICs, however, give specifications at the Die. BIRD31.3 - MATED MODELS In preparation for Version 3.0 ratification, Bob Ross wanted to close out some dormant BIRDs. BIRD31.3 was issued May, 1996. Any new mated model proposal should be made relative to IBIS Version 3.0. Since it would likely be proposed as a separate file, work on it can proceed in an independent manner from IBIS Version 3.0. BIRD31.3 was rejected unanimously. BIRD32 - ADDITIONAL ENHANCEMENT TO THE PACKAGE MODEL (.pkg FILE) Bob Ross proposed that BIRD32 issued January, 1996 also be closed out, and C. Kumar agreed. A new proposal could be generated relative to IBIS Version 3.0 to advance the package syntax for coupled sections. BIRD32 was rejected unanimously. CONNECTOR MODELING Bob Ross suggested that this discussion be dropped until new proposals are presented. MODELING EARLY CLAMPS IN IBIS Stephen Peters reported that a proposal will be issued, when needed. VERSION 3.0 RATIFICATION In preparation for the EIA/IBIS Summit, Bob Ross plans an updated Work in Progress pending Version 3.0 of IBIS stored on vhdl.org under /pub/ibis/wip. This version will include the changes in pending BIRDs 41.7, 42.2 and 43. Bob will also plan a cleaned up pending IBIS Version 3.0 that does not contain the internal references to the BIRDs. Bob will also make some minor editorial changes the document. One change, for example, would be to simply the BIRD30.2 [Model Selector] to use more readable model names. Because of the anticipated size of these documents, Bob does not plan to mail them out on the IBIS reflector. They will be available from a browser or by FTP. However, Bob will mail a copy to anyone who requests one. Also, IBIS members who cannot attend the EIA/IBIS Summit may submit votes on the pending BIRDs and on ratification of EIA/IBIS Version 3.0 by mail to Bob Ross (address below). AR - Bob Ross put in the IBIS wip directory the final updated pending IBIS Version 3.0 which shows the BIRD changes, and of a cleaned up Version of pending IBIS Version 3.0 without the references to BIRDs [Done]. NEXT MEETING: The next meeting is a Face-to-face IBIS Summit Meeting on Thursday, June 12, 1997, 8:30 A.M. to 5:00 P.M. at the Design Automation Conference in Anaheim, California. BIRDs 41.7 and 42.3 and 43 will be up for a vote along with IBIS Version 3.0 ratification. No telephone bridge will be available for this meeting. ============================================================================== 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 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design/Viewlogic 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via FTP anonymous. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Mon Jun 2 10:49:13 1997 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id KAA12805; Mon, 2 Jun 1997 10:49:13 -0700 (PDT) Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA11875; Mon, 2 Jun 97 10:50:55 PDT Received: by ricky.sun_net (4.1/SMI-4.1) id AA16843; Mon, 2 Jun 97 10:50:53 PDT Date: Mon, 2 Jun 97 10:50:53 PDT From: scotts@actel.com (Scott Schlachter) Message-Id: <9706021750.AA16843@ricky.sun_net> To: chang@nexen.com, ibis-users@vhdl.org, ibis@vhdl.org Subject: Re: Verifying IBIS models Cc: jem@ricky.actel.com Hi Luke, My oppinions here are my own, and not necessarily those of my company. I missed this when you first posted, but I feel compelled to input my oppinion on this. There has been discussion on the ibis reflector in the past regarding the accuracy of SPICE models, particularly in the diode voltage regions. For HSPICE in particular, we concluded that the only way to provide a "non-ideal" set of clamping diodes (for CMOS), the transistors' inherent diodes needed to be shut down (set IS=0, AD=0, and AS=0, I believe), and a descrete set of diodes placed on the drains of the transistors. This problem had something to do with the fact that there was no way to model the bulk resistance (the majority of the resistance that the inherent diodes should have experienced) without increasing channel resistance. The reason that I am even bringing this up here, is that I wanted to provide at least one example of a potential source of innacuracy of a *very* commonly used version of SPICE. We (painstakingly) developed our first IBIS model from a SPICE netlist, by attempting to add *all* possible parasitic components that we knew would exist in our actual silicon layout (resistance and capacitances in our metal interconnects, etc.). We discovered the above mentioned problem during this process, and sought advice throught this email reflector. What we found was that while a few companies that were participating on the reflector knew about and addressed this particular problem, there were definitely others that didn't. How well can you trust a vendors SPICE based IBIS model that you downloaded off the web? Not to sound too harsh, but roll the dice. Our hope was to produce a IBIS model based on silicon measurments, and then check to see how accurately the SPICE versions corellated. If they matched well, we knew that we would have a very usefull method of providing an IBIS model file to our customers, potentially even before we had silicon available. In addition, we wanted to be able to rely on the ramp data generated from the SPICE models, because we knew that this data would be extremely hard to extract from the Lab (on a packaged part, you have the package parasitics effecting the ramp; on an unpackaged die, you have parasitics added by the probe leads, etc.). What we found after doing our lab measurements, was that there was pretty good corellation between GND and VCC, but guess what? The diode regions were close, but still had some discrepencies (mostly around the knees). This, in my oppinion, is the ultimate test that you are asking for. However, when a vendor does this, they (like us) aren't going to bother releasing the SPICE based IBIS model - why should they, when they now have (the more accurate) silicon measurement based version that they can release instead? I'm not saying that SPICED based versions are untrustworthy; undoubtably there are some vendors that have developed extremely accurate SPICE models, even to the extent that they may have done all sorts of tricks so as to accurate model their netlists in the Voltage areas that are not traditionally dwelled in for development verification (more than a volt or 2 above VCC or below GND). But a behavioral model can only be as accurate as the thing that it's supposed to be behaving. If that "thing" is a SPICE netlist... I have just pointed out what I believe to be one definite shortcomming in one of the more popular SPICE versions out there. However, I also pointed out an unofficial workaround that *some* vendors are aware of. I'll let you draw your own conclusions. A last oppinion that I would like to make is this: I personally think that SPICED based IBIS model files should only be used as a last resort. The case where SPICE models for a new process are available, but the packaged silicon is not yet available, might be a good example - you might be interested in a chip vendors product even before it has hit the market, and this provides a way for you to initially simulate it's behavior on the new board that you are designing, now - before it can even be purchased. Otherwise, why bother? I am interested in hearing other vendors response to this. My conclusion was that extracting the data in the lab was 10x easier that struggling with trying to get the SPICE netlist to be as accurate as possible; and, the lab data is the "real thing" anyhow. Consequently, lab data can be screwed-up too, so ultimately you will need to either quiz the heck out of the vendor who created the model file as to their methodology (if they didn't describe it in total minute detail within the comments of their IBIS model files), or you will just have to trust them... -Scott Schlachter Design Engineering scotts@actel.com Actel Corporation Sunnyvale, CA > From owner-ibis@server.vhdl.org Fri May 30 15:21:20 1997 > Luke Chang wrote: > > > When IC vendors create IBIS models for their components, how do they > > verify whether they are correct or not, compared to either the original > > SPICE models or to physical measurement data? Do they actually do this > > comparison? Is there a simulation methodology to do this comparison? > > > > I am just a user of IBIS models and will never create them. So I am > > mainly interested in knowing whether I can always (blindly) trust the > > models I get from the vendor Web sites or directly from the vendors. > > I suppose the usual disclaimers (I can't, strictly speaking, > speak for VLSI, much less other manufacturers) are in order. > That said, here's a little about our approach: > > 1) We SPICE the dickens out of I/O designs. > 2) We verify the SPICE characteristics in design > validation and test against them. > 3) We generate IBIS models from the SPICE models. > 4) We spot-compare SPICE simulations made from > hand-translating IBIS back to SPICE. > > We're in the process of converting the canonical > model for testing purposes from old-fashioned data > sheets to IBIS. We *intensely* wish we had a > working IBIS-to-SPICE translator that we could use > for closing the loop, but at present there don't > seem to be any around. > > -- > D. C. Sessions > dc.sessions@tempe.vlsi.com > From owner-ibis Mon Jun 2 16:21:02 1997 Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA18489 for ; Mon, 2 Jun 1997 16:21:01 -0700 (PDT) Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id QAA15848 for ; Mon, 2 Jun 1997 16:17:25 -0700 Received: from pico.apple.com (pico.apple.com [17.216.20.171]) by scv3.apple.com (8.8.5/8.8.5) with SMTP id QAA05358 for ; Mon, 2 Jun 1997 16:22:19 -0700 Received: from snakeye.apple.com by pico.apple.com (4.1/SMI-4.1) id AA02361; Mon, 2 Jun 97 16:22:03 PDT Received: from snakeye (localhost) by snakeye.apple.com id AA07774; Mon, 2 Jun 97 16:22:03 PDT Sender: danwei@pico.apple.com Message-Id: <3393559A.2781E494@pico.apple.com> Date: Mon, 02 Jun 1997 16:22:02 -0700 From: Danwei Xue X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Subject: What is SSTL? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Could anyone explain what Serial Stub Terminated Transceiver Logic (SSTL) is and point out where I can find some reading materials on it? Thank you very much in advance, Danwei Apple Computer, Inc. From owner-ibis Tue Jun 3 04:37:08 1997 Received: from alcatel.fr (gatekeeper.alcatel.fr [194.133.58.131]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id EAA01212 for ; Tue, 3 Jun 1997 04:37:06 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (8.8.5/8.8.5) with ESMTP id NAA31241 for ; Tue, 3 Jun 1997 13:36:17 +0200 Received: from ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by nsfhh5.alcatel.fr (8.7.3/8.7.3) with SMTP id NAA08437 for ; Tue, 3 Jun 1997 13:35:37 +0200 (METDST) Received: from las41247.ln.cit.alcatel.fr by ln.cit.alcatel.fr (4.1/SMI-4.1) id AA29083; Tue, 3 Jun 97 13:35:41 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA00319; Tue, 3 Jun 97 13:35:13 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <33940170.2781E494@ln.cit.alcatel.fr> Date: Tue, 03 Jun 1997 13:35:12 +0200 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Re: What is SSTL? References: <3393559A.2781E494@pico.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, Danwei's mail made me think about how to describe inputs of technologies like SSTL and GTL in IBIS. These technologies have "differential" inputs, in the sense that there is a common reference input that can be set externally. In IBIS 3.0, it will be possible to specify the input thresholds for typ/min/max voltages. But there is no way of specifying an external voltage reference. Is there a need to extend IBIS to model SSTL inputs better? It is very likely the SSTL (or similar technos, eg Rambus) will become commonplace in memory systems. Just a thought, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 Danwei Xue wrote: > > Hello, > > Could anyone explain what Serial Stub Terminated Transceiver Logic > (SSTL) is and point out where I can find some reading materials on it? > > Thank you very much in advance, > > Danwei > Apple Computer, Inc. From owner-ibis Wed Jun 4 17:13:09 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 RAA09047; Wed, 4 Jun 1997 17:13:08 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id RAA02740; Wed, 4 Jun 1997 17:10:29 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma002652; Wed, 4 Jun 97 17:10:20 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA13795 for ibis@vhdl.org; Wed, 4 Jun 97 17:12:03 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA22691; Wed, 4 Jun 97 17:15:49 PDT Date: Wed, 4 Jun 97 17:15:49 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9706050015.AA22691@rockie.nsc.com> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: IBIS model download URL update - National Cc: huq@rockie.nsc.com IBISfans, If you have bookmarked the National IBIS site, you need to update the URL. The new URL is: http://www.national.com/models Previous link will send you to an old site. Sorry for this inconvinience. Regards, Syed National Semiconductor Corp. From owner-ibis Thu Jun 5 18:41:59 1997 Received: from montana.nwlink.com (root@montana.nwlink.com [199.242.23.13]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA05227 for ; Thu, 5 Jun 1997 18:41:58 -0700 (PDT) Received: from steve.nwlink.com ([209.20.148.68]) by montana.nwlink.com (8.8.5/8.8.5) with SMTP id SAA23593 for ; Thu, 5 Jun 1997 18:41:07 -0700 (PDT) Date: Thu, 5 Jun 1997 18:41:07 -0700 (PDT) Message-Id: <199706060141.SAA23593@montana.nwlink.com> X-Sender: stevek@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: Steve Kaufer Subject: needed for IBIS V3.1 Mini-topic for the upcoming IBIS Summit meeting at DAC: I believe it's important for V3.1 of the specification to include several simple, clear example files, e.g., a simple IC using a minimum of constructs, a more-complex IC using a few "extra" features like waveform tables, a network-packaged passive device, and a bus switch. Why? Because lacking these, the specification is so intimidating to newcomers that many are being scared off, to the detriment of the entire standard. Remember V1.x? It was a relatively quick, easily comprehended "read." What we have now is richer and more powerful, but also exponentially more confusing. Some of us on the committee are probably "velocitized" to the point where we're not aware of the problem's gravity. From recent conversations with IBIS "newbies" (and this includes semiconductor-vendor personnel, unfortunately), I think it works like this: 1. Reads IBIS spec (or part of it). 2. Wants to kill self. 3. Hears about Spice-to-IBIS, and thinks "that's my only hope!" 4. Then the real trouble begins... Personally, I'd like to see the opening page of the spec state clearly that about 85% of modeling applications can use about 25% of the specification's constructs, and point straight to the example models. Also good would be a designation of some kind delineating between "basic" and "luxury" constructs. I'd be interested in hearing opinions about this at the Summit... Regards, Steve Kaufer, HyperLynx From owner-ibis Fri Jun 6 02:31:44 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id CAA13385 for ; Fri, 6 Jun 1997 02:31:43 -0700 (PDT) Received: from alfred.itg.ti.com ([192.168.43.15]) by jester.ti.com (8.8.5) with ESMTP id EAA01398; Fri, 6 Jun 1997 04:29:50 -0500 (CDT) Received: from dfrs15.itg.ti.com (dfrs15.itg.ti.com [137.167.210.19]) by alfred.itg.ti.com (8.8.5/8.8.5) with SMTP id EAA20807; Fri, 6 Jun 1997 04:29:48 -0500 (CDT) Received: from ti (CNA0819696.business.tide.ti.com [137.167.202.100]) by dfrs15.itg.ti.com (TI SMTPMail MTA v1.0.9.3) with SMTP id EFJFBGBI; Fri, 6 Jun 1997 11:30:31 +0100 (W. Europe Daylight Time) X-Mailer: BeyondMail for Windows/Professional 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit To: ibis@vhdl.org, Steve Kaufer From: Hans M Hilbig Subject: re: needed for IBIS V3.1 Date: Fri, 6 Jun 1997 11:31:19 -0700 X-BeyondMail-Priority: 1 Message-Id: Conversation-Id: <199706060141.SAA23593@montana.nwlink.com> In-Reply-To: <199706060141.SAA23593@montana.nwlink.com> Reply-To: Hans M Hilbig X-Receipt-From-Agent: true Steve, I fully subscribe the statements of your msg about the example files. Having started with IBIS in my group early this year, we are still relativly new to IBIS and can remember well the pitfalls we were trapping into. We had two major reasons to generate IBIS models: Our customers like it and it's (still) relativly easy to construct and to tweak (compared to H-SPICE). Personally I'm concerned that IBIS will become so blown up in the future that the latter reason will go away. Adding more bells and whistles does not necessarily mean better 'accuracy', particularly if you don't have real (accurate) data to feed the bells and whistles. Pls remember that our customers want us to supply IBIS models early in the development stages, mostly at that time when the design (and its simulation) is not completed yet. The more estimates and judgements we add, the higher the chance that the model does not reflect the silicon that comes out later. Regards, Hans M Hilbig ************************************************************** EMSLP New Products Characterization Texas Instruments Freising Phone: +49-8161-804126 FAX:+49-8161-804909 e-mail: h-hilbig@ti.com ------------------ Original text From: Steve Kaufer , on 6/6/97 9:25 AM: Mini-topic for the upcoming IBIS Summit meeting at DAC: I believe it's important for V3.1 of the specification to include several simple, clear example files, e.g., a simple IC using a minimum of constructs, a more-complex IC using a few "extra" features like waveform tables, a network-packaged passive device, and a bus switch. Why? Because lacking these, the specification is so intimidating to newcomers that many are being scared off, to the detriment of the entire standard. Remember V1.x? It was a relatively quick, easily comprehended "read." What we have now is richer and more powerful, but also exponentially more confusing. Some of us on the committee are probably "velocitized" to the point where we're not aware of the problem's gravity. From recent conversations with IBIS "newbies" (and this includes semiconductor-vendor personnel, unfortunately), I think it works like this: 1. Reads IBIS spec (or part of it). 2. Wants to kill self. 3. Hears about Spice-to-IBIS, and thinks "that's my only hope!" 4. Then the real trouble begins... Personally, I'd like to see the opening page of the spec state clearly that about 85% of modeling applications can use about 25% of the specification's constructs, and point straight to the example models. Also good would be a designation of some kind delineating between "basic" and "luxury" constructs. I'd be interested in hearing opinions about this at the Summit... Regards, Steve Kaufer, HyperLynx From owner-ibis Fri Jun 6 07:48:37 1997 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.29.70]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id HAA18785 for ; Fri, 6 Jun 1997 07:48:36 -0700 (PDT) Received: from d01lms04.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA08004; Fri, 6 Jun 1997 14:53:21 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400003996789; Fri, 6 Jun 1997 10:50:05 -0400 From: Joe Cahill To: Cc: Subject: Re: examples needed for IBIS V3.1 Message-Id: <5010400003996789000002L092*@MHS> Date: Fri, 6 Jun 1997 10:50:05 -0400 Mime-Version: 1.0 Content-Type: text/plain Either examples or the cookbook are a very fine idea. I have been lurking here for years, building models (not IBIS) and timing our systems for much longer, and I am not easily intimidated. But I know that my first IBIS model will be a very difficult task, and probably quite sloppy if I tackle it just with the knowledge I can gain from the specification. I have been awaiting the cookbook before I attempt my first 'trial' or 'experimental' models. Money for tools is very tight here, money for engineering time is even tighter. Getting over the steep learning curve quickly would allow us to consider much more intelligently using IBIS models (and IBIS-based tools) as a base for our system timing tasks. Joe From owner-ibis Fri Jun 6 07:58:30 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 HAA18967 for ; Fri, 6 Jun 1997 07:58:29 -0700 (PDT) Received: from fmmail.fm.intel.com by calliope1.fm.intel.com (8.8.4/10.0i); Fri, 6 Jun 1997 14:57:39 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.8.5/8.7.3) id HAA06754 for ibis@vhdl.org; Fri, 6 Jun 1997 07:57:45 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 06 Jun 97 07:57:45 PDT Date: Fri, 06 Jun 97 07:55:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: needed for IBIS V3.1 Text item: Steve, Regarding the issue of "basic" and "luxury" items in IBIS, a very simple way to determine what is basic is to look at the criteria whether the item is required or not. You will find that most items are optional. Arpad =============================================================================== Mini-topic for the upcoming IBIS Summit meeting at DAC: I believe it's important for V3.1 of the specification to include several simple, clear example files, e.g., a simple IC using a minimum of constructs, a more-complex IC using a few "extra" features like waveform tables, a network-packaged passive device, and a bus switch. Why? Because lacking these, the specification is so intimidating to newcomers that many are being scared off, to the detriment of the entire standard. Remember V1.x? It was a relatively quick, easily comprehended "read." What we have now is richer and more powerful, but also exponentially more confusing. Some of us on the committee are probably "velocitized" to the point where we're not aware of the problem's gravity. From recent conversations with IBIS "newbies" (and this includes semiconductor-vendor personnel, unfortunately), I think it works like this: 1. Reads IBIS spec (or part of it). 2. Wants to kill self. 3. Hears about Spice-to-IBIS, and thinks "that's my only hope!" 4. Then the real trouble begins... Personally, I'd like to see the opening page of the spec state clearly that about 85% of modeling applications can use about 25% of the specification's constructs, and point straight to the example models. Also good would be a designation of some kind delineating between "basic" and "luxury" constructs. I'd be interested in hearing opinions about this at the Summit... Regards, Steve Kaufer, HyperLynx Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: needed for IBIS V3.1 From: Steve Kaufer To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 2.1.2 X-Sender: stevek@mail.nwlink.com Message-Id: <199706060141.SAA23593@montana.nwlink.com> Date: Thu, 5 Jun 1997 18:41:07 -0700 (PDT) Received: from steve.nwlink.com ([209.20.148.68]) by montana.nwlink.com (8.8.5/8.8.5) with SMTP id SAA23593 for ; Thu, 5 Jun 1997 18:41:07 -0700 (PDT) Received: from montana.nwlink.com (root@montana.nwlink.com [199.242.23.13]) by s erver.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA05227 for ; Thu, 5 Jun 1997 18:41:58 -0700 (PDT) Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) by mailbag.jf.intel.com (8.8.5/8.8.4) with ESMTP id SAA27462; Thu, 5 Jun 1997 18:54:11 -0700 (PDT) Received: from mailbag.jf.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0wZoDG-000qDQC; Thu, 5 Jun 97 18:53 PDT From owner-ibis Fri Jun 6 09:00:44 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA20067; Fri, 6 Jun 1997 09:00:43 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA18986; Fri, 6 Jun 1997 08:59:37 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA22856; Fri, 6 Jun 1997 08:59:52 -0700 (PDT) Message-Id: <199706061559.IAA22856@ichips.intel.com> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: examples needed for IBIS V3.1 Date: Fri, 06 Jun 1997 08:59:52 -0700 From: Stephen Peters Hello All: I've been reading the mail talking about adding examples to the spec and/or the cookbook. It's a very good idea, especially in regards to the cookbook. Do you, the dedicated users of IBIS, have some specific examples in mind? Also, are there some specific areas of the spec that needs explanation or was particularly difficult to understand? I am in the process of updateing the cookbook for presentation at the IBIS face to face at DAC next week and your suggestions for cookbook improvement would be helpfull. Thanks, Stephen Peters Intel Corp. From owner-ibis Fri Jun 6 09:02:23 1997 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA20080 for ; Fri, 6 Jun 1997 09:02:22 -0700 (PDT) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQcsua07733; Fri, 6 Jun 1997 12:01:41 -0400 (EDT) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 6 Jun 1997 12:01:30 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00704; Fri, 6 Jun 97 08:44:12 PDT Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA25958; Fri, 6 Jun 97 08:44:12 PDT Sender: jonp@qdt.com Message-Id: <33982FF4.62319AC4@qdt.com> Date: Fri, 06 Jun 1997 08:42:44 -0700 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Subject: MODELS web page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The IBIS models web page has been updated with recent information. Check it out. Bugs to jonp@qdt.com regards, jon From owner-ibis Fri Jun 6 10:09:55 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 KAA21389 for ; Fri, 6 Jun 1997 10:09:54 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 6 Jun 97 10:08 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 6 Jun 97 10:08 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 6 Jun 97 10:08 PDT Message-Id: Date: Fri, 6 Jun 97 10:08 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, stevek@hyperlynx.com Subject: Re: needed for IBIS V3.1 Steve: We will put this discussion topic on the meeting Agenda. Thank you for proposing it. I am also concerned about the amount of material in IBIS and the fact that the fundamental aspects of IBIS are no longer apparent. The new features in IBIS are all justified, based on real device modeling issues. However, most IBIS models will still need to follow only the guidelines and convensions of IBIS Versions 1.1 and 2.1. Having a set of examples is an excellent starting point to illustrate both the recommended fundamental aspects of IBIS models which apply to most situations, and also to illustrate the new functionality. I am also interested in ideas on how we can organize IBIS in a clearer manner. Bob Ross Interconnectix > Date: Thu, 5 Jun 1997 18:41:07 -0700 (PDT) > To: ibis@vhdl.org > From: Steve Kaufer > Subject: needed for IBIS V3.1 > Mini-topic for the upcoming IBIS Summit meeting at DAC: > I believe it's important for V3.1 of the specification to include several > simple, clear example files, e.g., a simple IC using a minimum of > constructs, a more-complex IC using a few "extra" features like waveform > tables, a network-packaged passive device, and a bus switch. > Why? Because lacking these, the specification is so intimidating to > newcomers that many are being scared off, to the detriment of the entire > standard. Remember V1.x? It was a relatively quick, easily comprehended > "read." What we have now is richer and more powerful, but also exponentially > more confusing. Some of us on the committee are probably "velocitized" to > the point where we're not aware of the problem's gravity. > >From recent conversations with IBIS "newbies" (and this includes > semiconductor-vendor personnel, unfortunately), I think it works like this: > 1. Reads IBIS spec (or part of it). > 2. Wants to kill self. > 3. Hears about Spice-to-IBIS, and thinks "that's my only hope!" > 4. Then the real trouble begins... > Personally, I'd like to see the opening page of the spec state clearly that > about 85% of modeling applications can use about 25% of the specification's > constructs, and point straight to the example models. Also good would be a > designation of some kind delineating between "basic" and "luxury" constructs. > I'd be interested in hearing opinions about this at the Summit... > Regards, > Steve Kaufer, > HyperLynx From owner-ibis Fri Jun 6 10:29:16 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA21738; Fri, 6 Jun 1997 10:29:15 -0700 (PDT) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id KAA07519; Fri, 6 Jun 1997 10:28:08 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id KAA23920; Fri, 6 Jun 1997 10:28:24 -0700 (PDT) Received: by ccm.jf.intel.com (ccmgate 3.2 #8) Fri, 06 Jun 97 10:28:23 PDT Date: Fri, 06 Jun 97 10:22:00 PDT From: Will Hobbs Message-ID: To: owner-ibis@server.vhdl.org, stevek@hyperlynx.com cc: Ibis@Vhdl.Org Subject: Re[2]: examples needed for IBIS V3.1 Text item: Folks, The cookbook for V2.1 is imminent. Stephen Peters of Intel, who is responsible for the majority of the V1.1 cookbook, has made good progress on the new one. He is hoping to have it largely done and ready for review prior to the IBIS Summit at DAC next week. My preference would be to keep the examples out of the spec, but I could be swayed. Regards, Will Hobbs Intel Corp. Either examples or the cookbook are a very fine idea. I have been lurking here for years, building models (not IBIS) and timing our systems for much longer, and I am not easily intimidated. But I know that my first IBIS model will be a very difficult task, and probably quite sloppy if I tackle it just with the knowledge I can gain from the specification. I have been awaiting the cookbook before I attempt my first 'trial' or 'experimental' models. Money for tools is very tight here, money for engineering time is even tighter. Getting over the steep learning curve quickly would allow us to consider much more intelligently using IBIS models (and IBIS-based tools) as a base for our system timing tasks. Joe 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-Type: text/plain Mime-Version: 1.0 Date: Fri, 6 Jun 1997 10:50:05 -0400 Message-Id: <5010400003996789000002L092*@MHS> Subject: Re: examples needed for IBIS V3.1 Cc: To: From: Joe Cahill Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400003996789; Fri, 6 Jun 1997 10:50:05 -0400 Received: from d01lms04.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA08004; Fri, 6 Jun 1997 14:53:21 GMT Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.29.70]) by server .vhdl.org (8.8.5/8.8.3) with SMTP id HAA18785 for ; Fri, 6 Jun 19 97 07:48:36 -0700 (PDT) Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) by mailbag.jf.intel.com (8.8.5/8.8.4) with ESMTP id KAA06044; Fri, 6 Jun 1997 10:09:14 -0700 (PDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id KAA19682; Fri, 6 Jun 1997 10:06:54 -0700 (PDT) Return-Path: owner-ibis@server.vhdl.org From owner-ibis Fri Jun 6 10:38:00 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 KAA21909; Fri, 6 Jun 1997 10:37:59 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id KAA21529; Fri, 6 Jun 1997 10:33:44 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma021179; Fri, 6 Jun 97 10:33:20 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA25510 for ibis@vhdl.org; Fri, 6 Jun 97 10:35:15 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA11399; Fri, 6 Jun 97 10:39:04 PDT Date: Fri, 6 Jun 97 10:39:04 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9706061739.AA11399@rockie.nsc.com> To: ibis@vhdl.org, ibis-users@vhdl.org, sjpeters@ichips.intel.com Subject: Re: examples needed for IBIS V3.1 Hi, One helpful thing would be to put a model example that has data of almost all the model types and with all the optional parameters that IBIS supports. This may not be a 'true' device but would serve as a 'example' only. Model types meaning, open_drain, ECL, PECL, CMOS etc etc and there is a LOT of optional parameters .... Regards, Syed National Semiconductor Corp. > From owner-ibis@server.vhdl.org Fri Jun 6 10:31:04 1997 > To: ibis@vhdl.org, ibis-users@vhdl.org > Subject: Re: examples needed for IBIS V3.1 > Date: Fri, 06 Jun 1997 08:59:52 -0700 > From: Stephen Peters > > > Hello All: > > I've been reading the mail talking about adding examples to the > spec and/or the cookbook. It's a very good idea, especially in > regards to the cookbook. Do you, the dedicated users of IBIS, have > some specific examples in mind? Also, are there some specific areas of the > spec that needs explanation or was particularly difficult to understand? > I am in the process of updateing the cookbook for presentation at the > IBIS face to face at DAC next week and your suggestions for > cookbook improvement would be helpfull. > > Thanks, > Stephen Peters > Intel Corp. > > From owner-ibis Fri Jun 6 11:05:01 1997 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA22287 for ; Fri, 6 Jun 1997 11:05:00 -0700 (PDT) Received: from simba.msp.sc.ti.com ([172.24.194.179]) by dragon.ti.com (8.8.5) with ESMTP id NAA08126 for ; Fri, 6 Jun 1997 13:03:36 -0500 (CDT) Received: from monty.msp.sc.ti.com (monty.msp.sc.ti.com [172.24.194.150]) by simba.msp.sc.ti.com (8.6.12/8.6.10) with ESMTP id NAA26702 for ; Fri, 6 Jun 1997 13:04:57 -0500 From: Sri Jandhyala Received: (from srij@localhost) by monty.msp.sc.ti.com (8.6.12/8.6.10) id NAA13679 for ibis@vhdl.org; Fri, 6 Jun 1997 13:05:50 -0500 Date: Fri, 6 Jun 1997 13:05:50 -0500 Message-Id: <199706061805.NAA13679@monty.msp.sc.ti.com> To: ibis@vhdl.org Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: YGJ4nqYysjdcfJxfXFvLWQ== UNSUBSCRIBE From owner-ibis Fri Jun 6 12:31:19 1997 Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA23839 for ; Fri, 6 Jun 1997 12:30:45 -0700 (PDT) Received: by fishbowl02.emc.com; Fri, 6 Jun 97 15:28:54 -0400 Date: Fri, 6 Jun 97 15:24:03 EDT Message-ID: X-Priority: 3 (Normal) To: From: "fabrizio zanella" Subject: re: needed for IBIS V3.1 Hans, you say that IBIS models are easier to work with than HSPICE models. What tool do you use to run the IBIS models? I use HSPICE, it's an accurate tool and up until now 90% of the device models provided, ASICs and discrete transistors, have been in HSPICE format. Now some of our suppliers are starting to create IBIS models and a couple have said they are switching exclusively to IBIS format for all their future ASIC and transistor models. My question is, does anyone have a translator from IBIS to HSPICE or Berkeley or PSPICE format? If not, how have other SPICE users handled the problem of running IBIS models? Thank you, Fabrizio Zanella _/ _/ email: zanella_fabrizio@emc.com _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. 4645 _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 _/_/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ EMC Corporation _/_/_/_/ _/ _/ _/_/_/ 171 South Street Hopkinton, MA 01748-9103 ------------- Original Text From: Hans M Hilbig , on 6/6/97 11:31 AM: To: , "Steve Kaufer" Steve, I fully subscribe the statements of your msg about the example files. Having started with IBIS in my group early this year, we are still relativly new to IBIS and can remember well the pitfalls we were trapping into. We had two major reasons to generate IBIS models: Our customers like it and it's (still) relativly easy to construct and to tweak (compared to H-SPICE). Personally I'm concerned that IBIS will become so blown up in the future that the latter reason will go away. Adding more bells and whistles does not necessarily mean better 'accuracy', particularly if you don't have real (accurate) data to feed the bells and whistles. Pls remember that our customers want us to supply IBIS models early in the development stages, mostly at that time when the design (and its simulation) is not completed yet. The more estimates and judgements we add, the higher the chance that the model does not reflect the silicon that comes out later. Regards, Hans M Hilbig ************************************************************** EMSLP New Products Characterization Texas Instruments Freising Phone: +49-8161-804126 FAX:+49-8161-804909 e-mail: h-hilbig@ti.com ------------------ Original text From: Steve Kaufer , on 6/6/97 9:25 AM: Mini-topic for the upcoming IBIS Summit meeting at DAC: I believe it's important for V3.1 of the specification to include several simple, clear example files, e.g., a simple IC using a minimum of constructs, a more-complex IC using a few "extra" features like waveform tables, a network-packaged passive device, and a bus switch. Why? Because lacking these, the specification is so intimidating to newcomers that many are being scared off, to the detriment of the entire standard. Remember V1.x? It was a relatively quick, easily comprehended "read." What we have now is richer and more powerful, but also exponentially more confusing. Some of us on the committee are probably "velocitized" to the point where we're not aware of the problem's gravity. From recent conversations with IBIS "newbies" (and this includes semiconductor-vendor personnel, unfortunately), I think it works like this: 1. Reads IBIS spec (or part of it). 2. Wants to kill self. 3. Hears about Spice-to-IBIS, and thinks "that's my only hope!" 4. Then the real trouble begins... Personally, I'd like to see the opening page of the spec state clearly that about 85% of modeling applications can use about 25% of the specification's constructs, and point straight to the example models. Also good would be a designation of some kind delineating between "basic" and "luxury" constructs. I'd be interested in hearing opinions about this at the Summit... Regards, Steve Kaufer, HyperLynx From owner-ibis Fri Jun 6 13:51:28 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 NAA25062 for ; Fri, 6 Jun 1997 13:51:27 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.8.5/8.8.5) id NAA07049; Fri, 6 Jun 1997 13:50:35 -0700 (PDT) Message-Id: <3.0.32.19970606135040.006e4d54@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 06 Jun 1997 13:50:41 -0700 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Re: examples needed for IBIS V3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBISians, It seems we have found considerable common ground on this issue. The next question is who will contribute to effort. Syed mentioned simple models of many different technologies would be useful. e.g. Intel -> GTL model Xilinx -> basic CMOS model Syed -> RS232 model TI -> ABT model Bob Ross -> switch model Any takers? Step up to the plate and commit now while the ball is in motion. One model from each company will be a lot of models. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx Inc. kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Fri Jun 6 15:30:22 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 PAA26757 for ; Fri, 6 Jun 1997 15:30:21 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id PAA20133; Fri, 6 Jun 1997 15:27:24 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma019734; Fri, 6 Jun 97 15:26:55 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA24374 for ibis@vhdl.org; Fri, 6 Jun 97 15:28:52 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA16910; Fri, 6 Jun 97 15:32:41 PDT Date: Fri, 6 Jun 97 15:32:41 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9706062232.AA16910@rockie.nsc.com> To: ibis@vhdl.org, kellee@hyperlynx.com Subject: Re: examples needed for IBIS V3.1 Hi, Infact, I am right now working on doing my first RS-232 IBIS model which will be TYP model based on measurements. You should add a 'Differential' model to the list and I can pass one of National's too. Regards, Syed. > From owner-ibis@server.vhdl.org Fri Jun 6 15:18:14 1997 > X-Sender: kellee@mail.nwlink.com > X-Mailer: Windows Eudora Pro Version 3.0 (32) > Date: Fri, 06 Jun 1997 13:50:41 -0700 > To: ibis@vhdl.org > From: Kellee Crisafulli > Subject: Re: examples needed for IBIS V3.1 > Content-Type> : > text/plain> ; > charset="us-ascii"> > > Hi IBISians, > > It seems we have found considerable common ground on this issue. The > next question is who will contribute to effort. Syed mentioned simple models > of many different technologies would be useful. > > e.g. > Intel -> GTL model > Xilinx -> basic CMOS model > Syed -> RS232 model > TI -> ABT model > Bob Ross -> switch model > > Any takers? > Step up to the plate and commit now while the ball is in motion. > One model from each company will be a lot of models. > > > > > > > ------------------------------------------------------------------------- > Have a great day... > Kellee Crisafulli at HyperLynx Inc. > kellee@hyperlynx.com http://www.hyperlynx.com > ------------------------------------------------------------------------- > From owner-ibis Sat Jun 7 14:01:58 1997 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA19227 for ; Sat, 7 Jun 1997 14:01:57 -0700 (PDT) Received: from us8rmc.bb.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA03180; Sat, 7 Jun 1997 16:58:33 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA24053; Sat, 7 Jun 97 16:59:39 -0400 Message-Id: <9706072059.AA24053@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Sat, 7 Jun 97 16:59:53 EDT Date: Sat, 7 Jun 97 16:59:53 EDT From: Andy Ingraham To: ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org Subject: Re: examples needed for IBIS V3.1 D. C. Sessions wrote: > Just to be contrary, I'd think that it is better to have > several VERY simple examples rather than one complex one > where the (terrified) user has a hard time finding what > she needs. I whole-heartedly agree! We already have example fragments with all the keywords and many of the optional parameters, right in the IBIS spec document itself. What we need are plain and simple examples with only what's needed to get started. All the extra keywords and parameters come with experience and fine-tuning. There is/was an example file with the version 1.0 spec. In fact I think it's still there. Try this URL: ftp://ftp.vhdl.org/pub/ibis/ver1.0/n74f244n.ibs Some of the models in the ibis/models/ directory also might be worth using. Unfortunately, that directory seems to have fallen into disrepair these days.... Regards, Andy Ingraham From owner-ibis Mon Jun 9 00:02:03 1997 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id AAA22537 for ; Mon, 9 Jun 1997 00:02:02 -0700 (PDT) Received: from alfred.itg.ti.com ([192.168.43.15]) by dragon.ti.com (8.8.5) with ESMTP id CAA09639; Mon, 9 Jun 1997 02:00:21 -0500 (CDT) Received: from dfrs15.itg.ti.com (dfrs15.itg.ti.com [137.167.210.19]) by alfred.itg.ti.com (8.8.5/8.8.5) with SMTP id BAA12143; Mon, 9 Jun 1997 01:59:06 -0500 (CDT) Received: from ti (CNA0819696.business.tide.ti.com [137.167.202.100]) by dfrs15.itg.ti.com (TI SMTPMail MTA v1.0.9.3) with SMTP id QLGJCTAS; Mon, 9 Jun 1997 08:59:20 +0100 (W. Europe Daylight Time) X-Mailer: BeyondMail for Windows/Professional 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit To: "fabrizio zanella" , From: Hans M Hilbig Subject: re: needed for IBIS V3.1 Date: Mon, 9 Jun 1997 09:00:37 -0700 X-BeyondMail-Priority: 1 Message-Id: Conversation-Id: In-Reply-To: Reply-To: Hans M Hilbig X-Receipt-From-Agent: true Fabrizio, I'm comming from the bench measurement side, not from the Design or Simulation side. Thus it was easier for us to 'close the loop' with IBIS: take measurements of the device - generate the IBIS model - add the bench board parasitics - feed both into an IBIS simulator - and see how well this matches to what you have measured. On those parts where we didn't have silicon we used the SPICE outputs from our Designers, generated IBIS models and verified them by running the IBIS simulator with the known parasitics of the bench board added. Best regards, Hans ************************************************* EMSLP Characterization Texas Instruments Freising Phone: +49-8161-804126 FAX:+49-8161-804909 e-mail: h-hilbig@ti.com ------------------ Original text From: "fabrizio zanella" , on 6/6/97 3:24 PM: Hans, you say that IBIS models are easier to work with than HSPICE models. What tool do you use to run the IBIS models? I use HSPICE, it's an accurate tool and up until now 90% of the device models provided, ASICs and discrete transistors, have been in HSPICE format. Now some of our suppliers are starting to create IBIS models and a couple have said they are switching exclusively to IBIS format for all their future ASIC and transistor models. My question is, does anyone have a translator from IBIS to HSPICE or Berkeley or PSPICE format? If not, how have other SPICE users handled the problem of running IBIS models? Thank you, Fabrizio Zanella _/ _/ email: zanella_fabrizio@emc.com _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. 4645 _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 _/_/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ EMC Corporation _/_/_/_/ _/ _/ _/_/_/ 171 South Street Hopkinton, MA 01748-9103 ------------- Original Text From: Hans M Hilbig , on 6/6/97 11:31 AM: To: , "Steve Kaufer" Steve, I fully subscribe the statements of your msg about the example files. Having started with IBIS in my group early this year, we are still relativly new to IBIS and can remember well the pitfalls we were trapping into. We had two major reasons to generate IBIS models: Our customers like it and it's (still) relativly easy to construct and to tweak (compared to H-SPICE). Personally I'm concerned that IBIS will become so blown up in the future that the latter reason will go away. Adding more bells and whistles does not necessarily mean better 'accuracy', particularly if you don't have real (accurate) data to feed the bells and whistles. Pls remember that our customers want us to supply IBIS models early in the development stages, mostly at that time when the design (and its simulation) is not completed yet. The more estimates and judgements we add, the higher the chance that the model does not reflect the silicon that comes out later. Regards, Hans M Hilbig ************************************************************** EMSLP New Products Characterization Texas Instruments Freising Phone: +49-8161-804126 FAX:+49-8161-804909 e-mail: h-hilbig@ti.com ------------------ Original text From: Steve Kaufer , on 6/6/97 9:25 AM: Mini-topic for the upcoming IBIS Summit meeting at DAC: I believe it's important for V3.1 of the specification to include several simple, clear example files, e.g., a simple IC using a minimum of constructs, a more-complex IC using a few "extra" features like waveform tables, a network-packaged passive device, and a bus switch. Why? Because lacking these, the specification is so intimidating to newcomers that many are being scared off, to the detriment of the entire standard. Remember V1.x? It was a relatively quick, easily comprehended "read." What we have now is richer and more powerful, but also exponentially more confusing. Some of us on the committee are probably "velocitized" to the point where we're not aware of the problem's gravity. From recent conversations with IBIS "newbies" (and this includes semiconductor-vendor personnel, unfortunately), I think it works like this: 1. Reads IBIS spec (or part of it). 2. Wants to kill self. 3. Hears about Spice-to-IBIS, and thinks "that's my only hope!" 4. Then the real trouble begins... Personally, I'd like to see the opening page of the spec state clearly that about 85% of modeling applications can use about 25% of the specification's constructs, and point straight to the example models. Also good would be a designation of some kind delineating between "basic" and "luxury" constructs. I'd be interested in hearing opinions about this at the Summit... Regards, Steve Kaufer, HyperLynx From owner-ibis Mon Jun 9 07:05:59 1997 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA00197 for ; Mon, 9 Jun 1997 07:05:52 -0700 (PDT) Received: from us1rmc.bb.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA03129; Mon, 9 Jun 1997 09:48:32 -0400 (EDT) Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA20693; Mon, 9 Jun 97 09:47:19 -0400 Message-Id: <9706091347.AA20693@us1rmc.bb.dec.com> Received: from wrksys.enet; by us1rmc.enet; Mon, 9 Jun 97 09:48:42 EDT Date: Mon, 9 Jun 97 09:48:42 EDT From: Andy Ingraham To: ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org Subject: Re: IBIS PENDING VERSION 3.0 DOCUMENTS May I suggest clearly identifying any IBIS spec work-in-progress documents as being preliminary, within the document itself? I have maybe a dozen copies of the version 2.1 spec in my mailbox, including one that is identified as the "official, ratified IBIS 2.1 specification." They all differ from the three versions of "version 2.1" on vhdl.org (which ought to have been given different minor revision numbers ... but that's yet another matter). Please, put something RIGHT WITHIN THE DOCUMENT ITSELF, identifying it as an unapproved version, until it has actually been approved. I suggest adding the word "UNAPPROVED" to the second line, the one that identifies the spec version. Regards, Andy Ingraham From owner-ibis Mon Jun 9 08:45: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 IAA01931 for ; Mon, 9 Jun 1997 08:45:53 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 9 Jun 97 08:44 PDT Received: by chane.icx.com (/\==/\ Smail3.1.28.1 #28.16) id ; Mon, 9 Jun 97 08:44 PDT Received: by bob.icx.com via send-mail with stdio id for kellee@hyperlynx.com; Mon, 9 Jun 1997 08:44:46 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Mon, 9 Jun 1997 08:44:46 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, kellee@hyperlynx.com Subject: Re: examples needed for IBIS V3.1 Kellee: I also support doing this. We can discuss this at the next meeting. I would like to see a set of samples that we have reviewed stored under a "samples" subdirectory. Bob Ross Interconnectix > Date: Fri, 06 Jun 1997 13:50:41 -0700 > To: ibis@vhdl.org > From: Kellee Crisafulli > Subject: Re: examples needed for IBIS V3.1 > Hi IBISians, > It seems we have found considerable common ground on this issue. The > next question is who will contribute to effort. Syed mentioned simple models > of many different technologies would be useful. > e.g. > Intel -> GTL model > Xilinx -> basic CMOS model > Syed -> RS232 model > TI -> ABT model > Bob Ross -> switch model > Any takers? > Step up to the plate and commit now while the ball is in motion. > One model from each company will be a lot of models. > ------------------------------------------------------------------------- > Have a great day... > Kellee Crisafulli at HyperLynx Inc. > kellee@hyperlynx.com http://www.hyperlynx.com > ------------------------------------------------------------------------- From owner-ibis Mon Jun 9 09:10:03 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 JAA02283 for ; Mon, 9 Jun 1997 09:10:02 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 9 Jun 97 09:09 PDT Received: by chane.icx.com (/\==/\ Smail3.1.28.1 #28.16) id ; Mon, 9 Jun 97 09:08 PDT Received: by bob.icx.com via send-mail with stdio id for bob; Mon, 9 Jun 1997 09:08:57 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Mon, 9 Jun 1997 09:08:57 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, ingraham@wrksys.enet.dec.com Subject: Re: IBIS PENDING VERSION 3.0 DOCUMENTS Andy: This is my mistake. The ver3_0.ibs file has been updated in the wip directory that the document is UNOFFICIAL PENDING. Bob Ross Interconnectix > Date: Mon, 9 Jun 97 09:48:42 EDT > From: Andy Ingraham > To: ibis@vhdl.org > Cc: ingraham@wrksys.ENET.dec.com > Apparently-To: ibis@vhdl.org > Subject: Re: IBIS PENDING VERSION 3.0 DOCUMENTS > Status: RO > May I suggest clearly identifying any IBIS spec work-in-progress > documents as being preliminary, within the document itself? > I have maybe a dozen copies of the version 2.1 spec in my mailbox, > including one that is identified as the "official, ratified IBIS 2.1 > specification." They all differ from the three versions of > "version 2.1" on vhdl.org (which ought to have been given different > minor revision numbers ... but that's yet another matter). > Please, put something RIGHT WITHIN THE DOCUMENT ITSELF, identifying it > as an unapproved version, until it has actually been approved. > I suggest adding the word "UNAPPROVED" to the second line, the one > that identifies the spec version. > Regards, > Andy Ingraham From owner-ibis Mon Jun 9 09:13:23 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 JAA02433 for ; Mon, 9 Jun 1997 09:13:19 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 9 Jun 97 09:12 PDT Received: by chane.icx.com (/\==/\ Smail3.1.28.1 #28.16) id ; Mon, 9 Jun 97 09:12 PDT Received: by bob.icx.com via send-mail with stdio id for bob; Mon, 9 Jun 1997 09:12:18 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Mon, 9 Jun 1997 09:12:18 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD44 Interpretation of Min/Max/Weak/Strong Data To IBIS Committee: BIRD44 was just submitted by Andy Ingraham. This can also be discussed at the IBIS Summit Meeting. Bob Ross Interconnectix Buffer Issue Resolution Document (BIRD) BIRD ID#: 44 ISSUE TITLE: Interpretation of Min/Max/Weak/Strong data REQUESTOR: Andy Ingraham, Digital Equipment Corp. DATE SUBMITTED: June 8, 1997 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The wording in the IBIS spec doesn't clarify what "min" and "max" refer to, where those terms are used. For example, min temperature for the [Temperature Range] keyword refers to the temperature that causes minimum device strength, NOT to the minimum temperature. For a CMOS device, this is usually the maximum temperature within its operating range. This has caused IBIS models to be created incorrectly. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: Modify the [Temperature Range] keyword definition section. The old text is: |============================================================================== | Keyword: [Temperature Range] | Required: Yes, if other than the preferred 0, 50, 100 degree Celsius | range | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various V/I curves and ramp rates were | derived. |------------------------------------------------------------------------------ | variable typ min max [Temperature Range] 27.0 -50 130.0 | The new text is: |============================================================================== | Keyword: [Temperature Range] | Required: Yes, if other than the IBIS default values | Description: Defines the temperature range over which the model is | to operate. | Usage Rules: List the actual die temperatures (not percentages) in the | typ, slow/weak, fast/strong format. "NA" is allowed for | slow/weak and fast/strong only. | Other Notes: The [Temperature Range] keyword also describes the temperature | values over which the various V/I curves, ramp rates, and | waveforms were derived. | | The default temperatures are 0, 50, 100 degree Celsius, | where the slow/weak is 0 and the fast/strong is 100. | Thus, most CMOS devices will require the [Temperature | Range] keyword. |------------------------------------------------------------------------------ | variable typ slow/weak fast/strong [Temperature Range] 27.0 -50 130.0 | Modify the [Pulldown], [Pullup], [GND Clamp], and [POWER Clamp] keyword definition section, as follows. Old text: | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. New text: | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, slow/weak, and fast/strong current values. The four | entries, Voltage, I(typ), I(slow/weak), and I(fast/strong) | must be placed on a single line and must be separated by at | least one white space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If slow/weak | and/or fast/strong current values are not available, the | reserved word "NA" must be used. "NA" can be used for | currents in the typical column, but numeric values MUST be | specified for the first and last voltage points on any V/I | curve. Each V/I curve must have at least 2, but not more than | 100, voltage points. Old text: |------------------------------------------------------------------------------ [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | New text: |------------------------------------------------------------------------------ [Pulldown] | Voltage I(typ) I(slow/weak) I(fast/strong) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(slow/weak) I(fast/strong) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(slow/weak) I(fast/strong) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(slow/weak) I(fast/strong) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | Modify the [Ramp] keyword definition section, as follows: Old text: | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load subparameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ min max New text: | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the slow and fast values only. The R_load subparameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |------------------------------------------------------------------------------ [Ramp] | variable typ slow fast Modify the [Rising Waveform] and [Falling Waveform] keyword definition sections, as follows. Old text: | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. New text: | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, slow, and fast format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If slow or fast | waveform data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. Old text: | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. New text: | V_fixture defines the voltage for typ, slow, and fast | waveform conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | the slow and fast waveforms. Old text: |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | New text: |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(slow) V(fast) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(slow) V(fast) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | Modify the "NOTES ON DATA DERIVATION METHOD" as follows. Old text: | This section explains how data values are derived. It describes certain | assumed parameter and table extraction conditions if they are not | explicitly specified. It also describes the allocation of data into | the "typ", "min", and "max" columns under variations of voltage, | temperature, and process. | | The required "typ" column for all data represents typical operating | conditions. For most [Model] keyword data, the "min" column describes | slow, weak performance, and the "max" column describes the fast, strong | performance. It is permissible to use slow, weak devices or models to | derive the data for the "min" column, and to use fast, strong devices or | models to derive the data in the "max" columns under the corresponding | voltage and temperature derating conditions for these columns. It is also New text: | This section explains how data values are derived. It describes certain | assumed parameter and table extraction conditions if they are not | explicitly specified. It also describes the allocation of data into | the "typ", "min", "slow", "slow/weak", "max", "fast", and "fast/strong" | columns under variations of voltage, temperature, and process. | | The required "typ" column for all data represents typical operating | conditions. For most [Model] keyword data, the "min", "slow", or | "slow/weak" column describes slow, weak performance, and the "max", "fast", | or "fast/strong" column describes the fast, strong performance. It is | permissible to use slow, weak devices or models to derive the data for the | "min", "slow", or "slow/weak" column, and to use fast, strong devices or | models to derive the data in the "max", "fast", or "fast/strong" column | under the corresponding voltage and temperature derating conditions for | these columns. It is also Old text: | The voltage and temperature keywords and optionally the process models | control the conditions which define the "typ", "min", and "max" column | entries for all V/I table keywords [Pulldown], [Pullup], [Gnd Clamp], | and [Power Clamp]; all [Ramp] subparameters dV/dt_r and dV/dt_f; and | all waveform table keywords and subparameters [Rising Waveform], | [Falling Waveform], V_fixture, V_fixture_min, and V_fixture_max. New text: | The voltage and temperature keywords and optionally the process models | control the conditions which define the "typ", "slow", "slow/weak", "fast", | and "fast/strong" column entries for all V/I table keywords [Pulldown], | [Pullup], [Gnd Clamp], and [Power Clamp]; all [Ramp] subparameters dV/dt_r | and dV/dt_f; and all waveform table keywords and subparameters [Rising | Waveform], [Falling Waveform], V_fixture, V_fixture_min, and V_fixture_max. Old text: | The optional [Temperature] keyword will contain the temperature | which causes or amplifies the slow, weak conditions in the "min" column | and the temperature which causes or amplifies the fast, strong | conditions in the "max" column. Therefore, the "min" column for | [Temperature] will contain the lowest value for bipolar devices (TTL | and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. New text: | The optional [Temperature Range] keyword will contain the temperature | which causes or amplifies the slow, weak conditions in the "slow/weak" | column and the temperature which causes or amplifies the fast, strong | conditions in the "fast/strong" column. Therefore, the "slow/weak" column | for [Temperature Range] will contain the lowest value for bipolar devices | (TTL and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. Old text: | The default temperatures under which all V/I tables are extracted are | provided below. The same defaults also are stated for the [Ramp] | subparameters, but they also apply for the waveform keywords. New text: | The default temperatures under which all V/I tables, [Ramp] subparameters, | and waveform tables are extracted are provided below. Old text: | 1) V/I curves for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "X%" | max = maximum voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "X%" | max = maximum voltage, max temp deg C, typical process, plus "X%" New text: | 1) V/I curves for CMOS devices: | typ = typical voltage, nominal temp deg C, typical process | slow/weak = min voltage, max temp deg C, typical process, minus "X%" | fast/strong = max voltage, min temp deg C, typical process, plus "X%" | | V/I curves for bipolar devices: | typ = typical voltage, nominal temp deg C, typical process | slow/weak = min voltage, min temp deg C, typical process, minus "X%" | fast/strong = max voltage, max temp deg C, typical process, plus "X%" Old text: | e. Typ, Min, and Max must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, max temp deg C, typical process, minus "Y%" | max = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, typical temp deg C, typical process | min = minimum voltage, min temp deg C, typical process, minus "Y%" | max = maximum voltage, max temp deg C, typical process, plus "Y%" New text: | e. Typ, Slow, and Fast must all be posted, and are derived at the same | extremes as the V/I curves, which are: | | Ramp rates for CMOS devices: | typ = typical voltage, nominal temp deg C, typical process | slow = minimum voltage, max temp deg C, typical process, minus "Y%" | fast = maximum voltage, min temp deg C, typical process, plus "Y%" | | Ramp rates for bipolar devices: | typ = typical voltage, nominal temp deg C, typical process | slow = minimum voltage, min temp deg C, typical process, minus "Y%" | fast = maximum voltage, max temp deg C, typical process, plus "Y%" ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: These changes do not affect the IBIS spec itself. There are no new or modified keywords or subparameters. Only the explanatory portions are modified. The problem with the existing wording is that it doesn't describe what is meant by "min" or "max" at the place where they are used in the spec. This leads to confusion and misinterpretation, because the customary meaning of "min", when speaking of temperatures, currents, or voltages, is the minimum temperature, current, or voltage. This is generally not what is meant by the IBIS spec, as borne out by the explanatory notes added to the back of the spec. These definitions belong up-front, not tucked away in the back. The changes proposed here are meant to make it obvious when the "min" or "max" data should refer to "slow" or "fast" devices, as opposed to "min" or "max" of the data being listed. It is a move toward making it possible for anyone to pick up the spec, read one section, and understand it correctly, without having to read the whole thing through and cross-reference items that you thought were obvious but aren't, and are not defined until you reach the end of the spec. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: This is partly inspired by my making someone from another company correct their IBIS model. ******************************************************************************* From owner-ibis Mon Jun 9 09:27:10 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA02605 for ; Mon, 9 Jun 1997 09:27:10 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id JAA16721 for ; Mon, 9 Jun 1997 09:26:03 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id JAA13987; Mon, 9 Jun 1997 09:26:19 -0700 (PDT) Message-Id: <199706091626.JAA13987@ichips.intel.com> To: ibis@vhdl.org Subject: Example Models Date: Mon, 09 Jun 1997 09:26:18 -0700 From: Stephen Peters Hello All: In the quest for an examplet model -- does anyone have one? I do remember that the parser came with an example 74x04 hex inverter example, but I can't locate it. If anyone has an example of a 'simple' component using the basic keywords please pass it along to sjpeters@ichips.intel.com Thanks, Stephen Peters Intel Corp From owner-ibis Mon Jun 9 10:03:22 1997 Received: from atlantis.erlm.siemens.de (atlantis.erlm.siemens.de [194.174.230.11]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA03169 for ; Mon, 9 Jun 1997 10:03:21 -0700 (PDT) Received: from tcenter.erlm.siemens.de (tcenter.erlm.siemens.de [193.25.63.21]) by atlantis.erlm.siemens.de (8.7.5/8.7.3) with ESMTP id TAA01067; Mon, 9 Jun 1997 19:01:54 +0200 (MET DST) Received: from PGTD0131 (pgtd0131.a45am.erlm.siemens.de [139.25.24.49]) by tcenter.erlm.siemens.de (8.7.5/8.7.3) with SMTP id SAA09138; Mon, 9 Jun 1997 18:57:41 +0200 (MET DST) Received: by PGTD0131 with Microsoft Mail id <01BC7507.5071FE00@PGTD0131>; Mon, 9 Jun 1997 18:59:53 +-200 Message-ID: <01BC7507.5071FE00@PGTD0131> From: Unger Bernhard To: "'fabrizio zanella'" Cc: "'ibis@vhdl.org'" Subject: AW: needed for IBIS V3.1 Date: Mon, 9 Jun 1997 18:59:51 +-200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.vhdl.org id KAA03170 Fabrizio, we have developed an IBIS to HSPICE converter to generate HSPICE behavioral models. The bases are IBIS 2.1 models. The static and dynamic driver characteristics fit very well with the transistor based HSPICE simulations. Best regards Bernhard ************************************************************************************ # Dr. Bernhard Unger # Siemens AG # Dept. ANL A45 AM # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 # D-81730 Munich Fax. +49-89-636-44595 # Germany E-Mail Bernhard.Unger@erlm.siemens.de ************************************************************************************ ---------- Von: fabrizio zanella[SMTP:fabrizio=zanella%Eng%EMCHOP1@fishbowl02.lss.emc.com] Gesendet: Freitag, 6. Juni 1997 21:24 An: ibis@vhdl.org Betreff: re: needed for IBIS V3.1 Hans, you say that IBIS models are easier to work with than HSPICE models. What tool do you use to run the IBIS models? I use HSPICE, it's an accurate tool and up until now 90% of the device models provided, ASICs and discrete transistors, have been in HSPICE format. Now some of our suppliers are starting to create IBIS models and a couple have said they are switching exclusively to IBIS format for all their future ASIC and transistor models. My question is, does anyone have a translator from IBIS to HSPICE or Berkeley or PSPICE format? If not, how have other SPICE users handled the problem of running IBIS models? Thank you, Fabrizio Zanella _/ _/ email: zanella_fabrizio@emc.com _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. 4645 _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 _/_/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ EMC Corporation _/_/_/_/ _/ _/ _/_/_/ 171 South Street Hopkinton, MA 01748-9103 ------------- Original Text From: Hans M Hilbig , on 6/6/97 11:31 AM: To: , "Steve Kaufer" Steve, I fully subscribe the statements of your msg about the example files. Having started with IBIS in my group early this year, we are still relativly new to IBIS and can remember well the pitfalls we were trapping into. We had two major reasons to generate IBIS models: Our customers like it and it's (still) relativly easy to construct and to tweak (compared to H-SPICE). Personally I'm concerned that IBIS will become so blown up in the future that the latter reason will go away. Adding more bells and whistles does not necessarily mean better 'accuracy', particularly if you don't have real (accurate) data to feed the bells and whistles. Pls remember that our customers want us to supply IBIS models early in the development stages, mostly at that time when the design (and its simulation) is not completed yet. The more estimates and judgements we add, the higher the chance that the model does not reflect the silicon that comes out later. Regards, Hans M Hilbig ************************************************************** EMSLP New Products Characterization Texas Instruments Freising Phone: +49-8161-804126 FAX:+49-8161-804909 e-mail: h-hilbig@ti.com ------------------ Original text From: Steve Kaufer , on 6/6/97 9:25 AM: Mini-topic for the upcoming IBIS Summit meeting at DAC: I believe it's important for V3.1 of the specification to include several simple, clear example files, e.g., a simple IC using a minimum of constructs, a more-complex IC using a few "extra" features like waveform tables, a network-packaged passive device, and a bus switch. Why? Because lacking these, the specification is so intimidating to newcomers that many are being scared off, to the detriment of the entire standard. Remember V1.x? It was a relatively quick, easily comprehended "read." What we have now is richer and more powerful, but also exponentially more confusing. Some of us on the committee are probably "velocitized" to the point where we're not aware of the problem's gravity. >From recent conversations with IBIS "newbies" (and this includes semiconductor-vendor personnel, unfortunately), I think it works like this: 1. Reads IBIS spec (or part of it). 2. Wants to kill self. 3. Hears about Spice-to-IBIS, and thinks "that's my only hope!" 4. Then the real trouble begins... Personally, I'd like to see the opening page of the spec state clearly that about 85% of modeling applications can use about 25% of the specification's constructs, and point straight to the example models. Also good would be a designation of some kind delineating between "basic" and "luxury" constructs. I'd be interested in hearing opinions about this at the Summit... Regards, Steve Kaufer, HyperLynx From owner-ibis Mon Jun 9 11:15:54 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 LAA04340 for ; Mon, 9 Jun 1997 11:15:53 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.8.5/8.8.5) id LAA27032; Mon, 9 Jun 1997 11:13:46 -0700 (PDT) Message-Id: <3.0.32.19970609111344.00744c40@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 09 Jun 1997 11:13:45 -0700 To: ibis@vhdl.org, sjpeters@ichips.intel.com, Stevek@hyperlynx.com From: Kellee Crisafulli Subject: Re: Example Models Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi All, At 09:26 AM 6/9/97 -0700, you wrote: > In the quest for an examplet model -- does anyone have one? I do >remember that the parser came with an example 74x04 hex inverter >example, but I can't locate it. HyperLynx will sign up for this one. We will make a 74HC04 DIP model for delivery by the middle of next week. I would do it sooner but everyone is busy with DAC releated items. Who will sign up for a GTL model and an RS232 model and a .... with a deliver date? ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx Inc. kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Mon Jun 9 11:33:50 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 LAA04666 for ; Mon, 9 Jun 1997 11:33:50 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA08749; Mon, 9 Jun 1997 11:30:22 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma008455; Mon, 9 Jun 97 11:30:04 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA22045 for fabrizio=zanella%Eng%EMCHOP1@fishbowl02.lss.emc.com; Mon, 9 Jun 97 11:32:11 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA03454; Mon, 9 Jun 97 11:36:03 PDT Date: Mon, 9 Jun 97 11:36:03 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9706091836.AA03454@rockie.nsc.com> To: fabrizio=zanella%Eng%EMCHOP1@fishbowl02.lss.emc.com, Bernhard.Unger@erlm.siemens.de Subject: Re: IBIS to HSPICE Cc: ibis@vhdl.org Bernhard, Do you consider this translation utility proprietary or can this be used by the IBIS community as a shareware ? Regards, Syed National Semiconductor Corp. > From owner-ibis@server.vhdl.org Mon Jun 9 11:26:15 1997 > From: Unger Bernhard > To: "'fabrizio zanella'" > > Cc: "'ibis@vhdl.org'" > Subject: AW: needed for IBIS V3.1 > Date: Mon, 9 Jun 1997 18:59:51 +-200 > Content-Type> : > text/plain> ; > charset="us-ascii"> > Content-Transfer-Encoding: quoted-printable > > Fabrizio, > we have developed an IBIS to HSPICE converter to generate HSPICE = > behavioral models. > The bases are IBIS 2.1 models. The static and dynamic driver = > characteristics fit very well > with the transistor based HSPICE simulations. > > Best regards > Bernhard > > *************************************************************************= > *********** > # Dr. Bernhard Unger = > =20 > # Siemens AG = > =20 > # Dept. ANL A45 AM = > =20 > # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 = > =20 > # D-81730 Munich Fax. +49-89-636-44595 = > =20 > # Germany E-Mail = > Bernhard.Unger@erlm.siemens.de = > =20 > *************************************************************************= From owner-ibis Mon Jun 9 12:06:20 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA05232 for ; Mon, 9 Jun 1997 12:06:19 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id MAA20745 for ; Mon, 9 Jun 1997 12:05:12 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id MAA02458; Mon, 9 Jun 1997 12:05:28 -0700 (PDT) Message-Id: <199706091905.MAA02458@ichips.intel.com> To: ibis@vhdl.org Subject: Re: Example Models Date: Mon, 09 Jun 1997 12:05:28 -0700 From: Stephen Peters Hello Kellie: Thank you very much for the '04 model! Seeing as how I have been dealing the GTL models, I can probably supply a model showing the use of the V/T waveform and open-drain constructs. It would also be good to show a PCI driver that includes different references for pullup and clamps. Stephen Hi All, At 09:26 AM 6/9/97 -0700, you wrote: > In the quest for an examplet model -- does anyone have one? I do >remember that the parser came with an example 74x04 hex inverter >example, but I can't locate it. HyperLynx will sign up for this one. We will make a 74HC04 DIP model for delivery by the middle of next week. I would do it sooner but everyone is busy with DAC releated items. Who will sign up for a GTL model and an RS232 model and a .... with a deliver date? ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx Inc. kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Wed Jun 11 03:34:51 1997 Received: from atlantis.erlm.siemens.de (atlantis.erlm.siemens.de [194.174.230.11]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id DAA15721 for ; Wed, 11 Jun 1997 03:34:50 -0700 (PDT) Received: from tcenter.erlm.siemens.de (tcenter.erlm.siemens.de [193.25.63.21]) by atlantis.erlm.siemens.de (8.7.5/8.7.3) with ESMTP id MAA15183; Wed, 11 Jun 1997 12:33:34 +0200 (MET DST) Received: from PGTD0131 (pgtd0131.a45am.erlm.siemens.de [139.25.24.49]) by tcenter.erlm.siemens.de (8.7.5/8.7.3) with SMTP id MAA16193; Wed, 11 Jun 1997 12:29:17 +0200 (MET DST) Received: by PGTD0131 with Microsoft Mail id <01BC7663.634C0EA0@PGTD0131>; Wed, 11 Jun 1997 12:31:29 +-200 Message-ID: <01BC7663.634C0EA0@PGTD0131> From: Unger Bernhard To: "'Syed Huq'" Cc: "'ibis@vhdl.org'" Subject: AW: IBIS to HSPICE Date: Wed, 11 Jun 1997 12:31:27 +-200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.vhdl.org id DAA15722 Syed, we have developed the IBIS to HSPICE converter for internal use only. We are part of Siemens ANL Technical Services for Information Technology organization provideing EMC services for Siemens internal and external use. Presently we are discussing models on how to distribute the conversion utility among potential users or alternatively to provide support for conversion. If there is a need for somebody to convert his IBIS models to HSPICE behavioral models we can provide this service on request. So we encourage everyone to establish contact to us to find a suitable solution ( see address below ). Regards, Bernhard ************************************************************************************ # Dr. Bernhard Unger # Siemens AG # Dept. ANL A45 AM # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 # D-81730 Munich Fax. +49-89-636-44595 # Germany E-Mail Bernhard.Unger@erlm.siemens.de ************************************************************************************ ---------- Von: Syed Huq[SMTP:huq@rockie.nsc.com] Gesendet: Montag, 9. Juni 1997 20:36 An: fabrizio=zanella%Eng%EMCHOP1@fishbowl02.lss.emc.com; Bernhard.Unger@erlm.siemens.de Cc: ibis@vhdl.org Betreff: Re: IBIS to HSPICE Bernhard, Do you consider this translation utility proprietary or can this be used by the IBIS community as a shareware ? Regards, Syed National Semiconductor Corp. > From owner-ibis@server.vhdl.org Mon Jun 9 11:26:15 1997 > From: Unger Bernhard > To: "'fabrizio zanella'" > > Cc: "'ibis@vhdl.org'" > Subject: AW: needed for IBIS V3.1 > Date: Mon, 9 Jun 1997 18:59:51 +-200 > Content-Type> : > text/plain> ; > charset="us-ascii"> > Content-Transfer-Encoding: quoted-printable > > Fabrizio, > we have developed an IBIS to HSPICE converter to generate HSPICE = > behavioral models. > The bases are IBIS 2.1 models. The static and dynamic driver = > characteristics fit very well > with the transistor based HSPICE simulations. > > Best regards > Bernhard > > *************************************************************************= > *********** > # Dr. Bernhard Unger = > =20 > # Siemens AG = > =20 > # Dept. ANL A45 AM = > =20 > # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 = > =20 > # D-81730 Munich Fax. +49-89-636-44595 = > =20 > # Germany E-Mail = > Bernhard.Unger@erlm.siemens.de = > =20 > *************************************************************************= From owner-ibis Wed Jun 11 05:20:37 1997 Received: from atlantis.erlm.siemens.de (atlantis.erlm.siemens.de [194.174.230.11]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id FAA17412 for ; Wed, 11 Jun 1997 05:20:35 -0700 (PDT) Received: from tcenter.erlm.siemens.de (tcenter.erlm.siemens.de [193.25.63.21]) by atlantis.erlm.siemens.de (8.7.5/8.7.3) with ESMTP id OAA18535; Wed, 11 Jun 1997 14:19:12 +0200 (MET DST) Received: from PGTD0131 (pgtd0131.a45am.erlm.siemens.de [139.25.24.49]) by tcenter.erlm.siemens.de (8.7.5/8.7.3) with SMTP id OAA26605; Wed, 11 Jun 1997 14:14:53 +0200 (MET DST) Received: by PGTD0131 with Microsoft Mail id <01BC7672.239BE5A0@PGTD0131>; Wed, 11 Jun 1997 14:17:05 +-200 Message-ID: <01BC7672.239BE5A0@PGTD0131> From: Unger Bernhard To: "'D. C. Sessions'" Cc: "'ibis@vhdl.org'" Subject: AW: AW: IBIS to HSPICE converter Date: Wed, 11 Jun 1997 14:17:03 +-200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.vhdl.org id FAA17414 You have asked for more informations about the IBIS to HSPICE converter. Here they are: The converter itself consists on some linked unix shell scripts. Starting the converter you have to name the IBIS file, the pin number you want to generate the HSPICE behavioral model and the name of the generated behavioral model. If there are more than one rising/falling waveforms the converter asks you, which of them you want to select. After finishing the conversion a first HSPLOT window opens showing you a comparison of the static output characteristics of transistor and behavioral level based simulations. Going on a second HSPLOT window opens showing the comparison of the dynamic output characteristics. Presently the converter can not handle ECL and Open Collector outputs. But I see no principle problems to implement these features. The behavioral model itself is a parametrisized model. That means, there is no input. Pulse width, period, delay, initial state and in case of bidirectional pins enable active/inactive are controlled by .PARAM statements. Regards, Bernhard ************************************************************************************ # Dr. Bernhard Unger # Siemens AG # Dept. ANL A45 AM # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 # D-81730 Munich Fax. +49-89-636-44595 # Germany E-Mail Bernhard.Unger@erlm.siemens.de ************************************************************************************ ---------- Von: D. C. Sessions[SMTP:dc.sessions@tempe.vlsi.com] Gesendet: Montag, 9. Juni 1997 19:52 An: Unger Bernhard Betreff: Re: AW: needed for IBIS V3.1 Unger Bernhard wrote: > > Fabrizio, > we have developed an IBIS to HSPICE converter to generate HSPICE behavioral models. > The bases are IBIS 2.1 models. The static and dynamic driver characteristics fit very well > with the transistor based HSPICE simulations. More, bitte? -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Fri Jun 13 17:28:40 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 RAA19361 for ; Fri, 13 Jun 1997 17:28:33 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 13 Jun 97 17:27 PDT Received: by chane.icx.com (/\==/\ Smail3.1.28.1 #28.16) id ; Fri, 13 Jun 97 17:27 PDT Received: by bob.icx.com via send-mail with stdio id for bob; Fri, 13 Jun 1997 17:27:33 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 13 Jun 1997 17:27:33 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD41.8 Modelling Series Switchable Devices IBIS Committee: BIRD41.8 is a modification of BIRD41.7 which was approved by the IBIS Open Forum Summit meeting on June 12, 1997 with the following changes. Keyword nomenclature change: [R_series], [L_series], [R_l_series], [C_series], [R_c_series], [L_c_series] to [R Series], [L Series], [Rl Series], [C Series], [Rc Series], [Lc Series] This is a style change so that only one space/dash is needed. Also under [Model], first paragraph, two additional references to [Pin] are changed to [Pin] or/and [Series Pin Mapping]. This is to document that the [Model] keyword also handles models refererenced under both the [Pin] and [Series Pin Mapping] keywords. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 41.8 ISSUE TITLE: Modelling Series Switchable Devices REQUESTER: John Fitzpatrick, Alcatel, Bob Ross, Interconnectix DATE SUBMITTED: 2/12/97, 2/17/97, 5/14/97, 5/15/97, 5/16/97, 5/22/97, 5/28/97, 5/30/97, 6/12/97 DATE ACCEPTED BY IBIS OPEN FORUM: June 12, 1997 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: IBIS cannot model series devices. IBIS cannot model switches. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords are defined under [Component]: [Series Switch Groups] [Series Pin Mapping] Two new keywords are defined under [Model] by IV characteristics: [Series Current] [Series MOSFET] RLC series paths can be defined under [Model] with: [R Series], [L Series], [Rl Series], [C Series], [Rc Series], [Lc Series] Two additional Model_type subparameter values are allowed under the [Model] keyword: Series, Series_switch Two new keywords are defined under [Model] keyword so that the two electrical states of Series_switch models can be described: [On] [Off] Other changes are made in other sections that relate to these additions. Add the following text somewhere after the [Component] keyword: |============================================================================== | Keyword: [Series Switch Groups] | Required: No | Description: Used to define allowable switching combinations of series | switches described using the names of the groups in the | [Series Pin Mapping] keyword function_table_group column | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A typical | state line will start with 'On' followed by all of the on-state | group names or an 'Off' followed by all of the off-state | group names. Only one of 'On' or 'Off' is required since the | undefined states are presumed to be opposite of the explicitly | defined states. The state line is terminated with the slash | '/', even if it extends over several lines to fit within the 80 | character column width restriction. | | The group names in the function_table_group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |------------------------------------------------------------------------------ [Series Switch Groups] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 / On 1 2 4 / On 1 3 4 / On 2 3 4 / | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | On 5 / | Crossbar switch straight thru connection On 6 / | Crossbar cross over connection Off 5 6 / | Crossbar open switches | |============================================================================== | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series device. | Sub-Params: pin_2, model_name, function_table_group | Usage Rules: Enter only series pin pairs. The first column, [Series Pin | Mapping], contains the series pin for which input impedances | are measured. The second column, pin_2, contains the other | connection of the series model. Each pin must match the | pin numbers declared previously in the [Pin] section of the | IBIS file. The third column, model_name, associates the | Series or Series_switch model for the pair of pins in the | first two columns. The fourth column, function_table_group, | contains an alphanumeric designator string to associate those | sets of of Series_switch pins that are switched together. | | Each line must contain either three or four columns. When | using four columns, the header function_table_group must be | listed. | | One possible application is to model crossbar switches where | the straight through On paths are indicated by one designator | and the cross over On paths are indicated by another | designator. If the model referenced is a Series model, then | the function_table_group entry is omitted. | | Column length limits are: | [Series Pin Mapping] 5 characters max | pin_2 5 characters max | model_name 20 characters max | function_table_group 20 characters max | | Other Notes: If the model_name is for a non-symmetrical series device, | then the order of the pins is important. The [Series Pin | Mapping] and pin_2 entries must be in the columns that | correspond with Pin 1 and Pin 2 of the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any other elements such as additional | capacitance or clamping circuitry are defined by the | model_name that is referenced in the [Pin] keyword. The | model_names under the [Pin] keyword that are also referenced | by the [Series Pin Mapping] keyword must be either 'NC' or | reference a [Model] whose Model_type is 'Terminator'. Thus. | for example, a Series_switch model may contain Terminator | models on EACH of the pins to describe both the capacitance | on each pin and some clamping circuitry that may exist on | each pin. | |------------------------------------------------------------------------------ [Series Pin Mapping] pin_2 model_name function_table_group | 2 3 CBTSeries 1 | Four independent groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight through path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross over path 25 23 CBTSeries 6 | 32 33 Fixed_series | No group needed Under the [Model] keyword, first paragraph of 'Usage Rule:', change the references to [Pin] keyword to [Pin] and/or [Series Pin Mapping] keyword(s)" as shown: | Usage Rules: Each model type must begin with the keyword [Model]. | The model name must match the one that is listed under | the [Pin] or [Series Pin Mapping] keyword and must not | contain more than 20 characters. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] and [Series Pin | Mapping] keywords, except | for those model names that use reserved words (POWER, GND and | NC). Model names with reserved words are an exception and they | do not have to have a corresponding [Model] keyword. | Under the [Model] keyword, change existing text from: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | to: | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, Terminator, Series, and | Series_switch. | Add text to the special usage rules: | | Series This model type is for series devices | which can be described by [R Series], | [L Series], [Rl Series], [C Series], | [Lc Series], [Rc Series], [Series | Current] or [Series MOSFET] keywords | | Series_switch This model type is for series switch | devices which can described by [On], | [Off], [R Series], [L Series], | [Rl Series], [C Series], [Lc Series], | [Rc Series], [Series Current] and | [Series MOSFET] keywords Add the following text after the [Rgnd] keyword: |============================================================================== | Keyword: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off'state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | use the [On] and [Off] keywords. | | In Series_switch models, [On] or [Off] must be positioned | before any of the [R Series], [L Series], [Rl Series], | [C Series], [Lc Series], [Rc Series], [Series Current], | and [Series MOSFET} keywords. There is no provision for | any of these keywords to be defined once, but to apply to | both states. |------------------------------------------------------------------------------ [On] | ... On state keywords such as [R Series], [Series Current], | ... [Series MOSFET] [Off] | ... Off state keywords such as [R Series], [Series Current] |============================================================================== | Keywords: [R Series], [L Series], [Rl Series], [C Series]. [Lc Series], | [Rc Series] | Required: Yes, if they exist in the device | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the typical, | minimum, and maximum resistance values. The three entries must | be placed on a single line and must be separated by at least | one white space or tab character. All three columns are | required under these keywords. However, data is only required | in the typical column. If minimum and/or maximum values are | not available, the reserved word "NA" must be used. | Other Notes: This series RLC model is defined to allow IBIS to model | simple passive devices and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R Series | +---/\/\/\/\--------------------+ | | | | Pin 1 | L Series Rl Series | Pin 2 | <---+---@@@@@@@@-/\/\/\/\-----------+---> | | | | | | | | | +---| |--@@@@@@@@@---/\/\/\/\---+ | | | Lc Series Rc Series | C Series | | [Rl Series] shall be defined only if [L Series] exists. | [Rl Series] is 0 ohms if it is not defined in the path. | | [Rc Series] and [Lc Series] shall be defined only if | [C Series] exists. [Rc Series] is 0 ohms if it is not | defined in the path. [Lc Series] is 0 henries if it is | not defined in the path. | | C_comp values are ignored for these keywords. |------------------------------------------------------------------------------ | variable R(typ) R(min) R(max) [R Series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L Series] 5nH NA NA | variable R(typ) R(min) R(max) [Rl Series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C Series] 50pF NA NA | are 0 impedance | |============================================================================== | Keyword: [Series Current] | Required: Yes, if they exist in the device | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | columns [Series Pin Mapping] and pin_2, respectively. | Usage Rules: The first column contains the voltage value, and the | remaining columns hold the typical, minimum, and maximum | current values. The four entries, Voltage, I(typ), I(min), | and I(max) must be placed on a single line and must be | separated by at least one white space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | | Other Notes: There is no monotonicity requirement. However the model | supplier should realise that it may not be possible to derive | a behavioral model from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | | C_comp values are ignored for [Series Current] models. |------------------------------------------------------------------------------ [Series Current] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m |============================================================================== | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the V/I curves for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | [Series Pin Mapping] and pin_2 columns, respectively. | Sub-Params: Vds | Usage Rules: The first column contains the voltage value, and the three | remaining columns hold the typical, minimum, and maximum | current values. The four entries, Voltage, I(typ), I(min), | and I(max) must be placed on a single line and must be | separated by at least one white space or tab character. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | | Other Notes: There is no monotonicity requirement. However the model | supplier should realise that it may not be possible to derive | a behavioral model from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings provide the assumed gate voltages. | If the [POWER Clamp Reference] exists, it overrides the | [Voltage Range] value. The table entries are actually the | Vgs values referenced to the power rail. The polarity | conventions are identical with those used for other tables that | are referenced to power rails. Thus the voltage column can | be viewed as a table defining the source voltages Vs according | to the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd => Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the device with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow both in directions, as | would occur due to refections when the switch is connected | in series with an unterminated transmission line. | | The model data is used to create an On state relationship | between the actual drain to source current, ids, and the | actual drain to source voltage, vds: | | ids = f(vds). | | This functional relationship depends on the actual source | voltage Vs and can be expressed in terms of the corresponding | table currents associated with Vs (and expressed as a function | of Vgs). | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be linearly related to the table drain to source current, | Ids, for the given Vds subparameter value and located at the | existing gate to source voltage value Vgs. This table current | is denoted as Ids(Vgs, Vds). The functional relationship | becomes: | | ids = Ids(Vgs, Vds) * vds / Vds. | | More than one [Series MOSFET] table is permitted, but it is | simulator dependent how the data will be used. | | C_comp values are ignored for [Series MOSFET] models. |------------------------------------------------------------------------------ [On] [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) | 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================== In the [Model Selector] keyword associated with approved BIRD30.2, change the first paragraph of 'Usage Rules:' as follows so that each occurance of [Pin] keyword is changed to [Pin] and/or [Series Pin Mapping] keyword(s) as shown: | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Model]s must be unique and can be listed under the | [Model selector] keyword and/or pin list. The name of the | [Model selector] keyword must match the corresponding model | name listed under the [Pin] or [Series Pin Mapping] keyword | and must not contain more | than 20 characters. A .ibs file must contain enough [Model | selector] keywords to cover all of the model selector names | specified under the [Pin] and [Series Pin Mapping] keywords. | In the NOTES ON DATA DERIVATION METHOD add to the table in section 2) two lines so that the first part of section 2) reads: | 2) Voltage Ranges: | Points for each curve must span the voltages listed below: | | Curve Low Voltage High Voltage | ----------- ----------- ------------ | [Pulldown] GND - POWER POWER + POWER | [Pullup] GND - POWER POWER + POWER | [GND Clamp] GND - POWER GND + POWER | [POWER Clamp] POWER POWER + POWER | [Series Current] GND - POWER GND + POWER | [Series MOSFET] GND GND + POWER | In the NOTES ON DATA DERIVATION METHOD, section 5) is added: | 5) Series MOSFET Table Extractions: | An extraction circuit is set up according to the figure below. The | switch is configured into the 'On' state. This assumes that the Vcc | voltage will be applied to the gate by internal logic. Designate one | pin of the switch as the source node, and the other pin as the drain | node. The Table Currents designated as Ids are derived directly as a | function of the Vs voltage at the source node as Vs is varied from 0 | to Vcc. This voltage is entered as a Vgs value as a consequence of | the relationship Vtable = Vgs = Vcc - Vs. Vds is held constant by | having a fixed voltage Vds between the drain and source nodes. Note, | Vds > 0 V. The current flowing into the drain is tabulated in the table | for the corresponding Vs points. | | | +----------------------------------------+ | | | | | Ids = Table Current | | | ---> | | +---<---| |--->----------+ | | d |_____| - s | + | | --+-- Vgs +---+---+ +----+----+ | | g + | Sweep | | Vs + | | | Vs | |Fixed Vds| | +---+---+ +----+----+ | | - | | GND GND | | Example of Series MOSFET Table Extraction | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDS 41 and 41.1: Bus-switches (ex: 74LVX3L383 from NS or 74CBT3383 from TI) are increasingly being used on high-speed boards. They cannot be modelled by IBIS 2.1. This BIRD allows the definition of a series device which is connected between any two pins. If this device is a non-linear resistor (e.g. a diode), then it can be described by an I/V table. One approach suggested was to force one of the pins to Vcc or ground, and then reuse the [Pullup] and [Pulldown] tables. This approach will not correctly model bus-switches. So instead, a new keword [Series_Impedance] is defined. This has a R_load keyword. For bus-switches, R_load should be set to a value >> 5ohms in order to allow the Ron vs. bias voltage (as given in application notes) curves be obtained. The author would like to suggest an extra keyword [Impedance] to "replace", or provide an alternative, to the pullup, pulldown, etc. This keyword would have a mode subparameter, with values Pullup, Pulldown and Hi-state. This would allow 3 sets of measurements be included in the IBIS file, without any fiddly subtaracting of curves, or confusing Vcc relativity. As suggested by Chris Reid, a state entry is added to allow crossbar switches be modelled. It is expected that the simulator detect these states, then ask the user to choose one of them. Is this information really in the right place?? Often a bus-switch is used to provide 3.3V to 5V translation. If this is to be modelled in IBIS, then a second model must be generated for Vcc=4.3V. Use the [Model selector] keyword to allow the correct buffer be chosen. Additional series RLC paths are defined in this BIRD. An alternative solution would be to allow an arbitrary path be defined, similar to Bird 36.1 prior to the amputation of connector support. BIRD41.2: The RLC proposal is retained. The [Series Impedance] proposal is split into [Series Current] and [Series MOSFET]. The [Series Current] represents a simple V/I relationship ACROSS the series element and would be suitable for a series diode model. This model is sensitive to the actual pin assignment polarity. The [Series MOSFET] model representative of series switches needs some tables which are specific to this device in order to provide consistency within the IBIS architecture. The tables need to be made relative to the positive voltage rail. One or more tables need to be provided under precisely defined conditions. The [Series MOSFET] model is assumed to be symmetrical and not dependent on the which side "Pin 1" and "Pin 2" are designated. These individual considerations justify providing two separate keywords. [On] and [Off] keywords are added under [Model] and are used when the Model_type is Series_switch. This ensures that the model function is clearly indicated by the Model_type subparameter, and the electrical characteristics of the 'On' and 'Off' states are clearly indicated within the model. It might be argued that the Series_switch Model_type is already redundant, but it may be necessary so that the Series_switch information is properly stored. Under [Component], a [Series Pin Mapping] is defined to map the series pins with the Model_name and also with a Function Table Group designation. For just series elements, this designator is not used and can be any any alphanumeric word. The Series element is assumed to be 'On'. However, for actual series switch components, a common control often is used for groups of switches that have their switching action sychronized. The Function Table Group designator is used to associate those switches that have sychronized switching action. The [Series Switch Groups] keyword is added to give the allowable combinations of sychronized switching states for the set of groups defined. A number of other details that have been considered are embedded in this expanded proposal. Most of the considerations relate to consistency and compatibility with the existing IBIS syntax and implicit conventions. Any shunt element can be provided by separate [Model]s. This will include the package parasitics on EACH of the pins. The existing [Pin] keyword is used for this purpose. If clamping diodes exist, they would be entered as "Terminator" models and can be assigned to the appropriate pin directly. This may be a complication, but allows consistency with the existing IBIS syntax. C_comp is not defined for series elements. It could be used as a residual capacitance ACROSS the series element. BIRD41.3: BIRD41.3 is issued in response to some comments and suggestions made on May 14, 1997 by John Fitzpatrick regarding BIRD41.2. Some other minor changes are made. C_comp is values is ignored in Series and Series Switch models because it is defined as a capacitance to ground. Use [C Series] for any capacitance needed ACROSS the pins. While the range of the [Series MOSFET] tables are defined from a minimum of GND to GND + POWER, the actual range of the derived model extends well beyond GND + POWER based on the equations provided for Vds. There may be undershoot conditions driving both sides of a MOSFET switch to values below ground. However the switch will be in its lowest impedance state, and any analysis based either on truncated data at 0 V or extrapolated data below 0 V will be sufficiently accurate. Extending the ranges beyond what is defined may result in significant extraction problems from measurement if there exists clamping diodes in the physical switch. It is clarified further that all of the models associated with the [Pin] keyword are still used to define shunt elements such as Schotkey diodes and capacitances on EACH pin of series device. While this splits up the electrical models, they would all be called under the [Component] description. The reason for this approach is that it just uses the already existing IBIS structure. [Series Switch Groups] keyword is now used to better describe the allowable Function Table states. Some additonal clarification is provided regarding defaulting some of the undefined series discrete devices to a short circuit. A restriction regarding Series_switch models is stated that there will be no common electrical model spanning both the [On] and [Off] states. The list of models which must be positioned below the [On] or [Off] keywords is stated. This will avoid some additional rules and confusing interpretations if a particular keyword were positioned both above and below the [On] or [Off] keyword. BIRD41.4: John Fitzpatrick suggested in a private note that models that can be attached to Series or Series_switch models under the [Pin] table be Terminator models. Text is put in Other Notes under [Series Pin Mapping] stating this restriction (and also including 'NC'). It is a complication to allow Input or I/O models, and if the pin is connected to a power rail, this can be done in a simulator dependent manner. John also suggested expanding approved BIRD30.2 to include [Series Pin Mapping] models to be included in the [Model Selector] keyword. This could be used for selecting Series_switch models for Vcc = 5 V or Vcc = 4.3 V when used in 3.3 to 5 V logic interface applications. An additional modification is included to make this change. It makes sense to capture within [Model Selector] all of the Model_names that can be selected. The [Series Pin Mapping] keyword defines new models that are not listed under the [Pin] keyword. BIRD41.5: References to quadradic fitting for [Series MOSFET} based on two tables are removed because the algorithms did not yield significant improvement and usually caused other problems. Also there was some extreme data sensitivity issues when the data was near zero mA which would cause much additional complexity. The linear algorithm provided good correlation when more data points were taken. The table extraction circuit is modified so that current through the device is sensed on the source side so that a leakage current to the substrate does not cause non-monotonic increasing values for higher source voltages. BIRD41.6: [Series Pin Mapping] syntax is revised to define the columns in terms of subparameters. This is consistent with the [Pin], [Pin Mapping] and [Diff Pin] keywords. It also allows entering only three columns for Series models and four columns for Series_switch models. All of the other keywords allow two selections for number of columns. Parser development effort should be reduced by maintaining consistency with other similarly formatted keywords. BIRD41.7 The relationship for defining the drain to source current as a function of drain to source voltage was incorrect. A more rigorous explaination is provided in terms of actual ids, vds values and the information from the table. BIRD41.8 Some editorial corrections are made as part of the BIRD41.7 that are documented in BIRD41.8 to simplify the discrete series element notation and to add [Series Pin Mapping] references under Usage Rules: of the [Model] keyword. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: 41 Submitted Feb 12, 1997 41.1 Submitted Feb 17, 1997 - Better explanation of State column - Define new [Series Impedance] keyword - Define series RLC path (to model passive device + parasitics) 41.2 Submitted May 14, 1997 - Extensive revisions based on two IBIS meetings and other notes 41.3 Submitted May 15, 1997 - Response to John Fitzpatricks comments 41.4 Submitted May 16, 1997 - [Pin] model Terminator or NC restriction for series pins - [Model Selector] keyword addition to include [Series Pin Mapping] models. 41.5 Submitted May 22, 1997 - Removed references to Quadradric fitting for [Series MOSFET] table - Changed VI extraction setup to prevent non-monotonic currents 41.6 Submitted May 28, 1997 - Changed [Series Pin Mapping] syntax to conform with [Pin], [Pin Mapping] and [Diff Pin] syntax by including column headings as subparameters. - Added to [Series Switch Groups] the example for Bus Switch in the [Series Pin Mapping] keyword - Made other miscellaneous editorial changes for consistency. 41.7 Submitted May 30, 1997 - Corrects and Provides a more rigorous linear functional relationship for using the [Series MOSFET] table data. - Makes minor editorial corrections. 41.8 Approved June 12, 1997 conditional upon some editorial changes - Series elements changed to: [R Series], [L Series], [Rl Series], [C Series], [Rc Series], [Lc Series] - Additional change of [Pin] to [Pin] and/or [Series Pin Mapping] under [Model] From owner-ibis Fri Jun 13 17:34:32 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 RAA19392 for ; Fri, 13 Jun 1997 17:34:26 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 13 Jun 97 17:32 PDT Received: by chane.icx.com (/\==/\ Smail3.1.28.1 #28.16) id ; Fri, 13 Jun 97 17:32 PDT Received: by bob.icx.com via send-mail with stdio id for airboss@europa.com; Fri, 13 Jun 1997 17:32:11 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 13 Jun 1997 17:32:11 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD42.3 Modeling Current Waveforms To IBIS Committee: BIRD42.3 contains changes made at the IBIS Open Forum Summit meeting on June 12, 1997. BIRD42.3 was discussed, but not voted on since some controversial issues arose that could not be resolved at the meeting. Some of the discussion concerned the need for this additional functionality for accuracy, and the problems associated with extracting good information that was not redundant or contradictory. Portions of BIRD42.3 which relate to editorial and example changes for the [Rising Waveform] and [Falling Waveform] keywords only were accepted and will be part of the editoral changes contained in IBIS Version 3.0. The keyword [GND Current] is changed to [Pulldown Reference Current]. The keyword [POWER Current] is changed to [Pullup Reference Current]. Other related references in the text and diagram are modified accordingly. These changes are made to reflect explicitly the reference rail for which they are defined and also to allow addtional currents for the clamps in the future. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 42.3 ISSUE TITLE: Modeling Current Waveforms REQUESTER: C. Kumar, Cadence, Bob Ross, Interconnectix DATE SUBMITTED: May 16, 1997, May 19, 1997, May 30, 1997, June 12, 1997 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Current into the power and ground rails are needed to give a more accurate analysis for ground and power bounce analysis associated with simutaneous switching. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two current Waveform tables [Pulldown Reference Current] and [Pullup Reference Current] are defined to be associated with [Rising Waveform] and [Falling Waveform] are added. Also some of the data associated with [Rising Waveform] and [Falling Waveform] is modified to reflect a real situation. The existing data in the specification was not realistic and gave incorrect guidance. The waveform tables in the examples were generated from a real sample. Replace this section: |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture subparameters are | required, the rest of the subparameters are optional. | If a subparameter is not used, its value defaults to | zero. The subparameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | Insert this new [Rising Waveform] and [Falling Waveform] section and new examples and text changes noted by "|*" lines. A note about C_comp is desinated by the ""|**" lines, per BIRD42.2 change. Add the new keyword [Pulldown Reference Current] and [Pullup Reference Current] section and examples. |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, | C_fixture, L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | subparameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | |* NOTE: The use of L_dut, R_dut, and C_dut is strongly |* discouraged in developing Waveform data from simulation |* models. Some simulators may ignore these parameters |* because they may introduce numerical time constant |* artifacts. |* | Only the R_fixture and V_fixture subparameters are | required, the rest of the subparameters are optional. | If a subparameter is not used, its value defaults to | zero. The subparameters must appear in the text after | the keyword and before the first row of the waveform | table. | | V_fixture defines the voltage for typ, min, and max | supply conditions. However, when the fixture voltage | is related to the power supply voltages, then the | subparameters V_fixture_min and V_fixture_max can | be used to further specify the fixture voltage for | min and max supply voltages. |* |* NOTE: Test fixtures with R_fixture and V_fixture, |* V_fixture_min, and V_fixture_max only are strongly |* encouraged because they provide the BEST set of data |* needed to produce the best model for simulation. C_fixture |* and L_fixture can be used to produce waveforms which |* describe the typical test case setups for reference. |** |** All tables assume that the die capacitance is included. |** Potential numerical problems associated with processing |** the data using the effective C_comp for effective die |** capacitance may be handled differently among simulators. |** |------------------------------------------------------------------------------ |*** New Example Below: [Rising Waveform] R_fixture = 50 V_fixture = 0.0 | C_fixture = 50p | These are shown, but are generally not recommended | L_fixture = 2n | C_dut = 7p | R_dut = 1m | L_dut = 1n | Time V(typ) V(min) V(max) 0.0000S 25.2100mV 15.2200mV 43.5700mV 0.2000nS 2.3325mV -8.5090mV 23.4150mV 0.4000nS 0.1484V 15.9375mV 0.3944V 0.6000nS 0.7799V 0.2673V 1.3400V 0.8000nS 1.2960V 0.6042V 1.9490V 1.0000nS 1.6603V 0.9256V 2.4233V 1.2000nS 1.9460V 1.2050V 2.8130V 1.4000nS 2.1285V 1.3725V 3.0095V 1.6000nS 2.3415V 1.5560V 3.1265V 1.8000nS 2.5135V 1.7015V 3.1600V 2.0000nS 2.6460V 1.8085V 3.1695V | ... 10.0000nS 2.7780V 2.3600V 3.1670V | [Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time V(typ) V(min) V(max) 0.0000S 5.0000V 4.5000V 5.5000V 0.2000nS 4.7470V 4.4695V 4.8815V 0.4000nS 3.9030V 4.0955V 3.5355V 0.6000nS 2.7313V 3.4533V 1.7770V 0.8000nS 1.8150V 2.8570V 0.8629V 1.0000nS 1.1697V 2.3270V 0.5364V 1.2000nS 0.7539V 1.8470V 0.4524V 1.4000nS 0.5905V 1.5430V 0.4368V 1.6000nS 0.4923V 1.2290V 0.4266V 1.8000nS 0.4639V 0.9906V 0.4207V 2.0000nS 0.4489V 0.8349V 0.4169V | ... 10.0000nS 0.3950V 0.4935V 0.3841V | |============================================================================== | Keywords: [Pulldown Reference Current], [Pullup Reference Current] | Required: No | Description: Describes the shape of the rising and falling edge | current waveforms of a GND and POWER nodes, respectively. | Usage Rules: Each [Pulldown Reference Current] and [Pullup Reference | [Current] keyword is | positioned under the [Rising Waveform] (for rising | waveform currents) and [Falling Waveform (for falling | waveform currents. The keywords are followed by a table | of time vs. current points that | describe the shape of a current waveform. These | time/current points are taken under the conditions | specified in the [Rising Waveform] or [Falling Waveform] | R/L/C/V_fixture subparameters. The table itself consists | of one column of time points, then three columns of | current points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a current column | must be the DC current before switching | and the last entry (or entries) of the column must be | the final DC value after switching. Each | table must contain at least two entries. Thus, numerical | values are required for the first and last entries of any | column containing numerical data. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | Each [Pulldown Reference Current] and [Pullup Reference | [Current] table must be | time correlated with its associated [Rising Waveform] | or [Falling Waveform] table. | | The diagram below illustrates the complete model with | respect to the [Rising Waveform] and [Falling Waveform] | subparameters. The diagram also illustrates the direction | of positive [Pulldown Reference Current] and [Pullup | Reference Current] current flow by the notation I_PULLDOWN | and I_PULLUP. | | PULLUP REFERENCE | | | | | | I_PULLUP | | | v | PACKAGE | TEST FIXTURE | ____|____ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\--- V_fixture | |_________| | | | | | | | | | ^ | | | | | I_PULLDOWN | | C_dut === | === C_fixture | | | | | | | | | | | | PULLDOWN REFERENCE GND | GND | | | The 'fixture' subparameters specify the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut subparameters are analogous to the | package parameters R_pkg, C_pkg, and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. | | NOTE: For computation purposes, the effect of the | L_dut, R_dut, and C_dut subparameters will be ignored. | It is strongly recommended that they not be used, if | possible. Furthermore, it is strongly recommended that | the 'fixture' not use any L_fixture or C_fixture | component. | | Because of an assumption that the currents into the | Pulldown Reference, Pullup Reference nodes and output | nodes must sum to zero, only the [Pullup Reference | Current] or [Pulldown Reference Current] tables are | needed. The output | node current is available from the test fixture and | output waveform data. However, both current | waveform tables are permitted. Similarly, an Open model | device such as Open_drain or and ECL device such as | Output_ECL may not need any current waveform table. | However, each or both are still permitted. It is | simulator dependent which set of data takes precedence | in case of redundant information. | |------------------------------------------------------------------------------ [Rising Waveform] | ... | ... | Rising Waveform subparameters and table | ... [Pulldown Reference Current] | Time I(typ) I(min) I(max) 0.0000S -338.4000uA -188.6000uA -635.9000uA 0.2000nS -2.0160mA -123.4000uA -6.2360mA 0.4000nS -2.3650mA -3.5670mA -11.0600mA 0.6000nS -7.2070mA -5.1150mA -12.0600mA 0.8000nS -7.4570mA -4.9160mA -17.1600mA 1.0000nS -8.2950mA -3.9180mA -19.7900mA 1.2000nS -9.5720mA -3.5720mA -8.2330mA 1.4000nS -10.5400mA -3.5850mA -2.9600mA 1.6000nS -7.8290mA -3.8150mA -1.4140mA 1.8000nS -4.6260mA -3.9860mA -1.1420mA 2.0000nS -2.3870mA -4.1520mA -1.1250mA | ... 10.0000nS -388.4000uA -135.3000uA -964.2000uA | [Pullup Reference Current] | Time I(typ) I(min) I(max) 0.0000S 842.5000uA 493.0000uA 1.5070mA 0.2000nS 6.6700mA 3.2490mA 9.7430mA 0.4000nS 12.9000mA 4.6150mA 26.3100mA 0.6000nS 25.9800mA 11.3000mA 42.5700mA 0.8000nS 35.3200mA 19.0900mA 58.4600mA 1.0000nS 43.2400mA 24.2100mA 70.4200mA 1.2000nS 49.7700mA 28.9700mA 64.7800mA 1.4000nS 55.3400mA 32.9800mA 64.7600mA 1.6000nS 56.4000mA 36.3800mA 64.3900mA 1.8000nS 56.3100mA 39.1500mA 64.4500mA 2.0000nS 56.2000mA 41.3300mA 64.5700mA | ... 10.0000nS 55.9500mA 47.3500mA 64.3200mA | [Falling Waveform] | ... | ... | Falling Waveform subparameters and table | ... [Pulldown Reference Current] | Time I(typ) I(min) I(max) 0.0000S -157.4000uA -86.9600uA -291.0000uA 0.2000nS -34.6000mA -17.1000mA -48.6100mA 0.4000nS -41.5400mA -20.8600mA -70.7200mA 0.6000nS -60.5500mA -30.4800mA -96.8400mA 0.8000nS -77.7500mA -41.5500mA -107.4000mA 1.0000nS -88.1500mA -52.0000mA -115.5000mA 1.2000nS -92.9400mA -60.9400mA -110.6000mA 1.4000nS -96.9700mA -68.0800mA -107.1000mA 1.6000nS -98.1100mA -72.7800mA -106.4000mA 1.8000nS -96.5100mA -75.9600mA -106.0000mA 2.0000nS -95.1600mA -77.7100mA -105.9000mA | ... 10.0000nS -94.3700mA -81.4700mA -106.3000mA [Pullup Reference Current] | Time I(typ) I(min) I(max) 0.0000S 157.4000uA 86.8500uA 291.0000uA 0.2000nS 17.4600mA 10.0440mA 22.5200mA 0.4000nS 11.7300mA 8.2320mA 18.0200mA 0.6000nS 11.0800mA 6.8680mA 15.2900mA 0.8000nS 10.1700mA 6.2700mA 11.1900mA 1.0000nS 8.3370mA 6.2160mA 14.7000mA 1.2000nS 6.2100mA 5.7840mA 9.4580mA 1.4000nS 6.9920mA 5.3040mA 5.7280mA 1.6000nS 8.2280mA 4.6130mA 4.8490mA 1.8000nS 5.5850mA 3.8730mA 4.3310mA 2.0000nS 4.0180mA 3.2190mA 4.1990mA | ... 10.0000nS 2.2710mA 1.3390mA 3.9900mA | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Some additonal clarification information is needed in the original [Rising Waveform] and [Falling Waveform] keyword. A better example needs to be supplied because the existing example illustrates some bad practices. The current waveform specification is needed to better define the currents in the GND and POWER nodes during switching. Currently the allocation of currents into these nodes is simulator-algorithm dependent. There is no information regarding paths directly from POWER to GND as might occur in a make-before-break transition implementation that exists in some CMOS devices. The L_dut, R_dut, and C_dut fixture parameters are deleted from the new keywords. While actual package electrical characteristic may exist, there effects are negligible for current waveforms. Moreover, this level of detail has proven in many case to actually reduce accuracy in simulation because of numerical time constant considerations. Suggestions encouraging resistive-only fixture loads are embedded in this proposal to encourage generating data that is most suitable for developing models that may be used by most simulators. The new examples reflect this practice. BIRD42.1: By restricting the already correlated current waveforms to be under the current keyword, several simplifications can be made: Eliminate [GND Rising Waveform], [GND Falling Waveform], [POWER Rising Waveform], [POWER Falling Waveform] Instead, add as a result, [GND Current] and [POWER Current]. These keywords are restricted to directly under their corresponding [Rising Waveform] and [Falling Waveform] tables for the particular waveform of interest. Eliminate all references to subparameters - The current tables are based on the [Rising Waveform] and [Falling Waveform] table subparameters. All of the proposed functionality remains. BIRD42.1: Some editoral cleanup is done and a note concerning numerical artifacts associated with C_comp is added under the [Rising Waveform] and [Falling Waveform] keyword description is added. Calculating current as a function of changing voltage across a capacitance is a numerically sensitive process. BIRD42.2, BIRD42.3: More editorial Cleanup. Change [GND Current] to [Pulldown Reference Current]. Change [POWER Current] to [Pullup Reference Current]. These changes reflect more explicitly the power rails for which the current waveforms are defined. They also allow working with ECL device models. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This proposal is based on discussion initiated by C. Kumar at the IBIS Open Forum Meeting on May 9, 1997 Part of the introduction material for BIRD42.1 includes this statement: "Also, I acknowledge that even with this more detailed set of data, REAL power and bounce analsis may be influenced by factors BEYOND Output buffer switching. Scott McMorrow correctly points out that some internal circuitry such as internal clock drivers are already internally loaded and may not have external connections. There may be significant movement of currents due to these internal elements that can interact and affect the internal bounce of common internal ground and power busses. So beware that bounce analysis may be more dependent on (undocumented) internal construction (sharing of common busses) and undocumented internal switching effects. The IBIS Model may UNDERESTIMATE the true bounce effects." From owner-ibis Fri Jun 13 18:46:02 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 SAA20672 for ; Fri, 13 Jun 1997 18:46:01 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 13 Jun 97 18:45 PDT Received: by chane.icx.com (/\==/\ Smail3.1.28.1 #28.16) id ; Fri, 13 Jun 97 18:44 PDT Received: by bob.icx.com via send-mail with stdio id for bob; Fri, 13 Jun 1997 18:45:00 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 13 Jun 1997 18:45:00 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Version 3.0 Ratification To IBIS Fans: IBIS Version 3.0 was formally ratified at the EIA/IBIS Open Forum Summit Meeting held on June 12, 1997 per modifications discussed during the meeting and per approved BIRDs. Version 3.0 with appropriate revisions will be put under /pub/ibis/ver3.0 shortly and will be the basis for beginning the editorial correction process leading to Version 3.1. Bob Ross Interconnectix From owner-ibis Tue Jun 17 08:26:27 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA18391 for ; Tue, 17 Jun 1997 08:26:26 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA15034 for ; Tue, 17 Jun 1997 08:25:15 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA15261; Tue, 17 Jun 1997 08:25:31 -0700 (PDT) Message-Id: <199706171525.IAA15261@ichips.intel.com> To: ibis@vhdl.org Subject: IBIS Face to Face Meeting Minutes Date: Tue, 17 Jun 1997 08:25:31 -0700 From: Stephen Peters VOTING MEMBERS AND 1997 PARTICIPANTS LIST: AMP Jeff Walden Applied Simulation Technology Dileep Divekar*, Norio Matsui*, Raj Raghuram 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* INCASES Olaf Rethmeier, Werner Rissiek* Intel Corporation Stephen Peters*, Arpad Muranyi*, Henry Maramis*, Will Hobbs* Interconnectix Bob Ross* Mitsubushi Tam Cao, Hoang Nguyen* Motorola Ahmed Omer National Semiconductor Syed Huq*, Cheng-Yang Kao, Mike Bristol, Peter Laflamme, Kevin Smith NCR Dave Moxley, Richard Mellitz NEC (Hiroshi Matsumoto) Quad Design/Viewlogic Jon Powell, Chris Rokusek*, Peivand Tehrani* Quantic EMC (Mike Ventham) Texas Instruments Thomas Fisher* Thomson-CSF/SCTF (Jean LeBrun) VeriBest Ian Dodd, William Bell VLSI Technology Harish Patel*, D.C. Sessions* Zuken-Redac (John Berrie) 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* EIA Patti Rusher* EMC Fabrizio Zanella 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 Friday, July 11 (916) 356-9200 2-160894 4369865 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 Twenty eight people attended the EIA/IBIS Open Forum Summit and introduced themselves. Bob Ross thanked Patti Rusher of EIA for handling the meeting details including arranging for the fine meals and refreshments. PRESS AND WEB PAGE UPDATES Bob Ross reported two articles in the June 1997 issue of Computer Design by Charles Small which mention IBIS: "Demand for IBIS Models Begins to Take Off", p. 34 and "Achieving Signal Integrity Demands Rethinking the Design Process", pp. 34-40. Bob Ross also submitted after the meeting these articles which refer to IBIS: "Signal Integrity: More than a Board Issue" in Electrical Engineering Times, by John Colfield and Greg Doyle on June 1997, p. 80; and "Analysis Tools Target PC-Board Design-Cycle", by Cheryl Ajluni in a Supplement to Electronic Design, May 27, 1997, pp. 57-63. NEW MODELS AVAILABLE, LIBRARY UPDATE Syed Hug has submitted prior to the meeting a new National URL for IBIS Models: http://www.national.com/models Bob Ross submitted prior to the meeting that Siemens has IBIS models at http://www.siemens.de/Semiconductor/products/ICs/31/3177.htm Also Bob submitted that the Micron link has changed to an FTP site ftp://www.micron.com/pub/ibis Cypress has more models in the Timing Technologies section. Motorola also has added some models in the Power PC library. John Powell has updated the EIA/IBIS Web Site Models section with the new links. DESIGN AUTOMATION CONFERENCE (DAC) 1997 IBIS MEETING The morning session consisted of presentations and discussions by several individuals and the election of EIA/IBIS Open Forum Committee Officers for 1997-1998. While this is not intended to be comprehensive, some notes about the presentations are given. Among the casual conversation, Patti Rusher indicated good traffic at the EIA booth at DAC and continued interest in IBIS. She also had reprints of Syed Huq's December 1996 Article in Electronic Design: "Ease System Simulation With IBIS Device Models". The IBIS poster at the Booth looked very nice and listed the participating companies. IBIS YEARLY REVIEW, Bob Ross, Interconnectix Bob summarized the technical features of IBIS from the "Core" Version 1.1 in June, 1993, "Extensions" of Version 2.1 form June, 1994 through December, 1995, and the proposed "Refinements" of June 1997. International Progress includes IBIS as a work item proposal 93/46/NP in TC93 of IEC, a pending French proposal including EMC, Japanese activities at a more detailed level through EIAJ on the I/O Interface Model for Integrated Circuits and the fact that IBIS is referenced in EDIF 4 0 0. IBIS models are now widely available from many companies (with demand for IBIS models greater than Spice models). Eleven companies have model sites for downloading (up from four a year ago), and three commercial companies provide libraries and services - amounting to around 10,000 IBIS models. There have been s2ibis2 and ibischk2 improvements. Four companies read IBIS models directly, and many others translate models from the IBIS format. IBIS is accepted and spreading! Two articles appeared on IBIS from Committee members, and Howard Johnson of "High Speed Digital Design, A Handbook of Black Magic" fame has written favorably about IBIS. The Committee continues to be active with over 20 official members and a 300+ mailing list. The major challenges include a clearer editorial release of IBIS Version 3.1, ibischk3 parser development, and improved information including the Cookbook, more articles and information. Good modeling practices need to be conveyed, and Bob suggests that IBIS model developers attempt to work more closely with CAE vendors who parse IBIS models. s2ibis improvements are needed. There also continue to exist technical improvements consistent with evolving technology, and continued international involvement. The major thrust is now for stabilization, cleanup, and information about IBIS. MITSUBISHI IBIS MODELING ACTIVITIES (4/96-5/97), Hoang Nguyen, Mitsubishi Semiconductor America, Inc. Hoang indicated that Mitsubishi provides IBIS, HSPICE, HDL models to support customers for DRAM and application-specific memory products. A Web page is being created to access the models. He showed the support system for models in North America and for Japan/Asian and European customers. Mitsubishi IBIS models are Version 2.1 and are based on s2ibis2 processing of Spice models validated by chip designers. The response to IBIS models is positive. Hoang noted that some vendors have their own IBIS to Spice translators to process IBIS models in Spice simulation environments. Hoang noted that some customers want test loads for waveforms and ramp different from the cookbook recommended test loads. Hoang also noted that he hoped IBIS Version 3.0 contained an index page for quick referencing of major keywords or definitions. CONSTRUCTION OF REAL EXAMPLE OF INPUT/OUTPUT INTERFACE MODEL FOR INTEGRATED CIRCUITS, Saburo Hojo, Hitachi. Saburo, (an original author of the Electronic Industries Association of Japan (EIAJ) I/O buffer modedling standard) gave an overview. The proposal originates from the Technical Standardization Center, Committee on Semiconductor Devices, I/O Interface Model Project Group. The model is expressed as a network and covers the IC Buffer and Package. Its advantage are that the transistor descriptions are in a table form to protect process information, and the network descriptions can show details including power/ground circuitry for bounce analysis. Saburo showed networks and examples of MOS one, two and three dimensional table formulations. A real construction example was shown for a 16M DRAM in a TSOP 50 pin package. Waveform tables to drive the gates were derived from simulation. The power/ground connections were derived from an RC network from the physical layout. The MOS transistor table and parameters were derived from simulation results. The package was derived from the layout as an LMRC network (with coupling). Saburo noted the size of the model as 460k bytes and broke down the lines needed: I/O buffer Network (36), Waveforms to Output Buffer (283), Power/ Ground Network (5428), Table Model (2080), Package Network (4639). It currently takes one week to construct manually. Stephen Peters asked how fast the EIAJ model simulates, and if any SPICE vendor support the table driven MOS transistor descriptions. Saburo replied that the simulation speed depends on the size of the model (the 460K byte example simulated no faster than a full spice model) and that Metasoft is planning on supporting the table driven MOS descriptions. Concerning future work, Saburo noted some current limitations in the format. Version 1.0 of the draft is expected September 1997 and final approval is planned December 1997 by EIAJ. (Saburo also has generated Hitachi IBIS models for customers.) SIMULATOR ALGORITHMS, Bob Ross, Interconnectix Bob showed samples indicating that we need to know what is inside the model since simulator algorithms may be different concerning Ramp based models and Waveform table based models. Bob showed by a simple example that there are a number of choices based on linear (ramp) transitions to simulate the data - all giving different results. The implied IBIS model topology corresponds to a Current-based model, but its dual corresponds to a Voltage- based model. Non-linear transitions can be derived from Waveform information to give better fits corresponding to an IBIS reference topology. Other internal details such as C_comp handling, ramp rounding, and package details may be handled differently among simulators. So, at the detailed level, IBIS models probably will be treated differently by simulators. Even with these differences, the accuracy by all simulators has still proven to be sufficient for general board level analysis situations where IBIS models are very suitable. C. Kumar added some discussion about using power and ground current table information to improve accuracy. More information can always be used. He also noted that reactive elements in the *_fixture and *_dut should be avoided because they lead to numerical difficulties. C_comp handling, while needed, also leads to dV/dt numerical difficulties (spikes) since derivatives are handled using discrete time step algorithms. EIAJ IC PACKAGE MODEL STANDARDIZATION ACTIVITIES, Norio Matsui, Applied Simulation Technology, Ltd. Norio stated that under the Technical Standardization Center exists the Committee on Semiconductor Packages, Package Electrical Characterization Project Group. This group consists of 18 members, headed by Hitachi, and has had six monthly one-half day face-to-face meetings. Norio showed some preliminary research results of simulator and simulation investigations. Data book L and C parameters are undefined or too high. Concerning radiation noise, 30% to 70% of PCB surfaces are covered with IC packages. Radiation can be generated from horizontal lead frames, vertical lead frames and power/ground planes. Both electrical and physical models are required. Model standardization for ceramic packages, plastic packages and MCMs for memory models is considered. A BGA structure would include signal traces, ground and Vcc planes. These would be described via nodal networks in the EIAJ table format. Additional information includes frequency and position of planes. Among the rules, avoid using node 0 or GND/gnd - ground should be floating. Self R, L, C, (G) for lead frames and planes are provided, and mutual coupling for L and C for long distances is not necessary. So the full LCR matrix is not needed. Tools need to extract the user models from the total model. Tools need to extract macro-models from segmented, detailed network models for simplified modeling for a large number of pins. Under discussion is how to make models for huge pin counts for signal and power/grounds. All pin model is still required. Some techniques include using symmetry, limiting coupling range, connect all or grouped ground/power pins for BGA, and macromodels by one segment per pin at a frequency. Norio showed simulation results to complement Saburo Hojo's presentation based on the EIAJ Table Spice and package model using an Applied Simulation Technology implementation. The schedule tracks the I/O IMIC activity with June 1997 for Draft 1.0 with examples, September 1997 for Draft 2.0, and EIAJ approval of Level 2 (SI and PI) planned for December 1997. IBIS FORUM I/O BUFFER MODELING COOKBOOK, Stephen Peters, Intel Corp. Stephen passed out Revision 2.0, June 11, 1997 draft of the above document and reviewed its contents. It extends the cookbook to Version 2.1 levels and contains tables to clearly show the key components of IBIS models and the required/optional keywords and subparameters. The sections are Introduction, Pre-Modeling Steps, Extracting the Data, Putting the Data Into and IBIS File, Validating the Model, Correlating the Data, and Resources. Five Examples are proposed and several individuals volunteered to provide them. Stephen asked for feedback including comments from EDA vendors on the recommended test loads for waveforms. AR - The following people have volunteered to supply examples Steve Kaufer/Hyperlynx -- Example 1 Arpad Muranyi - Example 2 Stephen Peters - Example 3 AR - D.C Sessions. Supply a paragraph or two explaining the best way to modify a SPICE transistor model to get realistic power and ground clamp information AR - Bob Ross. Supply the text for the section "Diode Transient Time Data" AR - Syed Huq. Review and expand (if necessary) Section 3.3. on "Obtaining I/V and Switching Information via Lab Measurment". AR - Everyone who received a copy review the document and provide comments to Stephen Peters (address at the end). ELECTION OF EIA/IBIS OPEN FORUM OFFICERS FOR 1997-1998. The following Individuals were nominated and elected to serve as Committee officers: Bob Ross, Chair, Syed Huq, Vice Chair, Stephen Peters, Secretary, and Jon Powell, Librarian. They are listed at the end of these minutes. Patti Rusher presented EIA/IBIS Committee appreciation plaques to Jon Powell, Syed Huq, and Bob Ross for service for the 1996-1997 term. TECHNICAL SESSION After a break for lunch the technical session focused on final consideration of the Open BIRDs and the Ratification of IBIS Version 3.0 with modifications discussed at the meeting. BIRD41.7 - MODELING SERIES SWITCHABLE DEVICES Bob Ross proposed a syntax change for discrete elements changing [R L Series] to [Rl Series], [R C Series] to [Rc Series], and [L C Series] to [Lc Series]. This was to make the syntax clearer and reduce underbar and space combinations. This was approved. Also Bob Ross indicated that another reference in IBIS in the first paragraph under the [Model] keyword needs to be changed in two locations: [Pin] is changed to "[Pin] and [Series Pin Mapping]". This was approved. Bob Ross also gave a presentation SERIES SWITCH MODELING TESTS showing the models and simulation results under Spice. A crossbar switch model was shown. Drain Current as a function of Source Voltage for fixed Drain to Source voltages were shown. This is another way of showing resistance as a function of voltage. The tables show that this effective resistance changes as the drain to source voltage increases. Because of the values of the models, using a 1/2 volt or 1 volt basis provides reasonable accuracy approximations. All of the data assumed a linear relationship between voltage across the component and corresponding drain current. While a two table implementation using a quadratic fit was tested, Bob reported did not have the predicted accuracy improvement to justify recommending it. Under loaded conditions, the proposed [Series MOSFET] table model showed excellent correlation with the Spice Model for a single MOSFET transistor. A reflected wave circuit was used for the remaining tests to force the table model to operate in the forward and reverse directions over its entire range. Again good correlation was shown, with the major deviation being in the high impedance range. The model supports moving the Vcc to 4.3 V for 5 V to 3.3 V interface applications. A full Spice model for the TI 74CBT3383 was tested against the proposed IBIS simulation. This switch has effective ground clamps and capacitances at both terminals. The Spice simulation also showed agreement for 3.3 V inputs using the reflected wave test circuit. The 5 V input showed more of a mismatch. However, D.C. Sessions and others indicated that the results were as good as could be expected since there were some very non- linear capacitances when the drain and source node voltage differences become equal. The results also showed an effective power clamp, even though the DC extraction shows no such clamp. However, this may also be second order effects associated with the non-linear behavior of the actual Spice Level 13 model. In this region, the results were still deemed satisfactory considering the numerical uncertainties with high impedance regions. Bob stated that the 4 pF capacitances were found by experimental matching, the data book indicates 6 pF. As part of the subsequent discussion, Stephen Peters requested a fully formatted IBIS example. A vote on BIRD41.7 with changes was conducted. BIRD41.7 was unanimously approved with the above changes. AR - Bob Ross post BIRD41.8 documenting these changes and include the changes in the revised IBIS Version 3.0 [Done] AR - Bob Ross submit an example of a Series MOSFET component. BIRD43 - COMPONENT TEST POINT SUBPARAMETERS Bob Ross briefly introduced BIRD43 as an extension of the [Component] keyword by adding two subparameters for timing and signal integrity testing location (Die or Pin). The primary motivation is that ASICs tend to provide specifications at the Die rather than the (default) Pin location. BIRD43 was approved by unanimous vote. BIRD44 - INTERPRETATION OF MIN/MAX/WEAK/STRONG DATA Bob Ross introduced BIRD44, recently submitted by Andy Ingraham. With few exceptions the Committee requires that BIRDs to be submitted at least two weeks prior to voting to give everyone an opportunity for review. BIRD44 does not change any technical content but is intended to provide clarity of the min and max tables usage for [Model]s. Since the content is mostly editorial, BIRD44 can be considered for IBIS Version 3.1 where a number of suggested editorial changes will be considered. Also, Bob indicated that maybe a note in the front may be an alternative way of dealing with the issue while retaining much of the established min/max notation that currently exists in models. BIRD42.2 - MODELING CURRENT WAVEFORMS Based on a suggestion by D.C. Sessions, Bob Ross deferred discussion of BIRD42.2 after considering the other BIRDs because of some controversial aspects. BIRD42.2 introduces keywords under the [Rising Waveform] and [Falling Waveform] tables for tables describing the ground and power currents of the buffer. These tables give more detail regarding actual current flow for the buffer for bounce calculations and potentially provide more information for accurate modeling of buffer transitions. C. Kumar drew some diagrams to support the position for more accurate modeling. D.C. Sessions was concerned that this might not be the case and that the additional information might either be redundant or contradictory. Much discussion and debate followed. One question was whether just a shunt current between rails was all that was needed. Some other questions were raised regarding other paths - such as the input current glitch and possible capacitance and diode paths that may enter into the distribution. It became clear that we could not reach a consensus. Werner Rissiek proposed that we not vote on BIRD42.2 and that it not be included in IBIS Version 3.0. The committee agreed to keep the editorial changes, example changes and recommendation text additions to [Rising Waveform] and [Falling Waveform] that are documented in BIRD42.2 as an editorial change to IBIS Version 3.0. Regardless of the outcome, Bob proposed that BIRD42.2 keywords be changed to reflect the rail to which they are attached. [GND Current] would be changed to [Pulldown Reference Current] and [POWER Current] would be changed to [Pullup Reference Current]. The Committee agreed with this change. This would allow extensions to the other rails if needed and allow descriptions for ECL models to be consistent within the IBIS conventions. AR - Bob Ross post Bird42.3 documenting these changes. Also delete the keywords [GND Current] and [POWER Current] from IBIS Version 3.0. [Done] AR - D.C. Sessions and Kumar get together and provide an example showing where the rising and falling waveform tables do not result in correct results. Bob mentioned that that while we have traditionally made the IBIS Version X.1 an editorial correction release, we were not bound by this convention. BIRD42.3 can be a candidate for inclusion in IBIS Version 3.1. We also could issue an IBIS Version 3.2 as the final editorial correction since the parser development is expected to take a long time (one-half a year or more). DYNAMIC CLAMPS AND OTHER ITEMS Arpad Muranyi has not yet prepared a BIRD on this area. However, since it relates to actual implementations, it could also be considered as a possible addition to IBIS Version 3.1 if the proposal is approved. Stephen Peters felt that the dynamic ranges within IBIS were unnecessarily large for some open configurations such as GTL devices with 3.3 V supplies, which are terminated 1.2 V or 1.5 V and have a reduced voltage swing. Some notes could be made in the Cookbook or proposed as an editorial revision of IBIS Version 3.0 via the BIRD process. VERSION 3.0 RATIFICATION After the above consideration and resolutions of BIRD41.8 and BIRD43, Bob Ross asked for a ratification vote on IBIS Version 3.0 with the discussed modifications. IBIS Version 3.0 was unanimously ratified as modified. Bob will make the agreed upon changes and a few other minor corrections he discovered and will put the text on vhdl.org under /pub/ibis/ver3.0. This will provide the baseline for IBIS Version 3.1 discussions. Version 3.0 is not suitable for formal EIA and ANSI ratification. However, it does formally endorse the newly approved functionality and syntax that has been under discussion for several years. D.C. Sessions asked for a grammar for IBIS. Bob mentioned that he had helped generate an unofficial BNF grammar for IBIS Version 2.1 and will generate an update for Version 3.0. He will put in the ver3.0 subdirectory. AR - Bob Ross generate the approved IBIS Version 3.0 document from the Pending document and the approved BIRDs and changes of this meeting and post the document on vhdl.org. AR - Bob Ross generate and post a BNF for IBIS Version 3.0 Chris Rokusek asked what the parser status was. With Version 3.0 ratified, Bob now has a document which parser development work can be contracted. AR - Bob Ross contact Paul Munsey concerning IBIS Version 3.0 parser development. FINAL ITEMS Steve Kaufer did not need to lead the scheduled discussion on examples for IBIS based on recent reflector e-mail. Adequate discussion already occurred with the IBIS Cookbook presentation. Syed Huq raised the question concerning whether the IBIS Version 3.1 should have better graphics, and perhaps should be a formatted document rather than an ASCII document with character pictures. Word or HTML formats could be considered. This will be a subject for further discussion. Stephen Peters volunteered to be involved with the editorial cleanup activity. Because of holidays and people being on vacation, the next teleconferencing meeting was scheduled on Friday, July 11, 1997. NEXT MEETING: The next meeting is on Friday, July 11, 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, Quad Design/Viewlogic 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@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via FTP anonymous. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Wed Jun 18 10:42:14 1997 Received: from atlantis.erlm.siemens.de (atlantis.erlm.siemens.de [194.174.230.11]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA15233 for ; Wed, 18 Jun 1997 10:42:13 -0700 (PDT) Received: from tcenter.erlm.siemens.de (tcenter.erlm.siemens.de [193.25.63.21]) by atlantis.erlm.siemens.de (8.7.5/8.7.3) with ESMTP id TAA10316; Wed, 18 Jun 1997 19:40:56 +0200 (MET DST) Received: from PGTD0131 (pgtd0131.a45am.erlm.siemens.de [139.25.24.49]) by tcenter.erlm.siemens.de (8.7.5/8.7.3) with SMTP id TAA29662; Wed, 18 Jun 1997 19:36:26 +0200 (MET DST) Received: by PGTD0131 with Microsoft Mail id <01BC7C1F.38AFB180@PGTD0131>; Wed, 18 Jun 1997 19:38:39 +-200 Message-ID: <01BC7C1F.38AFB180@PGTD0131> From: Unger Bernhard To: "'Syed Huq'" Cc: "'ibis@vhdl.org'" Subject: Question on Ramp Date: Wed, 18 Jun 1997 19:38:36 +-200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.vhdl.org id KAA15234 Syed, you wrote s2ibis2 will add 50Ohms pullup to calculate dV/dt_f and 50Ohms pulldown to calculate dV/dt_r values. Looking in the [RAMP] specification of 2.1 IBIS spec. there is only a definition for a R_load sub-parameter but not for a termination voltage. The subparameter is optional if the preferred 50Ohms load is used. Is it obvious that the ramp values given in an IBIS model are valid for the following conditions: dV/dt_f: R_load pullup to VCC ? dV/dt_r: R_load pulldown to GND ? Regards, Bernhard ************************************************************************************ # Dr. Bernhard Unger # Siemens AG # Dept. ANL A45 AM # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 # D-81730 Munich Fax. +49-89-636-44595 # Germany E-Mail Bernhard.Unger@erlm.siemens.de ************************************************************************************ ---------- Von: Syed Huq[SMTP:huq@rockie.nsc.com] Gesendet: Dienstag, 17. Juni 1997 17:36 An: ibis-users@vhdl.org; milan@indusinc.com Betreff: Re: Question on Ramp Milan, s2ibis2 will add 50Ohms pullup and pulldown to calculate dV/dt_f and dV/dt_r values. You can try changing these values to see if your device will switch or not. ...in your .s2i file: [Rising waveform] 500 0 NA NA NA NA NA NA NA [Falling waveform] 500 3.3 NA NA NA NA NA NA NA Try changing the sim time to a larger number too in your .s2i file [sim time] 10ns Regards, Syed National Semiconductor Corp. > From owner-ibis@server.vhdl.org Mon Jun 16 17:27:09 1997 > Date: Mon, 16 Jun 1997 15:51:23 -0700 (PDT) > From: Milan Gandhi > To: ibis-users@vhdl.org > Subject: Question on Ramp > X-Sun-Charset: US-ASCII > > Hi, > This is our first experience with IBIS, so this might > be a trivial issue for you experienced folks !! > > We are getting Ramp (dV/dt) as 0 in ibis inspite of > providing required Voltage values. > What should we be looking for in order to get > correct Ramp values in Ibis model. > We are using tools from NC university. > > -Thanks, Milan > From owner-ibis Wed Jun 18 12:11:14 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 MAA16538 for ; Wed, 18 Jun 1997 12:11:13 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id MAA02933; Wed, 18 Jun 1997 12:06:38 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma002685; Wed, 18 Jun 97 12:06:18 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23707 for Bernhard.Unger@erlm.siemens.de; Wed, 18 Jun 97 12:09:41 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA15570; Wed, 18 Jun 97 12:13:40 PDT Date: Wed, 18 Jun 97 12:13:40 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9706181913.AA15570@rockie.nsc.com> To: huq@rockie.nsc.com, Bernhard.Unger@erlm.siemens.de Subject: Re: Question on Ramp Cc: ibis@vhdl.org Bernhard, It may not be obvious from the spec defination of [Ramp] but under 'NOTES ON DATA DERIVATION METHOD' at the end of the spec, section 3 talks more in details about the pullup to Vcc and pulldown to GND for various I/O structures. Regards, Syed > > Syed, > > you wrote s2ibis2 will add 50Ohms pullup to calculate=20 > dV/dt_f and 50Ohms pulldown to calculate dV/dt_r values. > Looking in the [RAMP] specification of 2.1 IBIS spec. there=20 > is only a definition for a R_load sub-parameter but not for a > termination voltage. The subparameter is optional if the preferred > 50Ohms load is used. > Is it obvious that the ramp values given in an IBIS model are valid > for the following conditions: > > dV/dt_f: R_load pullup to VCC ? > > dV/dt_r: R_load pulldown to GND ? > > Regards, > > Bernhard > From owner-ibis Wed Jun 18 12:59:16 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 MAA17306 for ; Wed, 18 Jun 1997 12:59:15 -0700 (PDT) Received: from us8rmc.bb.dec.com (us8rmc.bb.dec.com [16.53.0.44]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA09108; Wed, 18 Jun 1997 15:41:37 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA19633; Wed, 18 Jun 97 15:27:46 -0400 Message-Id: <9706181927.AA19633@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Wed, 18 Jun 97 15:43:07 EDT Date: Wed, 18 Jun 97 15:43:07 EDT From: Andy Ingraham To: bernhard.unger@erlm.siemens.de Cc: ibis@vhdl.org, ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org, bernhard.unger@erlm.siemens.de Subject: Re: Question on Ramp Bernhard, This is yet another one of those IBIS details where the spec ASSUMES you know what the "preferred" termination voltage is! Actually, the answer is in there, but it forces you to go scavenging through the IBIS spec to find it. (This is one of my big complaints about the IBIS spec.) If you look near the very back of the 2.1 IBIS spec, under the section "NOTES ON DATA DERIVATION METHOD", you will find this: | 3) Ramp Rates: ... | b. If: The Model_type is one of the following: Output, I/O, or | 3-state (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | | If: The Model_type is Output_ECL or I/O_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2 V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either POWER or the vendor- | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the vendor-suggested | termination resistance to either GND or the vendor-suggested | termination voltage. Use this load to derive both the rising | and falling edges. So your assumptions are correct for a standard CMOS/TTL type output buffer. This is one of many areas where the IBIS spec desperately needs fixing. Regards, Andy Ingraham From owner-ibis Wed Jun 18 13:11:25 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA17462 for ; Wed, 18 Jun 1997 13:11:24 -0700 (PDT) Received: from happy.memh.ti.com ([158.218.36.100]) by jester.ti.com (8.8.5) with ESMTP id PAA25111 for ; Wed, 18 Jun 1997 15:09:59 -0500 (CDT) Received: from r2d2.memh.ti.com by happy.memh.ti.com with ESMTP (1.37.109.16/16.2) id AA176424598; Wed, 18 Jun 1997 15:09:58 -0500 From: Vincent Chang Received: from r2d2 (localhost) by r2d2.memh.ti.com id ; Wed, 18 Jun 1997 15:09:55 -0500 Sender: vchang@memh.ti.com Message-Id: <33A84092.5A93@memh.ti.com> Date: Wed, 18 Jun 1997 15:09:54 -0500 X-Mailer: Mozilla 3.0 (X11; I; HP-UX A.09.07 9000/715) Mime-Version: 1.0 To: ibis@vhdl.org Subject: dv/dt measurement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit all, I have a question on rise and fall measurement. In the cook book, it states that the rise and fall time measurement are "no load" measurements; ie, remove the package parameters(L/R/C) before doing the simulation. But, later in Lab measurement section, it states that Capturing rise/fall time data requires either a specific test fixture or a motherboard to which the DUT can be attached. Rise/fall time measurements require an oscilloscope with at least a 4 GHz bandwidth. Take into account the effect on the rise/fall times of the device packaging and capacitive load. So, why it does not use any C_pkg and C_leadfram vaule in rise and fall time measurement in IBIS model. I am generating ibis model from spice. -- Best Regards, Vincent Chang ======================================================================= * Vincent Chang TI MSG ID: hui8 * * Design Automation mailto:vchang@memh.ti.com * * Memory Products Design http://www.memh.ti.com/~mcad * * Texas Instruments Inc. MS 657 Phone: (281) 274-3167 * * PO Box 1443, Houston, TX 77251 Fax: (281) 274-2067 * ======================================================================= From owner-ibis Wed Jun 18 14:34:29 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA18729 for ; Wed, 18 Jun 1997 14:34:29 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id OAA12814 for ; Wed, 18 Jun 1997 14:33:17 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id OAA15457; Wed, 18 Jun 1997 14:33:34 -0700 (PDT) Message-Id: <199706182133.OAA15457@ichips.intel.com> To: ibis@vhdl.org Subject: dv/dt measurement Date: Wed, 18 Jun 1997 14:33:34 -0700 From: Stephen Peters Hello Vincent: Good question, and I will attempt to clarify the cookbook. The purpose of the rise and fall data is to give the simulator information on the devices' pullup and pulldown transistors turn-on/turn-off times. This data should not include any degredation of rise/fall time due to packaging effects. In a simulation environment generating the 'transistor only' data is not a problem -- simply remove the package from the simualtion. Unfortunetly, in a measurement environment one cannot remove the package and so any data gathered will include package effects. What the model maker must do in that case is as described in the cookbook: "Using the known packaging parameters and measured I-V curves, construct a simulation model of the device using a best guess of the rise/fall time. With an IBIS simulator, adjust the rise/fall times in the model until the simulation results match the oscilloscope waveforms." Note that in either case (simulation or measurment) do NOT include a load capacitor on the output. Adding a load capacitor only complicates things. Regards, Stephen Peters Intel Corp. all, I have a question on rise and fall measurement. In the cook book, it states that the rise and fall time measurement are "no load" measurements; ie, remove the package parameters(L/R/C) before doing the simulation. But, later in Lab measurement section, it states that Capturing rise/fall time data requires either a specific test fixture or a motherboard to which the DUT can be attached. Rise/fall time measurements require an oscilloscope with at least a 4 GHz bandwidth. Take into account the effect on the rise/fall times of the device packaging and capacitive load. So, why it does not use any C_pkg and C_leadfram vaule in rise and fall time measurement in IBIS model. I am generating ibis model from spice. -- Best Regards, Vincent Chang ======================================================================= * Vincent Chang TI MSG ID: hui8 * * Design Automation mailto:vchang@memh.ti.com * * Memory Products Design http://www.memh.ti.com/~mcad * * Texas Instruments Inc. MS 657 Phone: (281) 274-3167 * * PO Box 1443, Houston, TX 77251 Fax: (281) 274-2067 * ======================================================================= From owner-ibis Wed Jun 18 12:54:16 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 MAA17187; Wed, 18 Jun 1997 12:54:15 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #1) id ; Wed, 18 Jun 1997 12:53:21 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Wed, 18 Jun 1997 12:53:05 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for bob; Wed, 18 Jun 1997 12:53:08 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Wed, 18 Jun 1997 12:53:08 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org, ibis@vhdl.org Subject: IBIS Version 3.0 on vhdl.org To IBIS Committee: I have uploaded the approved IBIS Version 3.0 specification to vhdl.org under /pub/ibis/ver3.0/ver3_0.ibs (also ver3_0.txt). Please destroy any prior versions you may have obtained under the wip directory since they are not valid. IBIS Version 3.0 was ratified at the June 12, 1997 EIA/IBIS Open Forum Summit meeting. The uploaded version contains some minor editoral changes for format consistency and alignment and some other changes such as replacing IV "curves" with "tables". The new features based on approved BIRDs contained in Version 3.0 consists of these extensions: [Model Selector] keyword for programmable buffers (BIRD30.2) [TTgnd], [TTpower] keywords for stored charge effects (BIRD34.2) [Driver Schedule] keyword for multi-staged outputs (BIRD35.3) Electrical Board Description for .ebd file and keywords(BIRD36.3): [Begin Board Description], [Manufacturer], [Number Of Pins], [PIn List], [Path Description], [Reference Designator Map], [End Board Description] Package Model Extensions (BIRD28.3 and BIRD37.3): [Number Of Sections], [Pin Numbers] extension, [Model Spec] keyword and subparameters (BIRD39 and BIRD40) Series and Series Switch Extensions (BIRD41.8) including keywords: Under [Component]: [Series Switch Groups], [Series Pin Mapping] Under [Model] [Series Current], [Series MOSFET] for IV data [R Series], [L Series], [Rl Series], [C Series], [Rc Series], [Lc Series] for RLC series paths [On], [Off] for Series_switch models [Component] test point subparameters (BIRD43) Bob Ross Interconnectix From owner-ibis Fri Jun 20 10:45:26 1997 Received: from c2smtp.eia.org (eia.org [207.17.181.10]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id KAA29621 for ; Fri, 20 Jun 1997 10:45:25 -0700 (PDT) Received: from Connect2 Message Router by c2smtp.eia.org via Connect2-SMTP 4.20A; Fri, 20 Jun 1997 13:36:22 -0400 Message-ID: <5DC9113B01301700@c2smtp.eia.org> Date: Fri, 20 Jun 1997 13:41:00 -0400 From: Patti Rusher Sender: Patti Rusher Organization: EIA To: ibis@vhdl.org Subject: IBIS Press Release X-Mailer: Connect2-SMTP 4.20A MHS/SMF to SMTP Gateway Please find below the press release announcing IBIS Version 3.0 ratification. Patti For Further Information Contact: Mark V. Rosenker For Immediate Release: Vice President Public Affairs June 19, 1997 (703) 907-7790 PR 97-30 EIA Ratifies IBIS Version 3.0 During Design Automation Conference Arlington, VA-- The Electronic Industries Association (EIA) announces the ratification of the Input/Output Buffer Information Specification (IBIS) Version 3.0. The new version was ratified by the EIA IBIS Committee during the Design Automation Conference on June 12, 1997, in Anaheim, California. IBIS Version 3.0 provides a format for new functionality requested by users, semiconductor vendors and computer aided engineering (CAE) vendors. Additionally, new IBIS Committee Officers for 1997-1998 were elected during the Design Automation Conference. Bob Ross, of the Interconnectix unit of Mentor Graphics, was named chair; Syed Huq of National Semiconductor was elected vice-chair; Stephen Peters of Intel Corporation was named secretary; and Jon Powell of the Quad Design unit of Viewlogic was named librarian. Committee Chair Bob Ross, in commenting on the ratification of Version 3.0, stated, "I am pleased that we are moving forward on this important project. IBIS Version 3.0 meets the immediate needs of those in our industry and allows us to move on to the next step." Version 3.0 extensions include driver selection of buffers, diode stored charge modeling, package model extensions for lines and sections, electrical board descriptions for SIMMS, multistage drivers, series components and series switches, as well as specification and information enhancements. IBIS Version 3.0 supports all the functionality of ANSI/EIA-656 (Version 2.1) and Version 1.1. Version 3.0 serves as the baseline for new IBIS parser development and editorial review leading to an anticipated Version 3.1. Information about IBIS Version 3.0 can be obtained through the EIA/IBIS Committee by sending a request to ibis-info@vhdl.org or by contacting EIA's Patti Rusher at pattir@eia.org. For more than 73 years the Electronic Industries Association has been the national trade organization representing U.S. electronics manufacturers. EIA represents the entire spectrum of companies involved in the design and manufacture of electronic components, parts, systems and equipment for communications, industrial, government and consumer uses. # # # EDITORS: Please note that information regarding the Electronic Industries Association is available via EIA's World Wide Web Site at http://www.eia.org. From owner-ibis Fri Jun 27 03:07:25 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 DAA18666 for ; Fri, 27 Jun 1997 03:07:23 -0700 (PDT) Received: from s15.fh-landshut.de by s1.fh-landshut.de with SMTP (1.38.193.4/16.2) id AA05644; Fri, 27 Jun 1997 12:06:11 +0200 Sender: schwa1@fh-landshut.de Message-Id: <33B39098.7B8A@fh-landshut.de> Date: Fri, 27 Jun 1997 12:06:16 +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: info-tms320C31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello! Is there anyone, having an ibis-modell for the tms320c31 (digital signalprocessor)? Who can give me some information for creating an ibis-modell for this? Besides I want to know, whether IBIS-modells are better appropriated for CMOS-technologies than for TTL-technologies. Thank you! email: schwa1@fh-landshut.de