From owner-ibis Fri Nov 1 02:21:35 1996 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id CAA19445 for ; Fri, 1 Nov 1996 02:21:34 -0800 (PST) Received: from s01.thesys.de by relay.xlink.net id <42438-0@relay.xlink.net>; Fri, 1 Nov 1996 11:08:17 +0000 Received: from s36.design by s01.thesys.de (4.1/SMI-4.1) id AA01646; Fri, 1 Nov 96 11:09:09 +0100 Date: Fri, 1 Nov 96 11:09:09 +0100 From: cornelia@thesys.de (Cornelia Foss) Message-Id: <9611011009.AA01646@s01.thesys.de> To: ibis-users@vhdl.org Subject: transistor diodes in HSPICE Arpad, I'm just a very beginner in IBIS modelling and I came across the same problem Scott Schlachter rised up. It was very kind if you could tell me how you handle this problem or if I perhaps misunderstood something. In your answer to Scott Schlachters question you wrote: >If you have access to an HSPICE manual, look up the RD, RDC, RS, >RSC, etc. parameters. Don't let yourself get confused that these >are Drain and Source resistance numbers; the currents of parasitic >diodes go through Drain, Source, and Bulk. I think you are absolutely right when saying it is possible to correctly model the resistance of the diodes. But there are some problems with the HSPICE diode implementatation, anyhow. RD, RDC, RSH ... specify the diode resistance. HSIPCE assumes the currend through the drain-bulk diode (for instance) to flow the same way as the drain-source currend does, so only one resistor is used in the HSPICE model (I guess to simplify numerical algorithms). Actually there are two differend resistances to take into account. Rdrain decreases as gate width increases and increases as HDIF+LD+LDD (contact to gate distance) increases but Rdiode decreases as both parameters increase. So I have to manually correlate every transistor diode params with actual measurment. If using only a few transistor types in gate arrays it is possible but otherwise this will cause a huge extra expenditure to generate IBIS models. Additionally there is no IK (forward knee current) parameter; neigther in ACM=0, 1, 2 nor 3. So it becomes impossible to model low and high current charactristics correctly. I was very pleased if you counceled me, much thanks in advance. Kindest regards Sascha Pawel From owner-ibis Sat Nov 2 19:19:50 1996 Received: from newsgw.mentorg.com (newsgw.mentorg.com [137.202.128.5]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id TAA10211 for ; Sat, 2 Nov 1996 19:19:48 -0800 (PST) Received: from emperor.sje.MENTORG.COM by newsgw.mentorg.com (8.6.8.1/CF5.22R) id TAA22679; Sat, 2 Nov 1996 19:08:56 -0800 Received: from griff by emperor.sje.MENTORG.COM (8.6.8.1/CF5.24R) id TAA07262; Sat, 2 Nov 1996 19:08:56 -0800 From: griff@sje.MENTORG.COM (Griff Derryberry) Received: by griff (1.38.193.4/CF5.24L) id AA02009; Sat, 2 Nov 1996 19:07:57 -0800 Date: Sat, 2 Nov 1996 19:07:57 -0800 Message-Id: <9611021907.ZM2007@griff> X-Mailer: Z-Mail (3.2.1 10oct95) To: ibis-users@vhdl.org Subject: IBIS data sheet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Is there a way to automatically generate an IBIS data sheet in Postscript format from an IBIS model? Thanks. --Griff -- Griffin Derryberry ; griff@sjc.mentorg.com EDA Tools and Process Instructor, Mentor Graphics Corporation Work: 408.451.5681; Fax: 408.451.5554; Home: 415.494.2890 A mind is like a parachute--it functions best when open. From owner-ibis Sun Nov 3 12:33:54 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA03402 for ; Sun, 3 Nov 1996 12:33:54 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id NAA19310 for ; Sun, 3 Nov 1996 13:23:04 -0700 Received: from cds9258.cadence.com(158.140.32.4) by mailgate.cadence.com via smap (V1.0mjr) id sma847052583.019307; Sun Nov 3 13:23:03 1996 Received: from [158.140.8.75] (mac585.cadence.com [158.140.8.75]) by cds9258.Cadence.COM (8.7.3/8.7.3) with SMTP id MAA28426 for ; Sun, 3 Nov 1996 12:23:02 -0800 (PST) Date: Sun, 3 Nov 1996 12:23:02 -0800 (PST) X-Sender: dmehta@cds9258 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis-users@vhdl.org From: dmehta@cadence.com (Dee Mehta) subscribe Dee Mehta Systems Core Competency Dmehta@cadence.com (408)428-5178 MS 1B1 From owner-ibis Tue Nov 5 06:02:06 1996 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id FAA23946 for ; Tue, 5 Nov 1996 05:59:40 -0800 (PST) Received: from s01.thesys.de by relay.xlink.net id <17881-0@relay.xlink.net>; Tue, 5 Nov 1996 14:47:55 +0000 Received: from s36.design by s01.thesys.de (4.1/SMI-4.1) id AA12823; Tue, 5 Nov 96 14:48:45 +0100 Date: Tue, 5 Nov 96 14:48:45 +0100 From: cornelia@thesys.de (Cornelia Foss) Message-Id: <9611051348.AA12823@s01.thesys.de> To: ibis-users@vhdl.org Subject: HSPICE diode modeling for IBIS Arpad, thank you for your response regarding diode resistance models. Modeling the diode resistance characteristics with an discrete resistor as you proposed is surely possible - but it equals to modeling with an external diode in efford. Unfortunately(??) I'm working at the silicon vendor's side, so I can't simply take the finished HSPICE files and rely on it. That is why I would like very much to find a "good" solution for the diode modeling problem. It absolutely was the best if one could model the diode within the ACM HSPICE model and so I examined possible solutions in HSPICE and came across some effects perhaps worth keeping in mind. The basic flaw within HSPICE seems to be that the resistance of the diodes is added to the effective drain (/source) resistance. Lets take an n-channel-MOSFET with negative Vout applied to drain and V_gate=0V.(source, bulk are at ground) The currend through the drain is I_diode + I_transistor where I_transistor is I_drain_source without any diode influence. Vout vs. I_transistor is expected to be (approximately) a straight line with the slope ~ R_cannel. I simulated such a transistor with all diodes disabled and got I_transistor as expected. When I simulated the same transistor with diodes enabled and looked at I_source (that is I_transistor) I found that the currend stops rising at about 0.7V. This is because of the incorrect R_diode handling in HSPICE that causes the voltage across R_cannel+R_source to be only the voltage across the differential resistance rdiff of the pn-junction and not the whole voltage across the diode (rdiff+Rdiode). Please see "pictures" below: HSPICE: o | | \ / Rdrain_eff \ (= Rdrain_cont+R_drain+Rdiode) / | | -------------- | | | | Rcannel+Rsource_eff / | \ | / | \ | | | | ___ | ^ | / \ (diode -> rdiff) | ''' | | --- ---- "real": o | | \ / Rdrain_cont \ / | | -------------- | | | / Rcannel+Rsource_eff / \ Rdiode +R_drain \ / / \ \ | | | | ___ | ^ (rdiff) | / \ | ''' | | --- ---- For rdiff is very small at high currends, the voltage across Rchannel+Rsource_eff+R_drain (that determines I_transistor) does rise only very slowly if voltages are smaller than about -0.7V. This causes an inaccuracy because I_transistor would normaly slow down its rising at voltages not less 2-3V. HSPICE: | I_drain_source (I_transistor) | . . | . | . | . |. -----------------------------------------Vout . . . . | | | | "real": | I_drain_source (I_transistor) | . . | . | . | . |. -----------------------------------------Vout . | . | . | . | If this is not just a mistake I made, it should be whatched at. I hope you can tell me weather I'm wrong or not, I will highly appreciate any information. Much thanks in advance. Kindest regards Sascha Pawel From owner-ibis Tue Nov 5 09:52:32 1996 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA25827 for ; Tue, 5 Nov 1996 09:52:32 -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 JAA15752; Tue, 5 Nov 1996 09:40:43 -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 KAA00337; Tue, 5 Nov 1996 10:40:42 -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 KAA14687; Tue, 5 Nov 1996 10:48:23 -0700 Sender: dc.sessions@tempe.vlsi.com Message-ID: <327F7C13.2F8F@tempe.vlsi.com> Date: Tue, 05 Nov 1996 10:40:35 -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: Cornelia Foss CC: ibis-users@vhdl.org Subject: Re: HSPICE diode modeling for IBIS References: <9611051348.AA12823@s01.thesys.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cornelia Foss wrote: > > Arpad, > > thank you for your response regarding diode resistance models. > > Modeling the diode resistance characteristics with an discrete resistor > as you proposed is surely possible - but it equals to modeling with an > external diode in efford. > Unfortunately(??) I'm working at the silicon vendor's side, so I can't > simply take the finished HSPICE files and rely on it. > That is why I would like very much to find a "good" solution for the > diode modeling problem. > > It absolutely was the best if one could model the diode within the ACM > HSPICE model and so I examined possible solutions in HSPICE and came across > some effects perhaps worth keeping in mind. For what it's worth, we've approached this by creating accurate models for source/drain to bulk diodes and then having a script rewrite the SPICE deck to replace transistors with a parameterized subcircuit that contains the transistor and the two parasitic diodes. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Tue Nov 5 16:36:18 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA29163; Tue, 5 Nov 1996 16:36:17 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA03495; Tue, 5 Nov 96 16:25:13 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA01931; Tue, 5 Nov 96 16:25:12 PST Date: Tue, 5 Nov 96 16:25:12 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9611060025.AA01931@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Serious s2ibis problem? Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu Hello IBIS folk: We've been trying to figure out why s2ibis produces a Pull-down (and Pull-up) curve that is VERY different from our self-produced tables (from SPICE), in particular at voltages from Vcc to 2*Vcc. This led me to the FAQ under the /man directory of S2IBIS. Here, I found: QUESTION (6): "How does s2ibis generate tables?" ANSWER: s2ibis uses the following scheme for determining what tables need to be generated for a particular pin: 0) For POWER, GND, and NC ... --snip-- 3) For each I/O or 3-state pin... --snip again-- -> pulldown(-5->0):subtract the associated ground clamp table from the pulldown table -> pulldown(0->Vcc): just use the pull-down table as simulated -> pulldown(Vcc->2*Vcc):extrapolate using the point at Vcc and the point five points before Vcc in the pulldown table A similar explanation is provided for pulldown table generation. My questions are: WHY DO THEY DO OPT FOR EXTRAPOLATION WHEN THEY HAVE ALL THE DATA NESSESSARY IN THE SPICE OUTPUT FILES? WHY ISN'T THE TRI-STATE DATA SUBTRACTED FROM THE ENTIRE VOLTAGE RANGE? After reviewing all of the files that are created (and left) by s2ibis, I found that it creates V/I tables (***from -Vcc to 2*Vcc***) for an I/O in: 1)Tri-state (un-enabled) conditions, 2)Pull-up conditions, and 3)Pull-down conditions. In searching through all of the IBIS documentation I could find, the best explanation for how to produce proper Pull-down and Pull-up curves (for either SPICE sim data or real data) was in the V2.1 Spec., under "Other Notes:" of the [Pulldown], [Pullup], [GND Clamp], [Power Clamp] Keyword section: ... The clamp curves of an input or I/O buffer can be measured directly with a curve tracer, with the I/O buffer 3-stated. However, sweeping enabled buffers results in curves that are the sum of the clamping curves and the output structures. Based on the assumption outlined above (which makes sense), the pull-up and the pull-down curves of an IBIS model must represent the DIFFERENCE of the 3-stated and the enabled buffers curves. (Note... ...) This requirement enables the simulator to sum the curves, without the danger of double counting, and arrive at an accurate model in both the 3-stated and enabled conditions. ... This explanation seems good for producing V1.1 tables as well (and perhaps just didn't make it into documentation until the V2.1 Spec). So: Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data from the entire range of both pull-down and pull-up data to derive the corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it takes EXTRA steps to produce seemingly innacurate tables... Is this a serious mistake with s2ibis, or are am I missunderstanding something. Thanks ahead for all feedback. Regards, -Scott Schlachter Design Engineering Actel Corporation Sunnyvale, CA From owner-ibis Thu Nov 7 11:29:37 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA26229; Thu, 7 Nov 1996 11:29:37 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA27237; Thu, 7 Nov 96 11:18:39 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02423; Thu, 7 Nov 96 11:18:38 PST Date: Thu, 7 Nov 96 11:18:38 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9611071918.AA02423@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Help, need feedback: Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu Hello IBIS world, I sent this message out last Tuesday to both IBIS reflectors, as well as all of the contacts at North Carolina State University, and have still recieved no response from anyone. I believe there is a serious problem with the s2ibis program algorythm, where they appear to fudge SPICE results in order to have (more proper looking?) waveforms. I believe that they may have done this as a improper work-around for the reason that SPICE does not seem to properly model the inherent CMOS diodes correctly. They extrapolate data for the pull-down and pull-up curves, instead of calculating it from the full range of I/V data that SPICE produces. I am not trying to repremand NCSU for this, as in all other respects this seems to be an excellent tool for producing IBIS V1.1 files from SPICE. I am still questioning if I am interpreting this correctly, and I really need some feedback from the IBIS community on this. As the ANSI/EIA-656 homepage endorses the use of s2ibis, and it seems that it may very well be a commonly used tool for producing IBIS files, I would think that this might have caught SOMEBODY'S attention... > From scotts Tue Nov 5 16:25:12 1996 > To: ibis@vhdl.org, ibis-users@vhdl.org > Subject: Serious s2ibis problem? > Cc: jem, whauff, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu > Content-Length: 2882 > > Hello IBIS folk: > > We've been trying to figure out why s2ibis produces a Pull-down (and > Pull-up) curve that is VERY different from our self-produced > tables (from SPICE), in particular at voltages from Vcc to 2*Vcc. > This led me to the FAQ under the /man directory of S2IBIS. Here, > I found: > > QUESTION (6): "How does s2ibis generate tables?" > > ANSWER: > s2ibis uses the following scheme for determining what tables > need to be generated for a particular pin: > 0) For POWER, GND, and NC ... > > --snip-- > > 3) For each I/O or 3-state pin... > > --snip again-- > > -> pulldown(-5->0):subtract the associated ground clamp table from > the pulldown table > > -> pulldown(0->Vcc): just use the pull-down table as simulated > > -> pulldown(Vcc->2*Vcc):extrapolate using the point at > Vcc and the point five points before Vcc in the pulldown table > > A similar explanation is provided for pulldown table generation. > My questions are: WHY DO THEY OPT FOR EXTRAPOLATION WHEN THEY HAVE > ALL THE DATA NESSESSARY IN THE SPICE OUTPUT FILES? > WHY ISN'T THE TRI-STATE DATA SUBTRACTED FROM THE > ENTIRE VOLTAGE RANGE? > > After reviewing all of the files that are created (and left) by > s2ibis, I found that it creates V/I tables (***from -Vcc to 2*Vcc***) > for an I/O in: 1)Tri-state (un-enabled) conditions, 2)Pull-up conditions, > and 3)Pull-down conditions. > > In searching through all of the IBIS documentation I could find, the best > explanation for how to produce proper Pull-down and Pull-up curves (for > either SPICE sim data or real data) was in the V2.1 Spec., under > "Other Notes:" of the [Pulldown], [Pullup], [GND Clamp], [Power Clamp] > Keyword section: > > ... The clamp curves of an input or I/O buffer can be measured > directly with a curve tracer, with the I/O buffer 3-stated. > However, sweeping enabled buffers results in curves that are > the sum of the clamping curves and the output structures. > Based on the assumption outlined above (which makes sense), the pull-up > and the pull-down curves of an IBIS model must represent the DIFFERENCE > of the 3-stated and the enabled buffers curves. (Note... ...) > This requirement enables the simulator to sum the curves, without the > danger of double counting, and arrive at an accurate model in both the > 3-stated and enabled conditions. ... > > This explanation seems good for producing V1.1 tables as well (and > perhaps just didn't make it into documentation until the V2.1 Spec). > > So: > Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data > from the entire range of both pull-down and pull-up data to derive the > corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it > takes EXTRA steps to produce seemingly innacurate tables... Is this a > serious mistake with s2ibis, or are am I missunderstanding something. > Thanks ahead for all feedback. > > Regards, > -Scott Schlachter > Design Engineering > Actel Corporation > Sunnyvale, CA > From owner-ibis Thu Nov 7 12:25:42 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA27170; Thu, 7 Nov 1996 12:25:41 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 7 Nov 1996 20:14:48 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id MAA15420; Thu, 7 Nov 1996 12:13:03 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 07 Nov 96 12:13:03 PST Date: Thu, 07 Nov 96 12:10:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Help, need feedback: Text item: Scott, I can't comment on the s2ibis program. I just wanted to correct you in saying it is not that SPICE doesn't model the diodes correctly, it is the people using SPICE who do not bother using some of the SPICE parameters to model the diodes correctly. Arpad =============================================================================== Hello IBIS world, I sent this message out last Tuesday to both IBIS reflectors, as well as all of the contacts at North Carolina State University, and have still recieved no response from anyone. I believe there is a serious problem with the s2ibis program algorythm, where they appear to fudge SPICE results in order to have (more proper looking?) waveforms. I believe that they may have done this as a improper work-around for the reason that SPICE does not seem to properly model the inherent CMOS diodes correctly. They extrapolate data for the pull-down and pull-up curves, instead of calculating it from the full range of I/V data that SPICE produces. I am not trying to repremand NCSU for this, as in all other respects this seems to be an excellent tool for producing IBIS V1.1 files from SPICE. I am still questioning if I am interpreting this correctly, and I really need some feedback from the IBIS community on this. As the ANSI/EIA-656 homepage endorses the use of s2ibis, and it seems that it may very well be a commonly used tool for producing IBIS files, I would think that this might have caught SOMEBODY'S attention... Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu Subject: Help, need feedback: To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9611071918.AA02423@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Thu, 7 Nov 96 11:18:38 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02423; Thu, 7 Nov 96 11:18:38 PST Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA27237; Thu, 7 Nov 96 11:18:39 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8 .7.3/8.7.3) with SMTP id LAA26229; Thu, 7 Nov 1996 11:29:37 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.2/8.7.3) with ESMTP id LAA16705; Thu, 7 Nov 1996 11:25:24 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id LAA08511; Thu, 7 Nov 1996 11:2 2:50 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Nov 7 14:01:22 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA28224; Thu, 7 Nov 1996 14:01:21 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA29410; Thu, 7 Nov 96 13:51:29 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02567; Thu, 7 Nov 96 13:51:28 PST Date: Thu, 7 Nov 96 13:51:28 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9611072151.AA02567@ricky.sun_net> To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Help, need feedback: Arpad, I consider the fact that in order to have SPICE model the correct diode resistance with a MOS transister that you have to "trick" it by either attaching a unidirectional resistor to the drain, attaching a resistor between the bulk and the drain, or negating the inherent diode all together and using an attached discrete component, that there is a fault with the SPICE simulator (or rather just an incomplete model). (Of the above, we are still experimenting as to which will provide the most accurate to the real device). No big deal, as through your help and others, we now have ideas for some possible workarounds, but the SPICE manual did not provide any discussion on this, and listed no apparent way of including the correct vertical resistance associated with the diode (instead it just includes the lateral drain resistance associated with the current path through the transistor). So, I don't think that the users of SPICE are to be blamed so quickly on this point, but more rather the limmitations to modeling the inherent diode associated with MOS transistors in SPICE (why don't they provide for a vertical resistance parameter that would be associated with the diode instead of the drain (or source) resistance?). From our observations so far, just a adding a few ohms of additional resistance in the form of a resistor between the bulk and source has a very significant effect to the IBIS table, specifically in the regions that the diodes start to clamp (between -Vcc to 0V, and Vcc to 2*Vcc). -Scott Schlachter >Scott, > >I can't comment on the s2ibis program. I just wanted to correct you in saying >it is not that SPICE doesn't model the diodes correctly, it is the people using> >SPICE who do not bother using some of the SPICE parameters to model the diodes >correctly. > >Arpad From owner-ibis Thu Nov 7 14:30:22 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA28484; Thu, 7 Nov 1996 14:30:22 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 7 Nov 1996 22:19:29 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id OAA21914; Thu, 7 Nov 1996 14:17:43 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 07 Nov 96 14:17:42 PST Date: Thu, 07 Nov 96 14:12:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re[2]: Help, need feedback: Text item: Scott, You are right. At the level of detail you are after SPICE seems to be lacking. What I was referring to was when SPICE modelers don't even go to the extent of using the available drain, source, etc resistance parameters yielding currents in the range of 1.0e+22 Amps at 1 V of forward bias. Arpad ================================================================================ Arpad, I consider the fact that in order to have SPICE model the correct diode resistance with a MOS transister that you have to "trick" it by either attaching a unidirectional resistor to the drain, attaching a resistor between the bulk and the drain, or negating the inherent diode all together and using an attached discrete component, that there is a fault with the SPICE simulator (or rather just an incomplete model). (Of the above, we are still experimenting as to which will provide the most accurate to the real device). No big deal, as through your help and others, we now have ideas for some possible workarounds, but the SPICE manual did not provide any discussion on this, and listed no apparent way of including the correct vertical resistance associated with the diode (instead it just includes the lateral drain resistance associated with the current path through the transistor). So, I don't think that the users of SPICE are to be blamed so quickly on this point, but more rather the limmitations to modeling the inherent diode associated with MOS transistors in SPICE (why don't they provide for a vertical resistance parameter that would be associated with the diode instead of the drain (or source) resistance?). From our observations so far, just a adding a few ohms of additional resistance in the form of a resistor between the bulk and source has a very significant effect to the IBIS table, specifically in the regions that the diodes start to clamp (between -Vcc to 0V, and Vcc to 2*Vcc). -Scott Schlachter >Scott, > >I can't comment on the s2ibis program. I just wanted to correct you in saying >it is not that SPICE doesn't model the diodes correctly, it is the people using> >SPICE who do not bother using some of the SPICE parameters to model the diodes >correctly. > >Arpad Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Help, need feedback: To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9611072151.AA02567@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Thu, 7 Nov 96 13:51:28 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02567; Thu, 7 Nov 96 13:51:28 PST Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA29410; Thu, 7 Nov 96 13:51:29 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8 .7.3/8.7.3) with SMTP id OAA28224; Thu, 7 Nov 1996 14:01:21 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.2/8.7.3) with ESMTP id NAA28684; Thu, 7 Nov 1996 13:59:10 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id NAA08467; Thu, 7 Nov 1996 13:5 6:36 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Fri Nov 8 07:57:30 1996 Received: from c11167-343dan.ece.ncsu.edu (c11167-343dan.ece.ncsu.edu [152.1.59.242]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA23726; Fri, 8 Nov 1996 07:57:29 -0800 (PST) From: awglaser@eos.ncsu.edu Received: by c11167-343dan.ece.ncsu.edu (8.6.9/EC06jan95) id KAA10040; Fri, 8 Nov 1996 10:46:30 -0500 Message-Id: <199611081546.KAA10040@c11167-343dan.ece.ncsu.edu> Subject: Re: Serious s2ibis problem? To: scotts@actel.com (Scott Schlachter) Date: Fri, 8 Nov 1996 10:46:30 -0500 (EST) Cc: ibis@vhdl.org, ibis-users@vhdl.org In-Reply-To: <9611060025.AA01931@ricky.sun_net> from "Scott Schlachter" at Nov 5, 96 04:25:12 pm X-Mailer: ELM [version 2.4 PL24/POP] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data > from the entire range of both pull-down and pull-up data to derive the > corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it > takes EXTRA steps to produce seemingly innacurate tables... Is this a > serious mistake with s2ibis, or are am I missunderstanding something. > Thanks ahead for all feedback. Scott: While I didn't write the version of s2ibis that you refer to, I think I can answer your question. The answer lies in the voltage ranges of the pullup (or pulldown) and power clamp (or ground clamp) curves, and the assumption that a tool will add the pullup and power clamp curves of a tristate device together to get the correct total behavior. If you look at the voltage points in the pullup curve, you'll see that they vary from -Vcc to 2*Vcc, while those in the power clamp curve only vary from Vcc to 2*Vcc. When the simulator adds these two curves together, then, it only adds values to the pullup curve in the range Vcc to 2*Vcc, not the whole range of the curve. If one were to subtract the tristated pullup curve from the active pullup curve over the entire -Vcc to 2*Vcc range, the IBIS tool would be unable to reconstruct the correct behavior of the model, as the required data (i.e. the tristated data from -Vcc to Vcc) would not be present in the IBIS file. Hope that clears things up. Regards, -- Alan Glaser "It's not a competition, ECE Dept. it's just a mint..." - K North Carolina State University From owner-ibis Mon Nov 11 04:21:47 1996 Received: from melcogw.melit.melco.co.jp (melcogw.melit.melco.co.jp [192.218.140.35]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id EAA03816; Mon, 11 Nov 1996 04:21:43 -0800 (PST) Received: by melcogw.melit.melco.co.jp (5.65+1.6W/2.7W) id AA19489; Mon, 11 Nov 96 21:10:40 JST Received: from bhb003 by inetgw.topo.melco.co.jp (1.38.193.5/6.4J.6-inetgw1.0) id AA16878; Mon, 11 Nov 1996 21:10:30 +0900 Received: from ss12 by bhb003.hoku.melco.co.jp (16.8/6.4J.6-hoku01) id AA15882; Mon, 11 Nov 96 21:01:34 +0900 Received: from [161.5.3.79] by ss12.memg2.hoku.melco.co.jp (4.1/6.4J.6-memg2-941124) id AA22537; Mon, 11 Nov 96 21:20:03 JST Date: Mon, 11 Nov 96 21:20:02 JST Message-Id: <9611111220.AA22537@ss12.memg2.hoku.melco.co.jp> To: awglaser@eos.ncsu.edu From: nakamae@memg2.hoku.melco.co.jp (nakamae midori) Subject: Question about Re: Serious s2ibis problem? Cc: hoang@msai.mea.com, ibis@vhdl.org, ibis-users@vhdl.org X-Mailer: Eudora-J(1.3.8.5-J13) Hello Alan Glaser : I am now developing a IBIS model by s2ibis program in Japan. I would like to have a question concerning your answer and make sure IBIS V2.1 spec. Could you please give your response to me ? My question is, Is the following my assumption right ? Is that the algorithm of IBIS simulators ? The following shows my assumption for IBIS simulator's algorithm. IBIS Version 2.1 (8/22/95) spec. say below. --------------------------------------------------------- It is assumed that the simulator sums the clamp curves together with the appropriate pull-up or pull-down curve when a buffer is driving high or low,respectively. From this assumption and the nature of 3-statable buffers, it follows that the data in the clamping curve sections ======================================(A) are handled as constantly present curves and the pull-up and pull-down curves are used only when needed in the simulation. --------------------------------------------------------- IBIS model have 4 tables for 3-state buffer. Pullup table = Pullup(enable High out) - (Disable output) at the range -Vcc~2*Vcc Pulldown table = Pulldown(enable Low out) - (Disable output) at the range -Vcc~2*Vcc GND-clamp table = Disable output at the range -Vcc~Vcc POWER-clamp table = Disable output at the range Vcc~2*Vcc If the ranges are right,IBIS simulator must add GND-clamp table(-Vcc~Vcc) and POWER-clamp table(Vcc~2*Vcc) to constract the full range clamp datas (the data in the clamping curve sections) and handle it as constantly present =====================================(A)(see above IBIS spec.) current, when OUTPUT is disable state , High-Z state or OFF. And IBIS simulator must add the full range clamp datas to Pullup table to construct the full range pull-up curve,when a pullup transistor is ON. Similarly,simulator must add the full range clamp datas to Pulldown table to construct the full range pull-down curve,when a pulldown transistor is ON. Here,my 3-state buffer has n-channel pullup transistor. (Note) My 3-state buffer is not a inverter which consist of P-ch. and N-ch. transistors,but a output buffer which consist of N-ch. pullup transistor and N-ch. pulldown transistor and is able to out High,Low and High-Z. My 3-state buffer have Hogh-out and Low-out I/V curves which exit a big current at the range -VCC~0V. But POWER-clamp table which s2ibis program generated for my 3-state buffer is only at VCC~2*VCC range and "all zero" of course. Is the POWER-clamp table for my buffer right ? If IBIS simulator add pullup table to only POWER-clamp table which expand to the full range,I think it is wrong either s2ibis or simulator. Best Regards, Nakamae. At 10:46 AM 96.11.8 -0500, awglaser@eos.ncsu.edu wrote: > >> Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data >> from the entire range of both pull-down and pull-up data to derive the >> corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it >> takes EXTRA steps to produce seemingly innacurate tables... Is this a >> serious mistake with s2ibis, or are am I missunderstanding something. >> Thanks ahead for all feedback. > > >Scott: > >While I didn't write the version of s2ibis that you refer to, I think I >can answer your question. > >The answer lies in the voltage ranges of the pullup (or pulldown) and >power clamp (or ground clamp) curves, and the assumption that a tool >will add the pullup and power clamp curves of a tristate device together >to get the correct total behavior. > >If you look at the voltage points in the pullup curve, you'll see that >they vary from -Vcc to 2*Vcc, while those in the power clamp curve only >vary from Vcc to 2*Vcc. When the simulator adds these two curves >together, then, it only adds values to the pullup curve in the range Vcc >to 2*Vcc, not the whole range of the curve. > >If one were to subtract the tristated pullup curve from the active >pullup curve over the entire -Vcc to 2*Vcc range, the IBIS tool would be >unable to reconstruct the correct behavior of the model, as the required >data (i.e. the tristated data from -Vcc to Vcc) would not be present in >the IBIS file. > >Hope that clears things up. > >Regards, > >-- >Alan Glaser "It's not a competition, >ECE Dept. it's just a mint..." - K >North Carolina State University From owner-ibis Mon Nov 11 09:39:39 1996 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA14548 for ; Mon, 11 Nov 1996 09:39:36 -0800 (PST) Received: from s01.thesys.de by relay.xlink.net id <62431-0@relay.xlink.net>; Mon, 11 Nov 1996 18:27:36 +0000 Received: from s36.design by s01.thesys.de (4.1/SMI-4.1) id AA03834; Mon, 11 Nov 96 17:37:10 +0100 Date: Mon, 11 Nov 96 17:37:10 +0100 From: cornelia@thesys.de (Cornelia Foss) Message-Id: <9611111637.AA03834@s01.thesys.de> To: ibis-users@vhdl.org Subject: HSPICE - nonconvergent Arpad, Scott thank you, especially Arpad, for prompt response to my questions. I highly appreciate the information you provided my with; the half- sided resistor seems to work good in our models. Despite the sucsess with Ardads proposal I tryed to model with external diodes, too. A problem occured when setting all ACM parameters to zero - HSPICE ended up nonconvergent and got a DOMAIN error. If anyone came across the same problem or even knows how to solve I would very much like to contact. Does adding a bulk resistor cause inaccuracies due to altering RC time constant of drain/source to bulk capacities? (I don't want to bore anybody with diode modeling but it is a question...) Again thanks for counseling and I'm hopefully looking forward to reply Kindest regards Sascha Pawel From owner-ibis Tue Nov 12 03:56:50 1996 Received: from melcogw.melit.melco.co.jp (melcogw.melit.melco.co.jp [192.218.140.35]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id DAA24296; Tue, 12 Nov 1996 03:56:47 -0800 (PST) Received: by melcogw.melit.melco.co.jp (5.65+1.6W/2.7W) id AA15971; Tue, 12 Nov 96 20:45:42 JST Received: from bhb003 by inetgw.topo.melco.co.jp (1.38.193.5/6.4J.6-inetgw1.0) id AA08971; Tue, 12 Nov 1996 20:45:33 +0900 Received: from ss12 by bhb003.hoku.melco.co.jp (16.8/6.4J.6-hoku01) id AA03745; Tue, 12 Nov 96 20:36:33 +0900 Received: from [161.5.3.79] by ss12.memg2.hoku.melco.co.jp (4.1/6.4J.6-memg2-941124) id AA18000; Tue, 12 Nov 96 20:55:02 JST Date: Tue, 12 Nov 96 20:55:01 JST Message-Id: <9611121155.AA18000@ss12.memg2.hoku.melco.co.jp> To: scotts@actel.com (Scott Schlachter) From: nakamae@memg2.hoku.melco.co.jp (nakamae midori) Subject: Re: Question about Re: Serious s2ibis problem? Cc: bob@icx.com, ibis@vhdl.org, ibis-users@vhdl.org X-Mailer: Eudora-J(1.3.8.5-J13) Hello Scott, Thank you for your response. I have been using s2ibis2 version 0.91BETA in this 6 months and have developed about more than 10 IBIS models for memory device. Is it the latest version of s2ibis2 ? Is this version of s2ibis2 different from yours ? My setting of .s2i command file for s2ibis2 shows below. (DQ-buffer is 3-state type IN/OUT(bi-directional) buffer.) ( .s2i command file) --------------------------------------------- [Pin] |pin_name spice_node signal_name model_name 1 23 DOUT DQ_BUF -> input ena 2 2 VDD POWER 3 0 GND GND input 15 DATA DUMMY1 ena 9 ENABLE DUMMY1 | | [Model] DQ_BUF [Model type] 3-state [Polarity] Non-Inverting [Enable] Active-High ------------------------------------------------ Here,when ENABLE is Active-High,I modify my SPICE netlist (.sp file) to tie ENABLE pin thru a resistor(10Kohm and so on) to GND. (It means to set the buffer to be disable.) GND ----- resistor -----ENABLE ----> (to DQ-buffer control) Because,though s2ibis2 set voltage to ena pin for pullup/pulldown (for example,VENAS2I 21 0 DC 0),it does not set for output disable .spi files (for example, ddnout1.spi, ddtout1.spi and ddxout1.spi). I wonder why s2ibis2 does not set voltage for output disable simulation automatically. Then I was able to get the normal end of s2ibis2 program. And It seem s2ibis2 generate a good Pulldown/Pullup tables according to IBIS V2.1 spec.,if my assumptions are right. If you have any other informations concerning s2ibis2 algorythm , please let me know. Thank you. And I insert my another comments below. (P.S.)I don't receive NCSU or IBIS FORUM response yet, though I understand NCSU peoples are busy. I hope that IBIS OPEN FORUM ask some EDA vendor to support and update a s2ibis2 program as well as IBIS simulators. Best Regards, Midori Nakamae Mitsubishi Electric Corp. JAPAN At 10:32 AM 96.11.11 -0800, Scott Schlachter wrote: >Nakamae, > >I have also been using s2ibis to generate IBIS files, and I have talked >to many people about the algorythm that it uses to generate the >tables. Your assumptions apear to be correct, including what you asked >about how the simulators sum the clamp curve data to the pull-up and >pull-down data when the output buffer is active (non-tristate). If you >are using s2ibis (not s2ibis2), then you can also read about the >algorythm that s2ibis uses in the FAQ file, under the /src directory >that gets created when you untar the s2ibis program. > >As for how s2ibis deals with you n-channel pull-up, it really sounds >like it is not set up correctly. You should be getting big values >in your power-clamp curve - and you are getting zeros! s2ibis performs >no subtraction to the power-clamp data that it gets from the spice run >that it performs. It records this data directly to the [Power-clamp] >table in the created .ibs file (after it shifts all of the voltage >values to represent the Vtable = Vcc - Vout requirement). > >If you want to see exactly what the signals are for the Power-clamp (and >what the spice file looks like), look under the file pc.spi, >and the corresponding pc.out output file. For example, >if your pin-name is "One", than the files would be pcOne.spi, and >pcOne.out . These files will only be left behind if you DON'T have the >*[Cleanup] command in your s2ibis input file! > Yes,I know. Thanks. >I would start by examining the FAQ and also the pc---.spi files. If you >don't have the FAQ, let me know and I can email it to you. There has >been a lot of discussion lately in the IBIS community that we should not >bother the people at NCSU too much about the s2ibis programs, as 1) they >provided them for free to the IBIS community, 2) they don't really >have the money or man-power to support the programs (and they never >said they would support them), and finally 3) Alan Glaser and others >there are busy trying to finalize the s2ibis2 program with what little >amount of funds they have. Yes,I understand. > >Hope this helps, >-Scott Schlachter > Design Engineering > Actel Corporation > From owner-ibis Wed Nov 20 18:19:15 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA23631 for ; Wed, 20 Nov 1996 18:19:15 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id SAA13811 for ; Wed, 20 Nov 1996 18:09:03 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma013763; Wed Nov 20 18:08:59 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA15304 for ibis-users@vhdl.org; Wed, 20 Nov 96 18:07:59 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA08834; Wed, 20 Nov 96 17:30:43 PST Date: Wed, 20 Nov 96 17:30:43 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9611210130.AA08834@rockie.nsc.com> To: ibis-users@vhdl.org Subject: Avoiding Double Counting Cc: huq@rockie.nsc.com IBISfans: Got a question about double counting of clamp data(Output models). I believe simulators combine the Pullup(pu) and Power Clamp(pc) data and also Pulldown(pd) and GND Clamp(gc). That is why both pu and pd V/I table should not contain pc and gc information. This is also why, pu and pd data can be non-monotonic and once the clamp data is combined, the data becomes monotonic. If the above statements are true, why not just take pu data with the pc data included and simply put 0.0mA on the pc V/I table. Take pd data with the gc data included and leave 0.0ma for the gc V/I table. If this can be done then Model providers who are creating models from actual bench measurements, do not have to go thru the pains of doing V/I table subtraction. A DC sweep on an enabled output structure gives you the combination of the output stage + the clamp structures. It seems that we go thru too much data crunching and Simulators simply connect the two tables anyway. Possible I am missing something very important here. Pls comment. Regards, Syed National Semiconductor Corp. From owner-ibis Wed Nov 20 18:38:48 1996 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id SAA23773 for ; Wed, 20 Nov 1996 18:38:48 -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 SAA27894; Wed, 20 Nov 1996 18:35:28 -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 TAA08865; Wed, 20 Nov 1996 19:27:14 -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 TAA24609; Wed, 20 Nov 1996 19:35:04 -0700 Sender: dc.sessions@tempe.vlsi.com Message-ID: <3293BE02.41D9@tempe.vlsi.com> Date: Wed, 20 Nov 1996 19:27:14 -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: Syed Huq CC: ibis-users@vhdl.org Subject: Re: Avoiding Double Counting References: <9611210130.AA08834@rockie.nsc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Syed Huq wrote: > > IBISfans: > > Got a question about double counting of clamp data(Output models). [...] > If this can be done then Model providers who are creating models > from actual bench measurements, do not have to go thru the pains > of doing V/I table subtraction. A DC sweep on an enabled output > structure gives you the combination of the output stage + the clamp > structures. > > It seems that we go thru too much data crunching and Simulators > simply connect the two tables anyway. > > Possible I am missing something very important here. Pls comment. So how would you handle tristate outputs? The drive is out of the picture but the clamp is far from negligible. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Thu Nov 21 14:02:00 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA18774 for ; Thu, 21 Nov 1996 14:01:59 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id NAA09941 for ; Thu, 21 Nov 1996 13:51:50 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma009609; Thu Nov 21 13:51:15 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA10973 for ibis-users@vhdl.org; Thu, 21 Nov 96 13:50:09 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA04193; Thu, 21 Nov 96 13:51:28 PST Date: Thu, 21 Nov 96 13:51:28 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9611212151.AA04193@rockie.nsc.com> To: ibis-users@vhdl.org Subject: s2ibis and s2ibis2 problem logs Cc: huq@rockie.nsc.com, mbristol@rockie.nsc.com, john.goldie@nsc.com Hi, As mentioned in the IBIS meeting minutes(11/8), I will be compiling a log of all s2ibis and s2ibis2 related problems/solutions users have encountered. A lot of you already know certain fixes to problems or work arounds. Pls E-mail me(huq@rockie.nsc.com)or send them to the reflector (ibis-users@vhdl.org). You need to specify a few things: 1)Version used. eg s2ibis Rev1.3 or s2ibis2 Beta x.xx 2)State the Problem seen 3)State the solution if any This compiled list will be forwarded back to NCSU at some point. SPICE-to-IBIS is a very critical tool for a lot of Model providers and your feedback as a user is very important. Best Regards, Syed Vice-Chair ANSI/EIA-656(IBIS) National Semiconductor Corp. From owner-ibis Fri Nov 22 11:58:21 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id LAA14910 for ; Fri, 22 Nov 1996 11:58:20 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Fri, 22 Nov 1996 19:47:19 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id LAA02559; Fri, 22 Nov 1996 11:45:07 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 22 Nov 96 11:45:07 PST Date: Fri, 22 Nov 96 10:55:00 PST From: Arpad Muranyi Message-ID: To: ibis-users@vhdl.org cc: huq@rockie.nsc.com Subject: Re: Avoiding Double Counting Text item: Syed, I have read the replies you got so far, and they are all correct. However, there is one other reason that I didn't see mentioned. When I first started experimenting with these I-V curves, my goal was to do them in such a way, that GND bounce and/or Vcc droop could be modeled correctly if desired. The problem goes as follows: Consider an I-V curve for a device driving low (the same is also true for high state, but I am not going to address that here). If you sweep it from -Vcc to 2*Vcc, you get basically three regions in the I-V curve. First you are measuring the GND clamps, which are in the range of -Vcc to 0 V. Then the pulldown transistor, between 0 V to Vcc, and above Vcc the power clamp. In CMOS, the GND clamp usually comes from the parasitic diode in the pulldown FET, but the power clamp comes from the parasitic diode of the pullup transistor. Now, if you modulate the GND or Vcc voltage in a simulation due to SSO noise, the knee voltages of these clamps should also move around with respect to their corresponding supply voltages. If you had a single I-V curve, this would not be possible. This was the real reason I choose to separate them the way they are done now. Of course, one might argue, that the separation could have been done by the simulator tool after reading in the curves from the IBIS model ("give me raw data" approach). But even in that case, we would have to use ON curves and 3-stated curves in the IBIS models. This method would work too, if done correctly. I guess I was just trying to make it easier on the tools (or make sure that this is being done right) when I decided to separate things during model generation. In the case of the output only buffers, this separation is not as straight forward, because we do not have a 3-stated curve that we could easily subtract from the ON curves. With some extra work, however, it would be possible to identify each of the clamps in the I-V curves, and knowing the saturation current of the pulldown or pullup transistor, it would be possible to reverse engineer a 3-stated curve for the output only devices also. This would then enable the modeler to generate models similar to the I/O models, with independent I-V curves for the clamps. The question is, is there a benefit to go through all this math to do that? Also, are there unusual devices out there with which this method falls apart? I guess, IBIS doesn't prohibit the output buffers from being modeled this way, but for the sake of simplicity, when I have an output only model, I generate "combined" curves and do not use the clamp curve sections. Arpad ================================================================================ IBISfans: Got a question about double counting of clamp data(Output models). I believe simulators combine the Pullup(pu) and Power Clamp(pc) data and also Pulldown(pd) and GND Clamp(gc). That is why both pu and pd V/I table should not contain pc and gc information. This is also why, pu and pd data can be non-monotonic and once the clamp data is combined, the data becomes monotonic. If the above statements are true, why not just take pu data with the pc data included and simply put 0.0mA on the pc V/I table. Take pd data with the gc data included and leave 0.0ma for the gc V/I table. If this can be done then Model providers who are creating models from actual bench measurements, do not have to go thru the pains of doing V/I table subtraction. A DC sweep on an enabled output structure gives you the combination of the output stage + the clamp structures. It seems that we go thru too much data crunching and Simulators simply connect the two tables anyway. Possible I am missing something very important here. Pls comment. Regards, Syed National Semiconductor Corp. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: huq@rockie.nsc.com Subject: Avoiding Double Counting To: ibis-users@vhdl.org Message-Id: <9611210130.AA08834@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Wed, 20 Nov 96 17:30:43 PST Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA08834; Wed, 20 Nov 96 17:30:43 PST Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA15304 for ibis-users@vhdl.org; Wed, 20 Nov 96 18:07:59 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma013763; Wed Nov 20 18:08:59 1996 Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id SAA1381 1 for ; Wed, 20 Nov 1996 18:09:03 -0800 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl. vhdl.org (8.7.3/8.7.3) with SMTP id SAA23631 for ; Wed, 20 Nov 1996 18:19:15 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.3/8.7.3) with ESMTP id SAA27620; Wed, 20 Nov 1996 18:15:09 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id SAA27253; Wed, 20 Nov 1996 18: 12:35 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Fri Nov 22 17:49:07 1996 Received: from hotmail.com (delivery.hotmail.com [206.86.127.236]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA17627 for ; Fri, 22 Nov 1996 17:49:07 -0800 (PST) Received: (http://www.hotmail.com 10194 invoked by uid 0); 23 Nov 1996 01:38:05 -0000 Date: 23 Nov 1996 01:38:05 -0000 Message-ID: <19961123013805.10193.qmail@hotmail.com> Received: from 206.86.127.195 by www.hotmail.com with HTTP; Fri, 22 Nov 1996 17:38:05 PST From: "Jin Man Han" To: ibis-users@vhdl.org Cc: ibis@vhdl.org Subject: I/O switching current? Content-Type: text/plain Hi, I hope somebody can answer this question. Doesn't IBIS have to specify I/O switching current? I think this information is crucial in estimating real situation 'cause given similar I/V characteristics and rise/fall time, I/O switching current can be significantly different. Min/max I/O switching current should be specified in IBIS, I think. Thanks in advance. --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- From owner-ibis Mon Nov 25 10:18:24 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA03398; Mon, 25 Nov 1996 10:18:20 -0800 (PST) Received: from uucp5.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp5.UU.NET [192.48.96.36]) id QQbrjs25435; Mon, 25 Nov 1996 13:04:41 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Mon, 25 Nov 1996 13:04:44 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00817; Mon, 25 Nov 96 09:17:51 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09927; Mon, 25 Nov 96 09:17:50 PST Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbrjo01557; Mon, 25 Nov 1996 12:06:26 -0500 (EST) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 25 Nov 1996 12:06:27 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00640; Mon, 25 Nov 96 08:37:05 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA09450; Mon, 25 Nov 96 08:37:04 PST Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <3299CB2F.6201DD56@qdt.com> Date: Mon, 25 Nov 1996 08:37:03 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Jin Man Han Cc: uunet!uunet!vhdl.org!ibis-users@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: I/O switching current? References: <19961123013805.10193.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jin Man, If you use the VT curves in the IBIS 2.1 model, it does specify switching current. It just does it in a behavioral fashion using voltage versus time into different loads. If the loads are properly chosen for the target technology it is possible to simulate SSO and other current switching effects. Jon Powell Quad Design From owner-ibis Mon Nov 25 14:32:52 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA05664 for ; Mon, 25 Nov 1996 14:32:52 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id OAA14923; Mon, 25 Nov 1996 14:21:51 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma014523; Mon Nov 25 14:21:19 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA28440 for ibis-users@vhdl.org; Mon, 25 Nov 96 14:20:37 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA03206; Mon, 25 Nov 96 14:21:59 PST Date: Mon, 25 Nov 96 14:21:59 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9611252221.AA03206@rockie.nsc.com> To: ibis-users@vhdl.org, Arpad_Muranyi@ccm.fm.intel.com Subject: Re: Avoiding Double Counting Cc: huq@rockie.nsc.com Hi, Thanks to all who had responded to my question on Double counting issues. Let me ask one more on this topic(see below): > ** Arpad Writes: ** > Consider an I-V curve for a device driving low (the same is also true for high > state, but I am not going to address that here). If you sweep it from -Vcc to > 2*Vcc, you get basically three regions in the I-V curve. First you are > measuring the GND clamps, which are in the range of -Vcc to 0 V. Then the > pulldown transistor, between 0 V to Vcc, and above Vcc the power clamp. In > CMOS, the GND clamp usually comes from the parasitic diode in the pulldown FET, > but the power clamp comes from the parasitic diode of the pullup transistor. > > Now, if you modulate the GND or Vcc voltage in a simulation due to SSO noise, > the knee voltages of these clamps should also move around with respect to their > corresponding supply voltages. If you had a single I-V curve, this would not be > possible. This was the real reason I choose to separate them the way they are > done now. > There are three regions on a Pullup or Pulldown V/I curve: -Vcc to 0V 0V to +Vcc +Vcc to +2Vcc Gnd Clamp Pu or Pd Power Clamp So, since GND Clamp and Power Clamp data are provided seperately for a Tri-statable output (by disabling that outputs), I think the Pu and Pd data could have been taken only from 0V to +Vcc(during enable mode). This does not sweep clamp structures, so no substraction of data is necessary, no double counting issues and the simulator can combine clamp data with 'On' data as necessary. When a CMOS device is 'ON', who would want to sweep that above Vcc ... Regards, Syed National Semiconductor Corp. From owner-ibis Mon Nov 25 15:03:29 1996 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA06071 for ; Mon, 25 Nov 1996 15:03:29 -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 PAA10159; Mon, 25 Nov 1996 15:05:51 -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 PAA09847; Mon, 25 Nov 1996 15:51:51 -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 PAA24217; Mon, 25 Nov 1996 15:59:41 -0700 Sender: dc.sessions@tempe.vlsi.com Message-ID: <329A2307.4D24@tempe.vlsi.com> Date: Mon, 25 Nov 1996 15:51:51 -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: Syed Huq CC: ibis-users@vhdl.org Subject: Re: Avoiding Double Counting References: <9611252221.AA03206@rockie.nsc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Syed Huq wrote: > Thanks to all who had responded to my question on Double counting issues. > Let me ask one more on this topic(see below): > > > ** Arpad Writes: ** > > Consider an I-V curve for a device driving low (the same is also true for high > > state, but I am not going to address that here). If you sweep it from -Vcc to > > 2*Vcc, you get basically three regions in the I-V curve. First you are > > measuring the GND clamps, which are in the range of -Vcc to 0 V. Then the > > pulldown transistor, between 0 V to Vcc, and above Vcc the power clamp. In > > CMOS, the GND clamp usually comes from the parasitic diode in the pulldown FET, > > but the power clamp comes from the parasitic diode of the pullup transistor. > > > > Now, if you modulate the GND or Vcc voltage in a simulation due to SSO noise, > > the knee voltages of these clamps should also move around with respect to their > > corresponding supply voltages. If you had a single I-V curve, this would not be > > possible. This was the real reason I choose to separate them the way they are > > done now. > There are three regions on a Pullup or Pulldown V/I curve: > > -Vcc to 0V 0V to +Vcc +Vcc to +2Vcc > > Gnd Clamp Pu or Pd Power Clamp > > So, since GND Clamp and Power Clamp data are provided seperately for a Tri-statable output > (by disabling that outputs), I think the Pu and Pd data could have been taken > only from 0V to +Vcc(during enable mode). > > This does not sweep clamp structures, so no substraction of data is necessary, no double > counting issues and the simulator can combine clamp data with 'On' data as > necessary. > > When a CMOS device is 'ON', who would want to sweep that above Vcc ... We do -- all the time. After all, when a reflection comes back into an active output the additional snubbing effect of an ON transistor makes a huge difference. Especially between the rail and the turnon point of the clamp structure, where the active device is highly conductive and the clamp nonexistent. The difference in line settling time and ringback level is remarkable. -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Mon Nov 25 15:41:22 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA06407 for ; Mon, 25 Nov 1996 15:41:22 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Mon, 25 Nov 1996 23:30:06 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id PAA23559; Mon, 25 Nov 1996 15:27:56 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Mon, 25 Nov 96 15:27:56 PST Date: Mon, 25 Nov 96 15:12:00 PST From: Arpad Muranyi Message-ID: To: huq@rockie.nsc.com cc: ibis-users@vhdl.org Subject: Re[2]: Avoiding Double Counting Text item: Syed, First, D. C. Sessions spoke (wrote) out of my heart. Second, the reason that the whole sweep range and subtraction is necessary is, because when the transistor is on, it does add more current to the clamps. In other words, when you sweep above Vcc while driving low, you get saturation current plus Vcc clamp current, therefore your clamp current is actually shifted up by the amount of the saturation current. If you measured the Vcc clamp the way you described it, it would start from around 0 mA (and not the saturation current). Similarly, when you sweep below GND, you get (approximately) the on-channel resistance current plus GND clamp current... I don't know of any other way to separate/combine them. Arpad ================================================================================ Syed Huq wrote: > Thanks to all who had responded to my question on Double counting issues. > Let me ask one more on this topic(see below): > > > ** Arpad Writes: ** > > Consider an I-V curve for a device driving low (the same is also true for high > > state, but I am not going to address that here). If you sweep it from -Vcc to > > 2*Vcc, you get basically three regions in the I-V curve. First you are > > measuring the GND clamps, which are in the range of -Vcc to 0 V. Then the > > pulldown transistor, between 0 V to Vcc, and above Vcc the power clamp. In > > CMOS, the GND clamp usually comes from the parasitic diode in the pulldown FET, > > but the power clamp comes from the parasitic diode of the pullup transistor. > > > > Now, if you modulate the GND or Vcc voltage in a simulation due to SSO noise, > > the knee voltages of these clamps should also move around with respect to their > > corresponding supply voltages. If you had a single I-V curve, this would not be > > possible. This was the real reason I choose to separate them the way they are > > done now. > There are three regions on a Pullup or Pulldown V/I curve: > > -Vcc to 0V 0V to +Vcc +Vcc to +2Vcc > > Gnd Clamp Pu or Pd Power Clamp > > So, since GND Clamp and Power Clamp data are provided seperately for a Tri-statable output > (by disabling that outputs), I think the Pu and Pd data could have been taken > only from 0V to +Vcc(during enable mode). > > This does not sweep clamp structures, so no substraction of data is necessary, no double > counting issues and the simulator can combine clamp data with 'On' data as > necessary. > > When a CMOS device is 'ON', who would want to sweep that above Vcc ... We do -- all the time. After all, when a reflection comes back into an active output the additional snubbing effect of an ON transistor makes a huge difference. Especially between the rail and the turnon point of the clamp structure, where the active device is highly conductive and the clamp nonexistent. The difference in line settling time and ringback level is remarkable. -- D. C. Sessions dc.sessions@tempe.vlsi.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 References: <9611252221.AA03206@rockie.nsc.com> Subject: Re: Avoiding Double Counting CC: ibis-users@vhdl.org To: Syed Huq MIME-Version: 1.0 X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.4 sun4m) Organization: VLSI Technology Inc. From: "D.C. Sessions" Date: Mon, 25 Nov 1996 15:51:51 -0700 Message-ID: <329A2307.4D24@tempe.vlsi.com> Sender: dc.sessions@tempe.vlsi.com Received: from witsend (witsend.tempe.vlsi.com [134.27.133.12]) by tempepop.temp e.vlsi.com (8.6.9/Hub-Perlotto/010296) with SMTP id PAA24217; Mon, 25 Nov 1996 1 5:59:41 -0700 Received: from tempepop.tempe.vlsi.com (devious.tempe.vlsi.com [134.27.128.5]) b y relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/101195) with ESMTP id PAA09847; M on, 25 Nov 1996 15:51:51 -0700 Received: from relayhost.tempe.vlsi.com (anubis.tempe.vlsi.com [134.27.128.1]) b y relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id PAA10159; Mon, 2 5 Nov 1996 15:05:51 -0800 Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by vhdl.vhdl. org (8.7.3/8.7.3) with ESMTP id PAA06071 for ; Mon, 25 Nov 1996 15:03:29 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.8.3/8.7.3) with ESMTP id OAA08298; Mon, 25 Nov 1996 14:54:59 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.8.2/8.7.3) with ESMTP id OAA17388; Mon, 25 Nov 1996 14:55:00 -0800 ( PST) Return-Path: owner-ibis@vhdl.vhdl.org