From owner-ibis Tue Oct 1 16:45:30 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 QAA16458 for ; Tue, 1 Oct 1996 16:45:29 -0700 (PDT) Received: from uucp2.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQbjpm16027; Tue, 1 Oct 1996 19:34:54 -0400 (EDT) Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Tue, 1 Oct 1996 19:34:56 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01858; Tue, 1 Oct 96 16:12:28 PDT Received: from awacs.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA26398; Tue, 1 Oct 96 16:12:28 PDT Date: Tue, 1 Oct 96 16:12:28 PDT From: peivand@qdt.com (Peivand Tehrani) Message-Id: <9610012312.AA26398@hal.qdt.com> To: ibis@vhdl.org Subject: subscribe please subscribe me in the ibis mailing list. From owner-ibis Thu Oct 3 09:11:49 1996 Received: from chronos.synopsys.com (chronos.synopsys.com [146.225.8.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA06708 for ; Thu, 3 Oct 1996 09:11:38 -0700 (PDT) Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA09451 (5.65c/IDA-1.4.4 for ); Thu, 3 Oct 1996 09:01:43 -0700 Received: from siarc.siarc.com (siarc.siarc.com [192.195.172.10]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id JAA27187 for ; Thu, 3 Oct 1996 09:01:00 -0700 Received: from [192.195.172.236] ([192.195.172.236]) by siarc.siarc.com (8.6.9/8.6.9) with SMTP id JAA10976 for ; Thu, 3 Oct 1996 09:04:54 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Oct 1996 09:02:22 -0800 To: ibis@vhdl.org From: crowen@siarc.com (Chris Rowen) Subject: Request for contact IBIS community: I'd like to take a moment to introduce myself, to to make contact on behalf of the steering working group of VSIA, the Virtual Socket Interface Alliance. The alliance is driving industry visibility and standards for mix-and-match of macro blocks (virtual components) for system-on-a-chip design. I am the VP of engineering for Synopsys's Design Reuse Group, Synopsys's representative to VSIA and chair of the subcommittee on working groups. Part of the charter of this committee is to identify which are the technical areas of greatest concern and importance to the design community in promoting the flow of "intellectual property blocks" inside and among companies. To that end, I want to make contact with the IBIS participants and understand how I/O buffers may play a role in macro block interchange. I am eager to hear back with thoughts, suggestions or proposals on the relevance of I/O buffers to interchange, the state of the IBIS effort, and suggestions about how IBIS might interact with VSIA, if there are areas of common interest. Chris Chris Rowen crowen@synopsys VP Engineering, Design Reuse Group Synopsys, Inc. 700 East Middlefield Road Mountain View, CA 94043-4033 tel (415) 943 5264 fax (415) 943 5010 pager (415) 317 1105 mobile (408) 334 0361 From owner-ibis Thu Oct 3 17:08:14 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 RAA10872 for ; Thu, 3 Oct 1996 17:08:12 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 3 Oct 96 16:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 3 Oct 96 16:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 3 Oct 96 16:59 PDT Message-Id: Date: Thu, 3 Oct 96 16:59 PDT From: bob@icx.com ( Bob Ross) To: crowen@siarc.com, ibis@vhdl.org Subject: Re: Request for contact Chris: On behalf of the IBIS community, I am willing to pursue further discussion. Furthermore, I can provide you with any information you need concerning our actives and concerning the technical details. If you have not already done so, you can also get information on our official home page http://eia.org/eig/ibis/ibis.htm I am not familiar with your committee's activities, so I cannot relate exactly how we may fit in. Briefly, we have standardized the electrical chararcterization of and I/O block to include parameters useful for electrical analog simulation. Our format is human-readable text. While it could be configured as an "intellectual property" block, that is not within the domain of the commitee's activities. Let us establish direct contact to pursue further discussions. I need to learn more of VSIA. Anyone else who is interested in this subject is encouraged to contact Chris. Best Regards, Bob Ross IBIS Open Forum Chair Phone (503) 603-2523, Fax (503) 639-3469 bob@icx.com Interconnectix, Inc., 10220 S.W. Nimbus Ave., K4, Portland, OR 97223 > Date: Thu, 3 Oct 1996 09:02:22 -0800 > To: ibis@vhdl.org > From: crowen@siarc.com (Chris Rowen) > Subject: Request for contact > Status: RO > IBIS community: > I'd like to take a moment to introduce myself, to to make contact > on behalf of the steering working group of VSIA, the Virtual Socket > Interface Alliance. The alliance is driving industry visibility and > standards for mix-and-match of macro blocks (virtual components) > for system-on-a-chip design. I am the VP of engineering for Synopsys's > Design Reuse Group, Synopsys's representative to VSIA and chair of > the subcommittee on working groups. Part of the charter of this > committee is to identify which are the technical areas of greatest > concern and importance to the design community in promoting the > flow of "intellectual property blocks" inside and among companies. > To that end, I want to make contact with the IBIS participants and > understand how I/O buffers may play a role in macro block interchange. > I am eager to hear back with thoughts, suggestions or proposals > on the relevance of I/O buffers to interchange, the state of the > IBIS effort, and suggestions about how IBIS might interact with > VSIA, if there are areas of common interest. > Chris > Chris Rowen > crowen@synopsys > VP Engineering, Design Reuse Group > Synopsys, Inc. > 700 East Middlefield Road > Mountain View, CA 94043-4033 > tel (415) 943 5264 > fax (415) 943 5010 > pager (415) 317 1105 > mobile (408) 334 0361 From owner-ibis Wed Oct 9 07:29:14 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 HAA16797 for ; Wed, 9 Oct 1996 07:29:05 -0700 (PDT) Received: from s01.thesys.de by relay.xlink.net id <38849-0@relay.xlink.net>; Wed, 9 Oct 1996 15:18:02 +0000 Received: from s36.design by s01.thesys.de (4.1/SMI-4.1) id AA26556; Wed, 9 Oct 96 16:18:41 +0100 Date: Wed, 9 Oct 96 16:18:41 +0100 From: cornelia@thesys.de (Cornelia Foss) Message-Id: <9610091518.AA26556@s01.thesys.de> To: ibis@vhdl.org Subject: Problem with s2ibis2 To IBIS engineers I have got a problem with s2ibis2 and can't solve it useing the documentation only. I'm running s2ibis2 on a sparc station to create IBIS models based upon HSPICE files. Though I set Vinl to 0 and Vinh to 5, IBIS runs the HSPICE jobs with 0.8V and 2 V, respectively. Confusingly in the .ibs file appears "Vinl= 0" and "Vinh= 5". I also defined [Sim time] to be 15ns but the .tran source is set to "PULSE(2 0.8 0 0 0 0 0)" and the analysis statement to ".tran 0 0". Additionally it was a great help if you could tell me where I can find a descriptionof the "NoModel" option that is not documentated in the s2ibis2 docs. I'm gratefully looking forward to any reply. Kindest regards Sascha Pawel. From owner-ibis Wed Oct 9 14:08:48 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 OAA20618 for ; Wed, 9 Oct 1996 14:08:46 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 9 Oct 96 13:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 9 Oct 96 13:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 9 Oct 96 13:59 PDT Message-Id: Date: Wed, 9 Oct 96 13:59 PDT From: bob@icx.com ( Bob Ross) To: cornelia@thesys.de, ibis@vhdl.org Subject: Re: Problem with s2ibis2 Sascha: I do not have specific answers to your questions. However, I plan to put the s2ibis2 fixup issue on the IBIS Open Forum agenda for the October 18, 1996 meeting. Any ideas are welcome. Best Regards, Bob Ross Interconnectix, Inc. > Date: Wed, 9 Oct 96 16:18:41 +0100 > From: cornelia@thesys.de (Cornelia Foss) > Message-Id: <9610091518.AA26556@s01.thesys.de> > To: ibis@vhdl.org > Subject: Problem with s2ibis2 > Status: RO > To IBIS engineers > I have got a problem with s2ibis2 and can't solve it useing the > documentation only. > I'm running s2ibis2 on a sparc station to create IBIS models > based upon HSPICE files. Though I set Vinl to 0 and Vinh to 5, > IBIS runs the HSPICE jobs with 0.8V and 2 V, respectively. > Confusingly in the .ibs file appears "Vinl= 0" and "Vinh= 5". > I also defined [Sim time] to be 15ns but the .tran source is set to > "PULSE(2 0.8 0 0 0 0 0)" and the analysis statement to ".tran 0 0". > Additionally it was a great help if you could tell me where I can > find a descriptionof the "NoModel" option that is not documentated > in the s2ibis2 docs. > I'm gratefully looking forward to any reply. > Kindest regards > Sascha Pawel. From owner-ibis Wed Oct 9 16:58: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 QAA22452 for ; Wed, 9 Oct 1996 16:58:09 -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 QAA14388 for ; Wed, 9 Oct 1996 16:47:23 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id QAA25182; Wed, 9 Oct 1996 16:47:23 -0700 (PDT) Message-Id: <199610092347.QAA25182@ichips.intel.com> To: ibis@vhdl.org Subject: IBIS packaging subcommittee Date: Wed, 09 Oct 1996 16:47:24 -0700 From: Stephen Peters Hello All: The next meeting of the IBIS packaging subcommittee will be this Friday, Oct 11. Phone bridge details are below. Time: 8:30 - 10:00 Pacific Daylight Time Phone #: (916) 356-9200 Res #: 10103413 Passcode: 3665174 I will follow up with a short agenda tommorrow. Regards, Stephen From owner-ibis Thu Oct 10 13:06: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 NAA17538 for ; Thu, 10 Oct 1996 13:06:53 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id MAA22106 for ; Thu, 10 Oct 1996 12:58:47 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma021794; Thu Oct 10 12:58:22 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA16465 for ibis@vhdl.org; Thu, 10 Oct 96 12:55:48 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA01862; Thu, 10 Oct 96 12:56:31 PDT Date: Thu, 10 Oct 96 12:56:31 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9610101956.AA01862@rockie.nsc.com> To: ibis@vhdl.org Subject: FREE IBIS info from National Semiconductor Cc: huq@rockie.nsc.com, cjfgsc@tevm2.nsc.com IBIS fans: You can get FREE helpful IBIS related information from the 1996: National Interface Databook. Chapter13(Modeling Support)is entirely dedicated to IBIS modeling and related subject matter. For a FREE copy, visit the Website at http://www.national.com and click on 'Design Engineers' then click on 'Free Interface Databook'. Regards, Syed Vice-Chair ANSI/EIA-656(IBIS) National Semiconductor Corp. From owner-ibis Thu Oct 10 14:56:01 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 OAA18449 for ; Thu, 10 Oct 1996 14:50:41 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 10 Oct 1996 21:37:58 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id OAA22993; Thu, 10 Oct 1996 14:36:48 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 10 Oct 96 14:36:48 PDT Date: Thu, 10 Oct 96 13:38:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: huq@rockie.nsc.com Subject: Re: FREE IBIS info from National Semiconductor Text item: Would it be possible, or make sense to have this on-line, and have a link to it from the IEEE Web page? Arpad =============================================================================== IBIS fans: You can get FREE helpful IBIS related information from the 1996: National Interface Databook. Chapter13(Modeling Support)is entirely dedicated to IBIS modeling and related subject matter. For a FREE copy, visit the Website at http://www.national.com and click on 'Design Engineers' then click on 'Free Interface Databook'. Regards, Syed Vice-Chair ANSI/EIA-656(IBIS) 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, cjfgsc@tevm2.nsc.com Subject: FREE IBIS info from National Semiconductor To: ibis@vhdl.org Message-Id: <9610101956.AA01862@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Thu, 10 Oct 96 12:56:31 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA01862; Thu, 10 Oct 96 12:56:31 PDT Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA16465 for ibis@vhdl.org; Thu, 10 Oct 96 12:55:48 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma021794; Thu Oct 10 12:58:22 1996 Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id MAA2210 6 for ; Thu, 10 Oct 1996 12:58:47 -0700 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 NAA17538 for ; Thu, 10 Oct 19 96 13:06:53 -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 NAA29059; Thu, 10 Oct 1996 13:05:42 -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 NAA03920; Thu, 10 Oct 1996 13:05:42 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Oct 10 15:27:32 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 PAA18701 for ; Thu, 10 Oct 1996 15:27:32 -0700 (PDT) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id PAA08984; Thu, 10 Oct 1996 15:19:22 -0700 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma008870; Thu Oct 10 15:19:13 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA27400 for ibis@vhdl.org; Thu, 10 Oct 96 15:16:38 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA06876; Thu, 10 Oct 96 15:17:22 PDT Date: Thu, 10 Oct 96 15:17:22 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9610102217.AA06876@rockie.nsc.com> To: ibis@vhdl.org, Arpad_Muranyi@ccm.fm.intel.com Subject: Re: FREE IBIS info from National Semiconductor Cc: huq@rockie.nsc.com Hi, This offer is only valid for a limited amount of time('til we run out!) so we cannot really establish a link ... Regards, Syed. > From owner-ibis@vhdl.vhdl.org Thu Oct 10 14:53:41 1996 > Date: Thu, 10 Oct 96 13:38:00 PDT > From: Arpad Muranyi > To: ibis@vhdl.org > Cc: huq@rockie.nsc.com > Subject: Re: FREE IBIS info from National Semiconductor > Content-Length: 2066 > > > Text item: > > Would it be possible, or make sense to have this on-line, and have a link to it > from the IEEE Web page? > > Arpad > > =============================================================================== > > > IBIS fans: > > You can get FREE helpful IBIS related information from the > 1996: National Interface Databook. > > Chapter13(Modeling Support)is entirely dedicated to IBIS modeling > and related subject matter. > > For a FREE copy, visit the Website at http://www.national.com and > click on 'Design Engineers' then click on 'Free Interface Databook'. > > Regards, > Syed > Vice-Chair ANSI/EIA-656(IBIS) > 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, cjfgsc@tevm2.nsc.com > Subject: FREE IBIS info from National Semiconductor > To: ibis@vhdl.org > Message-Id: <9610101956.AA01862@rockie.nsc.com> > From: huq@rockie.nsc.com (Syed Huq) > Date: Thu, 10 Oct 96 12:56:31 PDT > Received: from kural by rockie.nsc.com (4.1/SMI-4.1) > id AA01862; Thu, 10 Oct 96 12:56:31 PDT > Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP > id AA16465 for ibis@vhdl.org; Thu, 10 Oct 96 12:55:48 -0700 > Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) > id sma021794; Thu Oct 10 12:58:22 1996 > Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id MAA2210 > 6 for ; Thu, 10 Oct 1996 12:58:47 -0700 > 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 NAA17538 for ; Thu, 10 Oct 19 > 96 13:06:53 -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 NAA29059; Thu, 10 Oct 1996 13:05:42 -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 NAA03920; Thu, 10 Oct 1996 13:05:42 -0700 ( > PDT) > Return-Path: owner-ibis@vhdl.vhdl.org > From owner-ibis Fri Oct 11 11:17:38 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 LAA13514 for ; Fri, 11 Oct 1996 11:17:28 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 11 Oct 96 11:01 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 11 Oct 96 11:01 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 11 Oct 96 11:03 PDT Message-Id: Date: Fri, 11 Oct 96 11:03 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD39 - SPECIFICATION ENHANCEMENT Cc: john_m_keifer@ccm.fm.intel.com To IBIS Committee: BIRD39 is put forth as the Specification Committee recommendation. BIRD39 supercedes BIRD38 by John Fitzpatrick on overshoot and dynamic overshoot, some proposals by Ahmed Omer on dynamic noise immunity, and a proposal in Egg12 by Bob Ross on min and max thresholds. Comments are welcome. Bob Ross Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 39 ISSUE TITLE: SPECIFICATION ENHANCEMENT REQUESTER: John Fitzpatrick, Alcatel CIT Ahmed Omer, Motorola, Inc. Jon Powell, Quad Design Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 10/11/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Additional optional specification parameters are needed for completeness and useful extensions. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The optional [Model Spec] keyword is proposed to be associated with a model. Its purpose is to provide an extendable format to deal with new specification. Several parameters are contained in the proposal. |============================================================================== | Keywords: [Model Spec] | Required: No | Sub-params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, Overshoot_high, | Overshoot_low, D_overshoot_high, D_overshoot_low, | D_overshoot_time, Pulse_high, Pulse_low, Pulse_time | |Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparamters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- | Overshoot_high Static overshoot high voltage | Overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab or tab character. All four columns are required | under the [Model Spec] keyword. However, data is required | only in the typical column. If minimum and/or maximum values | are not available, the reserved word "NA" must be used | indicating the typical value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage range settings. | | Unless noted below, each subparameter does not require having | any other subparameter. | | Vinh, Vinl rules: | The threshold subparameter lines | provide additional min and max column values, if needed. | The typ column values are still required and would be | expected to override the Vinh and Vinl subparameter values | specified elsewhere. Note: the syntax rule that require | inserting Vinh and Vinl under models remains unchanged | even if the values are defined under the [Model Spec] | keyword. | | To mimic a hysteresis effect, the values of Vinh and Vinl may | interchanged such that the Vinl value is larger than the Vinh | value. However, simulators may process this information | differently or report an error. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | The four hysteresis subparmeters must all be defined before | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | | Overshoot_high, Overshoot_low rules: | The static overshoot sub-parameters provide the voltage values | for which the component is no longer guaranteed to function | correctly. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | The dynamic overshoot values provide a time window during | which the the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time is | required for dynamic overshoot testing. In addition, if | D_overshoot_high is specified, then Overshoot_high is necessary | for testing beyond the static limit. Similarly, if | D_overshoot_low is specified, then Overshoot_low is necessary | for testing beyond the static limit. | | Pulse_high, Pulse_low, Pulse_time rules: | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. Similarily, | the falling response drop below the Vinh value, but remain | above the Pulse_low value. In either case the input is | regarded as immune to switching if the the responses are | within these extended windows. If the hysteresis thresholds | are defined, then the rising response shall use Vinh- as the | reference voltage, and the falling response shall use Vinl+ | as the reference voltage. | |------------------------------------------------------------------------------ [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | Overshoot_high 5.5 5.0 6.0 | Static overshoot Overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRD39 is introduced to assist the model provider, model user and EDA tool provider. The model provider provides better models: - Improve specification threshold details for CMOS and other technologies - Allow hysteresis inputs to be modeled The model user can do better analysis: - Work with dynamic overshoot, a parameter not usually specified in datasheets - Work with pulse immunity The EDA tool provider has some clearly defined parameters for more expedient tool development: - Provide an easy to parse structure - Provide an evolution path for future extensions Providing a consistent extension format appears valuable, even if some parameters do not fit exactly. It may overspecify most parameters. The min/typ/max format was chosen over explicit definitions such as: Vinh_min = Vinl_max = Each additional subparameter would then require 3 names. Vinl and Vinh for typical values are redundant. The [Model Spec] subparameters are chosen to override the regular [Model] Subparameter because it is presumed that specification subparameter was purposefully chosen an may give more detail. The [Model] Vinh and Vinl remain required to support processing of files in simulators which support portions, but not all of Version 3.X. The following diagram shows how the hysteresis subparameters are defined: ^ O | +-------+----<----+--------+------------ U | ! ! ! ! T | ! ! ! ! P | ! ! ! ! U | ! ! ! ! T | ! ! ! ! | v v ^ ^ V | ! ! ! ! O | ! ! ! ! L | ! ! ! ! T | ! ! ! ! T | ! ! ! ! A | ! ! ! ! G | ! ! ! ! E | -----------+-------+---->----+--------+ |_____________________________________________________________> Vinl- Vinl+ Vinh- Vinh+ INPUT VOLTAGE Rather than getting into a complicated set of mixed rules, all four hysteresis subparameters were chosen to be required for hysteresis checking to take effect. The Overshoot_high and Overshoot_low values are the same subparameters as in RAIL. These are static. The dynamic overshoot, as introduced by BIRD38 can be represented by tables. However, such information is readily available for more than a handful of parts. Therefore a simpler representation was chosen. This would work with the PCI specification. There are defined test setups for dynamic overshoot - often a large voltage such as 5 V above the rail into 50 ohms connected to an input. Since the input typically has clamping, the actual overshoot value may depend on the clamp I/V characteristics. Thus the specification limits in the table may be voltages that arise with the clamp in place. The dynamic overshoot is a maximum voltage over which voltage may exceed the static overshoot limit for a maximum period of time. Thus no dynamic overshoot is specified unless time is specified and the two high limits (Overshoot_high and D_overshoot_high) or the two low limits (Overshoot_low and D_overshoot_low) are both in each case specified. Otherwise, no dynamic overshoot testing is done. It is too complicated to create a set of default scenerios. After long discussion, by the specification subcommittee, the pulse immunity specification was defined similar to the dynamic overshoot. The data appears mostly available from typical curves given as general information. The pulse immunity parameters can be estimated from the typical values. In fact, the designer has great latitude to enter a set of pulse and amplitude values according to how much immunity is to be tolerated. The reference thresholds from which immunity is calculated is chosen to be the limit input thresholds. Both the dynamic overshoot and pulse immunity data are not true specification limits. The data may appear as a pulse amplitude versus pulse duration graph for a typical device. Therefore the user may be the primary source of this data based on how conservative the user chooses. Because the data is not in the format of a true specification, it does not seem reasonable to provide a format for tabular data where there is no reliable source of such data. The pulse immunity data appears to be based on a typical threshold device. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This proposal replaces BIRD38 and expands the Specification areas regarding Overshoot. It also replaces Egg12 regarding typical, minimum, maximum format options for threshold specifications. The Specification committee consisted of Ahmed Omer, John Fitzpatrick, Jon Powell, and Bob Ross. ****************************************************************************** From owner-ibis Fri Oct 11 11:24:32 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 LAA13544 for ; Fri, 11 Oct 1996 11:24:30 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 11 Oct 96 11:13 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 11 Oct 96 11:13 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 11 Oct 96 11:16 PDT Message-Id: Date: Fri, 11 Oct 96 11:16 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA 10/18/96 IBIS Open Forum Meeting Agenda for 10/18/96 Bridge Number Reservation # Passcode ** Revised Reservation/Passcode ** (916) 356-9200 2-104707 6396839 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions Design SuperCon97 IBIS Meeting Huq s2ibis2 Plans Ross DAC97 IBIS Meeting Planning Rusher IEC Progress Rusher New Administrative Issues All 8:50 Technical Discussion BIRD37.2 - ENHANCEMENT TO THE PACKAGE MODEL SPEC. Peters (Vote) PACKAGE COMMITTEE REPORT Peters SPECIFICATION COMMITTEE REPORT Powell, All BIRD39 - SPECIFICATION ENHANCEMENT BIRD38 - MAXIMUM VOLTAGE BIRD35.2 - MULTI-STAGED OUTPUTS Ross PARSER ENHANCEMENT PROPOSAL Rokusek New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Mon Oct 14 02:36:21 1996 Received: from via.com.tw ([203.70.217.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id CAA21190 for ; Mon, 14 Oct 1996 02:36:13 -0700 (PDT) Received: from sun13.via.com.tw ([203.70.217.82]) by via.com.tw (4.1/SMI-4.1) id AA20932; Mon, 14 Oct 96 17:25:35 CST Message-Id: <326205ED.2B28@via.com.tw> Date: Mon, 14 Oct 1996 17:20:45 +0800 From: Huang Organization: VIA X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: IBIS committee Subject: s2ibis2 question? Content-Type: multipart/mixed; boundary="------------3C329507C80" This is a multi-part message in MIME format. --------------3C329507C80 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Hello, I am a new learner for IBIS models version 2.1 and is using s2ibis2. Now I am facing a problem: while I characterize for a simple 3-state I/O pad (refer to attachment), the generated .spi file will not function correctly. After examining the .spi file, I found the TN pin will NOT be set while characterizing for the A pin (and vice versa). So I need to correct this error by hand. Is there any way to make this process more automatically? Or I make a wrong .s2i file? Besides, if I just want the bd4t model for IO pin, could I just not create for the other 2 models for A and TN? Any help or comments will be appreciated. best regards, Arthur Huang ps. my s2ibis2 is s2ibis2.sparc, version no. v0.91BETA [attachment] (first is bd4t.s2i, and second is bd4t) --------------3C329507C80 Content-Type: text/plain; charset=big5; name="bd4t.s2i" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bd4t.s2i" | TEST IBIS characterization [IBIS Ver] 2.1 [File rev] 1.0 [Date] Mon Oct 14 15:56:30 1996 [Disclaimer] for characterization purpose only [Spice type] hspice | [Iterate] | [Cleanup] [Component] bd4t [Manufacturer] Arthur | [Package model] pkg_type [Spice file] bd4t [Temperature range] 50 100 0 [Voltage range] 3.3 3.0 3.6 [R_pkg] 1.0m 0.5m 1.5m [L_pkg] 2.5nH 2.0nH 3.0nH [C_pkg] 4.0pF 3.5pF 4.5pF | [Diff pin] | describe the differential pin list | [Pin mapping] | currently just neglect this command [Pin] A A s_A A TN TN s_TN TN IO IO s_IO bd4t -> A TN VDD vdd s_p POWER pGND g GND GND [Model] A [Model type] Input [Polarity] Non-Inverting [Vinl] 0 [Vinh] 5.0 [Model] TN [Model type] Input [Polarity] Non-Inverting [Vinl] 0 [Vinh] 5.0 [Model] bd4t [Model type] I/O [Polarity] Non-Inverting --------------3C329507C80 Content-Type: text/plain; charset=big5; name="bd4t" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bd4t" * testing spice deck for bd4t IBIS 2.1 model characterization * change the following line to your library file .inc "bd4t.lib" .global vdd gnd vpp xCKT A IO ZI TN bd4t .subckt bd4t a io zi tn xnd1 a tn n1 nand xnd2 n1 tn n2 nand xiv1 n2 n3 inv mpio io n1 vdd vdd p w=60u l=1u m=1 mnio io n3 gnd gnd n w=30u l=1u m=1 xiv2 n4 zi inv xiv3 io n4 inv .ends bd4t .subckt nand a b z mpa z a vdd vdd p w=6u l=1u m=1 mpb z b vdd vdd p w=6u l=1u m=1 mna z a mid gnd n w=3u l=1u m=1 mnb mid b gnd gnd n w=3u l=1u m=1 .ends nand .subckt inv a z mp z a vdd vdd p w=6u l=1u m=1 mn z a gnd gnd n w=3u l=1u m=1 .ends inv --------------3C329507C80-- From owner-ibis Mon Oct 14 03:33:24 1996 Received: from via.com.tw ([203.70.217.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id DAA21607 for ; Mon, 14 Oct 1996 03:33:19 -0700 (PDT) Received: from sun13.via.com.tw ([203.70.217.82]) by via.com.tw (4.1/SMI-4.1) id AA21342; Mon, 14 Oct 96 18:22:37 CST Message-Id: <3262141E.4775@via.com.tw> Date: Mon, 14 Oct 1996 18:21:18 +0800 From: Huang Organization: VIA X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: IBIS committee Subject: s2ibis2 question? Content-Type: multipart/mixed; boundary="------------20223C7622E" This is a multi-part message in MIME format. --------------20223C7622E Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Hello, I am a new learner for IBIS models version 2.1 and is using s2ibis2. Now I am facing a problem: while I characterize for a simple 3-state I/O pad (refer to attachment), the generated .spi file will not function correctly. After examining the .spi file, I found the TN pin will NOT be set while characterizing for the A pin (and vice versa). So I need to correct this error by hand. Is there any way to make this process more automatically? Or, do I make a wrong .s2i file? Any help or comments will be appreciated. best regards, Arthur Huang ps. my s2ibis2 is s2ibis2.sparc, version no. v0.91BETA [Attachment] (first is bd4t.s2i, second is bd4t) --------------20223C7622E Content-Type: text/plain; charset=big5; name="bd4t.s2i" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bd4t.s2i" | TEST IBIS characterization [IBIS Ver] 2.1 [File rev] 1.0 [Date] Mon Oct 14 15:56:30 1996 [Disclaimer] for characterization purpose only [Spice type] hspice | [Iterate] | [Cleanup] [Component] bd4t [Manufacturer] Arthur | [Package model] pkg_type [Spice file] bd4t [Temperature range] 50 100 0 [Voltage range] 3.3 3.0 3.6 [R_pkg] 1.0m 0.5m 1.5m [L_pkg] 2.5nH 2.0nH 3.0nH [C_pkg] 4.0pF 3.5pF 4.5pF | [Diff pin] | describe the differential pin list | [Pin mapping] | currently just neglect this command [Pin] A A s_A A TN TN s_TN TN IO IO s_IO bd4t -> A TN VDD vdd s_p POWER pGND g GND GND [Model] A [Model type] Input [Polarity] Non-Inverting [Vinl] 0 [Vinh] 5.0 [Model] TN [Model type] Input [Polarity] Non-Inverting [Vinl] 0 [Vinh] 5.0 [Model] bd4t [Model type] I/O [Polarity] Non-Inverting --------------20223C7622E Content-Type: text/plain; charset=big5; name="bd4t" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bd4t" * testing spice deck for bd4t IBIS 2.1 model characterization * change the following line to your library file .inc "bd4t.lib" .global vdd gnd vpp xCKT A IO ZI TN bd4t .subckt bd4t a io zi tn xnd1 a tn n1 nand xnd2 n1 tn n2 nand xiv1 n2 n3 inv mpio io n1 vdd vdd p w=60u l=1u m=1 mnio io n3 gnd gnd n w=30u l=1u m=1 xiv2 n4 zi inv xiv3 io n4 inv .ends bd4t .subckt nand a b z mpa z a vdd vdd p w=6u l=1u m=1 mpb z b vdd vdd p w=6u l=1u m=1 mna z a mid gnd n w=3u l=1u m=1 mnb mid b gnd gnd n w=3u l=1u m=1 .ends nand .subckt inv a z mp z a vdd vdd p w=6u l=1u m=1 mn z a gnd gnd n w=3u l=1u m=1 .ends inv --------------20223C7622E-- From owner-ibis Tue Oct 15 06:23:27 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 GAA09562 for ; Tue, 15 Oct 1996 06:23:26 -0700 (PDT) Received: from hws1.ma30.zds.com by nc-17.ma02.bull.com with SMTP (5.65c/101096-1) id AA44215; Tue, 15 Oct 1996 09:12:43 EDT Received: from hw25.ma30.zds.com by hws1.ma30.zds.com (4.1/SMI-4.1) id AA08020; Tue, 15 Oct 96 09:12:07 EDT Date: Tue, 15 Oct 96 09:12:07 EDT From: herb@hws1.ma30.zds.com (Herb Kaupp) Message-Id: <9610151312.AA08020@hws1.ma30.zds.com> To: ibis@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 Tue Oct 15 08:35:56 1996 Received: from pacific.mea.com (pacific.mea.com [140.237.7.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA10706 for ; Tue, 15 Oct 1996 08:35:19 -0700 (PDT) Received: from gatekeeper.msai.mea.com by pacific.mea.com with SMTP (1.38.193.4/16.2) id AA02050; Tue, 15 Oct 1996 11:24:22 -0400 Received: (from uucp@localhost) by gatekeeper.msai.mea.com (8.6.12/8.6.12) id LAA05638 for ; Tue, 15 Oct 1996 11:09:20 -0400 Received: from unknown(198.28.5.20) by gatekeeper.msai.mea.com via smap (V1.3) id sma005634; Tue Oct 15 11:09:09 1996 Received: from sbedrock.msai.mea.com (shared [192.65.252.62]) by msai.mea.com (8.6.12/8.6.12) with SMTP id LAA13973 for ; Tue, 15 Oct 1996 11:26:27 -0400 Received: from sfred.msaiasic by sbedrock.msai.mea.com (4.1/mh-version 2.4) id AA27550; Tue, 15 Oct 96 11:24:21 EDT Date: Tue, 15 Oct 96 11:24:21 EDT From: hoang@msai.mea.com (Hoang Nguyen) Message-Id: <9610151524.AA27550@sbedrock.msai.mea.com> To: ibis@vhdl.org Subject: Re: s2ibis2 question? Dear IBIS gurus: I'd like to share a similar experience working with s2ibis program, which Arthur has posted earlier. 1. For 3-state I/O buffer, the enable pin (in the pin list) needs to be connected to a resistor and tie to VDD or GND, depending if you have active-high or active-low buffer. s2ibis program does not do this automatically. In addition, declaring [Enable] Active-High or Active-Low in .s2i file does not guarantee that pullup/pulldown output disable simulation results are correct, unless the proper path is provided to VDD or GND by the users as mentioned above. 2. This is a related question to the above. When s2ibis generates Power clamp table and Pullup table for 3-state I/O, s2ibis sweeps a voltage range VDD->2*VDD for Power Clamp simulation. I think the program does this according to IBIS Spec: Curve Low Voltage High Voltage ----- ----------- ------------ [POWER Clamp] POWER POWER + POWER But when n-channel is used as pullup device, we only get insignificant current flow because the voltage range is not in the active region of the device. Has anyone have similar experience? To generate pullup table, only diode data [power clamp] in the active region [in the voltage range where the diode is active] is subtracted from from pullup data to generate pullup table. So then is it OK to sweep -VDD->VDD for n-channel pullup device in Power clamp simulation? because in this region the diode is active. It's contrary to IBIS Spec outlined above. Please advise. Best regards, Hoang Nguyen Mitsubishi Semiconductor From owner-ibis Wed Oct 16 04:59: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 EAA06698 for ; Wed, 16 Oct 1996 04:59:38 -0700 (PDT) Received: from s01.thesys.de by relay.xlink.net id <41510-0@relay.xlink.net>; Wed, 16 Oct 1996 12:48:48 +0000 Received: from s36.design by s01.thesys.de (4.1/SMI-4.1) id AA12761; Wed, 16 Oct 96 13:49:25 +0100 Date: Wed, 16 Oct 96 13:49:25 +0100 From: cornelia@thesys.de (Cornelia Foss) Message-Id: <9610161249.AA12761@s01.thesys.de> To: ibis@vhdl.org Subject: s2ibis2 problem To IBIS engineers, First of all thanks a lot for answering my first email. I came across an other problem concerning s2ibis2. According to the IBIS spec. the C_comp sub-parameter influences t-rise and t-fall, but actually within the simulations I run changeing of C_comp did not affect t-rise or t-fall. There is no C_comp added to the relevant .spi files by s2ibis2. Is this a known problem, did I make a mistake or was the spec canged, perhaps? Much thanks in advance for possible reply. Kindest regards Sascha Pawel From owner-ibis Wed Oct 16 07:11:17 1996 Received: from via.com.tw ([203.70.217.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA07677 for ; Wed, 16 Oct 1996 07:04:32 -0700 (PDT) Received: from sun13.via.com.tw ([203.70.217.82]) by via.com.tw (4.1/SMI-4.1) id AA16234; Wed, 16 Oct 96 21:49:53 CST Message-Id: <3264E7FF.153B@via.com.tw> Date: Wed, 16 Oct 1996 21:49:51 +0800 From: Huang Organization: VIA X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: IBIS committee Subject: [Fwd: s2ibis2 question?] Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Hi, Thank Mark and I have the following solution for my previous question for s2ibis2. I just post here for future reference. Arthur SIMPSON_MARK@Tandem.COM wrote: > > Arthur, > > You have a little of both going on. There is a way to the > process more automatic AND the s2i file is incomplete. You need to > add termination to the TN and A nodes in the .sp file since s2ibis2 > does not always terminate them to a voltage source (avoid no dc path > to ground and ensure the TN node is in it's proper state to generate > the pullup/down). The s2i file needs the [Model File] statement to > know which process corner to use. I copied your files, modified them > and created .ibs files using s2ibis2.sparc and hspice. See the > attached modified .s2i, .sp and lib files. > > Good luck > > Mark Simpson > > ------------ TEXT ATTACHMENT -------- > SENT 10-14-96 FROM SIMPSON_MARK @ESP > > :::::::::::::: > bd4t.s2i > :::::::::::::: > | TEST IBIS characterization > [IBIS Ver] 2.1 > [File rev] 1.0 > [Date] Mon Oct 14 15:56:30 1996 > [Disclaimer] for characterization purpose only > [Spice type] hspice > | [Iterate] > | [Cleanup] > [Component] bd4t > [Manufacturer] Arthur > | [Package model] pkg_type > [Spice file] bd4t.sp > [Temperature range] 50 100 0 > [Voltage range] 3.3 3.0 3.6 > [R_pkg] 1.0m 0.5m 1.5m > [L_pkg] 2.5nH 2.0nH 3.0nH > [C_pkg] 4.0pF 3.5pF 4.5pF > | [Diff pin] > | describe the differential pin list > > | [Pin mapping] > | currently just neglect this command > > [Pin] > A A s_A A > TN TN s_TN TN > IO IO s_IO bd4t > -> A TN > VDD vdd s_p POWER > pGND g GND GND > > [Model] A > [Model type] Input > [Polarity] Non-Inverting > [Model File] proc.typ proc.min proc.max > [Vinl] 0 > [Vinh] 3.3 > > [Model] TN > [Model type] Input > [Polarity] Non-Inverting > [Model File] proc.typ proc.min proc.max > [Vinl] 0 > [Vinh] 3.3 > > [Model] bd4t > [Model type] I/O > [Polarity] Non-Inverting > [Model File] proc.typ proc.min proc.max > [sim time] 10n > [C_comp] 2.0pF 3.0pF 1.0pF > [Rising waveform] 50 0 NA NA NA NA NA NA NA > [Falling waveform] 50 3.3 NA NA NA NA NA NA NA > [Vmeas] 1.5V > [Cref] 10pf > [Vref] 0V > > :::::::::::::: > bd4t.sp > :::::::::::::: > * input termination (TN low if active high, TN high if active low) > *RTN TN VDD 1E9 > RTN TN 0 1E9 > RA A 0 1E9 > > * testing spice deck for bd4t IBIS 2.1 model characterization > > * change the following line to your library file > *.inc 'junk.lib' > .global vdd gnd vpp > > xCKT A IO ZI TN bd4t > > .subckt bd4t a io zi tn > xnd1 a tn n1 nand > xnd2 n1 tn n2 nand > xiv1 n2 n3 inv > mpio io n1 vdd vdd p w=60u l=1u m=1 > mnio io n3 gnd gnd n w=30u l=1u m=1 > xiv2 n4 zi inv > xiv3 io n4 inv > .ends bd4t > > .subckt nand a b z > mpa z a vdd vdd p w=6u l=1u m=1 > mpb z b vdd vdd p w=6u l=1u m=1 > mna z a mid gnd n w=3u l=1u m=1 > mnb mid b gnd gnd n w=3u l=1u m=1 > .ends nand > > .subckt inv a z > mp z a vdd vdd p w=6u l=1u m=1 > mn z a gnd gnd n w=3u l=1u m=1 > .ends inv > > :::::::::::::: > proc.max > :::::::::::::: > .lib './junk.lib' BEST > :::::::::::::: > proc.min > :::::::::::::: > .lib './junk.lib' WORST > :::::::::::::: > proc.typ > :::::::::::::: > .lib './junk.lib' TYPICAL From owner-ibis Wed Oct 16 08:38:06 1996 Received: from via.com.tw ([203.70.217.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA08463 for ; Wed, 16 Oct 1996 08:35:55 -0700 (PDT) Received: from sun13.via.com.tw ([203.70.217.82]) by via.com.tw (4.1/SMI-4.1) id AA16234; Wed, 16 Oct 96 21:49:53 CST Message-Id: <3264E7FF.153B@via.com.tw> Date: Wed, 16 Oct 1996 21:49:51 +0800 From: Huang Organization: VIA X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: IBIS committee Subject: [Fwd: s2ibis2 question?] Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Hi, Thank Mark and I have the following solution for my previous question for s2ibis2. I just post here for future reference. Arthur SIMPSON_MARK@Tandem.COM wrote: > > Arthur, > > You have a little of both going on. There is a way to the > process more automatic AND the s2i file is incomplete. You need to > add termination to the TN and A nodes in the .sp file since s2ibis2 > does not always terminate them to a voltage source (avoid no dc path > to ground and ensure the TN node is in it's proper state to generate > the pullup/down). The s2i file needs the [Model File] statement to > know which process corner to use. I copied your files, modified them > and created .ibs files using s2ibis2.sparc and hspice. See the > attached modified .s2i, .sp and lib files. > > Good luck > > Mark Simpson > > ------------ TEXT ATTACHMENT -------- > SENT 10-14-96 FROM SIMPSON_MARK @ESP > > :::::::::::::: > bd4t.s2i > :::::::::::::: > | TEST IBIS characterization > [IBIS Ver] 2.1 > [File rev] 1.0 > [Date] Mon Oct 14 15:56:30 1996 > [Disclaimer] for characterization purpose only > [Spice type] hspice > | [Iterate] > | [Cleanup] > [Component] bd4t > [Manufacturer] Arthur > | [Package model] pkg_type > [Spice file] bd4t.sp > [Temperature range] 50 100 0 > [Voltage range] 3.3 3.0 3.6 > [R_pkg] 1.0m 0.5m 1.5m > [L_pkg] 2.5nH 2.0nH 3.0nH > [C_pkg] 4.0pF 3.5pF 4.5pF > | [Diff pin] > | describe the differential pin list > > | [Pin mapping] > | currently just neglect this command > > [Pin] > A A s_A A > TN TN s_TN TN > IO IO s_IO bd4t > -> A TN > VDD vdd s_p POWER > pGND g GND GND > > [Model] A > [Model type] Input > [Polarity] Non-Inverting > [Model File] proc.typ proc.min proc.max > [Vinl] 0 > [Vinh] 3.3 > > [Model] TN > [Model type] Input > [Polarity] Non-Inverting > [Model File] proc.typ proc.min proc.max > [Vinl] 0 > [Vinh] 3.3 > > [Model] bd4t > [Model type] I/O > [Polarity] Non-Inverting > [Model File] proc.typ proc.min proc.max > [sim time] 10n > [C_comp] 2.0pF 3.0pF 1.0pF > [Rising waveform] 50 0 NA NA NA NA NA NA NA > [Falling waveform] 50 3.3 NA NA NA NA NA NA NA > [Vmeas] 1.5V > [Cref] 10pf > [Vref] 0V > > :::::::::::::: > bd4t.sp > :::::::::::::: > * input termination (TN low if active high, TN high if active low) > *RTN TN VDD 1E9 > RTN TN 0 1E9 > RA A 0 1E9 > > * testing spice deck for bd4t IBIS 2.1 model characterization > > * change the following line to your library file > *.inc 'junk.lib' > .global vdd gnd vpp > > xCKT A IO ZI TN bd4t > > .subckt bd4t a io zi tn > xnd1 a tn n1 nand > xnd2 n1 tn n2 nand > xiv1 n2 n3 inv > mpio io n1 vdd vdd p w=60u l=1u m=1 > mnio io n3 gnd gnd n w=30u l=1u m=1 > xiv2 n4 zi inv > xiv3 io n4 inv > .ends bd4t > > .subckt nand a b z > mpa z a vdd vdd p w=6u l=1u m=1 > mpb z b vdd vdd p w=6u l=1u m=1 > mna z a mid gnd n w=3u l=1u m=1 > mnb mid b gnd gnd n w=3u l=1u m=1 > .ends nand > > .subckt inv a z > mp z a vdd vdd p w=6u l=1u m=1 > mn z a gnd gnd n w=3u l=1u m=1 > .ends inv > > :::::::::::::: > proc.max > :::::::::::::: > .lib './junk.lib' BEST > :::::::::::::: > proc.min > :::::::::::::: > .lib './junk.lib' WORST > :::::::::::::: > proc.typ > :::::::::::::: > .lib './junk.lib' TYPICAL From owner-ibis Wed Oct 16 10:44:55 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 KAA09722 for ; Wed, 16 Oct 1996 10:44:53 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 16 Oct 96 10:34 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Oct 96 10:34 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Oct 96 10:36 PDT Message-Id: Date: Wed, 16 Oct 96 10:36 PDT From: bob@icx.com ( Bob Ross) To: cornelia@thesys.de, ibis@vhdl.org Subject: Re: s2ibis2 problem Sascha: C_comp is an effective capacitance intended to model the non-linear capacitances already contained in the Spice file. Therefore C_comp is not added to the .spi decks, but its real effect already exists in the Spice deck as part of the Spice device model. So s2ibis2 is correct in this respect. Best Regards, Bob Ross Interconnectix, Inc. > Date: Wed, 16 Oct 96 13:49:25 +0100 > From: cornelia@thesys.de (Cornelia Foss) > Message-Id: <9610161249.AA12761@s01.thesys.de> > To: ibis@vhdl.org > Subject: s2ibis2 problem > Status: RO > To IBIS engineers, > First of all thanks a lot for answering my first email. > I came across an other problem concerning s2ibis2. > According to the IBIS spec. the C_comp sub-parameter > influences t-rise and t-fall, but actually within > the simulations I run changeing of C_comp did not affect > t-rise or t-fall. > There is no C_comp added to the relevant .spi files by s2ibis2. > Is this a known problem, did I make a mistake or was the spec > canged, perhaps? > Much thanks in advance for possible reply. > Kindest regards > Sascha Pawel From owner-ibis Wed Oct 16 16:49:12 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 QAA13061 for ; Wed, 16 Oct 1996 16:49:02 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 16 Oct 96 16:38 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Oct 96 16:38 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 16 Oct 96 16:40 PDT Message-Id: Date: Wed, 16 Oct 96 16:40 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD35.2 MULTI-STAGED OUTPUTS To IBIS Committee: Finally, after a long delay, here is BIRD35.2! BIRD35.2 is a complete revision of BIRD35.1 to reflect the IBIS Committee's request for a [Model] based scheduling mechanism. BIRD35.1 focused on scheduling a sequence of new [Pullup(n)] and [Pulldown(n) tables. BIRD35.2 now schedules other [Model]s directly. The key aspects of BIRD35.2 are: 1. Each [Model] can contain the [Driver Schedule] keyword to override using the [Pullup] and [Pulldown] and transition and use that data form the referenced models. Even though it is overrided, this information is still needed, as required for downward compatibility for simulators which do not support the multi-staged [Driver Schedule] keyword. 2. The [Model] keyword subparameters for specifications (Vinl, Vinh, Vmeas, Vref, Rref, Cref) and C_comp override any data contained in models that are referenced in the [Driver Schedule] table. 3. Only the [Power Clamp] and [Gnd Clamp] tables under [Model] are used. 4. The [Driver Schedule] consists of 5 columns for defining the referenced Model_name, its rising_on, rising_off, falling_on and falling_off delays. All four columns are required. A value of zero implies no delay. A value of NA implies that no response occurs for that part of the transition. This could occur, for example, if an Open_source model is used for an extra bit of source current for a small period of time for the rising transition, but has no effect for the falling transition. For background: The multi-staged switching functionality has been on the priority list for Version 3.0 addtions. BIRD35.2 is another proposal to address this issue. Unlike exiting IBIS keywords, the new tables cannot be measured directly or even be produced easily by direct decomposition and simulation of Spice elements because of too much internal interaction. The actual construction would be by trial and validation and based on the known architectural intent. Bob Ross Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 35.2 ISSUE TITLE: Multi-staged Outputs REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 5/13/96, 6/21/96, 10/16/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Modeling output transitions of buffers consisting of several sequentially switched internal devices has been a long standing request. The addition of the [Rising Waveform] and [Falling Waveform] keywords partially addresses the issue by waveform shaping control. However, these keywords do not model the dynamic impedance changes during transitions. The more direct solution is to add IBIS keywords which allow modeling the internal architecture more closely. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Driver Schedule] keyword is introduced as a keyword under the [Model] keyword to construct a multi-staged driver from other existing driver models. |============================================================================== | Keywords: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for referenced | models to produce a multi-staged driver. | | Usage Rules: The [Driver Schedule] table consists of five columns. The | first column is the model names of other models that exist | in the .ibs file. The remaining four columns describe | delays: rising_delay_on, rising_delay_off, falling_delay_on | and falling_delay_off. All values are referenced to 0 seconds | for the start of the rising transition and 0 seconds for the | start of the falling transition. All delays must be equal to | or greater than 0. | | The Rise_on_dly entry gives the begining of the low-to-high | transition. The Rise_off_dly entry may be given to end the | low-to-high transition and intiate a high-to-low transition | during the rising cycle. Similarily, the Fall_on_dly gives | the begining of the high-to-low transition. The Fall_off_dly | may be given to end the high-to-low transition and initiate | a low-to-high transition. | | Use 'NA' when no transition is applicable. For each model, | the transition sequence must be complete, i.e, it must start | and end at the same state. | | Only the [Pulldown] and [Pullup] tables and transition data | [Ramp] or [Rising Waveform] and [Falling Waveform] data are | used from each model that is referenced. The [Model] keyword | provides the specification information, [Gnd Clamp] and [Power | Clamp], and C_comp, regardless of information contained in | the referenced models. | | No [Driver Schedule] may reference a model which itself has | within it a [Driver Schedule] table keyword. | | Other Notes: The added models typically consist of Open_sink (Open_drain) | or Open_source models to provide sequentially increased drive | strengths. The added drive may be removed within the same | transition for a momentary boost or during the opposite | transition. | | The syntax also allows for reducing the drive strength. |------------------------------------------------------------------------------ | [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high | Bus-hold stage M_O_DRAIN3 NA 1.0n NA 0.5n | high (high-Z) to low low to high (high-Z) | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The proposal is designed to add to the existing IBIS structures and retain as much existing meaning as possible. The new "stage" tables follow all of the conventions of the existing non-staged tables. For that reason, even the subparameters R_dut, L_dut, and C_dut are permitted, although they are not relevant nor are expected to be used. The overall structure is to connect independently controlled stages to a common output node. The relative relationhips between waveform controls are used to produce phased turn-on and turn-off models. The structure can be also be used to model other internal artifacts. These may include providing an extra boost pulse or providing bus hold modeling. A general objection to these structures is that they do not relate to any externally obtained extraction. The intent of these structures is to give a format for modeling a known architecture with behavioral blocks and to also add some detail to existing models. BIRD35.1 introduces a [Rising Sequence] and [Falling Sequence] tables to control the sequencing of individual stages. This is in response to Jon Powell's comment to make the sequencing of waveforms easier to understand and modify. So each [Rising Waveform(n)] and [Falling Waveform(n)] table has its start time controlled by the Sequence tables. One technical limitation is that the Sequencing is the same for typ, min, and max columns. Any internal shifting within the typ, min, and max columns for the stage must be taken into account within the Waveform columns for that stage. BIRD35.2 removes the numbered [Pullup(n)], [Pulldown(n)], [Rising Waveform(n)] and [Falling Waveform(n)] syntax. Instead, references by Model_name is introduced so that existing [Model] syntax can be used. The new keyword [Driver Schedule] provides a syntax for sequencing other models. This is given as a keyword under the [Model] keyword. It overrides any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and [Falling Waveform] data for that model. However, the required tables for [Model] are still required for backwards compatibility reasons for simulators which do not support multi-staged switching. This information can be used as a composite model cross-check, although the resulting model may not perform in the same manner as the multi-stage model. Any model that is referenced may itself be a complete model. This creates a problem if several complete models are referenced and they contain common information such as specification data, C_comp, and clamping information. Some of this information can be conflicting such as timing test loads and thresholds. The simplist resolution is to rely only on the information withing the [Model] keyword itself. Then it can be found easily. Also, there is no confusion whether data in other models is "added". For example, would all of the C_comp values be added? The syntax allows for a reduction rather than an addition in driver strength by using the "*_off_dly". This can be used to turn off the boost with the transition to initiate an out of phase boost. Not all simulators may support this feature. This feature could be used to model a bus-hold output stage. The prohibition of [Driver Schedule] table referencing other models which contain the [Driver Schedule] keyword is added to keep all of the scheduling within one table for clarity and to avoid the need to test for models referencing each other. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell provided syntax of an existing implementation. This proposal is intended to be compatible with it. ****************************************************************************** From owner-ibis Thu Oct 17 11:35:30 1996 Received: from hq15.pcmail.ingr.com (hq15.pcmail.ingr.com [129.135.251.243]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA13108 for ; Thu, 17 Oct 1996 11:35:28 -0700 (PDT) Received: by hq15.pcmail.ingr.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBBC2E.7A4ACAA0@hq15.pcmail.ingr.com>; Thu, 17 Oct 1996 13:24:08 -0500 Message-ID: From: "Boeckmann, Ed (Edward F)" To: "'ibis@vhdl.org'" Subject: Spice to IBIS Conversion with newtryme files Date: Thu, 17 Oct 1996 13:23:00 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 40 TEXT Hello! Has anyone out there had this problem with the example files for spice to IBIS conversion: When running s2ibis2.sparc with the newtryme.sp and newtryme.s2i files I get two error messages as follows: "Spice run (TYP) aborted. See file ddt8.msg for information. Curve pulldown (output disabled) not generated." (the file ddt8.msg has only the cryptic message: "^G>error ***hspice aborted*** ) "Error in analysis for pin 8." There is no message file for the pin 8 error. Otherwise the run produces a normal looking IBIS file with no indication of errors. (Deceptively normal looking?). The command file newtryme.s2i looks a little strange to me in the pin description area with lines like: -> 8 and -> 4 But if I remove what looks like garbage in the file, the run results do not improve or get worse. I will appreciate any explanations someone might have. Thanks, Ed Boeckmann Intergraph Corp. Huntsville, Al 35894 Mail Stop CR1100 tel. (205)-730-6219 fax.(205)-730-6000 email efboeckm@ingr.com From owner-ibis Thu Oct 17 12:46:51 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 MAA17866 for ; Thu, 17 Oct 1996 12:46:47 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 17 Oct 1996 19:36:02 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id MAA01754 for ibis@vhdl.org; Thu, 17 Oct 1996 12:34:38 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 17 Oct 96 12:34:38 PDT Date: Thu, 17 Oct 96 12:30:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re[2]: s2ibis2 question? Text item: Hoang, Regarding 1) I can't help you, because I am not using that tool. Regarding 2) my answer is between your lines. Arpad Muranyi Intel Corporation ============================================================================= Dear IBIS gurus: I'd like to share a similar experience working with s2ibis program, which Arthur has posted earlier. 1. For 3-state I/O buffer, the enable pin (in the pin list) needs to be connected to a resistor and tie to VDD or GND, depending if you have active-high or active-low buffer. s2ibis program does not do this automatically. In addition, declaring [Enable] Active-High or Active-Low in .s2i file does not guarantee that pullup/pulldown output disable simulation results are correct, unless the proper path is provided to VDD or GND by the users as mentioned above. 2. This is a related question to the above. When s2ibis generates Power clamp table and Pullup table for 3-state I/O, s2ibis sweeps a voltage range VDD->2*VDD for Power Clamp simulation. I think the program does this according to IBIS Spec: Curve Low Voltage High Voltage ----- ----------- ------------ [POWER Clamp] POWER POWER + POWER But when n-channel is used as pullup device, we only get insignificant current flow because the voltage range is not in the active region of the device. Has anyone have similar experience? This is all correct. In most cases, N-channel pullups do not have parasitic clamps with respect to Vcc, because the substrate is connected to GND. The data you see is noise and/or leakage only. To generate pullup table, only diode data [power clamp] in the active region [in the voltage range where the diode is active] is subtracted from from pullup data to generate pullup table. So then is it OK to sweep -VDD->VDD for n-channel pullup device in Power clamp simulation? because in this region the diode is active. It's contrary to IBIS Spec outlined above. Please advise. Your question here is not entirely clear to me, but is seems to me that you are asking whether it is OK to subtract the entire Clamp curve from the pullup curve including the -VDD to 0 V region (where the clamp is active). To set things straight, when you sweep a 3-stated device from -VDD to 2*VDD, you get the GND Clamp on one end and the Power Clamp on the other end of the curve. The same thing is happening with the pullup and pulldown sweeps. Each of these have GND and Power Clamp data embedded within them in the top and bottom 1/3 of the sweep. To avoid the doubling (or tripling) of the clamps, the entire range of the data obtained with the 3-stated sweep needs to be subtracted from the pulldown and pullup sweeps. This is not in contradiction with the spec. Best regards, Hoang Nguyen Mitsubishi Semiconductor 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: s2ibis2 question? To: ibis@vhdl.org Message-Id: <9610151524.AA27550@sbedrock.msai.mea.com> From: hoang@msai.mea.com (Hoang Nguyen) Date: Tue, 15 Oct 96 11:24:21 EDT Received: from sfred.msaiasic by sbedrock.msai.mea.com (4.1/mh-version 2.4) id AA27550; Tue, 15 Oct 96 11:24:21 EDT Received: from sbedrock.msai.mea.com (shared [192.65.252.62]) by msai.mea.com (8 .6.12/8.6.12) with SMTP id LAA13973 for ; Tue, 15 Oct 1996 11:26: 27 -0400 Received: from unknown(198.28.5.20) by gatekeeper.msai.mea.com via smap (V1.3) id sma005634; Tue Oct 15 11:09:09 1996 Received: (from uucp@localhost) by gatekeeper.msai.mea.com (8.6.12/8.6.12) id LA A05638 for ; Tue, 15 Oct 1996 11:09:20 -0400 Received: from gatekeeper.msai.mea.com by pacific.mea.com with SMTP (1.38.193.4/16.2) id AA02050; Tue, 15 Oct 1996 11:24:22 -0400 Received: from pacific.mea.com (pacific.mea.com [140.237.7.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA10706 for ; Tue, 15 Oct 1996 08:35: 19 -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 IAA03945; Tue, 15 Oct 1996 08:32: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 IAA05394; Tue, 15 Oct 1996 08: 29:55 -0700 (PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Fri Oct 18 10:19:46 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 KAA16167 for ; Fri, 18 Oct 1996 10:19:36 -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 KAA03443 for ; Fri, 18 Oct 1996 10:08:48 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id KAA11083; Fri, 18 Oct 1996 10:07:34 -0700 (PDT) Message-Id: <199610181707.KAA11083@ichips.intel.com> To: ibis@vhdl.org Subject: Approved, Bird 37.3 Date: Fri, 18 Oct 1996 10:08:49 -0700 From: Stephen Peters Hello All: Here is the text of bird 37.3, with the editorial corrections included. Regards, Stephen Peters Intel Corp. ================== cut here ============================= ============================================================================= Buffer Issue Resolution Document (BIRD) BIRD ID#: 37.2 ISSUE TITLE: Enhancement To The Package Model (.pak file) Specification REQUESTER: Stephen Peters DATE SUBMITTED: Sept 23, 1996 DATE ACCEPTED BY IBIS OPEN FORUM: Oct 18, 1996 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current package model electrical description, (as proposed in Bird 28.3 and accepted by the forum) has the restriction that all the sections of a package stub connect in a series fashion, with no branches or stubs allowed. This limits the usefulness of the description when trying to describe BGA or other packages where branches or forks off the main package stub may be present. This BIRD corrects this deficiency by adding two new subparameters to the [Pin Numbers] keyword called 'Fork' and 'Endfork'. This bird also eliminates the Matrix description format (as introduced by Bird28.3) from the package description. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Following are the specific changes to the specification (spec as amended by Bird 28.3). 1. The Sub-params list of the [Pin Numbers] keyword is changed to that shown below |Sub-Params: Len, L, R, C, Fork, Endfork 2. The text following the first paragraph of the Usage Rules section of the [Pin Numbers] keyword is replaced by the following: | | Subparameters: | The Len, L, R, and C subparameters specify the length, | inductance, capacitance and resistance of each section of | each stub on a package. | The Fork and Endfork subparameters are used to denote branches | from the main package stub. | Len The of a package stub section. Lengths are given | in terms of arbitrary 'units'. | L The inductance of a package stub section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0nH and the | length of the section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). | C The capacitance of a package stub section, in terms of | capacitance per unit length. | R The DC (ohmic) resistance of a package stub section, in | terms of ohms per unit length. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main package stub. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a | branch. For every Fork subparameter there must be | a corresponding Endfork subparameter. As with the | Fork subparameter, the Endfork subparameter has no | arguments. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. However, if a non-zero length section | is specified, the L and C for that section should be treated | as distributed elements. | | Using The Subparameters to Describe Package Stub Sections: | A section description begins with the Len subparameter and | end with the backslash (/) character. The value of the Len, L, | R and C subparameters and the subparameter itself are | separated by an equals sign (=); whitespace around the equals | sign is optional. The Fork and Endfork subparameters | are placed between section descriptions (i.e. between the | concluding backslash of one section and the 'Len' parameters | that starts another). All package stub descriptions must | contain the same number of sections however, a particular | section description can contain no data (i.e. the description | is given as 'Len = 0 /'). | | Legal Subparameter Combinations for Section Descriptions: | A) A single Len = 0 subparameter, followed by a slash. | The is used to describe a section with no data. | | | B) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | D) Single Fork or Endfork subparameter. Normally, a package | stub is described as several sections, with the Fork and Endfork | subparameters surrounding a group of sections in the middle of | the complete package stub description. However, it is legal | for the Fork/Endfork subparameters to appear at the end of a | section description. The package pin is connected to the | last section of a package stub description not surrounded by | a Fork/Endfork statements. See the examples below. | | Package Stub Boundaries: | A package stub description starts at the connection to | the die and ends at the point at which the package pin | interfaces with the board or substrate the IC package | is mounted on. Note that in the case of a component | with thru-hole pins, the package stub description should | include only the portion of the pin not physically | inserted into the board or socket. However, it is legal for | a package stub description to include both the component | and socket together if this is how the component is | intended to be used. | 3. The examples added by Bird 28.3 are replaced by the following | |A three section package stub description that includes a bond wire |(lumped inductance), a trace (treated as a transmission line with DC |resistance), and a pin modeled as a lumped L/C element. | [Pin Number] A1 Len=0 L=1.2n/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0p/ | |Pin A2 below has an section with no data | A2 Len=0 L=1.2n/ Len=0/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0p/ | |A section description using the Fork and Endfork subparameters. Note |that the indentation of the Fork and Endfork subparameters are for |readability and are not required. | A1 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5p / | first section Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch Len=0.5 L=1.0 C=2.5p/ | second section Len=0.0 L=1.5n / | pin | |Here is an example where the Fork/Endfork subparameters are at the |end of a package stub description | B13 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5p / | first section Len=0.5 L=1.0 C=2.5/ | second section, pin connects here Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch |4. The [Model Data] and [End Model Data] keywords revert back to | there former (pre bird 28.3) definitions. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This bird grew out of the need to describe a particular structure found in BGA type packages. In these packages, the trace that connects the die pad to the via for the 'ball' does not stop there. For manufacturing reasons the trace continues out to the edge of the board and thus forms a 'stub' or branch off the main pad to ball (or pin) connection. Because of the need to stick with the existing section based description, the fork and Endfork subparameters were chosen. REVISIONS FOR 37.1: Based on comments received, removed backslash ("/") from the Fork and Endfork syntax, added a description of the package stub boundaries, and added two examples. I also added a recommendation that non-zero length section descriptions be treated as distributed elements. REVISIONS FOR 37.2 Until the forum can agree on a method to describe coupling, the 'Matrix' subparameter has been removed from the package description. Hopefully, it will be reintroduced when a common matrix description format had been agreed upon. 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 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 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 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 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:14:27 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 MAA03802 for ; Wed, 23 Oct 1996 12:14:22 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 23 Oct 96 12:03 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 23 Oct 96 12:03 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 23 Oct 96 12:05 PDT Message-Id: Date: Wed, 23 Oct 96 12:05 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 10/18/96 DATE: October 23, 1996 SUBJECT: 10/18/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann*, Tim Minnick, Russ Moser, Ray Ziesse*, Jeff Walden* Applied Simulation Technology Dileep Divekar*, Norio Matsui, Antonis Orphanou (formerly Contec) Cadence Design C. Kumar* Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier, Ralf Bruening Intel Corporation Stephen Peters*, Will Hobbs, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, [Donald Telian], Jim Kruchowski Interconnectix, Inc. Bob Ross*, Chris Reid Meta-Software (Sanjay Gangal) Mitsubushi Tam Cao, Hoang Nguyen Motorola Ahmed Omer National Semiconductor Syed Huq*, [Donald Snyder], Chune-Sin Yeh, [Bill Aronson] NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell, Chris Rokusek* Quantic Laboratories (Mike Ventham) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia Veribest Ian Dodd*, David Wiens VLSI Technology Dick Ulmer, Sung Oh, Swami Gangadharan, Daniel Kim, Tom Dockery, D.C. Sessions, Hrish Patel Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: 3M Fran Hart*, George Hare* Alcatel John Fitzpatrick Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu* EIA Patti Rusher IC Works Eric Chen Mentor Graphics Kim Owen Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Philips Semiconductor Mike Magdaluyo Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Symmetry Andy Hughes Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison VTC, Inc. Bob Ward Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Participants who have joined another organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 11/08/96 (916) 356-9200 2-104708 1692479 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Jeff Walden from AMP works with Ray Ziesse and is involved with connector modeling. George Hare from 3M is in the Electrical Products Division in Texas and has been working on modeling issues for the last six months. EIA MEMBERSHIP AND TREASURER'S REPORT Bob Ross reported that the EIA IBIS ledger remains at $9,285 for September, 1996. However some EIA shared expenses will be deducted by the end of the year. MINUTES REPORT, MISC. Fran Hart reported that she is with the Electronic Products Division of 3M, not the Electronics Products Group as previously stated. MISCELLANY/ANNOUNCEMENTS Bob Ross reported that each IBIS reflector mailing list contains over 290 people from all over the world. Each mailing typically generates a few bounced messages, typically because of people moving on and because of local computer network problems. Bob usually tries to forward the mail in a few days or attempts to contact the site "postmaster". However, if the problem is not resolved in a few days, the name is removed on the list. So, if you find that you are not receiving messages, you may have been dropped. One way to find out is to check the e-mail archives (email.archive and monthly archives) to see if you have received the most recent messages. PRESS AND WEB PAGE UPDATES Syed Huq reported that within a few weeks he will add links to an HTML version of the EE Times Article and to the BIRDs and the Cookbook on vhdl.org. He also plans some format changes on the official EIA/IBIS home page. Bob Ross also reported "PCB design tools continue Windows juggernaut", Computer Design, September 1996, pp. 35-38 contain reference to VeriBest usage of IBIS models. NEW MODELS Arpad Muranyi has several more Intel models available under NDA. He will submit the updated list to Jon Powell. Bob Ross reported that the Free Model Foundation now has 29 contributed IBIS models under ftp://vhdl.org/vi/fmf/fmf_public_models/ibis Arpad also raised the issue that the response time on vhdl.org is very slow. Bob has experienced reasonably fast responses, so he feels that the problem may possibly be internal to Intel. In any case both will try again to see if there is a response problem. [Bob and Arpad both found the response normal.] OPENS FOR NEW ISSUES Ray Ziesse on AMP patent position. C. Kumar on V/T waveform problems with IBIS Version 2.1. AMP PATENT POSITION Ray Ziesse responded to an earlier commitment that AMP provide its position to the Committee concerning Patent # 5,081,602 on Computer Simulator for Electrical Connectors. (Refer to the September 6, 1996 IBIS Open Forum Minutes.) A licensing agreement is available on Patent # 5,081,602. It can be obtained by contacting. Mr. Bruce Wolstoncroft The Whitaker Corporation Phone: (302) 633-2745 DESIGN SUPERCON97 Syed Huq reported that National Semiconductor has formally offered to host the IBIS Face-to-face meeting in Santa Clara on the Monday before Design SuperCon97 at the end of January. National will provide the room, lunch and support equipment. Syed felt that an EIA procedural rule prohibited a company such as National from hosting a formal EIA meeting on company premises. [This is not true, and in fact is encourage, based on a response from Patti Rusher.] We expect to formally select the host company at the next Open Forum meeting. Anyone else wishes to be considered should notify Bob Ross. Bob expects the meeting agenda to include some practical experiences regarding generating IBIS models by silicon vendors and by customer's with internal ASIC development capability. EDA vendors may be able to share more information on internal utilities. Bob also expects more discussions on model validation. Arpad Muranyi followed up on a point made at the last meeting that the Committee should consider holding some meetings on the East Coast for geographical balance. Bob indicated that the two traditional Face-to-face meetings are held at the Design SuperCon location (Santa Clara, California) and at wherever the Design Automation Conference (DAC) is held. The location in June 1997 is in Anaheim, CA). Many active IBIS Committee members already attend these conferences. So the opportunity for meetings elsewhere depend on DAC locations. Possibly some working group Face-to-face meetings can be held, if needed, on the East coast. DAC97 PLANNING (AND OTHER MEETINGS) Bob Ross indicated that EIA usually plans to have a Standards Booth covering the activities of all committees under EIA/EIG. The IBIS Open Forum Committee shared expenses with other standards groups last year, and we will probably do so again this year. S2IBIS PLANS Based on recent reflector activity, there are several questions and problems with s2ibis2. Bob Ross reported that the original s2ibis Version 2.091 was posted as a BETA version on vhdl.org around November, 1995. Some significant concerns including crashes, functional errors, and functional omissions have been reported. NCSU has used all their funding for the existing development and has not gotten new funding from DARPA to finish the job. NCSU has also investigated commercial opportunities. Bob offered several options to get the s2ibis2 code beyond the prototype level and to be functionally usable: 1. NCSU "steal" some time to complete the job. 2. Fund a new student for several months to complete the job. 3. Some other company take over "ownership" and complete s2ibis2. 4. Some individual be contracted to finish the job. Ian Dodd indicated that VeriBest has made its own corrections and is willing to communicate them publicly. VeriBest may offer their s2ibis conversion utility to the public domain. They will report some significant problems that they have discovered on the IBIS reflector. Syed Huq felt that NCSU should be encouraged to finish the job. Bob felt that while there are several items that need to be fixed, the completion project was still of limited scope. There is interest in an NT based utility. However, Bob felt this would be beyond the scope of this project. AR - Bob Ross work with NCSU to correct some defects and complete s2ibis2. AR - Ian Dodd post the problems he discovered. Optionally, Ian work with Bob Ross to post a working revised s2ibis2 conversion package if he obtains permission. Arpad Muranyi mentioned that his IBIS Center development utility is available to IBIS Committee members. He is restricted by a licensing agreement to 50 copies. Arpad cannot provide support but would welcome comments and feedback. The utility is not general. It focuses on CMOS technology and does not, for example, support ECL technologies. It does the following: 1. Reads simulated data from template files 2. Graphically displays the simulated data 3. Creates an IBIS Model set of data 4. Graphically displays the IBIS Model tables 5. Construct an IBIS Component model from several Models The graphical interface supports zooming. Templates are provided to set up the simulations to generate the initial simulated data, as a separate process. The utility is available for Sun Unix and DOS workstations. IBIS V/T PROBLEM WITH VERSION 2.1 IBIS MODELS C. Kumar raised the issue that some Version 2.1 level IBIS models contain V/T data that converge slowly to the final DC value. One issue is what may be a reasonable truncation criteria so that one can properly focus on the faster transition portion. Several people suggested experience using one percent. Kumar questioned whether this should be standardized. Too much truncation creates a DC mismatch. Chris Rokusek stated that the percentage voltage versus time approach can produce stable results. Too much truncation may hide other artifacts related to noise and EMI. Any criteria could be put in a cookbook for guidance. How C_comp interacts is a related issue. An actual fixed C_comp used in the IBIS model differs from any non-linear capacitance in the device or Spice model. These capacitances cannot be removed. Therefore, it is realistic that a simulation could differ from a "golden response". The point about the golden response is that it is a response based on a prescribed condition. Simulators probably have different algorithms to describe transitions, so one test of accuracy is how close the response is to the "golden response". AR - Kumar write up the specific issues and concerns on the IBIS reflector. BIRD37.2 Stephen Peters presented BIRD37.2 as a modification to BIRD28.3 which extended the package model by allowing cascaded sections and cascaded matrix sections. The matrix addition is removed. A simple Fork and End Fork branching capability is added. Per a Package Committee request, Bob Ross gave background of the existing package issues under discussion. Package models extensions consist of BIRD28.3 and BIRD37.2. At the other extreme electrical boards can be described by proprietary physical data bases and is being standardized by EDIF 4 0 0. The IBIS committee has been interested in board electrical descriptions for such components as SIMMs and MCMs. These descriptions would not be for large boards. They would allow models where the physical data is is not available (and for boards being designed). Transmission line models are appropriate. Several formats have been proposed: nodal descriptions (Spice-like), transmission line connection syntax (Z0, TD, Length, Forks), and field extractor like (L, C, length) formats. In practice, single line structures are quite adequate for electrical boards for timing and signal integrity analysis. Connector models are another requirement. Single line models can be used. However there is strong interest in multi-line (coupled) models to support multiboard applications. The typical analysis may cover cross-talk, ground bounce and differential nets. BIRD36 covers both the single line electrical board descriptions and also multi-line connector models. BIRD31.3 is a connector only proposal that is an extension of BIRD28.3 to cover two-terminal devices. It is currently on hold pending the resolution of BIRD36. BIRD32 is a coupling proposal extension that deals with subcircuit matrices as a more economical way of formatting matrix coupling. This is also on hold. Thus the proposals currently under consideration are BIRD37.2 for packages and BIRD36 for electrical board descriptions including connectors. Several minor editorial corrections were suggested for BIRD37.2. BIRD37.2 was approved unanimously. AR - Stephen Peters issue approved BIRD37.3 with the corrections. [Done] PACKAGE COMMITTEE REPORT Stephen Peters reported on Package Committee discussions. One consensus is that the electrical description is positioned to support smaller boards is not intended to be as comprehensive as a full physical description. So uncoupled networks are adequate. The EDIF 4 0 0 format covers the full physical description including coupling and contains references to IBIS models. Connectors are typically a repetitive structure that can be described by simple, single line, pin-to-pin formats and also by coupling matrix formats. EDA vendors need coupling. So the question is how to describe the coupling. Hank Herrmann has made some changes to BIRD36 based on some previous meeting comments and suggestions. He will forward the revised BIRD36 to Stephen to distribute to the Package Committee. Hank noted that single line connector models could be provided immediately once the format is defined. Package Committee meetings will continue on Fridays, 8:30 A.M. to 10 A.M. AR - Stephen Peters set up the Package Committee meeting. SPECIFICATION COMMITTEE REPORT Bob Ross reported that Ahmed Omer, John Fitzpatrick, Jon Powell and Bob held several conference call meetings resulting in BIRD39. Its key aspects are: - A new optional specification keyword [Model Spec] under [Model] - [Model Spec] subparameters with typ, min and max columns - Vinl and Vinh thresholds extended to min and max - Hysteresis thresholds - Overshoot and dynamic overshoot parameters - Pulse immunity parameters Arpad Muranyi questioned whether an area or energy definition could be used for dynamic overshoot. Bob responded that the committee had considered such an approach. The problem was in obtaining a value. Also the committee found that the source data information came in all types of formats. For example a PCI bus overshoot specification is derivable from a current limit value and clamping diode details. Some of the information may be in general sections showing typical characteristics rather than associated with a specific part. So the Committee opted for a simpler method where a voltage can exceed the overshoot value for a specified period of time as long as it remains below the dynamic overshoot limit value. The pulse immunity values also provide a do-not-exceed value for a specified period of time beyond some existing thresholds. A vote will be scheduled at the next meeting. Also a vote to reject BIRD38 will be scheduled since BIRD39 supersedes BIRD38. BIRD35.2 - MULTI-STAGED OUTPUTS Bob Ross recently introduced BIRD35.2 proposing a revised scheduling method He believes it is compatible to existing implementations, but plans to check with Jon Powell. EGG10 - PARSER ADDITIONS FOR NUMERICAL CHECKING Chris Rokusek indicated he could implement the proposed changes in one module so that the revised code could provide a new basis for further development. The unchanged ibischk2 would still be available. Chris and Bob Ross need to decide on some functionality details mentioned at the last meeting. AR - Chris Rokusek and Bob Ross decide on some functionality details and Chris produce the revised ibischk2. NEXT MEETING: The next meeting is on Friday, November 8, 1996, 8:00 A.M. to 9:55 A.M. BIRD39 and BIRD38 are scheduled for a vote. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Wed Oct 23 13:19:53 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 NAA04542 for ; Wed, 23 Oct 1996 13:19:53 -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 NAA21336 for ; Wed, 23 Oct 1996 13:09:06 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id NAA23889; Wed, 23 Oct 1996 13:08:35 -0700 (PDT) Message-Id: <199610232008.NAA23889@ichips.intel.com> To: ibis@vhdl.org Subject: IBIS packaging Subcommittee Date: Wed, 23 Oct 1996 13:09:07 -0700 From: Stephen Peters Hello all: The IBIS packaging subcommittee will be meeting this Friday. Details are below: Date: Friday, Oct 25 Time: 8:30am to 10:00am PDT Phone #: (916) 356-9200 Res #: 2-107696 Passcode: 3437649 The agenda will be to continue our discussion on connector modeling. Regards, Stephen Peters Intel Corp. From owner-ibis Wed Oct 23 16:27:13 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 QAA06076 for ; Wed, 23 Oct 1996 16:27:12 -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 AA19072 for ibis@vhdl.org; Wed, 23 Oct 96 16:16:27 MST Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA15671 for ibis@vhdl.org; Wed, 23 Oct 96 16:16:26 MST Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA01794; Wed, 23 Oct 1996 18:17:25 -0500 Date: Wed, 23 Oct 1996 18:17:25 -0500 From: omera@trailblazer.sps.mot.com (Ahmed Omer) Message-Id: <9610232317.AA01794@trailblazer.aisl.aus> To: ibis@vhdl.org Subject: Ramp Def. ?? X-Sun-Charset: US-ASCII Hello IBIS people Is ramp rate defined as the time it takes the output to go: (a) 20% to 80% of output final value or (b) 20% to 80% of output voltage swing* * I define voltage swing as the difference between final value and initial value. For example; Say, the output swings 1 to 5 volts. | 5 v ____ To calculate the ramp rate do I use | / (a) 20% to 80% of 5 volts | / or | / (b) 20% to 80% of 4 volts | 1v ____/ Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| From owner-ibis Wed Oct 23 18:29:30 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 SAA07005 for ; Wed, 23 Oct 1996 18:29:29 -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 SAA21749 for ; Wed, 23 Oct 1996 18:18:44 -0700 (PDT) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id SAA22195; Wed, 23 Oct 1996 18:18:11 -0700 (PDT) Message-Id: <199610240118.SAA22195@ichips.intel.com> To: ibis@vhdl.org Subject: Ramp Def. ?? Date: Wed, 23 Oct 1996 18:18:45 -0700 From: Stephen Peters Hello Ahmed: It's the 20% to 80% of the voltage swing. Specifically the Dt number is calculated as (for rising wavefront).... (time at which voltage waveform crosses [.8(voltage swing) + starting voltage]) - (time at which voltage waveform crosses [.2(voltage swing) + starting voltage]). Hope that helps. Regards, Stephen Peters Intel Corp. Hello IBIS people Is ramp rate defined as the time it takes the output to go: (a) 20% to 80% of output final value or (b) 20% to 80% of output voltage swing* * I define voltage swing as the difference between final value and initial value. For example; Say, the output swings 1 to 5 volts. | 5 v ____ To calculate the ramp rate do I use | / (a) 20% to 80% of 5 volts | / or | / (b) 20% to 80% of 4 volts | 1v ____/ Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| From owner-ibis Wed Oct 23 18:38:23 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 SAA07124 for ; Wed, 23 Oct 1996 18:38:22 -0700 (PDT) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 23 Oct 96 18:27 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 23 Oct 96 18:27 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 23 Oct 96 18:29 PDT Message-Id: Date: Wed, 23 Oct 96 18:29 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, omera@trailblazer.sps.mot.com Subject: Re: Ramp Def. ?? Ahmed: Case (b). The 20% and 80% voltage points are 1.8 V and 4.2 V. Best Regards, Bob Ross Interconnectix, Inc. > Date: Wed, 23 Oct 1996 18:17:25 -0500 > From: omera@trailblazer.sps.mot.com (Ahmed Omer) > Message-Id: <9610232317.AA01794@trailblazer.aisl.aus> > To: ibis@vhdl.org > Subject: Ramp Def. ?? > X-Sun-Charset: US-ASCII > Status: RO > Hello IBIS people > Is ramp rate defined as the time it takes the output to go: > (a) 20% to 80% of output final value > or > (b) 20% to 80% of output voltage swing* > * I define voltage swing as the difference > between final value and initial value. > > For example; > Say, the output swings 1 to 5 volts. | 5 v ____ > To calculate the ramp rate do I use | / > (a) 20% to 80% of 5 volts | / > or | / > (b) 20% to 80% of 4 volts | 1v ____/ > > Regards, Ahmed. > |---------------------------------------+------------------------------------| > |Ahmed Omer | Advanced Interconnect Systems Labs | > |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | > | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | > |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | > |Fax: 512-933-5845 | Austin, TX 78721 | > |---------------------------------------+------------------------------------| From owner-ibis Thu Oct 24 07:48:38 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 HAA29154 for ; Thu, 24 Oct 1996 07:48:37 -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 AA27429 for ibis@vhdl.org; Thu, 24 Oct 96 07:37:47 MST Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA28890 for ibis@vhdl.org; Thu, 24 Oct 96 07:37:42 MST Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA02524; Thu, 24 Oct 1996 09:38:40 -0500 Date: Thu, 24 Oct 1996 09:38:40 -0500 From: omera@trailblazer.sps.mot.com (Ahmed Omer) Message-Id: <9610241438.AA02524@trailblazer.aisl.aus> To: ibis@vhdl.org Subject: Re: Ramp Def. ?? X-Sun-Charset: US-ASCII Hello Bob and Stephen Thank you for your responses. Your answers are what I expected. However, the IBIS specifications are not clear on that. In fact it defines ramp rate in both ways. So we should make correction on the specifications. Regards, Ahmed. >>>> Bob Ross wrote: Ahmed: Case (b). The 20% and 80% voltage points are 1.8 V and 4.2 V. Best Regards, Bob Ross Interconnectix, Inc. >>>> Stephen Peters wrote: Hello Ahmed: It's the 20% to 80% of the voltage swing. Specifically the Dt number is calculated as (for rising wavefront).... (time at which voltage waveform crosses [.8(voltage swing) + starting voltage]) - (time at which voltage waveform crosses [.2(voltage swing) + starting voltage]). Hope that helps. Regards, Stephen Peters Intel Corp. >>>> Ahmed Omer wrote: Hello IBIS people Is ramp rate defined as the time it takes the output to go: (a) 20% to 80% of output final value or (b) 20% to 80% of output voltage swing* * I define voltage swing as the difference between final value and initial value. For example; Say, the output swings 1 to 5 volts. | 5 v ____ To calculate the ramp rate do I use | / (a) 20% to 80% of 5 volts | / or | / (b) 20% to 80% of 4 volts | 1v ____/ Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |____________________________________________________________________________| From owner-ibis Thu Oct 24 08:05:38 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 IAA29333 for ; Thu, 24 Oct 1996 08:05:38 -0700 (PDT) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 24 Oct 1996 14:54:53 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id HAA19296 for ibis@vhdl.org; Thu, 24 Oct 1996 07:53:26 -0700 (PDT) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 24 Oct 96 07:53:26 PDT Date: Thu, 24 Oct 96 07:50:00 PDT From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: Ramp Def. ?? Text item: It is 20-80% of the swing. Arpad Muranyi Intel Corporation =========================================== Hello IBIS people Is ramp rate defined as the time it takes the output to go: (a) 20% to 80% of output final value or (b) 20% to 80% of output voltage swing* * I define voltage swing as the difference between final value and initial value. For example; Say, the output swings 1 to 5 volts. | 5 v ____ To calculate the ramp rate do I use | / (a) 20% to 80% of 5 volts | / or | / (b) 20% to 80% of 4 volts | 1v ____/ Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| 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 Subject: Ramp Def. ?? To: ibis@vhdl.org Message-Id: <9610232317.AA01794@trailblazer.aisl.aus> From: omera@trailblazer.sps.mot.com (Ahmed Omer) Date: Wed, 23 Oct 1996 18:17:25 -0500 Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA01794; Wed, 23 Oct 1996 18:17:25 -0500 Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI- 4.1/Email-2.0) id AA15671 for ibis@vhdl.org; Wed, 23 Oct 96 16:16:26 MST Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA19072 for ibis@vhdl.org; Wed, 23 Oct 96 16:16:27 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 QAA06076 for ; Wed, 23 Oct 19 96 16:27:12 -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 QAA29638; Wed, 23 Oct 1996 16:20:16 -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 QAA04218; Wed, 23 Oct 1996 16:20:15 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Oct 24 08:37:41 1996 Received: from hq15.pcmail.ingr.com (hq15.pcmail.ingr.com [129.135.251.243]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA29698 for ; Thu, 24 Oct 1996 08:37:41 -0700 (PDT) Received: by hq15.pcmail.ingr.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57) id <01BBC195.E3DA6810@hq15.pcmail.ingr.com>; Thu, 24 Oct 1996 10:26:59 -0500 Message-ID: From: "Boeckmann, Ed (Edward F)" To: "'ibis@vhdl.org'" Subject: Rising Waveform Loading Effects Date: Thu, 24 Oct 1996 10:25:42 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57 Encoding: 41 TEXT 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 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 14:58:58 1996 Received: from crl.dec.com (crl.dec.com [192.58.206.2]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA00934 for ; Fri, 25 Oct 1996 14:58:57 -0700 (PDT) From: chu@rock.enet.dec.com Received: by crl.dec.com; id AA26610; Fri, 25 Oct 96 17:42:27 -0400 Received: by easynet.crl.dec.com; id AA13292; Fri, 25 Oct 96 17:42:27 -0400 Message-Id: <9610252142.AA13292@easynet.crl.dec.com> Received: from rock.enet; by crl.enet; Fri, 25 Oct 96 17:42:27 EDT Date: Fri, 25 Oct 96 17:42:27 EDT To: ibis@vhdl.org Cc: chu@rock.enet.dec.com Apparently-To: ibis@vhdl.org Subject: Spice to IBIS Conversion Hello Everyone: This is for those who are interested in the Spice to IBIS conversion program, S2IBIS2. I have observed the following difficulty in generating the V/I curve for an I/O pin. To generate a pull-up or pull-down curve for an I/O pin when enabled, s2ibis2 creates a voltage source at the enable pin in the .spi file (say putx.spi for pull-up, typical and pin x as an example) to make sure that the output is active. That was done correctly. However, when comes to generate the pull-up of pull-down curves under disabled condition, no active voltage source is created in the .spi file (it will be dutx.spi or ddtx.spi in this case). Anyone who has tried the tryme.s2i can look at the following two files, put8.spi and ddt8.spi. In put8.spi, a voltage source, 'venas2i 61 0 dc 0' was generated to enable the output. But in dut8.spi, node 61 is left floating. I tried to correct the problem by connecting a large resistor from the enable pin to VDD in the .sp file (the spice source file) to make that pin defaults to high. It fixed this situation but run into problem in other cases. Any feedback or comments from anyone would be very much appreciated. Jeff Chu Digital Equipment Corp. 77 Reed Road Hudson, MA 01749 (508)568-4197 (508)568-5195 fax email chu@rock.enet.dec.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 14:51:08 1996 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA21033 for ; Mon, 28 Oct 1996 14:51:02 -0800 (PST) Received: from wpgate.cae.ca by bhole with SMTP (DuhMail/2.0) id RAA15253; Mon, 28 Oct 1996 17:34:47 -0500 Received: from CAE_Montreal-Message_Server by wpgate.cae.ca with Novell_GroupWise; Mon, 28 Oct 1996 17:34:57 -0400 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 28 Oct 1996 17:34:36 -0400 From: Real Mongrain To: ibis@vhdl.org Subject: Low and high output level Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Hi, I just started to do some simulations (with SigNoise) using a manufacturer's model. My design is very simple : a driver connected to 3 receivers (the part is an ABT buffer). I noticed that the signal reach a perfect 5v for the rising waveform and reach a perfect 0v for the falling waveform. This Ibis model came from a convertion (s2ibis). Is it because the internal input of the output buffer has been set to 0 and vcc during the convertion (in the header file). No real part will switch to a completly on(vcc) or completly off(0v) state, so the shouldn't switch to these levels. How can i deal with that? For those who already make simulations, have you ever meet this situation? Thanks, Real Mongrain Jr. 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 Mon Oct 28 23:21:55 1996 Received: from compassion.hotmail.com (compassion.hotmail.com [206.86.127.245]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id XAA25521 for ; Mon, 28 Oct 1996 23:21:54 -0800 (PST) Received: (http://www.hotmail.com 7832 invoked by uid 0); 29 Oct 1996 03:01:15 -0000 Date: 29 Oct 1996 03:01:15 -0000 Message-ID: <19961029030115.7831.qmail@hotmail.com> Received: from 206.86.127.195 by www.hotmail.com with HTTP; Mon, 28 Oct 1996 19:01:15 PST From: "Jin Man Han" To: ibis@vhdl.org Subject: Ramp rate with 50ohm? Content-Type: text/plain Hi, every body. This is the first time I ask this question to IBIS forum after I joined yesterday. I am a memory designer and starts wondering why we have to provide ramp rate data with "non reactive 50ohm" attached to output buffer. Once we provided ramp rate to a customer and he asked us to attach 50ohm to output buffer. Why is that? Is it so crucial? Hope I can clarify this issue from all of you. Thanks. --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- 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 09:04:08 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 JAA15743 for ; Tue, 29 Oct 1996 09:04:08 -0800 (PST) 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 IAA29579 for ; Tue, 29 Oct 1996 08:53:18 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id IAA23846 for ibis@vhdl.org; Tue, 29 Oct 1996 08:53:14 -0800 (PST) Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Tue, 29 Oct 96 08:53:14 PST Date: Tue, 29 Oct 96 08:49:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re[2]: Rising Waveform Loading Effects Text item: Richard, Believe it or not, the kinds of comparisons that you are longing for are/were being done by vendors (at least by Intel). When we began to use IBIS, (or our IBIS-like behavioral models), the first thing we wanted to know was how accurate they are. If they would have not provided the accuracy, we wouldn't have gone out to simulation vendors to see if they are willing to sign up to a new standard, just to embarrass ourselves... Also, we use these in our own simulations. Do you think we would fool ourselves with a bunch of bogus data and spend millions of dollars in making chips based on that? I wonder how familiar you are with the IBIS modeling technique, at all. You say you would rather take I-V curves or SPICE models from the vendors than IBIS models. Do you realize that the IBIS models you do not want to accept contain the same I-V curves (and more) that you are willing to take? Arpad Muranyi Intel Corporation =============================================================================== 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. 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: , , 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 Subject: Re: Rising Waveform Loading Effects To: brockh@mdhost.cse.tek.com, uunet!qdt.com!jonp@uunet.uu.net Message-Id: <199610291423.IAA00293@flare.convex.com> From: schumach@flare.convex.com (Richard A. Schumacher) Date: Tue, 29 Oct 1996 08:23:10 -0600 Received: from localhost by flare.convex.com (8.6.4/1.28) id IAA00293; Tue, 29 Oct 1996 08:23:10 -0600 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 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 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 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 GAA13125; Tue, 29 Oct 1996 06:32:04 -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 GAA28416; Tue, 29 Oct 1996 06: 29:30 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Oct 29 10:23:28 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 KAA16643 for ; Tue, 29 Oct 1996 10:23:28 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Tue, 29 Oct 1996 18:12:40 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id KAA29230 for ibis@vhdl.org; Tue, 29 Oct 1996 10:11:07 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 29 Oct 96 10:11:07 PST Date: Tue, 29 Oct 96 09:18:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: Rising Waveform Loading Effects Text item: Ed, Your concern is well taken. However, I would like to point out that an IBIS model is nothing but data. The V-t curve in the IBIS model is not supposed to be the same as the simulation waveforms, unless the load is identical to the load that was used to generate the V-t curve. The simulator can do anything to this data. What I mean by this is, that if the simulator is smart enough, it can take the data and modify it, derive new curves, etc. So, if you have an I-V curve and a V-t curve which was generated with 50 Ohm resistive load in the model, a good simulator should derive a new V-t curve that matches the different load resistance in that particular simulation. Taking this further, the simulator could make V-t curves with reactive loads also. In general, then, the simulator can simulate at each iteration with a different set of curves that matches any loading condition, even if the "load" is another non-linear I-V curve. The point here is that the data in the IBIS model is not supposed to be a limiting factor to what the simulator does with it. Of course this is not the only way things can be done, I was just trying to illustrate the concept. The reason resistive (and not reactive or transmission line) loads are preferred for generating V-t curves is that with a resistive load we get only what the buffer does. With other types of loads we get what the load does also. Why would one want to add all that to the V-t curves when it will have to be taken out anyway to model just the buffer alone? Arpad Muranyi Intel Corporation ================================================================================ 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 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***. Encoding: 41 TEXT X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57 Date: Thu, 24 Oct 1996 10:25:42 -0500 Subject: Rising Waveform Loading Effects To: "'ibis@vhdl.org'" From: "Boeckmann, Ed (Edward F)" Message-ID: Received: by hq15.pcmail.ingr.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57) id <01BBC195.E3DA6810@hq15.pcmail.ingr.com>; Thu, 24 Oct 1996 10:26:59 -050 0 Received: from hq15.pcmail.ingr.com (hq15.pcmail.ingr.com [129.135.251.243]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA29698 for ; Thu, 24 O ct 1996 08:37:41 -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 IAA14618; Thu, 24 Oct 1996 08:30:29 -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 IAA00404; Thu, 24 Oct 1996 08:30:29 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Oct 29 10:53:14 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 KAA16938 for ; Tue, 29 Oct 1996 10:53:13 -0800 (PST) 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 KAA26705 for ; Tue, 29 Oct 1996 10:42:24 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id KAA16694 for ibis@vhdl.org; Tue, 29 Oct 1996 10:42:21 -0800 (PST) Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Tue, 29 Oct 96 10:42:21 PST Date: Tue, 29 Oct 96 10:39:00 PST From: James Blaschke Message-ID: To: ibis@vhdl.org Subject: unsuscribe please unsubscribe me from the ibis reflector. thanks From owner-ibis Tue Oct 29 11:01:02 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 LAA17003 for ; Tue, 29 Oct 1996 11:01:01 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Tue, 29 Oct 1996 18:50:14 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id KAA02019 for ibis@vhdl.org; Tue, 29 Oct 1996 10:48:40 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 29 Oct 96 10:48:40 PST Date: Tue, 29 Oct 96 10:10:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re[2]: Ramp Def. ?? Text item: Ahmed, In my opinion, the IBIS spec defines the ramp rates only one way, and clearly. See included sections below. Could you please point it out to me where you think the other definition is in the spec? Thanks, Arpad Muranyi Intel Corporation |============================================================================== | Keyword: [Ramp] | Required: Yes, except for inputs and terminators | Description: Defines the rise and fall times of a buffer. The ramp rate | does not include packaging but does include the effects of the | C_comp parameter. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. | The ramp rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction | and must not be reduced. The [Ramp] values can use "NA" for | the min and max values only. The R_load subparameter is | optional if the preferred 50 ohm load is used. The R_load sub- | parameter is required if a non-standard load is used. |============================================================================== | | NOTES ON DATA DERIVATION METHOD | | | 3) Ramp Rates: | | c. Due to the resistor, output swings will not make a full transition as | expected. However the pertinent data can still be collected as | follows: | 1) determine the 20% to 80% voltages of the 50 ohm swing | 2) measure this voltage change as "dV" | 3) measure the amount of time required to make this swing "dt" | =============================================================================== Hello Bob and Stephen Thank you for your responses. Your answers are what I expected. However, the IBIS specifications are not clear on that. In fact it defines ramp rate in both ways. So we should make correction on the specifications. Regards, Ahmed. >>>> Bob Ross wrote: Ahmed: Case (b). The 20% and 80% voltage points are 1.8 V and 4.2 V. Best Regards, Bob Ross Interconnectix, Inc. >>>> Stephen Peters wrote: Hello Ahmed: It's the 20% to 80% of the voltage swing. Specifically the Dt number is calculated as (for rising wavefront).... (time at which voltage waveform crosses [.8(voltage swing) + starting voltage]) - (time at which voltage waveform crosses [.2(voltage swing) + starting voltage]). Hope that helps. Regards, Stephen Peters Intel Corp. >>>> Ahmed Omer wrote: Hello IBIS people Is ramp rate defined as the time it takes the output to go: (a) 20% to 80% of output final value or (b) 20% to 80% of output voltage swing* * I define voltage swing as the difference between final value and initial value. For example; Say, the output swings 1 to 5 volts. | 5 v ____ To calculate the ramp rate do I use | / (a) 20% to 80% of 5 volts | / or | / (b) 20% to 80% of 4 volts | 1v ____/ Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |____________________________________________________________________________| 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 Subject: Re: Ramp Def. ?? To: ibis@vhdl.org Message-Id: <9610241438.AA02524@trailblazer.aisl.aus> From: omera@trailblazer.sps.mot.com (Ahmed Omer) Date: Thu, 24 Oct 1996 09:38:40 -0500 Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA02524; Thu, 24 Oct 1996 09:38:40 -0500 Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI- 4.1/Email-2.0) id AA28890 for ibis@vhdl.org; Thu, 24 Oct 96 07:37:42 MST Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA27429 for ibis@vhdl.org; Thu, 24 Oct 96 07:37:47 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 HAA29154 for ; Thu, 24 Oct 19 96 07:48:37 -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 HAA05439; Thu, 24 Oct 1996 07:45:44 -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 HAA21430; Thu, 24 Oct 1996 07:45:43 -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 11:20:33 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 LAA17165 for ; Tue, 29 Oct 1996 11:20:32 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Tue, 29 Oct 1996 19:09:45 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id LAA03514 for ibis@vhdl.org; Tue, 29 Oct 1996 11:08:12 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 29 Oct 96 11:08:12 PST Date: Tue, 29 Oct 96 11:00:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: Low and high output level Text item: Real, I must disagree with your statement that real parts will not switch to Vcc or GND. In the CMOS world all it takes is time. Given enough time, the capacitive inputs will be fully charged or discharged, i.e. the voltage will be Vcc or GND. You are right if you are talking about bipolar devices, since there is some amount of current flowing, which will load the output of the driver. So, before going on, you must answer two questions: Are you simulating with CMOS models, and how long did you run your simulation? Arpad Muranyi Intel Corporation ============================================================================ Hi, I just started to do some simulations (with SigNoise) using a manufacturer's model. My design is very simple : a driver connected to 3 receivers (the part is an ABT buffer). I noticed that the signal reach a perfect 5v for the rising waveform and reach a perfect 0v for the falling waveform. This Ibis model came from a convertion (s2ibis). Is it because the internal input of the output buffer has been set to 0 and vcc during the convertion (in the header file). No real part will switch to a completly on(vcc) or completly off(0v) state, so the shouldn't switch to these levels. How can i deal with that? For those who already make simulations, have you ever meet this situation? Thanks, Real Mongrain Jr. 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-Disposition: inline Content-Type: text/plain Mime-Version: 1.0 Subject: Low and high output level To: ibis@vhdl.org From: Real Mongrain Date: Mon, 28 Oct 1996 17:34:36 -0400 X-Mailer: Novell GroupWise 4.1 Message-Id: Received: from CAE_Montreal-Message_Server by wpgate.cae.ca with Novell_GroupWise; Mon, 28 Oct 1996 17:34:57 -0400 Received: from wpgate.cae.ca by bhole with SMTP (DuhMail/2.0) id RAA15253; Mon, 28 Oct 1996 17:34:47 -0500 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by vhdl.vhdl.org (8.7.3/8.7 .3) with SMTP id OAA21033 for ; Mon, 28 Oct 1996 14:51:02 -0800 ( PST) 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 OAA02275; Mon, 28 Oct 1996 14:51:03 -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 OAA25873; Mon, 28 Oct 1996 14: 48:29 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Tue Oct 29 12:43:25 1996 Received: from gateway.s3.com (gateway.s3.com [198.211.58.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA17787 for ; Tue, 29 Oct 1996 12:43:25 -0800 (PST) Received: from s3.s3.com (loghost.s3.com [172.19.8.4]) by gateway.s3.com (8.6.12/8.6.12) with ESMTP id MAA21180 for ; Tue, 29 Oct 1996 12:21:04 -0800 Received: from s3 (sunrise.s3.com [172.19.8.79]) by s3.s3.com (8.6.12/8.6.12) with SMTP id NAA15499 for ; Tue, 29 Oct 1996 13:31:22 -0700 Received: by s3 (4.1/SMI-4.1) id AA04745; Tue, 29 Oct 96 12:31:17 PST Date: Tue, 29 Oct 96 12:31:17 PST From: yhsia@s3.com (Yuwen Hsia S3 Inc (408)980-5401 x3402) Message-Id: <9610292031.AA04745@s3> To: ibis@vhdl.org Subject: unsuscribe Cc: yhsia@s3.com please unsubscribe me from the ibis reflector. thanks From owner-ibis Tue Oct 29 12:42:49 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA17784 for ; Tue, 29 Oct 1996 12:42:48 -0800 (PST) Received: (from kellee@localhost) by montana.nwlink.com (8.7.4/8.7.3) id MAA08776; Tue, 29 Oct 1996 12:32:01 -0800 (PST) Message-Id: <2.2.32.19961029202447.006ed094@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Oct 1996 12:24:47 -0800 To: ibis@vhdl.org From: Kellee Crisafulli Subject: IBIS as the accurate standard. There has been a number of emails of late about how accurate the IBIS models. I think some of this discussion really looses site of the FACTS. 1) No model is "accurate" for all uses especially SPICE models. 2) IBIS models are better than SPICE models in almost all respects associated with signal integrity analysis tools because: a) The model is a standard with agreed upoun rules unlike the 40+ different flavors of SPICE. b) The model is transportable as a public standard because it does not give away confidential design information. c) The models are generally plenty accurate given the tolerances of everything else in the system. e.g. PCB tolerences, IC process tolerence, power supply, etc.. Do we really need 5% accuracy when the IC varies by factors of 2 in some cases. The PCB's alone can make impedance changes of 10% or more. 3) IBIS models can be made from measured data or translated from SPICE model data. This makes them much more flexibly constructed then SPICE models. BOTTOM LINE: IBIS models are accurate enough for today's signal integrity needs in 99% of the cases. best wishes to all, Kellee --------------------------------------------------------------- Have a great day...Kellee Crisafulli, HyperLynx Inc. --------------------------------------------------------------- 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 14:26:33 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 OAA18712 for ; Tue, 29 Oct 1996 14:26:30 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA29790; Tue, 29 Oct 1996 14:03:10 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA25695; Tue, 29 Oct 96 13:50:48 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA19630; Tue, 29 Oct 1996 13:59:35 +0800 Date: Tue, 29 Oct 1996 13:59:35 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9610292159.AA19630@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Rising Waveform Loading Effects Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Arpad Muranyi, Intel Corporation wrote: > What I mean by this is, that if the simulator is smart enough, it can take the > data and modify it, derive new curves, etc. So, if you have an I-V curve and a > V-t curve which was generated with 50 Ohm resistive load in the model, a good > simulator should derive a new V-t curve that matches the different load > resistance in that particular simulation. Taking this further, the simulator > could make V-t curves with reactive loads also. In general, then, the simulator > can simulate at each iteration with a different set of curves that matches any > loading condition, even if the "load" is another non-linear I-V curve. The > point here is that the data in the IBIS model is not supposed to be a limiting > factor to what the simulator does with it. This is not quite true. Simulator cannot CREATE additional information. If V-t data is given only for one resistive load, how can the simulator create V-t data for arbitrary loading conditions? To illustrate the point, let us assume that the so called "load" can be described by only one independent variable. (In real life, it is an n-dimensional problem.) Let us assume that the dependent entity is the V-t curve. Thus, in this hypothetical two dimension space, the ibis specification gives one data point. From this single data point, there is no way to produce a straight line, or at least there is no UNIQUE way. If the ibis specification were to give two data points, then one can say that the simulator should be smart enough to fit a straight line thru these two points and then interpolate and extrapolate(although extrapolation is dangerous in many situations). [In practice, ibis specification has room to provide V-t curves for multiple loads, but the simulator is still limited by the information provided in the ibis model. It cannot CREATE V-t curves for the general n-dimensional case. The simulator may be able to do this if it makes certain assumptions, but since these assumptions are not specified in the ibis model, the simulation results will be unpredictable (and even unreliable).] ------------------------------------------------------------ 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 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 15:42:35 1996 Received: from ian.edaco.ingr.com (ian.dazixco.ingr.com [129.135.108.123]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA19337 for ; Tue, 29 Oct 1996 15:42:30 -0800 (PST) Received: by ian.edaco.ingr.com (4.1/SMI-4.1) id AA03438; Tue, 29 Oct 96 16:30:16 MST Date: Tue, 29 Oct 96 16:30:16 MST From: idodd@ian.edaco.ingr.com (Ian Dodd) Message-Id: <9610292330.AA03438@ian.edaco.ingr.com> To: ibis@vhdl.org Subject: RE: Rising Waveform Loading Effects Dileep, I am afraid I side with Arpad, the Rising waveform curves define how the driver gets from one specified point on the logic low I/V curve to a specified point on the high I/V curve. In transmission line simulation we want to know how the driver will go from a point on the logic low I/V curve defined by our loading to a point on the logic high I/V curve defined by our loading. If the first IV points and the ones that we want to use for our loading conditions are not too far apart, it seems reasonable to assume that the curve between the two points we want is very similar in shape to that connecting the two points on the Rising curve. An algorithm based on this observation should give predictable and reliable results. Ian Dodd Veribest Inc idodd@veribest.com ----- Begin Included Message ----- From owner-ibis@vhdl.vhdl.org Tue Oct 29 15:57:00 1996 From: dileep@contec.Apsimtech.COM (Dileep Divekar) To: ibis@vhdl.org Subject: Re: Rising Waveform Loading Effects Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Content-Length: 2417 X-Lines: 46 Arpad Muranyi, Intel Corporation wrote: > What I mean by this is, that if the simulator is smart enough, it can take the > data and modify it, derive new curves, etc. So, if you have an I-V curve and a > V-t curve which was generated with 50 Ohm resistive load in the model, a good > simulator should derive a new V-t curve that matches the different load > resistance in that particular simulation. Taking this further, the simulator > could make V-t curves with reactive loads also. In general, then, the simulator > can simulate at each iteration with a different set of curves that matches any > loading condition, even if the "load" is another non-linear I-V curve. The > point here is that the data in the IBIS model is not supposed to be a limiting > factor to what the simulator does with it. This is not quite true. Simulator cannot CREATE additional information. If V-t data is given only for one resistive load, how can the simulator create V-t data for arbitrary loading conditions? To illustrate the point, let us assume that the so called "load" can be described by only one independent variable. (In real life, it is an n-dimensional problem.) Let us assume that the dependent entity is the V-t curve. Thus, in this hypothetical two dimension space, the ibis specification gives one data point. From this single data point, there is no way to produce a straight line, or at least there is no UNIQUE way. If the ibis specification were to give two data points, then one can say that the simulator should be smart enough to fit a straight line thru these two points and then interpolate and extrapolate(although extrapolation is dangerous in many situations). [In practice, ibis specification has room to provide V-t curves for multiple loads, but the simulator is still limited by the information provided in the ibis model. It cannot CREATE V-t curves for the general n-dimensional case. The simulator may be able to do this if it makes certain assumptions, but since these assumptions are not specified in the ibis model, the simulation results will be unpredictable (and even unreliable).] ------------------------------------------------------------ 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 ------------------------------------------------------------ ----- End Included Message ----- From owner-ibis Tue Oct 29 15:51:01 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 PAA19494 for ; Tue, 29 Oct 1996 15:51:00 -0800 (PST) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbnow13210; Tue, 29 Oct 1996 18:39:42 -0500 (EST) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 29 Oct 1996 18:39:42 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01964; Tue, 29 Oct 96 15:36:54 PST Received: from awacs by hal.qdt.com (4.1/SMI-4.1) id AA14104; Tue, 29 Oct 96 15:36:54 PST Sender: crokusek@qdt.com Message-Id: <32769514.3F54BC7E@qdt.com> Date: Tue, 29 Oct 1996 15:36:52 -0800 From: Chris Rokusek Organization: Quad Design Technology X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: Dileep Divekar Cc: ibis@vhdl.org Subject: Re: Rising Waveform Loading Effects References: <9610292159.AA19630@contec13.contec.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dileep, There are a few "dimensions" of knowledge not explicity present in the .ibs model which may be useful to a simulator: - Nearly all digital drivers can be catagorized into one of a few unique output stages groups whose behavior can been studied in depth. - Transistors are well defined devices whose behavior has been studied for decades. *** Simulator modeling algorithms are not trivial. Given DC vi curves for high/low states and predetermined resistively loaded waveforms as required by simulator, waveform prediction into arbitrary loads is possible, proven and extremely reliable for board-level analysis. -Chris Rokusek Quad Deisgn Technology Dileep Divekar wrote: > > Arpad Muranyi, Intel Corporation wrote: > > > What I mean by this is, that if the simulator is smart enough, it can take the > > data and modify it, derive new curves, etc. So, if you have an I-V curve and a > > V-t curve which was generated with 50 Ohm resistive load in the model, a good > > simulator should derive a new V-t curve that matches the different load > > resistance in that particular simulation. Taking this further, the simulator > > could make V-t curves with reactive loads also. In general, then, the simulator > > can simulate at each iteration with a different set of curves that matches any > > loading condition, even if the "load" is another non-linear I-V curve. The > > point here is that the data in the IBIS model is not supposed to be a limiting > > factor to what the simulator does with it. > > This is not quite true. Simulator cannot CREATE additional information. > If V-t data is given only for one resistive load, how can the simulator > create V-t data for arbitrary loading conditions? To illustrate the point, > let us assume that the so called "load" can be described by only one > independent variable. (In real life, it is an n-dimensional problem.) > Let us assume that the dependent entity is the V-t curve. Thus, in this > hypothetical two dimension space, the ibis specification gives one data > point. From this single data point, there is no way to produce a straight > line, or at least there is no UNIQUE way. If the ibis specification were > to give two data points, then one can say that the simulator should be > smart enough to fit a straight line thru these two points and then > interpolate and extrapolate(although extrapolation is dangerous in many > situations). > [In practice, ibis specification has room to provide V-t curves for > multiple loads, but the simulator is still limited by the information > provided in the ibis model. It cannot CREATE V-t curves for the > general n-dimensional case. The simulator may be able to do this if it > makes certain assumptions, but since these assumptions are not specified > in the ibis model, the simulation results will be unpredictable (and even > unreliable).] > > ------------------------------------------------------------ > 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 Tue Oct 29 18:18:33 1996 Received: from netcomsv.netcom.com (uucp12.netcom.com [163.179.3.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA20798 for ; Tue, 29 Oct 1996 18:18:33 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id QAA18954; Tue, 29 Oct 1996 16:12:28 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA26401; Tue, 29 Oct 96 14:28:47 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA19642; Tue, 29 Oct 1996 14:37:35 +0800 Date: Tue, 29 Oct 1996 14:37:35 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9610292237.AA19642@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: IBIS as the accurate standard. Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Kellee Crisafulli, HyperLynx Inc. wrote: > There has been a number of emails of late about how accurate > the IBIS models. I think some of this discussion really looses > site of the FACTS. > > 1) No model is "accurate" for all uses especially SPICE models. > Where is the FACT in the above statement? It is more like an opinion and everyone is entitled to have one. I do not see why SPICE models should be ESPECIALLY less "accurate". Is it possible to prove the above statement? I agree with the first half of the statement that no model is accurate for all uses and both ibis and spice models have that limitation. I think it is possible to say good things about IBIS without saying bad things about SPICE. Why should it always be necessary to defend IBIS by bad mouthing SPICE? Both serve different but useful purposes. ------------------------------------------------------------ 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:12:40 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 IAA12672 for ; Wed, 30 Oct 1996 08:12:39 -0800 (PST) Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA03916 for ibis@vhdl.org; Wed, 30 Oct 96 09:01:50 MST Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA13288 for ibis@vhdl.org; Wed, 30 Oct 96 09:01:49 MST Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA21680; Wed, 30 Oct 1996 10:02:41 -0600 Date: Wed, 30 Oct 1996 10:02:41 -0600 From: omera@trailblazer.sps.mot.com (Ahmed Omer) Message-Id: <9610301602.AA21680@trailblazer.aisl.aus> To: ibis@vhdl.org Subject: Re: Re[2]: Ramp Def. ?? X-Sun-Charset: US-ASCII Hello Arpad, Look at the two phrases marked with ***<...>*** in the Usage Rules. These are (a) and (b) in my original question. | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from ***< 20% to 80% of its final value.>*** | The ramp rate is defined as: | | dV ***< 20% to 80% voltage swing >*** | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| 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 Wed Oct 30 08:49:56 1996 Received: from netcomsv.netcom.com (uucp7.netcom.com [163.179.3.7]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA12984 for ; Wed, 30 Oct 1996 08:49:55 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id IAA26112; Wed, 30 Oct 1996 08:26:58 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA14828; Wed, 30 Oct 96 08:00:21 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA20024; Wed, 30 Oct 1996 08:09:09 +0800 Date: Wed, 30 Oct 1996 08:09:09 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9610301609.AA20024@contec13.contec.COM> To: ibis@vhdl.org Subject: RE: Rising Waveform Loading Effects Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Ian, I agree with your statement about I-V curves. I was talking avout the V-t tables. Dileep From owner-ibis Wed Oct 30 08:53:35 1996 Received: from netcomsv.netcom.com (uucp7.netcom.com [163.179.3.7]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA13026 for ; Wed, 30 Oct 1996 08:53:35 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id IAA26120; Wed, 30 Oct 1996 08:27:06 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA15156; Wed, 30 Oct 96 08:22:05 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA20030; Wed, 30 Oct 1996 08:30:53 +0800 Date: Wed, 30 Oct 1996 08:30:53 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9610301630.AA20030@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Rising Waveform Loading Effects Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Chris Rokusek, Quad Deisgn Technology wrote: > >There are a few "dimensions" of knowledge not explicity present in the >.ibs model which may be useful to a simulator: That is precisely my point. You are making certain assumptions and guesses, which are OUTSIDE the ibis specification. In fact you are trying to guess the information which ibis is trying to hide. What do you do if you encounter some data which does not fit any of your guesses? All the knowledge "dimensions" should be utilized in developing the specification, but once the specification is developed, it should have any loose ends. Let us assume that you have a simulator which can predict waveforms for any arbitrary load, given ONE waveform for one RESISTIVE load. But the ibis specification does not specify that. A model developer can specify a waveform into a general RLC load (as shown in the example on page 19 of 2.1 specification) and claim that they have provided a perfectly legal ibis model and now it is up to the simulator to do the rest. What does the simulator do in this case with the waveform with all the ringing, overshoot, undershoot etc.? The simulator should not place restrictions in ADDITION to the ibis specification. Therefore, if one waveform into one resistive load is all that is required, then it should be stated explicitly. Otherwise different people can make different assumptions and guesses. If certain things are REQUIRED to carry out a simulation, then the ibis model should SPECIFY those things instead of leaving them to guesswork. ------------------------------------------------------------ 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:55:55 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 IAA13039 for ; Wed, 30 Oct 1996 08:55:54 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 30 Oct 1996 16:45:06 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id IAA19618; Wed, 30 Oct 1996 08:43:22 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 30 Oct 96 08:43:22 PST Date: Wed, 30 Oct 96 08:35:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: dileep@contec.Apsimtech.COM Subject: Re[2]: IBIS as the accurate standard. Text item: To all, I coulnd't agree more with Dileep's last sentence (below). The problem I see is that a lot of people want to use IBIS models for the wrong reason. For example, if you are a circuit designer working on your new buffer, you are much better off using SPICE. However, even if you are a circuit desginer, but you are concerned about the system behavior of your buffer, you might benefit from many the features in IBIS (and/or behavioral) models. Another observation. Many people automatically think that SPICE is inherently more accurate than IBIS. This is a misbelief. Any model is only as good as the data is in it. It is just as easy to make bad SPICE models as IBIS models. Yet many tend to believe SPCIE more, just because it is SPICE. That is what bothers me the most... Arpad Muranyi Intel Corporation ================================================================================ Kellee Crisafulli, HyperLynx Inc. wrote: > There has been a number of emails of late about how accurate > the IBIS models. I think some of this discussion really looses > site of the FACTS. > > 1) No model is "accurate" for all uses especially SPICE models. > Where is the FACT in the above statement? It is more like an opinion and everyone is entitled to have one. I do not see why SPICE models should be ESPECIALLY less "accurate". Is it possible to prove the above statement? I agree with the first half of the statement that no model is accurate for all uses and both ibis and spice models have that limitation. I think it is possible to say good things about IBIS without saying bad things about SPICE. Why should it always be necessary to defend IBIS by bad mouthing SPICE? Both serve different but useful purposes. ------------------------------------------------------------ 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: Re: IBIS as the accurate standard. To: ibis@vhdl.org Message-Id: <9610292237.AA19642@contec13.contec.COM> From: dileep@contec.Apsimtech.COM (Dileep Divekar) Date: Tue, 29 Oct 1996 14:37:35 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA19642; Tue, 29 Oct 1996 14:37:35 +0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA26401; Tue, 29 Oct 96 14:28:47 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id QAA18954; Tue, 29 Oct 1996 16:12:28 -0800 Received: from netcomsv.netcom.com (uucp12.netcom.com [163.179.3.12]) by vhdl.vh dl.org (8.7.3/8.7.3) with SMTP id SAA20798 for ; Tue, 29 Oct 1996 18:18:33 -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 SAA21591; Tue, 29 Oct 1996 18:16:23 -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 UAA15879; Tue, 29 Oct 1996 20: 36:20 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Oct 30 09:15:50 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 JAA13240 for ; Wed, 30 Oct 1996 09:15:49 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 30 Oct 1996 17:05:01 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id JAA20761 for ibis@vhdl.org; Wed, 30 Oct 1996 09:03:27 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 30 Oct 96 09:03:26 PST Date: Wed, 30 Oct 96 08:52:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re[4]: Ramp Def. ?? Text item: Ahmed, I see your point. I guess, the question is what do you think is the final value. When we wrote this, we were thinking about the final value under the given test conditions, which was defined to be a 50 Ohm resistive load. Therefore, the final value is not a rail-to-rail swing, because the resistor won't let that happen. Consider a rising edge measurement (for a CMOS device). Before the pullup begins to drive, the voltage on the output is at GND, because the load resistor is also connected to GND, so there is no current flowing in the loop. So the starting voltage of the swing is 0 V. When the pullup is done switching, you get a voltage division across the pullup and the load resistor. This is your final value after the transition. Considering the 0 V starting voltage, this number is also equal to the swing. I quess, this could have been written up a little more clearly, but we are engineers, not lawyers. And so far I didn't hear that any one else was confused by this. I hope this helps, Arpad Muranyi Intel Corporation ================================================================================ Hello Arpad, Look at the two phrases marked with ***<...>*** in the Usage Rules. These are (a) and (b) in my original question. | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from ***< 20% to 80% of its final value.>*** | The ramp rate is defined as: | | dV ***< 20% to 80% voltage swing >*** | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| 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 Subject: Re: Re[2]: Ramp Def. ?? To: ibis@vhdl.org Message-Id: <9610301602.AA21680@trailblazer.aisl.aus> From: omera@trailblazer.sps.mot.com (Ahmed Omer) Date: Wed, 30 Oct 1996 10:02:41 -0600 Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA21680; Wed, 30 Oct 1996 10:02:41 -0600 Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI- 4.1/Email-2.0) id AA13288 for ibis@vhdl.org; Wed, 30 Oct 96 09:01:49 MST Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA03916 for ibis@vhdl.org; Wed, 30 Oct 96 09:01:50 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 IAA12672 for ; Wed, 30 Oct 19 96 08:12:39 -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 IAA19234; Wed, 30 Oct 1996 08:11:42 -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 IAA12640; Wed, 30 Oct 1996 08: 09:09 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Oct 30 11:07:28 1996 Received: from netcomsv.netcom.com (uucp7.netcom.com [163.179.3.7]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA14247 for ; Wed, 30 Oct 1996 11:07:28 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id KAA03165; Wed, 30 Oct 1996 10:42:01 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA02279; Wed, 30 Oct 96 10:32:34 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA20142; Wed, 30 Oct 1996 10:41:22 +0800 Date: Wed, 30 Oct 1996 10:41:22 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9610301841.AA20142@contec13.contec.COM> To: ibis@vhdl.org Subject: Re[2]: IBIS as the accurate standard. Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Arpad Muranyi, Intel Corporation wrote: >Another observation. Many people automatically think that SPICE is inherently >more accurate than IBIS. This is a misbelief. Any model is only as good as the >data is in it. It is just as easy to make bad SPICE models as IBIS models. Yet >many tend to believe SPCIE more, just because it is SPICE. That is what bothers >me the most... I agree with the above statement. But by the same token one should not make the mistake of always ASSUMING that IBIS models are better just because they are IBIS. Any model needs to be looked at in the right perspective. ------------------------------------------------------------ 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 11:45:07 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 LAA14585 for ; Wed, 30 Oct 1996 11:45:07 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA19464; Wed, 30 Oct 96 11:35:15 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA07114; Wed, 30 Oct 96 12:35:14 PPE Date: Wed, 30 Oct 96 12:35:14 PPE From: scotts@actel.com (Scott Schlachter) Message-Id: <9610301935.AA07114@ricky.sun_net> To: ibis@vhdl.org Subject: Question to IBIS Reflector IBIS folk: I am curious how one does rise and fall time measurements using packaged parts. The spec calls for these ramps to be measured on I/Os with no loading, but this implies wafer-level measurements which are less than ideal from a noise standpoint. One can use a high-impedance probe on packaged parts but then one gets a few pF and a few nH of LC network. In programmable logic it is almost imperative that a tester be used, as the I/Os must be programmed into their appropriate modes. My guess is that this will cause little effect on the rise and fall times, but is this correct? Is this something that really must be SPICEd? From owner-ibis Wed Oct 30 12:30:16 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 MAA15087 for ; Wed, 30 Oct 1996 12:30:15 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id MAA05329; Wed, 30 Oct 1996 12:20:06 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma005228; Wed Oct 30 12:20:00 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23839 for ibis@vhdl.org; Wed, 30 Oct 96 12:19:18 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA18730; Wed, 30 Oct 96 12:20:15 PST Date: Wed, 30 Oct 96 12:20:15 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9610302020.AA18730@rockie.nsc.com> To: ibis@vhdl.org, scotts@actel.com Subject: Re: Question to IBIS Reflector Scott: From a bench measurement point of view, it's almost impossible to measure rise/fall on a die(wafer). Measuring Rise/Fall on a packaged device takes into account the C_comp effect as well. I believe this parameter measurements were defined by SPICE users where it's easy to isolate package effects. Regards, Syed National Semiconductor Corp. > From owner-ibis@vhdl.vhdl.org Wed Oct 30 11:42:53 1996 > Date: Wed, 30 Oct 96 12:35:14 PPE > From: scotts@actel.com (Scott Schlachter) > To: ibis@vhdl.org > Subject: Question to IBIS Reflector > Content-Length: 641 > > IBIS folk: > > I am curious how one does rise and fall time measurements > using packaged parts. The spec calls for these ramps to be measured > on I/Os with no loading, but this implies wafer-level measurements > which are less than ideal from a noise standpoint. One can use a > high-impedance probe on packaged parts but then one gets a few pF > and a few nH of LC network. In programmable logic it is almost > imperative that a tester be used, as the I/Os must be programmed > into their appropriate modes. > > My guess is that this will cause little effect on the > rise and fall times, but is this correct? Is this something that > really must be SPICEd? > > From owner-ibis Wed Oct 30 12:49:22 1996 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA15357 for ; Wed, 30 Oct 1996 12:49:18 -0800 (PST) Message-Id: <199610302049.MAA15357@vhdl.vhdl.org> Received: from BTVLABVM by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5510; Wed, 30 Oct 96 15:38:25 EST Date: Wed, 30 Oct 96 14:28:34 EST From: "Douglas W. Stout (446-6232)" To: IBIS@vhdl.org Subject: unsubscribe please unsubscribe me from the ibis reflector. thanks From owner-ibis Wed Oct 30 13:20:08 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 NAA15798 for ; Wed, 30 Oct 1996 13:20:08 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 30 Oct 1996 21:09:01 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id NAA04430; Wed, 30 Oct 1996 13:07:22 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 30 Oct 96 13:07:22 PST Date: Wed, 30 Oct 96 13:02:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, scotts@actel.com Subject: Re[2]: Question to IBIS Reflector Text item: Scott, They way you do this is like optimization. You do your measurements on the device (in the package) and then you make an IBIS model for it (including package). Then you tweek the IBIS rise and fall time parameters untill the simulated rise and fall times at the output of the package match the measuremets. Arpad Muranyi Intel Corporation ========================================================================= Scott: From a bench measurement point of view, it's almost impossible to measure rise/fall on a die(wafer). Measuring Rise/Fall on a packaged device takes into account the C_comp effect as well. I believe this parameter measurements were defined by SPICE users where it's easy to isolate package effects. Regards, Syed National Semiconductor Corp. > From owner-ibis@vhdl.vhdl.org Wed Oct 30 11:42:53 1996 > Date: Wed, 30 Oct 96 12:35:14 PPE > From: scotts@actel.com (Scott Schlachter) > To: ibis@vhdl.org > Subject: Question to IBIS Reflector > Content-Length: 641 > > IBIS folk: > > I am curious how one does rise and fall time measurements > using packaged parts. The spec calls for these ramps to be measured > on I/Os with no loading, but this implies wafer-level measurements > which are less than ideal from a noise standpoint. One can use a > high-impedance probe on packaged parts but then one gets a few pF > and a few nH of LC network. In programmable logic it is almost > imperative that a tester be used, as the I/Os must be programmed > into their appropriate modes. > > My guess is that this will cause little effect on the > rise and fall times, but is this correct? Is this something that > really must be SPICEd? > > 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: Question to IBIS Reflector To: ibis@vhdl.org, scotts@actel.com Message-Id: <9610302020.AA18730@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Wed, 30 Oct 96 12:20:15 PST Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA18730; Wed, 30 Oct 96 12:20:15 PST Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA23839 for ibis@vhdl.org; Wed, 30 Oct 96 12:19:18 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma005228; Wed Oct 30 12:20:00 1996 Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id MAA0532 9; Wed, 30 Oct 1996 12:20:06 -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 MAA15087 for ; Wed, 30 Oct 19 96 12:30:15 -0800 (PST) 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 MAA08444; Wed, 30 Oct 1996 12:24:34 -0800 (PST) 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 MAA06992; Wed, 30 Oct 1996 12:24:33 -0800 ( PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Oct 30 13:20:32 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 NAA15801 for ; Wed, 30 Oct 1996 13:20:30 -0800 (PST) Received: from uucp3.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp3.UU.NET [192.48.96.34]) id QQbnse11114; Wed, 30 Oct 1996 16:09:12 -0500 (EST) Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Wed, 30 Oct 1996 16:09:12 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01251; Wed, 30 Oct 96 12:23:37 PST Received: from awacs.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA21091; Wed, 30 Oct 96 12:23:38 PST Date: Wed, 30 Oct 96 12:23:38 PST Message-Id: <9610302023.AA21091@hal.qdt.com> Received: by awacs.qdt.com (4.1/SMI-4.1) id AA20507; Wed, 30 Oct 96 12:23:35 PST From: Chris Rokusek To: ibis@vhdl.org Subject: Egg10 Implementation Hi All, I've got a working version of ibischk2 that compares AC waveform endpoint voltages against the (DC) VI curves and the correspond test fixture. I need to define a tolerance of some sort to which the voltages agree. This relates to prior discussion of how long a waveform needs to settle. The spec does not provide a tolerence... Keywords: [Rising Waveform], [Falling Waveform] . . . A waveform table must include the entire waveform; i.e., the first entry (or entries) in a voltage column must be the DC voltage of the output before switching and the last entry (or entries) of the column must be the final DC value of the output after switching. I think we need to define a % voltage that the first/last entries must lie within (e.g. 2.0%). Percent of what, though? Well, how about percent of 0% to 100% of the waveform endpoint voltages difference itself. This would require a highly loaded waveform to settle to a more absolute voltage since it would have a smaller voltage swing. Is this a good thing? Also, this is easy to implement!! :) Example Waveform: Begins: (0ns, 0.0V) Ends: (9ns, 4.0V) Load: 50 Ohms, 0.0V For 2% agreement, the v_tolerance = 2% * (4.0 - 0) = .08V So model passes if... -0.08 < v_dc_low_for_load < 0.08 AND 3.92 < v_dc_high_for_load < 4.28 Is this reasonable? -Chris R. From owner-ibis Wed Oct 30 16:16:08 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 QAA17276 for ; Wed, 30 Oct 1996 16:16:07 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 30 Oct 96 16:03 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 30 Oct 96 16:03 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 30 Oct 96 16:05 PST Message-Id: Date: Wed, 30 Oct 96 16:05 PST From: bob@icx.com ( Bob Ross) To: crokusek@qdt.com, ibis@vhdl.org Subject: Re: Egg10 Implementation Chris: I think your assumptions are good. Holding the endpoints to within 2% of the difference between seems accurate enough for most cases. The check may fail with very heavily loaded devices. However, we cannot be perfect for all cases. Will the percentage be adjustable? Bob Ross Interconnectix, Inc. > I think we need to define a % voltage that the first/last entries must > lie within (e.g. 2.0%). > Percent of what, though? Well, how about percent of 0% to 100% of the > waveform endpoint voltages difference itself. This would require a > highly loaded waveform to settle to a more absolute voltage since it > would have a smaller voltage swing. Is this a good thing? > Also, this is easy to implement!! :) > Example Waveform: > Begins: (0ns, 0.0V) > Ends: (9ns, 4.0V) > Load: 50 Ohms, 0.0V > > For 2% agreement, the v_tolerance = 2% * (4.0 - 0) = .08V > So model passes if... > -0.08 < v_dc_low_for_load < 0.08 > AND > 3.92 < v_dc_high_for_load < 4.28 > Is this reasonable? > -Chris R. From owner-ibis Thu Oct 31 07:23:16 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 HAA09744 for ; Thu, 31 Oct 1996 07:20:34 -0800 (PST) Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA16258 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:13 MST Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA11454 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:09 MST Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA24827; Thu, 31 Oct 1996 09:10:01 -0600 Date: Thu, 31 Oct 1996 09:10:01 -0600 From: omera@trailblazer.sps.mot.com (Ahmed Omer) Message-Id: <9610311510.AA24827@trailblazer.aisl.aus> To: ibis@vhdl.org Subject: Re: Re[4]: Ramp Def. ?? X-Sun-Charset: US-ASCII Hello Arpad; In your last note on this subject you wrote: " I quess, this could have been written up a little more clearly, but we are engineers, not lawyers. And so far I didn't hear that any one else was confused by this." I do not understand! What point or points are you making with that paragraph? Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| From owner-ibis Thu Oct 31 10:15:22 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 KAA11177 for ; Thu, 31 Oct 1996 10:15:22 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id LAA12657; Thu, 31 Oct 1996 11:04:31 -0700 Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma846785067.012653; Thu Oct 31 11:04:27 1996 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id NAA21817; Thu, 31 Oct 1996 13:04:21 -0500 Date: Thu, 31 Oct 1996 13:04:21 -0500 From: "C. Kumar" Message-Id: <199610311804.NAA21817@hot> To: ibis@vhdl.org, crokusek@qdt.com Subject: Re: Egg10 Implementation X-Sun-Charset: US-ASCII That is a relative check. I have seen models which do not settle to anything anything near the dc voltage. I mean the dc voltage defined by the VI table. (it should be the true dc , isn't it?). I think it is necessary explicitly clarify whether you are talking about dc voltage or steady state settling voltage. > From owner-ibis@vhdl.vhdl.org Wed Oct 30 16:17 EST 1996 > Received-Date: Wed, 30 Oct 1996 16:17:17 -0500 > From: Chris Rokusek > To: ibis@vhdl.org > Subject: Egg10 Implementation > Content-Type: text > Content-Length: 1505 > X-Lines: 58 > > Hi All, > > I've got a working version of ibischk2 that compares AC waveform > endpoint voltages against the (DC) VI curves and the correspond test > fixture. > > I need to define a tolerance of some sort to which the voltages agree. > This relates to prior discussion of how long a waveform needs to > settle. The spec does not provide a tolerence... > > > Keywords: [Rising Waveform], [Falling Waveform] > . > . > . > A waveform table must include the entire waveform; > i.e., the first entry (or entries) in a voltage column > must be the DC voltage of the output before switching > and the last entry (or entries) of the column must be > the final DC value of the output after switching. > > > > I think we need to define a % voltage that the first/last entries must > lie within (e.g. 2.0%). > > Percent of what, though? Well, how about percent of 0% to 100% of the > waveform endpoint voltages difference itself. This would require a > highly loaded waveform to settle to a more absolute voltage since it > would have a smaller voltage swing. Is this a good thing? > > > Also, this is easy to implement!! :) > > > Example Waveform: > > Begins: (0ns, 0.0V) > Ends: (9ns, 4.0V) > Load: 50 Ohms, 0.0V > > > For 2% agreement, the v_tolerance = 2% * (4.0 - 0) = .08V > > So model passes if... > > -0.08 < v_dc_low_for_load < 0.08 > > AND > > 3.92 < v_dc_high_for_load < 4.28 > > > Is this reasonable? > > -Chris R. > > > From owner-ibis Thu Oct 31 11:13:47 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 LAA11637 for ; Thu, 31 Oct 1996 11:13:45 -0800 (PST) Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQbnvo05701; Thu, 31 Oct 1996 14:02:15 -0500 (EST) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 31 Oct 1996 14:02:16 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00902; Thu, 31 Oct 96 10:50:04 PST Received: from awacs by hal.qdt.com (4.1/SMI-4.1) id AA29147; Thu, 31 Oct 96 10:50:04 PST Sender: crokusek@qdt.com Message-Id: <3278F4DA.237C228A@qdt.com> Date: Thu, 31 Oct 1996 10:50:02 -0800 From: Chris Rokusek Organization: Quad Design Technology X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Cc: cpk@cadence.com Subject: Re: Egg10 Implementation References: <199610311804.NAA21817@hot> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kumar, C. Kumar wrote: > > That is a relative check. I have seen models which do not settle to anything anything near the dc voltage. I mean the dc voltage defined by the VI table. (it should be the true dc , isn't it?). I think it is necessary explicitly clarify whether you are talking about dc voltage or steady state settling voltage. The test is designed to enforce what the spec says: A waveform table must include the entire waveform; the first entry (or entries) in a voltage column *** must be the DC voltage of the output before switching and the last entry (or entries) of the column must be the final DC value of the output after switching. The spec says "MUST BE", I think the spec should be more explicit and say something more along the lines of... The first/last waveform point voltages must lie within X Volts of the given fixture loads interection with the appropriate (TYP/MIN/MAX) VI curve where X = (first Waveform voltage point - last Waveform voltage point) * 2%. The models you mention that don't settle to anything near dc appear to be in violation of the current spec. Correct? If we can decide on a percentage, be it .01%, 1%, or 5%, then ibischk2 can enforce the spec with the added code. In the orginal example below, "v_dc_for_load" refers to the intersection of the load line with the DC vi curve and thus would enforce a correlation between each AC waveform endpoint and the VI curves. > > Example Waveform: > > > > Begins: (0ns, 0.0V) > > Ends: (9ns, 4.0V) > > Load: 50 Ohms, 0.0V > > > > > > For 2% agreement, the v_tolerance = 2% * (4.0 - 0) = .08V > > > > So model passes if... > > > > -0.08 < v_dc_low_for_load < 0.08 > > > > AND > > > > 3.92 < v_dc_high_for_load < 4.28 > > From owner-ibis Thu Oct 31 11:43:50 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 LAA11910 for ; Thu, 31 Oct 1996 11:43:38 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id MAA24771 for ; Thu, 31 Oct 1996 12:32:44 -0700 Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma846790357.024748; Thu Oct 31 12:32:37 1996 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id NAA02814; Thu, 31 Oct 1996 13:43:02 -0500 Date: Thu, 31 Oct 1996 13:43:02 -0500 From: "C. Kumar" Message-Id: <199610311843.NAA02814@hot> To: ibis@vhdl.org, dileep@contec.Apsimtech.COM Subject: Re: Rising Waveform Loading Effects X-Sun-Charset: US-ASCII I think I get the point Dileep is trying to make. It is true that with the V-t data there is no UNIQUE solution possible. This problem will baloon when we add multi stage models. The real issue is IBIS is ONLY data. And the data is subject to different interpolation and extrapolation schemes. In other words this data by in itself cannot guarantee that different simulators will produce the same result. Neither can it say which one is correct. The only locus is the golden waveform. In this respect IBIS data is fundamentally different from a macro model , where you should expect the same results from different simulators. IBIS data is rather a precursor to a macro model, which we do not have any standard for. - kumar > From owner-ibis@vhdl.vhdl.org Tue Oct 29 17:31 EST 1996 > Received-Date: Tue, 29 Oct 1996 17:31:23 -0500 > From: dileep@contec.Apsimtech.COM (Dileep Divekar) > To: ibis@vhdl.org > Subject: Re: Rising Waveform Loading Effects > Cc: dileep@contec.Apsimtech.COM > X-Sun-Charset: US-ASCII > Content-Type: text > Content-Length: 2417 > X-Lines: 46 > > > Arpad Muranyi, Intel Corporation wrote: > > > What I mean by this is, that if the simulator is smart enough, it can take the > > data and modify it, derive new curves, etc. So, if you have an I-V curve and a > > V-t curve which was generated with 50 Ohm resistive load in the model, a good > > simulator should derive a new V-t curve that matches the different load > > resistance in that particular simulation. Taking this further, the simulator > > could make V-t curves with reactive loads also. In general, then, the simulator > > can simulate at each iteration with a different set of curves that matches any > > loading condition, even if the "load" is another non-linear I-V curve. The > > point here is that the data in the IBIS model is not supposed to be a limiting > > factor to what the simulator does with it. > > This is not quite true. Simulator cannot CREATE additional information. > If V-t data is given only for one resistive load, how can the simulator > create V-t data for arbitrary loading conditions? To illustrate the point, > let us assume that the so called "load" can be described by only one > independent variable. (In real life, it is an n-dimensional problem.) > Let us assume that the dependent entity is the V-t curve. Thus, in this > hypothetical two dimension space, the ibis specification gives one data > point. From this single data point, there is no way to produce a straight > line, or at least there is no UNIQUE way. If the ibis specification were > to give two data points, then one can say that the simulator should be > smart enough to fit a straight line thru these two points and then > interpolate and extrapolate(although extrapolation is dangerous in many > situations). > [In practice, ibis specification has room to provide V-t curves for > multiple loads, but the simulator is still limited by the information > provided in the ibis model. It cannot CREATE V-t curves for the > general n-dimensional case. The simulator may be able to do this if it > makes certain assumptions, but since these assumptions are not specified > in the ibis model, the simulation results will be unpredictable (and even > unreliable).] > > ------------------------------------------------------------ > 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 Thu Oct 31 11:47:46 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 LAA11958 for ; Thu, 31 Oct 1996 11:47:45 -0800 (PST) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbnvq18430; Thu, 31 Oct 1996 14:36:55 -0500 (EST) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Thu, 31 Oct 1996 14:36:55 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01042; Thu, 31 Oct 96 11:32:07 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA29638; Thu, 31 Oct 96 11:32:06 PST Sender: jonp@qdt.com Message-Id: <3278FEB6.2781E494@qdt.com> Date: Thu, 31 Oct 1996 11:32:06 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Model Update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The National GTL models have been updated on the IBIS reflector. part gp612mea.ibs has been updated. all other GTL parts have been removed. Dummy files with removed message have been left in the directory. jnp From owner-ibis Thu Oct 31 13:13:37 1996 Received: from custmail.InterNex.Net (custmail.internex.net [199.2.14.213]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id NAA12619 for ; Thu, 31 Oct 1996 13:13:36 -0800 (PST) Received: from cixgate ([192.156.136.10]) by custmail.InterNex.Net (8.7.1/8.7.1) with SMTP id NAA29643 for ; Thu, 31 Oct 1996 13:02:43 -0800 (PST) Received: from gw.3Com.COM by cixgate (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA21863; Thu, 31 Oct 96 14:15:37 PPE Received: from hqsmtp2.OPS.3Com.COM by gw.3Com.COM with SMTP id AA19851 (5.65c/IDA-1.4.4 for ); Thu, 31 Oct 1996 13:02:40 -0800 Received: by hqsmtp2.ops.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.17/1.0) id AA4942; Thu, 31 Oct 96 13:08:29 -0800 Message-Id: <9610312108.AA4942@hqsmtp2.ops.3com.com> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 3BE487BAEBAF784E882563D4006D3002; Thu, 31 Oct 96 13:08:27 EDT To: "Douglas W. Stout (446-6232)" Cc: IBIS From: Jose Sandoval/HQ/3Com Date: 31 Oct 96 11:52:53 EDT Subject: Re: unsubscribe Mime-Version: 1.0 Content-Type: Text/Plain me too. tx ----- Previous Message ---------------------------------------------------- To: IBIS @ vhdl.org @ UGATE cc: From: DSTOUT @ btvlabvm.vnet.ibm.com ("Douglas W. Stout (446-6232)") @ UGATE Date: Wednesday October 30, 1996 02:28 PM Subject: unsubscribe ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- please unsubscribe me from the ibis reflector. thanks From owner-ibis Thu Oct 31 14:05:58 1996 Received: from crimp.amp.com (crimp.amp.com [198.80.3.102]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA13121 for ; Thu, 31 Oct 1996 14:05:57 -0800 (PST) Message-Id: <199610312205.OAA13121@vhdl.vhdl.org> Received: by crimp.amp.com id AA26259 (InterLock SMTP Gateway 3.0 for IBIS@vhdl.org); Thu, 31 Oct 1996 16:55:07 -0500 Received: by crimp.amp.com (Internal Mail Agent-1); Thu, 31 Oct 1996 16:55:07 -0500 From: "Freedman, Martin G" To: "'IBIS@vhdl.org'" Subject: unsubscribe Date: Thu, 31 Oct 1996 16:54:10 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From owner-ibis Thu Oct 31 15:00:08 1996 Received: from montana (montana.Stanford.EDU [171.64.67.47]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA13585 for ; Thu, 31 Oct 1996 15:00:08 -0800 (PST) Received: by montana (940816.SGI.8.6.9/inc-1.0) id WAA16525; Thu, 31 Oct 1996 22:48:53 GMT From: "Ken Kun-Yung Chang" Message-Id: <9610311448.ZM16523@montana> Date: Thu, 31 Oct 1996 14:48:53 -0800 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: ibis@vhdl.org Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii -- Ken Kun-Yung Chang Gates 458, kunyung@montana.stanford.edu (415)723-9131 (O) From owner-ibis Thu Oct 31 15:42:06 1996 Received: from igate1.hac.com (igate1.HAC.COM [192.48.33.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA13905 for ; Thu, 31 Oct 1996 15:42:05 -0800 (PST) From: bhenson@CCGATE.HAC.COM Received: from ises01.ES.HAC.COM ([147.16.5.2]) by igate1.hac.com (8.7.6/8.7.3) with SMTP id PAA29037 for ; Thu, 31 Oct 1996 15:30:48 -0800 (PST) Received: by ises01.ES.HAC.COM; id AA17419; Thu, 31 Oct 1996 15:30:45 -0800 Received: from cc:Mail by CCGATE.HAC.COM id AA846804650; Thu, 31 Oct 96 15:05:41 PST Date: Thu, 31 Oct 96 15:05:41 PST Encoding: 1 Text Message-Id: <9609318468.AA846804650@CCGATE.HAC.COM> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From owner-ibis Thu Oct 31 17:55: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 RAA15041 for ; Thu, 31 Oct 1996 17:55:41 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Fri, 1 Nov 1996 01:44:52 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id RAA13922 for ibis@vhdl.org; Thu, 31 Oct 1996 17:43:15 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 31 Oct 96 17:43:15 PST Date: Thu, 31 Oct 96 17:12:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re[6]: Ramp Def. ?? Text item: Ahmed, I meant to say that lawyers have a good ability to put things in words so that noone can misinterpret what they say at a later time. (I could be wrong on that though). Writing a spec in a non-misinterpretable way is very difficult, and I find that very often what I meant to say gets interpreted differently by someone else, because they have a different vocabulary, background, mindframe, etc. This is what might have been the case here too. It was totally clear to me that both places were saying the same, and yet you thought that it meant rail-to-rail in the first place, and 20-80 % in the second. However, you were the first one I heard this interpretation from... Arpad ================================================================================ Hello Arpad; In your last note on this subject you wrote: " I quess, this could have been written up a little more clearly, but we are engineers, not lawyers. And so far I didn't hear that any one else was confused by this." I do not understand! What point or points are you making with that paragraph? Regards, Ahmed. |---------------------------------------+------------------------------------| |Ahmed Omer | Advanced Interconnect Systems Labs | |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 | |Fax: 512-933-5845 | Austin, TX 78721 | |---------------------------------------+------------------------------------| 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 Subject: Re: Re[4]: Ramp Def. ?? To: ibis@vhdl.org Message-Id: <9610311510.AA24827@trailblazer.aisl.aus> From: omera@trailblazer.sps.mot.com (Ahmed Omer) Date: Thu, 31 Oct 1996 09:10:01 -0600 Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) id AA24827; Thu, 31 Oct 1996 09:10:01 -0600 Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI- 4.1/Email-2.0) id AA11454 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:09 MST Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA16258 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:13 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 HAA09744 for ; Thu, 31 Oct 19 96 07:20:34 -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 HAA18237; Thu, 31 Oct 1996 07:21:31 -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 HAA12474; Thu, 31 Oct 1996 07: 18:59 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org