From owner-ibis Fri Feb 2 07:00:39 2001 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f12F0bH07703 for ; Fri, 2 Feb 2001 07:00:39 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA147446; Fri, 2 Feb 2001 09:55:43 -0500 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA114650; Fri, 2 Feb 2001 09:53:19 -0500 Importance: Normal Subject: Re: PCI and IBIS To: Syed Huq Cc: ibis@vhdl.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Gregory R Edlund" Date: Fri, 2 Feb 2001 08:58:18 -0600 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.5 |September 22, 2000) at 02/02/2001 08:58:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Syed, I asked this question two years ago. Here are the answers I got. Greg Edlund Advisory Engineer Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com To All: The IBIS Version 3.1 format could theoretically handle this multiple test load situation by using the [Model Selector] keyword to reference individual [Model] keywords containing the same information except for the individually specified test loads. However, it is likely that the user would to manually manage the analysis for testing the design corners. Bob Ross Interconnectix/Mentor Graphics Hi Greg, I ran into this exact problem when I was trying to set up a simulation environment for the 66 MHz PCI bus. Fortunately, the IBIS simulator I am using allows me to choose whether I want the buffer delays to come from a simulation into the standard load circuit from the IBIS model or from time values which I directly give to the simulator. So what I did was use Spice to measure the rise and fall delays into their respective standard load circuits; I then gave those Spice generated numbers to my IBIS simulator. Not an ideal solution, but a workaround that worked good enough. Unfortunately, this solution doesn't help you much if you can't directly give buffer delays to your simulator. The ideal solution would be to enhance the IBIS spec to allow for a unique standard load circuit for both the rising and falling edges; that is, if this is a common problem. Or is this pretty much an isolated case with the 66 MHz PCI spec? Regards, Tay Ansari Sun Microsystems We had a similar problem with a Motorola MPC750. The L2 cache MAX timing numbers are specified to a 20pF load and the MIN numbers to a 5pF load. We were using ICX to analyze timing. We looked at the output under no load, then at 20pF and 5pF. The delta was measured to be 477ps. We then adjusted the timing sheets in ICX so that the minimum allowed routing distance was effectively increased by 477ps to compensate for the additional 'test' load. This allowed us to use a single IBIS model with Cref set at 20pF. You may be able to apply a similar 'trick' with the PCI driver and Vref. David Haedge Raytheon Systems Company Greg, You can put the two Vref numbers into the IBIS model and comment one of them out. Unfortunately this means that you have to simulate things twice (with most IBIS based simulators), but fortunately the waveforms are not effected by this, only the flight time measurements. So one of the simulations could do the falling edge measurements, and the other one the rising edge measurements. If you need more detail send me another EMAIL, and I will give you an example. Arpad Muranyi Intel Corporation ============================================================================ A question came up here at IBM today that I could not answer. Has anyone run into this? The 66 MHz PCI bus spec has a different standard load for rising and falling edges. (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for falling.) As I read version 3.1 of IBIS, it only allows one value of Vref per [Model] keyword. This seems to make the 66 MHz PCI driver unable to be implemented in IBIS, at least if you want to do timing analysis. I would think someone else probably encountered this already. How did you get around it? Or am I missing something? Much thanks in advance. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com Syed Huq on 02/01/2001 11:32:09 PM Please respond to Syed Huq To: ibis-users@eda.org cc: Subject: PCI and IBIS IBISgurus: The PCI spec mentions of multiple Vmeas data points based on Rising edge or Falling edge. Since IBIS has only one Vmeas for any Output/I_O etc, how does the model provider spec the PCI Vmeas values ? Regards, Syed Cisco Systems, Inc From owner-ibis Fri Feb 2 07:57:42 2001 Received: from selene.cps.intel.com (selene.cps.intel.com [192.198.165.10]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f12FveH08101 for ; Fri, 2 Feb 2001 07:57:41 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id HAA03056 for ; Fri, 2 Feb 2001 07:53:46 -0800 (PST) Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 02 Feb 2001 15:53:46 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Feb 2001 07:53:45 -0800 Message-ID: <10C8636AE359D4119118009027AE9987051551EB@FMSMSX34> From: "Muranyi, Arpad" To: ibis@vhdl.org Subject: RE: PCI and IBIS Date: Fri, 2 Feb 2001 07:53:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" The problem with Bob's response from two years ago is that you can't swith between buffers with the model selector for rising and another one for falling edge... Arpad ========================================================== -----Original Message----- From: Gregory R Edlund [mailto:gedlund@us.ibm.com] Sent: Friday, February 02, 2001 6:58 AM To: Syed Huq Cc: ibis@vhdl.org Subject: Re: PCI and IBIS Syed, I asked this question two years ago. Here are the answers I got. Greg Edlund Advisory Engineer Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com To All: The IBIS Version 3.1 format could theoretically handle this multiple test load situation by using the [Model Selector] keyword to reference individual [Model] keywords containing the same information except for the individually specified test loads. However, it is likely that the user would to manually manage the analysis for testing the design corners. Bob Ross Interconnectix/Mentor Graphics Hi Greg, I ran into this exact problem when I was trying to set up a simulation environment for the 66 MHz PCI bus. Fortunately, the IBIS simulator I am using allows me to choose whether I want the buffer delays to come from a simulation into the standard load circuit from the IBIS model or from time values which I directly give to the simulator. So what I did was use Spice to measure the rise and fall delays into their respective standard load circuits; I then gave those Spice generated numbers to my IBIS simulator. Not an ideal solution, but a workaround that worked good enough. Unfortunately, this solution doesn't help you much if you can't directly give buffer delays to your simulator. The ideal solution would be to enhance the IBIS spec to allow for a unique standard load circuit for both the rising and falling edges; that is, if this is a common problem. Or is this pretty much an isolated case with the 66 MHz PCI spec? Regards, Tay Ansari Sun Microsystems We had a similar problem with a Motorola MPC750. The L2 cache MAX timing numbers are specified to a 20pF load and the MIN numbers to a 5pF load. We were using ICX to analyze timing. We looked at the output under no load, then at 20pF and 5pF. The delta was measured to be 477ps. We then adjusted the timing sheets in ICX so that the minimum allowed routing distance was effectively increased by 477ps to compensate for the additional 'test' load. This allowed us to use a single IBIS model with Cref set at 20pF. You may be able to apply a similar 'trick' with the PCI driver and Vref. David Haedge Raytheon Systems Company Greg, You can put the two Vref numbers into the IBIS model and comment one of them out. Unfortunately this means that you have to simulate things twice (with most IBIS based simulators), but fortunately the waveforms are not effected by this, only the flight time measurements. So one of the simulations could do the falling edge measurements, and the other one the rising edge measurements. If you need more detail send me another EMAIL, and I will give you an example. Arpad Muranyi Intel Corporation ============================================================================ A question came up here at IBM today that I could not answer. Has anyone run into this? The 66 MHz PCI bus spec has a different standard load for rising and falling edges. (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for falling.) As I read version 3.1 of IBIS, it only allows one value of Vref per [Model] keyword. This seems to make the 66 MHz PCI driver unable to be implemented in IBIS, at least if you want to do timing analysis. I would think someone else probably encountered this already. How did you get around it? Or am I missing something? Much thanks in advance. Greg Edlund Advisory Engineer, AS/400 System Timing IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com Syed Huq on 02/01/2001 11:32:09 PM Please respond to Syed Huq To: ibis-users@eda.org cc: Subject: PCI and IBIS IBISgurus: The PCI spec mentions of multiple Vmeas data points based on Rising edge or Falling edge. Since IBIS has only one Vmeas for any Output/I_O etc, how does the model provider spec the PCI Vmeas values ? Regards, Syed Cisco Systems, Inc From owner-ibis Fri Feb 2 13:32:30 2001 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f12LWRH09675 for ; Fri, 2 Feb 2001 13:32:29 -0800 (PST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id VAA19197 for ; Fri, 2 Feb 2001 21:29:58 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 02 Feb 2001 21:28:33 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21) id <1B4GGMXX>; Fri, 2 Feb 2001 13:28:32 -0800 Message-ID: <10C8636AE359D4119118009027AE9987051551F2@FMSMSX34> From: "Muranyi, Arpad" To: "'ibis@eda.org'" Subject: BIRD 65.2 Date: Fri, 2 Feb 2001 13:28:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C08D5F.15355480" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C08D5F.15355480 Content-Type: text/plain; charset="ISO-8859-1" **************************************************************************** ** **************************************************************************** ** BIRD ID#: 65.2 ISSUE TITLE: C_comp Refinements REQUESTER: Arpad Muranyi, Intel DATE SUBMITTED: 10-25-99, 12-12-2000, 2-2-2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending **************************************************************************** ** **************************************************************************** ** STATEMENT OF THE ISSUE: Currently, the IBIS specification (v3.2) uses a single constant value for describing the total die capacitance as seen at the pad. This value is given by the subparameter C_comp under the [Model] keyword. The specification does not mention how this capacitance is distributed between the power and ground references, or how it should be connected to the circuit. **************************************************************************** ** STATEMENT OF THE RESOLVED SPECIFICATIONS: Four new subparameters shall be introduced in the IBIS specification under the [Model] keyword to provide means for a more detailed description for the die capacitance. These new subparameters, C_comp_pullup, C_comp_pulldown, C_comp_power, and C_comp_gnd are associated with the corresponding voltage reference keywords, [Pullup Reference], [Pulldown Reference], [Power Clamp Reference], and [GND Clamp Reference], respectively. This mechanism allows the association of a specific capacitance between the I/O node and the four possible supply nodes without disturbing the submodel syntax. The syntax of these four new subparameters are identical to the existing C_comp subparameter. |=========================================================================== == | Keyword: [Model] | Required: Yes. | Description: Used to define a model, and its attributes. | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, |** C_comp_pullup, C_comp_pulldown, C_comp_power, and |** C_comp_gnd Vmeas, Cref, Rref, Vref | Usage Rules: Each model type must begin with the keyword [Model]. The | model name must match the one that is listed under a [Pin], | [Model Selector] or [Series Pin Mapping] keyword and must not | contain more than 20 characters. A .ibs file must contain | enough [Model] keywords to cover all of the model names | specified under the [Pin], [Model Selector] and [Series Pin | Mapping] keywords, except for those model names that use | reserved words (POWER, GND and NC). | | Model_type must be one of the following: | | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, 3-state_ECL, Terminator, | Series, and Series_switch. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl = 0.8 V and Vinh = 2.0 V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl = -1.475 V and Vinh = | -1.165 V are assumed. | | Terminator This model type is an input-only model | that can have analog loading effects on the | circuit being simulated but has no digital | logic thresholds. Examples of Terminators | are: capacitors, termination diodes, and | pullup resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | | 3-state This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | | Open_sink These model types indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = | 0 mA for all voltages specified) and the | output SINKS current. Open_drain model | type is retained for backward | compatibility. | | Open_source This model type indicates that the output | has an OPEN side (do not use the [Pulldown] | keyword, or if it must be used, set I = | 0 mA for all voltages specified) and the | output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | 3-state_ECL keyword. | | Series This model type is for series models that | can be described by [R Series], [L Series], | [Rl Series], [C Series], [Lc Series], | [Rc Series], [Series Current] and [Series | MOSFET] keywords | | Series_switch This model type is for series switch | models that can be described by [On], | [Off], [R Series], [L Series], [Rl Series], | [C Series], [Lc Series], [Rc Series], | [Series Current] and [Series MOSFET] | keywords | |** The Model_type subparameter is required. The C_comp |** subparameter is only required if C_comp_pullup, |** C_comp_pulldown, C_comp_power, and C_comp_gnd are not |*** present. If the C_comp subparameter is not present at least |*** one of the C_comp_pullup, C_comp_pulldown, C_comp_power, and |*** C_comp_gnd subparameters is required. It is not illegal |*** to define all five of these subparameters, but in that case |*** the simulator tool will have to make a decision whether |*** to use the old C_comp subparameter or the new C_comp_* |*** subparameters. Under no circumstances should all five |*** subparameters be used simultaneously. | | The Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref |* subparameters are optional. C_comp* define the silicon die |* capacitance. Thse values should not include the capacitance |* of the package. C_comp* are allowed to use "NA" for the min | and max values only. The Polarity subparameter can be | defined as either Non-Inverting or Inverting, and the Enable | subparameter can be defined as either Active-High or | Active-Low. | | The Cref and Rref subparameters correspond to the test load | that the semiconductor vendor uses when specifying the | propagation delay and/or output switching time of the model. | The Vmeas subparameter is the reference voltage level that the | semiconductor vendor uses for the model. Include Cref, Rref, | Vref, and Vmeas information to facilitate board-level timing | simulation. The assumed connections for Cref, Rref, and Vref | are shown in the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one or | more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, some | models may have only a subset of these keywords. For example, | an input structure normally only needs the [Voltage Range], | [GND Clamp], and possibly the [POWER Clamp] keywords. If one | or more of [Rgnd], [Rpower], [Rac], and [Cac] keywords are | used, then the Model_type must be Terminator. |--------------------------------------------------------------------------- -- | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V | Reference voltage for timing measurements Cref = 50pF | Timing specification test load capacitance value Rref = 500 | Timing specification test load resistance value Vref = 0 | Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |=========================================================================== == | [Model] Clockbuffer Model_type I/O Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any | | variable typ min max C_comp_pullup 3.0pF 2.5pF 3.5pF C_comp_pulldown 2.0pF 1.5pF 2.5pF C_comp_power 1.0pF 0.5pF 1.5pF C_comp_gnd 1.0pF 0.5pF 1.5pF | **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Problem statement The single (constant) C_comp value of the current IBIS specification (v3.2) does not provide enough information for the simulator to accurately simulate high speed signals and/or ground and supply noise. In order to simulate the signal current return path and/or supply rail noise (GND bounce and/or Vcc droop) accurately, a model needs to provide more detail on the distribution of the total die capacitance between the I/O pad, power and ground references. This BIRD attempts to provide the means for incorporating such information in a model. The existing C_comp subparameter does not specify how it should be connected between the I/O pad and the supply rails. Most naturally it will end up getting connected to the I/O node and ground. However, since it not only represents the capacitance of the pulldown device, but also the capacitance of the pullup device, one should split it between the I/O pin and ground, and the I/O pin and power rails. One can easily see that this configuration forms a series combination of two capacitances between power and ground. Simulations show a significant difference in the waveforms for the distributed or lumped capacitance when power and ground nodes of the die are connected through the package parasitics to the ideal power source(s). Possible solutions 1) Specify splitting factor coefficients 2) Use a new subparameter under each voltage reference keyword 3) Use a new subparameter under each I-V curve 4) Use four new subparameters under the [Model] keyword (as presented in this BIRD). **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: Changed the names for the four C_comp* parameters as requested in the 12-08-2000 IBIS Open Forum Teleconference meeting. Added the next paragraph. Transistors (consequently buffers) show different parasitic capacitance when turned on or off. Additional mechanisms need to be added to the IBIS specification to account for these variations. The voltage dependency of the die capacitance should also be addressed at some point. (Use typ., min., max, capacitance vs. voltage tables instead of single values)? **************************************************************************** ** ------_=_NextPart_000_01C08D5F.15355480 Content-Type: text/plain; name="BIRD65_2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="BIRD65_2.txt" ************************************************************************= ****** ************************************************************************= ****** BIRD ID#: 65.2 ISSUE TITLE: C_comp Refinements REQUESTER: Arpad Muranyi, Intel DATE SUBMITTED: 10-25-99, 12-12-2000, 2-2-2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ************************************************************************= ****** ************************************************************************= ****** STATEMENT OF THE ISSUE: Currently, the IBIS specification (v3.2) uses a single constant value = for describing the total die capacitance as seen at the pad. This value is = given by the subparameter C_comp under the [Model] keyword. The = specification does not mention how this capacitance is distributed between the power and = ground references, or how it should be connected to the circuit. ************************************************************************= ****** STATEMENT OF THE RESOLVED SPECIFICATIONS: Four new subparameters shall be introduced in the IBIS specification = under the [Model] keyword to provide means for a more detailed description = for the die capacitance. These new subparameters, C_comp_pullup, = C_comp_pulldown, C_comp_power, and C_comp_gnd are associated with the corresponding = voltage reference keywords, [Pullup Reference], [Pulldown Reference], [Power = Clamp Reference], and [GND Clamp Reference], respectively. This mechanism = allows the association of a specific capacitance between the I/O node and the = four possible supply nodes without disturbing the submodel syntax. The syntax of these four new subparameters are identical to the = existing C_comp subparameter. |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D | Keyword: [Model]=20 | Required: Yes. | Description: Used to define a model, and its attributes. | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, |** C_comp_pullup, C_comp_pulldown, C_comp_power, and |** C_comp_gnd Vmeas, Cref, Rref, Vref | Usage Rules: Each model type must begin with the keyword [Model]. = The | model name must match the one that is listed under a = [Pin], | [Model Selector] or [Series Pin Mapping] keyword and = must not | contain more than 20 characters. A .ibs file must = contain | enough [Model] keywords to cover all of the model names | specified under the [Pin], [Model Selector] and [Series = Pin | Mapping] keywords, except for those model names that = use | reserved words (POWER, GND and NC). | | Model_type must be one of the following: | | Input, Output, I/O, 3-state, Open_drain, = I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, 3-state_ECL, = Terminator, | Series, and Series_switch. | | Special usage rules apply to the following. Some = definitions | are included for clarification: | | Input These model types must have Vinl and = Vinh | I/O defined. If they are not defined, = the | I/O_open_drain parser issues a warning and the = default | I/O_open_sink values of Vinl =3D 0.8 V and Vinh = =3D 2.0 V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and = Vinh | I/O_ECL defined. If they are not defined, = the | parser issues a warning and the = default | values of Vinl =3D -1.475 V and Vinh = =3D | -1.165 V are assumed. | | Terminator This model type is an input-only = model | that can have analog loading effects = on the | circuit being simulated but has no = digital | logic thresholds. Examples of = Terminators | are: capacitors, termination diodes, = and | pullup resistors. | | Output This model type indicates that an = output | always sources and/or sinks current = and | cannot be disabled. | | 3-state This model type indicates that an = output | can be disabled, i.e. put into a = high | impedance state. | | Open_sink These model types indicate that the = output | Open_drain has an OPEN side (do not use the = [Pullup] | keyword, or if it must be used, set = I =3D | 0 mA for all voltages specified) and = the | output SINKS current. Open_drain = model | type is retained for backward | compatibility. | | Open_source This model type indicates that the = output | has an OPEN side (do not use the = [Pulldown] | keyword, or if it must be used, set = I =3D | 0 mA for all voltages specified) and = the | output SOURCES current. | | Input_ECL These model types specify that the = model | Output_ECL represents an ECL type logic that = follows | I/O_ECL different conventions for the = [Pulldown] | 3-state_ECL keyword. | | Series This model type is for series models = that | can be described by [R Series], [L = Series], | [Rl Series], [C Series], [Lc = Series], | [Rc Series], [Series Current] and = [Series | MOSFET] keywords | =20 | Series_switch This model type is for series switch | models that can be described by = [On], | [Off], [R Series], [L Series], [Rl = Series], =20 | [C Series], [Lc Series], [Rc = Series], | [Series Current] and [Series MOSFET] | keywords | |** The Model_type subparameter is required. The C_comp |** subparameter is only required if C_comp_pullup, |** C_comp_pulldown, C_comp_power, and C_comp_gnd are not |*** present. If the C_comp subparameter is not present at = least |*** one of the C_comp_pullup, C_comp_pulldown, = C_comp_power, and |*** C_comp_gnd subparameters is required. It is not = illegal=20 |*** to define all five of these subparameters, but in that = case |*** the simulator tool will have to make a decision whether = |*** to use the old C_comp subparameter or the new C_comp_* |*** subparameters. Under no circumstances should all five |*** subparameters be used simultaneously. | | The Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, = and Vref |* subparameters are optional. C_comp* define the silicon = die |* capacitance. Thse values should not include the = capacitance |* of the package. C_comp* are allowed to use "NA" for = the min | and max values only. The Polarity subparameter can be | defined as either Non-Inverting or Inverting, and the = Enable | subparameter can be defined as either Active-High or | Active-Low. | | The Cref and Rref subparameters correspond to the test = load | that the semiconductor vendor uses when specifying the | propagation delay and/or output switching time of the = model. | The Vmeas subparameter is the reference voltage level = that the | semiconductor vendor uses for the model. Include Cref, = Rref, | Vref, and Vmeas information to facilitate board-level = timing | simulation. The assumed connections for Cref, Rref, = and Vref | are shown in the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | =3D=3D=3D Cref | |_________| | | | | GND | | Other Notes: A complete [Model] description normally contains the = following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND = Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one = or | more of the [Rgnd], [Rpower], [Rac], and [Cac]. = However, some | models may have only a subset of these keywords. For = example, | an input structure normally only needs the [Voltage = Range], | [GND Clamp], and possibly the [POWER Clamp] keywords. = If one | or more of [Rgnd], [Rpower], [Rac], and [Cac] keywords = are | used, then the Model_type must be Terminator. |-----------------------------------------------------------------------= ------ | Signals CLK1, CLK2,... | Optional signal list, if = desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl =3D 0.8V | input logic "low" DC = voltage, if any Vinh =3D 2.0V | input logic "high" DC = voltage, if any Vmeas =3D 1.5V | Reference voltage for timing measurements Cref =3D 50pF | Timing specification test load = capacitance value Rref =3D 500 | Timing specification test load resistance = value Vref =3D 0 | Timing specification test load voltage | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D | [Model] Clockbuffer Model_type I/O Vinl =3D 0.8V | input logic "low" DC = voltage, if any Vinh =3D 2.0V | input logic "high" DC = voltage, if any | | variable typ min max C_comp_pullup 3.0pF 2.5pF 3.5pF C_comp_pulldown 2.0pF 1.5pF 2.5pF C_comp_power 1.0pF 0.5pF 1.5pF C_comp_gnd 1.0pF 0.5pF 1.5pF | ************************************************************************= ****** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Problem statement The single (constant) C_comp value of the current IBIS specification = (v3.2) does not provide enough information for the simulator to accurately = simulate high speed signals and/or ground and supply noise. In order to simulate the signal current return path and/or supply rail = noise (GND bounce and/or Vcc droop) accurately, a model needs to provide more detail on the distribution of the total die capacitance between the I/O = pad, power and ground references. This BIRD attempts to provide the means = for incorporating such information in a model. The existing C_comp subparameter does not specify how it should be = connected between the I/O pad and the supply rails. Most naturally it will end = up getting connected to the I/O node and ground. However, since it not = only represents the capacitance of the pulldown device, but also the = capacitance of the pullup device, one should split it between the I/O pin and ground, = and the I/O pin and power rails. One can easily see that this configuration = forms a series combination of two capacitances between power and ground. = Simulations show a significant difference in the waveforms for the distributed or = lumped capacitance when power and ground nodes of the die are connected = through the package parasitics to the ideal power source(s). Possible solutions 1) Specify splitting factor coefficients 2) Use a new subparameter under each voltage reference keyword 3) Use a new subparameter under each I-V curve 4) Use four new subparameters under the [Model] keyword (as presented = in this BIRD). ************************************************************************= ****** ANY OTHER BACKGROUND INFORMATION: Changed the names for the four C_comp* parameters as requested in the=20 12-08-2000 IBIS Open Forum Teleconference meeting. Added the next=20 paragraph. Transistors (consequently buffers) show different parasitic capacitance = when turned on or off. Additional mechanisms need to be added to the IBIS=20 specification to account for these variations. The voltage dependency of the die capacitance should also be addressed = at some point. (Use typ., min., max, capacitance vs. voltage tables instead of = single values)? ************************************************************************= ****** ------_=_NextPart_000_01C08D5F.15355480-- From owner-ibis Fri Feb 2 14:01:19 2001 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f12M1GH09797 for ; Fri, 2 Feb 2001 14:01:19 -0800 (PST) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id NAA29606 for ; Fri, 2 Feb 2001 13:57:26 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 02 Feb 2001 21:57:25 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id <11G3AYPR>; Fri, 2 Feb 2001 13:57:24 -0800 Message-ID: From: "Lorang, David D" To: "'ibis@eda.org'" Subject: Bird 68.1 Date: Fri, 2 Feb 2001 13:57:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: application/octet-stream; name="bird68_1.ZIP" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bird68_1.ZIP" UEsDBBQAAAAIAAB4QioFCN3gkQoAAKAoAAANAAAAYmlyZDY4XzExLnR4dO1aa28buRX9LkD/gUg/ 1F5I8mOLRRE0BWRbboQ4lmuNswiSRUppKIvNzFAdzljRwj++h5ecl4ay7G3zaZeADWuGvLz38D7O pfzDD//P0e3sm/Gy0e10O8w/zvLFQqRsrHUu2K3QKsozqRJ2oeZ5LJKMsYOz8e3FoRHR7Zg/2fji T6/t4p/+OjjpdsbT6d2IBePgamSen0c8lYsNy5Y8Y7dSy+Se8SRklzyKzN8/8wexUGms2XSp8ihk M8HOVZqKiGci7HZuR/+8G02Dya3d5II/yJBdqZQn9z02TjIRdTsXw2DEpndn78dBMLp4vcO2yTxT Mxh3+pceOz0+Pu7961LM0pynG3ZKT06cpOH5+egGgtjZRzY+G0/Z5GZ0zS4nt3fvrewbkYTQ3UCw D+sXju8gsNuZBrDq/eg6YJNLFrwdMTqi15UbuGNZu6NgIc840+VxzMvjYGuZLdnCHV1zfqYKcUsR rZiWcY41KtVslSocmmB8Ps9TiGFhnm3YfDOPhGYQAN8QMmUqz1Z5VggphOvBd4HZg8rtaDq5+oBj n96MzseX4/NhMJ5cTwmnYRgaLaFtFKm1MT4Ra7biKb9P+WoJ4+n1J4dk4dS/9Ngn5+jdTvmQvROb tUpDzWTCpmJOEfYTkMZbQXJqgk3Y6IynmSbwe+zVkHU7n96rUES/ML0Sc7mQc04y5hw/Ksk45MZW FlarRLDU6iXCezEYDF6RTY9b8RFgYzpJrIbOTC1Il/KUMz4zB1b5RSZjwdpyKncZMEQoU5CSMjK4 RxKNFuVOgs+XxVZtWW7Pg7RKHM77DmuKIDGJtPDOVBhQMnMkbXlwa6yNgLCSyGbYn4xYL0VCGsgE Lgi8jfPmOB/NOFJhDNnGvbelLQENlshMUnBwFql7OWcZkpOW5kQAwBBIlhC2RYhvmE0eUCKbCqRg kcwRMMAyjnGwW2qRztC9LQ4gA2uYXsYc00jpci6BUbSpQpBH8j6hjA7s23Kq6LN+sZCpzhhwF+WZ Nf2idhoe1EsMyW0gr7KxeRDkO3qlKL+a+bwtzQPyJZKI+MbjVSR6bjcXOYqQgnskPGqLqoVFS2wR dZBCqr1hxxaMxKdUXdKDijJ+L/q0zKITy/tlRrk0FeQrJJzSQgsst9+vIlUN9LV4ECmPnEQcXSoR GlZyWwz2IuNfRYKHfZm8cgDzXGP72ca+zZNQLHCqoUdCARubWVKAhMM39Szl7IRTZTmCclMg5gnj ElWYXBjlqghBVrh2v+/qAVvl6Upp4XdPLTIDXs2NyLhibeMA4PAPot93/skj7csLpPnWUQ+T0Oar hqaew/WET1k6t467cbo2X3GEgNZyBvzagkK5IAuhW6xyG607T/R5kvr9GXJJI9CAet3E7YP3CDOu AIiA0cYdP549SBxEsc9cUHl7pixrykxka4H4amd7UqzMkHy1EjxFoO+00yxxMJFoXcqm7FPJr5/v E2mQEtRSFPXo3zniEdtzmL9lsEPDZyfhg71FaZnTrbKn0r7hZ5664cK/odeAWV7+XfjS8Hp49XEK NnwzDN4egSgPwZqGAbsCYwomTdJE/CJYonzOlyDqwhTSRAAhbdj2TJDPMpGmhh46E4gzmDq4lCuf J3Q7TV+wMioqCew06CalbifScVDDDNxBwme7nRt4vkgfqMIsKXXYXPL0/o0QcWuk8UAZr7AtR3CG aJocExQ4xzlyIeKVQqCvN/FMRfZDkbQOxtPxIZEkPHQTIK8+xVA6qpkqN3ke4uAl1QYFc1ql8C4F akDaHRh9gcECzgiBFq8ycfPsEJzQAXRvYvM/8FgJHJ0wZExKOSTL7OjmGU1NNq6BVuDEKw3M3g0J ko6YDpvyqd0aphc2dDtriViYmcxTIyhaEfW/Vpkr5oBifDQpMskW9V1yw6MQO78KC5Be8pVT364w Z2V7jIq7GGVDhRWJyuhDrm0pA+541EPUQmZseI+lhy6b2aQFeQurmt3BAJQZe81c8kzaHiQOidbg 4RorIYieim8ATWtHfT1uWGUtCVd6QCNtADYYrGRiqBn69azuw92O14sBnDPc6vln+OX6iTRLbl1D 1EJc2NoQVSFI+cxUtDKeeRRXzL7cuXFuPZeEDald2trYisWKWa5s4IqwhyhZFNVODGy2EVsuEfOv xhbUushkV5KPfJBJsMRaZjekgbN7+QCgXDzYkNnudKq+psdMCYXk0nXKnR0NKlwWMLpVxChrHARS Y/Rpplcz1XtP5Ssy+zkwkUTxl/Vm1HFf26oWJ7N0maKaFguuc9MoBXPFDgJj1Hmk5l/7merbUz2E l0W5sE23rTQ0t0ZvD18zdproxuu6rnj/o3mNDjtfEYUjJNbCtkulDtUJcCrs6zJtOycIpemBY2AD 9QfW/qL8HaNd2h4nnoenx1aV4vN2Gd35rHFH9qU9PGu88778hr09z4xCT71/7jMn5/zq3Y41Hgt2 ydm6RPSs9C1sz2vKOfIs+ex5dtRY5lvlW2dWTe6Cm7sAevgXYdmWgkdN33v8W//vj8bvb9EonFqf w7PaQ+f/iMXIFm5m7xFjc2lDrl3kjRBJ0rYBJo5CmaIeRptemVtohcugVND09rWMdu2veVbGlkzM K5t0+Ew9mK44qekAaa2OtHZp0MwanpxUbv66CQ37gGYSFrH64fscYecFNI2jJ1+7t+6qzf/SO554 V736YO9zShuOavZtv9seO+V/3r2ze1Vch/ve+ceTL+tvizOpK/2Z4q4Vw9V4dL/acV6O4M2x+XWK nx/ZQaLdlwJDwz0XTCv4XOH+DYdl3N0fUGkE/yPHxmxbZkNl6qLxd8vejQ/bfrpwT0MlE1FwzVhq 0+lZ2qBR31tOacfLSob70JLy3ETrxe1Le3iW7qsjbjxbE8+zejl5YtpznzXFfY/i4oZHgG/avhrj xktKzSSV9xRGrnq8qOI0x28uPG48XX8uq/rj2WEbF88U3zQvfi0rfNgRANOyD3foeQDYX+PtI8+0 Fm67kGOP/RK4Ewdcv0TtpKjaQZuDGn5atCimt6P2b5GqGM0FCLQpnq4tMqzbXnqE/T7yk2mXOTWF k3flzQdVYmkpgOkpk9AWYNtG2C9L3TUpkh5anNh2ldRRUHO1q3Ujju32N3eC2xeI9t6ETDP9KfqT 7bsTxy88dyeuuxBZRt1FEtK+NB/aaZnl9WxNmuzQFR1/WQ1q3y5qZW00LZnKyyt9kkKQfegHlsBo t0mk1FdIi+RXQVr8vvmIx7L/mUF4iQnbt3j/+30MhT2PpDzuYSmGpARvTlo85WfDueFXuk5M6GvA Jg2pkRD4eJonvQaZcW4IspKZKyzyeV4LOsPq4dK2r1VFDXE83Xz9Zq8Sirxgif7O4DbEqX4LQUJt 2nE3F/bSy3xtWdyjdTsHciAGO2IaGQgxhGRRXRd4b1QHh39wqj3P/uBUZvz+OFULFz9+rUkeWc8E z8OonolcG7hnwrYDtRadqiF5aZG0C8fIpHkc83TTq6p587rWXY4Wl6KsfnFaXmRHkT8/Vjnc3Ksn 9j8Sqv9AIlZRJFja2/3LEqS1/jvJdZHuxnHfV2MvHMShrj+ySfB2dMvOhufv/nE7ubu+YOPry8nt ++rbM4vmd9m/2/kvUEsBAhQLFAAAAAgAAHhCKgUI3eCRCgAAoCgAAA0AAAAAAAAAAQAgAAAAAAAA AGJpcmQ2OF8xMS50eHRQSwUGAAAAAAEAAQA7AAAAvAoAAAAA From owner-ibis Fri Feb 2 14:26:12 2001 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f12MQ9H09898 for ; Fri, 2 Feb 2001 14:26:12 -0800 (PST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id WAA16463 for ; Fri, 2 Feb 2001 22:23:44 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 02 Feb 2001 22:22:19 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21) id <1B4GGR4F>; Fri, 2 Feb 2001 14:22:18 -0800 Message-ID: From: "Lorang, David D" To: "'ibis@eda.org'" Subject: Bird 68.1 Second Try Date: Fri, 2 Feb 2001 14:22:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C08D66.98610690" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C08D66.98610690 Content-Type: text/plain; charset="ISO-8859-1" I think my mailer compressed that last posting into a zip file. Here is an uncompressed version. <> ------_=_NextPart_000_01C08D66.98610690 Content-Type: text/plain; name="bird68_1.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bird68_1.txt" ************************************************************************= ****** ************************************************************************= ****** Buffer Issue Resolution Document (BIRD) BIRD ID#: 68.1 ISSUE TITLE: Clarify that Rising and Falling Waveforms Should be = Correlated REQUESTOR: David Lorang, Intel DATE SUBMITTED: October 24, 2000,`February 2, = 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ************************************************************************= ******* ************************************************************************= ******* STATEMENT OF THE ISSUE: Rising waveform data should be correlated with falling waveform = data to help simulators provide accurate duty cycles for their output waveforms. ************************************************************************= ******* STATEMENT OF THE RESOLVED SPECIFICATIONS: Add the following new paragraph to the [Rising Waveform], [Falling Waveform] Keywords in Section 6 before the paragraph that starts with, = "A=20 [Model] specification can contain more that one rising edge...": | The data in all of the waveform tables should be time=20 | correlated. In other words, the edge data in each of = the=20 | tables (rising and falling) should be entered with = respect to=20 | a single point in time when the input stimulus is = assumed to | have initiated a logic transition. All waveform=20 | extractions should reference a common input stimulus = time in=20 | order to provide a sufficiently accurate alignment of=20 | waveforms. The first line in each waveform table = should be=20 | assumed to be the reference point in time corresponding = to a | logic transition. For example, assume that some = internal | rising edge logic transition starts at time =3D 0. = Then a | rising edge voltage-time table might be created = starting | at time zero. The first several table entries might=20 | be some "lead-in" time caused by some undefined=20 | internal buffer delay before the voltage actually = starts=20 | transitioning. The falling edge stimulus--for the = purpose of=20 | setting reference time for the voltage-time = curve--should also=20 | start at time =3D 0. And, the falling edge = voltage-time table=20 | would be created starting at time zero with a possibly=20 | different amount of "lead-in" time caused by a possibly = | different--but corresponding--falling edge internal = buffer=20 | delay. Any actual device differences in internal = buffer=20 | delay time between rising and falling edges should = appear as=20 | differing lead-in times between the rising and the = falling=20 | waveforms in the tables just as any differences in = actual=20 | device rise and fall times appear as differing = voltage-time=20 | entries in the tables.=20 ************************************************************************= ******* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This change is necessary because errors in the relationship between = rising and=20 falling edges cause duty cycle distortion in the simulated waveform. =20 Preserving the timing relationship between rising and falling edge = timing is=20 important due to the effects of inter-symbol interference (ISI). = Intersymbol=20 interference can be thought of as the effect of the previous edge (and = in fact=20 edges before that) on the signal quality of the current edge of a = signal. If=20 the timing between a previous and current edge is in error, then the = ISI effect=20 will be inaccurate also. Note that an I/O buffer specification characterizes the shape of a = buffers=20 output waveform and does not and usually cannot, determine the internal = delay=20 of that buffer. It is the duty of a component data sheet to express = the=20 timing relationships between its various I/O pins. But the timing=20 relationship between an output buffer's own rising and falling edges is = characterization of that output buffer and does fall within the realm = of the=20 buffer's specification, and thus that timing relationship should be = preserved, if possible. The specification makes it clear that multiple waveforms for a given = signal=20 edge should be time correlated, but it does not specifically state that = correlation should also be maintained between rising and falling edges. = Consider the following example: A buffer has the following measured Tco (Time Clock-to-output) values. Tco (rising edge): 2ns Tco (falling edge): 3ns Suppose that we have measured waveforms as shown in the timing diagram = below. 0ns 10ns 20ns | | | ___________________ ____________________ | | | | | | | | CLK | |___________________| | ___________________ _________________ / \ / / \ / OUTPUT __/ \_______________/ |<->| TcoR =3D 2ns |<-->| TcoR =3D 3ns Although IBIS modeling does not deal with Tco directly, it does model = the=20 shapes of the waveforms. For the measured information above, an IBIS = model=20 might be created to provide the following rising and falling waveforms: Vfinal ___ ___ =20 / / Rising / / / Vinitial ___ / Vinitial ___ =20 \ \ Falling \ \ \ Vfinal ___ \___ | | | T=3D0 T=3D2 T=3D3 (ns) And if so, although the waveforms are the correct shape, a time domain=20 simulation would provide erroneous and misleading results: 0ns 10ns 20ns =20 | | | ___________________ = ____________________ | | | = | | | | = | CLK | |___________________| = | ___________________ = _________________ / \ / Original OUTPUT / \ / __/ \_______________/ |<->| TcoR =3D 2ns |<-->| TcoF =3D 3ns ________________ = _________________ / \ / Simulated OUTPUT / \ / / \_________________/ |-| TcoR =3D 1ns |-| TcoF =3D 1ns The timing diagram shows that the delay from clock to output has = changed--and that is OK because IBIS is not intended to specify that. The problem = is that=20 the rising and falling edges have changed by different amounts causing = duty=20 cycle distortion of the simulated waveform. A better handling of this situation would have the rising and falling=20 waveforms correlated so that for our example the IBIS V-T models would = look=20 like this: Vfinal ___ ___ =20 / / Rising / / / Vinitial ___ / Vinitial ___ ___ =20 \ \ Falling \ \ \ Vfinal ___ \___ | | | | T=3D0 T=3D1 T=3D2 T=3D3 (ns) With these waveforms when a time domain simulation is run, the waveform = would=20 still have a different Tco than the original measurement, but because = the=20 rising and falling edges are correlated, the output signal shape is = accurate=20 (i.e. the simulated waveform no longer has the duty cycle distortion.) 0ns 10ns 20ns =20 | | | ___________________ = ____________________ | | | = | | | | = | CLK | |___________________| = | ___________________ = _________________ / \ / Original OUTPUT / \ / __/ \_______________/ |<->| TcoR =3D 2ns |<-->| TcoF =3D 3ns ___________________ = _________________ / \ / Simulated OUTPUT/ \ / / \______________/ |-| TcoR =3D 1ns |<->| TcoF =3D 2ns In summary, the IBIS specification should maintain correlation between = all=20 rising and falling waveforms to enable simulators that use the IBIS = data to=20 provide accurate results. ************************************************************************= ******* ANY OTHER BACKGROUND INFORMATION: =20 ************************************************************************= ******* ------_=_NextPart_000_01C08D66.98610690-- From owner-ibis Fri Feb 2 14:49:51 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f12MnmH09959 for ; Fri, 2 Feb 2001 14:49:49 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id RAA17757 for ; Fri, 2 Feb 2001 17:45:52 -0500 (EST) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id RAA29508 for ; Fri, 2 Feb 2001 17:45:50 -0500 (EST) Received: from f22.innoveda.com (f22.camarillo.innoveda.com [139.181.194.48]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id OAA18534 for ; Fri, 2 Feb 2001 14:45:18 -0800 (PST) Received: by f22.innoveda.com (SMI-8.6/SMI-SVR4) id OAA12651; Fri, 2 Feb 2001 14:45:46 -0800 Date: Fri, 2 Feb 2001 14:45:46 -0800 From: guy@camarillo.innoveda.com (Guy de Burgh) Message-Id: <200102022245.OAA12651@f22.innoveda.com> To: ibis@eda.org Subject: EIA IBIS Summit Meeting Minutes Date: 2/2/01 SUBJECT: 1/29/01 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 2001 PARTICIPANTS LIST: 3Com (& CommWorks) Roy Leventhal Agilent (Mark Chang) Ansoft Corporation (Eric Bracken) Applied Simulation Technology Raj Raghuram*, Norio Matsui*, Fred Balistreri* Avanti (Chen Hongyu) Brocade Communications Robert Badal* Cadence Design Ian Dodd* Cisco Systems Syed Huq*, Lungfu Chen* Compaq Peter LaFlamme*, Ron Bellomio*, Quang Dam* Cypress (Rajesh Manapat) EMC Corporation Brian Arsenault*, Jinhua Chen* Fairchild Semiconductor Adam Tambone* IBM Michael Cohen*, Greg Edlund, Wes Martin*, Yeon-Chang Hahm*, Bill DeVey* Innoveda (& HyperLynx) Guy de Burgh*, John Angulo* Intel Corporation Stephen Peters*, Arpad Muranyi*, Dave Lorang, Michael Mirmak, Qinglun Chen*, Will Hobbs* LSI Logic Larry Barnes* Mentor Graphics Bob Ross*, Tom Dagostino*, Chris Reid*, Mike Donnelly*, Hazem Hegazy*, Tony Dunbar*, Griff Derryberry*, Dan Lake*, Sherif Hammad*, Mohammed Korany*, Weston Beal* Micron Technology Randy Wolff, Yong Phan Mitsubishi (Tam (Tom) Cao) Molex Incorporated Gus Panella*, Brian O'Malley* Motorola (Ron Werner) National Semiconductor Milt Schwartz* Nortel Networks Calvin Trowell North East Systems Associates Edward Sayre* Philips Semiconductor Zack Ciccone* Quantic EMC (Mike Ventham) Robinson-Nugent, Inc. (Alexander Barr) Siemens AG Bernhard Unger*, Helmut Katzier* SiQual Scott McMorrow*, Rob Hinz*, Bernard Voss*, Chris Brewster* Texas Instruments Thomas Fisher*, Stephen Nolan*, Ramzi Ammar* Time Domain Analysis Systems Dima Smolyansky*, Steve Corey* Tyco Electronics (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) (Werner Rissiek) OTHER PARTICIPANTS IN 2001: Actel Corporation Silvia Montoya* Acuson Kim Helliwell* AMCC Jeff Smith* Apple Computer John Figueroa* ASIS Ltd David Wright* EIA Cecilia Fleming FCI Sercu Stefaan* Foundary Networks Bertram Chan Framatom Conectors Danny Morlion* Fujitsu Ltd Tadashi Arai*, Takeshi Murakami* Huawei Technologies Rachild Chen* Hyundai Electronics Jongho Kang* Intrinsix Corporation Steven Chin* Nokia Tapani von Ravner* Oak Technology Darmin Jin* Plexus Technology Group Joseph Socha* Signal Integrity Software Douglas Burns*, Barry Katz*, Walter Katz* STMicroelectronics Peter Hirt* Xilinx Susan Wu* Independent, Consultant Al Davis* In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode February 16, 2001 (916) 356-9200 2-508083 4216977 March 2, 2001 (916) 356-9200 2-508084 6782941 March 16, 2001 European IBIS Summit Meeting - No Phone Bridge 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 AND MEETING QUORUM The IBIS Summit Meeting was held in Santa Clara, California at the Santa Clara Convention Center. About 72 people representing 35 organizations attended. The notes below capture some of the content and discussions. The meeting presentations and other material will be uploaded at: http://www.eda.org/pub/ibis/summits/jan01/ Bob Ross opened the meeting by asking everyone to introduce themselves. The group was well represented by Semiconductor and EDA tool vendors and users of IBIS models. Also several people from EDA commercial IBIS model providers and EDA consultants attended. Several people were also involved in other official standards bodies, some of which are considering using IBIS models for simulation models. Bob thanked DesignCon for providing the meeting room, refreshments and the Booth as part of our Associate Sponsorship of DesignCon. The IBIS Open Forum is mentioned in the literature. Bob thanked National Semiconductor for providing the hot lunch and Milt Schwartz for taking care of the local arrangements including providing copies of the presentations. Bob thanked Applied Simulation Technology for loaning an LCD projector. Bob thanked Guy de Burgh and Innoveda for taking care of the booth backdrop and handling the member signs. The IBIS Booth is #861 on the show floor. Finally, Bob thanked the presenters and participants for attending. IBIS TODAY Bob Ross, Mentor Graphics Bob Ross briefly noted the current IBIS activity: Ongoing Version 3.2 activity including ibischk3 Version 3.2.6 and more BUG processing. IBIS Version 4.0 BIRDs being processed Connector Specification (Version 0.960 has been uploaded) Future "IBIS-X" We are also tracking other activities including EIAJ IMIC progress, JEDEC activity and European TC93 WG6 EMC/EMI activity. We are also noting that there may impacts from other standards. The meeting today progresses from present to futures: Current IBIS Model Development and Validation Future Needs Connector Specification Progress and Discussion Future IBIS-X Progress and Discussion Other Topics and Discussions Bob then asked for any new topics. Ian Dodd's report on HTML format for IBIS will included as part of another presentation. IBIS DOCUMENTATION FOR ACME ENGINEERING Scott McMorrow, Siqual Corporation Because of equipment availability, Scott McMorrow started first. He stated that his presentation was a reduced form of an actual report on a model he developed for a customer (with names changed). It shows a process for developing and validating IBIS models. The first problem is gathering all of the specification and Spice model information. Sometimes initial information is incomplete, so this process may take several weeks. The IBIS model are developed by using internal tools based on improvements to the North Carolina State University s2ibis2 utility. Once completed, the model is checked against several test circuits similar to those in the IBIS Accuracy Report. In particular a transmission line with a small capacitive loads are used. The Figures of merit similar to those in the Report are given with the model. Scott expects values in the range of 97% to 99% for released models. Scott mentioned that the major EDA simulators that process IBIS models give essentially the same results. He showed examples of IBIS buffer simulation overlayed with Spice model simulation. Some differences were based on DC errors in the I-V data. Sometimes waveform mismatch between some expected DC starting and ending values and those documented in the waveform tables caused some overshoot glitches. The other main source of mismatch were related to the number of points in the V-T tables. IBIS has an overall 100 point limit that sometimes must be allocated between the different time shifted typ, and max columns. He had observed that with 33 points he may get 6% error in correlation. Scott indicated that, if necessary, more points can be extracted and 100 points per column and can achieve 99% correlation. With 256 points, correlation is excellent and delays are with picoseconds. Scott extracts the die capacitance from the model. A wrong die capacitance provides the second largest source of error, especially at the receiver where the reflected amplitude is doubled. He described two methods. One is based on the response to a current source. The other is based on simulation of a driver and receiver and use Spice to find the value through optimization. Scott illustrated these points by showing overlaying Spice simulation and IBIS model simulation examples and noting some of the mismatch details and the probable reasons for the deviations. Scott agreed with a comment from a participant that the correlation metric number itself could depend on the length of the period (and the corresponding amount of overlaying data). Visual inspection for differences should also be done. Scott concluded that IBIS model simulation can be as accurate as Spice model simulation. Other variables such as actual board impedances contribute far more deviation in actual measurement to simulated results than the accuracy deviations discussed in the correlation study. THE JOY OF WEB MODELS Tom Dagostino, Mentor Graphics A customer had asked Tom Dagostino to "QC" (do a quality control check) a set of IBIS models needed for a project. About 20 of them were obtained directly from semiconductor web sites. Most actually were quite acceptable and may have needed only minor, easy to do addition or corrections such as adding threshold and timing values to some models. However, Tom had three really bad examples to share. The model names and vendor names were changed to protect the guilty! While the review process involves more steps, the models illustrated in the presentation failed either or both the ibischk3 and visual inspection check. The first model was a clock driver that had serious ibischk3 mismatches for rising and falling waveforms and I-V data. Visual inspection revealed that the pulldown table had zero current in the active region, as the source to the problem. A visual inspection also revealed that C_comp value was constant for all three cases: typ, min, and max. Tom reported these problems to the manufacturer, and after the second call he received a corrected model that was satisfactory. The second model was documented as a SCSI terminator. It passed ibischk3 with zero errors. However the model type was listed as Output complete with [Pulldown] and [Pullup] tables and [Ramp] data. The manufacturer has been contacted and stated that they would pass the information on. However, the manufacturer has not responded. The third component had at least several bad models. A model named as an _in model with a signal_name and Model_type Output had ibischk3 waveform errors. Closer investigation showed a number of interesting aspects: Vinh and Vinl were defined; the typ, min, max temperatures were not correct; and the I-V table data contained zeros in the normal operating regions. Also, the [Ramp] data contained zeros. Another _in model was documented as an I/O model with weak [Pullup] and [Pulldown] data and more [Ramp] data problems including negative time. Another had a constant voltage [Falling Waveform] table. A model, really documented as an _out model, had meaningless and unrealistic conditions regarding the content of the data: a "rough approximation" to lab measurements, and a max condition that was not consistent with the IBIS definitions. It passed ibischk3, but with waveform warnings. One source of warning was a repeated voltage value. Some tables had strange values inconsistent with typ, min, and max values. This time the [Pulldown] table had -0A values and [Ramp] data values of 0. For this component, the manufacturer has not yet responded to Tom's feedback. Tom concluded that some model developers need to do a better job in making models and QC'ing them before they are released. LVDS MODELING Hazem Hegazy and Mohammed Korany, Mentor Graphics Mohammed Korany reported on the problems associated with creating IBIS models for LVDS differential driver buffers with internal differential terminations. The basic problem is to extract the proper DC I-V data. He reviewed several existing methods and then two new proposals. The last proposal gave the best results. First Mohammed reviewed LVDS. He then reviewed two methods that have been proposed. The first one dealt with a voltage sweep at PAD with PADN connected to R_load and Vref. The second method used a mirrored negative current source at PADN. A third method was also presented where mirrored delta voltages are applied at PAD and PADN. All of these methods worked for 50 ohm loads and provided nearly overlaying IBIS and Spice simulations. Some DC offset was observed with 100 ohm terminations. However, all methods gave DC offsets when internal differential terminations existed in the LVDS model. Mohammed accounted for these offsets by showing the mathematical distribution of currents during extraction of the model. Proposal I was similar to Method 3, but had the voltages attached to a Vmid value derived from averaging the low and high state voltages. This produced better results but still showed DC differences with internal terminators and the load equal to 100 ohms. It only supported the using the R_fix value load. Proposal II used mirrored resistance changes with resistors connected to the Vref value. This produced overlaying simulations for all cases. Mohammed showed overlaying simulations with a test circuit where the differential, internally terminated buffer was driving a lossy, coupled differential line into a receiver load. The results overlaied well for all differential conditions. Mohammed noted that one could remove the internal differential resistor as another approach. Bob Ross noted that we may not know exactly the internal resistor (if the driver does not have a high Z or input mode or if the Spice model is encrypted). Several people noted that the examples showed larger differential voltage swings than specified for LVDS. Mohammed stated that this was from an ASIC produced by one vendor. The methods discussed are applicable to LVDS. Arpad Muranyi (several methods were referenced from his class material) stated that this was good information. He never did consider the impact of internal differential terminations. Ed Sayre stated that even other terminations including AC terminations may exist. It is important to get the model correct for DC and AC responses. Mohammed concluded that LVDS IBIS modeling needs high DC resolution LSI POWER AND GROUND MODEL FOR EMI SIMULATION Norio Matsui, Applied Simulation Technology and Hiroshi Wabuka, NEC Norio Matsui introduced the problem by showing several simulation comparisons between IBIS Simulation, table Spice (IMIC) simulation and Spice (all done using the Applied Simulation Technology tool. Standard simulation of LVDS and PECL circuits work well. However, IBIS loses some detail with internal inverter circuits and also does not produce the same simultaneous switching output (SSO) responses for currents and voltages. ICs with complex internal structures cause unaccounted internal currents that need to be added to the model for ground and power modeling and EMI. For large scale integration (LSI), the conventional IBIS structures can be used for input and output. An internal current circuit is added between the input and output structures. Such an internal structure might represent a clock macro. The techniques for macro modeling can be: I/O IBIS or IMIC for I/O + Package Clock 10% consumes most power (highest frequency) Non Clock Behaves a filters/decoupling capacitors Norio described the procedures for macro modeling and showed some Spice and table Spice structures and also some IBIS EBD and IBIS I/O structures. The clock and non-clock model can be realized using a cascaded double IBIS I/O for the dynamic portion and a set of RC networks for the non-clock static portion. Norio showed a final circuit containing double inverters for the middle stage. Using this approach, Norio showed accurate correlation between the IBIS/EBD and table Spice (IMIC) models for current waveforms. There was some loss in accuracy when he simplified the model using only four IMIC transistors. Norio also showed accurate comparisons simulated and measured peaks of near field EMI. Arpad Muranyi questions whether splitting C_Comp into components to different rails might improve the accuracy for the simplified model. Also die interconnect details were not simulated in this study. SCSI COMPENSATION MODELING Larry Barnes, LSI Logic Larry Barnes introduced himself as co-chair and technical editor of a Ad hoc Working Group involved in T10. T10 is a Technical Committee of the National Committee for Information Technology Standards (NCITS). It was formerly known as the X3 Committee. NCITS is accredited by and operates under rules approved by ANSI. Larry showed the membership and gave some background on the Small computer Systems Interface (SCSI). A technical synopsis of SCSI configurations include: Bus structure with 27 data, 8 ground, 4 termination power, 2 reserved lines 68 conductors, 90 - 120 ohms, single ended or differential 25 meters point-to-point 12.5 meters with 16 stubs Allowable loading of 30 pF / stub Larry presented a number of issues that produce data errors associated with 320 MBytes/second transfer rates, decreased setup and hold time, intersymbol interference, decreased cable charge time, and 16 capacitively loaded stubs. The eye diagram without compensation has decreased, and the worse case situation has no opening. Larry proposes a solution which produces a very acceptable eye diagram: Run length encoded compensation at the transmitter Transmitter overdrives unless two or more data bits are sequentially the same value Second data bit and subsequent bits of the same value have the drive level reduced Drive strength, rise time and fallback are programmable Training pattern upon initialization with bit rate negotiation Larry is writing an ANSI/NCITS Technical Report on SCSI Signal Modeling to document the details of the solution. The Working Group has selected IBIS a the data exchange format for: Semiconductor device models Termination models Connector models (when codified) The Working Group would like to continue to use IBIS if fallback modeling can be accomplished. Currently IBIS Version 3.2 can be used for SCSI devices for: Single-ended models High voltage differential models Low voltage differential models SCSI 320 Mbyte/s driver characteristics require a fallback model: Differential current mode transmitters Negotiable data rates Multi-level parallel positive and negative current drivers Uses programmable fallback Fallback cannot be modeled in IBIS Version 3.2: Driver schedule keyword is close Needs bit position dependency, not time Future may include overdrive past first bit Needs accommodation for parallel current mode drivers Larry proposes adding a [Fallback Schedule] keyword: Similar in construction to [Driver Schedule] Describes switching sequence fallback modeling Delay parameters are in terms of bit times Accommodates typ, min, max conditions Differential operation Two current sources and sinks for each line This will cover the next generation of SCSI and IBIS futures through 2003. Subsequent generations may include phase encoding. Larry hopes that this will fit in the future of IBIS. Larry welcomes IBIS participation in this Working Group. A draft work in progress specification is available at: http://www.t10.org LUNCH The Group broke for a delicious buffet lunch sponsored by National Semiconductor. CONNECTOR SPECIFICATION Gus Panella, Molex Gus Panella reported on the progress of the IBIS Connector Specification. There have been some delay because of the loss of a key member (Kellee Crisafulli), limited participation, holidays, and working with a big document. However, the Working Group has been improving the descriptions and clarifying ambiguous syntax. Gus reported on some of the changes: Removal of Physical Map because of unnecessary complexity Distinction of Side_A and Side_B pin maps Clarification of [Redistribution] Specific to mean comments are in the Header section Some number of pins, rows, and columns ranges to document physical limits More [Cn_Row_Swath] and [Cn_Column_Swath] distinction and edge definitions and usage Gus reported that Ian Dodd provided a C-style syntax to describe the pin map information as a function of ROW and COLUMN entry specified by the EDA tool. Ian gave the brief description (given below) at this time. Gus stated that the current discussions involve following the IBIS-X group header suggestions, where practical. These include bracketing the header with [Begin Header] and [End Header] keywords. Gus asked if the [Source] keyword should be required. It is not required in all other documents. The consensus was mostly in favor on not making it required after some meeting discussion. Gus also asked about using " " (space) or "_" (underscore) between keywords, but this was clarified as an documentation editorial detail, not a functional detail. Both conventions will be supported. The work in progress (Version 0.960) of the Connector Specification has been uploaded for review. Gus closed by mentioning some short term goals. He concluded that the document is reaching technical completion. Bob Ross added that he plans to release the document for full IBIS Committee technical review and comments while the editorial cleanup of the document is being done. The document will go through formal review processes for EIA IBIS Open Forum approval, and further review processes (including a 90 day formal public review) for EIA ratification. IBIS CONNECTOR SPECIFICATION: PRELIMINARY PROPOSAL FOR A PIN NAMING LANGUAGE Ian Dodd, Cadence Design Systems As part of the Connector Specification presentation, Ian Dodd displayed and discussed aspects of a proposal for pin naming language. The main points of the proposal are: It adopts C - like code style including C style formatting statements It predefines certain variables ROW, COLUMN, SIGNAL_NAME, and PIN_NAME It presumes all variables are integers and do not need to be declared It has some simple math operations and conditionals It can easily specify incrementing characters through addition Ian showed some applications including one where a row was missing. He stated that the proposal might be compatible with the IBIS-X macro language. One issue is whether they should be aligned. The text formatting might be needed for the macro language. One pending decision is whether the C style of ending lines with semicolons should be done in the pin naming language. AN API FOR IBIS?? Al Davis, Consultant Al Davis gave an informative presentation on an application programmable interface (API) for IBIS. He defined an API as: A binary interface for models It supports portable models external to the simulator It provides the ultimate generality and intellectual property protection Al listed a number of issues: Type of interface Operating System differences Language differences Simulator differences Uses beyond simulation Hard to make portable (easy for one simulator) The interface can be dynamically linked object modules (faster, but harder to develop and less portable) or a separate application or applet (slower, but more general and portable). Al prefers the executable approach. He listed some advantages and issues. It should support different types of simulators ranging from Spice-like, mixed-mode, transmission line / tree based, gate level, and HDL. It should also support more than one simulation. There was some discussion on whether API's would be repeated if the model was used several times. This needs to be clarified. The functions needed for an API are: Parsing and printing the calling netlist Pre-processing Predictor step Evaluation Gather and scatter Review step (iteration and step control) Probes Status queries Plus about a dozen more Normally the user would use other tools to write the functions including VHDL-AMS, IBIS-X, etc. The simulator developers would do the work since the complete understanding of simulator internals is needed. Al concludes that an API is needed, but it will take coordination between EDA companies. It has potential beyond IBIS. IBIS FUTURES GROUP UPDATE ON IBIS-X Stephen Peters, Intel Corporation Stephen Peters, who is serving as Chair or the IBIS Futures Working Group introduced the progress on IBIS-X. He listed the goals: Provide extensible syntax Enable complex/coupled package descriptions Maintain backwards compatibility (IBIS Version 3.2) Support some additional requirements (equation based modeling, HTML viewing, public key encryption) Briefly, IBIS-X provides the following: Nodal based package description (die interconnect pin to pad, power delivery, and pin coupling) Macro language for creating new model types The current status is: Al Davis has implemented IBIS Version 3.2 in a macro language The Working Group meets bi-weekly on writing a formal specification: Overall IBIS-X Specification Library Guide Programmers Language Reference Manual (LRM) expected in months Work remains on the die interconnection section Stephen introduced some current issues: Alignment with the Connector Specification Case sensitivity in .ibs files (need to create rules for capitalization if it is supported. HTML support Support of more general equations and black boxes such as the Berkeley Spice B element Where does the API fit into this? (Later Al Davis raised the case sensitivity issue with the group. The majority indicated preference for removing the requirement.) PROPOSED NEW DIRECTIONS FOR IBIS PCB SIGNAL INTEGRITY MODELS Ian Dodd, Cadence Design Systems Ian Dodd provided an overview of IBIS today and future needs. He gave the brief history of IBIS development and features and described its well-known modeling advantages. He also listed some limitations: Feature changes require the slow process of adding new keywords The rate of requests for feature changes is accelerating Models assume a fixed topology The present standard is inadequate for todays needs in: Input transition detection Simultaneous switching noise Power delivery Coupling within packages Ian listed a number of goals, similar to those discussed by Stephen Peters. IBIS-X for the next generation should: Extend the data sheet Add a new structure template Ian illustrated the extended data sheet (similar to IBIS) and noted the structure details and topology. He also listed a number of circuit elements for IBIS-X Ian also discussed and illustrated how IBIS and IBIS-X can be made compatible with HTML. A feature is that lines with "<" in column one are assumed to be HTML formatting commands. Some details have to be worked out regarding some initial declarations. HTML can also be used to add separate graphics file pictures within IBIS files. Ian illustrated doing this using a portion of an example provide by Stephen Nolan. Scott McMorrow raised the concern that the Working Group might be working on fluff and not dealing with the critical issues. Ian responded that this issue was really not taking much time. Ian listed and discussed a number of advantages of IBIS-X: Extensible Allows reuse of structural template Data is separated from templates Devices in a wide range of logic families can share structural templates Can read existing IBIS models Nodal structure allows multiple levels of abstraction He also listed some concerns: High expertise is needed to create new IBIS-X templates Model developers will need to create more than one type of data sheet Simulation tools will have to be more intelligent in syntax checking. Model validation will be more difficult. Ian listed the future IBIS-X work and noted that there are still some open issues and concerns regarding the level of abstraction and whether exiting standards can be used. Ian concluded that IBIS-X is promising, but it will require increased sophistication of validation tools and training for model developers. IBIS-X PROGRESS REPORT Al Davis, Consultant Al Davis listed the progress: Some documents Working parser Tested with about 100 IBIS files Some bugs Generates partial Spice deck Al's goals are Doing simulations by March Also include the Connector Specification Produce a presentable version of the Specification by March He currently has a working demonstration. It can be downloaded (pre-alpha code for review). It can be found at: http://table.jps.net/~atd/ibisx.200101.tar.gz IBIS-X MACROLANGUAGE Al Davis, Consultant Al Davis reviewed a previous presentation on IBIS X. He stated that the basic simulator requirements were: Handling piece-wise linear (PWL) constructs Handling two-dimensional PWL tables (time and signal) Having a "trigger" to shift time tables Additional elements include generalized expressions for Voltage, current, charge, flux Multi-port block IBIS-X supports structure (a spice like description with expressions). IBIS already contains data with data sheet like information for tables and attributes. These were illustrated. Other structures Al illustrated were conditionals (if), time dependent tables and triggers, an IBIS compatible driver element, a new foreach statement, and an alarm, and value expression. A number of points were discussed including having a floating gnd versus absolute 0 voltage ground and having $ before variables. CONCLUDING ITEMS Bob Ross again thanked the sponsors of the meeting and also the presenters and participants. Bob stated that the next teleconference meeting is planned for Friday, February 16, 2001, and the following one on March 2, 2001. Actions are still needed for issuing BIRD65.2 and BIRD68.1 prior to voting on these. Bob reminded us that the European IBIS Summit Meeting is scheduled for Friday, March 16, 2001 in Munich Germany in a hotel near the Design Automation And Testing in Europe DATE 2001) conference and exhibition. The four co-sponsors are Cadence Design, Innoveda, Mentor Graphics, and Zuken (Incases). The first notice was sent out at the end of January 2001. So far Bob has about three or four presentations proposed so far, so he expects this to be an all day meeting with a free lunch to participants. Bob asked if there were any questions or issues to discuss briefly. Kim Helliwell asked about what was happening to the s2ibis3. Michael Cohen commented that after much debate we decided not to seek funding on the project because it would create a product that already competed with a commercial product. Bob added that there were other commercial modeling services as well. However, the project specification is still uploaded, and anyone can still work on it. NEXT MEETING: The next teleconference meeting will be on Friday, February 16, 2001 from 8:00 AM to 10:00 AM. BIRD65.2 and BIRD68.1 are scheduled for a vote if ready. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 stephen.peters@intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Roy Leventhal (837) 797-2152, Fax: (847) 222-2799 roy_leventhal@3com.com Senior Engineer, CommWorks Corp. (a wholly owned 3Com subsidiary) 1800 W. Central Rd. Mt. Prospect, IL 60056-2293 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 jangulo@innoveda.com Development Engineer, Innoveda 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eigroup.org/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Wed Feb 7 10:59:54 2001 Received: from hummingbird.prod.itd.earthlink.net (hummingbird.prod.itd.earthlink.net [207.217.120.125]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f17Ixrn00615 for ; Wed, 7 Feb 2001 10:59:53 -0800 (PST) Received: from rosebud.al.dynip.com (dialup-209.244.111.6.Seattle1.Level3.net [209.244.111.6]) by hummingbird.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id KAA05924 for ; Wed, 7 Feb 2001 10:56:02 -0800 (PST) Received: from hobbes ([192.168.22.7]) by rosebud.al.dynip.com (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with SMTP id f17IvCT09303 for ; Wed, 7 Feb 2001 10:57:12 -0800 X-Authentication-Warning: rosebud.al.dynip.com: Host [192.168.22.7] claimed to be hobbes From: Al Davis To: Subject: Re: BIRD 65.2 Date: Wed, 7 Feb 2001 10:55:37 -0800 X-Mailer: KMail [version 1.1.61] Content-Type: text/plain References: <10C8636AE359D4119118009027AE9987051551F2@FMSMSX34> In-Reply-To: <10C8636AE359D4119118009027AE9987051551F2@FMSMSX34> MIME-Version: 1.0 Message-Id: <0102071055370E.01056@hobbes> Content-Transfer-Encoding: 8bit (Most of this message is a repeat, because the issues have not been addressed.) I have some questions and reservations on this. To summarize, although I agree that such a thing is needed, this proposal does not solve the problem adequately and has the potential for introducing problems that have not been considered. Also, the problem it intends to solve becomes a non-issue once IBIS-X is completed. The first question is how difficult it is to implement. Ordinarily, I would say that it is necessary to prove it with a prototype, but it is a simple topology change, so it would be no worse than the existing C_comp. Incidentally, the C_comp as we know it is rarely implemented correctly for driving models. It is very difficult to do correctly. The implementations tend to be very good for non-driving models, where it is just a simple capacitor. In any case, it is no worse than what we have so I am satisfied on this point. Still, testing is a problem. How do you measure it? How do you validate that the measured data actually relates to reality? Before approval of this bird, I would like to see a description of a procedure for measuring it, and a procedure for validating that the measured data is actually correct and useful. These procedures should be tried on a prototype. The purpose is stated to be information on how the capacitance is distributed over the 4 ground/power nodes. Another way to look at it is how the current in the capacitance is distributed. OK. Now back up. We have pullup/pulldown and the clamps for the DC conditions. The proposed c_comp's are the dynamic parts. Existing models usually do not model the split of these correctly. The pullup and power clamp are sort of in parallel, so the measurement is usually to measure the clamps in input or tri-state mode, and the pullup/pulldown in driving mode, by measuring a total and subtracting off the clamps. This often leads to the pullup/pulldown showing strange bahavior when it is masked by the clamps, because the subtraction magnifies the errors. In any case, the current path is not necessarily as intended. The standard provides the mechanism to properly model the current paths, but most models do not. They arbitrarily mix them. Given that most models do not get the DC split correct, what justifies even trying for the dynamic part? The next issue is that this capacitance is strongly nonlinear. Measuring it in the various states produces very different results. Even then, there is no hint at what they do during the transition, other than that the wave tables include the effect. The wave tables do not provide information on how that current is distributed to the 4 power/ground nodes, and possibly also to other connection nodes including input and enable. The nonlinear nature of this capacitance is significant in the development of the simulator algorithms. Some actual models will only work accurately when the capacitance is treated as nonlinear. Part of this capacitance is already in the standard as transit time. The [TT*] parameters are essentially equivalent to the C_comp_power and C_comp_ground parts, complete with the nonlinear component. Thus, part of what this bird proposes is already available. (OK -- the bird asks for the linear part.) Do you have any examples of actual models that use these parameters? with test data showing the quality of correlation to the real device? How many simulators support it fully? It has been in the standard for a long time. Considering the number of unanswered questions, and that this functionality and much more will be available in IBIS-X, I think it is best not to rush into this. So, Arpad, you should prototype this in IBIS-X (trivial) , and also prototype a measurement system for it in IBIS-X (not so trivial). This will validate both this bird and IBIS-X. The rest of us should wait for the answer. Note to readers not familiar with IBIS-X: This is a proposed future IBIS based on a macro language. It is fully backward compatible with IBIS as we know it, and provides the capability to add extensions like this one easily. Arpad and I are both on the sub-committee that is working on it. A prototype implementation of IBIS-X is being built, and a partial one (incomplete work in progress) is available for review to the committee and to those interested. The change in wording of the "required" section is an improvement, but it still needs work. How about: Either the C_comp parameter or all four of C_comp_pullup, C_comp_pulldown, C_comp_power, and C_comp_gnd are required. If C_comp is provided, the others are not allowed. From owner-ibis Wed Feb 7 23:53:49 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f187rin03551 for ; Wed, 7 Feb 2001 23:53:49 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id XAA16182; Wed, 7 Feb 2001 23:49:46 -0800 (PST) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id <1CABTDWP>; Wed, 7 Feb 2001 23:49:45 -0800 Message-ID: <2179BC5B6583D311B44700508B4414690468CFB7@svr-orw-exc-02.wv.mentorg.com> From: "Dagostino, Tom" To: "'Al Davis'" , ibis@eda.org Subject: RE: BIRD 65.2 Date: Wed, 7 Feb 2001 23:49:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Re: required C_comp In stead of requiring all 4 values of C_comp (you don't need C_comp_pullup, etc with an open drain driver) require the appropriate C_comp for every IV table in the model. Tom Dagostino IBIS and Tau Modeling Manager SDD Mentor Graphics Corp. 503-685-1613 tom_dagostino@mentor.com -----Original Message----- From: Al Davis [mailto:aldavis@ieee.org] Sent: Wednesday, February 07, 2001 10:56 AM To: ibis@eda.org Subject: Re: BIRD 65.2 (Most of this message is a repeat, because the issues have not been addressed.) I have some questions and reservations on this. To summarize, although I agree that such a thing is needed, this proposal does not solve the problem adequately and has the potential for introducing problems that have not been considered. Also, the problem it intends to solve becomes a non-issue once IBIS-X is completed. The first question is how difficult it is to implement. Ordinarily, I would say that it is necessary to prove it with a prototype, but it is a simple topology change, so it would be no worse than the existing C_comp. Incidentally, the C_comp as we know it is rarely implemented correctly for driving models. It is very difficult to do correctly. The implementations tend to be very good for non-driving models, where it is just a simple capacitor. In any case, it is no worse than what we have so I am satisfied on this point. Still, testing is a problem. How do you measure it? How do you validate that the measured data actually relates to reality? Before approval of this bird, I would like to see a description of a procedure for measuring it, and a procedure for validating that the measured data is actually correct and useful. These procedures should be tried on a prototype. The purpose is stated to be information on how the capacitance is distributed over the 4 ground/power nodes. Another way to look at it is how the current in the capacitance is distributed. OK. Now back up. We have pullup/pulldown and the clamps for the DC conditions. The proposed c_comp's are the dynamic parts. Existing models usually do not model the split of these correctly. The pullup and power clamp are sort of in parallel, so the measurement is usually to measure the clamps in input or tri-state mode, and the pullup/pulldown in driving mode, by measuring a total and subtracting off the clamps. This often leads to the pullup/pulldown showing strange bahavior when it is masked by the clamps, because the subtraction magnifies the errors. In any case, the current path is not necessarily as intended. The standard provides the mechanism to properly model the current paths, but most models do not. They arbitrarily mix them. Given that most models do not get the DC split correct, what justifies even trying for the dynamic part? The next issue is that this capacitance is strongly nonlinear. Measuring it in the various states produces very different results. Even then, there is no hint at what they do during the transition, other than that the wave tables include the effect. The wave tables do not provide information on how that current is distributed to the 4 power/ground nodes, and possibly also to other connection nodes including input and enable. The nonlinear nature of this capacitance is significant in the development of the simulator algorithms. Some actual models will only work accurately when the capacitance is treated as nonlinear. Part of this capacitance is already in the standard as transit time. The [TT*] parameters are essentially equivalent to the C_comp_power and C_comp_ground parts, complete with the nonlinear component. Thus, part of what this bird proposes is already available. (OK -- the bird asks for the linear part.) Do you have any examples of actual models that use these parameters? with test data showing the quality of correlation to the real device? How many simulators support it fully? It has been in the standard for a long time. Considering the number of unanswered questions, and that this functionality and much more will be available in IBIS-X, I think it is best not to rush into this. So, Arpad, you should prototype this in IBIS-X (trivial) , and also prototype a measurement system for it in IBIS-X (not so trivial). This will validate both this bird and IBIS-X. The rest of us should wait for the answer. Note to readers not familiar with IBIS-X: This is a proposed future IBIS based on a macro language. It is fully backward compatible with IBIS as we know it, and provides the capability to add extensions like this one easily. Arpad and I are both on the sub-committee that is working on it. A prototype implementation of IBIS-X is being built, and a partial one (incomplete work in progress) is available for review to the committee and to those interested. The change in wording of the "required" section is an improvement, but it still needs work. How about: Either the C_comp parameter or all four of C_comp_pullup, C_comp_pulldown, C_comp_power, and C_comp_gnd are required. If C_comp is provided, the others are not allowed. From owner-ibis Thu Feb 8 00:27:51 2001 Received: from kestrel.prod.itd.earthlink.net (kestrel.prod.itd.earthlink.net [207.217.121.155]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f188Ron03760 for ; Thu, 8 Feb 2001 00:27:50 -0800 (PST) Received: from rosebud.al.dynip.com (dialup-64.154.185.98.Seattle1.Level3.net [64.154.185.98]) by kestrel.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id AAA19827; Thu, 8 Feb 2001 00:24:00 -0800 (PST) Received: from hobbes ([192.168.22.7]) by rosebud.al.dynip.com (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with SMTP id f188PIT11434; Thu, 8 Feb 2001 00:25:18 -0800 X-Authentication-Warning: rosebud.al.dynip.com: Host [192.168.22.7] claimed to be hobbes From: Al Davis To: "Dagostino, Tom" , ibis@eda.org Subject: Re: BIRD 65.2 Date: Thu, 8 Feb 2001 00:23:43 -0800 X-Mailer: KMail [version 1.1.61] Content-Type: text/plain References: <2179BC5B6583D311B44700508B4414690468CFB7@svr-orw-exc-02.wv.mentorg.com> In-Reply-To: <2179BC5B6583D311B44700508B4414690468CFB7@svr-orw-exc-02.wv.mentorg.com> MIME-Version: 1.0 Message-Id: <0102080023430K.01056@hobbes> Content-Transfer-Encoding: 8bit On Wed, 07 Feb 2001, Dagostino, Tom wrote: > .......(you don't need > C_comp_pullup, etc with an open drain driver) ..... You don't? It seems to me that real drivers can have capacitance there even if there is no transistor there. From owner-ibis Thu Feb 8 00:38:05 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f188c3n03810 for ; Thu, 8 Feb 2001 00:38:04 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id AAA19604; Thu, 8 Feb 2001 00:34:06 -0800 (PST) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id <1CABTDW7>; Thu, 8 Feb 2001 00:34:06 -0800 Message-ID: <2179BC5B6583D311B44700508B4414690468CFBD@svr-orw-exc-02.wv.mentorg.com> From: "Dagostino, Tom" To: "'Al Davis'" , ibis@eda.org Subject: RE: BIRD 65.2 Date: Thu, 8 Feb 2001 00:33:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" I agree but it is not "required" to have 4 C_comp's to model this. Tom Dagostino IBIS and Tau Modeling Manager SDD Mentor Graphics Corp. 503-685-1613 tom_dagostino@mentor.com -----Original Message----- From: Al Davis [mailto:aldavis@ieee.org] Sent: Thursday, February 08, 2001 12:24 AM To: Dagostino, Tom; ibis@eda.org Subject: Re: BIRD 65.2 On Wed, 07 Feb 2001, Dagostino, Tom wrote: > .......(you don't need > C_comp_pullup, etc with an open drain driver) ..... You don't? It seems to me that real drivers can have capacitance there even if there is no transistor there. From owner-ibis Thu Feb 8 08:40:35 2001 Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f18GeWn06436 for ; Thu, 8 Feb 2001 08:40:34 -0800 (PST) Received: from us-bb-gtwy-2.bb.unisys.com (us-bb-gtwy-2.bb.unisys.com [192.63.78.152]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id QAA23883 for ; Thu, 8 Feb 2001 16:31:06 GMT Received: by us-bb-gtwy-2.bb.unisys.com with Internet Mail Service (5.5.2650.21) id <1M9GYA2G>; Thu, 8 Feb 2001 11:36:57 -0500 Message-ID: From: "Mahoney, Margaret" To: ibis@eda.org Subject: Schottky Barrier Diode Date: Thu, 8 Feb 2001 11:36:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi, Does anyone know how to model a Schottky Barrier Diode in IBIS? If so, how? Maggie Mahoney From owner-ibis Thu Feb 8 09:54:04 2001 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f18Hs0n06871 for ; Thu, 8 Feb 2001 09:54:03 -0800 (PST) Received: from us-ea-gtwy-6.ea.unisys.com (us-ea-gtwy-6.ea.unisys.com [192.61.146.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id RAA05955; Thu, 8 Feb 2001 17:48:47 GMT Received: by us-ea-gtwy-6.ea.unisys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Feb 2001 11:49:09 -0600 Message-ID: From: "Mahoney, Margaret" To: "Dunbar, Tony" Cc: ibis@eda.org Subject: RE: Schottky Barrier Diode Date: Thu, 8 Feb 2001 11:49:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi Tony, I would like to model the Schottky diode as a 2 terminal device and be able to model the reverse recovery time of the diode. The model you sent is a one terminal device, is there a way I could model it with two terminals? Thanks for you help. Maggie -----Original Message----- From: Dunbar, Tony [mailto:tony_dunbar@mentorg.com] Sent: Thursday, February 08, 2001 12:13 PM To: 'Mahoney, Margaret' Subject: RE: Schottky Barrier Diode Hi Maggie, Diodes are relatively simple to model and a Schottky diode should not be any different than a 'regular' diode, except it would have a lower knee voltage. Presumably you have a datasheet to give you this type of information. The attached file is a generic diode model that comes with the Interconnectix (ICX) tools. Feel free to use it as the starting point for your model and shift the V/I table info to suit your needs. If you need any more help with it, please get back to me. Regards, Tony Dunbar Mentor Graphics/ICX Dallas, TX -----Original Message----- From: Mahoney, Margaret [mailto:margaret.mahoney@unisys.com] Sent: Thursday, February 08, 2001 10:37 AM To: ibis@eda.org Subject: Schottky Barrier Diode Hi, Does anyone know how to model a Schottky Barrier Diode in IBIS? If so, how? Maggie Mahoney From owner-ibis Thu Feb 8 10:18:47 2001 Received: from www.sigrity.com ([208.203.156.190]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f18IIhn07010 for ; Thu, 8 Feb 2001 10:18:46 -0800 (PST) Received: from si108 ([208.203.156.180]) by www.sigrity.com (8.10.2/8.10.2) with SMTP id f18IEIp11944 for ; Thu, 8 Feb 2001 10:14:18 -0800 From: "Baikuan Wang" To: Subject: R_dut, L_dut and C_dut Date: Thu, 8 Feb 2001 10:14:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <10C8636AE359D4119118009027AE9987051551F2@FMSMSX34> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Hi, IBIS exports, Regarding V(t) curve, the following circuit is given including R_dut, L_dut and C_dut. My question is: The rising/falling waveform refers to Voltage at the node between C_dut and L_fixture. Am I right? Can you comment? Thanks. Brian Sigity, Inc. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | From owner-ibis Thu Feb 8 10:26:31 2001 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f18IQSn07030 for ; Thu, 8 Feb 2001 10:26:31 -0800 (PST) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id KAA22517 for ; Thu, 8 Feb 2001 10:22:32 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 08 Feb 2001 18:16:34 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id <11G3NPRW>; Thu, 8 Feb 2001 10:06:30 -0800 Message-ID: <10C8636AE359D4119118009027AE998705155214@FMSMSX34> From: "Muranyi, Arpad" To: ibis@eda.org Subject: RE: Schottky Barrier Diode Date: Thu, 8 Feb 2001 10:06:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Did you check out how to use the "TT" parameter? Arpad ==================================================== -----Original Message----- From: Mahoney, Margaret [mailto:margaret.mahoney@unisys.com] Sent: Thursday, February 08, 2001 9:49 AM To: Dunbar, Tony Cc: ibis@eda.org Subject: RE: Schottky Barrier Diode Hi Tony, I would like to model the Schottky diode as a 2 terminal device and be able to model the reverse recovery time of the diode. The model you sent is a one terminal device, is there a way I could model it with two terminals? Thanks for you help. Maggie -----Original Message----- From: Dunbar, Tony [mailto:tony_dunbar@mentorg.com] Sent: Thursday, February 08, 2001 12:13 PM To: 'Mahoney, Margaret' Subject: RE: Schottky Barrier Diode Hi Maggie, Diodes are relatively simple to model and a Schottky diode should not be any different than a 'regular' diode, except it would have a lower knee voltage. Presumably you have a datasheet to give you this type of information. The attached file is a generic diode model that comes with the Interconnectix (ICX) tools. Feel free to use it as the starting point for your model and shift the V/I table info to suit your needs. If you need any more help with it, please get back to me. Regards, Tony Dunbar Mentor Graphics/ICX Dallas, TX -----Original Message----- From: Mahoney, Margaret [mailto:margaret.mahoney@unisys.com] Sent: Thursday, February 08, 2001 10:37 AM To: ibis@eda.org Subject: Schottky Barrier Diode Hi, Does anyone know how to model a Schottky Barrier Diode in IBIS? If so, how? Maggie Mahoney From owner-ibis Thu Feb 8 10:50:41 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f18Iodn07081 for ; Thu, 8 Feb 2001 10:50:40 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA00182; Thu, 8 Feb 2001 10:46:37 -0800 (PST) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1CABT1VF; Thu, 8 Feb 2001 10:46:35 -0800 Sender: bobr@relay1.mentorg.com Message-ID: <3A82E98A.26601CF0@mentor.com> Date: Thu, 08 Feb 2001 10:46:34 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Baikuan Wang CC: ibis@eda.org Subject: Re: R_dut, L_dut and C_dut References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian: You are correct. Bob Ross Mentor Graphics Baikuan Wang wrote: > > Hi, IBIS exports, > > Regarding V(t) curve, the following circuit is given including > R_dut, L_dut and C_dut. My question is: > The rising/falling waveform refers to Voltage at the node > between C_dut and L_fixture. Am I right? Can you comment? > Thanks. > > Brian > Sigity, Inc. > > | > | PACKAGE | TEST FIXTURE > | _________ | > | | DUT | L_dut R_dut | L_fixture R_fixture > | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- > V_fixture > | |_________| | | | > | | | | > | | | | > | C_dut === | === C_fixture > | | | | > | | | | > | GND | GND > | From owner-ibis Thu Feb 8 10:59:55 2001 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f18Ixrn07151 for ; Thu, 8 Feb 2001 10:59:54 -0800 (PST) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id KAA00544; Thu, 8 Feb 2001 10:56:02 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 08 Feb 2001 18:55:56 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id <11G3NTXC>; Thu, 8 Feb 2001 10:55:54 -0800 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A74BF@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'Bob Ross'" , Baikuan Wang Cc: ibis@eda.org Subject: RE: R_dut, L_dut and C_dut Date: Thu, 8 Feb 2001 10:55:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi Brian: I just wanted to point out that for best model creation, it is strongly recomened that R_dut and L_dut be set to zero (i.e. take your data from Si simulations with no package). C_dut represents the output capactiance of the device and is pretty much unavoidable. Regards, Stephen Peters Intel Corp. -----Original Message----- From: Bob Ross [mailto:bob_ross@mentorg.com] Sent: Thursday, February 08, 2001 10:47 AM To: Baikuan Wang Cc: ibis@eda.org Subject: Re: R_dut, L_dut and C_dut Brian: You are correct. Bob Ross Mentor Graphics Baikuan Wang wrote: > > Hi, IBIS exports, > > Regarding V(t) curve, the following circuit is given including > R_dut, L_dut and C_dut. My question is: > The rising/falling waveform refers to Voltage at the node > between C_dut and L_fixture. Am I right? Can you comment? > Thanks. > > Brian > Sigity, Inc. > > | > | PACKAGE | TEST FIXTURE > | _________ | > | | DUT | L_dut R_dut | L_fixture R_fixture > | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- > V_fixture > | |_________| | | | > | | | | > | | | | > | C_dut === | === C_fixture > | | | | > | | | | > | GND | GND > | From owner-ibis Thu Feb 8 18:11:37 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f192Ban09050 for ; Thu, 8 Feb 2001 18:11:36 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id SAA28814; Thu, 8 Feb 2001 18:07:42 -0800 (PST) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1SJS08X7; Thu, 8 Feb 2001 18:07:41 -0800 Sender: bobr@relay1.mentorg.com Message-ID: <3A8350ED.15F4026@mentor.com> Date: Thu, 08 Feb 2001 18:07:41 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Agenda 2/16/01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 2/16/01 Bridge Number Reservation # Passcode (916) 356-9200 2-508083 4216977 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Leventhal, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin/Ross - JEDEC JC-16 Modeling and Testing Sessions DesignCon 2001 IBIS Summit Meeting Review Ross Date 2001 European IBIS Summit Meeting Ross IBIS Model Review Committee Angulo New Administrative Issues All 8:45 Technical Discussion (some topics may be deferred) Connector Proposal Review Panella IBIS Futures Group Report (IBIS-X, API, BIRDxx) Peters BIRD65.2 - C_comp Refinements (Vote) Muranyi BIRD68.1 - Clarify that Rising and Falling Waveform Lorang Tables Should be Correlated (Vote) BIRD69 - Golden Waveforms Edlund ibischk3 Bug Tracking Ross - BUG53 BUG34 is not Implemented Correctly in Ross/Mirmak Version 3.2.6 - BUG49 Warning Message for Unreferenced Models, Ross/Mirmak Submodels - resolution New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Mon Feb 12 16:33:14 2001 Received: from ns1.mentorg.com (ns1.mentorg.com [192.94.38.65]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1D0X1n04769; Mon, 12 Feb 2001 16:33:14 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by ns1.mentorg.com (8.8.8/CF5.40F) id QAA23136; Mon, 12 Feb 2001 16:29:05 -0800 (PST) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15MYW92C; Mon, 12 Feb 2001 16:29:03 -0800 Sender: bobr@ns1.mentorg.com Message-ID: <3A887FCC.867092D6@mentor.com> Date: Mon, 12 Feb 2001 16:29:00 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org, si-list@silab.eng.sun.com Subject: EUROPEAN IBIS SUMMIT MEETING 2ND ANNOUNCEMENT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: This is the second announcement for the European IBIS Summit Meeting to be held on Friday, March 16, 2001 after the DATE 2001 exhibition in Munich Germany. The purpose is to promote communication among users and developers of IBIS models in Europe. The meeting is free and open to everyone. Refreshments and a hot lunch will be provided to all attendees. Below is more information. We have four presentations so far. Bob Ross Mentor Graphics E U R O P E A N I B I S S U M M I T M E E T I N G S E C O N D A N N O U N C E M E N T Time/Date: 8:30 PM - 5:00 PM, Friday, March 16, 2001 Location: ASTRON HOTEL/Neue Messe Eggenfeldener Strasse 100 Munich, Germany This hotel is near the DATE 2001 Conference Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas Sponsors: Cadence Design, Innoveda, Mentor Graphics, Zuken DATE 2001: March 13 - 16, 2001. The IBIS meeting is scheduled the day after the DATE 2001 exhibition ends. Location: International Congress Center, Munich, Germany See http://www.date-conference.com for more information. BACKGROUND We have been holding interesting European IBIS Summit Meetings for the last three years. This year we are planning another meeting to include: Submitted Presentations on IBIS Topics (See below) Information about IBIS Version 3.2 and Activities Less formal Ad Hoc Presentations and Discussions IBIS Questions and Answers Below is an invitation to register and also to submit presentations. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the European IBIS Summit meeting. If you plan to participate, please register with the information below (deadline, March 9, 2001): Name: E-mail address: Company: Telephone: Send to: Karine Loudet (karine_loudet@mentor.com) +33 1 40 94 74 54 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Some suggested subjects of interest are: IBIS Model Development Experiences Company IBIS Standards and Requirements Generating and Validating IBIS Models Future IBIS Requirements EMC/EMI IBIS Issues Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by March 6, 2001. Otherwise the presentor will be expected to provide 50 copies for distribution. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Karine Loudet (karine_loudet@mentor.com) Bob Ross (bob_ross@mentor.com) AGENDA The agenda includes presentations, discussions. A free lunch is scheduled for all attendees. Several presentations submitted so far are listed: - Parasitic IC Emission Modeling Etienne Sicard, National Institute of Applied Science, Toulouse, France - DOGEN, A Siemens Internal Model Tool, Extension 1999 - 2001 Hans Pichlmaier, Siemens, Germany - Title to be Determined Eckhard Lenski, Siemens, Germany - LVDS Modeling Hazem Hegany and Mohammed Korany, Mentor Graphics, Egypt FOR FURTHER INFORMATION: Bob Ross, Chair, EIA/IBIS Open Forum Mentor Graphics 8005 S.W. Boeckman Road Wilsonville, Oregon 97070 USA (503) 685-0732 bob_ross@mentor.com From owner-ibis Wed Feb 14 12:57:21 2001 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1EKvHn16729 for ; Wed, 14 Feb 2001 12:57:20 -0800 (PST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id UAA02679 for ; Wed, 14 Feb 2001 20:54:49 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 14 Feb 2001 20:53:25 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id <1P58RRS8>; Wed, 14 Feb 2001 12:53:24 -0800 Message-ID: <10C8636AE359D4119118009027AE998705155240@FMSMSX34> From: "Muranyi, Arpad" To: ibis@eda.org Subject: RE: BIRD 65.2 Date: Wed, 14 Feb 2001 12:53:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Tom, Al's response was correct that it is possible to have capacitance when there is no IV curve. For example, in ASIC cell technology the designer may use a complementary buffer in an open-source configuration, which basically 3-states half of the buffer for ever. In this case the IBIS model would not have an IV curve for the always off transistor, even though it may have capacitance. However, your real question in my mind is whether we should make all four C_comp values required. I spelled it out in the usage rules section that |*** If the C_comp subparameter is not present at least |*** one of the C_comp_pullup, C_comp_pulldown, C_comp_power, and |*** C_comp_gnd subparameters is required. It says "at least one of the ... subparameters is required". Does this answer your question? Arpad ======================================================= -----Original Message----- From: Dagostino, Tom [mailto:tom_dagostino@mentorg.com] Sent: Wednesday, February 07, 2001 11:50 PM To: 'Al Davis'; ibis@eda.org Subject: RE: BIRD 65.2 Re: required C_comp In stead of requiring all 4 values of C_comp (you don't need C_comp_pullup, etc with an open drain driver) require the appropriate C_comp for every IV table in the model. Tom Dagostino IBIS and Tau Modeling Manager SDD Mentor Graphics Corp. 503-685-1613 tom_dagostino@mentor.com From owner-ibis Wed Feb 14 16:57:52 2001 Received: from smtp.huawei.com ([202.96.135.132]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1F0vfn17606 for ; Wed, 14 Feb 2001 16:57:45 -0800 (PST) Received: from h03678 ([10.105.28.106]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G8RWZR03.P07; Thu, 15 Feb 2001 08:50:15 +0800 Message-ID: <001301c096e9$d60e9480$6a1c690a@huawei.com> From: "Rachel Huang" To: "Muranyi, Arpad" , References: <10C8636AE359D4119118009027AE998705155240@FMSMSX34> Subject: Re: BIRD 65.2 Date: Thu, 15 Feb 2001 08:54:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by server.eda.org id f1F0wfn17607 Please stop sending me emails. You have sent them to a wrong person. Regards, Rachel Huang ----- Original Message ----- From: Muranyi, Arpad To: Sent: Thursday, February 15, 2001 4:53 AM Subject: RE: BIRD 65.2 > Tom, > > Al's response was correct that it is possible to have > capacitance when there is no IV curve. For example, > in ASIC cell technology the designer may use a > complementary buffer in an open-source configuration, > which basically 3-states half of the buffer for ever. > In this case the IBIS model would not have an IV curve > for the always off transistor, even though it may have > capacitance. > > However, your real question in my mind is whether we > should make all four C_comp values required. I spelled > it out in the usage rules section that > > |*** If the C_comp subparameter is not present at least > |*** one of the C_comp_pullup, C_comp_pulldown, C_comp_power, and > |*** C_comp_gnd subparameters is required. > > It says "at least one of the ... subparameters is required". > > Does this answer your question? > > Arpad > ======================================================= > > > -----Original Message----- > From: Dagostino, Tom [mailto:tom_dagostino@mentorg.com] > Sent: Wednesday, February 07, 2001 11:50 PM > To: 'Al Davis'; ibis@eda.org > Subject: RE: BIRD 65.2 > > > Re: required C_comp > > In stead of requiring all 4 values of C_comp (you don't need C_comp_pullup, > etc with an open drain driver) require the appropriate C_comp for every IV > table in the model. > > Tom Dagostino > IBIS and Tau Modeling Manager > SDD > Mentor Graphics Corp. > 503-685-1613 > tom_dagostino@mentor.com > From owner-ibis Wed Feb 14 17:00:34 2001 Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1F10Un17645 for ; Wed, 14 Feb 2001 17:00:33 -0800 (PST) Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with ESMTP id AAA21052; Thu, 15 Feb 2001 00:53:09 GMT Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id <1RTB94RT>; Wed, 14 Feb 2001 16:52:54 -0800 Message-ID: <10C8636AE359D4119118009027AE998705155246@FMSMSX34> From: "Muranyi, Arpad" To: "'Al Davis'" , ibis@eda.org Subject: RE: BIRD 65.2 Date: Wed, 14 Feb 2001 16:52:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C096E9.A059F410" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C096E9.A059F410 Content-Type: text/plain; charset="iso-8859-1" Al, You are raising good points. First of all, I agree that IBIS-X will solve most or all of these issues. However, this BIRD was originally written a long time ago, when we had no idea how long it will take to make IBIS-X a reality. Even though that day is getting closer, I am still not entirely sure when it will happen. When this BIRD was first written, the idea was to have a quick release of IBIS4 with minor fixes. This BIRD was written, because when HSPICE implemented their new B-element (the IBIS element) they connected the C_comp to the ideal "node 0" ground. I could not do ANY reasonable power bounce simulations that way, and I had to ask them to fix it IMMEDIATELY, which they did. So HSPICE has this fixed now, and it would make sense for the IBIS spec to have it fixed the same way. Unfortunately, the quick release of IBIS4 has gotten dragged out way beyond my expectations. It was targeted to be done by the summer following the East Coast summit a year and a half ago. I agree, if IBIS-X happens soon it may not make sense to have IBIS4 at all, but we don't know that for sure yet. Now, I understand that this BIRD does not answer many of the more detailed questions, such as voltage and frequency dependency, non linearity, etc... I will be glad to leave that to IBIS-X. However, the intent was to get this fixed on the first order, since the connection to node 0 does not make sense at all. Regarding prototyping, is it not enough that HSPICE version 2000.2 has it and it works? Regarding the splitting of the DC and AC currents, all I can say is that whether it is done correctly or not, the HSPICE B-element in v2000.2 is much more useful than the earlier versions without this fix. I CAN simulate return currents and power delivery simulations much more accurately than I could before which was basically bogus. It may be true that there is still room for improvements in terms of accuracy, but as I said it above, I will leave those issues to be addressed in IBIS-X. Regarding how you can measure the independent C_comp values I am including an HSPICE example for you in the attachment. I am not sure if it will go through the email reflector, so I am sending a duplicate of this message to you directly. This example shows only two capacitance calculations for C_vcc and C_gnd, but the idea can be easily extended to four, if independent clamping circuits would require that. This example is done in the time domain, and is not the only way you can do this. There are other techniques using the .AC sweep for this. Regarding TT (transit time), even though it can be viewed as a related item (AC capacitance), I still think of it differently. It controls how the diode currents turn on or off with respect to time. This C_comp BIRD is more related to how much of the total capacitance current should come from the vcc and/or gnd pins. This has not much to do with time. I hope this will answer some of your questions. Sincerely, Arpad ============================================================ -----Original Message----- From: Al Davis [mailto:aldavis@ieee.org] Sent: Wednesday, February 07, 2001 10:56 AM To: ibis@eda.org Subject: Re: BIRD 65.2 (Most of this message is a repeat, because the issues have not been addressed.) I have some questions and reservations on this. To summarize, although I agree that such a thing is needed, this proposal does not solve the problem adequately and has the potential for introducing problems that have not been considered. Also, the problem it intends to solve becomes a non-issue once IBIS-X is completed. The first question is how difficult it is to implement. Ordinarily, I would say that it is necessary to prove it with a prototype, but it is a simple topology change, so it would be no worse than the existing C_comp. Incidentally, the C_comp as we know it is rarely implemented correctly for driving models. It is very difficult to do correctly. The implementations tend to be very good for non-driving models, where it is just a simple capacitor. In any case, it is no worse than what we have so I am satisfied on this point. Still, testing is a problem. How do you measure it? How do you validate that the measured data actually relates to reality? Before approval of this bird, I would like to see a description of a procedure for measuring it, and a procedure for validating that the measured data is actually correct and useful. These procedures should be tried on a prototype. The purpose is stated to be information on how the capacitance is distributed over the 4 ground/power nodes. Another way to look at it is how the current in the capacitance is distributed. OK. Now back up. We have pullup/pulldown and the clamps for the DC conditions. The proposed c_comp's are the dynamic parts. Existing models usually do not model the split of these correctly. The pullup and power clamp are sort of in parallel, so the measurement is usually to measure the clamps in input or tri-state mode, and the pullup/pulldown in driving mode, by measuring a total and subtracting off the clamps. This often leads to the pullup/pulldown showing strange bahavior when it is masked by the clamps, because the subtraction magnifies the errors. In any case, the current path is not necessarily as intended. The standard provides the mechanism to properly model the current paths, but most models do not. They arbitrarily mix them. Given that most models do not get the DC split correct, what justifies even trying for the dynamic part? The next issue is that this capacitance is strongly nonlinear. Measuring it in the various states produces very different results. Even then, there is no hint at what they do during the transition, other than that the wave tables include the effect. The wave tables do not provide information on how that current is distributed to the 4 power/ground nodes, and possibly also to other connection nodes including input and enable. The nonlinear nature of this capacitance is significant in the development of the simulator algorithms. Some actual models will only work accurately when the capacitance is treated as nonlinear. Part of this capacitance is already in the standard as transit time. The [TT*] parameters are essentially equivalent to the C_comp_power and C_comp_ground parts, complete with the nonlinear component. Thus, part of what this bird proposes is already available. (OK -- the bird asks for the linear part.) Do you have any examples of actual models that use these parameters? with test data showing the quality of correlation to the real device? How many simulators support it fully? It has been in the standard for a long time. Considering the number of unanswered questions, and that this functionality and much more will be available in IBIS-X, I think it is best not to rush into this. So, Arpad, you should prototype this in IBIS-X (trivial) , and also prototype a measurement system for it in IBIS-X (not so trivial). This will validate both this bird and IBIS-X. The rest of us should wait for the answer. Note to readers not familiar with IBIS-X: This is a proposed future IBIS based on a macro language. It is fully backward compatible with IBIS as we know it, and provides the capability to add extensions like this one easily. Arpad and I are both on the sub-committee that is working on it. A prototype implementation of IBIS-X is being built, and a partial one (incomplete work in progress) is available for review to the committee and to those interested. The change in wording of the "required" section is an improvement, but it still needs work. How about: Either the C_comp parameter or all four of C_comp_pullup, C_comp_pulldown, C_comp_power, and C_comp_gnd are required. If C_comp is provided, the others are not allowed. ------_=_NextPart_000_01C096E9.A059F410 Content-Type: application/octet-stream; name="c_meter.sp" Content-Disposition: attachment; filename="c_meter.sp" Capacitance meter circuit *************************************************************************** .TRAN 100.0e-12 '2*dt' SWEEP CapV LIN 'Points+1' CapV1 CapV2 .OPTIONS POST=1 POST_VERSION=9007 ACCURATE NUMDGT=8 *************************************************************************** .PARAM CapV1 = 0.0V .PARAM CapV2 = 5.0V .PARAM Points = 20 .PARAM dt = 100.0e-9 *************************************************************************** .PARAM dV = 'CapV2-CapV1' .PARAM Ovh = 0.1 .PARAM CapV = 0.0V *************************************************************************** .MEAS TRAN dV_dt DERIVATIVE V(Sweep) WHEN V(Sweep)=CapV .MEAS TRAN Sw_I1 FIND PAR('I(Vsw)') WHEN V(Sweep)=CapV Rise=1 .MEAS TRAN Sw_I2 FIND PAR('I(Vsw)') WHEN V(Sweep)=CapV Fall=1 .MEAS TRAN Cap PARAM='abs((Sw_I1-Sw_I2)/2/dV_dt)' .MEAS TRAN Sw_Ivcc FIND PAR('I(Vvcc)') WHEN V(Sweep)=CapV Fall=1 .MEAS TRAN Cap_vcc PARAM='abs((Sw_Ivcc-I(Vvcc_iv))/dV_dt)' .MEAS TRAN Sw_Ignd FIND PAR('I(Vgnd)') WHEN V(Sweep)=CapV Fall=1 .MEAS TRAN Cap_gnd PARAM='abs((Sw_Ignd-I(Vgnd_iv))/dV_dt)' .MEAS TRAN Sum PARAM='Cap_vcc+Cap_gnd' *************************************************************************** Vvcc Vcc 0 DC= 5.0 Vvcc_iv Vcc_iv 0 DC= 5.0 * Vgnd GRND 0 DC= 0.0 Vgnd_iv GRND_iv 0 DC= 0.0 * Viv Viv 0 DC= CapV Vsw Sweep 0 PWL + 0ns 'CapV1-dV*Ovh' + dt 'CapV2+dV*Ovh' + '2*dt' 'CapV1-dV*Ovh' *************************************************************************** X1 in Sweep Vcc GRND 0 IO_buf R1 in 0 1e+3 * X2 in Viv Vcc_iv GRND_iv 0 IO_buf R2 in 0 1e+3 * *C1 Sweep 0 C=10.0pF $ Test capacitor (constant) *C1 Sweep 0 C='10.0e-12*V(sweep)' $ Test capacitor (variable) *************************************************************************** .END ------_=_NextPart_000_01C096E9.A059F410 Content-Type: application/octet-stream; name="IO_buf.inc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IO_buf.inc" ************************************************************************= *** .SUBCKT IO_buf input output power ground enable ************************************************************************= *** *X1 enable en_b power ground INVERTER *X2 input en_b pre_p1 power ground NAND2 *X3 input enable pre_n1 power ground NOR2 *X4 pre_p1 pre_p2 power ground INVERTER mult_p=3D2 = mult_n=3D2 *X5 pre_n1 pre_n2 power ground INVERTER mult_p=3D2 = mult_n=3D2 *X6 pre_p2 pre_p2 gate_p power ground NAND2 mult_p=3D4 = mult_n=3D2 *X7 pre_n2 pre_n2 gate_n power ground NOR2 mult_p=3D2 = mult_n=3D4 * *Mp output gate_p power power PMOS L=3D0.800U W=3D43.40U = NRD=3D0.0897 NRS=3D0.0737 Mp output power power power PMOS L=3D0.800U W=3D43.40U = NRD=3D0.0897 NRS=3D0.0737 + AS=3D434.0P AD=3D217.0P PS=3D106.8U = PD=3D53.40U + M=3D12 *Mn output gate_n ground ground NMOS L=3D0.800U W=3D43.40U = NRD=3D0.0897 NRS=3D0.0714 Mn output power ground ground NMOS L=3D0.800U W=3D43.40U = NRD=3D0.0897 NRS=3D0.0714 + AS=3D434.0P AD=3D217.0P PS=3D106.8U = PD=3D53.40U + M=3D6 *C1 pre_p2 ground C=3D0.07pF *C2 pre_n2 ground C=3D0.07pF *C3 gate_p ground C=3D0.04pF *C4 gate_n ground C=3D0.03pF * R1 input in_R R=3D200 C5 in_R ground C=3D0.2pF X8 input out_r power ground INVERTER * .SUBCKT INVERTER IN OUT POW GRND mult_p=3D1 mult_n=3D1 = ************************ Minv1 OUT IN POW POW PMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D26.88P PS=3D27.20U = PD=3D27.20U + M=3Dmult_p Minv2 OUT IN GRND GRND NMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D26.88P PS=3D27.20U = PD=3D27.20U + M=3Dmult_n .ENDS = ********************************************************************* * .SUBCKT NAND2 IN1 IN2 OUT POW GRND mult_p=3D1 mult_n=3D1 = ********************** Mnand1 OUT IN1 POW POW PMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D13.44P PS=3D27.20U = PD=3D13.60U + M=3Dmult_p Mnand2 OUT IN2 POW POW PMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D13.44P PS=3D27.20U = PD=3D13.60U + M=3Dmult_p Mnand3 OUT IN2 N_N GRND NMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D13.44P AD=3D26.88P PS=3D13.60U = PD=3D27.20U + M=3Dmult_n Mnand4 N_N IN1 GRND GRND NMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D13.44P PS=3D27.20U = PD=3D13.60U + M=3Dmult_n .ENDS = ********************************************************************* * .SUBCKT NOR2 IN1 IN2 OUT POW GRND mult_p=3D1 mult_n=3D1 = *********************** Mnor1 P_P IN1 POW POW PMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D13.44P PS=3D27.20U = PD=3D13.60U + M=3Dmult_p Mnor2 OUT IN2 P_P POW PMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D13.44P AD=3D26.88P PS=3D13.60U = PD=3D27.20U + M=3Dmult_p Mnor3 OUT IN2 GRND GRND NMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D13.44P PS=3D27.20U = PD=3D13.60U + M=3Dmult_p Mnor4 OUT IN1 GRND GRND NMOS L=3D0.800U W=3D11.200U NRD=3D0.0714 = NRS=3D0.0714 + AS=3D26.88P AD=3D13.44P PS=3D27.20U = PD=3D13.60U + M=3Dmult_p .ENDS = ********************************************************************* * ************************************************************************= ***=20 * LEVEL3 MOS MODEL *-----------------------------------------------------------------------= ---=20 .MODEL NMOS NMOS (LEVEL=3D3 UO=3D300.0 VTO=3D1.0 + TPG=3D1 TOX=3D20E-9 NSUB=3D2.0E17 VMAX=3D200.0E3 + RSH=3D70 XJ=3D100.0E-9 LD=3D100.0E-9 DELTA=3D20.00E-3 = THETA=3D0.2 + ETA=3D10.0E-3 KAPPA=3D20.0E-18 PB=3D0.80 JS=3D0.00 + CGSO=3D2.0E-10 CGDO=3D2.0E-10 CJ=3D0.300E-3 CJSW=3D0.200E-9=20 + MJ=3D300.0E-3 MJSW=3D200.0E-3) *-----------------------------------------------------------------------= ---=20 .MODEL PMOS PMOS (LEVEL=3D3 UO=3D100.0 VTO=3D-1.0 + TPG=3D-1 TOX=3D20E-9 NSUB=3D3.0E17 GAMMA=3D1.0 VMAX=3D250.0E3 + RSH=3D80 XJ=3D400.0E-9 LD=3D100.0E-9 DELTA=3D20.0E-3 = THETA=3D0.20 + ETA=3D40.0E-3 KAPPA=3D20.0E-18 PB=3D0.80 JS=3D0.00 + CGSO=3D5.0E-10 CGDO=3D4.0E-10 CJ=3D0.5E-3 CJSW=3D0.2E-9=20 + MJ=3D500.0E-3 MJSW=3D300.0E-3) *-----------------------------------------------------------------------= ---=20 .ENDS ************************************************************************= *** ------_=_NextPart_000_01C096E9.A059F410-- From owner-ibis Wed Feb 14 18:28:44 2001 Received: from kestrel.prod.itd.earthlink.net (kestrel.prod.itd.earthlink.net [207.217.121.155]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1F2Shn18008 for ; Wed, 14 Feb 2001 18:28:44 -0800 (PST) Received: from rosebud.al.dynip.com (dialup-209.245.171.45.Seattle1.Level3.net [209.245.171.45]) by kestrel.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id SAA04198; Wed, 14 Feb 2001 18:24:50 -0800 (PST) Received: from hobbes ([192.168.22.7]) by rosebud.al.dynip.com (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with SMTP id f1F2PlT31739; Wed, 14 Feb 2001 18:25:47 -0800 X-Authentication-Warning: rosebud.al.dynip.com: Host [192.168.22.7] claimed to be hobbes From: Al Davis To: "Muranyi, Arpad" , ibis@eda.org Subject: Re: BIRD 65.2 Date: Wed, 14 Feb 2001 18:24:08 -0800 X-Mailer: KMail [version 1.1.61] Content-Type: text/plain References: <10C8636AE359D4119118009027AE998705155246@FMSMSX34> In-Reply-To: <10C8636AE359D4119118009027AE998705155246@FMSMSX34> MIME-Version: 1.0 Message-Id: <0102141824081G.01056@hobbes> Content-Transfer-Encoding: 8bit On Wed, 14 Feb 2001, Muranyi, Arpad wrote: (answers to my questions.) Thank you. That is the information I was looking for. From owner-ibis Tue Feb 20 13:37:00 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1KLavn21966 for ; Tue, 20 Feb 2001 13:36:59 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id QAA12501 for ; Tue, 20 Feb 2001 16:32:56 -0500 (EST) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id QAA04681 for ; Tue, 20 Feb 2001 16:32:54 -0500 (EST) Received: from innoveda.com ([139.181.6.202]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with ESMTP id NAA06163 for ; Tue, 20 Feb 2001 13:31:45 -0800 (PST) Message-ID: <3A92E151.1F515A95@innoveda.com> Date: Tue, 20 Feb 2001 13:27:45 -0800 From: Guy de Burgh Organization: Innoveda X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting minutes Content-Type: multipart/mixed; boundary="------------21F0843F613CA4958129AD78" This is a multi-part message in MIME format. --------------21F0843F613CA4958129AD78 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------21F0843F613CA4958129AD78 Content-Type: text/plain; charset=us-ascii; name="ibis_mins.2_16_01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ibis_mins.2_16_01.txt" Date: 2/20/01 SUBJECT: 2/16/01 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2001 PARTICIPANTS LIST: 3Com (& CommWorks) Roy Leventhal Agilent (Mark Chang) Ansoft Corporation (Eric Bracken) Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Balistreri Avanti (Chen Hongyu) Brocade Communications Robert Badal Cadence Design Ian Dodd* Cisco Systems Syed Huq, Lungfu Chen Compaq Peter LaFlamme, Ron Bellomio, Quang Dam Cypress (Rajesh Manapat) EMC Corporation Brian Arsenault, Jinhua Chen Fairchild Semiconductor Adam Tambone IBM Michael Cohen*, Greg Edlund*, Wes Martin, Yeon-Chang Hahm, Bill DeVey, Pravin Patel* Innoveda (& HyperLynx) Guy de Burgh*, John Angulo* Intel Corporation Stephen Peters, Arpad Muranyi*, Dave Lorang*, Michael Mirmak*, Qinglun Chen, Will Hobbs LSI Logic Larry Barnes* Mentor Graphics Bob Ross*, Tom Dagostino, Chris Reid, Mike Donnelly, Hazem Hegazy, Tony Dunbar, Griff Derryberry, Dan Lake, Sherif Hammad Mohammed Korany, Weston Beal Micron Technology Randy Wolff*, Yong Phan* Mitsubishi (Tam (Tom) Cao) Molex Incorporated Gus Panella, Brian O'Malley Motorola (Ron Werner) National Semiconductor Milt Schwartz* Nortel Networks Calvin Trowell North East Systems Associates Edward Sayre Philips Semiconductor Zack Ciccone Quantic EMC (Mike Ventham) Robinson-Nugent, Inc. (Alexander Barr) Siemens AG Bernhard Unger, Helmut Katzier SiQual Scott McMorrow, Rob Hinz, Bernard Voss, Chris Brewster Texas Instruments Thomas Fisher, Stephen Nolan, Ramzi Ammar Time Domain Analysis Systems Dima Smolyansky, Steve Corey Tyco Electronics (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) (Werner Rissiek) OTHER PARTICIPANTS IN 2001: Actel Corporation Silvia Montoya Acuson Kim Helliwell AMCC Jeff Smith Apple Computer John Figueroa ASIS Ltd David Wright EIA Cecilia Fleming* FCI Sercu Stefaan Foundary Networks Bertram Chan Framatom Conectors Danny Morlion Fujitsu Ltd Tadashi Arai, Takeshi Murakami Huawei Technologies Rachild Chen Hyundai Electronics Jongho Kang Intrinsix Corporation Steven Chin Nokia Tapani von Ravner Oak Technology Darmin Jin Plexus Technology Group Joseph Socha Signal Integrity Software Douglas Burns, Barry Katz, Walter Katz STMicroelectronics Peter Hirt Xilinx Susan Wu Independent, Consultant Al Davis In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode March 2, 2001 (916) 356-9200 2-508084 6782941 March 16, 2001 European IBIS Summit Meeting - No Phone Bridge 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 AND MEETING QUORUM Pravin Patel from IBM introduced himself. He is replacing Michael Cohen who will be in a new position that is less directly involved with IBIS. Pravin's main interest is in working with and using IBIS models. MEMBERSHIP UPDATE AND TREASURER'S REPORT Cecilia Fleming reported that she has about 22 payments so far, with more expected based on the latest accounting report. Bob commented that we may lose one member due to economic problems, but we have invoiced three other potential members for a total of 36 invoices. Bob reviewed the year 2000 financial results. We have income of about $32,100 versus the budget of $22,800. Our expenses were $18,700 and the revised budget of $21,400. The net income was $18,700 versus the revised budget of $1,400. About $6,200 of income came from non-budgeted ibischk3 parser license payments for 2000. Cecilia is working on the final numbers to account for some additional membership payments made in 2000. The profits will be handled as a reserve account to be used for future expenses. REVIEW OF MINUTES AND AR'S The January 5, 2001 IBIS Minutes were approved without change. The January 29, 2001 IBIS Minutes were approved with this correction: Dr. Norio Matusi submitted a correction for the January 29, 2001 IBIS Summit Minutes regarding the writeup of his presentation - LSI POWER AND GROUND MODEL FOR EMI SIMULATION by Norio Matsui, Applied Simulation Technology and Hiroshi Wabuka, NEC. Norio adds clarification to the last sentence: "Also die interconnect details were not simulated in this study" He submitted the paragraph below: "We have modeled interconnect details in our study. You may find this in two slides. One is flow chart of modeling. Net list plus CR model means that we have extracted so many inter- connection CR models. You may find the result in a slide which shows simplified model. A couple of capacitances both for power and ground are seen simplified model. The original interconnection CRs are involved in the net list." The January 29, 2001 IBIS Minutes were approved with the above correction (added to the uploaded minutes). The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Cecilia Fleming reported that the Upcoming Events have been updated per an input from Syed Huq. Bob Ross reported that Syed Huq made some Roster updates and added the Linux executable for ibischk3. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported some Network Switching and Routing IBIS models from Music Semiconductor: http://www.music-ic.com/technical/techfiles.html and some communication IBIS models from Cirrus Logic: http://www.cirrus.com/design/products/pubs/index.cfm?TypeID=14 Also Bob reported that several links list a number of Lattice Semiconductor IBIS models. Registration is required to get the models. The links are: http://www.latticesemi.com/lit/html/ibis/mach4a.html http://www.latticesemi.com/lit/html/ibis/isp2000ve.html http://www.latticesemi.com/lit/html/ibis/isp5000v.html http://www.latticesemi.com/lit/html/ibis/ispgdx.html Also, a link to a Real Time Video of Arpad Muranyi's IBIS Modeling Training course delivered April 18, 2000 exists at: http://www.silicontech.com/home/seminar-index.shtml Arpad Muranyi commented that this link had been up for quite a while. OPENS FOR NEW ISSUES None. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Cecilia Fleming stated that she requested status information from IEC TC 93 Secretariat, Greg Ledenbach. After the meeting, she sent Bob the following response from Greg: "The document is published for FDIS voting. The record date was 17-January-2001. The voting period is 26-January-2001 to 13-April-2001 with parallel voting in CENELEC." - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - No report. - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross expects at least one presentation and maybe more at the European IBIS Summit Meeting in Munich, Germany on March 16, 2001. - JEDEC JC-16 - Modeling and Testing - Bob Ross had no report from the JEDEC JC-16 and JC-42 meetings in December 2000. Bob received the minutes sent by Cecilia Fleming. There was not any significant IBIS content at that meeting. - T10, Project 1414-DT - SCSI Signal Modeling (a Technical Committee of the National Committee for Information Technology (NCITS)) - Larry Barnes reported that T10 is holding a meeting in California from February 20 - 22, 2001. Information about the Committee can be found on the web site: http://www.t10.org/ Larry stated that the Committee is interested in producing an IBIS BIRD to reduce drive strength upon detection of a second data bit and subsequent bits. Bob Ross will put the T10 Committee on the agenda for a regular report. DESIGNCON 2001 IBIS SUMMIT MEETING REVIEW Bob Ross asked for comments on the DesignCon 2001 IBIS meeting. Bob noted that we had an excellent turnout of 72 plus probably several more who did not sign in. There were some minor logistics issues that were resolved based on the event organizer wanting to save some money. The issues included having refreshments in the room and scheduling the large room at the last minute. These issues were successfully resolved. John Angulo commented that the IBIS-X material was well-received. Guy de Burgh reported that the IBIS booth setup and takedown went smoothly. About half of the EIA brochures were taken, indicating interest in our activities. He is keeping the remainder for another Summit meeting. Bob stated the the logo display looked good. This was a passive booth that served as a meeting place for contacting people. DATE 2001 EUROPEAN IBIS SUMMIT MEETING Bob Ross gave a report on the European IBIS Summit meeting to be held Friday, March 16, 2000 in Munich, Germany along with the Design Automation and Testing in Europe (DATE 2001) conference and exhibit. The IBIS Summit Meeting is on the day after the tradeshow portion of the show. Bob stated that four companies are co-sponsors of the meeting: Cadence, Innoveda, Mentor Graphics, and Zuken (Incases). This pays for the meeting room, refreshments and free lunch to participants. Two announcements have been sent out, one at the end of January 2001, and the other on February 12, 2001. Four presentations are planned so far: Parasitic IC Emisson Modeling Etienne Sicard, National Institute of Applied Science, Toulouse, France DOGEN, A Siemens Internal Model Tool, Extension 1999 - 2001 Hans Pichlmaier, Siemens, Germany Experiences with and Tips for IBIS Models Eckhard Lenski, Siemens, Germany LVDS Modeling Hazem Hegazy and Mohammed Korany, Mentor Graphics, Egypt Arpad Muranyi may give an update on IBIS-X, if he attends: IBIS-X Arpad Muranyi, Intel, USA Bob stated that the meeting will probably last most of the day. IBIS MODEL REVIEW COMMITTEE DISCUSSION John Angulo stated that he sent out two LVDS IBIS models from Texas Instruments for review. Also John is working with the semiconductor vendor concerning another model for review. CONNECTOR PROPOSAL REVIEW Bob Ross noted that a meeting was held on January 16, 2001, mostly to prepare for the IBIS Summit Meeting and also to discuss the revised Version 0.960 document. The next meeting is scheduled on February 27, 2001 to resolve some final details. Bob stated that the main issues remaining are finalizing the header section in a manner consistent with the IBIS-X work, and finalizing the expansion code provided by Ian Dodd. Arpad Muranyi questioned when this would be completed. He wants to use the Specification for package modeling and stated that we need to have a target date for release. Ian clarified that the first version will not have frequency dependent losses. After some discussion, Bob set the goal of completion of the document by the Design Automation Conference time frame in June 2001. The Committee needs to review the work, and the actual public review standardization process takes at least three months. Version 0.960 has most of the technical content. It does need some editorial cleanup. The next meeting will be devoted to the final details for release. IBIS FUTURES (IBIS-X, API, BIRDxx) Bob Ross stated that Working Group meetings were held on January 9, 2001, January 23, 2001, and February 6, 2001. The next meeting is scheduled on February 20, 2001. John Angulo felt that people were interested in the IBIS-X work at the January 26, 2001 IBIS Summit. There was interest in differential buffers, current mode logic and equation based modeling. John stated that Stephen Nolan was interested in a proof of concept exercise to validate its functionality. The goal of the Working Group is to have a document of the 0.9 level to be released in the June time frame for the IBIS Summit Meeting held at the Design Automation Conference. BIRD65.2 - C_comp REFINEMENTS Bob Ross introduced BIRD65.2 by stating that C_comp is split into four values to be attached to up to four rails. We have already had discussion on it at the January 5, 2001 meeting and almost conducted a vote. Arpad Muranyi, the author, provided some additional clarification in issuing BIRD65.2. There was more IBIS reflector discussion and apparently satisfactory responses. Arpad commented that splitting C_comp into four components was needed for a better calculation of ground and power bounce effects for simultaneous switching output analysis. In response to e-mail comments by Al Davis, Arpad stated that BIRD65.2 has been prototyped in a commercial product. Arpad did provide in his e-mail utilities to measure and extract the C_comp components. Finally he reworded a paragraph to clarify that if any of the components of C_comp_* were defined, C_comp was not to be used. The EDA tool would issue a Warning if the C_comp components did not add up to the optional C_comp value. Bob noted that another issue was also clarified. C_comp components could be defined even if the corresponding I-V tables were not defined. For example, a C_comp_pullup could be defined for Open_drain models that did not have the corresponding [Pullup] table. Bob called for a vote. BIRD65.2 was approved by unanimous vote. BIRD68.1 - CLARIFY THAT RISING AND FALLING WAVEFORM TABLES SHOULD BE CORRELATED Bob Ross introduced BIRD68.1 that Dave Lorang issued. BIRD68.1 had revisions discussed at the January 5, 2001 meeting and clarified that the input stimulus could define the common reference point for both [Rising Waveform] and [Falling Waveform] tables. Bob elaborated that while BIRD68.1 was designed to provide a more accurate analysis of intersymbol interference, the correlation was already necessary in modeling differential buffers and handling [Driver Schedule] and [Submodel] constructs. It was noted that BIRD68.1 did not add any new functionality. It clarified the intent of the existing functionality. With this clarification, equal lead-in delay times could be removed from both [Rising Waveform] and [Falling Waveform] tables for faster clock rate analysis. Bob called for a vote. BIRD68.1 was approved by Unanimous vote. Bob stated that approved BIRD65.2 and BIRD68.1 would be added to the draft Version 4.0 specification containing four other approved BIRDs that resides in the work in progress directory: http://www.eda.org/pub/ibis/wip/ BIRD69 - GOLDEN WAVEFORMS Greg Edlund provided a brief introduction to BIRD69. Greg indicated that he had trouble getting his purchasing department to make validated IBIS models a requirement for purchasing components. Embedding the validation waveforms and test circuit provides a solution where the golden waveform keywords could be required by certain vendors. It was noted that the golden waveforms, [Rising Golden Waveform] and [Falling Golden Waveform] are different than the waveforms used in producing the model. Bob Ross commented on some IBIS reflector comments on BIRD69. One dealt with aligning the syntax of the test circuit more closely with some other keywords that indicate connection to ground or power rails. Another stated that the Drive_model_name sub-parameter was redundant since the golden waveforms were already in the specified driver model. Bob also added that the equal sign "=" is used in IBIS only for numerical assignment, and a space is used for name or argument assignment. Greg accepted these comments and would respond in a BIRD69.1 with changes. Bob then opened the discussion to EDA vendors and semiconductor vendors to ask whether they would implement the test circuit analysis or provide the golden waveform data if BIRD69 were passed. The general EDA vendor response was that they would probably do other higher priority projects first unless pressured by users or competition. The semiconductor vendors have a difficult enough time to provide the regular IBIS data and would not want to add to the golden waveform data. Then Bob asked the user community whether they would insist on validation data per BIRD69. Greg responded that there might be interest in doing this. Making this a condition of purchase would force the EDA vendors or some other vendors to add the validation and correlation software in their products. Bob expressed some concerns over BIRD69. While on one hand it provides data that is useful, but could be ignored by tools, it does add complication to the IBIS document. It also does not provide support for the growing need for differential buffer validation. (This could be handled with a separate BIRD.) However, it may still be worthwhile to work on BIRD69 and make the suggested changes. IBISCHK3 BUG TRACKING - BUG53 - BUG34 is Incorrectly Fixed in Version 3.2.6 Bob Ross commented that Michael Mirmak issued BUG53 in response to an incorrect fix in BUG34. Certain missing I-V warning messages are issued for cases where the I-V tables can be missing. Since Warnings are given for correct models, Bob classified BUG53 as Severe, High, and Open. BUG53 needs to fixed soon. Bob also commented that he reviewed ibischk3.2.6 and it appears to have correct fixes for the other BUGs. - BUG49 - Warning Message for Unreferenced Models, Submodels Bob Ross noted that BUG49 was discussed at the January 5, 2001 meeting, but we ran out of time before reaching final resolution. Michael Mirmak also submitted BUG49. It called for a one time Warning message for unreferenced [Model]s that should have been referenced in [Pin], [Model Selector], [Driver Schedule], or [Series Pin Mapping]. It also provided for Warning messages for each unreferenced [Submodel]. After some discussion the resolution was to add BUG49 to the list of BUGs to be fixed. Currently BUGs 48-53 are on the list. Bob noted that BUG53 is the highest priority (to provide the correct fix of BUG34). Currently users may use ibischk3 Version 3.2.6, but also may need to use ibischk3 Version 3.2.5 to test provide assurance that the BUG53 Warning message is not a problem. CONCLUDING TOPICS In the remaining time, Bob Ross and others continued the discussion regarding the goals of IBIS. One issue is whether to include equation based modeling in the first release of IBIS-X, or to conduct a staged release with it coming in the second release . Package modeling is not yet being addressed. The nodal syntax can be used, but the full package modeling should support coupled transmission line package models. Michael Cohen thanked everyone and stated that it was an honor to work with the IBIS Committee. Bob thanked Michael for his service during the past years. NEXT MEETING: The next teleconference meeting will be on Friday, March 2, 2001, from 8:00 AM to 10:00 AM. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 stephen.peters@intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Roy Leventhal (837) 797-2152, Fax: (847) 222-2799 roy_leventhal@3com.com Senior Engineer, CommWorks Corp. (a wholly owned 3Com subsidiary) 1800 W. Central Rd. Mt. Prospect, IL 60056-2293 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 jangulo@innoveda.com Development Engineer, Innoveda 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eigroup.org/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== --------------21F0843F613CA4958129AD78-- From owner-ibis Wed Feb 23 06:49:58 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id e1NEnwX00481 for ; Wed, 23 Feb 2000 06:49:58 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id GAA15744; Thu, 22 Feb 2001 06:56:55 -0800 (PST) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15MYY2CR; Thu, 22 Feb 2001 06:56:55 -0800 Sender: bobr@relay1.mentorg.com Message-ID: <3A9528B6.D352FD30@mentor.com> Date: Thu, 22 Feb 2001 06:56:54 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD69.1 Golden Waveforms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: BIRD69.1 is issued with changes provided by Greg Edlund and documented in the ANALYSIS PATH/DATA THAT LED TO SPECIFICATION section. Bob Ross Mentor Graphics ******************************************************************************* ******************************************************************************* BIRD ID#: 69.1 ISSUE TITLE: Golden Waveforms REQUESTOR: Greg Edlund, IBM DATE SUBMITTED: December 15, 2000, February 22, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Golden Waveforms are a set of SPICE waveforms simulated using known ideal test loads. They are useful in verifying the accuracy of behavioral simulation results for any given simulator. They are not the same thing as the traditional VT tables recommended in the "IBIS Cookbook." The "I/O Buffer Accuracy Handbook" recommends a set of ideal test loads for classical push-pull and open-drain drivers. There is currently a problem with including Golden Waveforms in an IBIS datasheet: the simulator tries to use these waveforms to construct its stimulus waveform, and erroneous simulations result. This BIRD proposes a new syntactical construct to tell the simulator that a waveform is a Golden Waveform. The simulator may then choose to ignore the data or (better yet) run a set of simulations using the network and circuit parameters provided and report the correlation between the simulation results and the Golden Waveforms. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: I propose that we add two new keywords and a corresponding set of sub- parameters to accommodate the inclusion of Golden Waveform in an IBIS datasheet. These sub-parameters should also facilitate simulation. |============================================================================= | Keywords: [Rising Golden Waveform], [Falling Golden Waveform] | Required: No | Description: Documents expected behavioral simulation results using | known ideal test loads for simulation accuracy reporting. | Sub-Params: C1_near, Rs_near, Ls_near, C2_near, Rp1_near, Rp2_near, | Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, C1_far, | R_diff, T_ref, V_term1, V_term1_min, V_term1_max, V_term2, | V_term2_min, V_term2_max, | Pkg_pin, Receiver_model_name, Test_point | Usage Rules: Each [Rising Golden Waveform] and [Falling Golden Waveform] | keyword introduces a table of voltage vs. time points that | describe the shape of a reference waveform. These voltage- | time waveforms are generated under the conditions specified | by the subparameters. The process, temperature, and voltage | conditions under which the waveforms are generated must be | identical to those used to generate the VI and VT tables. | The Golden Waveforms must be generated using unpackaged | driver and receiver models. | | The table itself consists of one column of time points, then | three columns of points in the standard typ, min, and max | format. The four entries must be placed on a single line and | must be separated by at least one white space. All four | columns are required. However, data is only required in the | typical column. If minimum or maximum data is not available, | use the reserved word "NA". The first value in the time | column need not be '0'. The waveform table can contain a | maximum of 1000 data rows. A maximum of 100 waveform tables | are allowed per model. | | The subparameters specify the loading conditions under which | the waveform is generated. The diagram below shows the | interconnection of these elements. | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | R_diff is not shown in the schematic but would be connected | between the true and complement far end nodes in the case | of a differential driver. In this case, the true and | complement nets will be identical as defined by the other | subparameters. | | T_ref is the time at which the output of the driver crosses | V_meas when driving C_ref/R_ref/V_ref with an input signal | identical to the one used to generate the Golden Waveform. | Behavioral simulators may use T_ref to establish a time | base for time correlation measurements. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [voltage range] keyword. | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. | | Pkg_pin is required and indicates which, if any, pin model | was used to generate the Golden Waveform. If the Golden | Waveform represents a packaged simulation, then its value | must be a valid pin name as defined by the [Pin] keyword. | If the Golden Waveform represents an unpackaged simulation, | then the Pkg_pin subparameter must have the value "none." | | Receiver_model_name is required and indicates which, if any, | receiver model was used to simulate the Golden Waveform. | If the Golden Waveform represents a simulation using a | receiver, its value must be a valid model name. If the | Golden Waveform represents a simulation with no receiver, | then the Receiver_model_name subparameter must have the | value "none." | | Test_point is required and defines the node in the above | schematic at which the Golden Waveform is measured. It must | have the value near or far. | | Using the Golden Waveform tables, it is possible to run | behavioral simulations under conditions identical to the ones | used to generate the waveforms in SPICE. The behavioral | waveforms can be correlated against the Golden Waveforms in | voltage and time to produce a quantitative measurement of | the accuracy of 1) the model data, 2) the behavioral model, | and 3) the behavioral simulator. | | If a parameter is not used, it defaults to the value | specified in the following table: | | C1_near = 1f | Rs_near = 1M | Ls_near = 1p | C2_near = 1f | Rp1_near = 1M | Rp2_near = 1M | Td = 1ns | Zo = 50 | Rp1_far = 1M | Rp2_far = 1M | C2_far = 1f | Ls_far = 1p | Rs_far = 1M | C1_far = 1f | T_ref = 1.00ns | R_diff = 1M | V_term1 = 1.0 | V_term1_min = 1.0 | V_term1_max = 1.0 | V_term2 = 1.0 | V_term2_min = 1.0 | V_term2_max = 1.0 | |----------------------------------------------------------------------------- [Rising Golden Waveform] C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff = 100 T_ref = 2.00ns V_term1 = 1.50 V_term1_min = 1.35 V_term1_max = 1.65 V_term2 = 0.00 V_term2_min = 0.05 V_term2_max = 0.05 Pkg_pin none Receiver_model_name Input1 Test_point far | | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Golden Waveform] C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff = 100 T_ref = 2.00ns V_term1 = 1.50 V_term1_min = 1.35 V_term1_max = 1.65 V_term2 = 0.00 V_term2_min = 0.05 V_term2_max = 0.05 Pkg_pin none Receiver_model_name Input1 Test_point far | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The East Coast IBIS Users Group identified a need to document accuracy information and formed the IBIS Accuracy Subcommittee to address this need. This subcommittee met during the year 1997-1998 and drafted what became the "I/O Buffer Accuracy Handbook." This document outlines a set of procedures that can be used by modeling engineers to verify behavioral simulation accuracy, using SPICE simulations as a reference. This BIRD provides an infrastructure within IBIS for communicating important accuracy data as defined by the "I/O Buffer Accuracy Handbook." It is not intended that this BIRD require any simulator changes except to ignore the new keywords and sub-parameters. However, should a simulator vendor decide to use the new keywords and sub-parameters, it is intended that they provide a complete set of information for carrying out simulations that may be used to report correlation statistics to the user. In the absence of simulator support, the user would have to perform the correlation work manually (which many of us are doing already) using the information in the new Golden Waveform tables. It is entirely up to the modeling engineer to decide which values to assign to which sub-parameters. This is an engineering decision that should be based on the design of the I/O buffer under test. The generalized test load network should cover a broad range of I/O buffer families. Since these new keywords and sub-parameters are not required, I don't see any backward compatibility problems. BIRD69.1 Changes by Greg Edlund: I have updated BIRD 69 according to our discussion during the Open Forum last Friday. Here is a summary of the changes: 1. Removed subparameter Driver_model_name (was redundant). 2. Removed "=" from Node and Receiver_model_name. 3. Changed name of subparameter Node to Test_point to enhance clarity. 4. Added subparameter R_diff to handle far-end termination for differential drivers. 5. Replaced V_term with V_term1. Added V_term2 to allow for termination to negative voltages, e.g. ECL. 6. Added subparameter Pkg_pin to indicate which package model, if any, to use. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: I have discussed similar ideas with members of several simulator vendor companies, and each had a positive response in general. Please see the "I/O Buffer Accuracy Handbook" for complete details on correlation test loads, procedures, and metrics. The C program "ack" could provide an example of correlation metric calculation for interested simulator vendors. Thanks to Jerry Hayes at IBM for coming up with the idea for a generalized test load network. ******************************************************************************* From owner-ibis Fri Feb 23 11:26:07 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1NJQ5j00602 for ; Fri, 23 Feb 2001 11:26:06 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA21319; Fri, 23 Feb 2001 11:26:00 -0800 (PST) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQQYLM26; Fri, 23 Feb 2001 11:25:59 -0800 Sender: bobr@relay1.mentorg.com Message-ID: <3A96B946.91864EA6@mentor.com> Date: Fri, 23 Feb 2001 11:25:58 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Meeting 3/2/01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 3/2/01 Bridge Number Reservation # Passcode (916) 356-9200 2-508084 6782941 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Leventhal, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin/Ross - JEDEC JC-16 Modeling and Testing Sessions - T10, Project 1414-DT - SCSI Signal Modeling Barnes Date 2001 European IBIS Summit Meeting Ross IBIS Model Review Committee Angulo New Administrative Issues All 8:45 Technical Discussion (some topics may be deferred) Connector Proposal Review Panella IBIS Futures Group Report (IBIS-X, API, BIRDxx) Peters BIRD69.1 - Golden Waveforms Edlund ibischk3 Bug Tracking Ross - BUG54 - Corners with NA Give Bad Test Load Warnings Mirmak New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Tue Feb 27 01:10:47 2001 Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1R9Ajj18927 for ; Tue, 27 Feb 2001 01:10:46 -0800 (PST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA06917 for ; Tue, 27 Feb 2001 10:10:49 +0100 (MET) Received: from icn.siemens.de ([139.21.8.237]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA07112 for ; Tue, 27 Feb 2001 10:10:17 +0100 (MET) Message-ID: <3A9B6EF5.D38893A2@icn.siemens.de> Date: Tue, 27 Feb 2001 10:10:13 +0100 From: Katja Zuleeg Organization: Siemens AG X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From owner-ibis Tue Feb 27 06:17:28 2001 Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1REHQj20431 for ; Tue, 27 Feb 2001 06:17:27 -0800 (PST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA03775 for ; Tue, 27 Feb 2001 15:17:30 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA26220 for ; Tue, 27 Feb 2001 15:17:29 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 15:17:28 +0100 Message-ID: From: Koller Katja To: "'ibis@eda.org'" Subject: subscribe Date: Tue, 27 Feb 2001 15:17:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Katja.Koller@icn.siemens.de From owner-ibis Tue Feb 27 12:08:49 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1RK8lj22048; Tue, 27 Feb 2001 12:08:48 -0800 (PST) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA01512; Tue, 27 Feb 2001 10:59:10 -0800 (PST) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FW9BF9RS; Tue, 27 Feb 2001 10:59:09 -0800 Sender: bobr@relay1.mentorg.com Message-ID: <3A9BF8FC.B3569891@mentor.com> Date: Tue, 27 Feb 2001 10:59:08 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org, si-list@silab.eng.sun.com Subject: EUROPEAN IBIS SUMMIT 3/16/01 - THIRD ANNOUNCEMENT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: This is the third announcement for the European IBIS Summit Meeting to be held on Friday, March 16, 2001 after the DATE 2001 exhibition in Munich Germany. The purpose is to promote communication among users and developers of IBIS models in Europe. The meeting is free and open to everyone. Refreshments and a hot lunch will be provided to all attendees. Below is more information. We have approximately 11 presentations so far listed below. Some titles are tentative. If you have not done so, please respond to Karine Loudet if you are attending. Bob Ross Mentor Graphics E U R O P E A N I B I S S U M M I T M E E T I N G T H I R D A N N O U N C E M E N T Time/Date: 8:30 PM - 5:00 PM, Friday, March 16, 2001 Location: ASTRON HOTEL/Neue Messe Eggenfeldener Strasse 100 Munich, Germany This hotel is near the DATE 2001 Conference Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas Sponsors: Cadence Design, Innoveda, Mentor Graphics, Zuken DATE 2001: March 13 - 16, 2001. The IBIS meeting is scheduled the day after the DATE 2001 exhibition ends. Location: International Congress Center, Munich, Germany See http://www.date-conference.com for more information. BACKGROUND We have been holding interesting European IBIS Summit Meetings for the last three years. This year we are planning another meeting to include: Submitted Presentations on IBIS Topics (See below) Information about IBIS Version 3.2 and Activities Less formal Ad Hoc Presentations and Discussions IBIS Questions and Answers Below is an invitation to register and also to submit presentations. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the European IBIS Summit meeting. If you plan to participate, please register with the information below (deadline, March 9, 2001): Name: E-mail address: Company: Telephone: Send to: Karine Loudet (karine_loudet@mentor.com) +33 1 40 94 74 54 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Some suggested subjects of interest are: IBIS Model Development Experiences Company IBIS Standards and Requirements Generating and Validating IBIS Models Future IBIS Requirements EMC/EMI IBIS Issues Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by March 6, 2001. Otherwise the presentor will be expected to provide 50 copies for distribution. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Karine Loudet (karine_loudet@mentor.com) Bob Ross (bob_ross@mentor.com) AGENDA The agenda includes presentations, discussions. A free lunch is scheduled for all attendees. Some titles have not been finalized: - EMC Standardization Progress (title to be determined) Jean-Claude Perrin, Texas Instruments, France - EMC Models (title to be determined) Christian Marot, Siemens, France - Parasitic IC Emisson Modeling Etienne Sicard, National Institute of Applied Science, Toulouse, France - Ground-Noise Model Mariusz Faferko, Fraunhofer Institute Reliability and Microintegration, Germany - Radiated Emission Model for IC Peter Kralicek, Fraunhofer Institute Reliability and Microintegration, Germany - DOGEN, A Siemens Internal Model Tool, Extension 1999 - 2001 Hans Pichlmaier, Siemens AG, Germany - Experiences with and Tips for IBIS Models Eckhard Lenski, Siemens AG, Germany - IBIS Bus Modeling (title to be determined) Bernhard Unger, Siemens AG, Germany - LVDS Modeling Hazem Hegany and Mohammed Korany, Mentor Graphics, Egypt - (title to be determined) John Barrie, Zuken, England - IBIS-X Arpad Muranyi, Intel, USA FOR FURTHER INFORMATION: Bob Ross, Chair, EIA/IBIS Open Forum Mentor Graphics 8005 S.W. Boeckman Road Wilsonville, Oregon 97070 USA (503) 685-0732 bob_ross@mentor.com From owner-ibis Tue Feb 27 15:33:18 2001 Received: from ausxc08.us.dell.com (ausxc08.us.dell.com [143.166.99.216]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1RNXHj22735 for ; Tue, 27 Feb 2001 15:33:18 -0800 (PST) Received: by ausxc08.us.dell.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 17:30:44 -0600 Message-ID: From: Girish_Singh@Dell.com To: ibis@vhdl.org Subject: Subscribe! Date: Tue, 27 Feb 2001 17:30:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" -Girish. Simulation Engineer Signal Integrity Group Dell Computer Corporation. (512)-723-6210 E-Mail:Girish_Singh@Dell.com www.dell.com From owner-ibis Tue Feb 27 15:40:30 2001 Received: from ausxc07.us.dell.com (ausxc07.us.dell.com [143.166.99.215]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f1RNeTj22802 for ; Tue, 27 Feb 2001 15:40:30 -0800 (PST) Received: by ausxc07.us.dell.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 17:34:37 -0600 Message-ID: From: Girish_Singh@Dell.com To: ibis@vhdl.org Subject: PCI/PCIX STANDARD IBIS MODEL... Date: Tue, 27 Feb 2001 17:34:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi All, Does anyone have a standard PCI and PCIX IBIS Model? I have a standard PCIX Model but the test load seems to be too heavy for the Weak Buffer(Tval(max)Rising/Falling Edge Test Load).I made my PCIX Model from the PCIX Bus Specifications,Rev 1.0. Thanks in advance for the help. -Girish Simulation Engineer Signal Integrity Group Dell Computer Corporation. (512)-723-6210 E-Mail:Girish_Singh@Dell.com www.dell.com