From owner-ibis Sun Oct 4 18:35:54 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA06648 for ; Sun, 4 Oct 1998 18:35:54 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA26468; Sun, 4 Oct 1998 18:31:07 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA02806; Sun, 4 Oct 1998 18:31:05 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA12602; Sun, 4 Oct 98 18:31:04 PDT Date: Sun, 4 Oct 98 18:31:04 PDT Message-Id: <9810050131.AA12602@bob> To: ibis@eda.org Subject: IBIS BIRD55 - [Model Spec] Vmeas Addition IBIS folks: BIRD55 proposes defining the timing test load extraction based on typical model parameters only. Only single values are given for the [Model] keyword subparameters Vmeas, Vref, Rref, and Cref. However minimum and maximum column values of Vmeas are needed in simulators when minimum and maximum columns are used for the models. Currently there there is an inconsistency between PECL and ECL timing specification numbers and applications for the same device. More details of a proposal are given below to promote discussion and understanding. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 55 ISSUE TITLE: [Model Spec] Vmeas Addition REQUESTER: Bob Ross, Mentor Graphics DATE SUBMITTED: October 4, 1998 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Vmeas may need to be different for min and max columns. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Changes and additions to the [Model Spec] keyword are shown by the |* lines to add Vmeas with typ-min-max values: |============================================================================= | Keyword: [Model Spec] | Required: No | Sub-Params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, | S_overshoot_low, D_overshoot_high, D_overshoot_low, |* D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas | Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparameters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- | S_overshoot_high Static overshoot high voltage | S_overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | |* Vmeas Measurement voltage for timing measurements |* | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab character. All four columns are required under | the [Model Spec] keyword. However, data is required only in | the typical column. If minimum and/or maximum values are not | available, the reserved word "NA" must be used indicating the | typical value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage Range settings. | | Unless noted below, each subparameter does not require having | any other subparameter. | | Vinh, Vinl rules: | | The threshold subparameter lines provide additional min and | max column values, if needed. The typ column values are still | required and would be expected to override the Vinh and Vinl | subparameter values specified elsewhere. Note: the syntax | rule that require inserting Vinh and Vinl under models remains | unchanged even if the values are defined under the [Model | Spec] keyword. | | To mimic a hysteresis effect, the values of Vinh and Vinl may | be interchanged such that the Vinl value is larger than the | Vinh value. However, simulators may process this information | differently or report an error. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | | The four hysteresis subparmeters must all be defined before | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | | S_overshoot_high, S_overshoot_low rules: | | The static overshoot subparameters provide the voltage values | for which the model is no longer guaranteed to function | correctly. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | | The dynamic overshoot values provide a time window during | which the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time | is required for dynamic overshoot testing. In addition, if | D_overshoot_high is specified, then S_overshoot_high is | necessary for testing beyond the static limit. Similarly, if | D_overshoot_low is specified, then S_overshoot_low is | necessary for testing beyond the static limit. | | Pulse_high, Pulse_low, Pulse_time rules: | | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. | Similarly, the falling response may drop below the Vinh value, | but remain above the Pulse_low value. In either case the | input is regarded as immune to switching if the responses | are within these extended windows. If the hysteresis | thresholds are defined, then the rising response shall use | Vinh- as the reference voltage, and the falling response shall | use Vinl+ as the reference voltage. |* |* Vmeas rules: |* |* The Vmeas values under the [Model Spec] keyword override the |* Vmeas entry elsewhere. |----------------------------------------------------------------------------- [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | S_overshoot_high 5.5 5.0 6.0 | Static overshoot S_overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | |*** ADDED EXAMPLE BELOW: | Timing Thresholds | Vmeas 3.68 3.18 4.68 | A 5 volt PECL | | example | |*** END OF ADDED EXAMPLE |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRD55 is issued because the timing measurement value Vmeas defined under the [Model] keyword changes with the Vcc reference voltage for some technologies (such as PECL) when used for the min or max column. This can cause ibischk3 Warning messages, particularly for the min column that the waveform cannot drive through Vmeas. Adding the Vref, Rref, Cref timing load list of parameters for [Model Spec] was also considered. However, the Rref and Cref values are always fixed in data books (we are not interested it the tolerances of these components). Also Vref tends to be fixed. The compelling reason for not including these is that the REFERENCE value for timing test load extraction should be taken from the typical model only (it is the only required set of data). From a data book point of view. the timing test load is fixed, and a number of devices could be tested. The spread of the results (based on minimum and maximum process corners and test conditions) would define the specification range of timing values in the data book. From a simulator point of view, the typical value model would center up the calibration of the simulator delays to the midpoint or typical component delay in the data book. A minimum or maximum model already has a slower response or faster response that should have already contributed to some of the delay spread in the data book. So it is not clear what number to compare this response delay to in the data book without risking "double counting" some of the delay. Vmeas may be used elsewhere for other measurements related to calibrating the actual response under minimum and maximum column test conditions. Thus minimum and maximum column entries are needed (related to the Vcc values). However, Vref would not be needed to be changed since the actual calibration extraction should be done using typical conditions to avoid "double counting" of delay changes due to model response changes. ibischk2+ and ibischk3 checks whether the signal passes throught the timing reference for each column. For PECL technology, the signal may not be able to reach the reference value for the minimum column. If the same device is configured for ECL operation (with a 0 volt reference), the values of Vref and Vmeas remain at a constant offset from the positive rail, and no Warning is issued. This inconsistency would be resolved with BIRD55 by simply not doing the check for minimum and maximum conditions. (A Bug report would have to be filed to make the change in ibischk3.) An alternative approach is to add Vmeas_min and Vmeas_max, etc. subparameters to the [Model] keyword. This would be similar to the V_fixture_min and V_fixture_max subparameters for the [Rising Waveform] and [Falling Waveform] keywords. However, the [Model Spec] keyword method is chosen since it is already set up for formating existing and new subparameter values into a typical/minimum/maximum column format. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Wed Oct 7 16:23:45 1998 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA15810 for ; Wed, 7 Oct 1998 16:23:44 -0700 (PDT) Received: from uucp3.uu.net by relay1.UU.NET with SMTP (peer crosschecked as: uucp3.uu.net [192.48.96.83]) id QQfkcz24139; Wed, 7 Oct 1998 19:19:26 -0400 (EDT) Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL ; Wed, 7 Oct 1998 19:19:27 -0400 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA17374; Wed, 7 Oct 98 16:18:13 PDT Received: from f14 by qdt.com (4.1/SMI-4.1) id AA23862; Wed, 7 Oct 98 16:15:08 PDT Sender: crokusek@qdt.com Message-Id: <361BF5FB.500F9F30@viewlogic.com> Date: Wed, 07 Oct 1998 16:15:07 -0700 From: Chris Rokusek Organization: Viewlogic Systems X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@eda.org Subject: True or False? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ibisians, I have a Quiz, True or False: The models of pins referenced by a [Diff Pin] keyword may NOT be of any of the following: Terminator, Series, Series_switch. Chris I think the spec implicitly says TRUE... |============================================================================= | Keyword: [Diff Pin] | Required: No | Description: Associates differential pins, their differential threshold | voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max | Usage Rules: Enter only differential pin pairs. The first column, [Diff | Pin], contains a non-inverting pin name. The second column, | inv_pin, contains the corresponding inverting pin name for | I/O output. Each pin name must match the pin names declared | previously in the [Pin] section of the IBIS file. The third | column, vdiff, contains the specified output and differential | threshold voltage between pins if the pins are Input or I/O | model types. For output only differential pins, the vdiff | entry is 0 V. The fourth, fifth, and sixth columns, | tdelay_typ, tdelay_min, and tdelay_max, contain launch delays | of the non-inverting pins relative to the inverting pins. The | values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh | and Vinl. | | If vdiff is not defined for a pin that is defined as requiring | a Vinh by its [Model] type, vdiff is set to the default value | of 200 mV. | | Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the inv_pin | column is Inverting. This convention enables one [Model] to | be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tdelay_typ, or tdelay_min columns, its | entry is interpreted as 0 V or 0 ns. If "NA" appears in the | tdelay_max column, its value is interpreted as the tdelay_typ | value. When using six columns, the headers tdelay_min and | tdelay_max must be listed. Entries for the tdelay_min column | are based on minimum magnitudes; and tdelay_max column, | maximum magnitudes. One entry of vdiff, regardless of its | polarity, is used for difference magnitudes. |----------------------------------------------------------------------------- [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0 22 21 NA NA | Output*, tdelay = 0 | * Could be Input or I/O with vdiff = 0 | |====================================================================== From owner-ibis Wed Oct 7 18:08:02 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA15992 for ; Wed, 7 Oct 1998 18:08:01 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA29929; Wed, 7 Oct 1998 18:01:29 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA03547; Wed, 7 Oct 1998 18:01:28 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA23949; Wed, 7 Oct 98 18:01:27 PDT Date: Wed, 7 Oct 98 18:01:27 PDT Message-Id: <9810080101.AA23949@bob> To: crokusek@viewlogic.com, ibis@eda.org Subject: Re: True or False? Cc: bobr@emicx.mentorg.com Chris: I vote for True. Bob Ross Interconnectix/Mentor Graphics > Date: Wed, 07 Oct 1998 16:15:07 -0700 > From: Chris Rokusek > To: ibis@eda.org > Subject: True or False? > Ibisians, > I have a Quiz, True or False: > The models of pins referenced by a [Diff Pin] keyword may NOT be of any > of the following: > Terminator, > Series, > Series_switch. > Chris > I think the spec implicitly says TRUE... > |============================================================================= > | Keyword: [Diff Pin] > | Required: No > | Description: Associates differential pins, their differential > threshold > | voltages, and differential timing delays. > | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max > | Usage Rules: Enter only differential pin pairs. The first column, > [Diff > | Pin], contains a non-inverting pin name. The second > column, > | inv_pin, contains the corresponding inverting pin name > for > | I/O output. Each pin name must match the pin names > declared > | previously in the [Pin] section of the IBIS file. The > third > | column, vdiff, contains the specified output and > differential > | threshold voltage between pins if the pins are Input or > I/O > | model types. For output only differential pins, the > vdiff > | entry is 0 V. The fourth, fifth, and sixth columns, > | tdelay_typ, tdelay_min, and tdelay_max, contain launch > delays > | of the non-inverting pins relative to the inverting > pins. The > | values can be of either polarity. > | > | If a pin is a differential input pin, the differential > input > | threshold (vdiff) overrides and supersedes the need for > Vinh > | and Vinl. > | > | If vdiff is not defined for a pin that is defined as > requiring > | a Vinh by its [Model] type, vdiff is set to the default > value > | of 200 mV. > | > | Other Notes: The output pin polarity specification in the table > overrides > | the [Model] Polarity specification such that the pin in > the > | [Diff Pin] column is Non-Inverting and the pin in the > inv_pin > | column is Inverting. This convention enables one > [Model] to > | be used for both pins. > | > | Column length limits are: > | [Diff Pin] 5 characters max > | inv_pin 5 characters max > | vdiff 9 characters max > | tdelay_typ 9 characters max > | tdelay_min 9 characters max > | tdelay_max 9 characters max > | > | Each line must contain either four or six columns. If > "NA" is > | entered in the vdiff, tdelay_typ, or tdelay_min columns, > its > | entry is interpreted as 0 V or 0 ns. If "NA" appears in > the > | tdelay_max column, its value is interpreted as the > tdelay_typ > | value. When using six columns, the headers tdelay_min > and > | tdelay_max must be listed. Entries for the tdelay_min > column > | are based on minimum magnitudes; and tdelay_max column, > | maximum magnitudes. One entry of vdiff, regardless of > its > | polarity, is used for difference magnitudes. > |----------------------------------------------------------------------------- > [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max > | > 3 4 150mV -1ns 0ns -2ns | Input or I/O > pair > 7 8 0V 1ns NA NA | Output* pin > pair > 9 10 NA NA NA NA | Output* pin > pair > 16 15 200mV 1ns | Input or I/O pin pair > 20 19 0V NA | Output* pin pair, tdelay = 0 > 22 21 NA NA | Output*, tdelay = 0 > | * Could be Input or I/O with > vdiff = 0 > | > |====================================================================== From owner-ibis Thu Oct 8 09:36:09 1998 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA18521 for ; Thu, 8 Oct 1998 09:36:08 -0700 (PDT) Received: from fmsmsx28.fm.intel.com (fmsmsx28.fm.intel.com [132.233.61.205]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id QAA12981; Thu, 8 Oct 1998 16:30:27 GMT Message-Id: <199810081630.QAA12981@calliope1.fm.intel.com> Received: by FMSMSX28 with Internet Mail Service (5.5.1960.3) id ; Thu, 8 Oct 1998 09:30:27 -0700 From: "Muranyi, Arpad" To: "\"crokusek@viewlogic.com\" " , "\"ibis@eda.org\" " Cc: "\"bobr@emicx.mentorg.com\" " Subject: RE: True or False? Date: Thu, 8 Oct 1998 08:48:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" I would vote for FALSE, because I could see them being used together in a situation where you have a differential pair going into the chip and come out on two other pins though a series model. For example, let's make pin2 = diff_in+ pin3 = diff_in- pin4 = diff_out+ pin5 = diff_out- where the ins and outs are "shorted" with metal. In this case the [Diff Pin] keyword would associate pins 2-3 and pins 4-5 as differencial, but the [Series Pin Mapping] keyword would connect pins 2-4 and pins 3-5. Since the series models ignore the C_comp, the only way I can enter the die capacitance into this picture is if I use the Terminator model on each pin with nothing but C_comp in it. This is how I can see the series and terminator models used together with differencial pins. Arpad ============================================================================ ==== Chris: I vote for True. Bob Ross Interconnectix/Mentor Graphics > Date: Wed, 07 Oct 1998 16:15:07 -0700 > From: Chris Rokusek > To: ibis@eda.org > Subject: True or False? > Ibisians, > I have a Quiz, True or False: > The models of pins referenced by a [Diff Pin] keyword may NOT be of any > of the following: > Terminator, > Series, > Series_switch. > Chris > I think the spec implicitly says TRUE... > |=========================================================================== == > | Keyword: [Diff Pin] > | Required: No > | Description: Associates differential pins, their differential > threshold > | voltages, and differential timing delays. > | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max > | Usage Rules: Enter only differential pin pairs. The first column, > [Diff > | Pin], contains a non-inverting pin name. The second > column, > | inv_pin, contains the corresponding inverting pin name > for > | I/O output. Each pin name must match the pin names > declared > | previously in the [Pin] section of the IBIS file. The > third > | column, vdiff, contains the specified output and > differential > | threshold voltage between pins if the pins are Input or > I/O > | model types. For output only differential pins, the > vdiff > | entry is 0 V. The fourth, fifth, and sixth columns, > | tdelay_typ, tdelay_min, and tdelay_max, contain launch > delays > | of the non-inverting pins relative to the inverting > pins. The > | values can be of either polarity. > | > | If a pin is a differential input pin, the differential > input > | threshold (vdiff) overrides and supersedes the need for > Vinh > | and Vinl. > | > | If vdiff is not defined for a pin that is defined as > requiring > | a Vinh by its [Model] type, vdiff is set to the default > value > | of 200 mV. > | > | Other Notes: The output pin polarity specification in the table > overrides > | the [Model] Polarity specification such that the pin in > the > | [Diff Pin] column is Non-Inverting and the pin in the > inv_pin > | column is Inverting. This convention enables one > [Model] to > | be used for both pins. > | > | Column length limits are: > | [Diff Pin] 5 characters max > | inv_pin 5 characters max > | vdiff 9 characters max > | tdelay_typ 9 characters max > | tdelay_min 9 characters max > | tdelay_max 9 characters max > | > | Each line must contain either four or six columns. If > "NA" is > | entered in the vdiff, tdelay_typ, or tdelay_min columns, > its > | entry is interpreted as 0 V or 0 ns. If "NA" appears in > the > | tdelay_max column, its value is interpreted as the > tdelay_typ > | value. When using six columns, the headers tdelay_min > and > | tdelay_max must be listed. Entries for the tdelay_min > column > | are based on minimum magnitudes; and tdelay_max column, > | maximum magnitudes. One entry of vdiff, regardless of > its > | polarity, is used for difference magnitudes. > |--------------------------------------------------------------------------- -- > [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max > | > 3 4 150mV -1ns 0ns -2ns | Input or I/O > pair > 7 8 0V 1ns NA NA | Output* pin > pair > 9 10 NA NA NA NA | Output* pin > pair > 16 15 200mV 1ns | Input or I/O pin pair > 20 19 0V NA | Output* pin pair, tdelay = 0 > 22 21 NA NA | Output*, tdelay = 0 > | * Could be Input or I/O with > vdiff = 0 > | > |====================================================================== From owner-ibis Thu Oct 8 10:54:59 1998 Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA18889 for ; Thu, 8 Oct 1998 10:54:58 -0700 (PDT) Received: from uucp3.uu.net by relay6.UU.NET with SMTP (peer crosschecked as: uucp3.uu.net [192.48.96.83]) id QQfkfv06170; Thu, 8 Oct 1998 13:50:35 -0400 (EDT) Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL ; Thu, 8 Oct 1998 13:50:36 -0400 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA22240; Thu, 8 Oct 98 10:53:06 PDT Received: from f14 by qdt.com (4.1/SMI-4.1) id AA07316; Thu, 8 Oct 98 10:49:34 PDT Sender: crokusek@qdt.com Message-Id: <361CFB2D.7566F4CF@viewlogic.com> Date: Thu, 08 Oct 1998 10:49:33 -0700 From: Chris Rokusek Organization: Viewlogic Systems X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: arpad.muranyi@intel.com Cc: ibis@eda.org Subject: Re: True or False? References: <199810081630.QAA12981@calliope1.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad, The Spec explicitly does NOT allow either side of the series device to be anything except terminator. So how can you have a differential relationship (such as vdiff, or tdelay) between terminators (there's no sensing nor driving)? I argue that if that component is not sensing the voltage difference on those pins then from the point of view of that component, the pins are not differential. Note that if you want the nets to be connected differentionally, this would occur at a another component(s) on the board which would have an actual differential driver or receiver pair triggering an electrical association between the nets. I+ ---series--- O+ I- ---series--- O- Would it be sufficient to define the [Series mapping] only and not the [Diff Pin] relationship for the above case? Chris > > > I would vote for FALSE, because I could see them being used together in a > situation where you have a differential pair going into the chip and come > out on > two other pins though a series model. For example, let's make > > pin2 = diff_in+ > pin3 = diff_in- > pin4 = diff_out+ > pin5 = diff_out- > > where the ins and outs are "shorted" with metal. > > In this case the [Diff Pin] keyword would associate pins 2-3 and pins 4-5 as > > differencial, but the [Series Pin Mapping] keyword would connect pins 2-4 > and > pins 3-5. Since the series models ignore the C_comp, the only way I can > enter > the die capacitance into this picture is if I use the Terminator model on > each > pin with nothing but C_comp in it. > > This is how I can see the series and terminator models used together with > differencial pins. > > Arpad > ========================================================================== > From owner-ibis Thu Oct 8 11:39:37 1998 Received: from mail-gw5.pacbell.net (mail-gw5.pacbell.net [206.13.28.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA19054 for ; Thu, 8 Oct 1998 11:39:37 -0700 (PDT) Received: from pacbell.net (ppp-209-79-182-215.vntrcs.pacbell.net [209.79.182.215]) by mail-gw5.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id LAA18917; Thu, 8 Oct 1998 11:34:07 -0700 (PDT) Message-ID: <361D04A7.4DF6BE40@pacbell.net> Date: Thu, 08 Oct 1998 11:29:59 -0700 From: Jon Powell Reply-To: jonp@qdt.com Organization: Viewlogic Consulting Services X-Mailer: Mozilla 4.04 [en]C-PBI-NC404 (Win95; I) MIME-Version: 1.0 To: "Muranyi, Arpad" CC: "\"crokusek@viewlogic.com\"" , "\"ibis@eda.org\"" , "\"bobr@emicx.mentorg.com\"" Subject: Re: True or False? References: <199810081630.QAA12981@calliope1.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Be careful on this question. We are not asking "what do we want" we are asking, "What does the spec say" jon From owner-ibis Thu Oct 8 11:45:47 1998 Received: from wile.nesa.com ([204.240.29.30]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA19071 for ; Thu, 8 Oct 1998 11:45:45 -0700 (PDT) Received: (from mail@localhost) by wile.nesa.com (8.8.5/8.8.5) id OAA20139; Thu, 8 Oct 1998 14:37:18 -0400 Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3) id sma020135; Thu Oct 8 14:37:16 1998 Message-Id: <3.0.3.32.19981008143706.0070da2c@mail.nesa.com> X-Sender: esayre@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 08 Oct 1998 14:37:06 -0400 To: Chris Rokusek From: "Dr. Edward P. Sayre" Subject: Re: True or False? Cc: ibis@eda.org In-Reply-To: <361CFB2D.7566F4CF@viewlogic.com> References: <199810081630.QAA12981@calliope1.fm.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" All differential quantities, whether they be voltage or impedance, etc. are derived quantities. They come from the node voltages and can always be defined in terms of the node voltages. If the current IBIS specs allowed for arithmetic operations, then diffential quantities could be defined in terms of the node quantities. ed sayre -------------------- At 10:49 AM 10/8/98 -0700, you wrote: >Arpad, > >The Spec explicitly does NOT allow either side of the series device to >be anything except terminator. So how can you have a differential >relationship (such as vdiff, or tdelay) between terminators (there's >no sensing nor driving)? I argue that if that component is not >sensing the voltage difference on those pins then from the point of >view of that component, the pins are not differential. > >Note that if you want the nets to be connected differentionally, this >would occur at a another component(s) on the board which would have an >actual differential driver or receiver pair triggering an electrical >association between the nets. > > I+ ---series--- O+ > > I- ---series--- O- > >Would it be sufficient to define the [Series mapping] only and not the >[Diff Pin] relationship for the above case? > >Chris > >> >> >> I would vote for FALSE, because I could see them being used together in a >> situation where you have a differential pair going into the chip and come >> out on >> two other pins though a series model. For example, let's make >> >> pin2 = diff_in+ >> pin3 = diff_in- >> pin4 = diff_out+ >> pin5 = diff_out- >> >> where the ins and outs are "shorted" with metal. >> >> In this case the [Diff Pin] keyword would associate pins 2-3 and pins 4-5 as >> >> differencial, but the [Series Pin Mapping] keyword would connect pins 2-4 >> and >> pins 3-5. Since the series models ignore the C_comp, the only way I can >> enter >> the die capacitance into this picture is if I use the Terminator model on >> each >> pin with nothing but C_comp in it. >> >> This is how I can see the series and terminator models used together with >> differencial pins. >> >> Arpad >> ========================================================================== >> > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dr. Ed Sayre e-mail: esayre@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.978.897-8787 | | Stow, MA 01775 USA Fax +1.978.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Thu Oct 8 12:02:24 1998 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA19151 for ; Thu, 8 Oct 1998 12:02:24 -0700 (PDT) Received: from fmsmsx18.intel.com (fmsmsx18.fm.intel.com [132.233.233.232]) by thalia.fm.intel.com (8.8.6/8.8.5) with ESMTP id SAA03554; Thu, 8 Oct 1998 18:56:49 GMT Message-Id: <199810081856.SAA03554@thalia.fm.intel.com> Received: by FMSMSX18 with Internet Mail Service (5.5.1960.3) id ; Thu, 8 Oct 1998 11:56:49 -0700 From: "Muranyi, Arpad" To: "\"Chris Rokusek\" " Cc: "\"ibis@eda.org\" " Subject: RE: True or False? Date: Thu, 8 Oct 1998 11:54:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Chris, 1) Could you please point it out to me where the spec says that it is NOT allowed to have anything, except terminators on either side of the series device? I don't recall reading that, but might have missed it. 2) Our device which has this situation actually does sense the signal differentially, but since it never drives and the clamps are so far out from the signal swing, we didn't include a receiver model (even though I was considering to do it). 3) It may be sufficient to define [Series mapping] only if we didn't have a receiver in the device. Since we just made an IBIS model like that, you got my curiosity up, is it really illegal to do this? By the way, it passed the parser, so if it is illegal, should the parser check for that? Arpad ============================================================================ === Arpad, The Spec explicitly does NOT allow either side of the series device to be anything except terminator. So how can you have a differential relationship (such as vdiff, or tdelay) between terminators (there's no sensing nor driving)? I argue that if that component is not sensing the voltage difference on those pins then from the point of view of that component, the pins are not differential. Note that if you want the nets to be connected differentionally, this would occur at a another component(s) on the board which would have an actual differential driver or receiver pair triggering an electrical association between the nets. I+ ---series--- O+ I- ---series--- O- Would it be sufficient to define the [Series mapping] only and not the [Diff Pin] relationship for the above case? Chris > > > I would vote for FALSE, because I could see them being used together in a > situation where you have a differential pair going into the chip and come > out on > two other pins though a series model. For example, let's make > > pin2 = diff_in+ > pin3 = diff_in- > pin4 = diff_out+ > pin5 = diff_out- > > where the ins and outs are "shorted" with metal. > > In this case the [Diff Pin] keyword would associate pins 2-3 and pins 4-5 as > > differencial, but the [Series Pin Mapping] keyword would connect pins 2-4 > and > pins 3-5. Since the series models ignore the C_comp, the only way I can > enter > the die capacitance into this picture is if I use the Terminator model on > each > pin with nothing but C_comp in it. > > This is how I can see the series and terminator models used together with > differencial pins. > > Arpad > ========================================================================== > From owner-ibis Thu Oct 8 12:30:42 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA19188 for ; Thu, 8 Oct 1998 12:30:41 -0700 (PDT) Received: from Kellee98 ([192.168.148.110]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id MAA11374; Thu, 8 Oct 1998 12:22:58 -0700 Message-Id: <199810081922.MAA11374@mail.hyperlynx.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 08 Oct 1998 12:22:56 -0700 To: Chris Rokusek , ibis@eda.org From: Kellee Crisafulli Subject: Re: True or False? In-Reply-To: <361BF5FB.500F9F30@viewlogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id MAA19189 It is TRUE, At 04:15 PM 10/7/98 -0700, Chris Rokusek wrote: >Ibisians, > >I have a Quiz, True or False: > >The models of pins referenced by a [Diff Pin] keyword may NOT be of any >of the following: > > Terminator, > Series, > Series_switch. > >Chris > >I think the spec implicitly says TRUE... > >|========================================================================== === >| Keyword: [Diff Pin] >| Required: No >| Description: Associates differential pins, their differential >threshold >| voltages, and differential timing delays. >| Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max >| Usage Rules: Enter only differential pin pairs. The first column, >[Diff >| Pin], contains a non-inverting pin name. The second >column, >| inv_pin, contains the corresponding inverting pin name >for >| I/O output. Each pin name must match the pin names >declared >| previously in the [Pin] section of the IBIS file. The >third >| column, vdiff, contains the specified output and >differential >| threshold voltage between pins if the pins are Input or >I/O >| model types. For output only differential pins, the >vdiff >| entry is 0 V. The fourth, fifth, and sixth columns, >| tdelay_typ, tdelay_min, and tdelay_max, contain launch >delays >| of the non-inverting pins relative to the inverting >pins. The >| values can be of either polarity. >| >| If a pin is a differential input pin, the differential >input >| threshold (vdiff) overrides and supersedes the need for >Vinh >| and Vinl. >| >| If vdiff is not defined for a pin that is defined as >requiring >| a Vinh by its [Model] type, vdiff is set to the default >value >| of 200 mV. >| >| Other Notes: The output pin polarity specification in the table >overrides >| the [Model] Polarity specification such that the pin in >the >| [Diff Pin] column is Non-Inverting and the pin in the >inv_pin >| column is Inverting. This convention enables one >[Model] to >| be used for both pins. >| >| Column length limits are: >| [Diff Pin] 5 characters max >| inv_pin 5 characters max >| vdiff 9 characters max >| tdelay_typ 9 characters max >| tdelay_min 9 characters max >| tdelay_max 9 characters max >| >| Each line must contain either four or six columns. If >"NA" is >| entered in the vdiff, tdelay_typ, or tdelay_min columns, >its >| entry is interpreted as 0 V or 0 ns. If "NA" appears in >the >| tdelay_max column, its value is interpreted as the >tdelay_typ >| value. When using six columns, the headers tdelay_min >and >| tdelay_max must be listed. Entries for the tdelay_min >column >| are based on minimum magnitudes; and tdelay_max column, >| maximum magnitudes. One entry of vdiff, regardless of >its >| polarity, is used for difference magnitudes. >|-------------------------------------------------------------------------- --- >[Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max >| > 3 4 150mV -1ns 0ns -2ns | Input or I/O >pair > 7 8 0V 1ns NA NA | Output* pin >pair > 9 10 NA NA NA NA | Output* pin >pair >16 15 200mV 1ns | Input or I/O pin pair >20 19 0V NA | Output* pin pair, tdelay = 0 >22 21 NA NA | Output*, tdelay = 0 > | * Could be Input or I/O with >vdiff = 0 >| >|====================================================================== > --------------------------------------------------------- Have a great day.... Kellee Crisafulli at HyperLynx SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Thu Oct 8 12:40:52 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA19217 for ; Thu, 8 Oct 1998 12:40:49 -0700 (PDT) Received: from Kellee98 ([192.168.148.110]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id MAA11417; Thu, 8 Oct 1998 12:33:17 -0700 Message-Id: <199810081933.MAA11417@mail.hyperlynx.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 08 Oct 1998 12:33:15 -0700 To: "Muranyi, Arpad" , "\"crokusek@viewlogic.com\" " , "\"ibis@eda.org\" " From: Kellee Crisafulli Subject: RE: True or False? Cc: "\"bobr@emicx.mentorg.com\" " In-Reply-To: <199810081630.QAA12981@calliope1.fm.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id MAA19218 You should use the .EBD file for this Arpad. I thought the terminator keyword is intended to be used stand alone. At 08:48 AM 10/8/98 -0700, Muranyi, Arpad wrote: >I would vote for FALSE, because I could see them being used together in a >situation where you have a differential pair going into the chip and come >out on >two other pins though a series model. For example, let's make > > pin2 = diff_in+ > pin3 = diff_in- > pin4 = diff_out+ > pin5 = diff_out- > >where the ins and outs are "shorted" with metal. > >In this case the [Diff Pin] keyword would associate pins 2-3 and pins 4-5 as > >differencial, but the [Series Pin Mapping] keyword would connect pins 2-4 >and >pins 3-5. Since the series models ignore the C_comp, the only way I can >enter >the die capacitance into this picture is if I use the Terminator model on >each >pin with nothing but C_comp in it. > >This is how I can see the series and terminator models used together with >differencial pins. > >Arpad >============================================================================ >==== > >Chris: > >I vote for True. > >Bob Ross >Interconnectix/Mentor Graphics > >> Date: Wed, 07 Oct 1998 16:15:07 -0700 >> From: Chris Rokusek >> To: ibis@eda.org >> Subject: True or False? > > >> Ibisians, > >> I have a Quiz, True or False: > >> The models of pins referenced by a [Diff Pin] keyword may NOT be of any >> of the following: > >> Terminator, >> Series, >> Series_switch. > >> Chris > >> I think the spec implicitly says TRUE... > >> >|=========================================================================== >== >> | Keyword: [Diff Pin] >> | Required: No >> | Description: Associates differential pins, their differential >> threshold >> | voltages, and differential timing delays. >> | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max >> | Usage Rules: Enter only differential pin pairs. The first column, >> [Diff >> | Pin], contains a non-inverting pin name. The second >> column, >> | inv_pin, contains the corresponding inverting pin name >> for >> | I/O output. Each pin name must match the pin names >> declared >> | previously in the [Pin] section of the IBIS file. The >> third >> | column, vdiff, contains the specified output and >> differential >> | threshold voltage between pins if the pins are Input or >> I/O >> | model types. For output only differential pins, the >> vdiff >> | entry is 0 V. The fourth, fifth, and sixth columns, >> | tdelay_typ, tdelay_min, and tdelay_max, contain launch >> delays >> | of the non-inverting pins relative to the inverting >> pins. The >> | values can be of either polarity. >> | >> | If a pin is a differential input pin, the differential >> input >> | threshold (vdiff) overrides and supersedes the need for >> Vinh >> | and Vinl. >> | >> | If vdiff is not defined for a pin that is defined as >> requiring >> | a Vinh by its [Model] type, vdiff is set to the default >> value >> | of 200 mV. >> | >> | Other Notes: The output pin polarity specification in the table >> overrides >> | the [Model] Polarity specification such that the pin in >> the >> | [Diff Pin] column is Non-Inverting and the pin in the >> inv_pin >> | column is Inverting. This convention enables one >> [Model] to >> | be used for both pins. >> | >> | Column length limits are: >> | [Diff Pin] 5 characters max >> | inv_pin 5 characters max >> | vdiff 9 characters max >> | tdelay_typ 9 characters max >> | tdelay_min 9 characters max >> | tdelay_max 9 characters max >> | >> | Each line must contain either four or six columns. If >> "NA" is >> | entered in the vdiff, tdelay_typ, or tdelay_min columns, >> its >> | entry is interpreted as 0 V or 0 ns. If "NA" appears in >> the >> | tdelay_max column, its value is interpreted as the >> tdelay_typ >> | value. When using six columns, the headers tdelay_min >> and >> | tdelay_max must be listed. Entries for the tdelay_min >> column >> | are based on minimum magnitudes; and tdelay_max column, >> | maximum magnitudes. One entry of vdiff, regardless of >> its >> | polarity, is used for difference magnitudes. >> >|--------------------------------------------------------------------------- >-- >> [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max >> | >> 3 4 150mV -1ns 0ns -2ns | Input or I/O >> pair >> 7 8 0V 1ns NA NA | Output* pin >> pair >> 9 10 NA NA NA NA | Output* pin >> pair >> 16 15 200mV 1ns | Input or I/O pin pair >> 20 19 0V NA | Output* pin pair, tdelay = 0 >> 22 21 NA NA | Output*, tdelay = 0 >> | * Could be Input or I/O with >> vdiff = 0 >> | >> |====================================================================== > --------------------------------------------------------- Have a great day.... Kellee Crisafulli at HyperLynx SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Thu Oct 8 12:46:42 1998 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA19232 for ; Thu, 8 Oct 1998 12:46:42 -0700 (PDT) Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id TAA22167; Thu, 8 Oct 1998 19:40:36 GMT Message-Id: <199810081940.TAA22167@calliope1.fm.intel.com> Received: by FMSMSX17 with Internet Mail Service (5.5.1960.3) id ; Thu, 8 Oct 1998 12:40:36 -0700 From: "Muranyi, Arpad" To: "\"crokusek@viewlogic.com\" \" " , "\"ibis@eda.org\" \" " , "\"Kellee Crisafulli\" " Cc: "\"bobr@emicx.mentorg.com\" \" " Subject: RE: True or False? Date: Thu, 8 Oct 1998 12:39:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Kellee, My understanding of .EBD is that they are for PC Board description. What I have is a short on the die connecting two pins on the device. How would the .EBD file help me with that? Arpad ============================================================================ === You should use the .EBD file for this Arpad. I thought the terminator keyword is intended to be used stand alone. At 08:48 AM 10/8/98 -0700, Muranyi, Arpad wrote: >I would vote for FALSE, because I could see them being used together in a >situation where you have a differential pair going into the chip and come >out on >two other pins though a series model. For example, let's make > > pin2 = diff_in+ > pin3 = diff_in- > pin4 = diff_out+ > pin5 = diff_out- > >where the ins and outs are "shorted" with metal. > >In this case the [Diff Pin] keyword would associate pins 2-3 and pins 4-5 as > >differencial, but the [Series Pin Mapping] keyword would connect pins 2-4 >and >pins 3-5. Since the series models ignore the C_comp, the only way I can >enter >the die capacitance into this picture is if I use the Terminator model on >each >pin with nothing but C_comp in it. > >This is how I can see the series and terminator models used together with >differencial pins. > >Arpad >=========================================================================== = >==== > >Chris: > >I vote for True. > >Bob Ross >Interconnectix/Mentor Graphics > >> Date: Wed, 07 Oct 1998 16:15:07 -0700 >> From: Chris Rokusek >> To: ibis@eda.org >> Subject: True or False? > > >> Ibisians, > >> I have a Quiz, True or False: > >> The models of pins referenced by a [Diff Pin] keyword may NOT be of any >> of the following: > >> Terminator, >> Series, >> Series_switch. > >> Chris > >> I think the spec implicitly says TRUE... > >> >|========================================================================== = >== >> | Keyword: [Diff Pin] >> | Required: No >> | Description: Associates differential pins, their differential >> threshold >> | voltages, and differential timing delays. >> | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max >> | Usage Rules: Enter only differential pin pairs. The first column, >> [Diff >> | Pin], contains a non-inverting pin name. The second >> column, >> | inv_pin, contains the corresponding inverting pin name >> for >> | I/O output. Each pin name must match the pin names >> declared >> | previously in the [Pin] section of the IBIS file. The >> third >> | column, vdiff, contains the specified output and >> differential >> | threshold voltage between pins if the pins are Input or >> I/O >> | model types. For output only differential pins, the >> vdiff >> | entry is 0 V. The fourth, fifth, and sixth columns, >> | tdelay_typ, tdelay_min, and tdelay_max, contain launch >> delays >> | of the non-inverting pins relative to the inverting >> pins. The >> | values can be of either polarity. >> | >> | If a pin is a differential input pin, the differential >> input >> | threshold (vdiff) overrides and supersedes the need for >> Vinh >> | and Vinl. >> | >> | If vdiff is not defined for a pin that is defined as >> requiring >> | a Vinh by its [Model] type, vdiff is set to the default >> value >> | of 200 mV. >> | >> | Other Notes: The output pin polarity specification in the table >> overrides >> | the [Model] Polarity specification such that the pin in >> the >> | [Diff Pin] column is Non-Inverting and the pin in the >> inv_pin >> | column is Inverting. This convention enables one >> [Model] to >> | be used for both pins. >> | >> | Column length limits are: >> | [Diff Pin] 5 characters max >> | inv_pin 5 characters max >> | vdiff 9 characters max >> | tdelay_typ 9 characters max >> | tdelay_min 9 characters max >> | tdelay_max 9 characters max >> | >> | Each line must contain either four or six columns. If >> "NA" is >> | entered in the vdiff, tdelay_typ, or tdelay_min columns, >> its >> | entry is interpreted as 0 V or 0 ns. If "NA" appears in >> the >> | tdelay_max column, its value is interpreted as the >> tdelay_typ >> | value. When using six columns, the headers tdelay_min >> and >> | tdelay_max must be listed. Entries for the tdelay_min >> column >> | are based on minimum magnitudes; and tdelay_max column, >> | maximum magnitudes. One entry of vdiff, regardless of >> its >> | polarity, is used for difference magnitudes. >> >|-------------------------------------------------------------------------- - >-- >> [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max >> | >> 3 4 150mV -1ns 0ns -2ns | Input or I/O >> pair >> 7 8 0V 1ns NA NA | Output* pin >> pair >> 9 10 NA NA NA NA | Output* pin >> pair >> 16 15 200mV 1ns | Input or I/O pin pair >> 20 19 0V NA | Output* pin pair, tdelay = 0 >> 22 21 NA NA | Output*, tdelay = 0 >> | * Could be Input or I/O with >> vdiff = 0 >> | >> |====================================================================== > --------------------------------------------------------- Have a great day.... Kellee Crisafulli at HyperLynx SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Thu Oct 8 14:48:34 1998 Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA19603 for ; Thu, 8 Oct 1998 14:48:33 -0700 (PDT) Received: from uucp3.uu.net by relay4.UU.NET with SMTP (peer crosschecked as: uucp3.uu.net [192.48.96.83]) id QQfkgk07258; Thu, 8 Oct 1998 17:40:19 -0400 (EDT) Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL ; Thu, 8 Oct 1998 17:41:00 -0400 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA23636; Thu, 8 Oct 98 14:43:06 PDT Received: from f14 by qdt.com (4.1/SMI-4.1) id AA10541; Thu, 8 Oct 98 14:40:42 PDT Sender: crokusek@qdt.com Message-Id: <361D3158.64880EEB@viewlogic.com> Date: Thu, 08 Oct 1998 14:40:40 -0700 From: Chris Rokusek Organization: Viewlogic Systems X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: "Muranyi, Arpad" Cc: "\"ibis@eda.org\"" Subject: Re: True or False? References: <199810081856.SAA03554@thalia.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad, > 1) Could you please point it out to me where the spec says that it is NOT > allowed to have anything, except terminators on either side of the series > device? I don't recall reading that, but might have missed it. Yes, from ver3_2.a.ibs, see 2nd paragraph under Other Notes, sentence #2 below. | Keyword: [Series Pin Mapping] | Other Notes: If the model_name is for a non-symmetrical series model, | then the order of the pins is important. The [Series Pin | Mapping] and pin_2 entries must be in the columns that | correspond with Pin 1 and Pin 2 of the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any other elements such as additional | capacitance or clamping circuitry are defined by the | model_name that is referenced in the [Pin] keyword. The | model_names under the [Pin] keyword that are also referenced | by the [Series Pin Mapping] keyword must be either 'NC' or | reference a [Model] whose Model_type is 'Terminator'. Thus. | for example, a Series_switch model may contain Terminator | models on EACH of the pins to describe both the capacitance | on each pin and some clamping circuitry that may exist on | each pin. > 2) Our device which has this situation actually does sense the signal > differentially, but since it never drives and the clamps are so far out from > the > signal swing, we didn't include a receiver model (even though I was > considering > to do it). We've never had to model "paths through active devices" so that is where the problem comes in where a single pin is defined as both a recevier (customarily terminating the signal) and defined as a passive series device to another pin. However using only the [Series mapping] only will work A.O.K for us as you state in #3 below assuming another component on the board joins these two nets differentially. > 3) It may be sufficient to define [Series mapping] only if we didn't have a > > receiver in the device. > > Since we just made an IBIS model like that, you got my curiosity up, is it > really illegal to do this? By the way, it passed the parser, so if it is > illegal, should the parser check for that? The part I thought was illegal was the tying of a single pin together with other pins using BOTH [Series Mapping] and [Diff Pin] since the Series pins could only be terminators but the Diff Pins had to be NON-terminators. The parser should check. It sounds like you may wish to propose a BIRD to allow this type of thing in the future in which case we will enhance the capabilities of our software to handle. Its just never come up before. There's always been a buffer between Input and Output allowing us to decoupling the two sides of the analysis. Chris From owner-ibis Thu Oct 8 16:04:36 1998 Received: from wile.nesa.com ([204.240.29.30]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA19687; Thu, 8 Oct 1998 16:04:33 -0700 (PDT) Received: (from mail@localhost) by wile.nesa.com (8.8.5/8.8.5) id RAA24270; Thu, 8 Oct 1998 17:35:54 -0400 Received: from porky.nesa.com(204.240.29.45) by wile.nesa.com via smap (V1.3) id sma024247; Thu Oct 8 17:35:47 1998 Message-Id: <3.0.3.32.19981008173538.007424a4@mail.nesa.com> X-Sender: breda@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 08 Oct 1998 17:35:38 -0400 To: ibis-users@eda.org, ibis@eda.org, si-list@silab.Eng.Sun.COM From: Kathy Breda Subject: IBIS SUMMIT FINAL AGENDA - Summit Date Thurs. Oct. 15, 1998 Boxboro, Massachusetts. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To All: Below is the EIA IBIS Summit Agenda. Hope you can join us for this informative meeting. Please sign up with Kathy Breda (breda@nesa.com) by Tuesday, Oct 13, 1998 so we have a final estimate for lunch reservations. Also contact Kathy if you need directions (Word Format) to the meeting or hotel information. Thanks to the following Sponsors (to date): Cadence Design Systems Compaq Computer EMC Corporation Focus Technology. Inc. North East Systems Associates, Inc. (NESA) During the BREAKS and AFTER the Meeting, Informative Demos are available from the following companies: Cadence Design Systems - Todd Westerhoff HyperLynx - Dave Kohlmeier Interconnectix/Mentor Graphics - Kevin Cohan Viewlogic - Jon Powell Also, the IBIS User's Group plans a test board demo. Infinium Scope provided by Hewlett-Packard for the demo. Presentors, please provide the electronic format of the presentation to Kathy Breda (breda@nesa.com) by Tuesday, Oct 13, 1998 for copying, or else plan to bring 50 copies. Everyone is invited to a social gathering and dinner (not supplied) after the meeting at the hotel to unwind interact informally. Bob Ross Interconnectix/Mentor Graphics EIA IBIS OPEN FORUM SUMMIT MEETING AGENDA October 15, 1998 Boxboro Holiday Inn One Adams Place, Boxboro, MA 8:30 A.M. REFRESHMENTS & INFORMAL GATHERING 9:00 WELCOME, INTRODUCTIONS OF PARTICIPANTS Ed Sayre (NESA), Bob Ross (Mentor Graphics) 9:15 GENERAL IBIS BUSINESS /DESIGNCon99 Sponsorship of EIA IBIS Summit Bob Ross (Mentor Graphics) 9:30 IBIS TRAINING TUTORIAL Ed Sayre (NESA), Joe Socha (Trilogic) 10:30 BREAK & OPTIONAL DEMOS 11:00 IBIS TUTORIAL (CONTINUATION) 11:40 IBIS CONNECTOR MODEL DEFINITION BIRD Fabrizio Zanella (EMC) 12:00 P.M. LUNCH (SUPPLIED FREE TO ATTENDEES) 12:30 OPTIONAL DEMOS 1:00 BEHAVIORAL/IBIS MODELING OF A FET BUS SWITCH USING CADENCE TOOLS Tay Ansari (Sun Microsystems) 1:20 IBIS ACCURACY SPECIFICATION Bob Haller (Compaq) 1:40 IBIS ACCURACY TEST BOARD Peter LaFlamme (Fairchild Semiconductor) 2:00 MEASUREMENT AND SIMULATIONS USING VARIOUS TOOLS DEMONSTRATING AND COMPARING 1) MEASUREMENTS, 2) SPICE USING SPICE MODEL, 3) VENDORS "A" AND "B" USING IBIS MODELS Fabrizio Zenella (EMC) 2:20 COMPARISON BETWEEN SPICE AND IBIS I/O DEVICE SIMULATIONS Jinhua Chen (NESA) 2:40 BREAK 3:00 WRITING AND VERIFICATION OF IBIS MODELS Jon Powell (Viewlogic) 3:20 MODEL PROCESSING ALGORITHMS Bob Ross (Mentor Graphics) 3:40 IBIS FUTURES Will Hobbs (Intel) 4:00 TOOL CAPABILITIES NEEDED FOR DESIGNING 100 MHZ INTERCONNECTS Tim Schreyer & Ray Martin (Intel) 4:30 BUSINESS WRAP-UP Bob Ross (Mentor Graphics) 4:40 END OF MEETING OPTIONAL DEMOS OPTIONAL SOCIAL HOUR OPTIONAL GROUP DINNER AT HOTEL +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | NORTH EAST SYSTEMS ASSOCIATES, INC. | | ------------------------------------- | | "High Performance Engineering & Design" | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Kathy Breda e-mail: breda@nesa.com | | NESA, Inc. http://www.nesa.com/ | | 636 Great Road Tel +1.978.897-8787 | | Stow, MA 01775 USA Fax +1.978.897-5359 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From owner-ibis Fri Oct 9 09:38:30 1998 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA22254 for ; Fri, 9 Oct 1998 09:38:30 -0700 (PDT) Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id QAA02229; Fri, 9 Oct 1998 16:32:55 GMT Message-Id: <199810091632.QAA02229@calliope1.fm.intel.com> Received: by FMSMSX26 with Internet Mail Service (5.5.1960.3) id ; Fri, 9 Oct 1998 09:32:54 -0700 From: "Muranyi, Arpad" To: "\"Chris Rokusek\" " Cc: "\"ibis@eda.org\" " Subject: RE: True or False? Date: Fri, 9 Oct 1998 09:31:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Chris, Thanks for the clarification. I reread the section you pointed out to me (several more times) and I believe I am starting to understand the problem. It seems to me that the problem is not that I am using the series model together with a terminator model, but that these were "coupled" as a differential pair. You made a statement that "the Diff Pins had to be NON-terminators" (I guess Input, I/O, etc...). Looking at the [Diff Pin] section of the spec, however, I could not find anything that suggests that differential pins had to be a certain type of a model. Also, I don't see anything in the [Diff Pin] section that calls a [Model](s) for the pins it defines as differential. The [Model] keywords are still referenced only by the pin list section (some times through the [Model Selector] keyword) even if we have a [Diff Pin] definition for them. In my opinion then, it would be perfectly legal (even if it makes no sense) to have two pins in the pin list defined as "NC" while defining them as differential pairs in the [Diff Pin] section. If this is legal then calling Terminator type models in the pin list and defining them as differential pairs should also be legal. Using this argument I would summarize that the model we made is NOT violating the spec. because 1) The pin list calls a model that is type Terminator 2) Terminator model types are legal with Series models 3) Applying the [Diff Pin] keyword does not change the model type already defined on the pin list to anything else 3) Applying the [Diff Pin] keyword does not add models of any type to the models already defined on the pin list 4) There are no restrictions for what model types can be associated as differential pair in the [Diff Pin] section Please let me know whether this argument is acceptable or not. Sincerely, Arpad ============================================================================ ==== Arpad, > 1) Could you please point it out to me where the spec says that it is NOT > allowed to have anything, except terminators on either side of the series > device? I don't recall reading that, but might have missed it. Yes, from ver3_2.a.ibs, see 2nd paragraph under Other Notes, sentence #2 below. | Keyword: [Series Pin Mapping] | Other Notes: If the model_name is for a non-symmetrical series model, | then the order of the pins is important. The [Series Pin | Mapping] and pin_2 entries must be in the columns that | correspond with Pin 1 and Pin 2 of the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any other elements such as additional | capacitance or clamping circuitry are defined by the | model_name that is referenced in the [Pin] keyword. The | model_names under the [Pin] keyword that are also referenced | by the [Series Pin Mapping] keyword must be either 'NC' or | reference a [Model] whose Model_type is 'Terminator'. Thus. | for example, a Series_switch model may contain Terminator | models on EACH of the pins to describe both the capacitance | on each pin and some clamping circuitry that may exist on | each pin. > 2) Our device which has this situation actually does sense the signal > differentially, but since it never drives and the clamps are so far out from > the > signal swing, we didn't include a receiver model (even though I was > considering > to do it). We've never had to model "paths through active devices" so that is where the problem comes in where a single pin is defined as both a recevier (customarily terminating the signal) and defined as a passive series device to another pin. However using only the [Series mapping] only will work A.O.K for us as you state in #3 below assuming another component on the board joins these two nets differentially. > 3) It may be sufficient to define [Series mapping] only if we didn't have a > > receiver in the device. > > Since we just made an IBIS model like that, you got my curiosity up, is it > really illegal to do this? By the way, it passed the parser, so if it is > illegal, should the parser check for that? The part I thought was illegal was the tying of a single pin together with other pins using BOTH [Series Mapping] and [Diff Pin] since the Series pins could only be terminators but the Diff Pins had to be NON-terminators. The parser should check. It sounds like you may wish to propose a BIRD to allow this type of thing in the future in which case we will enhance the capabilities of our software to handle. Its just never come up before. There's always been a buffer between Input and Output allowing us to decoupling the two sides of the analysis. Chris From owner-ibis Fri Oct 9 10:46:03 1998 Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA22464 for ; Fri, 9 Oct 1998 10:46:02 -0700 (PDT) Received: from uucp3.uu.net by relay6.UU.NET with SMTP (peer crosschecked as: uucp3.uu.net [192.48.96.83]) id QQfkjm20299; Fri, 9 Oct 1998 13:41:40 -0400 (EDT) Received: from qdt.UUCP by uucp3.uu.net with UUCP/RMAIL ; Fri, 9 Oct 1998 13:41:41 -0400 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA28994; Fri, 9 Oct 98 10:43:05 PDT Received: from f14 by qdt.com (4.1/SMI-4.1) id AA27954; Fri, 9 Oct 98 10:42:22 PDT Sender: crokusek@qdt.com Message-Id: <361E4AFD.4A7B7C1D@viewlogic.com> Date: Fri, 09 Oct 1998 10:42:21 -0700 From: Chris Rokusek Organization: Viewlogic Systems X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: "Muranyi, Arpad" Cc: "\"ibis@eda.org\"" Subject: Re: True or False? References: <199810091632.QAA02229@calliope1.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad, I wonder if this is what it feels like to be an attourney?... > In my opinion then, it would be perfectly legal (even if it makes no sense) > to have two pins in the pin list defined as "NC" while defining them as > differential pairs in the [Diff Pin] section. "EVEN IT MAKES NO SENSE" -- Abusing the spec in a insensible manner promotes confusion and indicates that the spec should be revised to either: A) eliminate the insensible use - don't use [Diff Pin] to assign a vdiff to a pair of "non-sensing" (excuse the pun) terminators. B) make the use sensible - Allow [Series Mapping] to be applied to a receiver as well as a terminator. I don't think you should release a model that makes no sense even if it's debatably "legal." Chris Muranyi, Arpad wrote: > > Chris, > > Thanks for the clarification. I reread the section you pointed out to me > (several more times) and I believe I am starting to understand the problem. > > It seems to me that the problem is not that I am using the series model > together > with a terminator model, but that these were "coupled" as a differential > pair. > > You made a statement that "the Diff Pins had to be NON-terminators" (I guess > > Input, I/O, etc...). Looking at the [Diff Pin] section of the spec, > however, I > could not find anything that suggests that differential pins had to be a > certain > type of a model. Also, I don't see anything in the [Diff Pin] section that > calls a [Model](s) for the pins it defines as differential. The [Model] > keywords are still referenced only by the pin list section (some times > through > the [Model Selector] keyword) even if we have a [Diff Pin] definition for > them. > In my opinion then, it would be perfectly legal (even if it makes no sense) > to > have two pins in the pin list defined as "NC" while defining them as > differential pairs in the [Diff Pin] section. If this is legal then calling > > Terminator type models in the pin list and defining them as differential > pairs > should also be legal. > > Using this argument I would summarize that the model we made is NOT > violating > the spec. because > > 1) The pin list calls a model that is type Terminator > 2) Terminator model types are legal with Series models > 3) Applying the [Diff Pin] keyword does not change the model type > already defined on the pin list to anything else > 3) Applying the [Diff Pin] keyword does not add models of any type > to the models already defined on the pin list > 4) There are no restrictions for what model types can be associated > as differential pair in the [Diff Pin] section > > Please let me know whether this argument is acceptable or not. > > Sincerely, > > Arpad > From owner-ibis Fri Oct 9 15:24:46 1998 Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA22996 for ; Fri, 9 Oct 1998 15:24:45 -0700 (PDT) Received: from orsmsx27.INTEL.COM (orsmsx27.jf.intel.com [192.168.75.27]) by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA01417; Fri, 9 Oct 1998 15:29:01 -0700 (PDT) Message-Id: <199810092229.PAA01417@hebe.or.intel.com> Received: by ORSMSX27 with Internet Mail Service (5.5.1960.3) id ; Fri, 9 Oct 1998 15:19:52 -0700 From: "Muranyi, Arpad" To: "\"Chris Rokusek\" " Cc: "\"ibis@eda.org\" " Subject: RE: True or False? Date: Fri, 9 Oct 1998 15:17:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="ISO-8859-1" Chris, I don't know what it feels like to be an attorney, because I have never been one. I wonder about the same question... Regarding A) The device has a differential input, so I DO HAVE TO use the [Diff Pin] keyword. The die has a direct connection between the pads which do the loopback, so I must have a way to describe the series properties of those connections. The only model type that is allowed in the IBIS spec with the series models is the "non-sensing" Terminator model type. Do you have a suggestion for how to model this other than the way I did it? I am willing to make changes if it makes sense... Regarding B) I have to make a model now, since the customer wants to use it immediately. Even though I would prefer this, I can't wait for a new IBIS spec version. I don't see why my model is "debatebly" legal because nothing I did in it is illegal according to the spec. The model makes sense if you think about what it describes and not about what the comments in the spec say regarding what the Terminator models could be used for. So we have a choice of fixing the spec, make legal (but "senseless"? models), or not have any models. Which one would you choose when the customer wants to simulate and is pounding on the door for models? Remember, this is an existing device and we should both be interested in finding a way to model it. Arpad ============================================================================ ==== Arpad, I wonder if this is what it feels like to be an attourney?... > In my opinion then, it would be perfectly legal (even if it makes no sense) > to have two pins in the pin list defined as "NC" while defining them as > differential pairs in the [Diff Pin] section. "EVEN IT MAKES NO SENSE" -- Abusing the spec in a insensible manner promotes confusion and indicates that the spec should be revised to either: A) eliminate the insensible use - don't use [Diff Pin] to assign a vdiff to a pair of "non-sensing" (excuse the pun) terminators. B) make the use sensible - Allow [Series Mapping] to be applied to a receiver as well as a terminator. I don't think you should release a model that makes no sense even if it's debatably "legal." Chris Muranyi, Arpad wrote: > > Chris, > > Thanks for the clarification. I reread the section you pointed out to me > (several more times) and I believe I am starting to understand the problem. > > It seems to me that the problem is not that I am using the series model > together > with a terminator model, but that these were "coupled" as a differential > pair. > > You made a statement that "the Diff Pins had to be NON-terminators" (I guess > > Input, I/O, etc...). Looking at the [Diff Pin] section of the spec, > however, I > could not find anything that suggests that differential pins had to be a > certain > type of a model. Also, I don't see anything in the [Diff Pin] section that > calls a [Model](s) for the pins it defines as differential. The [Model] > keywords are still referenced only by the pin list section (some times > through > the [Model Selector] keyword) even if we have a [Diff Pin] definition for > them. > In my opinion then, it would be perfectly legal (even if it makes no sense) > to > have two pins in the pin list defined as "NC" while defining them as > differential pairs in the [Diff Pin] section. If this is legal then calling > > Terminator type models in the pin list and defining them as differential > pairs > should also be legal. > > Using this argument I would summarize that the model we made is NOT > violating > the spec. because > > 1) The pin list calls a model that is type Terminator > 2) Terminator model types are legal with Series models > 3) Applying the [Diff Pin] keyword does not change the model type > already defined on the pin list to anything else > 3) Applying the [Diff Pin] keyword does not add models of any type > to the models already defined on the pin list > 4) There are no restrictions for what model types can be associated > as differential pair in the [Diff Pin] section > > Please let me know whether this argument is acceptable or not. > > Sincerely, > > Arpad > From owner-ibis Fri Oct 9 18:33:42 1998 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA23204 for ; Fri, 9 Oct 1998 18:33:41 -0700 (PDT) Received: from uucp2.uu.net by relay3.UU.NET with SMTP (peer crosschecked as: uucp2.uu.net [192.48.96.82]) id QQfkkr03515; Fri, 9 Oct 1998 21:29:22 -0400 (EDT) Received: from qdt.UUCP by uucp2.uu.net with UUCP/RMAIL ; Fri, 9 Oct 1998 21:29:22 -0400 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA01772; Fri, 9 Oct 98 18:33:05 PDT Received: from f14 by qdt.com (4.1/SMI-4.1) id AA08045; Fri, 9 Oct 98 18:29:14 PDT Sender: crokusek@qdt.com Message-Id: <361EB868.446B9B3D@viewlogic.com> Date: Fri, 09 Oct 1998 18:29:12 -0700 From: Chris Rokusek Organization: Viewlogic Systems X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: "Muranyi, Arpad" Cc: "\"ibis@eda.org\"" Subject: Re: True or False? References: <199810092229.PAA01417@hebe.or.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arpad, Since you must have the [Series Map] to connect IN to OUT and therefore must have terminators on those pins to stay "legal" for the time being, I urge for you to leave out the [Diff Pin] relationship and rely on another device within the board to associate the nets since you can't legally put an actual sensing receiver at the series pin locations anyway. As a temporary solution, this method would result in the proper connectivity for our customers...any other vendors care to comment? If you want to leave it in that is your choice as I must surrender that your model may actually be legal--perhaps due to an oversight in the [Diff Pin] specification (noticed I used the word "may"!!). We will instruct our customers to delete the [Diff Pin] lines until we are able to support it with a patch (yuck!). Viewlogic will endorse a proposed BIRD allowing other types of models on the series pin nodes. Chris P.S. I will be out of the office all next week so am defenseless to your reply :) !! Muranyi, Arpad wrote: > > Chris, > > I don't know what it feels like to be an attorney, because I have never been > > one. I wonder about the same question... > > Regarding A) The device has a differential input, so I DO HAVE TO use the > [Diff Pin] keyword. The die has a direct connection between > the > pads which do the loopback, so I must have a way to describe > the > series properties of those connections. The only model type > that > is allowed in the IBIS spec with the series models is the > "non-sensing" Terminator model type. Do you have a suggestion > for > how to model this other than the way I did it? I am willing to > make changes if it makes sense... > > Regarding B) I have to make a model now, since the customer wants to use it > immediately. Even though I would prefer this, I can't wait for > a > new IBIS spec version. > > I don't see why my model is "debatebly" legal because nothing I did in it is > > illegal according to the spec. The model makes sense if you think about > what it > describes and not about what the comments in the spec say regarding what the > > Terminator models could be used for. > > So we have a choice of fixing the spec, make legal (but "senseless"? > models), or > not have any models. Which one would you choose when the customer wants to > simulate and is pounding on the door for models? > > Remember, this is an existing device and we should both be interested in > finding > a way to model it. > > Arpad > ============================================================================ From owner-ibis Fri Oct 9 19:28:45 1998 Received: from mail2.teleport.com (mail2.teleport.com [192.108.254.43]) by server.eda.org (8.8.5/8.8.3) with SMTP id TAA23266 for ; Fri, 9 Oct 1998 19:28:44 -0700 (PDT) Received: (qmail 22957 invoked from network); 10 Oct 1998 02:24:25 -0000 Received: from pdx75-i48-26.teleport.com (HELO teleport.com) (204.202.174.40) by mail2.teleport.com with SMTP; 10 Oct 1998 02:24:25 -0000 Message-ID: <361EC554.E36A1F4A@teleport.com> Date: Fri, 09 Oct 1998 19:24:21 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.5b2 [en]C-DIAL (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Rokusek CC: "Muranyi, Arpad" , "ibis@eda.org" Subject: Re: True or False? References: <199810092229.PAA01417@hebe.or.intel.com> <361EB868.446B9B3D@viewlogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I believe the more appropriate solution is to model the device using an ebd model. In this way a differential receiver can be place on the pass-thru between the input and output pins of the device. Ebd models work quite well for complex package situations, such as this one. Regards, Scott Chris Rokusek wrote: > Arpad, > > Since you must have the [Series Map] to connect IN to OUT and therefore > must have terminators on those pins to stay "legal" for the time being, > I urge for you to leave out the [Diff Pin] relationship and rely on > another device within the board to associate the nets since you can't > legally put an actual sensing receiver at the series pin locations > anyway. > > As a temporary solution, this method would result in the proper > connectivity for our customers...any other vendors care to comment? > > If you want to leave it in that is your choice as I must surrender that > your model may actually be legal--perhaps due to an oversight in the > [Diff Pin] specification (noticed I used the word "may"!!). We will > instruct our customers to delete the [Diff Pin] lines until we are able > to support it with a patch (yuck!). > > Viewlogic will endorse a proposed BIRD allowing other types of models on > the series pin nodes. > > Chris > > P.S. I will be out of the office all next week so am defenseless to > your reply :) !! > > Muranyi, Arpad wrote: > > > > Chris, > > > > I don't know what it feels like to be an attorney, because I have never been > > > > one. I wonder about the same question... > > > > Regarding A) The device has a differential input, so I DO HAVE TO use the > > [Diff Pin] keyword. The die has a direct connection between > > the > > pads which do the loopback, so I must have a way to describe > > the > > series properties of those connections. The only model type > > that > > is allowed in the IBIS spec with the series models is the > > "non-sensing" Terminator model type. Do you have a suggestion > > for > > how to model this other than the way I did it? I am willing to > > make changes if it makes sense... > > > > Regarding B) I have to make a model now, since the customer wants to use it > > immediately. Even though I would prefer this, I can't wait for > > a > > new IBIS spec version. > > > > I don't see why my model is "debatebly" legal because nothing I did in it is > > > > illegal according to the spec. The model makes sense if you think about > > what it > > describes and not about what the comments in the spec say regarding what the > > > > Terminator models could be used for. > > > > So we have a choice of fixing the spec, make legal (but "senseless"? > > models), or > > not have any models. Which one would you choose when the customer wants to > > simulate and is pounding on the door for models? > > > > Remember, this is an existing device and we should both be interested in > > finding > > a way to model it. > > > > Arpad > > ============================================================================ -- ___________________________ Scott McMorrow Principal Engineer SiQual mailto:scottmc@siqual.com ___________________________ From owner-ibis Mon Oct 12 11:08:57 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA27767 for ; Mon, 12 Oct 1998 11:08:56 -0700 (PDT) Received: from Kellee98 ([192.168.148.110]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id LAA32447; Mon, 12 Oct 1998 11:01:17 -0700 Message-Id: <199810121801.LAA32447@mail.hyperlynx.com> X-Sender: kellee@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 12 Oct 1998 11:01:26 -0700 To: "Muranyi, Arpad" , "\"Chris Rokusek\" " From: Kellee Crisafulli Subject: RE: True or False? Cc: "\"ibis@eda.org\" " In-Reply-To: <199810092229.PAA01417@hebe.or.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id LAA27768 Hi Arpad, Chris, IBIS I have 2 points which seem important in the context of your question: 1) Why not use .ebd it seems perfect for what you are doing. 2) I thought terminators are stand alone key words. That is not used in the context of an IC model but rather used to create and define a terminating component. --------------------------------------------------------- Have a great day.... Kellee Crisafulli at HyperLynx SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Fri Oct 16 14:36:12 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA13962 for ; Fri, 16 Oct 1998 14:36:12 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id OAA20712; Fri, 16 Oct 1998 14:31:20 -0700 (PDT) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA23824; Fri, 16 Oct 1998 14:31:18 -0700 (PDT) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA04763; Fri, 16 Oct 98 14:31:17 PDT Date: Fri, 16 Oct 98 14:31:17 PDT Message-Id: <9810162131.AA04763@bob> To: ibis@eda.org Subject: IBIS/JEDEC SUMMIT MEETING ANNOUNCEMENT Cc: bob_ross@mentorg.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS/JEDEC SUMMIT CALL FOR PARTICIPATION, PRESENTATIONS ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:30 AM - 5:00 PM, Wednesday, December 9, 1998 Location: Kona Kai Continental Hotel 1551 Shelter Island Drive San Diego, CA 92106-3102 Tel: 619-221-8000 Fax: 619-221-5953 Content: Interchange of ideas with JEDEC JC16.2 Subcommittee on Modeling and Test Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: EIA J E D E C M E E T I N G S Time/Date: 8:00 AM - 5 PM, Tuesday, December 8, 1998 Content: IBIS Participants are invited to the JEDEC JC16.2 meeting also to view and discuss issues of mutual concern. You must signup for these meetings to be formally invited. Schedule of Meetings: JC16.2 - Modeling and Test: Tuesday Morning, December 8, 1998 JC42 - Memories: Tuesday Afternoon, December 8, 1998 Deadline: JEDEC Meeting Registration Deadline is November 11, 1998 Contact for Signup to JEDEC Meeting: D.C. Sessions dc.sessions@tempe.vlsi.com URL for JC42 Schedule: http://www.jedec.org BACKGROUND The JEDEC committee is involved in standardization activities from the physical device point of view. D.C. Sessions of VLSI Technology has been active in both JEDEC JC16.2 and the EIA IBIS Open Forum. The joint/co- located meeting offers several opportunities: EDA people can understand some real device modeling and testing concerns and the semiconductor people can understand the applicability of IBIS models and corresponding simulation tools. The IBIS format is being considered as the template for a JEDEC data sheet proposal. The proposal is to provide the envelope tables and data for the I/O characteristics and pin capacitance for SSTL2 related specifications. Interaction with IBIS experts will be very helpful. The IBIS meeting will be conducted as a formal IBIS Summit meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to: Bob Ross (bob_ross@mentorg.com) CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or 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. Plan to bring about 50 copies for distribution at the meeting. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Bob Ross (bob_ross@mentorg.com) AGENDA The agenda includes presentations, discussions, breaks, and a luncheon (which will be provided). In addition, we will have an opportunity for Ad Hoc presentations. From owner-ibis Wed Oct 21 09:31:15 1998 Received: from mail.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA25707 for ; Wed, 21 Oct 1998 09:31:10 -0700 (PDT) Received: from tensor ([192.168.148.75]) by mail.hyperlynx.com (8.8.5/8.8.5) with SMTP id JAA16864 for ; Wed, 21 Oct 1998 09:26:47 -0700 Message-Id: <3.0.5.32.19981021092746.00946cf0@mail.nwlink.com> X-Sender: mbflora@mail.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Oct 1998 09:27:46 +0000 To: ibis@eda.org From: Matthew Flora Subject: IBIS Open Forum Minutes 15 Oct 1998 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DATE: 10/21/98 SUBJECT: 10/15/98 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 1998 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Norio Matsui, Raj Raghuram* Cadence Design (& UniCAD) C. Kumar*, Don Telian, Patrick Riffault, Craig Lewis, Greg Fitzgerald, Paul Galloway, Patrick Dos Santos, Catherine Weiss, Alain Tribaudot, Geoffrey Ellis, Todd Westerhoff*, Ken Willis* Compaq Shariq Rahma, Jeff Chu, Bob Haller*, (Digital Equipment Corp.) Doug Burns*, Steve Coe* Cypress Bruce Wenniger H.A.S. Electronics Haruny Said Hewlett Packard (EEsof, etc.) Karl Kachigan, Henry Wu, Paul Gregory, Brenda Arena* High Design Technology Razvan Ene HyperLynx Kellee Crisafulli, Matthew Flora, Gene Garat*, Dave Kohlmeier* Incases Olaf Rethmeier, Scott Jacobson, Werner Rissiek Intel Corporation Stephen Peters*, Arpad Muranyi, Frank Kern*, (& formerly NCR) Will Hobbs*, Prakash Radhakrishnan, Mohammed Hawana, Martin Chang, Dave Moxley, Tim Schreyer* LSI Logic (Symbios Logic) Larry Barnes Mentor Graphics (Zeelan, Bob Ross*, George Opsahl, Mark Noneman, Interconnectix, etc.) Tom Dagostino, Karine Loudet, Jean Oudinot, Manuel De Almeida, Stephane Rousseau, Neven Orhanovic, Mohamed Mahmoud, Kevin Cohan* Mitsubishi Tam Cao Motorola (Ron Werner) National Semiconductor Cheng-Yang Kao, John Goldie, Ikchang Song, Milt Schwartz North East Systems Associates Edward Sayre*, Kathy Breda*, Michael Baxter* (NESA) Jon Green*, Jinhua Chen* NEC (Hiroshi Matsumoto) Quantic EMC (Mike Ventham) Texas Instruments Thomas Fisher, Harvey Stiegler, Vincent Chang, Jean-Claude Perrin, Peter Forstner Thomson-CSF Jean-Marc Claveau, Laurent Duzaic, Saverio Lerose, Benoit Meyniel, Jean Lefebvre Viewlogic Jon Powell*, Chris Rokusek, Guy de Burgh, Gary Mandel VeriBest Ian Dodd, David Weins, Ian Gabbitas VLSI Technology D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1998: 3Com Steve Miller* 3Dfx Interactive Ken Wu* A.T.Sinker Tony Sinker* Actel Eric Tardif, Emmonvelle Gaudin Aerospatiale Lionel Dreux, Claude Huet Alcatel (Bell, Espace, etc.) John Fitzpatrick, W. Temmerman, Laure Bessettes, Jean-Claude Pourtau, Daniel Peron ALS Design Yves Mouquet Ansoft Eric Bogatin Apple Fred Floresca, Danny Itani Apteq Design Systems Dan FitzPatrick Atmel Ali Baktashian Avanti Nik Bannov CERN Olivier Clere, Jean-Michel Sainson, Rudi Zurbroken Cisco Systems Syed Huq, Sergio Camerlo, Irfan Elahi Corning John Nieznanski* Crucial Technology Rathna Reddy DIVA Corp Tieng Nguyen* Dynamic Research Corporation Mike Walsh* EIA Patti Rusher* EMC Fawn Engelmann, Fabrizio Zanella* ENST, Paris Jean-Jacques Charlot European CAD Standardization Adam Morawiec Intitiative (ECSI) Fairchild Semiconductor Peter LaFlamme* Focus Technology John Salzillo*, Gary Brophy*, Mike Arieta*, Jim Skane* IBM Richard Steinle, Kevin Jackson, Greg Edlund* InRange Elliot Lipin* Intracon Design Ltd. Derek Laidlaw Philips Semiconductor Todd Andersen Rockwell Semiconductor Tim Gilbert* Scottish Electronics Robert Easson Manufacturing Center (SEMC) Seagate Vanessa Howard Signal Integrity Software Barry Katz* SGS-Thomson Philippe Lefevre Siemens Gerald Bannert, Bernhard Unger, Christian Marot, Miguel Hernandez, Gil Russell SSEI Tom Hawkins Stratus Bruce Heilbrunn*, Steve Mango*, Lewis Steiner*, Karla Eignor*, Rich Newell* Summit Computer Systems Bob Davis Sun Microsystems Lam Dong, Kevin Ko, Tay Ansari*, Ken Weiss* Symmetry Andy Hughes Tektronix Nassrin Ghahyasi Teradyne Michael Khusid* TranSwitch Bill Todd* TRILOGIC Joe Socha* Ultratest International Chris O'Connor Xilinx Susan Wu 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 November 6, 1998 (916) 356-9200 2-275145 3938931 Wednesday, December 7, 1998 IBIS Summit Meeting - No Teleconference 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 ----------------------------------- IBIS SUMMIT MEETING SUPPORT The IBIS Summit Meeting was held at the Boxboro Woods Holiday Inn in Boxboro, Massachusetts. Thanks to Kathy Breda and the staff of North East Systems Associates (NESA) for taking care of the arrangements and to the IBIS Users group and the sponsors of the meeting for providing additional support and funding. The sponsors are listed: Applied Simulation Technology Cadence Design Systems Compaq Computer Systems EMC Corporation Focus Technology HyperLynx North East Systems Associates Thanks to the following groups for showing equipment and demonstrations supporting IBIS model processing: Applied Simulation Technology - Raj Raghuram Cadence Design Systems - Todd Westerhoff HyperLynx - Dave Kohlmeier and Gene Garat Interconnectix/Mentor Graphics - Kevin Cohan Viewlogic - Jon Powell IBIS Users Group (with equipment from Hewlett Packard) About 50 people representing 29 organizations participated in a meeting packed with content. The food, refreshments, and the facilities were excellent. The Minutes here just briefly note some of the content of the meeting and some discussion. Most of the presentations and related documents will be uploaded at: http://www.eda.org/pub/ibis/summits/oct98. INTRODUCTIONS AND BUSINESS - Bob Ross (Mentor Graphics) and Ed Sayre (NESA) Bob Ross opened the meeting and introduced the officers, sponsors, and people doing demonstrations. The participants introduced themselves. Bob noted that there was good representation from the semiconductor, EDA vendor and user sectors. Ed Sayre noted that a strong IBIS Users Group has put in a lot of effort to propose a method of quantifying the quality of IBIS models. Ed showed a three-way linkage between IBIS models of chips, transmission lines, connectors, etc; IBIS software, syntax checker, IBIS to SPICE, SPICE to IBIS, training; and simulators and circuit prediction software. He stated that IBIS Users and their missions are central to IBIS. Bob Ross reviewed some ongoing IBIS Open Forum activities. The first IBIS Version 3.2 parser was distributed to the 12 funding companies. Several BIRDs exist for ratifying IBIS Version 3.2. Bob noted that the ratification of IEC 62014-1 has been delayed since the IBIS Version 2.1 document had not been forwarded to the IEC Central Office for distribution. Patti Rusher properly forwarded the document, and it will be sent out for Committee Draft for Vote (CDV) on a fast track basis which should take about a year. Bob along with Will Hobbs (past Chair of the EIA IBIS Open Forum) and Stephen Peters (Vice-Chair.), both from Intel, and some model and simulator development people from Mentor Graphics had recently met with Dr. Hideki Fukuda, Chair of the EIAJ committee on I/O Model for Integrated Circuits (IMIC). Ed Sayre and the staff at NESA had also met with Dr. Fukuda. The agenda was to get more information and to investigate whether IBIS and IMIC can and should be merged or linked in some manner. Bob noted that the next IBIS Summit meeting is being held in San Diego, CA, and is co-located with the JEDEC JC-16.2 (Modeling and Test) committee meeting. The meeting, originally proposed by D.C. Sessions is scheduled for December 9, 1998. This should provide more communication and interaction between IBIS members and people involved with semiconductor development. Information will be sent out shortly. [Added note - this meeting is now being changed to December 7, 1998.] A formal business item was to consider a proposal for IBIS Open Forum Associate Sponsorship of DesignCon99. The benefits include a meeting room and refreshments for the IBIS Summit Meeting on February 1, 1999, a 10x10 booth at DesignCon99, a suite, publicity, VIP registration with 10% discount, and other perks. DesignCon99 would be able to use the IBIS reflector lists for advertising DesignCon99. Patti checked that this was acceptable with EIA. The group approved accepting the Associate Sponsorship proposal. [Administrative note - H.A.S. Electronics is now an official EIA IBIS Open Forum Member.] IBIS TRAINING - Joseph Socha (TRILOGIC) Joe Socha gave a quick run through of an IBIS training tutorial he is developing. Joe took some material from a number of publicly available documents and integrated them into a training program which could be merged with vendor-specific programs. The content included reviewing the keywords for I/V data and ramp information within Version 1.1. He would like feedback on the content and material. Joe's plan is to enlarge the presentation into a 4 hour class and is considering offering it at DesignCon99. IBIS CONNECTOR MODELS: WORKING GROUP STATUS - Fabrizio Zanella (EMC Corporation) Fabrizio Zanella gave an interim status. The Connector Working Group has had participation from 9 individuals from 7 companies and meets several times a month. The goal is to draft an IBIS Connector BIRD to define single line and multiline connector models. About 25 new keywords are defined that support connectors derived from 2D and 3D field solver extractions. Both mated and unmated configurations will be supported. Connectors can support several cascaded L,C matrix sections. A smaller section (designated a swath) can be used which is repeated for the entire connector. One option includes providing a JPEG file to show the connector. The Group plans to investigate T stubs and loops and issue the BIRD by January 1999. The Group also is seeking funding for parser development. BEHAVIORAL/IBIS MODELING OF A FET BUS SWITCH USING CADENCE TOOLS - Tay Ansari (Sun Microsystems) Tay Ansari discussed a series of experiments to model FET bus switches. After discussing some FET theory, Tay presented several modeling approaches for FET switches: Series (5 ohm) resistor, Voltage Controlled Resistor, I-V Tables/Conditional Statements, and IBIS 3.0 format. He also showed the model for parasitic elements. Using a criteria that he expects behavioral simulations to overlay with SPICE simulation results, Tay then inserted the FET switch models in a multiboard test circuit and showed the results. All cases showed general agreement, but the table/conditional approach seemed to give the closest correlation. He did not test the IBIS Version 3.0 approach directly, but considered it a format variation of the table approach. He recommends using two-dimension tables for best accuracy relative to SPICE simulation. IBIS ACCURACY SPECIFICATION - Robert Haller (Compaq Computer Corporation) In the presentation, Bob Haller reviewed the contents of the draft document and its rationale. The draft IBIS Accuracy Specification document was also provided. To limit the scope of the project, the document focused on IBIS Version 1.1 keywords and subparameters and corresponding test setups for extractions. The goal is to provide quantitative metrics which correlate hardware measurements to IBIS simulations. This can be used as a quality standard for IBIS datasheets. A Subcommittee of six people worked on the proposal since December, 1997 and also worked on the test configurations for checking IV data, test load waveforms and capacitance. The correlation metrics include timing and voltage deltas, documentation of monotonic behavior, curve overlay and curve envelope correlations, and capacitance differences. Four correlation levels take into account these cases: Random Sample with no SPICE model available, Random Sample with SPICE model available, Known typical sample with SPICE model available, and Known corner samples with no SPICE model required. The goal is to produce a finished Specification by DesignCon99. IBIS TEST BOARD - Peter LaFlamme (Fairchild Semiconductor) Peter LaFlamme followed the presentation by discussing the test board itself. It was designed for measuring DC IV tables, extracting AC waveforms for various test loads and measuring capacitance. It could be used for creating IBIS models from sample silicon. The schematics and layout are now available, and the plan is to demonstrate to board at DesignCon99. The test board accommodates a 16244 function in a 48 lead TSSOP package. It houses two devices, one to set up I/V data collection and input/output capacitance, and the other to do AC measurements. Also, there are test strips for transmission line characteristics and board traces and load characteristics of board vias. Examples of DC and AC tests were illustrated. The AC waveforms include the transmission line terminated to Z0, standard lumped timing test load, a lightly loaded transmission line, and a driver driving a receiver of the same family. Several methods to measure capacitance are supported including frequency domain (LRC meter and capacitance bridge) and time domain (TDR and pulse technique) methods. Not measured are package resistance (usually negligible, and package inductance). More work is needed to characterize the board. However, the complete package includes schematics, Gerber files, and a parts list. IBIS CASE STUDIES: COMPARISONS OF SIMULATIONS - Fabrizio Zanella (EMC Corporation) Fabrizio Zanella presented the results of case studies comparing IBIS model simulation, SPICE simulation and measurements. Three cases were presented: Case 1: TTL signal, empirical, SPICE, IBIS simulation; Case 2: SRAM signals: empirical, SPICE, IBIS; and Case 3: IBIS model comparison. While there were differences due to a number of factors, Case 1 showed excellent agreement on the 1.5 V ringback signal. Case 2 showed similar undershoot between IBIS simulations and measurements. However, there were some unaccounted differences in waveforms. Case 3 showed differences in simulation waveforms between data sheet and SPICE 2 IBIS extracted models. In general, Fabrizio concludes the SI simulators using IBIS models are reasonably accurate, but beware of data sheet models. COMPARISONS BETWEEN SPICE AND IBIS I/O DEVICE SIMULATIONS - Jinhua Chen (North East Systems Associates) Jinhua Chen compared results of SPICE and IBIS model simulations using the Fairchild 74LCX16245 SPICE and extracted IBIS models. Three Cases were studied: Case 1: 50 ohm net with no termination, Case 2: Same net with a 25 ohm series resistance to dampen the overshoot, and Case 3: A 15 pF capacitive load only. In Case 1 at two clock frequencies, there was good correlation between waveforms, but the IBIS simulation ringing was about 20 percent larger. Excellent correlation was obtained in Case 2. Case 3 showed larger overshoot and undershoot using the IBIS models. However, overall correlation was good with SPICE models. TIPS AND TRICKS FOR CREATING IBIS MODELS - Jon Powell (Viewlogic Consulting Services) Jon Powell provided many tips based on much experience developing IBIS models. An important setup is to extract VT tables using 50 ohms to ground and 50 ohms to Vcc. Parasitics need to be eliminated. The time domain extractions need to be set up for maximum accuracy by controlling the Options settings in SPICE and by doing the simulations for a long enough duration to capture the whole waveform. Jon showed excellent, overlaying correlation between Spice extractions and model simulations. He pointed out a number of extraction problems related to simulation time, Cdie, control options to converge, unrealistic SPICE diode models, and the fact that some SPICE features are not modeled. Some difficulties with IBIS include: 100 point limitation, the typ-min-max corners may not give the full range of corners, the LC package model may be too simplistic, and rise time and high speed buffers need more than just the transition time specification. However, using QA simulations with the complete model, Jon again showed overlaying correlation. He also showed a significant difference in results when he just used the [Ramp] specification. MODEL PROCESSING ALGORITHMS - Bob Ross (Interconnectix/Mentor Graphics Corporation) Bob Ross discussed some details in a prototype SPICE implementation of IBIS done several years ago and sent on the IBIS reflector in October, 1997. The algorithm involved the transition between the high and low state tables by using multiplying Ku(t) and Kd(t) tables. Some code details were shown for one and two waveform based methodologies. The K table extractions were based on a feedback method which forced convergence to the correct solution using the SPICE convergence algorithms. Bob presented results which showed excellent overlaying correlation between the original Spice waveforms and IBIS model simulations and superimposed with the corresponding Ku(t) and Kd(t) tables. However, a one waveform based model for K(t) extraction showed some simulation difference between the second waveform and the corresponding simulation. Bob also presented some aspects of the EIAJ IMIC 1, 2, and 3 dimensional table model. The model does allow two independent waveforms that can be extracted from within the Spice model for controlling the PMOS and NMOS devices of an output stage. However, the accuracy of this approach needs to be validated since the table transistor models themselves are given in terms of derived tables. IBIS EVOLUTION AND ADOPTION - Will Hobbs (Intel Corporation) Will Hobbs gave a brief IBIS history and then issued the challenge for models and simulators to keep up with technology. New challenges cause the subtler effects (and their combinations) to become significant. Accuracy work is needed, and IBIS Version 3.X functionality needs to be adopted. Future developments need to be deployed more quickly. Will shared a real case study experience where the combined effects of SSO, coincident reflections with SSO, and noise margin erosion caused by termination plane noise, routing topology, package routing, Vcc bypassing, connector inductance, and sub-optimal ground return path all contributed to a deep glitch. Normally these are considered second order effects. Will described a recent modeling approach where the timing is taken from the input of the driver to the output of the receiver for cleaner test points. Such advances raise the question about how far the IBIS methodology can go and what to do about addressing the emerging needs. He speculated on some alternatives including a more sophisticated input model, improved package models, equation based models, and feedback. He also speculated on a coexistence between structural and behavioral modeling (through an interface which protects intellectual property). TOOL CAPABILITIES NEEDED FOR DESIGNING 100 MHZ INTERCONNECTS - Tim Schreyer (Intel Corporation) Tim Schreyer summarized a presentation he gave at ASP DAC 98 in February 1998 in Tokyo, Japan. He described the interconnect design challenges for the Pentium(R) II processor based PCs. The trends are moving to higher speeds away from the CPU (e.g., AGP bus), and changing buses from "common clock" to "source-synchronous" configurations. The common clock goal is to minimize interconnect delay, whereas the source synchronous goal is to match interconnect delays and minimize uncertainty. This requires more attention to second order effects. Worse case design is harder to achieve. Conventional iterative or single pass approaches may not converge or take into account the resulting second order effects. Tim proposes doing extensive Monte Carlo simulations to understand the real effects and their interactions so that realistic design rules can be developed. One example considering variations in length, capacitance, pulsewidth, rise and fall times, and odd/even mode interactions showed a worse case design variation of 1.55ns when the effects were added independently versus a computed worse case variation of 0.647ns when the effects were treated together. Such simulations create a lot of data. Tim showed some graphical displays using Microsoft Excel graphics and drop down macros to process the data. Various two and three dimensional plots and distributions quickly allow the user to see the worse case conditions among the interacting parameters. Tim concluded by noting that thousands of simulations are needed for speeds above 100 MHz. Tools must be designed for batch mode processing and post processing visualization. Tim emphasized that the primary role is to achieve understanding rather than automation. ADJOURNMENT Bob Ross thanked the organizers for their efforts, and the meeting was adjourned for social interaction. NEXT MEETING: The next teleconference meeting will be on Friday, November 6, 1998 from 8:00 AM to 10:00 AM. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentorg.com Modeling Engineer, Interconnectix BU of Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 SECRETARY: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 17641 NE 67th Court Redmond, WA 98052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 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 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.eia.org 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 Oct 21 17:06:41 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA26902; Wed, 21 Oct 1998 17:06:40 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id RAA16424; Wed, 21 Oct 1998 17:01:46 -0700 (PDT) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA11374; Wed, 21 Oct 1998 17:01:44 -0700 (PDT) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA04920; Wed, 21 Oct 98 17:01:44 PDT Date: Wed, 21 Oct 98 17:01:44 PDT Message-Id: <9810220001.AA04920@bob> To: ibis-users@eda.org, ibis@eda.org Subject: IBIS SUMMIT PRESENTATIONS 10/15/98 To All: All of the presentations and related documents for the October 15, 1998 IBIS Summit meeting have been uploaded on http://www.eda.org/pub/ibis/summits/oct98. See 00readme.txt for a listing of the contents. Thanks to all of you who provided very quickly the electronic presentations. Also, a corrupted ibischk3 executable has been replaced on http://www.eda.org/pub/ibis/ibischk3/sun_5. Bob Ross Mentor Graphics From owner-ibis Wed Oct 21 17:29:18 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA26946; Wed, 21 Oct 1998 17:29:17 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id RAA18020; Wed, 21 Oct 1998 17:24:15 -0700 (PDT) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA13602; Wed, 21 Oct 1998 17:24:13 -0700 (PDT) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA04961; Wed, 21 Oct 98 17:24:13 PDT Date: Wed, 21 Oct 98 17:24:13 PDT Message-Id: <9810220024.AA04961@bob> To: geoff@cadence.com, ibis-users@eda.org, ibis@eda.org Subject: Re: Should [Model Data] be required? Geoffrey: Your desired interpretation is correct. Pending BIRD54 is issued to correct a mistake in the document, and a related BUG32 is issued to correct a corresponding mistake in the ibischk3 parser in this area. The intention of the authors was NOT to require the [Model Data] and corresponding matrix formulations when using the transmission line format for package models. This should be resolved at the next meeting. Bob Ross Mentor Graphics > Date: Wed, 21 Oct 1998 14:31:51 -0700 (PDT) > From: Geoffrey Ellis > Message-Id: <199810212131.OAA05058@milliways.Cadence.COM> > To: ibis-users@eda.org > Subject: Should [Model Data] be required? > When the [Package Model] was introduced, in Bird 10.2, it probably made sense > to require [Model Data]. Without [Model Data], there would have been little > value in using a package model. > However, now (BIRDS 28.3 and 37.3, included in IBIS 3.0 and beyond) a package > model may have transmission line models for pins using sub-parameters Len, > L, R, C, Fork, and Endfork. This provides another reason to use a package > model. Yet the IBIS specification still requires [Model Data], which requires > at least a [Capacitance Matrix] and an [Inductance Matrix], even if no > coupling data is provided. > Question: does it still make sense to require [Model Data] in a package model? > *********************************************************************** > * Geoffrey Ellis * > * Cadence Design Systems phone: 831-685-6559 * > * 9057 Soquel Drive fax: 831-685-6556 * > * Aptos, CA 95003 E-mail: geoff@cadence.com * > *********************************************************************** From owner-ibis Thu Oct 22 09:16:32 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA29246 for ; Thu, 22 Oct 1998 09:16:31 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id JAA03158; Thu, 22 Oct 1998 09:11:35 -0700 (PDT) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id JAA17502; Thu, 22 Oct 1998 09:11:34 -0700 (PDT) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA05608; Thu, 22 Oct 98 09:11:34 PDT Date: Thu, 22 Oct 98 09:11:34 PDT Message-Id: <9810221611.AA05608@bob> To: ibis@eda.org Subject: REVISED IBIS/JEDEC SUMMIT MEETING 12/7/98 Cc: dc.sessions@tempe.vlsi.com, juliec@gw.eia.org, pattir@eia.org To All: We have changed the date and time of the IBIS Summit Meeting in December 1998 to better accomodate the JEDEC meeting activities and promote better interaction between the groups. We are also inviting JEDEC members to present and discuss some new technologies at the meeting. Some signup details have been revised. The IBIS Meeting will start with a FREE Buffet Lunch to those who signup. Bob Ross Mentor Graphics. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- *************** REVISED DATE AND TIME ***************** ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS/JEDEC SUMMIT CALL FOR PARTICIPATION, PRESENTATIONS ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 12:00 PM - 5:00 PM, Wednesday, December 7, 1998 Location: Kona Kai Continental Hotel 1551 Shelter Island Drive San Diego, CA 92106-3102 Tel: 619-221-8000 Fax: 619-221-5953 Content: Interchange of ideas with JEDEC JC16.2 Subcommittee on Modeling and Test Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: EIA Contact for Signup for IBIS Meeting and FREE Buffet Lunch: Patti Rusher pattir@eia.org J E D E C M E E T I N G S Time/Date: 8:00 AM - 5 PM, Tuesday, December 8, 1998 Content: IBIS Participants are invited to the JEDEC JC16.2 meeting also to view and discuss issues of mutual concern. You must signup for these meetings to be formally invited. Schedule of Meetings: JC16.2 - Modeling and Test: Tuesday Morning, December 8, 1998 JC42 - Memories: Tuesday Afternoon, December 8, 1998 Deadline: JEDEC Meeting Registration Deadline is November 11, 1998 Contact for Signup to JEDEC Meeting: Patti Rusher pattir@eia.org URL for JC42 Schedule: http://www.jedec.org BACKGROUND The JEDEC committee is involved in standardization activities from the physical device point of view. D.C. Sessions of VLSI Technology has been active in both JEDEC JC16.2 and the EIA IBIS Open Forum. The joint/co- located meeting offers several opportunities: EDA people can understand some real device modeling and testing concerns and the semiconductor people can understand the applicability of IBIS models and corresponding simulation tools. The IBIS format is being considered as the template for a JEDEC data sheet proposal. The proposal is to provide the envelope tables and data for the I/O characteristics and pin capacitance for SSTL2 related specifications. Interaction with IBIS experts will be very helpful. The IBIS meeting will be conducted as a formal IBIS Summit meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. JEDEC MEMBERS ARE INVITED TO PROVIDE PRESENTATIONS ON CURRENT TECHNOLOGIES SUCH AS SSTL AND HSTL, ETC., AND ASSOCIATED MODELING/SIMULATION ISSUES TO THE IBIS SUMMIT MEETING TO PROMOTE INTERACTION AMONG TECHNICAL EXPERTS. CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or 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. Plan to bring about 30 copies for distribution at the meeting. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Bob Ross bob_ross@mentorg.com AGENDA The agenda includes presentations, discussions, a break, and a luncheon (which will be provided). In addition, we will have an opportunity for Ad Hoc presentations. From owner-ibis Thu Oct 22 11:34:26 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA29561 for ; Thu, 22 Oct 1998 11:34:25 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id LAA17238; Thu, 22 Oct 1998 11:29:31 -0700 (PDT) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA06789; Thu, 22 Oct 1998 11:29:28 -0700 (PDT) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA05753; Thu, 22 Oct 98 11:29:29 PDT Date: Thu, 22 Oct 98 11:29:29 PDT Message-Id: <9810221829.AA05753@bob> To: ibis@eda.org Subject: CORRECTION REVISED IBIS/JEDEC SUMMIT MEETING To All: Correction - the IBIS Meeting is scheduled for MONDAY, December 7, 1998. Bob To All: We have changed the date and time of the IBIS Summit Meeting in December 1998 to better accomodate the JEDEC meeting activities and promote better interaction between the groups. We are also inviting JEDEC members to present and discuss some new technologies at the meeting. Some signup details have been revised. The IBIS Meeting will start with a FREE Buffet Lunch to those who signup. Bob Ross Mentor Graphics. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- *************** REVISED DATE AND TIME ***************** ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS/JEDEC SUMMIT CALL FOR PARTICIPATION, PRESENTATIONS ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 12:00 PM - 5:00 PM, Monday, December 7, 1998 Location: Kona Kai Continental Hotel 1551 Shelter Island Drive San Diego, CA 92106-3102 Tel: 619-221-8000 Fax: 619-221-5953 Content: Interchange of ideas with JEDEC JC16.2 Subcommittee on Modeling and Test Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: EIA Contact for Signup for IBIS Meeting and FREE Buffet Lunch: Patti Rusher pattir@eia.org J E D E C M E E T I N G S Time/Date: 8:00 AM - 5 PM, Tuesday, December 8, 1998 Content: IBIS Participants are invited to the JEDEC JC16.2 meeting also to view and discuss issues of mutual concern. You must signup for these meetings to be formally invited. Schedule of Meetings: JC16.2 - Modeling and Test: Tuesday Morning, December 8, 1998 JC42 - Memories: Tuesday Afternoon, December 8, 1998 Deadline: JEDEC Meeting Registration Deadline is November 11, 1998 Contact for Signup to JEDEC Meeting: Patti Rusher pattir@eia.org URL for JC42 Schedule: http://www.jedec.org BACKGROUND The JEDEC committee is involved in standardization activities from the physical device point of view. D.C. Sessions of VLSI Technology has been active in both JEDEC JC16.2 and the EIA IBIS Open Forum. The joint/co- located meeting offers several opportunities: EDA people can understand some real device modeling and testing concerns and the semiconductor people can understand the applicability of IBIS models and corresponding simulation tools. The IBIS format is being considered as the template for a JEDEC data sheet proposal. The proposal is to provide the envelope tables and data for the I/O characteristics and pin capacitance for SSTL2 related specifications. Interaction with IBIS experts will be very helpful. The IBIS meeting will be conducted as a formal IBIS Summit meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. JEDEC MEMBERS ARE INVITED TO PROVIDE PRESENTATIONS ON CURRENT TECHNOLOGIES SUCH AS SSTL AND HSTL, ETC., AND ASSOCIATED MODELING/SIMULATION ISSUES TO THE IBIS SUMMIT MEETING TO PROMOTE INTERACTION AMONG TECHNICAL EXPERTS. CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or 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. Plan to bring about 30 copies for distribution at the meeting. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Bob Ross bob_ross@mentorg.com AGENDA The agenda includes presentations, discussions, a break, and a luncheon (which will be provided). In addition, we will have an opportunity for Ad Hoc presentations. From owner-ibis Mon Oct 26 10:38:52 1998 Received: from mailserver.synergy (mailserver.synergysemi.com [209.0.44.115]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA07469 for ; Mon, 26 Oct 1998 10:38:52 -0800 (PST) Received: by mailserver.synergysemi.com with Internet Mail Service (5.5.1960.3) id ; Mon, 26 Oct 1998 10:32:11 -0800 Message-ID: From: "WILSON, Stan" To: "'ibis@vhdl.org'" Subject: unsubscribe Date: Mon, 26 Oct 1998 10:32:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain unsubscribe From owner-ibis Fri Oct 30 09:09:56 1998 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA20946 for ; Fri, 30 Oct 1998 09:09:56 -0800 (PST) Received: (shuq@localhost) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id JAA28205 for ibis@eda.org; Fri, 30 Oct 1998 09:04:52 -0800 (PST) Date: Fri, 30 Oct 1998 09:04:52 -0800 (PST) From: Syed Huq Message-Id: <199810301704.JAA28205@jasper.cisco.com> To: ibis@eda.org Subject: Upcoming Events listed on IBIS website Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: C80rJykubhhbynMeWdKBVA== IBISfans: A new 'Upcoming Events' section has been added to the IBIS website http://www.eia.org/EIG/IBIS/ibis.htm Various IBIS conferences from Dec'98 to June'99 are listed. Regards, Syed. Cisco Systems, Inc From owner-ibis Fri Oct 30 11:04:13 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA21297 for ; Fri, 30 Oct 1998 11:04:13 -0800 (PST) Received: from em-wv03.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id KAA29281; Fri, 30 Oct 1998 10:59:14 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA13173; Fri, 30 Oct 1998 10:59:12 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA02630; Fri, 30 Oct 98 10:59:11 PST Date: Fri, 30 Oct 98 10:59:11 PST Message-Id: <9810301859.AA02630@bob> To: ibis@eda.org Subject: IBIS MEETING AGENDA 11/6/98 Cc: thomas.r.brinkoetter@exgate.tek.com IBIS Open Forum Meeting Agenda for 11/6/98 Bridge Number Reservation # Passcode (916) 356-9200 2-275145 3938931 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 2.1) Rusher - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - 93/67/NP IBIS and EMC Simulation Perrin - JEDEC JC-16.2 Modeling and Testing Sessions - IEEE P1537 Data Format Project Davis/Peters IBIS (East) Users Group Meetings Haller IBISEAST October 15, 1998 SUMMIT Feedback All JEDEC/IBIS December 7, 1998 SUMMIT Meeting Sessions/Ross DesignCon99 February 1, 1999 SUMMIT Meeting Ross Version 3.2 Parser Development Ross/Flora/Rokusek - Source, Executables - Version 3.2 Document - Version 3.2 Parser Development Version 3.2 Ratification Ross Tektronix IPA510 Software Distribution Proposal Huq/Brinkoetter Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 9:15 Technical Discussion BIRD54 - Package Model Corrections (Vote) Ross/Peters BUG32 - Package Model Lumped and Distributed Syntax Ross Not Correct BIRD55 - [Model Spec] Vmeas Addition (Vote) Ross Series Elements restriction Ross/Rokusek 100 Point BIRD? Ross EIAJ IMIC Technical Discussion Ross BUG31 - Error for [Pulldown Decreasing Current Should Ross be Warning (more discussion) New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off