From owner-ibis Tue Oct 15 06:24:40 1996 Received: from bull.com (root@bull.com [128.35.253.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id GAA09567 for ; Tue, 15 Oct 1996 06:24:39 -0700 (PDT) Received: from hws1.ma30.zds.com by nc-17.ma02.bull.com with SMTP (5.65c/101096-1) id AA45528; Tue, 15 Oct 1996 09:13:58 EDT Received: from hw25.ma30.zds.com by hws1.ma30.zds.com (4.1/SMI-4.1) id AA08023; Tue, 15 Oct 96 09:13:23 EDT Date: Tue, 15 Oct 96 09:13:23 EDT From: herb@hws1.ma30.zds.com (Herb Kaupp) Message-Id: <9610151313.AA08023@hws1.ma30.zds.com> To: ibis-users@vhdl.org Subject: Address Change please change address from herb@hws1.ma30.bull.com to herb@hws1.ma30.zds.com ************************************ * Herb Kaupp * * MA30/822A * * Zenith Data Systems * * 300 Concord Road * * Billerica, Mass 01821-4186 * * Phone/fax 508 294-2340/3054 * * e-mail: herb@hws1.ma30.zds.com * ************************************ From owner-ibis Mon Oct 21 09:50:46 1996 Received: from netcomsv.netcom.com (uucp10.netcom.com [163.179.3.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA05173; Mon, 21 Oct 1996 09:50:46 -0700 (PDT) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id JAA26896; Mon, 21 Oct 1996 09:23:32 -0700 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA00272; Mon, 21 Oct 96 09:17:27 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA12459; Mon, 21 Oct 1996 09:19:21 +0800 Date: Mon, 21 Oct 1996 09:19:21 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9610211619.AA12459@contec13.contec.COM> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Comments on bird 35.2 - Multi-Staged Outputs Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII I have some general comments about this bird. I think this makes the specification quite complex and I was just wondering if we have some idea as to how many IC manufacturers are willing spend the resources required to provide this level of detail. So far, ibis specification was simulator independent. That is, it was possible to develop a model without having to use a simulator and also, the model developer could pretty much predict what the characteristics will be, from a simulator. In this case, you have to run a simulator to see what the output characteristcs are going to be. And then you have to adjust various i-v curves without really having any physical clue as to how to adjust these values. I was just curious if any one has actually attempted to develop such a model and if so, whether they will be willing to share their experiences as to how they did it, how much time they spent and finally what was the difference in the final signal integrity results. As a general philosophical comment, one has to realize that one should be willing to give up a certain level of detail if one wants to use the behavioral models with all the advantages they offer. At some point, one has to say that we can take the behavioral model only so far and it cannot do everything. ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Mon Oct 21 17:13:13 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA09038; Mon, 21 Oct 1996 17:13:09 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 21 Oct 96 17:02 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 21 Oct 96 17:02 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 21 Oct 96 16:49 PDT Message-Id: Date: Mon, 21 Oct 96 16:49 PDT From: chris@icx.com ( Chris Reid) To: ibis-users@vhdl.org, ibis@vhdl.org Subject: Bird 35.2 Arpad, In support of Dileep's comments, is it possible to model the multi-stage effect with V-T curves? In other words, if we already have a technique for capturing the significant effects of multi-stage drivers we should not add another method to do the same thing. I don't know the answer to this question, but I would like to see a demonstration of the correct answer one way or another. If Ibis can't model these drivers then we do need a technique to handle them. Chris Reid From owner-ibis Mon Oct 21 16:43:29 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 QAA08730; Mon, 21 Oct 1996 16:43:28 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Mon, 21 Oct 1996 23:31:45 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id QAA03056; Mon, 21 Oct 1996 16:30:20 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Mon, 21 Oct 96 16:30:20 PDT Date: Mon, 21 Oct 96 14:42:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org cc: dileep@contec.Apsimtech.COM Subject: Re: Comments on bird 35.2 - Multi-Staged Outputs Text item: Dileep, You have a lot of good points in your opinion regarding BIRD 35.2. However, I think that this BIRD is very important, because there are some new features in some of our buffers which could not be modeled without it. The problem is that these features are not just minute accuracy differences, they are very important in terms of signal integrity. Leaving them out might make the difference between making it or failing. For that reason, I believe the user of those models will want to see those features being modeled. Arpad Muranyi Intel Corporation ================================================================================ I have some general comments about this bird. I think this makes the specification quite complex and I was just wondering if we have some idea as to how many IC manufacturers are willing spend the resources required to provide this level of detail. So far, ibis specification was simulator independent. That is, it was possible to develop a model without having to use a simulator and also, the model developer could pretty much predict what the characteristics will be, from a simulator. In this case, you have to run a simulator to see what the output characteristcs are going to be. And then you have to adjust various i-v curves without really having any physical clue as to how to adjust these values. I was just curious if any one has actually attempted to develop such a model and if so, whether they will be willing to share their experiences as to how they did it, how much time they spent and finally what was the difference in the final signal integrity results. As a general philosophical comment, one has to realize that one should be willing to give up a certain level of detail if one wants to use the behavioral models with all the advantages they offer. At some point, one has to say that we can take the behavioral model only so far and it cannot do everything. ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.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***. X-Sun-Charset: US-ASCII Cc: dileep@contec.Apsimtech.COM Subject: Comments on bird 35.2 - Multi-Staged Outputs To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9610211619.AA12459@contec13.contec.COM> From: dileep@contec.Apsimtech.COM (Dileep Divekar) Date: Mon, 21 Oct 1996 09:19:21 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA12459; Mon, 21 Oct 1996 09:19:21 +0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA00272; Mon, 21 Oct 96 09:17:27 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id JAA26896; Mon, 21 Oct 1996 09:23:32 -0700 Received: from netcomsv.netcom.com (uucp10.netcom.com [163.179.3.10]) by vhdl.vh dl.org (8.7.3/8.7.3) with SMTP id JAA05173; Mon, 21 Oct 1996 09:50:46 -0700 (PDT ) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.7.6/8.7.3) with ESMTP id JAA28682; Mon, 21 Oct 1996 09:58:39 -0700 (PDT) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id JAA00667; Mon, 21 Oct 1996 09: 56:05 -0700 (PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Oct 22 20:40:04 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 UAA10039; Tue, 22 Oct 1996 20:40:04 -0700 (PDT) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA11216; Tue, 22 Oct 96 20:30:12 PDT Received: by ricky.sun_net (4.1/SMI-4.1) id AA03124; Tue, 22 Oct 96 20:30:11 PDT Date: Tue, 22 Oct 96 20:30:11 PDT From: scotts@actel.com (Scott Schlachter) Message-Id: <9610230330.AA03124@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: R_Pad? Hello IBIS folk, I'm participating in my companies initial developement stages of generating IBIS files, and currently we are simultaniously investigating generating them from both actual silicon, as well as from spice netlists. Were new to this email list, so please excuse us if this has been discussed: I have searched all of the documents that I could find, including searching through the email archives, but we are still having trouble answering this one question: How do we deal with a Pad resistance (CMOS)... R_comp would have been perfect for this. It seems that those who asked about R_comp in the past were told to figure it into the R_package (or R_pin). However, when the data is collected from real silicon without the package (using a tester's probe leads directly on the die's I/O pads), any resistance between the I/O pad and the I/O buffer circuitry gets included... So the test yeilds Pull-up and Pull-down data that includes an effective R_comp. For those who have designs with a built-in resistance between your pad and your I/O circuitry, how did you deal with this since the specs don't allow for R_comp, and including this resistance in the R_package is (seems) impossible? The thing that flagged us to this problem was that our Pull-down curve (after subtracting the Power-clamp diode data from the initial pull-down data) gets brought down to close to 0 current when there's about a diode voltage above Vcc on the pin (in our initial SPICE testing where we included a resistance between the I/O circuitry and the Pad). Thanks in advance, -Scott Schlachter Actel Corporation Sunnyvale, CA From owner-ibis Wed Oct 23 07:30:08 1996 Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA00894 for ; Wed, 23 Oct 1996 07:30:06 -0700 (PDT) Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA28845 for ibis-users@vhdl.org; Wed, 23 Oct 96 07:19:21 MST Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA27996 for ibis-users@vhdl.org; Wed, 23 Oct 96 07:19:20 MST Received: from cloud.msil.sps.mot.com ([223.64.95.1]) by msil.sps.mot.com (4.1/SMI-4.1) id AA07452; Wed, 23 Oct 96 16:18:15+020 Date: Wed, 23 Oct 96 16:18:15+020 From: nahum@msil.sps.mot.com (Nachum Rozen) Message-Id: <9610231418.AA07452@msil.sps.mot.com> To: ibis-users@vhdl.org Subject: Sould IBIS reflect SPEC or actual silicon? Hello IBIS folk: I've got a question regarding what IBIS file should reflect: The actual silicon parameters or spec parameters? This might seem an odd question but - lets consider the following case as an example: Let say that some signal is able to drive currents up to 10mA (this is its electrical characteristic). Now because of elecromigration limmitations the alowable current in the spec is only 5mA. In this case, what should the IBIS file reflect - the 10mA (the actual silicon characteristic) or thr 5mA (the SPEC limmitation)? Thanks in advace. Nahum Rozen. Motorola Semiconductors. From owner-ibis Wed Oct 23 08:39:16 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 IAA01497 for ; Wed, 23 Oct 1996 08:39:15 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 23 Oct 1996 15:28:32 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id IAA27307 for ibis-users@vhdl.org; Wed, 23 Oct 1996 08:27:06 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 23 Oct 96 08:27:06 PDT Date: Wed, 23 Oct 96 08:10:00 PDT From: Arpad Muranyi Message-ID: To: ibis-users@vhdl.org Subject: Re: Sould IBIS reflect SPEC or actual silicon? Text item: I would vote for the actual. Think of a SPICE model. What does that reflect? It will show you what the chip does, not what the spec says. Arpad Muranyi Intel Corporation ============================================================================== Hello IBIS folk: I've got a question regarding what IBIS file should reflect: The actual silicon parameters or spec parameters? This might seem an odd question but - lets consider the following case as an example: Let say that some signal is able to drive currents up to 10mA (this is its electrical characteristic). Now because of elecromigration limmitations the alowable current in the spec is only 5mA. In this case, what should the IBIS file reflect - the 10mA (the actual silicon characteristic) or thr 5mA (the SPEC limmitation)? Thanks in advace. Nahum Rozen. Motorola Semiconductors. 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: Sould IBIS reflect SPEC or actual silicon? To: ibis-users@vhdl.org Message-Id: <9610231418.AA07452@msil.sps.mot.com> From: nahum@msil.sps.mot.com (Nachum Rozen) Date: Wed, 23 Oct 96 16:18:15+020 Received: from cloud.msil.sps.mot.com ([223.64.95.1]) by msil.sps.mot.com (4.1/S MI-4.1) id AA07452; Wed, 23 Oct 96 16:18:15+020 Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI- 4.1/Email-2.0) id AA27996 for ibis-users@vhdl.org; Wed, 23 Oct 96 07:19:20 MST Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA28845 for ibis-users@vhdl.org; Wed, 23 Oct 96 07:19:21 MST Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by vhdl. vhdl.org (8.7.3/8.7.3) with SMTP id HAA00894 for ; Wed, 23 Oct 1996 07:30:06 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.7.6/8.7.3) with ESMTP id HAA13092; Wed, 23 Oct 1996 07:27:35 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id HAA19585; Wed, 23 Oct 1996 07:27:34 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Oct 23 09:30:33 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA02081 for ; Wed, 23 Oct 1996 09:30:32 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 23 Oct 96 09:00 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 23 Oct 96 09:00 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 23 Oct 96 08:47 PDT Message-Id: Date: Wed, 23 Oct 96 08:47 PDT From: chris@icx.com ( Chris Reid) To: ibis-users@vhdl.org Subject: Sould IBIS reflect SPEC or actual silicon? I agree with Arpad. The IBIS model should reflect what the device actually does because the board designer wants to know what actually happens when he uses the device, not what the spec says should happen. If there is a concern about possibly damaging the device then undershoot and overshoot limits should be specified and tested. Chris Reid From owner-ibis Wed Oct 23 09:06:10 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA01806; Wed, 23 Oct 1996 09:06:09 -0700 (PDT) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id IAA29655; Wed, 23 Oct 1996 08:55:20 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id IAA05759; Wed, 23 Oct 1996 08:55:17 -0700 (PDT) Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Wed, 23 Oct 96 08:55:17 PDT Date: Wed, 23 Oct 96 08:53:00 PDT From: Will Hobbs Message-ID: To: owner-ibis@vhdl.org, ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: R_Pad? Text item: IBISians, Pad resistance is generally encompassed in the R_package. I'm surprised if this isn't sufficient, given the vanishinly small value of the pad resistance and its immediate interconnection to bonding wires. However, as a tribute to Arpad Muranyi, the technical father of IBIS, I think an R_pad keyword would be terrific. And perhaps I'm wrong about whether or not there is a technical reason to break it out, so I'll defer to those who perceive a real need. Will Hello IBIS folk, I'm participating in my companies initial developement stages of generating IBIS files, and currently we are simultaniously investigating generating them from both actual silicon, as well as from spice netlists. Were new to this email list, so please excuse us if this has been discussed: I have searched all of the documents that I could find, including searching through the email archives, but we are still having trouble answering this one question: How do we deal with a Pad resistance (CMOS)... R_comp would have been perfect for this. It seems that those who asked about R_comp in the past were told to figure it into the R_package (or R_pin). However, when the data is collected from real silicon without the package (using a tester's probe leads directly on the die's I/O pads), any resistance between the I/O pad and the I/O buffer circuitry gets included... So the test yeilds Pull-up and Pull-down data that includes an effective R_comp. For those who have designs with a built-in resistance between your pad and your I/O circuitry, how did you deal with this since the specs don't allow for R_comp, and including this resistance in the R_package is (seems) impossible? The thing that flagged us to this problem was that our Pull-down curve (after subtracting the Power-clamp diode data from the initial pull-down data) gets brought down to close to 0 current when there's about a diode voltage above Vcc on the pin (in our initial SPICE testing where we included a resistance between the I/O circuitry and the Pad). Thanks in advance, -Scott Schlachter Actel Corporation Sunnyvale, CA 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: R_Pad? To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9610230330.AA03124@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Tue, 22 Oct 96 20:30:11 PDT Received: by ricky.sun_net (4.1/SMI-4.1) id AA03124; Tue, 22 Oct 96 20:30:11 PDT Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA11216; Tue, 22 Oct 96 20:30:12 PDT 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 UAA10039; Tue, 22 Oct 1996 20:40:04 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.7.6/8.7.3) with ESMTP id UAA22949; Tue, 22 Oct 1996 20:38:51 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id UAA02929; Tue, 22 Oct 1996 20:38:50 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Oct 23 09:53:49 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA02275; Wed, 23 Oct 1996 09:53:49 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id JAA10899; Wed, 23 Oct 1996 09:43:03 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id JAA04144; Wed, 23 Oct 1996 09:42:33 -0700 (PDT) Message-Id: <199610231642.JAA04144@ichips.intel.com> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: R_Pad? Date: Wed, 23 Oct 1996 09:43:04 -0700 From: Stephen Peters Hello Scott, and fellow IBISains: If I recall past conversations correctly, resistance between the pad and the active xsistors has been accounted for by including it's effects in the pullup and pullown curves. At least, that is how I have done models before. I'm curious however -- do you see a reason why this resistance should be called out seperatly? It's a good question.... Regards, Stephen Peters Intel Corp. Hello IBIS folk, I'm participating in my companies initial developement stages of generating IBIS files, and currently we are simultaniously investigating generating them from both actual silicon, as well as from spice netlists. Were new to this email list, so please excuse us if this has been discussed: I have searched all of the documents that I could find, including searching through the email archives, but we are still having trouble answering this one question: How do we deal with a Pad resistance (CMOS)... R_comp would have been perfect for this. It seems that those who asked about R_comp in the past were told to figure it into the R_package (or R_pin). However, when the data is collected from real silicon without the package (using a tester's probe leads directly on the die's I/O pads), any resistance between the I/O pad and the I/O buffer circuitry gets included... So the test yeilds Pull-up and Pull-down data that includes an effective R_comp. For those who have designs with a built-in resistance between your pad and your I/O circuitry, how did you deal with this since the specs don't allow for R_comp, and including this resistance in the R_package is (seems) impossible? The thing that flagged us to this problem was that our Pull-down curve (after subtracting the Power-clamp diode data from the initial pull-down data) gets brought down to close to 0 current when there's about a diode voltage above Vcc on the pin (in our initial SPICE testing where we included a resistance between the I/O circuitry and the Pad). Thanks in advance, -Scott Schlachter Actel Corporation Sunnyvale, CA From owner-ibis Wed Oct 23 12:50:10 1996 Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA04202 for ; Wed, 23 Oct 1996 12:49:32 -0700 (PDT) From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Content-Type: text Message-Id: <9610231543.ZM17415@eagle> Date: Wed, 23 Oct 1996 15:43:04 -0400 In-Reply-To: nahum@msil.sps.mot.com (Nachum Rozen) "Sould IBIS reflect SPEC or actual silicon?" (Oct 23, 4:18pm) References: <9610231418.AA07452@msil.sps.mot.com> X-Mailer: Z-Mail (2.1.4 02apr93) To: ibis-users@vhdl.org Subject: Re: Sould IBIS reflect SPEC or actual silicon? I would think it also depends on whether you call the device that has been subjected to electromigration defective. If not defective, then I vote for using the lower current model for the weak case. In short, the I feel the models should reflect what will be put into products regardless of how you derive them. ... Rich Mellitz, NCR On Oct 23, 4:18pm, Nachum Rozen wrote: > Subject: Sould IBIS reflect SPEC or actual silicon? > > Hello IBIS folk: > > I've got a question regarding what IBIS file should reflect: > The actual silicon parameters or spec parameters? > > This might seem an odd question but - lets consider the > following case as an example: Let say that some signal is able > to drive currents up to 10mA (this is its electrical characteristic). > Now because of electromigration limmitations the alowable current > in the spec is only 5mA. In this case, what should the IBIS file > reflect - the 10mA (the actual silicon characteristic) or thr 5mA > (the SPEC limmitation)? > > Thanks in advace. > > Nahum Rozen. > Motorola Semiconductors. >-- End of excerpt from Nachum Rozen From owner-ibis Thu Oct 24 11:23:21 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA01362; Thu, 24 Oct 1996 11:23:19 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 24 Oct 96 11:11 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 24 Oct 96 11:11 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 24 Oct 96 11:14 PDT Message-Id: Date: Thu, 24 Oct 96 11:14 PDT From: bob@icx.com ( Bob Ross) To: efboeckm@ingr.com, ibis-users@vhdl.org, ibis@vhdl.org Subject: Re: Rising Waveform Loading Effects Ed: Your concern about accuracy of IBIS models in simulation environments is valid. I do not want to get totally bogged down here in an accuracy debate, but I want to make a few points: 1. The IBIS models might be positioned at a higher level of abstraction than Spice models. IBIS models are based on actual measured or Spice derived information. So to the extent that the IBIS model is accurate depends only on the source information. IBIS models do not carry all of the parameters that are contained in a Spice model. 2. IBIS models have performed very well in PCB design and simulation environments. The EDA vendors have algorithms which treat transmission lines and vias and otehr effects very well. Many times these elements provide the dominant characteristics rather than the model details. IBIS models are very suitable with large sized physical data bases (the whole board) containing thousands of nets and many components. Just getting Spice models that are compatible (e.g., are of equal accuracy, do not have conflicting options such as scaling factors, and are actually available from the vendors, etc.) is in practice usually unrealistic. Physical databases capture the layout of each net and locations of nearby nets. So board level analysis where random interactions can occur is one area where IBIS models (or behavioral models in general) are appropriate. Spice analysis might be better for a detailed investigation of some critical nets to validate a design or to really test some variations. The network topology may be easier to describe here. 3. Regarding the Waveform extraction methodology, the objective is to provide test loads which create the best model. They need to be as close as possible to the simulation enviroment. In high speed applications the transmission line load looks initially resistive, but may be at any voltage from low state to high state (and beyond) based on the dynamic reflection characteristics. So I feel for CMOS technology that resistive test loads to ground and Vcc of approximately 50 to 100 ohms (or whatever the characteristic impedance) will provide the best model. This set spans the voltage range and provides the load resistance seen by the device. Simulators properly handle any added capacitance and inductance that is seen by the device. The IBIS mode architecture is a simplified representation of most devices for the purposes of modeling. To the extent that the Spice model architecture functions in the same manner, the IBIS model will be very accurate. A fixed percentage (such as 5%) accuracy when comparing a Spice model and IBIS model directly under a test suite may not be achieved, in my opinion, for many devices because of the internal non-linear switching characteristics of actual Spice models (and devices). However, for timing and signal integrity analysis of real networks, the accuracy is very good compared to a similar Spice analysis and measurements. Best Regards, Bob Ross Interconnectix, Inc. > Hello to all, > I am concerned about the validity of using IBIS models for general > printed circuit board signal analysis in an environment of various types > of loads, transmission lines, vias, pads, connectors, various > terminations, etc. > According to the IBIS specification V2.1 dated Dec. 13, 1995, for a > rising waveform (for example), there are various loads specified as > L_dut, R_dut, L_fixture, R_fixture, C_dut, and C_fixture. In addition > data is to be taken with the effects of C_comp included. There is > however no provision for generating curves with a transmission line load > which is more typically the case, especially for high speed circuits. in > actual circuit boards. > It is well known however, that the ramp rate and levels reached will be > affected by the loads. For example, changing the values of R_fixture > and V_fixture on a typical buffer. (The s2ibis2 program will generate > different curves for different values of R_fixture, for example IBIS > curves for 50 ohms and 100 ohms is generated from a command file that > specified curves for 50 and 100 ohms.) > My question is this: If in an actual simulation environment we really > have a different loading condition with transmission lines , vias, etc., > how can we legitimately use an IBIS model that was generated with a > different lumped element loading condition ? > I hope someone can help me to understand how the IBIS models will > accurately produce the correct physical response with an arbitrary but > realistic loading condition, different from the test fixture, at least > to a level of accuracy close to that which would result from the > original transistor level spice model, say within 5%. > Ed Boeckmann, "My comments reflect solely my own opinion!" > Intergraph Corp. > Huntsville AL 35894 > tel. (205)-730-6219 > fax (205)-730-6000 > email efboeckm@ingr.com From owner-ibis Fri Oct 25 13:55:12 1996 Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA00339; Fri, 25 Oct 1996 13:55:11 -0700 (PDT) Received: from salope.cse.tek.com by inet1.tek.com id ; Fri, 25 Oct 1996 13:43:51 -0700 Received: from mdhost.cse.tek.com (localhost [127.0.0.1]) by salope.cse.tek.com (8.7.5/8.7.3) with ESMTP id NAA07706; Fri, 25 Oct 1996 13:43:50 -0700 (PDT) Message-Id: <199610252043.NAA07706@salope.cse.tek.com> To: bob@icx.com ( Bob Ross) cc: efboeckm@ingr.com, ibis-users@vhdl.org, ibis@vhdl.org, brockh@mdhost.cse.tek.com Subject: Re: Rising Waveform Loading Effects In-reply-to: Your message of "Thu, 24 Oct 1996 11:14:00 PDT." Date: Fri, 25 Oct 1996 13:43:49 -0700 From: Brock Hannibal Hi all, Let me add a thought. Ed Boeckman asks: "I hope someone can help me to understand how the IBIS models will accurately produce the correct physical response with an arbitrary but realistic loading condition, different from the test fixture, at least to a level of accuracy close to that which would result from the original transistor level spice model, say within 5%." I've found that board level simulation accuracy is difficult to quantify as a percentage number. There are a number of contributing factors such as etch width and thickness variations along the length of the interconnect line, cross-section variations(dielectric thickness), dielectric constant variation with frequency, humidity, temperature, etc. Most FR-4 type boards are themselves about 10% components. Holding the boards to a tighter tolerance is both expensive and difficult. It turns out that if the IBIS model is derived into a nominal resistive load that is representative of the transmission line characteristic impedance that the dominant effect in the simulation is usually the transmission line formed by the interconnect. I have verified this by actual measurement in a number of cases. This is not to say that the model is irrelevant, only that the model's output impedance curves and risetimes are not as critical as one might think in predicting the performance of the system. Brock Hannibal Design Engineer Tektronix, Inc. From owner-ibis Mon Oct 28 15:50:53 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 PAA21537; Mon, 28 Oct 1996 15:50:52 -0800 (PST) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbnle07756; Mon, 28 Oct 1996 18:39:15 -0500 (EST) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 28 Oct 1996 18:39:15 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA02043; Mon, 28 Oct 96 15:38:12 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA05779; Mon, 28 Oct 96 15:38:12 PST Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbnkz17375; Mon, 28 Oct 1996 17:28:11 -0500 (EST) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 28 Oct 1996 17:28:12 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00589; Mon, 28 Oct 96 09:10:37 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA01753; Mon, 28 Oct 96 09:10:37 PST Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <3274E90C.3F54BC7E@qdt.com> Date: Mon, 28 Oct 1996 09:10:36 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Brock Hannibal Cc: Bob Ross , uunet!uunet!ingr.com!efboeckm@uunet.uu.net, uunet!uunet!vhdl.org!ibis-users@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: Rising Waveform Loading Effects References: <199610252043.NAA07706@salope.cse.tek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brock Hannibal wrote: > > Hi all, > > Let me add a thought. Ed Boeckman asks: > > "I hope someone can help me to understand how the IBIS models will > accurately produce the correct physical response with an arbitrary but > realistic loading condition, different from the test fixture, at least > to a level of accuracy close to that which would result from the > original transistor level spice model, say within 5%." > > I've found that board level simulation accuracy is difficult to quantify > as a percentage number. There are a number of contributing factors such > as etch width and thickness variations along the length of the interconnect > line, cross-section variations(dielectric thickness), dielectric constant > variation with frequency, humidity, temperature, etc. Most FR-4 type boards > are themselves about 10% components. Holding the boards to a tighter tolerance > is both expensive and difficult. > > It turns out that if the IBIS model is derived into a nominal resistive > load that is representative of the transmission line characteristic > impedance that the dominant effect in the simulation is usually the > transmission line formed by the interconnect. > > I have verified this by actual measurement in a number of cases. This is > not to say that the model is irrelevant, only that the model's > output impedance curves and risetimes are not as critical as one might > think in predicting the performance of the system. > > Brock Hannibal > Design Engineer > Tektronix, Inc. I must disagree with this statement. Though accurate transmission line characteristics are crucial for simulation, risetime and IV curve accuracy is also important. The IV curve vs line impedance directly determines the incident wave height (and thus incident switching and/or number of round-trips to switch) and crosstalk and overshoot are a function of risetime/falltime as much as line coupling and impedance. Jon Powell Quad Design From owner-ibis Mon Oct 28 18:14:12 1996 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id SAA22648; Mon, 28 Oct 1996 18:14:11 -0800 (PST) Received: from inet1.tek.com by relay3.UU.NET with SMTP (peer crosschecked as: inet1.tek.com [134.62.48.21]) id QQbnlo22259; Mon, 28 Oct 1996 21:02:42 -0500 (EST) Received: from salope.cse.tek.com by inet1.tek.com id ; Mon, 28 Oct 1996 17:01:30 -0800 Received: from mdhost.cse.tek.com (localhost [127.0.0.1]) by salope.cse.tek.com (8.7.5/8.7.3) with ESMTP id RAA14039; Mon, 28 Oct 1996 17:01:28 -0800 (PST) Message-Id: <199610290101.RAA14039@salope.cse.tek.com> To: Jon Powell cc: Brock Hannibal , Bob Ross , uunet!uunet!ingr.com!efboeckm@uunet.uu.net, uunet!uunet!vhdl.org!ibis-users@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net, brockh@mdhost.cse.tek.com Subject: Re: Rising Waveform Loading Effects In-reply-to: Your message of "Mon, 28 Oct 1996 09:10:36 PST." <3274E90C.3F54BC7E@qdt.com> Date: Mon, 28 Oct 1996 17:01:28 -0800 From: Brock Hannibal Hi all, Well Jon, I don't think we fundamentally disagree. It's more a matter of degree. For instance, if I can hold tolerance of characteristic Z, losses, L and C of vias, L and C of package pins, stability of power supplies, etc. to really tight tolerances then I can make use of extremely accurate IBIS models which have V@t curves which are derived into my known load. Unfortunately all these other factors are extremely difficult to hold to tight tolerances. All I was saying was that an IBIS model derived into a resistive load is probably sufficient for most signal integrity work. The current crop of IBIS models are a far cry from being accurate enough to really predict the kinds of things Jon is talking about, but many of them are good enough to ensure that I don't drastically mis-terminate the transmission lines on my boards. Another question to think about: do Ibis models derived from Spice models really have the kind of accuracy that Jon needs? Brock Hannibal Design Engineer Tektronix, Inc. Jon Powell says, >I must disagree with this statement. Though accurate transmission line >characteristics are crucial for simulation, risetime and IV curve >accuracy is also important. The IV curve vs line impedance directly >determines the incident wave height (and thus incident switching and/or >number of round-trips to switch) and crosstalk and overshoot are a >function of risetime/falltime as much as line coupling and impedance. >Brock Hannibal wrote: >> >> Hi all, >> >> Let me add a thought. Ed Boeckman asks: >> >> "I hope someone can help me to understand how the IBIS models will >> accurately produce the correct physical response with an arbitrary but >> realistic loading condition, different from the test fixture, at least >> to a level of accuracy close to that which would result from the >> original transistor level spice model, say within 5%." >> >> I've found that board level simulation accuracy is difficult to quantify >> as a percentage number. There are a number of contributing factors such >> as etch width and thickness variations along the length of the interconnect >> line, cross-section variations(dielectric thickness), dielectric constant >> variation with frequency, humidity, temperature, etc. Most FR-4 type boards >> are themselves about 10% components. Holding the boards to a tighter tolerance >> is both expensive and difficult. >> >> It turns out that if the IBIS model is derived into a nominal resistive >> load that is representative of the transmission line characteristic >> impedance that the dominant effect in the simulation is usually the >> transmission line formed by the interconnect. >> >> I have verified this by actual measurement in a number of cases. This is >> not to say that the model is irrelevant, only that the model's >> output impedance curves and risetimes are not as critical as one might >> think in predicting the performance of the system. >> From owner-ibis Tue Oct 29 06:34:53 1996 Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id GAA14594; Tue, 29 Oct 1996 06:34:50 -0800 (PST) Received: from convex.convex.com by relay6.UU.NET with SMTP (peer crosschecked as: convex.convex.com [130.168.1.1]) id QQbnnl10792; Tue, 29 Oct 1996 09:23:19 -0500 (EST) Received: from flare.convex.com by convex.convex.com (8.6.4.2/1.35) id IAA06298; Tue, 29 Oct 1996 08:23:11 -0600 Received: from localhost by flare.convex.com (8.6.4/1.28) id IAA00293; Tue, 29 Oct 1996 08:23:10 -0600 Date: Tue, 29 Oct 1996 08:23:10 -0600 From: schumach@flare.convex.com (Richard A. Schumacher) Message-Id: <199610291423.IAA00293@flare.convex.com> To: brockh@mdhost.cse.tek.com, uunet!qdt.com!jonp@uunet.uu.net Subject: Re: Rising Waveform Loading Effects Cc: , , Bob@mdhost.cse.tek.com, Brock@mdhost.cse.tek.com, Hannibal@mdhost.cse.tek.com, Ross@mdhost.cse.tek.com, uunet!uunet!ingr.com!efboeckm@uunet.uu.net, uunet!uunet!vhdl.org!ibis-users@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net The current crop of IBIS models are a far cry from being accurate enough to really predict the kinds of things Jon is talking about, but many of them are good enough to ensure that I don't drastically mis-terminate the transmission lines on my boards. One almost does not need any models for that, IBIS or otherwise. If a simulator will not provide 200 mV and 500 psec accuracy while simulating a situation complex enough to be non-intuitive then it's hardly worth the trouble. Another question to think about: do Ibis models derived from Spice models really have the kind of accuracy that Jon needs? I don't know. How do we know how accurate such IBIS models are? That uncertainty is why I'm not rushing to embrace IBIS as a substitute for SPICE or measurement-derived I-V curves in simulation. When a vendor is willing to make direct comparisions between simulations (using their own nominal SPICE models, measured I-V curves and IBIS models) and measurements of actual circuits, and demonstrate at least 200 mV/500 psec accuracy, then I'll start to have some confidence. Such simulations must address realistic situations in multiple cases (heavy vs light loading, lumped vs transmission line environments), and not merely 50 pF - 500 ohm test cases. Until then I'll continue to press vendors for SPICE models or I-V curves, or generate my own. Richard Schumacher I do not speak in any capacity for the Convex Division of the Hewlett Packard Company. From owner-ibis Tue Oct 29 11:14:14 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 LAA17086; Tue, 29 Oct 1996 11:14:14 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Tue, 29 Oct 1996 19:03:25 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id LAA02917; Tue, 29 Oct 1996 11:01:52 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 29 Oct 96 11:01:51 PST Date: Tue, 29 Oct 96 10:39:00 PST From: Arpad Muranyi Message-ID: To: ibis-users@vhdl.org, ibis@vhdl.org Subject: Re: Bird 35.2 Text item: Chris, Probably not. I have thought about modeling it with the V-t curves also. I am frugal also, so I wouldn't want to add new syntax if we don't have to... I was talking about two different features. One of them would probably need that BIRD, but the other one might need something other than BIRD35. I am not sure though, since I have not spent too much time on this yet. For the time being, I am just following the conversation. Arpad ================================================================================ Arpad, In support of Dileep's comments, is it possible to model the multi-stage effect with V-T curves? In other words, if we already have a technique for capturing the significant effects of multi-stage drivers we should not add another method to do the same thing. I don't know the answer to this question, but I would like to see a demonstration of the correct answer one way or another. If Ibis can't model these drivers then we do need a technique to handle them. Chris Reid 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: Bird 35.2 To: ibis-users@vhdl.org, ibis@vhdl.org From: chris@icx.com ( Chris Reid) Date: Mon, 21 Oct 96 16:49 PDT Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 21 Oct 96 16:49 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 21 Oct 96 17:02 PDT Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 21 Oct 96 17:02 PDT Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/ 8.7.3) with SMTP id RAA09038; Mon, 21 Oct 1996 17:13:09 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.7.6/8.7.3) with ESMTP id RAA24745; Mon, 21 Oct 1996 17:08:28 -0700 (PDT) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id RAA19951; Mon, 21 Oct 1996 17: 05:54 -0700 (PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Oct 29 11:10:04 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 LAA17053; Tue, 29 Oct 1996 11:10:03 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Tue, 29 Oct 1996 18:59:16 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id KAA02616; Tue, 29 Oct 1996 10:57:42 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 29 Oct 96 10:57:42 PST Date: Tue, 29 Oct 96 10:29:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: R_Pad? Text item: Scott, I agree with Stephen Peters, that the pad resistance is included in the I-V curves of the pullup and/or pulldown structures. This is similar to the resistive properties of the diodes. A pure diode I-V curve is exponential, and if you plot that equation, you will see currents in the Giga and Tera Ampere magnitude already at 1 Volt of forward bias. The diode equation in text books refers to junction voltage, not terminal voltage, and there is a significant series resistance between the junction and the terminals. I have seen many SPICE models that ignore the resistive properties of the ESD diodes, yielding such large currents at 1 Volt of over or undershoot. So much for the accuracy of the SPICE models... Real diodes do not have such I-V curves, they usually start out exponentially, but then straighten out when the resistive properties begin to limit the current. So, between 1 and 5 volts of forward bias (if the device lets this) you would get a more or less linear I-V curve with a few Ohms slope. Just like we don't separate this resistance, I don't think we need to separate the pad resistance. It just simply modifies the shape of the transistor I-V curves. Also, in most cases the effect of the pad resistance is so small that I don't think it would be noticable by just eyeballing the curve (in contrary to the diode example above). From your EMAIL, it seems to me that you might have a different problem, if the pad resistance seemed to make such a big difference, or if the subtraction made an almost 0 pulldown curve. I would be glad to help you with that problem, but you would have to supply more information. (Your IBIS model might have beed incorrectly done also). I hope this helps, Arpad Muranyi Intel Corporation ================================================================================ Hello Scott, and fellow IBISains: If I recall past conversations correctly, resistance between the pad and the active xsistors has been accounted for by including it's effects in the pullup and pullown curves. At least, that is how I have done models before. I'm curious however -- do you see a reason why this resistance should be called out seperatly? It's a good question.... Regards, Stephen Peters Intel Corp. Hello IBIS folk, I'm participating in my companies initial developement stages of generating IBIS files, and currently we are simultaniously investigating generating them from both actual silicon, as well as from spice netlists. Were new to this email list, so please excuse us if this has been discussed: I have searched all of the documents that I could find, including searching through the email archives, but we are still having trouble answering this one question: How do we deal with a Pad resistance (CMOS)... R_comp would have been perfect for this. It seems that those who asked about R_comp in the past were told to figure it into the R_package (or R_pin). However, when the data is collected from real silicon without the package (using a tester's probe leads directly on the die's I/O pads), any resistance between the I/O pad and the I/O buffer circuitry gets included... So the test yeilds Pull-up and Pull-down data that includes an effective R_comp. For those who have designs with a built-in resistance between your pad and your I/O circuitry, how did you deal with this since the specs don't allow for R_comp, and including this resistance in the R_package is (seems) impossible? The thing that flagged us to this problem was that our Pull-down curve (after subtracting the Power-clamp diode data from the initial pull-down data) gets brought down to close to 0 current when there's about a diode voltage above Vcc on the pin (in our initial SPICE testing where we included a resistance between the I/O circuitry and the Pad). Thanks in advance, -Scott Schlachter Actel Corporation Sunnyvale, CA 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***. From: Stephen Peters Date: Wed, 23 Oct 1996 09:43:04 -0700 Subject: R_Pad? To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <199610231642.JAA04144@ichips.intel.com> Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id JAA04144; Wed, 23 Oct 1996 09:42:33 -0700 (PDT) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.in tel.com (8.7.6/8.7.3) with ESMTP id JAA10899; Wed, 23 Oct 1996 09:43:03 -0700 (P DT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl. org (8.7.3/8.7.3) with ESMTP id JAA02275; Wed, 23 Oct 1996 09:53:49 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.7.6/8.7.3) with ESMTP id JAA04851; Wed, 23 Oct 1996 09:49:05 -0700 (PDT) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id JAA17644; Wed, 23 Oct 1996 09: 46:32 -0700 (PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Oct 29 14:39:37 1996 Received: from netcomsv.netcom.com (uucp9.netcom.com [163.179.3.9]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA18826; Tue, 29 Oct 1996 14:39:36 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA00342; Tue, 29 Oct 1996 14:12:40 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA26186; Tue, 29 Oct 96 14:02:49 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA19636; Tue, 29 Oct 1996 14:11:36 +0800 Date: Tue, 29 Oct 1996 14:11:36 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9610292211.AA19636@contec13.contec.COM> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: R_Pad? Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Arpad Muranyi, Intel Corporation wrote: > I have seen many SPICE models that ignore the resistive properties of the ESD > diodes, yielding such large currents at 1 Volt of over or undershoot. So much > for the accuracy of the SPICE models... > Please do not get confused between the model EQUATIONS and model PARAMETERS. SPICE diode model equations have the provision for specifying the parasitic resistance. Of course, if it is not specified in the model PARAMETERS, it can produce large currents. IBIS models will exhibit similar unrealistic behavior if the parasitic resistance is not taken into account while making the ibis model from simulations. It is always possible to use a very good model improperly to produce unrealistic results. SPICE is not to be blamed for that. ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Tue Oct 29 17:48:51 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 RAA20536; Tue, 29 Oct 1996 17:48:51 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA28503; Tue, 29 Oct 96 17:38:49 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA06967; Tue, 29 Oct 96 18:38:47 PPE Date: Tue, 29 Oct 96 18:38:47 PPE From: scotts@actel.com (Scott Schlachter) Message-Id: <9610300138.AA06967@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: R_Pad? Cc: dileep@contec.Apsimtech.COM Dileep and Arpad: HSPICE will model the inherent CMOS diodes (D to Bulk) within the transistor model. From what I can tell, there seems to be a fallback to this specification of the model: the diode saturation current equations do not appear to have any way to include any parasitic resistance whatsoever. I believe that you both have valid points here. HSPICE can model the diode correctly, but it seems that the only way is to extract it from the said transistors, and model it seperately - a definate unexpected extra step. When modeled this way, there is no problem assigning the appropriate parasitic impedances associated with the diodes. However, in trying to keep the power and ground clamp diodes as being inherently modeled within the pull-up and pull-down transistors, there seems to be a flaw with the HSPICE model. Perhaps there is something that I'm overlooking with this, and if anyone knows how to deal with this in the HSPICE transistor models, please respond. Thanks, -Scott Schlachter Actel Corporation > Arpad Muranyi, Intel Corporation wrote: > > > I have seen many SPICE models that ignore the resistive properties of the ESD > > diodes, yielding such large currents at 1 Volt of over or undershoot. So much > > for the accuracy of the SPICE models... > > > > Please do not get confused between the model EQUATIONS and model PARAMETERS. > SPICE diode model equations have the provision for specifying the parasitic > resistance. Of course, if it is not specified in the model PARAMETERS, > it can produce large currents. IBIS models will exhibit similar unrealistic > behavior if the parasitic resistance is not taken into account while > making the ibis model from simulations. It is always possible to use a very > good model improperly to produce unrealistic results. SPICE is not to be > blamed for that. > > ------------------------------------------------------------ > Dileep Divekar > Applied Simulation Technology, Inc. > 2188 Bering Drive > San Jose, CA 95131 > > Phone - (408)-434-0967 x 100 > Fax - (408)-434-1003 > Email - dileep@apsimtech.com > ------------------------------------------------------------ > From owner-ibis Wed Oct 30 08:42:00 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 IAA12914; Wed, 30 Oct 1996 08:41:59 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 30 Oct 1996 16:31:11 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id IAA18870; Wed, 30 Oct 1996 08:29:28 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 30 Oct 96 08:29:27 PST Date: Wed, 30 Oct 96 08:24:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org cc: dileep@contec.Apsimtech.COM Subject: Re[2]: R_Pad? Text item: Scott, There is no need to take out the parasitic diodes from the MOSFETs in order to model them correctly (i.e. to include their resistiveness). You are right, that the current equation itself does not include the resistance, but there is no need for it. (If you included the resistance in the diode equation, you would end up with a transcendental equation which is a tough one to work with). 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. Notice that these resistances all default to zero. This means that if someone doesn't specify them explicitly, there will be no resistive parasitics in the model. (Which happens way to often, unfortunately). Arpad =============================================================================== Dileep and Arpad: HSPICE will model the inherent CMOS diodes (D to Bulk) within the transistor model. From what I can tell, there seems to be a fallback to this specification of the model: the diode saturation current equations do not appear to have any way to include any parasitic resistance whatsoever. I believe that you both have valid points here. HSPICE can model the diode correctly, but it seems that the only way is to extract it from the said transistors, and model it seperately - a definate unexpected extra step. When modeled this way, there is no problem assigning the appropriate parasitic impedances associated with the diodes. However, in trying to keep the power and ground clamp diodes as being inherently modeled within the pull-up and pull-down transistors, there seems to be a flaw with the HSPICE model. Perhaps there is something that I'm overlooking with this, and if anyone knows how to deal with this in the HSPICE transistor models, please respond. Thanks, -Scott Schlachter Actel Corporation > Arpad Muranyi, Intel Corporation wrote: > > > I have seen many SPICE models that ignore the resistive properties of the ESD > > diodes, yielding such large currents at 1 Volt of over or undershoot. So much > > for the accuracy of the SPICE models... > > > > Please do not get confused between the model EQUATIONS and model PARAMETERS. > SPICE diode model equations have the provision for specifying the parasitic > resistance. Of course, if it is not specified in the model PARAMETERS, > it can produce large currents. IBIS models will exhibit similar unrealistic > behavior if the parasitic resistance is not taken into account while > making the ibis model from simulations. It is always possible to use a very > good model improperly to produce unrealistic results. SPICE is not to be > blamed for that. > > ------------------------------------------------------------ > Dileep Divekar > Applied Simulation Technology, Inc. > 2188 Bering Drive > San Jose, CA 95131 > > Phone - (408)-434-0967 x 100 > Fax - (408)-434-1003 > Email - dileep@apsimtech.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***. Cc: dileep@contec.Apsimtech.COM Subject: Re: R_Pad? To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9610300138.AA06967@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Tue, 29 Oct 96 18:38:47 PPE Received: by ricky.sun_net (4.1/SMI-4.1) id AA06967; Tue, 29 Oct 96 18:38:47 PPE Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA28503; Tue, 29 Oct 96 17:38:49 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 RAA20536; Tue, 29 Oct 1996 17:48:51 -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 RAA20387; Tue, 29 Oct 1996 17:43:57 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id TAA12789; Tue, 29 Oct 1996 19: 56:15 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Oct 31 16:07:57 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 QAA14128 for ; Thu, 31 Oct 1996 16:07:57 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id PAA16115; Thu, 31 Oct 1996 15:57:47 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma016025; Thu Oct 31 15:57:41 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA28107 for ibis-users@vhdl.org; Thu, 31 Oct 96 15:56:58 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA24378; Thu, 31 Oct 96 15:57:56 PST Date: Thu, 31 Oct 96 15:57:56 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9610312357.AA24378@rockie.nsc.com> To: ibis-users@vhdl.org Subject: Open_drain and s2ibis(v1.3) Cc: huq@rockie.nsc.com, slipa@eos.ncsu.edu Hi, I have been having some problems getting an Open_drain to work with the s2ibis(Rev1.3). So I decided to check out the FAQ on NCSU website and found the following ----------------------------------------------------------------------------- QUESTION (7): "I'm having trouble getting s2ibis to deal with my open-drain I/O pin!?!" ANSWER: This is a problem with the IBIS v1.1 spec. IBIS v1.1 sees open-drain pins as output only. You need to go to a newer IBIS version. ----------------------------------------------------------------------------- My ouput is an I/O Open Drain. Since v1.1 does not support that, I tried to model that as Open_drain only. Has anyone run into this type of problems ? I think I can make it work by manually editing the .spi file. Just wanted to know if anyone has a better work around ? Regards Syed National Semiconductor Corp.