From owner-ibis Fri Feb 7 09:09:40 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id JAA02078 for ; Fri, 7 Feb 1997 09:09:39 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id JAA27244; Fri, 7 Feb 1997 09:09:28 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma026992; Fri Feb 7 09:09:03 1997 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA29873 for h-hilbig@ti.com; Fri, 7 Feb 97 09:07:41 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA09457; Fri, 7 Feb 97 09:09:53 PST Date: Fri, 7 Feb 97 09:09:53 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9702071709.AA09457@rockie.nsc.com> To: huq@rockie.nsc.com, h-hilbig@ti.com, ibis-users@vhdl.org Subject: Re: Silicon based IBIS models Cc: pweber@ti.com, h-behrmann@ti.com Hans, You may use the 'ibis-users@vhdl.org' E-mail reflector for IBIS spec/use related questions. You are correct, we do not yet have a way of posting questions from the web site. What I have done for our model generation is to delete data in the linear regions if the data points exceed the 100 points limitation. I am not aware of tools available that can readily do this but if there is, I am sure someone from the IBIS community will respond to this. Regards, Syed National Semiconductor. > From h-hilbig@ti.com Fri Feb 7 05:55:05 1997 > Date: Fri, 07 Feb 1997 14:52:36 +0100 > From: "H.M.Hilbig" > Organization: EMSLP > X-Mailer: Mozilla 3.0 (WinNT; I) > To: huq@rockie.nsc.com > Cc: pweber@ti.com, h-behrmann@ti.com > Subject: Silicon based IBIS models > Content-Type> : > text/plain> ; > charset=us-ascii> > Content-Transfer-Encoding: 7bit > > HI, > there is no real IBIS contact listed on the Internet home page and I > have just requested to be set up on the mail reflector. But I have an > immediate question I would be glad to get answered or relayed to the > right person: > > We plan to generate Silicon based IBIS models from characterization data > we have available anyhow. It is required that the IBIS data does not > exceed 100 measure points, while our DC curves usually have around 300 > measure points across any sweep range. > Now the question: > We could simply 'delete' equidistant samples from the x-axis, thus > reducing the amount of measurements from 300 to 100. This bears the risk > that we skip important non linear information of the curve. We could > develop an algorithm which deletes samples of the curve's linear > regions, resulting in a 'linearity' weight distribution of the 100 > measurement samples. Is this an overkill? Are tools out in the field > which could parse 300+ samples to 100 samples curves for IBIS? > > Thanks for some experienced feedback, > > Best regards, > Hans M Hilbig Texas Instruments Germany > e-mail: h-hilbig@ti.com, phone: +49-8161-804126 > From owner-ibis Fri Feb 7 09:23:46 1997 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id JAA02119; Fri, 7 Feb 1997 09:23:45 -0800 (PST) Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA08540; Fri, 7 Feb 97 09:24:06 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA09450; Fri, 7 Feb 97 09:23:59 PST Date: Fri, 7 Feb 97 09:23:59 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9702071723.AA09450@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Lab data vs. Spice data Hello Ibis folks, I'd like to compare notes with those who have produced IBIS files from *BOTH* Spice and lab measurements. Please respond to me directly (not through the reflector) if you have done this, particularly if yours is a CMOS process. Thanks, -Scott Schlachter Actel Corporation scotts@actel.com Sunnyvale, CA From owner-ibis Mon Feb 10 07:36:56 1997 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA11104 for ; Mon, 10 Feb 1997 07:36:54 -0800 (PST) Received: from jaxom.eng.pko.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA18654; Mon, 10 Feb 1997 10:27:46 -0500 (EST) Received: from exchange.eng.pko.dec.com by jaxom.eng.pko.dec.com (5.65v3.2/1.1.10.5/18Jan97-1020AM) id AA17984; Mon, 10 Feb 1997 10:27:44 -0500 Received: by exchange.eng.pko.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC173D.0AFF7910@exchange.eng.pko.dec.com>; Mon, 10 Feb 1997 10:27:40 -0500 Message-Id: From: "Edlund, Greg" To: "'ibis-users@vhdl.org'" Subject: DRAM output IV curves Date: Mon, 10 Feb 1997 10:27:38 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Does anyone have experience trying to extract output IV curves from DRAMs in the lab? This seems like a tough nut to crack since DRAMs lose their data unless you throw refresh patterns at them continuously. I haven't actually tried to do this myself, but I would guess you could get the pull-down curve all right since the memory cells should default to a zero state if you don't refresh them. To get the pull-up curve, you have to get your curve tracer to work in conjunction with a pattern generator. It sure would be nice to have some way of jamming the outputs to make these measurements... ---------- Greg Edlund , Principal Engineer Alpha Server Signal Integrity Digital Equipment Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (508) 493-4157 voice (508) 493-0941 FAX edlund@eng.pko.dec.com From owner-ibis Mon Feb 10 08:32:43 1997 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA11212 for ; Mon, 10 Feb 1997 08:32:43 -0800 (PST) Received: from relayhost.tempe.vlsi.com (anubis.tempe.vlsi.com [134.27.128.1]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id JAA06746; Mon, 10 Feb 1997 09:21:08 -0800 Received: from tempepop.tempe.vlsi.com (devious.tempe.vlsi.com [134.27.128.5]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/101195) with ESMTP id JAA14414; Mon, 10 Feb 1997 09:29:43 -0700 Received: from witsend (witsend.tempe.vlsi.com [134.27.133.12]) by tempepop.tempe.vlsi.com (8.6.9/Hub-Perlotto/010296) with SMTP id JAA06086; Mon, 10 Feb 1997 09:37:43 -0700 Sender: dc.sessions@tempe.vlsi.com Message-ID: <32FF4CF6.2F0C@tempe.vlsi.com> Date: Mon, 10 Feb 1997 09:29:42 -0700 From: "D.C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.4 sun4m) MIME-Version: 1.0 To: "Edlund, Greg" CC: "'ibis-users@vhdl.org'" Subject: Re: DRAM output IV curves References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Edlund, Greg wrote: > > Does anyone have experience trying to extract output IV curves from > DRAMs in the lab? This seems like a tough nut to crack since DRAMs lose > their data unless you throw refresh patterns at them continuously. I > haven't actually tried to do this myself, but I would guess you could > get the pull-down curve all right since the memory cells should default > to a zero state if you don't refresh them. To get the pull-up curve, > you have to get your curve tracer to work in conjunction with a pattern > generator. > > It sure would be nice to have some way of jamming the outputs to make > these measurements... First off, DRAM cells are read differentially and you can't count on them degrading to all zeros. As to the question, sure: write an all-ones or all-zeros pattern to the DRAM (a counter works) and then read it out continually (using the same counter). Practically speaking, though, it might be cheaper and quicker to just buy the model if the manufacturer won't give you one. Our experience (contact me directly, BTW; we're probably working on at least one project in common) has been that several DRAM makers can provide the models but aren't willing to publish them -- strictly on a request basis. I've gotten 24-hour turns thanks to the clock skew between here and Asia. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Mon Feb 10 16:55:05 1997 Received: from f7.hotmail.com (F7.hotmail.com [207.82.250.18]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA12624 for ; Mon, 10 Feb 1997 16:55:04 -0800 (PST) Received: (from root@localhost) by f7.hotmail.com (8.7.5/8.7.3) id QAA13920; Mon, 10 Feb 1997 16:53:38 -0800 (PST) Date: Mon, 10 Feb 1997 16:53:38 -0800 (PST) Message-Id: <199702110053.QAA13920@f7.hotmail.com> Received: from 203.241.132.194 by www.hotmail.com with HTTP; Mon, 10 Feb 1997 16:53:38 PST From: "Jin Man Han" To: ibis-users@vhdl.org Subject: Re: DRAM output IV Curve Content-Type: text/plain Right after power up and without any pattern writing, most of the memory cell will be initialized to zero.(I cannnot gurantee, thouh) The problem is, since internal Read is differential, DRAM output may be one or zero accroding to row addresses. So if you access a certain row(with some luck), then you may get all ones.(and vice versa) If you don't want to bother supplying address to DRAM at all, then just operate DRAM in Multi-bit-test mode. Then, most likely, you will have one in you output driver. When you entering MBT mode, most of the current DRAM outputs one if all the cells under test have the same data. And that's very likely. Hope this will help you extract DRAM IBIS data. Thanks. Jin Man Han Samsung Electronics jmhan@hotmail.com jmhan@samsung.co.kr --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- From owner-ibis Mon Feb 10 17:01:21 1997 Received: from f16.hotmail.com (F16.hotmail.com [207.82.250.27]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA12646 for ; Mon, 10 Feb 1997 17:01:19 -0800 (PST) Received: (from root@localhost) by f16.hotmail.com (8.7.5/8.7.3) id QAA10909; Mon, 10 Feb 1997 16:59:53 -0800 (PST) Date: Mon, 10 Feb 1997 16:59:53 -0800 (PST) Message-Id: <199702110059.QAA10909@f16.hotmail.com> Received: from 203.241.132.194 by www.hotmail.com with HTTP; Mon, 10 Feb 1997 16:59:53 PST From: "Jin Man Han" To: ibis-users@vhdl.org Subject: Re: DRAM output IV Curve Content-Type: text/plain Right after power up and without any pattern writing, most of the memory cell will be initialized to zero.(I cannnot gurantee, thouh) The problem is, since internal Read is differential, DRAM output may be one or zero accroding to row addresses. So if you access a certain row(with some luck), then you may get all ones.(and vice versa) If you don't want to bother supplying address to DRAM at all, then just operate DRAM in Multi-bit-test mode. Then, most likely, you will have one in you output driver. When you entering MBT mode, most of the current DRAM outputs one if all the cells under test have the same data. And that's very likely. Hope this will help you extract DRAM IBIS data. Thanks. Jin Man Han Samsung Electronics jmhan@hotmail.com jmhan@samsung.co.kr --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- From owner-ibis Mon Feb 10 17:49:43 1997 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA13345 for ; Mon, 10 Feb 1997 17:49:39 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Tue, 11 Feb 1997 01:47:13 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id RAA19127 for ibis-users@vhdl.org; Mon, 10 Feb 1997 17:43:23 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Mon, 10 Feb 97 17:43:23 PST Date: Mon, 10 Feb 97 08:22:00 PST From: Arpad Muranyi Message-ID: To: ibis-users@vhdl.org Subject: Re: DRAM output IV curves Text item: Greg, we have done this succeessfully with a simple test fixture which had an oscillator on it to keep the data refreshed. You don't have to refresh the whole array, it is enough to repetitively read from the same cell while you are curve tracing. If you are reading for about 14.5 us and then let go for 0.5 us and repeat this forever, the (slowly sweeping) curve tracer will not notice anything. You can build this circuit so that you can write first a zero or one into the cell and then just read it forever. Arpad =============================================================================== Does anyone have experience trying to extract output IV curves from DRAMs in the lab? This seems like a tough nut to crack since DRAMs lose their data unless you throw refresh patterns at them continuously. I haven't actually tried to do this myself, but I would guess you could get the pull-down curve all right since the memory cells should default to a zero state if you don't refresh them. To get the pull-up curve, you have to get your curve tracer to work in conjunction with a pattern generator. It sure would be nice to have some way of jamming the outputs to make these measurements... ---------- Greg Edlund , Principal Engineer Alpha Server Signal Integrity Digital Equipment Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (508) 493-4157 voice (508) 493-0941 FAX edlund@eng.pko.dec.com Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Date: Mon, 10 Feb 1997 10:27:38 -0500 Subject: DRAM output IV curves To: "'ibis-users@vhdl.org'" From: "Edlund, Greg" Message-Id: Received: by exchange.eng.pko.dec.com with SMTP (Microsoft Exchange Server Inter net Mail Connector Version 4.0.994.63) id <01BC173D.0AFF7910@exchange.eng.pko.dec.com>; Mon, 10 Feb 1997 10:27:40 -0500 Received: from exchange.eng.pko.dec.com by jaxom.eng.pko.dec.com (5.65v3.2/1.1.1 0.5/18Jan97-1020AM) id AA17984; Mon, 10 Feb 1997 10:27:44 -0500 Received: from jaxom.eng.pko.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV ) id KAA18654; Mon, 10 Feb 1997 10:27:46 -0500 (EST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by vhdl.v hdl.org (8.8.5/8.8.3) with ESMTP id HAA11104 for ; Mon, 10 Feb 1997 07:36:54 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id HAA20733; Mon, 10 Feb 1997 07:44:01 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.8.4/8.7.3) with ESMTP id HAA13137; Mon, 10 Feb 1997 07:44:09 -0800 ( PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Feb 11 09:23:10 1997 Received: from acy1hp03.mea.com ([208.145.189.35]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA17095 for ; Tue, 11 Feb 1997 08:35:46 -0800 (PST) Received: from gatekeeper.msai.mea.com by acy1hp03.mea.com with ESMTP (8.7.1/16.2) id LAA20308; Tue, 11 Feb 1997 11:32:58 -0500 (EST) Received: (from uucp@localhost) by gatekeeper.msai.mea.com (8.6.12/8.6.12) id LAA14147; Tue, 11 Feb 1997 11:33:07 -0500 Received: from unknown(198.28.5.20) by gatekeeper.msai.mea.com via smap (V1.3) id sma014139; Tue Feb 11 11:33:05 1997 Received: from sbedrock.msai.mea.com (shared [192.65.252.62]) by msai.mea.com (8.6.12/8.6.12) with SMTP id LAA13090; Tue, 11 Feb 1997 11:37:08 -0500 Received: from sfred.msaiasic by sbedrock.msai.mea.com (4.1/mh-version 2.4) id AA27269; Tue, 11 Feb 97 11:35:26 EST Date: Tue, 11 Feb 97 11:35:26 EST From: hoang@msai.mea.com (Hoang Nguyen) Message-Id: <9702111635.AA27269@sbedrock.msai.mea.com> To: ibis-users@vhdl.org Subject: 3-state pullup table generation by s2ibis2 0.91BETA Cc: hoang@msai.mea.com, tcao@msai.mea.com, nakamae@memg2.hoku.melco.co.jp Hello IBIS users: We at Mitsubishi have evaluated the new version of s2ibis2 v1.0, and we're quite please with the new features and good documentation. Thank you to the IBIS developers at NCSU. A couple of tests were run with s2ibis2 version 1.0 and 0.91BETA on the same device. We observed the results and thought that there is a problem in 0.91BETA version regarding pullup table generation for 3-state pin. To generate the Pullup table for 3-state pin, 0.91BETA version subtracts the pullup disable curve from the pullup enable curve for the entire sweep range [-Vcc to 2*Vcc]. While the correct subtraction should be in the pullup disable range [Vcc to 2*Vcc], which is the same as the Power Clamp range. Such operation executes properly in the new version 1.0. We had provided numerous models generated by 0.91BETA version to customers. I wonder if other IBIS users and model providers experience a similar problem. Although 0.91BETA is just a beta version, I feel that all 3-state models generated by 0.91BETA should be re-run using the latest s2ibis2 version 1.0 to meet IBIS SPEC. This may take a while if you have to re-do a lot of models. I will be glad to hear your ideas/comments on this, as well as how servere the impact of the bug on IBIS simulators you're using. Best regards, Hoang Nguyen From owner-ibis Tue Feb 11 10:51:35 1997 Received: from convex.convex.com (convex.convex.com [130.168.1.1]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id KAA00528 for ; Tue, 11 Feb 1997 10:51:30 -0800 (PST) Received: from flare.convex.com by convex.convex.com (8.6.4.2/1.35) id KAA27330; Tue, 11 Feb 1997 10:38:58 -0600 Received: from localhost by flare.convex.com (8.6.4/1.28) id KAA12318; Tue, 11 Feb 1997 10:38:52 -0600 Date: Tue, 11 Feb 1997 10:38:52 -0600 From: schumach@flare.convex.com (Richard A. Schumacher) Message-Id: <199702111638.KAA12318@flare.convex.com> To: Arpad_Muranyi@ccm.fm.intel.com, ibis-users@vhdl.org Subject: Re: DRAM output IV curves Cc: schumach@flare.convex.com Another reason for LSI parts to have JTAG or other boundary scan. With an external controller for the output stages you can forget about the internal logic. This makes it easy to model a single output, study SSO and package effects, et cetera. Richard Schumacher I do not speak officially for the Convex Division of the Hewlett Packard Company. From owner-ibis Tue Feb 11 14:14:20 1997 Received: from netcomsv.netcom.com (uucp5.netcom.com [163.179.3.5]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id OAA01063 for ; Tue, 11 Feb 1997 14:14:19 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA24346; Tue, 11 Feb 1997 12:50:47 -0800 Received: from contec10.contec.COM by contec.COM (4.1/SMI-4.1) id AA13482; Tue, 11 Feb 97 11:53:38 PST Received: by contec10.contec.COM (5.x/SMI-SVR4) id AA15279; Tue, 11 Feb 1997 11:57:14 -0800 Date: Tue, 11 Feb 1997 11:57:14 -0800 From: raghu@contec.com (Raj Raghuram) Message-Id: <9702111957.AA15279@contec10.contec.COM> To: hoang@msai.mea.com, ibis-users@vhdl.org Subject: Re: 3-state pullup table generation by s2ibis2 0.91BETA X-Sun-Charset: US-ASCII This is in reply to Hoang's comments on s2ibis v1.0. In my earlier job (at National) we used s2ibis to generate version 1 IBIS models for a number of tristate devices. I do not remember the version number of s2ibis. I suspect it is an earlier version as we did this in Jan. 1995. We did find a problem with s2ibis and corrected it. The problem was exactly what you have mentioned. There is an error in subtracting the curves with the output enabled and the output floated. ************************************************************************ Raj Raghuram Applied Simulation Technology, 2188 Bering Drive, San Jose, CA-95131. Tel: (408) 434-0967 ext.101 Fax: (408) 434-1003 e-mail: raghu@apsimtech.com ************************************************************************ From owner-ibis Tue Feb 11 12:34:32 1997 Received: from c11167-343dan.ece.ncsu.edu (c11167-343dan.ece.ncsu.edu [152.1.59.242]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA00900; Tue, 11 Feb 1997 12:34:31 -0800 (PST) From: awglaser@eos.ncsu.edu Received: (from awglaser@localhost) by c11167-343dan.ece.ncsu.edu (8.8.4/EC02Jan97) id PAA06562; Tue, 11 Feb 1997 15:33:01 -0500 (EST) Message-Id: <199702112033.PAA06562@c11167-343dan.ece.ncsu.edu> Subject: New s2ibis2 update To: ibis-users@vhdl.org, ibis@vhdl.org Date: Tue, 11 Feb 1997 15:33:01 -0500 (EST) In-Reply-To: from "Bob Ross" at Feb 11, 97 12:03:00 pm X-Mailer: ELM [version 2.4 PL24/POP] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit S2ibis2 has now been updated to v1.1 This update is a bug-fix only, and does not provide any new functionality. It fixes the following bug: - When using Spectre for simulations, VI curves had the sign of the current value reversed (e.g. -1.2A should have been 1.2A) NOTE THAT THIS BUG ONLY APPEARED WHEN USING SPECTRE FOR SIMULATIONS. (Thanks to Ganesh Balamitran for the bug report.) The new distribution (which includes updated sources, new executables, and corrected example files) can be found at ftp://vhdl.org/pub/ibis/s2ibis/s2ibis2_v1.1/s2ibis2.tar.Z and ftp://ftp.eos.ncsu.edu/pub/vlsi/techreports/s2ibis2.tar.Z Also, please note that the new distribution does not include an AIX executable, as I no longer have access to an AIX machine. Regards, -- Alan Glaser "It's not a competition, ECE Dept. it's just a mint..." - K North Carolina State University From owner-ibis Tue Feb 11 22:44:20 1997 Received: from obelix.cats-erfurt.de ([194.122.182.252]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id WAA02159 for ; Tue, 11 Feb 1997 22:44:19 -0800 (PST) Received: from s01.thesys.de ([193.141.53.1]) by obelix.cats-erfurt.de (8.7.1/8.7.1) with SMTP id HAA18108 for ; Wed, 12 Feb 1997 07:44:26 GMT Received: from s36.design by s01.thesys.de (4.1/SMI-4.1) id AA07913; Wed, 12 Feb 97 07:43:16 +0100 Date: Wed, 12 Feb 97 07:43:16 +0100 From: cornelia@thesys.de (Cornelia Foss) Message-Id: <9702120643.AA07913@s01.thesys.de> To: ibis-users@vhdl.org Subject: use of Vil, Vih, Tr, Tf Hello all, at first I`d like to thank Chris Rokusek who offered very useful recommendations concerning [.. waveform] test loads. A related question reffers to new s2ibis2 V1.0 tool. Vil, Vih, Tr and Tf are implemented to control input stimulus. These parameters are not part of the IBIS 2.1 spec (I think) so simulators might not have algorithms to shape the output waveform of a buffer relative to the input stimulus. If so, there could be large in- accuracies due to an input with, say 1ns rise time and the simulator of course processing the waveform as generated with a 0ns rise time input.(for none of the above parameters are contained by the .ibs file) I hope I did not simply overlook something, but if not it might be better not to use these parameters. (?) Kindest regards Sascha Pawel From owner-ibis Wed Feb 19 07:01:42 1997 Received: from obelix.cats-erfurt.de ([194.122.182.252]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id HAA02543 for ; Wed, 19 Feb 1997 07:01:25 -0800 (PST) Received: from s01.thesys.de (s01.thesys.de [193.141.53.1]) by obelix.cats-erfurt.de (8.7.1/8.7.1) with SMTP id QAA09644 for ; Wed, 19 Feb 1997 16:00:45 GMT Received: from s161.design by s01.thesys.de (4.1/SMI-4.1) id AA15615; Wed, 19 Feb 97 16:00:05 +0100 Received: by s161.design (SMI-8.6/SMI-SVR4) id PAA09386; Wed, 19 Feb 1997 15:56:59 +0100 Date: Wed, 19 Feb 1997 15:56:59 +0100 From: sabineh@s01.thesys.de (Sabine Herre) Message-Id: <199702191456.PAA09386@s161.design> To: ibis-users@vhdl.org Subject: sweep range overlay in clamp curves ?? Cc: sabineh@s01.thesys.de X-Sun-Charset: US-ASCII > From sascha Wed Feb 19 15:54:53 1997 > To: sabineh > Subject: bitte abschicken, danke > Content-Length: 992 > X-Lines: 24 > > To:ibis-users@vhdl.org > Subject: sweep range overlay in clamp curves ?? > > > Hello all, > > I tried to model an input structure with constantly connected pullup > resistor using GND_clamp and POWER_clamp keywords. That causes these > tables to contain values of some mA for instance for input voltage = > 5V (Vcc = 5V) as opposed to some nA current for inputs without pullup > resistor. I hope simulators will handle this correctly. (has anyone > experiance?) The problem, anyway, is: The POWER_clamp table for 0V > (that means 0V above Vcc) and the GND_clamp table for 5V describe the > same point, for the input characteristic follows the sum of both tables. > That ends up with double counting of this current value at Vout = Vcc. > I'm not quite sure I'm right here at all since I saw a published IBIS > file having two differend currents for POWER_clamp at 0V and GND_clamp > at 5V and so two differend currents for the same Vout = 5V. > > Any comments are greatly appreciated, > > Sascha Pawel > > email: sabineh@thesys.de > From owner-ibis Wed Feb 19 09:27:51 1997 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA02657 for ; Wed, 19 Feb 1997 09:27:50 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Wed, 19 Feb 1997 17:26:16 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id JAA08011; Wed, 19 Feb 1997 09:22:15 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 19 Feb 97 09:22:15 PST Date: Wed, 19 Feb 97 09:17:00 PST From: Arpad Muranyi Message-ID: To: ibis-users@vhdl.org cc: sabineh@s01.thesys.de Subject: Re: sweep range overlay in clamp curves ?? Text item: Sasha, Your observation is correct. If you have an always present pullup or pulldown "resistor" (usually implemented as a MOSFET transistor) in a device, the GND and Power clamp curves would both show the same effect in the measurement. And you are also right, if nothing is done, this causes double counting. For this reason, I developed an algorythm in my IBIS model maker tool that will take the appropriate steps to avoid double counting. I am going to describe the case here which applies to a situation when you have a pullup "resistor" in the device. This example can also be applied to the opposite case when the device has a pulldown "R", you just have to invert the whole thing symmetrically. The following two drawings show the I-V curve of a device with a pullup "R", first as it is measured GND relative for the GNC clamp curve, and second as it is measured Vcc relative for the power clamp curve. GND relative: | / | / | / GND| / ----------+-------------------+----------- | /Vcc /-|-----------------/ / | / | / | Vcc relative:\ | \ | \ | \| GND ----------+-------------------+----------- Vcc|\ | \-------------------\ | \ | \ | \ Obviously, if both of these are put into an IBIS model, you will double count the effects of the "resistor", because the clamp curves are to be added together in an IBIS simulator. To avoid this double counting, you need to eliminate one of these curves. But how do you do it correctly? Since the device has a pullup "resistor" it makes sence to use the Vcc relative curve to preserve its Vcc relativeness. Since the slope on the right is coming from the GND clamp, I cut that part off. The question is what do you do with the GNC clamp then? The simple answer is to use the left side slope from the GND relative data, but there is a problem. This data is shifted down by the amount of saturation current from the pullup "resistor". To avoid double counting, you need to take the left side slope in the GND relative measurement and shift it up by the amount of that current so that this curve goes into the origin, and not Isat at 0 volts. To satisfy the -Vcc to Vcc range, I just add another point at Vcc with 0 mA. Comment: It is true that IBIS only requires a range of -Vcc to 0 V for the power clamp curve. When I brought this issue up in one of the open forum meetings, we all decided that the spec doesn't say that you cannot provide data outside that range, so it was legal to do what I described above for the power clamp curves. This might be recorded in one of the meeting minutes, just don't ask me which one... I hope this explaination will help you making correct IBIS models for these kind of devices. Arpad Muranyi Intel Corporation ================================================================================ > From sascha Wed Feb 19 15:54:53 1997 > To: sabineh > Subject: bitte abschicken, danke > Content-Length: 992 > X-Lines: 24 > > To:ibis-users@vhdl.org > Subject: sweep range overlay in clamp curves ?? > > > Hello all, > > I tried to model an input structure with constantly connected pullup > resistor using GND_clamp and POWER_clamp keywords. That causes these > tables to contain values of some mA for instance for input voltage = > 5V (Vcc = 5V) as opposed to some nA current for inputs without pullup > resistor. I hope simulators will handle this correctly. (has anyone > experiance?) The problem, anyway, is: The POWER_clamp table for 0V > (that means 0V above Vcc) and the GND_clamp table for 5V describe the > same point, for the input characteristic follows the sum of both tables. > That ends up with double counting of this current value at Vout = Vcc. > I'm not quite sure I'm right here at all since I saw a published IBIS > file having two differend currents for POWER_clamp at 0V and GND_clamp > at 5V and so two differend currents for the same Vout = 5V. > > Any comments are greatly appreciated, > > Sascha Pawel > > email: sabineh@thesys.de > Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. X-Sun-Charset: US-ASCII Cc: sabineh@s01.thesys.de Subject: sweep range overlay in clamp curves ?? To: ibis-users@vhdl.org Message-Id: <199702191456.PAA09386@s161.design> From: sabineh@s01.thesys.de (Sabine Herre) Date: Wed, 19 Feb 1997 15:56:59 +0100 Received: by s161.design (SMI-8.6/SMI-SVR4) id PAA09386; Wed, 19 Feb 1997 15:56:59 +0100 Received: from s161.design by s01.thesys.de (4.1/SMI-4.1) id AA15615; Wed, 19 Feb 97 16:00:05 +0100 Received: from s01.thesys.de (s01.thesys.de [193.141.53.1]) by obelix.cats-erfur t.de (8.7.1/8.7.1) with SMTP id QAA09644 for ; Wed, 19 Feb 1997 16:00:45 GMT Received: from obelix.cats-erfurt.de ([194.122.182.252]) by vhdl.vhdl.org (8.8.5 /8.8.3) with ESMTP id HAA02543 for ; Wed, 19 Feb 1997 07:01 :25 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.4/8.7.3) with ESMTP id HAA15258; Wed, 19 Feb 1997 07:12:21 -0800 (PST) Received: from mailbag.jf.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0vxDgn-000qIBC; Wed, 19 Feb 97 07:12 PST From owner-ibis Wed Feb 19 12:41:19 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id MAA02904; Wed, 19 Feb 1997 12:41:14 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 19 Feb 97 12:39 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 19 Feb 97 12:39 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 19 Feb 97 12:40 PST Message-Id: Date: Wed, 19 Feb 97 12:40 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org, ibis@vhdl.org, mongrain@poster.cae.ca Subject: Re: Simulation tools To everyone: The IBIS reflectors are NOT to be used for discussing/ commenting on/comparing COMMERCIAL products of Silicon Vendors, CAE vendors, Connector Vendors, or Users in any manner whatsoever. The IBIS Open Forum consists of many competing companies working together based on common interests, while at the same time representing the important positions of individual companies (most of which are commercial based). If we start bickering who is best, we will destroy all cooperation. Real's questions are fair, however. If you which to respond, please respond in private directly to Real. Best Regards, Bob Ross IBIS Open Forum Chair Phone (503) 603-2523, Fax (503) 639-3469 bob@icx.com Interconnectix, 10220 S.W. Nimbus Ave., K4, Portland, OR 97223 > Date: Wed, 19 Feb 1997 11:55:06 -0500 > From: "Real Mongrain Jr." > To: ibis@vhdl.org > Subject: Simulation tools > Hi everyone, > I want to know if anybody have tried many different signal integrity > simulation tools? (IBIS compatible) > Anobody compared SigNoise with XTK? Which one is the best? > Is there other great tools and what are their big advantage? > Any comments will be very helpful. > Regards, > -- > =============================================================== > Real Mongrain Jr. MailTo:mongrain@cae.ca > CAE Electronics Ltd http://www.cae.ca > 8585 Cote de Liesse > St-Laurent, Qc, Canada, H4T 1G6 > Tel.:(514) 341-6780 ext.3218 fax.:(514) 734-5618 > =============================================================== From owner-ibis Fri Feb 21 06:19:29 1997 Received: from obelix.cats-erfurt.de ([194.122.182.252]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA06420 for ; Fri, 21 Feb 1997 06:19:25 -0800 (PST) Received: from s01.thesys.de ([193.141.53.1]) by obelix.cats-erfurt.de (8.7.1/8.7.1) with SMTP id PAA03756 for ; Fri, 21 Feb 1997 15:17:58 GMT Received: from s36.design by s01.thesys.de (4.1/SMI-4.1) id AA26458; Fri, 21 Feb 97 15:17:30 +0100 Date: Fri, 21 Feb 97 15:17:30 +0100 From: cornelia@thesys.de (Cornelia Foss) Message-Id: <9702211417.AA26458@s01.thesys.de> To: ibis-users@vhdl.org Subject: problems with s2ibis2 v1.0 ? Hello everyone, first of all I'd like to thank Arpad Muranyi who explained a good method to avoid double counting when modelling some certain inputs. However, I think the parser should give a warning if the GND_ and POWER_ clamp tables define currents for the same output voltage and both tables contain non-sero values within this overlap area. This is currently mandatory within IBIS for GND_clamp at Vcc and POWER_clamp at 0V define two currents for the same voltage. I would be very grateful if anyone could help me with s2ibis2 v1.0. The main problem is that s2ibis2 does not subtract the POWER_clamp data from pulldown curves of I/Os (the same with GND_clamp and pullup) that resulting pulldown tables that contain diode current for Vout greater than Vcc. (same problem with 3-state type drivers) This would be correct if simulators add only ONE clamp table to the pullup/ pulldown tables to get the total I/V curve, but my spec says that both clamps are constantly present and appropriate pullup/pulldown tables are only added when needed. s2ibis2 is my favorite IBIS maker tool and works very well in version 1.0 so any help as well as comments on s2ibis2 v1.0 and clamp overlap is very much appreciated. (and needed) Sascha Pawel email: cornelia@thesys.de From owner-ibis Fri Feb 21 11:14:08 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id LAA06730 for ; Fri, 21 Feb 1997 11:14:06 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 21 Feb 97 11:12 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 21 Feb 97 11:12 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 21 Feb 97 11:14 PST Message-Id: Date: Fri, 21 Feb 97 11:14 PST From: bob@icx.com ( Bob Ross) To: cornelia@thesys.de, ibis-users@vhdl.org Subject: Re: ground noise analysis with IBIS Sascha: My mistake. I got the message earlier, but thought it was for the ibis-users@vhdl.org reflector. Thus, no response. I am forwarding it to the ibis-users@vhdl.org reflector for additonal comments. I will give you a some general answers. If people have any vendor-specific differences to my response, please reply privately to Sascha. Sascha, you described the crux of the ground/power bounce problem in your memo. Your observations are correct. With the information currently provided in IBIS, you have to make some ASSUMPTIONS regarding which rails (ground and power rails) supply the current used during the output transitions. IBIS does not give any details for this. Furthermore the "assumptions" are usually IMPLICIT, a consequence of the internal vendor transition algorithms. My example case is that there is no provision in IBIS to describe a make-before-break transition mechanism that might provide additional rail and ground currents than needed just for the output alone. However, to the extent that an IBIS model may still provide you with a reasonable ball-park estimate, you can still use IBIS models to provide a reasonable estimate of the effects in this complicated problem. There are a lot of other issues involved (simutaneous switching, allocation of currents to various rails for multiple drivers, etc.) The TTgnd and TTpower parameters were intended to provide a hook so that the often undocument and unpublicized "diode kick-back" effect could be modeled and included in the analysis where applicable. The diode currents COULD also be included in the power and ground bounce analysis. In my opinion, IBIS has some opportunity to address the power/ground bounce problem to a reasonable level of accuracy, but does not have all of the details that might be needed for an analysis that compares "very" closely to a Spice analysis or an actual part in SOME cases. I cannot QUANTIFY any of the statements in this response. Best Regards Bob Ross Inerconnectix > Date: Fri, 21 Feb 97 15:20:25 +0100 > From: cornelia@thesys.de (Cornelia Foss) > Message-Id: <9702211420.AA26474@s01.thesys.de> > To: ibis-info@vhdl.org > Subject: ground noise analysis with IBIS > Status: RO > Hello everyone, > I sent out a message to ibis-info@vhdl.org but did not receive any > response. To assure this mail made it through my system that might > had some problems, I post it again. If you got it twice, please > forgive. It is definitely NOT meant as a "reminder" for I know you > provide this good support via ibis-info on your own time despite you > are very busy as well. > Thanks a lot, > Sascha Pawel > email: cornelia@thesys.de > ********************original message********************************* > Hello Bob, > I'd like to thank you for the detailed response to my > question regarding best test loads. The information > was very useful and is highly appreciated. > As test load recommendations of various simulator vendors > do not differ that much I hopefully think results won't, > too. Due to the high level of abstraction when generating > IBIS models there is the risk of getting simulator dependent > outcomes, but that risk seems to be lower than I expected. > Looking though the reflector discussion and all BIRDs I found, > I couldn't surely solve the following problem: > When trying to perform ground noise analyses, one has to > calculate the currents through each ground path of each driver. > This could be approximately done by summing all output currents > extracted from waveform tables. But the simulator will have to > assign the current to pullup/down side of the driver, depending > on the point of transition. Additionally, the current from VDD > to GND has to be calculated and stored charges to be considered. > My question is: Are these problems intended to be solved in IBIS > and are there simulators that are capable of that. Further, if > yes, will IBIS 3.0 rise enhancements, e.g. will the [TTgnd/pwr] > keywords be used for ground/power noise analyses? > I'm not quite sure such transition effects are ment to be modelled > by IBIS but they are important for SI and hard to simulate with > some 30 drivers in SPICE.(would be time saving in IBIS, even if > not as accurate as SPICE) > I'm very grateful you counseled me several times and I highly > appreciated if you could do so, again. > Much thanks in advance > Sascha Pawel > email: cornelia@thesys.de From owner-ibis Tue Feb 25 09:31:42 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id JAA17150; Tue, 25 Feb 1997 09:31:41 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 25 Feb 97 09:30 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 25 Feb 97 09:30 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 25 Feb 97 09:31 PST Message-Id: Date: Tue, 25 Feb 97 09:31 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org, ibis@vhdl.org Subject: IBIS SUMMIT MEETING To All: The IBIS Summit meeting presentations are now stored on vhdl.org under /pub/ibis/summits/summit97. Compressed versions of the presentations are contained in the z97 and zip97 subdirectories for downloading. Refer to 00readme.txt for more details. Bob Ross Interconnectix From owner-ibis Fri Feb 28 02:39:53 1997 Received: from ns.NL.net (ns.NL.net [193.78.240.1]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id CAA23771 for ; Fri, 28 Feb 1997 02:39:51 -0800 (PST) Received: from tulip6 by ns.NL.net (5.65b/NLnet1.3) id AA23467; Fri, 28 Feb 1997 11:16:00 +0100 Received: from uucpgt by tulip6.tulip.nl id aa24472; 28 Feb 97 11:13 WET Received: from cc:Mail by uucpgt.tulip.nl id AA857156598 Fri, 28 Feb 97 11:03:18 Date: Fri, 28 Feb 97 11:03:18 From: "Hilbers, Alex" Encoding: 1449 Text Message-Id: <9701288571.AA857156598@uucpgt.tulip.nl> To: ibis-users@vhdl.org Subject: Ibis simulation versus Measurement Hello, lately I have been using an Ibis model of a clock. As I use a Quad simulator, the Ibis model is converted to a Quad model. Although a V-T table is included to describe the waveform, there is a distinct difference between the rising and falling edge in simulation and measurement. Even when taking into account probe loading and oscilloscope filtering, the simulated edges cannot match the measurement. The step in the clock output (caused by transmission line loading and reflected wave effects), visible in the simulation, is not seen on the oscilloscope screen. I tried to modify the waveform, which by the way is normalised in Quad, but with unsatisfactory results. Tested are: - the waveform supplied with the clock model - a straight line - a sinusoidal form - no waveform at all (deleted) Especially the straight line shows a sharp step, the worst of all. The last one (no waveform at all) shows the least visible step, and thus is the best (with respect to the rising/falling edge form). Thus one would ask oneself, why taking the trouble of including those waveforms? Is there someone with a similar experience? Or does someone have some recommendations? Best Regards Alex Hilbers ahilbers@tulip.nl From owner-ibis Fri Feb 28 04:34:13 1997 Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id EAA25289 for ; Fri, 28 Feb 1997 04:34:12 -0800 (PST) From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Content-Type: text Message-Id: <9702280739.ZM21194@eagle> Date: Fri, 28 Feb 1997 07:39:30 -0500 In-Reply-To: "Hilbers, Alex" "Ibis simulation versus Measurement" (Feb 28, 11:03am) References: <9701288571.AA857156598@uucpgt.tulip.nl> X-Mailer: Z-Mail (2.1.4 02apr93) To: ibis-users@vhdl.org Subject: Re: Ibis simulation versus Measurement Alex, o In Quad, check the tlp and cpl files to make sure they are a physical realization. o Use a 5Gs+ scope & a > 1GHZ probe with < 1pf o Charcterize the load. o Find out if the clock has more than one VI curve. o Find out how nonlinear the clock driver is. o Try comparing to spice. Richard Mellitz, NCR On Feb 28, 11:03am, "Hilbers, Alex" wrote: > Subject: Ibis simulation versus Measurement > > Hello, > > lately I have been using an Ibis model of a clock. As I use a Quad > simulator, the Ibis model is converted to a Quad model. Although a V-T > table is included to describe the waveform, there is a distinct > difference between the rising and falling edge in simulation and > measurement. Even when taking into account probe loading and > oscilloscope filtering, the simulated edges cannot match the > measurement. The step in the clock output (caused by transmission line > loading and reflected wave effects), visible in the simulation, is not > seen on the oscilloscope screen. I tried to modify the waveform, which > by the way is normalised in Quad, but with unsatisfactory results. > > Tested are: > > - the waveform supplied with the clock model > - a straight line > - a sinusoidal form > - no waveform at all (deleted) > > Especially the straight line shows a sharp step, the worst of all. The > last one (no waveform at all) shows the least visible step, and thus > is the best (with respect to the rising/falling edge form). Thus one > would ask oneself, why taking the trouble of including those > waveforms? > > Is there someone with a similar experience? > Or does someone have some recommendations? > > > Best Regards > > Alex Hilbers > ahilbers@tulip.nl > >-- End of excerpt from "Hilbers, Alex"