From Arpad_Muranyi@ccm.fm.intel.com Fri Sep 1 08:23:13 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18702; Fri, 1 Sep 95 08:23:13 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0soXoZ-000UinC; Fri, 1 Sep 95 08:15 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0soXoZ-000txbC; Fri, 1 Sep 95 08:15 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Fri, 01 Sep 95 08:15:31 PDT Date: Fri, 01 Sep 95 08:08:00 PDT From: Arpad Muranyi Message-Id: To: fvance@FirePower.COM, bob@icx.com Cc: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re[2]: On Non-Monotonic Drivers Text item: One example is one of IBM's process in which the shape of the I-V curve looks like the curve with the "*" vs. the normal shape shown with "-" (this is shown here with their permission). _ _----------------- * * * * * * * * * * * * * * * Even though IBM's circuit is not known to me, it seems that this can be achieved by some kind of feedback. I agree with Jon Powell, it is important to know the timing characteristics of this feedback path, however, if it is "instantaneous", I think it could be ignored. Arpad ============================================================================== Does anyone else have an example of a non-monotonic output buffer? Fred Vance 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: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re: On Non-Monotonic Drivers To: bob@icx.com ( Bob Ross) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 31 Aug 95 19:05:21 -0700 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA00780; Thu, 31 Aug 95 19:05:21 -0700 Message-Id: <9509010205.AA14506@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14506; Thu, 31 Aug 95 19:05:23 -0700 Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA15088; Thu, 31 Aug 95 19:05:26 -0700 Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRN et) id AA09553; Thu, 31 Aug 95 19:13:34 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 31 Aug 95 19 :09:43 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soLY8-000tx9C; Thu, 31 Aug 95 19:09 PDT From uunet!qdt.com!jonp@uunet.uu.net Fri Sep 1 09:27:18 1995 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19224; Fri, 1 Sep 95 09:27:18 PDT Received: from relay3.UU.NET by chronos.synopsys.com with SMTP id AA10674 (5.65c/IDA-1.4.4 for ); Fri, 1 Sep 1995 09:20:26 -0700 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzfif29851; Fri, 1 Sep 1995 12:18:30 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 1 Sep 1995 12:18:30 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00461; Fri, 1 Sep 95 08:50:51 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA26123; Fri, 1 Sep 95 08:50:51 PDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzfic15787; Fri, 1 Sep 1995 11:36:13 -0400 Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 1 Sep 1995 11:36:14 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00346; Fri, 1 Sep 95 07:47:08 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA25928; Fri, 1 Sep 95 07:47:08 PDT Date: Fri, 1 Sep 95 07:47:08 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9509011447.AA25928@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA25123; Fri, 1 Sep 95 07:47:07 PDT To: fvance@FirePower.COM Cc: bob@icx.com, ibis@vhdl.org, si-list@silab.eng.sun.com In-Reply-To: <9509010205.AA14506@oahu.FirePower.COM> (uunet!FirePower.COM!fvance) Subject: Re: On Non-Monotonic Drivers I am pretty sure that Miller effect is an at-speed effect and so would not be seen in a DC IV curve.(though it is still an important issue) Or was that the Budweiser effect? jon From jbrennan@VNET.IBM.COM Fri Sep 1 10:00:37 1995 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19582; Fri, 1 Sep 95 10:00:37 PDT Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3224; Fri, 01 Sep 95 12:53:37 EDT Received: by BTV (XAGENTA 4.0) id 9810; Fri, 1 Sep 1995 12:53:31 -0400 Received: from eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) id ; Fri, 1 Sep 1995 12:53:33 -0400 Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) id AA19911; Fri, 1 Sep 1995 12:53:33 -0400 Message-Id: <9509011653.AA19911@btv.ibm.com> To: ibis@vhdl.org Cc: jbrennan@btv.ibm.com Subject: Re: Re[2]: On Non-Monotonic Drivers In-Reply-To: Your message of Fri, 01 Sep 1995 08:08:00 PDT. Date: Fri, 01 Sep 1995 12:53:32 -0400 From: "John Brennan" To the first order you can assume it is instantaneous. Thanks, John Brennan ************************************************************************ John Brennan Internal: jbrennan@btv IBM Microelectronics Internet: jbrennan@vnet.ibm.com 862C / 1000 River Road Tel: 802-769-6982 (Tie-Line: 446) Essex Junction, VT 05452 Fax: 802-769-5882 (Tie-Line: 446) ************************************************************************ ------------------ Referenced E-Mail ---------------------------- Date: Fri, 01 Sep 1995 08:08:00 PDT To: fvance@FirePower.COM, bob@icx.com cc: ibis@vhdl.org, si-list@silab.eng.sun.com From: Arpad Muranyi Subject: Re[2]: On Non-Monotonic Drivers Message-Id: Text item: One example is one of IBM's process in which the shape of the I-V curve looks like the curve with the "*" vs. the normal shape shown with "-" (this is shown here with their permission). _ _----------------- * * * * * * * * * * * * * * * Even though IBM's circuit is not known to me, it seems that this can be achieve d by some kind of feedback. I agree with Jon Powell, it is important to know the timing characteristics of this feedback path, however, if it is "instantaneous" , I think it could be ignored. Arpad ============================================================================== Does anyone else have an example of a non-monotonic output buffer? Fred Vance 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: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re: On Non-Monotonic Drivers To: bob@icx.com ( Bob Ross) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 31 Aug 95 19:05:21 -0700 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA00780; Thu, 31 Aug 95 19:05:21 -0700 Message-Id: <9509010205.AA14506@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14506; Thu, 31 Aug 95 19:05:23 -0700 Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA15088; Thu, 31 Aug 95 19:05:26 -0700 Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARR N et) id AA09553; Thu, 31 Aug 95 19:13:34 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 31 Aug 95 1 9 :09:43 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soLY8-000tx9C; Thu, 31 Aug 95 19:09 PDT From huq@rockie.nsc.com Fri Sep 1 10:24:02 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19686; Fri, 1 Sep 95 10:24:02 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA11294 for ibis@vhdl.org; Fri, 1 Sep 95 10:17:11 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA05022 for ibis@vhdl.org; Fri, 1 Sep 95 10:17:08 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA11544; Fri, 1 Sep 95 10:19:53 PDT Date: Fri, 1 Sep 95 10:19:53 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9509011719.AA11544@rockie.nsc.com> To: ibis@vhdl.org Subject: FAQ#6 IBISgurus: Here is a re-worded #6, pls comment/suggest changes on the reflector. Thanks, Syed. 6.0 Can IBIS model SSO(Simultaneous Switching Output) ? IBIS as a model, has all the important parameters required to model an SSO event. These are mainly the package inductance, other associated parasitics and the number of buffers switching. IBIS specifies R, L and C in matrix format and the use of a matrix for the inductance accounts for the "loop"inductance i.e. the mutuals between the pins. Specifying the mutual inductance is necessary to account for SSO event simulation. [Pin Mapping] keyword was specifically defined in IBISv2.1 to handle SSO defination. Simulating SSO depends on the model provided and the simulator used. From sung.oh@tempe.vlsi.com Fri Sep 1 12:41:53 1995 Return-Path: Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20717; Fri, 1 Sep 95 12:41:53 PDT Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id MAA01252; Fri, 1 Sep 1995 12:44:43 -0700 From: sung.oh@tempe.vlsi.com Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id MAA10400; Fri, 1 Sep 1995 12:41:29 -0700 Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id LAA02262; Fri, 1 Sep 1995 11:50:11 -0700 Received: by sedona id AA02581; Fri, 1 Sep 95 11:52:10 MST Date: Fri, 1 Sep 95 11:52:10 MST Message-Id: <9509011852.AA02581@sedona> To: Arpad_Muranyi@ccm.fm.intel.com Subject: Re: Re[2]: On Non-Monotonic Drivers Cc: ibis@vhdl.org Arpad, It is a measured curve or a simulated one? SPICE simulations may have a negative resistance in the saturation region depending on velocity saturation parameters, which does not happen in real devices. Sung ----- Begin Included Message ----- From Arpad_Muranyi@ccm.fm.intel.com Fri Sep 1 08:43 MST 1995 Date: Fri, 01 Sep 95 08:08:00 PDT From: Arpad Muranyi To: fvance@FirePower.COM, bob@icx.com Cc: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re[2]: On Non-Monotonic Drivers Content-Type: text Content-Length: 2012 X-Lines: 54 Text item: One example is one of IBM's process in which the shape of the I-V curve looks like the curve with the "*" vs. the normal shape shown with "-" (this is shown here with their permission). _ _----------------- * * * * * * * * * * * * * * * Even though IBM's circuit is not known to me, it seems that this can be achieved by some kind of feedback. I agree with Jon Powell, it is important to know the timing characteristics of this feedback path, however, if it is "instantaneous", I think it could be ignored. Arpad ============================================================================== Does anyone else have an example of a non-monotonic output buffer? Fred Vance 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: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re: On Non-Monotonic Drivers To: bob@icx.com ( Bob Ross) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 31 Aug 95 19:05:21 -0700 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA00780; Thu, 31 Aug 95 19:05:21 -0700 Message-Id: <9509010205.AA14506@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14506; Thu, 31 Aug 95 19:05:23 -0700 Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA15088; Thu, 31 Aug 95 19:05:26 -0700 Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRN et) id AA09553; Thu, 31 Aug 95 19:13:34 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 31 Aug 95 19 :09:43 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soLY8-000tx9C; Thu, 31 Aug 95 19:09 PDT ----- End Included Message ----- From contec!contec.contec.COM!dileep@netcom.com Fri Sep 1 13:29:28 1995 Return-Path: Received: from netcomsv.netcom.com (uucp6.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20962; Fri, 1 Sep 95 13:29:28 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id NAA16522; Fri, 1 Sep 1995 13:07:11 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA18199; Fri, 1 Sep 95 09:05:30 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA03147; Fri, 1 Sep 1995 09:08:05 +0800 Date: Fri, 1 Sep 1995 09:08:05 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9509011608.AA03147@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Non-Monotonic Drivers Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 642 > From Arpad_Muranyi@ccm.fm.intel.com Thu Aug 31 17:11:11 1995 > To: ibis@vhdl.org > Cc: dileep@contec.contec.COM > Subject: Re: Non-Monotonic Drivers > Content-Length: 3139 > X-Lines: 88 > > > Text item: > > Dileep, > > I tend to agree. I am just curious which tool you are referring to. > Would you be able to disclose that info to us? > > Arpad > ========================================================================== > I did not want to specify any names, but now since the question has been asked, I was referring to ContecSPICE, which is the simulator used by ContecSI, Contec's signal integrity analysis software. Dileep From contec!contec.contec.COM!dileep@netcom.com Fri Sep 1 13:31:24 1995 Return-Path: Received: from netcomsv.netcom.com (uucp6.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21012; Fri, 1 Sep 95 13:31:24 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id NAA16531; Fri, 1 Sep 1995 13:07:23 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA18385; Fri, 1 Sep 95 09:21:06 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA03157; Fri, 1 Sep 1995 09:23:40 +0800 Date: Fri, 1 Sep 1995 09:23:40 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9509011623.AA03157@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Non-Monotonic Drivers Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 1920 > From uunet!qdt.com!jonp@uunet.uu.net Thu Aug 31 18:34:09 1995 > To: uunet!uunet!contec.contec.COM!dileep@uunet.uu.net > Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, > uunet!uunet!prodigy.com!EGJJ77A@uunet.uu.net, > uunet!uunet!vnet.ibm.com!jbrennan@uunet.uu.net, > uunet!uunet!contec.contec.COM!dileep@uunet.uu.net > Subject: Re: Non-Monotonic Drivers > Content-Length: 1279 > X-Lines: 30 > > I disagree with this accessment. Unless the feedback speed > of the path is known an accurate guess cannot be made as to > how to simulate the device. Of course, if the feedback path just > doesn't matter then it doesn't so much matter what you guess. > I would like us to explore a mechanism for behaviorally defining > this feedback path/speed. > > At the very outside, I have seen two different devices that had > non-monotonic IV curves that looked approximately the same at DC. > One had a feedback path that was 20ns (it was only used for changing > the long term DC operating point of the device) and another had a feedback > path that was "instantaneous". It is my claim that these two devices would > have different simulations even though they would have identical IBIS models. > > that is all. > > jon > > All I was saying is that if the DC non-monotonic IV table is speficied, that can be used for simulations. Since the model specifies only DC behavior, the simulator also can guarantee that it can reproduce only that DC behavior. If additional dynamic effects are desired from the simulations, then of course that information has to be provided. The sumulator is not supposed to do any guesswork. If a certain effect is specified in the model then that will be reflected in the simulations. If ONLY dc information is provided, then comparison of dynamic effects is meaningless, but that does not mean that the available DC information cannot and/or should not be used. Dileep From sung.oh@tempe.vlsi.com Fri Sep 1 13:39:07 1995 Return-Path: Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21043; Fri, 1 Sep 95 13:39:07 PDT Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id NAA02449; Fri, 1 Sep 1995 13:42:15 -0700 From: sung.oh@tempe.vlsi.com Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id NAA10833; Fri, 1 Sep 1995 13:38:48 -0700 Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id MAA02598; Fri, 1 Sep 1995 12:41:44 -0700 Received: by sedona id AA02589; Fri, 1 Sep 95 12:43:43 MST Date: Fri, 1 Sep 95 12:43:43 MST Message-Id: <9509011943.AA02589@sedona> To: huq@rockie.nsc.com Subject: Re: FAQ#6 Cc: ibis@vhdl.org Syed, Like I said in the meeting, IBIS does not have ALL the important parameters to model SSO noise. IBIS do have some of them, but not ALL of them. Taking double derivative of output waveform and multiplying output load capacitance and parasitic inductance would generate the ground bounce. However, this process would overestimate the ground bounce because of input gate modulation effect (negative feedback); when ground node becomes higher from ground level, the gate to source voltage of an output driver becomes small resulting in less current flowing into the inductor, which in turn reduce the ground bounce. Therefore, to perform SSO noise simulation, the input transition time of output buffers should be defined in the model. Also the on-chip capacitor between power lines should be included. Without those informations, I am afraid that the simulation result would be GIGO (Garbage In, Garbage Out). At the second line from the bottom, SSO defination should read definition. If you need more information, you can contact me at (602)752-6263. Best regards, Sung >>From huq@rockie.nsc.com Fri Sep 1 10:41 MST 1995 >>Date: Fri, 1 Sep 95 10:19:53 PDT >>From: huq@rockie.nsc.com (Syed Huq) >>To: ibis@vhdl.org >>Subject: FAQ#6 >>Content-Type >>: >>text >> >>Content-Length: 748 >>X-Lines: 23 >> >>IBISgurus: >> >>Here is a re-worded #6, pls comment/suggest changes on the >>reflector. >> >>Thanks, >>Syed. >> >> >>6.0 Can IBIS model SSO(Simultaneous Switching Output) ? >> >>IBIS as a model, has all the important parameters required to model an >>SSO event. These are mainly the package inductance, other associated >>parasitics and the number of buffers switching. IBIS specifies R, L and >>C in matrix format and the use of a matrix for the inductance accounts >>for the "loop"inductance i.e. the mutuals between the pins. Specifying >>the mutual inductance is necessary to account for SSO event simulation. >> >>[Pin Mapping] keyword was specifically defined in IBISv2.1 to handle >>SSO defination. Simulating SSO depends on the model provided and the >>simulator used. >> >> >> From Arpad_Muranyi@ccm.fm.intel.com Fri Sep 1 16:51:18 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22292; Fri, 1 Sep 95 16:51:18 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sofko-000UiAC; Fri, 1 Sep 95 16:44 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sofkn-000twyC; Fri, 1 Sep 95 16:44 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Fri, 01 Sep 95 16:44:09 PDT Date: Fri, 01 Sep 95 16:39:00 PDT From: Arpad Muranyi Message-Id: To: sung.oh@tempe.vlsi.com Cc: ibis@vhdl.org Subject: Re[4]: On Non-Monotonic Drivers Text item: Sung, I was told that this is the curve that you would get in the lab if you swept the device with a programmable DC supply and measured the current at each voltage point. Arpad ============================================================================== Arpad, It is a measured curve or a simulated one? SPICE simulations may have a negative resistance in the saturation region depending on velocity saturation parameters, which does not happen in real devices. Sung Text item: One example is one of IBM's process in which the shape of the I-V curve looks like the curve with the "*" vs. the normal shape shown with "-" (this is shown here with their permission). _ _----------------- * * * * * * * * * * * * * * * Even though IBM's circuit is not known to me, it seems that this can be achieved by some kind of feedback. I agree with Jon Powell, it is important to know the timing characteristics of this feedback path, however, if it is "instantaneous" , I think it could be ignored. Arpad ============================================================================== Does anyone else have an example of a non-monotonic output buffer? Fred Vance 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: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re: On Non-Monotonic Drivers To: bob@icx.com ( Bob Ross) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 31 Aug 95 19:05:21 -0700 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA00780; Thu, 31 Aug 95 19:05:21 -0700 Message-Id: <9509010205.AA14506@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14506; Thu, 31 Aug 95 19:05:23 -0700 Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA15088; Thu, 31 Aug 95 19:05:26 -0700 Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARR N et) id AA09553; Thu, 31 Aug 95 19:13:34 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 31 Aug 95 19 :09:43 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soLY8-000tx9C; Thu, 31 Aug 95 19:09 PDT ----- End Included Message ----- 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: ibis@vhdl.org Subject: Re: Re[2]: On Non-Monotonic Drivers To: Arpad_Muranyi@ccm.fm.intel.com Message-Id: <9509011852.AA02581@sedona> Date: Fri, 1 Sep 95 11:52:10 MST Received: by sedona id AA02581; Fri, 1 Sep 95 11:52:10 MST Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vl si.com (8.6.9/Hub-Perlotto/032095) with SMTP id LAA02262; Fri, 1 Sep 1995 11:50: 11 -0700 Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by re layhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id MAA10400; Fri, 1 Sep 1995 12:41:29 -0700 From: sung.oh@tempe.vlsi.com Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8 .6.12/Hub-Perlotto/050895) with ESMTP id MAA01252; Fri, 1 Sep 1995 12:44:43 -070 0 Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4. 1/BARRNet) id AA20717; Fri, 1 Sep 95 12:41:53 PDT Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Fri, 1 Sep 95 12: 45:32 -0700 Received: from aurora.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soc1t-000txGC; Fri, 1 Sep 95 12:45 PDT From mjohnson@netcom.com Fri Sep 1 17:32:39 1995 Return-Path: Received: from netcom2.netcom.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22540; Fri, 1 Sep 95 17:32:39 PDT Received: by netcom2.netcom.com (8.6.12/Netcom) id RAA23496; Fri, 1 Sep 1995 17:22:58 -0700 Date: Fri, 1 Sep 1995 17:22:58 -0700 From: mjohnson@netcom.com (Mark Johnson) Message-Id: <199509020022.RAA23496@netcom2.netcom.com> To: ibis@vhdl.org, si-list@silab.Eng.Sun.COM Subject: HERE IS: published circuit of non-monotonic output driver The schematic diagram of an output buffer which displays non monotonicity (measured at low frequencies, for example in a direct current I-V plot), is published in the following paper: J. Petrovik et al, "A 300k-Circuit ASIC Logic Family", 1990 International Solid State Circuits Conference, Digest of Technical Papers ("ISSCC-90"), pp. 88-89. Figure 6 of that paper shows a remarkably clever output driver circuit which compensates for process variations, supply voltage variations, and temperature variations. It performs this compensation better than any other circuit I've ever seen. (Quiz: but there's a cost; find the cost. Hint: it starts with the letter "p") If you put this output buffer on your curve tracer to measure the I-V curves, AND if you took more than 10 nanoseconds to move from one point on the curve to another point (i.e. if the A/D converter inside your curve tracer needs more than 10ns to settle), then you would see the exact I-V curve that Arpad Muranyi drew: > > * > * * > * * * * * * * * * > * > * > * > The region where the slope of the I-V curve goes negative (an incremental *negative resistance*, not usually felt to be the greatest thing in the world to hook up to a transmission line), is caused by the compensation circuitry. As Arpad hypothesized, there is indeed feedback in this output driver circuit. And, oh by the way, the circuit is symmetric; it has negative resistance in both its IOH-VOH curve and also in its IOL-VOL curve. Take a look at Figure 6 of the paper. Better yet, put it in your local SPICE simulator and simulate it "at speed" (transient) and also simulate a DC transfer curve. Don't believe me, I'm some random guy you've never met. Don't believe this message, it's just phosphor dots dancing on your CRT. Be self sufficient, try it yourself and make up your own mind. There are two $64,000 questions: 1. Does anybody actually _use_ circuits like Figure 6 in real products? 2. When you run the thing at full speed (transient analysis), does it work OK? Final remark: the authors of this paper were from "IBM General Technology Division, Essex Junction, Vermont, USA". --Mark Johnson From sung.oh@tempe.vlsi.com Fri Sep 1 17:26:18 1995 Return-Path: Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22478; Fri, 1 Sep 95 17:26:18 PDT Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id RAA07580; Fri, 1 Sep 1995 17:29:38 -0700 From: sung.oh@tempe.vlsi.com Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id RAA12435; Fri, 1 Sep 1995 17:18:49 -0700 Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id RAA04561; Fri, 1 Sep 1995 17:16:16 -0700 Received: by sedona id AA02636; Fri, 1 Sep 95 17:18:00 MST Date: Fri, 1 Sep 95 17:18:00 MST Message-Id: <9509020018.AA02636@sedona> To: Arpad_Muranyi@ccm.fm.intel.com Subject: Re: Re[4]: On Non-Monotonic Drivers Cc: ibis@vhdl.org Arpad, Then you are right. The circuit must be using a feedback. There is a circuit which turns on additional drivers when the output voltage reaches one voltage level and turns off the drivers when the output reaches another voltage level. In this case, the output current increases and then decreases as the output voltage changes. Eventually, we will see more circuits which employ some feedback mechanism in the future for various reasons. Anyway, it might not be easy to model this kind of circuits with present form of IBIS models unless we provide something like a feedback delay time. Goodluck. Sung ----- Begin Included Message ----- From Arpad_Muranyi@ccm.fm.intel.com Fri Sep 1 16:50 MST 1995 Date: Fri, 01 Sep 95 16:39:00 PDT From: Arpad Muranyi To: sung.oh@tempe.vlsi.com cc: ibis@vhdl.org Subject: Re[4]: On Non-Monotonic Drivers Content-Type: text Content-Length: 3862 X-Lines: 112 Text item: Sung, I was told that this is the curve that you would get in the lab if you swept the device with a programmable DC supply and measured the current at each voltage point. Arpad ============================================================================== Arpad, It is a measured curve or a simulated one? SPICE simulations may have a negative resistance in the saturation region depending on velocity saturation parameters, which does not happen in real devices. Sung Text item: One example is one of IBM's process in which the shape of the I-V curve looks like the curve with the "*" vs. the normal shape shown with "-" (this is shown here with their permission). _ _----------------- * * * * * * * * * * * * * * * Even though IBM's circuit is not known to me, it seems that this can be achieved by some kind of feedback. I agree with Jon Powell, it is important to know the timing characteristics of this feedback path, however, if it is "instantaneous" , I think it could be ignored. Arpad ============================================================================== Does anyone else have an example of a non-monotonic output buffer? Fred Vance 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: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re: On Non-Monotonic Drivers To: bob@icx.com ( Bob Ross) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 31 Aug 95 19:05:21 -0700 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA00780; Thu, 31 Aug 95 19:05:21 -0700 Message-Id: <9509010205.AA14506@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14506; Thu, 31 Aug 95 19:05:23 -0700 Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA15088; Thu, 31 Aug 95 19:05:26 -0700 Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARR N et) id AA09553; Thu, 31 Aug 95 19:13:34 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 31 Aug 95 19 :09:43 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soLY8-000tx9C; Thu, 31 Aug 95 19:09 PDT ----- End Included Message ----- 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: ibis@vhdl.org Subject: Re: Re[2]: On Non-Monotonic Drivers To: Arpad_Muranyi@ccm.fm.intel.com Message-Id: <9509011852.AA02581@sedona> Date: Fri, 1 Sep 95 11:52:10 MST Received: by sedona id AA02581; Fri, 1 Sep 95 11:52:10 MST Received: from sedona (sedona.tempe.vlsi.com [134.27.89.68]) by pcdmail.tempe.vl si.com (8.6.9/Hub-Perlotto/032095) with SMTP id LAA02262; Fri, 1 Sep 1995 11:50: 11 -0700 Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.89.15]) by re layhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id MAA10400; Fri, 1 Sep 1995 12:41:29 -0700 From: sung.oh@tempe.vlsi.com Received: from relayhost.tempe.vlsi.com ([180.0.26.63]) by relayhost.vlsi.com (8 .6.12/Hub-Perlotto/050895) with ESMTP id MAA01252; Fri, 1 Sep 1995 12:44:43 -070 0 Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4. 1/BARRNet) id AA20717; Fri, 1 Sep 95 12:41:53 PDT Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Fri, 1 Sep 95 12: 45:32 -0700 Received: from aurora.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soc1t-000txGC; Fri, 1 Sep 95 12:45 PDT ----- End Included Message ----- From nihat@mucsun.sps.mot.com Tue Sep 5 04:37:34 1995 Return-Path: Received: from spsgate.sps.mot.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07029; Tue, 5 Sep 95 04:37:34 PDT Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA00774 for ibis@vhdl.org; Tue, 5 Sep 95 04:30:40 MST Received: from emailmesa by mogate (4.1/SMI-4.1/Email-2.0) id AA17901; Tue, 5 Sep 95 04:30:39 MST Received: from nihoa.suedsee by mucsun.suedsee (4.1/SMI-4.1) id AA09015; Tue, 5 Sep 95 13:31:20 +0200 Date: Tue, 5 Sep 95 13:31:20 +0200 From: nihat@mucsun.sps.mot.com (Nihat Cabuk) Message-Id: <9509051131.AA09015@mucsun.suedsee> To: ibis@vhdl.org Subject: unsubscribe Please delete my name from the subscription list. Thanks. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Nihat Çabuk _/ _/ Sen. Staff Eng. Tel.: +49 89 92 103 399 _/ _/ Motorola GmbH Fax.: +49 89 92 103 150 _/ _/ ASIC _/ _/ Schatzbogen 7 e-mail: nihat@mucsun.sps.mot.com _/ _/ 81829 Muenchen or ttg538@email.sps.mot.com _/ _/ Germany _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From jbrennan@VNET.IBM.COM Tue Sep 5 04:52:08 1995 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07100; Tue, 5 Sep 95 04:52:08 PDT Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1545; Tue, 05 Sep 95 07:45:03 EDT Received: by BTV (XAGENTA 4.0) id 0315; Tue, 5 Sep 1995 07:45:00 -0400 Received: from eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) id ; Tue, 5 Sep 1995 07:43:56 -0400 Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) id AA29451; Tue, 5 Sep 1995 07:43:56 -0400 Message-Id: <9509051143.AA29451@btv.ibm.com> To: sung.oh@tempe.vlsi.com Cc: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: Re: Re[2]: On Non-Monotonic Drivers In-Reply-To: Your message of Fri, 01 Sep 1995 11:52:10 MST. <9509011852.AA02581@sedona> Date: Tue, 05 Sep 1995 07:43:55 -0400 From: "John Brennan" The points are simulated, but hardware measurements have confirmed this characteristic in real hardware. Each point on the curve is DC. ************************************************************************ John Brennan Internal: jbrennan@btv IBM Microelectronics Internet: jbrennan@vnet.ibm.com 862C / 1000 River Road Tel: 802-769-6982 (Tie-Line: 446) Essex Junction, VT 05452 Fax: 802-769-5882 (Tie-Line: 446) ************************************************************************ ------------------ Referenced E-Mail ---------------------------- Date: Fri, 01 Sep 1995 11:52:10 MST To: Arpad_Muranyi@ccm.fm.intel.com cc: ibis@vhdl.org From: sung.oh@tempe.vlsi.com Subject: Re: Re[2]: On Non-Monotonic Drivers Message-Id: <9509011852.AA02581@sedona> Arpad, It is a measured curve or a simulated one? SPICE simulations may have a negative resistance in the saturation region depending on velocity saturation parameters, which does not happen in real devices. Sung ----- Begin Included Message ----- >From Arpad_Muranyi@ccm.fm.intel.com Fri Sep 1 08:43 MST 1995 Date: Fri, 01 Sep 95 08:08:00 PDT From: Arpad Muranyi To: fvance@FirePower.COM, bob@icx.com Cc: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re[2]: On Non-Monotonic Drivers Content-Type: text Content-Length: 2012 X-Lines: 54 Text item: One example is one of IBM's process in which the shape of the I-V curve looks like the curve with the "*" vs. the normal shape shown with "-" (this is shown here with their permission). _ _----------------- * * * * * * * * * * * * * * * Even though IBM's circuit is not known to me, it seems that this can be achieve d by some kind of feedback. I agree with Jon Powell, it is important to know the timing characteristics of this feedback path, however, if it is "instantaneous" , I think it could be ignored. Arpad ============================================================================== Does anyone else have an example of a non-monotonic output buffer? Fred Vance 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: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re: On Non-Monotonic Drivers To: bob@icx.com ( Bob Ross) Received: by NeXT Mailer (1.99.1) Received: by NeXT.Mailer (1.99.1) Date: Thu, 31 Aug 95 19:05:21 -0700 Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA00780; Thu, 31 Aug 95 19:05:21 -0700 Message-Id: <9509010205.AA14506@oahu.FirePower.COM> From: Fred Vance Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14506; Thu, 31 Aug 95 19:05:23 -0700 Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA15088; Thu, 31 Aug 95 19:05:26 -0700 Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARR N et) id AA09553; Thu, 31 Aug 95 19:13:34 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 31 Aug 95 1 9 :09:43 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0soLY8-000tx9C; Thu, 31 Aug 95 19:09 PDT ----- End Included Message ----- From speters@ichips.intel.com Tue Sep 5 08:30:04 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08314; Tue, 5 Sep 95 08:30:04 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 5 Sep 95 08:22:54 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 5 Sep 95 08:22:48 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 5 Sep 95 08:22:48 PDT Message-Id: <9509051522.AA28335@xtg801.intel.com> To: Fabian_Wai_Lee_Kung@ccm.ipn.intel.com Cc: si-list@silab.Eng.Sun.COM, ibis@vhdl.org Subject: Buffer/Driver modelling Date: Tue, 05 Sep 1995 08:22:46 -0700 From: Stephen Peters Hello Fabian: I've forwared your inquire to the IBIS reflector in case someone wants to respond in more detail, but the short answer to your question is yes. It is possible to model an I/O buffer using the I-V curves and output transition time and that is exactly what IBIS modeling is all about. For an overview of IBIS, a cookbook on IBIS modeling, and a copy of the spec itself anonymous ftp to the vhdl.org machine (IP address 198.31.14.3) and look in the /pub/ibis directory. Hope this helps. Regards, Stephen Peters Intel Corp. Hi, Came across lots of discussion on buffer simulation lately, have some questions which I hope somebody can educate me. 1.) Can we model a buffer based on gross device information such as the I-V curve? Any other information required ? For instance output impedance versus loading, slew rate of pulse versus loading etc. This approach of modelling a buffer using circuit elements based on device ouput characteristic is very attractive as it is fast and easy to implement, compare to constructing a complete buffer circuit using transistors/FETs. 2.) What is IBIS format ? thanks & regards Fabian From speters@ichips.intel.com Tue Sep 5 11:13:13 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09437; Tue, 5 Sep 95 11:13:13 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Tue, 5 Sep 95 11:06:15 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Tue, 5 Sep 95 11:05:54 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Tue, 5 Sep 95 11:05:54 PDT Message-Id: <9509051805.AA29003@xtg801.intel.com> To: ibis@vhdl.org Subject: Bird 28 and sign on matrix data Date: Tue, 05 Sep 1995 11:05:52 -0700 From: Stephen Peters Hello All: The question has been asked about the 'proper' way to treat the sign of the off diagonal elements in the coupling matrixes defined in IBIS. As both Eric Bracken and Dileep Divekar have rightly pointed out, the sign of the off diagonal element is negative. However, Bird 28 specifies that the value should be entered as a positive number. I did this because the CAD programs I have delt with output their coupling matrixes this way. I have no objection to specifing negative values but I would like to get the simulator vendor's input. Is there some technical reason that the off diagonal elements NEED to be specfied one way or the other? Just asking.... Regards, Stephen Peters From ventham@quantic.mb.ca Tue Sep 5 13:30:39 1995 Return-Path: Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10675; Tue, 5 Sep 95 13:30:39 PDT Received: by access.mbnet.mb.ca with UUCP id AA25589 (5.67b/IDA-1.4.4 for ibis@vhdl.org); Tue, 5 Sep 1995 15:21:16 -0500 Received: by quantic.mb.ca (4.1/SMI-4.1) id AA15319; Tue, 5 Sep 95 15:22:50 CDT From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9509052022.AA15319@quantic.mb.ca> Subject: Re: Bird 28 and sign on matrix data To: speters@ichips.intel.com (Stephen Peters) Date: Tue, 5 Sep 95 15:22:49 CDT Cc: ibis@vhdl.org In-Reply-To: <9509051805.AA29003@xtg801.intel.com>; from "Stephen Peters" at Sep 5, 95 11:05 am X-Mailer: ELM [version 2.3 PL11] > > Hello All: > > The question has been asked about the 'proper' way to > treat the sign of the off diagonal elements in the coupling > matrixes defined in IBIS. As both Eric Bracken and Dileep > Divekar have rightly pointed out, the sign of the off diagonal > element is negative. However, Bird 28 specifies that the > value should be entered as a positive number. I did this because > the CAD programs I have delt with output their coupling matrixes this > way. I have no objection to specifing negative values but I would > like to get the simulator vendor's input. Is there some technical > reason that the off diagonal elements NEED to be specfied one way > or the other? Just asking.... > > Regards, > Stephen Peters > > We typically display off-diagonal capacitances as negative for the same reasons as the others. When mapping them into a SPICE subcircuit we do, of course, have to map them into positive as SPICE is not too hot on negative things. In the case of IBIS we will treat them as the specification defines them and polarise them to whatever sign is appropriate for the application. So the answer is yes and no. Regards Mike +======================================================================+ | Mike Ventham - Vice President Engineering, Quantic Laboratories Inc, | | 12th Floor, 191 Lombard Ave, Winnipeg, Manitoba, Canada R3B 0X1 | | Tel: (204) 942 4000 Fax: (204) 957 1158 Email: ventham@quantic.mb.ca | +======================================================================+ From mbs@eos.ncsu.edu Wed Sep 6 07:41:22 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22674; Wed, 6 Sep 95 07:41:22 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA05354; Wed, 6 Sep 1995 10:34:27 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509061434.AA05354@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS Date: Wed, 06 Sep 95 10:34:26 EDT The S2IBIS release date is September 11. Code will be placed in /pub/ibis/s2ibis and email will be posted. S2IBIS is running well and we need to finish the man pages finalize the default sweep values. Defining the ECL supply voltage sweep is causing us a problem but with Bob Ross's help I think that this issue will be resolved today. The S2IBIS team North Carolina State University From bob@icx.com Wed Sep 6 09:57:56 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23747; Wed, 6 Sep 95 09:57:56 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Sep 95 09:50 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Sep 95 09:53 PDT Message-Id: Date: Wed, 6 Sep 95 09:53 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD30 Prog. Buffers Comment To Arpad, Malan, Stephen and IBIS Team: I would prefer to avoid the "Default" syntax associated with the [Model Selector] keyword. Here is the example of what is currently proposed: [Model selector] Progbuffer1 ABCD0123456789ABCDE0 ABCD0123456789ABCDE1 Default ABCD0123456789ABCDE2 ABCD0123456789ABCDE3 ABCD0123456789ABCDE4 | [Model selector] Progbuffer2 ABCD0123456789ABCDE0 Default ABCD0123456789ABCDE3 ABCD0123456789ABCDE4 ABCD0123456789ABCDE5 ABCD0123456789ABCDE6 I would prefer that the first model encountered is the default: [Model selector] Progbuffer1 ABCD0123456789ABCDE2 | the default ABCD0123456789ABCDE0 ABCD0123456789ABCDE1 ABCD0123456789ABCDE3 ABCD0123456789ABCDE4 | [Model selector] Progbuffer2 ABCD0123456789ABCDE3 | the default ABCD0123456789ABCDE0 ABCD0123456789ABCDE4 ABCD0123456789ABCDE5 ABCD0123456789ABCDE6 Comments could provide a description of the buffers if they are no clear from the name. An alternative is to have another column required column for describing such buffers, similar to "signal_name in the [Pin] keyword: [Model selector] Progbuffer1 | model name description ABCD0123456789ABCDE2 SS3.3 | the default ABCD0123456789ABCDE0 WS3.3 ABCD0123456789ABCDE1 WF3.3 ABCD0123456789ABCDE3 SF3.3 ABCD0123456789ABCDE4 SF3.3_OD | [Model selector] Progbuffer2 | model name description ABCD0123456789ABCDE3 SF3.3 | the default ABCD0123456789ABCDE0 WS3.3 ABCD0123456789ABCDE4 SF3.3_OD ABCD0123456789ABCDE5 SF5.0 ABCD0123456789ABCDE6 SF5.0 The description would not be standardized since there are many ways to differentiate models. The simulator could display the description and could optionally base a selection mechanism on the description. This syntax would then have two columns for each model for consistency. Bob Ross, Interconnectix, Inc. From uunet!qdt.com!jonp@uunet.uu.net Wed Sep 6 12:16:06 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24647; Wed, 6 Sep 95 12:16:06 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzgbc27907; Wed, 6 Sep 1995 15:08:50 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 6 Sep 1995 15:08:51 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00732; Wed, 6 Sep 95 11:40:02 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA14573; Wed, 6 Sep 95 11:40:01 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQzgba19334; Wed, 6 Sep 1995 14:37:16 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Wed, 6 Sep 1995 14:37:16 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00693; Wed, 6 Sep 95 11:21:34 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA14506; Wed, 6 Sep 95 11:21:33 PDT Date: Wed, 6 Sep 95 11:21:33 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9509061821.AA14506@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA29025; Wed, 6 Sep 95 11:21:32 PDT To: uunet!uunet!icx.com!bob@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: (uunet!icx.com!bob) Subject: Re: BIRD30 Prog. Buffers Comment How does one control the selection of the various buffer types? It seems that it would be important to provide a mechanism that allows simple programmable selection of output types. If this is not provided then the user will be forced to create a unique IBIS file that has the actual model mapping that was decided. Even if you "leave this up to the tool vendors" the user will still have to, effectively, create their own pin map file. regards, jon From bob@icx.com Wed Sep 6 13:05:18 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24963; Wed, 6 Sep 95 13:05:18 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Sep 95 12:57 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Sep 95 13:00 PDT Message-Id: Date: Wed, 6 Sep 95 13:00 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, jonp@qdt.com Subject: Re: BIRD30 Prog. Buffers Comment Jon: My view is that the selection of various buffer types would be done through a user interface extension for the simulator. It could be directly based on model names associated with the [Model Selector] name or by some other method based on using the description information. The user would have to set up the mapping if it differs from the default. The default pin mapping will be set up. The user would have to modify the IBIS file to change the default mapping. Any non-default mapping selection done within the IBIS file would require editing the file. Therefore the selection method needs to be external to the IBIS file. I do not know of any way to standardize on this for a variety of whatif and semiautomatic selection applications. Bob Ross, Interconnectix, Inc. > How does one control the selection of the various buffer types? > It seems that it would be important to provide a mechanism that allows > simple programmable selection of output types. If this is not provided then > the user will be forced to create a unique IBIS file that has the actual model > mapping that was decided. Even if you "leave this up to the tool vendors" the > user will still have to, effectively, create their own pin map file. > regards, > jon From brockh@mdhost.cse.TEK.COM Wed Sep 6 15:06:30 1995 Return-Path: Received: from inet1.tek.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25837; Wed, 6 Sep 95 15:06:30 PDT Received: by inet1.tek.com id ; Wed, 6 Sep 1995 15:00:10 -0700 Received: from tektronix.tek.com(134.62.48.24) by inet1 via smap (V1.3) id sma017322; Wed Sep 6 14:58:10 1995 Received: from mdhost.cse.tek.com (tekadm1.cse.tek.com) by tektronix.TEK.COM (4.1/8.2) id AA02729; Wed, 6 Sep 95 14:57:02 PDT Received: from salope.CSE.TEK.COM by mdhost.cse.tek.com (4.1/8.1) id AA28758; Wed, 6 Sep 95 14:57:32 PDT Received: from localhost.TEK by salope.CSE.TEK.COM (4.1/8.0) id AA05401; Wed, 6 Sep 95 14:57:32 PDT Message-Id: <9509062157.AA05401@salope.CSE.TEK.COM> From: brockh@mdhost.cse.TEK.COM To: bob@icx.COM ( Bob Ross) Cc: ibis@vhdl.org, jonp@qdt.COM, brockh@mdhost.CSE.TEK.COM Subject: Re: BIRD30 Prog. Buffers Comment In-Reply-To: Your message of Wed, 06 Sep 95 13:00:00 -0700. Date: Wed, 06 Sep 95 14:57:31 PDT Sender: brockh@mdhost.cse.TEK.COM Hi Bob, Jon and Ibisans, As you may recall from the BOF meeting at DAC this topic of different strength, speed, you name it, I/O cells is a topic that has been troublesome already to me in my short time applying IBIS modeling to real world designs.. I think that the mechanism proposed in Bob's last posting works if the simulator UI's can be coerced into it. I like this one: Bob sezz.., >Comments could provide a description of the buffers if they are no clear >from the name. An alternative is to have another column required column >for describing such buffers, similar to "signal_name in the [Pin] keyword: > >The description would not be standardized since there are many ways to >differentiate models. The simulator could display the description and >could optionally base a selection mechanism on the description. This >syntax would then have two columns for each model for consistency. If I understand this correctly the way to use this is as follows: (I pirate freely from Bob's post) [Component] PROGRAMMED_PART [Manufacturer] [Package] | variable typ min max R_pkg 0.0m NA NA L_pkg 0.0nH NA NA C_pkg 0.0pF NA NA | |*************************************************************** | [Pin] signal_name model_name R_pin L_pin C_pin 1 OUT_1 Progbuffer2 2 OUT_2 Progbuffer1 3 OUT_3 Progbuffer2 4 OUT_4 Progbuffer1 | | [Model selector] Progbuffer1 | model name description ABCD0123456789ABCDE2 SS3.3 | the default ABCD0123456789ABCDE0 WS3.3 ABCD0123456789ABCDE1 WF3.3 ABCD0123456789ABCDE3 SF3.3 ABCD0123456789ABCDE4 SF3.3_OD | [Model selector] Progbuffer2 | model name description ABCD0123456789ABCDE3 SF3.3 | the default ABCD0123456789ABCDE0 WS3.3 ABCD0123456789ABCDE4 SF3.3_OD ABCD0123456789ABCDE5 SF5.0 ABCD0123456789ABCDE6 SF5.0 Of course a list of the models in IBIS syntax would follow. I would hope the simulator UI would bring up a list of the model names available for the given pin, complete with the description, so that the user would merely point and shoot at the desired model to be used for that particular simulation. I think the first one in the list after the [Model selector] should automatically be the default. Saves making more keywords. Am I in the ballpark on the usage model? I think this can work also for a "whatif" mechanism for ASIC's and glue logic too! One of the problems I have encountered is that currently if a [Model] isn't referenced by a [Component] then it doesn't get loaded and so is not available for "whatif" experiments(more than one vendor's sw exhibits this). This is a neat way around that. Thanks, Brock Hannibal HW Design Engineer Tektronix, Inc. From uunet!qdt.com!jonp@uunet.uu.net Wed Sep 6 16:44:56 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26391; Wed, 6 Sep 95 16:44:56 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQzgbu29792; Wed, 6 Sep 1995 19:37:58 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 6 Sep 1995 19:37:58 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01193; Wed, 6 Sep 95 16:16:50 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA16616; Wed, 6 Sep 95 16:16:50 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzgbt26589; Wed, 6 Sep 1995 19:15:21 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Wed, 6 Sep 1995 19:15:22 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01140; Wed, 6 Sep 95 15:58:01 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA16477; Wed, 6 Sep 95 15:58:00 PDT Date: Wed, 6 Sep 95 15:58:00 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9509062258.AA16477@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA29258; Wed, 6 Sep 95 15:57:59 PDT To: uunet!uunet!mdhost.cse.TEK.COM!brockh@uunet.uu.net Cc: uunet!uunet!icx.COM!bob@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: <9509062157.AA05401@salope.CSE.TEK.COM> (message from uunet!mdhost.cse.TEK.COM!brockh on Wed, 06 Sep 95 14:57:31 PDT) Subject: Re: BIRD30 Prog. Buffers Comment I guess I would like to tie the model into the physical selection mechanism. For instance, if the output strength is tied to the state of an input pin PROG I would like the user to be able to say PROG=1 and the IBIS model know what that means. This would mean that the [Model Selector] choices would be tied to selection values (Physical or Logical) If these things are programmed by JTAG shift registers, maybe we should use the JTAG input file description or some derivative. By the way, this only sounds complex, the implementation could be as simple as C #ifdef statements. What do the IC vendors have to say about strength selection? regards, jon From brockh@mdhost.cse.TEK.COM Wed Sep 6 17:42:20 1995 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26744; Wed, 6 Sep 95 17:42:20 PDT Received: from inet1.tek.com by relay2.UU.NET with SMTP id QQzgby08245; Wed, 6 Sep 1995 20:34:58 -0400 From: brockh@mdhost.cse.TEK.COM Received: by inet1.tek.com id ; Wed, 6 Sep 1995 17:35:24 -0700 Received: from tektronix.tek.com(134.62.48.24) by inet1 via smap (V1.3) id sma018321; Wed Sep 6 17:35:06 1995 Received: from mdhost.cse.tek.com (tekadm1.cse.tek.com) by tektronix.TEK.COM (4.1/8.2) id AA15377; Wed, 6 Sep 95 17:33:58 PDT Received: from salope.CSE.TEK.COM by mdhost.cse.tek.com (4.1/8.1) id AA16914; Wed, 6 Sep 95 17:34:30 PDT Received: from localhost.TEK by salope.CSE.TEK.COM (4.1/8.0) id AA05640; Wed, 6 Sep 95 17:34:28 PDT Message-Id: <9509070034.AA05640@salope.CSE.TEK.COM> To: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Cc: uunet!uunet!mdhost.cse.TEK.COM!brockh@uunet.uu.net, uunet!uunet!icx.COM!bob@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: BIRD30 Prog. Buffers Comment In-Reply-To: Your message of Wed, 06 Sep 95 15:58:00 -0700. <9509062258.AA16477@hal.qdt.com> Date: Wed, 06 Sep 95 17:34:28 PDT Sender: brockh@mdhost.cse.TEK.COM Hi guys, The problem with tying the selection of strength, speed, whatever to a physical thing on the part is that sometimes its an internal register that the board designer really has no visibility of. The software guys may program it, the part designer may have hardwired it through a fuse(PAL), the internal programming of the PLD may select it. It's hard to say what information about the part(if any) will tell us which [Model] to select. It would be nice if we had some kind of automatic selection but it doesn't appear to me that the appropriate information is available in the IBIS model or from the board database. A Verilog or VHDL simulation of the system might or might not contain the salient info. The software might contain the appropriate information, as might the firmware. I don't see a clear path to linking the analog I/O behavioral simulation to the logic simulation or the software/firmware. Brock Hannibal HW Design Engineer Tektronix, Inc. From speters@ichips.intel.com Wed Sep 6 18:14:10 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26932; Wed, 6 Sep 95 18:14:10 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 6 Sep 95 18:07:16 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 6 Sep 95 18:07:09 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 6 Sep 95 18:07:09 PDT Message-Id: <9509070107.AA15289@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD30 Date: Wed, 06 Sep 1995 18:07:08 -0700 From: Stephen Peters Hello Jon, FellowIBISans: I have to agree with Brock. There are so many ways that a buffer is selected (voltage on the VCC pins, state of a pin when reset goes away, etc.) that it would be very dificult to link that info into the IBIS file. As I said before, what I (as a user) want is a way to make a quick global default selection, then be able to select/change buffers on a pin by pin basis. I think this is best acomplished by a good user interface that the simulator vendor supplies. Regards, Stephen Peters Intel Corp. From hans_o@mucsun.sps.mot.com Thu Sep 7 04:31:24 1995 Return-Path: Received: from spsgate.sps.mot.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06358; Thu, 7 Sep 95 04:31:24 PDT Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA17741 for ibis@vhdl.org; Thu, 7 Sep 95 04:24:30 MST Received: from emailmesa by mogate (4.1/SMI-4.1/Email-2.0) id AA07449; Thu, 7 Sep 95 04:24:29 MST Received: from manua.suedsee by mucsun.suedsee (4.1/SMI-4.1) id AA18641; Thu, 7 Sep 95 13:25:13 +0200 Date: Thu, 7 Sep 95 13:25:13 +0200 From: hans_o@mucsun.sps.mot.com (Johann Oberhauser) Message-Id: <9509071125.AA18641@mucsun.suedsee> To: ibis@vhdl.org Subject: subscribe Hi, I would like to join the IBIS forum. Thanks, Hans _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ _/ Hans Oberhauser _/ _/ _/ Design Engineer _/ Tel.: +49-89-92103-257 _/ _/ Motorola GmbH _/ Fax.: +49-89-92103-150 _/ _/ High Performance ES _/ _/ _/ Schatzbogen 7 _/ e-mail: hans_o@mucsun.sps.mot.com _/ _/ 81829 Muenchen _/ or r14628@email.sps.mot.com _/ _/ Germany _/ _/ _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From schumach@flare.convex.com Thu Sep 7 06:39:12 1995 Return-Path: Received: from convex.convex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07012; Thu, 7 Sep 95 06:39:12 PDT Received: from flare.convex.com by convex.convex.com (8.6.4.2/1.35) id IAA07303; Thu, 7 Sep 1995 08:30:59 -0500 Received: from localhost by flare.convex.com (8.6.4/1.28) id IAA03715; Thu, 7 Sep 1995 08:30:56 -0500 Date: Thu, 7 Sep 1995 08:30:56 -0500 From: schumach@flare.convex.com (Richard A. Schumacher) Message-Id: <199509071330.IAA03715@flare.convex.com> To: ibis@vhdl.org, speters@ichips.intel.com Subject: Re: BIRD30 Agreed! Don't let IBIS bloat into a monster. Stick to basic functionality for the definition. Strength selection and whatnot are library management issues where the simulator software can add value. From bob@icx.com Thu Sep 7 12:08:39 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09005; Thu, 7 Sep 95 12:08:39 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Sep 95 12:01 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Sep 95 12:03 PDT Message-Id: Date: Thu, 7 Sep 95 12:03 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA SEPT 15, 1995 IBIS Open Forum Meeting Agenda for 9/15/95 Bridge Number Reservation # Passcode (916) 356-9200 1-16347 1272371 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 Hobbs - Intros of New IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Rusher/Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press Updates All - New Models Available, Library Update All - Opens for New Issues All 8:10 EIA IBIS Ratification - Action Items / Time Table for Final Draft Hobbs - Press Release Discussion Hobbs/Rusher 8:20 Administrative and Project Discussions Face-to-face meeting Hobbs Web Project Update Huq New Web Documents Approval (Vote) Huq Model Usage Tracking on vhdl.org Huq/Steer Golden Parser 2.1 Status Hobbs S2IBIS 2.1 Status Kumar/Steer Version 2.1 Cookbook and Overview Chrisafulli/Ross New Administrative Issues All 9:00 Technical Discussions Non-monotonic Drivers Christopher BIRD 30 - Pin Programmable Buffer Strengths Muranyi Egg 6 - CMOS and TTL Data Powell BIRD 27.1 - New Keyword for Differential I/O (defer) Ross BIRD 28.2 - Package Model Extension Peters Physical Package Description Discussion Crisafulli New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From EGJJ77A@mail.prodigy.com Sun Sep 10 21:16:27 1995 Return-Path: Received: from maily2.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19399; Sun, 10 Sep 95 21:16:27 PDT Received: from mail.prodigy.com (mail [199.4.137.13]) by maily2.prodigy.com (8.6.10/8.6.9) with SMTP id XAA43257; Sun, 10 Sep 1995 23:38:30 -0400 Date: Sun, 10 Sep 1995 23:50:35 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.01107521.EGJJ77A@prodigy.com> To: ibis@vhdl.org, roadmap-eii@cfi.org Subject: Fwd: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing Verification -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- I should have addressed these concerns/questions to the IBIS forum as well. In hierarchical processing involving ASIC chips, I recommend there be an IBIS model for each driver circuit and for each receiver circuit and a standard representation for the physical parasitics. If this is where we are going, then associating a single IBIS model with a component MCM pin (if I understand IBIS) seems questionable for the future?? My questions are illustrated in the referenced file. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Wednesday, 06-Sep-95 02:17 AM > > From: Ronald J Christoph \ Internet: (egjj77a@prodigy.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing > Verification > > I have put some timing verification methodology and standards concerns on > the relationships between the DCL delay calculation language, IBIS, and > DIET into a framemaker .mif file. The file is timever.mif at > ftp.cfi.org/incoming. > > I am sure it requires further explanation, or maybe someone has it all > resolved. > > Ron Christopher > > > ------- FORWARD, End of original message ------- From mbs@eos.ncsu.edu Tue Sep 12 19:34:02 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01736; Tue, 12 Sep 95 19:34:02 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA07020; Tue, 12 Sep 1995 22:27:03 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509130227.AA07020@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS'95 .... start Date: Tue, 12 Sep 95 22:27:03 EDT Actually version 2. S2IBIS2 has been released as beta code. S2IBIS2 supports the automatic generation of IBIS model given a SPICE model. All features of IBIS veriosn 2.1 are supported except for the package parameters which must be acquired by some other means. The code, documentation and compiled binaries for RS6000, DEC 3000/5000, HPUX, and SUN are available in pub/ibis/s2ibis/s2ibis_v2.0/s2ibis2.tar.Z The code and documentation only are available in pub/ibis/s2ibis/s2ibis_v2.0/s2ibis2.zip We do need a Microsoft windows version (3.x please) ... any volunteers? (It compiles using gnu tools so if these are used there should be no problems.) Send contribution to me and I will put them on vhdl.org The code has no known bugs. We will collect bug reports addressed to awglaser@eos.ncsu.edu. We hope to be able to correct bugs pending future support. Thanks go to CADENCE for their generous support of the S2IBIS2 development. Thanks to Bob Ross for his help in establishing voltage sweep ranges and ironing out the ECL supply ambiguity in the IBIS2.1 spec. Michael Steer IBIS LIBRARIAN on behalf of the S2IBIS development team Alan Glaser (a supper effort, he has a month of sleep to catch up on) Steve Lipa Michael Steer Paul Franzon North Carolina State University From mbs@eos.ncsu.edu Tue Sep 12 19:44:14 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01770; Tue, 12 Sep 95 19:44:14 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA07069; Tue, 12 Sep 1995 22:37:16 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509130237.AA07069@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS Date: Tue, 12 Sep 95 22:37:16 EDT I forgot to add. S2IBIS2 includes a nice liitle plotting utility that plots all of the waveforms in a *.ibs file. The code is wriiten in perl script, is not compiled, and uses gnuplot. Check it out. Michael Steer From mbs@eos.ncsu.edu Wed Sep 13 05:46:43 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10202; Wed, 13 Sep 95 05:46:43 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08714; Wed, 13 Sep 1995 08:39:43 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509131239.AA08714@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS2 Date: Wed, 13 Sep 95 08:39:42 EDT The version of S2IBIS that was copied to vhdl.org appears to be corrupted. We will need to reload it but this may not be till for a day. Sorry. I don't know how it happened. Michael Steer From bd25531@bingsuns.cc.binghamton.edu Wed Sep 13 10:50:21 1995 Return-Path: Received: from bingnet1.cc.binghamton.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12435; Wed, 13 Sep 95 10:50:21 PDT Received: from bingsuns.cc.binghamton.edu (bd25531@bingsuns.cc.binghamton.edu [128.226.1.2]) by bingnet1.cc.binghamton.edu (8.6.9/8.6.9) with ESMTP id NAA03804 for ; Wed, 13 Sep 1995 13:43:21 -0400 From: bd25531@bingsuns.cc.binghamton.edu Received: (from bd25531@localhost) by bingsuns.cc.binghamton.edu (8.6.12/8.6.9) id NAA09598 for ibis@vhdl.org; Wed, 13 Sep 1995 13:43:55 -0400 Message-Id: <199509131743.NAA09598@bingsuns.cc.binghamton.edu> Subject: V/I transition curves To: ibis@vhdl.org Date: Wed, 13 Sep 1995 13:43:54 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 423 Hi IBISians! According to the information in IBIS documents only one curve for Low and High states are given. Assuming that the device Low-High or High-Low transtion takes some time, the transition data would be neccessary, one way that I can think of is scaling the V/I curves for this purpose. I am looking for other ways to do this thing,so can any of you IBISians help me in this matter? Viva IBIS!! peivand From sung.oh@tempe.vlsi.com Wed Sep 13 11:51:27 1995 Return-Path: Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12895; Wed, 13 Sep 95 11:51:27 PDT Received: from relayhost.tempe.vlsi.com ([134.27.128.1]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id MAA07879; Wed, 13 Sep 1995 12:00:57 -0700 From: sung.oh@tempe.vlsi.com Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.130.2]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id LAA09484; Wed, 13 Sep 1995 11:50:49 -0700 Received: from sedona (sedona.tempe.vlsi.com [134.27.133.167]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id LAA26176; Wed, 13 Sep 1995 11:48:47 -0700 Received: by sedona id AA01692; Wed, 13 Sep 95 11:50:54 MST Date: Wed, 13 Sep 95 11:50:54 MST Message-Id: <9509131850.AA01692@sedona> To: bd25531@bingsuns.cc.binghamton.edu Subject: Re: V/I transition curves Cc: ibis@vhdl.org Peivand, This is actually a dead zone for IBIS modeling. IBIS modeling assumes fast input transtion. You can scale the I/V curve with respect to the input rise/fall time only if you have short-channel MOSFET devices for your output drivers. Slow input transition alters the knee voltage at the driver output. Also it affects rising/falling characteristics at the driver. These changes are not significant unless you have an extraordinary long input transition time. There certainly are trade-offs between accuracy and speed in simulation models, which limit IBIS modeling capability in some applications. Regrads, Sung Oh VLSI Technology, Inc. >>From bd25531@bingsuns.cc.binghamton.edu Wed Sep 13 11:15 MST 1995 >>From: bd25531@bingsuns.cc.binghamton.edu >>Subject: V/I transition curves >>To: ibis@vhdl.org >>Date: Wed, 13 Sep 1995 13:43:54 -0400 (EDT) >>X-Mailer: ELM [version 2.4 PL24] >>Mime-Version: 1.0 >>Content-Transfer-Encoding: 7bit >>Content-Type >>: >>text/plain >>; >>charset=US-ASCII >> >>Content-Length: 423 >>X-Lines: 13 >> >>Hi IBISians! >>According to the information in IBIS documents only one curve for >>Low and High states are given. Assuming that the device Low-High or >>High-Low transtion takes some time, the transition data would be >>neccessary, one way that I can think of is scaling the V/I curves >>for this purpose. I am looking for other ways to do this thing,so >>can any of you IBISians help me in this matter? >> >>Viva IBIS!! >> >>peivand >> >> >> From uunet!qdt.com!jonp@uunet.uu.net Wed Sep 13 14:14:58 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13737; Wed, 13 Sep 95 14:14:58 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzhbg12662; Wed, 13 Sep 1995 17:07:58 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 13 Sep 1995 17:07:58 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00994; Wed, 13 Sep 95 13:40:13 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA15669; Wed, 13 Sep 95 13:40:13 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzhay10680; Wed, 13 Sep 1995 15:12:04 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Wed, 13 Sep 1995 15:12:04 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00842; Wed, 13 Sep 95 11:36:40 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA15305; Wed, 13 Sep 95 11:36:40 PDT Date: Wed, 13 Sep 95 11:36:40 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9509131836.AA15305@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA00109; Wed, 13 Sep 95 11:36:39 PDT To: uunet!uunet!bingsuns.cc.binghamton.edu!bd25531@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: <199509131743.NAA09598@bingsuns.cc.binghamton.edu> (message from uunet!bingsuns.cc.binghamton.edu!bd25531 on Wed, 13 Sep 1995 13:43:54 -0400 (EDT)) Subject: Re: V/I transition curves >>Hi IBISians! >>According to the information in IBIS documents only one curve for >>Low and High states are given. Assuming that the device Low-High or >>High-Low transtion takes some time, the transition data would be >>neccessary, one way that I can think of is scaling the V/I curves >>for this purpose. I am looking for other ways to do this thing,so >>can any of you IBISians help me in this matter? >> >>Viva IBIS!! >> >>peivand The transistion information is meant to be inherent in the AC rising and falling T/V curves that are in the 2.1 spec. By looking at how the device drives different loads you can calculate the IV transition shape. For devices without AC data (ie. v1.1 models) you have to assume standard CMOS/TTL transistor behavior. jonp From Arpad_Muranyi@ccm.fm.intel.com Wed Sep 13 14:38:26 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13945; Wed, 13 Sep 95 14:38:26 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sszOb-000UgXC; Wed, 13 Sep 95 14:31 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sszOa-000tx3C; Wed, 13 Sep 95 14:31 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Wed, 13 Sep 95 14:31:03 PDT Date: Wed, 13 Sep 95 14:26:00 PDT From: Arpad Muranyi Message-Id: To: ibis@vhdl.org, bd25531@bingsuns.cc.binghamton.edu Subject: Re: V/I transition curves Text item: Peivand, The "transition data" you are looking for is there in the IBIS models as the V-t curves. The final point of the V-t curve should match with the corresponding point on the I-V curve (unsing Ohm's law, of course). You can then use the V-t curve to scale the I-V curve to obtain "partially-on" I-V curves. (Of course you can use the V-t data any other way you like). I don't know of any other methods to obtain what you are asking for. Think about it this way: Even if a buffer is fairly slow, it will switch within 100 ns most likely. Sweeping an I-V curve takes time, and to get many I-V sweeps for a buffer during its switching implies that you need to sweep it with sub nanosecond sweep times. This has two problems, one, the parasitic C and L will mess up your measurements, and second, you are not going to find any equipment which can do it that fast. You might be able to measure things like that in simulations, but even there, the parasitics will take over if the device is modelled correctly... Arpad Muranyi Intel Corporation ============================================================================== Hi IBISians! According to the information in IBIS documents only one curve for Low and High states are given. Assuming that the device Low-High or High-Low transtion takes some time, the transition data would be neccessary, one way that I can think of is scaling the V/I curves for this purpose. I am looking for other ways to do this thing,so can any of you IBISians help me in this matter? Viva IBIS!! peivand 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-Length: 423 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: ELM [version 2.4 PL24] Date: Wed, 13 Sep 1995 13:43:54 -0400 (EDT) To: ibis@vhdl.org Subject: V/I transition curves Message-Id: <199509131743.NAA09598@bingsuns.cc.binghamton.edu> Received: (from bd25531@localhost) by bingsuns.cc.binghamton.edu (8.6.12/8.6.9) id NAA09598 for ibis@vhdl.org; Wed, 13 Sep 1995 13:43:55 -0400 From: bd25531@bingsuns.cc.binghamton.edu Received: from bingsuns.cc.binghamton.edu (bd25531@bingsuns.cc.binghamton.edu [1 28.226.1.2]) by bingnet1.cc.binghamton.edu (8.6.9/8.6.9) with ESMTP id NAA03804 for ; Wed, 13 Sep 1995 13:43:21 -0400 Received: from bingnet1.cc.binghamton.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12435; Wed, 13 Sep 95 10:50:21 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 13 Sep 95 10 :48:04 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0ssvvP-000txoC; Wed, 13 Sep 95 10:48 PDT From contec!contec.contec.COM!dileep@netcom.com Thu Sep 14 09:55:01 1995 Return-Path: Received: from netcomsv.netcom.com (uucp7.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27045; Thu, 14 Sep 95 09:55:01 PDT Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id JAA04691; Thu, 14 Sep 1995 09:34:23 -0700 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA26224; Thu, 14 Sep 95 08:54:04 PDT Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA08893; Thu, 14 Sep 1995 08:56:21 +0800 Date: Thu, 14 Sep 1995 08:56:21 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9509141556.AA08893@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: V/I transition curves Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 595 Some of the recent posts mentioned about scaling the I-V table to obtain "partially-on" I-V curves. I was not participating when that discussion took place. Can someone please explain how to obtain the partially-on I-V data, or forward the relevant messages to me or tell me how to get that discussion ? Thanks for the help. ------------------------------------------------------------ Dileep Divekar Contec CAE, Ltd. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From mbs@eos.ncsu.edu Thu Sep 14 10:25:08 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27229; Thu, 14 Sep 95 10:25:08 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA13499; Thu, 14 Sep 1995 13:18:09 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509141718.AA13499@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS2 Date: Thu, 14 Sep 95 13:18:08 EDT Version 2.09 is ready. It is the first beta release and is in the directory /pub/ibis/s2ibis/s2ibis_v2.09 Michael Steer From cpk@Cadence.COM Fri Sep 15 08:37:33 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11940; Fri, 15 Sep 95 08:37:33 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA09143 for ; Fri, 15 Sep 1995 08:30:33 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma008863; Fri Sep 15 08:27:19 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA01072; Fri, 15 Sep 95 08:27:15 -0700 Received: by hot (5.65+/1.5) id AA18514; Fri, 15 Sep 95 11:27:14 -0400 Date: Fri, 15 Sep 95 11:27:14 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9509151527.AA18514@hot> To: ibis@vhdl.org Subject: check this out If you have not heard , there is a meeting on electronic packaging coming up Oct 1 -4 Check it out at http://www.emclab.umr.edu/news9.html From huq@rockie.nsc.com Fri Sep 15 09:19:15 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12200; Fri, 15 Sep 95 09:19:15 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA07895 for ibis@vhdl.org; Fri, 15 Sep 95 09:11:51 -0700 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA05885 for mbs@eos.ncsu.edu; Fri, 15 Sep 95 09:11:49 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA24871; Fri, 15 Sep 95 09:14:45 PDT Date: Fri, 15 Sep 95 09:14:45 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9509151614.AA24871@rockie.nsc.com> To: mbs@eos.ncsu.edu Subject: Model tracking usage - Help wanted ! Cc: ibis@vhdl.org Mike, This is an issue that we need your help on. I brought up a request couple of months ago for coming up with a mechanism for tracking model usage on vhdl.org. This information is ONLY for the Semiconductor vendors providing their respective models. We would like to know, if possible on a monthly basis, a report of how many times, who and what models got copied out of our 'models' dir on vhdl.org. You may add other info if you think will be valuable. To justify putting resources in IBIS model generation, management & marketing are always curious to know these kinds of statistical data. I hope you will be able to take some time out of your busy schedule and provide us with a response on this. Thanks in advance Regards Syed National Semiconductor. From jonp@qdt.com Fri Sep 15 10:13:52 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12590; Fri, 15 Sep 95 10:13:52 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzhia14305; Fri, 15 Sep 1995 13:06:25 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 15 Sep 1995 13:06:41 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00628; Fri, 15 Sep 95 09:54:10 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA26079; Fri, 15 Sep 95 09:54:10 PDT Date: Fri, 15 Sep 95 09:54:10 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9509151654.AA26079@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA01181; Fri, 15 Sep 95 09:54:09 PDT To: ibis@vhdl.org Subject: Logo Page > To: ibis@vhdl.org > Subject: LOGO, POSTER, WWW > I have very few logos and releases for the new IBIS logo > poster and WWW page. > I have data from the folowing companies: > Hyperlynx > INCASES > Anacad > Unicad > Redac > Contec > National > Quad From jbrennan@VNET.IBM.COM Fri Sep 15 14:18:52 1995 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15050; Fri, 15 Sep 95 14:18:52 PDT Received: from BTV by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1769; Fri, 15 Sep 95 17:11:33 EDT Received: by BTV (XAGENTA 4.0) id 9545; Fri, 15 Sep 1995 17:11:17 -0400 Received: from eeyore.btv.ibm.com by btv.ibm.com (AIX 3.2/UCB 5.64/1.9) id ; Fri, 15 Sep 1995 17:11:13 -0400 Received: by btv.ibm.com (AIX 3.2/UCB 5.64/fs4.03) id AA37951; Fri, 15 Sep 1995 17:11:13 -0400 Message-Id: <9509152111.AA37951@btv.ibm.com> To: ibis@vhdl.org Subject: Re: HERE IS: published circuit of non-monotonic output driver In-Reply-To: Your message of Fri, 01 Sep 1995 17:22:58 PDT. <199509020022.RAA23496@netcom2.netcom.com> Date: Fri, 15 Sep 1995 17:11:12 -0400 From: "John Brennan" Sorry for the late reply. The note from Mark Johnson motivated me to do some digging and I found the following... The Petrovik(spelled Petrovick) paper refers to CMOS 4S/Hydra drivers, which were not the subject of my IBIS study. I have not seen their DC output IV curves. I suspect they would cause non-monotonic behavior like Phoenix. OMNI and Phoenix were designed after these drivers, and this compensation scheme was improved upon. There is a paper in 1993 CICC digest of papers(section 25, paper 5), that describes the driver compensation scheme used in Phoenix... Makoto Ueda, Allen Carl, et al, "A 3.3V ASIC for Mixed Voltage Applications with Shut Down Mode", IEEE 1993 Custom Integrated Circuits Conference, Digest of Technical Papers ("CICC-93"), pp. 25.5.1. I would like to point out that the nodes on the reference stacks between devices T11 and T12 are not connected(this caused problems). T12 Drain is tied to Vdd and T11 Drain is tied to GND. The shut off mechanism is provided by an extra transistor in the stack whose gate is fed from the output node via a half latch. In summary, the non-monotonic curves are created by a circuit of the form Vdd | --- IO | | | PAD---------- A O---| | P | | | | | | | | --- --- | | Vgate | | | | O-----------------O-----------------------| | N | | | | | | | | --- | Vdd --- | | | | | | | | A O---| | N | | --- GND | | | | | | | | | --- | | P | |---O A | | | | | | | GND | --- | | | | | | | | | | | --- --------- | | | | | | Delay | | | | N | |-----| Buffer |---------- | | | | | | --- --- --------- | | | | | N | |----O Vref | | | | --- --- | | | | GND | N | |---O Vdd | | | --- | GND where A is a control signal such as (data NOR user_enable_not). Just the simplified pull-down is shown above. During the transition, Vgate < Vdd is defined by the voltage stack reference voltage Vref. This voltage is larger at high Vdd and fast process conditions to minimize the driver performance window. This sets up the low Vgs at hi Vds curve in the IV curves for IBIS. When the transition is finishing(the worst di/dt region is past) the feedback delay buffer shuts off the stack and Vgate = Vdd(now Vds on big output decvice is small). This is the hi Vgs at low Vds curve. The IV curve also shows the transition region between the curves. The success of this scheme is highly dependent on the tuning of the transistors involved. As mentioned, care must be taken such that the stack shut off does not cause an impedance mismatch on the line that generates new reflections. Variations of this scheme were used in OMNI and Phoenix. So the answers to the $64K questions are 1.) yes and 2.) yes. John Brennan ************************************************************************ John Brennan Internal: jbrennan@btv IBM Microelectronics Internet: jbrennan@vnet.ibm.com 862C / 1000 River Road Tel: 802-769-6982 (Tie-Line: 446) Essex Junction, VT 05452 Fax: 802-769-5882 (Tie-Line: 446) ************************************************************************ ------------------ Referenced E-Mail ---------------------------- Date: Fri, 01 Sep 1995 17:22:58 PDT To: ibis@vhdl.org, si-list@silab.Eng.Sun.COM From: mjohnson@netcom.com (Mark Johnson) Subject: HERE IS: published circuit of non-monotonic output driver Message-Id: <199509020022.RAA23496@netcom2.netcom.com> The schematic diagram of an output buffer which displays non monotonicity (measured at low frequencies, for example in a direct current I-V plot), is published in the following paper: J. Petrovik et al, "A 300k-Circuit ASIC Logic Family", 1990 International Solid State Circuits Conference, Digest of Technical Papers ("ISSCC-90"), pp. 88-89. Figure 6 of that paper shows a remarkably clever output driver circuit which compensates for process variations, supply voltage variations, and temperature variations. It performs this compensation better than any other circuit I've ever seen. (Quiz: but there's a cost; find the cost. Hint: it starts with the letter "p") If you put this output buffer on your curve tracer to measure the I-V curves, AND if you took more than 10 nanoseconds to move from one point on the curve to another point (i.e. if the A/D converter inside your curve tracer needs more than 10ns to settle), then you would see the exact I-V curve that Arpad Muranyi drew: > > * > * * > * * * * * * * * * > * > * > * > The region where the slope of the I-V curve goes negative (an incremental *negative resistance*, not usually felt to be the greatest thing in the world to hook up to a transmission line), is caused by the compensation circuitry. As Arpad hypothesized, there is indeed feedback in this output driver circuit. And, oh by the way, the circuit is symmetric; it has negative resistance in both its IOH-VOH curve and also in its IOL-VOL curve. Take a look at Figure 6 of the paper. Better yet, put it in your local SPICE simulator and simulate it "at speed" (transient) and also simulate a DC transfer curve. Don't believe me, I'm some random guy you've never met. Don't believe this message, it's just phosphor dots dancing on your CRT. Be self sufficient, try it yourself and make up your own mind. There are two $64,000 questions: 1. Does anybody actually _use_ circuits like Figure 6 in real products? 2. When you run the thing at full speed (transient analysis), does it work OK? Final remark: the authors of this paper were from "IBM General Technology Division, Essex Junction, Vermont, USA". --Mark Johnson From EGJJ77A@mail.prodigy.com Sun Sep 17 21:41:14 1995 Return-Path: Received: from pimaia1y.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12104; Sun, 17 Sep 95 21:41:14 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by pimaia1y.prodigy.com (8.6.10/8.6.9) with SMTP id AAA28786 for ; Mon, 18 Sep 1995 00:16:53 -0400 Date: Mon, 18 Sep 1995 00:14:32 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.01468215.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Fwd: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing Verification -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- In the teleconference call Friday 9/15/95, I was asked to put the text from the referenced file here on the reflector without the picture for those who cannot retrieve either the .mif or .ps file available on cfi.org/incoming. The text only of the referenced file follows: I believe ASIC vendor timing tools are used both on the chip and above the chip. This hierarchical processing will move from above the chip boundary down inside the chip itself. There is good standardization work going on for the chip itself but what about the interactions above the chip? Many of the problems currently occurring above the chip in timing will be moving down inside the chip as chip design complexity increases in the next three years. Figure 1 shows two chips connected together on an MCM. Wire X is the connection and associated wire on chip 1 connecting a driver and a receiver circuit and the chip pad. Wire Y does the same on chip 2. Net D is the connection on the MCM connecting the two chip pads together. Assume that chip 1 represents a component where the designer provided timing data in the DIET form. The second designer used the CFI/OVI methodology for ASIC chip using the DCL delay language. The second designer for chip 2 ran delay abstraction which creates a special abstracted form which can only be used by the ASIC designer's timing verifier tool when processing the higher level package. Delay calculation on the MCM requires SPICE like analysis of the module net D which requires IBIS models. Now, should the designer of chip 1 have to construct a single IBIS model for the driver and the receiver together with the chip wire effects, or should there be a standard which allows the system to use the IBIS model of the driver and the IBIS model of the receiver and the wire segments of just the net which connects to the chip pad so no further manual derivation is required as processing proceeds up the hierarchy from the chip analysis to the MCM analysis, and to the board analysis. If one want to extend this methodology down to hierarchical processing on chips, the DIET format does not contain sufficient information to handle rise time dependent delays on unbuffered drivers. What is the architecture for this higher level delay calculation and timing verification? Is wire X and wire Y counted in the chip processing? Must it be included in the Net D analysis? There must be a standard methodology for handling this. Is DCL used at the higher level to call a SPICE analysis? ------- FORWARD, Original message follows ------- > Date: Monday, 11-Sep-95 12:26 AM > > From: Ronald J Christoph \ Internet: (egjj77a@prodigy.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Fwd: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing > Verification > > I should have addressed these concerns/questions to the IBIS forum as > well. In hierarchical processing involving ASIC chips, I recommend there > be an IBIS model for each driver circuit and for each receiver circuit and > a standard representation for the physical parasitics. If this is where > we are going, then associating a single IBIS model with a component MCM > pin (if I understand IBIS) seems questionable for the future?? My > questions are illustrated in the referenced file. > > Ron Christopher > ------- FORWARD, Original message follows ------- > > > Date: Wednesday, 06-Sep-95 02:17 AM > > > > From: Ronald J Christoph \ Internet: (egjj77a@prodigy.com) > > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > > > Subject: [OVI/DC-TSC/WG-arch-No.22] Multiple Standards in Timing > > Verification > > > > I have put some timing verification methodology and standards concerns on > > the relationships between the DCL delay calculation language, IBIS, > and DIET into a framemaker .mif file. The file is timever.mif at > > ftp.cfi.org/incoming. > > > > I am sure it requires further explanation, or maybe someone has it all > > resolved. > > > > Ron Christopher > > > > > > > > ------- FORWARD, End of original message ------- > > > ------- FORWARD, End of original message ------- From cpk@Cadence.COM Mon Sep 18 07:07:27 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20419; Mon, 18 Sep 95 07:07:27 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id HAA15563; Mon, 18 Sep 1995 07:00:17 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma015357; Mon Sep 18 06:56:33 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA20836; Mon, 18 Sep 95 06:56:29 -0700 Received: by hot (5.65+/1.5) id AA20577; Mon, 18 Sep 95 09:56:48 -0400 Date: Mon, 18 Sep 95 09:56:48 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9509181356.AA20577@hot> To: ibis@vhdl.org, jbrennan@VNET.IBM.COM Subject: Re: HERE IS: published circuit of non-monotonic output driver I want to clarify the following regarding non monotonic curves: 1. In IBIS 2.1 you can specify non monotonic VI curves of the type referred to in Mark Johnson's email. IBIS specification is a data holder mechanism and as such does not preclude non monotonic data. 2. You can certainly use these curves "unaltered" in simulation. Convergence problems are certainly a possiblity, but then it is so for non linear simulation in general. So using these curves properly is the responsibility of the SIMULATION VENDOR. I hope this helps. C. Kumar Cadence Design Systems 280 Billerica Rd Chelmsford, MA 01824 508-262-6488 508-262-6600 (Fax) > From jbrennan@VNET.IBM.COM Fri Sep 15 17:31:21 1995 > Return-Path: > To: ibis@vhdl.org > Subject: Re: HERE IS: published circuit of non-monotonic output driver > In-Reply-To: Your message of Fri, 01 Sep 1995 17:22:58 PDT. > <199509020022.RAA23496@netcom2.netcom.com> > From: "John Brennan" > Content-Length: 7401 > X-Lines: 166 > > > Sorry for the late reply. > > The note from Mark Johnson motivated me to do some digging and I found > the following... > > The Petrovik(spelled Petrovick) paper refers to CMOS 4S/Hydra drivers, > which were not the subject of my IBIS study. I have not seen their > DC output IV curves. I suspect they would cause non-monotonic behavior > like Phoenix. > > OMNI and Phoenix were designed after these drivers, and this compensation > scheme was improved upon. There is a paper in 1993 CICC digest > of papers(section 25, paper 5), that describes the driver compensation > scheme used in Phoenix... > > Makoto Ueda, Allen Carl, et al, "A 3.3V ASIC for Mixed > Voltage Applications with Shut Down Mode", IEEE > 1993 Custom Integrated Circuits Conference, > Digest of Technical Papers ("CICC-93"), pp. 25.5.1. > > I would like to point out that the nodes on the reference stacks > between devices T11 and T12 are not connected(this caused problems). > T12 Drain is tied to Vdd and T11 Drain is tied to GND. The shut off > mechanism is provided by an extra transistor in the stack whose gate is > fed from the output node via a half latch. > > In summary, the non-monotonic curves are created by a circuit of > the form > > Vdd > | > --- IO > | | | PAD---------- > A O---| | P | | | > | | | | | > --- --- | > | Vgate | | | | > O-----------------O-----------------------| | N | | > | | | | | | > --- | Vdd --- | > | | | | | | | > A O---| | N | | --- GND | > | | | | | | | | > --- | | P | |---O A | > | | | | | | > GND | --- | > | | | > | | | > | | | > | --- --------- | > | | | | | Delay | | > | | N | |-----| Buffer |---------- > | | | | | | > --- --- --------- > | | | | > | N | |----O Vref > | | | | > --- --- > | | | | > GND | N | |---O Vdd > | | | > --- > | > GND > > where A is a control signal such as (data NOR user_enable_not). Just > the simplified pull-down is shown above. During the transition, > Vgate < Vdd > is defined by the voltage stack reference voltage Vref. This voltage > is larger at high Vdd and fast process conditions to minimize the > driver performance window. This sets up the low Vgs at hi Vds curve in the > IV curves for IBIS. When the transition is finishing(the worst > di/dt region is past) the feedback delay buffer shuts off the > stack and Vgate = Vdd(now Vds on big output decvice is small). This > is the hi Vgs at low Vds curve. The IV curve also shows the transition region > between the curves. The success of this scheme is highly dependent > on the tuning of the transistors involved. As mentioned, care must > be taken such that the stack shut off does not cause an impedance mismatch > on the line that generates new reflections. > > Variations of this scheme were used in OMNI and Phoenix. So the answers > to the $64K questions are 1.) yes and 2.) yes. > > John Brennan > > ************************************************************************ > John Brennan Internal: jbrennan@btv > IBM Microelectronics Internet: jbrennan@vnet.ibm.com > 862C / 1000 River Road Tel: 802-769-6982 (Tie-Line: 446) > Essex Junction, VT 05452 Fax: 802-769-5882 (Tie-Line: 446) > ************************************************************************ > > > ------------------ Referenced E-Mail ---------------------------- > > Date: Fri, 01 Sep 1995 17:22:58 PDT > To: ibis@vhdl.org, si-list@silab.Eng.Sun.COM > From: mjohnson@netcom.com (Mark Johnson) > Subject: HERE IS: published circuit of non-monotonic output driver > Message-Id: <199509020022.RAA23496@netcom2.netcom.com> > The schematic diagram of an output buffer which displays > non monotonicity (measured at low frequencies, for > example in a direct current I-V plot), is published in > the following paper: > > J. Petrovik et al, "A 300k-Circuit ASIC Logic Family", > 1990 International Solid State Circuits Conference, > Digest of Technical Papers ("ISSCC-90"), pp. 88-89. > > Figure 6 of that paper shows a remarkably clever output > driver circuit which compensates for process variations, > supply voltage variations, and temperature variations. > It performs this compensation better than any other circuit > I've ever seen. (Quiz: but there's a cost; find the > cost. Hint: it starts with the letter "p") > > If you put this output buffer on your curve tracer > to measure the I-V curves, AND if you took more than > 10 nanoseconds to move from one point on the curve > to another point (i.e. if the A/D converter inside > your curve tracer needs more than 10ns to settle), > then you would see the exact I-V curve that Arpad > Muranyi drew: > > > > > * > > * * > > * * * * * * * * * > > * > > * > > * > > > > The region where the slope of the I-V curve goes negative > (an incremental *negative resistance*, not usually felt to > be the greatest thing in the world to hook up to a > transmission line), is caused by the compensation circuitry. > As Arpad hypothesized, there is indeed feedback in this > output driver circuit. And, oh by the way, the circuit > is symmetric; it has negative resistance in both its > IOH-VOH curve and also in its IOL-VOL curve. > > Take a look at Figure 6 of the paper. Better yet, put it > in your local SPICE simulator and simulate it "at speed" > (transient) and also simulate a DC transfer curve. Don't > believe me, I'm some random guy you've never met. Don't > believe this message, it's just phosphor dots dancing on > your CRT. Be self sufficient, try it yourself and > make up your own mind. > > There are two $64,000 questions: > > 1. Does anybody actually _use_ circuits like Figure 6 > in real products? > > 2. When you run the thing at full speed (transient > analysis), does it work OK? > > Final remark: the authors of this paper were from > "IBM General Technology Division, Essex Junction, > Vermont, USA". > > > --Mark Johnson > > From chris@icx.com Mon Sep 18 08:57:44 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21207; Mon, 18 Sep 95 08:57:44 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 18 Sep 95 08:50 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 18 Sep 95 08:51 PDT Message-Id: Date: Mon, 18 Sep 95 08:51 PDT From: chris@icx.com ( Chris Reid) To: ibis@vhdl.org Subject: Multiple Timing Formats and Ibis Hello, It seems to me the point Ron Christopher raises about multiple dies in one MCM is significant from a timing point of view, but is not significant for Ibis with its current charter. From an Ibis viewpoint an MCM is just another package with a certain set of driver, receiver, power, and ground pins. The particular construction inside the package is not of interest except in how it affects the package model (particularly with the Bird 28 changes). From a timing viewpoint it seems to me we must take a similar stand. There is no hope of capturing all possible intricacies of an MCM layout in some standard description language. That is the function of the layout tool vendors and the associated analysis vendors. Many MCMs today are simple, but there is no fundamental restriction on their structure. They could become as complicated as a board. So, while Ron raises some important issues, I don't think this is the right forum to address those issues. Ibis should stay focused on a package level description regardless of the internals of the package. From a timing perspective (which is off the thrust of Ibis) composite packages such as MCM's will require timing models that descirbe their behavior as a whole. Christopher Reid chris@icx.com 503-603-2527 From EGJJ77A@mail.prodigy.com Tue Sep 19 13:48:10 1995 Return-Path: Received: from pimaia1w-int.prodigy.com (pimaia1w.prodigy.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07702; Tue, 19 Sep 95 13:48:10 PDT Received: from mail.prodigy.com ([199.4.137.13]) by pimaia1w-int.prodigy.com (8.6.10/8.6.9) with SMTP id PAA49402 for ; Tue, 19 Sep 1995 15:41:55 -0400 Date: Tue, 19 Sep 1995 15:39:31 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.01548688.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Use of IBIS -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- I understood IBIS is used as the circuit model to support delay calculation which in turn supports static timing verification and/or dynamic delay logic simulation. I know it is also used for noise analysis or signal integrity. I picked this up over on the CFI/OVI reflector. " From all the EDA vendors that I know that are supporting IBIS, their targte is not logic synthesis, it is not static timing analysis, it is not logic simulation, it is not floorplanning, etc. IBIS is primarily a modeling of the exterior of the Chip I/O targeted to support intra-chip delays, noise, and waveform propagation." Who are the vendors that support IBIS for static timing analysis and/or logic simulation? I thought at least EPIC and Quad do. Am I correct, and are there more? Ron Christopher From fvance@FirePower.COM Tue Sep 19 15:29:37 1995 Return-Path: Received: from FirePower.COM ([198.4.104.7]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08581; Tue, 19 Sep 95 15:29:37 PDT Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA18823; Tue, 19 Sep 95 15:22:36 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14035; Tue, 19 Sep 95 15:22:33 -0700 From: Fred Vance Message-Id: <9509192222.AA14035@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02546; Tue, 19 Sep 95 15:22:29 -0700 Date: Tue, 19 Sep 95 15:22:29 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: fvance@FirePower.COM Subject: Re: Use of IBIS Cc: ibis@vhdl.org EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) >Who are the vendors that support IBIS for >static timing analysis and/or logic simulation? I believe that any tool that simulates interconnect delay could be used to provide input for any static timing analysis and/or logic simulation. Some tools may integrate the two analyses to a higher degree than others. Fred FirePower Systems, Inc. From fvance@FirePower.COM Tue Sep 19 15:48:43 1995 Return-Path: Received: from FirePower.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08730; Tue, 19 Sep 95 15:48:43 PDT Received: from oahu by FirePower.COM (NX5.67e/FPS-munged-v1.0) id AA18916; Tue, 19 Sep 95 15:41:39 -0700 Received: from protocol by oahu.FirePower.COM (NX5.67d/NX3.0M) id AA14470; Tue, 19 Sep 95 15:41:36 -0700 From: Fred Vance Message-Id: <9509192241.AA14470@oahu.FirePower.COM> Received: by protocol.FirePower.COM (NX5.67d/NX3.0X) id AA02555; Tue, 19 Sep 95 15:41:35 -0700 Date: Tue, 19 Sep 95 15:41:35 -0700 Received: by NeXT.Mailer (1.99.1) Received: by NeXT Mailer (1.99.1) To: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Subject: Re: Use of IBIS Cc: ibis@vhdl.org >Who are the vendors that support IBIS for >static timing analysis and/or logic simulation? I believe that any tool that simulates interconnect delay could be used to provide input for any static timing analysis and/or logic simulation. Some tools may integrate the two analyses to a higher degree than others. As for the quotation: >" From all the EDA vendors that I know that are >supporting IBIS, their targte is not logic synthesis, >it is not static timing analysis, it is not logic simulation, >it is not floorplanning, etc. IBIS is primarily a modeling >of the exterior of the Chip I/O targeted to support intra-chip >delays, noise, and waveform propagation." This is a statement that might be argued either way. If a design is running slow enough or (PCB traces are short enough), then the interconnect delay may be inconsequential. However with core logic driving nets external to the ASIC at clock rates of 66MHz and higher, the interconnect delay is significant. If you accept the premise that interconnect delay is significant, then any tool that uses IBIS models will be of value in timing analysis, logic simulation, floorplanning, etc. Fred FirePower Systems, Inc. From bob@icx.com Tue Sep 19 16:44:07 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09020; Tue, 19 Sep 95 16:44:07 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 19 Sep 95 16:37 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 19 Sep 95 16:39 PDT Message-Id: Date: Tue, 19 Sep 95 16:39 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS 9/15/95 MINUTES DATE: September 19, 1995 SUBJECT: 9/15/95 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS: AT&T Global Info Solutions Dave Moxley* Cadence Design Sandeep Khanna, C. Kumar* Contec CAE, Ltd. Dileep Divekar* HyperLynx Kellee Crisafulli IBM Jay Diepenbrock INCASES Werner Rissiek, Olaf Rethmeier Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi, Derrick Duehren Interconnectix, Inc. Bob Ross* Meta-Software Les Spruiell, Mei Wong, You-Pang Wei, John Sliney Motorola Ron Werner National Semiconductor Syed Huq*, Atul Agarwal, Cheng-Yang Kao NEC Hiroshi Matsumoto, Eldar Yazbashevz* Quad Design Jon Powell* Quantic Labs Mike Ventham* Tanner Research, Inc. Scott Wedge, Ed Miller, Peter Parrish Texas Instruments Roger Cline, Ben Andresen* Thomson-CSF/SCTF Jean LeBrun UniCAD Canada Ltd. Stephen Lum VLSI Technology Dick Ulmer*, Sung Oh* Zuken-Redac John Berrie OTHER PARTICIPANTS: ARPA Randy Harr Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadlab Ralf Bruning CFI Ron Christopher* Digital Equipment Corp. Barry Katz EIA Patti Rusher* High Design Technology Michael Smith, Dr. Ing. Cosso Hewlett Packard Tom Langdorf, Karl Kachigan, Henry Wu Integrated Silicon Systems Eric Bracken Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz LSI Logic Corp. Satish Pratadneni Mentor Graphics Ravender Goyal, Greg Doyle Micron Technology Brian Johnson MicroSim Arthur Wong North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Univ. of Illinois, Urbana Raj Mittra Zeelan Technology George Opsahl, Hiro Moriyasu (Independent) Bob Ward In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 10/6/95 (303) 633-2197 1-308636 No pass code 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 Ron Christopher of CFI and working as an independent consultant on a ten- year roadmap for EIA standards introduced his work. He is working with CFI, EDAC and Semitech. His long range concern is EDA standardization of delay/verification and compatibility of related models including IBIS. He is also concerned about the acceptance of standards by major vendors. His documents and preliminary reports are on the Web at http://www.cfi.org/roadmap/roadMap-eii-report.html. EIA MEMBERSHIP AND TREASURER'S REPORT Patti Rusher reported the treasury is $8725.54. IBM and VLSI are members, as previously reported, and Tanner Research has also become a voting member. MINUTES REPORT, MISC. Will submitted some spelling corrections to the 8/25/95 minutes which have been made on the posted copy on vhdl.org. Also, Raj Mittra was incorrectly reported as present at the last meeting. MISCELLANY/ANNOUNCEMENTS C. Kumar reported that the 4th Topical Meeting on Electronic Performance of Electronic Packaging (EPEP'95) is being held in Portland, Oregon on October 2-4, 1995. More information can be obtained on a web site: http://www.emclab.umr.edu/news9.html. AR - Kumar post this on the reflector [Done]. Jon Powell still needs logos from participants. Only a few have been received. Because of some vhdl.org computer difficulties, the message he sent may not have gone out. AR - Jon Powell send again the logo message [Done]. PRESS UPDATES None. NEW MODELS None. OPENS FOR NEW ISSUES VI table and slow input discussion based on reflector questions. Ground bounce discussion based on reflector questions. Roadmap questions Ron Christopher is raising related to delay. EIA IBIS RATIFICATION (VOTES) Patti Rusher reported that she has not received the documents from Will. AR - Will Hobbs/Stephen Peters FAX all documents to Patti. Patti requires the rolled up standard, copies of the official responses and changes, and a cover letter. The package will be put together by EIA Engineering to be presented at the next EIA Board Meeting (EDAC) for review and ratification. This will then become EIA-656 and will also be forwarded for ANSI standardization. Will Hobbs will work on a generic press release timed at the official transition. The press release will list the official EIA members. Bob Ross will work with EIA (Cecilia Fleming) regarding ensuring all of the preface changes are included (that were not part of IBIS Version 2.1). FACE TO FACE MEETING Will Hobbs indicated that we typically meet sometime around December plus or minus a month. January is proposed as a meeting time. Intel is willing to host the meeting unless another company wishes to volunteer. A number of technical items will be discussed including monotonicity, package models, clamping models, and other items. In the past, these meetings have been very informative and have resulted in extensions to IBIS. WEB UPDATE Syed Huq reported that the EIA home page is up in preliminary form with a new search utility. IBIS can be accessed by searching on standards proposal 3527 or on (case insensitive) ibis. This currently points to the IBIS Home page area. Syed is going to put in the approved contents. When IBIS becomes EIA-656, then the search will can be done by this number. The web site is http://www.eia.org/eng. The EDN article appears in Word For Windows format on vhdl.org under /pub/ibis/documents. Syed will convert this and have it available on the Web site. Syed will post the FAQ's and will also send a copy to Bob Ross so they can be posted on vhdl.org. FAQ VOTE Q6: Can IBIS model SSO (Simultaneous Switching Output) ? This was posted on the reflector. The issue is that it is dangerous to imply that SSO is completely covered because there can be complicated interactions with external and internal chip and MCM parameters. However, IBIS does have a number of parameters that are useful for SSO analysis. To indicate that SSO can be handled by IBIS models to a limited extent, the original answer "IBIS as a model, has all the important parameters required to model an SSO event. ...." is changed to "IBIS as a model, has the key parameters required to model an SSO event. ..." This change was approved by committee vote, so FAQ Q6 can be posted. The issue of ground bounce generated some positioning discussion related to whether the primary mechanisms are external or internal to the chip. Usually the internal details are not known, nor is there any real desire to make them available. So the primary focus of ground bounce is at the board level. The SSO model being regarded as a practical approximation, but not an exact source of all information. MODEL USAGE TRACKING Syed Huq has been in contact with Michael Steer regarding setting up a model usage tracking system for vhdl.org. The information would be provided only to the providers of models for their models only. Michael Steer needs to respond on the problems and progress of this activity. AR - Michael Steer work with Syed and give status of model usage tracking project. GOLDEN PARSER UPDATE Version 9 has been distributed. A Test Matrix was distributed showing all know problems have been fixed. IBISCHK2 is ready for official (non-Beta) distribution. AR - Will Hobbs work with Paul Munsey to remove the Beta designation. The official Parser will be distributed to those who have purchased it. AR - Bob Ross provide Jon Powell with several IBIS test files to validate functionality of the Parser. The primary reason is to have test cases against which ibishck2 executables for different machines can be tested. AR - Jon Powell make executables for a number of machines and test them. AR - Jon Powell send-to/work-with Bob Ross to post these executables on vhdl.org. This should occur around the October 2 time frame based on peoples schedules. SPICE TO IBIS VERSION 2.1 Michael Steer and North Carolina State University team have posted a Beta version on vhdl.org under /pub/ibis/s2ibis/s2ibis_v2.09. Bob Ross has done a prelimary review, and it functions well. There are a few typos in the documentation and the functionality still needs to be reviewed. A major difference is that the "*" and "**" control syntax is replaced by IBIS keywords and IBIS-like syntax. Syed Huq indicated that National has modified the original s2ibis code to be compatible with the internal Spice features. COOKBOOK Bob Ross reported no progress. NON-MONOTONOCITY Ron Christopher lead the discussion by indicating for a frame of reference that handling non-monotonic drivers seems to be a barrier to a major vendor (IBM) for adopting IBIS. The goal of IBIS was for a transfer of useful information while preserving proprietary process information. IBIS does allow the full characterization of non-monotonic VI data (with warning messages), but the real problem is that the actual internal mechanisms are guarded. Furthermore, performance information is not available. Both are needed for simulator vendors to actually process the data properly. Ron suggested that some independent vendor such as Zeelan could provide measurement based data to give characterization information. That would be a start, but not necessarily the total picture. Also, there may be problems of vendors suppling such sensitive chips for measurement for public distribution and the willingness of whoever does the measurements to distribute the information. Ron will pursue this path. The technical discussions regarding non-monotonic impact related to possible delay artifacts. Jon Powell indicated that attempts to reverse engineer the non-monotonic effects to provide a simulation model were to date unsuccessful. The simulation data did not match the actual data. So the internal mechanisms are probably needed. Other companies may have similar technology. However, TI's reference to GTL structures are probably not similar. Most likely the non-monotonic architecture will be more fully understood and could be implemented in IBIS. Sources of information may emerge through patents and pending patents, papers and other vendors. Vendors interested in using IBIS for these effects need to participate in the IBIS activities to supply the essential information so that EDA vendors can correctly architect the simulators. Ron, through his contacts could urge vendors to become active in IBIS. BIRD30 - PIN PROGRAMMABLE BUFFER STRENGTHS Arpad Muranyi had submitted BIRD30 in August, and it has already generated reflector discussion. Since Arpad was away on a prestigous internal technical conference, Bob Ross summarized BIRD30 and the reflector discussion. BIRD30 introduces the new keyword [Model Selector] keyword. This allows a variety of buffers (different voltages, different strengths, different slew rates, different Model_types, even different technologies) to be assigned to a pin or group of pins. One direction on the reflector was to extend this capability to standardize "Classes" of capability. Then the selection method could be based on function. The consensus was that this complication was not warrented, would be difficult to standardize, and would still be subject to individual simulator characteristics. An opposite direction was to eliminate the "default" parameter and use the first entered model as the default. This would be simplier to implement. An intermediate position was to add a "discription" column associated with each model name. This discription column would guarentee a text entry (as opposed to relying on comment information) which could be viewed by simulators. While not standardized, the information would be reasonably descriptive. It could be used as the basis for interactive user selection of models for a group of pins. The consensus was to go with this approach. AR - Arpad Muranyi submit BIRD30.1 with the "default" parameter removed, with selection of the first model as the default, and with the a description column extension. This will be the basis for further discussion. EGG6 - CMOS/TTL DIFFERENCES Jon Powell introduced EGG6 discussion, also delayed from August. Basically there are differences in the way TTL and CMOS transitions occur. Several proposals have been sent regarding ways to detect TTL and CMOS type data. However, there are probably counter examples where any such detection scheme will fail. An alternative is to introduce into the [Model] keyword another sub-parameter designating TTL, CMOS, etc for technology differentiation. An automatic detections scheme may still be need if such a sub-parameter is not required. This egg is subject to more discussion related to how the transition methods of TTL and CMOS differ, possible sub-parameter markers, and possible automatic detection methods. BIRD27.1 - DEFAULT DIFFERENTIAL THRESHOLD Still Deferred, but will be submitted by Bob Ross in the future. BIRD28.2 PACKAGE MODEL ENHANCEMENT Agreement that the "Maxwell" capacitance should be the reference for the coupled matrix. Stephen Peters should submit BIRD28.3 with this change. This may generate more discussion and or lead to a possible vote. ROADMAP QUESTIONS Ron Christopher has some technical issues with IBIS which he has in a frame document on cfi/incoming/timezer. Since various participants do not have ftp or framework capabilitity, it is better to send this document in Postscript form on the reflector. Then the questions and concerns can be considered. AR - Will Hobbs get timezer, transform it, and send to the reflector as a Postscript document. NEXT MEETING: It is set on Friday, October 6, 1995. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Modeling Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com 10220 SW Nimbus Ave, K4, Portland, OR 97223 To become a voting member of the EIA IBIS Open Forum, send email to ibis-info@vhdl.org for instructions. If you want to join the e-mail reflector (ibis@vhdl.org), send e-mail to the IBIS secretary at ibis-request@vhdl.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 email 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 cpk@Cadence.COM Wed Sep 20 05:27:10 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18121; Wed, 20 Sep 95 05:27:10 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id FAA16122; Wed, 20 Sep 1995 05:20:06 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma015970; Wed Sep 20 05:15:37 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA00547; Wed, 20 Sep 95 05:15:32 -0700 Received: by hot (5.65+/1.5) id AA23242; Wed, 20 Sep 95 08:15:32 -0400 Date: Wed, 20 Sep 95 08:15:32 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9509201215.AA23242@hot> To: ibis@vhdl.org, bob@icx.com Subject: Re: IBIS 9/15/95 MINUTES Again I want to emphasize some simple faces about non monotonicity 1. IBIS does not preclude non monotonic data 2. Simulation of non monotonic is as much of a black art as any non linear simulation. We have succeessfully simulated them. - kumar > NON-MONOTONOCITY > Ron Christopher lead the discussion by indicating for a frame of reference > that handling non-monotonic drivers seems to be a barrier to a major > vendor (IBM) for adopting IBIS. The goal of IBIS was for a transfer of > useful information while preserving proprietary process information. IBIS > does allow the full characterization of non-monotonic VI data (with warning > messages), but the real problem is that the actual internal mechanisms are > guarded. Furthermore, performance information is not available. Both > are needed for simulator vendors to actually process the data properly. > > Ron suggested that some independent vendor such as Zeelan could provide > measurement based data to give characterization information. That would > be a start, but not necessarily the total picture. Also, there may > be problems of vendors suppling such sensitive chips for measurement > for public distribution and the willingness of whoever does the measurements > to distribute the information. Ron will pursue this path. > > The technical discussions regarding non-monotonic impact related to possible > delay artifacts. Jon Powell indicated that attempts to reverse engineer > the non-monotonic effects to provide a simulation model were to date > unsuccessful. The simulation data did not match the actual data. So the > internal mechanisms are probably needed. > > Other companies may have similar technology. However, TI's reference to > GTL structures are probably not similar. > > Most likely the non-monotonic architecture will be more fully understood > and could be implemented in IBIS. Sources of information may emerge > through patents and pending patents, papers and other vendors. Vendors > interested in using IBIS for these effects need to participate in the IBIS > activities to supply the essential information so that EDA vendors can > correctly architect the simulators. Ron, through his contacts could urge > vendors to become active in IBIS. > From speters@ichips.intel.com Wed Sep 20 09:00:25 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19485; Wed, 20 Sep 95 09:00:25 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 20 Sep 95 08:53:22 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 20 Sep 95 08:53:12 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 20 Sep 95 08:53:12 PDT Message-Id: <9509201553.AA22710@xtg801.intel.com> To: ibis@vhdl.org Subject: Bird 28.3 Date: Wed, 20 Sep 1995 08:53:10 -0700 From: Stephen Peters Hello Fellow IBISans: Here is an update to bird 28. Changes are listed below: Changes 9/20 Dropped the requirement that the capacitance and inductance values in the coupling matrix have to be entered as positive quantities. Also corrected the word 'backslash' to 'slash' thru out the document and added the editorial comments per Dileep Divakar email of Aug 24th. Best Regards, Stephen Peters Intel Corp. -------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 28.3 ISSUE TITLE: Enhancement To The Package Model (.pak file) Specification REQUESTER: Stephen Peters DATE SUBMITTED: Sept 20, 1995 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current package model specification describes each pin on a package using lumped L/R/C parameters. Coupling between pins also assumes lumped electrical parameters. However, these description are inadequate when the electrical length of the package elements are greater than ~1/6 of the I/O buffers' rise time. This bird enhances the package description by allowing package elements to be described in terms of length and L, R and C per unit length; i.e. a transmission line representation. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Following are the specific changes to the specification. 1. The keyword [Number of Sections] is added to the specification after the Description keyword |============================================================================== | Keyword: [Number of Sections] | Required: No |Description: Defines the maximum number of sections that make up a 'package | stub'. A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. |Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. |----------------------------------------------------------------------------- [Number of Sections] 3 | |============================================================================= 2. The current [Pin Numbers] keyword description is replaced by the following: |============================================================================= | Keyword: [Pin Numbers] | Required: Yes |Description: Tells the parser the set of names that are used for the package | pins and also defines pin ordering. If the [Number of Sections] | keyword is present it also lists the elements for each section | of a pin's die to pin connection. | Sub-Params: Len, L, R, C, Matrix |Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number of Pins] keyword). Pin names | can not exceed 5 characters in length. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." If the [Number of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number of | Sections] keyword is not present then subparameter usage is | NOT allowed. | | Subparameters: | The subparameters specify the length, inductance, capacitance | and resistance of each section of each stub on a package. If | a particular section exhibits coupling to an adjacent (same | numbered) section of a different package stub then the Matrix | subparameter is used. The subparameters are defined as | follows: | Len The length 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 package stub section is 3.0nH and the | length of this 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. | Matrix Use of this subparameter means that this package stub | sections electrical parameters are presented as part of | a coupling matrix. The data for the matrix is included | between the [Model Data]/[End Model Data] keyword pairs | as described below. | | Specifying a length 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. | | Using The Subparameters to Describe Package Stub Sections: | Each section description must begin with the Len subparameter and | ends with the slash (/) character. The value of a sub- | parameter and the subparameter itself are separated by an equals | sign (=); whitespace around the equals sign is optional. 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 /'. See the | example below). | | Legal Subparameter Combinations: | A) A single Len = 0 subparameter, followed by a slash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | backslash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. The matrix description must include both the 'self' | inductance/capacitance/resistance (as required) of a section | as well as the mutual coupling terms. If one section is | described using the the Matrix subparameter then the | corresponding (same numbered) sections on ALL other package | stubs must use the Matrix subparameter. | | C) 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. | | | In the example below the first section is a lumped inductor, | the second section is described using a matrix, and the third | section is modeled using distributed elements. Pin A3 shows | an example of sections with no data. Pins A4 and A5 illustrate | how a section description can be broken across multiple lines | and how each section description is delimited by the slash. |----------------------------------------------------------------------------- [Pin Number] A1 Len = 0 L=1.2n / Len = 1.3 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01 / A2 Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 / A3 Len = 0 / Len = 1.1 Matrix / Len = 0 / A4 Len = 0 L=1.2n / Len = 1.0 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01/ A5 Len = 0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / | | Note that the actual length for each section is reported, even for | those sections that use the Matrix subparameter. | 3. The current [Model Data] and [End Model Data] keyword descriptions are replaced by the following |============================================================================= | Keyword: [Model Data] | Required: Yes, if any of the sections in a package stub description | use the 'Matrix' subparameter or if the [Number of Sections] | keyword is not used. |Description: Indicates the beginning of the matrix data used to describe | a package stub section. |Usage Rules: If the [Number of Sections] keyword is used then the [Model | Data] keyword must be followed by the word 'section' and the | section number the matrix data applies to. There must be a | [Model Data] keyword for every section in a package stub | description that uses the Matrix keyword. Note that if the | [Number of Sections] keyword is used but no package stub | sections use the Matrix subparameter then the [Model Data] | and [End Model Data] keyword are not required. |----------------------------------------------------------------------------- [Model Data] section 2 | |============================================================================= | Keyword: [End Model Data] | Required: Yes, if the [Model Data] keyword is present. |Description: Indicates the end of the matrix data used to describe | a package stub section. |Usage Rules: In between the [Model Data] and [End Model Data] keywords is | the matrix data itself. The data is a set of three matrices: | the resistance (R) , inductance (L) , and capacitance (C), | matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords to mark the | beginning of each matrix. As with the [Model Data] keyword | the [End Model Data] keyword is followed by the word 'section' | and the section number. |----------------------------------------------------------------------------- [End Model Data] section 2 | |============================================================================= 4. The following paragraph is added to the section entitled "RLC MATRIX NOTES" (place after the first paragraph). There are two different ways to extract the coefficients that are reported in the the capacitance and inductance matrices. For the purposes of this specification, the coefficients reported in the capacitance matrices shall be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. The Maxwell capacitance Kij is defined as the charge induced on conductor "j" when conductor "i" is held at 1 volt and all other conductors are held at zero volts. Note that Kij ( when i /= j) will be a negative number and should be entered as such. Likewise, for the inductance matrix the coefficients for Lij are defined as the voltage induced on conductor "j" when conductor "i"'s current is changed by 1amp/sec and all other conductors have no current change. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This bird proposes three fundamental enhancement to the current package specification. They are: 1. The connection between the pad on the die and the external package pin (referred to in this bird as the package 'stub') is now considered to be composed of a number of elements, or sections, in series. 2. Each of these elements can have a non-zero length, thus enabling one to model each section as having a time delay -- i.e. as a transmission line 3. The current matrix description can now be applied to individual section of the package stub, and there can be more than one [Model data] and [End Model Data] keyword pair per package model description. The purpose of this bird is to enable IBIS to describe the connection between the pad and pin of a package in greater detail. Specifically, with this bird one will now be able to model the effect of long package traces and also the effects when one package trace couples with another. The author has found that this level of detail is vital for accurately modeling the effects of large PGA packages and/or packages that have no ground plane and exhibit coupling between package traces. With these enhancement, the .pkg file should be able to accurately describe the great majority of DIP/SOIC/PGA/BGA/PQFP packages. It is NOT the purpose of this bird to describe a generalized topology suitable for describing MCM and SIM modules. In addition to the enhancements required to better describe packages, the capacitance and inductance coefficients used for the matrix data elements are defined. I believe that even if this bird is not accepted, this portion should be adopted in order to make the current matrix format usable. Changes 6/28 Per the suggestions of Bob Ross (email on May 30) I have removed the 'Unit Length' keyword and incorporated his syntax suggestions regarding slash delimiters and the '=' sign. Changes 8/21 The previous change on 6/28 included the requirement that the same length for each coupled stub in a section be reported as the same length. This requirement has been deemed un-feasible and is dropped. Changes 9/20 Dropped the requirement that the capacitance and inductance values in the coupling matrix have to be entered as positive quantities. Also corrected the word 'backslash' to 'slash' thru out the document and added the editorial comments per Dileep Divakar email. ANY OTHER BACKGROUND INFORMATION For a much more detailed description of Maxwell capacitances refer to the paper by Robert Canright entitled "Capacitance: Relationships and Measurements" available from the IEEE (Thanks to Bob Ward at Texas Instruments for supplying me with this paper). I would also like to thanks Samie Samaan at Intel for his review of this bird and for bringing the whole issue of matrix data coefficients to my attention. From Arpad_Muranyi@ccm.fm.intel.com Wed Sep 20 11:22:16 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20478; Wed, 20 Sep 95 11:22:16 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0svTft-000UksC; Wed, 20 Sep 95 11:15 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0svTft-000tyOC; Wed, 20 Sep 95 11:15 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Wed, 20 Sep 95 11:15:13 PDT Date: Wed, 20 Sep 95 11:08:00 PDT From: Arpad Muranyi Message-Id: To: Arpad_Muranyi@ccm.fm.intel.com, jonp@qdt.com, ibis@vhdl.org Subject: Re[2]: EGG Half Dozen Text item: Since noone responded to this EMAIL I sent quite a while ago, I suspect that it might have gotten lost, so I am resending it again. Is this automated detection method acceptable, or are there cases when it would fail? Arpad ================================================================================ Jon, I have an idea that might do the thing without an extra keyword. (I didn't spend much time on this, though, so I am not sure if this is fool proof). The I-V curves of bipolar pulldown structures usually cross the voltage axis above 0 volt, in other words, zero current is at approximately 0.15 V on those I-V curves. On the other hand, the I-V curves of CMOS pulldowns would go through the origin, since the channel behaves more like a voltage controlled resistor (i.e. no voltage, no current). If the I-V curve in an IBIS file is accurate enough to detect this difference, I think you can just look for the voltage at zero current, and if it is not zero, you could assume a bipolar device. Do you think this will work? Arpad =============================================================================== More Argument on EGG Half Dozen. Hopefully by now people have the hardcopy in hand and can look at the two IV curve groups. If we have no argument on how they look (at least, in general appearance) then my problem is this: As the "control" voltage changes on the CMOS gate only the IV curve strength changes. The zero millamp point stays constant (at ~VCC) this makes sense as all we are doing is making the CMOS gate more resistive. The TTL gate, however, changes its zero milliamp point, it being a totem pole arrangement and all. The point is, at risetime/2, what is the proper thevinin equivalent for the driver? You have to know if it is CMOS or TTL. If there is a fool proof way to determine this form the IV curve alone, they we are done, else I would like a new (optional?) KEYWORD. regards, jon (I hope I got this HALF-DOZEN joke out before bob or will). (If you still need hardcopy, let me know. Won't it be nice when I can just post HTML to a WWW EGG discussion page?). 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: EGG Half Dozen To: ibis@vhdl.org Received: by f14.qdt.com (4.1/SMI-4.1) id AA10842; Thu, 10 Aug 95 10:09:50 PDT Message-Id: <9508101709.AA27974@hal.qdt.com> From: jonp@qdt.com (Jon Powell) Date: Thu, 10 Aug 95 10:09:52 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27974; Thu, 10 Aug 95 10:09:52 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00557; Thu, 10 Aug 95 10:09:52 PDT Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 10 Aug 1995 13:36:18 -0400 Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQzcfe02475; Thu, 10 Aug 1995 13:36:26 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04774; Thu, 10 Aug 95 10:43:05 PDT Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, 10 Aug 95 10 :39:38 -0700 Received: from aurora.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sgbZz-000twZC; Thu, 10 Aug 95 10:39 PDT 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: EGG Half Dozen To: jonp@qdt.com, ibis@vhdl.org Message-Id: From: Arpad Muranyi Date: Thu, 17 Aug 95 16:46:00 PDT Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 17 Aug 95 16:56:39 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sjEnf-000txAC; Thu, 17 Aug 95 16:56 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sjEng-000UgMC; Thu, 17 Aug 95 16:56 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04272; Thu, 17 Aug 95 17:03:27 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 17 Aug 95 16 :58:49 -0700 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sjEpo-000twvC; Thu, 17 Aug 95 16:58 PDT From cpk@Cadence.COM Wed Sep 20 12:00:03 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20646; Wed, 20 Sep 95 12:00:03 PDT Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id LAA27491; Wed, 20 Sep 1995 11:46:05 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma027106; Wed Sep 20 11:43:13 1995 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA16802; Wed, 20 Sep 95 11:43:07 -0700 Received: by hot (5.65+/1.5) id AA24151; Wed, 20 Sep 95 14:43:08 -0400 Date: Wed, 20 Sep 95 14:43:08 -0400 From: cpk@cadence.com (C. Kumar) Message-Id: <9509201843.AA24151@hot> To: Arpad_Muranyi@ccm.fm.intel.com, jonp@qdt.com, ibis@vhdl.org Subject: Re: Re[2]: EGG Half Dozen I do not see we need to add anything special in IBIS to detect whether is curve is TTL or CMOS. The VT curves in 2.1 provides the mechanism to specify a non ideal transient behavior = Kumar Cadence design System > > > Text item: > > Since noone responded to this EMAIL I sent quite a while ago, I suspect that it > might have gotten lost, so I am resending it again. Is this automated detection > method acceptable, or are there cases when it would fail? > > Arpad > ================================================================================ > Jon, > > I have an idea that might do the thing without an extra keyword. (I didn't > spend much time on this, though, so I am not sure if this is fool proof). > > The I-V curves of bipolar pulldown structures usually cross the voltage axis > above 0 volt, in other words, zero current is at approximately 0.15 V on those > I-V curves. On the other hand, the I-V curves of CMOS pulldowns would go > through the origin, since the channel behaves more like a voltage controlled > resistor (i.e. no voltage, no current). If the I-V curve in an IBIS file is > accurate enough to detect this difference, I think you can just look for the > voltage at zero current, and if it is not zero, you could assume a bipolar > device. > > Do you think this will work? > > Arpad > =============================================================================== > More Argument on EGG Half Dozen. > > Hopefully by now people have the hardcopy in hand and can look at > the two IV curve groups. If we have no argument on how they look > (at least, in general appearance) then my problem is this: > > As the "control" voltage changes on the CMOS gate only the IV curve > strength changes. The zero millamp point stays constant (at ~VCC) this > makes sense as all we are doing is making the CMOS gate more resistive. > > The TTL gate, however, changes its zero milliamp point, it being a totem > pole arrangement and all. > > The point is, at risetime/2, what is the proper thevinin equivalent for the > driver? You have to know if it is CMOS or TTL. If there is a fool proof way > to determine this form the IV curve alone, they we are done, else I would > like a new (optional?) KEYWORD. > > regards, > jon > > (I hope I got this HALF-DOZEN joke out before bob or will). > > (If you still need hardcopy, let me know. Won't it be nice when I can just > post HTML to a WWW EGG discussion page?). > > 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: EGG Half Dozen > To: ibis@vhdl.org > Received: by f14.qdt.com (4.1/SMI-4.1) > id AA10842; Thu, 10 Aug 95 10:09:50 PDT > Message-Id: <9508101709.AA27974@hal.qdt.com> > From: jonp@qdt.com (Jon Powell) > Date: Thu, 10 Aug 95 10:09:52 PDT > Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) > id AA27974; Thu, 10 Aug 95 10:09:52 PDT > Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) > id AA00557; Thu, 10 Aug 95 10:09:52 PDT > Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL > ; Thu, 10 Aug 1995 13:36:18 -0400 > Received: from uucp4.UU.NET by relay3.UU.NET with SMTP > id QQzcfe02475; Thu, 10 Aug 1995 13:36:26 -0400 > Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) > id AA04774; Thu, 10 Aug 95 10:43:05 PDT > Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Thu, > 10 Aug 95 10 > :39:38 -0700 > Received: from aurora.intel.com by relay.jf.intel.com with smtp > (Smail3.1.28.1 #2) id m0sgbZz-000twZC; Thu, 10 Aug 95 10:39 PDT > > 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: EGG Half Dozen > To: jonp@qdt.com, ibis@vhdl.org > Message-Id: > From: Arpad Muranyi > Date: Thu, 17 Aug 95 16:46:00 PDT > Received: by ccm.hf.intel.com (ccmgate 3.2 #2) Thu, 17 Aug 95 16:56:39 PDT > Received: from ccm.hf.intel.com by relay.jf.intel.com > (Smail3.1.28.1 #2) id m0sjEnf-000txAC; Thu, 17 Aug 95 16:56 PDT > Received: from relay.jf.intel.com by ormail.intel.com with smtp > (Smail3.1.28.1 #7) id m0sjEng-000UgMC; Thu, 17 Aug 95 16:56 PDT > Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) > id AA04272; Thu, 17 Aug 95 17:03:27 PDT > Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 17 Aug 95 16 > :58:49 -0700 > Received: from hermes.intel.com by relay.jf.intel.com with smtp > (Smail3.1.28.1 #2) id m0sjEpo-000twvC; Thu, 17 Aug 95 16:58 PDT > From EGJJ77A@mail.prodigy.com Thu Sep 21 00:49:58 1995 Return-Path: Received: from pimaia1y.prodigy.com ([192.207.105.44]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25987; Thu, 21 Sep 95 00:49:58 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by pimaia1y.prodigy.com (8.6.10/8.6.9) with SMTP id PAA06722; Wed, 20 Sep 1995 15:52:19 -0400 Date: Wed, 20 Sep 1995 15:49:58 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.01607028.EGJJ77A@prodigy.com> To: ibis@vhdl.org, ovidc-arch@chronologic.com, roadmap-eii@cfi.org Subject: Fwd: Multiple Timing Formats and Ibis -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Chris Reid, Thank you for the feedback. I was not thinking that the physical design data should be represented in IBIS. I was trying to preserve the original IBIS model for the circuit, supplied and qualified by the technology house, through all levels of packaging. This could perhaps be done by allowing the IBIS model to be named by the package pin plus a hierarchical internal node name which would correspond to a point where the physical design data standard would relate. Our roadmap says there will be a standard for physical design representation. I suspect we need a standard for conveying a subset of the physical design which consists of the physical connection data to connect the most external pin of the package down through the hierarchy to the circuit. The parasitic extraction is independent of the circuit model. We ought to be able to use the qualified IBIS circuit model without modification. This keeps the circuit model independent of parasitic extraction for debug purposes as we progress up the hierarchy using different vendor tools. Otherwise one will not be able to go back to the technology house when the model does not work in the board environment. No one will be able to determine what factors were put in and why. Please guide me in my thinking. Ron Christopher ------- FORWARD, Original message follows ------- > Date: Monday, 18-Sep-95 12:05 PM > > From: Chris Reid \ Internet: (chris@icx.com) > To: Ron Christopher \ PRODIGY: (EGJJ77A) > > Subject: Multiple Timing Formats and Ibis > > Hello, > > It seems to me the point Ron Christopher raises about multiple dies in one > MCM is significant from a timing point of view, but is not significant for > Ibis with its current charter. > > From an Ibis viewpoint an MCM is just another package with a certain set > of driver, receiver, power, and ground pins. The particular construction > inside the package is not of interest except in how it affects the package > model (particularly with the Bird 28 changes). > > From a timing viewpoint it seems to me we must take a similar stand. There > is no hope of capturing all possible intricacies of an MCM layout in some > standard description language. That is the function of the layout tool > vendors and the associated analysis vendors. Many MCMs today are simple, > but there is no fundamental restriction on their structure. They could > become as complicated as a board. > > So, while Ron raises some important issues, I don't think this is the > right forum to address those issues. Ibis should stay focused on a package > level description regardless of the internals of the package. From a > timing perspective (which is off the thrust of Ibis) composite packages > such as MCM's will require timing models that descirbe their behavior as a > whole. > > Christopher Reid > chris@icx.com > 503-603-2527 > > > ------- FORWARD, End of original message ------- From EGJJ77A@mail.prodigy.com Thu Sep 21 01:07:02 1995 Return-Path: Received: from pimaia1y.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26094; Thu, 21 Sep 95 01:07:02 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by pimaia1y.prodigy.com (8.6.10/8.6.9) with SMTP id QAA29416 for ; Wed, 20 Sep 1995 16:57:00 -0400 Date: Wed, 20 Sep 1995 16:54:44 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.01610195.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: Bird 28.3 and IBIS Package Limitations -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Is it generally agreed to that IBIS does not support MCM or SIMM Modules per the description in Bird 28.3? Is there a requirement for support for these packages? Is it in the IBIS plan to extend to support these packages and should I mention this coming extension in the 10 year roadmap? Ron Christopher From EGJJ77A@mail.prodigy.com Thu Sep 21 03:34:22 1995 Return-Path: Received: from pimaia1w.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28052; Thu, 21 Sep 95 03:34:22 PDT Received: from mail.prodigy.com ([199.4.137.13]) by pimaia1w-int.prodigy.com (8.6.10/8.6.9) with SMTP id PAA48176 for ; Wed, 20 Sep 1995 15:13:59 -0400 Date: Wed, 20 Sep 1995 15:11:43 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.01605312.EGJJ77A@prodigy.com> To: ibis@vhdl.org Subject: EDA Roadmap for Standards -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- The 10 year Roadmap for EDA Standards referenced in the minutes has moved. It is on the web at www.cfi.org. Click on "Get Information about EDA Industry Standards Roadmap" Then click on "EDA Industry Standards Roadmap Document" It is also available as postscript file via ftp at: cfi.org/public/Cfi/Development/EII/roadmap.ps Ron Christopher From ttrieu@pcocd2.intel.com Thu Sep 21 08:00:58 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05300; Thu, 21 Sep 95 08:00:58 PDT Received: from pcocd2.intel.com by hermes.intel.com (5.65/10.0i); Thu, 21 Sep 95 07:53:56 -0700 Received: from fsp103.fmdln3 (fsp103.fm.intel.com) by pcocd2.intel.com with SMTP id AA28033 (5.65c/IDA-1.4.4 for ); Thu, 21 Sep 1995 07:56:58 -0700 From: Tuong Trieu Message-Id: <199509211456.AA28033@pcocd2.intel.com> Subject: unsubscribe To: ibis@vhdl.org Date: Thu, 21 Sep 1995 07:55:49 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 13 unsubscribe From bob@icx.com Thu Sep 21 09:31:00 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05842; Thu, 21 Sep 95 09:31:00 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 21 Sep 95 09:23 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 21 Sep 95 09:26 PDT Message-Id: Date: Thu, 21 Sep 95 09:26 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD27.1 DIFFERENTIAL THRESHOLD To IBIS Committee: BIRD27.1 is an IBIS Version 3.0 proposal to provide/change the diff_pin default threshold and also to provide a simplier syntax for the [Diff_Pin] entries. This issue was deferred while the IBIS Version 2.1 ratification discussion was taking place. It is now presented for consideration an/or a vote. Bob Ross, Interconnectix, Inc. Buffer Issue Resolution Document (BIRD) BIRD ID#: 27.1 ISSUE TITLE: Propose new keyword to specify default differential threshold REQUESTOR: Bob Ward, Texas Instruments & Bob Ross, Inteconnectix, Inc. DATE SUBMITTED: 03APR95 DATE MODIFIED: 21SEPT95 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The proposal is made to include a new keyword [diff_threshold] to set the default value of differential threshold voltage. This is similar in spirit to the use of Lpkg, Rpkg, and Cpkg to set default values for pins. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) An Optional keyword is defined after each [Component] along with the [Manufacturer] and [Package] keywords where component or package defaults are collected. |========================================================================= | Keyword: [Diff_Threshold] | | Required: No | | Description: Specifies the default value for the differential threshold | voltage of a differential input pin pair. If thresholds | are set on individual pin pairs, these override the default | specifed here. | | Usage Rules: This keyword is to be specified only if diffential pin | pairs are specified, although no harm will come from | specifying it otherwise. | |* Delete this (redundant) sentence. |* If diff pins are then not |* specified, only some redundant work is done since an unused |* default is all that is changed and so no harm is done. | |------------------------------------------------------------------------- [Diff_Threshold] 420mv | Set default differential threshold to .420 V | (2) The [Diff_Pin] keyword is modified with changes shown by "|*" : |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The forth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh and | Vinl. | | If vdiff is not defined for a pin that is defined as requiring a | Vinh by its [Model] type, vdiff is set to the default value of | 200mV. | |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | one [Model] to be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | |* Each line must contain two, four or six columns. Only the |* inv_pin header needs to be listed if only two columns are |* entered. The vdiff values use the [Diff_Threshold] value |* if defined and 200mV if not defined for all differential input |* thresholds of Input and I/O pins, and 0V otherwise. All |* tdelay values are set to 0ns. |* |* If four columns are entered, the vdiff and tdelay_typ headers |* must be listed. If six columns are entered, the tdelay_min |* and tdelay_max headers must be listed. |* | If "NA" is | entered in the vdiff, tdelay_typ, or tdelay_min columns, its | entry is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is interpreted as the |* tdelay_typ value. {sentence deleted} |* Remove this sentence: |* When using six columns, the headers |* tdelay_min and tdelay_max must be listed. |* | | Entries for the | tdelay_min column are based on minimum magnitudes; and | tdelay_max column, maximum magnitudes. One entry of vdiff, | regardless of its polarity, is used for difference magnitudes. |--------------------------------------------------------------------------- [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V |* 25 24 | Illustrates a two column format using |* | [Diff_Threshold] value | |============================================================================== ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: We have a differential switch matrix chip for telecom switching ( yes, it is digital! ) which has rather larger threshold than the 200mv provided as a default by the present spec. It also has a large number, several tens, of input pin pairs. It would be desireable to be able to set this threshold without having to specify it on each pin pair. It could still be specified per pin pair, and that specification would override this default. This keyword only specifies a default value other than the fixed value stated in the present spec. This keyword is in exactly the same spirit as the default package parasitics keywords. A [Diff_Pin] two-column format extension is proposed since that will conform to many practical applications, especially with the [Diff_Threshold] default entry method. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: It is conceivable that this keyword could specify typ, min, and max values, but this is not seen as necessary at this time. From myl@awam.com.au Thu Sep 21 17:16:53 1995 Return-Path: Received: from warrane.connect.com.au by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08884; Thu, 21 Sep 95 17:16:53 PDT Received: (from root@localhost) by warrane.connect.com.au with UUCP id KAA10467 (8.6.12/IDA-1.6 for ibis@vhdl.org); Fri, 22 Sep 1995 10:09:44 +1000 Received: from sun2.sunnet (sun2) by sun1.awam.com.au with SMTP id AA04378 (5.67b/IDA-1.5 for ); Fri, 22 Sep 1995 09:32:37 +1000 Date: Fri, 22 Sep 1995 09:32:37 +1000 From: "Raymond Leung (AWA MicroElectronics)" Message-Id: <199509212332.AA04378@sun1.awam.com.au> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From go@helm.cadlab.de Fri Sep 22 00:24:39 1995 Return-Path: Received: from boromir.cadlab.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11675; Fri, 22 Sep 95 00:24:39 PDT Received: from helm.cadlab.de (go@helm.cadlab.de [131.234.81.102]) by boromir.cadlab.de (8.6.9/8.6.5) with SMTP id JAA24209 for ; Fri, 22 Sep 1995 09:17:22 +0200 From: Joachim Mueller Message-Id: <9509220717.AA21410@helm.cadlab.de> Received: by helm.cadlab.de (4.1/12.71); Fri, 22 Sep 95 09:17:20 +0200 Subject: unsubscribe To: ibis@vhdl.org Date: Fri, 22 Sep 1995 09:17:20 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1025 unsubscribe -- +---------------------------------------------------------------------+ | voice: +49 +5251 606-178 | Joachim Mueller, Cadlab | | fax : +49 +5251 606-155 | Fuerstenallee 7, D-33102 Paderborn,| | e-mail: go@cadlab.de | Germany | +---------------------------------------------------------------------+ | cadlab/Analog System Engineering | | - Joint venture University of Paderborn and | | Siemens Nixdorf Informationssysteme AG | | | | __o | | _`\<,_ | | (_)/ (_) | | ~~~~~~~~~~ | +---------------------------------------------------------------------+ From ushrivas@sedona.intel.com Fri Sep 22 08:26:37 1995 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19053; Fri, 22 Sep 95 08:26:37 PDT Received: from sedona.intel.com by hermes.intel.com (5.65/10.0i); Fri, 22 Sep 95 08:19:26 -0700 Received: from tombstone (tombstone.ch.intel.com) by sedona.intel.com with SMTP id AA04392 (5.65c+/IDA-1.4.4 for ); Fri, 22 Sep 1995 08:19:13 -0700 From: Udy Shrivastava -FT-~ Received: by tombstone (AIX 3.2/UCB 5.64/SCDT-RS6000) id AA24885; Fri, 22 Sep 1995 08:19:05 -0700 Date: Fri, 22 Sep 1995 08:19:05 -0700 Message-Id: <9509221519.AA24885@tombstone> To: ibis@vhdl.org Subject: unsubscribe unsubsribe From EGJJ77A@mail.prodigy.com Fri Sep 22 08:36:52 1995 Return-Path: Received: from pimaia1y.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19132; Fri, 22 Sep 95 08:36:52 PDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by pimaia1y.prodigy.com (8.6.10/8.6.9) with SMTP id KAA25276; Fri, 22 Sep 1995 10:57:15 -0400 Date: Fri, 22 Sep 1995 10:54:44 EDT From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] Message-Id: <013.01710611.EGJJ77A@prodigy.com> To: ovidc-arch@chronologic.com, ibis@vhdl.org, roadmap-eii@cfi.org Subject: Minutes of Meeting Relationship DCL, DIET, IBIS and System Delay -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Minutes of Meeting with John Beatty from CFI/OVI Delay 8/29/95 DCL is the standard Delay Calculation Language being proposed by CFI/OVI. DCL may be extended to include variable length arrays and FOR loops to support transmission analysis as requested by CFI. This can be done now by dropping into C. This extension is not in the current proposed standard but is being looked at. DCL is executable and thus can call ASX or SPICE, or RICE, or AWE. AWE out of U. Of Texas Asymptotic Wave Form Evaluation can be called by DCL - Freeware. DCL documents are at cfi.org/public/Cfi/Development/Projects/Alr. DCPIs_date. Sooner or later transmission analysis will be needed on chip as well as off chip. DIET: DIET is inadequate for cores because it depends on buffered drivers which are not dependent on rise time. The dependency on rise time requires the expressive capability of DCL. Tables can be defined in DCL to contain everything that is currently in DIET. IBIS: It appears that DCL could contain all the data is currently in the IBIS model as well. Negative Delays: It appears that the VITAL support for negative delays may only support negative delays in constraint checking. Negative delays have been used inside IBM in bipolar level shifters for example. It is not clear whether the standards support this. Multiple Clock Support in Abstracted Data for Higher Level Processing: DCL could be the proposed standard for abstracted timing data for hierarchical delay verification. It has the capability to represent the results of multiple clocks in one member. DIET has an internal timing point concept and could do the same. IBIS does not seem to have this concept. Ron Christopher From peter.parrish@tanner.com Fri Sep 22 11:21:43 1995 Return-Path: Received: from tanner.com (bastion.tanner.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20285; Fri, 22 Sep 95 11:21:43 PDT Received: by tanner.com (4.1/SMI-4.1) id AA02060; Fri, 22 Sep 95 11:14:36 PDT Received: from unknown(192.100.143.1) by bastion.tanner.com via smap (V1.3) id sma002058; Fri Sep 22 11:14:15 1995 Received: from [192.100.143.19] (petermac) by suntan1.tanner.com (4.1/SMI-4.1) id AA28715; Fri, 22 Sep 95 11:14:12 PDT X-Sender: peter@suntan1.tanner.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Sep 1995 11:16:37 -0800 To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org From: peter.parrish@tanner.com (Peter Parrish) Subject: JOB OPENING AT TANNER RESEARCH Cc: melanie@tanner.com, wedge@tanner.com, peter@tanner.com JOB OPENING AT TANNER RESEARCH--Software Project Manager for MCM CAE Tools Tanner Research, Inc. is a leading vendor of CAD tools for VLSI design on PC, Macintosh and UNIX platforms. The company was founded by Caltech Ph.D. graduate, John Tanner, to research advanced VLSI design techniques and to develop and market tools for IC design needs. We have a growing user base of over 3500 licenses in more than 30 countries and an aggressive product development effort to fuel expanded growth by meeting advancing VLSI and Multi-chip Module technology demands. We are an Equal Employment Opportunity employer. Job Title: Software Project Manager Date Needed: Immediate Date Posted: 9-18-95 Software Project Manager needed to integrate, productize, and advance the development of our CAE tools for multi-chip module design. Duties include contributing to and coordinating the development of physical, electrical, thermal, and mechanical design tools that address the needs of MCM design engineers. The individual will be responsible for integrating schematic, layout, and simulation products to form a cohesive design tool suite. Applicants must possess a B.S. in EE, C.S. or similar discipline with 5 or more years related work experience. M.S. or Ph.D. preferred. Candidates experienced with digital, analog, and mixed-signal MCM design processes and integrated circuit packaging issues will be given priority. General familiarity with CAE tools and C/C++ programming in Unix and PC environments is expected. Individual must be highly motivated, have excellent organizational skills and be willing to manage the efforts of software design engineers working on multiple projects. CODE: CAD1-9/95 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Melanie E. Hamon Tanner Research, Inc. 818-792-3000 Human Resources 180 N. Vinedo Ave. 818-792-0300/fax Pasadena, CA 91107 melanie@tanner.com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From Brett_S_Pemble@ccm2.hf.intel.com Fri Sep 22 12:39:06 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20790; Fri, 22 Sep 95 12:39:06 PDT Received: from relay.hf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0swDpL-000Ul0C; Fri, 22 Sep 95 12:32 PDT Received: from ccm.hf.intel.com by relay.hf.intel.com (Smail3.1.28.1 #2) id m0swDpL-000qDLC; Fri, 22 Sep 95 12:32 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 22 Sep 95 12:32:03 PST Date: Fri, 22 Sep 95 12:32:03 PST From: Brett S Pemble Message-Id: <950922123203_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From scott@icx.com Fri Sep 22 12:44:32 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20796; Fri, 22 Sep 95 12:44:32 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Sep 95 12:37 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Sep 95 12:41 PDT Message-Id: To: ibis@vhdl.org Subject: unsubscribe Date: Fri, 22 Sep 1995 12:41:04 -0700 From: Scott Aron Bloom unsubscribe From mbs@eos.ncsu.edu Sun Sep 24 17:41:41 1995 Return-Path: Received: from ecemws.ncsu.edu (c11039-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17615; Sun, 24 Sep 95 17:41:41 PDT Received: by ecemws.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA03608; Sun, 24 Sep 1995 20:34:36 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509250034.AA03608@ecemws.ncsu.edu> To: ibis@vhdl.org Subject: Model update Date: Sun, 24 Sep 95 20:34:35 EDT National has updated one of their models Directory Structure: /pub/ibis/models/national/superI_O Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes -------------------------------------------------------------------------------- pc87306.ibs superI_O 9-5-95 1.1 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int -------------------------------------------------------------------------------- A full listing of available models will be sent out withni a week when at least one new model will be added. Michael Steer IBIS librarian From rmittra@decwa.ece.uiuc.edu Sun Sep 24 20:16:28 1995 Return-Path: Received: from uxh.cso.uiuc.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18469; Sun, 24 Sep 95 20:16:28 PDT Received: from decwa.ece.uiuc.edu by uxh.cso.uiuc.edu with SMTP id AA11815 (5.67b/IDA-1.5 for ); Sun, 24 Sep 1995 22:09:19 -0500 Received: by decwa.ece.uiuc.edu (5.57/Ultrix3.0-C) id AA29133; Sun, 24 Sep 95 22:09:39 -0500 Date: Sun, 24 Sep 95 22:09:39 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: rmittra@decwa.ece.uiuc.edu (raj mittra) unsubscribe -------------------------------------------------------------------------- Raj Mittra, MC-702, Director Electromagnetic Communication Laboratory, University of Illinois 1406 W. Green Street, Urbana, IL, 61801-2991 Phone(217)333-1202; Fax(217)333-8986, or, 333-7427 Secretary 333-1200; e-mail: sdipert@decwa.ece.uiuc.edu From mbs@eos.ncsu.edu Mon Sep 25 05:51:09 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26405; Mon, 25 Sep 95 05:51:09 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA00991; Mon, 25 Sep 1995 08:44:02 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509251244.AA00991@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: New IBIS model Date: Mon, 25 Sep 95 08:44:02 EDT National announces a new IBIS model 38c86av.ibs cbtl 9-18-95 1.0 1.1 CMOS BTL 9-Bit Latching Data Transceiver This is in the directory vhdl.org::/pub/ibis/models/national/cbtl Michael Steer IBIS Librarian The contents of the model library follows. National Semiconductor Corporation - Advanced Systems & Interface Product Group IBIS Files on vhdl.org as of 9/25/95 Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes -------------------------------------------------------------------------------- ds26c31.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Drvr ds26c32.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Recvr 90c031tm.ibs interface 6/8/95 1.0 2.1 LVDS Quad Diff Line Drvr (NDA only) ** 90c032tm.ibs interface 6/8/95 1.0 2.1 LVDS Quad Diff Line Recvr (NDA only) ** 38c86av.ibs cbtl 9-18-95 1.0 1.1 CMOS BTL 9-Bit Latching Data Transceiver lct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524n.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr c2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2525m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) c2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2527v.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2528m.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528n.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2529v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) 2534v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Commercial) 2535v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) 2536v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) b303m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr 701v.ibs cgs 04-05-95 1.0 1.1 Low Skew PLL 1to8 CMOS Clk Drvr 2537v.ibs cgs 04-17-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) pc87306.ibs superI_O 9-5-95 1.1 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int -------------------------------------------------------------------------------- g612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead g612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead gp612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead gp612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead dp8440vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver dp8441vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver ** submitted by Syed B. Huq Interface Applications Engineer National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com (NDA only) Non disclosure agreement required to obtain model. Contact submitter. Intel Corporation IBIS Files on vhdl.org as of 9/25/95 Part/File vhdl.org alpha rev. rev. IBIS name Directory name date level ver. Notes -------------------------------------------------------------------------------- 82371fb.ibs chipset PIIX 08-09-95 R1.21 V1.1 Triton (NDA only)** 82371mb.ibs chipset MPIIX 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82374eb.ibs chipset ESC 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82374sb.ibs chipset ESC 08-09-95 R1.03 V1.1 PCI-EISA Bridge** 82375eb.ibs chipset PCEB 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82375sb.ibs chipset PCEB 08-09-95 R1.01 V1.1 PCI-EISA Bridge** 82378ib.ibs chipset SIO 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82378zb.ibs chipset SIO 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82379ab.ibs chipset SIO.A 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82423tx.ibs chipset DPU 08-09-95 R2.13 V1.1 Saturn** 82424zx.ibs chipset CDC 08-09-95 R2.13 V1.1 Saturn** 82425ex.ibs chipset PSC 08-09-95 R0.94 V1.1 Aries** 82426ex.ibs chipset IB 08-09-95 R0.94 V1.1 Aries** 82433lx.ibs chipset LBX 08-09-95 R2.13 V1.1 Mercury** 82433nx.ibs chipset LBX 08-09-95 R2.01 V1.1 Neptune** 82434lx.ibs chipset PCMC 08-09-95 R2.13 V1.1 Mercury** 82434nx.ibs chipset PCMC 08-09-95 R2.01 V1.1 Neptune** 82437fx.ibs chipset TSC 08-09-95 R1.21 V1.1 Triton (NDA only)** 82437mx.ibs chipset MTSC 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82437vx.ibs chipset TVX 08-09-95 R1.00 V1.1 Triton VX (NDA only)** 82438fx.ibs chipset TDP 08-09-95 R1.21 V1.1 Triton (NDA only)** 82438mx.ibs chipset MTDP 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82438vx.ibs chipset TDX 08-09-95 R1.00 V1.1 Triton (NDA only)** dx4pga.ibs cpu DX4 05-04-94 R2.0 V1.1 IntelDX4(TM) uP pp66sem.ibs pentium PP66 10-16-94 R3.0 V1.1 66MHz Pentium* pp100sem.ibs pentium PP100 10-15-94 R3.0 V1.1 100MHz Pentium* * Translated from an Intel Simplified Electrical Model. ** submitted by Name of Person Submitting: Arpad Muranyi Address: 1900 Prairie City Road Folsom, CA 95630 Affiliation: Intel Corporation E-Mail: arpad_muranyi@ccm.fm.intel.com Telephone Number: (916) 356-2558 Fax Number: (916) 356-3162 (NDA only) Non disclosure agreement required to obtain model. Contact submitter. From rmittra@decwa.ece.uiuc.edu Mon Sep 25 06:40:58 1995 Return-Path: Received: from uxh.cso.uiuc.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26685; Mon, 25 Sep 95 06:40:58 PDT Received: from decwa.ece.uiuc.edu by uxh.cso.uiuc.edu with SMTP id AA23935 (5.67b/IDA-1.5 for ); Mon, 25 Sep 1995 08:33:54 -0500 Received: by decwa.ece.uiuc.edu (5.57/Ultrix3.0-C) id AA00227; Mon, 25 Sep 95 08:34:16 -0500 Date: Mon, 25 Sep 95 08:34:16 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: rmittra@decwa.ece.uiuc.edu (raj mittra) Subject: unsubscribe unsubscribe -------------------------------------------------------------------------- Raj Mittra, MC-702, Director Electromagnetic Communication Laboratory, University of Illinois 1406 W. Green Street, Urbana, IL, 61801-2991 Phone(217)333-1202; Fax(217)333-8986, or, 333-7427 Secretary 333-1200; e-mail: sdipert@decwa.ece.uiuc.edu From Brett_S_Pemble@ccm2.hf.intel.com Mon Sep 25 10:03:12 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28268; Mon, 25 Sep 95 10:03:12 PDT Received: from relay.hf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sxGoz-000Uj2C; Mon, 25 Sep 95 09:56 PDT Received: from ccm.hf.intel.com by relay.hf.intel.com (Smail3.1.28.1 #2) id m0sxGoz-000qDLC; Mon, 25 Sep 95 09:56 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 25 Sep 95 09:56:01 PST Date: Mon, 25 Sep 95 09:56:01 PST From: Brett S Pemble Message-Id: <950925095601_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From uunet!qdt.com!jonp@uunet.uu.net Mon Sep 25 13:25:22 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00402; Mon, 25 Sep 95 13:25:22 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzitl00286; Mon, 25 Sep 1995 16:17:43 -0400 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Mon, 25 Sep 1995 16:17:58 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00682; Mon, 25 Sep 95 10:54:46 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA10612; Mon, 25 Sep 95 10:51:45 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQzita21263; Mon, 25 Sep 1995 13:40:03 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 25 Sep 1995 13:40:28 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00472; Mon, 25 Sep 95 09:05:57 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09603; Mon, 25 Sep 95 09:04:30 PDT Date: Mon, 25 Sep 95 09:04:30 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9509251604.AA09603@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA01805; Mon, 25 Sep 95 09:02:58 PDT To: uunet!uunet!prodigy.com!EGJJ77A@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!qdt.com!jonp@uunet.uu.net, uunet!qdt.com!chuck@uunet.uu.net In-Reply-To: <013.01548688.EGJJ77A@prodigy.com> (uunet!prodigy.com!EGJJ77A) Subject: Re: Use of IBIS Quad supports IBIS for static timing verification in the following manner (which we consider the right way to do it, by the way): XTK uses IBIS to model transmission line effects for highly accurate analog simulations. From these Simulations and knowledge of Time to VM for the driver and logic thresholds for the receiver we calculate min max pin to pin delay data which is communicated to MOTIVE (our static timing analysis tool) thourgh IDD or SDF file formats. Regards, jon powell quad design From Will_Hobbs@ccm.jf.intel.com Tue Sep 26 17:28:21 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20943; Tue, 26 Sep 95 17:28:21 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sxkFM-000UyOC; Tue, 26 Sep 95 17:21 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sxkFM-000txHC; Tue, 26 Sep 95 17:21 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Tue, 26 Sep 95 17:21:12 PDT Date: Tue, 26 Sep 95 17:18:00 PDT From: Will Hobbs Message-Id: To: EGJJ77A@mail.prodigy.com, ibis@vhdl.org Subject: Re: Bird 28.3 and IBIS Package Limitations Text item: Ron, There is a lot of desire on the part of IBIS participants to support MCMs and SIMMs, and my crystal ball says we will resolve the issues of this support in the next year. The issues primarily revolve around how to represent the data-- physical description (gerber, length/width/direction/etc. matrix, ...), or electrical equivalent, SPICE notation, or some other format? Our current Bird 28.3 is aimed at creating a package description (such as a PGA, BGA, PQFP, etc.), not an MCM description, and we've chosen to separate the two areas of concern so that we can move forward more quickly. Watch for early and on-going activity in the MCM/SIMM arena in the coming months. Will -- [ From: Ron Christopher * EMC.Ver #2.10P ] -- Is it generally agreed to that IBIS does not support MCM or SIMM Modules per the description in Bird 28.3? Is there a requirement for support for these packages? Is it in the IBIS plan to extend to support these packages and should I mention this coming extension in the 10 year roadmap? Ron Christopher 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 28.3 and IBIS Package Limitations To: ibis@vhdl.org Message-Id: <013.01610195.EGJJ77A@prodigy.com> X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56] From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Wed, 20 Sep 1995 16:54:44 EDT Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by pimaia1y.pr odigy.com (8.6.10/8.6.9) with SMTP id QAA29416 for ; Wed, 20 Sep 1995 16:57:00 -0400 Received: from pimaia1y.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26094; Thu, 21 Sep 95 01:07:02 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 21 Sep 95 01 :45:13 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 21 Sep 9 5 01:45:23 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0svhG1-000twkC; Thu, 21 Sep 95 01:45 PDT From Will_Hobbs@ccm.jf.intel.com Tue Sep 26 17:40:14 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21061; Tue, 26 Sep 95 17:40:14 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sxkQp-000UyfC; Tue, 26 Sep 95 17:33 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0sxkQo-000txRC; Tue, 26 Sep 95 17:33 PDT Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Tue, 26 Sep 95 17:33:02 PDT Date: Tue, 26 Sep 95 17:29:00 PDT From: Will Hobbs Message-Id: To: bob@icx.com, ibis@vhdl.org Subject: Re: BIRD27.1 DIFFERENTIAL THRESHOLD Text item: Bob, et al, A point of order: You (Bob Ross) already issued revision 27.1 on 5/29/95. This revision is therefore 27.2. Will To IBIS Committee: BIRD27.1 is an IBIS Version 3.0 proposal to provide/change the diff_pin default threshold and also to provide a simplier syntax for the [Diff_Pin] entries. This issue was deferred while the IBIS Version 2.1 ratification discussion was taking place. It is now presented for consideration an/or a vote. Bob Ross, Interconnectix, Inc. Buffer Issue Resolution Document (BIRD) BIRD ID#: 27.1 ISSUE TITLE: Propose new keyword to specify default differential threshold REQUESTOR: Bob Ward, Texas Instruments & Bob Ross, Inteconnectix, Inc. DATE SUBMITTED: 03APR95 DATE MODIFIED: 21SEPT95 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The proposal is made to include a new keyword [diff_threshold] to set the default value of differential threshold voltage. This is similar in spirit to the use of Lpkg, Rpkg, and Cpkg to set default values for pins. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) An Optional keyword is defined after each [Component] along with the [Manufacturer] and [Package] keywords where component or package defaults are collected. |========================================================================= | Keyword: [Diff_Threshold] | | Required: No | | Description: Specifies the default value for the differential threshold | voltage of a differential input pin pair. If thresholds | are set on individual pin pairs, these override the default | specifed here. | | Usage Rules: This keyword is to be specified only if diffential pin | pairs are specified, although no harm will come from | specifying it otherwise. | |* Delete this (redundant) sentence. |* If diff pins are then not |* specified, only some redundant work is done since an unused |* default is all that is changed and so no harm is done. | |------------------------------------------------------------------------- [Diff_Threshold] 420mv | Set default differential threshold to .420 V | (2) The [Diff_Pin] keyword is modified with changes shown by "|*" : |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The forth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh and | Vinl. | | If vdiff is not defined for a pin that is defined as requiring a | Vinh by its [Model] type, vdiff is set to the default value of | 200mV. | |Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the | inv_pin column is Inverting. This convention enables | one [Model] to be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | |* Each line must contain two, four or six columns. Only the |* inv_pin header needs to be listed if only two columns are |* entered. The vdiff values use the [Diff_Threshold] value |* if defined and 200mV if not defined for all differential input |* thresholds of Input and I/O pins, and 0V otherwise. All |* tdelay values are set to 0ns. |* |* If four columns are entered, the vdiff and tdelay_typ headers |* must be listed. If six columns are entered, the tdelay_min |* and tdelay_max headers must be listed. |* | If "NA" is | entered in the vdiff, tdelay_typ, or tdelay_min columns, its | entry is interpreted as 0V or 0ns. If "NA" appears in | the tdelay_max column, its value is interpreted as the |* tdelay_typ value. {sentence deleted} |* Remove this sentence: |* When using six columns, the headers |* tdelay_min and tdelay_max must be listed. |* | | Entries for the | tdelay_min column are based on minimum magnitudes; and | tdelay_max column, maximum magnitudes. One entry of vdiff, | regardless of its polarity, is used for difference magnitudes. |--------------------------------------------------------------------------- [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0ns 22 21 NA NA | Output*, tdelay = 0ns | * Could be Input or I/O with vdiff = 0V |* 25 24 | Illustrates a two column format using |* | [Diff_Threshold] value | |============================================================================== ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: We have a differential switch matrix chip for telecom switching ( yes, it is digital! ) which has rather larger threshold than the 200mv provided as a default by the present spec. It also has a large number, several tens, of input pin pairs. It would be desireable to be able to set this threshold without having to specify it on each pin pair. It could still be specified per pin pair, and that specification would override this default. This keyword only specifies a default value other than the fixed value stated in the present spec. This keyword is in exactly the same spirit as the default package parasitics keywords. A [Diff_Pin] two-column format extension is proposed since that will conform to many practical applications, especially with the [Diff_Threshold] default entry method. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: It is conceivable that this keyword could specify typ, min, and max values, but this is not seen as necessary at this time. 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: BIRD27.1 DIFFERENTIAL THRESHOLD To: ibis@vhdl.org From: bob@icx.com ( Bob Ross) Date: Thu, 21 Sep 95 09:26 PDT Message-Id: Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 21 Sep 95 09:26 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 21 Sep 95 09:23 PDT Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05842; Thu, 21 Sep 95 09:31:00 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 21 Sep 95 10 :30:04 -0700 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 21 Sep 9 5 10:30:17 -0700 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0svpS0-000txYC; Thu, 21 Sep 95 10:30 PDT From mbs@eos.ncsu.edu Thu Sep 28 06:13:55 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15619; Thu, 28 Sep 95 06:13:55 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA12943; Thu, 28 Sep 1995 09:06:49 -0400 From: mbs@eos.ncsu.edu Message-Id: <9509281306.AA12943@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: S2IBIS update Date: Thu, 28 Sep 95 09:06:48 EDT S2IBIS has been updated The new version is 2.091 (in the directory /pub/ibis/s2ibis/...) Changes from the previous and initial version are 1. The names of the tar and zip files were shortened. 2. Some users were experiencing problems using s2ibis2 with HSpice--the program would hang in an infinite loop when reading HSpice output files. This has been corrected. 3. The sample files distributed with s2ibis2 used spice node 0 for the ground pin of the device. Some versions of spice would complain when s2ibis2 connected a voltage source between this node and the absolute reference node (node 0). The sample files now use spice node 98 for the ground pin node. In general, it's best not to use node 0 for the ground pin for this very reason. Michael Steer IBIS Librarian From scott_bloom@MENTORG.COM Thu Sep 28 10:20:19 1995 Return-Path: Received: from newsgw.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18204; Thu, 28 Sep 95 10:20:19 PDT Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id NAA23490; Thu, 28 Sep 1995 13:12:36 -0400 Received: from em-wv03.wv.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id KAA23905; Thu, 28 Sep 1995 10:13:10 -0700 Received: from neon by em-wv03.wv.mentorg.com (8.6.8.1/CF5.23H) id KAA18213; Thu, 28 Sep 1995 10:13:39 -0700 Received: from localhost by neon (1.38.193.4/CF5.23L) id AA06023; Thu, 28 Sep 1995 10:13:07 -0700 Message-Id: <9509281713.AA06023@neon> To: ibis@vhdl.org Subject: subscribe Date: Thu, 28 Sep 95 10:13:07 PDT From: Scott Bloom subscribe thanks Scott: From fabrizio_zanella@smtpgate.tcs.teradyne.com Fri Sep 29 14:27:15 1995 Return-Path: Received: from smtpgate.tcs.teradyne.com (tcsmail.tcs.teradyne.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07230; Fri, 29 Sep 95 14:27:15 PDT Message-Id: Date: 29 Sep 1995 17:16:45 U From: "FABRIZIO ZANELLA" Subject: unsuscribe To: "ibis Org" X-Mailer: Mail*Link SMTP-QM 3.0.2 REGARDING unsuscribe Please unsuscribe me from the ibis reflector mail list Thank you, Fabrizio Zanella fab@tcs.teradyne.com From bob@icx.com Sat Sep 30 11:38:18 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19229; Sat, 30 Sep 95 11:38:18 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 30 Sep 95 11:27 PDT Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 30 Sep 95 11:33 PDT Message-Id: Date: Sat, 30 Sep 95 11:33 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA 10/6/95 IBIS Open Forum Meeting Agenda for 10/06/95 Bridge Number Reservation # Passcode (303) 633-2197 1-308636 No pass code 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 Hobbs - Intros of New IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Rusher/Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press Updates All - New Models Available, Library Update All - Opens for New Issues All 8:10 EIA IBIS Ratification - EIA/ANSI Ratification Progress Hobbs/Rusher - Press Release Discussion Hobbs/Rusher 8:20 Administrative and Project Discussions Face-to-face meeting Hobbs Web Project Update Huq Model Usage Tracking on vhdl.org Huq/Steer Golden Parser 2.1 Status Hobbs S2IBIS 2.1 Status Kumar/Steer Version 2.1 Cookbook and Overview Chrisafulli/Ross New Administrative Issues All 9:00 Technical Discussions BIRD 27.1 (.2) - New Keyword for Differential I/O Ross BIRD 28.3 - Package Model Extension Peters BIRD 30.1 - Pin Programmable Buffer Strengths Muranyi Egg 6 - CMOS and TTL Data Powell Non-monotonic Drivers, Roadmap timing Christopher Physical Package Description Discussion Crisafulli New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off