From Will_Hobbs@ccm2.jf.intel.com Wed Feb 1 09:01:43 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00389; Wed, 1 Feb 95 09:01:43 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rZiME-000UdQC; Wed, 1 Feb 95 08:56 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rZiMD-000twgC; Wed, 1 Feb 95 08:56 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 1 Feb 95 08:56:40 PST Date: Wed, 1 Feb 95 08:56:40 PST From: Will Hobbs Message-Id: <950201085640_1@ccm.jf.intel.com> To: ibis@vhdl.org Subject: 4th Beta of Golden Parser 2.1 going out today Text item: Text_1 IBIS Golden Parser licensees: I have received the (hopefully) final version of the IBIS 2.1 Golden Parser Source. It is being mailed out today to the companies who have licensed it. Paul and Ron believe this version should be good enough to remove the term. Please look it over and provide whatever feedback you can to Ron and Paul. Paul's e-mail address is 73053.721@compuserve.com Regards, Will From raghu@berlioz.nsc.com Thu Feb 2 10:38:05 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15741; Thu, 2 Feb 95 10:38:05 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA10601 for ibis@vhdl.org; Thu, 2 Feb 95 10:33:10 -0800 Received: from berlioz.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA10241 for ibis@vhdl.org; Thu, 2 Feb 95 10:33:09 -0800 Received: from snappy.nsc.com by berlioz.nsc.com (4.1/SMI-4.1) id AA28929; Thu, 2 Feb 95 10:30:08 PST Date: Thu, 2 Feb 95 10:30:08 PST From: raghu@berlioz.nsc.com (Raj Raghuram) Message-Id: <9502021830.AA28929@berlioz.nsc.com> To: ibis@vhdl.org Subject: Clarifications on IBIS standard Cc: chai@rockie.nsc.com Clarifications on IBIS standard We are in the process of making IBIS models and there were a few items in the standard and in the discussions which were not clear to us. I hope somebody can clear these issues. 1. When is the Golden Parser for version 2.0 likely to be ready ? 2. It is rightly pointed out that the pulldown and pullup characteristic for tristate outputs may be non-monotonic. The standard says that this can happen in at most one place. The i-v characteristic may then locally have a negative resistance. Will this not pose a problem to simulators ? 3. During a transition, it is not clear whether the pullup or pulldown characteristics should be used by a simulator. This is not a problem for making the IBIS models, but only for using them in a simulator. 4. Is there a provision for specifying a pad or die resistance i.e R_comp in addition to C_comp? 5. The standard does not explicity specify the nature of the input ramp in obtaining ramp rates. What should be the input rise time as well as the high and low values of the input pulse? Perhaps many of these issues have been thrashed out at different forums. I would be greatly obliged if somebody would educate me on this. Raj Raghuram National Semiconductor 2900 Semiconductor Drive Mail Stop D3-677 Santa Clara, CA-95052 email: raghu@berlioz.nsc.com Phone: (408) 721-6220 (O) Phone: (408) 252-1285 (H) From Derrick_Duehren@ccm2.jf.intel.com Thu Feb 2 10:41:02 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15746; Thu, 2 Feb 95 10:41:02 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0ra6Nz-000UhBC; Thu, 2 Feb 95 10:36 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0ra6Nw-000twjC; Thu, 2 Feb 95 10:36 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 2 Feb 95 10:36:03 PST Date: Thu, 2 Feb 95 10:36:03 PST From: Derrick Duehren Message-Id: <950202103603_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Open Forum 2/6/95 Summit Meeting Agenda Text item: Text_1 IBIS Open Forum Summit Meeting Agenda 2/6/95 9:30 am - 5:00 pm Intel Robert Noyce Building 2200 Mission College Blvd., Santa Clara 9:30 Check-in, Intros, Announcements Hobbs - Introductions - Miscellany/announcements/door prize 10:00 EIA discussion (phone bridge available) Hobbs - IBIS Open Forum scope discussion - Membership fees, grandfathering - Assignment of 1.1 and 2.1 spec copyrights - Officer elections effectivity date - Election of officers 11:30 Future direction discussion (3.0 possibilities) Hobbs Noon Lunch 12:30 Diode storage effects (time delay effects) Schryer [Tim Schryer has been ill and may present via call-in.] Diode storage effects Powell 1:30 Handling multiple personality drivers discussion Ward 2:00 Issues Regarding Min and Max Model Data (30 min) Ross 2:30 Gate Modulation and Replacing Min., and Max. Muranyi Tables with Scaling Factors (60 min) 3:30 Series termination discussion Kumar 4:00 Alternative packaging representations discussion Peters 4:30 Wrap up, schedule next meeting. BIN LIST (if we have time) Inter-simulation correlation discussion Hobbs Kumar's Egg ? Model validation ? ------------------------------------------------------------------- FOOD ORDER FOR 20: 9:00 Fruit trays, muffins, donuts, coffee, and juice Noon Box lunches w/chips, cookies, and fruit. Coffee and soda (2 meals are vegetarian) 2:30 Cookies, fruit, coffee, soda From fvance@FirePower.COM Thu Feb 2 12:19:39 1995 Return-Path: Received: from FirePower.COM (copan.FirePower.COM) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16666; Thu, 2 Feb 95 12:19:39 PST Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA14855; Thu, 2 Feb 95 11:56:53 -0800 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA19558; Thu, 2 Feb 95 12:12:37 -0800 From: Fred Vance Message-Id: <9502022012.AA19558@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA04432; Thu, 2 Feb 95 12:12:33 -0800 Date: Thu, 2 Feb 95 12:12:33 -0800 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: ibis@vhdl.org, si-list@silab.Eng.Sun.COM Subject: Re: Clarifications on IBIS standard Raj, Items 3 through 5 are also of interest to me. I too have been wondering if ibis@vhdl.org is the proper forum for those of us who are interested in the application of IBIS data rather than the creation of IBIS data and standards. It seems to me from the regular IBIS participation that there are mostly representatives of IC and EDA tools vendors. I am sure that the tool vendors will eventually offer means of using IBIS data with their tools. In the meantime, some of the tool users (like me) must be struggling along trying to use IBIS data as it becomes available (and changes form). I recently subscribed to the SI reflector, si-list@silab.Eng.Sun.COM (subscribe to si-admin@silab.eng.sun.com), but in the past two weeks, I've seen very little discussion, an nothing relating to IBIS use. If you want, I could let you know what I've been doing with IBIS data, but maybe I should take it off-line. I would like to hear opionions regarding the proper forum for IBIS use from all you IBISians and SI-listians out there. Fred fvance@FirePower.com FirePower Systems, Inc. 190 Independence Dr. Menlo Park, CA 94025 (415) 462-3055 Begin forwarded message: Date: Thu, 2 Feb 95 10:30:08 PST From: raghu@berlioz.nsc.com (Raj Raghuram) To: ibis@vhdl.org Subject: Clarifications on IBIS standard Cc: chai@rockie.nsc.com Clarifications on IBIS standard We are in the process of making IBIS models and there were a few items in the standard and in the discussions which were not clear to us. I hope somebody can clear these issues. 1. When is the Golden Parser for version 2.0 likely to be ready ? 2. It is rightly pointed out that the pulldown and pullup characteristic for tristate outputs may be non-monotonic. The standard says that this can happen in at most one place. The i-v characteristic may then locally have a negative resistance. Will this not pose a problem to simulators ? 3. During a transition, it is not clear whether the pullup or pulldown characteristics should be used by a simulator. This is not a problem for making the IBIS models, but only for using them in a simulator. 4. Is there a provision for specifying a pad or die resistance i.e R_comp in addition to C_comp? 5. The standard does not explicity specify the nature of the input ramp in obtaining ramp rates. What should be the input rise time as well as the high and low values of the input pulse? Perhaps many of these issues have been thrashed out at different forums. I would be greatly obliged if somebody would educate me on this. Raj Raghuram National Semiconductor 2900 Semiconductor Drive Mail Stop D3-677 Santa Clara, CA-95052 email: raghu@berlioz.nsc.com Phone: (408) 721-6220 (O) Phone: (408) 252-1285 (H) From Derrick_Duehren@ccm2.jf.intel.com Thu Feb 2 12:26:05 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16701; Thu, 2 Feb 95 12:26:05 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0ra81d-000UipC; Thu, 2 Feb 95 12:21 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0ra81d-000twfC; Thu, 2 Feb 95 12:21 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 2 Feb 95 12:21:08 PST Date: Thu, 2 Feb 95 12:21:08 PST From: Derrick Duehren Message-Id: <950202122108_4@ccm.hf.intel.com> To: Randy_L_Wilhelm@ccm.fm.intel.com, IBIS@vhdl.org Subject: Minutes from IBIS Open Forum Meeting 1/27/95 Text item: Text_1 Date: Feb. 2, 1995 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, OR 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum Meeting 1/27/95 To: ARPA Randy Harr AT&T Global Info Solutions Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar Cadlab Ralf Bruning Contec Dileep Divkar Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HP Palo Alto Tom Langdorf HyperLynx Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, John Burnett INCASES Werner Rissiek, Olaf Rethmeier* Integrated Silicon Systems Eric Bracken Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei, John Sliney MicroSim Arthur Wong National Semiconductor Syed Huq NEC Hiroshi Matsumoto North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn PC Ware Paul Munsey, Ron Neville Quad Design Jon Powell Quantic Labs Mike Ventham Racal-Redac John Berrie Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zeelan Technology George Opsahl, Hiro Moriyasu CC: Intel Corporation Randy Wilhelm, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 2/6/95 (916) 356-9999 TBD (Face-to-face summit w/teleconference for EIA decisions 10:00 - Noon PDT) All meetings are 8:00 AM to 10:00 AM PDT (16:00 to 18:00 UTC). 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------------ Check-in, Intros, Announcements There were no new participants. There were no corrections made to last month's minutes. Will announced that Intel has sent linear Pentium(R) processor IBIS models to Michael Steer for posting to vhdl.org. Kellee reported that Xylinx has created IBIS models for their 3000A family and are working on their 4000 family. The 3000A family models are being tested by some "beta" customers. They plan to release a complete model set in March. New Agenda Items: BIRD 25 introduction. Press Updates: The Press Release we worked on over the reflector is being released through Intel MarCom today. Bob Ross reported that IBIS was mentioned in two articles: Jan `95 of Printed Circuit Design EDN, Jan 19, Sig. Integrity Tools. Golden Parser 2.1 progress and release date Will read a message from Paul Munsey We still need another pass through the latest changes before we can call it "2.1" (Bob Ross has more tweaks, two-point tables in waveforms/"NA" issue and Pin Mapping keyword accepting NA when NC is the correct term). We will leave "beta" on it for now. Package model support in the parser has not yet been fully validated. AR Bob R -- Send out the test matrix with updates. AR Will -- Communicate the Beta status to Paul. AR Will -- Ask Paul to run the vhdl.org models through the parser before release. [Update: The 4th, and hopefully final, beta version was mailed out on 2/1/95.] Status of EIA affiliation Patti Rusher, of the EIA/Electronic Information Group of EIA, joined us for a discussion of Derrick's affiliation proposals. Many items are to be discussed and voted on at the 2/6/95 summit meeting (such as scope, dues structure, copyrights, etc.). Refer to the 2nd draft proposal posted 1/27/95 for details. AR Derrick -- Send IBIS roster.txt to Patti. [DONE] 1.1 Spec will remain in public domain. After discussing the merits of putting the 2.1 Spec in the public domain, we decided to turn over the copyright to EIA. It can still be on reflector. AR Patti -- Send boilerplate licensing documents to Will. AR Will -- Ask Ron/Paul to assign Golden Parser rights to EIA. [Update: DONE. Waiting for boilerplate copyright assignment text from Intel Legal.] AR Will/Derrick -- Find out what we need to do to release Intel copyright on the Overview, Cookbook, and EDN article documents. [Update: Work in progress.] AR Patti -- Send letter to roster.txt announcing EIA formation, dues, membership request. We decided to have one company, one vote. Subsidiaries cannot vote separately. AR Will -- Communicate to Patti decisions on fees and grandfatherhood made at the summit meeting before 2/10 (Patti has executive committee meeting on 2/10). Meeting minutes will remain the responsibility of the Forum (secretary's duty). The EIA will handle all Press Releases. A treasurer is not needed. EIA will provide accounting services. Meeting minutes will go through EIA legal before distribution. Patti will soon be on the Internet as prusher@eia.org. We will hold EIA-IBIS officer elections on 2/6, with the new officers taking over later (TBD, e.g., after the grandfather issues are resolved). IBIS General Session/Summit (face-to-face) AR Will -- Ask Tim Schryer to scrub his ringback paper and bring copies to the summit. [Update: DONE. Tim has been ill all week and probably will not attend. He may present by phone, however.] AR Summit Speakers -- Send titles, timing to Derrick. AR Derrick -- Set up 10:00 am phone bridge for EIA discussion. BIRD 25 introduction. Bob introduced BIRD 25. It clarifies the test conditions discussion. C_comp change may be controversial, as min for everything else implies slow, where for C_comp, min values are associated with fast corners. Wrap-up, Next Meeting Plans Our next meetings are the summit meeting 2/6/95 in Santa Clara and a normal teleconference 2/24/95. ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From speters@ichips.intel.com Thu Feb 2 13:44:08 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17413; Thu, 2 Feb 95 13:44:08 PST Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Thu, 2 Feb 95 13:39:11 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 2 Feb 95 13:39:06 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 2 Feb 95 13:39:06 PST Message-Id: <9502022139.AA04906@xtg801.intel.com> To: raghu@berlioz.nsc.com To: ibis@vhdl.org Subject: Clarifications on IBIS standard Date: Thu, 02 Feb 1995 13:39:05 -0800 From: Stephen Peters Hello Raj: I can answer some of your questions, my comments are prefixed by >> Regards, Stephen Peters Intel, Corp. (503) 696-4108 Clarifications on IBIS standard We are in the process of making IBIS models and there were a few items in the standard and in the discussions which were not clear to us. I hope somebody can clear these issues. 1. When is the Golden Parser for version 2.0 likely to be ready ? 2. It is rightly pointed out that the pulldown and pullup characteristic for tristate outputs may be non-monotonic. The standard says that this can happen in at most one place. The i-v characteristic may then locally have a negative resistance. Will this not pose a problem to simulators ? >> The IBIS standard specifies that the pullup and pulldown curves >> contain pullup and pulldown data ONLY, i.e. in the region where >> the clamp diodes are active the current due to the clamp diodes must >> be subtracted from the pullup/pulldown current. This is where the >> non-monotonic curves come from -- at the extremes of the I/V curves >> where you are subtracting a large diode current from the combined >> diode/on-state-IV curve. In practice, a simulator sums the two >> currents together (power clamp and pullup or gnd clamp and pulldown) >> thereby making the result monotonic. 3. During a transition, it is not clear whether the pullup or pulldown characteristics should be used by a simulator. This is not a problem for making the IBIS models, but only for using them in a simulator. >> Which curve to use and how they transistion is a characteristic >> of the simulator. In general, the purpose of the IBIS standard >> is to present consistant data in a consistant format and not to >> specify how simulators are to use the data. 4. Is there a provision for specifying a pad or die resistance i.e R_comp in addition to C_comp? >> No. The effects of a pad or die resistance are >> accounted for in the I/V curves. 5. The standard does not explicity specify the nature of the input ramp in obtaining ramp rates. What should be the input rise time as well as the high and low values of the input pulse? Perhaps many of these issues have been thrashed out at different forums. I would be greatly obliged if somebody would educate me on this. Raj Raghuram National Semiconductor 2900 Semiconductor Drive Mail Stop D3-677 Santa Clara, CA-95052 email: raghu@berlioz.nsc.com Phone: (408) 721-6220 (O) Phone: (408) 252-1285 (H) From Derrick_Duehren@ccm2.jf.intel.com Thu Feb 2 14:33:08 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17853; Thu, 2 Feb 95 14:33:08 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0raA0b-000Uk3C; Thu, 2 Feb 95 14:28 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0raA0a-000twhC; Thu, 2 Feb 95 14:28 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 2 Feb 95 14:28:12 PST Date: Thu, 2 Feb 95 14:28:12 PST From: Derrick Duehren Message-Id: <950202142812_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Phone Bridge for 2/6 IBIS Summit Text item: Text_1 IBISians, If you are not attending the 2/6/95 IBIS Summit in person, you can still participate in the EIA affiliation discussions/decisions. The phone bridge number for the EIA discussion portion of the IBIS Summit is below. The discussion will start at 10:00 am. Phone Number: (916) 356-9999 Res. Number: 450808 Derrick Duehren ------------------------------------------------------------------------------ XTG TPV Programs Manager, Intel Corp. | Phone (503) 696-4299 | "Experience is not what happens to Fax (503) 696-4904 | you; it's what you do with what Derrick_Duehren@ccm.jf.intel.com | happens to you." 5200 NE Elam Young Pkwy. JF1-97 | - Aldous Huxley Hillsboro, OR 97224 | ------------------------------------------------------------------------------ From Derrick_Duehren@ccm2.jf.intel.com Thu Feb 2 14:55:32 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18177; Thu, 2 Feb 95 14:55:32 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0raALi-000Uf4C; Thu, 2 Feb 95 14:50 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0raALi-000twnC; Thu, 2 Feb 95 14:50 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 2 Feb 95 14:50:01 PST Date: Thu, 2 Feb 95 14:50:01 PST From: Derrick Duehren Message-Id: <950202145001_1@ccm.hf.intel.com> To: speters@ichips.intel.com, IBIS@vhdl.org, billd@reprise.com Subject: Re: To Many Hops >> IBIS Reflector Stephen, Yes, I know. I get them on every message I send out. It is very annoying. I have forwarded many requests to ibis-request to have these names removed from the reflector list, but the list has not been changed and we are still getting the messages. I would edit the file if I could, but it's a >8 character UNIX filename so I can only read it with my DOS/Windows machine. Invalid Addresses: kerryp@arnie.xilinx.com canyimi@pcocd2.intel.com jeff@deutsch.com dermott@contec.com maah@contec.com - Derrick ______________________________ Reply Separator _________________________________ Subject: To Many Hops Author: Stephen Peters at JFCCM3 Date: 2/2/95 1:55 PM Hello Derrick: I sent out a message to the IBIS reflector and the following bounced. Just thought I'd let you know.... Stephen <-- to many hops 501 ... 550 Host unknown (Name server: karoshi.vlsi.com.: host not found From Will_Hobbs@ccm2.jf.intel.com Thu Feb 2 15:48:04 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18765; Thu, 2 Feb 95 15:48:04 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0raBAj-000Uj9C; Thu, 2 Feb 95 15:42 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0raBAi-000twfC; Thu, 2 Feb 95 15:42 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 2 Feb 95 15:42:44 PST Date: Thu, 2 Feb 95 15:42:44 PST From: Will Hobbs Message-Id: <950202154244_4@ccm.jf.intel.com> To: fvance@FirePower.COM, ibis@vhdl.org, si-list@silab.Eng.Sun.COM Subject: Re[2]: Clarifications on IBIS standard Text item: Fred, Please post your questions and comments to this reflector. We have a good group of people here who are more than willing to help. We are interested in problems, observations or questions you have. The 2.1 Spec does offer new data in the models, but retains 1.1 backward compatibility. Backward compatibility is one of our guiding principles, to avoid scaring people off with a spec that is evolving to better meet the needs of the engineers using the models. Regards, Will Hobbs Intel Corp. Raj, Items 3 through 5 are also of interest to me. I too have been wondering if ibis@vhdl.org is the proper forum for those of us who are interested in the application of IBIS data rather than the creation of IBIS data and standards. It seems to me from the regular IBIS participation that there are mostly representatives of IC and EDA tools vendors. I am sure that the tool vendors will eventually offer means of using IBIS data with their tools. In the meantime, some of the tool users (like me) must be struggling along trying to use IBIS data as it becomes available (and changes form). I recently subscribed to the SI reflector, si-list@silab.Eng.Sun.COM (subscribe to si-admin@silab.eng.sun.com), but in the past two weeks, I've seen very little discussion, an nothing relating to IBIS use. If you want, I could let you know what I've been doing with IBIS data, but maybe I should take it off-line. I would like to hear opionions regarding the proper forum for IBIS use from all you IBISians and SI-listians out there. Fred fvance@FirePower.com FirePower Systems, Inc. 190 Independence Dr. Menlo Park, CA 94025 (415) 462-3055 Begin forwarded message: Date: Thu, 2 Feb 95 10:30:08 PST From: raghu@berlioz.nsc.com (Raj Raghuram) To: ibis@vhdl.org Subject: Clarifications on IBIS standard Cc: chai@rockie.nsc.com Clarifications on IBIS standard We are in the process of making IBIS models and there were a few items in the standard and in the discussions which were not clear to us. I hope somebody can clear these issues. 1. When is the Golden Parser for version 2.0 likely to be ready ? 2. It is rightly pointed out that the pulldown and pullup characteristic for tristate outputs may be non-monotonic. The standard says that this can happen in at most one place. The i-v characteristic may then locally have a negative resistance. Will this not pose a problem to simulators ? 3. During a transition, it is not clear whether the pullup or pulldown characteristics should be used by a simulator. This is not a problem for making the IBIS models, but only for using them in a simulator. 4. Is there a provision for specifying a pad or die resistance i.e R_comp in addition to C_comp? 5. The standard does not explicity specify the nature of the input ramp in obtaining ramp rates. What should be the input rise time as well as the high and low values of the input pulse? Perhaps many of these issues have been thrashed out at different forums. I would be greatly obliged if somebody would educate me on this. Raj Raghuram National Semiconductor 2900 Semiconductor Drive Mail Stop D3-677 Santa Clara, CA-95052 email: raghu@berlioz.nsc.com Phone: (408) 721-6220 (O) Phone: (408) 252-1285 (H) Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Clarifications on IBIS standard To: ibis@vhdl.org, si-list@silab.Eng.Sun.COM Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 2 Feb 95 12:12:33 -0800 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA04432; Thu, 2 Feb 95 12:12:33 -0800 Message-Id: <9502022012.AA19558@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA19558; Thu, 2 Feb 95 12:12:37 -0800 Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA14855; Thu, 2 Feb 95 11:56:53 -0800 Received: from FirePower.COM ([198.4.104.7]) by Sun.COM (sun-barr.Sun.COM) id AA17285; Thu, 2 Feb 95 12:16:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00079; Thu, 2 Feb 1995 12:16:58 -0800 Received: from Eng.Sun.COM (tuna) by silab.Eng.Sun.COM (4.1/SMI-4.1) id AA00218; Thu, 2 Feb 95 12:14:28 PST Received: from silab.Eng.Sun.COM (silab-188.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI id AA08005; Thu, 2 Feb 1995 12:17:32 -0800 Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20309; Thu, 2 Feb 95 12:20:11 PST Received: from koriel.Sun.COM by hermes.intel.com (5.65/10.0i); Thu, 2 Feb 95 12 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 2 Feb 95 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0ra8Ig-000twfC; Thu, 2 Feb 95 12:38 PST From Derrick_Duehren@ccm2.jf.intel.com Thu Feb 2 17:24:01 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19365; Thu, 2 Feb 95 17:24:01 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0raCfy-000UjLC; Thu, 2 Feb 95 17:19 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0raCfy-000twfC; Thu, 2 Feb 95 17:19 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 2 Feb 95 17:19:05 PST Date: Thu, 2 Feb 95 17:19:05 PST From: Derrick Duehren Message-Id: <950202171905_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Revised IBIS Open Forum Summit Meeting Agenda Text item: Text_1 Revised (*) IBIS Open Forum Summit Meeting Agenda 2/6/95 9:30 am - 5:00 pm Intel Robert Noyce Building 2200 Mission College Blvd., Santa Clara 9:30 Check-in, Intros, Announcements Hobbs - Introductions - Miscellany/announcements/door prize 10:00 EIA discussion (phone bridge available) Hobbs - IBIS Open Forum scope discussion - Membership fees, grandfathering - Assignment of 1.1 and 2.1 spec copyrights - Officer elections effectivity date - Election of officers 11:30 Future direction discussion (3.0 possibilities) Hobbs Noon Lunch 12:30 Diode storage effects (time delay effects) Schryer [Tim Schryer has been ill and may present via call-in.] Diode storage effects Powell 1:30 Handling multiple personality drivers discussion Ward 2:00 Issues Regarding Min and Max Model Data (30 min) Ross 2:30 Gate Modulation and Replacing Min., and Max. Muranyi Tables with Scaling Factors (60 min) *3:30 Inter-simulation correlation discussion Hobbs 4:00 Alternative packaging representations discussion Peters 4:30 Wrap up, schedule next meeting. BIN LIST (if we have time) * Series termination discussion Kumar Kumar's Egg ? Model validation ? * IBIS models/physical packages/circuit blocks Kumar ------------------------------------------------------------------- FOOD ORDER: 9:00 Fruit trays, muffins, donuts, coffee, and juice Noon Box lunches w/chips, cookies, and fruit. Coffee and soda (2 meals are vegetarian) 2:30 Cookies, fruit, coffee, soda From fvance@FirePower.COM Thu Feb 2 17:42:37 1995 Return-Path: Received: from FirePower.COM (copan.FirePower.COM) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19461; Thu, 2 Feb 95 17:42:37 PST Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA16153; Thu, 2 Feb 95 17:19:23 -0800 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA28122; Thu, 2 Feb 95 17:36:20 -0800 From: Fred Vance Message-Id: <9502030136.AA28122@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA04535; Thu, 2 Feb 95 17:36:18 -0800 Date: Thu, 2 Feb 95 17:36:18 -0800 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: Will Hobbs , ibis@vhdl.org Subject: IBIS Model Users Will, Thanks for your reply. I hope I didn't appear negative about ibis@vhdl.org. I am impressed with the cooperative spirit, professional attitude, and progress of the ibis group. More importantly, I believe the IBIS standard is going to benefit everyone. If it's of any interest, I've received 8 responses to my query: 1 ibis response, 1 ibis/si-list response, 1 undetermined, and 5 returned mail. I'm rather surprised since there are over 280 subscribers to the si-list. ;) Fred FirePower Systems >Date: Thu, 2 Feb 95 15:42:44 PST >From: Will Hobbs >To: fvance@FirePower.COM, ibis@vhdl.org, si-list@silab.Eng.Sun.COM >Subject: Re[2]: Clarifications on IBIS standard > > >Text item: > >Fred, > >Please post your questions and comments to this reflector. We have a good group >of people here who are more than willing to help. We are interested inproblems, >observations or questions you have. From bob@icx.com Thu Feb 2 18:23:09 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19686; Thu, 2 Feb 95 18:23:09 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 2 Feb 95 18:17 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 2 Feb 95 18:19 PST Message-Id: Date: Thu, 2 Feb 95 18:19 PST From: bob@icx.com ( Bob Ross) To: fvance@FirePower.COM, ibis@vhdl.org, si-list@silab.Eng.Sun.COM Subject: Re: Clarifications on IBIS standard Cc: raghu@berlioz.nsc.com Fred and Raj: As Will Hobbs, Chairman of IBIS Forum responded, the ibis@vhdl.org reflector is the appropriate place to ask questions. Several questions have resulted in good discussions and refinements to IBIS. Here are some of my thoughts on your questions. (1) The Golden Parser is in the final stages of review, and the final version is expected shortly (weeks). We cannot commit to an exact date. (2) Monotonicity has been a big concern with the committee and has generated a lot of discussion. Some simulators are more sensitive to non-monotonic data than others. Without getting totally bogged down in this discussion here, I will just respond that some [Pulldown] tables are non-monotonic in the negative voltage region. When the data is summed with the [GND Clamp] table, the TOTAL table is monotonic. Even simulators that are sensitve to non-monotonic data will usually handle this case. The Golden Parser gives a non-monotonic data warning. So, if necessary, you can adjust the data. The overall philosophy in allowing non-monotonic tables is that IBIS presents raw data extractions without appling any particular data modification strategy which would corrupt the data. (3) The transition algorithms regarding the [Pulldown] and [Pullup] tables will probably be different between simulator companies. Also, some companies convert the IBIS data into their internal representations, so their existing transition algorithms are used. Generally, the transition algorithms are not public. The Waveform table extension in IBIS Version 2.0 captures actual reponses and can be used to check the accuracy and/or to shape the transitions. (4) Adjustments to the [GND Clamp] table can be made to create an effective R_comp if it is parallel to C_comp. If the resistance is in series, it possibly can be lumped with R_pin or the default R_pkg sub-parameters. We need to know about the specific concerns to provide more detail. (5) You are right, IBIS does not provide an Input pulse specification for deriving Ramp rates (and Waveform Tables). A reasonable guideline is to mimic actual conditions for which the device would be used. Therefore it is probably better not to mandate a specific condition. The voltage swing should be appropriate for the technology, e.g., 0 to 5V for CMOS and about 0 to 3V for TTL. A signal faster than the expected Ramp rates is my preference, although a case could be made to provide a response that mimics the data book input ramps specified for timing tests. Possibly a 50 Ohm series resistance approximating the pulser source impedance and trace environment to the device input should be included. However, since the actual thresholds are narrow (several 100 mV), the Ramp rates and Waveform tables should not differ significantly for any reasonable, appropriate Input. Bob Ross, Interconnectix, Inc. > Raj, > Items 3 through 5 are also of interest to me. I too have been wondering if > ibis@vhdl.org is the proper forum for those of us who are interested in the > application of IBIS data rather than the creation of IBIS data and standards. > It seems to me from the regular IBIS participation that there are mostly > representatives of IC and EDA tools vendors. I am sure that the tool vendors will > eventually offer means of using IBIS data with their tools. In the meantime, some > of the tool users (like me) must be struggling along trying to use IBIS data as it > becomes available (and changes form). > I recently subscribed to the SI reflector, si-list@silab.Eng.Sun.COM (subscribe to > si-admin@silab.eng.sun.com), but in the past two weeks, I've seen very little > discussion, an nothing relating to IBIS use. > If you want, I could let you know what I've been doing with IBIS data, but maybe I > should take it off-line. > I would like to hear opionions regarding the proper forum for IBIS use from all > you IBISians and SI-listians out there. > Fred > fvance@FirePower.com > FirePower Systems, Inc. > 190 Independence Dr. > Menlo Park, CA 94025 > (415) 462-3055 > Begin forwarded message: > Date: Thu, 2 Feb 95 10:30:08 PST > From: raghu@berlioz.nsc.com (Raj Raghuram) > To: ibis@vhdl.org > Subject: Clarifications on IBIS standard > Cc: chai@rockie.nsc.com > Clarifications on IBIS standard > We are in the process of making IBIS models and there were a few items > in the standard and in the discussions which were not clear to us. I hope > somebody can clear these issues. > 1. When is the Golden Parser for version 2.0 likely to be ready ? > 2. It is rightly pointed out that the pulldown and pullup > characteristic for tristate outputs may be non-monotonic. The standard > says that this can happen in at most one place. The i-v characteristic > may then locally have a negative resistance. Will this not pose a > problem to simulators ? > 3. During a transition, it is not clear whether the pullup or pulldown > characteristics should be used by a simulator. This is not a problem > for making the IBIS models, but only for using them in a simulator. > 4. Is there a provision for specifying a pad or die resistance i.e > R_comp in addition to C_comp? > 5. The standard does not explicity specify the nature of the input > ramp in obtaining ramp rates. What should be the input rise time as > well as the high and low values of the input pulse? > Perhaps many of these issues have been thrashed out at different > forums. I would be greatly obliged if somebody would educate me on > this. > Raj Raghuram > National Semiconductor > 2900 Semiconductor Drive > Mail Stop D3-677 > Santa Clara, CA-95052 > email: raghu@berlioz.nsc.com > Phone: (408) 721-6220 (O) > Phone: (408) 252-1285 (H) From olaf@salamix.cadlab.de Fri Feb 3 04:07:12 1995 Return-Path: Received: from boromir.cadlab.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26596; Fri, 3 Feb 95 04:07:12 PST Received: from salamix.cadlab.de (salamix.cadlab.de [131.234.80.168]) by boromir.cadlab.de (8.6.9/8.6.5) with SMTP id NAA12509 for ; Fri, 3 Feb 1995 13:01:46 +0100 From: Olaf Rethmeier Message-Id: <9502031201.AA10473@salamix.cadlab.de> Received: by salamix.cadlab.de (4.1/12.71); Fri, 3 Feb 95 13:01:44 +0100 Subject: comment to EIA proposal To: ibis@vhdl.org Date: Fri, 3 Feb 1995 13:01:43 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 634 Dear IBIS-members, since we can not participate at the next face-to-face meeting, we mail our comments to the IBIS EIA proposal. In general we agree to the proposal and we are interested in a further cooperation with IBIS committee as an EIA group. But since we are a small company the amount of the annual dues may be a critical question. These dues should be as small as possible. Especially, we think the charge of the Golden Parser must be taken into account so that the first annual dues should be reduced. We wish everybody a succesful meeting on monday. Best regards Werner Rissiek, Olaf Rethmeier INCASES Engineering From kerryp@arnie.xilinx.com Fri Feb 3 08:25:53 1995 Return-Path: Received: from mail2.netcom.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28418; Fri, 3 Feb 95 08:25:53 PST Received: from mailman.xilinx.com by mail2.netcom.com (8.6.9/Netcom) id IAA02949; Fri, 3 Feb 1995 08:19:18 -0800 Received: from arnie.xilinx.com (Sarnie.xilinx.com [149.199.99.144]) by mailman.xilinx.com (8.6.9/8.6.9) with SMTP id IAA18540; Fri, 3 Feb 1995 08:20:57 -0800 Received: by arnie.xilinx.com id AA00303 (5.65c/IDA-1.4.4); Fri, 3 Feb 1995 08:23:31 -0800 Date: Fri, 3 Feb 1995 08:23:31 -0800 From: Kerry Pierce Message-Id: <199502031623.AA00303@arnie.xilinx.com> To: IBIS@vhdl.org, billd@reprise.com, kerryp@arnie.xilinx.com, speters@ichips.intel.com Subject: my e-mail address/too many hops Hello my correct e-mail address is kerryp@xilinx.com not kerryp@arnie.xilinx.com. The kerryp@arnie.xilinx.com problem arises due to my running on a remote slip machine. The kerryp@xilinx.com will work without hops. Sorry for the inconvienence. --Kerry From bob@icx.com Tue Feb 7 21:06:15 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22429; Tue, 7 Feb 95 21:06:15 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 7 Feb 95 19:17 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 7 Feb 95 19:18 PST Message-Id: Date: Tue, 7 Feb 95 19:18 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD25.1 DATA DERIVATION EXPANSION IBIS Members: First, thank you Will Hobbs, Derrick Duehren and Intel for arranging and hosting the very successful IBIS Summit on February 6. Based on discussions there, BIRD25.1 is issued. It contains an initial statement to point to the Notes on Data Extraction per Karl Kachigan's suggestion. It also changes the default of C_comp to be consistent with existing practice when min and max values are given independent of process information. This is the major change from BIRD25. There are also some minor text corrections. The major impact of BIRD25.1 is to add clarity by: (1) Giving a rational for populating the "min" and "max" columns. (2) Allowing usage of "slow, weak" process and "fast, strong" process models or devices in developing IBIS models. (3) Giving a process corner rational for inserting C_comp "min" and "max" column entries. (4) Including conditions for [Rising Waveform] and [Falling Waveform] table "min" and "max" column entries, to correct an omission. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 25.1 ISSUE TITLE: DATA DERIVATION EXPANSION REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 25 January 1995 DATE REVISED: 7 February 1995 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: As IBIS has expanded in functionality, some of the derivation rules and usage has not been fully considered or documented in the standard. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Item #12 is added to the "General syntax rules and guidelines fpr ASCII IBIS files" section at the beginning to point to important information in the NOTES ON DATA DERIVATION METHOD section at the end: | 12) Important supplimental information is contained in the last section, | "NOTES ON DATA DERIVATION METHOD", concerning how data values are | derived. | Replace the first Paragraph of NOTES ON DATA DERIVATION METHOD section shown below: |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor | base its data on typical process data, and then derate by voltage and | temperature, and a proprietary "X%" factor. This methodology also has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | The replacement text follows: |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. It describes certain | assumed parameter and table extraction conditions if they are not | explicitly specified. It also describes the allocation of data into | the "typ", "min", and "max" columns under variations of Voltage, | Temperature, and Process. | | The required "typ" column for all data represents nominal operating | conditions. The "min" column corresponds to slow, weak conditions, and | the "max" column corresponds to fast, strong conditions. It is | permissible to use weak, slow devices or models to derive the data | for the "min" column, and to use strong, fast devices or models to | derive the data in the "max" columns with the voltage and temperature | derating conditions described in the "min" or "max" columns. It is also | permissible to use typical devices or models under voltage and temperature | conditions and also optionally apply proprietary "X%" and "Y%" factors | described later for further derating. This methodology has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | All voltage keyword settings will always contain the smallest magnitude | voltage in the "min" column and the largest magnitude voltage for the | "max" column to represent simutaneously all supplies set at their | minimum values and all supplies at their maximum values. | | The optional [Temperature] keyword parameters will have the temperature | which causes or amplifies the slow, weak conditions in the "min" column | and the temperature which causes or amplifies the fast, strong | conditions in the "max" column. Therefore, the "min" column for | [Temperature] will contain the lowest value for bipolar devices (TTL | and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. | | The [Model] sub-parameter C_comp allows optional "min" and "max" values. | If extractable, the values under the "min" and "max" columns shall be | obtained under the same conditions that the other data is extracted. | Otherwise, if only the range of values is known, the smallest value | should be placed in the "min" column, and the largest value in the | "max" column. | | Default conditions under which all V/I tables are extracted are given | below when the temperature is not explicitly specified and a typical | model or device is used. The voltage ranges for the tables cover the | most common, single supply, standard logic situations. For situations | where multiple supplies are used, extend the tables in a similar manner | to voltages which handle the worst case reflected wave values that would | be encountered in practice. | | Default conditions under which the [Ramp] sub-parameters dV/dt_r and | dV/dt_f are given for the "typ", "min", and "max" columns. A 50 Ohm | load is normally assumed, but this can be overriden with the value given | by the R_load sub-parameter. The temperature and voltage conditions | for the "min" and "max" columns are consistent with and identical to | those of the V/I columns. | | The measurement setups under which the optional keyword tables for | [Rising Waveform] and [Falling Waveform] tables are described as | required and optional sub-parameter for those keywords. Therefore, | there are no alternative default measurement conditions. The temperature | and voltage operating conditions shall also be consistent with the [Ramp] | sub-parameter conditions. Note, that even though waveform keywords | may be supplied, the [Ramp] keyword is still required so that the | IBIS model can still be used in applications which do not support | processing of waveform data. | | The overriding rule for inserting data into "typ", "min", and "max" | columns for the C_comp, V/I, ramp and waveform keywords and sub-parameters | is that the data under each column is obtained under the same voltage | and voltage conditions to preserve correlation and consistency. | | Any keyword or sub-paramater which is not explicitly mentioned in this | section is expected to have "min" column entry to contain the | smallest value, and the "max" column entry the largest value. For example, | the default package sub-parameter "min" and "max" column entries are | expected to span the smallest to largest values based on physical | locations and unrelated to the voltage, temperature, and process | considerations in this section. | | The following discussion lists details and default conditions when | explicit, optional temperature settings and test conditions are not | provided. | Existing text follows. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION As IBIS expands to capture more capability, there needs to be consistent alignment of certain correlated data. More restrictive guidelines are needed in specifying "min" and "max" column entries so that related groupings for the die model can all exist in the same column. The rational for "min" and "max" columns needs to be expressed. Because Spice based I/O models frequently are given as separate "slow, weak" and "fast, strong" models such as in the TI Advanced Bus Interface SPICE I/O Models Data Book, provisions to accept such models needed to be stated. This is consistent with actual usage and needs to be included in supporting utilities such as "s2ibis" for Version 2.1. If the [Temperature] keyword is used, the data that goes into the "min" and "max" columns is restated in terms of the reason for providing the "min" and "max" columns. Furthermore, while temperature itself may not necessarily be used in processing an IBIS model, it could be used to generate it through automated tools. Therefore, the temperature used needs to be aligned with the other data in the column. There exists a potential conflict in IBIS in that the C_comp "min" and "max" column entries can be derived in certain cases from actual Spice models or data and is correlated with other "min" column or "max" column entries. The largest value does not necessarily reside in the "max" column. Without clarification, the larger value of C_comp would be positioned in the "max" column, and any correlation would be lost. Because automated extraction of IBIS data from die models is a reality, it is important to obtain each column of data under identical conditions. When correlation of C_comp is not known, the smaller value is positioned in the "min" column and the larger value in the "max" column. This arbitrary correlation may relate to internal die size tolerance and strength, but may be opposite of the correlation of capacitance value and speed. However, it is consistent with existing practice to date. Conditions for [Rising Waveform] and [Falling Waveform] column entries are clarified to be consistent with the [Ramp] sub-parameter entries. The "min" column and "max" column entries apply only to the "process- based" IBIS data. Other data follow standard "min" and "max" entries based on magnitude because they pertain to variations that are unrelated to process parameter variations or else their application (such as terminator resistor values) would be treated (optionally) as an independent variation for analysis and design. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION From bob@icx.com Wed Feb 8 10:00:56 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01345; Wed, 8 Feb 95 10:00:56 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Feb 95 09:54 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Feb 95 09:56 PST Message-Id: Date: Wed, 8 Feb 95 09:56 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, schumach@flare.convex.com Subject: Re: BIRD25.1 DATA DERIVATION EXPANSION Richard Thank you for your correction. All comments including spelling are welcome. Now I understand why I had problems with "rationale" numbers in math. Bob Ross > One bit of nit-picking: > >The rational for "min" and "max" columns needs to be expressed. > ^^^^^^^^ > rationale > Regards, > Richard Schumacher From uunet!qdt.com!jonp@uunet.uu.net Wed Feb 8 12:26:55 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02242; Wed, 8 Feb 95 12:26:55 PST Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQycfx12482; Wed, 8 Feb 1995 15:20:49 -0500 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 8 Feb 1995 15:20:43 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00765; Wed, 8 Feb 95 11:03:07 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28445; Wed, 8 Feb 95 11:06:24 PST Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQycfs24879; Wed, 8 Feb 1995 14:03:34 -0500 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 8 Feb 1995 14:03:20 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00578; Wed, 8 Feb 95 10:22:19 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28081; Wed, 8 Feb 95 10:25:37 PST Date: Wed, 8 Feb 95 10:25:37 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9502081825.AA28081@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA10649; Wed, 8 Feb 95 10:24:03 PST To: uunet!uunet!icx.com!bob@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Bob Ross's message of Tue, 7 Feb 95 19:18 PST Subject: BIRD25.1 DATA DERIVATION EXPANSION | | The [Model] sub-parameter C_comp allows optional "min" and "max" values. | If extractable, the values under the "min" and "max" columns shall be | obtained under the same conditions that the other data is extracted. | Otherwise, if only the range of values is known, the smallest value | should be placed in the "min" column, and the largest value in the | "max" column. I feel that this statement is too weak. We are proposing a change to the way a model is created. Presumably this means a change to the IBIS version number (2.1 -> 2.2). I think it is reasonable to require that 2.2 rev. models follow the stronger requirement of min max definition. If you don't know where the data came from then it is either a) a 2.1 model b) unsuitable for use c) wrong. The problem is that if we allow this multiple definition there is no way to determine how the data was collected and so me must ALWAYS assume that the data is WRONG and so this strengthening does not accomplish anything. It is as if we have said: You can fix the problem or not, and you don't have to tell us which you did. respectfull submitted, jon powell From fkai@dellgate.us.dell.com Wed Feb 8 13:02:15 1995 Return-Path: Received: from dellgate.us.dell.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02624; Wed, 8 Feb 95 13:02:15 PST Received: by dellgate.us.dell.com with UUCP (Smail3.1.28.1 #1) id m0rcKWf-000D8YC; Wed, 8 Feb 95 16:06 CST Message-Id: Date: Wed, 8 Feb 95 16:06 CST From: fkai@dellgate.us.dell.com (Francis Kai) To: ibis@vhdl.org, bob@icx.com ( Bob Ross), schumach@flare.convex.com Subject: Re: BIRD25.1 DATA DERIVATION EXPANSION I just received the mail from Mr. Richard Schumacher about "rationale". I do not have too many math books in my office, however, I do have a lot in my Houston home. One book that I have in office is "Mathematical Analysis" by Tom M. Apostol, second edition. In Apostol's book, page 6, Section 1.8, he says the following: Quotients of integers a/b (where b/= 0) are called rational numbers. I also check my dictionary, Webster'II New Riverside University Dictionary, page 1012, it says, rational 4.Math. Designating an algebraic expression no variable of which appears in an irreducible radical or with a fractional exponent. rationale 1.The fundamental reasons for something: BASIS I believe we should use rational instead of rationale. The page number is 976. Regards, Francis Kai Dell Computer Corporation From Will_Hobbs@ccm2.jf.intel.com Wed Feb 8 13:13:21 1995 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02654; Wed, 8 Feb 95 13:13:21 PST Received: from ormail.intel.com by relay2.UU.NET with SMTP id QQycga29121; Wed, 8 Feb 1995 16:07:03 -0500 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rcJbH-000UhmC; Wed, 8 Feb 95 13:06 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rcJbH-000tweC; Wed, 8 Feb 95 13:06 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 8 Feb 95 13:06:58 PST Date: Wed, 8 Feb 95 13:06:58 PST From: Will Hobbs Message-Id: <950208130658_5@ccm.jf.intel.com> To: jonp%qdt.com%uunet@uunet.uu.net, uunet!uunet!icx.com!bob@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: BIRD25.1 DATA DERIVATION EXPANSION Text item: Bob, Jon, et al, Perhaps we need to rev V1.1 to V1.2 to clarify this. I think we should check with model developers and see how they have interpreted this in the past. Let them know of the clarification, and let them rev their models if they interpreted it backwards. Fixing the column placement and rev-ing the model to V1.2 or V2.2 would allow them to continue to supply C_comp in existing models. Will Hobbs Intel Corp. | | The [Model] sub-parameter C_comp allows optional "min" and "max" values. | If extractable, the values under the "min" and "max" columns shall be | obtained under the same conditions that the other data is extracted. | Otherwise, if only the range of values is known, the smallest value | should be placed in the "min" column, and the largest value in the | "max" column. I feel that this statement is too weak. We are proposing a change to the way a model is created. Presumably this means a change to the IBIS version number (2.1 -> 2.2). I think it is reasonable to require that 2.2 rev. models follow the stronger requirement of min max definition. If you don't know where the data came from then it is either a) a 2.1 model b) unsuitable for use c) wrong. The problem is that if we allow this multiple definition there is no way to determine how the data was collected and so me must ALWAYS assume that the data is WRONG and so this strengthening does not accomplish anything. It is as if we have said: You can fix the problem or not, and you don't have to tell us which you did. respectfull submitted, jon powell 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: BIRD25.1 DATA DERIVATION EXPANSION In-Reply-To: Bob Ross's message of Tue, 7 Feb 95 19:18 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Wed, 8 Feb 95 10:25:37 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28081; Wed, 8 Feb 95 10:25:37 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00578; Wed, 8 Feb 95 10:22:19 PST Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 8 Feb 1995 14:03:20 -0500 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQycfs24879; Wed, 8 Feb 1995 14:03:34 -0500 Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28445; Wed, 8 Feb 95 11:06:24 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00765; Wed, 8 Feb 95 11:03:07 PST Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Wed, 8 Feb 1995 15:20:43 -0500 Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQycfx12482; Wed, 8 Feb 1995 15:20:49 -0500 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02242; Wed, 8 Feb 95 12:26:55 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 8 Feb 95 12: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 8 Feb 95 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rcJDd-000twcC; Wed, 8 Feb 95 12:42 PST From fkai@simulate.us.dell.com Wed Feb 8 13:21:55 1995 Return-Path: Received: from dell1.us.dell.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02727; Wed, 8 Feb 95 13:21:55 PST Received: from simulate.us.dell.com.us.dell.com (simulate.us.dell.com [143.166.2.233]) by dell1.us.dell.com (8.6.8.1/8.6.8-DELL1-INTERNET-GATEWAY) with SMTP id PAA14478; Wed, 8 Feb 1995 15:18:57 -0600 Received: by simulate.us.dell.com.us.dell.com (4.1/SMI-4.1) id AA04812; Wed, 8 Feb 95 15:17:40 CST Date: Wed, 8 Feb 95 15:17:40 CST From: fkai@simulate.us.dell.com (Francis Kai) Message-Id: <9502082117.AA04812@simulate.us.dell.com.us.dell.com> To: bob@icx.com, ibis@vhdl.org, schumach@flare.convex.com Subject: rational number Bob, Richard, I just received the mail from Mr. Richard Schumacher about "rationale". I do not have too many math books in my office, however, I do have a lot in my Houston home. One book that I have in office is "Mathematical Analysis" by Tom M. Apostol, second edition. In Apostol's book, page 6, Section 1.8, he says the following: Quotients of integers a/b (where b/= 0) are called rational numbers. I also check my dictionary, Webster'II New Riverside University Dictionary, page 976, it says, rational 4.Math. Designating an algebraic expression no variable of which appears in an irreducible radical or with a fractional exponent. rationale 1.The fundamental reasons for something: BASIS I believe we should use rational instead of rationale. Regards, Francis Kai Dell Computer Corporation >From icx.com!bob Wed Feb 8 13:20:34 1995 >Received: from simulate.us.dell.com.us.dell.com by dellgate.us.dell.com with smtp > (Smail3.1.28.1 #1) id m0rcHwH-000D8mC; Wed, 8 Feb 95 13:20 CST >Received: from vhdl.vhdl.org by simulate.us.dell.com.us.dell.com (4.1/SMI-4.1) > id AA04790; Wed, 8 Feb 95 12:12:08 CST >Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) > id AA01345; Wed, 8 Feb 95 10:00:56 PST >Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 8 Feb 95 09:54 PST >Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 8 Feb 95 09:56 PST >Message-Id: >Date: Wed, 8 Feb 95 09:56 PST >From: bob@icx.com ( Bob Ross) >To: ibis@vhdl.org, schumach@flare.convex.com >Subject: Re: BIRD25.1 DATA DERIVATION EXPANSION >Status: RO > >Richard > >Thank you for your correction. All comments including spelling are welcome. >Now I understand why I had problems with "rationale" numbers in math. > >Bob Ross > One bit of nit-picking: > >The rational for "min" and "max" columns needs to be expressed. > ^^^^^^^^ > rationale > Regards, > Richard Schumacher From Will_Hobbs@ccm2.jf.intel.com Wed Feb 8 17:56:01 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04772; Wed, 8 Feb 95 17:56:01 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rcO1T-000UixC; Wed, 8 Feb 95 17:50 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rcO1T-000twcC; Wed, 8 Feb 95 17:50 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 8 Feb 95 17:50:18 PST Date: Wed, 8 Feb 95 17:50:18 PST From: Will Hobbs Message-Id: <950208175018_1@ccm.jf.intel.com> To: fkai@simulate.us.dell.com, bob@icx.com, ibis@vhdl.org, schumach@flare.convex.com Subject: Re: rational number Text item: Francis, Rational may be rational, but it is also a noun and the Bird used it as an adjective. This sentence no verb. Will Hobbs Intel Corp. However, Bob, Richard, I just received the mail from Mr. Richard Schumacher about "rationale". I do not have too many math books in my office, however, I do have a lot in my Houston home. One book that I have in office is "Mathematical Analysis" by Tom M. Apostol, second edition. In Apostol's book, page 6, Section 1.8, he says the following: Quotients of integers a/b (where b/= 0) are called rational numbers. I also check my dictionary, Webster'II New Riverside University Dictionary, page 976, it says, rational 4.Math. Designating an algebraic expression no variable of which appears in an irreducible radical or with a fractional exponent. rationale 1.The fundamental reasons for something: BASIS I believe we should use rational instead of rationale. Regards, Francis Kai Dell Computer Corporation >From icx.com!bob Wed Feb 8 13:20:34 1995 >Received: from simulate.us.dell.com.us.dell.com by dellgate.us.dell.com with smtp > (Smail3.1.28.1 #1) id m0rcHwH-000D8mC; Wed, 8 Feb 95 13:20 CST >Received: from vhdl.vhdl.org by simulate.us.dell.com.us.dell.com (4.1/SMI-4.1) > id AA04790; Wed, 8 Feb 95 12:12:08 CST >Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) > id AA01345; Wed, 8 Feb 95 10:00:56 PST >Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 8 Feb 95 09:54 PST >Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 8 Feb 95 09:56 PST >Message-Id: >Date: Wed, 8 Feb 95 09:56 PST >From: bob@icx.com ( Bob Ross) >To: ibis@vhdl.org, schumach@flare.convex.com >Subject: Re: BIRD25.1 DATA DERIVATION EXPANSION >Status: RO > >Richard > >Thank you for your correction. All comments including spelling are welcome. >Now I understand why I had problems with "rationale" numbers in math. > >Bob Ross > One bit of nit-picking: > >The rational for "min" and "max" columns needs to be expressed. > ^^^^^^^^ > rationale > Regards, > Richard Schumacher 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: rational number To: bob@icx.com, ibis@vhdl.org, schumach@flare.convex.com Message-Id: <9502082117.AA04812@simulate.us.dell.com.us.dell.com> From: fkai@simulate.us.dell.com (Francis Kai) Date: Wed, 8 Feb 95 15:17:40 CST Received: by simulate.us.dell.com.us.dell.com (4.1/SMI-4.1) id AA04812; Wed, 8 Feb 95 15:17:40 CST Received: from simulate.us.dell.com.us.dell.com (simulate.us.dell.com [143.166.2 Received: from dell1.us.dell.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02727; Wed, 8 Feb 95 13:21:55 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 8 Feb 95 13: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 8 Feb 95 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rcK2H-000twdC; Wed, 8 Feb 95 13:34 PST From Will_Hobbs@ccm2.jf.intel.com Wed Feb 8 18:01:55 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04843; Wed, 8 Feb 95 18:01:55 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rcO1U-000UiMC; Wed, 8 Feb 95 17:50 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rcO1U-000twcC; Wed, 8 Feb 95 17:50 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 8 Feb 95 17:50:19 PST Date: Wed, 8 Feb 95 17:50:19 PST From: Will Hobbs Message-Id: <950208175019_2@ccm.jf.intel.com> To: Will_Hobbs@ccm2.jf.intel.com, fkai@simulate.us.dell.com, bob@icx.com, ibis@vhdl.org, schumach@flare.convex.com Subject: Re[2]: rational number Text item: Whoa, Brain fade. I got my sentence bacwards. Sorry, Francis and others. Was: Rational may be rational, but it is also a noun and the Bird used it as an adjective. This sentence no verb. Should have been: Rational may be rational, but it is also an adjective and the Bird used it as a noun. This sentence no verb. Will Hobbs Intel Corp. Bob, Richard, I just received the mail from Mr. Richard Schumacher about "rationale". I do not have too many math books in my office, however, I do have a lot in my Houston home. One book that I have in office is "Mathematical Analysis" by Tom M. Apostol, second edition. In Apostol's book, page 6, Section 1.8, he says the following: Quotients of integers a/b (where b/= 0) are called rational numbers. I also check my dictionary, Webster'II New Riverside University Dictionary, page 976, it says, rational 4.Math. Designating an algebraic expression no variable of which appears in an irreducible radical or with a fractional exponent. rationale 1.The fundamental reasons for something: BASIS I believe we should use rational instead of rationale. Regards, Francis Kai Dell Computer Corporation >From icx.com!bob Wed Feb 8 13:20:34 1995 >Received: from simulate.us.dell.com.us.dell.com by dellgate.us.dell.com with smtp > (Smail3.1.28.1 #1) id m0rcHwH-000D8mC; Wed, 8 Feb 95 13:20 CST >Received: from vhdl.vhdl.org by simulate.us.dell.com.us.dell.com (4.1/SMI-4.1) > id AA04790; Wed, 8 Feb 95 12:12:08 CST >Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) > id AA01345; Wed, 8 Feb 95 10:00:56 PST >Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 8 Feb 95 09:54 PST >Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) > id ; Wed, 8 Feb 95 09:56 PST >Message-Id: >Date: Wed, 8 Feb 95 09:56 PST >From: bob@icx.com ( Bob Ross) >To: ibis@vhdl.org, schumach@flare.convex.com >Subject: Re: BIRD25.1 DATA DERIVATION EXPANSION >Status: RO > >Richard > >Thank you for your correction. All comments including spelling are welcome. >Now I understand why I had problems with "rationale" numbers in math. > >Bob Ross > One bit of nit-picking: > >The rational for "min" and "max" columns needs to be expressed. > ^^^^^^^^ > rationale > Regards, > Richard Schumacher 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: rational number To: bob@icx.com, ibis@vhdl.org, schumach@flare.convex.com Message-Id: <9502082117.AA04812@simulate.us.dell.com.us.dell.com> From: fkai@simulate.us.dell.com (Francis Kai) Date: Wed, 8 Feb 95 15:17:40 CST Received: by simulate.us.dell.com.us.dell.com (4.1/SMI-4.1) id AA04812; Wed, 8 Feb 95 15:17:40 CST Received: from simulate.us.dell.com.us.dell.com (simulate.us.dell.com [143.166.2 Received: from dell1.us.dell.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02727; Wed, 8 Feb 95 13:21:55 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 8 Feb 95 13: Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 8 Feb 95 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rcK2H-000twdC; Wed, 8 Feb 95 13:34 PST From bob@icx.com Wed Feb 8 21:09:14 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05834; Wed, 8 Feb 95 21:09:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Feb 95 21:03 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Feb 95 21:05 PST Message-Id: Date: Wed, 8 Feb 95 21:05 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Bird25.1 Response To Members: Thank you for your comments. Jon raised very nicely the fundamental paradox and problem with respect to positioning the values of C_comp. From a model development point of view, it would be nice to give ONE rule that positions C_comp and gives the BEST representation of the device. Unfortunately, the assumption that enough information is available to correlate C_comp may not be valid in most(?) cases. I don't know how well C_comp actually correlates to the "voltage" and "temperature" variables vs its correlation to internal metalization variations. Furthermore, when models are developed using data book information containing specification tables, the correlation is not known at all. So, the assumed C_comp correlation to voltage/temperature/process variations may not always be valid, and information about such potential correlation is often unavailable. From a simulator point of view, it is very desireable for the modeling information to be well-defined. In particular, if it is always known that the "max" column contains the largest value of C_comp, then that column can be relied upon to provide the largest load for the slowest timing condition for an Input model - as a consistent configuration. Otherwise, a worst case corner may require doing a min/max search on all of the entries. While this may appear simple, it is one additional complication and source of variation. Also, if there are inconsistencies between the various models within a design, there could be combined capacitance variaitons which cancel, defeating the reason for worst case analysis. So perhaps the best resolution is just to require the max C_comp value to be positioned in the "max" column, regardless of conditions under which it is extracted. The surprising tradeoff is that by overriding some extractions which give the most accurate model, one creates a set of models which function in a more consistent manner and which taken together are more useful for worst case analysis and design. More discussion is welcome before I issue a new revision to BIRD25.1. Bob Ross, Interconnectix, Inc From johnb@redpo.redac.co.uk Thu Feb 9 05:58:47 1995 Return-Path: Received: from relay1.pipex.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12868; Thu, 9 Feb 95 05:58:47 PST Received: from redac.co.uk (actually host redactcouk.redac.co.uk) by bath.pipex.net with SMTP (PP); Thu, 9 Feb 1995 13:53:07 +0000 Received: from redpo by redac.co.uk (5.0/SMI-SVR4) id AA17346; Thu, 9 Feb 1995 13:57:08 +0000 Received: from [89.32.39.5] (mac4_tsupp) by redpo (4.1/Redac-Interior-Gateway-V1.1) id AA06646; Thu, 9 Feb 95 13:46:11 GMT Date: Thu, 9 Feb 95 13:46:10 GMT Message-Id: <9502091346.AA06646@redpo> To: ibis@vhdl.org From: johnb@redpo.redac.co.uk (John Berrie) Subject: Model Mapping Question Content-Length: 1224 Dear Ibisians, Could anyone help me with a simple query ? The IBIS models I have seen all contain a mapping from pins to driver/receiver models which are then defined in the same file. It is, however, sometimes desirable to define this mapping directly in a component library. Is it reasonable to allow specification of the driver/receiver model name directly on the pins in the library as an alternative to referencing the models at the component level, or could there be a name clash with another model using the same name for a different characteristic ? Presumably, this could be overcome by also specifying the model at the component level, but what if none exists but we want to specify a driver model at the pin level which is defined somewhere else ? Thank you in advance for your anticipated help. John Best Regards, John -------------------------------------------------------------------------- John Berrie, Chief Application Engineer Zuken-Redac Limited, Green Lane,Tewkesbury, Glos. GL20 8HE, England Tel: (44) 0684 294161 Fax:(44) 0684 299754 E-Mail johnb@redact.co.uk -------------------------------------------------------------------------- From cpk@Cadence.COM Thu Feb 9 06:42:23 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13432; Thu, 9 Feb 95 06:42:23 PST Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA02149; Thu, 9 Feb 1995 06:37:24 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma002111; Thu Feb 9 06:37:01 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA04550; Thu, 9 Feb 95 06:35:46 -0800 Received: by hot (5.65+/1.5) id AA11712; Thu, 9 Feb 95 09:36:55 -0500 Date: Thu, 9 Feb 95 09:36:55 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9502091436.AA11712@hot> To: ibis@vhdl.org, bob@icx.com Subject: Re: Bird25.1 Response Given the complexity of deciding what is fast , slow , worst and best, I am more and more convinced the max, min columns should be simple. i.e. they should contain numerical max , min values. Then you can define what is fast, slow, worst etc. e.g FAST = (C_comp(min), pull_up (max), pull_down (max) ... ) This is unambigous. The draw back is there will be no way of automatically determining what is fast slow etc and it will violate 1.1 specs!! (oops) > > To Members: > > Thank you for your comments. Jon raised very nicely the fundamental paradox > and problem with respect to positioning the values of C_comp. > > >From a model development point of view, it would be nice to give ONE rule > that positions C_comp and gives the BEST representation of the device. > > Unfortunately, the assumption that enough information is available to > correlate C_comp may not be valid in most(?) cases. I don't know how well > C_comp actually correlates to the "voltage" and "temperature" variables > vs its correlation to internal metalization variations. Furthermore, > when models are developed using data book information containing specification > tables, the correlation is not known at all. So, the assumed C_comp > correlation to voltage/temperature/process variations may not always be > valid, and information about such potential correlation is often unavailable. > > >From a simulator point of view, it is very desireable for the modeling > information to be well-defined. In particular, if it is always known that > the "max" column contains the largest value of C_comp, then that column > can be relied upon to provide the largest load for the slowest timing > condition for an Input model - as a consistent configuration. Otherwise, > a worst case corner may require doing a min/max search on all of the entries. > While this may appear simple, it is one additional complication and source > of variation. Also, if there are inconsistencies between the various models > within a design, there could be combined capacitance variaitons which cancel, > defeating the reason for worst case analysis. > > So perhaps the best resolution is just to require the max C_comp value > to be positioned in the "max" column, regardless of conditions under which > it is extracted. The surprising tradeoff is that by overriding some > extractions which give the most accurate model, one creates a set of models > which function in a more consistent manner and which taken together are > more useful for worst case analysis and design. > > More discussion is welcome before I issue a new revision to BIRD25.1. > > Bob Ross, > Interconnectix, Inc > From cpk@Cadence.COM Thu Feb 9 06:47:44 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13477; Thu, 9 Feb 95 06:47:44 PST Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA02468 for ; Thu, 9 Feb 1995 06:42:45 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma002448; Thu Feb 9 06:42:40 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA04807; Thu, 9 Feb 95 06:41:26 -0800 Received: by hot (5.65+/1.5) id AA11716; Thu, 9 Feb 95 09:42:37 -0500 Date: Thu, 9 Feb 95 09:42:37 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9502091442.AA11716@hot> To: ibis@vhdl.org, johnb@Cadence.COM Subject: Re: Model Mapping Question I believe this refers to our old discussion about component centered versus buffer (pin) centered representation. I agree that there is a case for organizing data on a buffer centric basis but we have no provisions for it now. May be we can reopen this discussion. > > Dear Ibisians, > Could anyone help me with a simple query ? > The IBIS models I have seen all contain a mapping from pins to > driver/receiver models which are then defined in the same file. > It is, however, sometimes desirable to define this mapping directly in a > component library. Is it reasonable to allow specification of the > driver/receiver model name directly on the pins in the library as an > alternative to referencing the models at the component level, or could > there be a name clash with another model using the same name for a > different characteristic ? > Presumably, this could be overcome by also specifying the model at the > component level, but what if none exists but we want to specify a driver > model at the pin level which is defined somewhere else ? > > Thank you in advance for your anticipated help. > > John > > > Best Regards, > > > John > > -------------------------------------------------------------------------- > John Berrie, Chief Application Engineer > Zuken-Redac Limited, > Green Lane,Tewkesbury, > Glos. GL20 8HE, England > Tel: (44) 0684 294161 > Fax:(44) 0684 299754 > E-Mail johnb@redact.co.uk > -------------------------------------------------------------------------- > > From johnb@redpo.redac.co.uk Thu Feb 9 07:59:51 1995 Return-Path: Received: from relay1.pipex.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13877; Thu, 9 Feb 95 07:59:51 PST Received: from redac.co.uk (actually host redactcouk.redac.co.uk) by bath.pipex.net with SMTP (PP); Thu, 9 Feb 1995 15:54:42 +0000 Received: from redpo by redac.co.uk (5.0/SMI-SVR4) id AA19143; Thu, 9 Feb 1995 15:58:21 +0000 Received: from [89.32.39.5] (mac4_tsupp) by redpo (4.1/Redac-Interior-Gateway-V1.1) id AA08432; Thu, 9 Feb 95 15:47:18 GMT Date: Thu, 9 Feb 95 15:47:15 GMT Message-Id: <9502091547.AA08432@redpo> To: ibis@vhdl.org, cpk@cadence.com (C. Kumar) From: johnb@redpo.redac.co.uk (John Berrie) Subject: Re: Model Mapping Question Content-Length: 2311 >Thanks, I presume the original reason is that the method provides the safest environment for independent model development, to avoid name clashes. There is only one drawback except for data size that I can see: that is, experimenting with 'What If' scenarios is made less straightforward. John I believe this refers to our old discussion about component centered versus >buffer (pin) centered representation. I agree that there is a case for >organizing data on a buffer centric basis but we have no provisions for it >now. May be we can reopen this discussion. >> >> Dear Ibisians, >> Could anyone help me with a simple query ? >> The IBIS models I have seen all contain a mapping from pins to >> driver/receiver models which are then defined in the same file. >> It is, however, sometimes desirable to define this mapping directly in a >> component library. Is it reasonable to allow specification of the >> driver/receiver model name directly on the pins in the library as an >> alternative to referencing the models at the component level, or could >> there be a name clash with another model using the same name for a >> different characteristic ? >> Presumably, this could be overcome by also specifying the model at the >> component level, but what if none exists but we want to specify a driver >> model at the pin level which is defined somewhere else ? >> >> Thank you in advance for your anticipated help. >> >> John >> >> >> Best Regards, >> >> >> John >> >> -------------------------------------------------------------------------- >> John Berrie, Chief Application Engineer >> Zuken-Redac Limited, >> Green Lane,Tewkesbury, >> Glos. GL20 8HE, England >> Tel: (44) 0684 294161 >> Fax:(44) 0684 299754 >> E-Mail johnb@redact.co.uk >> -------------------------------------------------------------------------- >> >> Best Regards, John -------------------------------------------------------------------------- John Berrie, Chief Application Engineer Zuken-Redac Limited, Green Lane,Tewkesbury, Glos. GL20 8HE, England Tel: (44) 0684 294161 Fax:(44) 0684 299754 E-Mail johnb@redact.co.uk -------------------------------------------------------------------------- From Arpad_Muranyi@ccm.fm.intel.com Thu Feb 9 09:10:25 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14718; Thu, 9 Feb 95 09:10:25 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rccIo-000UjJC; Thu, 9 Feb 95 09:05 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rccIm-000tweC; Thu, 9 Feb 95 09:05 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 9 Feb 95 09:05:05 PST Date: Thu, 9 Feb 95 09:05:05 PST From: Arpad Muranyi Message-Id: <950209090505_2@ccm.hf.intel.com> To: ibis@vhdl.org, cpk@Cadence.COM Subject: Re[2]: Bird25.1 Response Text item: Hello all, I don't see why it would violate the 1.1 spec. I don't know of anything in it that would say what goes where regarding C_comp. Arpad ------------------------------------------------------------------------------ Given the complexity of deciding what is fast , slow , worst and best, I am more and more convinced the max, min columns should be simple. i.e. they should contain numerical max , min values. Then you can define what is fast, slow, worst etc. e.g FAST = (C_comp(min), pull_up (max), pull_down (max) ... ) This is unambigous. The draw back is there will be no way of automatically determining what is fast slow etc and it will violate 1.1 specs!! (oops) > > To Members: > > Thank you for your comments. Jon raised very nicely the fundamental paradox > and problem with respect to positioning the values of C_comp. > > >From a model development point of view, it would be nice to give ONE rule > that positions C_comp and gives the BEST representation of the device. > > Unfortunately, the assumption that enough information is available to > correlate C_comp may not be valid in most(?) cases. I don't know how well > C_comp actually correlates to the "voltage" and "temperature" variables > vs its correlation to internal metalization variations. Furthermore, > when models are developed using data book information containing specification > tables, the correlation is not known at all. So, the assumed C_comp > correlation to voltage/temperature/process variations may not always be > valid, and information about such potential correlation is often unavailable. > > >From a simulator point of view, it is very desireable for the modeling > information to be well-defined. In particular, if it is always known that > the "max" column contains the largest value of C_comp, then that column > can be relied upon to provide the largest load for the slowest timing > condition for an Input model - as a consistent configuration. Otherwise, > a worst case corner may require doing a min/max search on all of the entries. > While this may appear simple, it is one additional complication and source > of variation. Also, if there are inconsistencies between the various models > within a design, there could be combined capacitance variaitons which cancel, > defeating the reason for worst case analysis. > > So perhaps the best resolution is just to require the max C_comp value > to be positioned in the "max" column, regardless of conditions under which > it is extracted. The surprising tradeoff is that by overriding some > extractions which give the most accurate model, one creates a set of models > which function in a more consistent manner and which taken together are > more useful for worst case analysis and design. > > More discussion is welcome before I issue a new revision to BIRD25.1. > > Bob Ross, > Interconnectix, Inc > Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Bird25.1 Response To: ibis@vhdl.org, bob@icx.com Message-Id: <9502091436.AA11712@hot> From: cpk@cadence.com (C. Kumar) Date: Thu, 9 Feb 95 09:36:55 -0500 Received: by hot (5.65+/1.5) id AA11712; Thu, 9 Feb 95 09:36:55 -0500 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA04550; Thu, 9 Feb 95 06:35:46 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma id sma002111; Thu Feb 9 06:37:01 1995 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA0214 Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13432; Thu, 9 Feb 95 06:42:23 PST Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, 9 Feb 95 06: Received: from aurora.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rcaIQ-000twcC; Thu, 9 Feb 95 06:56 PST From gre@scintl.com Thu Feb 9 10:55:48 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15782; Thu, 9 Feb 95 10:55:48 PST Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQycjj08966; Thu, 9 Feb 1995 13:50:56 -0500 Received: from puma.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 9 Feb 1995 13:50:43 -0500 Received: from porpoise.scintl.com by scintl.com via SMTP (931110.SGI/930416.SGI) for uunet!vhdl.org!ibis id AA00230; Thu, 9 Feb 95 12:50:16 -0600 Date: Thu, 9 Feb 95 12:50:16 -0600 Message-Id: <9502091850.AA00230@scintl.com> X-Sender: gre@scintl.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: gre@scintl.com (Greg Edlund) Subject: Quest for IBIS models I took a peek into /pub/ibis/models the other day and found only a small collection of models for Intel's CPUs and chip sets. Am I correct in assuming that in order to procure IBIS models for the parts on my board design, I will either have to a. go to the mfgr's rep, or b. buy a library from someone like Zeelan? Have any of you found manufacturers yet who know what IBIS models are? I'm having a hard time trying to explain what SPICE models are, much less get them in my greedy hands. And SPICE has been around a LONG time. I'm just wondering how far we are along the road toward creating an information exchange which is beneficial to the engineer and does not give the manufacturer a migraine and/or keep their lawyers up at night. Thanks in advance. -- Greg Edlund +----+----+ "Years ago my mother would say to me, Circuits and Modeling | | | 'Elwood-' she always called me Elwood. SuperComputers, Int'l. < | ) 'Elwood, in this world, you must be 1414 W. Hamilton Ave. > ----- ) oh-so-smart or oh-so-pleasant.' Well, Eau Claire, WI 54701 < ----- ) for years I was smart. I recommend (715) 833-7067 voice > | ) pleasant. You may quote me." (715) 833-7096 FAX | | | Elwood P. Dowd gre@scintl.com email +----+----+ (Jimmy Stewart in "Harvey") From uunet!qdt.com!jonp@uunet.uu.net Thu Feb 9 10:58:28 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15788; Thu, 9 Feb 95 10:58:28 PST Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQycjj08922; Thu, 9 Feb 1995 13:50:47 -0500 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 9 Feb 1995 13:50:44 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00944; Thu, 9 Feb 95 10:23:34 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA04514; Thu, 9 Feb 95 10:26:52 PST Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQycjh01450; Thu, 9 Feb 1995 13:18:26 -0500 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 9 Feb 1995 13:18:23 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00546; Thu, 9 Feb 95 08:25:09 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA03686; Thu, 9 Feb 95 08:28:29 PST Date: Thu, 9 Feb 95 08:28:29 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9502091628.AA03686@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA12425; Thu, 9 Feb 95 08:26:55 PST To: uunet!uunet!icx.com!bob@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Bob Ross's message of Wed, 8 Feb 95 21:05 PST Subject: Bird25.1 Response >>So perhaps the best resolution is just to require the max C_comp value >>to be positioned in the "max" column, regardless of conditions under which >>it is extracted. The surprising tradeoff is that by overriding some >>extractions which give the most accurate model, one creates a set of models >>which function in a more consistent manner and which taken together are >>more useful for worst case analysis and design. This requirement would effectively make the C_comp value an un-correlated variable, so If we were doing a monte-carlo simulation it would enter in as another free variable. To me this change is no different than the current specification and so I can see no need for the bird (at least, on this point). Of course, we could come up with a COR_C_comp or some such thing. I am thinking that we are moving toward a situation where we want more that two variables and perhaps multiple corners and this whole discussion may be more appropriate aimed at a major 3.0 type enhancement. jonp From huq@rockie.nsc.com Thu Feb 9 12:56:39 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16688; Thu, 9 Feb 95 12:56:39 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA17175 for ibis@vhdl.org; Thu, 9 Feb 95 12:51:40 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA26519 for ibis@vhdl.org; Thu, 9 Feb 95 12:51:38 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA11125; Thu, 9 Feb 95 12:51:53 PST Date: Thu, 9 Feb 95 12:51:53 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9502092051.AA11125@rockie.nsc.com> To: ibis@vhdl.org, gre@scintl.com Subject: Re: Quest for IBIS models Hi Greg, It's true that Intel is the only one who has released IBIS models but within the next couple of months, you will see more and more models being released from other semiconductor vendors. National has just submitted a few models for release on vhdl.org and more will follow soon. I believe Xilinx is also releasing models sometime in March. Stay tuned. Syed. National Semiconductor. > From gre@scintl.com Thu Feb 9 11:20:45 1995 > Date: Thu, 9 Feb 95 12:50:16 -0600 > X-Sender: gre@scintl.com > X-Mailer: Windows Eudora Version 2.0.3 > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset="us-ascii"> > To: ibis@vhdl.org > From: gre@scintl.com (Greg Edlund) > Subject: Quest for IBIS models > Content-Length: 1367 > > I took a peek into /pub/ibis/models the other day and found only > a small collection of models for Intel's CPUs and chip sets. > Am I correct in assuming that in order to procure IBIS models > for the parts on my board design, I will either have to > > a. go to the mfgr's rep, or > b. buy a library from someone like Zeelan? > > Have any of you found manufacturers yet who know what IBIS models > are? I'm having a hard time trying to explain what SPICE models > are, much less get them in my greedy hands. And SPICE has been > around a LONG time. I'm just wondering how far we are along the > road toward creating an information exchange which is beneficial > to the engineer and does not give the manufacturer a migraine > and/or keep their lawyers up at night. > > Thanks in advance. > > -- > Greg Edlund +----+----+ "Years ago my mother would say to me, > Circuits and Modeling | | | 'Elwood-' she always called me Elwood. > SuperComputers, Int'l. < | ) 'Elwood, in this world, you must be > 1414 W. Hamilton Ave. > ----- ) oh-so-smart or oh-so-pleasant.' Well, > Eau Claire, WI 54701 < ----- ) for years I was smart. I recommend > (715) 833-7067 voice > | ) pleasant. You may quote me." > (715) 833-7096 FAX | | | Elwood P. Dowd > gre@scintl.com email +----+----+ (Jimmy Stewart in "Harvey") > > From Arpad_Muranyi@ccm.fm.intel.com Thu Feb 9 13:19:06 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16831; Thu, 9 Feb 95 13:19:06 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rcgBg-000UiMC; Thu, 9 Feb 95 13:14 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rcgBf-000twcC; Thu, 9 Feb 95 13:14 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 9 Feb 95 13:14:03 PST Date: Thu, 9 Feb 95 13:14:03 PST From: Arpad Muranyi Message-Id: <950209131403_1@ccm.hf.intel.com> To: ibis@vhdl.org, gre@scintl.com Subject: Re: Quest for IBIS models Text item: Greg, Most vendors are reluctant to give out SPICE models even if they have it (and regardless that SPICE has been around for about 20 years), becuase those kind of models give away all their secrets. You should have better luck in pursuading them to make IBIS models, because those are accurate, but still safe regarding propriatary material. Even though there are not many models on vhdl.org, we are hoping to get more and more companies to start making models. In order to achieve this goal, we need people like you (who need models) to contact IC manufacturers and express your needs. It is a painful process, but demand drives market. Arpad Muranyi Intel Corporation I took a peek into /pub/ibis/models the other day and found only a small collection of models for Intel's CPUs and chip sets. Am I correct in assuming that in order to procure IBIS models for the parts on my board design, I will either have to a. go to the mfgr's rep, or b. buy a library from someone like Zeelan? Have any of you found manufacturers yet who know what IBIS models are? I'm having a hard time trying to explain what SPICE models are, much less get them in my greedy hands. And SPICE has been around a LONG time. I'm just wondering how far we are along the road toward creating an information exchange which is beneficial to the engineer and does not give the manufacturer a migraine and/or keep their lawyers up at night. Thanks in advance. -- Greg Edlund +----+----+ "Years ago my mother would say to me, Circuits and Modeling | | | 'Elwood-' she always called me Elwood. SuperComputers, Int'l. < | ) 'Elwood, in this world, you must be 1414 W. Hamilton Ave. > ----- ) oh-so-smart or oh-so-pleasant.' Well, Eau Claire, WI 54701 < ----- ) for years I was smart. I recommend (715) 833-7067 voice > | ) pleasant. You may quote me." (715) 833-7096 FAX | | | Elwood P. Dowd gre@scintl.com email +----+----+ (Jimmy Stewart in "Harvey") 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: Quest for IBIS models From: gre@scintl.com (Greg Edlund) To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 X-Sender: gre@scintl.com Message-Id: <9502091850.AA00230@scintl.com> Date: Thu, 9 Feb 95 12:50:16 -0600 Received: from porpoise.scintl.com by scintl.com via SMTP (931110.SGI/930416.SGI for uunet!vhdl.org!ibis id AA00230; Thu, 9 Feb 95 12:50:16 -0600 Received: from puma.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 9 Feb 1995 13:50:43 -0500 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQycjj08966; Thu, 9 Feb 1995 13:50:56 -0500 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15782; Thu, 9 Feb 95 10:55:48 PST Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA20566; Thu, 9 Feb 95 11:12:42 PST Received: from SSD.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rceIO-000twcC; Thu, 9 Feb 95 11:12 PST From fvance@FirePower.COM Thu Feb 9 13:31:17 1995 Return-Path: Received: from FirePower.COM (copan.FirePower.COM) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16922; Thu, 9 Feb 95 13:31:17 PST Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA09330; Thu, 9 Feb 95 13:08:57 -0800 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA27604; Thu, 9 Feb 95 13:26:05 -0800 From: Fred Vance Message-Id: <9502092126.AA27604@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA06747; Thu, 9 Feb 95 13:26:02 -0800 Date: Thu, 9 Feb 95 13:26:02 -0800 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: gre@scintl.com (Greg Edlund) Subject: Re: Quest for IBIS models Cc: ibis@vhdl.org Greg, IBIS is *information* not a model. If there is such a thing as an IBIS model I would guess that it is a SPICE behavioral model that uses IBIS data in Piece-Wise Linear voltage or current sources. I have seen a document describing a methodology for converting IBIS data into a SPICE behavioral model. It was generated by Intel and the copy I saw was marked confidential. Maybe Will or someone at Intel can tell you how to get a copy. Frankly, I'm surprised that it is not in pub/ibis/documents on vhdl.org. The IBIS/SPICE behavioral model has the same advantages that any SPICE behavioral model has over a transistor-level SPICE model, ie. it is faster and gives you fewer convergence problems. I've seen IBIS data from Intel, and Motorola. TriQuint has data in their databook that looks like IBIS data to me. Almost everyone will give you SPICE models if you keep after them. TI, LSI, and IDT are great about providing SPICE models. DRAM companies like Micron, Motorola, and Hitachi will give you SPICE models, but unfortunately, they don't provide the all important clamp (protection) diodes in their models. I'm sure I've left out some very important companies who provide SPICE models and I apologize for my lapse of memory. With the SPICE model, you can create your own IBIS data and from that, create your own SPICE behavioral model. I think maybe you are looking for a simulation tool that ingests IBIS data and can be used for simulation and analysis. I'm sure you will hear from many of them. I understand that Quad Design (XTK/TLC) and MetaSoftware (HSPICE) are planning to release something like that. I would bet that every EDA company on the IBIS roster has similar plans. Until the EDA IBIS tools are all available I would suggest that you try using IBIS SPICE models generated from SPICE models. This should not be a threat to the EDA companies. In fact, I believe it is a healthy exercise to create SPICE IBIS behavioral models. It will give you a better understanding of the entire process and maybe some of the advantages and pitfalls of IBIS data. I am sure that it will also give you a great appreciation of the various tools that use IBIS data when they are available. If you have a question about a specific SPICE or IBIS model that you are looking for let me know what it is off-line, and I'll see if I can help you with it. Regards, Fred FirePower Systems, Inc. Begin forwarded message: Date: Thu, 9 Feb 95 12:50:16 -0600 X-Sender: gre@scintl.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: gre@scintl.com (Greg Edlund) Subject: Quest for IBIS models I took a peek into /pub/ibis/models the other day and found only a small collection of models for Intel's CPUs and chip sets. Am I correct in assuming that in order to procure IBIS models for the parts on my board design, I will either have to a. go to the mfgr's rep, or b. buy a library from someone like Zeelan? Have any of you found manufacturers yet who know what IBIS models are? I'm having a hard time trying to explain what SPICE models are, much less get them in my greedy hands. And SPICE has been around a LONG time. I'm just wondering how far we are along the road toward creating an information exchange which is beneficial to the engineer and does not give the manufacturer a migraine and/or keep their lawyers up at night. Thanks in advance. -- Greg Edlund +----+----+ "Years ago my mother would say to me, Circuits and Modeling | | | 'Elwood-' she always called me Elwood. SuperComputers, Int'l. < | ) 'Elwood, in this world, you must be 1414 W. Hamilton Ave. > ----- ) oh-so-smart or oh-so-pleasant.' Well, Eau Claire, WI 54701 < ----- ) for years I was smart. I recommend (715) 833-7067 voice > | ) pleasant. You may quote me." (715) 833-7096 FAX | | | Elwood P. Dowd gre@scintl.com email +----+----+ (Jimmy Stewart in "Harvey") From Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com Thu Feb 9 15:17:59 1995 Return-Path: Received: from wotan.compaq.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17551; Thu, 9 Feb 95 15:17:59 PST Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0rci2m-000vIkC; Thu, 9 Feb 95 17:13 CST Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0rci2j-000ugvC; Thu, 9 Feb 95 17:12 CST Message-Id: Received: by bangate.compaq.com with VINES ; Thu, 9 Feb 95 17:12:56 CST Date: Thu, 9 Feb 95 15:58:31 CST From: Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com Subject: re: Quest for IBIS models To: ibis@vhdl.org Cc: gre@scintl.com Greg, My experience in getting Spice and/or IBIS models has varied dramatically from vendor to vendor. As this might also be of some interest to the various tool vendors, here's my feedback... My starting point is usually the vendor's rep. Inevitably the rep has no clue what we're requesting, though they do come up to speed fairly quickly. Within a day or so I get feedback as to what's available. An increasing number of companies have Spice information readily available, and a small number have v1.1 IBIS stuff available. I've yet to see a v2.1 model (though Intel has provided equivalent Quad and HSpice models for buffers that couldn't be accurately modeled in the earlier format). Interestingly enough, many of the companies I've encountered that have IBIS models also are willing to provide the original Spice info. I make a point to try to get my hands on Spice models for several reasons (even though I won't be using Spice to run the sims). First off, we've had some success in getting vendors to "guarantee" their Spice models. I rarely get guaranteed IBIS models (it's happened once, and wasn't a memorable experience). Secondly, I can gain some insight into the model accuracy by looking through the netlist and device models. Though this can be misleading it can also be quite beneficial. I have a big issue with non-guaranteed models, but that's another subject. Finally, with most Spice models you're free to set the operating conditions (process point, voltage, and temperature) according to the each system's specifications. IBIS min/max conditions are often predefined and accordingly are too conservative for some applications. When Spice models aren't available or can't be obtained in an acceptable time period (the lawyers got involved), I take one of two different approaches depending on my needs. Sometimes I'll ask for IBIS models, while other times I'll ask the vendor to perform a series of buffer characterization sims and simply send me the raw results. The second approach has worked well when the vendor doesn't have IBIS models, doesn't know what IBIS models are, has v1.1 models that aren't accurate enough, or has the wrong operating conditions in their standard models. These two approaches have worked well at times, while other times the whole experience is a big pain in the [insert favorite anatomical reference here]. As to Zeelan models, they could come in handy at times. I've yet to purchase a copy of their library for two reasons: it doesn't contain min/max models and doesn't contain all the parts I think it should (DRAMs, cache RAMs, etc.). There have been times, however, when it would've been beneficial to have their library available. As to industry trends, I've seen a positive shift over the last 6 months or so. In general most of the companies have a long way to go, but I get the impression that more and more of 'em are heading the right way. I know I've been going to a lot of trouble to educate a number of 'em... Mark Leonard Lead Engineer, Signal Integrity Group Compaq Computer Corporation From uunet!qdt.com!jonp@uunet.uu.net Thu Feb 9 15:50:15 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17744; Thu, 9 Feb 95 15:50:15 PST Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQyckd14098; Thu, 9 Feb 1995 18:45:15 -0500 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 9 Feb 1995 18:45:17 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01680; Thu, 9 Feb 95 14:43:55 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA05532; Thu, 9 Feb 95 14:47:15 PST Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQycjz03756; Thu, 9 Feb 1995 17:45:23 -0500 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Thu, 9 Feb 1995 17:45:11 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01650; Thu, 9 Feb 95 14:27:43 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA05410; Thu, 9 Feb 95 14:31:03 PST Date: Thu, 9 Feb 95 14:31:03 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9502092231.AA05410@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA12754; Thu, 9 Feb 95 14:29:29 PST To: uunet!uunet!FirePower.COM!fvance@uunet.uu.net Cc: uunet!uunet!scintl.com!gre@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Fred Vance's message of Thu, 9 Feb 95 13:26:02 -0800 <9502092126.AA27604@oahu.FirePower.COM> Subject: Quest for IBIS models Greg, I must heartily DISAGREE with Fred from FirePower. IBIS is a behavioral model standard. IBIS models, though quite usable as SPICE behavoiral models, are also equally usable by the various non-spice offerings of Quad, Hyperlynx, Cadence, Quantic, Interconnectix etc. (sorry who-ever I left out). These non-spice companies have been IBIS compatible since the creation of IBIS (some even before) and have been some of the stronger driving forces in the establishment of the IBIS standard (partially because they pioneered the behavioral model representation). All of the IBIS associated companies have IBIS converters or can read IBIS directly, all have different strengths etc. regards, jon powell Transmission Line Products Manager, Quad Design. From fvance@FirePower.COM Thu Feb 9 17:07:39 1995 Return-Path: Received: from FirePower.COM (copan.FirePower.COM) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18230; Thu, 9 Feb 95 17:07:39 PST Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA10095; Thu, 9 Feb 95 16:45:17 -0800 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA02708; Thu, 9 Feb 95 17:02:25 -0800 From: Fred Vance Message-Id: <9502100102.AA02708@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA06805; Thu, 9 Feb 95 17:02:23 -0800 Date: Thu, 9 Feb 95 17:02:23 -0800 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Subject: Re: Quest for IBIS models Cc: ibis@vhdl.org Jon, I stand corrected. I hold too limited a view of a model. Information for the behavioral specification of IC I/O analog characteristics is indeed a model. I tend to think of a model as something that I can use directly to analyze and/or simulate circuitry, like an XTK model or a SPICE model. Thanks for the tip on IBIS2XTK. I've had XNS ver. 5.3 installed for a month now and didn't realize it was there. I notice that it was available in ver. 5.2, but for some reason, I missed that version. I'll give IBIS2XTK a try on some of my IBIS data. For all my SPICE models, do you recommend using S2IBIS and IBIS2XTK or just SPI2MOD? I'm working on getting an updated version of HSPICE, maybe they will have a converter as you say and life will be much easier. I sincerely look forward to the day when everyone provides IBIS information... I mean models. Regards, Fred FirePower Systems, Inc. Begin forwarded message: Date: Thu, 9 Feb 95 14:31:03 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) To: uunet!uunet!FirePower.COM!fvance@uunet.uu.net Cc: uunet!uunet!scintl.com!gre@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Fred Vance's message of Thu, 9 Feb 95 13:26:02 -0800 <9502092126.AA27604@oahu.FirePower.COM> Subject: Quest for IBIS models Greg, I must heartily DISAGREE with Fred from FirePower. IBIS is a behavioral model standard. IBIS models, though quite usable as SPICE behavoiral models, are also equally usable by the various non-spice offerings of Quad, Hyperlynx, Cadence, Quantic, Interconnectix etc. (sorry who-ever I left out). These non-spice companies have been IBIS compatible since the creation of IBIS (some even before) and have been some of the stronger driving forces in the establishment of the IBIS standard (partially because they pioneered the behavioral model representation). All of the IBIS associated companies have IBIS converters or can read IBIS directly, all have different strengths etc. regards, jon powell Transmission Line Products Manager, Quad Design. From bob@icx.com Thu Feb 9 21:15:31 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19660; Thu, 9 Feb 95 21:15:31 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 9 Feb 95 21:10 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 9 Feb 95 21:12 PST Message-Id: Date: Thu, 9 Feb 95 21:12 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD25.2 DATA DERIVATION EXPANSION IBIS Members: Thank you for the comments. It looks like we have gone full circle on C_comp back to the original and common usage. I will defer any consideration of a "Cor_C_comp" that Jon introduced and focus on just clarifying what we already have. The primary purpose of this BIRD25.2 is to state some of the common assumptions. By nailing down some of these details, we will not be surprised by some very reasonable, but contrary interpretations. I have also chopped and made more specific some of the proposed text. The major impact of BIRD25.2 is to add clarity by: (1) Giving a rationale for populating the "min" and "max" columns. (2) Allowing usage of "slow, weak" process and "fast, strong" process models or devices in developing IBIS models. (3) Stating a MAGNITUDE rationale for inserting C_comp "min" and "max" column entries. (4) Including conditions for [Rising Waveform] and [Falling Waveform] table "min" and "max" column entries, to correct an omission. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 25.2 ISSUE TITLE: DATA DERIVATION EXPANSION REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 25 January 1995 DATE REVISED: 7 Feb 95, 9 Feb 95 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: As IBIS has expanded in functionality, some of the derivation rules and usage has not been fully considered or documented in the standard. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Item #12 is added to the "General syntax rules and guidelines for ASCII IBIS files" section at the beginning to point to important information in the NOTES ON DATA DERIVATION METHOD section at the end: | 12) Important supplimental information is contained in the last section, | "NOTES ON DATA DERIVATION METHOD", concerning how data values are | derived. | Replace the first Paragraph of NOTES ON DATA DERIVATION METHOD section shown below: |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor | base its data on typical process data, and then derate by voltage and | temperature, and a proprietary "X%" factor. This methodology also has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | The replacement text follows: |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. It describes certain | assumed parameter and table extraction conditions if they are not | explicitly specified. It also describes the allocation of data into | the "typ", "min", and "max" columns under variations of voltage, | temperature, and process. | | The required "typ" column for all data represents typical operating | conditions. For most [Model] keyword data, he "min" column describes | slow, weak performance, and the "max" column describes the fast, strong | performance. It is permissible to use weak, slow devices or models to | derive the data for the "min" column, and to use strong, fast devices or | models to derive the data in the "max" columns under the corresponding | voltage and temperature derating conditions for these columns. It is also | permissible to use typical devices or models derated by voltage and | temperature and optionally apply proprietary "X%" and "Y%" factors | described later for further derating. This methodology has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | The voltage and temperature keywords and optionally the process models | control the conditions which define the "typ", "min", and "max" column | entries for all V/I table keywords [Pulldown], [Pullup], [Gnd Clamp], | and [Power Clamp]; all [Ramp] sub-parameters dV/dt_r and dV/dt_f; and | all waveform table keywords and sub-parameters [Rising Waveform], | [Falling Waveform], V_fixture, V_fixture_min, and V_fixture_max. | | The voltage keywords which control the voltage conditions are [Voltage | Range], [Pulldown Reference], [Pullup Reference], [Gnd Clamp Reference], | and [Power Clamp Reference]. The entries in the "min" columns | contain the smallest magnitude voltages, and the entries in the "max" | columns contain the largest magnitude voltages. | | The optional [Temperature] keyword will contain the temperature | which causes or amplifies the slow, weak conditions in the "min" column | and the temperature which causes or amplifies the fast, strong | conditions in the "max" column. Therefore, the "min" column for | [Temperature] will contain the lowest value for bipolar devices (TTL | and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. | | The "min" and "max" columns for all remaining keywords and sub-parameters | will contain the smallest and largest magnitude values. This applies | to the [Model] sub-parameter C_comp as well even if the correlation | to the voltage, temperature, and process variations are known because | information about such correlation is not available in all cases. | | The default temperatures under which all V/I tables are extracted are | provided below. The same defaults also are stated for the [Ramp] | sub-parameters, but they also apply for the waveform keywords. | | The stated voltage ranges for V/I tables cover the most common, single | supply cases. When multiple supplies are specified, the voltages shall | extend similarly to values which handle practical extremes in reflected | wave simulations. | | For the [Ramp] sub-parameters, the default test load and voltages are | provided. However, the test load can be entered directly by the R_load | sub-parameter. The allowable test loads and voltages for the waveform | keywords are stated by required and optional sub-parameters; no defaults | are needed. Even with waveform keywords, the [Ramp] keyword continues | to be required so that the IBIS model remains functional in situations | which do not support waveform processing. | | The following discussion lists test details and default conditions. | Existing text follows. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION As IBIS expands to capture more capability, there needs to be consistent alignment of certain correlated data. More restrictive guidelines are needed in specifying "min" and "max" column entries so that related groupings for the die model can all exist in the same column. The rational for "min" and "max" columns needs to be expressed. Because Spice based I/O models frequently are given as separate "slow, weak" and "fast, strong" models such as in the TI Advanced Bus Interface SPICE I/O Models Data Book, provisions to accept such models needed to be stated. This is consistent with actual usage and needs to be included in supporting utilities such as "s2ibis" for Version 2.1. If the [Temperature] keyword is used, the data that goes into the "min" and "max" columns is restated in terms of the reason for providing the "min" and "max" columns. Furthermore, while temperature itself may not necessarily be used in processing an IBIS model, it could be used to generate it through automated tools. Therefore, the temperature used needs to be aligned with the other data in the column. The C_comp sub-parameter has special consideration because it's correlation with temperature, voltage and process variations may not always be known. Consistent with existing practice, it is positioned based on magnitude regardless of any known correlation information so that all IBIS models can be used in a consistent manner. Conditions for [Rising Waveform] and [Falling Waveform] column entries are clarified to be consistent with the [Ramp] sub-parameter entries. The "min" column and "max" column entries apply only to the "process- based" IBIS data. Other data follow standard "min" and "max" entries based on magnitude because they pertain to variations that are unrelated to process parameter variations or else their application (such as terminator resistor values) would be treated (optionally) as an independent variation for analysis and design. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION From rharr@arpa.mil Fri Feb 10 16:18:17 1995 Return-Path: Received: from [158.63.7.159] by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01427; Fri, 10 Feb 95 16:18:17 PST Date: Fri, 10 Feb 95 16:18:16 PST X-Sender: randyh@vhdl.vhdl.org (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Derrick Duehren From: rharr@arpa.mil (Randolph E. "Randy" Harr) Subject: Re: To Many Hops >> IBIS Reflector Cc: ibis@vhdl.org My apologies to your group for this lack of service. I have experienced the same long delay in getting my name removed from the list. I have turned over ibis-request and ibis-owner to Derrick -- these messages will go to him until he designates a different owner / caretaker. Derrick -- you can telnet to the machine using your account and edit the files using EMACS, VI or ED. If this is a problem, you can either create 8.3 character name aliases for each file or FTP them onto your PC for editing and then FTP them back. I have removed all the listed "problem" names below (as well as my own as I unfortunately do not have the time to even skip all the messages of your very active group!). Please accept my apologies and let me know if you continue to have problems. I will be glad to setup group admin accounts for anyone Derrick or Will designate. +----------------------------------------------------------------+ | Randolph E. (Randy) Harr (off) (703) 696-0085 | | ARPA/ESTO, 3701 N. Fairfax Drive (fax) (703) 696-2203 | | "Research Run", Arlington, VA 22203-1714 rharr@arpa.mil | +----------------------------------------------------------------+ > > Stephen, > > Yes, I know. I get them on every message I send out. It is very >annoying. I > have forwarded many requests to ibis-request to have these names removed from > the reflector list, but the list has not been changed and we are still >getting > the messages. I would edit the file if I could, but it's a >8 character UNIX > filename so I can only read it with my DOS/Windows machine. > > Invalid Addresses: > kerryp@arnie.xilinx.com > canyimi@pcocd2.intel.com > jeff@deutsch.com > dermott@contec.com > maah@contec.com > > - Derrick > +--------------------------------------------------------------------+ | Randolph E. (Randy) Harr | | randy.harr@vhdl.org, rharr@mojave.stanford.edu. (415) 725-3639 | | | | NEW ADDRESS AFTER 1 FEB: | | ARPA/ESTO, 3701 Fairfax Drive, Arlington, VA 22203-1714 | | (703) 696-0085 (off), (703) 696-2203 (fax), rharr@arpa.mil | +--------------------------------------------------------------------+ From mbs@eos.ncsu.edu Tue Feb 14 12:33:21 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18807; Tue, 14 Feb 95 12:33:21 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA10471; Tue, 14 Feb 1995 15:28:20 -0500 From: mbs@eos.ncsu.edu Message-Id: <9502142028.AA10471@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: New IBIS Models Date: Tue, 14 Feb 95 15:28:19 EST Two new models have been added to the library. These are pp100sem.ibs pp66sem.ibs and are models for the pentium chip. They are in the directory vhdl.org:/pub/ibis/models/intel/pentium Michael Steer (The Librarian) From Derrick_Duehren@ccm2.jf.intel.com Tue Feb 21 11:43:30 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16263; Tue, 21 Feb 95 11:43:30 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rh0PL-000UdtC; Tue, 21 Feb 95 11:38 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rh0PL-000tweC; Tue, 21 Feb 95 11:38 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 21 Feb 95 11:38:02 PST Date: Tue, 21 Feb 95 11:38:02 PST From: Derrick Duehren Message-Id: <950221113802_1@ccm.hf.intel.com> To: PattiR@EIA.org, IBIS@vhdl.org Subject: IBIS EIA Charter (approved 2/6/95) Text item: Text_1 IBIS EIA Charter Approved 2/6/95 The IBIS Open Forum is seeking to become a committee under the Design Automation Division of the Electronic Information Group of EIA. IBIS Open Forum Scope --------------------- The IBIS EIA Open Forum develops, supports, and promotes accurate vendor-independent behavioral I/O buffer model specification standards. Chairperson Designate (Interim Chair) -------------------------------------- Will Hobbs (503) 696-4369, Fax (503) 696-4210 Will_Hobbs@ccm.jf.intel.com XTG Modeling Manager, Intel Corp. Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, OR 97124 USA Committee Roster ---------------- See the roster.txt document on the vhdl.org server for a complete listing. The following companies/universities have actively participated in the past 6 months: AT&T Global Info Solutions Intergraph* Cadence Design Systems* Mentor Graphics Contec National Semiconductor Digital Equipment Corp.* North Carolina State U. Hewlett-Packard* Quad Design* HyperLynx* Quantic Labs* IBM-Motorola alliance Synopsys INCASES* Texas Instruments Integrated Silicon Systems UniCAD Canada Ltd. Intel Corp* Zeelan Technology. Interconnectix, Inc.* * Has purchased the 2.1 Golden Parser source code (under Open Forum rules, these companies vote on issues when there is not a clear consensus during a normal vote). Copyright Ownership/Licenses ---------------------------- The following companies signed a form 2/6/95 to release ownership of the 2.1 spec to the EIA: Intel, Texas Instruments, Interconnectix, Zeelan Technology, Cadence Design Systems, National Semiconductor, UniCAD, Quad Design Technology, HyperLynx, Meta-Software, Quantic Laboratories, Hewlett-Packard, Intergraph Electronics The Golden Parser 1.1 and 2.1 source code is currently owned by Paul Munsey and Ron Neville. They will release the ownership/rights of both versions to the EIA. The s2ibis Spice-to-IBIS conversion utility was developed with ARPA funding to be put into the public domain. EIA will not have ownership. Anyone can create their own conversion utilities. The IBIS Overview and Cookbook documents are owned by Intel. Intel will release the ownership/rights to the EIA. IBIS models can be created by anyone, member or not, without royalty fees. Ownership of IBIS models remains with the creator A licensee to the Golden Parser can use the source code within the licensee's product and distribute any derivative executable works without royalty payment to the IBIS Forum. Licensees may not publicly divulge Golden Parser source code. Appropriate acknowledgments must be included in the derivative works. Operating Policies/Procedures ----------------------------- MEMBERSHIP Committee participation is free and open to any interested person who wants to participate in meetings and internet reflector discussions, submit BIRDs, and submit models to the public-domain billboard. Membership is limited to representatives of dues-paying companies. DUES $500 (US dollars) dues will be collected annually in January. Golden Parser source will be $500. A membership company can license the source code for $250, for a total of $750. In 1995, companies that have already paid $500 for the 2.1 Golden Parser will only pay $250 incremental for membership and the Golden Parser. BENEFITS Membership Companies have the right to vote on all issues. Membership Companies get a 50% discount on licenses to the source code of the IBIS Golden Parser. VOTING Only persons representing Membership Companies can vote. There is one vote per Membership Company. Votes require a simple majority of those Membership Companies present at a meeting, with a minimum quorum of 5 Membership Companies represented. BIRDs must to be distributed 14 days before they can be voted on. All votes must be done by roll call of Membership Company attendees. Votes by written/email proxy are allowed. Changes to this IBIS EIA Charter requires 2/3 vote of all Membership Companies. BIRDs Buffer Issue Resolution Documents (BIRDs) will be used to propose and discuss any changes to the specification and Golden Parser. See Appendix A for the specifications of a BIRD. STRUCTURE Position Responsibilities ----------------------------------------------------------------------------- Chairperson Oversee all forum activities, preside at all general meetings. Finance authority. This person must be an employee of a Membership Company. Vice Chair Cover for chair and secretary in their absence, coordinate all public relations (press releases, media contacts). This person must be an employee of a Membership Company. Secretary Coordinate logistics of all meetings, take and publish meeting minutes within 10 days of meeting. Work with or act as file server sysop to maintain the reflector and on-line files. This person does not need to be an employee of a Membership Company. Librarian Maintain the library of public IBIS models, including verifying authenticity and compliance before posting. This person does not need to be an employee of Membership Company. All officers are selected annually by election of the voting membership. Elections occur at DAC (Design Automation Conference) each year, beginning at the `95 DAC conference. The following interim officers were elected to serve until DAC `95. Chair: Will Hobbs, Intel Corp. Vice-chair: Jon Powell, Quad Design Technology Secretary: Derrick Duehren, Intel Corp. Librarian: Michael Steer, North Carolina State University INTERNET ETIQUETTE When possible, all correspondence, BIRDs, etc. are transmitted via the IBIS reflector in plain ASCII text, 80 columns max., and with no tabs. +++++++++++++++++++++++++++++++ page break ++++++++++++++++++++++++++++++++++ APPENDIX A Buffer Issue Resolution Document (BIRD) (a process for resolving issues) ----------------------------------------------------------------------------- BIRD filename convention: pbirdn_n.txt new/pending abirdn_n.txt approved dbirdn_n.txt dead ----------------------------------------------------------------------------- Issues must be well thought out and clearly documented using this template to be placed on the agenda of IBIS Open Forum meetings. Instructions: Write up your issue and submit it to the Chairperson via the internet. The Chair will do a preliminary check for completeness and (potentially) send your BIRD back to you. If not, the Chair will post the issue to the IBIS reflector. Each issue must be out for review 14 days before the Open Forum will vote on it. During that time, you will be expected to answer questions related to your BIRD. In each meeting announcement, the agenda will list those BIRDs that will be discussed and possibly voted on at that meeting. BIRDs are accepted on a 51% vote of quorum. NOTE: All text in French brackets is for explanation only and should be deleted. ----------------------------- cut here ---------------------------------- ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: {don't fill in, will be filled in by the chairperson} ISSUE TITLE: {one line description of your issue} REQUESTOR: {your name and company} DATE SUBMITTED: {date you sent to the chair} DATE REVISED: {revision date} DATE ACCEPTED BY IBIS OPEN FORUM: {status or date BIRD accepted} ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: {Place a short description of your issue here. People should be able tell by reading this if they care about this in less than 1 minute.} ***************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: {For new keywords, write the text EXACTLY AS IT SHOULD APPEAR in a future IBIS specification. If this is a change, state the old text and the new text again EXACTLY AS IT SHOULD APPEAR. Be sure to give intended location in the specification.} ***************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: {There are many "experts" reviewing this document. Your reasons, analysis, and justifications must be precise and well documented, or your BIRD will be sent back to you. Use this section to show that you've done your homework, and answer all questions that will undoubtedly be asked. If your issue is a change instead of an enhancement, document how backward compatibility is to be addressed.} ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ***************************************************************************** From Derrick_Duehren@ccm2.jf.intel.com Tue Feb 21 11:48:40 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16336; Tue, 21 Feb 95 11:48:40 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rh0UC-000UenC; Tue, 21 Feb 95 11:43 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rh0UB-000twdC; Tue, 21 Feb 95 11:43 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 21 Feb 95 11:43:03 PST Date: Tue, 21 Feb 95 11:43:03 PST From: Derrick Duehren Message-Id: <950221114303_1@ccm.hf.intel.com> To: PattiR@EIA.org, IBIS@vhdl.org Subject: IBIS Open Forum Meeting Minutes 2/6/95 Text item: Text_1 Date: Feb. 21, 1995 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, OR 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum Meeting 2/6/95 To: Apple Computer Duane Talsahashi* ARPA Randy Harr AT&T Global Info Solutions Dave Moxley Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec Dileep Divkar* Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HP Palo Alto Tom Langdorf HP EESof Karl Kachigan*, Henry Wu* HyperLynx Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, John Burnett INCASES Werner Rissiek, Olaf Rethmeier Integrated Silicon Systems Eric Bracken Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd*, David Wiens, Walter Katz IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei*, John Sliney MicroSim Arthur Wong National Semiconductor Syed Huq*, Raj Raghuraum(?)*, Atul Agarwal* NEC Hiroshi Matsumoto North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang* PC Ware Paul Munsey, Ron Neville Quad Design Jon Powell* Quantic Labs Mike Ventham* Racal-Redac John Berrie Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum* Zeelan Technology George Opsahl, Hiro Moriyasu* CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 2/24/95 (916) 356-9999 457668 All meetings are 8:00 AM to 10:00 AM Pacific Time (16:00 to 18:00 UTC). 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------------ Check-in, Intros, Announcements All 22 participants introduced themselves and Ian Dodd "won the world" sweepstakes (an Intel travel alarm clock). New Agenda Items: Release of Golden Parser 2.1 object code (Syed) New Keyword (Bob Ward) EIA discussion Spice to IBIS: Anyone can create one. We discussed three options for dues. 1. $500 dues will be collected annually in January. Companies that have already paid $500 for the 2.1 Golden Parser will have their 1995 waived. 2. $500 dues will be collected annually in January. Companies that have already paid $500 for the 2.1 Golden Parser will have their 1995 dues reduced to $250 if they paid in 1994. If paid in 1995, the fee will be waived. 3. $500 dues will be collected annually in January. Golden Parser source will be $500. If a company is a membership, they can license the source code for $250, for a total of $750. Companies that have already paid $500 for the 2.1 Golden Parser will only pay $250 incremental for membership and the Golden Parser. The forum approved #3 unanimously. AR Will/Derrick -- Resolve alias-list problems. [Update, Derrick now owns the lists and receives all ibis-request mail, although is having technical difficulties telnetting to make the changes.] We agreed to have the funds in our IBIS account at Conference Management Systems roll over into EIA. AR Patti -- Send out letter to each company to confirm intent to join. Kellee pointed out that the executable version of the parser needs to be explicitly reserved for public-domain distribution. The license fee for the Golden Parser will be one-time, with rights to use forever. Future Direction Discussion (Will Hobbs) Will briefly summarized IBIS's history from its beginning in 1993. And introduced potential future directions/projects for the forum: o Fund computer programs for making it easier to create IBIS models. For example, a project to create a Windows/UNIX editor with the Golden Parser built in (PERL/Auk scripts or Excel spreadsheet macros). o Actively encourage creation of model libraries. o Make clear the stability of V1.1 and V2.1, obsolescence immunity. o EDA vendors implement V2.1. o EIA affiliation (in process). o Formation of a separate IBIS users group for model developers (conference and technical forum). Possibly using a WWW home page, internet newsgroup, SI list, mail list (newsletter). o Publish articles, books, press releases. o Update the cookbook to V2.1. o Publicize the reflector, vhdl.org. o Add more models to the vhdl.org library. publicize them. o DAC IBIS booth. "IBIS supporter" stand-up placards for DAC. As new interim vice-chair, Jon Powell will coordinate the creation and distribution of the placards. o Create an IBIS modeling company. A decryption Application Programmable Interface may be needed to help enable charging fees for IBIS models. o V3.0 Suggestions. - Improved package elements - Improve diode modeling: transit time, charge storage - Refine SSO modeling - Support noise injection on Vcc - Support feedback - Curve scaling (T,V) from typical to min, max - Model additional devices (transistors, analog I/O, ???) - EMI, microwave - Power modeling - Support for static timing o Potential new uses/arenas for IBIS - Integrate with VHDL and Verilog for mixed simulation, timing - Electronic data book element - Bi-directional medium for information exchange between component architects, system designers, and I/O buffer designers o Need to grow the IBIS tool kit - Data-extraction methodologies (improved techniques, expanded cookbook, auto-extraction tools, auto-validation tools [silicon and simulation]) - Improve silicon testing and offer guaranteed models - Improve Golden Waveform support by EDA and model vendors - Create a compliance test suite Diode Storage Effects (Tim Schryer, Intel) Tim was unable to participate. Diode Storage Effects (Jon Powell, Quad) Jon Powell discussed diode turn-on time, charge storage. He has been exploring how to extract information that can be represented in IBIS format. E.g., a voltage/capacitance array. Transit time approach is well stated and is in Spice already, but it is tough to measure and formulate, so it is less desirable for IBIS. The IBIS spec assumes that diodes turn on/off instantaneously. There is a time delay due to the stored charge in the diode. Jon invited any interested parties to devise a means of adding diode storage effects to the IBIS standard. Arpad discussed the difficulty of measuring capacitance with readily available equipment. He noticed that when a sweep goes from low-to-high and high-to-low, he gets a different result. He found he could reverse engineer the capacitance through an averaging process. Hiro Moriyasu shared his experience with actual measurement experience. As you switch from - to + through a resistor, stored charge causes a delay, a step in the voltage as measured at the diode, for a time related to the size of capacitance. Td/tau = ln(1 + (If/Ir)), where If = forward bias current and Ir = reverse bias current. tau is a range of 20 -100 nS over reasonable operating ranges, and this technique predicts well within 10%. This was described as we went from forward to reverse biased. You don't see this effect when going from reversed to forward biased. Zeelan measured in the latter case and does not see the delay. Arpad described experience with a 74F part that has a speed-up diode on the input. He found that he could simulate it with a capacitor that is switched in for one transition (forward to reverse bias transition) and out for the other. We'd like a behavioral diode description. We'd like a way to take spice and measured data and convert it into this behavioral way. A voltage-dependent resister may be a valid method. AR Arpad, Hiro, and Jon -- Post a description of your approaches to diode storage effects to the reflector. We will attempt to converge on a behavioral representation that captures the essential elements or the best of the three. Handling Multiple Personality Drivers Discussion (Bob Ward, TI) Bob Ward described a chip that has a "personality pin" that allows a driver to be switched from TTL to CMOS to GTL, and some customer wants to do this dynamically! At 1.5 V on the personality pin, one type of output is enabled, another for 1.5V - 2.5V, and the third for >2.5V. Ian Dodd suggested three models in parallel with separate enables. Hiro suggested driving the enable pin with analog comparators. Jon and Kellee discussed ways of specifying multiple models for the same pin and selecting between them. For example, "Pin, model, model, model". Jon suggested adding hints in cookbook on how to handle multiple driver personalities per pin. Hiro mentioned that VHDL-A handles this type of case (1076.1) Issues Regarding Min and Max Model Data (Bob Ross, Interconnectix) Bob Ross discussed Min and Max data and characterization. 2 Paradigms: 1) min corresponds to min data, max to max data. 2) min corresponds to the min process corner, max to max corner (e.g., min capacitance => max speed). This relates to Bird 25. For temperature in V2.1, temperature is specifically called out for CMOS min to correspond to highest temperature value. Hiro pointed out we have 3 axes to deal with, given environment and process (voltage, temperature, process). The main thrust of the presentation was clarity of the spec. Another way of handling it is with new keywords that call out what columns to use for fast and slow behavior. Absolute value of voltage is not clearly spelled out, either: for ECL, increasing the absolute value for the power supply corresponds to making it go farther below zero. Arpad suggested a counter-example of max capacitance == slow; big transistor = fast; and = big c_comp. We may also want to call out/highlight the Data Derivation section at the front of the spec. We agreed that this issue is one of clarifying/interpreting the spec. Bob will update BIRD 25 to reflect the issues discussed. On another subject, Bob said that when min or max columns are not present and a min or max simulation is being done, everyone generally defaults to typ. For waverform tables, however, this is not a good assumption. What do you do when all three columns are not present? E.g., if running min simulation and only typ and max waveform tables are available, Bob suggests reverting to dv/dt_r min instead of typical waveform table. Jon P. disagrees, Will suggested it is the model provider's job to make sure this doesn't get done. Bob also suggested aligning waveform tables to start at 0 nS or to shift them to align all at same point (5 nS, e.g.). Waveform priority: use first one. Waveform test load priority: favor resistive loads. Few or many points? Vary v_fixture of r_fixture? CMOS, TTL, ECL strategies? AR Intel -- Determine how the Intel-posted models handle these issues and report to Bob Ross. AR Bob Ross -- Update BIRD 25. [Done, below] Based on 2/6/95 discussions, BIRD25.1 is issued. It contains an initial statement to point to the Notes on Data Extraction per Karl Kachigan's suggestion. It also changes the default of C_comp to be consistent with existing practice when min and max values are given independent of process information. This is the major change from BIRD25. There are also some minor text corrections. Gate Modulation and Replacing Min. and Max. Tables with Scaling (Arpad Muranyi, Intel) Arpad presented a proposal for replacing the Min. and Max. tables with x-scale, x-shift, y-scale, y-shift scaling parameters for Vcc and Temp. Arpad proposes that this mechanism could provide more detailed and efficient ways to describe the effects of Vcc and temperature variations. Arpad discussed gate modulation: ground bounce causes pre-driver to shift relative to output driver, causing a shift in output V/I. Does IBIS contain enough data to model this effect? In regard to scaling, Arpad showed that under normal conditions, V/I tables can be scaled by some K factor for voltage and temperature. Iout = Kvcc*Vgs*IV@5V, where Kvcc is the scaling factor and Vgs = instantaneous die Vcc. Perhaps we could have a separate scaling factor for temperature, voltage and process. Complications arise from the fact that some parameters scale, while others shift (n-channel pullups versus clamping diodes, e.g.; or, VT curves may scale on time axis but not on voltage axis). Problem could be solved with separate x and y shift and scaling values for temperature and voltage. What is missing from this is the charge storage in the buffers that resist change to gate modulation effects, and Vcc ringing. We still don't know the skew between buffers turning on. Inter-simulation Correlation Discussion (Will Hobbs) Not discussed due to lack of time. Alternative Packaging Representations Discussion (Stephen Peters) Stephen presented an expanded proposal for representing packages. Jon Powell expressed concern over using this proposal with Multi-chip module parts. Wrap-up, Next Meeting Plans Our next meeting is a "normal" teleconference 2/24/95. ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From Derrick_Duehren@ccm2.jf.intel.com Tue Feb 21 12:00:16 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16414; Tue, 21 Feb 95 12:00:16 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rh0fp-000UexC; Tue, 21 Feb 95 11:55 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rh0fp-000twdC; Tue, 21 Feb 95 11:55 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 21 Feb 95 11:55:05 PST Date: Tue, 21 Feb 95 11:55:05 PST From: Derrick Duehren Message-Id: <950221115505_3@ccm.hf.intel.com> To: PattiR@EIA.org, IBIS@vhdl.org Subject: IBIS 2/24/95 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 2/24/95 Bridge: Res: (916) 356-9999 457668 All meetings are 8:00 AM to 10:00 AM Pacific Time (16:00 to 18:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes (and ARs) - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available 8:20 Progress toward enlisting new IC vendors All 8:30 Golden Parser 2.1 status Munsey 8:45 EIA affiliation status Hobbs Rev 2.1 updates Hobbs o S2IBIS 2.1 o Cookbook o Overview 9:15 BIRD 25.1 discussion Ross 9:55 Wrap-up, next meeting plans Hobbs From mbs@eos.ncsu.edu Tue Feb 21 19:33:24 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19354; Tue, 21 Feb 95 19:33:24 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA09796; Tue, 21 Feb 1995 22:28:18 -0500 From: mbs@eos.ncsu.edu Message-Id: <9502220328.AA09796@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: New IBIS Model Date: Tue, 21 Feb 95 22:28:18 EST There is a new ibis model from National Semiconductot Corporation. It is ds26c31.ibs It is in the directory vhdl.org:/pub/ibis/models/national.sc This is a v2.1 file. It has not been tested as to whether the golden parser accepts it. (There are not executables available to me) Michael Steer From mbs@eos.ncsu.edu Tue Feb 21 19:43:17 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19405; Tue, 21 Feb 95 19:43:17 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA09830; Tue, 21 Feb 1995 22:38:10 -0500 From: mbs@eos.ncsu.edu Message-Id: <9502220338.AA09830@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: IBIS models Date: Tue, 21 Feb 95 22:38:10 EST Correction. There are two new models from National Semiconductor They are in the dircetory bhdl.org:/pub/ibis/models/national/semiconductor ds26c31.ibs interface 2/09/95 R1.0 V2.1 RS-422 Quad Diff Line Driver ds26c32.ibs interface 2/09/95 R1.0 V2.1 RS-422 Quad Diff Line Receiver Michael Steer From huq@rockie.nsc.com Wed Feb 22 08:29:05 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28202; Wed, 22 Feb 95 08:29:05 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA08090 for ibis@vhdl.org; Wed, 22 Feb 95 08:23:59 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA25201 for ibis@vhdl.org; Wed, 22 Feb 95 08:23:57 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA12932; Wed, 22 Feb 95 08:24:21 PST Date: Wed, 22 Feb 95 08:24:21 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9502221624.AA12932@rockie.nsc.com> To: ibis@vhdl.org Subject: gpv2.1 release date ? Hi IBISgurus, The question still remains: When will the gp2.1 be released ? Can someone answer this before the Fri meeting? Regards, Syed National Semiconductor From huq@rockie.nsc.com Wed Feb 22 08:29:14 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28207; Wed, 22 Feb 95 08:29:14 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA08107 for ibis@vhdl.org; Wed, 22 Feb 95 08:24:09 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA25206 for ibis@vhdl.org; Wed, 22 Feb 95 08:24:08 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA12935; Wed, 22 Feb 95 08:24:32 PST Date: Wed, 22 Feb 95 08:24:32 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9502221624.AA12935@rockie.nsc.com> To: ibis@vhdl.org, mbs@eos.ncsu.edu Subject: Re: IBIS models Corrections: The directory path is: vhdl.org:/pub/ibis/models/national/interface Regards, Syed National Semiconductor > From mbs@eos.ncsu.edu Tue Feb 21 19:53:06 1995 > From: mbs@eos.ncsu.edu > To: ibis@vhdl.org > Subject: IBIS models > Date: Tue, 21 Feb 95 22:38:10 EST > Content-Length: 314 > > > Correction. There are two new models from National Semiconductor > > They are in the dircetory bhdl.org:/pub/ibis/models/national/semiconductor > > ds26c31.ibs interface 2/09/95 R1.0 V2.1 RS-422 Quad Diff Line Driver > ds26c32.ibs interface 2/09/95 R1.0 V2.1 RS-422 Quad Diff Line Receiver > > > Michael Steer > From jonp@qdt.com Wed Feb 22 17:23:42 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02531; Wed, 22 Feb 95 17:23:42 PST Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyegj05076; Wed, 22 Feb 1995 20:18:47 -0500 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Wed, 22 Feb 1995 20:18:35 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01342; Wed, 22 Feb 95 16:44:10 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA01864; Wed, 22 Feb 95 16:47:57 PST Date: Wed, 22 Feb 95 16:47:57 PST From: jonp@qdt.com (Jon Powell) Message-Id: <9502230047.AA01864@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA26044; Wed, 22 Feb 95 16:46:05 PST To: ibis@vhdl.org Subject: [uunet!eos.ncsu.edu!mbs: New IBIS Model] I believe it is IBIS policy not to post models unless we have proven them to pass the golden parser. Can we set up a BETA area or something? jonp Return-Path: From: uunet!eos.ncsu.edu!mbs To: uunet!vhdl.org!ibis Subject: New IBIS Model Date: Tue, 21 Feb 95 22:28:18 EST There is a new ibis model from National Semiconductot Corporation. It is ds26c31.ibs It is in the directory vhdl.org:/pub/ibis/models/national.sc This is a v2.1 file. It has not been tested as to whether the golden parser accepts it. (There are not executables available to me) Michael Steer From Will_Hobbs@ccm2.jf.intel.com Wed Feb 22 17:57:59 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02735; Wed, 22 Feb 95 17:57:59 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rhSjY-000Uf2C; Wed, 22 Feb 95 17:52 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rhSjX-000twcC; Wed, 22 Feb 95 17:52 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 22 Feb 95 17:52:47 PST Date: Wed, 22 Feb 95 17:52:47 PST From: Will Hobbs Message-Id: <950222175247_4@ccm.jf.intel.com> To: jonp@qdt.com, ibis@vhdl.org Subject: Re: [uunet!eos.ncsu.edu!mbs: New IBIS Model] Text item: Jon, et al, I asked Bob Ross to run it through the parser, and it did pass. I agree that in the future, it should not go into the release area until it has passed this test. A Beta area is a good idea. Will I believe it is IBIS policy not to post models unless we have proven them to pass the golden parser. Can we set up a BETA area or something? jonp Return-Path: From: uunet!eos.ncsu.edu!mbs To: uunet!vhdl.org!ibis Subject: New IBIS Model Date: Tue, 21 Feb 95 22:28:18 EST There is a new ibis model from National Semiconductot Corporation. It is ds26c31.ibs It is in the directory vhdl.org:/pub/ibis/models/national.sc This is a v2.1 file. It has not been tested as to whether the golden parser accepts it. (There are not executables available to me) Michael Steer 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: [uunet!eos.ncsu.edu!mbs: New IBIS Model] To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA26044; Wed, 22 Feb 95 16:46:05 PST Message-Id: <9502230047.AA01864@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Wed, 22 Feb 95 16:47:57 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA01864; Wed, 22 Feb 95 16:47:57 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01342; Wed, 22 Feb 95 16:44:10 PST Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Wed, 22 Feb 1995 20:18:35 -0500 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyegj05076; Wed, 22 Feb 1995 20:18:47 -0500 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02531; Wed, 22 Feb 95 17:23:42 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 22 Feb 95 17 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 22 Feb 9 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rhSd2-000twcC; Wed, 22 Feb 95 17:46 PST From Derrick_Duehren@ccm2.jf.intel.com Thu Feb 23 09:52:57 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12478; Thu, 23 Feb 95 09:52:57 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rhhdn-000UdSC; Thu, 23 Feb 95 09:47 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rhhdm-000tweC; Thu, 23 Feb 95 09:47 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 23 Feb 95 09:47:50 PST Date: Thu, 23 Feb 95 09:47:50 PST From: Derrick Duehren Message-Id: <950223094750_1@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Re[2]: [uunet!eos.ncsu.edu!mbs: New IBIS Model] I thought Michael Steer was parsing the files as part of his librarian duties. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 696-4299, Fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 ______________________________ Reply Separator _________________________________ Subject: Re: [uunet!eos.ncsu.edu!mbs: New IBIS Model] Author: Will Hobbs at JFCCM3 Date: 2/22/95 6:00 PM Jon, et al, I asked Bob Ross to run it through the parser, and it did pass. I agree that in the future, it should not go into the release area until it has passed this test. A Beta area is a good idea. Will I believe it is IBIS policy not to post models unless we have proven them to pass the golden parser. Can we set up a BETA area or something? jonp Return-Path: From: uunet!eos.ncsu.edu!mbs To: uunet!vhdl.org!ibis Subject: New IBIS Model Date: Tue, 21 Feb 95 22:28:18 EST There is a new ibis model from National Semiconductot Corporation. It is ds26c31.ibs It is in the directory vhdl.org:/pub/ibis/models/national.sc This is a v2.1 file. It has not been tested as to whether the golden parser accepts it. (There are not executables available to me) Michael Steer From Will_Hobbs@ccm2.jf.intel.com Thu Feb 23 10:29:24 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12930; Thu, 23 Feb 95 10:29:24 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rhiD4-000UefC; Thu, 23 Feb 95 10:24 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rhiD4-000twcC; Thu, 23 Feb 95 10:24 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 23 Feb 95 10:24:18 PST Date: Thu, 23 Feb 95 10:24:18 PST From: Will Hobbs Message-Id: <950223102418_1@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, ibis@vhdl.org Subject: Re[3]: [uunet!eos.ncsu.edu!mbs: New IBIS Model] Text item: Derrick, This was part of it, but he didn't have a 2.1 parser, so he put it through anyway, rather than delaying it. This problem should go away after we give the parser our stamp of approval and post its object code. Will I thought Michael Steer was parsing the files as part of his librarian duties. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 696-4299, Fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 ______________________________ Reply Separator _________________________________ Subject: Re: [uunet!eos.ncsu.edu!mbs: New IBIS Model] Author: Will Hobbs at JFCCM3 Date: 2/22/95 6:00 PM Jon, et al, I asked Bob Ross to run it through the parser, and it did pass. I agree that in the future, it should not go into the release area until it has passed this test. A Beta area is a good idea. Will I believe it is IBIS policy not to post models unless we have proven them to pass the golden parser. Can we set up a BETA area or something? jonp Return-Path: From: uunet!eos.ncsu.edu!mbs To: uunet!vhdl.org!ibis Subject: New IBIS Model Date: Tue, 21 Feb 95 22:28:18 EST There is a new ibis model from National Semiconductot Corporation. It is ds26c31.ibs It is in the directory vhdl.org:/pub/ibis/models/national.sc This is a v2.1 file. It has not been tested as to whether the golden parser accepts it. (There are not executables available to me) Michael Steer Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re[2]: [uunet!eos.ncsu.edu!mbs: New IBIS Model] To: ibis@vhdl.org Message-Id: <950223094750_1@ccm.jf.intel.com> From: Derrick Duehren Date: Thu, 23 Feb 95 09:47:50 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 23 Feb 95 09:47:50 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rhhdm-000tweC; Thu, 23 Feb 95 09:47 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rhhdn-000UdSC; Thu, 23 Feb 95 09:47 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12478; Thu, 23 Feb 95 09:52:57 PST Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, 23 Feb 95 10 Received: from aurora by ichips.intel.com (5.64+/10.0i); Thu, 23 Feb 95 10:19:24 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rhi8P-000twcC; Thu, 23 Feb 95 10:19 PST From kellee@nwlink.com Fri Feb 24 09:32:29 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25117; Fri, 24 Feb 95 09:32:29 PST Received: from kellee (port15.link.nwlink.com) by washington.nwlink.com with SMTP id AA01797 (5.67b/IDA-1.5 for ); Fri, 24 Feb 1995 09:26:26 -0800 Date: Fri, 24 Feb 1995 09:26:26 -0800 Message-Id: <199502241726.AA01797@washington.nwlink.com> X-Sender: kellee@nwlink.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Where to get MOSAIC for the PC At the IBIS meeting today several people expressed interest in getting a Mosaic package for the PC. The ftp site: ftp.NCSA.uiuc.edu contains a very good windows Mosaic package that is public domain from a university. Have a great day. Kellee .. Have a great day... From Donald_Telian@ccm.fm.intel.com Fri Feb 24 12:14:22 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26392; Fri, 24 Feb 95 12:14:22 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0ri6K7-000UhEC; Fri, 24 Feb 95 12:09 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0ri6K7-000twdC; Fri, 24 Feb 95 12:09 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 24 Feb 95 12:09:10 PST Date: Fri, 24 Feb 95 12:09:10 PST From: Donald Telian Message-Id: <950224120910_6@ccm.hf.intel.com> To: Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com, ibis@vhdl.org Cc: gre@scintl.com Subject: Re[2]: Quest for IBIS models, A NOTE TO IBIS USERS Text item: Text_1 IBISers, I've been encouraged to see the latest chain of emails. It shows me that there is a growing USER interest in IBIS models. For a while now, I've seen the need for an "IBIS Users Group" (IUG!?, needs work, too blunt, and it has nothing to do with birds). I almost started this myself, but it doesn't make sense given my current job objectives. This group would focus on the USEABILITY of IBIS models, and push for the AVAILABILITY of IBIS models. Accuracy has been well addressed, but useability can get easily overlooked. As someone who is responsible for releasing IBIS Models, I (for one) would definitely pay attention to what such a group might come up with. It's difficult to handle miscellaneous requests from all over, but if such a group came up with a prioritized list of what could and should happen with IBIS we could work with that. I think simulation tool vendors would feel the same way. And how about a list of the "Top 10 Necessary IBIS Models", along with the manufacturer(s) who should provide them? Model releases normally flow from a certain threshold of end user pull or customer demand. Trying to look at the modeling problem from the user's perspective is part of what started IBIS in the first place, and the ball is now rolling. It has been pointed out that the Open Forum is largely simulation companies. That needed to happen to coordinate model style. Now that there's agreement on format, it's time for the users to organize, stand up, and define the next step. Any takers? Donald Telian Intel Corporation PS: Time-wise, this probably makes more sense than everyone trying to push for models by themselves. ------------------------------------------------------------------------------ Greg, My experience in getting Spice and/or IBIS models has varied dramatically from vendor to vendor. As this might also be of some interest to the various tool vendors, here's my feedback... My starting point is usually the vendor's rep. Inevitably the rep has no clue what we're requesting, though they do come up to speed fairly quickly. Within a day or so I get feedback as to what's available. An increasing number of companies have Spice information readily available, and a small number have v1.1 IBIS stuff available. I've yet to see a v2.1 model (though Intel has provided equivalent Quad and HSpice models for buffers that couldn't be accurately modeled in the earlier format). Interestingly enough, many of the companies I've encountered that have IBIS models also are willing to provide the original Spice info. I make a point to try to get my hands on Spice models for several reasons (even though I won't be using Spice to run the sims). First off, we've had some success in getting vendors to "guarantee" their Spice models. I rarely get guaranteed IBIS models (it's happened once, and wasn't a memorable experience). Secondly, I can gain some insight into the model accuracy by looking through the netlist and device models. Though this can be misleading it can also be quite beneficial. I have a big issue with non-guaranteed models, but that's another subject. Finally, with most Spice models you're free to set the operating conditions (process point, voltage, and temperature) according to the each system's specifications. IBIS min/max conditions are often predefined and accordingly are too conservative for some applications. When Spice models aren't available or can't be obtained in an acceptable time period (the lawyers got involved), I take one of two different approaches depending on my needs. Sometimes I'll ask for IBIS models, while other times I'll ask the vendor to perform a series of buffer characterization sims and simply send me the raw results. The second approach has worked well when the vendor doesn't have IBIS models, doesn't know what IBIS models are, has v1.1 models that aren't accurate enough, or has the wrong operating conditions in their standard models. These two approaches have worked well at times, while other times the whole experience is a big pain in the [insert favorite anatomical reference here]. As to Zeelan models, they could come in handy at times. I've yet to purchase a copy of their library for two reasons: it doesn't contain min/max models and doesn't contain all the parts I think it should (DRAMs, cache RAMs, etc.). There have been times, however, when it would've been beneficial to have their library available. As to industry trends, I've seen a positive shift over the last 6 months or so. In general most of the companies have a long way to go, but I get the impression that more and more of 'em are heading the right way. I know I've been going to a lot of trouble to educate a number of 'em... Mark Leonard Lead Engineer, Signal Integrity Group Compaq Computer Corporation From bob@icx.com Fri Feb 24 18:05:26 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28700; Fri, 24 Feb 95 18:05:26 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 24 Feb 95 18:00 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 24 Feb 95 18:02 PST Message-Id: Date: Fri, 24 Feb 95 18:02 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD25.3 DATA DERIVATION EXPANSION IBIS Members: The Approved Version of BIRD25.3 is presented with the addition of the "C_comp ..." paragraph and some text corrections. Thank you all for your comments and consideration. The major impact of BIRD25.3 is to add clarity by: (1) Giving a rationale for populating the "min" and "max" columns. (2) Allowing usage of "slow, weak" process and "fast, strong" process models or devices in developing IBIS models. (3) Stating a MAGNITUDE rationale for inserting C_comp "min" and "max" column entries. (4) Including conditions for [Rising Waveform] and [Falling Waveform] table "min" and "max" column entries, to correct an omission. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 25.3 ISSUE TITLE: DATA DERIVATION EXPANSION REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 25 January 1995 DATE REVISED: 7Feb95, 9Feb95, 24Feb95 DATE ACCEPTED BY IBIS OPEN FORUM: 24Feb95 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: As IBIS has expanded in functionality, some of the derivation rules and usage have not been fully considered or documented in the standard. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Item #12 is added to the "General syntax rules and guidelines for ASCII IBIS files" section at the beginning to point to important information in the NOTES ON DATA DERIVATION METHOD section at the end: | 12) Important supplimental information is contained in the last section, | "NOTES ON DATA DERIVATION METHOD", concerning how data values are | derived. | Replace the first Paragraph of NOTES ON DATA DERIVATION METHOD section shown below: |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. The intention is to | avoid over-guardbanding which enables simulation results that are meaningful | and useful. This intention is accomplished by having each silicon vendor | base its data on typical process data, and then derate by voltage and | temperature, and a proprietary "X%" factor. This methodology also has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | The replacement text follows: |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | This section explains how data values are derived. It describes certain | assumed parameter and table extraction conditions if they are not | explicitly specified. It also describes the allocation of data into | the "typ", "min", and "max" columns under variations of voltage, | temperature, and process. | | The required "typ" column for all data represents typical operating | conditions. For most [Model] keyword data, the "min" column describes | slow, weak performance, and the "max" column describes the fast, strong | performance. It is permissible to use slow, weak devices or models to | derive the data for the "min" column, and to use fast, strong devices or | models to derive the data in the "max" columns under the corresponding | voltage and temperature derating conditions for these columns. It is also | permissible to use typical devices or models derated by voltage and | temperature and optionally apply proprietary "X%" and "Y%" factors | described later for further derating. This methodology has the | nice feature that the data can be derived either from vendor-proprietary | silicon models, or typical device measurement over temperature/voltage. | | The voltage and temperature keywords and optionally the process models | control the conditions which define the "typ", "min", and "max" column | entries for all V/I table keywords [Pulldown], [Pullup], [Gnd Clamp], | and [Power Clamp]; all [Ramp] sub-parameters dV/dt_r and dV/dt_f; and | all waveform table keywords and sub-parameters [Rising Waveform], | [Falling Waveform], V_fixture, V_fixture_min, and V_fixture_max. | | The voltage keywords which control the voltage conditions are [Voltage | Range], [Pulldown Reference], [Pullup Reference], [Gnd Clamp Reference], | and [Power Clamp Reference]. The entries in the "min" columns | contain the smallest magnitude voltages, and the entries in the "max" | columns contain the largest magnitude voltages. | | The optional [Temperature] keyword will contain the temperature | which causes or amplifies the slow, weak conditions in the "min" column | and the temperature which causes or amplifies the fast, strong | conditions in the "max" column. Therefore, the "min" column for | [Temperature] will contain the lowest value for bipolar devices (TTL | and ECL) and the highest value for CMOS devices. Default values | described later are assumed if temperature is not specified. | | The "min" and "max" columns for all remaining keywords and sub-parameters | will contain the smallest and largest magnitude values. This applies | to the [Model] sub-parameter C_comp as well even if the correlation | to the voltage, temperature, and process variations are known because | information about such correlation is not available in all cases. | | C_comp is considered an independent variable. This is because C_comp | includes bonding pad capacitance, which does not necessarily track | fabrication process variations. The conservative approach to using IBIS | data will associate large C_comp values with slow, weak models, and the | small C_comp values with fast, strong models." | | The default temperatures under which all V/I tables are extracted are | provided below. The same defaults also are stated for the [Ramp] | sub-parameters, but they also apply for the waveform keywords. | | The stated voltage ranges for V/I tables cover the most common, single | supply cases. When multiple supplies are specified, the voltages shall | extend similarly to values which handle practical extremes in reflected | wave simulations. | | For the [Ramp] sub-parameters, the default test load and voltages are | provided. However, the test load can be entered directly by the R_load | sub-parameter. The allowable test loads and voltages for the waveform | keywords are stated by required and optional sub-parameters; no defaults | are needed. Even with waveform keywords, the [Ramp] keyword continues | to be required so that the IBIS model remains functional in situations | which do not support waveform processing. | | The following discussion lists test details and default conditions. | Existing text follows. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION As IBIS expands to capture more capability, there needs to be consistent alignment of certain correlated data. More restrictive guidelines are needed in specifying "min" and "max" column entries so that related groupings for the die model can all exist in the same column. The rationale for "min" and "max" columns needs to be expressed. Because Spice based I/O models frequently are given as separate "slow, weak" and "fast, strong" models such as in the TI Advanced Bus Interface SPICE I/O Models Data Book, provisions to accept such models needed to be stated. This is consistent with actual usage and needs to be included in supporting utilities such as "s2ibis" for Version 2.1. If the [Temperature] keyword is used, the data that goes into the "min" and "max" columns is restated in terms of the reason for providing the "min" and "max" columns. Furthermore, while temperature itself may not necessarily be used in processing an IBIS model, it could be used to generate it through automated tools. Therefore, the temperature used needs to be aligned with the other data in the column. The C_comp sub-parameter has special consideration because it's correlation with temperature, voltage and process variations may not always be known. Consistent with existing practice, it is positioned based on magnitude regardless of any known correlation information so that all IBIS models can be used in a consistent manner. Conditions for [Rising Waveform] and [Falling Waveform] column entries are clarified to be consistent with the [Ramp] sub-parameter entries. The "min" column and "max" column entries apply only to the "process- based" IBIS data. Other data follow standard "min" and "max" entries based on magnitude because they pertain to variations that are unrelated to process parameter variations or else their application (such as terminator resistor values) would be treated (optionally) as an independent variation for analysis and design. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION Subsequent investigation by Intel revealed that C_comp was primarily uncorrelated to the process fabrication variations because it includes bonding capacitance as a primary contributer. A new paragraph was added to state this. From kellee@nwlink.com Fri Feb 24 18:06:02 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28705; Fri, 24 Feb 95 18:06:02 PST Received: from kellee (port17.link.nwlink.com) by washington.nwlink.com with SMTP id AA24903 (5.67b/IDA-1.5 for ); Fri, 24 Feb 1995 17:50:34 -0800 Date: Fri, 24 Feb 1995 17:50:34 -0800 Message-Id: <199502250150.AA24903@washington.nwlink.com> X-Sender: kellee@nwlink.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Donald_Telian@ccm.fm.intel.com From: kellee@nwlink.com Subject: IBIS users group Cc: ibis@vhdl.org Hi Don, I think the IBIS users group is a great idea. We have talked about it several times in the IBIS meetings and I believe Will's last idea was that we would allow users to ask questions in the regular group until it becomes a problem. I would support creating a separate mail group for IBIS users however. Perhaps a real news group would be even better. This was brought up at the last meeting also, and no one there knew what was involved with creating a news group. Kellee Crisafulli, HyperLynx Inc. 206-896-2320 kellee@nwlink.com Have a great day... From bward@Starbase.NeoSoft.COM Sun Feb 26 13:28:08 1995 Return-Path: Received: from Starbase.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19742; Sun, 26 Feb 95 13:28:08 PST Received: (from bward@localhost) by Starbase.NeoSoft.COM (8.6.10/8.6.10) id PAA10598 for ibis@vhdl.org; Sun, 26 Feb 1995 15:22:59 -0600 Date: Sun, 26 Feb 1995 15:22:59 -0600 From: Bob Ward Message-Id: <199502262122.PAA10598@Starbase.NeoSoft.COM> X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 To: ibis@vhdl.org Subject: e-mail silence Hi, ibis folk, I seem to notice a profound silence on the ibis mail list the past three weeks. Seems most uncharacteristic of this crew! Have I fallen off the reflector again, am I having e-mail trouble here, or has the list really been sioent? In particular, was there a Forum conference call last Friday? Thanks, Bob Ward bward@neosoft.com From Derrick_Duehren@ccm2.jf.intel.com Mon Feb 27 09:01:51 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00877; Mon, 27 Feb 95 09:01:51 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rj8kT-000UfUC; Mon, 27 Feb 95 08:56 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rj8kR-000twfC; Mon, 27 Feb 95 08:56 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 27 Feb 95 08:56:37 PST Date: Mon, 27 Feb 95 08:56:37 PST From: Derrick Duehren Message-Id: <950227085637_1@ccm.hf.intel.com> To: IBIS@vhdl.org, bward@neosoft.com Subject: e-mail silence << NOT Bob, Your name was NOT in the reflector mail list. You are there now. You should get two copies of this mail. One I sent directly to your address, and one through the reflector. BTW: I have added about 10 new reflectees since I took over this responsibility a week ago. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 696-4299, Fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 ______________________________ Forward Header __________________________________ Subject: e-mail silence Author: bward@Starbase.NeoSoft.COM at SMTPGATE Date: 2/26/95 1:33 PM Hi, ibis folk, I seem to notice a profound silence on the ibis mail list the past three weeks. Seems most uncharacteristic of this crew! Have I fallen off the reflector again, am I having e-mail trouble here, or has the list really been sioent? In particular, was there a Forum conference call last Friday? Thanks, Bob Ward bward@neosoft.com From Will_Hobbs@ccm2.jf.intel.com Tue Feb 28 10:27:40 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14649; Tue, 28 Feb 95 10:27:40 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjWZ5-000UefC; Tue, 28 Feb 95 10:22 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjWZ4-000twdC; Tue, 28 Feb 95 10:22 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 28 Feb 95 10:22:30 PST Date: Tue, 28 Feb 95 10:22:30 PST From: Will Hobbs Message-Id: <950228102230_1@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Re[4]: How to spawn a new newsgroup Text item: IBIS-folk, I rarely read net news (~once a year), so I'm passing this info on. I requested information from our network people at Intel on how to spawn a new newsgroup and got the following information. Would someone like to do this on Internet? I propose the group be named something like omp.simulation.ibis. There may be a more appropriate parent group than comp.simulation, but I couldn't find one in my .newsrc. Any takers? Will Usually you get on news.groups and post an article such as: Subject: CFV: Proposed group comp.blue.plastic.widgets Call For Votes for the new comp.blue.plastic.widgets is now open. This group would discuss.... The reasons why this topic deserves its own newsgroup is.... To register your vote, send E-mail with the word "YES" or "NO" and your mail address to: whobbs@ichips.intel.com Then you can post articles in related newsgroups pointing people to the CFV in news.groups (or cross-post the CFV article) so all the right people notice and can discuss (in news.groups) the relative merits of the new group. You should tally up the votes (keeping the e-mail addresses of each voter and how he/she voted in case you're asked). If you get at least 100 more yes votes than no votes, the netiquette rules say the group can be created; otherwise there was not enough interest to justify the bandwidth. --steve Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Re[2]: How to spawn a new newsgroup To: steve@ichips.intel.com, timk@ichips.intel.com, whobbs@ichips.intel.com, Derrick_Duehren@ccm.jf.intel.com, Will_Hobbs@ccm2.jf.intel.com Message-Id: <9502280147.AA14951@pdx840.intel.com> From: steve@ichips.intel.com Date: Mon, 27 Feb 95 17:47:39 PST Received: by pdx840.intel.com (4.1/10.0i); Mon, 27 Feb 95 17:47:39 PST Received: from pdx840 by ichips.intel.com (5.64+/10.0i); Mon, 27 Feb 95 17:47:38 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjH2M-000twcC; Mon, 27 Feb 95 17:47 PST Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re[4]: How to spawn a new newsgroup To: steve@ichips.intel.com, timk@ichips.intel.com, whobbs@ichips.intel.com, Derrick_Duehren@ccm.jf.intel.com Message-Id: <950227175231_2@ccm.jf.intel.com> From: Will Hobbs Date: Mon, 27 Feb 95 17:52:31 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 27 Feb 95 17:52:31 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjH71-000twcC; Mon, 27 Feb 95 17:52 PST Received: from relay.jf.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 27 Feb 95 17:52:33 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjH77-000twcC; Mon, 27 Feb 95 17:52 PST From kellee@nwlink.com Tue Feb 28 10:56:24 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14972; Tue, 28 Feb 95 10:56:24 PST Received: from kellee (port7.link.nwlink.com) by washington.nwlink.com with SMTP id AA22739 (5.67b/IDA-1.5 for ); Tue, 28 Feb 1995 10:50:21 -0800 Date: Tue, 28 Feb 1995 10:50:21 -0800 Message-Id: <199502281850.AA22739@washington.nwlink.com> X-Sender: kellee@nwlink.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Bugs in latest version of Parser. I just got it today. IBISCHK2 ver 2.1d received 2-28-95, Kellee Crisafulli, HyperLynx Inc. bugs: 1) File extension should be case insensitive. If extension has different case then file the program DOES NOT RUN. 2) File name should be case insensitive > e.g. File name opened 'ALTERA.ibs' not the same as File_name 'altera.ibs'. The parser runs on the file but gives an error message. A warning would ok. 3) Spelling error > Bandwidth is miss spelled as Bandidth in an error message e.g. ERROR (line 1363) - Bandidth keyword in wrong location. 4) When tested with file ver_2.ibs which was on the disk with parser the parser asserted -> program bug at line 568 or file PKGMDL.c I am still testing, but I thought I would make an early post to indicate that there are still bugs which must be fixed. Have a great day... From Arpad_Muranyi@ccm.fm.intel.com Tue Feb 28 11:31:33 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15266; Tue, 28 Feb 95 11:31:33 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjXYj-000UeyC; Tue, 28 Feb 95 11:26 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjXYj-000twcC; Tue, 28 Feb 95 11:26 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 28 Feb 95 11:26:12 PST Date: Tue, 28 Feb 95 11:26:12 PST From: Arpad Muranyi Message-Id: <950228112612_3@ccm.hf.intel.com> To: ibis@vhdl.org, kellee@nwlink.com Subject: Re: Bugs in latest version of Parser. I just got it today. Text item: Kellee, According to IBIS1_1 and 2.1, the file names must be lower case. However, in the DOS and Windows world this does not make sense, and some times causes problems (I don't want to go into the details here, but I can explain it again if you want to know about it). In one of the Open Forum meetings I specifically requested that they should compile it case insensitive for the DOS/Windows environment to avoid those issues to which we all agreed to. What platform did you try it on? If it was on DOS/Windows machine, I feel they should make it case insensitive, othervise the all-lower case is the way it should be. Arpad Muranyi Intel Corporation IBISCHK2 ver 2.1d received 2-28-95, Kellee Crisafulli, HyperLynx Inc. bugs: 1) File extension should be case insensitive. If extension has different case then file the program DOES NOT RUN. 2) File name should be case insensitive > e.g. File name opened 'ALTERA.ibs' not the same as File_name 'altera.ibs'. The parser runs on the file but gives an error message. A warning would ok. 3) Spelling error > Bandwidth is miss spelled as Bandidth in an error message e.g. ERROR (line 1363) - Bandidth keyword in wrong location. 4) When tested with file ver_2.ibs which was on the disk with parser the parser asserted -> program bug at line 568 or file PKGMDL.c I am still testing, but I thought I would make an early post to indicate that there are still bugs which must be fixed. Have a great day... 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: Bugs in latest version of Parser. I just got it today. From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 X-Sender: kellee@nwlink.com Message-Id: <199502281850.AA22739@washington.nwlink.com> Date: Tue, 28 Feb 1995 10:50:21 -0800 Received: from kellee (port7.link.nwlink.com) by washington.nwlink.com with SMTP id AA22739 (5.67b/IDA-1.5 for ); Tue, 28 Feb 1995 10:50:21 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA14972; Tue, 28 Feb 95 10:56:24 PST Received: from VHDL.VHDL.ORG by hermes.intel.com (5.65/10.0i); Tue, 28 Feb 95 10 :53:58 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjX3X-000twcC; Tue, 28 Feb 95 10:53 PST From kellee@nwlink.com Tue Feb 28 11:46:33 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15365; Tue, 28 Feb 95 11:46:33 PST Received: from kellee (port18.link.nwlink.com) by washington.nwlink.com with SMTP id AA25021 (5.67b/IDA-1.5 for ); Tue, 28 Feb 1995 11:40:31 -0800 Date: Tue, 28 Feb 1995 11:40:31 -0800 Message-Id: <199502281940.AA25021@washington.nwlink.com> X-Sender: kellee@nwlink.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: >From: Arpad Muranyi >To: ibis@vhdl.org, kellee@nwlink.com >Kellee, > >According to IBIS1_1 and 2.1, the file names must be lower case. However, in >the DOS and Windows world this does not make sense, and some times causes >problems (I don't want to go into the details here, but I can explain it again >if you want to know about it). In one of the Open Forum meetings I >specifically requested that they should compile it case insensitive for the >DOS/Windows environment to avoid those issues to which we all agreed to. > >What platform did you try it on? If it was on DOS/Windows machine, I feel they >should make it case insensitive, othervise the all-lower case is the way it >should be. > >Arpad Muranyi > I have a dual boot 486 with both Windows and Windows NT operating systems. The specific problem is that DOS forces upper case for all file names. Windows NT allows upper or lower case. For the specific test case I was running on Windows NT using the same file directories created when running under windows. When the file names come in with lower case in the file for example xilinx.ibs and the file name is XILINX.IBS than the parser refuses to run on the file. When I changed the file name to XILINX.ibs than the parser runs but a I get an error message stating that the file name does not match the name in the file. This will be a very common probablem for any person running Windows NT getting files from computers running Windows3.1 or DOS. It seems like the same problem would apply for UNIX systems getting files from DOS or Windows 3.1 platforms. Kellee Have a great day... From gre@scintl.com Tue Feb 28 13:07:03 1995 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16048; Tue, 28 Feb 95 13:07:03 PST Received: from relay3.UU.NET by chronos.synopsys.com with SMTP id AA19342 (5.65c/IDA-1.4.4 for ); Tue, 28 Feb 1995 13:01:49 -0800 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyfbw04376; Tue, 28 Feb 1995 16:00:34 -0500 Received: from puma.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Tue, 28 Feb 1995 16:00:33 -0500 Received: from porpoise.scintl.com by scintl.com via SMTP (931110.SGI/930416.SGI) for uunet!vhdl.org!ibis id AA27515; Tue, 28 Feb 95 15:00:19 -0600 Date: Tue, 28 Feb 95 15:00:19 -0600 Message-Id: <9502282100.AA27515@scintl.com> X-Sender: gre@scintl.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: gre@scintl.com (Greg Edlund) Subject: thoughts about IBIS users group I like the idea of an IBIS users group. My personal preference is for a mailing list such as this. I have found that news groups often get cluttered with postings that aren't relevant. I think this can detract from the professional nature of the group and maybe even scare a potential new user away because his or her first impression is that of a bunch of people with time to kill instead of a serious group. It's kind of like Nature magazine publishing an article by some guy whose research just proved that the earth is really a cube. In a short while, people would cancel their subscriptions. Call me an elitist -- it's just my 2 cents. -- Greg Edlund +----+----+ Circuits and Modeling | | | SuperComputers, Int'l. < | ) 1414 W. Hamilton Ave. > ----- ) Eau Claire, WI 54701 < ----- ) (715) 833-7067 voice > | ) (715) 833-7096 FAX | | | gre@scintl.com email +----+----+ From gre@scintl.com Tue Feb 28 13:21:48 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16187; Tue, 28 Feb 95 13:21:48 PST Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQyfbx09537; Tue, 28 Feb 1995 16:16:48 -0500 Received: from puma.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Tue, 28 Feb 1995 16:16:30 -0500 Received: from porpoise.scintl.com by scintl.com via SMTP (931110.SGI/930416.SGI) for uunet!vhdl.org!ibis id AA27602; Tue, 28 Feb 95 15:04:36 -0600 Date: Tue, 28 Feb 95 15:04:36 -0600 Message-Id: <9502282104.AA27602@scintl.com> X-Sender: gre@scintl.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: gre@scintl.com (Greg Edlund) Subject: Does IBIS cover SSO noise? I've begun taking a look at IBIS modeling and what it has to offer for us, and the one thing that sticks out to me is that I don't see any provisions for simultaneously switching output (SSO) noise. This can be a big part of your noise budget, especially when you're pressed for chip-to-chip timing and there's no logic between the latch and the driver. Does anybody know if SSO capability exists within IBIS? If it does not, are there plans to incorportate it? -- Greg Edlund +----+----+ Circuits and Modeling | | | SuperComputers, Int'l. < | ) 1414 W. Hamilton Ave. > ----- ) Eau Claire, WI 54701 < ----- ) (715) 833-7067 voice > | ) (715) 833-7096 FAX | | | gre@scintl.com email +----+----+ From gdpeter@sandia.gov Tue Feb 28 13:34:34 1995 Return-Path: Received: from sass165 (sass165.sandia.gov) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16545; Tue, 28 Feb 95 13:34:34 PST Received: from sass191.ess.sandia.gov (sass191.ess.sandia.gov [134.253.21.10]) by sass165 (8.6.8/8.6.6) with SMTP id OAA14995 for ; Tue, 28 Feb 1995 14:34:00 -0700 Received: from sass1365.sandia.gov by sass191.ess.sandia.gov (4.1/SMI-4.1) id AA28620; Tue, 28 Feb 95 14:30:29 MST Date: Tue, 28 Feb 95 14:30:29 MST From: gdpeter@sandia.gov (Gary Peterson) Message-Id: <9502282130.AA28620@sass191.ess.sandia.gov> To: ibis@vhdl.org Subject: IBIS Users' Group Just another vote for an IBIS users' group. I'm getting ready to seriously apply Quad SI tools to our board designs. I was hoping the IBIS model repository would be filled to overflowing by now. Gary D. Peterson Sandia National Labs From fvance@FirePower.COM Tue Feb 28 15:01:43 1995 Return-Path: Received: from FirePower.COM (firepower.FirePower.COM) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17270; Tue, 28 Feb 95 15:01:43 PST Received: from oahu by FirePower.COM (NX5.67d/NX4.0Mhb.0b) id AA01071; Tue, 28 Feb 95 14:56:04 -0800 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA20208; Tue, 28 Feb 95 14:56:32 -0800 From: Fred Vance Message-Id: <9502282256.AA20208@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA12705; Tue, 28 Feb 95 14:56:29 -0800 Date: Tue, 28 Feb 95 14:56:29 -0800 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: ibis@vhdl.org Subject: IBIS User's Group Hi, I am interested in an IBIS User's group. Like Greg, I would prefer it to be on a reflector. From the small number of responses to Don Telian's suggestion, It doesn't sound like there are enough people to start a news group as described by Will's "How to spawn a new newsgroup". About a month ago, I enquired whether ibis@vhdl.org or si-list was the appropriate forum for IBIS users. From the lack of response on the si-list reflector and from Will's reply, I feel like ibis@vhdl.org is the best place to disscuss user issues, at least until it begins to interfere with the IBIS Open Forum's efforts at standardization. Fred Vance Fire Power Systems, Inc. From Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com Tue Feb 28 15:31:32 1995 Return-Path: Received: from wotan.compaq.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17472; Tue, 28 Feb 95 15:31:32 PST Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0rjbJK-000vIkC; Tue, 28 Feb 95 17:26 CST Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0rjbJ8-000uHAC; Tue, 28 Feb 95 17:26 CST Message-Id: Received: by bangate.compaq.com with VINES ; Tue, 28 Feb 95 17:26:23 CST Date: Tue, 28 Feb 95 16:05:41 CST From: Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com Subject: re: IBIS Users' Group To: ibis@vhdl.org Cc: Gary brings up a good point about the lack of an established IBIS model library out on the VHDL ftp server (the exception being Intel, of course). Without an IBIS champion or two from the user community, however, I doubt the situation will change very rapidly. I think there's a couple of different approaches we can take to populate the model libraries. First off, whenever we get models directly from a vendor we can suggest they submit their models to the IBIS model champion as well. I've done this twice this month, though without success. I'll try to push the issue again sometime soon. Similar efforts from other companies are going to be required to expand the public libraries. A second approach would be to directly share each other's existing libraries. We currently have a fairly extensive signal integrity model library at Compaq (though only a small portion of it is in IBIS format). Some of the library can't be shared for legal reasons, but I bet most most of the behavioral models could be after getting an OK from the vendor. Unfortunately, this approach gets a little tricky when considering the competitive nature of many of our companies. I don't have a problem sharing with non-competitive companies, but would probably have to consider everyone else on a case by case basis. Until models are more readily available I imagine Compaq isn't the only company that feels this way (those of us that feel we have an advantage in the market aren't interested in giving it away). I see the same situation among the various EDDY companies -- I don't see any of those companies posting their libraries in the public domain. Anyway, a new IBIS user's group would be the logical step to start dealing with this topic. I'll join everybody else in saying I prefer the reflector to a news group. Mark Leonard Compaq Computer Corporation mleonard@bangate.compaq.coma From Arpad_Muranyi@ccm.fm.intel.com Tue Feb 28 15:47:06 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17576; Tue, 28 Feb 95 15:47:06 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjbXr-000UjRC; Tue, 28 Feb 95 15:41 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjbXq-000twcC; Tue, 28 Feb 95 15:41 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 28 Feb 95 15:41:34 PST Date: Tue, 28 Feb 95 15:41:34 PST From: Arpad Muranyi Message-Id: <950228154134_1@ccm.hf.intel.com> To: kellee@nwlink.com, ibis@vhdl.org Subject: Re: Text item: Kellee, You are running into the same problem I did when the 1.1 parser came out. I created a Windows(3.1) macro with the Recorder, so that I could highlight the ibis file in File Manager, press the shortcut key combination for the macro which would execute "File, Run, Home, type:ibis_chk ". This way the highlighted file name would appear in the File Run dialog box and the command typed (ibis_chk) would get it as its argument. The problem was that the file name appeared in all upper case. (When I ran it from a DOS prompt there was no problem, because the case of the argument would be passed to the program as typed at the prompt). I got around the problem by modifying IBIS_CHK.C to make it case insensitive. I told Paul about this once in person, and once openly in one of our Open Forum meetings. The minutes should have taken note of this remark. I thought we all agreed that the program would be compiled with a conditional statement, which makes the checker case insensitive for file names if it is compiled for DOS/Windows. If this hasn't been done, I agree with you, it should be fixed. Arpad Muranyi Intel Corporation ----------------------------------------------------------------------------- I have a dual boot 486 with both Windows and Windows NT operating systems. The specific problem is that DOS forces upper case for all file names. Windows NT allows upper or lower case. For the specific test case I was running on Windows NT using the same file directories created when running under windows. When the file names come in with lower case in the file for example xilinx.ibs and the file name is XILINX.IBS than the parser refuses to run on the file. When I changed the file name to XILINX.ibs than the parser runs but a I get an error message stating that the file name does not match the name in the file. This will be a very common probablem for any person running Windows NT getting files from computers running Windows3.1 or DOS. It seems like the same problem would apply for UNIX systems getting files from DOS or Windows 3.1 platforms. Kellee Have a great day... 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: From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 X-Sender: kellee@nwlink.com Message-Id: <199502281940.AA25021@washington.nwlink.com> Date: Tue, 28 Feb 1995 11:40:31 -0800 Received: from kellee (port18.link.nwlink.com) by washington.nwlink.com with SMT P id AA25021 (5.67b/IDA-1.5 for ); Tue, 28 Feb 1995 11:40:31 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA15365; Tue, 28 Feb 95 11:46:33 PST Received: from VHDL.VHDL.ORG by hermes.intel.com (5.65/10.0i); Tue, 28 Feb 95 11 :44:01 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjXq0-000twfC; Tue, 28 Feb 95 11:44 PST From Derrick_Duehren@ccm2.jf.intel.com Tue Feb 28 15:59:11 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17611; Tue, 28 Feb 95 15:59:11 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjbju-000UiDC; Tue, 28 Feb 95 15:54 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjbjt-000twdC; Tue, 28 Feb 95 15:54 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 28 Feb 95 15:54:01 PST Date: Tue, 28 Feb 95 15:54:01 PST From: Derrick Duehren Message-Id: <950228155401_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: FW: IBIS users group (What will it take?) ______________________________ Forward Header __________________________________ Subject: FW: IBIS users group (What will it take?) Author: rharr@arpa.mil at SMTPGATE Date: 2/28/95 2:56 PM You might get some action and help after all! The note below is a request to Synopsys MIS/NCS to fix the vhdl.org NEWS feed and installation. We will wait and hope for the best. BTW, there is a procedure to go through to setup a "recognized" and "accepted" USENET news group, if this is what you are really looking for. From what I recall in setting up comp.lang.vhdl a few years ago, it takes a proposal from within another (existing) newsgroup and an online, electronic ballot for 30 days. If, at the end, a certain threshold of "yes" votes is received (100, if I recall correctly), then a message is sent to create a newsgroup automatically in 99% of the machines which exchange news. Setting up a USENET (Internet) wide IBIS group (assuming what you want is something like comp.lang.ibis?) is independent of having NEWS working on vhdl.org. We have always wanted to get setup an email-based USENET news read/submit capability. The software is on the net but we do not have the time to track it down and install it. Much like you can use email to get "FTP" available files, you can use email to a) subscribe to a news group (receiving USENET news messages via email), and b) submit messages to a news group. IBIS community members without news could use this method to stay in touch and the interaction will be just like the current email reflector. Others with USENET news readers could have all the benefits of NEWS (instead of email) such as threads, etc. which make reading and traversing the information more useful. Finally, you can have local (to a machine or domain) news groups which are locally sponsored and cared for. This would require NEWS working on vhdl.org. What were you really looking for? Randy Harr _______________________________________________________________________________ From: Mitch Wyle on Tue, Feb 28, 1995 4:50 PM Subject: IBIS users group (What will it take?) To: cts@Synopsys.COM Cc: rharr@ARPA.MIL Paul, Can you please look into fixing news on vhdl.vhdl.org at your convenience? Feel free to close this call with a "no" answer if you can't. Thanks, -Mitch NCS: cat e2 : assign ple >>To:Derrick Duehren >>From:rharr@arpa.mil (Randolph E. "Randy" Harr) >>Subject:Re: IBIS users group (What will it take?) >>Cc:kellee@nwlink.com, Will_Hobbs@ccm2.jf.intel.com >> >>I do not think so but a) am not very familiar with NEWS and its protocols, >>b) we do not have anyone very familiar helping us SYSOP right now, and c) >>our NEWS feed from the Internet / USENET news is currently broken (since >>the physical move of the machine to Synopsys.). >> >>The answer is it should/would be easy for someone knowledgeable, but we do >>not have the talent currently (Synopsys admins -- anyone wish to take a >>stab?). If you can find someone who is knowledgeable, we would be more >>than happy to give them access to the system to set it up. >> >>Sorry I cannot offer more help! >> >>randy harr >>rharr@arpa.mil >> >>> >>> VHDL Support, >>> >>> Would it take much to set up an IBIS news group for the IBIS Open Forum? >>> >>> Derrick Duehren >>> IBIS Open Forum Secretary (a volunteer position) >>> Phone (503) 696-4299, Fax (503) 696-4904 >>> Derrick_Duehren@ccm.jf.intel.com >>> 2111 NE 25th, JF1-97, Hillsboro, OR 97224 >>> >>>______________________________ Forward Header >>>__________________________________ >>>Subject: IBIS users group >>>Author: kellee@nwlink.com at SMTPGATE >>>Date: 2/24/95 6:07 PM >>> >>> >>>Hi Don, I think the IBIS users group is a great idea. We have talked about >>>it several times in the IBIS meetings and I believe Will's last idea was that >>>we would allow users to ask questions in the regular group until it becomes a >>>problem. >>> >>>I would support creating a separate mail group for IBIS users however. >>> >>>Perhaps a real news group would be even better. This was brought up at the >>>last meeting also, and no one there knew what was involved with creating a >>>news group. >>> >>>Kellee Crisafulli, HyperLynx Inc. >>>206-896-2320 >>>kellee@nwlink.com >>>Have a great day... >> > > >+--------------------------------------------------------------------+ >| Randolph E. (Randy) Harr | >| randy.harr@vhdl.org, rharr@mojave.stanford.edu. (415) 725-3639 | >| | >| NEW ADDRESS AFTER 1 FEB: | >| ARPA/ESTO, 3701 Fairfax Drive, Arlington, VA 22203-1714 | >| (703) 696-0085 (off), (703) 696-2203 (fax), rharr@arpa.mil | >+--------------------------------------------------------------------+ > > From Will_Hobbs@ccm2.jf.intel.com Tue Feb 28 17:32:42 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18170; Tue, 28 Feb 95 17:32:42 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjdCP-000UgLC; Tue, 28 Feb 95 17:27 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjdCP-000twcC; Tue, 28 Feb 95 17:27 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 28 Feb 95 17:27:33 PST Date: Tue, 28 Feb 95 17:27:33 PST From: Will Hobbs Message-Id: <950228172733_1@ccm.jf.intel.com> To: Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com, ibis@vhdl.org Subject: Re[2]: IBIS Users' Group Text item: Mark, I appreciate your concern for Compaq's competitive advantage. I would like to point out, though, that the various participants in the IBIS Open Forum are competitors, such as the dozen or so EDA vendors and the multiple IC vendors. Our view is that we all benefit from widespread support of IBIS, and if this exposes us to some short term risk in reducing our advantage over our competition, it is offset by increased ability to do our jobs in a quality way. I feel each company will still have its own advantage over their competition even when sharing models and modeling techniques. The gain obtained from being able to simulate more of our systems and offer robust designs to our customers partially offsets the fact that others are also helped by this. Will Gary brings up a good point about the lack of an established IBIS model library out on the VHDL ftp server (the exception being Intel, of course). Without an IBIS champion or two from the user community, however, I doubt the situation will change very rapidly. I think there's a couple of different approaches we can take to populate the model libraries. First off, whenever we get models directly from a vendor we can suggest they submit their models to the IBIS model champion as well. I've done this twice this month, though without success. I'll try to push the issue again sometime soon. Similar efforts from other companies are going to be required to expand the public libraries. A second approach would be to directly share each other's existing libraries. We currently have a fairly extensive signal integrity model library at Compaq (though only a small portion of it is in IBIS format). Some of the library can't be shared for legal reasons, but I bet most most of the behavioral models could be after getting an OK from the vendor. Unfortunately, this approach gets a little tricky when considering the competitive nature of many of our companies. I don't have a problem sharing with non-competitive companies, but would probably have to consider everyone else on a case by case basis. Until models are more readily available I imagine Compaq isn't the only company that feels this way (those of us that feel we have an advantage in the market aren't interested in giving it away). I see the same situation among the various EDDY companies -- I don't see any of those companies posting their libraries in the public domain. Anyway, a new IBIS user's group would be the logical step to start dealing with this topic. I'll join everybody else in saying I prefer the reflector to a news group. Mark Leonard Compaq Computer Corporation mleonard@bangate.compaq.coma Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: To: ibis@vhdl.org Subject: re: IBIS Users' Group From: Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com Date: Tue, 28 Feb 95 16:05:41 CST Received: by bangate.compaq.com with VINES ; Tue, 28 Feb 95 17:26:23 CST Message-Id: Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0rjbJ8-000uHAC; Tue, 28 Feb 95 17:26 CST Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0rjbJK-000vIkC; Tue, 28 Feb 95 17:26 CST Received: from wotan.compaq.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17472; Tue, 28 Feb 95 15:31:32 PST Received: from VHDL.VHDL.ORG by hermes.intel.com (5.65/10.0i); Tue, 28 Feb 95 15 :55:08 -0800 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 28 Feb 9 5 15:55:15 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjbl8-000tweC; Tue, 28 Feb 95 15:55 PST From Will_Hobbs@ccm2.jf.intel.com Tue Feb 28 17:51:26 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18265; Tue, 28 Feb 95 17:51:26 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjdUV-000UjTC; Tue, 28 Feb 95 17:46 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjdQ0-000twcC; Tue, 28 Feb 95 17:41 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 28 Feb 95 17:41:35 PST Date: Tue, 28 Feb 95 17:41:35 PST From: Will Hobbs Message-Id: <950228174135_4@ccm.jf.intel.com> To: ibis@vhdl.org, gre@scintl.com Subject: Re: Does IBIS cover SSO noise? Text item: Greg, SSO has been handled in several ways: derate the slow model to be as bad as SSO (which doesn't deal with ground bounce); embed multiple IBIS models in a Vcc and ground net representative of the component. V2.1 allows for much more flexibility in this regard. Look at the section on complex packages. Will I've begun taking a look at IBIS modeling and what it has to offer for us, and the one thing that sticks out to me is that I don't see any provisions for simultaneously switching output (SSO) noise. This can be a big part of your noise budget, especially when you're pressed for chip-to-chip timing and there's no logic between the latch and the driver. Does anybody know if SSO capability exists within IBIS? If it does not, are there plans to incorportate it? -- Greg Edlund +----+----+ Circuits and Modeling | | | SuperComputers, Int'l. < | ) 1414 W. Hamilton Ave. > ----- ) Eau Claire, WI 54701 < ----- ) (715) 833-7067 voice > | ) (715) 833-7096 FAX | | | gre@scintl.com email +----+----+ 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: Does IBIS cover SSO noise? From: gre@scintl.com (Greg Edlund) To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 X-Sender: gre@scintl.com Message-Id: <9502282104.AA27602@scintl.com> Date: Tue, 28 Feb 95 15:04:36 -0600 Received: from porpoise.scintl.com by scintl.com via SMTP (931110.SGI/930416.SGI ) for uunet!vhdl.org!ibis id AA27602; Tue, 28 Feb 95 15:04:36 -0600 Received: from puma.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Tue, 28 Feb 1995 16:16:30 -0500 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQyfbx09537; Tue, 28 Feb 1995 16:16:48 -0500 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16187; Tue, 28 Feb 95 13:21:48 PST Received: from VHDL.VHDL.ORG by hermes.intel.com (5.65/10.0i); Tue, 28 Feb 95 13 :45:08 -0800 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Tue, 28 Feb 9 5 13:45:13 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjZjJ-000twdC; Tue, 28 Feb 95 13:45 PST From kellee@nwlink.com Tue Feb 28 20:05:35 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19148; Tue, 28 Feb 95 20:05:35 PST Received: by washington.nwlink.com id AA21428 (5.67b/IDA-1.5 for ibis@vhdl.org); Tue, 28 Feb 1995 19:59:33 -0800 Date: Tue, 28 Feb 1995 19:59:33 -0800 Message-Id: <199503010359.AA21428@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: SSO answer to Greg's question >To: ibis@vhdl.org >From: gre@scintl.com (Greg Edlund) >Subject: Does IBIS cover SSO noise? >Content-Length: 787 >X-UIDL: 794017938.004 > >I've begun taking a look at IBIS modeling and what it >has to offer for us, and the one thing that sticks out >to me is that I don't see any provisions for simultaneously >switching output (SSO) noise. This can be a big part of >your noise budget, especially when you're pressed for >chip-to-chip timing and there's no logic between the >latch and the driver. Does anybody know if SSO capability >exists within IBIS? If it does not, are there plans to >incorportate it? > Hi Greg, Yes IBIS can handle SSO. It is more a question of what the simulators do with the data. The IBIS models include package information about ground inductance, VCC inductance etc. Additionally Ver 2.x of IBIS adds the ability to define which power supply pins go with each of the output pins. This was the piece that was missing to provide good SSO simulation. Now the next part of your question really is do any of the simulator vendors use this data. And that needs to be answered by each vendor separately. It may also require that you as a user get involved and specify how many outputs and which outputs you want to simutaneously transition. Is it all 8 outputs on an octal or just 2. Kellee Crisafulli, HyperLynx Inc. Have a great day... From kellee@nwlink.com Tue Feb 28 20:44:49 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19331; Tue, 28 Feb 95 20:44:49 PST Received: by washington.nwlink.com id AA23485 (5.67b/IDA-1.5 for ibis@vhdl.org); Tue, 28 Feb 1995 20:38:49 -0800 Date: Tue, 28 Feb 1995 20:38:49 -0800 Message-Id: <199503010438.AA23485@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: IBISCHK2 version 2.1d checkout I found another minor bug in IBISCHK2 that needs to be fixed: if I typed IBISCHK2 without a file the following message comes up: IBISfile validation: This program has been provided free to the electrical engineering community by the IBIS consortium. The purpose of this program is to validate that the contents of ASCII device data in a file specified conform to the IBIS specification. Usage: ibis_chk Notice that the usage line has the wrong program name. Also I test compiled the program with the large buffers for WIN32s and it works great, compiled without errors. I will make a version available for windows 32s with a windows interface when John get's done with his changes. I would say this is a good indicator that the code is relatively clean since I had the warnings set to level 3. Next question is who is going to fix these bugs in V2.1d? Paul? or perhaps John when you make the other modifications to improve the parser errors? Kellee Crisafulli, HyperLynx Inc. Have a great day... From kellee@nwlink.com Tue Feb 28 21:14:33 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19494; Tue, 28 Feb 95 21:14:33 PST Received: by washington.nwlink.com id AA26644 (5.67b/IDA-1.5 for ibis@vhdl.org); Tue, 28 Feb 1995 21:08:33 -0800 Date: Tue, 28 Feb 1995 21:08:33 -0800 Message-Id: <199503010508.AA26644@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: IBISCHK2 ver2.1d Dear birds of a feather Ok here is the actual problem with file names and case. If the file name is upper case, and the file name in the file is lower case (normal case for DOS is upper case) and I run IBISCHK2 XXX.IBS it fails. If on the other hand I type IBISCHK2 xxx.ibs it passes. The reason is that the operating system will automatically translate the case if it is lower. I believe we should change the parser to translate all input file names to lower case. Since IBIS file names are required by the specification to be lower case, this should always work. By the way I tried this with the FAT, NTFS, HPFS file systems. FAT is what DOS and windows use. HPFS is what OS uses. NTFS is what NT and Windows 95 use natively. Windows NT can use all of the above file systems. I got the same result with all file systems running under NT. Have a great day...Kellee Crisafulli, HyperLynx Inc. From Derrick_Duehren@ccm2.jf.intel.com Wed Mar 1 05:21:49 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26496; Wed, 1 Mar 95 05:21:49 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjoGe-000Ue4C; Wed, 1 Mar 95 05:16 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjoGd-000twdC; Wed, 1 Mar 95 05:16 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 1 Mar 95 05:16:38 PST Date: Wed, 1 Mar 95 05:16:38 PST From: Derrick Duehren Message-Id: <950301051638_6@ccm.hf.intel.com> To: IBIS@vhdl.org Cc: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com Subject: Minutes from IBIS Open Forum Meeting 2/24/95 Text item: Text_1 Date: Feb. 28, 1995 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, OR 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager, IBIS Secretary Subject: Minutes from IBIS Open Forum Meeting 2/24/95 To: Apple Computer Duane Talsahashi ARPA Randy Harr AT&T Global Info Solutions Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar Cadlab Ralf Bruning Contec Dileep Divekar* Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HP Palo Alto Tom Langdorf HP EESof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, John Burnett INCASES Werner Rissiek, Olaf Rethmeier Integrated Silicon Systems Eric Bracken Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei, John Sliney MicroSim Arthur Wong National Semiconductor Syed Huq*, Raj Raghuraum, Atul Agarwal* NEC Hiroshi Matsumoto North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang PC Ware Paul Munsey, Ron Neville Quad Design Jon Powell* Quantic Labs Mike Ventham Racal-Redac John Berrie Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zeelan Technology George Opsahl, Hiro Moriyasu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 3/17/95 (916) 356-9999 461603 4/7/95 (916) 356-9999 461605 4/28/95 (916) 356-9999 461609 All meetings are 8:00 AM to 10:00 AM Pacific Time (16:00 to 18:00 UTC). 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------------ Check-in, Intros, Announcements There were no new participants. There were no corrections made to last month's minutes. Will reported that Meta Software has licensed the Parser. AR Derrick: Note on the charter document that National Semiconductor has paid for the parser and inform Patti Rusher at EIA. [DONE] Conference Management Systems requested (and Will approved) a $500 payment to CMS for their services over the last two years. This amount is less than half what they typically charge. CMS had been providing the service free with the expectation that we would eventually become a paying client. CMS is now transferring our remaining funds ($1,400) to our EIA account. There were no new agenda items. Press Updates: Integrated Systems Design, March `95, pg 12 and pg 84 EETimes,2/6, Pg 8 Electronic news, 2/6, pg 52 New Models Available: Syed posted two 2.1 models, unchecked with parser because Michael does not have the parser. ds26c31.ibs, an RS-422 Quad Diff Line Driver ds26c32.ibs, an RS-422 Quad Diff Line Receiver Note: Bob Ross checked the files with the 2.1 parser and they passed. AR Jon -- get new parser binary to Michael. We discussed the need for a "Beta" directory in the vhdl.org library with a strong disclaimer file. Jon suggested having some means of enabling people to post models for evaluation. Will suggested indicating in the IBIS file name that the file is experimental/not final. Possibly, the "Beta" directory could be a publicly read/write. AR Michael -- Please make a proposal for this capability [Michael has agreed to make a proposal]. Progress toward enlisting new IC vendors Mike Ventham reported via email to Derrick that he has requested contact information from VLSI in Phoenix, but has not received anything yet. Dave Moxley is working with ASIC suppliers, and has gotten preliminary IBIS models from two of them. The files are not passing the parser yet, but Dave is working with them to get them right. Kellee is working with National and Xylinx. He expects Xylinx to have a set of 2000, 3000, 4000 Xylinx IBIS models for the vhdl.org library in a few months. We discussed the potential need for a separate reflector or newsgroup for IBIS users. [Update, many messages bouncing around the reflector on this topic.] Golden Parser 2.1 progress and release date Many did not receive their copies. Will will reissue the parser and asked if everyone could validate the GP by Friday 3/3/95. The approved parser is needed to get the EIA spec approval process going. Jon reported that he can do cross-compilation of the parser for all but DOS platforms and will update us next week. AR Will -- Resend the Rev 4 Golden Parser to the 13 licensees. [DONE -- Will apologizes. His admin. had prepared the disks to go out and then went on a short medical leave -- it was forgotten.] AR Derrick/Will -- Post Golden Parser 2.1 release approval process. [DONE. The 13 licensees will discuss and vote via email. No vote (silence) will be considered a YES vote.] Status of EIA affiliation Will and Derrick met with Patti Rusher of the EIA yesterday. Patti is OK with everything in our charter. EIA is now handling our finances. All checks can now be made to "EIA". Any payments still sent to CMS will be forwarded to the EIA. Patti will be sending a letter (which Will and Derrick have reviewed) to those in the roster document. The fee structure we decided upon is included. We discussed the cost of sending out a hardcopy of the spec (and possibly a floppy). Kellee volunteered to put together an IBIS "starter kit" with the spec, parser executable, overview, cookbook, and sample models, which we can make available as a floppy with the hardcopy spec. Suggested list price of $20 for spec only, $50 for starter kit. We need a formal process to respond to balloting comments. Bob Ross suggested we have a subcommittee draft a response, have the whole committee review the comment, and then respond officially. Kellee volunteer to chair the committee, and Bob Ross and Jon Powell will participate. Kellee wants to make sure the responses are professional so the commenter feels acknowledged and we continue to get their support. Rev 2.1 updates o S2IBIS 2.1 Bob Ross reported that Michael Steer has a student assigned to work on the conversion utility, but the funding has not yet arrived. Bob Ross suggested that they modularize the program before expanding it further. o Cookbook It could easily be a 3 person-month effort to redo this book. It may be more practical to make smaller changes and additions to the existing book. Syed is creating an internal book for generating models from bench measurement. It is in rough draft form now. Syed will check to see if there is any confidential information included. He thinks that he'll be able to make the material available Kellee volunteered to coordinate the Cookbook update/Starter Kit. Bob Ross and Syed will help. Bob thinks he may have tech pubs help available, though he can't commit yet. Syed put an article in HTML form, and posted it for Mosaic in NSC. Rumor is that the next version of Word can export HTML directly. If we had a vhdl.org IBIS home page, we could link to companies that support IBIS, etc. AR Kellee -- post information on public domain Mosaic software [DONE]. o Overview This document could be rolled into the cookbook. BIRD 25.2 Will reported that Intel has discussed this BIRD internally. Intel's position is that "C_comp is considered an independent variable. This is because C_comp includes bonding pad capacitance, which does not necessarily track fabrication process variations. The conservative approach to using IBIS data will associate large C_comp values with slow, weak models, and the small C_comp values with fast, strong models." (The low value should go in the Min. column.) This means that we have 4 potential models out of each set of data. In 3.0, we may want to add a keyword that can indicate which C_comp goes with the first ramp and vice-versa, if the model provider so chooses. The consensus is that C_comp is magnitude. AR Bob R. -- Add a sentence indicating that "This is an independent variable." [DONE] Bob Ross stepped through each paragraph of the BIRD 25.2. He suggested that portions may be good for inclusion in the new cookbook. Roll-call vote taken. BIRD 25.3 approved unanimously (including the quoted text above.). AR Bob -- Repost as approved BIRD 25.3. [DONE] We discussed options for rolling this BIRD into the spec. If we put this BIRD into the spec, the spec will need to be rolled to 2.2, the parser will also need to be updated. We also identified a need for a formal Golden Parser bug list that identifies everything that the parser does not check. Two issues are left on the table: First, should we roll in this BIRD before sending the 2.1 Spec out for EIA vote or wait to roll it in along with any other changes that come out of the voting process. Second, should be upgrade the parser to catch all 2.1 issues that it does not currently check for? Jon volunteered to do coding work on the GP. Wrap-up, Next Meeting Plans Our next meeting is a teleconference 3/17/95. Suggested Topics: o Tim Schreyer's findings on Diode effects. o Directions for MCM. ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ==============================================================================