From owner-ibis Mon Nov 2 09:00:42 1998 Received: from calmicro.com (zeus.calmicro.com [207.124.218.194]) by server.eda.org (8.8.5/8.8.3) with SMTP id JAA27298 for ; Mon, 2 Nov 1998 09:00:41 -0800 (PST) Received: from Calmicro-Message_Server by calmicro.com with Novell_GroupWise; Mon, 02 Nov 1998 08:56:40 -0800 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 02 Nov 1998 08:56:13 -0800 From: "Thang Tu" To: ibis-users@eda.org Subject: SPICE to IBIS Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id JAA27299 I have downloaded the SPICE-to-IBIS conversion files s2ibis2.tar.Z , ans2ibis2_fix.tar.Z from the website and tried to unzip the files, however it is giving me the following message... "The archive does not contain complete filename information, so WinZip cannot determine the full filename of the compressed file. Replace all or some of the suggested filename with the corrected name and press OK." Can you please tell me what the complete filename information is? Thank you. Thang Tu Applications Engineer California Micro Devices 215 Topaz Street Milpitas, CA USA 95035-5430 Ph: 800-325-4966 Direct: 408-934-3126 Fax: 408-263-7846 E-mail: thangt@calmicro.com Web Site: http://www.calmicro.com From owner-ibis Mon Nov 2 09:19:16 1998 Received: from calmicro.com (zeus.calmicro.com [207.124.218.194]) by server.eda.org (8.8.5/8.8.3) with SMTP id JAA27416 for ; Mon, 2 Nov 1998 09:19:15 -0800 (PST) Received: from Calmicro-Message_Server by calmicro.com with Novell_GroupWise; Mon, 02 Nov 1998 09:15:10 -0800 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 02 Nov 1998 09:14:57 -0800 From: "Thang Tu" To: ibis-users@eda.org Subject: IBIS Convert Files Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id JAA27417 I seem to be having a problem unzipping the following files: s2ibis2_tar.z and s2ibis2_fix_tar.z . What does the .z extension mean? Is it suppose to have a ".zip" extension? Can you please kindly provide me with some assistance. Thang Tu Applications Engineer California Micro Devices 215 Topaz Street Milpitas, CA USA 95035-5430 Ph: 800-325-4966 Direct: 408-934-3126 Fax: 408-263-7846 E-mail: thangt@calmicro.com Web Site: http://www.calmicro.com From owner-ibis Mon Nov 2 09:20:08 1998 Received: from calmicro.com (zeus.calmicro.com [207.124.218.194]) by server.eda.org (8.8.5/8.8.3) with SMTP id JAA27421 for ; Mon, 2 Nov 1998 09:20:06 -0800 (PST) Received: from Calmicro-Message_Server by calmicro.com with Novell_GroupWise; Mon, 02 Nov 1998 09:16:10 -0800 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 02 Nov 1998 09:15:54 -0800 From: "Thang Tu" To: ibis-users@eda.org Subject: SPICE to IBIS Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id JAA27422 I have downloaded the SPICE-to-IBIS conversion files s2ibis2.tar.Z , ans2ibis2_fix.tar.Z from the website and tried to unzip the files, however it is giving me the following message... "The archive does not contain complete filename information, so WinZip cannot determine the full filename of the compressed file. Replace all or some of the suggested filename with the corrected name and press OK." Can you please tell me what the complete filename information is? Thank you. Thang Tu Applications Engineer California Micro Devices 215 Topaz Street Milpitas, CA USA 95035-5430 Ph: 800-325-4966 Direct: 408-934-3126 Fax: 408-263-7846 E-mail: thangt@calmicro.com Web Site: http://www.calmicro.com From owner-ibis Mon Nov 2 09:46:43 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA27489 for ; Mon, 2 Nov 1998 09:46:39 -0800 (PST) Received: from tensor ([192.168.148.75]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id JAA18073; Mon, 2 Nov 1998 09:42:06 -0800 Message-Id: <3.0.5.32.19981102094215.014c2160@mail.nwlink.com> X-Sender: mbflora@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 02 Nov 1998 09:42:15 -0100 To: "Thang Tu" , ibis-users@eda.org From: Matthew Flora Subject: Re: SPICE to IBIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear Thang Tu, >I have downloaded the SPICE-to-IBIS conversion files s2ibis2.tar.Z , >ans2ibis2_fix.tar.Z from the website and tried >to unzip the files, however it is giving me the following message... > >"The archive does not contain complete filename information, so WinZip cannot >determine the full filename of the compressed file. Replace all or some of >the suggested filename with the corrected name and press OK." When I downloaded s2ibis2.tar.Z and s2ibis2_fix.tar.Z from , MS Internet Explorer 4.0 changed the names to s2ibis2_tar.Z and s2ibis2_fix_tar.Z, respectively (it replaced the first dot in each name with an underscore). Without the dot before the "tar", WinZIP is unaware that the files are compressed tar files. I found that by simply renaming the files back to their original names, WinZIP was able to decompress them correctly. Regards, Matthew Flora IBIS Open Forum Secretary (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA From owner-ibis Mon Nov 2 15:25:32 1998 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA28348; Mon, 2 Nov 1998 15:25:32 -0800 (PST) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA69732; Mon, 2 Nov 1998 18:03:10 -0500 Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id SAA09762; Mon, 2 Nov 1998 18:16:47 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU036 id 5010400028512960; Mon, 2 Nov 1998 18:26:11 -0500 From: Gregory R Edlund To: Cc: Subject: PCB East IBIS Summit - comments on Accuracy Message-ID: <5010400028512960000002L002*@MHS> Date: Mon, 2 Nov 1998 18:26:11 -0500 MIME-Version: 1.0 Content-Type: text/plain On behalf of the IBIS Accuracy Subcommittee and the IBIS User's Group, I want to thank everyone who attended the PCB East IBIS Summit. Thanks also to the folks at NESA for making the arrangements and to Applied Simulation Technology, Cadence, Compaq, EMC, Focus Technology, Hyperlynx, NESA, and Viewlogic for sponsoring the event. The IBIS Accuracy Subcommittee especially appreciated the feedback we got from attendees. Yes, there are differences of opinion about what accuracy means and about implementation during modeling and simulation. However, I firmly believe that the collective wisdom represented by the IBIS Committee is a tool that we can use to craft a solid, useful document for communicating accuracy data to the user. Perhaps we need to make the idea of "communicating accuracy data" more clear in the future. Just like an IBIS data sheet is not a model but a format for communicating model data, the IBIS Accuracy Specification is not a certification of model accuracy. Rather, it is a means for communicating model correlation data to the end user. To make sure we carefully consider the input you give us, the IBIS Accuracy Subcommittee will be keeping a running record of feedback we have received from various parties and what action we have taken on this feedback. We will periodically post this list to the reflector, perhaps as part of our minutes. Once again, if you have an opinion about something in the rough draft, please voice it to anyone on the subcommittee or the reflector. If you wish to remain anonymous, we will respect your wishes. The IBIS Accuracy Subcommittee has a lot of work to do before DesignCon99. We have a paper and demo to prepare, we are making the test board ready for public consumption, and the IBIS Accuracy Specification will go through another revision cycle. We hope to meet many of you again at the DesignCon99 Summit with a more refined specification. p.s. We will be posting the IBIS Accuracy Specification to the web in the near future. When this happens, we will post a pointer on the IBIS reflector. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Tue Nov 3 03:30:45 1998 Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by server.eda.org (8.8.5/8.8.3) with ESMTP id DAA29968 for ; Tue, 3 Nov 1998 03:30:43 -0800 (PST) Received: from sni.de (limber.pdb.sni.de [129.103.151.127]) by nixpbe.pdb.sni.de (8.8.8/8.8.8) with ESMTP id LAA10395 for ; Tue, 3 Nov 1998 11:26:10 GMT Message-ID: <363EE914.787CEA92@sni.de> Date: Tue, 03 Nov 1998 12:29:24 +0100 From: Hans-Joerg John Organization: Siemens AG X-Mailer: Mozilla 4.06 [en]C-DM19971112 (WinNT; I) MIME-Version: 1.0 To: ibis-users@eda.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe -- Dr.-Ing. Hans-Joerg John email: john.pad@sni.de Siemens AG phone: +49 5251 820 347 ICP CS PS DH4 fax: +49 5251 820 349 EMC and Signal Integrity Support Heinz-Nixdorf-Ring 1 D-33106 Paderborn Germany From owner-ibis Fri Nov 6 09:23:29 1998 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA12642; Fri, 6 Nov 1998 09:23:28 -0800 (PST) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id MAA67146; Fri, 6 Nov 1998 12:00:56 -0500 Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id MAA42516; Fri, 6 Nov 1998 12:14:25 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU036 id 5010400028671109; Fri, 6 Nov 1998 12:24:07 -0500 From: Gregory R Edlund To: Cc: Subject: IBIS Accuracy Subcommittee Minutes - 11/05/98 Message-ID: <5010400028671109000002L092*@MHS> Date: Fri, 6 Nov 1998 12:24:07 -0500 MIME-Version: 1.0 Content-Type: text/plain IBIS Accuracy Subcommittee Minutes Thursday, November 5, 1998 Held at Compaq Computer, Maynard, MA Attendees Greg Edlund, IBM (by phone) Bob Haller, Compaq Computer Peter LaFlamme, Fairchild Semiconductor Harvey Stiegler, Texas Instruments (by phone) Time and location of next meeting to be determined. MILESTONES Pass 2 of the test board has been fabricated, assembled, and is currently in testing. Those of you who have been waiting for the design files can expect them before the end of 1998. The Test Board Application Note make take a while longer. The subcommittee will post a notice to the reflector when these events occur October 15, 1998: IBIS Accuracy Test Board tested - demo at PCB East IBIS Summit. October 15, 1998: Rough draft of IBIS Accuracy Spec distributed at PCB East IBIS Summit. November 22, 1998: Submit final draft of DesignCon99 paper. February 1999: Present the IBIS Accuracy Specification at DesignCon99. EDITING No activity this meeting. The IBIS Accuracy Specification should be made available on the web as soon as possible to increase visibility and the potential for feedback. The subcommittee would like to see a link to the spec from somewhere within the main IBIS web page if possible. DESIGNCON99 Most of the group activity has been focused on the final draft of the DesignCon99 paper, which includes taking data from the test board. HP will be providing test equipment for the demo that accompanies the paper: HP54750 digital oscilloscope and TDR, FET probes, power supply, and multimeter. Bob Ross has suggested the possibility of space at the IBIS booth, and this topic will be up for discussion at the next Open Forum. The Accuracy Subcommittee would also like to suggest setting up IBIS development software from one or more vendors and demonstrating curve overlay techniques. FUTURE ACTIVITIES Once the DesignCon99 final draft is done, the subcommittee will return to activities related to the IBIS Accuracy Specification and the test board. These include: 1. Finish writing the rough draft of the IBIS Accuracy Specification. 2. Publish the test board design files. 3. Write and publish the IBIS Accuracy Test Board Application Note. 4. Implement feedback from the IBIS community. There seems to be a strong body of opinion that the IBIS Accuracy Specification needs to be decoupled from the question of simulator accuracy. One possible means suggested for accomplishing this goal is VT tables. However, VT tables presently lack the capability of transmission line loads. This means a new BIRD, which would delay the introduction of the first draft. We began debating ways to implement VT tables into the spec, but decided to table the discussion until after we submit the DesignCon99 final draft. Including VT tables in the spec represents a significant amount of work. Indeed, parts of the spec would have to be re-written. We are coming to the realization that no matter what direction we take on the implementation of VT tables, much of the next year of the IBIS Accuracy Subcommittee will be spent dealing with simulation questions and advanced model features, including advanced I/O buffer designs. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Fri Nov 6 11:20:27 1998 Received: from hotmail.com (f172.hotmail.com [207.82.251.58]) by server.eda.org (8.8.5/8.8.3) with SMTP id LAA13140 for ; Fri, 6 Nov 1998 11:20:26 -0800 (PST) Received: (qmail 15859 invoked by uid 0); 6 Nov 1998 19:15:25 -0000 Message-ID: <19981106191525.15858.qmail@hotmail.com> Received: from 147.145.40.40 by www.hotmail.com with HTTP; Fri, 06 Nov 1998 11:15:25 PST X-Originating-IP: [147.145.40.40] From: "Shaggy Gonzalez" To: ibis-users@eda.org MIME-Version: 1.0 Content-Type: text/plain Date: Fri, 06 Nov 1998 11:15:25 PST Hi, Could you tell as to why are the warnings like : Typical/Max/Min Data Non-Monotonic Pullup/PullDown. What are these and how can they be removed.. Also. some warnings are: Typical AC points not within 2% etc How are they taken care of.. shaggy ASD Design Solutions: ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Fri Nov 6 15:43:37 1998 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA13689 for ; Fri, 6 Nov 1998 15:43:36 -0800 (PST) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA86064 for ; Fri, 6 Nov 1998 18:21:04 -0500 Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id SAA19170 for ; Fri, 6 Nov 1998 18:34:48 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU036 id 5010400028685644; Fri, 6 Nov 1998 18:44:27 -0500 From: Gregory R Edlund To: Subject: standard loads on 66 MHz PCI Message-ID: <5010400028685644000002L042*@MHS> Date: Fri, 6 Nov 1998 18:44:27 -0500 MIME-Version: 1.0 Content-Type: text/plain A question came up here at IBM today that I could not answer. Has anyone run into this? The 66 MHz PCI bus spec has a different standard load for rising and falling edges. (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for falling.) As I read version 3.1 of IBIS, it only allows one value of Vref per [Model] keyword. This seems to make the 66 MHz PCI driver unable to be implemented in IBIS, at least if you want to do timing analysis. I would think someone else probably encountered this already. How did you get around it? Or am I missing something? Much thanks in advance. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Fri Nov 6 16:16:18 1998 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA13740 for ; Fri, 6 Nov 1998 16:16:18 -0800 (PST) Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id AAA26034; Sat, 7 Nov 1998 00:11:46 GMT Message-Id: <199811070011.AAA26034@calliope1.fm.intel.com> Received: by FMSMSX17 with Internet Mail Service (5.5.2232.9) id ; Fri, 6 Nov 1998 16:11:46 -0800 From: "Muranyi, Arpad" To: "\"ibis-users@vhdl.org\" " , "\"Gregory R Edlund\" " Subject: RE: standard loads on 66 MHz PCI Date: Fri, 6 Nov 1998 16:09:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Greg, You can put the two Vref numbers into the IBIS model and comment one of them out. Unfortunately this means that you have to simulate things twice (with most IBIS based simulators), but fortunately the waveforms are not effected by this, only the flight time measurements. So one of the simulations could do the falling edge measurements, and the other one the rising edge measurements. If you need more detail send me another EMAIL, and I will give you an example. Arpad Muranyi Intel Corporation ============================================================================ A question came up here at IBM today that I could not answer. Has anyone run into this? The 66 MHz PCI bus spec has a different standard load for rising and falling edges. (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for falling.) As I read version 3.1 of IBIS, it only allows one value of Vref per [Model] keyword. This seems to make the 66 MHz PCI driver unable to be implemented in IBIS, at least if you want to do timing analysis. I would think someone else probably encountered this already. How did you get around it? Or am I missing something? Much thanks in advance. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Mon Nov 9 07:43:57 1998 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA18279 for ; Mon, 9 Nov 1998 07:43:56 -0800 (PST) Received: from rlep1.itg.ti.com ([157.170.135.170]) by jester.ti.com (8.8.8) with ESMTP id JAA11212 for ; Mon, 9 Nov 1998 09:38:03 -0600 (CST) Received: from ti.com (CNA0153032.rsc.raytheon.com [138.126.42.118]) by rlep1.itg.ti.com (8.8.8/8.8.8) with ESMTP id JAA28104 for ; Mon, 9 Nov 1998 09:38:28 -0600 (CST) Message-ID: <36470BEA.B2C95C5E@ti.com> Date: Mon, 09 Nov 1998 09:36:11 -0600 From: David Haedge X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ibis-users@vhdl.org Subject: Re: standard loads on 66 MHz PCI References: <199811070011.AAA26034@calliope1.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We had a similar problem with a Motorola MPC750. The L2 cache MAX timing numbers are specified to a 20pF load and the MIN numbers to a 5pF load. We were using ICX to analyze timing. We looked at the output under no load, then at 20pF and 5pF. The delta was measured to be 477ps. We then adjusted the timing sheets in ICX so that the minimum allowed routing distance was effectively increased by 477ps to compensate for the additional 'test' load. This allowed us to use a single IBIS model with Cref set at 20pF. You may be able to apply a similar 'trick' with the PCI driver and Vref. David Haedge Raytheon Systems Company From owner-ibis Mon Nov 9 08:15:48 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA18350 for ; Mon, 9 Nov 1998 08:15:48 -0800 (PST) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id IAA07046; Mon, 9 Nov 1998 08:10:46 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id IAA00062; Mon, 9 Nov 1998 08:10:44 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA15947; Mon, 9 Nov 98 08:10:44 PST Date: Mon, 9 Nov 98 08:10:44 PST Message-Id: <9811091610.AA15947@bob> To: ibis-users@eda.org, shaggy_gonzalez@hotmail.com Subject: IBISCHK Warnings Shaggy: Then non-monotonic inforation is valuable as a Warning. Many models contain some non-monotonic behavior in the clamping regions, but the summation of clamping tables with the corresponding [Pulldown] or [Pullup] table produces a monotonic response which many simulators can handle. However, there could be regions which cause problems. So the tables should be examined with a graphical viewer. The Typical AC points not within 2% ... Warning needs to be taking very seriously. It usually reveals one of several things which can cause serious distortion of IBIS model simulations: (1) The [Rising Waveform] or [Falling Waveform] is not constructed in a consistent manner with the various IV tables. (2) The time range for the [Rising Waveform] or [Falling Waveform] table did not extend long enough for the voltage entry to converge to the final value. This usually occurs for the minimum entry under loading conditions which cause the response to be the slowest. (3) Some malformed clamping tables (usually the [Power Clamp] table] which ends as 0 V) would linearly extrolate in a manner that causes it to appear as a resistor in the normal operating region. For example the last two entries may appear as: | V typ min max ... 0.1 1m 1m 1m 0 0 0 0 This would extrapolate as a 10 ma per volt (100 ohm) pullup resistor into the operating region - enough to cause the calculated response to be different than the captured response. ibischk3 test for extropolated values when predicting the DC starting and ending points of waveforms. These are serious problems. The technical reason that this is treated only as a Warning is that the 2% tolerance limit is arbitrary. In some cases if you are within a slightly higher error limit, you may still get good simulations. Bob Ross Interconnectix/Mentor Graphics > From: "Shaggy Gonzalez" > To: ibis-users@eda.org > Hi, > Could you tell as to why are the warnings like : > Typical/Max/Min Data Non-Monotonic Pullup/PullDown. > What are these and how can they be removed.. > Also. some warnings are: Typical AC points not within 2% etc > How are they taken care of.. > shaggy > ASD Design Solutions: > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Mon Nov 9 08:26:34 1998 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by server.eda.org (8.8.5/8.8.3) with SMTP id IAA18376 for ; Mon, 9 Nov 1998 08:26:33 -0800 (PST) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA24369 for ; Mon, 9 Nov 1998 08:21:32 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id LAA09848; Mon, 9 Nov 1998 11:21:26 -0500 Received: from toro.East.Sun.COM (toro [129.148.29.93]) by suneast.East.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id LAA24034 for ; Mon, 9 Nov 1998 11:21:26 -0500 (EST) Received: from toro by toro.East.Sun.COM (SMI-8.6/SMI-SVR4) id LAA11415; Mon, 9 Nov 1998 11:21:26 -0500 Date: Mon, 9 Nov 1998 11:21:26 -0500 (EST) From: Tay Ansari - Board Design Technology Reply-To: Tay Ansari - Board Design Technology Subject: Re: standard loads on 66 MHz PCI To: ibis-users@vhdl.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cwRMWJGemgNJWifywdRbMA== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Hi Greg, I ran into this exact problem when I was trying to set up a simulation environment for the 66 MHz PCI bus. Fortunately, the IBIS simulator I am using allows me to choose whether I want the buffer delays to come from a simulation into the standard load circuit from the IBIS model or from time values which I directly give to the simulator. So what I did was use Spice to measure the rise and fall delays into their respective standard load circuits; I then gave those Spice generated numbers to my IBIS simulator. Not an ideal solution, but a workaround that worked good enough. Unfortunately, this solution doesn't help you much if you can't directly give buffer delays to your simulator. The ideal solution would be to enhance the IBIS spec to allow for a unique standard load circuit for both the rising and falling edges; that is, if this is a common problem. Or is this pretty much an isolated case with the 66 MHz PCI spec? Regards, Tay Ansari Sun Microsystems > > From: Gregory R Edlund > To: > Subject: standard loads on 66 MHz PCI > > A question came up here at IBM today that I could not answer. Has anyone run > into this? > > The 66 MHz PCI bus spec has a different standard load for rising and falling > edges. (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for > falling.) As I read version 3.1 of IBIS, it only allows one value of Vref per > [Model] keyword. This seems to make the 66 MHz PCI driver unable to be > implemented in IBIS, at least if you want to do timing analysis. I wouldthink > someone else probably encountered this already. How did you get around it? Or > am I missing something? > > Much thanks in advance. > > Greg Edlund > Advisory Engineer, AS/400 System Timing > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > From owner-ibis Mon Nov 9 11:09:26 1998 Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by server.eda.org (8.8.5/8.8.3) with SMTP id LAA18836 for ; Mon, 9 Nov 1998 11:09:25 -0800 (PST) Received: from mailext02.compaq.com by mailext02.compaq.com via smail with esmtp id for ; Mon, 9 Nov 98 09:59:37 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.10 built 27-oct-98) Received: from mail.compaq.com([207.18.199.32]) by mailext02.compaq.com with SMTP (peer mailint01.compaq.com[207.18.199.34]) id rcv001252; Mon, 9 Nov 1998 09:59:37 -0600 (CST) Received: from lisbon.eng.hou.compaq.com(really [131.168.159.105]) by mail.compaq.com via sendmail with smtp id for ; Mon, 9 Nov 98 10:03:42 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97) Received: by lisbon.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0zctmL-000KyfC; Mon, 9 Nov 98 10:02 CST Message-Id: Date: Mon, 9 Nov 98 10:02 CST From: beal@lisbon.eng.hou.compaq.com (Weston Beal) To: ibis-users@vhdl.org Subject: Re: standard loads on 66 MHz PCI Greg, This is a good question. I've thought about it too. I've seen evidense that no one knows how to handle it. I have yet to see an IBIS file of a PCI component with the timing reference load specified. There is one more problem. There is another load for min time. The advice to uncomment the appropriate load and rerun simulation (from Arpad) is about the only work around. I wonder if we can change the PCI spec or at least come up with a standard PCI test load to include in IBIS. Does anyone know WHY PCI has three different timing test loads? I think that is an important question before we can come up with an appropriate test load for IBIS. Regards, Weston Beal > From: Gregory R Edlund > To: > Subject: standard loads on 66 MHz PCI > Date: Fri, 6 Nov 1998 18:44:27 -0500 > > A question came up here at IBM today that I could not answer. Has anyone run > into this? > > The 66 MHz PCI bus spec has a different standard load for rising and falling > edges. (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for > falling.) As I read version 3.1 of IBIS, it only allows one value of Vref per > [Model] keyword. This seems to make the 66 MHz PCI driver unable to be > implemented in IBIS, at least if you want to do timing analysis. I would think > someone else probably encountered this already. How did you get around it? Or > am I missing something? > > Much thanks in advance. > > Greg Edlund > Advisory Engineer, AS/400 System Timing > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > From owner-ibis Mon Nov 9 11:26:37 1998 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA18885 for ; Mon, 9 Nov 1998 11:26:37 -0800 (PST) Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by thalia.fm.intel.com (8.8.6/8.8.5) with ESMTP id TAA29945 for ; Mon, 9 Nov 1998 19:22:04 GMT Message-Id: <199811091922.TAA29945@thalia.fm.intel.com> Received: by FMSMSX26 with Internet Mail Service (5.5.2232.9) id ; Mon, 9 Nov 1998 11:22:03 -0800 From: "Muranyi, Arpad" To: "\"ibis-users@vhdl.org\" " , "\"beal@lisbon.eng.hou.compaq.com\" " Subject: RE: standard loads on 66 MHz PCI Date: Mon, 9 Nov 1998 11:19:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain All, I guess it is not impossible to come up with a fix to the IBIS spec to accommodate the various reference loads the PCI spec uses. But, to answer someone's question, I have only seen this kind of multiple reference loads in the PCI spec. so far. And, sorry, but I have no idea why it was done that way. To further complicate things, think about this. There is a separate min and max reference (test) load. But what are you supposed to use if you want to run a typical simulation? This makes me suggest that we should look into how to fix the PCI spec... Arpad ============================================================================ == Greg, This is a good question. I've thought about it too. I've seen evidense that no one knows how to handle it. I have yet to see an IBIS file of a PCI component with the timing reference load specified. There is one more problem. There is another load for min time. The advice to uncomment the appropriate load and rerun simulation (from Arpad) is about the only work around. I wonder if we can change the PCI spec or at least come up with a standard PCI test load to include in IBIS. Does anyone know WHY PCI has three different timing test loads? I think that is an important question before we can come up with an appropriate test load for IBIS. Regards, Weston Beal > From: Gregory R Edlund > To: > Subject: standard loads on 66 MHz PCI > Date: Fri, 6 Nov 1998 18:44:27 -0500 > > A question came up here at IBM today that I could not answer. Has anyone run > into this? > > The 66 MHz PCI bus spec has a different standard load for rising and falling > edges. (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for > falling.) As I read version 3.1 of IBIS, it only allows one value of Vref per > [Model] keyword. This seems to make the 66 MHz PCI driver unable to be > implemented in IBIS, at least if you want to do timing analysis. I would think > someone else probably encountered this already. How did you get around it? Or > am I missing something? > > Much thanks in advance. > > Greg Edlund > Advisory Engineer, AS/400 System Timing > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > From owner-ibis Mon Nov 9 12:25:50 1998 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA19027 for ; Mon, 9 Nov 1998 12:25:49 -0800 (PST) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with ESMTP id PAA22772 for ; Mon, 9 Nov 1998 15:21:17 -0500 (EST) Received: by sbuamazko2ae.zko.dec.com with Internet Mail Service (5.0.1458.49) id ; Mon, 9 Nov 1998 15:21:14 -0500 Message-ID: <890ED1999E9CD01197A10000F84AA1F7FDFF43@sbuamapko3cc.eng.pko.dec.com> From: Andrew Ingraham To: ibis-users@vhdl.org Subject: RE: standard loads on 66 MHz PCI Date: Mon, 9 Nov 1998 15:21:02 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Why does PCI have three different test loads? To try to mimic some aspect of actual operating conditions. The minimum test load mimics the lightly loaded case: short bus wires, minimum device capacitance. The two maximum test loads model a driver sitting in the middle of a long transmission line that has settled to the previous state's voltage. Thus, when switching high-to-low, the bus is initially high, and looks like a thevenin resistance of Zo/2 (both "halves" of the t-line in parallel) to Vdd. While an infinitely long t-line may not be completely "realistic," its purpose as a test load is to extract how well the buffer switches such a load, before the reflection has returned. Are multiple test loads an isolated case with the 66MHz PCI spec? Well, 33MHz PCI (at 3.3V signaling) uses it too. Regards, Andy Ingraham From owner-ibis Mon Nov 9 15:05:56 1998 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA19459 for ; Mon, 9 Nov 1998 15:05:55 -0800 (PST) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id RAA20588 for ; Mon, 9 Nov 1998 17:43:16 -0500 Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id RAA44530 for ; Mon, 9 Nov 1998 17:57:05 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU036 id 5010400028756362; Mon, 9 Nov 1998 18:06:35 -0500 From: Gregory R Edlund To: Subject: Re: standard loads on 66 MHz PCI Message-ID: <5010400028756362000002L022*@MHS> Date: Mon, 9 Nov 1998 18:06:35 -0500 MIME-Version: 1.0 Content-Type: text/plain I wonder if this is really a non-issue? Does the somewhat "unusual" passage in the PCI spec about Tval loading necessarily mean that the vendor datasheet for that component must use the same loads? Couldn't the vendor specify a "traditional" standard load in the datasheet and still comply with PCI? The real concern here is that the load used by the simulator to compute net delays be IDENTICAL to the one specified in the datasheet. Now, if component datasheets are really using the three new PCI loads, then we truly have a problem. Beside the Motorola SRAM example, does anyone know of any PCI components that actually use all three loads in the datasheet? How new are these Tval loads? Version 2.2 (currently in draft, dated June 1998)? Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on 11/09/98 04:44 PM --------------------------- d-haedge@ti.com on 11/09/98 10:20:22 AM Please respond to d-haedge@ti.com To: ibis-users@vhdl.org cc: Subject: Re: standard loads on 66 MHz PCI We had a similar problem with a Motorola MPC750. The L2 cache MAX timing numbers are specified to a 20pF load and the MIN numbers to a 5pF load. We were using ICX to analyze timing. We looked at the output under no load, then at 20pF and 5pF. The delta was measured to be 477ps. We then adjusted the timing sheets in ICX so that the minimum allowed routing distance was effectively increased by 477ps to compensate for the additional 'test' load. This allowed us to use a single IBIS model with Cref set at 20pF. You may be able to apply a similar 'trick' with the PCI driver and Vref. David Haedge Raytheon Systems Company From owner-ibis Mon Nov 9 15:56:50 1998 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA19597 for ; Mon, 9 Nov 1998 15:56:49 -0800 (PST) Received: from fmsmsx18.intel.com (fmsmsx18.fm.intel.com [132.233.233.232]) by thalia.fm.intel.com (8.8.6/8.8.5) with ESMTP id XAA22812; Mon, 9 Nov 1998 23:52:17 GMT Message-Id: <199811092352.XAA22812@thalia.fm.intel.com> Received: by FMSMSX18 with Internet Mail Service (5.5.2232.9) id ; Mon, 9 Nov 1998 15:52:16 -0800 From: "Muranyi, Arpad" To: "\"ibis-users@vhdl.org\" " , "\"Gregory R Edlund\" " Subject: RE: standard loads on 66 MHz PCI Date: Mon, 9 Nov 1998 15:49:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain The purpose of the test loads is to have a well defined load into which the semiconductor wendor can test their Tco (Tval) numbers. So when we simulate flight times, we start our flight time measurements from the point on the reference waveform where the Tco (Tval) number was measured to. If we didn't do it that way, we would have a gap or overlap in our AC spreadhseets and our timings would be hosed... (Remember, the actual driver has a totally different waveform from the reference load waveform, so we can't use that as the beginning of the flight time). Greg Edlund is absolutely correct, that for this reason it is very important to match the reference load in the simulation to the load the manuafturer used to obtain the Tco (Tval) numbers. Therefore I wold trun around Greg Edlund's question and ask: Do the semiconductor vendors really use these different reference loads to obtain their min and max Tco (Tval) numbers for their chips? In my opinion, these loads were not invented for the sake of PCI or the SIE engineer, they were invented for the IC manufacturer so that they can provide more meaningful Tco (Tval) numbers(?). I only question whether it is really necessary to have different min/max loads. The test load (and waveform) doesn't match the driver's real load (and waveform) anyway, so why bother making a separate test load for "minimum" and "maximum" conditions? Arpad ============================================================================ == I wonder if this is really a non-issue? Does the somewhat "unusual" passage in the PCI spec about Tval loading necessarily mean that the vendor datasheet for that component must use the same loads? Couldn't the vendor specify a "traditional" standard load in the datasheet and still comply with PCI? The real concern here is that the load used by the simulator to compute net delays be IDENTICAL to the one specified in the datasheet. Now, if component datasheets are really using the three new PCI loads, then we truly have a problem. Beside the Motorola SRAM example, does anyone know of any PCI components that actually use all three loads in the datasheet? How new are these Tval loads? Version 2.2 (currently in draft, dated June 1998)? Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on 11/09/98 04:44 PM --------------------------- d-haedge@ti.com on 11/09/98 10:20:22 AM Please respond to d-haedge@ti.com To: ibis-users@vhdl.org cc: Subject: Re: standard loads on 66 MHz PCI We had a similar problem with a Motorola MPC750. The L2 cache MAX timing numbers are specified to a 20pF load and the MIN numbers to a 5pF load. We were using ICX to analyze timing. We looked at the output under no load, then at 20pF and 5pF. The delta was measured to be 477ps. We then adjusted the timing sheets in ICX so that the minimum allowed routing distance was effectively increased by 477ps to compensate for the additional 'test' load. This allowed us to use a single IBIS model with Cref set at 20pF. You may be able to apply a similar 'trick' with the PCI driver and Vref. David Haedge Raytheon Systems Company From owner-ibis Tue Nov 10 05:02:01 1998 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA21233 for ; Tue, 10 Nov 1998 05:01:59 -0800 (PST) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with ESMTP id HAA20853 for ; Tue, 10 Nov 1998 07:57:25 -0500 (EST) Received: by sbuamazko2ae.zko.dec.com with Internet Mail Service (5.0.1458.49) id ; Tue, 10 Nov 1998 07:57:22 -0500 Message-ID: <890ED1999E9CD01197A10000F84AA1F7FDFF44@sbuamapko3cc.eng.pko.dec.com> From: Andrew Ingraham To: "'ibis-users@vhdl.org'" Subject: RE: standard loads on 66 MHz PCI Date: Tue, 10 Nov 1998 07:57:14 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Greg Edlund asked: > How new are these Tval loads? Version 2.2 (currently in draft, dated > June > 1998)? Much older than that. They became official at least as early as June 11, 1995, and were available in preliminary form a year before that. See Version 2.1, note 2 under Table 4-6, on page 134; and Figures 7-6, 7-7, and 7-8 on pages 227-228. Parts for the 5V PCI signaling environment use the two simple "lumped" test loads (0pF and 50pF), as these were already in place and in use for Version 2.0 (1993). Arpad Myranyi said: > The test load (and waveform) doesn't match the driver's real load > (and waveform) ... But I think they do! They are more realistic than the conventional 50pF lumped test load. The minimum load represents the limiting case of two PCI devices on a motherboard with no expansion slots and short etch; a strictly local bus. The maximum load represents that first nanosecond or so on a long bus, before the incident edge bounces off the open ends and returns to the driver. The waveform you get is ... well ... it's what you really get! Regards, Andy Ingraham From owner-ibis Tue Nov 10 08:07:47 1998 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA21665 for ; Tue, 10 Nov 1998 08:07:47 -0800 (PST) Received: from valencia.rsn.hp.com (valencia.rsn.hp.com [15.99.50.121]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id IAA25986; Tue, 10 Nov 1998 08:03:04 -0800 (PST) Received: (from schumach@localhost) by valencia.rsn.hp.com (8.7.1/8.7.1) id KAA09643; Tue, 10 Nov 1998 10:02:59 -0600 (CST) From: "Richard A. Schumacher" Message-Id: <199811101602.KAA09643@valencia.rsn.hp.com> Subject: Re: standard loads on 66 MHz PCI To: gedlund@us.ibm.com Date: Tue, 10 Nov 1998 10:02:58 CST Cc: ibis-users@vhdl.org, schumach@valencia.rsn.hp.com In-Reply-To: <5010400028756362000002L022*@MHS>; from "Gregory R Edlund" at Nov 9, 98 6:06 pm X-Mailer: Elm [revision: 212.4] > I wonder if this is really a non-issue? Does the somewhat "unusual" passage in > the PCI spec about Tval loading necessarily mean that the vendor datasheet for > that component must use the same loads? Couldn't the vendor specify a > "traditional" standard load in the datasheet and still comply with PCI? How do you demonstrate compliance in all corner cases with a single load datasheet? Especially if that single load is not _any_ of those given in the design spec? Any device which complies in one corner case may comply in the others, or it may not. PCI takes the right approach in explicitly specifying the corner cases. It's up to customers to demand appropriate data sheets and models. Is it feasible to expand the IBIS model spec and build enough intelligence into the simulators so that together they can automatically simulate all the corner cases in a given design? That would be required to meet the logic designers' expectation for a plug-and-chug solution. (Most SPICEs have monte carlo capabilities for such work; they require manual intervention to set parameter limits et cetera, but at least they don't require a different model for each loading case. With a model consisting of multiple sets of I-V and V-T curves, one per loading case, there's more scope for error: knowing that the set for one case is correct does not tell the user whether the other sets are correct.) From owner-ibis Tue Nov 10 08:34:42 1998 Received: from stortek.stortek.com (stortek.stortek.com [129.80.22.249]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA21750 for ; Tue, 10 Nov 1998 08:34:41 -0800 (PST) Received: from lsv-bridge.stortek.com (lsv-bridge.stortek.com [129.80.5.131]) by stortek.stortek.com (8.9.0/8.9.0) with ESMTP id JAA29957 for ; Tue, 10 Nov 1998 09:29:27 -0700 (MST) Received: by lsv-bridge.stortek.com with Internet Mail Service (5.5.2232.9) id ; Tue, 10 Nov 1998 09:29:27 -0700 Message-ID: From: "Krull, Nick J" To: "'ibis-users@vhdl.org'" Subject: Non Monatomic waveform, practically, how important? Date: Tue, 10 Nov 1998 09:29:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Has anybody run test cases against popular simulators to determine how important/sensitive monotonicity is to: 1) Convergence 2) Accuracy We are frequently running into models with non-monotomic features. The simulator vendors recommend that models be monotomic and I believe the IBIS spec demands it. Screening these features out is time consuming and testing the resultant model is even more time consuming. IBIS simulators generally do not have the knobs that SPICE simulators do. Is there a mathematical reason for this, or is it more a customer issue? Anybody have a few pearls of wisdom on this? What is the history behind it? Nick Krull StorageTek 11/10/98 From owner-ibis Tue Nov 10 08:34:49 1998 Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA21756 for ; Tue, 10 Nov 1998 08:34:47 -0800 (PST) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id LAA67748 for ; Tue, 10 Nov 1998 11:16:51 -0500 Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id LAA36486 for ; Tue, 10 Nov 1998 11:25:56 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU036 id 5010400028779344; Tue, 10 Nov 1998 11:35:23 -0500 From: Gregory R Edlund To: Subject: Re: standard loads on 66 MHz PCI Message-ID: <5010400028779344000002L042*@MHS> Date: Tue, 10 Nov 1998 11:35:23 -0500 MIME-Version: 1.0 Content-Type: text/plain Is it a requirement to demonstrate compliance with the PCI Tval spec on the component datasheet? I'm already taking PCI compliance on faith because most vendors do not include IV curves or rise/fall times on their datasheets. In the case of PCI drivers, my main interest as a system designer in the clock-to-out spec is as an input to my static timing analyzer. I agree with you that if vendors are specifying clock-to-out delays using the PCI loads ONLY, then IBIS should be ammended to facilitate seamless timing analysis. However, my preference would be that vendors use a simple, traditional standard load. Simplicity reduces the probability of random errors! Corner analysis using a single standard load has always been possible - as long as the vendor specifies min/typ/max clock-to-out delays. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com schumach@valencia.rsn.hp.com on 11/10/98 10:10:01 AM Please respond to schumach@valencia.rsn.hp.com To: Gregory R Edlund/Rochester/IBM@IBMUS cc: schumach@valencia.rsn.hp.com, ibis-users@vhdl.org Subject: Re: standard loads on 66 MHz PCI > I wonder if this is really a non-issue? Does the somewhat "unusual" passage in > the PCI spec about Tval loading necessarily mean that the vendor datasheet for > that component must use the same loads? Couldn't the vendor specify a > "traditional" standard load in the datasheet and still comply with PCI? How do you demonstrate compliance in all corner cases with a single load datasheet? Especially if that single load is not _any_ of those given in the design spec? Any device which complies in one corner case may comply in the others, or it may not. PCI takes the right approach in explicitly specifying the corner cases. It's up to customers to demand appropriate data sheets and models. Is it feasible to expand the IBIS model spec and build enough intelligence into the simulators so that together they can automatically simulate all the corner cases in a given design? That would be required to meet the logic designers' expectation for a plug-and-chug solution. (Most SPICEs have monte carlo capabilities for such work; they require manual intervention to set parameter limits et cetera, but at least they don't require a different model for each loading case. With a model consisting of multiple sets of I-V and V-T curves, one per loading case, there's more scope for error: knowing that the set for one case is correct does not tell the user whether the other sets are correct.) From owner-ibis Tue Nov 10 08:58:06 1998 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA21829 for ; Tue, 10 Nov 1998 08:58:06 -0800 (PST) Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by thalia.fm.intel.com (8.8.6/8.8.5) with ESMTP id QAA05387; Tue, 10 Nov 1998 16:53:33 GMT Message-Id: <199811101653.QAA05387@thalia.fm.intel.com> Received: by FMSMSX26 with Internet Mail Service (5.5.2232.9) id ; Tue, 10 Nov 1998 08:53:33 -0800 From: "Hobbs, Will" To: "\"'ibis-users@vhdl.org'\" " , "\"Krull; Nick J\" " Subject: RE: Non Monatomic waveform, practically, how important? Date: Tue, 10 Nov 1998 08:52:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Nick, IBIS doesn't disallow non-monotonic curves, but the parser issues a warning. The discussion (back in '93) that led to this parser feature was based on the observation that such curves frequently are in error-- most I/V behavior on real parts is monotonic. Note that this is a warning only, and meant to spur the engineer to take a second look to be sure the curve is accurate. Will Hobbs Intel Corp. Has anybody run test cases against popular simulators to determine how important/sensitive monotonicity is to: 1) Convergence 2) Accuracy We are frequently running into models with non-monotomic features. The simulator vendors recommend that models be monotomic and I believe the IBIS spec demands it. Screening these features out is time consuming and testing the resultant model is even more time consuming. IBIS simulators generally do not have the knobs that SPICE simulators do. Is there a mathematical reason for this, or is it more a customer issue? Anybody have a few pearls of wisdom on this? What is the history behind it? Nick Krull StorageTek 11/10/98 From owner-ibis Tue Nov 10 09:03:37 1998 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA21845 for ; Tue, 10 Nov 1998 09:03:36 -0800 (PST) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with ESMTP id LAA11669 for ; Tue, 10 Nov 1998 11:59:03 -0500 (EST) Received: by sbuamazko2ae.zko.dec.com with Internet Mail Service (5.0.1458.49) id ; Tue, 10 Nov 1998 11:59:00 -0500 Message-ID: <71EEA9EA5129D1118EA30000F840EBF1DFFC0F@sbuamapko3bc.eng.pko.dec.com> From: Robert Haller To: ibis-users@vhdl.org, "'Gregory R Edlund'" Subject: RE: standard loads on 66 MHz PCI Date: Tue, 10 Nov 1998 11:46:42 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Greg, As you may know, one of the ways we handle this (in our internal simulator) is it by having a unique standard load entry for each corner and for each rise/fall transistion. This way you do not need to make multiple runs in order to obtain corner analysis for different standard loads. I wonder if this idea could be extended for IBIS ? just my $.02 regards, Bob Haller ---------- From: Gregory R Edlund[SMTP:gedlund@us.ibm.com] Sent: Tuesday, November 10, 1998 11:35 AM To: ibis-users@vhdl.org Subject: Re: standard loads on 66 MHz PCI Is it a requirement to demonstrate compliance with the PCI Tval spec on the component datasheet? I'm already taking PCI compliance on faith because most vendors do not include IV curves or rise/fall times on their datasheets. In the case of PCI drivers, my main interest as a system designer in the clock-to-out spec is as an input to my static timing analyzer. I agree with you that if vendors are specifying clock-to-out delays using the PCI loads ONLY, then IBIS should be ammended to facilitate seamless timing analysis. However, my preference would be that vendors use a simple, traditional standard load. Simplicity reduces the probability of random errors! Corner analysis using a single standard load has always been possible - as long as the vendor specifies min/typ/max clock-to-out delays. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com schumach@valencia.rsn.hp.com on 11/10/98 10:10:01 AM Please respond to schumach@valencia.rsn.hp.com To: Gregory R Edlund/Rochester/IBM@IBMUS cc: schumach@valencia.rsn.hp.com, ibis-users@vhdl.org Subject: Re: standard loads on 66 MHz PCI > I wonder if this is really a non-issue? Does the somewhat "unusual" passage in > the PCI spec about Tval loading necessarily mean that the vendor datasheet for > that component must use the same loads? Couldn't the vendor specify a > "traditional" standard load in the datasheet and still comply with PCI? How do you demonstrate compliance in all corner cases with a single load datasheet? Especially if that single load is not _any_ of those given in the design spec? Any device which complies in one corner case may comply in the others, or it may not. PCI takes the right approach in explicitly specifying the corner cases. It's up to customers to demand appropriate data sheets and models. Is it feasible to expand the IBIS model spec and build enough intelligence into the simulators so that together they can automatically simulate all the corner cases in a given design? That would be required to meet the logic designers' expectation for a plug-and-chug solution. (Most SPICEs have monte carlo capabilities for such work; they require manual intervention to set parameter limits et cetera, but at least they don't require a different model for each loading case. With a model consisting of multiple sets of I-V and V-T curves, one per loading case, there's more scope for error: knowing that the set for one case is correct does not tell the user whether the other sets are correct.) From owner-ibis Tue Nov 10 09:09:03 1998 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA21875 for ; Tue, 10 Nov 1998 09:09:02 -0800 (PST) Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by emcmail.lss.emc.com (8.9.1/8.9.1) with SMTP id MAA17027 for ; Tue, 10 Nov 1998 12:02:21 -0500 (EST) Received: by fishbowl02.emc.com with VINES-ISMTP; Tue, 10 Nov 98 12:03:55 -0500 Date: Tue, 10 Nov 98 11:59:17 -0500 Message-ID: X-Priority: 3 (Normal) To: "'ibis-users@vhdl.org'" , From: "fabrizio zanella" Reply-To: Errors-to: Subject: re: Non Monatomic waveform, practically, how important? X-Incognito-SN: 1467 X-Incognito-Version: 4.11.23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Nick, it's not true that the IBIS spec demands monotonicity on models. If you run one of the free IBIS model viewers available on a model with non-monotonic curves, you will get warnings, not errors. I know of two SI simulators which accept non-monotonic IBIS models. Non-monotonicity is a reality in some devices, as I've learned in talking to engineers at semiconductor vendors. Regards, Fabrizio Zanella EMC corporation fzanella@emc.com ------------- Original Text From: "Krull, Nick J" , on 11/10/98 11:29 AM: To: smtp@Eng@EMCHOP1["'ibis-users@vhdl.org'" ] Has anybody run test cases against popular simulators to determine how important/sensitive monotonicity is to: 1) Convergence 2) Accuracy We are frequently running into models with non-monotomic features. The simulator vendors recommend that models be monotomic and I believe the IBIS spec demands it. Screening these features out is time consuming and testing the resultant model is even more time consuming. IBIS simulators generally do not have the knobs that SPICE simulators do. Is there a mathematical reason for this, or is it more a customer issue? Anybody have a few pearls of wisdom on this? What is the history behind it? Nick Krull StorageTek 11/10/98 From owner-ibis Tue Nov 10 09:27:36 1998 Received: from mail-gw5.pacbell.net (mail-gw5.pacbell.net [206.13.28.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA21923 for ; Tue, 10 Nov 1998 09:27:36 -0800 (PST) Received: from pacbell.net (ppp-209-79-182-238.vntrcs.pacbell.net [209.79.182.238]) by mail-gw5.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id JAA19604; Tue, 10 Nov 1998 09:22:56 -0800 (PST) Message-ID: <3648768D.12181894@pacbell.net> Date: Tue, 10 Nov 1998 09:23:25 -0800 From: Jon Powell Reply-To: jonp@qdt.com Organization: Viewlogic Consulting Services X-Mailer: Mozilla 4.04 [en]C-PBI-NC404 (Win95; I) MIME-Version: 1.0 To: "Krull, Nick J" CC: "'ibis-users@vhdl.org'" Subject: Re: Non Monatomic waveform, practically, how important? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The classic reason we argued against allowing non-monotonic IV curves was because the non-monotonic behavior requires a feedback path (and thus a delay) that we have never been able to properly define. If you don't know the feedback path delay then you do not know the inherent non-stable point for the driver. We have tried to work with IC companies that have this problem (and I think we did get a few non-real examples from some people) but the actual resolution of the feedback delay has never been completely addressed. I think that the current IBIS simulators take one of two approaches: 1) Allow the non-monotonic behavior and assume 0 delay. 2) Filter out the non-monotonic behavior automatically. Which one is right? Depends on the driver and the feedback delay. regards, Jon Powell Manager, High Speed Consulting Services, Viewlogic Systems. From owner-ibis Tue Nov 10 09:42:31 1998 Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA22010 for ; Tue, 10 Nov 1998 09:42:24 -0800 (PST) Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id JAA12698; Tue, 10 Nov 1998 09:47:38 -0800 (PST) Message-Id: <199811101747.JAA12698@hebe.or.intel.com> Received: by ORSMSX28 with Internet Mail Service (5.5.2232.9) id ; Tue, 10 Nov 1998 09:37:47 -0800 From: "Muranyi, Arpad" To: "\"Krull; Nick J\" " , "\"Jon Powell\" " Cc: "\"'ibis-users@vhdl.org'\" " Subject: RE: Non Monatomic waveform, practically, how important? Date: Tue, 10 Nov 1998 09:35:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Also, don't forget that some of these non-monotonic curves come from the numerical separation of the pulldown/up and clamp curves which will become monotonic again after they are added back together. The problem is that the checker checks for non-monotonocity without adding them up. Arpad ======================================================================= The classic reason we argued against allowing non-monotonic IV curves was because the non-monotonic behavior requires a feedback path (and thus a delay) that we have never been able to properly define. If you don't know the feedback path delay then you do not know the inherent non-stable point for the driver. We have tried to work with IC companies that have this problem (and I think we did get a few non-real examples from some people) but the actual resolution of the feedback delay has never been completely addressed. I think that the current IBIS simulators take one of two approaches: 1) Allow the non-monotonic behavior and assume 0 delay. 2) Filter out the non-monotonic behavior automatically. Which one is right? Depends on the driver and the feedback delay. regards, Jon Powell Manager, High Speed Consulting Services, Viewlogic Systems. From owner-ibis Tue Nov 10 10:49:03 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA22209 for ; Tue, 10 Nov 1998 10:49:03 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id KAA06215 for ibis-users@vhdl.org; Tue, 10 Nov 1998 10:43:49 -0800 (PST) Date: Tue, 10 Nov 1998 10:43:49 -0800 (PST) From: Syed Huq Message-Id: <199811101843.KAA06215@jasper.cisco.com> To: ibis-users@vhdl.org Subject: *_dut params for waveform tables Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: C6nxcs3K/L9hy1blu+txpQ== IBISgurus, For waveform tables, there are sub-params called R_dut, L_dut and C_dut. These are same as R_pkg, L_pkg and C_pkg. From talking to a few IBIS experts I understand that waveform tables should be generated without any pkg parasitics. Simulators will attach the package parasitcs to the waveform tables and run simulations. That means, do not include *_dut in your s2ibis2 translation. If that is true, Why does s2ibis2 include R_d, L_d and C_d parameters ? Why does IBIS even have *_dut parameters in the spec ? How does one avoid double counting of pkg numbers for V/T ? Are the *_dut only for measurement based IBIS models ? Regards, Syed Cisco Systems,Inc From owner-ibis Tue Nov 10 14:39:25 1998 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA22956 for ; Tue, 10 Nov 1998 14:39:24 -0800 (PST) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with ESMTP id RAA06165 for ; Tue, 10 Nov 1998 17:34:51 -0500 (EST) Received: by sbuamazko2ae.zko.dec.com with Internet Mail Service (5.0.1458.49) id ; Tue, 10 Nov 1998 17:34:47 -0500 Message-ID: <890ED1999E9CD01197A10000F84AA1F7FDFF47@sbuamapko3cc.eng.pko.dec.com> From: Andrew Ingraham To: "'ibis-users@vhdl.org'" Subject: RE: Non Monatomic waveform, practically, how important? Date: Tue, 10 Nov 1998 17:34:36 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain The other problem with feedback (as in a "bus-hold" circuit) is that the I/V curve has hysteresis. There is some range of voltages over which there are two possible current values. Which one you get depends on previous history (i.e., whether you ramp up or down). A non-monotonic I/V curve means the device is capable of being an amplifier within that region, and depending on its load, may oscillate. Sometimes it doesn't actually oscillate but causes the simulator to become unstable or otherwise run into numeric difficulties. Regards, Andy Ingraham From owner-ibis Wed Nov 11 07:33:01 1998 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA25723 for ; Wed, 11 Nov 1998 07:33:00 -0800 (PST) Received: from hpbs2933.boi.hp.com (pgregory@hpbs2933.boi.hp.com [15.8.28.3]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id HAA21595 for ; Wed, 11 Nov 1998 07:28:26 -0800 (PST) Received: (from pgregory@localhost) by hpbs2933.boi.hp.com (8.8.6 (PHNE_14041)/8.7.3) id IAA26696 for ibis-users@eda.org; Wed, 11 Nov 1998 08:28:23 -0700 (MST) From: Paul Gregory Message-Id: <199811111528.IAA26696@hpbs2933.boi.hp.com> Subject: Scaling IBIS models To: ibis-users@eda.org Date: Wed, 11 Nov 1998 8:28:23 MST Reply-to: paul_gregory@hp.com X-Mailer: Elm [revision: 212.4] I have a v2.1 model from a supplier. The models is of a CMOS 24ma driver. After simulations, I find that the driver is too strong, that is, there is ringing on the transitions, and the transition is faster than is necessary. So I request the supplier to reduce the drive strength by 10%, rebuild the IBIS models and send me the new stuff. I get the new models. I find that the V/I tables show about a 10% reduction. That is what I expected. But, the transition times and rising and falling waveforms are not slower, but faster than the original (by about 10%). I think about this. Perhaps its because the capacitance of the the gate is reduced. No, the C_comp value is not changed. Note: these models are created from a home-grown s2ibis procedure. These are not measured values. So the questions: Why does a model with reduced drive capacity have faster edge rates? Is this a model error or should it really be so? Second, if you need to do some "what-if'ing", and you decide to edit the ibis model to scale it, what things should be changed and in what direction (that is increased or decreased)? Should everything scale by the same factor? -- Paul Gregory From owner-ibis Wed Nov 11 08:21:05 1998 Received: from relayhost.vlsi.com (relayhost.vlsi.com [134.27.20.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA25851 for ; Wed, 11 Nov 1998 08:20:33 -0800 (PST) Received: (from smtp@localhost) by relayhost.vlsi.com (SMI-8.6/) id IAA05091 for ; Wed, 11 Nov 1998 08:15:21 -0800 Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by isis.vlsi.com via smap (V2.0) id xma005080; Wed, 11 Nov 98 08:15:01 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id TXYVF9AX; Wed, 11 Nov 1998 09:13:53 -0700 Sender: dsession@vlsi.com Message-ID: <3649B804.6FD5C883@vlsi.com> Date: Wed, 11 Nov 1998 09:15:00 -0700 From: "D. C. Sessions" Reply-To: ibis-users@eda.org Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.06 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ibis-users@eda.org Subject: Re: Scaling IBIS models References: <199811111528.IAA26696@hpbs2933.boi.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Gregory wrote: > > I have a v2.1 model from a supplier. The models is of > a CMOS 24ma driver. After simulations, I find that the > driver is too strong, that is, there is ringing on the > transitions, and the transition is faster than is > necessary. So I request the supplier to reduce the drive > strength by 10%, rebuild the IBIS models and send me the > new stuff. Quick sanity check: the clamp curves should be pretty much unchanged. This is because the total amount of output transistor is determined mostly by ESD requirements, so when a driver is sized the drain area is left unchanged but several gates are tied off. > I get the new models. I find that the V/I tables show > about a 10% reduction. That is what I expected. But, > the transition times and rising and falling waveforms > are not slower, but faster than the original (by about > 10%). I think about this. Perhaps its because the > capacitance of the the gate is reduced. No, the C_comp > value is not changed. They didn't change the predriver. Output transition times are dictated by the rise and fall times of the final drive gate voltages, which in turn are a function of the predriver output currents and the gate capacitance of the final drive stage. When they tied off 10% of the final stage gates, the ones that were left switched faster, giving a higher di/dt at the output. > So the questions: Why does a model with reduced drive > capacity have faster edge rates? Is this a model error > or should it really be so? It's real. > Second, if you need to do some "what-if'ing", and you decide > to edit the ibis model to scale it, what things should be > changed and in what direction (that is increased or decreased)? > Should everything scale by the same factor? IMNSHO (This is my job, here) each predriver should be individually sized to give adequate results with the intended final stage. Failing that, you can *almost* expect a constant value for di/dt irrespective of final drive size as long as the predriver doesn't change. The clamp curves shouldn't change at all, and the final drive saturation (short-circuit) current should scale. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Fri Nov 13 14:34:04 1998 Received: from mailhost.avanticorp.com (uucp@mailhost.avanticorp.com [207.220.204.13]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA03712 for ; Fri, 13 Nov 1998 14:34:03 -0800 (PST) From: nikolai@avanticorp.com Received: (from uucp@localhost) by mailhost.avanticorp.com (8.9.1a/8.9.1) id OAA27493; Fri, 13 Nov 1998 14:29:22 -0800 (PST) Received: from avant250.src.avanticorp.com(172.18.10.12) via SMTP by shamu.avanticorp.com, id smtpdAAAI0mtH_; Fri Nov 13 14:29:14 1998 Received: from iris.src.avanticorp.com (iris.src.avanticorp.com [172.18.5.78]) by avant250.src.avanticorp.com (8.9.1a/8.9.1) with ESMTP id OAA12700; Fri, 13 Nov 1998 14:29:13 -0800 (PST) Received: (from nikolai@localhost) by iris.src.avanticorp.com (8.8.8/8.8.8) id OAA28977; Fri, 13 Nov 1998 14:26:48 -0800 (PST) Date: Fri, 13 Nov 1998 14:26:48 -0800 (PST) Message-Id: <199811132226.OAA28977@iris.src.avanticorp.com> To: ibis-users@eda.org Subject: ecl models in ibis X-Sun-Charset: US-ASCII IBIS Gurus, Experst, Inventors, and Developers: Can anybody clarify the following ECL model related issues in IBIS. Below is an excerpt from IBIS file (downloaded from internet). I have 2 questions regasrding these data. 1) Why current in PU/PD tables is always negative? Why the buffer "ECL_OBUF3_5" always source current and never sink current? Is this something "ECL_OBUF3_5" model specific or it is a typical case for Output_ECL buffer? 2) regarding: [Voltage Range] 0.0 0.0 0.0 [Pulldown Reference] 0.0 0.0 0.0 [Power Clamp Reference] 0.0 0.0 0.0 [GND Clamp Reference] -3.3 -3.0 -3.8 Why [Pulldown Reference] = 0, why not to use [Pulldown Reference] = -3.3V ? THis question is more about conventions used. It is clear what voltages are applied. Why not to use notations: [Voltage Range] 0.0 0.0 0.0 [Pullup Reference] 0.0 0.0 0.0 (*) [Pulldown Reference] -3.3 -3.0 -3.8 [Power Clamp Reference] 0.0 0.0 0.0 (*) [GND Clamp Reference] -3.3 -3.0 -3.8 (*) indicate optional parameter (no need to include it, but no harm if it is given) Thank you Nik nikolai@avanticorp.com [IBIS ver] 2.1 [File name] mc_lvecl.ibs [File Rev] 1.2 [Date] 4/28/98 [Source] Motorola spice models [Notes] This ibis package is made for Motorola ECLinPS and ECLinPS Lite families, and is particularly for the Low Voltage family. It includes [Model] ECL_OBUF3_5 Model_type Output_ECL Polarity Non-Inverting Vmeas = -1.3 Rref = 50.0 Vref = -2.0 | |Variable typ min max C_comp 2.9p 2.0p 6.0p | |Variable typ min max [Temperature Range] 27 0 85 | |Variable typ min max [Voltage Range] 0.0 0.0 0.0 [Pulldown Reference] 0.0 0.0 0.0 [Power Clamp Reference] 0.0 0.0 0.0 [GND Clamp Reference] -3.3 -3.0 -3.8 | [Pulldown] |Volts I(typ) I(min) I(max) +3.00 -2.290e-01 -1.623e-01 -2.832e-01 +2.90 -2.152e-01 -1.523e-01 -2.603e-01 +2.80 -2.010e-01 -1.419e-01 -2.422e-01 +2.70 -1.862e-01 -1.312e-01 -2.240e-01 +2.60 -1.707e-01 -1.201e-01 -2.050e-01 +2.50 -1.544e-01 -1.085e-01 -1.850e-01 +2.40 -1.372e-01 -9.633e-02 -1.637e-01 +2.30 -1.189e-01 -8.357e-02 -1.410e-01 +2.20 -9.939e-02 -7.012e-02 -1.166e-01 +2.10 -7.841e-02 -5.592e-02 -9.036e-02 +2.00 -5.586e-02 -4.094e-02 -6.207e-02 +1.90 -3.210e-02 -2.537e-02 -3.272e-02 +1.80 -1.011e-02 -1.036e-02 -8.403e-03 +1.70 -6.249e-04 -1.060e-03 -5.795e-04 +1.60 -1.429e-05 -1.917e-05 -2.407e-05 +1.50 +0.000e+00 +0.000e+00 +0.000e+00 +1.00 +0.000e+00 +0.000e+00 +0.000e+00 +0.50 +0.000e+00 +0.000e+00 +0.000e+00 +0.00 +0.000e+00 +0.000e+00 +0.000e+00 | | [Pullup] |Volts I(typ) I(min) I(max) +3.00 -2.528e-01 -1.876e-01 -3.089e-01 +2.90 -2.436e-01 -1.790e-01 -2.977e-01 +2.80 -2.346e-01 -1.709e-01 -2.869e-01 +2.70 -2.258e-01 -1.639e-01 -2.761e-01 +2.60 -2.169e-01 -1.571e-01 -2.653e-01 +2.50 -2.081e-01 -1.503e-01 -2.545e-01 +2.40 -1.992e-01 -1.433e-01 -2.437e-01 +2.30 -1.902e-01 -1.361e-01 -2.328e-01 +2.20 -1.812e-01 -1.288e-01 -2.219e-01 +2.10 -1.721e-01 -1.212e-01 -2.110e-01 +2.00 -1.630e-01 -1.135e-01 -2.000e-01 +1.90 -1.536e-01 -1.055e-01 -1.889e-01 +1.80 -1.440e-01 -9.734e-02 -1.777e-01 +1.70 -1.339e-01 -8.885e-02 -1.664e-01 +1.60 -1.229e-01 -8.005e-02 -1.548e-01 +1.50 -1.106e-01 -7.090e-02 -1.426e-01 +1.40 -9.719e-02 -6.136e-02 -1.282e-01 +1.30 -8.285e-02 -5.139e-02 -1.079e-01 +1.20 -6.708e-02 -4.094e-02 -8.326e-02 +1.10 -4.788e-02 -2.997e-02 -5.614e-02 +1.00 -2.591e-02 -1.797e-02 -2.801e-02 +0.90 -6.389e-03 -5.536e-03 -6.124e-03 +0.80 -2.749e-04 -2.551e-04 -3.688e-04 +0.70 -6.068e-06 -3.933e-06 -1.513e-05 +0.60 +0.000e+00 +0.000e+00 +0.000e+00 +0.40 +0.000e+00 +0.000e+00 +0.000e+00 +0.20 +0.000e+00 +0.000e+00 +0.000e+00 +0.00 +0.000e+00 +0.000e+00 +0.000e+00 | | [Ramp] |Variable typ min max dV/dt_r 0.48/0.32n 0.46/0.34n 0.48/0.26n dV/dt_f 0.47/0.30n 0.45/0.33n 0.49/0.26n | From owner-ibis Fri Nov 13 18:22:55 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA03978 for ; Fri, 13 Nov 1998 18:22:54 -0800 (PST) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA00311; Fri, 13 Nov 1998 18:17:49 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id SAA28632; Fri, 13 Nov 1998 18:17:50 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA21131; Fri, 13 Nov 98 18:17:48 PST Date: Fri, 13 Nov 98 18:17:48 PST Message-Id: <9811140217.AA21131@bob> To: ibis-users@vhdl.org, shuq@cisco.com Subject: Re: *_dut params for waveform tables Syed: Some comments (and opinions) are in your text. Bob Ross Mentor Graphics > Date: Tue, 10 Nov 1998 10:43:49 -0800 (PST) > From: Syed Huq > Message-Id: <199811101843.KAA06215@jasper.cisco.com> > To: ibis-users@vhdl.org > Subject: *_dut params for waveform tables > IBISgurus, > For waveform tables, there are sub-params called R_dut, L_dut and C_dut. These > are same as R_pkg, L_pkg and C_pkg. From talking to a few IBIS experts I > understand that waveform tables should be generated without any pkg parasitics. > Simulators will attach the package parasitcs to the waveform tables and > run simulations. > That means, do not include *_dut in your s2ibis2 translation. If that is true, > > Why does s2ibis2 include R_d, L_d and C_d parameters ? It was designed to comform with the Version 2.1 Spec. > Why does IBIS even have *_dut parameters in the spec ? In retrospect this may have not been a good decision. However, at the time we wanted to be able to document the package parasitics when you really had to extract waveforms from the pin (versus the die). However, may of us learned after the fact that the values themselves may lead to time-constant numerical problems during simulation. It may be theoretically possible to deal with these problems with smoothing algorithms, but in practice it is safer to not use the values. > How does one avoid double counting of pkg numbers for V/T ? If the package effects are negligible, then a suitable accurate model might be constructed by just not using the DUT values. Another method might be to time scale the V/T table to compensate for the measurement degradation - if the degradation can be determined. > Are the *_dut only for measurement based IBIS models ? They were intended for measurement models and should never be used for Spice models where the package parameters can be removed. > Regards, > Syed > Cisco Systems,Inc From owner-ibis Fri Nov 13 18:32:21 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA03986 for ; Fri, 13 Nov 1998 18:32:20 -0800 (PST) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA01388; Fri, 13 Nov 1998 18:27:15 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id SAA29199; Fri, 13 Nov 1998 18:27:15 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA21140; Fri, 13 Nov 98 18:27:13 PST Date: Fri, 13 Nov 98 18:27:13 PST Message-Id: <9811140227.AA21140@bob> To: ibis-users@eda.org, nikolai@avanticorp.com Subject: Re: ecl models in ibis Nik: Answers to your questions are in your text. Bob Ross Mentor Graphics > From: nikolai@avanticorp.com > Date: Fri, 13 Nov 1998 14:26:48 -0800 (PST) > Message-Id: <199811132226.OAA28977@iris.src.avanticorp.com> > To: ibis-users@eda.org > Subject: ecl models in ibis > IBIS Gurus, Experst, Inventors, and Developers: > Can anybody clarify the following ECL model related issues in IBIS. > Below is an excerpt from IBIS file (downloaded from internet). > I have 2 questions regasrding these data. > 1) Why current in PU/PD tables is always negative? Why > the buffer "ECL_OBUF3_5" always source current and never sink current? > Is this something "ECL_OBUF3_5" model specific or it is a typical case for > Output_ECL buffer? The currents are negative because they follow the polarity convention that currents are positive when they are flowing into the pin. Output_ECL buffers typically source current in both the high and low stages. > 2) regarding: > [Voltage Range] 0.0 0.0 0.0 > [Pulldown Reference] 0.0 0.0 0.0 > [Power Clamp Reference] 0.0 0.0 0.0 > [GND Clamp Reference] -3.3 -3.0 -3.8 > Why [Pulldown Reference] = 0, why not to use [Pulldown Reference] = -3.3V ? The IBIS Spec set the reference voltage for BOTH the Pulldown and Pullup tables to the highest rail - in this case 0 Volts. So this table follows the Standard. > THis question is more about conventions used. > It is clear what voltages are applied. Why not to use notations: > [Voltage Range] 0.0 0.0 0.0 > [Pullup Reference] 0.0 0.0 0.0 (*) > [Pulldown Reference] -3.3 -3.0 -3.8 > [Power Clamp Reference] 0.0 0.0 0.0 (*) > [GND Clamp Reference] -3.3 -3.0 -3.8 > (*) indicate optional parameter (no need to include it, but no harm if it is > given) We did treat the ECL case as different. thus the conventions you suggest do not work. > Thank you > Nik > nikolai@avanticorp.com From owner-ibis Mon Nov 16 15:35:58 1998 Received: from serf.lsscorp.com (serf.lsscorp.com [206.86.154.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA11034 for ; Mon, 16 Nov 1998 15:35:57 -0800 (PST) Received: from athens (athens.lsscorp.com [206.86.154.27]) by serf.lsscorp.com (8.9.1a/8.9.1) with ESMTP id PAA30643; Mon, 16 Nov 1998 15:30:53 -0800 Received: by athens (SMI-8.6/8.6.9) id PAA15014; Mon, 16 Nov 1998 15:30:42 -0800 Date: Mon, 16 Nov 1998 15:30:42 -0800 From: Sagheer Ahmad Message-Id: <199811162330.PAA15014@athens> To: ibis-users@eda.org Subject: convergence problem Cc: sagheer@lsscorp.com X-Sun-Charset: US-ASCII I am trying to do IBIS modeling of my output buffer (vdd= 3,3.3,3.6 volt). While simulating, using hspice for getting pull-up data, circuit does't converge for DC as well as TRAN analsis (beyond 3.8volt and below -2volt of out voltage). And it looks correct that output buffers should not converge (if there are no clamp/ESD diodes) in those conditions. If that happens that what should I should. Should I truncate the pull-up range (-vdd to vdd*2) to -2v to 3.8v only. Or there is some other solution possible. Please help me out. I am stuck. Thanks in advance, Sagheer at Interra. From owner-ibis Mon Nov 16 16:49:27 1998 Received: from mail.huawei.com.cn ([202.96.135.132]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA11171 for ; Mon, 16 Nov 1998 16:49:05 -0800 (PST) Received: from huawei.com.cn ([10.102.11.119]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA11447 for ; Tue, 17 Nov 1998 08:42:43 +0800 Message-ID: <3650C662.D35D4E7D@huawei.com.cn> Date: Tue, 17 Nov 1998 08:42:10 +0800 From: zhoujun Reply-To: zhoujun@huawei.com.cn X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ibis-users@eda.org Subject: ask for help to read document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Lady and Gentlemen, I am engineer working on the IBIS modeling in the Company Huawei tech. Co., in china. We want to convert the Hspice model into IBIS model and we have loaded down the converting software spi_tran ,the unix version software. But in the directory docs the s2ibis process flow is in 'fm' format. I can't read the guideline for the converting tool. So I hope you can help me to solve this problem, with which software can I read this guide document? I am looking forward your early reply. Best regards ***************************************************** Zhou Jun PH: 86-755-6540501 CAD group Found. Dept. R&D FAX: 86-755-6540499 Kefa road Science-based industrial Park Nanshan District, shenzhen 518057 P.R.China Email: zhoujun@huawei.com.cn ***************************************************** From owner-ibis Mon Nov 16 17:01:22 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA11209 for ; Mon, 16 Nov 1998 17:01:21 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id QAA15352; Mon, 16 Nov 1998 16:55:53 -0800 (PST) Date: Mon, 16 Nov 1998 16:55:53 -0800 (PST) From: Syed Huq Message-Id: <199811170055.QAA15352@jasper.cisco.com> To: ibis-users@eda.org, zhoujun@huawei.com.cn Subject: Re: ask for help to read document Mime-Version: 1.0 Content-Type: multipart/mixed;boundary=6a50_1432-4b03_7900-1104_4fa5 --6a50_1432-4b03_7900-1104_4fa5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: IDj756EElEHImxxlS2D/8A== X-Sun-Data-Type: text Hello, The .fm is a FrameMaker file and can only be opened thru FrameMaker. I have converted the file to 'text' only and attaching it for you. Hope this helps. Syed. Cisco Systems,Inc > From zhoujun@huawei.com.cn Mon Nov 16 16:46:05 1998 > X-SMAP-Received-From: outside > Date: Tue, 17 Nov 1998 08:42:10 +0800 > From: zhoujun > MIME-Version: 1.0 > To: ibis-users@eda.org > Subject: ask for help to read document > Content-Transfer-Encoding: 7bit > > Dear Lady and Gentlemen, > > I am engineer working on the IBIS modeling in the > Company Huawei tech. Co., in china. > > We want to convert the Hspice model into IBIS model > and we have loaded down the converting software spi_tran > ,the unix version software. But in the directory docs the > s2ibis process flow is in 'fm' format. I can't read the > guideline for the converting tool. So I hope you can help > me to solve this problem, with which software can I read > this guide document? > > I am looking forward your early reply. > > > Best regards > > > ***************************************************** > Zhou Jun PH: > 86-755-6540501 > CAD group Found. Dept. R&D FAX: 86-755-6540499 > Kefa road > Science-based industrial Park > Nanshan District, shenzhen 518057 > P.R.China Email: zhoujun@huawei.com.cn > ***************************************************** > > --6a50_1432-4b03_7900-1104_4fa5 Content-Type: text/plain; charset=ISO-8859-1; name=s2ibis_process_flow.txt Content-Transfer-Encoding: quoted-printable Content-MD5: xi1wbG8r/LmaUJ2H3ozeUQ== Content-Description: s2ibis_process_flow.txt Content-Disposition: attachment; filename=s2ibis_process_flow.txt X-Sun-Data-Type: text S2IBIS Process Flow 1. Introduction This document explains the current state of s2ibis process flow and the = enhancements being made in phase 2. =09 2. Product Description 2.1 Overview of current use model To understand the use model targeted for this functionality, it is = necessary to first understand how the s2ibis2 shareware works, as it = will be leveraged in this effort. In s2ibis2, the user is made to embed = information in the header of the input SPICE deck as SPICE comments in = order to produce a completed IBIS file. Then s2ibis2 is run on the file, = and the deck is stimulated to produce SPICE output data. This data is = concatenated into the final IBIS file. In our use model, a single IO buffer model is generated at a time, with = the process driven from the UI. Rather than create a text header in the = SPICE deck with SPICE comment lines, all of the required data to = generate the complete IOCell is filled into fields in a form. This will = contain a means to specify the input SPICE deck, as well as items like = Polarity, whether VT waveforms for Rising_ and Falling_Waveform data are = to be produced, etc., that are relevant to the SPICE translation = process. Then the s2ibis2 code is invoked. This fills in the data for the = following: =B7 rising and falling slew rates =B7 rising and falling waveforms (if requested) =B7 VI curves This will create the output .ibs file in IBIS format. 2.2 Dependencies =B7 For the translator to run, the required host simulator executable is = licensed and in your path. The UI must provide a means to point to this. =B7 s2ibis code from NCSU =B7 ibischk code =B7 SigNoise License (required ONLY for full checks to ensure that the = model works fine with the simulator) 2.3 Current State The s2i tool developed in Phase 1 provides UI for accepting all user = inputs, creates the necessary SPICE stimulus. Using s2ibis2, it creates = the IBIS model which is checked using ibischk2. User can view/edit the = IBIS file that has been created. 2.4 New Features 2.4.1 Preparation of SPICE file (this is currently done manually and = would have to be facilitated to the extent possible). 2.4.2 SPICECheck to ensure that all prerequisites are complete and the = model runs and converges with a typical load (50 pF OR as specified in = the spec sheet). 2.4.3 Postprocessing of IBIS data 2.4.4 ibis2signoise to generate .dml file 2.4.5 dmlcheck and postprocessing of .dml file if required. 2.4.6 Verification of Model in SPICE, necessary SPICE file preparation = and comparing the output of SPICE run with Signoise output The above three features (4.4.4 to 4.4.6) are all model development = process features for optimization and verification of models. These are = absolutely required for our model development process and to enable = advanced customers to develop and optimize .dml files but the SPICE to = IBIS utility itself should be independent and produce an intermediary = IBIS file as an industry standard supporter. 2.4.7 Graphics Feature: To view the plots 2.4.8 S2IBIS2 fixes 2.5 Functional Description 2.5.1 SPICECheck This module must verify that (this can be merged with premodeling step): =B7 all prerequisites are complete =B7 the model runs and converges, by running a simple test case driving = a test (ex. 50 pF load) =B7=09 2.5.2 Preparation of SPICE file (premodeling) The required changes need to be done in the SPICE file should either get = done automatically with inputs given by the user OR the feature should = guide the user to perform necessary edits through required checks on = SPICE file and issue of messages, warnings and errors statements. This includes: =B7 Check that the file set is complete from simulation perspective. =B7 Removal of statements which are for analysis (ex: transient, DC) or = act as test stimulus (ex: pulse, piecewise linear) and test loads. =B7 Building of subcircuit which connects to the converted SPICE deck to = s2ibis program. =B7 Verify that there are no floating nodes. =B7 Providing options for printing, method, DC-step, Time step, ingold = value, post, list. =B7 Adding reference supplies for buffers which use more than one supply =B7 Addition of behavioral inverter for handling ECL devices. =B7 Ensure that package parasitics do not affect VI and VT curves and = that package parasitics included for power and gnd bus and removed from = SIGNAL pins (as per IBIS). 2.5.3 Removal of Non-monotonicity of .ibs file =B7 Only non-monotonicities would be removed. The algorithm would be to = extend the value of previous point for the non monotonic point. This = step could be executed irrespective of whether user would go ahead with = SigNoise or not to have a first order cleaned-up .ibs file (Pullup and = Pulldown data may be non-monotonic for tri-state buffers without the = POWER and GND Clamp and should be left as is). Code from enhanced = "dmlcheck" will be used to remove monotonicity. This feature should solve the following two problems: 1) remove = non-monotonicities yes/no to allow for some cases that do have inherent = non-monotonicities. 2) extrapolation that would chop off the anomalous = extreme V/I data that sometimes results from SPICE and simply replace = with extrapolated data. 2.5.4 "ibis2signoise" and Postprocessing of .dml The post processing phase shall include extrapolation of the data to the = required ranges to facilitate convergence and simulation. Note that part = of the post-processing is being incorporated in the "dmlcheck" utility. =B7 Smoothening the curves. This should help eliminate problems like = jagged VI curves, or insufficient data points around the knee of a curve =B7 Extrapolation over the required -VCC to 2VCC range. SPICE decks = often produce bogus data outside of their normal ranges of operation. It = is often required to delete the last section of curve generated by = s2ibis2 and extrapolate over the rest of the required voltage range. The = user should be able to specify whether linear or logarithmic = extrapolation is to be used as a minimum (this may be debatable).=20 =B7 ibis2signoise and .dml processing to add=20 - VOH/VOL - Technology - Temperature Coefficients for VOH/VOL for ECL outputs 2.5.5 Model Verification =B7 Verification of model by simulating at the test load. =B7 The verification of the model against SPICE simulation results at = same test load as for SigNoise and reporting any mismatches. If the = mismatches exceed 5%, these should be investigated and possible = explanation provided (the criteria for comparison could be to take = difference of values on Y axis (Voltage) between SPICE and SigNoise = simulation every 1/10th of stimulus duration and get the average value = of deviation).=20 =B7 This should be done for all the cells for a given device. 2.5.6 Graphical Interface (To view the plots) =B7 These capabilities should be similar to IBIS Center features = (scaling, zoom fit, scale selection for X and Y axis at a minimum). This = feature should be derived from SigWave (by plugging in relevant code). 2.5.7 Derive Model =B7 Based on the IBIS data available for the cells, it should be = possible to derive the model for a new device by selecting Pullup, = Pulldown, GND Clamp and Power Clamp data from different cells. 2.5.8 Device Level Model =B7 It should be possible to create a device level model based on the = IOCell level models by associating these with device terminals. =B7 "dml2ibis" should be available to get the correct .ibs file from the = post-processed .dml file. Model Verification features are absolutely essential for an optimized = model development process. These are really critical features for = SigNoise to make it essential to the model development process. Basic = Spice to IBIS feature is required as an industry standard enabler and = leverage this to provide the steps of entire process.=20 --6a50_1432-4b03_7900-1104_4fa5-- From owner-ibis Mon Nov 16 17:01:40 1998 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA11214 for ; Mon, 16 Nov 1998 17:01:40 -0800 (PST) Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id AAA00170; Tue, 17 Nov 1998 00:57:03 GMT Message-Id: <199811170057.AAA00170@calliope1.fm.intel.com> Received: by FMSMSX17 with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Nov 1998 16:57:02 -0800 From: "Muranyi, Arpad" To: "\"ibis-users@eda.org\" " , "\"Sagheer Ahmad\" " Cc: "\"sagheer@lsscorp.com\" " Subject: RE: convergence problem Date: Mon, 16 Nov 1998 16:09:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sagheer, Not knowing how you are doing this in HSPICE (i.e. what is your behavioral model constructed) it is hard to give you exact solutions. However, there are generally two types of problems, and is seems that you got them both. If your circuit doesn't converge for DC (i.e. it can't find a DC operating point before the transient simulation begins), chances are that your I-V curves have more than just one solution, or the solution is just not there. To overcome this problem you can use the .IC statement to help the simulator to find a DC operating point solution. Once you got the transients running, you might get "time step too small" errors, if your behavioral elements violate the relative (iteration-to-iteration) currents and/or voltages exceed the tolerance limits. Since controlled sources have a tendency to behave in an "ideal" fashion, this condition can happen very easily, especially if you are using tight tolerance settings (like the accurate option). Your question, however, is not entirely clear to me when you say "doesn't converge ... (beyond 3.8 volt and below -2 volt of out voltage)". What are you talking about? A situation when the signal on the output goes above 3.8 or below -2 volts? Are you saying that if the voltage is in-between you have no problems at all? If that is the case you may need to extend the I-V curve range to cover the voltages you expect to see on the node. HSPICE tends to continue the data tables of PWL sources (I assume your I-V curves also) horizontally in the undefined range, which may cause the problem. I hope these hints might get you going in the right direction. Arpad Muranyi =========================================================================== I am trying to do IBIS modeling of my output buffer (vdd= 3,3.3,3.6 volt). While simulating, using hspice for getting pull-up data, circuit does't converge for DC as well as TRAN analsis (beyond 3.8volt and below -2volt of out voltage). And it looks correct that output buffers should not converge (if there are no clamp/ESD diodes) in those conditions. If that happens that what should I should. Should I truncate the pull-up range (-vdd to vdd*2) to -2v to 3.8v only. Or there is some other solution possible. Please help me out. I am stuck. Thanks in advance, Sagheer at Interra. From owner-ibis Mon Nov 16 17:24:14 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA11281 for ; Mon, 16 Nov 1998 17:24:12 -0800 (PST) Received: from Kellee98 ([192.168.148.110]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id QAA24631; Mon, 16 Nov 1998 16:59:07 -0800 Message-Id: <199811170059.QAA24631@mail.hyperlynx.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 16 Nov 1998 16:59:17 -0800 To: Sagheer Ahmad , ibis-users@eda.org From: Kellee Crisafulli Subject: Re: convergence problem Cc: sagheer@lsscorp.com In-Reply-To: <199811162330.PAA15014@athens> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id RAA11282 If you have exhaused methods to fix the model in HSPICE you might consider the following: Do your best to extrapolate the likely values. If the HSPICE model works within the range for which the chip is most likely to operate then the only time this data is needed is if a circuit uses the model out side this range (i.e. abnormal case). The simulator that uses the IBIS model needs to know what to do so it doesn't have the same problem that HSPICE did. Typically you might consider a linear extrapolation of the last valid data. Or if you have a "feel" for this device you might know for example it is likely to saturate and roll off. You might than include a best guess and roll off the current. Best wishes.. Kellee At 03:30 PM 11/16/98 -0800, Sagheer Ahmad wrote: >I am trying to do IBIS modeling of my output buffer (vdd= 3,3.3,3.6 volt). While simulating, >using hspice for getting pull-up data, circuit does't converge for DC as well as TRAN analsis (beyond >3.8volt and below -2volt of out voltage). > >And it looks correct that output buffers should not converge (if there are no clamp/ESD diodes) in those >conditions. If that happens that what should I should. Should I truncate the pull-up range (-vdd to vdd*2) >to -2v to 3.8v only. Or there is some other solution possible. > > >Please help me out. I am stuck. > >Thanks in advance, >Sagheer at Interra. > --------------------------------------------------------- Have a great day.... Kellee Crisafulli at HyperLynx SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Tue Nov 17 17:03:40 1998 Received: from hotmail.com (f130.hotmail.com [207.82.251.9]) by server.eda.org (8.8.5/8.8.3) with SMTP id RAA14729 for ; Tue, 17 Nov 1998 17:03:39 -0800 (PST) Received: (qmail 20434 invoked by uid 0); 18 Nov 1998 00:58:32 -0000 Message-ID: <19981118005832.20433.qmail@hotmail.com> Received: from 147.145.40.40 by www.hotmail.com with HTTP; Tue, 17 Nov 1998 16:58:32 PST X-Originating-IP: [147.145.40.40] From: "bharat sinha" To: ibis@vhdl.org Cc: ibis-users@eda.org MIME-Version: 1.0 Content-Type: text/plain Date: Tue, 17 Nov 1998 16:58:32 PST hI, Could you please tell me why are the PULL UP/PULL DOWN curves seen thru s2iplt having kinks and spikes. They are weird and triangular. The Power/Gnd Clamps are O.K. I have generated the IBIS files successfully. They have passed the IBISCHK2 .Only warnings are there. The cell under question is a Impedance controlled bUffer. The foll warnings are there TYP AC Rising Endpoints(-0.0V, 1.76 V) not within 0.035V (2%) of (-0.70, 0.00V) on VI curves for 100 Ohms to 0V. TYP AC Falling Endpoints(0.67V, 2.5 V) not within 0.037V (2%) of (-0.70, 2.50V) on VI curves for 100 Ohms to 2.5V. MIN AC Rising Endpoints (0.0, 1.5V) not within 0.031V (2%) of (-0.70V, 4.87V) on VI curves for 100 ohms to 0v. MIN AC Falling Endpoints (0.71, 2.31V) not within 0.032V (2%) of (-0.70V, 4.92V) on VI curves for 100 ohms to 2.5V Please reply ASAP thanx Bharat ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Wed Nov 18 08:07:45 1998 Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [199.92.133.126]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA17002 for ; Wed, 18 Nov 1998 08:07:44 -0800 (PST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA09491 for ; Wed, 18 Nov 1998 11:03:46 -0500 (EST) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma009389; Wed, 18 Nov 98 11:03:26 -0500 Received: from olympus.ctron.com (olympus [134.141.72.253]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id LAA25861 for ; Wed, 18 Nov 1998 11:02:41 -0500 (EST) Received: from warhawk.ctron.com (warhawk.ctron.com [134.141.72.217]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id LAA21285; Wed, 18 Nov 1998 11:02:06 -0500 (EST) Received: (from cmartin@localhost) by warhawk.ctron.com (8.8.7/8.8.7) id KAA14283; Wed, 18 Nov 1998 10:52:17 -0500 (EST) Date: Wed, 18 Nov 1998 10:52:17 -0500 (EST) From: "Charles W. Martin" Message-Id: <199811181552.KAA14283@warhawk.ctron.com> To: ibis-users@eda.org Subject: Models & EDA Vendors Cc: guyp@cabletron.com I've recently seen a demo for MGC's ICX tools (Including Tau for timing verification). There software uses native IBIS models for timing and signal integrity estimations on the fly, and simulation. ICX mentions a library of 10K parts, as a first tier, afterwards there are two-tiers which cost the end-user progressively more for ICX to develop ibis models. ICX mentions that they are working with ic vendors providing them with tools which would allow them to develop accurate ibis models themselves. I'd like some feedback from anyone (ICX users, IC Vendors, etc..) who have worked with ICX on developing IBIS models. Secondly, we've found that many of the parts we'd like to simulate with don't exist in their library. While it's expected that newer components/ technologies might not have models, some of the models that are lacking are typical everyday parts/technologies. What's the preferred approach to obtaining and verifying accuracy of these parts? Lastly, IBIS is a great idea, and the people behind the scenes really deserve a round of applause. However, I'm interested in people's opinions on how widely available _accurate_ models are from component vendors. Thanks for your feedback, Chuck Charles Martin Cabletron Systems, Inc. EDA Tools cmartin@ctron.com Phone: (603) 337-2973 Fax : (603) 337-1764 From owner-ibis Wed Nov 18 10:18:15 1998 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA17369 for ; Wed, 18 Nov 1998 10:18:14 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA09788; Wed, 18 Nov 1998 10:13:08 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA01265; Wed, 18 Nov 1998 10:13:09 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA25493; Wed, 18 Nov 98 10:13:07 PST Date: Wed, 18 Nov 98 10:13:07 PST Message-Id: <9811181813.AA25493@bob> To: ibis-users@eda.org Subject: Forwarded: Re: Models & EDA Vendors Charles: You ask a very good question regarding how users validate IBIS models. The IBIS User's group plus many companies are dealing with this issue. However, we regard this reflector off limits for public discussion or feedback on specific company activities or semiconductor products because of EIA policy and because many of the companies and their competitors are funding the IBIS activity. The signal integrity reflector is open to such discussion, or specific feedback could be sent to Charles directy. Bob Ross Mentor Graphics > Date: Wed, 18 Nov 1998 10:52:17 -0500 (EST) > From: "Charles W. Martin" > To: ibis-users@eda.org > Subject: Models & EDA Vendors > Cc: guyp@cabletron.com > I've recently seen a demo for MGC's ICX tools (Including Tau for timing > verification). There software uses native IBIS models for timing and > signal integrity estimations on the fly, and simulation. > ICX mentions a library of 10K parts, as a first tier, afterwards there > are two-tiers which cost the end-user progressively more for ICX to develop > ibis models. > ICX mentions that they are working with ic vendors providing them with > tools which would allow them to develop accurate ibis models themselves. > I'd like some feedback from anyone (ICX users, IC Vendors, etc..) who > have worked with ICX on developing IBIS models. > Secondly, we've found that many of the parts we'd like to simulate with > don't exist in their library. While it's expected that newer components/ > technologies might not have models, some of the models that are lacking > are typical everyday parts/technologies. What's the preferred approach > to obtaining and verifying accuracy of these parts? > Lastly, IBIS is a great idea, and the people behind the scenes really > deserve a round of applause. However, I'm interested in people's opinions > on how widely available _accurate_ models are from component vendors. > Thanks for your feedback, > Chuck > Charles Martin > Cabletron Systems, Inc. > EDA Tools > cmartin@ctron.com > Phone: (603) 337-2973 > Fax : (603) 337-1764 > -------- End of Forwarded Message From owner-ibis Wed Nov 18 11:06:35 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA17497 for ; Wed, 18 Nov 1998 11:06:34 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id LAA13392; Wed, 18 Nov 1998 11:00:30 -0800 (PST) Date: Wed, 18 Nov 1998 11:00:30 -0800 (PST) From: Syed Huq Message-Id: <199811181900.LAA13392@jasper.cisco.com> To: ibis@vhdl.org, bharat_sinha@hotmail.com Subject: Re: Your Message Sent on Tue, 17 Nov 1998 16:58:32 PST Cc: ibis-users@eda.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Cq9QQK/y6/A0vm/03ddcWA== Hi, What you see as kinks/spikes are usually in the ranges where s2ibis2 has done some extrapolation. If they are in the region beyond which the simulator has no interest in, they may be ignored. If you see kinks/spikes in the region of operation for your device then the derived data should be checkout out for errors. Regards, Syed. Cisco Systems,Inc > > hI, > Could you please tell me why are the PULL UP/PULL DOWN curves seen thru > s2iplt having kinks and spikes. They are weird and triangular. > The Power/Gnd Clamps are O.K. > From owner-ibis Wed Nov 18 11:13:05 1998 Received: from mail2.teleport.com (mail2.teleport.com [192.108.254.43]) by server.eda.org (8.8.5/8.8.3) with SMTP id LAA17514 for ; Wed, 18 Nov 1998 11:13:05 -0800 (PST) Received: (qmail 10673 invoked from network); 18 Nov 1998 19:08:26 -0000 Received: from pdx77-i48-38.teleport.com (HELO teleport.com) (204.202.175.52) by mail2.teleport.com with SMTP; 18 Nov 1998 19:08:26 -0000 Message-ID: <36531AE9.95B01B52@teleport.com> Date: Wed, 18 Nov 1998 11:07:21 -0800 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.5 [en]C-DIAL (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Charles W. Martin" CC: ibis-users@eda.org, guyp@cabletron.com Subject: Re: Models & EDA Vendors References: <199811181552.KAA14283@warhawk.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles, Generally, all models from component vendors, whether IBIS, Quad, or Spice, should be considered suspect until used and correlated against actual in-circuit operation. Oftentimes models are not given the care that they deserve at the IC vendor. They are often "extracted" by someone who doesn't understand the problem. And the problem is multifold .... Are the IV curves and waveform tables modeled accurately? If care is taken, the accuracy of an IBIS model can correlate with high precision to original HSPICE simulations or physical measurements. If not, you might be in the right ballpark, you might not. ICX/Zeelan models are based upon physical measurements, and so have highly accurate characteristics. However, these are not worst case measurements. They are based upon a sampling of typical silicon. Care must be taken by the design engineer to insure that worst case behavior is taken into account. However, in the absence of manufacturer's models, these are the best you'll get ... and they are very good. I use ICX/Zeelan models in my work when manufacturer models are not available. Are packages modeled correctly? In order to correctly model package effects with high performance silicon devices with sub 500 ps rise times, it is necessary to model the package in detail. This usually requires a 3D field solver and results in numerous sections of transmission line. Detailed package analysis by vendors is rarely provided. Intel is an exception to this rule. There may be other vendors which also provide this data in Ibis or Quad format, however, I am aware of few. It is generally next to impossible to get this data from a manufacturer in any format, even Spice. So are we totally out of the ballpark for most manufacturers? Well, that depends. If you are concerned about tight timing margins in the sub 500 ps range, then highly accurate model and package characterization are absolutely necessary. You must work with your chip suppliers to provide you accurate data. This often takes multiple iterations to "help" them understand your problem. Intel is an example of a vendor who has "generally" taken care in characterizing their devices for worst case margin analysis. However, if you are concerned about signal integrity effects alone, (non-monotonicity, overshoot, undershoot, ringback, and crosstalk) and their effect upon correct device operation and timing, and have a bit of timing margin to spare, then the IBIS models which are available from ICX/Zeelan, other independent model vendors, and IC manufacturers will fit the bill. Using these models one can perform very good board signal integrity analysis. In my work, I use both options. I am often called upon to analyze systems that have sub 500 ps and even sub 150 ps timing margins. In these cases, I work closely with the manufacturers to obtain IBIS and HSPICE device and package models. I often have to perform my own HSPICE to IBIS conversions and correlations in order to "know" that the data I am getting from simulations are accurate. In other cases, I perform analysis on designs that are not pushing the state of the art in performance, but are pushing the density and complexity boundaries of a pc board. Here I am concerned about noise, overshoot, undershoot, crosstalk and non-monotonicity of asynchronous signals and clocks. I do complete board analysis across worst case device corners. However, I usually have at least 1 ns or more of timing margins on most busses. In these cases I have had incredible success with using manufacturer's, and ICX/Zeelan based IBIS models. I still have to check them for reasonableness, and I have to run them through IBIS parser checks to ready them for my ICX simulation environments, but these are minor nuisances compared to having no simulation models at all. I hope my comments have helped. Regards, Scott "Charles W. Martin" wrote: > I've recently seen a demo for MGC's ICX tools (Including Tau for timing > verification). There software uses native IBIS models for timing and > signal integrity estimations on the fly, and simulation. > > ICX mentions a library of 10K parts, as a first tier, afterwards there > are two-tiers which cost the end-user progressively more for ICX to develop > ibis models. > > ICX mentions that they are working with ic vendors providing them with > tools which would allow them to develop accurate ibis models themselves. > I'd like some feedback from anyone (ICX users, IC Vendors, etc..) who > have worked with ICX on developing IBIS models. > > Secondly, we've found that many of the parts we'd like to simulate with > don't exist in their library. While it's expected that newer components/ > technologies might not have models, some of the models that are lacking > are typical everyday parts/technologies. What's the preferred approach > to obtaining and verifying accuracy of these parts? > > Lastly, IBIS is a great idea, and the people behind the scenes really > deserve a round of applause. However, I'm interested in people's opinions > on how widely available _accurate_ models are from component vendors. > > Thanks for your feedback, > > Chuck > > Charles Martin > Cabletron Systems, Inc. > EDA Tools > cmartin@ctron.com > Phone: (603) 337-2973 > Fax : (603) 337-1764 > -- ___________________________ Scott McMorrow Principal Engineer SiQual mailto:scottmc@teleport.com ___________________________ From owner-ibis Wed Nov 18 15:28:34 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA18025 for ; Wed, 18 Nov 1998 15:28:33 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id PAA07144; Wed, 18 Nov 1998 15:23:24 -0800 (PST) Date: Wed, 18 Nov 1998 15:23:24 -0800 (PST) From: Syed Huq Message-Id: <199811182323.PAA07144@jasper.cisco.com> To: bharat_sinha@hotmail.com Subject: Re: Imp Cc: ibis-users@vhdl.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: b6LX1x4I2KQ7TIRuhXdQTA== Hello, First of all you are using a version of the translator that is known to have certain bugs. This is obvious if you look at the table. This particular version only shows two digits after the decimel and also does not format the data properly. (See data below) Download the s2ibis2_fix.tar.Z version from the website: http://www.eda.org/pub/ibis/s2ibis/s2ibis2_v1.1/ Your .s2i file may also not be set right pointing to the right spice nodes. This could result in bad pullup and pulldown tables. Regards, Syed Cisco Systems,Inc > From bharat_sinha@hotmail.com Wed Nov 18 15:08:10 1998 > X-SMAP-Received-From: outside > X-Originating-IP: [147.145.40.40] > From: "bharat sinha" > To: shuq@cisco.com > Cc: ibis@vhdl.org > Subject: Imp > MIME-Version: 1.0 > Date: Wed, 18 Nov 1998 15:06:14 PST > > > Hi, > This is just one of the sample files. Could you please spare a few > minutes and see it thru S2IPLT. See how weird the waveforms are. > This is a cell about which I had mailed warnings etc. yeterday. > This problem is there with at least 1000 more cells! > .please help me out. > Thanx > Bharat > >> 4.20 -0.41A -0.57A -0.27A > >> 4.40 -0.51A -0.66A -0.37A > >> 4.60 -0.61A -0.76A -0.47A > >> 4.80 -0.71A -0.87A -0.57A > >> 5.00 -0.81A -0.97A -0.67A > >>-133287736222332993536.00 0.00 1.00e 0.00 > >>-133287736222332993536.00 0.00 1.00e 0.00 > >>-133287736222332993536.00 0.00 1.00e 0.00 > >> 5.00 -0.81A -0.97A -0.67A > >>| From owner-ibis Wed Nov 18 15:50:20 1998 Received: from hpcsos.col.hp.com (hpcsos.col.hp.com [15.255.240.16]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA18063 for ; Wed, 18 Nov 1998 15:50:16 -0800 (PST) Received: from valencia.rsn.hp.com (valencia.rsn.hp.com [15.99.50.121]) by hpcsos.col.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id QAA07466 for ; Wed, 18 Nov 1998 16:45:41 -0700 (MST) Received: (from schumach@localhost) by valencia.rsn.hp.com (8.7.1/8.7.1) id RAA17395; Wed, 18 Nov 1998 17:39:34 -0600 (CST) From: "Richard A. Schumacher" Message-Id: <199811182339.RAA17395@valencia.rsn.hp.com> Subject: Re: Forwarded: Re: Models & EDA Vendors To: ibis-users@eda.org Date: Wed, 18 Nov 1998 17:39:33 CST Cc: schumach@valencia.rsn.hp.com In-Reply-To: <9811181813.AA25493@bob>; from "Bob Ross" at Nov 18, 98 10:13 am X-Mailer: Elm [revision: 212.4] Those wishing to join the signal integrity email list may do so by sending email to majordomo@silab.eng.sun.com In the BODY of the message place: subscribe si-list regards, Richard Schumacher Hewlett Packard > You ask a very good question regarding how users validate > IBIS models. The IBIS User's group plus many companies > are dealing with this issue. > > However, we regard this reflector off limits for public discussion > or feedback on specific company activities or semiconductor > products because of EIA policy and because many of the companies and > their competitors are funding the IBIS activity. The signal > integrity reflector is open to such discussion, or specific > feedback could be sent to Charles directy. > > Bob Ross > Mentor Graphics From owner-ibis Wed Nov 18 19:15:11 1998 Received: from exchange2.via.com.tw (exchange2.via.com.tw [202.145.217.249]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA18675 for ; Wed, 18 Nov 1998 19:14:58 -0800 (PST) Received: by exchange2.via.com.tw with Internet Mail Service (5.5.1960.3) id ; Thu, 19 Nov 1998 11:03:11 +0800 Message-ID: <4399E411E49ED111973000A0C92BD8A00C1332@exchange2.via.com.tw> From: Clarence Lin To: "'ibis-users@vhdl.org'" Subject: subscribe Date: Thu, 19 Nov 1998 11:03:09 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain subscribe clarencelin@via.com.tw From owner-ibis Mon Nov 23 14:34:23 1998 Received: from ntmail.qlc.com (ntmail.qlc.com [192.215.217.150]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA01944 for ; Mon, 23 Nov 1998 14:34:22 -0800 (PST) Received: by ntmail.qlc.com with Internet Mail Service (5.5.2232.9) id ; Mon, 23 Nov 1998 14:26:21 -0800 Message-ID: From: John Martin To: "'ibis-users@eda.org'" Subject: IBIS differential model questions Date: Mon, 23 Nov 1998 14:26:19 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) I am trying to build a differential IBIS model. I am not aware of a way to create a single IBIS model from a differential buffer which has two output pins and two independent voltage sources. It does not seem logical to create two IBIS models for one differential buffer, one for each output pin. Is there a way to create a single IBIS model for a differential I/O buffer using s2ibis2? I have read the section in the s2ibis2 manual that describes the differential pin list and it states that s2ibis2 does not process any of the information in that list, it simply copies it to the output file. I use s2ibis2 for Solaris to create IBIS models. Thanks, John Martin QLogic Corporation From owner-ibis Mon Nov 23 15:55:38 1998 Received: from hotmail.com (f107.hotmail.com [207.82.250.226]) by server.eda.org (8.8.5/8.8.3) with SMTP id PAA02170 for ; Mon, 23 Nov 1998 15:55:38 -0800 (PST) Received: (qmail 19751 invoked by uid 0); 23 Nov 1998 23:50:29 -0000 Message-ID: <19981123235029.19750.qmail@hotmail.com> Received: from 147.145.40.40 by www.hotmail.com with HTTP; Mon, 23 Nov 1998 15:50:29 PST X-Originating-IP: [147.145.40.40] From: "Shaggy Gonzalez" To: ibis-users@vhdl.org MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 23 Nov 1998 15:50:29 PST Hi , I generated an IBS Model for a cell which is an input buffer. Hence , it has only Power and Gnd Clamp information in the .ibs file. 1.Problem is that though the Gnnd Clamp is showing values from-2.5V to 2.5V, the Power Clamp is showing from -2.5V to 0V only.Is it O.K.? 2. All the max/min/typ values for Power Clmp table for all voltages between -2.5V to 0V are identical. Is that possible?When does it happen? Bye Shaggy ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Mon Nov 23 16:31:08 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA02800 for ; Mon, 23 Nov 1998 16:31:07 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id QAA04993; Mon, 23 Nov 1998 16:25:59 -0800 (PST) Date: Mon, 23 Nov 1998 16:25:59 -0800 (PST) From: Syed Huq Message-Id: <199811240025.QAA04993@jasper.cisco.com> To: ibis-users@vhdl.org, shaggy_gonzalez@hotmail.com Subject: Re: Your Message Sent on Mon, 23 Nov 1998 15:50:29 PST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: hyqiK3fXyuLkSF2WF1Ek9g== Hi, Power Clamp is swept from Vdd to 2Vdd but note that the data is offset by Vdd using this formula -> Vtable=Vdd-Vmeasured. That means: 0V = 2.5 - 2.5 (Vmeas = 2.5V) -2.5V = 2.5 - 5.0 (Vmeas = 2*Vdd) So the sweep range is correct. Regards, Syed. Cisco Systems, Inc > shaggy_gonzalez writes: > > 1.Problem is that though the Gnnd Clamp is showing values from-2.5V to > 2.5V, the Power Clamp is showing from -2.5V to 0V only.Is it O.K.? > From owner-ibis Mon Nov 23 17:12:52 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA02957 for ; Mon, 23 Nov 1998 17:12:50 -0800 (PST) Received: from Kellee98 ([192.168.148.110]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id RAA02631; Mon, 23 Nov 1998 17:08:06 -0800 Message-Id: <199811240108.RAA02631@mail.hyperlynx.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 23 Nov 1998 17:08:05 -0800 To: Syed Huq , ibis-users@vhdl.org, shaggy_gonzalez@hotmail.com From: Kellee Crisafulli Subject: Re: Your Message Sent on Mon, 23 Nov 1998 15:50:29 PST In-Reply-To: <199811240025.QAA04993@jasper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id RAA02966 Hi Syed,all Syed while I agree with you that the data is representing the normal forward bias region of the diode, the normal operating range of the device should also be included in the V/I table so we know the diode is off. Extrapolated data is likely to have it slightly on with uA's to mA's when the reverse leakage of the diode will actually be femto amps. This is simulator dependant however which is why the IBIS specification says this range should be defined. Perhaps I missed the point, is this a 2.5V power supply? i.e. the power clamp, -2.5 in table -> 5.0V 0V in table -> 2.5v +2.5 in table -> 0.0v +5.0 in table -> -2.5v so the Power Clamp table should span -2.5 to +5.0 At 04:25 PM 11/23/98 -0800, Syed Huq wrote: >Hi, > >Power Clamp is swept from Vdd to 2Vdd but note that the data is offset by >Vdd using this formula -> Vtable=Vdd-Vmeasured. > >That means: >0V = 2.5 - 2.5 (Vmeas = 2.5V) >-2.5V = 2.5 - 5.0 (Vmeas = 2*Vdd) > >So the sweep range is correct. >Regards, >Syed. >Cisco Systems, Inc > >> shaggy_gonzalez writes: >> >> 1.Problem is that though the Gnnd Clamp is showing values from-2.5V to >> 2.5V, the Power Clamp is showing from -2.5V to 0V only.Is it O.K.? >> > --------------------------------------------------------- Have a great day.... Kellee Crisafulli at HyperLynx SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Mon Nov 23 17:15:34 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA03005 for ; Mon, 23 Nov 1998 17:15:33 -0800 (PST) Received: from Kellee98 ([192.168.148.110]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id QAA02575; Mon, 23 Nov 1998 16:54:45 -0800 Message-Id: <199811240054.QAA02575@mail.hyperlynx.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 23 Nov 1998 16:54:44 -0800 To: "Shaggy Gonzalez" , ibis-users@vhdl.org From: Kellee Crisafulli Subject: Re: In-Reply-To: <19981123235029.19750.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id RAA03006 I am paraphrasing your questions, hope I have it right. Q:If the voltage range does not cover the 2Vcc to -Vcc range will the model still work: A: If a given simulation run enters the region for which the V/I data is not defined the simulation results are going to be different from simulator to simulator because the data was not defined. If the simulation never enters this region than it probably won't matter unless a simulator has trouble reach DC convergence. For the Power Clamp, positive voltage is in the normal operating region so the power clamp has no data in the normal operating region. While this may cause no problem if the value a 0V is 0 current and the simulator does not extrapolate it will cause a problem if the simulator does extrapolate. Bottom line -> this is a a potential problem. Q:IS min/typ/max all the same going to cause a simulation problem? A:Only if you care about min/max. If not then the model is fine. If so than you need to be aware that min/max conditions are not represented. At 03:50 PM 11/23/98 -0800, Shaggy Gonzalez wrote: >Hi , >I generated an IBS Model for a cell which is an input buffer. Hence , it >has only Power and Gnd Clamp information in the .ibs file. > >1.Problem is that though the Gnnd Clamp is showing values from-2.5V to >2.5V, the Power Clamp is showing from -2.5V to 0V only.Is it O.K.? > > 2. All the max/min/typ values for Power Clmp table for all voltages >between -2.5V to 0V are identical. Is that possible?When does it happen? >Bye >Shaggy > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > --------------------------------------------------------- Have a great day.... Kellee Crisafulli at HyperLynx SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Tue Nov 24 08:00:18 1998 Received: from ex2.elcsci.com ([198.102.179.235]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA05577 for ; Tue, 24 Nov 1998 08:00:17 -0800 (PST) Received: from aa1.elcsci.com (AA1 [198.47.1.58]) by ex2.elcsci.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id XKM0N1VX; Tue, 24 Nov 1998 07:54:47 -0800 Received: by AA1 with Internet Mail Service (5.5.2232.9) id ; Tue, 24 Nov 1998 10:49:41 -0500 Message-ID: From: Gary Templeton To: ibis-users@eda.org Subject: VOH as a function of Iout Date: Tue, 24 Nov 1998 10:49:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Hi all, I have been completing an electrical stress analysis of a design currently being assembled here at ESI. The noise margin calculation takes into account the loading of the output,since this load is much less than the maximum. This will result in a VOH that is greater than the worse case, specified value. The component being analyzed is an Altera Flex 10K (5V) device. The IBIS models available through Altera do not map VOH as a function of IOH. Multiple calls to Altera has not given me the data I would like. Do the tables provided by standard IBIS listings indicate VOH as a function of IOH? Thanks.... Gary Templeton ESI From owner-ibis Tue Nov 24 08:33:48 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA05691 for ; Tue, 24 Nov 1998 08:33:48 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id IAA06000; Tue, 24 Nov 1998 08:28:40 -0800 (PST) Date: Tue, 24 Nov 1998 08:28:40 -0800 (PST) From: Syed Huq Message-Id: <199811241628.IAA06000@jasper.cisco.com> To: ibis-users@eda.org, TempletonG@esi.com Subject: Re: VOH as a function of Iout Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: X9TrMmaOtbT7voAObSJizQ== Gary, Voh vs Ioh is the [Pullup] IBIS V/I table data. But note that the data is offset by Vdd and not referenced to GND. Regards, Syed. Cisco Systems,Inc > From TempletonG@esi.com Tue Nov 24 07:57:19 1998 > X-SMAP-Received-From: outside > From: Gary Templeton > To: ibis-users@eda.org > Subject: VOH as a function of Iout > Date: Tue, 24 Nov 1998 10:49:40 -0500 > MIME-Version: 1.0 > > Hi all, > > I have been completing an electrical stress analysis of a design currently > being assembled here at ESI. The noise margin calculation takes into account > the loading of the output,since this load is much less than the maximum. > This will result in a VOH that is greater than the worse case, specified > value. The component being analyzed is an Altera Flex 10K (5V) device. The > IBIS models available through Altera do not map VOH as a function of IOH. > Multiple calls to Altera has not given me the data I would like. Do the > tables provided by standard IBIS listings indicate VOH as a function of IOH? > > > Thanks.... > > Gary Templeton > ESI > From owner-ibis Tue Nov 24 11:59:51 1998 Received: from toga.it.dtu.dk (toga.it.dtu.dk [130.225.76.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA06281 for ; Tue, 24 Nov 1998 11:59:50 -0800 (PST) Received: from gfx5d (gfx5d.it.dtu.dk [192.38.72.110]) by toga.it.dtu.dk (8.9.0/8.9.0) with SMTP id UAA31769 for ; Tue, 24 Nov 1998 20:55:06 +0100 (MET) From: "Thomas Gleerup" To: Subject: unsubscribe Date: Tue, 24 Nov 1998 20:55:07 +0100 Message-ID: <000301be17e4$55c2e190$6e4826c0@gfx5d.it.dtu.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal unsubscribe From owner-ibis Tue Nov 24 12:44:02 1998 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA06350 for ; Tue, 24 Nov 1998 12:44:01 -0800 (PST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id OAA20147 for ; Tue, 24 Nov 1998 14:39:17 -0600 (CST) Comments: ( Received on ftpbox.mot.com from client mothost.mot.com, sender ra3862@email.sps.mot.com ) Received: from msgphx1.sps.mot.com (msgphx1.sps.mot.com [216.11.52.1]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id OAA00239 for ; Tue, 24 Nov 1998 14:39:17 -0600 (CST) Received: from email.sps.mot.com ([163.4.1.131]) by msgphx1.sps.mot.com (Netscape Messaging Server 3.6) with ESMTP id AAA118B for ; Tue, 24 Nov 1998 13:39:14 -0700 Message-ID: <365B0B7E.D989596F@email.sps.mot.com> Date: Tue, 24 Nov 1998 14:39:52 -0500 From: "Robert Goodrich" X-Mailer: Mozilla 4.03C-MOTSPS4.03 (Macintosh; I; PPC) MIME-Version: 1.0 To: "ibis-users@eda.org" Subject: R_load for linear ramp Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 Hi all: In reading the "IBIS Forum I/O Buffer Modeling Cookbook" as well as the IBIS v2.1 spec. on the [Ramp] keyword, the R_load subparameter is said to be a preferred 50 Ohm load. The Cookbook states that "if the device does not have enough drive capability to make a "significant" output transition than a higher value of load resistance may be used." My question is - what constitutes a "significant" output transition? The particular 3.3V I/O I am trying to model (and I am very new to IBIS) can only drive around a 1.5V transition with a 50 Ohm load. Increasing R_load increases the output transition and significantly changes the [Ramp] dV/dt_r and dV/dt_f ratio's. Knowing nothing about the IBIS model users concerns (that is - what constitutes a good IBIS model to the user), does it matter as long as the R_load is specified in the model? Regards, Robert Goodrich Motorola, SPS From owner-ibis Tue Nov 24 13:30:52 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA06454 for ; Tue, 24 Nov 1998 13:30:52 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id NAA09662; Tue, 24 Nov 1998 13:25:40 -0800 (PST) Date: Tue, 24 Nov 1998 13:25:40 -0800 (PST) From: Syed Huq Message-Id: <199811242125.NAA09662@jasper.cisco.com> To: ibis-users@eda.org, j_martin@qlc.com Subject: Re: IBIS differential model questions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: FEsA1IhxNjpGSMbA6+jogw== John, Here are my thoughts on this. s2ibis2 or IBIS looks at a differential buffer as if it was a single ended buffer. So only one leg of the buffer output is modeled. Even the [Ramp] numbers are derived out of one single-ended output. It uses the [Diff pin] keyword to indicate the other leg of the Diff buffer. The simulators take info of the modeled single ended buffer and re-creates the other leg of the Diff buffer(using [Diff pin]). One problem here is the R_load gets tied to either Vdd or GND(based on test). There is no true differential load. You can get by by using the V/T table data and specifying V_fixture, R_fixture. So, in summary, for a Diff buffer, you create ONE IBIS model(single-ended)and use the [Diff pin] keyword to mention the other pin of the output. Regards, Syed Cisco Systems, Inc > From j_martin@qlc.com Mon Nov 23 14:30:37 1998 > X-SMAP-Received-From: outside > From: John Martin > To: "'ibis-users@eda.org'" > Subject: IBIS differential model questions > Date: Mon, 23 Nov 1998 14:26:19 -0800 > > I am trying to build a differential IBIS model. I am not aware of a way to > create a single IBIS model from a differential buffer which has two output > pins and two independent voltage sources. It does not seem logical to > create two IBIS models for one differential buffer, one for each output pin. > Is there a way to create a single IBIS model for a differential I/O buffer > using s2ibis2? I have read the section in the s2ibis2 manual that describes > the differential pin list and it states that s2ibis2 does not process any of > the information in that list, it simply copies it to the output file. I use > s2ibis2 for Solaris to create IBIS models. > > Thanks, > John Martin > QLogic Corporation > From owner-ibis Tue Nov 24 13:32:41 1998 Received: from relayhost.vlsi.com (relayhost.vlsi.com [134.27.20.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA06459 for ; Tue, 24 Nov 1998 13:32:40 -0800 (PST) Received: (from smtp@localhost) by relayhost.vlsi.com (SMI-8.6/) id NAA10181 for ; Tue, 24 Nov 1998 13:27:30 -0800 Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by isis.vlsi.com via smap (V2.0) id xma010173; Tue, 24 Nov 98 13:27:08 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id TXYVGLQW; Tue, 24 Nov 1998 14:32:28 -0700 Sender: dsession@vlsi.com Message-ID: <365B24AB.FC484B44@vlsi.com> Date: Tue, 24 Nov 1998 14:27:07 -0700 From: "D. C. Sessions" Reply-To: "ibis-users@eda.org" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "ibis-users@eda.org" Subject: Re: R_load for linear ramp References: <365B0B7E.D989596F@email.sps.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Goodrich wrote: > In reading the "IBIS Forum I/O Buffer Modeling Cookbook" as well as the > IBIS v2.1 spec. on the [Ramp] keyword, the R_load subparameter is said > to be a preferred 50 Ohm load. The Cookbook states that "if the device > does not have enough drive capability to make a "significant" output > transition than a higher value of load resistance may be used." My > question is - what constitutes a "significant" output transition? The > particular 3.3V I/O I am trying to model (and I am very new to IBIS) can > only drive around a 1.5V transition with a 50 Ohm load. Increasing > R_load increases the output transition and significantly changes the > [Ramp] dV/dt_r and dV/dt_f ratio's. Knowing nothing about the IBIS > model users concerns (that is - what constitutes a good IBIS model to > the user), does it matter as long as the R_load is specified in the > model? You want to use an R_load heavy enough that you see the whole output- current profile of the driver, and light enough that the Miller effect is representative and you swing enough to get some precision. Half of supply at typical is pretty good, and that's just what you have in your example. Sounds like 50 ohms works well for you. BTW, [Ramp] is only supported for historical reasons; you really should use the [Rising Waveform] and [Falling Waveform] tables, with each developed for both a pullup and a pulldown (Four tables altogether). That way you capture both the turn--on and turn-off behavior of both the pullup and pulldown paths. Doing just the turn-on transition may be adequate in unterminated environments, but terminators make the turn-off transitions important. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Tue Nov 24 18:52:31 1998 Received: from exchange2.via.com.tw (exchange2.via.com.tw [202.145.217.249]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA07778 for ; Tue, 24 Nov 1998 18:52:28 -0800 (PST) Received: by exchange2.via.com.tw with Internet Mail Service (5.5.2232.9) id ; Wed, 25 Nov 1998 10:50:50 +0800 Message-ID: <4399E411E49ED111973000A0C92BD8A0025969@exchange2.via.com.tw> From: Weber Chuang To: "'Syed Huq'" , ibis-users@eda.org Subject: RE : IBIS differential model questions Date: Wed, 25 Nov 1998 10:50:47 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Hi Syed and all, Though I don't quite get the meaning but I still want to express my question and concern here, it sounds to me that the tools will use the single ended characteristic to generate another leg, but we have some drivers which I believe to be the differential drivers, for example, the USB driver which has p0+ and p0-. And due to some pad pitch and layout optimization problems, we are not able to make the driving and edge rate...etc of the two legs exactly the same, so it is not accurate to derive one leg from the other, then how should we do? Thanks for any input and hope that I am not off the topic.. Best Regards ChingFu Chuang > -----Original Message----- > From: Syed Huq [SMTP:shuq@cisco.com] > Sent: Wednesday, November 25, 1998 5:26 AM > To: ibis-users@eda.org; j_martin@qlc.com > Subject: Re: IBIS differential model questions > > John, > > Here are my thoughts on this. s2ibis2 or IBIS looks at a differential > buffer > as if it was a single ended buffer. So only one leg of the buffer output > is > modeled. Even the [Ramp] numbers are derived out of one single-ended > output. > > It uses the [Diff pin] keyword to indicate the other leg of the Diff > buffer. > The simulators take info of the modeled single ended buffer and re-creates > the > other leg of the Diff buffer(using [Diff pin]). > > One problem here is the R_load gets tied to either Vdd or GND(based on > test). > There is no true differential load. You can get by by using the V/T table > data > and specifying V_fixture, R_fixture. > > So, in summary, for a Diff buffer, you create ONE IBIS model(single-ended) > and > use the [Diff pin] keyword to mention the other pin of the output. > > Regards, > Syed > Cisco Systems, Inc > > > From j_martin@qlc.com Mon Nov 23 14:30:37 1998 > > X-SMAP-Received-From: outside > > From: John Martin > > To: "'ibis-users@eda.org'" > > Subject: IBIS differential model questions > > Date: Mon, 23 Nov 1998 14:26:19 -0800 > > > > I am trying to build a differential IBIS model. I am not aware of a way > to > > create a single IBIS model from a differential buffer which has two > output > > pins and two independent voltage sources. It does not seem logical to > > create two IBIS models for one differential buffer, one for each output > pin. > > Is there a way to create a single IBIS model for a differential I/O > buffer > > using s2ibis2? I have read the section in the s2ibis2 manual that > describes > > the differential pin list and it states that s2ibis2 does not process > any of > > the information in that list, it simply copies it to the output file. I > use > > s2ibis2 for Solaris to create IBIS models. > > > > Thanks, > > John Martin > > QLogic Corporation > > From owner-ibis Wed Nov 25 01:35:01 1998 Received: from alphatje.NL.net (alphatje.NL.net [193.78.240.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id BAA08442 for ; Wed, 25 Nov 1998 01:35:00 -0800 (PST) Received: from hgl99-5.Hengelo.NL.net ([193.79.43.230]:4612 "HELO vigil" ident: "NO-IDENT-SERVICE[2]") by alphatje.NL.net with SMTP id <231334-4276>; Wed, 25 Nov 1998 10:29:11 +0100 From: "Hans Klos" To: Subject: unsuscribe Date: Wed, 25 Nov 1998 10:25:51 +0100 Message-ID: <000901be1855$98fda8c0$883557c0@vigil> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 From owner-ibis Wed Nov 25 08:56:18 1998 Received: from gatekeeper.collins.rockwell.com (firewall-user@gatekeeper.collins.rockwell.com [205.175.225.1]) by server.eda.org (8.8.5/8.8.3) with SMTP id IAA09919 for ; Wed, 25 Nov 1998 08:56:17 -0800 (PST) From: rmhau@cacd.rockwell.com Received: by gatekeeper.collins.rockwell.com; id KAA12263; Wed, 25 Nov 1998 10:51:31 -0600 Received: from mailserv.collins.rockwell.com(131.198.66.23) by gatekeeper.collins.rockwell.com via smap (3.2) id xma012154; Wed, 25 Nov 98 10:51:11 -0600 Received: from pc114074.cca.rockwell.com (pc114074.collins.rockwell.com) by mailserv.cacd.rockwell.com with SMTP (1.40.112.8/16.2) id AA160572673; Wed, 25 Nov 1998 10:51:13 -0600 Message-Id: <365C3580.6A42@cacd.rockwell.com> Date: Wed, 25 Nov 1998 10:51:12 -0600 Reply-To: rmhau@cacd.rockwell.com Organization: Rockwell A&C X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: ibis-users@eda.org Subject: INTEL 80C196 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could anyone point me to an IBIS model for the INTEL 80C196? Thanks Ron Hau Rochwell From owner-ibis Wed Nov 25 12:54:17 1998 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA10447 for ; Wed, 25 Nov 1998 12:54:16 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id PAA18454 for ; Wed, 25 Nov 1998 15:30:55 -0500 Received: from us.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay01.pok.ibm.com (8.8.7/NCO v1.3) with SMTP id PAA26952 for ; Wed, 25 Nov 1998 15:49:05 -0500 Received: by us.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 852566C7.007258EE ; Wed, 25 Nov 1998 15:48:58 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <852566C7.007257D0.00@us.ibm.com> Date: Wed, 25 Nov 1998 14:46:48 -0600 Subject: R_load for linear ramp Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello Robert, Welcome to IBIS. I think you'll find the people on this reflector to be fairly responsive to requests for assistance in making a good IBIS datasheet, although as a group we're lacking a bit in organized education. D.C.'s comments about covering the IV space and Miller capacitance were well said. Going back to the semiconductor electronics is always important in behavioral modeling. I would add that I have had success in accurately modeling an I/O buffer without VT tables (i.e. Rising Waveform and Falling Waveform IBIS keywords). In my opinion, your inclusion of a keyword or subparameter should be based on whether or not you need it to accurately capture the behavior of your particular I/O buffer. I think it was Einstein who said that we should strive to make things as simple as possible - but no simpler! Of course, you probably won't go wrong by adding the extra keywords, either. This is just my personal philosophical bent. The most important thing from a user's perspective is that the developer of an IBIS datasheet correlate behavioral simulations of that I/O buffer driving various loads with SPICE and lab waveforms. That's what the "IBIS Accuracy Specification" is all about. (http://www.vhdl.org/pub/ibis/accuracy/) It's a document that attempts to define a means for communicating behavioral vs. SPICE and behavioral vs. lab correlation data between the IC vendor and the user. Bear in mind, this is a work-in-progress. Constructive criticism is welcome. One area that needs work is the question of whose simulator you use to do the correlation work. Your users will likely span the simulator product space, and each simulator uses a different solution algorithm. It's unrealistic to think that an IC vendor can qualify his or her IBIS datasheet on all simulators. This issue has yet to be resolved. There is one thing we can all agree on: it's vitally important to document correlation work! That's the only way a user knows if an IBIS datasheet is accurate enough for the application at hand. And if a user doesn't feel confident in the margins on a given net because the IBIS datasheet is in question, then the user can't order the component. (descend soapbox) Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on 11/25/98 12:44 PM --------------------------- "Robert Goodrich" on 11/24/98 01:39:52 PM To: "ibis-users@eda.org" cc: (bcc: Gregory R Edlund/Rochester/IBM) Subject: R_load for linear ramp Hi all: In reading the "IBIS Forum I/O Buffer Modeling Cookbook" as well as the IBIS v2.1 spec. on the [Ramp] keyword, the R_load subparameter is said to be a preferred 50 Ohm load. The Cookbook states that "if the device does not have enough drive capability to make a "significant" output transition than a higher value of load resistance may be used." My question is - what constitutes a "significant" output transition? The particular 3.3V I/O I am trying to model (and I am very new to IBIS) can only drive around a 1.5V transition with a 50 Ohm load. Increasing R_load increases the output transition and significantly changes the [Ramp] dV/dt_r and dV/dt_f ratio's. Knowing nothing about the IBIS model users concerns (that is - what constitutes a good IBIS model to the user), does it matter as long as the R_load is specified in the model? Regards, Robert Goodrich Motorola, SPS