From owner-ibis Wed Oct 1 06:46:15 1997 Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA07160; Wed, 1 Oct 1997 06:46:14 -0700 (PDT) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id GAA08126; Wed, 1 Oct 1997 06:44:38 -0700 (PDT) Received: from hi-av1.cadence.com(158.140.128.31) by mailgate.cadence.com via smap (V1.0mjr) id sma875713477.008123; Wed Oct 1 06:44:37 1997 Received: from unihsa0.Cadence.COM (unihsa0 [158.140.95.36]) by mailhub.Cadence.COM (8.8.5/8.7.3) with SMTP id GAA28869; Wed, 1 Oct 1997 06:43:31 -0700 (PDT) Received: from unipna3 by unihsa0.Cadence.COM (1.38.193.4) id AA19686; Wed, 1 Oct 1997 09:38:21 -0400 Message-Id: <34325557.2534@cadence.com> Date: Wed, 01 Oct 1997 09:51:19 -0400 From: Celso Faia Organization: Cadence Design Systems X-Mailer: Mozilla 3.01 (WinNT; I) Mime-Version: 1.0 To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Real World Measurements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings, Has anyone out there in IBIS LAND ever create an ibis model from direct IC measurements. If so could you provide a detailed explanation as to how and what measuring equipment was used. Are there any issues associated with this method of ibis model extraction. Thanks, Celso -- ****************************************************************** * Celso Faia * Phone: 613-596-9091 x337 * * Cadence Design Systems Ltd * Fax: 613-596-9080 * * Ottawa, Ontario, Canada * Email: celso@cadence.com * ****************************************************************** From owner-ibis Wed Oct 1 10:10:39 1997 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA11282; Wed, 1 Oct 1997 10:10:38 -0700 (PDT) Received: (from kellee@localhost) by montana.nwlink.com (8.8.5/8.8.5) id KAA21855; Wed, 1 Oct 1997 10:09:00 -0700 (PDT) Message-Id: <3.0.32.19971001100903.0070df10@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 01 Oct 1997 10:09:04 -0700 To: Celso Faia , ibis@vhdl.org, ibis-users@vhdl.org From: Kellee Crisafulli Subject: Re: Real World Measurements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Cesco At 09:51 AM 10/1/97 -0400, Celso Faia wrote: >Greetings, > >Has anyone out there in IBIS LAND ever create an ibis model >from direct IC measurements. If so could you provide a detailed >explanation as to how and what measuring equipment was used. >Are there any issues associated with this method of ibis model >extraction. Their is a very nice write up from Intel on the IBIS site on this subject called the IBIS cookbook. They are working on a new version as well. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Wed Oct 1 11:52:40 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA13188; Wed, 1 Oct 1997 11:52:40 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA09113; Wed, 1 Oct 1997 11:51:02 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2) id xma008885; Wed, 1 Oct 97 11:50:50 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA08594 for ibis@vhdl.org; Wed, 1 Oct 97 11:50:35 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA14681; Wed, 1 Oct 97 11:52:03 PDT Date: Wed, 1 Oct 97 11:52:03 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9710011852.AA14681@rockie.nsc.com> To: ibis@vhdl.org, ibis-users@vhdl.org, celso@cadence.com Subject: Re: Real World Measurements Celso, The Electronic Design Article on the IBIS webpage titled 'Ease System Simulation With IBIS Device Models' lists a variety of vendors/instruments make/model that National uses for IBIS modeling based on measurements. Regards, Syed. National Semiconductor Corp. > > Greetings, > > Has anyone out there in IBIS LAND ever create an ibis model > from direct IC measurements. If so could you provide a detailed > explanation as to how and what measuring equipment was used. > Are there any issues associated with this method of ibis model > extraction. > > Thanks, > > Celso > > -- > ****************************************************************** > * Celso Faia * Phone: 613-596-9091 x337 * > * Cadence Design Systems Ltd * Fax: 613-596-9080 * > * Ottawa, Ontario, Canada * Email: celso@cadence.com * > ****************************************************************** > From owner-ibis Thu Oct 2 13:34:54 1997 Received: from fw.icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id NAA10780; Thu, 2 Oct 1997 13:34:52 -0700 (PDT) Received: by fw.icx.com (Smail-3.2.0.92 1997-Feb-9 #4) id ; Thu, 2 Oct 1997 13:33:14 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Thu, 2 Oct 1997 13:33:03 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Thu, 2 Oct 1997 13:33:08 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Thu, 2 Oct 1997 13:33:08 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org, ibis@eda.org Subject: Re: questions on ibis Cc: schwa1@fh-landshut.de Walter: You raised some good questions. I have some comments in your questions which may help. Best Regards Bob Ross Interconnectix >Date: Thu, 02 Oct 1997 09:02:15 +0200 >From: Schneider Walter >Organization: Fachhochschule Landshut >To: ibis@vhdl.org >Subject: questions on ibis > >Hello! > >After creating some ibis-modells and simulating with them, I have >now some questions: > >1) Does anyone know, what voltage step (u/i-tables) is normally used? > I had the problem that by taking a step of 0.1V some oscillations > occured when simulating a transmission line. By increasing the > step up to 0.5V these oscillations disappeared. > What can be the reason for this? I would have to see the test circuit, results, and full model to figure out what is expected and how bad the results are. This could also be dependent on what simulator is used and its internal algorithms. There could be a numerical processing issue related to internal time steps that may induce or kill the oscillation. In general, I would expect that you would get better results with more data points if they are continous-like in nature. > >2) The ibis-specification defines what voltages, temperatures and > process parameters have to be used for simulating worst/best case > conditions only for TTL- and CMOS-technologies? > What should be used for ABT (advanced BICMOS technology) or > BCT (BICMOS technology)? Still use low voltage, slow-weak process for the min column, and the opposite for the max column. The real issue what temperature to use. My first approach was to base the temperature on the output stage technology. However, when I tried this, it did not give me the fastest or slowest responses. So I now try both temperature extremes and take the temperature which gives me the slowest rise and fall times for the min column, and fastest rise and fall times for the max column. In one ABT case this worked out to be the highest temperature for the min column, and lowest temperature for the max column. > >3) By creating the u/i-tables from actual silicon measurements > the voltage sweep (-VCC ... +2VCC) must be reduced. > To cover the recommended region the specification says to make > an extrapolation. > Has anyone ever made such an extrapolation and compared the > simulation results with an ibis-modell without the extrapolation > (i.e. reduced u/i-tables) ? Many behavioral simulators automatically do extrapolation of the VI table endpoints. So the results should be the same even if the extrapolated data is not provided. However, when tranforming the IBIS data into a Spice syntax using table based controlled voltage or controlled current sources, there will be a difference. Most Spice simulators will truncate the tables to the endpoint current values if the voltages are outside of the table range. So if a reflected signal actually causes a voltage outside of the table value, the result should be different. IBIS contains the range requirements so that all types of simulators will process the same set of data. > > >I hope I hear from you soon! > >Thank you very much! > > > >email: schwa1@fh-landshut.de > >mail: Walter Schneider > Muehlweg 25 > 94513 Schoenberg > Germany > phone: 08554/3916 > From owner-ibis Fri Oct 3 11:38:04 1997 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA03707 for ; Fri, 3 Oct 1997 11:38:00 -0700 (PDT) Received: from hpbs2933.boi.hp.com (pgregory@hpbs2933.boi.hp.com [15.8.28.3]) by palrel3.hp.com (8.8.5/8.8.5tis) with SMTP id LAA25154 for ; Fri, 3 Oct 1997 11:36:19 -0700 (PDT) Received: by hpbs2933.boi.hp.com (1.38.193.4/15.5+IOS 3.22) id AA20168; Fri, 3 Oct 1997 12:34:01 -0600 From: Paul Gregory Message-Id: <9710031834.AA20168@hpbs2933.boi.hp.com> Subject: IBIS at >400MHz To: ibis-users@eda.org Date: Fri, 3 Oct 97 12:34:01 MDT Mailer: Elm [revision: 70.85] In future designs, we plan to use interfaces that reach beyond 400 MHz. As I think about the tools that we need to help us successfully design at that speed, simulation is going to be a big part of it. But I am concerned that IBIS descriptions and simulation techniques may not be adequate to accurately simulate at that speed. Perhaps SPICE simulation will be required. Should IBIS based simulators be capable of accurate simulation at speed of 400MHz to 1000MHz? When device parasitics play a larger part of the equation, is IBIS sufficiently robust to accurately describe these parasitics? What are the key factors to consider when simulating at these higher frequencies? What are your thoughts? -- Paul Gregory phone: (208) 396-5086 USmail: Hewlett-Packard fax: (208) 396-4122 M/S 143 email: paul_gregory@hp.com 11311 Chinden Blvd. Boise, ID 83714 From owner-ibis Wed Oct 8 07:31:34 1997 Received: from wile.nesa.com ([204.240.29.34]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id HAA03001 for ; Wed, 8 Oct 1997 07:31:22 -0700 (PDT) Date: Wed, 8 Oct 1997 10:03:58 -0400 Message-Id: <199710081403.KAA20936@wile.nesa.com> Received: from porky.nesa.com(204.240.29.45) by wile.nesa.com via smap (V1.3) id sma020932; Wed Oct 8 10:03:56 1997 X-Sender: breda@mail.nesa.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: si-list@silab.Eng.Sun.COM, ibis-users@eda.org From: Kathy Breda Subject: Minutes from IBIS-East Forum kickoff meeting IBIS - East Forum Kickoff Meeting Minutes On September 18, 1997, NESA sponsored the kickoff meeting of the IBIS - East Forum. The purpose of the meeting was to encourage the participation of East coast designers of computer, communication and telephony systems in the in the development of IBIS behavioral modeling as a tool in their system design practices. There were a total of 43 participants at the meeting held in the Boxboro, MA Holiday Inn. The meeting was chaired by NESA's CEO, Dr. Ed Sayre. Area participants included engineering personnel and designers from Boston area computer, EDA software vendors and others. Out of town participants included designers from the New York City environs, Princeton, NJ, Hartford CT as well as visitors from Intel locations in California and Oregon, Texas Instruments in the Dallas TX area, an engineer from the "new" Fairchild Semiconductor in Portland, ME as well as engineers from Seattle, WA and Portland, OR. It seemed that there was an old home week atmosphere between present and ex-DEC folks and a group of designers from both coasts who had worked for Tektronix in Oregon. Its really a small world when you get to high performance designers. The first featured speaker was Bob Ross, Chairman of the IBIS Forum and member of the technical staff of Interconnetix an EDA software house. Bob spoke about the history of IBIS and the development of the standard to meet a real world need for large system simulation and verification for signal integrity and routing performance. The IBIS standard has progressed to the point that it now comes under Electronic Industries Association (EIA) sponsorship. Future developments in multi-line transmission line modeling and other packaging issues were greeted with interest. His enthusiasm for a group on the East coast was heartfelt as he saw it as a necessary extension for the use IBIS as a behavioral standard for the description of semiconductor devices and interconnect system components. Gary Husted of Intel, Hillsboro, OR spoke about the trials and tribulations of implementing an IBIS capability for boards level systems design. The comment was made by someone that there were probably over 10,000 IBIS models for semiconductors, with 95% of them flawed in some way. It is strictly a buyer beware situation unless you know where the model has lived previously. The representative from TI stated that TI is committed to the standard and accurate behavioral characterization models based on the standard. Gary was forthright in stating that a company has to make the investment for some time before the process runs smoothly. The EDA company representatives made the additional comment that they can provide software that computes correctly, but only if the underlying models are themselves correct. Intel's commitment to IBIS was clear from Gary and other Intel engineers either who use IBIS or who themselves create IBIS models of Intel parts. Ed Sayre then made a sales pitch for participants to help with organization and topics for future East Coast user group meetings. About 25% of the participants said they would help out. The next meeting will be held in approximately four to six weeks. Notices will be sent to interested participants by e-mail. The meeting closed with a panel discussion that focused on tools and EDA vendor ideas. The panel included Gary Husted, Paul Galloway of Cadence, David Kohlmeier of HyperLynx and Frederick Saal of View Logic. Questions from the audience were moderated by Ed Sayre. The questions focused on the validity of IBIS as a systems description language. All EDA vendors were committed to IBIS, although how IBIS syntax is handled by their tools and how IBIS models are created were different for each tool. Also, it was noted by the audience that the tools were expensive and the existence of a public version of low cost similar to Berkeley SPICE would be a tremendous help for systems designers to try out and drive around the block! If you would like to receive hard copies of Gary Husted's or Bob Ross' presentations, please send an e-mail with your postal address and the requested presentation will be mailed to you. Also, let us know if you are interested in joining the East Coast users group. Thanks to all who took the time and interest to attend and participate in the first IBIS East meeting. We look forward to useful and interesting IBIS discussions in the future. Regards, Ed Sayre and Kathy Breda +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Kathy Breda e-mail: breda@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.978.897-8787 | | Stow, MA 01775 USA Fax +1.978.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Thu Oct 9 12:17:24 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA03850 for ; Thu, 9 Oct 1997 12:17:21 -0700 (PDT) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Thu, 9 Oct 1997 12:14:29 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Thu, 9 Oct 1997 12:14:00 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ericb@cadence.com; Thu, 9 Oct 1997 12:14:06 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Thu, 9 Oct 1997 12:14:06 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org, pgregory@hpbs2933.boi.hp.com Subject: Re: IBIS at >400MHz Cc: ericb@cadence.com Paul: You raise some very good points and questions. I don't have definitive answers. I support using Spice simulation and measurement as part of the design methodology along with IBIS based behavioral simulation. I would expect that as specific IBIS format limitations are identified with respect to higher frequency simulation accuracy, proposals to ammend the IBIS format will be made. Eric Blomberg in "IBIS "models" come of age" in the October 1997 issue of Printed Circuit Design. p. 20 provides a very concise paragraph that addresses your points and provides some thoughts. Eric's paragraph follows: "Can I use IBIS models for my 600 MHz bus?" The simplest answer is yes - if the IBIS provider has validated the model at 600 MHz. It is true that the device effects which are simplified out of the IBIS model format start to become visible about 300 MHz. It is also true that other effects, such as dielectric loss, and the modeling engine's way of handling this become significant as well. Device package models play a larger role. The expectation answer is that above 300 MHz, validation becomes a part-by-part issue for the entire modeling system. Bob Ross Interconnectix > From: Paul Gregory > Message-Id: <9710031834.AA20168@hpbs2933.boi.hp.com> > Subject: IBIS at >400MHz > To: ibis-users@eda.org > Date: Fri, 3 Oct 97 12:34:01 MDT > In future designs, we plan to use interfaces that > reach beyond 400 MHz. As I think about the tools > that we need to help us successfully design at that > speed, simulation is going to be a big part of it. > But I am concerned that IBIS descriptions and > simulation techniques may not be adequate to accurately > simulate at that speed. Perhaps SPICE simulation > will be required. > Should IBIS based simulators be capable of accurate > simulation at speed of 400MHz to 1000MHz? > When device parasitics play a larger part of the > equation, is IBIS sufficiently robust to accurately > describe these parasitics? > What are the key factors to consider when simulating > at these higher frequencies? > What are your thoughts? > -- Paul Gregory > phone: (208) 396-5086 USmail: Hewlett-Packard > fax: (208) 396-4122 M/S 143 > email: paul_gregory@hp.com 11311 Chinden Blvd. > Boise, ID 83714 From owner-ibis Fri Oct 10 09:09:16 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id JAA25754 for ; Fri, 10 Oct 1997 09:09:15 -0700 (PDT) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 10 Oct 1997 09:07:35 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 10 Oct 1997 09:07:22 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis-users@eda.org; Fri, 10 Oct 1997 09:07:15 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 10 Oct 1997 09:07:15 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org Subject: Forwarded: CHDStd Workshop agenda and joining the mailing list To IBIS Folks: This is being forwarded for your information in case you are interested in or know of someone interesed in the subject below. Bob Ross Interconnectix CHDSTD WORKSHOPS: an agenda for upcoming CHDStd Workshops may be found at http://vhdl.org/pub/chdstd/chdstd-list/hm. REQUEST FOR PARTICIPATION: - We are seeking the participation of experts such as leading edge high performance IC designers, EDA system integrators, and EDA application developers to review the CHDStd draft standard as part of its standardization within the IEEE DASC and IEC TC93 (Design Automation). To get involved, send a voice or email message to mailto:steve.grout@sematech.org or mailto:cottrell@si2.org or join the below CHDStd mailing list. MAILING LIST: - A mailing list for CHDStd participation has been set up. To join send a message to mailto:majordomo@vhdl.org with the following in the message body: subscribe chdstd From owner-ibis Fri Oct 10 08:39:50 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id IAA25181; Fri, 10 Oct 1997 08:39:49 -0700 (PDT) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 10 Oct 1997 08:38:10 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 10 Oct 1997 08:37:56 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis@eda.org; Fri, 10 Oct 1997 08:37:49 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 10 Oct 1997 08:37:49 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org, ibis@eda.org, si-list@silab.eng.sun.com Subject: EUROPE IBIS SUMMIT MEETING Cc: bob@icx.com To All: Please respond if you are interested in an IBIS Summit Meeting in Europe. There exists a lot of IBIS work in Europe related to model development, IBIS usage, model validation, translation to/from Spice, EMC extensions and IBIS needs. We are considering setting up an IBIS Summit meeting for the primary purpose sharing your experiences and communicating your needs. Similar to some of the other IBIS Summit Meetings, we would request that the presentations be available in an electronic format so that they can be made available to anyone who cannot attend. See http://www.eda.org/pub/ibis/summits for other IBIS Summit presentations. We are considering holding the IBIS Summit Meeting in Paris associated with the DATE98 (Design Automation and Test in Europe) Conference (the merger of several conferences including EuroDAC) in February, 1998. This is similar to the IBIS Summit meeting that is held along with the Design Automation Conference (DAC) in the U.S. A 2-hour "Fringe" meeting (Similar to the DAC "Birds of the Feather" meeting) is already being planned. The IBIS Summit under consideration would be for 1/2 to 1 day and devoted to presentations and possible group discussion topics. To find out the level of interest, please respond to me regarding: What dates can you attend and prefer (DATE98 is February 23-26, 1998): Sunday, February 22, 1998 before DATE98? This could be officially affilated with DATE98 Thursday, February 26, 1998 after the trade show portion? This is similar to DAC Other Dates? Would you plan to attend the meeting? Would you plan to prepare a presentation (~15-30 minutes or even longer)? Do you have any suggestions for the Summit Meeting or its topics? Please respond to me as soon as possible since we need to make some committments soon based on your interest. Thank you Bob Ross Interconnectix bob@icx.com or bobross@eda.com From owner-ibis Mon Oct 13 06:32:24 1997 Received: from honcho.columbiasc.ncr.com (h153-78-17-231.NCR.COM [153.78.17.231]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id GAA05604 for ; Mon, 13 Oct 1997 06:32:21 -0700 (PDT) Received: from exchsmtp.ColumbiaSC.NCR.COM (xgate.ColumbiaSC.NCR.COM [153.78.17.107]) by honcho.columbiasc.ncr.com (8.6.12/8.6.12) with SMTP id JAA19845 for ; Mon, 13 Oct 1997 09:29:59 -0400 Received: by exchsmtp.ColumbiaSC.NCR.COM with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BCD7BA.8CB48160@exchsmtp.ColumbiaSC.NCR.COM>; Mon, 13 Oct 1997 09:29:48 -0400 Message-ID: From: "Mellitz, Richard" To: "'ibis-users@eda.org'" , "'pgregory@hpbs2933.boi.hp.com'" , "'bob@icx.com'" Cc: "'ericb@cadence.com'" Subject: RE: IBIS at >400MHz Date: Mon, 13 Oct 1997 09:31:52 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 107 TEXT Hi folks, Can IBIS help at > 400 MHz. Maybe. Here's my opinion (mostly babbling): At < 100 MHz we can talk about register to register transactions. We can talk about a simple algebraic equation. Clock to out, flight time, setup etc. Simple, eh? Maybe we even through in fudge factors for clock uncertainty and SSO. At > 100 MHz there are more players; statistical com theory, feedback, and crazy types of dispersion to name few. You need to understand these to develop design guidelines. For these you need just about every tool and trick you can muscle up. No tool alone is sufficient. You need to do some "real hard to make measurements" too. I guess this validation stuff is your basic a multi-dimensional task ;-) Who knows? You may get lucky and find a case where simple IBIS alone will work for you. After all that, the IBIS tools can be relegated the mammoth work horse task at the system level to being the "bell ringer" for problems you may want to look at closer. The real trick is to figure out what bells to ring and how loud to ring them. Anyone got any bells? Richard Mellitz, NCR >---------- >From: bob@icx.com[SMTP:bob@icx.com] >Sent: Thursday, October 09, 1997 3:14 PM >To: ibis-users@eda.org; pgregory@hpbs2933.boi.hp.com >Cc: ericb@cadence.com >Subject: Re: IBIS at >400MHz > >Paul: > >You raise some very good points and questions. I don't >have definitive answers. I support using Spice simulation >and measurement as part of the design methodology along >with IBIS based behavioral simulation. I would expect >that as specific IBIS format limitations are identified >with respect to higher frequency simulation accuracy, >proposals to ammend the IBIS format will be made. > >Eric Blomberg in "IBIS "models" come of age" in the October 1997 >issue of Printed Circuit Design. p. 20 provides a very concise >paragraph that addresses your points and provides some thoughts. >Eric's paragraph follows: > > "Can I use IBIS models for my 600 MHz bus?" The simplest > answer is yes - if the IBIS provider has validated the > model at 600 MHz. It is true that the device effects which > are simplified out of the IBIS model format start to become > visible about 300 MHz. It is also true that other effects, > such as dielectric loss, and the modeling engine's way of > handling this become significant as well. Device package > models play a larger role. The expectation answer is that > above 300 MHz, validation becomes a part-by-part issue for > the entire modeling system. > >Bob Ross >Interconnectix > > >> From: Paul Gregory >> Message-Id: <9710031834.AA20168@hpbs2933.boi.hp.com> >> Subject: IBIS at >400MHz >> To: ibis-users@eda.org >> Date: Fri, 3 Oct 97 12:34:01 MDT > >> In future designs, we plan to use interfaces that >> reach beyond 400 MHz. As I think about the tools >> that we need to help us successfully design at that >> speed, simulation is going to be a big part of it. >> But I am concerned that IBIS descriptions and >> simulation techniques may not be adequate to accurately >> simulate at that speed. Perhaps SPICE simulation >> will be required. > >> Should IBIS based simulators be capable of accurate >> simulation at speed of 400MHz to 1000MHz? > >> When device parasitics play a larger part of the >> equation, is IBIS sufficiently robust to accurately >> describe these parasitics? > >> What are the key factors to consider when simulating >> at these higher frequencies? > >> What are your thoughts? > >> -- Paul Gregory > >> phone: (208) 396-5086 USmail: Hewlett-Packard >> fax: (208) 396-4122 M/S 143 >> email: paul_gregory@hp.com 11311 Chinden Blvd. >> Boise, ID 83714 > > > From owner-ibis Mon Oct 13 11:45:39 1997 Received: from zoom.bga.com (root@zoom.realtime.net [205.238.128.40]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id LAA11028 for ; Mon, 13 Oct 1997 11:45:37 -0700 (PDT) Received: from russellr.bga.com (apm0-50.realtime.net [205.238.146.50]) by zoom.bga.com (8.6.12/8.6.12) with SMTP id NAA24071; Mon, 13 Oct 1997 13:43:41 -0500 Message-ID: <3442875D.1A34@staktek.com> Date: Mon, 13 Oct 1997 13:41:01 -0700 From: Russell Rapport Reply-To: russellr@staktek.com Organization: Staktek X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: si-list@silab.Eng.Sun.COM CC: ibis-users@eda.org Subject: EDA suite for Win NT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I realize these newsgroups consist of vendors from various competing EDA companies, so please send any replies to me directly, not to the newsgroups! I am trying to develop a well-integrated suite of moderate-cost (<$50K total) EDA tools for the PC Windows NT platform. I need schematic capture, PCB layout, Spice modelling for signal integrity, and IBIS capability. I would also like to be able to integrate thermal modelling at the component and board levels and FPGA and ASIC design and verification at some point. Some PCB routing will be contracted to an outside house with UNIX tools such as Cadence, Mentor, etc. I am especially interested in hearing from users who have managed to get their tools to work well together. Again, please reply directly to me. Thanks in advance, Russell Rapport Product Development Engineer Staktek Corporation From owner-ibis Thu Oct 16 17:10:45 1997 Received: from mail.huawei.co.cn ([202.96.135.132]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA04076 for ; Thu, 16 Oct 1997 17:10:39 -0700 (PDT) Received: from chenxy.huawei.co.cn ([129.9.4.100]) by mail.huawei.co.cn (Netscape Mail Server v2.02) with SMTP id AAA20208 for ; Fri, 17 Oct 1997 08:08:42 +0800 Message-ID: <3446AD25.AAF@huawei.co.cn> Date: Fri, 17 Oct 1997 08:11:17 +0800 From: chenxy@huawei.co.cn (Chen Xiaoyuan) Reply-To: chenxy@huawei.co.cn X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: ibis-users Subject: How to deal with analog devices? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, everyone! I want to ask one simple and naive question. WHen we do signal integrity analysis for PCB, we can assign IBIS model to the digital devices, but how to deal with the analog devices coexisting in the same board? And also, how about the discrete diodes and transistors? Thanks in advance. -- ************************** Chen XiaoYuan R&D Basic, CAD HuaWei Technology Co.Ltd Scientific Industrial Park ShenZhen City, GuanDong P.R China 518057 Tel: 86-755-6633828-3310 ************************** From owner-ibis Fri Oct 17 06:29:31 1997 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA18374 for ; Fri, 17 Oct 1997 06:29:30 -0700 (PDT) Received: from us8rmc.bb.dec.com (us8rmc.bb.dec.com [16.53.0.44]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA19553; Fri, 17 Oct 1997 08:30:41 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA13019; Fri, 17 Oct 97 08:23:19 -0400 Message-Id: <9710171223.AA13019@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Fri, 17 Oct 97 08:30:35 EDT Date: Fri, 17 Oct 97 08:30:35 EDT From: Andy Ingraham To: chenxy@huawei.co.cn Cc: ibis-users@vhdl.org, ingraham@wrksys.ENET.dec.com Apparently-To: ibis-users@vhdl.org, chenxy@huawei.co.cn Subject: Re: How to deal with analog devices? > I want to ask one simple and naive > question. WHen we do signal integrity analysis > for PCB, we can assign IBIS model to the > digital devices, but how to deal with the > analog devices coexisting in the same board? > And also, how about the discrete diodes and > transistors? I think this isn't really an IBIS issue. It's a question to take up with whoever makes your simulator. IBIS is a format for models, not simulators. My naive answer is that any simulator that handles IBIS models, (probably) also handles SPICE models. So just use SPICE models where appropriate, and IBIS models for those digital devices that have them, in the same simulation. If there is a simulator that accepts IBIS but not SPICE models, I think I'd stay well away from it. I can't imagine that any analog simulator would take IBIS models but not SPICE models. Regards, Andy Ingraham From owner-ibis Fri Oct 17 19:25:19 1997 Received: from mail.huawei.co.cn ([202.96.135.132]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id TAA03083 for ; Fri, 17 Oct 1997 19:25:11 -0700 (PDT) Received: from chenxy.huawei.co.cn ([129.9.4.100]) by mail.huawei.co.cn (Netscape Mail Server v2.02) with SMTP id AAA15768 for ; Sat, 18 Oct 1997 10:23:05 +0800 Message-ID: <34481E21.5D95@huawei.co.cn> Date: Sat, 18 Oct 1997 10:25:37 +0800 From: chenxy@huawei.co.cn (Chen Xiaoyuan) Reply-To: chenxy@huawei.co.cn X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: ibis-users Subject: Looking for help! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, everyone: I want to know whether there is any user of DF/SigNoise in ALLEGRO (Cadence EDA) to do signal integrity analysis or engineers from Cadence dealing with such issue among you. If there is, you can contact me directly, MAYBE we can discuss the details of how to use this software . BTW, what do you think about the performance of DF/SigNoise in doing PCB signal analysis ? And what others is better? Thanks in advance. -- ************************** Chen XiaoYuan R&D Basic, CAD HuaWei Technology Co.Ltd Scientific Industrial Park ShenZhen City, GuanDong P.R China 518057 ************************** From owner-ibis Fri Oct 17 20:00:13 1997 Received: from mail.istar.ca (mail1.toronto.istar.net [209.89.75.17]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id UAA03752 for ; Fri, 17 Oct 1997 20:00:12 -0700 (PDT) Received: from Lab-5 [204.191.153.236] by mail.istar.ca with smtp (Exim 1.70 #1) id 0xMP5q-0004sw-00; Fri, 17 Oct 1997 22:58:26 -0400 Message-ID: <33A0AE33.1DE@dynavision.com> Date: Thu, 12 Jun 1997 19:19:31 -0700 From: ram Reply-To: rmcbain@dynavision.com X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ibis-users@vhdl.org Subject: low budget IBIS tools Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit are there such a thing? I'm doing a 40 Mhz microprocessor design which looks like it has some potential problems with the bus layout. I'd rather not spend the 5 to 50K for modelling tools if I can help it. Are there any lower cost IBIS to spice convertors out there? And is the conversion accurate (i.e., do you lose information in the conversion from IBIS to spice), or should I be looking for native-mode tools? Thanks in advance. Rick McBain Senior Engineer Dynamic Control Syetms Inc. From owner-ibis Fri Oct 17 21:27:41 1997 Received: from montana.nwlink.com (root@montana.nwlink.com [199.242.23.13]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id VAA05071 for ; Fri, 17 Oct 1997 21:27:40 -0700 (PDT) Received: from stargate ([209.20.148.70]) by montana.nwlink.com (8.8.5/8.8.5) with SMTP id VAA18811; Fri, 17 Oct 1997 21:25:37 -0700 (PDT) Message-Id: <3.0.32.19971017212600.008f61c0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 17 Oct 1997 21:26:02 -0700 To: chenxy@huawei.co.cn, ibis-users From: Kellee Crisafulli Subject: Re: Looking for help! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Chen, At 10:25 AM 10/18/97 +0800, Chen Xiaoyuan wrote: >Hi, everyone: > I want to know whether there is any user >of DF/SigNoise in ALLEGRO (Cadence EDA) to do Please do not use this mail group for non IBIS releated issues. Use the high speed SI group for that. This group is dedicated to IBIS. From owner-ibis Sat Oct 18 10:17:30 1997 Received: from montana.nwlink.com (root@montana.nwlink.com [199.242.23.13]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA17977 for ; Sat, 18 Oct 1997 10:17:29 -0700 (PDT) Received: from stargate ([209.20.148.70]) by montana.nwlink.com (8.8.5/8.8.5) with SMTP id KAA26233; Sat, 18 Oct 1997 10:15:42 -0700 (PDT) Message-Id: <3.0.32.19971018101605.00911840@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 18 Oct 1997 10:16:07 -0700 To: rmcbain@dynavision.com, ibis-users@vhdl.org From: Kellee Crisafulli Subject: Re: low budget IBIS tools Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Rick, At 07:19 PM 6/12/97 -0700, ram wrote: >are there such a thing? I'm doing a 40 Mhz microprocessor design which >looks like it has some potential problems with the bus layout. I'd >rather not spend the 5 to 50K for modelling tools if I can help it. Are >there any lower cost IBIS to spice convertors out there? And is the >conversion accurate (i.e., do you lose information in the conversion >from IBIS to spice), or should I be looking for native-mode tools? Our Visual IBIS editor is free. Our Simulators do not require a conversion to spice and start at less than 3K, See www.hyperlynx.com From owner-ibis Thu Oct 23 14:59:07 1997 Received: from crimp.amp.com (crimp.amp.com [198.80.3.102]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id OAA25697 for ; Thu, 23 Oct 1997 14:59:04 -0700 (PDT) Message-Id: <199710232159.OAA25697@server.vhdl.org> Received: by crimp.amp.com id AA18385 (InterLock SMTP Gateway 3.0 for ibis-users@vhdl.org); Thu, 23 Oct 1997 17:57:04 -0400 Received: by crimp.amp.com (Internal Mail Agent-1); Thu, 23 Oct 1997 17:57:04 -0400 From: "Lin, Ted" To: "'ibis-users@vhdl.org'" , "'ram'" Subject: RE: low budget IBIS tools Date: Thu, 23 Oct 1997 17:56:57 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Rick, AMP Inc. offers a signal integrity tool called the AMPredictor Signal Integrity Analyzer. ($8,500 for a single license, $5,000 a piece if you purchase 3 licenses.) It is a Spice-based pre-layout tool that includes a complete Spice engine, a 2-D field solver that generates coupled-lossy transmission line models, connector noise analyzer, and an IBIS-to-AMPSPICE converter. The software can convert an IBIS data file to a SPICE-format analog behavior model. It then can be used with the AMPSPICE engine to perform Spice-based critical net analysis. There is more information on the website. www.ampincorporated.com/ampredictor ---------- From: ram [SMTP:rmcbain@dynavision.com] Sent: Thursday, June 12, 1997 10:20 PM To: ibis-users@vhdl.org Subject: low budget IBIS tools are there such a thing? I'm doing a 40 Mhz microprocessor design which looks like it has some potential problems with the bus layout. I'd rather not spend the 5 to 50K for modelling tools if I can help it. Are there any lower cost IBIS to spice convertors out there? And is the conversion accurate (i.e., do you lose information in the conversion from IBIS to spice), or should I be looking for native-mode tools? Thanks in advance. Rick McBain Senior Engineer Dynamic Control Syetms Inc. From owner-ibis Thu Oct 23 18:55:07 1997 Received: from via.com.tw (sun13.via.com.tw [203.70.217.13]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id SAA00068 for ; Thu, 23 Oct 1997 18:55:06 -0700 (PDT) Received: from weber.via.com.tw ([192.168.100.164]) by via.com.tw (4.1/SMI-4.1) id AA24223; Fri, 24 Oct 97 06:31:36 CST Message-Id: <34500110.238B@via.com.tw> Date: Fri, 24 Oct 1997 09:59:44 +0800 From: weberchuang Organization: VIA tech. X-Mailer: Mozilla 3.01Gold (Win95; I) Mime-Version: 1.0 To: "Lin, Ted" Cc: "'ibis-users@vhdl.org'" Subject: Re: low budget IBIS tools References: <199710232159.OAA25697@server.vhdl.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lin, Ted wrote: > > Hi Rick, > > AMP Inc. offers a signal integrity tool called the AMPredictor Signal > Integrity Analyzer. ($8,500 for a single license, $5,000 a piece if > you purchase 3 licenses.) It is a Spice-based pre-layout tool that > includes a complete Spice engine, a 2-D field solver that generates > coupled-lossy transmission line models, connector noise analyzer, and > an IBIS-to-AMPSPICE converter. The software can convert an IBIS data > file to a SPICE-format analog behavior model. It then can be used > with the AMPSPICE engine to perform Spice-based critical net analysis. > > There is more information on the website. > www.ampincorporated.com/ampredictor > > ---------- > From: ram [SMTP:rmcbain@dynavision.com] > Sent: Thursday, June 12, 1997 10:20 PM > To: ibis-users@vhdl.org > Subject: low budget IBIS tools > > are there such a thing? I'm doing a 40 Mhz microprocessor design > which > looks like it has some potential problems with the bus layout. I'd > rather not spend the 5 to 50K for modelling tools if I can help it. > Are > there any lower cost IBIS to spice convertors out there? And is the > conversion accurate (i.e., do you lose information in the conversion > from IBIS to spice), or should I be looking for native-mode tools? > > Thanks in advance. > > Rick McBain > Senior Engineer > Dynamic Control Syetms Inc. Dear Ted, Can I know to what level of MOS models that the AMP-spice can support? Thanks! Weber Chuang SI eng. VIA tech. Taiwan, ROC From owner-ibis Thu Oct 23 23:01:59 1997 Received: from alabama.nwlink.com (alabama.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id XAA04239 for ; Thu, 23 Oct 1997 23:01:58 -0700 (PDT) Received: from stargate ([209.20.148.70]) by alabama.nwlink.com (8.8.7/8.8.7) with SMTP id WAA25439; Thu, 23 Oct 1997 22:59:05 -0700 (PDT) Message-Id: <3.0.32.19971023225948.009171e0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 23 Oct 1997 22:59:51 -0700 To: weberchuang , "Lin, Ted" From: Kellee Crisafulli Subject: Re: low budget IBIS tools Cc: "'ibis-users@vhdl.org'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" This email group is for IBIS uses only! please take product specific email off or do it privately. At 09:59 AM 10/24/97 +0800, weberchuang wrote: > > Can I know to what level of MOS models that the AMP-spice can >support? Thanks! > >Weber Chuang >SI eng. >VIA tech. Taiwan, ROC > > From owner-ibis Fri Oct 24 05:04:15 1997 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id FAA10545 for ; Fri, 24 Oct 1997 05:04:14 -0700 (PDT) Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by emcmail.lss.emc.com (8.8.7/8.7.3) with SMTP id IAA26916 for ; Fri, 24 Oct 1997 08:06:39 -0400 (EDT) Received: by fishbowl02.emc.com with VINES-ISMTP; Fri, 24 Oct 97 8:02:03 -0400 Date: Fri, 24 Oct 97 7:56:45 -0400 Message-ID: X-Priority: 3 (Normal) To: "'ibis-users@vhdl.org'" , "'ram'" , From: "fabrizio zanella" Reply-To: Errors-to: Subject: RE: low budget IBIS tools X-Incognito-SN: 1467 X-Incognito-Version: 4.10.130 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Ted, regarding the IBIS to SPICE conversion in the AMPredictor tool; is the SPICE behavioral model output a file which can also be read by tools like HSPICE, PSPICE? How do you verify the accuracy of the IBIS models and also have you verified if any critical information has been lost in the conversion process? Does anyone else out there know of any other tools which are available for sale which convert IBIS files to HSPICE or PSPICE formats? Thanks, Fabrizio Zanella Sr. Design Engineer Hardware Engineering _/ _/ email: zanella_fabrizio@emc.com _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. 4645 _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 _/_/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ EMC Corporation _/_/_/_/ _/ _/ _/_/_/ 171 South Street Hopkinton, MA 01748-9103 ------------- Original Text From: "Lin, Ted" , on 10/23/97 5:56 PM: To: smtp@Eng@EMCHOP1["'ibis-users@vhdl.org'" ], smtp@Eng@EMCHOP1["'ram'" ] Hi Rick, AMP Inc. offers a signal integrity tool called the AMPredictor Signal Integrity Analyzer. ($8,500 for a single license, $5,000 a piece if you purchase 3 licenses.) It is a Spice-based pre-layout tool that includes a complete Spice engine, a 2-D field solver that generates coupled-lossy transmission line models, connector noise analyzer, and an IBIS-to-AMPSPICE converter. The software can convert an IBIS data file to a SPICE-format analog behavior model. It then can be used with the AMPSPICE engine to perform Spice-based critical net analysis. There is more information on the website. www.ampincorporated.com/ampredictor ---------- From: ram [SMTP:rmcbain@dynavision.com] Sent: Thursday, June 12, 1997 10:20 PM To: ibis-users@vhdl.org Subject: low budget IBIS tools are there such a thing? I'm doing a 40 Mhz microprocessor design which looks like it has some potential problems with the bus layout. I'd rather not spend the 5 to 50K for modelling tools if I can help it. Are there any lower cost IBIS to spice convertors out there? And is the conversion accurate (i.e., do you lose information in the conversion from IBIS to spice), or should I be looking for native-mode tools? Thanks in advance. Rick McBain Senior Engineer Dynamic Control Syetms Inc. From owner-ibis Fri Oct 24 05:30:48 1997 Received: from kaw.com ([206.155.177.89]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id FAA10934 for ; Fri, 24 Oct 1997 05:30:47 -0700 (PDT) Received: by kaw.com; id AA09986; Fri, 24 Oct 97 08:31:02 EDT Received: from omni.kaw.com(192.168.200.83) by explorer via smap (V3.1) id xma009982; Fri, 24 Oct 97 08:30:58 -0400 Received: from blazer.kaw.com (blazer [192.168.200.90]) by kaw.com (8.7.5/8.7.3) with SMTP id IAA13859; Fri, 24 Oct 1997 08:30:02 -0400 (EDT) Date: Fri, 24 Oct 1997 08:30:02 -0400 (EDT) Received: by blazer.kaw.com (SMI-8.6/SMI-SVR4) id IAA00461; Thu, 18 Sep 1997 08:27:26 -0400 From: dan@kaw.com (Dan Aleksandrowicz) Message-Id: <199709181227.IAA00461@blazer.kaw.com> To: ibis-users@vhdl.org Subject: Re: low budget IBIS tools Cc: kellee@mail.nwlink.com X-Sun-Charset: US-ASCII Hi there. Kellee is right, we all, once in a while, want to show and tell about our specific products or services. However, we have a fragile common goal and a lot of sensitivity is required. There are no specific "rules" or guidelines about what is right or wrong for this mail group, which I think is vital to the free discussion. However, I feel that in general problems and solutions that are not EDA tool specific, were and are the essence of this mail group. And from my experience, any EDA tool specific problems and solution are most efficiently handle out side this group. Thanks Dan Aleksandrowicz KAW/USA From owner-ibis Fri Oct 24 05:32:05 1997 Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id FAA11079 for ; Fri, 24 Oct 1997 05:32:04 -0700 (PDT) Received: from cisco.com (twarneke-sun.cisco.com [171.69.208.231]) by pilgrim.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA14863 for ; Fri, 24 Oct 1997 08:29:59 -0400 (EDT) Sender: twarneke@cisco.com Message-ID: <345094BC.EF968159@cisco.com> Date: Fri, 24 Oct 1997 08:29:49 -0400 From: Tom Warneke Organization: Cisco Systems X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "'ibis-users@vhdl.org'" Subject: Re: low budget IBIS tools References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am perplexed why one would want to convert IBIS to Spice models. My experience has been that digital designers (which IBIS is intended to serve) want to move away from SPICE to tools better suited to analyzing signal integrity, cross-talk, and EMC -- the annoying by-products of high speed digital circuits and fast edge rate devices that are common today. SPICE is a valuable tool for the analog engineer, and gives accurate results to the experienced user that understands the modeling requirements; however, it has not been the most effective tool for doing large scale signal integrity analysis on PCBs which is becoming more and more necessary on today's digital designs. In addition, IBIS models are often converted from SPICE. Why not request the SPICE models directly? All comments welcome, Tom -- Tom Warneke CAD Application Engineer Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 email: twarneke@cisco.com Phone: 508-244-8214 FAX: 508-244-8347 fabrizio zanella wrote: > > Ted, regarding the IBIS to SPICE conversion in the AMPredictor tool; > is the SPICE behavioral model output a file which can also be read by tools > like HSPICE, PSPICE? How do you verify the accuracy of the IBIS models and > also have you verified if any critical information has been lost in the > conversion process? > Does anyone else out there know of any other tools which are available for > sale which convert IBIS files to HSPICE or PSPICE formats? > Thanks, > Fabrizio Zanella > Sr. Design Engineer > Hardware Engineering > _/ _/ email: > zanella_fabrizio@emc.com > _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. > 4645 > _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 > _/_/_/_/ _/ _/ _/ _/ _/_/_/ > _/ _/ _/ _/ EMC Corporation > _/_/_/_/ _/ _/ _/_/_/ 171 South Street > Hopkinton, MA 01748-9103 > ------------- > Original Text > From: "Lin, Ted" , on 10/23/97 5:56 PM: > To: smtp@Eng@EMCHOP1["'ibis-users@vhdl.org'" ], > smtp@Eng@EMCHOP1["'ram'" ] > > Hi Rick, > > AMP Inc. offers a signal integrity tool called the AMPredictor Signal > Integrity Analyzer. ($8,500 for a single license, $5,000 a piece if > you purchase 3 licenses.) It is a Spice-based pre-layout tool that > includes a complete Spice engine, a 2-D field solver that generates > coupled-lossy transmission line models, connector noise analyzer, and > an IBIS-to-AMPSPICE converter. The software can convert an IBIS data > file to a SPICE-format analog behavior model. It then can be used > with the AMPSPICE engine to perform Spice-based critical net analysis. > > There is more information on the website. > www.ampincorporated.com/ampredictor > > ---------- > From: ram [SMTP:rmcbain@dynavision.com] > Sent: Thursday, June 12, 1997 10:20 PM > To: ibis-users@vhdl.org > Subject: low budget IBIS tools > > are there such a thing? I'm doing a 40 Mhz microprocessor design > which > looks like it has some potential problems with the bus layout. I'd > rather not spend the 5 to 50K for modelling tools if I can help it. > Are > there any lower cost IBIS to spice convertors out there? And is the > conversion accurate (i.e., do you lose information in the conversion > from IBIS to spice), or should I be looking for native-mode tools? > > Thanks in advance. > > Rick McBain > Senior Engineer > Dynamic Control Syetms Inc. From owner-ibis Fri Oct 24 07:01:25 1997 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA12557 for ; Fri, 24 Oct 1997 07:01:24 -0700 (PDT) Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by emcmail.lss.emc.com (8.8.7/8.7.3) with SMTP id KAA06131 for ; Fri, 24 Oct 1997 10:04:52 -0400 (EDT) Received: by fishbowl02.emc.com with VINES-ISMTP; Fri, 24 Oct 97 9:59:15 -0400 Date: Fri, 24 Oct 97 9:51:21 -0400 Message-ID: X-Priority: 3 (Normal) To: "'ibis-users@vhdl.org'" , From: "fabrizio zanella" Reply-To: Errors-to: Subject: Re: low budget IBIS tools X-Incognito-SN: 1467 X-Incognito-Version: 4.10.130 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Tom, the problem is that some semiconductor vendors are starting to only make IBIS models available, they don't want to release SPICE models (at times they release them under NDA, which is a nuisance for it can take up to a month to get all the signatures). I use HSPICE for computer system signal integrity analysis and have found very good correlation to empirical measurements. I have many device HSPICE models which are quite accurate. The few IBIS tools available are completely different and incompatible with SPICE files. I therefore want to continue using HSPICE, but run into a problem at times if I can only get IBIS models. Does anyone have any thoughts on this? Thanks, Fabrizio Zanella Sr. Design Engineer Hardware Engineering _/ _/ email: zanella_fabrizio@emc.com _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. 4645 _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 _/_/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ EMC Corporation _/_/_/_/ _/ _/ _/_/_/ 171 South Street Hopkinton, MA 01748-9103 ------------- Original Text From: "Tom Warneke" , on 10/24/97 8:29 AM: To: smtp@Eng@EMCHOP1["'ibis-users@vhdl.org'" ] Hi, I am perplexed why one would want to convert IBIS to Spice models. My experience has been that digital designers (which IBIS is intended to serve) want to move away from SPICE to tools better suited to analyzing signal integrity, cross-talk, and EMC -- the annoying by-products of high speed digital circuits and fast edge rate devices that are common today. SPICE is a valuable tool for the analog engineer, and gives accurate results to the experienced user that understands the modeling requirements; however, it has not been the most effective tool for doing large scale signal integrity analysis on PCBs which is becoming more and more necessary on today's digital designs. In addition, IBIS models are often converted from SPICE. Why not request the SPICE models directly? All comments welcome, Tom -- Tom Warneke CAD Application Engineer Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 email: twarneke@cisco.com Phone: 508-244-8214 FAX: 508-244-8347 fabrizio zanella wrote: > > Ted, regarding the IBIS to SPICE conversion in the AMPredictor tool; > is the SPICE behavioral model output a file which can also be read by tools > like HSPICE, PSPICE? How do you verify the accuracy of the IBIS models and > also have you verified if any critical information has been lost in the > conversion process? > Does anyone else out there know of any other tools which are available for > sale which convert IBIS files to HSPICE or PSPICE formats? > Thanks, > Fabrizio Zanella > Sr. Design Engineer > Hardware Engineering > _/ _/ email: > zanella_fabrizio@emc.com > _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. > 4645 > _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 > _/_/_/_/ _/ _/ _/ _/ _/_/_/ > _/ _/ _/ _/ EMC Corporation > _/_/_/_/ _/ _/ _/_/_/ 171 South Street > Hopkinton, MA 01748-9103 > ------------- > Original Text > From: "Lin, Ted" , on 10/23/97 5:56 PM: > To: smtp@Eng@EMCHOP1["'ibis-users@vhdl.org'" ], > smtp@Eng@EMCHOP1["'ram'" ] > > Hi Rick, > > AMP Inc. offers a signal integrity tool called the AMPredictor Signal > Integrity Analyzer. ($8,500 for a single license, $5,000 a piece if > you purchase 3 licenses.) It is a Spice-based pre-layout tool that > includes a complete Spice engine, a 2-D field solver that generates > coupled-lossy transmission line models, connector noise analyzer, and > an IBIS-to-AMPSPICE converter. The software can convert an IBIS data > file to a SPICE-format analog behavior model. It then can be used > with the AMPSPICE engine to perform Spice-based critical net analysis. > > There is more information on the website. > www.ampincorporated.com/ampredictor > > ---------- > From: ram [SMTP:rmcbain@dynavision.com] > Sent: Thursday, June 12, 1997 10:20 PM > To: ibis-users@vhdl.org > Subject: low budget IBIS tools > > are there such a thing? I'm doing a 40 Mhz microprocessor design > which > looks like it has some potential problems with the bus layout. I'd > rather not spend the 5 to 50K for modelling tools if I can help it. > Are > there any lower cost IBIS to spice convertors out there? And is the > conversion accurate (i.e., do you lose information in the conversion > from IBIS to spice), or should I be looking for native-mode tools? > > Thanks in advance. > > Rick McBain > Senior Engineer > Dynamic Control Syetms Inc. From owner-ibis Fri Oct 24 07:23:27 1997 Received: from kaw.com ([206.155.177.89]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id HAA12887 for ; Fri, 24 Oct 1997 07:23:26 -0700 (PDT) Received: by kaw.com; id AA10298; Fri, 24 Oct 97 10:23:39 EDT Received: from omni.kaw.com(192.168.200.83) by explorer via smap (V3.1) id xma010296; Fri, 24 Oct 97 10:23:09 -0400 Received: from blazer.kaw.com (blazer [192.168.200.90]) by kaw.com (8.7.5/8.7.3) with SMTP id KAA14166; Fri, 24 Oct 1997 10:22:12 -0400 (EDT) Date: Fri, 24 Oct 1997 10:22:12 -0400 (EDT) Received: by blazer.kaw.com (SMI-8.6/SMI-SVR4) id KAA00657; Thu, 18 Sep 1997 10:19:36 -0400 From: dan@kaw.com (Dan Aleksandrowicz) Message-Id: <199709181419.KAA00657@blazer.kaw.com> To: twarneke@cisco.com Subject: Re: low budget IBIS tools Cc: ibis-users@vhdl.org X-Sun-Charset: US-ASCII Hi Tom. You are correct in your assumption that IBIS users, as much as IC vendors, wanted to move from spice simulation/models to IBIS simulations/models. Yet, there will always be that digital circuit that IBIS does not apply. This might be in today's in serial IC's or even an active termination. Another, most common possibility would be in the initial stage of a project were technologies and concepts are tested for signal integrity. So we try to find a combined solution which enable us to use IBIS models and to some spice simulation for a wide range of scenarios. And a pure routed PCB simulation is good as a verification procedure. Solving problem at that stage is usually very problematic. Dan Aleksandrowicz. From owner-ibis Fri Oct 24 08:18:26 1997 Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA13913 for ; Fri, 24 Oct 1997 08:18:26 -0700 (PDT) Received: from cisco.com (twarneke-sun.cisco.com [171.69.208.231]) by pilgrim.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA21823; Fri, 24 Oct 1997 11:16:16 -0400 (EDT) Sender: twarneke@cisco.com Message-ID: <3450BBB6.E516FEE6@cisco.com> Date: Fri, 24 Oct 1997 11:16:06 -0400 From: Tom Warneke Organization: Cisco Systems X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Dan Aleksandrowicz CC: ibis-users@vhdl.org Subject: Re: low budget IBIS tools References: <199709181419.KAA00657@blazer.kaw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I understand the need for SPICE and the value it can provide in offering a more robust environment and control over modeling characteristics than IBIS models and simulators support. It seems that something will be lost in going from SPICE Model -> IBIS -> SPICE model. My understanding is that (behavioral) IBIS models are generally derived from (functional) SPICE models. At best, it seems, that you will get a behavioral -- not functional -- SPICE model. I suppose it makes sense if only an IBIS model is available. It seems, however, that the SPICE run will be limited by the behavioral data that can be extracted from the IBIS model. IBIS models and simulators are fine tuned to be faster and easier to use for their intended purpose. This imposes limitations which are not realized in the SPICE world (i.e. support for voltage controlled multi-stage drivers and the examples you provided). It seems to me that using a SPICE simulator with models derived from IBIS is taking on the worst of both worlds: SPICE complexity and run times and IBIS model limitations. Would it make sense to convert your SPICE model library to IBIS -- it takes effort and care to translate models accurately -- to use in the IBIS domain for those cases when you must use IBIS models because SPICE models are not available? Then you get the relatively easy and fine tuned IBIS environment which is better suited to the required IBIS models, and you can use SPICE on those circuits for which you have all the SPICE models available. Further feedback is welcome... Regards, Tom Dan Aleksandrowicz wrote: > > Hi Tom. > > You are correct in your assumption that IBIS users, as much as IC vendors, > wanted to move from spice simulation/models to IBIS simulations/models. > > Yet, there will always be that digital circuit that IBIS does not apply. > This might be in today's in serial IC's or even an active termination. > Another, most common possibility would be in the initial stage of a project > were technologies and concepts are tested for signal integrity. > > So we try to find a combined solution which enable us to > use IBIS models and to some spice simulation for a wide range > of scenarios. > > And a pure routed PCB simulation is good as a verification procedure. > Solving problem at that stage is usually very problematic. > > Dan Aleksandrowicz. -- Tom Warneke CAD Application Engineer Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 email: twarneke@cisco.com Phone: 508-244-8214 FAX: 508-244-8347 From owner-ibis Fri Oct 24 08:46:21 1997 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA14304 for ; Fri, 24 Oct 1997 08:46:21 -0700 (PDT) Received: from us8rmc.bb.dec.com (us8rmc.bb.dec.com [16.53.0.44]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA03870 for ; Fri, 24 Oct 1997 11:37:52 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA28327; Fri, 24 Oct 97 11:34:49 -0400 Message-Id: <9710241534.AA28327@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Fri, 24 Oct 97 11:37:51 EDT Date: Fri, 24 Oct 97 11:37:51 EDT From: Andrew Ingraham To: ibis-users@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis-users@vhdl.org Subject: Re: low budget IBIS tools > Tom, the problem is that some semiconductor vendors are starting to only > make IBIS models available, they don't want to release SPICE models (at > times they release them under NDA, which is a nuisance for it can take up > to a month to get all the signatures). > I use HSPICE for computer system signal integrity analysis and have found > very good correlation to empirical measurements. I have many device HSPICE > models which are quite accurate. The few IBIS tools available are > completely different and incompatible with SPICE files. I therefore want > to continue using HSPICE, but run into a problem at times if I can only get > IBIS models. > Does anyone have any thoughts on this? I agree 100% !!! Today I need a SPICE model for an 8-pin part. We either take their IBIS model or we wait a month for the NDA. But I need the SPICE model! From owner-ibis Fri Oct 24 11:29:38 1997 Received: from alabama.nwlink.com (alabama.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA17101 for ; Fri, 24 Oct 1997 11:29:34 -0700 (PDT) Received: (from kellee@localhost) by alabama.nwlink.com (8.8.7/8.8.7) id LAA03550; Fri, 24 Oct 1997 11:27:48 -0700 (PDT) Message-Id: <3.0.32.19971024112751.00690c28@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 24 Oct 1997 11:27:53 -0700 To: Andrew Ingraham , ibis-users@vhdl.org From: Kellee Crisafulli Subject: Re: IBIS tools Cc: ingraham@wrksys.enet.dec.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Andy, At 11:37 AM 10/24/97 EDT, Andrew Ingraham wrote: >> The few IBIS tools available are completely different and incompatible with >> SPICE files. I therefore want to continue using SPICE, but run into a >> problem at times if I can only get IBIS models. >> Does anyone have any thoughts on this? It seems to me the big problem is the very poor support a few of the spice vendors have provided for IBIS. The SPICE vendors could easily provide an IBIS model as a native model in their tool. I feel you should work on your SPICE vendor to provide better IBIS support. It should be easier for them to provide support for IBIS directly than to support a single complex transistor behavior model like SPICE does now. To summarize: The solution I feel you should be pushing for is to get your simulator vendor to improve their IBIS support. The majority of the simulator companies that focus on signal integrity tools have excellent support for IBIS. Two SPICE companies need to catch up. ------------------------------------------------------------------------- Live long and prosper ... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Fri Oct 24 12:19:17 1997 Received: from cliff.molex.com (cliff.molex.com [209.28.10.2]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id MAA18007 for ; Fri, 24 Oct 1997 12:19:13 -0700 (PDT) From: apanella@molex.com Received: from ccMail by cliff.molex.com (IMA Internet Exchange 2.11 Enterprise) id 0000252A; Fri, 24 Oct 1997 14:19:06 -0500 Mime-Version: 1.0 Date: Fri, 24 Oct 1997 14:08:50 -0500 Message-ID: <0000252A.@molex.com> Subject: Re[2]: low budget IBIS tools To: ibis-users@vhdl.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Greetings, Might I suggest a couple reason's 1. Some people only have one "solver" SPICE or IBIS..' 2. Some models might only come in one of the two versions... therefore a translator is required. For example, digital IC companies like to provide IBIS models because they do not reveal manufacturing processes. 3. Someone might be interested in MULTIPLE coupled line effects (electrostatic AND magnetic) for analog or digital designs. The IBIS standard format does not have a format to do this ... yet??.. SPICE does... Are there other reasons? _gus panella Molex, Inc. ______________________________ Reply Separator _________________________________ Subject: Re: low budget IBIS tools Author: owner-ibis@server.vhdl.org at internet Date: 97/10/24 8:29 AM Hi, I am perplexed why one would want to convert IBIS to Spice models. My experience has been that digital designers (which IBIS is intended to serve) want to move away from SPICE to tools better suited to analyzing signal integrity, cross-talk, and EMC -- the annoying by-products of high speed digital circuits and fast edge rate devices that are common today. SPICE is a valuable tool for the analog engineer, and gives accurate results to the experienced user that understands the modeling requirements; however, it has not been the most effective tool for doing large scale signal integrity analysis on PCBs which is becoming more and more necessary on today's digital designs. In addition, IBIS models are often converted from SPICE. Why not request the SPICE models directly? All comments welcome, Tom -- Tom Warneke CAD Application Engineer Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 email: twarneke@cisco.com Phone: 508-244-8214 FAX: 508-244-8347 fabrizio zanella wrote: > > Ted, regarding the IBIS to SPICE conversion in the AMPredictor tool; > is the SPICE behavioral model output a file which can also be read by tools > like HSPICE, PSPICE? How do you verify the accuracy of the IBIS models and > also have you verified if any critical information has been lost in the > conversion process? > Does anyone else out there know of any other tools which are available for > sale which convert IBIS files to HSPICE or PSPICE formats? > Thanks, > Fabriz io Zanella > Sr. De sign Engineer > Hardwa re Engineering > _/ _/ email: > zanella_fabrizio@emc.com > _/_/_/_/ _/ _/ _/_/_/ _/ voice: (508) 435-1000 Ext. > 4645 > _/ _/_/ _/_/ _/ _/ Fax: (508) 435-8949 > _/_/_/_/ _/ _/ _/ _/ _/_/_/ > _/ _/ _/ _/ EMC Corporation > _/_/_/_/ _/ _/ _/_/_/ 171 South Street > Hopkinton, MA 01748-9103 > ------------- > Original Text > From: "Lin, Ted" , on 10/23/97 5:56 PM: > To: smtp@Eng@EMCHOP1["'ibis-users@vhdl.org'" ], > smtp@Eng@EMCHOP1["'ram'" ] > > Hi Rick, > > AMP Inc. offers a signal integrity tool called the AMPredictor Signal > Integrity Analyzer. ($8,500 for a single license, $5,000 a piece if > you purchase 3 licenses.) It is a Spice-based pre-layout tool that > includes a complete Spice engine, a 2-D field solver that generates > coupled-lossy transmission line models, connector noise analyzer, and > an IBIS-to-AMPSPICE converter. The software can convert an IBIS data > file to a SPICE-format analog behavior model. It then can be used > with the AMPSPICE engine to perform Spice-based critical net analysis. > > There is more information on the website. > www.ampincorporated.com/ampredictor > > ---------- > From: ram [SMTP:rmcbain@dynavision.com] > Sent: Thursday, June 12, 1997 10:20 PM > To: ibis-users@vhdl.org > Subject: low budget IBIS tools > > are there such a thing? I'm doing a 40 Mhz microprocessor design > which > looks like it has some potential problems with the bus layout. I'd > rather not spend the 5 to 50K for modelling tools if I can help it. > Are > there any lower cost IBIS to spice convertors out there? And is the > conversion accurate (i.e., do you lose information in the conversion > from IBIS to spice), or should I be looking for native-mode tools? > > Thanks in advance. > > Rick McBain > Senior Engineer > Dynamic Control Syetms Inc. From owner-ibis Fri Oct 24 12:30:11 1997 Received: from InterJet.apsimtech.com (apsimtech.com [209.21.21.35]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA18187 for ; Fri, 24 Oct 1997 12:30:10 -0700 (PDT) Received: from apsimtech.com (raghu.apsimtech.com [192.168.1.79]) by InterJet.apsimtech.com (8.8.5/8.8.4) with ESMTP id MAA05293; Fri, 24 Oct 1997 12:21:37 -0700 (PDT) Sender: raghu@apsimtech.com Message-ID: <3450F4F3.4B53AA7E@apsimtech.com> Date: Fri, 24 Oct 1997 12:20:19 -0700 From: Raghu Organization: Applied Simulation Technology X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.4 sun4c) MIME-Version: 1.0 To: Kellee Crisafulli CC: Andrew Ingraham , ibis-users@vhdl.org Subject: Re: IBIS tools References: <3.0.32.19971024112751.00690c28@mail.nwlink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit With all this talk about SPICE and IBIS, I felt compelled to say something on this issue. We, at Applied Simulation, do use SPICE (in particular ApsimSPICE) even for IBIS models. We have implemented special implements in ApsimSPICE and our IBIS Translator translates an IBIS model into equivalent SPICE models. The user is then free to add whatever other SPICE elements (e.g a transistor described in BSIM3 v3. model) he /she wants and do a combined simulation. This should be the preferred approach as a pure IBIS simulator may be restricted in the topologies it can handle. Also SPICE algorithms are well known and the results are better understood. ************************************************************************ Raj Raghuram Applied Simulation Technology, 2188 Bering Drive, San Jose, CA-95131. Tel: (408) 434-0967 ext.101 Fax: (408) 434-1003 e-mail: raghu@apsimtech.com ************************************************************************ From owner-ibis Fri Oct 24 14:37:43 1997 Received: from alabama.nwlink.com (alabama.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA20381 for ; Fri, 24 Oct 1997 14:37:42 -0700 (PDT) Received: from stargate ([209.20.148.70]) by alabama.nwlink.com (8.8.7/8.8.7) with SMTP id OAA25430; Fri, 24 Oct 1997 14:35:48 -0700 (PDT) Message-Id: <3.0.32.19971024143630.00926100@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 24 Oct 1997 14:36:33 -0700 To: Raghu From: Kellee Crisafulli Subject: Re: IBIS tools Cc: ibis-users@vhdl.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Raghu, At 12:20 PM 10/24/97 -0700, Raghu wrote: >With all this talk about SPICE and IBIS, I felt compelled to say >something on this issue. Also SPICE algorithms are well known and the >results are better understood. I don't wish to get into a war about SPICE problems, but your above statement is simply not true. The transistor behavior models in SPICE packages vary all over the place. For example I personally know of two very well known SPICE packages both simulating the exact same SPICE model and getting slew rates that where more than 2x different. The problem was chased down to differences in the transistor behavioral models used by the two SPICE packages. These are apparently NOT well known algorithms. This is not an unusual problem with SPICE IC models contrary to the propaganda. If someone creates a SPICE model and runs it on the exact same companies SPICE simulator the transistor models do match very well. If the transistor model is from one SPICE company and the simulator from another than the matching erodes. Often people attempt to translate transistor parameters from one package to another by hand because the simulations will not run and again the transistor model accuracy is gone. There is a very serious lack of standards in the SPICE community regarding transistor models. (My opinion) And I have used HSPICE, PSPICE, Intusoft SPICE, Berkley SPICE, and Contec SPICE, AMI SPICE, and DR SPICE. I suggest we drop this thread for now and refocus on the purpose of this group (to develop and promote IBIS models). From owner-ibis Fri Oct 24 13:28:53 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by server.vhdl.org (8.8.5/8.8.3) with SMTP id NAA19250; Fri, 24 Oct 1997 13:28:52 -0700 (PDT) Received: by icx.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Fri, 24 Oct 1997 13:27:06 -0700 (PDT) Received: by chane.icx.com (Smail-3.2.0.92 1997-Feb-9 #5) id ; Fri, 24 Oct 1997 13:26:53 -0700 (PDT) Received: by bob.icx.com via send-mail with stdio id for ibis-users@eda.org; Fri, 24 Oct 1997 13:26:53 -0700 (PDT) (Smail-3.2.0.92 1997-Feb-9 #7 built 1997-Jun-4) Message-Id: Date: Fri, 24 Oct 1997 13:26:53 -0700 (PDT) From: bob@icx.com ( Bob Ross) To: ibis-users@eda.org, ibis@eda.org Subject: IBIS Reflector Usage Cc: bob@icx.com To All: This note is to inform people on IBIS reflector usage as reminder of some previous discussions on this subject and also to communicate to the many newer reflector participants of our discussion restrictons. We request all COMMERCIAL PRODUCT related discussions or reponses to questions to be handled PRIVATELY OFF LINE. These types of discussions, even if they relate to tools that use IBIS or translate IBIS data, are best handled on the signal integrity reflector. It is OK to INFORM people of FREE PRODUCTS and FREE IBIS MODELS that are available. We do provide links/information on some companies on the EIA IBIS Web Site through the Poster selection and also through the Roster and Model Provider selections. We allow and even encourage information about IBIS related products in the Support or Tag-Line fields of the Roster, and this is open to any company. There are several reasons for the relfector discussion restriction. The EIA IBIS Open Forum is formally affiliated with EIA, and it is the EIA policy is to forbid Commercial discussion. In addition, the EIA IBIS Open Forum consists of individuals particpating as company representatives, and many companies are providing financial support for their participation and financial support to the EIA IBIS Open Forum through EIA IBIS Open Forum membership fees and contributions. Therefore it is NOT appropriate to put individuals in the position of having to promote or defend their own products when their real charter is work together on IBIS issues. So any IBIS discussion is appropriate as long as it does not relate to Commercial Products. Please use another reflector and/or respond PRIVATELY if you have any product information that may be helpful someone. Bob Ross Interconnectix Chair. EIA IBIS Open Forum From owner-ibis Fri Oct 24 18:53:45 1997 Received: from alabama.nwlink.com (alabama.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA24663 for ; Fri, 24 Oct 1997 18:53:44 -0700 (PDT) Received: (from kellee@localhost) by alabama.nwlink.com (8.8.7/8.8.7) id SAA04729; Fri, 24 Oct 1997 18:51:58 -0700 (PDT) Message-Id: <3.0.32.19971024185202.00740dac@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 24 Oct 1997 18:52:03 -0700 To: ibis-users@vhdl.org From: Kellee Crisafulli Subject: How to subscribe to the Signal Integrity group Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi IBIS Land, I have had several requests in the last 2 days for the reflector address for the SI group. Here it is for anyone that wants it. The address to subscribe is: si-admin@silab.Eng.Sun.COM All that's required is "subscribe" in the subject line. For general discussions on tools, and techniques associated with signal integrity this is the place. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Sat Oct 25 19:51:26 1997 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id TAA18915 for ; Sat, 25 Oct 1997 19:51:25 -0700 (PDT) Received: from us8rmc.bb.dec.com (us8rmc.bb.dec.com [16.53.0.44]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA15689 for ; Sat, 25 Oct 1997 22:40:51 -0400 (EDT) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA26945; Sat, 25 Oct 97 22:35:47 -0400 Message-Id: <9710260235.AA26945@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Sat, 25 Oct 97 22:40:51 EDT Date: Sat, 25 Oct 97 22:40:51 EDT From: Andrew Ingraham To: ibis-users@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis-users@vhdl.org Subject: Re: low budget IBIS tools Tom Warneke wrote: > I am perplexed why one would want to convert IBIS to Spice models. > > My experience has been that digital designers (which IBIS is intended to > serve) want to move away from SPICE to tools better suited to analyzing > signal integrity, cross-talk, and EMC -- the annoying by-products of > high speed digital circuits and fast edge rate devices that are common > today. I disagree that IBIS is intended to serve digital designers who want to move away from SPICE. IBIS has everything to do with analog simulation, the same stuff we use SPICE for. IBIS models are not inherently different from SPICE models in terms of signal integrity, crosstalk, EMC, etc. One of the reasons for IBIS is because of the proprietary model problem. Lots of us folks who use SPICE, have this problem, both analog and digital engineers. Quoting from the IBIS FAQ: "IBIS ... is a method of providing the Input/Output device characteristics through V/I data without disclosing any circuit/process information." Another reason is speed. SPICE models can be unnecessarily complex, when all you are after are the interconnect characteristics. Some SPICE models include the whole chip, or huge portions of the output buffers, and run unbearably slow. IBIS focuses only on the I/O characteristics. Yet another reason, is that IBIS models lend themselves particularly well to being based on real, measured data. Trying to tweak a full-blown SPICE model to fit measured data, is risky at best. IBIS models don't need to be tweaked to fit the data; the measured data becomes the IBIS model. In my opinion, the free s2ibis tool, has done a lot to damage IBIS's potential, by allowing anyone to make IBIS models from their SPICE models and not even trying to use measured data. s2ibis is how you jump on the IBIS bandwagon. It's not how you do it right. On the other hand, a free i2spice tool, is exactly what IBIS needs and has needed since day 1. IBIS is neither a simulator, nor a simulation methodology. It is merely a spec for an electrical model, that is intended to be used in a SPICE or SPICE-like (analog) simulator. The very unfortunate thing for us users, is that some of the old SPICE programs still don't know IBIS. At work, I use two SPICE programs. One is generic SPICE with in-house customizations to know all about the CMOS processes of our fab. The other is a popular program with extensions for dozens of other MOS transistor models. I *must* use the first program when I want to simulate something involving the chips we make when I only have models for the first program. I *must* use the second program when I want to simulate something involving external vendor's chips where their SPICE models are unique to that program, as the majority of external SPICE models seem to be. God help me if I have to simulate a signal that connects between both kinds of chips! IBIS models only make this worse. Don't get me wrong; I support the idea of IBIS models. But I do not have the means to use an IBIS model in a simulation; neither of the two SPICE programs I use, knows IBIS. If I use a newer IBIS-aware signal integrity simulator, it would not be able to accept at least one of the two types of SPICE models above; maybe even both. That is totally unacceptable to me. If the majority of my models are proprietary SPICE, and occasionally an IBIS model comes along, and since my environment is already set up for working with SPICE, I think I am better off (for now) staying with the SPICE environment. So considering those increasingly frequent cases where an IC vendor refuses to show us the SPICE model, it makes a heck of a lot of sense to translate their IBIS model into a SPICE-usable format. In fact, I might even expect such a model to be more accurate, if it is based on measured data. How often have you gotten a SPICE model that differed from the measured buffer strength by 300%, or where the SPICE model completely lacked clamp diodes that were there, or where all the diodes had zero resistance? If the IBIS model was created from measured data, then I should be in much better shape with it, or a SPICE behavioral model derived from it. > It seems that something will be lost in going from SPICE Model -> IBIS > -> SPICE model. My understanding is that (behavioral) IBIS models are > generally derived from (functional) SPICE models. Indeed, many are, but they shouldn't be. We should expect to get measured IBIS models for anything for which real silicon exists. IBIS models derived from SPICE should only be acceptable when the device is in development and hasn't been built yet. But, alas, IC vendors are too stupid or lazy to do this. > IBIS models and simulators are fine tuned to be faster and easier to use > for their intended purpose. This imposes limitations which are not > realized in the SPICE world (i.e. support for voltage controlled > multi-stage drivers and the examples you provided). It seems to me that > using a SPICE simulator with models derived from IBIS is taking on the > worst of both worlds: SPICE complexity and run times and IBIS model > limitations. What makes SPICE slow, are the SPICE models. Not the simulator per se. SPICE simulates what happens at every single internal node and device in the structural model, even if they have no effect on the I/O pin. IBIS models are faster because they skip all that and concentrate on just the I/O pin. SPICE can have behavioral models too, and they run extremely fast. Translating an IBIS model into a behavioral SPICE model should let it run just about as fast as using the IBIS model directly in an IBIS-aware environment. Regards, Andy From owner-ibis Sun Oct 26 09:56:09 1997 Received: from alabama.nwlink.com (alabama.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA04151 for ; Sun, 26 Oct 1997 09:56:07 -0800 (PST) Received: from stargate ([209.20.148.70]) by alabama.nwlink.com (8.8.7/8.8.7) with SMTP id JAA19299; Sun, 26 Oct 1997 09:52:44 -0800 (PST) Message-Id: <3.0.32.19971026095324.009537a0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 26 Oct 1997 09:53:27 -0800 To: Andrew Ingraham , ibis-users@vhdl.org From: Kellee Crisafulli Subject: SPICE problems Cc: ingraham@wrksys.enet.dec.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Andrew, >Tom Warneke wrote: >> I am perplexed why one would want to convert IBIS to Spice models. > >Andrew wrote: >I disagree that IBIS is intended to serve digital designers who want >to move away from SPICE. IBIS has everything to do with analog >simulation, the same stuff we use SPICE for. IBIS models are not >inherently different from SPICE models in terms of signal integrity, >crosstalk, EMC, etc. I think you are missing Tom's point. Yes I agree IBIS simulators and SPICE do the same thing functionally and yes I agree that all SPICE packages should be able to run IBIS natively and certainly could be made to. I believe Tom's point about digital engineers was related to ease of use. IBIS defines many things automatically that SPICE models of the same component do not. This is due mostly to lack of standards. There is no 'SPICE' model to define the standard method of pin-outs, power supplies, package parameters etc in SPICE. IBIS is the method of doing that and much more. Whether it is used with SPICE as the engine or a signal integrity tool which has an equal or better engine for SI analysis. There are other problems with SPICE that make it difficult for digital engineers including DC and AC stability problems that are a part of most if not ALL SPICE packages. As an avid SPICE user I bet you have run into more than one IC models that you had a problem getting to stabilize or you had trouble figuring out which polarity on the enable to use or had trouble figuring out how to connect the package modeling to the die model, or had trouble figuring out how to convert it from HSPICE to PSPICE or PSPICE to Berkley SPICE etc. I separate digital engineers from analog engineers only in that they will not use signal integrity tools if they have to put up with the amount of work required to get a board full of SPICE models hooked up and running. An analog engineer often only models a small part of a board associated with a one or two pins. He can afford to invest the time to use SPICE without the high level gain of using IBIS models and the other high level interface gains any good signal integrity tool offers. Don't get me wrong SPICE is a great tool for more constrained problem sets. I have spent many hundreds of hours using it. Bottom line. I felt Tom's point was ease of use differences. From owner-ibis Mon Oct 27 07:12:56 1997 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA25629 for ; Mon, 27 Oct 1997 07:12:55 -0800 (PST) Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by emcmail.lss.emc.com (8.8.7/8.7.3) with SMTP id KAA25145 for ; Mon, 27 Oct 1997 10:16:30 -0500 (EST) Received: by fishbowl02.emc.com with VINES-ISMTP; Mon, 27 Oct 97 10:10:34 -0500 Date: Mon, 27 Oct 97 10:05:26 -0500 Message-ID: X-Priority: 3 (Normal) To: From: "fabrizio zanella" Reply-To: Errors-to: Subject: Re: low budget IBIS tools X-Incognito-SN: 1467 X-Incognito-Version: 4.10.130 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Andy, I agree 100% with your comments. IBIS models are a great idea, but until an IBIS to SPICE converter is available to the general public, most of us will not be able to use IBIS models. The availability of an IBIS to SPICE converter will spread the use of IBIS models, which is what this group's goal is. So either the major simulator companies or a university group need to create such a tool. The spice to IBIS converter is not a good idea if we are trying to create better models that are based on measurements. Regards, Fabrizio Zanella, EMC corporation ------------- Original Text From: "Andrew Ingraham" , on 10/25/97 9:40 PM: To: smtp@Eng@EMCHOP1[], smtp@Eng@EMCHOP1[] Cc: smtp@Eng@EMCHOP1[] Tom Warneke wrote: > I am perplexed why one would want to convert IBIS to Spice models. > > My experience has been that digital designers (which IBIS is intended to > serve) want to move away from SPICE to tools better suited to analyzing > signal integrity, cross-talk, and EMC -- the annoying by-products of > high speed digital circuits and fast edge rate devices that are common > today. I disagree that IBIS is intended to serve digital designers who want to move away from SPICE. IBIS has everything to do with analog simulation, the same stuff we use SPICE for. IBIS models are not inherently different from SPICE models in terms of signal integrity, crosstalk, EMC, etc. One of the reasons for IBIS is because of the proprietary model problem. Lots of us folks who use SPICE, have this problem, both analog and digital engineers. Quoting from the IBIS FAQ: "IBIS ... is a method of providing the Input/Output device characteristics through V/I data without disclosing any circuit/process information." Another reason is speed. SPICE models can be unnecessarily complex, when all you are after are the interconnect characteristics. Some SPICE models include the whole chip, or huge portions of the output buffers, and run unbearably slow. IBIS focuses only on the I/O characteristics. Yet another reason, is that IBIS models lend themselves particularly well to being based on real, measured data. Trying to tweak a full-blown SPICE model to fit measured data, is risky at best. IBIS models don't need to be tweaked to fit the data; the measured data becomes the IBIS model. In my opinion, the free s2ibis tool, has done a lot to damage IBIS's potential, by allowing anyone to make IBIS models from their SPICE models and not even trying to use measured data. s2ibis is how you jump on the IBIS bandwagon. It's not how you do it right. On the other hand, a free i2spice tool, is exactly what IBIS needs and has needed since day 1. IBIS is neither a simulator, nor a simulation methodology. It is merely a spec for an electrical model, that is intended to be used in a SPICE or SPICE-like (analog) simulator. The very unfortunate thing for us users, is that some of the old SPICE programs still don't know IBIS. At work, I use two SPICE programs. One is generic SPICE with in-house customizations to know all about the CMOS processes of our fab. The other is a popular program with extensions for dozens of other MOS transistor models. I *must* use the first program when I want to simulate something involving the chips we make when I only have models for the first program. I *must* use the second program when I want to simulate something involving external vendor's chips where their SPICE models are unique to that program, as the majority of external SPICE models seem to be. God help me if I have to simulate a signal that connects between both kinds of chips! IBIS models only make this worse. Don't get me wrong; I support the idea of IBIS models. But I do not have the means to use an IBIS model in a simulation; neither of the two SPICE programs I use, knows IBIS. If I use a newer IBIS-aware signal integrity simulator, it would not be able to accept at least one of the two types of SPICE models above; maybe even both. That is totally unacceptable to me. If the majority of my models are proprietary SPICE, and occasionally an IBIS model comes along, and since my environment is already set up for working with SPICE, I think I am better off (for now) staying with the SPICE environment. So considering those increasingly frequent cases where an IC vendor refuses to show us the SPICE model, it makes a heck of a lot of sense to translate their IBIS model into a SPICE-usable format. In fact, I might even expect such a model to be more accurate, if it is based on measured data. How often have you gotten a SPICE model that differed from the measured buffer strength by 300%, or where the SPICE model completely lacked clamp diodes that were there, or where all the diodes had zero resistance? If the IBIS model was created from measured data, then I should be in much better shape with it, or a SPICE behavioral model derived from it. > It seems that something will be lost in going from SPICE Model -> IBIS > -> SPICE model. My understanding is that (behavioral) IBIS models are > generally derived from (functional) SPICE models. Indeed, many are, but they shouldn't be. We should expect to get measured IBIS models for anything for which real silicon exists. IBIS models derived from SPICE should only be acceptable when the device is in development and hasn't been built yet. But, alas, IC vendors are too stupid or lazy to do this. > IBIS models and simulators are fine tuned to be faster and easier to use > for their intended purpose. This imposes limitations which are not > realized in the SPICE world (i.e. support for voltage controlled > multi-stage drivers and the examples you provided). It seems to me that > using a SPICE simulator with models derived from IBIS is taking on the > worst of both worlds: SPICE complexity and run times and IBIS model > limitations. What makes SPICE slow, are the SPICE models. Not the simulator per se. SPICE simulates what happens at every single internal node and device in the structural model, even if they have no effect on the I/O pin. IBIS models are faster because they skip all that and concentrate on just the I/O pin. SPICE can have behavioral models too, and they run extremely fast. Translating an IBIS model into a behavioral SPICE model should let it run just about as fast as using the IBIS model directly in an IBIS-aware environment. Regards, Andy From owner-ibis Mon Oct 27 08:47:44 1997 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA27469 for ; Mon, 27 Oct 1997 08:47:43 -0800 (PST) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id IAA00453 for ; Mon, 27 Oct 1997 08:41:29 -0800 Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (V2.0) id xma000436; Mon, 27 Oct 97 08:40:59 -0800 Received: from mailserver.tempe.vlsi.com (mailserver.tempe.vlsi.com [134.27.128.5]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/101195) with ESMTP id JAA27917 for ; Mon, 27 Oct 1997 09:40:57 -0700 Received: from tempe.vlsi.com ([134.27.133.12]) by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02) with ESMTP id AAA10239 for ; Mon, 27 Oct 1997 09:40:56 -0700 Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions) Message-ID: <3454C418.4C0A80BA@tempe.vlsi.com> Date: Mon, 27 Oct 1997 09:40:56 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ibis-users@vhdl.org Subject: Re: low budget IBIS tools References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit fabrizio zanella wrote: > > Andy, I agree 100% with your comments. IBIS models are a great idea, but > until an IBIS to SPICE converter is available to the general public, most > of us will not be able to use IBIS models. The availability of an IBIS to > SPICE converter will spread the use of IBIS models, which is what this > group's goal is. So either the major simulator companies or a university > group need to create such a tool. > The spice to IBIS converter is not a good idea if we are trying to create > better models that are based on measurements. Another aspect: as I observed some time ago, for those of us using SPICE sims to generate IBIS models an IBIS->SPICE translator would also allow us to QA the IBIS models by translation back with subsequent correlation. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Mon Oct 27 09:24:26 1997 Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA28080 for ; Mon, 27 Oct 1997 09:24:25 -0800 (PST) Received: from rabbit.tcs.teradyne.com (www.tcs.teradyne.com [131.101.144.22]) by steadfast.teradyne.com (8.7.1/8.7.1) with SMTP id MAA09861 for ; Mon, 27 Oct 1997 12:22:07 -0500 (EST) Received: from smtpgate.tcs.teradyne.com (tcsmail.tcs.teradyne.com) by rabbit.tcs.teradyne.com (4.1/SMI-4.1/TER-1.43/rabbit-1.7) id AA12120; Mon, 27 Oct 97 12:08:57 EST Message-Id: Date: 27 Oct 1997 12:11:46 -0400 From: "MARK GAILUS" Subject: Re: low budget IBIS tools To: ibis-users@vhdl.org X-Mailer: Mail*Link SMTP-QM 4.0.0 RE>>low budget IBIS tools 10/27/97 I agree with Fabrizio and Andy. A free spice2ibis tool does at least as much harm as good by facilitating a proliferation of IBIS models not derived from or correlated with measurements. A free ibis2spice tool, on the other hand, would do a great deal towards making IBIS the defacto format for providing I/O-level device models. It would also help overcome the difficulties sometimes encountered with respect to SPICE models supplied in incompatible SPICE dialects, and go a long way to convince "hardline" SPICE users (perhaps including myself) that properly constructed IBIS-format models can be more accurate for certain purposes than many of the available SPICE models. (It would be comforting to know that we could use the familiar and powerful SPICE syntax to modify or elaborate converted device or package models for any special needs that may arise in our application.) A good ibis2spice tool would also assist design/simulation teams who find it advisable to switch back and forth between narrower SPICE-level simulations and wider behavioral system-level simulations, by helping make sure that at least one parameter (the measurement-based buffer model) is held approximately constant. Regards -Mark Gailus Teradyne Connection Systems gailus.mark@teradyne.com From owner-ibis Mon Oct 27 11:15:31 1997 Received: from alabama.nwlink.com (alabama.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA00074 for ; Mon, 27 Oct 1997 11:15:30 -0800 (PST) Received: (from kellee@localhost) by alabama.nwlink.com (8.8.7/8.8.7) id LAA08743; Mon, 27 Oct 1997 11:13:37 -0800 (PST) Message-Id: <3.0.32.19971027111334.00767e8c@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 27 Oct 1997 11:13:40 -0800 To: ibis-users@vhdl.org From: Kellee Crisafulli Subject: IBIS to SPICE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi D.C., all D.C. wrote: >Another aspect: as I observed some time ago, for those of us using >SPICE sims to generate IBIS models an IBIS->SPICE translator would >also allow us to QA the IBIS models by translation back with >subsequent correlation. This would be a great improvement over not testing an IBIS model. I would hope there are not any companies out there that ship IBIS models without testing them in some way. If there are any IC companies doing this please contact me and I will do my best to help you get setup with a simulator. If you do use a SPICE to IBIS translator to check the IBIS model it may or may not prove out your model. It all depends on the quality of the IBIS translator. This is not a trival task. I am very concerned about a quick and dirty IBIS to SPICE translator that only works for a very limited set of cases. This could cause significant problems for users that then blame the IBIS model when the problem is the translator. IBIS is a very powerful standard but it does take a significant amount of work to do it right. Anyone that creates a translator in a few weeks has missed most of the really hard to find triva that is need to make things like LVDS or ECL or 2 stage outputs work correctly to mention just a few items. I still believe the best solution is to beat on the remaining SPICE companies that haven't added IBIS modeling. Why aren't more of their users demanding it be added to SPICE? It should be only slightly more difficult to add it to SPICE then to create a really good translator. This way you know the vendors will take over support of the simulation and make sure it works. With a translator created by someone and put in the public domain you mayl have no idea what it doesn't do correctly and no where to turn to get it fixed. ------------------------------------------------------------------------- Have a great day... Kellee Crisafulli at HyperLynx kellee@hyperlynx.com http://www.hyperlynx.com ------------------------------------------------------------------------- From owner-ibis Tue Oct 28 12:59:10 1997 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA27340 for ; Tue, 28 Oct 1997 12:59:09 -0800 (PST) Received: from fmmail.fm.intel.com (fmmail.fm.intel.com [198.175.75.69]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id MAA24106 for ; Tue, 28 Oct 1997 12:57:22 -0800 (PST) Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.8.5/8.7.3) id MAA29920 for ibis-users@vhdl.org; Tue, 28 Oct 1997 12:56:35 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 28 Oct 97 12:56:35 PST Date: Tue, 28 Oct 97 12:52:00 PST From: Arpad Muranyi Message-ID: To: ibis-users@vhdl.org Subject: IBIS models and i2spice Text item: All interested, I just came back from a week of vacation and read the EMAIL correspondence on the IBIS to SPICE conversion issues with great interest. I agree with the statement that there is a great need for IBIS support in the SPICE tools. Ideally, I would like to have a SPICE/behavioral combo tool that has the advantages and capabilities of both worlds. If needed, this tool could run transistor level SPICE models for detailed buffer design work, or higher level behavioral simulations for fast interconnect design work. Due to this double feature, this tool would also cover the situation when one has both types of models which need to be simulated together. Unfortunately, a standard would still be required for covering the various flavors and levels of transistor descriptions. I vould like to make a couple of comments on what I have read in the correspondence. 1) IBIS actually started on HSPICE when I wrote behavioral models (for internal use) using HSPICE. Just because a specific SPICE tool vendor does not support IBIS, it doesn't mean that the user cannot write behavioral models that use IBIS data. Bob Ross gave an excellent example for how to do this in one of the most recent replies to this subject. Most SPICE flavors have behavioral elements (controlled voltage and current sources) which can be used to create a behavioral model. However, the support from the SPICE tool vendor is still badly needed because of the problems that arise with the usage of these elements, such as non convergence, time step too small errors, etc... Specialized features (such as event triggered sources to detect a threshold crossing, for example) would significantly improve behavioral modeling. Of course, the ideal solution would be if the user would not have to develop the behavioral model at all, just plug in the IBIS data into something that the vendor provides. 2) Another reason I use IBIS models under a SPICE tool is actually something that I have not read in any of the replies. The problem I see with most (if not all) of the IBIS simulator tools is that they all lack substantial amounts of freedom. In my work I have to specify buffer characteristics as well as interconnect guidelines. For this I run sweep simulations on many of the buffer as well as interconnect parameters. I like to plot the simulation results in many different ways, such as flight time vs. buffer strength, amount of cross talk vs. signal pattern, etc... to make the data meaningful. Many tools don't have variable sweeping or scaling capabilities, scaling factors for altering the I-V curves of the IBIS models for sweeps, or arbitrary measurement definition capabilities, and have nothing but a voltage vs. time (waveform) plotting capability. Some tools provide some of these features, but in very primitive shape and form. Even though it is painful some times, I can do most of these tasks fairly well in HSPICE, but I could still use better features and support. To sum it up, IBIS tool vedors could eliminate part of the need for running IBIS simulations in SPICE tools by adding a bunch of much desired felixibility features to their tools which can only be done today in SPICE tools. These tools are only useful if they provide the necessary user interface, and automation features which are required for the work at hand and for being more productive. But I would still prefer a tool that can do both worlds together... Arpad Muranyi Intel Corporation ================================================================================ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-type: text/plain; charset=us-ascii MIME-Version: 1.0 X-Incognito-Version: 4.10.130 X-Incognito-SN: 1467 Subject: Re: low budget IBIS tools Errors-to: Reply-To: From: "fabrizio zanella" To: "'ibis-users@vhdl.org'" , X-Priority: 3 (Normal) Message-ID: Date: Fri, 24 Oct 97 9:51:21 -0400 Received: by fishbowl02.emc.com with VINES-ISMTP; Fri, 24 Oct 97 9:59:15 -0400 Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by em cmail.lss.emc.com (8.8.7/8.7.3) with SMTP id KAA06131 for ; Fri, 24 Oct 1997 10:04:52 -0400 (EDT) Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by serv er.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA12557 for ; Fri, 24 Oct 1997 07:01:24 -0700 (PDT) Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id HAA18933; Fri, 24 Oct 1997 07:19:25 -0700 (PDT) Received: from hebe.or.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0xOkbx-000qLxC; Fri, 24 Oct 97 07:21 PDT From owner-ibis Tue Oct 28 16:22:53 1997 Received: from ole.cdac.com (ole.cdac.com [199.5.216.26]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA00788 for ; Tue, 28 Oct 1997 16:22:50 -0800 (PST) Received: from ember.cdac.com (fwuser@cascade.cdac.com [199.5.216.206]) by ole.cdac.com (8.8.5/8.7.1) with ESMTP id QAA12054 for ; Tue, 28 Oct 1997 16:21:01 -0800 (PST) Received: from quark.cdac.com (quark.cdac.com [10.0.10.112]) by ember.cdac.com (8.7.1/8.7.1) with ESMTP id QAA07944 for ; Tue, 28 Oct 1997 16:20:59 -0800 (PST) From: Lynne Green Received: (from lgreen@localhost) by quark.cdac.com (8.7.1/8.7.1) id QAA01807 for ibis-users@vhdl.org; Tue, 28 Oct 1997 16:20:59 -0800 (PST) Date: Tue, 28 Oct 1997 16:20:59 -0800 (PST) Message-Id: <199710290020.QAA01807@quark.cdac.com> To: ibis-users@vhdl.org Subject: IBIS models and i2spice This has been an interesting thread to watch. Has anyone thought about using VHDL/AMS? This gives you digital (VHDL), analog/mixed signal (including SPICE), and annything else you can build a behavioral description for. Surely someone can build behavioral descriptions for "ibis" models, since that is what ibis is at heart. There are a few simulation vendors already ramping up for VHDL/AMS. Among others, Analogy (Saber, Mast, VHDL/AMS) and Mentor Graphics (Accusim, HDL-A, VHDL/AMS) come to mind. Unfortunately, few of the traditional SPICE vendors are jumping on this, since they seem to be waiting for customer demand (their claim) (which may well show in loss of market share to those who provide it - my personal guess). Lynne Green Cascade Design Automation ----- Begin Included Message ----- From owner-ibis@server.vhdl.org Tue Oct 28 14:48:56 1997 Date: Tue, 28 Oct 97 12:52:00 PST From: Arpad Muranyi To: ibis-users@vhdl.org Subject: IBIS models and i2spice Text item: All interested, I just came back from a week of vacation and read the EMAIL correspondence on the IBIS to SPICE conversion issues with great interest. I agree with the statement that there is a great need for IBIS support in the SPICE tools. Ideally, I would like to have a SPICE/behavioral combo tool that has the advantages and capabilities of both worlds. If needed, this tool could run transistor level SPICE models for detailed buffer design work, or higher level behavioral simulations for fast interconnect design work. Due to this double feature, this tool would also cover the situation when one has both types of models which need to be simulated together. Unfortunately, a standard would still be required for covering the various flavors and levels of transistor descriptions. I vould like to make a couple of comments on what I have read in the correspondence. 1) IBIS actually started on HSPICE when I wrote behavioral models (for internal use) using HSPICE. Just because a specific SPICE tool vendor does not support IBIS, it doesn't mean that the user cannot write behavioral models that use IBIS data. Bob Ross gave an excellent example for how to do this in one of the most recent replies to this subject. Most SPICE flavors have behavioral elements (controlled voltage and current sources) which can be used to create a behavioral model. However, the support from the SPICE tool vendor is still badly needed because of the problems that arise with the usage of these elements, such as non convergence, time step too small errors, etc... Specialized features (such as event triggered sources to detect a threshold crossing, for example) would significantly improve behavioral modeling. Of course, the ideal solution would be if the user would not have to develop the behavioral model at all, just plug in the IBIS data into something that the vendor provides. 2) Another reason I use IBIS models under a SPICE tool is actually something that I have not read in any of the replies. The problem I see with most (if not all) of the IBIS simulator tools is that they all lack substantial amounts of freedom. In my work I have to specify buffer characteristics as well as interconnect guidelines. For this I run sweep simulations on many of the buffer as well as interconnect parameters. I like to plot the simulation results in many different ways, such as flight time vs. buffer strength, amount of cross talk vs. signal pattern, etc... to make the data meaningful. Many tools don't have variable sweeping or scaling capabilities, scaling factors for altering the I-V curves of the IBIS models for sweeps, or arbitrary measurement definition capabilities, and have nothing but a voltage vs. time (waveform) plotting capability. Some tools provide some of these features, but in very primitive shape and form. Even though it is painful some times, I can do most of these tasks fairly well in HSPICE, but I could still use better features and support. To sum it up, IBIS tool vedors could eliminate part of the need for running IBIS simulations in SPICE tools by adding a bunch of much desired felixibility features to their tools which can only be done today in SPICE tools. These tools are only useful if they provide the necessary user interface, and automation features which are required for the work at hand and for being more productive. But I would still prefer a tool that can do both worlds together... Arpad Muranyi Intel Corporation ================================================================================ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-type: text/plain; charset=us-ascii MIME-Version: 1.0 X-Incognito-Version: 4.10.130 X-Incognito-SN: 1467 Subject: Re: low budget IBIS tools Errors-to: Reply-To: From: "fabrizio zanella" To: "'ibis-users@vhdl.org'" , X-Priority: 3 (Normal) Message-ID: Date: Fri, 24 Oct 97 9:51:21 -0400 Received: by fishbowl02.emc.com with VINES-ISMTP; Fri, 24 Oct 97 9:59:15 -0400 Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by em cmail.lss.emc.com (8.8.7/8.7.3) with SMTP id KAA06131 for ; Fri, 24 Oct 1997 10:04:52 -0400 (EDT) Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by serv er.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA12557 for ; Fri, 24 Oct 1997 07:01:24 -0700 (PDT) Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id HAA18933; Fri, 24 Oct 1997 07:19:25 -0700 (PDT) Received: from hebe.or.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0xOkbx-000qLxC; Fri, 24 Oct 97 07:21 PDT ----- End Included Message ----- From owner-ibis Tue Oct 28 16:45:17 1997 Received: from netcomsv.netcom.com (uucp14.netcom.com [163.179.3.18]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA01331 for ; Tue, 28 Oct 1997 16:45:16 -0800 (PST) Received: (from uucp@localhost) by netcomsv.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.01)) id QAA21839; Tue, 28 Oct 1997 16:43:28 -0800 (PST) >Received: from contec12.apsimtech.COM by apsimtech.COM (4.1/SMI-4.1) id AA05476; Tue, 28 Oct 97 15:47:45 PST Received: from contec by netcomsv.netcom.com; Tue, 28 Oct 1997 16:43 PST Received: from contec12.apsimtech.COM by apsimtech.COM (4.1/SMI-4.1) id AA05476; Tue, 28 Oct 97 15:47:45 PST Received: from contec12 (localhost) by contec12.apsimtech.COM (5.0/SMI-SVR4) id AA10843; Tue, 28 Oct 1997 15:48:19 +0800 Sender: fred@apsimtech.com Message-Id: <345679C3.529B@apsimtech.com> Date: Tue, 28 Oct 1997 15:48:19 -0800 From: Fred Balistreri Organization: Apsim X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.3 sun4c) Mime-Version: 1.0 To: Arpad Muranyi Cc: ibis-users@vhdl.org Subject: Re: IBIS models and i2spice References: Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Arpad Muranyi wrote: > > Text item: > > All interested, > > I just came back from a week of vacation and read the EMAIL correspondence on > the IBIS to SPICE conversion issues with great interest. I agree with the > statement that there is a great need for IBIS support in the SPICE tools. > Ideally, I would like to have a SPICE/behavioral combo tool that has the > advantages and capabilities of both worlds. If needed, this tool could run > transistor level SPICE models for detailed buffer design work, or higher level > behavioral simulations for fast interconnect design work. Due to this double > feature, this tool would also cover the situation when one has both types of > models which need to be simulated together. Unfortunately, a standard would > still be required for covering the various flavors and levels of transistor > descriptions. > > I vould like to make a couple of comments on what I have read in the > correspondence. > > 1) IBIS actually started on HSPICE when I wrote behavioral models (for internal > use) using HSPICE. Just because a specific SPICE tool vendor does not support > IBIS, it doesn't mean that the user cannot write behavioral models that use IBIS > data. Bob Ross gave an excellent example for how to do this in one of the most > recent replies to this subject. Most SPICE flavors have behavioral elements > (controlled voltage and current sources) which can be used to create a > behavioral model. However, the support from the SPICE tool vendor is still > badly needed because of the problems that arise with the usage of these > elements, such as non convergence, time step too small errors, etc... > Specialized features (such as event triggered sources to detect a threshold > crossing, for example) would significantly improve behavioral modeling. Of > course, the ideal solution would be if the user would not have to develop the > behavioral model at all, just plug in the IBIS data into something that the > vendor provides. > > 2) Another reason I use IBIS models under a SPICE tool is actually something > that I have not read in any of the replies. The problem I see with most (if not > all) of the IBIS simulator tools is that they all lack substantial amounts of > freedom. In my work I have to specify buffer characteristics as well as > interconnect guidelines. For this I run sweep simulations on many of the buffer > as well as interconnect parameters. I like to plot the simulation results in > many different ways, such as flight time vs. buffer strength, amount of cross > talk vs. signal pattern, etc... to make the data meaningful. Many tools don't > have variable sweeping or scaling capabilities, scaling factors for altering the > I-V curves of the IBIS models for sweeps, or arbitrary measurement definition > capabilities, and have nothing but a voltage vs. time (waveform) plotting > capability. Some tools provide some of these features, but in very primitive > shape and form. Even though it is painful some times, I can do most of these > tasks fairly well in HSPICE, but I could still use better features and support. > > To sum it up, IBIS tool vedors could eliminate part of the need for running IBIS > simulations in SPICE tools by adding a bunch of much desired felixibility > features to their tools which can only be done today in SPICE tools. These > tools are only useful if they provide the necessary user interface, and > automation features which are required for the work at hand and for being more > productive. But I would still prefer a tool that can do both worlds together... > > Arpad Muranyi > Intel Corporation > ================================================================================ > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > Content-type: text/plain; charset=us-ascii > MIME-Version: 1.0 > X-Incognito-Version: 4.10.130 > X-Incognito-SN: 1467 > Subject: Re: low budget IBIS tools > Errors-to: > Reply-To: > From: "fabrizio zanella" > To: "'ibis-users@vhdl.org'" , > > X-Priority: 3 (Normal) > Message-ID: > Date: Fri, 24 Oct 97 9:51:21 -0400 > Received: by fishbowl02.emc.com with VINES-ISMTP; Fri, 24 Oct 97 9:59:15 -0400 > Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by em > cmail.lss.emc.com (8.8.7/8.7.3) with SMTP id KAA06131 for ; > Fri, 24 Oct 1997 10:04:52 -0400 (EDT) > Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by serv > er.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA12557 for ; Fri, > 24 Oct 1997 07:01:24 -0700 (PDT) > Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) > by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id HAA18933; > Fri, 24 Oct 1997 07:19:25 -0700 (PDT) > Received: from hebe.or.intel.com by relay.hf.intel.com with smtp > (Smail3.1.28.1 #2) id m0xOkbx-000qLxC; Fri, 24 Oct 97 07:21 PDT We have looked into the enemy's face and the enemy is us. Such tools alredy exist. The user community needs to look at the various SI companies and solutions carefully! We are just one of several SI spice based tools that have had IBIS models working together with Spice transistors and coupled lossy transmission lines since 1991! WAKE UP! Where have you guys been! We attend the various converences and marketing shows for a REASON. In our particular case interfaces exist into the most popular CAD products. These type of products have been put to good use for quite some time by hundreds of companies! -- Fred Balistreri fred@apsimtech.com 408-434-0967 ext. 102 From owner-ibis Wed Oct 29 10:16:22 1997 Received: from atlantis.erlm.siemens.de (atlantis.erlm.siemens.de [194.174.230.11]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA20366 for ; Wed, 29 Oct 1997 10:16:21 -0800 (PST) Received: from tcenter.erlm.siemens.de (tcenter-ext.erlm.siemens.de [193.98.99.20]) by atlantis.erlm.siemens.de (8.7.5/8.7.3) with ESMTP id TAA25334 for ; Wed, 29 Oct 1997 19:15:45 +0100 (MET) Received: from pgtd0131 (pgtd0131.a45am.erlm.siemens.de [139.25.106.124]) by tcenter.erlm.siemens.de (8.7.5/8.7.3) with SMTP id TAA11368 for ; Wed, 29 Oct 1997 19:11:17 +0100 (MET) Received: by pgtd0131 with Microsoft Mail id <01BCE49F.094856C0@pgtd0131>; Wed, 29 Oct 1997 19:15:36 +-100 Message-ID: <01BCE49F.094856C0@pgtd0131> From: Unger Bernhard To: "'ibis-users'" Subject: Electrical Board description Date: Wed, 29 Oct 1997 19:15:30 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.vhdl.org id KAA20371 attempting to understand the new IBIS 3.0 feature "Electrical Board Description" I have some questions: 1. Is there any example for a .edb file available for instance for a SIMM module? 2. Path description in case of a second forc in one branche of the first forc? Example: Pin J25 Node u1 ______________0__________________0 Pin A1 0_________| Len=1 | Len=2 Len=0.5 | |__________________0 Pin A2 | Len=2.2 |_________________________________ 0 Pin A3 Len=4 Is the following description correct for this path? [Path Description] PathJ25Ax Pin J25 Len = 0.5 L = 6.0n C=2.0p / Fork Len = 1 L = 6.0n C=2.0p / Node u1 Fork Len = 2 L = 6.0n C=2.0p / Pin A1 Endfork Len = 2.2 L = 6.0n C=2.0p / Pin A2 Endfork Len = 4 L = 6.0n C=2.0p / Pin A3 3. Can a path with a series resistance be described as follows? Pin J25 Rs=22Ohms ________ 0_________| |________________0 Pin A1 Len=0.5 |_______| Len=1 [Path Description] PathJ25A1 Pin J25 Len = 0.5 L = 6.0n C=2.0p / Len = 0 R=22 / Len = 1 L = 6.0n C=2.0p / Pin A1 4. Are there any tools today, which can handle .ebd files? Thanks Bernhard Unger ************************************************************************************ # Dr. Bernhard Unger # Siemens AG # Dept. ANL A45 AM # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 # D-81730 Munich Fax. +49-89-636-44595 # Germany E-Mail Bernhard.Unger@erlm.siemens.de ************************************************************************************ From owner-ibis Wed Oct 29 15:41:23 1997 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA26118 for ; Wed, 29 Oct 1997 15:40:42 -0800 (PST) Received: from hpbs2933.boi.hp.com (pgregory@hpbs2933.boi.hp.com [15.8.28.3]) by palrel3.hp.com (8.8.5/8.8.5tis) with SMTP id PAA06112 for ; Wed, 29 Oct 1997 15:38:54 -0800 (PST) Received: by hpbs2933.boi.hp.com (1.38.193.4/15.5+IOS 3.22) id AA25631; Wed, 29 Oct 1997 16:36:26 -0700 From: Paul Gregory Message-Id: <9710292336.AA25631@hpbs2933.boi.hp.com> Subject: Driver Output Impedance Calculation To: ibis-users@vhdl.org Date: Wed, 29 Oct 97 16:36:26 MST Mailer: Elm [revision: 70.85] Hello ibis users, I need some help in understanding how to determine output impedance. Given the ibis model data that follows, how does one determine the output impedance of this driver for both the pullup and pulldown side of the driver. Thanks for your help. -- Paul Gregory |************************************************************ [Model] driver Model_type I/O Vinl = 0.66V Vinh = 2.31V C_comp 4.00pF 4.00pF 4.00pF | (typ) (min) (max) [Temperature Range] 25.00 125.00 0.00 [Voltage Range] 3.30 3.00 3.6 [GND_clamp] | I(typ) I(min) I(max) -0.7 -3.7 NA NA -0.6 -111.0m NA NA -0.5 -5.5m NA NA -0.4 -131.0u NA NA -0.3 -2.3u NA NA -0.2 -60.0n NA NA -0.1 -1.1n NA NA 0.0 -188.0p NA NA 0.1 -131.0p NA NA 0.2 -101.0p NA NA 0.3 -70.0p NA NA 0.4 -40.0p NA NA 0.5 -10.0p NA NA 0.6 19.0p NA NA 0.7 49.0p NA NA 0.8 79.0p NA NA 0.9 110.0p NA NA 1.0 140.0p NA NA 1.1 170.0p NA NA 1.2 200.0p NA NA 1.3 231.0p NA NA 1.4 261.0p NA NA 1.5 291.0p NA NA 1.6 321.0p NA NA 1.7 352.0p NA NA 1.8 382.0p NA NA 1.9 412.0p NA NA 2.0 443.0p NA NA 2.1 473.0p NA NA 2.2 503.0p NA NA 2.3 534.0p NA NA 2.4 564.0p NA NA 2.5 595.0p NA NA 2.6 625.0p NA NA 2.7 656.0p NA NA 2.8 686.0p NA NA 2.9 716.0p NA NA 3.0 747.0p NA NA 3.1 778.0p NA NA 3.2 808.0p NA NA 3.3 839.0p NA NA [POWER_clamp] | I(typ) I(min) I(max) 3.3 -46.0u NA NA 3.2 -46.0u NA NA 3.1 -45.0u NA NA 3.0 -45.0u NA NA 2.9 -45.0u NA NA 2.8 -45.0u NA NA 2.7 -45.0u NA NA 2.6 -45.0u NA NA 2.5 -45.0u NA NA 2.4 -44.0u NA NA 2.3 -44.0u NA NA 2.2 -44.0u NA NA 2.1 -44.0u NA NA 2.0 -44.0u NA NA 1.9 -43.0u NA NA 1.8 -43.0u NA NA 1.7 -42.0u NA NA 1.6 -41.0u NA NA 1.5 -40.0u NA NA 1.4 -39.0u NA NA 1.3 -37.0u NA NA 1.2 -35.0u NA NA 1.1 -33.0u NA NA 1.0 -31.0u NA NA 0.9 -29.0u NA NA 0.8 -26.0u NA NA 0.7 -24.0u NA NA 0.6 -21.0u NA NA 0.5 -18.0u NA NA 0.4 -14.0u NA NA 0.3 -11.0u NA NA 0.2 -7.0u NA NA 0.1 -3.0u NA NA 0.0 839.0p NA NA -0.1 4.0u NA NA -0.2 8.0u NA NA -0.3 12.0u NA NA -0.4 17.0u NA NA -0.5 22.0u NA NA -0.6 32.0u NA NA -0.7 260.0u NA NA -0.8 7.0m NA NA -0.9 166.0m NA NA -1.0 6.0 NA NA -1.1 269.0 NA NA -1.2 11.0k NA NA -1.3 513.0k NA NA -1.4 22.0M NA NA -1.5 995.0M NA NA -1.6 44.0G NA NA -1.7 1.0T NA NA -1.8 88.0T NA NA -1.9 3.0e+15 NA NA -2.0 1.0e+17 NA NA -2.1 8.0e+18 NA NA -2.2 3.0e+20 NA NA -2.3 1.0e+22 NA NA -2.4 7.0e+23 NA NA -2.5 3.0e+25 NA NA -2.6 1.0e+27 NA NA -2.7 8.0e+28 NA NA -2.8 3.0e+30 NA NA -2.9 1.0e+32 NA NA -3.0 8.0e+33 NA NA -3.1 4.0e+35 NA NA -3.2 1.0e+37 NA NA -3.3 9.0e+38 NA NA [Pullup] | I(typ) I(min) I(max) 6.6 -63.0m NA NA 3.4 -54.0m NA NA 3.3 -54.0m NA NA 3.2 -53.0m NA NA 3.1 -53.0m NA NA 3.0 -53.0m NA NA 2.9 -52.0m NA NA 2.8 -52.0m NA NA 2.7 -52.0m NA NA 2.6 -51.0m NA NA 2.5 -51.0m NA NA 2.4 -50.0m NA NA 2.3 -50.0m NA NA 2.2 -50.0m NA NA 2.1 -49.0m NA NA 2.0 -49.0m NA NA 1.9 -48.0m NA NA 1.8 -47.0m NA NA 1.7 -46.0m NA NA 1.6 -44.0m NA NA 1.5 -43.0m NA NA 1.4 -41.0m NA NA 1.3 -39.0m NA NA 1.2 -37.0m NA NA 1.1 -34.0m NA NA 1.0 -32.0m NA NA 0.9 -29.0m NA NA 0.8 -26.0m NA NA 0.7 -24.0m NA NA 0.6 -21.0m NA NA 0.5 -17.0m NA NA 0.4 -14.0m NA NA 0.3 -11.0m NA NA 0.2 -7.0m NA NA 0.1 -3.0m NA NA 0.0 -45.0p NA NA -0.1 3.0m NA NA -3.3 128.0m NA NA [Pulldown] | I(typ) I(min) I(max) -3.3 -138.0m NA NA -0.1 -4.0m NA NA 0.0 18.0p NA NA 0.1 4.0m NA NA 0.2 8.0m NA NA 0.3 11.0m NA NA 0.4 15.0m NA NA 0.5 18.0m NA NA 0.6 21.0m NA NA 0.7 24.0m NA NA 0.8 27.0m NA NA 0.9 29.0m NA NA 1.0 31.0m NA NA 1.1 33.0m NA NA 1.2 34.0m NA NA 1.3 36.0m NA NA 1.4 36.0m NA NA 1.5 37.0m NA NA 1.6 38.0m NA NA 1.7 38.0m NA NA 1.8 39.0m NA NA 1.9 39.0m NA NA 2.0 39.0m NA NA 2.1 39.0m NA NA 2.2 40.0m NA NA 2.3 40.0m NA NA 2.4 40.0m NA NA 2.5 40.0m NA NA 2.6 40.0m NA NA 2.7 40.0m NA NA 2.8 40.0m NA NA 2.9 40.0m NA NA 3.0 40.0m NA NA 3.1 41.0m NA NA 3.2 41.0m NA NA 3.3 41.0m NA NA 3.4 41.0m NA NA 6.6 42.0m NA NA [Ramp] | typ min max dV/dt_r 1.205/5.64e-10 NA NA dV/dt_f 1.139/1.436e-09 NA NA From owner-ibis Thu Oct 30 00:53:19 1997 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id AAA05287 for ; Thu, 30 Oct 1997 00:53:19 -0800 (PST) From: JEAN-CHRISTOPHE_PAUTRAT@HP-France-om5.om.hp.com Received: from rossini.grenoble.hp.com (rossini.grenoble.hp.com [15.128.127.193]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id AAA03929 for ; Thu, 30 Oct 1997 00:51:30 -0800 (PST) Received: from localhost (root@localhost) by rossini.grenoble.hp.com with SMTP (8.7.6/8.7.3 TIS Messaging 5.0 Openmail) id JAA04930; Thu, 30 Oct 1997 09:51:25 +0100 (MET) X-OpenMail-Hops: 1 Date: Thu, 30 Oct 97 09:51:17 +0100 Message-Id: In-Reply-To: <01BCE49F.094856C0@pgtd0131> Subject: Re: Electrical Board description MIME-Version: 1.0 TO: Bernhard.Unger@erlm.siemens.de CC: ibis-users@vhdl.org Content-Type: text/plain; charset=US-ASCII; name="Electrical" Content-Disposition: inline; filename="Electrical" Content-Transfer-Encoding: 7bit Hi Bernhard, 1: no that I am aware of, but I'd be interested if someone has one 2: seems good to me 3: I'm not sure of the syntax with the series resistor (not enough familiar with the new 3.0 spec) 4: in fact this description is very close (should I say *is exactly*) to the quad standard. quad does not support yet ibis 3.0 translation because of the parser not yet available, but I guess with a minimum set of efforts, they will support edb, since in fact, ..., it's already built in ! I don't know of other tools reading edbs. Jean-Christophe PAUTRAT, R&D Engineer, Design Engineering Commercial Desktop Computer Division, H E W L E T T - P A C K A R D. ______________________________ Reply Separator _________________________________ Subject: Electrical Board description Author: Non-HP-Bernhard.Unger (Bernhard.Unger@erlm.siemens.de) at HP-France,mimegw6 Date: 29-10-97 7:15 PM attempting to understand the new IBIS 3.0 feature "Electrical Board Description" I have some questions: 1. Is there any example for a .edb file available for instance for a SIMM module ? 2. Path description in case of a second forc in one branche of the first forc? Example: Pin J25 Node u1 ______________0__________________0 Pin A1 0_________| Len=1 | Len=2 Len=0.5 | |__________________0 Pin A2 | Len=2.2 |_________________________________ 0 Pin A3 Len=4 Is the following description correct for this path? [Path Description] PathJ25Ax Pin J25 Len = 0.5 L = 6.0n C=2.0p / Fork Len = 1 L = 6.0n C=2.0p / Node u1 Fork Len = 2 L = 6.0n C=2.0p / Pin A1 Endfork Len = 2.2 L = 6.0n C=2.0p / Pin A2 Endfork Len = 4 L = 6.0n C=2.0p / Pin A3 3. Can a path with a series resistance be described as follows? Pin J25 Rs=22Ohms ________ 0_________| |________________0 Pin A1 Len=0.5 |_______| Len=1 [Path Description] PathJ25A1 Pin J25 Len = 0.5 L = 6.0n C=2.0p / Len = 0 R=22 / Len = 1 L = 6.0n C=2.0p / Pin A1 4. Are there any tools today, which can handle .ebd files? Thanks Bernhard Unger ******************************************************************************** **** # Dr. Bernhard Unger # Siemens AG # Dept. ANL A45 AM # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 # D-81730 Munich Fax. +49-89-636-44595 # Germany E-Mail Bernhard.Unger@erlm.siemens.de ******************************************************************************** **** From owner-ibis Thu Oct 30 06:40:16 1997 Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA11385 for ; Thu, 30 Oct 1997 06:40:15 -0800 (PST) Received: from sky.com by relay7.UU.NET with SMTP (peer crosschecked as: sky.SKY.COM [198.4.246.2]) id QQdnmw03840; Thu, 30 Oct 1997 09:37:58 -0500 (EST) Received: from nin.sky.com by sky.com (SMI-8.6/SMI-SVR4) id JAA03403; Thu, 30 Oct 1997 09:33:28 -0500 Received: from nin (localhost) by nin.sky.com (4.1/SMI-4.1) id AA08060; Thu, 30 Oct 97 09:38:36 EST Sender: taddonio@sky.com Message-Id: <34589BEB.41C67EA6@sky.com> Date: Thu, 30 Oct 1997 09:38:35 -0500 From: Paul Taddonio X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: Paul Gregory Cc: ibis-users@vhdl.org Subject: Re: Driver Output Impedance Calculation References: <9710292336.AA25631@hpbs2933.boi.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Gregory wrote: > > Hello ibis users, > > I need some help in understanding how to determine output > impedance. > > Given the ibis model data that follows, how does one determine > the output impedance of this driver for both the pullup and > pulldown side of the driver. > > Thanks for your help. > > -- Paul Gregory > For a first order approximation, I would do the following: ignore the clamp diodes, look at the pulldown curve data, pick 5 voltage points within the voltage swing of the signal, apply Ohms law to calculate the impedance, then average the values. do the same for the pullup curve but remember that the voltage is relative to ground so you need to subtract from VCC to determine the voltage across the pullup. -- N. Paul Taddonio phone: 508-250-1920 x245 fax: 508-250-0036 SKY Computers, Inc. 27 Industrial Ave. Chelmsford, MA 01824 Web: http://www.sky.com From owner-ibis Thu Oct 30 08:42:49 1997 Received: from ganymede.or.intel.com (root@ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA13617 for ; Thu, 30 Oct 1997 08:42:48 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id IAA07464 for ; Thu, 30 Oct 1997 08:49:52 -0800 (PST) Received: from mh-relay by ichips.intel.com (8.7.4/jIIIa) id IAA24863; Thu, 30 Oct 1997 08:40:52 -0800 (PST) Message-Id: <199710301640.IAA24863@ichips.intel.com> To: ibis-users@vhdl.org Subject: Electrical Board description Date: Thu, 30 Oct 1997 08:40:52 -0800 From: Stephen Peters Hello Bernhard: In answer to your questions.... 1. No, I don't know of any exsisting SIMM module descriptions. 2. You description of a path with multipule forks is corrent. In general, the fork and endfork statements can be nested (as you have shown). 3. No, I don't know of any currently available tools that will accept an .edb file. However, with the passage of IBIS 3.0 I would expect that CAE vendors are working on it. Regards, Stephen Peters Intel Corp. ======================================================= on Wed, 29 Oct 1997 19:15:30 Bernhard Unger wrote: attempting to understand the new IBIS 3.0 feature "Electrical Board = Description"=20 I have some questions: 1. Is there any example for a .edb file available for instance for a = SIMM module? 2. Path description in case of a second forc in one branche of the first = forc? Example: Pin J25 Node u1 ______________0__________________0 Pin A1 0_________| Len=3D1 | Len=3D2 Len=3D0.5 | |__________________0 Pin A2 | Len=3D2.2 |_________________________________ 0 Pin A3 Len=3D4 Is the following description correct for this path? [Path Description] PathJ25Ax Pin J25 Len =3D 0.5 L =3D 6.0n C=3D2.0p / Fork Len =3D 1 L =3D 6.0n C=3D2.0p / Node u1 Fork Len =3D 2 L =3D 6.0n C=3D2.0p / Pin A1 Endfork Len =3D 2.2 L =3D 6.0n C=3D2.0p / Pin A2 Endfork Len =3D 4 L =3D 6.0n C=3D2.0p / Pin A3 3. Can a path with a series resistance be described as follows? Pin J25 Rs=3D22Ohms ________ 0_________| |________________0 Pin A1 Len=3D0.5 |_______| Len=3D1 [Path Description] PathJ25A1 Pin J25 Len =3D 0.5 L =3D 6.0n C=3D2.0p / Len =3D 0 R=3D22 / Len =3D 1 L =3D 6.0n C=3D2.0p / Pin A1 4. Are there any tools today, which can handle .ebd files? Thanks Bernhard Unger *************************************************************************= *********** # Dr. Bernhard Unger = =20 # Siemens AG = =20 # Dept. ANL A45 AM = =20 # Otto-Hahn-Ring 6 Tel. +49-89-636-47404 = =20 # D-81730 Munich Fax. +49-89-636-44595 = =20 # Germany E-Mail = Bernhard.Unger@erlm.siemens.de = =20 *************************************************************************= *********** From owner-ibis Thu Oct 30 09:15:25 1997 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA14188 for ; Thu, 30 Oct 1997 09:15:24 -0800 (PST) Received: from us8rmc.bb.dec.com (us8rmc.bb.dec.com [16.53.0.44]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA22851; Thu, 30 Oct 1997 11:12:47 -0500 (EST) Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97) id AA29207; Thu, 30 Oct 97 11:07:48 -0500 Message-Id: <9710301607.AA29207@us8rmc.bb.dec.com> Received: from wrksys.enet; by us8rmc.enet; Thu, 30 Oct 97 11:12:20 EST Date: Thu, 30 Oct 97 11:12:20 EST From: Andrew Ingraham To: pgregory@hpbs2933.boi.hp.com Cc: ibis-users@vhdl.org, ingraham@wrksys.ENET.dec.com Apparently-To: ibis-users@vhdl.org, pgregory@hpbs2933.boi.hp.com Subject: Re: Driver Output Impedance Calculation > Given the ibis model data that follows, how does one determine > the output impedance of this driver for both the pullup and > pulldown side of the driver. Output impedance tends to be nonlinear, but the small-signal, low frequency impedances are easy to estimate. Just look at the slopes of the Pulldown and Pullup curves where they intersect 0V. > [Pullup] > | I(typ) I(min) I(max) ... > 0.2 -7.0m NA NA > 0.1 -3.0m NA NA > 0.0 -45.0p NA NA > -0.1 3.0m NA NA 0.1V/3.0mA = 33 ohms for the pullup, immediately around VDD. > [Pulldown] > | I(typ) I(min) I(max) ... > -0.1 -4.0m NA NA > 0.0 18.0p NA NA > 0.1 4.0m NA NA > 0.2 8.0m NA NA > 0.3 11.0m NA NA > 0.4 15.0m NA NA 0.1V/4.0mA = 25 ohms for the pulldown, immediately around GND. Use a bigger delta-V for more accuracy; it looks like the current resolution (accuracy) in your tabulated data is 1.0mA. Regards, Andy Ingraham