From owner-ibis Tue Jan 4 16:01:57 2000 Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA29471 for ; Tue, 4 Jan 2000 16:01:55 -0800 (PST) Received: from postoffice.pacbell.net ([209.79.182.78]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FNU002G5589B3@mta1.snfc21.pbi.net> for ibis@vhdl.org; Tue, 4 Jan 2000 15:57:47 -0800 (PST) Date: Tue, 04 Jan 2000 15:56:14 -0800 From: Jon Powell Subject: Signs for DesignCon To: "ibis@vhdl.org" Reply-to: jpowell@viewlogic.com Message-id: <3872889D.23636BCF@postoffice.pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Hello all, this is a DesignCon update. I have received new signs from the following companies: TDA SIQUAL CADENCE HYPERLYNX They all look REALLY GOOD. (This is a hint that your company making a sign probably looks better than a sign I made last year, so don't blame me if Kelle's sign looks better than yours) If you think that you sent me a sign and you aren't on the list, please send email. If you want to send me a sign, do so. and HAPPY NEW YEAR. jon IBIS Librarian. -- Jon Powell Director of HSSD Consulting Services Viewlogic Systems, INC. 805 988 8250 From owner-ibis Thu Jan 6 08:27:21 2000 Received: from soran.bos.ascend.com (soran.bos.ascend.com [152.148.40.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA10973 for ; Thu, 6 Jan 2000 08:27:19 -0800 (PST) Received: from rawhide.bos.ascend.com (rawhide [152.148.140.32]) by soran.bos.ascend.com (8.9.3/8.9.3) with ESMTP id LAA08813 for ; Thu, 6 Jan 2000 11:00:33 -0500 (EST) Received: from fox.bos.ascend.com (fox.bos.ascend.com [152.148.141.238]) by rawhide.bos.ascend.com (8.8.8+Sun/8.8.4) with ESMTP id KAA07715 for ; Thu, 6 Jan 2000 10:59:54 -0500 (EST) Received: by fox.bos.ascend.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 10:59:45 -0500 Message-ID: From: "Ruston, Matt" To: "'ibis@eda.org'" Subject: cPCI generic 5V Ibis Models Date: Thu, 6 Jan 2000 10:59:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" All: Hi. I'm trying to do 5V Compact PCI sims and am in need of strong and weak models. In the cPCI draft spec (PICMG 2.0 D3.0) dated July 21, 1999, there is reference in Appendix A (Pg 79) to models and they plot the I-V curves referenced to the min-max specs. Does anyone have these models (either Ibis or Spice) and can they forward them to me? If not, does anyone have anything that is close to covering the full range of the cPCI 5V signaling specs? Thanks in advance... Matt Matt Ruston (mruston@lucent.com) Lucent Technologies CNS Voice: (508) 486-2188 Fax: (508) 486-2126 From owner-ibis Thu Jan 6 11:25:35 2000 Received: from osiris.vlsi.com (relayhost.vlsi.com [63.194.140.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA11591 for ; Thu, 6 Jan 2000 11:17:30 -0800 (PST) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id LAA16741 for ; Thu, 6 Jan 2000 11:16:30 -0800 (PST) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris via smap (V2.0) id xma016706; Thu, 6 Jan 00 11:16:15 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CMAW7S3V; Thu, 6 Jan 2000 12:16:13 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <3874E9FE.7173CD8@vlsi.com> Date: Thu, 06 Jan 2000 12:16:14 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "'ibis@eda.org'" Subject: Re: cPCI generic 5V Ibis Models References: Content-Type: multipart/mixed; boundary="------------3980460E3BE76C1DA1365D62" This is a multi-part message in MIME format. --------------3980460E3BE76C1DA1365D62 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ruston, Matt" wrote: > > All: > > Hi. I'm trying to do 5V Compact PCI sims and am in need of strong and weak > models. In the cPCI draft spec (PICMG 2.0 D3.0) dated July 21, 1999, there > is reference in Appendix A (Pg 79) to models and they plot the I-V curves > referenced to the min-max specs. Does anyone have these models (either Ibis > or Spice) and can they forward them to me? If not, does anyone have anything > that is close to covering the full range of the cPCI 5V signaling specs? If someone wants to modify them, I've build a set of V/I models for AGP, which is similar to the PCI specs. Shouldn't be too tough. Models attached. -- D. C. Sessions dc.sessions@vlsi.com --------------3980460E3BE76C1DA1365D62 Content-Type: text/plain; charset=us-ascii; name="vi_functions.inc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vi_functions.inc" * AGP 2.0 V/I curve functions * Source: * AGP specification rev. 2.0 Figure 4-29 (3.3v) * AGP specification rev. 2.0 Figure 4-30 (1.5v) * AGP specification rev. 2.0 Figure 4-33 (1.5v) * Maximum pullup current at 3.3v .SUBCKT ioh33max pad vddq vssq E1 vddq offs + VOL='0.3*v(vddq,vssq)' E2 offs pad + VOL='((i(E1)/54m)*v(vddq,vssq)/(v(pad,vssq)+(0.4*v(vddq,vssq))))-v(vddq,offs)' + MAX=0 .ENDS ioh33max * Maximum pulldown current at 3.3v .SUBCKT iol33max pad vddq vssq E1 offs vssq + VOL='0.18*v(vddq,vssq)' E2 pad offs + VOL='((i(E1)/141m)*v(vddq,vssq)/v(vddq,pad))-v(offs,vssq)' + MAX=0 .ENDS iol33max * Minimum pullup current at 3.3v .SUBCKT ioh33min pad vddq vssq .PARAM + rline = '0.7/9m' E1 vddq offs VOL='0.1*v(vddq,vssq)' E2 offs pad + VOL='(i(E2)*rline)-v(vddq,offs)' + MIN=0 MAX=4 G1 offs pad + CUR='(v(vddq,vssq)*0.7/rline)-i(E2)' MIN=-50m MAX=0 R1 vddq pad 1e8 .ENDS ioh33min * Minimum pulldown current at 3.3v .SUBCKT iol33min pad vddq vssq .PARAM + rline = '0.6/12m' E1 offs vssq VOL='0.1*v(vddq,vssq)' E2 pad offs + VOL='(i(E2)*rline)-v(offs,vssq)' + MIN=0 MAX=4 G1 pad offs + CUR='(v(vddq,vssq)*0.6/rline)-i(E2)' + MIN=-50m MAX=0 R1 pad vssq 1e8 .ENDS iol33min * 1.5v constraint curves * Maximum pullup current at 1.5v (per 4-30) .SUBCKT ioh15max1 pad vddq vssq E1 vddq offs + VOL='0.3*v(vddq,vssq)' E2 offs pad + VOL='((i(E1)/111m)*v(vddq,vssq)/v(pad,vssq))-v(vddq,offs)' + MAX=0 .ENDS ioh15max1 * Maximum pulldown current at 1.5v (per 4-30) .SUBCKT iol15max1 pad vddq vssq E1 offs vssq + VOL='0.3*v(vddq,vssq)' E2 pad offs + VOL='((i(E1)/111m)*v(vddq,vssq)/v(vddq,pad))-v(offs,vssq)' + MAX=0 .ENDS iol15max1 * Minimum pullup current at 1.5v (per 4-30) .SUBCKT ioh15min1 pad vddq vssq .PARAM + rline = '0.675/11m' E1 vddq offs VOL='0.1*v(vddq,vssq)' E2 offs pad + VOL='(i(E2)*rline)-v(vddq,offs)' + MIN=0 MAX=2 G1 offs pad + CUR='(v(vddq,vssq)*0.675/rline)-i(E2)' MIN=-50m MAX=0 R1 vddq pad 1e8 .ENDS ioh15min1 * Minimum pulldown current at 1.5v (per 4-30) .SUBCKT iol15min1 pad vddq vssq .PARAM + rline = '0.675/11m' E1 offs vssq VOL='0.1*v(vddq,vssq)' E2 pad offs + VOL='(i(E2)*rline)-v(offs,vssq)' + MIN=0 MAX=2 G1 pad offs + CUR='(v(vddq,vssq)*0.675/rline)-i(E2)' + MIN=-50m MAX=0 R1 pad vssq 1e8 .ENDS iol15min1 * Maximum pullup current at 1.5v (per 4-33) .SUBCKT ioh15max2 pad vddq vssq .PARAM + ib1 = '200m/9' E1 vddq pad2 VOL='MIN(v(vddq,pad),v(vddq,vssq)/2) G1 vddq pad + CUR='ib1*(v(vddq,pad)+(v(pad2,vssq)*v(vddq,pad2)/v(vddq,vssq)))' R1 vddq pad 1e8 .ENDS ioh15max2 * Maximum pulldown current at 1.5v (per 4-33) .SUBCKT iol15max2 pad vddq vssq .PARAM + ib1 = '200m/9' E1 pad2 vssq VOL='MIN(v(pad,vssq),v(vddq,vssq)/2) G1 pad vssq + CUR='ib1*(v(pad,vssq)+(v(pad2,vssq)*v(vddq,pad2)/v(vddq,vssq)))' R1 pad vssq 1e8 .ENDS iol15max2 * Minimum pullup current at 1.5v (per 4-33) .SUBCKT ioh15min2 pad vddq vssq .PARAM + k1 = 48 $ 1/20.833m + k2 = 600 $ 1/1.667m + k3 = 'k2-k1' E1 n1 vddq VOL='MIN(-0.15*v(vddq,vssq),48*i(E1))' E2 pad n1 VOL='MIN(0,k3*(i(E1)+(0.5*v(vddq,vssq)/k1)))' .ENDS ioh15min2 * Minimum pulldown current at 1.5v (per 4-33) .SUBCKT iol15min2 pad vddq vssq .PARAM + k1 = 48 $ 1/20.833m + k2 = 600 $ 1/1.667m + k3 = 'k2-k1' E1 n1 vssq VOL='MAX(0.15*v(vddq,vssq),48*i(E1))' E2 pad n1 VOL='MAX(0,k3*(i(E1)-(0.5*v(vddq,vssq)/k1)))' .ENDS iol15min2 --------------3980460E3BE76C1DA1365D62-- From owner-ibis Thu Jan 6 13:56:26 2000 Received: from mage.dt.wdc.com (mage.dt.wdc.com [129.253.40.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA12256 for ; Thu, 6 Jan 2000 13:56:25 -0800 (PST) Received: from daak.dt.wdc.com ([172.31.2.106]) by mage.dt.wdc.com (8.8.8/8.8.8) with ESMTP id NAA27282 for ; Thu, 6 Jan 2000 13:55:16 -0800 (PST) Received: from dt.wdc.com ([172.31.10.16]) by daak.dt.wdc.com (Netscape Messaging Server 4.1) with ESMTP id FNXOXZ00.71V for ; Thu, 6 Jan 2000 13:56:23 -0800 Message-ID: <38750F70.956A197D@dt.wdc.com> Date: Thu, 06 Jan 2000 13:56:00 -0800 From: "Martin Mcsweeney" X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From owner-ibis Thu Jan 6 14:18:41 2000 Received: from lsi.lsil.com (lsi.lsil.com [147.145.40.2]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA12376 for ; Thu, 6 Jan 2000 14:18:39 -0800 (PST) Received: from mhbs.lsil.com ([147.145.31.100]) by lsi.lsil.com (8.9.3+Sun/8.9.1) with ESMTP id OAA15846 for ; Thu, 6 Jan 2000 14:17:14 -0800 (PST) Received: from [147.145.143.10] by mhbs.lsil.com for ibis@eda.org; Thu, 6 Jan 2000 14:15:50 -0800 Received: from mms21.minn by mms10 (SMI-8.6/SMI-SVR4) id QAA03035; Thu, 6 Jan 2000 16:15:46 -0600 Received: from mms21 by mms21.minn (SMI-8.6/SMI-SVR4) id QAA16879; Thu, 6 Jan 2000 16:15:46 -0600 Message-Id: <200001062215.QAA16879@mms21.minn> Date: Thu, 6 Jan 2000 16:15:46 -0600 (CST) From: Bret Huettl Reply-To: Bret Huettl Subject: unsubscribe To: ibis@eda.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hdeBTR4qbJ4p96fDbDRqhQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc unsubscribe From owner-ibis Thu Jan 6 13:35:03 2000 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA12187; Thu, 6 Jan 2000 13:35:03 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.17 2000/01/06 00:19:44 nzand Exp $) with ESMTP id NAA20593; Thu, 6 Jan 2000 13:34:09 -0800 (PST) Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35]) by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id NAA11638; Thu, 6 Jan 2000 13:34:09 -0800 (PST) Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1]) by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA02670; Thu, 6 Jan 2000 13:13:20 -0800 (PST) Message-Id: <200001062113.NAA02670@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: Bird 62.2 -- Enhanced Specification of Receiver Thresholds Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jan 2000 13:13:20 -0800 From: Stephen Peters Hello All: Bird 62.2 includes a minor syntax correction. For details, refer to the ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: section at the bottom. Regards, Stephen Peters Intel Corp. ============ Buffer Issue Resolution Document (BIRD) BIRD ID#: 62.2 ISSUE TITLE: Enhanced Specification of Receiver Thresholds REQUESTOR: DC Sessions (Philips), Stephen Peters, Richard Melitz, Arpad Muranyi (Intel Corp). DATE SUBMITTED: Aug 24, 1999, Dec 28, 1999, Jan 6, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: When specifying receiver input thresholds the current specification allows only the traditional DC derived Vinh and Vinl parameters. These two parameters are no longer adequate for describing receivers used for high speed designs. This BIRD proposes four new input switching threshold parameters: Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc. These parameters are referenced to an reference point Vth, and this reference is allowed to vary with variations in a supply. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Model Spec] keyword. |============================================================================= | Keyword: [Receiver Thresholds] | Required: No | Sub-Params: Vth, Vth_min, Vth_max, Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc, | Vth_sensitivity, Input_Ref_Supply | Description: The [Receiver Thresholds] keyword defines both a set of | receiver input thresholds as well as their sensitivity to | variations in a referenced supply. The subparameters are | defined as follows: | | Vth, Vth_min and Vth_max are the ideal input threshold voltage | at which the output of a digital logic receiver changes state. | Vth is the nominal input threshold voltage under the voltage, | temperature and process conditions that define 'typ'. Vth_min | is the minimum input threshold voltage at 'typ' conditions | while Vth_max is the maximum input threshold voltage at 'typ' | conditions. | | Vinh_ac is the voltage that a low-to-high going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinh_ac is | sufficient to guarantee a receiver state change. Vinh_ac is | expressed as an offset from Vth. | | Vinh_dc is the voltage that an input waveform must remain | above (more positive than) in order to guarantee that a | receiver output will NOT change state. Vinh_dc is expressed | as an offset from Vth. | | Vinl_ac is the voltage that a high-to-low going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinl_ac is | sufficient to guarantee a receiver state change. Vinl_ac | is expressed as an offset from Vth. | | Vinl_dc is the voltage that an input waveform must remain below | (more negative than) in order to guarantee that a receiver's | output will NOT change state. Vinh_dc is expressed as a | offset from Vth. | | Vth_sensitivity is a unitless number that specifies how Vth | varies with respect to the supply voltage defined by the | Input_Ref_Supply subparameter. Vth_sensitivity is defined | as: | | change in input threshold voltage | Vth_sensitivity = ------------------------------------ | change in referenced supply voltage | | Vth_sensitivity must be entered as a whole number or | decimal, not as a fraction. | | Input_Ref_Supply indicates which supply voltage Vth tracks; | i.e. it indicates which supply voltage change causes a change | in input threshold. The legal arguments to this subparameter | are VOLTAGE_RANGE (the supply voltage defined by the | [Voltage Range] keyword), PULLUP_REF (the supply voltage | defined by the [Pullup Reference] keyword), or EXT (an | external voltage defined by the [External Reference] keyword). | | | Usage Rules: The [Receiver Thresholds] keyword is valid if the model type | includes any reference to input or I/O. The Vinh_ac, Vinh_dc, | Vinl_ac, Vinh_dc and Vth subparameters are required and | override the Vinh, Vinl, Vinh+/- and Vinl+/- subparameters | declared under the [Model] or [Model Spec] keywords. The | Vth_min, Vth_max, Vth_sensitivity and Input_Ref_Supply | subparameters are optional. However, if the Vth_sensitivity | subparameter is present then the Input_Ref_Supply | subparameter must also be present. | | Subparameter Usage Rules: | Numerical arguments are separated from their associated | subparameter by an equals sign (=); white space around the | equals sign is optional. The argument to the | Input_Ref_Supply subparameter is separated from the | subparameter by white space. | | Vth at Minimum or Maximum Operating Conditions: | As described above, the Vth_min and Vth_max subparameters | define the minimum and maximum input threshold values under | typical operating conditions. There is no provision for | directly specifying Vth under minimum or maximum operating | conditions. Instead, these values are calculated using | the following equation: | | Vth(min/max) = Vth* + [(Vth_sensitivity) X (change in supply voltage)] | | where Vth* is either Vth, Vth_min or Vth_max as appropriate, | and the supply voltage is the one indicated by the | Input_Ref_Supply subparameter. | | | Differential Receivers: | For a single ended receiver the numerical values of Vth, | Vth_min and Vth_max are specified with respect to 0v. | However, if the [Receiver Threshold] keyword is describing | a differential receiver (i.e. is part of a [Model] statement | that describes a pin listed in the [Diff Pin] keyword), then | Vth is typically assigned a value of zero volts and the | Vth_min and Vth_max parameters are not used. The values of | Vinh_* and Vinl_* subparameters are still given as an | offset from Vth and become, in effect, the more traditional | Vdiff. | | Examples: | | A basic 3.3v single ended receiver using only the required | subparameters | Vth = 1.5v Vinh_ac = +225mV Vinh_dc = +100mV Vinl_ac = -225mV Vinl_dc = -100mV | | | A single ended receiver using an external threshold reference. In this | case the input threshold is the external reference voltage so | Vth_sensitivity equals 1. | Vth = 1.0v Vth_sensitivity = 1 Input_Ref_Supply EXT Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A fully specified single ended 3.3v CMOS receiver | Vth = 1.5v Vth_min = 1.45v Vth_max = 1.53v Vth_sensitivity = 0.45 Input_Ref_Supply VOLTAGE_RANGE Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A differential receiver | Vth = 0.0v Vinh_ac = +50mV Vinh_dc = +25mV Vinl_ac = -50mV Vinl_dc = -25mV 2) The following new keyword is defined and place in the specification following the [GND Clamp Reference] keyword |============================================================================= | Keyword: [External Reference] | Required: Yes, if a receiver's input threshold is determined by an | external reference voltage | Description: Defines a voltage source that supplies the reference voltage | used by a receiver for its input threshold reference. | Usage Notes: Provide actual voltages (not percentages in the typ, min max | format. "NA" is allowed for the min and max values only. |----------------------------------------------------------------------------- | variable typ min max [External Reference] 1.0v 0.95v 1.05v 3) Under section 2 of General Syntax Rules and Guidelines the following words are added to the list of reserved words. EXT - A reference to a voltage defined by the [External Reference] Keyword VOLTAGE_RANGE - A reference to a voltage defined by the [Voltage Range] keyword PULLUP_REFERENCE - A reference to a voltage defined by the [Pullup Reference] keyword ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This proposal follows the recommendations of the JC-15 committee for specifying SDRAM inputs. Update for 62.1: Specified exactly which [Model] and [Model Spec] parameters are overridden by [Receiver Threshold] and changed the wording of the "Differential Receivers:" to indicate that the numerical value of Vth is *typically* assigned a value of 0v rather than *must* be assigned a value of zero. Update for 62.2 Under Usage Rules: added the section (Subparameter Usage Rules:) describing the syntax rules for seperating arguments from subparameters. Updated examples with this change. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Melitz and Aprad Muranyi of Intel Corp. ******************************************************************************* From owner-ibis Thu Jan 6 13:38:45 2000 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 NAA12208; Thu, 6 Jan 2000 13:38:45 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.17 2000/01/06 00:19:44 nzand Exp $) with ESMTP id NAA15911; Thu, 6 Jan 2000 13:48:34 -0800 (PST) Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35]) by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id NAA12494; Thu, 6 Jan 2000 13:37:50 -0800 (PST) Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1]) by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA02682; Thu, 6 Jan 2000 13:17:02 -0800 (PST) Message-Id: <200001062117.NAA02682@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: Bird 63.2 -- Documentation of Receiver Setup and Hold Timing Conditions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jan 2000 13:17:01 -0800 From: Stephen Peters Hello All: Bird 63 is reissued as Bird 63.2 to correct a syntax usage error. For details, refer to the ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: section at the bottom. Regards, Stephen Peters Intel Corp. ============= Buffer Issue Resolution Document (BIRD) BIRD ID#: 63.3 ISSUE TITLE: Documentation of Receiver Setup and Hold Timing Conditions REQUESTOR: D.C. Sessions (Philips), Stephen Peters, Richard Melitz, Arpad Muranyi (Intel Corp.) DATE SUBMITTED: Sept 8, 1999, Dec 27, 1999, Jan 6, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Currently, the edge rate and overdrive conditions under which a receiver's data book setup and hold timings are specified are not documented. This bird provides a way for the model creator to document those conditions in an IBIS file. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Receiver Threshold] keyword. |============================================================================= | Keyword: [Tester Spec] | Required: No | Sub-Params: Tester_Vlow, Tester_Vhigh, Tester_Vth, Tester_Slew_Setup, | Tester_Slew_Hold | Description: The [Tester Spec] keyword documents the input overdrive | and tester slew rate conditions under which a device's | input setup and hold times are specified. The subparameters | are defined as follows: | | Tester_Vth is the point on the input waveform from | which an receivers setup and hold time is referenced. It is | usually the input voltage at which the output of a digital | logic receiver changes state. Tester_Vth is used as the | reference voltage for the Tester_Vlow and Tester_Vhigh | parameters. | | Tester_Vlow represents the starting voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the ending voltage of a | high-to-low going waveform. Tester_Vlow is expressed as an | offset from Tester_Vth. | | Tester_Vhigh represents the ending voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the starting voltage of | a high-to-low going waveform. Tester_Vhigh is expressed as an | offset from Tester_Vth. | | Tester_Slew_Setup is the tester waveform's slew rate at | which a receiver's setup time is specified. For purposes of | this keyword, slew rate is defined as: | | Tester_Vhigh - (Tester_Vlow) | Slew Rate = ------------------------------------------- | Time it takes to swing the above voltage | | Tester_Slew_Setup must be expressed as an explicit ratio | of voltage over time, and not reduced to a decimal number. | | Tester_Slew_Hold is the tester waveform's slew rate at which | a receiver's hold time is specified. Slew rate is defined | as above. Tester_Slew_Hold must be expressed as an explicit | ratio of voltage over time, and not reduced to a decimal | number. | | | Usage Rules: The [Tester Spec] keyword is valid if the model type | includes any reference to input or I/O. All subparameters | are required to be present. When entering a numeric value the | subparameter argument and the subparameter itself must | be separated by an equals sign (=). The argument to the | Tester_Skew_* subparameter must be seperated from the | subparameter itself by a white space. | | Differential Receivers: | For a single ended receiver the numerical value of | Tester_Vth is specified with respect to 0v. However, if | the [Tester Spec] keyword is describing a differential receiver | (i.e. is part of a [Model] statement that describes a pin | listed in the [Diff Pin] keyword), then the numerical value of | Tester_Vth is typically given as 0v. Tester_Vlow and | Tester_Vhigh are then assumed to represent the difference in | voltage between one input and the other. | | | A basic 3.3v single ended receiver Tester_Vth = 1.5v Tester_Vlow = -1.0v Tester_Vhigh = 2.5v Tester_Slew_setup 1v/ns Tester_Slew_hold 1v/ns | | A differential receiver Tester_Vth = 0V Tester_Vlow = -200mV Tester_Vhigh = +200mV Tester_Slew_setup 1.2v/1ns Tester_Slew_hold 1.2v/1ns | | ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Like it's companion BIRD #62, this bird is an attempt to better specify and document a receiver's functionality. It follows the convention of the previous BIRDS in that most of the parameter values are specified as an offset from a reference voltage. This technique supports both single ended and differential receivers. Note that there are separate slew rate entries for setup and hold time. When formulating this bird the authors were not sure if receiver hold time was specified under different slew rate conditions than setup time. Thus, separate slew rate entries. These two parameters can be collapsed into one if further information indicates that this is not the case. Updates for 63.1: Corrected "Tester_Skew" to "Tester_Slew" in the examples (typo correction) and fixed up the Slew_rate equation by removing the absolute value markers. Changed Slew_rate so that it is expressed as an explicit ratio and not as a decimal (following the convention of [Ramp Rate]). Clarified the meaning of Tester_Vth. Finally, under "Differential Receivers:" changed the text to indicate that the numerical value of Tester_Vth is *typically* given as 0v rather than *must* be given as zero. Updates for 63.2: Syntax correction -- the argument to the Tester_Slew_* parameter should be seperated from the subparameter by white space, not an equals sign (it's a non-numeric argument). Corrected examples. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Melitz and Aprad Muranyi of Intel Corp. ******************************************************************************* From owner-ibis Fri Jan 7 13:43:40 2000 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA17894 for ; Fri, 7 Jan 2000 13:43:39 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.8.8/8.6.11) id NAA19426 for ; Fri, 7 Jan 2000 13:42:42 -0800 (PST) Received: from scmh1.nsc.com(139.187.179.130) by natsemi-bh.nsc.com via smap (4.1) id xmab18824; Fri, 7 Jan 00 13:42:06 -0800 Received: from scmh1-gw.nsc.com by scmh1.nsc.com (X.400 to RFC822 Gateway); Fri, 7 Jan 2000 13:42:04 -0800 X400-Received: by mta MTANSC1 in /c=us/admd= /prmd=National/; Relayed; 07 Jan 2000 13:42:02 -0800 X400-Received: by /c=us/admd= /prmd=National/; Relayed; 07 Jan 2000 13:42:02 -0800 X400-MTS-Identifier: [/c=us/admd= /prmd=National/; 03F7438765DAA082-MTANSC1] Content-Identifier: 03F7438765DAA082 Content-Return: Allowed X400-Content-Type: P2-1988 ( 22 ) Conversion: Allowed Original-Encoded-Information-Types: IA5-Text Priority: normal Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: Milt.Schwartz@nsc.com X400-Recipients: non-disclosure; Message-Id: <"03F7438765DAA082*/c=US/admd= /prmd=National/o=notes/ou=Americas/s=Schwartz/g=Milt/"@MHS> Date: 07 Jan 2000 13:42:02 -0800 From: Milt Schwartz To: ibis Subject: IBIS Summit 2000; 2nd Call To All: This is the second call for presentations and participation at the IBIS Summit Meeting held with DesignCon 2000. Milt Schwartz National Semiconductor ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------------------------------------------- DESIGNCON 2000 IBIS SUMMIT 2ND CALL FOR PARTICIPATION, PRESENTATIONS -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:00 PM - 5:00 PM, Monday, January 31, 2000 Location: Santa Clara Convention Center Santa Clara, CA Content: IBIS Future Requirements is the main topic of this meeting These include an exchange of ideas on IBIS accuracy, connectors, and new requirements under discussion. Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: DesignCon 2000 & National Semiconductor Corporation IBIS Summit Signup: Milt Schwartz schwartz@nsc.com D E S I G N C O N 2 0 0 0 M E E T I N G S Time/Date: Monday - Thursday, January 31 - February 3, 2000 Exhibition: Tuesday - Wednesday, 12:30 PM - 6:30 PM, February 1 - 2, 2000 IBIS Booth: #1039, Exhibition Hall - Possible Accuracy Committee Demonstration - IBIS Information - Contact Jon Powell, jpowell@viewlogic.com, for information. URL DesignCon99: http://www.designcon.com/ Signup Discount: IBIS member companies may receive a 15 percent discount to the DesignCon 2000 Conference. Past Conference attendees also will receive a 20% alumni discount. AGENDA The agenda includes presentations, discussions, refreshments, and a free buffet luncheon for participants. In addition, we will have an opportunity for Ad Hoc presentations and extended discussions. So far we tentatively plan the following presentations and discussions: Model Design: Tables and Equations - Lynne Green, HyperLynx Conector Model Specification - Gus Panella, Molex Accuracy Specification - Bob Haller, Compaq Input Receiver Modeling - Don Telium, Cadence Discussion - Future of IBIS - Stephen Peters, Intel CALL FOR IBIS SUMMIT PRESENTATIONS Some additional presentations are welcome 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. If you cannot provide an electronic format, then plan to bring 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: Milt Schwartz schwartz@nsc.com Deadline: Wednesday, January 26, 2000 for receiving presentations for copying. regards, milt Milt Schwartz Interface Applications National Semiconductor email: schwartz@nsc.com Phone: 408-721-3261 Fax: 408-721-4785 Mail Stop: A2595 From owner-ibis Fri Jan 7 15:59:26 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA18163 for ; Fri, 7 Jan 2000 15:59:25 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA03071; Fri, 7 Jan 2000 15:58:01 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA06005; Fri, 7 Jan 2000 15:57:59 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <38767D88.4377856F@mentor.com> Date: Fri, 07 Jan 2000 15:58:00 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Meeting Agenda 1/14/2000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 1/14/00 Bridge Number Reservation # Passcode (916) 356-9200 5-169351 4378912 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin - JEDEC JC-16.2 Modeling and Testing Sessions DesignCon2000 IBIS Summit Planning Ross/Schwartz DATE2000 IBIS Summit Planning Ross Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 8:45 Technical Discussion (some topics may be deferred) IBIS Futures (IBIS-X, API, BIRDxx) Peters/Muranyi Connector Proposal Review (Continued) Panella/Chrisafulli BIRD64.1 - Package Model Selector Muranyi BIRD66 - [Model Spec] Vref Addition McMorrow/Ross BUG34 - No Error Reported for Missing V/I Tables Flora in Output Buffers BIRD61.1 - Enhanced Characterization of Receivers Peters BIRD62.2 - Enhanced Chararcterization of Receiver Peters Thresholds BIRD63.2 - Documentation of Receiver Setup and Hold Peters Timing Conditions BIRD65 - C_comp Refinements Muranyi Other ibischk3 Bugs Ross New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Mon Jan 10 06:47:08 2000 Received: from mail1.uunet.ca (root@mail1.uunet.ca [209.167.141.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA26514 for ; Mon, 10 Jan 2000 06:47:08 -0800 (PST) From: kraahemifar@interactiv.com Received: from interactiv.com (mail.interactiv.com [207.176.193.5]) by mail1.uunet.ca with SMTP id <215718-10531>; Mon, 10 Jan 2000 09:46:01 -0500 Received: from ccMail by interactiv.com (ccMail Link to SMTP R8.11.00.3) id AA947515465; Mon, 10 Jan 2000 09:44:36 -0500 Message-Id: <0001109475.AA947515465@interactiv.com> X-Mailer: ccMail Link to SMTP R8.11.00.3 Date: Mon, 10 Jan 2000 09:55:54 -0500 To: Subject: A question MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" Hello Sir: I understand why IBIS models are needed. However, I am still trying to understand how the simulation of IBIS models are performed. One way of doing it is to convert IBIS models to structural models and use SPICE on them. I am interested to see documents on the simulation of IBIS components. Please note that I am not talking about the verification of the models using simulation. Let me explain. Suppose you have a circuit whose components are described using IBIS models. Now, you are interested to perform transient analysis. How is the simulation done? Thanks a lot for your care and response. Best Regards, Kaamran From owner-ibis Mon Jan 10 06:59:33 2000 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA26601 for ; Mon, 10 Jan 2000 06:59:32 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id HAA26779 for ; Mon, 10 Jan 2000 07:58:37 -0700 (MST)] Received: [from msgphx8.sps.mot.com (msgphx8.sps.mot.com [216.11.52.8]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA10179 for ; Mon, 10 Jan 2000 07:58:37 -0700 (MST)] Received: from email.sps.mot.com ([163.12.136.17]) by msgphx8.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA51FE for ; Mon, 10 Jan 2000 07:58:36 -0700 Message-ID: <3879F3C2.1F5EA2F3@email.sps.mot.com> Date: Mon, 10 Jan 2000 08:59:14 -0600 From: "Bob Garbs" Organization: Motorola Semiconductor Products Sector X-Mailer: Mozilla 4.61 [en]C-MOT45 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 unsubscribe From owner-ibis Mon Jan 10 10:30:21 2000 Received: from mta3.snfc21.pbi.net (mta3.snfc21.pbi.net [206.13.28.141]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA27521 for ; Mon, 10 Jan 2000 10:30:20 -0800 (PST) Received: from postoffice.pacbell.net ([209.79.182.43]) by mta3.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FO400MSOTPEX9@mta3.snfc21.pbi.net> for ibis@vhdl.org; Mon, 10 Jan 2000 10:22:28 -0800 (PST) Date: Mon, 10 Jan 2000 10:20:51 -0800 From: Jon Powell Subject: Virus Alert To: "ibis@vhdl.org" Reply-to: jpowell@viewlogic.com Message-id: <387A2303.D3DEBE29@postoffice.pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit In December I received (from an si-list member) a reponse to a posting that contained the text: ************************ I received your email and I shall send you a reply ASAP. Till then, take a look at the attached zipped docs. ************************** The attached zipped.exe file was a notorious (and new) virus called Worm.ExploreZip(pack) Luckily I never executed the file. However, if anyone were to execute it it would 1) send out this email to everyone on your email list. 2) erase all of your word and powerpoint and other docs and in general really screw up your day. WARNING: Other people on the list probably got this. Don't execute anything named zipped.exe. NEW (as of December 25) Norton Antivirus can find it. Previous definitions won't. You can search your mail for the above ASCII. I am not saying where I got this from (he is already screwed). If anyone else has noticed this, please respond so that all can be properly alerted. Happy New Year, Jon -- Jon Powell Director of HSSD Consulting Services Viewlogic Systems, INC. 805 988 8250 From owner-ibis Mon Jan 10 14:25:37 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA28260 for ; Mon, 10 Jan 2000 14:25:36 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA25202; Mon, 10 Jan 2000 14:24:10 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA14034; Mon, 10 Jan 2000 14:24:08 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <387A5C06.3CA5C8EB@mentor.com> Date: Mon, 10 Jan 2000 14:24:06 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Connector Specification Editorial Review Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee: I appreciate the amount of work and consideration that was needed to produce the Version 0.92 Connector Specification. Overall, the document contains a lot of good material and is very comprehensive. This review is mostly editorial and deals with syntax and conventions. The emphasis of most comments is to align the Connector Specification more closely with IBIS Version 3.2, or else to understand why we should deviate. In any case, we can discuss these and other comments at the next meeting and on the reflector. While IBIS Version 3.2 is not perfect and some deviation is needed, I believe unnecessary deviation should be avoided for several reasons: Minimize confusion between documents over syntax Simplify the document and parser development/testing Speed up the formal adoption Leverage on the latest publicly reviewed document I will probably have more comments as a result of further reading and technical review. Bob Ross Mentor Graphics GENERAL: 1. I would prefer keywords with 3 or less individual words since both the IBIS and Connector keywords allow both the underscore "_" and space characters as separators. This keeps the variations that need to be stored to 8 or less. One suggestion is to eliminate "Cn_" in many of the keywords. 2. The existing IBIS extensions are .ibs, .pkg, and .ebd. The new document proposes .ibiscnn. The practical reason for 3-letter extensions no longer exists. However, I still would favor .cnn or some other 3 letter choice because the file name itself may be a column entry in some new keyword (such as [Reference Designator Map] in an EBD). 3. The new format sets the line length limit to 120 characters but restricts comment lines to 80 characters. I would favor keeping the 80 character limitation throughout, but would also accept 120 characters throughout. Having two limits provides unnecessary complication in the document and in the parser. GENERAL SYNTAX RULES AND GUIDELINES SECTION: 1. Item 2) adds reserved word PWRGND. This is unnecessary since POWER can be used to include GND. Also RET is not referenced anywhere else in the document. I do not think it is necessary. 2. Item 3) in the IBIS Version 3.2 setting file name case and size limits is omitted. I would add that paragraph. Note, the information is moved to the [File Name] keyword. More comments on this are below. 3. Item 3) in the Connector Specification should be replaced by the text of Item 4) in IBIS Version 3.2 (changed from 80 to 120 characters, if that is the consensus). 4. Item 5) in the Connector Specification should be replaced by Item 6) in IBIS Version 3.2 to clarify the keyword syntax. 5. Item 8) in the Connector Specification should be replaced by the updated Item 10) in IBIS Version 3.2 regarding tab character usage. The reference to 80 characters could be replaced by 120 characters if 120 is chosen as the line length limit. 6. I recommend deleting Item 11) regarding location of files. This is out of date. This information might be better located in a general introduction section. 7. Item 13) regarding number of decimal points in a number should be eliminated. There are probably exceptions on each end. As an alternative, a general recommendation similar to IBIS Version 3.2 regarding I-V and V-T data in Item 9) could be added recommending up to 5 decimal digit accuracy where necessary. 8. Item 14) in IBIS Version 3.2 regarding defining ASCII characters should be added. FILE HEADER INFORMATION: 1. [IBIS_Cn_Model_Ver]: I would change to [Conn Ver] to (parallel to [IBIS Ver]) to distinuish a Connector file. I would start with [Conn Ver] 1.0. I would use the same text as the used for [IBIS Ver] except substituting CONN for IBIS. 2. [Comment Char]: I would use the latest IBIS Version 3.2 description since it lists the permitted versus excluded characters. 3. I do not see any reason for creating new rules for the common IBIS Verison 3.2 keywords [File Name], [File Rev], [Date], [Source], [Notes], [Disclaimer] and [Copyright]. While IBIS rules may not be perfect, they are, in practice, quite adequate. The discriptions should be the same as in IBIS Version 3.2 (except with modifications appropriate for the Connector File). Some new number of line limits may be practical, but would require new checks in an area where we really do not have practical problems. The [Copyright] limit of 4 lines is not realistic. Many files have full Copyright statements with many paragraphs. 4. The [File Name] lengths should be consistent with IBIS Version 3.2. (either 20.3 or 20.7 if .ibiscnn is used). The reason is that in the future the file name may be one entry in the column of another keyword - e.g., [Reference Designator Map] in an EBD. 5. The [File Rev] rules can be adapted for connector recommending 0.x and 1.x as given. 6. The [Manufacturer] keyword should be positioned under the [Begin Cn Model Family] description keyword, consistent with usage in IBIS Version 3.2 positioning. 7. I recommend eliminating the [Web Site], [Email] and [Redistribution] keywords at this time the following reasons: - Not consistent with IBIS Version 3.2 files - they are NOT a common keywords. - The information can be easily handled within the [Source], [Notes] and [Copyright] keywords - The removal will simpify the parser and document - With Company mergers, acquitions, name changes, etc. these keywords may contain out of date information. - The only legal terms should be [Disclaimer] and [Copyright]. Business conditions implied by the [Redistribution] keyword are typically spelled out in detail in the [Copyright] keyword or do not seem appropriate in a data file. Only the [Copyright] keyword is "required" by IBIS to be in "derivative" models; the others are recommended. CONNECTOR ELECTRICAL SPECIFICATION In general, I would simply the syntax to remove some of the keywords to be consistent with IBIS. I would recommend per the general comment above to simplify the keyword names. 1. The [Begin ..] [End ..] is an unnecessary complexity for some of the keywords. I would use [Begin ..] [End ..] (or some variation) consistent with the for just the major groupings, not Description lines. It is common and well understood for a new keyword to terminate a list or table. I would position [Manufacturer], and "[Family Description]" and [Model List] directly under [Begin Cn Model Family] keyword. I would position a single keyword [Description] under each [Begin Cn Model] keyword. 2. In terms of organization, the keywords grouped under [Begin Cn Model] should be described next. Then the keywords outside of this grouping should be described: [Begnin Cn Pin Map], [Begin Cn Phy Map] and [Begin Cn Section]. 3. [Row] under [Begin_Cn_Phy_Map] should be renamed since the meaning of [Row] is inconsistent with its usage under the [.. Matrix] keywords. This is a reference to a physical row, not a matrix row. 4. In IBIS Version 3.2, [Row] uses the pin names whereas which can be alpha-numeric characters. [Row] and other matrix entries are limited to sequential indices. This is noted. Some comment might be added to emphasize there is a difference. 5. The "subparameters" in IBIS Version 3.2 for Full_matrix, Sparse_matrix, Banded_matrix and the new Diagonal_matrix are documented both as keywords and subparameters in the Connector Specification. From owner-ibis Mon Jan 10 15:48:00 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA28522; Mon, 10 Jan 2000 15:47:59 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA02957; Mon, 10 Jan 2000 15:46:32 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA01803; Mon, 10 Jan 2000 15:46:31 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <387A6F57.B72F5851@mentor.com> Date: Mon, 10 Jan 2000 15:46:31 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: kraahemifar@interactiv.com CC: ibis-users@eda.org, ibis@eda.org Subject: Re: A question - IBIS Simulation References: <0001109475.AA947514667@interactiv.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kaamran: Here are a few links to uploaded documents that deal with some simulation algorithms. Other information may be available from vendors directly. Best Regards, Bob Ross Mentor Graphics Papers: http://www.sigrity.com/papers/ectc96/DOectc96ibis.htm http://www.ntu.edu.sg/home/ehntan/glsvlsi.zip Presentations: http://www.eda.org/pub/ibis/summits/feb99/unger.zip http://www.eda.org/pub/ibis/summits/feb98/unger.zip kraahemifar@interactiv.com wrote: > > Hello Sir: > > I understand why IBIS models are needed. However, I am still trying to > understand how the simulation of IBIS models are performed. One way of doing it > is to convert IBIS models to structural models and use SPICE on them. I am > interested to see documents on the simulation of IBIS components. > > Thanks a lot for your care and response. > > Best Regards, > > Kaamran From owner-ibis Mon Jan 10 23:07:20 2000 Received: from oliver.al.dynip.com (root@209-63-189-43.sea.jps.net [209.63.189.43]) by server.eda.org (8.8.5/8.8.3) with ESMTP id XAA29784 for ; Mon, 10 Jan 2000 23:07:18 -0800 (PST) Received: from localhost (localhost [[UNIX: localhost]]) by oliver.al.dynip.com (8.9.3/8.8.7) id WAA24994; Mon, 10 Jan 2000 22:11:18 -0800 From: Al Davis To: Bob Ross , ibis@eda.org Subject: Re: IBIS Connector Specification Editorial Review Date: Mon, 10 Jan 2000 21:41:57 -0800 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: <387A5C06.3CA5C8EB@mentor.com> MIME-Version: 1.0 Message-Id: <0001102211180B.01165@oliver.al.dynip.com> Content-Transfer-Encoding: 8bit Regarding the header section .... I agree that the header section should be EXACTLY the same as the other IBIS files (which should be EXACTLY the same as each other), but there are some good points here, that probably should make their way to all IBIS files. There should be a document describing the header section, that others should reference, not repeat. Basic syntax rules should also be consistent, and stated only once in a document that applys to all IBIS family files. (max lengths, case sensitivity, basic form, optional parameters, how scoping is specified, ...) In general, I think the committee should not legislate aesthetics. The existing IBIS standard goes way too far at legislating aesthetics. Now, I take issue with Bob's comment ...... > 7. I recommend eliminating the [Web Site], [Email] and [Redistribution] > keywords at this time the following reasons: > - Not consistent with IBIS Version 3.2 files - they are NOT a common > keywords. > - The information can be easily handled within the [Source], [Notes] and > [Copyright] keywords > - The removal will simpify the parser and document > - With Company mergers, acquitions, name changes, etc. these keywords > may contain out of date information. > - The only legal terms should be [Disclaimer] and [Copyright]. Business > conditions implied by the [Redistribution] keyword are typically > spelled out in detail in the [Copyright] keyword or do not seem > appropriate in a data file. Only the [Copyright] keyword is "required" > by IBIS to be in "derivative" models; the others are recommended. In this case, I believe that the new fields should be added. The old ones Disclaimer and Copyright are not really necessary because they could be in a general comment. Actually, one could say that the whole header could just be a comment. The only reasons not to do this are 1. to make sure the info is not omitted, and 2. to assist in automation in processing libraries. The new ones [Web Site], [Email] and [Redistribution] really do serve a purpose, and should be there in a specific form. One reason is that some simulator vendors supply a library of models with the simulator. This is a great convenience to the customers, but can be a big headache to maintain. With these fields as suggested here, the process can be more automated. Without them, it is necessary to manually process every file. Therefore, I recommend that they be added to other IBIS files, too. The tree diagram (posted by Bob Ross) should be incorporated as official. (Same goes for the other IBIS files.) From owner-ibis Tue Jan 11 17:12:12 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA05824; Tue, 11 Jan 2000 17:12:12 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA20299; Tue, 11 Jan 2000 17:10:46 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA04985; Tue, 11 Jan 2000 17:10:44 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <387BD495.1DEFCD07@mentor.com> Date: Tue, 11 Jan 2000 17:10:45 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: [Fwd: Complimentary Exhibits and Demo Pass for DesignCon 2000] Content-Type: multipart/mixed; boundary="------------0ADE42D1FF363E6488ED8949" This is a multi-part message in MIME format. --------------0ADE42D1FF363E6488ED8949 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: This is for people on the IBIS lists who want to just visit the exhibits for free. Note the Exhibit dates should be Tuesday, February 1 and Wednesday, February 2, 2000. Bob Ross Mentor Graphics --------------0ADE42D1FF363E6488ED8949 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline >Received: from relay1.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id IAA13129; Tue, 11 Jan 2000 08:35:44 -0800 (PST) From: kfields@iec.org Received: from relay1.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id IAA13129; Tue, 11 Jan 2000 08:35:44 -0800 (PST) Received: from iec.org by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA28696; Tue, 11 Jan 2000 08:35:42 -0800 (PST) To: bob_ross Subject: Complimentary Exhibits and Demo Pass for DesignCon 2000 Date: Tue, 11 Jan 2000 10:37:31 Message-Id: <677.403836.893631@iec.org> Reply-To: kfields@iec.org Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Mozilla-Status2: 00000000

Complimentary Exhibits and Demonstrations Pass for DesignCon 2000

 

Thank you for exhibiting at DesignCon 2000, we are looking forward to successful program!  As part of our ongoing attendee promotions, we are providing you with this electronic exhibits pass to share with your customers and electronic databases for the design-engineering community.  Please share this information with your team, and pass along via email to your constituents.  Should you have any questions, please contact David Erickson via email at derickson@iec.org

 

 

DesignCon, invites you to experience the design-engineering industry's premier conference and exhibition. This electronic exhibits pass provides you with access to DesignCon Demonstrations and Exhibits to be held February 2-3, at the Santa Clara Convention Center, Santa Clara California.

 

Simply Print this e-mail, complete and bring with you to the conference for free exhibits-only registration.  Avoid the On-site charge!   Or complete the fields below and reply to: designcon@iec.org.  This pass is transferable, make multiple copies, or email it to a colleague! 

 

 

 

Exhibit & Demonstration Hours

Tuesday, February 2                             12:30 p.m.-6:30pm

Wednesday, February 3                             12:30 p.m.-6:30pm

 

VISIT DESIGNCON EXHIBITORS ON THE WEB!  www.designcon.com

 

Please fill in the following information to complete your registration

 

Name: _____________________________________________

 

E-mail: _____________________________________________

 

Badge: ____________________________________________

 

Title: ______________________________________________

 

Company: __________________________________________

 

Division: ___________________________________________

 

Address: ___________________________________________

 

__________________________________________________

 

City, State, Zip: _____________________________________

 

__________________________________________________

 

Country: ___________________________________________

 

Office Phone: _______________________________________

 

Office Fax: _________________________________________

 

Return FAX THIS FORM TO: 312-559-4111

 

 

Exhibits

The exhibits at DesignCon 2000 provide attendees with a firsthand look at the latest technologies and solutions available. More than 100 companies will present their technologies and provide all of the solutions you need.

 

Here are just some of the products you will find at the DesignCon exhibits and demonstrations:

 

Applications Engineering

ASICs Components

Computer Software and Peripherals

Design Automation Tools

EDA/CAE Tools

FPGAs

Interconnection Devices

Packaging

PLDs

Semiconductors

Standard, Analog, Mixed-Signal, Digital, and Memory ICs

System Boards

Test, Measurement, and Debug Tools

 

 

Interested in the DesignCon Sessions?  You can view or download the entire conference catalog at www.designcon.com/catalog.pdf   Experience the DesignCon difference! 

--------------0ADE42D1FF363E6488ED8949-- From owner-ibis Tue Jan 11 17:41:27 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA05915 for ; Tue, 11 Jan 2000 17:41:26 -0800 (PST) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id RAA26342; Tue, 11 Jan 2000 17:40:30 -0800 (PST) Message-Id: <200001120140.RAA26342@pop.nwlink.com> Received: from KELLEE98 by ip210.c246.blk1.bel.nwlink.com via smtpd (for mail.nwlink.com [209.20.130.40]) with SMTP; 12 Jan 2000 01:41:53 UT X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 11 Jan 2000 17:40:30 -0800 To: Bob Ross , ibis@eda.org From: Kellee Crisafulli Subject: Re: IBIS Connector Specification Editorial Review In-Reply-To: <387A5C06.3CA5C8EB@mentor.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 RAA05916 Hi all, I have added the keyword tree table (Thanks to help from Bob Ross). The keyword table is located at the top of the specification. I have also nearly completed adding "usage" rules for every keyword as requested by Arpad. I am planning to upload the updated V0.93 specification by Wednesday late. It should be available for review all day Thursday prior to the Friday meeting. If possible I would still like to put it up for a vote at Design Con. As I recall we cannot make any changes for two weeks prior to a final vote and it will still meet that requirement. best wishes.. Kellee --------------------------------------------------------- Have a great day.... Kellee Crisafulli HyperLynx, a division of Pads Software Inc. SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Wed Jan 12 06:20:05 2000 Received: from soran.bos.ascend.com (soran.bos.ascend.com [152.148.40.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA09424 for ; Wed, 12 Jan 2000 06:20:03 -0800 (PST) Received: from rawhide.bos.ascend.com (rawhide [152.148.140.32]) by soran.bos.ascend.com (8.9.3/8.9.3) with ESMTP id JAA17893 for ; Wed, 12 Jan 2000 09:17:19 -0500 (EST) Received: from fox.bos.ascend.com (fox.bos.ascend.com [152.148.141.238]) by rawhide.bos.ascend.com (8.8.8+Sun/8.8.4) with ESMTP id JAA15036 for ; Wed, 12 Jan 2000 09:18:24 -0500 (EST) Received: by fox.bos.ascend.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jan 2000 09:18:10 -0500 Message-ID: From: "Peregrim, Lawrence" To: "'ibis@eda.org'" Subject: unsubscribe Date: Wed, 12 Jan 2000 09:18:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" unsubscribe From owner-ibis Wed Jan 12 09:03:51 2000 Received: from osiris.vlsi.com (relayhost.vlsi.com [63.194.140.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA10265; Wed, 12 Jan 2000 09:03:50 -0800 (PST) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id JAA21784; Wed, 12 Jan 2000 09:02:52 -0800 (PST) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris via smap (V2.0) id xma021772; Wed, 12 Jan 00 09:02:40 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CMAW7VWA; Wed, 12 Jan 2000 10:02:39 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <387CB3AF.7B6BFC@vlsi.com> Date: Wed, 12 Jan 2000 10:02:39 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: Re: [Fwd: Complimentary Exhibits and Demo Pass for DesignCon 2000] References: <387BD495.1DEFCD07@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just a reminder: if you don't like spam, use a throwaway e-mail address. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Wed Jan 12 10:19:57 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA10482 for ; Wed, 12 Jan 2000 10:19:56 -0800 (PST) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id KAA05208 for ; Wed, 12 Jan 2000 10:19:00 -0800 (PST) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for pop.nwlink.com [209.20.130.39]) with SMTP; 12 Jan 2000 18:20:23 UT Received: from hlgw.hyperlynx.com ([192.168.148.149]) by hazard.hyperlynx.com (8.9.3/8.9.3) with SMTP id LAA04835 for ; Wed, 12 Jan 2000 11:24:37 -0800 Message-ID: <009901bf5d29$92f11a60$9594a8c0@hyperlynx.com> From: "Matthew Flora" To: Received: from SQUIDGE by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 12 Jan 2000 18:20:22 UT References: <387A5C06.3CA5C8EB@mentor.com> Subject: Re: IBIS Connector Specification Editorial Review Date: Wed, 12 Jan 2000 10:19:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Dear Bob, > 1. I would prefer keywords with 3 or less individual words since > both the IBIS and Connector keywords allow both the underscore "_" > and space characters as separators. This keeps the variations that > need to be stored to 8 or less. One suggestion is to eliminate > "Cn_" in many of the keywords. This really is just a matter of preference. The parser actually scans each keyword candidate and converts all the spaces to underscores before converting the keyword candidate to uppercase. The resulting keyword candidate string is then compared to the list of keywords. So, there really is only one keyword lookup for each candidate. (In other words, only one variation of each keyword is stored.) > GENERAL SYNTAX RULES AND GUIDELINES SECTION: > > 1. Item 2) adds reserved word PWRGND. This is unnecessary since > POWER can be used to include GND. Also RET is not referenced > anywhere else in the document. I do not think it is necessary. I would recommend against using POWER to mean both ideal-ground and non-ground (ideal or otherwise) else this use of the POWER keyword would be a special case that differs from the usage in IBIS [Component] and EBD pin lists. > CONNECTOR ELECTRICAL SPECIFICATION > > 1. The [Begin ..] [End ..] is an unnecessary complexity for some of > the keywords. I would use [Begin ..] [End ..] (or some variation) > consistent with the for just the major groupings, not Description > lines. It is common and well understood for a new keyword to terminate > a list or table. One of the complaints about the IBIS spec is that it has some inconsistencies. Using [Begin ..] [End ..] consistently for all keywords seems appropriate. My two cents, Matthew Flora From owner-ibis Wed Jan 12 12:55:34 2000 Received: from tekincisnts-4.teklogix.com (mail.teklogix.com [207.219.2.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA11125 for ; Wed, 12 Jan 2000 12:55:32 -0800 (PST) Received: by tekincisnts-4 with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 15:54:05 -0500 Message-ID: From: Larry Forsythe To: "'ibis@eda.org'" Subject: unsubscribe Date: Wed, 12 Jan 2000 15:54:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain unsubscribe From owner-ibis Wed Jan 12 17:11:56 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA12120 for ; Wed, 12 Jan 2000 17:11:55 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA25052; Wed, 12 Jan 2000 17:10:31 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA11939; Wed, 12 Jan 2000 17:10:29 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <387D2604.24945D40@mentor.com> Date: Wed, 12 Jan 2000 17:10:28 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Connector Specification Technical Comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee: Thank you for the comments and responses to the editorial review. Some of the points will be discussion items at the next meeting. One main purpose is to get concensus on the content. Differences should be highlighted, rather than slipped in unnoticed. Then a deliberate decision by the group should be made with respect to the features. Our goal is to stablize the document and syntax to a sufficient extent to initiate a parser development project. Bob Ross Mentor Graphics This is the beginning of a technical review. I expect to do more techical review later. 1. [Begin_Cn_Model_Family] Should there be a family_name? I do not see any reason why we need to limit this to one family per file. While in practice this might be the case for Connector suppliers, this might not be convenient for designers who want to store or export models of all connectors in a design into a single file. 2. [Begin_Cn_Model_List] Regarding "Max_Slew_Time", do you really mean max slew rate and "Min_Slew_Time"? While the Connector Committee debated this point, I am wondering if the image files could just be "recommended" as .jpg or .txt formats. The statement "may be either" must be changed to "must be either" or else "is recommended to be either". New formats might emerge. 3. [Begin_Cn_Model] Does the optional SNR need to be restricted to SLM? Could the format be generalized to "a:b" such as for 5:2. Are the numbers restricted to integers? Is there a need for a limit (e.g. 100:1.) I would prefer a syntax of the form: "[Begin_Cn_Model] ModelName" and then have the other entries as subparameters. We already have a conflict with having the "required" ModelPinMap and ModelPhyMap entries that would not be used if [Begin_Cn_Auto_Map] is used. Also, the single name argument is more consistent with all the IBIS keywords for named sections (e.g., [Component], [Model], [Define Package Model], [Begin Board Description], [Submodel]). Can the syntax: "Cn_Section SectionA SectionB SectionC .. " be supported in a manner parallel to "Cn_Stub Stub1 Stub2 ..." that is also a series connection of stubs? 4. Item 12) in syntax rules and [Cn_Number_of_Conductors] Is there a need to limit the size of the conductors to 100000. I would just let real designs decide the limit? There is no tecnical reason why more than 100000 conductors can be supported. I do not have a alternative proposal, but I would like to avoid multi- choice arguments. The argument for this keyword is either a positive integer or a range, e.g, "9 to 25". Is 9to25 allowed? 9 TO 25?, 25 to 9?, etc. All of these would need to be tested. The same comment applies for [Cn_Columns_of_Pins] integer or VARIABLE (uppercase only). The syntax is inconsistent with [Cn_Rows_of_Pins] which does not allow VARIABLE. While there is no technical limit, there does not seem to be the need to introduce a new data type for each keyword. It seems that this range and "variable" choice information is best positioned in the [Begin_Cn_Auto_Map] keyword or in some manner that is self-checking. 5. [Begin_Cn_Auto_Map]. The equation methodology for Index, Pin and Signal seems powerful. However, there seems to be an opportunity to make a mistake and create indicies that repeat, if improper equations are entered. We need to review this further since there is an interaction with fixed equations and some of the numerical choices that could be entered (e.g, if [Cn_Rows_of_Pins] were change from 2 to 3 in the first example. Also, it is not clear that a specific entry would be passed into the model for the "VARIABLE" in order to produce the specific connector of interest. The parameter passing mechanism needs to be better defined than just a "VARIABLE" where critical information regarding the acceptable values of VARIABLE are buried within the model itself. The autogeneration syntax seems to be well thought out, but still needs review. From owner-ibis Wed Jan 12 23:04:29 2000 Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by server.eda.org (8.8.5/8.8.3) with ESMTP id XAA13061 for ; Wed, 12 Jan 2000 23:04:28 -0800 (PST) Received: from earthlink.net (ip9.san-francisco56.ca.pub-ip.psi.net [38.28.103.9]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id XAA06443 for ; Wed, 12 Jan 2000 23:03:31 -0800 (PST) Message-ID: <387D7953.454C0BB8@earthlink.net> Date: Wed, 12 Jan 2000 23:05:55 -0800 From: Bruce Wenniger X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Please Remove me from Your Email Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From owner-ibis Wed Jan 12 23:25:56 2000 Received: from nt40.zh.t2-design.com (ts.zhuhai.gd.cn [202.96.178.2]) by server.eda.org (8.8.5/8.8.3) with ESMTP id XAA13186 for ; Wed, 12 Jan 2000 23:25:46 -0800 (PST) Received: from DRACO by nt40.zh.t2-design.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id C6H0KD2N; Thu, 13 Jan 2000 15:26:21 +0800 Date: Fri, 13 Mar 1998 15:24:41 -0800 From: "Zhao.Cong" X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: "Zhao.Cong" X-Priority: 3 (Normal) Message-ID: <11642.980313@zh.t2-design.com> To: ibis@eda.org Subject: Please Remove me from Your Email Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello ibis, Please Remove me from Your Email Mailing List Best regards, Zhao.Cong mailto:bob@zh.t2-design.com From owner-ibis Thu Jan 13 04:24:20 2000 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA15515 for ; Thu, 13 Jan 2000 04:24:19 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id GAA29705 for ; Thu, 13 Jan 2000 06:23:21 -0600 (CST) Received: from unknown(150.150.15.100) by molexinc-bh.molex.com via smap (4.1) id xma029665; Thu, 13 Jan 00 06:22:25 -0600 Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 0002E65E; Thu, 13 Jan 2000 06:25:38 -0600 Mime-Version: 1.0 Date: Thu, 13 Jan 2000 06:14:09 -0600 Message-ID: <0002E65E.C21030@molex.com> Subject: [Begin_Cn_Model_Family] To: ibis@eda.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part As stated... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. [Begin_Cn_Model_Family] Should there be a family_name? I do not see any reason why we need to limit this to one family per file. While in practice this might be the case for Connector suppliers, this might not be convenient for designers who want to store or export models of all connectors in a design into a single file. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From a file usage / size point of view... * It is very possible that a Cascaded model as outlined in the specification will result in a model file that is very large. Some of the simple examples for a single family that I created already exceed 20kB. I believe that this could develop into serious issues with regards to file parsing and maintenance. From a model suppliers point of view...... * I need a way to tie part revision and model revision levels. * I need to be able to update models... and make sure that the customer also is using the most up to date version. If the models get stacked into a single "library"... then the designer will need to adjust that library when a new model is released. Won't this cause more work for the designer? Maybe lead to copy/paste errors? * It is convenient to name connector sections with the same name.... so whether you have an edgecard connector or a pin/socket connector... it is handy to be able to use SMT, through_hole, press_fit sections for both. As such, I think that one Connector family per model is required. _gus apanella@molex.com From owner-ibis Thu Jan 13 05:23:50 2000 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA15771 for ; Thu, 13 Jan 2000 05:23:49 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id HAA05180 for ; Thu, 13 Jan 2000 07:22:50 -0600 (CST) Received: from unknown(150.150.15.100) by molexinc-bh.molex.com via smap (4.1) id xma005064; Thu, 13 Jan 00 07:22:07 -0600 Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 0002E956; Thu, 13 Jan 2000 07:25:19 -0600 Mime-Version: 1.0 Date: Thu, 13 Jan 2000 07:16:48 -0600 Message-ID: <0002E956.C21030@molex.com> Subject: Image files To: ibis@eda.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part As stated: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ While the Connector Committee debated this point, I am wondering if the image files could just be "recommended" as .jpg or .txt formats. The statement "may be either" must be changed to "must be either" or else "is recommended to be either". New formats might emerge. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From a model suppliers perspective.... I think that this is OK. However, would that potentially make it real difficult for the simulator vendors? The simulator vendor will then need to support many different type.... what ever type the model supplier wants to supply. I am not sure that this is fair....??? _gus apanella@molex.com 630-527-4617 r, DOES NOT relieve the specification from being incomplete or confusing or inconsistent. I would like to think that since the swath is such a new concept, that extra extra extra extra care is need when reviewing the swath related keywords... I think initially some things may seem inconsistent.. but in reality.. in the fine print... do at least attempt to cover the bases. SIDE NOTE: To me the "casual end user" should NOT need to worry about the details of this model. That should be the responsibility of the people making the models. As such, the casual end user probably should not adjust the model as supplied from the manufacturer. (i.e. add a swath where one was not provided... this could be VERY dangerous if you do not know how the model was created!!!) If there is something wrong with the models implementation... shame on the model creator. Being a model creator, I should be the one to blame and should fix it ASAP!! ---- See you at DesignConn... By the way, some presentation time was set aside for the IBIS Connector Specification Presentation. If you would like, send me an email with what you would like to know more about with regards to IBISCnn... and I could try to incorporate some slides into the presentation. _gus apanella@molex.com 630-527-4617 From owner-ibis Thu Jan 13 05:23:49 2000 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA15767 for ; Thu, 13 Jan 2000 05:23:48 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id HAA05166 for ; Thu, 13 Jan 2000 07:22:50 -0600 (CST) Received: from unknown(150.150.15.100) by molexinc-bh.molex.com via smap (4.1) id xma005055; Thu, 13 Jan 00 07:22:04 -0600 Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 0002E955; Thu, 13 Jan 2000 07:25:17 -0600 Mime-Version: 1.0 Date: Thu, 13 Jan 2000 07:16:34 -0600 Message-ID: <0002E955.C21030@molex.com> Subject: 3. [Begin_Cn_Model]... and other issues... To: ibis@eda.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part As stated.... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3. [Begin_Cn_Model] Does the optional SNR need to be restricted to SLM? Could the format be generalized to "a:b" such as for 5:2. Are the numbers restricted to integers? Is there a need for a limit (e.g. 100:1.) I would prefer a syntax of the form: "[Begin_Cn_Model] ModelName" and then have the other entries as subparameters. We already have a conflict with having the "required" ModelPinMap and ModelPhyMap entries that would not be used if [Begin_Cn_Auto_Map] is used. Also, the single name argument is more consistent with all the IBIS keywords for named sections (e.g., [Component], [Model], [Define Package Model], [Begin Board Description], [Submodel]). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SNR... Do you mean SGR? Assuming yes... No, it doesn't need to be limited to SLMs..... but, from a technical standpoint... why worry about pin to pin coupling when the return path effects have been removed? I am sure that people do this all the time.... but I am also sure that it will lead to incorrect system analysis. I would really prefer if this spec draws the line between models that represent return path effects and models that do not in the SLM / MLM differentiation. I really believe that not doing this will result in greater end user confusion in the long run. [SoapBox_on] For signal Integrity issues, we need to have a point where return path effects are KNOWN accounted for in a simulation. I propose that this be done in the differentiation between SLM and MLM I guess this assumes that the simulator (unknown to the user) or user does not put perfect ground nodes on both sides of the connector) [SoapBox_off] Line Parameters / sub parameters... To me this is a formatting issue... So what ever I do not believe there is really a conflict with the mapping... "Automap" is required for swath.... but although a model can be swathed ... it isn't required for it to be used as a swath... As such, a model that is supplied could have both "fixed mapping" and automapping. Fixed mapping is required for all models... while automapping is ONLY to be used as an optional enhancement to the "fixed map" model. Also, swathing is option for the following reasons * Model makers may not be comfortable with the concept. Therefore, the model maker would not want to include the option * Some models CAN NOT be swathed Reasons to REQUIRE a fixed map... * All the above plus... * Maybe a simulator vendor will not want to support the swath for technical implementation reasons. * A fixed map is a "Least Common Denominator? _gus apanella@molex.com 630-527-4617 From owner-ibis Thu Jan 13 05:23:48 2000 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA15762 for ; Thu, 13 Jan 2000 05:23:47 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id HAA05162 for ; Thu, 13 Jan 2000 07:22:49 -0600 (CST) Received: from unknown(150.150.15.100) by molexinc-bh.molex.com via smap (4.1) id xma005050; Thu, 13 Jan 00 07:22:01 -0600 Received: from ccMail by smtp1.molex.com (IMA Internet Exchange 3.12) id 0002E953; Thu, 13 Jan 2000 07:25:14 -0600 Mime-Version: 1.0 Date: Thu, 13 Jan 2000 07:15:03 -0600 Message-ID: <0002E953.C21030@molex.com> Subject: 5. [Begin_Cn_Auto_Map]...... To: ibis@eda.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part As Stated... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5. [Begin_Cn_Auto_Map]. The equation methodology for Index, Pin and Signal seems powerful. However, there seems to be an opportunity to make a mistake and create indicies that repeat, if improper equations are entered. We need to review this further since there is an interaction with fixed equations and some of the numerical choices that could be entered (e.g, if [Cn_Rows_of_Pins] were change from 2 to 3 in the first example. Also, it is not clear that a specific entry would be passed into the model for the "VARIABLE" in order to produce the specific connector of interest. The parameter passing mechanism needs to be better defined than just a "VARIABLE" where critical information regarding the acceptable values of VARIABLE are buried within the model itself. The autogeneration syntax seems to be well thought out, but still needs review. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As points of reference... the "auto" and "variable" were installed to make the "swath operator" a viable solution. And... we wanted any model to be able to... ..stand alone ... or be swathed... or both We knew that swath model creation will not be easy. Further, incorporating the swath into a written specification would be difficult to do and understand. But, I think the potential benefits are large. _gus apanella@molex.com 630-527-4617 From owner-ibis Thu Jan 13 06:40:03 2000 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA16034 for ; Thu, 13 Jan 2000 06:40:02 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id HAA00387 for ; Thu, 13 Jan 2000 07:39:05 -0700 (MST)] Received: [from zuk28exb01.ecid.cig.mot.com (zuk28exb01.ecid.cig.mot.com [175.12.130.200]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA18591 for ; Thu, 13 Jan 2000 07:39:04 -0700 (MST)] Received: by zuk28exb01.ecid.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Thu, 13 Jan 2000 14:39:03 -0000 Message-ID: From: Royle Colin-QSWI1123 To: "'ibis@eda.org'" Subject: unsubscribe Date: Thu, 13 Jan 2000 14:39:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" unsubscribe From owner-ibis Thu Jan 13 07:23:20 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA16180 for ; Thu, 13 Jan 2000 07:23:19 -0800 (PST) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id HAA25906 for ; Thu, 13 Jan 2000 07:22:20 -0800 (PST) Received: from cadence.com (d158140105198 [158.140.105.198]) by zip.Cadence.COM (8.8.8/8.8.5) with ESMTP id KAA29581 for ; Thu, 13 Jan 2000 10:21:45 -0500 (EST) Message-ID: <387DED8A.6A66CE3D@cadence.com> Date: Thu, 13 Jan 2000 10:21:46 -0500 From: Mike LaBonte Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: Image files References: <0002E956.C21030@molex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as HAA25906 at Thu Jan 13 07:22:20 2000 Possibly the guideline for image formats could be to limit them to the formats supported by commonly available web browsers. The list for Netscape, for example, is: GIF (Graphics Interchange Format) JPEG (Joint Photographic Experts Group) XPM (X PixMap) XBM (X BitMap) And of course web browsers can display text, too. Taking this one step further, could we have a reference to an HTML file instead of just an image file name? The URL could point to local files, or to elsewhere on the web. I guess I am leaning in the direction of using web pages to show information that is not intended for machine parsing. Although an image file *could* be displayed in my own tool, I think I would settle for a "View data sheet" button. Mike apanella@molex.com wrote: > > As stated: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > While the Connector Committee debated this point, I am wondering > if the image files could just be "recommended" as .jpg or .txt formats. > The statement "may be either" must be changed to "must be either" > or else "is recommended to be either". New formats might emerge. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >From a model suppliers perspective.... I think that this is OK. However, > would that potentially make it real difficult for the simulator vendors? The > simulator vendor will then need to support many different type.... what ever > type the model supplier wants to supply. I am not sure that this is fair....??? > > _gus > apanella@molex.com > 630-527-4617 From owner-ibis Thu Jan 13 07:34:48 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA16248 for ; Thu, 13 Jan 2000 07:34:47 -0800 (PST) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id HAA27090 for ; Thu, 13 Jan 2000 07:33:50 -0800 (PST) Received: from cadence.com (d158140105198 [158.140.105.198]) by zip.Cadence.COM (8.8.8/8.8.5) with ESMTP id KAA29845 for ; Thu, 13 Jan 2000 10:33:49 -0500 (EST) Message-ID: <387DF05D.D662A58@cadence.com> Date: Thu, 13 Jan 2000 10:33:49 -0500 From: Mike LaBonte Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: 4. Item 12) in syntax rules.... inconsistencies?? References: <0002E954.C21030@molex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as HAA27090 at Thu Jan 13 07:33:50 2000 Reasons for having limits: 1) Tool vendors can stress test the tools for certain compliance with the specification. 2) It becomes easier to state how much memory is required to use the tool, given compliant files. That said, a reasonable limit is usually a value that seems ridiculously high at the time. For example, no PC will ever need more than 640KB of memory, right? Mike apanella@molex.com wrote: > > As stated.. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 4. Item 12) in syntax rules and [Cn_Number_of_Conductors] > Is there a need to limit the size of the conductors to 100000. I would > just let real designs decide the limit? There is no technical > reason why more than 100000 conductors can be supported. > > I do not have a alternative proposal, but I would like to avoid multi- > choice arguments. The argument for this keyword is either a positive > integer or a range, e.g, "9 to 25". Is 9to25 allowed? 9 TO 25?, > 25 to 9?, etc. All of these would need to be tested. > > The same comment applies for [Cn_Columns_of_Pins] integer or VARIABLE > (uppercase only). The syntax is inconsistent with [Cn_Rows_of_Pins] > which does not allow VARIABLE. While there is no technical limit, > there does not seem to be the need to introduce a new data type for > each keyword. It seems that this range and "variable" choice > information is best positioned in the [Begin_Cn_Auto_Map] keyword or > in some manner that is self-checking. > ~~~~~~~~~~~~~~~~~~~~~ > > There are descriptor words that describe the model as simulated through out the > document. > > There are also descriptor words that are used to enable the swath operator. > > I think this is the point of confusion. > > I think that there is documentation to try to separate these descriptors... > Does it need to be more clear?? > > _gus > apanella@molex.com > 630-527-4617 From owner-ibis Thu Jan 13 08:04:15 2000 Received: from osiris.vlsi.com (relayhost.vlsi.com [63.194.140.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA16832 for ; Thu, 13 Jan 2000 08:04:14 -0800 (PST) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id IAA12928 for ; Thu, 13 Jan 2000 08:03:16 -0800 (PST) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris via smap (V2.0) id xma012918; Thu, 13 Jan 00 08:03:09 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CMAW7WPS; Thu, 13 Jan 2000 09:03:09 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <387DF73C.7458BDFD@vlsi.com> Date: Thu, 13 Jan 2000 09:03:08 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IBIS Mailing list Subject: Re: Image files Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit apanella@molex.com wrote: > > As stated: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > While the Connector Committee debated this point, I am wondering > if the image files could just be "recommended" as .jpg or .txt formats. > The statement "may be either" must be changed to "must be either" > or else "is recommended to be either". New formats might emerge. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >From a model suppliers perspective.... I think that this is OK. However, > would that potentially make it real difficult for the simulator vendors? The > simulator vendor will then need to support many different type.... what ever > type the model supplier wants to supply. I am not sure that this is fair....??? The way this is handled in other contexts (e.g., MIME for HTML mail) is that there is (are) one or two default formats that ALL tools must support, and alternates which may or may not be supported. Files are allowed to include multiple redundant content, with the tool using the richer form if supported and otherwise falling back on the default. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Thu Jan 13 08:15:34 2000 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA17113 for ; Thu, 13 Jan 2000 08:15:33 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id JAA01224; Thu, 13 Jan 2000 09:14:35 -0700 (MST)] Received: [from emailsps.sps.mot.com (emailsps.sps.mot.com [216.8.10.1]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA02174; Thu, 13 Jan 2000 09:14:34 -0700 (MST)] Received: from [222.161.249.191] by omni.sps.mot.com (4.1/SMI-4.1) id AA08990; Thu, 13 Jan 00 10:16:11 CST Message-Id: <387DFD03.CBE38E0@omni.sps.mot.com> Date: Thu, 13 Jan 2000 10:27:47 -0600 From: Dennis Goodrich Organization: Motorola Semiconductor Products Sector X-Mailer: Mozilla 4.06 [en]C-MOTSPS405U (WinNT; I) Mime-Version: 1.0 To: "D. C. Sessions" Cc: IBIS Mailing list , Dennis Goodrich Subject: Re: Re: Image files References: <387DF73C.7458BDFD@vlsi.com> 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 IAA17114 If we could specify the DXF 2D/3D format, most of the FEA SW tools would be able to import the drawings and dimensions for conversion to electrical analysis.. Most of the connector suppliers can make this format readily (painlessly) available.. Just a suggestion from a guy who has to fall back to SPICE once and a while. Dennis Goodrich D. C. Sessions wrote: > apanella@molex.com wrote: > > > > As stated: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > While the Connector Committee debated this point, I am wondering > > if the image files could just be "recommended" as .jpg or .txt formats. > > The statement "may be either" must be changed to "must be either" > > or else "is recommended to be either". New formats might emerge. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > >From a model suppliers perspective.... I think that this is OK. However, > > would that potentially make it real difficult for the simulator vendors? The > > simulator vendor will then need to support many different type.... what ever > > type the model supplier wants to supply. I am not sure that this is fair....??? > > The way this is handled in other contexts (e.g., MIME for HTML mail) is > that there is (are) one or two default formats that ALL tools must support, > and alternates which may or may not be supported. Files are allowed to > include multiple redundant content, with the tool using the richer form if > supported and otherwise falling back on the default. > > -- > D. C. Sessions > dc.sessions@vlsi.com -- ˙ūD From owner-ibis Thu Jan 13 09:27:25 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA17634 for ; Thu, 13 Jan 2000 09:27:25 -0800 (PST) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id JAA09606; Thu, 13 Jan 2000 09:26:27 -0800 (PST) Message-Id: <200001131726.JAA09606@pop.nwlink.com> Received: from KELLEE98 by ip210.c246.blk1.bel.nwlink.com via smtpd (for mail.nwlink.com [209.20.130.40]) with SMTP; 13 Jan 2000 17:27:49 UT X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 13 Jan 2000 09:26:22 -0800 To: Bob Ross , ibis@eda.org From: Kellee Crisafulli Subject: Re: IBIS Connector Specification Editorial Review In-Reply-To: <387A5C06.3CA5C8EB@mentor.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 JAA17635 To IBIS Committee: I have made several more changes to the specification: 1) Added a table of contents (copy of the one form IBIS IC specification) 2) Added a General Introduction section (copy of the one form IBIS IC specification) 3) Added a Revision history section 4) Added keyword tree diagram section Also I have responded to Bob's comments below: (Bob wrote) >GENERAL: >1. I would prefer keywords with 3 or less individual words since >both the IBIS and Connector keywords allow both the underscore "_" >and space characters as separators. This keeps the variations that >need to be stored to 8 or less. One suggestion is to eliminate >"Cn_" in many of the keywords. I believe Matt addressed this one, it makes no difference to the parser, there is only one variant the way it is coded. So I feel Cn_ keywords should stay. >2. The existing IBIS extensions are .ibs, .pkg, and .ebd. The new >document proposes .ibiscnn. The practical reason for 3-letter >extensions no longer exists. However, I still would favor .cnn or >some other 3 letter choice because the file name itself may be >a column entry in some new keyword (such as [Reference Designator Map] >in an EBD). .cnn was rejected because so many other tools have already used this extension for something different or connector formats they may already have. As you point out there is no reason to stick with 3 characters any longer (DOS is dead). So I feel we should keep the committee's .ibiscnn extension. >3. The new format sets the line length limit to 120 characters but >restricts comment lines to 80 characters. I would favor keeping the >80 character limitation throughout, but would also accept 120 >characters throughout. Having two limits provides unnecessary >complication in the document and in the parser. The complication to the parser of two line limits is insignificant. I feel the complication to creators of connector models will be minor and the gain is that a standardized display area in CAE tools can be established at 80 characters. This allows a reasonable display size in most windows. The need to got to 120 characters is for readability of the large matricies needed for connectors in many cases. I propose the 120 limit for all lines except comments be upheld for improved readability of matricies. I propose that the 80 character limit for comments be upheld for improved readability of comments when displayed in CAE tools. Since we have hard-coded end of line characters maintaining tabing and alignment without such a limit is very difficult. >GENERAL SYNTAX RULES AND GUIDELINES SECTION: >1. Item 2) adds reserved word PWRGND. This is unnecessary since >POWER can be used to include GND. Also RET is not referenced >anywhere else in the document. I do not think it is necessary. The RET reserved word was specifically requested by several connector companies to more formally indicated that it is not "GROUND". This was very important to several of the sub-committe members. I suggest we keep RET and the PWRGND reserved word to allow additional flexability as desired by the model builders in describing how the model is expected to be used. As this was their desire by including these keywords. I did notice an inconsistant use of the reserve word PWR which I have changed in the specification to POWER. >2. Item 3) in the IBIS Version 3.2 setting file name case and >size limits is omitted. I would add that paragraph. Note, the >information is moved to the [File Name] keyword. More comments >on this are below. >3. Item 3) in the Connector Specification should be replaced by >the text of Item 4) in IBIS Version 3.2 (changed from 80 to 120 >characters, if that is the consensus). I disagree on this one the 120 character limit is needed for matrices and this is too wide for comments that need to be displayed within CAE tools. Therefore I feel the 120/80 limits are justified. >4. Item 5) in the Connector Specification should be replaced >by Item 6) in IBIS Version 3.2 to clarify the keyword syntax. I agree, I made this change and copied item 6 in V3.2 spec. >5. Item 8) in the Connector Specification should be replaced by >the updated Item 10) in IBIS Version 3.2 regarding tab character >usage. The reference to 80 characters could be replaced by >120 characters if 120 is chosen as the line length limit. The existing specification does not accent the potential problem \ with a warning statement as does the new text. I did change the line so it removes the 120 comment and just says it may make the line too long causing a syntax error. That way no matter what we decide for line lengths this paragraph is correct. >6. I recommend deleting Item 11) regarding location of files. >This is out of date. This information might be better located >in a general introduction section. I agree. I changed item 11 as follows: | 11) Important information is contained in the sample files provided | with the specification and these should be refered to as a | starting point for creating new models. >7. Item 13) regarding number of decimal points in a number should >be eliminated. There are probably exceptions on each end. This was discussed extensively by the sub-group. It was noted that since these models will mostly be automatically generated there is no reason not reduced the garbage in the file by limiting the data size within reason. I do feel the 5 digit mantissa suggestion and 15 digit limit are very reasonable. It was noted that many files had been created for which the data was only accurate to 3 digits and 12 or more digits of information was provided. This not only wastes file space on all the computers storing data it is also plain wrong. The number of digits generally indicates the accuracy of a measurement. If 12 digits are shown then that should be the accuracy of the data. Again this is worded as a suggestion only. The actual limit is reasonable considering the double precission limits of unix/IEEE numeric processors which are many times smaller than windows numeric processors. >As an alternative, a general recommendation similar to IBIS Version 3.2 >regarding I-V and V-T data in Item 9) could be added recommending >up to 5 decimal digit accuracy where necessary. I believe the text that is present does just this. I don't see any need to change item 13. >8. Item 14) in IBIS Version 3.2 regarding defining ASCII characters >should be added. I agree, it has been added. >FILE HEADER INFORMATION: > >1. [IBIS_Cn_Model_Ver]: I would change to [Conn Ver] to >(parallel to [IBIS Ver]) to distinuish a Connector file. I would >start with [Conn Ver] 1.0. I would use the same text as the used >for [IBIS Ver] except substituting CONN for IBIS. I disagree. The method we have retains a coupling to the IBIS group. Your proposal looses that coupling. >2. [Comment Char]: I would use the latest IBIS Version 3.2 >description since it lists the permitted versus excluded characters. The existing specification permits characters that would make the specification unusable. For example 0,1,2,3,4,5,6,7,8,9 etc are allowed as comment characters. I did modify this section to include the same list of control characters as the IBIS specification. Also the usage rules have been broken out the same as I am doing for all the keywords. >3. I do not see any reason for creating new rules for the common >IBIS Verison 3.2 keywords [File Name], [File Rev], [Date], [Source], >[Notes], [Disclaimer] and [Copyright]. While IBIS rules may not >be perfect, they are, in practice, quite adequate. The discriptions >should be the same as in IBIS Version 3.2 (except with modifications >appropriate for the Connector File). Some new number of line limits >may be practical, but would require new checks in an area where we >really do not have practical problems. The [Copyright] limit of >4 lines is not realistic. Many files have full Copyright statements >with many paragraphs. The new keywords are parsable meaning that CAE tools can optimize the way in which it displays the information to a user. This was done to improve usability to the end-users and should be added to the V3.2 IBIS IC specification as well. >4. The [File Name] lengths should be consistent with IBIS Version 3.2. >(either 20.3 or 20.7 if .ibiscnn is used). The reason is that in >the future the file name may be one entry in the column of another >keyword - e.g., [Reference Designator Map] in an EBD. If IBIS 3.2 is modified to add support for .ibiscnn it will be easy to add support for the longer extension. Shorter 3 character extensions are no longer being used by many companies as the potential for collisions with extensions is too high. There I suggest .ibiscnn is a keeper. >5. The [File Rev] rules can be adapted for connector recommending >0.x and 1.x as given. I agree, I have changed the section to conform with IBIS standards. >6. The [Manufacturer] keyword should be positioned under the [Begin >Cn Model Family] description keyword, consistent with usage in IBIS >Version 3.2 positioning. I agree. I have moved the [Begin_Cn_Model_Family] above the [Manufacturer] keyword which is better as it also moves the associated keywords [Web_Site], [Email],[Redistribution] to go along with [Manufacturer]. >7. I recommend eliminating the [Web Site], [Email] and [Redistribution] >keywords at this time the following reasons: >- Not consistent with IBIS Version 3.2 files - they are NOT a common > keywords. >- The information can be easily handled within the [Source], [Notes] and > [Copyright] keywords >- The removal will simpify the parser and document >- With Company mergers, acquitions, name changes, etc. these keywords > may contain out of date information. >- The only legal terms should be [Disclaimer] and [Copyright]. Business > conditions implied by the [Redistribution] keyword are typically > spelled out in detail in the [Copyright] keyword or do not seem > appropriate in a data file. Only the [Copyright] keyword is "required" > by IBIS to be in "derivative" models; the others are recommended. I strongly disagree. These are very useful and are parasable. It cannot be handled with source and notes as it is not parasable and cannot be presented easily to users by the CAE tool. >1. The [Begin ..] [End ..] is an unnecessary complexity for some of >the keywords. I would use [Begin ..] [End ..] (or some variation) >consistent with the for just the major groupings, not Description >lines. It is common and well understood for a new keyword to terminate >a list or table. See comments by Matt, Begin and end are a good thing to do and there is a precendent in previous IBIS work. >I would position [Manufacturer], and "[Family Description]" and >[Model List] directly under [Begin Cn Model Family] keyword. I agree, done. > >I would position a single keyword [Description] under each [Begin >Cn Model] keyword. I feel this is not as clear as having a specific keyword [Begin_Cn_Model_Description], I feel it will be somewhat easier to insure the parser is written correctly knowing in what context the model description will be and insuring that it ends up a separate piece of information in the parsed data base. All in all I don't feel strongly either way on this but lean toward having the separate keyword. A group vote can resolve this if needed. 2. In terms of organization, the keywords grouped under >[Begin Cn Model] should be described next. Then the keywords outside >of this grouping should be described: [Begnin Cn Pin Map], >[Begin Cn Phy Map] and [Begin Cn Section]. I agree, I have re-organized per your suggestion. --------------------------------------------------------- Have a great day.... Kellee Crisafulli HyperLynx, a division of Pads Software Inc. SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Thu Jan 13 09:32:30 2000 Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA17694 for ; Thu, 13 Jan 2000 09:32:29 -0800 (PST) Received: from asterix (dhcp7-206.ironbridgenetworks.com [192.168.7.206]) by ironbridgenetworks.com (8.9.3/8.9.3) with SMTP id MAA18344 for ; Thu, 13 Jan 2000 12:31:32 -0500 (EST) Reply-To: From: "John D. Allen" To: "IBIS Mailing list" Subject: RE: Re: Image files Date: Thu, 13 Jan 2000 12:32:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <387DFD03.CBE38E0@omni.sps.mot.com> I am not sure that DXF is a good way to go. Lots of programs (in general) seem to have problems importing DXF's, apparently due to slight differences in the file format from one type of DXF to another, and also due to the vendor changing the DXF format with (almost?) every revision of AutoCad. If I am way off base on this, forgive me - it is based on mt experience of the last year or so. John John Allen  Sr. Consulting Engineer   jallen@IronBridgeNetworks.com IronBridge Networks / 55 Hayden Avenue / Lexington MA  02421 / USA phone: 781-372-8151  fax:   781-372-8092  Main Number 781-372-8000   > -----Original Message----- > From: Dennis Goodrich [mailto:dennisg@omni.sps.mot.com] > Sent: Thursday, January 13, 2000 11:28 AM > To: D. C. Sessions > Cc: IBIS Mailing list; Dennis Goodrich > Subject: Re: Re: Image files > > If we could specify the DXF 2D/3D format, most of the FEA SW tools > would be able to import the drawings and dimensions for > conversion to electrical analysis.. Most of the connector suppliers can make this >format readily (painlessly)available.. > > Just a suggestion from a guy who has to fall back to SPICE once > and a while. > > Dennis Goodrich > > D. C. Sessions wrote: > > > apanella@molex.com wrote: > > > > > > As stated: > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > While the Connector Committee debated this point, I am wondering > > > if the image files could just be "recommended" as .jpg or > .txt formats. > > > The statement "may be either" must be changed to "must be either" > > > or else "is recommended to be either". New formats might emerge. > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > >From a model suppliers perspective.... I think that this is > OK. However, > > > would that potentially make it real difficult for the > simulator vendors? The > > > simulator vendor will then need to support many different > type.... what ever > > > type the model supplier wants to supply. I am not sure that > this is fair....??? > > > > The way this is handled in other contexts (e.g., MIME for HTML mail) is > > that there is (are) one or two default formats that ALL tools > must support, > > and alternates which may or may not be supported. Files are allowed to > > include multiple redundant content, with the tool using the > richer form if > > supported and otherwise falling back on the default. > > > > -- > > D. C. Sessions > > dc.sessions@vlsi.com > > -- > ˙ūD > > > From owner-ibis Thu Jan 13 10:46:09 2000 Received: from easystreet01.easystreet.com (easystreet.com [206.26.36.40]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA18142 for ; Thu, 13 Jan 2000 10:46:09 -0800 (PST) Received: from tdasystems.com (c1008766-a.sttln1.wa.home.com [24.5.72.216]) by easystreet01.easystreet.com (8.9.1/8.9.1) with ESMTP id KAA29997 for ; Thu, 13 Jan 2000 10:45:12 -0800 (PST) Message-ID: <387E1D20.9573DD5@tdasystems.com> Date: Thu, 13 Jan 2000 10:44:48 -0800 From: Steve Corey Organization: TDA Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: Image files References: <0002E956.C21030@molex.com> <387DED8A.6A66CE3D@cadence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A word of warning on GIF and other LZW-based lossless compression algorithms -- they're proprietary. Simulator vendors be forewarned -- you may get more than you bargained for if you agree to support it. See http://www.unisys.com/unisys/lzw/ http://graphicssoft.about.com/compute/graphicssoft/gi/dynamic/offsite.htm?site=http://www.cloanto.com/users/mcb/19950127giflzw.html (sorry if the above URL wraps) If I remember right when we looked into supporting it, the fees weren't unbearable as much as we didn't care for the legal hassle of maintaining a license for it. Furthermore, UniSys seems to be constantly changing their licensing policies. An alternate public-domain format with significant growing support is PNG (Portable Network Graphics). -- Steve Mike LaBonte wrote: > Possibly the guideline for image formats could be to limit them to > the formats supported by commonly available web browsers. The list > for Netscape, for example, is: > > GIF (Graphics Interchange Format) > JPEG (Joint Photographic Experts Group) > XPM (X PixMap) > XBM (X BitMap) > > And of course web browsers can display text, too. Taking this one > step further, could we have a reference to an HTML file instead of > just an image file name? The URL could point to local files, or to > elsewhere on the web. > > I guess I am leaning in the direction of using web pages to show > information that is not intended for machine parsing. Although an > image file *could* be displayed in my own tool, I think I would > settle for a "View data sheet" button. > > Mike > > apanella@molex.com wrote: > > > > As stated: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > While the Connector Committee debated this point, I am wondering > > if the image files could just be "recommended" as .jpg or .txt formats. > > The statement "may be either" must be changed to "must be either" > > or else "is recommended to be either". New formats might emerge. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > >From a model suppliers perspective.... I think that this is OK. However, > > would that potentially make it real difficult for the simulator vendors? The > > simulator vendor will then need to support many different type.... what ever > > type the model supplier wants to supply. I am not sure that this is fair....??? > > > > _gus > > apanella@molex.com > > 630-527-4617 -- ------------------------------------------- Steven D. Corey, Ph.D. Time Domain Analysis Systems, Inc. "The Interconnect Modeling Company." http://www.tdasystems.com email: steve@tdasystems.com phone/fax: (206) 417-3439 ------------------------------------------- From owner-ibis Thu Jan 13 16:40:12 2000 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 QAA19300 for ; Thu, 13 Jan 2000 16:40:12 -0800 (PST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.18 2000/01/07 21:56:55 dmccart Exp $) with SMTP id AAA20638 for ; Fri, 14 Jan 2000 00:39:50 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 14 Jan 2000 00:39:15 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 16:39:14 -0800 Message-ID: <46A91601AF52D211AC3E00A0C984150201F43988@pgsmsx31.png.intel.com> From: "Tan, Fern Nee" To: ibis@eda.org Subject: unsubscribe Date: Thu, 13 Jan 2000 16:38:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" unsubscribe From owner-ibis Thu Jan 13 23:11:37 2000 Received: from mail.huawei.com.cn ([202.96.135.132]) by server.eda.org (8.8.5/8.8.3) with ESMTP id XAA20534 for ; Thu, 13 Jan 2000 23:11:34 -0800 (PST) Received: from huawei.com.cn ([10.11.72.32]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA1757; Fri, 14 Jan 2000 15:09:50 +0800 Message-ID: <387ECA6A.B5022E9C@huawei.com.cn> Date: Fri, 14 Jan 2000 15:04:10 +0800 From: sunweifeng X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ibis-users , "ibis-vhdl.org" Subject: simulator Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sir, Happy new year! Now we want to simulate the EMI/EMC GROUND-BOUNCE and SSN of the PCB, would you please to tell me which simulator is better? and which version ibis model can support this simulate? thanks a lot. Best & Regards, Sun Weifeng From owner-ibis Fri Jan 14 06:20:47 2000 Received: from mail.staktek.com (root@mail.staktek.com [204.181.85.2]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA23753 for ; Fri, 14 Jan 2000 06:20:44 -0800 (PST) Received: from staktek.com (pc114.staktek.com [204.181.85.114]) by mail.staktek.com with ESMTP (8.7.6/8.7.1) id IAA03948; Fri, 14 Jan 2000 08:11:38 -0600 (CST) Message-ID: <387F306A.333FFB7A@staktek.com> Date: Fri, 14 Jan 2000 08:19:22 -0600 From: Russell Rapport X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sunweifeng CC: ibis-users , "ibis-vhdl.org" Subject: Re: simulator References: <387ECA6A.B5022E9C@huawei.com.cn> Content-Type: multipart/mixed; boundary="------------4D47BA718EA8B8FF43716029" This is a multi-part message in MIME format. --------------4D47BA718EA8B8FF43716029 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You should probably add a request to make all replies to you directly to avoid a discussion concerning which product is better. sunweifeng wrote: > Hi Sir, > > Happy new year! > Now we want to simulate the EMI/EMC GROUND-BOUNCE and SSN of the PCB, > would you please to tell me which simulator is better? and which > version ibis model can support this simulate? thanks a lot. > > Best & Regards, > > Sun Weifeng --------------4D47BA718EA8B8FF43716029 Content-Type: text/x-vcard; charset=us-ascii; name="rrapport.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Russell Rapport Content-Disposition: attachment; filename="rrapport.vcf" begin:vcard n:Rapport;Russell tel;fax:512-454-9409 tel;work:Staktek Corporation x-mozilla-html:FALSE org:Staktek Corporation;512-454-9531x235 adr:;;8900 Shoal Creek Blvd. #125;Austin;Tx;78757; version:2.1 email;internet:rrapport@staktek.com title:Sr. Product Development Engineer x-mozilla-cpt:;-8736 fn:Russell Rapport end:vcard --------------4D47BA718EA8B8FF43716029-- From owner-ibis Fri Jan 14 07:01:41 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA23983 for ; Fri, 14 Jan 2000 07:01:40 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id HAA12871; Fri, 14 Jan 2000 07:00:14 -0800 (PST) Received: from davidhan by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id HAA08219; Fri, 14 Jan 2000 07:00:13 -0800 (PST) From: "David Hanson" To: Date: Fri, 14 Jan 2000 07:00:08 -0800 Message-ID: <000701bf5ea0$0c7f4970$5a352293@davidhan.wv.mentorg.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0008_01BF5E5C.FE5C0970" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0008_01BF5E5C.FE5C0970 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01BF5E5C.FE5E5360" ------=_NextPart_001_0009_01BF5E5C.FE5E5360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit unsubscribe David L. Hanson (503) 685-1121 david_hanson@Mentor.com "For God so loved the world that he gave his one and only Son, that whoever believes in him shall not perish but have eternal life." John 3:16 ------=_NextPart_001_0009_01BF5E5C.FE5E5360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

unsubscribe

 
David L. Hanson
(503) 685-1121
david_hanson@Mentor.com
"For God so loved the world = that he=20 gave his one and only Son, that whoever believes in him shall not perish = but=20 have eternal life."   John = 3:16
------=_NextPart_001_0009_01BF5E5C.FE5E5360-- ------=_NextPart_000_0008_01BF5E5C.FE5C0970 Content-Type: image/gif; name="Column Twill.gif" Content-Transfer-Encoding: base64 Content-ID: <961265814@14012000-34c0> R0lGODlhIAMQALP/AKWUhFpSSmNaMf/vpYR7Ss7GhJyUUmtrUoSEY1JSMb3GUpScMWtzMWuEEMDA wAAAACH5BAEAAA4ALAAAAAAgAxAAQAT/MB1QRlGrNUYQIowhEiRhIAaZliOLqqX5Moy2KFUBHIHj /8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvter/gMDcRoFgwNQniwGO73YG4572G8wIHT/3NTtRu ChY7PWKFhoeIiYqLjI2Oj5CRkpNCcWYXGQ0HHR+bBAcMdnl6JZtveKMeJHNuNA2AgjyUs7S1tre4 ubq7vL1RZGYDBpl+np+ffHubNCR8eW6fHBylG68KgTqyvtvc3d7f4OHi41l4lxgaCRIMAmTq73Hw PO3v8AHyAe3sAvQJNjiC4pAbSLCgwYMIEypcYi4Hugbq8OTbx0+AG34JKgqgGOpiRo2o/1r9AahD 4MKTKFOqXMmypZWGZzJZXIPM2TM2ymzmtCmg2o0cAEy6HEq0qNGjSHPBxKRhAwlpMaJOKzE1Kgir Uv8BFZq0q9evYMOKPWLJYSYaJ0Aw20eDn4oUUNnue3uVQ8UGPWFlIzS2r9+/gAOTW/oQokV2BwTE OXUvjmKLikPeIZPvHkZ1PUcC1Sa4s+fPoEMbIpxplZsPxzrUPMYggKpjndiwdq3ng6ufsfiK3s27 t+/fP0hvCFUbxYfizWKkOC4DNagSxW1b26wbuPXr2LMXFb7h2U6Jp+cgCIkqpJ484Hn4mZ5bu/v3 8OOP4x7R8vc7cfLfz8/f2Xrce8kn4EqABBYICX2h8CMXKGy0c5hGG4XSkYOgUGQRgzWwF6CBHHbo 4YdUcMcBACKUaMIJKADwgYklpnDCizKMsIAKHgyjWXsg5qjjjjtGAAA7 ------=_NextPart_000_0008_01BF5E5C.FE5C0970-- From owner-ibis Fri Jan 14 08:17:45 2000 Received: from tower.ti.com (tower.ti.com [192.94.94.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA24379 for ; Fri, 14 Jan 2000 08:17:44 -0800 (PST) Received: from dlep6.itg.ti.com ([157.170.188.9]) by tower.ti.com (8.9.3/8.9.3) with ESMTP id KAA02157 for ; Fri, 14 Jan 2000 10:16:18 -0600 (CST) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA19981 for ; Fri, 14 Jan 2000 10:16:12 -0600 (CST) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA19967 for ; Fri, 14 Jan 2000 10:16:12 -0600 (CST) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA14118 for ; Fri, 14 Jan 2000 10:16:16 -0600 (CST) Message-ID: <387F4BAE.D492908A@ti.com> Date: Fri, 14 Jan 2000 10:15:42 -0600 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: URL for TI's AVC DOC(tm) circuitry app report Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit URL for TI's AVC family DOC(tm) circuitry app report. This describes the Dynamic Output Control output that the TI & Philips AVC families utilize. http://www-s.ti.com/sc/psheets/scea009b/scea009b.pdf -- Regards, Stephen M. Nolan From owner-ibis Fri Jan 14 13:48:01 2000 Received: from exchange2.3dfx.com (h-53.3dfx.com [205.158.17.53]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA25567 for ; Fri, 14 Jan 2000 13:48:01 -0800 (PST) Received: by exchange2.3dfx.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 13:44:16 -0800 Message-ID: <4F7525F7D14CD211AABD00A0C9DED90103888DB1@exchange2.3dfx.com> From: Ken Wu To: "'ibis@eda.org'" Subject: unsubscribe Date: Fri, 14 Jan 2000 13:44:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5ED8.8157CCA8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5ED8.8157CCA8 Content-Type: text/plain; charset="iso-8859-1" Ken Z. Wu 3Dfx Interactive, Inc. 4435 Fortran Drive San Jose, CA 95134 Tel: (408)935-4309 Fax: (408)262-8602 Email: kenw@3dfx.com ------_=_NextPart_001_01BF5ED8.8157CCA8 Content-Type: text/html; charset="iso-8859-1" unsubscribe

Ken Z. Wu
3Dfx Interactive, Inc.
4435 Fortran Drive
San Jose, CA 95134
Tel: (408)935-4309
Fax: (408)262-8602
Email: kenw@3dfx.com


------_=_NextPart_001_01BF5ED8.8157CCA8-- From owner-ibis Fri Jan 14 14:39:53 2000 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA25749 for ; Fri, 14 Jan 2000 14:39:53 -0800 (PST) Received: from us-ea-gtwy-4.ea.unisys.com (us-ea-gtwy-4.ea.unisys.com [192.61.146.122]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id WAA18008 for ; Fri, 14 Jan 2000 22:37:57 GMT Received: by us-ea-gtwy-4.ea.unisys.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 16:38:25 -0600 Message-ID: <8B504D0423F9D211B0F400609703ED82316777@us-rb-exch-1.rb.unisys.com> From: "Walker, Jim" To: "'ibis@eda.org'" Subject: unsubscribe Date: Fri, 14 Jan 2000 16:38:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" From owner-ibis Tue Jan 18 10:23:49 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA12232 for ; Tue, 18 Jan 2000 10:23:48 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id NAA25485 for ; Tue, 18 Jan 2000 13:22:06 -0500 (EST) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id NAA17255 for ; Tue, 18 Jan 2000 13:22:05 -0500 (EST) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id KAA17282 for ; Tue, 18 Jan 2000 10:21:33 -0800 (PST) Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4) id KAA00263; Tue, 18 Jan 2000 10:23:14 -0800 Date: Tue, 18 Jan 2000 10:23:14 -0800 From: guy@camarillo.viewlogic.com (Guy de Burgh) Message-Id: <200001181823.KAA00263@f22.viewlogic.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting Minutes - 1/14/00 DATE: 1/18/00 SUBJECT: 1/14/00 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2000 PARTICIPANTS LIST: 3Com (Roy Leventhal) Applied Simulation Technology Raj Raghuram* Avanti (Nikolai Bannov) Cadence Design Mike LaBonte* Cisco Systems (Syed Huq) Compaq Bob Haller* Cypress (Rajesh Manapat) EMC Corporation (Fabrizio Zanella), Fairchild Semiconductor (Craig Klein) H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) (Karl Kachigan) HyperLynx (& Pads Software) Matthew Flora*, Kellee Crisafulli*, John Angulo* IBM Michael Cohen* Incases (Werner Rissiek) Intel Corporation Stephen Peters*, Arpad Muranyi* LSI Logic (Larry Barnes) Mentor Graphics (& Veribest) Bob Ross* Mitsubishi (Tam Cao) Motorola Ron Werner* National Semiconductor Milt Schwartz* North East Systems Associates (Edward Sayre) NEC (Hiroshi Matsumoto) Nortel Networks (Calvin Trowell) Philips Semiconductor D.C. Sessions* (& VLSI Technology) Quantic EMC (Mike Ventham) Siemens (Gerald Bannert) SiQual (Scott McMorrow) Texas Instruments Stephen Nolan*, Time Domain Analysis Systems (Dima Smolyansky) Viewlogic Systems Chris Rokusek*, Guy de Burgh*, (Jon Powell) Via Technologies (Weber Chuang) OTHER PARTICIPANTS IN 2000: EIA (Cecilia Fleming) Molex Incorporated Gus Panella* 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 January 31, 2000 - DesignCon 2000 IBIS Summit Meeting (No Bridge) All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Bob Ross started the meeting and stated that there were the required number of companies present to establish a quorum. Stephen Nolan of Texas Instruments introduced himself. He is an application engineer in the logic products group and is involved with IBIS model development. Another engineer in the group is also expected to become active. Stephen is also leader of a JEDEC JC-40.4 group and is active in other groups as well. One of Stephen's interests is to learn more about IBIS and propose a BIRD enhancement to deal with the AVC dynamic output control circuitry which uses voltage feedback to control driver output impedance. This technology is being implemented by several companies. Stephen plans to send out to the IBIS reflector a web address describing the technology. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross does not have any recent updates. He announced that Cecilia Fleming has sent out the year 2000 membership invoices. REVIEW OF MINUTES AND AR'S Bob Ross reported that Michael Cohen had submitted a request that the December 17, 1999 Minutes be amended to include the actual s2ibis3 funding vote. Bob noted that the recorded vote was as follows and will add this to the minutes: YES - Cisco Systems, HyperLynx, IBM, National Semiconductor, NO - 3Com, Applied Simulation Technology, Cadence Systems, Intel, Motorola, Time Domain Analysis Systems, VLSI Technology (Philips Semiconductor) ABSTAIN - Compaq, Fairchild Semiconductor, Mentor Graphics, Viewlogic Systems NOT PRESENT - Texas Instruments Bob also will make a minor editorial correction in the list of participants. The December 17, 1999 IBIS Open Forum Meeting Minutes were approved with the above changes and the amended minutes will be uploaded [Done]. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Bob Ross noted that the year 2000 participation list starts again this year. Bob keeps this information to document industry-wide support and interest. Last year we had 33 official member companies. We also had about 88 people from member companies and about 140 people total who participated in at least one meeting. This represents a modest growth from previous years. Currently we have 31 members since Mentor Graphics now includes VeriBest, and Philips Semiconductor now includes VLSI Technology. PRESS AND WEB PAGE UPDATES Bob Ross reported that Syed Huq made a lot roster changes and upgrades to the membership list starting at year 2000. Some of these include an address change for TDA Systems, and the combining of company information for Philips Semiconductor and Mentor Graphics as noted above. Also Syed added that web links to the home page were added to all companies which did not supply links. Members who want the links directed elsewhere can contact Syed. Bob reported that a reference to IBIS exists in "Implementing an Internal Signal Integrity Department" by Lynne Green and Lee Richey in the January 2000 issue of Printed Circuit Design, pp. 24-28. Also, Bob reported that Jon Powell will be giving two presentations at the PCB Design Conference West, March 20-24, 2000 titled: "Introduction to the Use and Effectiveness of IBIS Models for SI Simulation", and "Writing and Qualifying IBIS Models". NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross had no report. OPENS FOR NEW ISSUES None INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Bob Ross noted that the international representative has been out, and we have not yet been able to find out the status on the formal ratification of IBIS Version 3.2 as IEC 62104-1. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross reported that the December 21, 1999 deadline for comments had passed for Version 1.2. Mike LaBonte stated that the group is meeting in January and will probably accept late comments. - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross had no further report. - JC-16.2 Subcommittee: Modeling and Test - D.C. Sessions reported that committee plans to issue a set of reference simulations for DDR. He also has some meetings regarding using IBIS in a standards context for JEDEC specification issues. D.C. stated that there are some technologies such as AGP4X which have features not covered by IBIS. Bob Ross noted that IBIS emerged primarily to capture information for simulation, but has always included some specification information. There has always been pressure to add more specification limit information. Later, D.C. stated that he and Bob have been working on a joint JEDEC/IBIS meeting to be held on Thursday afternoon, February 3, 2000. A formal JEDEC JC-42.3 Working Group meeting is held on Friday, February 4, 2000. The smaller meeting is intended to be a less formal working group session to discuss and coordinate some newer technology issues common to both organizations. D.C. plans for about 10 to 12 people total to be held in a (small) room at Philips in San Jose, California. The planning has just been occurring recently, so meeting details and participation is still not finalized. From the IBIS side, Bob has already invited several people involved with input modeling proposals (an issue of common interest) and wants to expand the participation to include an EDA representative from the IBIS member companies. D.C. is inviting JEDEC participants from semiconductor vendors. While more details will emerge in the following weeks as the participation list is confirmed, D.C. stated that some final planning may occur after the IBIS Summit Meeting on Monday, January 31, 2000. (Bob is following through on inviting EDA vendor participants.) DESIGNCON 2000 IBIS SUMMIT PLANNING Bob Ross restated that the IBIS Summit meeting is being held on Monday, January 31, 2000 in Santa Clara, California. The IBIS Open Forum is listed again as an Associate Sponsor of DesignCon 2000 which means that DesignCon is providing the meeting room and refreshments and also booth space. National Semiconductor is sponsoring the luncheon. Milt Schwartz commented that he sent out the second announcement and also estimates about 27 signups so far. He is planning for 50. Several people stated that they did not realize that the announcements also requested signing up for the meeting. After some discussion, Bob stated that we plan to send another announcement shortly for signup. We will finalize the agenda and send it out later, one week before the meeting. Bob noted updates in the program. We dropped the Accuracy discussion since the most recent work is an upgrade to the test board which may or may not be available at the IBIS Booth. A presentations by Richard Mellitz has been added. Updated Program: "Model Design: Tables and Equations" - Lynne Green, Hyperlynx "Connector Model Specification" - Gus Panella, Molex "Input Receiver Modeling" - Donald Telium, Cadence "Using Statistical Methods to Characterize Receivers to Determine the Applicability of Receiver Modeling Standardization" - Richard Mellitz, Intel "Discussion on the Future of IBIS" - Stephen Peters, Intel Bob stated that he will plan the Model Design presentation and Connector discussion in the morning and the input modeling and IBIS Futures discussion in the afternoon. Ad Hoc presentations will be welcome. The recent trend of having fewer presentations to allow more time for interactive discussions has worked well in recent IBIS Summit meetings. The EIA IBIS Open Forum will have a booth at DesignCon. Bob Haller stated that he is arranging a demonstration and test board to demonstrate some techniques to measure critical parameters on a high speed connector. He may also have an accuracy test board, if it is ready, for discussion and illustration purposes. He mentioned several people who are working on it. Equipment will be supplied by Agilent. Bob H. wanted to pass out the latest copy of the pending IBIS Connector Specification document. Ron Werner pointed out that we should not pass out preliminary work. However, we can have some copies available for review at the booth. Also, the document is large, and we can provide the links to download the document. Bob R. note that Jon Powell is collecting IBIS logo signs to be used as a backdrop for the booth (being donated by Viewlogic). Jon will use the member company signs from last year if updated ones are not received. New member companies are welcome to send Jon their signs. DATE2000 IBIS SUMMIT PLANNING Bob Ross reviewed that the DATE2000 IBIS Summit meeting associated with the Design Automation and Testing in Europe conference is planned to be held in Paris, France on Friday, March 31, 2000. The meeting is planned to run from morning to early afternoon. Incases, Viewlogic and Mentor Graphics are co-sponsors. Bob plans to have a notice sent out in the next several weeks for early planning and travel arrangement approval. COOKBOOK STATUS Stephen Peters had no report. Ron Werner asked what the future plans are, and Stephen responded that on a low priority basis, some Version 3.2 features will be added. Stephen Nolan commented that he is closely reviewing the Cookbook and may be able to help in an updating the document. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora reported that he has received a model from Honeywell for review. Matthew needs to update the distribution list before sending out this model. Matthew Flora had previously sent out a model from Galileo Technology at end of last year for review. IBIS FUTURES (IBIS-X, API, BIRDxx) Stephen Peters introduced the IBIS-X proposal to deal with some current issues. IBIS lacks some critical analysis factors and does not handle well the power and ground distribution and return path. One unattractive option is to issue encrypted Spice models. The IBIS-X proposal uses some major concepts of IBIS such as the I-V and V-T table description for buffers. It also uses submodels. It adds a nodal descriptions and will be able to deal with pin to pin coupling. D.C. Sessions stated that package parasitics are becoming the dominant factor in high speed design. He emphasized that board level EDA tools needs to handle this better. Stephen added that an exchange format may be developed to support newer constructs that have not been standardized. The overall IBIS-X proposal is not intended to be backwards compatible with IBIS Verison 3.2. Gus Panella asked, and Stephen responded that this proposal is planned to be in a separate document. Bob Ross noted that some good structural comments were provided by Al Davis. Matthew Flora indicated that Al has examples of the methodology and some macro extensions to support existing IBIS keywords for backwards compatibility. Bob welcomed a suggestion of having Al do a presentation at the IBIS Summit Meeting on January 31, 2000. Stephen also invited putting this information on the IBIS reflector. IBISCHK BUGS Bob Ross noted that we are still deferring discussion on BUG34. We also have several other reported bugs and enhancements. One old report is that repeated voltage values in I-V tables are not reported. Stephen Nolan recently reported that the 8.3 file size rule is not checked anymore using ibischk3 when the file is designated by Version 2.1. We need to issue BUG reports for tracking, but these fixes have not been a high priority item in recent months. Matthew Flora asked who has the source code. Bob responsed that Atul Agarwal still controls the master copy and also has unreleased fixes for BUG36 and BUG37. Matthew and Chris Rokusek have also made significant technical enhancements to the source code in the past. CONNECTOR PROPOSAL REVIEW During the discussion, Kellee Crisafulli stated that Version 0.93 of the Connector Specification had just been uploaded. A number of editorial suggestions have been incorporated. However, no major technical based on recent suggestions have been incorporated. The new document divides the information into sections similar to IBIS Verison 3.2. Kellee has added an Introduction, Statement of Intent, Change Section, and Tree diagram. He did re-position the keywords for [Manufacturer], [Web], [Email], and [Redistribution] to be under the [Define_Cn_Model_Family]. Kellee also changed the order of keywords for clarity. To avoid confusing the discussion at this meeting, he did not pre-announce the new document. D.C. Sessions questioned whether the Connector Specification was outside the charter of the IBIS Open Forum, which has been concerned about a single IBIS document. Bob Ross thought that EIA and ANSI would not have a problem with the work we are doing with Connectors. Bob Ross opened the Connector Specification by stating that there has been much progress in recent months. The enhanced matrix discussion had been added. There appears to be general consensus on the current scope of the Connector Specification (deferring frequency dependent losses until later) and using the coupled matrix structures similar to those in IBIS Version 2.1. Bob reviewed some of his technical comments and responses issued on the IBIS reflector. Many, but not all of the comments are captured below. We attempted to provide better understanding, but not necessarily any final resolution on the point that were raised. Bob questioned why we needed to limit the [Begin_Cn_Model_Family] to one per file. This is inconsistent with other top-level IBIS keywords. While manufacturers might in practice limit one per file for distribution, a design file might include many connectors for file efficiency. Also, the connectors of a design might be exported in one file. Kellee pointed out that this would not be a limitation. The new [Begin_Cn_Model_Family] could be used to bracket the body from the header information. Bob thought this might be a good interpretation. Bob questioned the [Begin_Cn_Model_List] Max_Slew_Time term. Bob thought that what was intended was to document the maximum slew rate which would then correspond to the minimum slew time (or transition time) for which the model is considered valid. Kellee and Gus Panella commented that the connector committee had spent time discussing the terminology and thought that they had come to a resolution. Others had suggestions. Kellee and Gus agreed to take the suggestions and provide an alternative proposal. The [Begin_Cn_Model] syntax was discussed. Gus Panella confirmed that there were situations where only the internal [Begin_Cn_Auto_Map] is used and there is no need for the required ModelPinMap and ModelPhyMap parameters on the command line. Bob noted that other similar commands only have the model_name entry on the command line. Gus had suggested on the IBIS reflector that we might consider requiring a default pin map and physical pin map for simulators not supporting the [Begin_Cn_Auto_Map] keyword. Bob noted that other similar commands only have the model_name entry. Subparameters could also be considered. Kellee commented that subparameters mixed with the topology lines (Cn_Section, Cn_Stub) might be confusing. Bob noted that no keywords in this document have subparameters. Bob stressed that this type of issue needs to be resolved because it would arise again as a parser development question regarding missing references and what errors to issue. Bob also commented that the Cn_Series should support cascading sections in series on the same line. This would be consistent with Cn_Stub which supports cascaded section. This would also simplify the syntax rules and implementation. Putting Cn_Series sections on separate lines would still be permitted. We debated the need for providing a 100,000 point conductor size limit. Bob felt that actual conductor topologies should determine the limit. Kellee and others noted that a limit was needed so that EDA vendors have an upper bound on memory allocation. Plus it could be used by the parser to check against mistaken entries. We talked about other maximums. Bob would be comfortable with just a recommendation statement or dealing with this as a parser test warning message. Bob just noted that the [Begin_Cn_Auto_Map] might allow some syntax violations - such as indices of the same value. Also, the parameter method needs to be reviewed. Kellee indicated that VARIABLE was an appropriate place holder for a variable. Bob questioned why only .jpg and .txt images were permitted under [Begin_ Cn_Model_List]. Gus argued that limiting the formats was intended to be helpful to EDA tool vendors by limiting the choices to be supported. Other formats were suggested. When Bob questioned the EDA Vendors, he got several answers. Kellee indicated that the .gif format was rejected because of reader licensing issues. Bob's main point is that he would prefer recommended, but not required formats. Otherwise, the parser would have to provide an extension test and reject models with unapproved extensions. Bob closed the discussion by noting that we plan more discussion at the IBIS Summit Meeting. Bob also welcomes continued reflector discussion. Kellee will continue to be the editor of the Connector Specification and may incorporated changes based on this and other discussions. BIRD62.2 ENHANCED CHARACTERIZATION OF RECEIVER THRESHOLDS BIRD63.2 DOCUMENTATION OF RECEIVER SETUP AND HOLD TIMING CONDITIONS Bob Ross mentioned that we need to review these BIRDs since they will be coming up for a vote after the DesignCon IBIS Summit Meeting. NEXT MEETING: The next Meeting is the IBIS Summit Meeting from 8:30 AM to 5:00 PM on Monday, January 31, 2000 associated with DesignCon 2000 in the Westin Hotel in Ballroom C. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@viewlogic.com Senior Manager, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jpowell@viewlogic.com Senior Scientist, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Signal Integrity Engineer, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 114715 N.E. 95th Street Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org/eig/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Tue Jan 18 14:02:47 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA13206; Tue, 18 Jan 2000 14:02:46 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA11514; Tue, 18 Jan 2000 14:01:17 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA05427; Tue, 18 Jan 2000 14:01:16 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3884E2AB.887820EF@mentor.com> Date: Tue, 18 Jan 2000 14:01:15 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: IBIS SUMMIT ANNOUNCEMENT JAN. 31, 2000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee: I am sending this out on behalf of Milt. Bob Ross Mentor Graphics ------------------------------------------ To All: This is the final call for presentations and participation at the IBIS Summit Meeting held with DesignCon 2000. If you have not done so, PLEASE signup with me below so we have an estimated attendence count for planning the lunch. Milt Schwartz National Semiconductor ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- DESIGNCON 2000 IBIS SUMMIT FINAL CALL FOR PARTICIPATION, PRESENTATIONS ---------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:00 PM - 5:00 PM, Monday, January 31, 2000 Location: Santa Clara Convention Center Santa Clara, CA Meeting Location - Weston Hotel, Grand Ballroom C Content: IBIS Future Requirements is the main topic of this meeting These include an exchange of ideas on IBIS accuracy, connectors, and new requirements under discussion. Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: DesignCon 2000 & National Semiconductor Corporation SIGN UP FOR THE IBIS Summit by sending a note to the address below: Milt Schwartz schwartz@nsc.com D E S I G N C O N 2 0 0 0 M E E T I N G S Time/Date: Monday - Thursday, January 31 - February 3, 2000 Exhibition: Tuesday - Wednesday, 12:30 PM - 6:30 PM, February 1 - 2, 2000 IBIS Booth: #1039, Exhibition Hall - Connector Specification and Accuracy Committee Demonstration - IBIS Information - Contact Jon Powell, jpowell@viewlogic.com, for information. URL DesignCon2000: http://www.designcon.com/ Signup Discount: IBIS member companies may receive a 15 percent discount to the DesignCon 2000 Conference. Past Conference attendees also will receive a 20% alumni discount. AGENDA FOR IBIS SUMMIT The agenda includes presentations, discussions, refreshments, and a free buffet luncheon for participants. In addition, we will have an opportunity for Ad Hoc presentations and extended discussions. So far we tentatively plan the following presentations and discussions: Morning: Model Design: Tables and Equations - Lynne Green, HyperLynx Connector Model Specification - Gus Panella, Molex Afternoon: Using Statistical Methods to Characterize Receivers to Determine the Applicability of Receiver Modeling Standardization - Richard Mellitz, Intel Input Receiver Modeling - Don Telium, Cadence Extendable Macro Structures of IBIS - Al Davis, HyperLynx Ideas for Future IBIS Versions - Arpad Muranyi, Intel Discussion - Future of IBIS - Stephen Peters, Intel Adequate time is set aside for Ad Hoc presentations and discussion. Presentors, plan on 50 copies for handing out. Or else, National Semiconductor will make and bring the copies of the presentations are received by Milt Schwartz by Wednesday, January 26, 2000. From owner-ibis Fri Jan 21 10:27:31 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA03173 for ; Fri, 21 Jan 2000 10:27:30 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id NAA14192 for ; Fri, 21 Jan 2000 13:26:00 -0500 (EST) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id NAA15923 for ; Fri, 21 Jan 2000 13:25:59 -0500 (EST) Received: from consulthp1 (consulthp1.camarillo.viewlogic.com [139.181.194.167]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id KAA10980 for ; Fri, 21 Jan 2000 10:25:24 -0800 (PST) From: "Jon Powell" To: Subject: DesignCon Sign Update. Date: Fri, 21 Jan 2000 10:24:02 -0800 Message-ID: <003301bf643c$b140e9e0$a7c2b58b@consulthp1.camarillo.viewlogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Would the representative for 3COM please contact me at 805 988 8250 regarding the sign that you sent. thanks jon Jon N. Powell Director of Board Design Consulting Services Viewlogic Systems, Inc. 1369 Del Norte Rd. Camarillo, CA. 93010 (804) 988 8250 From owner-ibis Mon Jan 24 13:26:39 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA15367; Mon, 24 Jan 2000 13:26:39 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA20335; Mon, 24 Jan 2000 13:25:07 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA26686; Mon, 24 Jan 2000 13:25:06 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <388CC330.FA48A206@mentor.com> Date: Mon, 24 Jan 2000 13:25:04 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: IBIS SUMMIT MEETING AGENDA 1/31/00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: Below is the planned Agenda. We have room for discussions, and we also may end the meeting early. Please contact Milt Schwartz at schwartz@nsc.com to sign up, if you have not done so. Confirm the room location at the hotel. It may be listed under some sponsoring organization such as IEC, DesignCon, National Semiconductor, etc. Bob Ross Mentor Graphics ------------------------------------------------------------------ AGENDA, IBIS SUMMIT MEETING JANUARY 31, 2000 Westin Hotel, Ballroom E Santa Clara Convention Center Santa Clara, California ------------------------------------------------------------------ 8:00 AM Refreshments & Sign In 8:30 AM Introductions - Welcome to Summit - Introductions - IBIS Booth #1039 Placards - Opens for Issues, Discussion 9:00 AM Model Designs: Tables and Equations Lynne Green, HyperLynx 9:30 AM Simutaneous Switching Noise Modeling Bernhard Unger, Siemens 10:00 AM Break 10:15 AM IBIS Booth #1039 - Connector Demonstration Bob Haller, Compaq 10:20 AM Connector Model Specification (& Discussion) Gus Panella, Molex 11:30 AM Using Statistical Methods to Characterize Receivers to Determine the Applicability of Receiver Modeling Standardization Richard Mellitz, Intel 12:00 PM Lunch Ballroom D (Hosted by National Semiconductor) Westin Hotel 1:00 PM Input Receiver Behavioral Modeling (& Discussion) Donald Telian, Intel 2:15 PM Extendable Macro Structures of IBIS Al Davis, HyperLynx 2:45 PM Break 3:00 PM Ideas for Future IBIS Versions Arpad Muranyi, Intel 3:30 PM Discussion - Future of IBIS Stephen Peters, Intel 4:00 PM Other Topics 4:45 PM Concluding Items - Date2000 IBIS Summit - Next Meeting February 25, 2000 - ?? 5:00 PM End of IBIS Summit Meeting 5:00 PM JEDEC/IBIS Working Group Meeting Plans ------------------------------------------------------------------ From owner-ibis Mon Jan 24 13:48:03 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA15520; Mon, 24 Jan 2000 13:48:02 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA22406; Mon, 24 Jan 2000 13:46:30 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA01236; Mon, 24 Jan 2000 13:46:30 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <388CC834.290ECFC1@mentor.com> Date: Mon, 24 Jan 2000 13:46:28 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: CORRECTION - IBIS SUMMIT MEETING AGENDA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: Correction - (Company affiliation correction for Don Telian) Bob Ross Mentor Graphics ------------------------------------------------------------------ AGENDA, IBIS SUMMIT MEETING JANUARY 31, 2000 Westin Hotel, Ballroom E Santa Clara Convention Center Santa Clara, California ------------------------------------------------------------------ 8:00 AM Refreshments & Sign In 8:30 AM Introductions - Welcome to Summit - Introductions - IBIS Booth #1039 Placards - Opens for Issues, Discussion 9:00 AM Model Designs: Tables and Equations Lynne Green, HyperLynx 9:30 AM Simutaneous Switching Noise Modeling Bernhard Unger, Siemens 10:00 AM Break 10:15 AM IBIS Booth #1039 - Connector Demonstration Bob Haller, Compaq 10:20 AM Connector Model Specification (& Discussion) Gus Panella, Molex 11:30 AM Using Statistical Methods to Characterize Receivers to Determine the Applicability of Receiver Modeling Standardization Richard Mellitz, Intel 12:00 PM Lunch Ballroom D (Hosted by National Semiconductor) Westin Hotel 1:00 PM Input Receiver Behavioral Modeling (& Discussion) Donald Telian, Cadence Design 2:15 PM Extendable Macro Structures of IBIS Al Davis, HyperLynx 2:45 PM Break 3:00 PM Ideas for Future IBIS Versions Arpad Muranyi, Intel 3:30 PM Discussion - Future of IBIS Stephen Peters, Intel 4:00 PM Other Topics 4:45 PM Concluding Items - Date2000 IBIS Summit - Next Meeting February 25, 2000 - ?? 5:00 PM End of IBIS Summit Meeting 5:00 PM JEDEC/IBIS Working Group Meeting Plans ------------------------------------------------------------------ From owner-ibis Tue Jan 25 17:32:11 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA24689; Tue, 25 Jan 2000 17:32:10 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA20217; Tue, 25 Jan 2000 17:30:39 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA23056; Tue, 25 Jan 2000 17:30:38 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <388E4E3D.9BB742D9@mentor.com> Date: Tue, 25 Jan 2000 17:30:37 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: REVISED IBIS SUMMIT AGENDA 1/31/00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Summit Attendees: This is a revised Agenda to resolve a scheduling conflict. Lynne Green's presentation is moved to the end. Note, some Ad Hoc presentations and discussions may be done in the morning if we have time. If you have not done so already, let Milt Schwartz know if you are attending. People who are presenting: please send the presentations to Milt for copying at schwartz@nsc.com. Otherwise, plan to bring 50 copies for distribution at the meeting. We will have an overhead projector and also a projector for laptop presentations. I prefer using the overhead projector, if practical, to maximize interaction and allow Ad Hoc presentations and discussions (and so my hand drawn slides won't look so bad :-)). Bob Ross Mentor Graphics ------------------------------------------------------------------ AGENDA, IBIS SUMMIT MEETING JANUARY 31, 2000 Westin Hotel, Ballroom E Santa Clara Convention Center Santa Clara, California ------------------------------------------------------------------ 8:00 AM Refreshments & Sign In 8:30 AM Introductions - Welcome to Summit - Introductions - IBIS Booth #1039 Placards - Opens for Issues, Discussion 9:00 AM Simutaneous Switching Noise Modeling Bernhard Unger, Siemens 9:30 AM Ad Hoc Presentations and Discussions 9:50 AM IBIS Booth #1039 - Connector Demonstration Bob Haller, Compaq 10:00 AM Break 10:15 AM Connector Model Specification (& Discussion) Gus Panella, Molex 11:30 AM Using Statistical Methods to Characterize Receivers to Determine the Applicability of Receiver Modeling Standardization Richard Mellitz, Intel 12:00 PM Lunch Ballroom D (Hosted by National Semiconductor) Westin Hotel 1:00 PM Input Receiver Behavioral Modeling (& Discussion) Donald Telian, Cadence Design 2:15 PM Extendable Macro Structures of IBIS Al Davis, HyperLynx 2:45 PM Break 3:00 PM Ideas for Future IBIS Versions Arpad Muranyi, Intel 3:30 PM Discussion - Future of IBIS Stephen Peters, Intel 4:00 AM Model Designs: Tables and Equations Lynne Green, HyperLynx 4:30 PM Other Topics 4:45 PM Concluding Items - Date2000 IBIS Summit - Next Meeting February 25, 2000 - ?? 5:00 PM End of IBIS Summit Meeting 5:00 PM JEDEC/IBIS Working Group Meeting Plans ------------------------------------------------------------------ From owner-ibis Thu Jan 27 07:55:33 2000 Received: from ckpnt01.intergraph.com (ckpnt01.intergraph.com [205.139.151.254]) by server.eda.org (8.8.5/8.8.3) with SMTP id HAA03899 for ; Thu, 27 Jan 2000 07:55:21 -0800 (PST) Received: from hq15.pcmail.ingr.com by ckpnt01.intergraph.com via smtpd (for server.vhdl.org [171.64.101.103]) with SMTP; 27 Jan 2000 15:54:18 UT Received: by HQ15 with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jan 2000 09:54:12 -0600 Message-ID: <7D1F1CEAECA8D2118013080009B025340304312E@HQ1> From: "Kelley, Rob" To: IBIS , SI Mailing List Administration Subject: unsubscribe Date: Thu, 27 Jan 2000 09:54:10 -0600 X-MS-TNEF-Correlator: <7D1F1CEAECA8D2118013080009B025340304312E@HQ1> X-Mailer: Internet Mail Service (5.5.2650.21) begin 600 winmail.dat M>)\^(@T/`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<` M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T``#!``0````@```!22T5,3$59``,`&4```````P#>/Z]O M```#``"`""`&``````#`````````1@````!2A0``\!,``!X``8`((`8````` M`,````````!&`````%2%```!````!````#@N-0`#``*`""`&``````#````` M````1@`````!A0````````L``X`((`8``````,````````!&``````.%```` M````"P`$@`@@!@``````P````````$8`````#H4````````#``6`""`&```` M``#`````````1@`````0A0````````,`!H`((`8``````,````````!&```` M`!&%`````````P`(@`@@!@``````P````````$8`````&(4````````>``F` M""`&``````#`````````1@`````VA0```0````$`````````'@`*@`@@!@`` M````P````````$8`````-X4```$````!`````````!X`"X`((`8``````,`` M``````!&`````#B%```!`````0`````````+`.R`"R`&``````#````````` M1@``````B`````````L`[8`+(`8``````,````````!&``````6(```````` M"P`7@0@@!@``````P````````$8`````!H4````````#`/$_"00```,`_3_D M!````P`F```````#`#8```````,`@!#_____`@%'``$````P````8SU54SMA M/2`[<#U)3E1%4D=205!(.VP]2%$Q+3`P,#$R-S$U-30Q,%HM,C8T,S,`'@`X M0`$````(````4DM%3$Q%60`>`#E``0````@```!22T5,3$59`$``!S"T'D;` MWFB_`4``"#"F-8C`WFB_`1X`/0`!`````0`````````>`!T.`0````P```!U M;G-U8G-C`#40`0```"\````\-T0Q1C%#14%%0T$X1#(Q,3@P,3,P M.#`P,#E",#(U,S0P,S`T,S$R14!(43$^```+`"D```````L`(P```````P`& M$``````#``<0``````,`$!```````P`1$``````>``@0`0````$````````` M`@%_``$````O````/#=$,48Q0T5!14-!.$0R,3$X,#$S,#@P,#`Y0C`R-3,T 1,#,P-#,Q,D5`2%$Q/@``7X(= ` end From owner-ibis Fri Jan 28 13:10:39 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA14103; Fri, 28 Jan 2000 13:10:38 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA11043; Fri, 28 Jan 2000 13:09:04 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA15527; Fri, 28 Jan 2000 13:09:04 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3892056E.252F63F2@mentor.com> Date: Fri, 28 Jan 2000 13:09:02 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org, si-list@silab.eng.sun.com Subject: EUROPEAN IBIS SUMMIT MEETING ANNOUNCEMENT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit E U R O P E A N I B I S S U M M I T M E E T I N G F I R S T A N N O U N C E M E N T Time/Date: 8:30 AM - 2 PM, Friday, March 31, 2000 Location: Concorde-Lafayette Hotel (adjacent to Le Palais des Congress de Paris Prote Mailot - site of the DATE2000 Conference in Paris, France Rooms: Salon, Van Gogh, Pissarro Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: INCASES, Mentor Graphics and Viewlogic DATE2000: March 27-30, 2000. The IBIS meeting is scheduled the day following the trade show portion of the Conference and the PCB Symposium. See http://www.date-conference.com for more information. BACKGROUND For the last several years we have been holding very successful European IBIS Summit Meetings. We plan a combination of the following: Submitted Presentations on IBIS Topics (See below) Less formal Ad Hoc Presentations and Discussions IBIS Questions and Answers Below is an invitation to register and also to submit presentations. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the European IBIS Summit meeting. If you plan to participate, please supply the information below: Name: E-mail address: Company: Telephone: Send to: Karine Loudet (karine_loudet@mentor.com) +33 1 40 94 74 54 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Some suggested subjects of interest are: IBIS Model Development Experiences Company IBIS Standards and Requirements Generating and Validating IBIS Models Future IBIS Requirements EMC/EMI IBIS Issues Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Bob Ross (bob_ross@mentor.com) AGENDA The agenda includes presentations, discussions, and a free lunch. FOR FURTHER INFORMATION: Bob Ross, Chair, EIA/IBIS Open Forum Mentor Graphics 8005 S.W. Boeckman Road Wilsonville, Oregon 97070 USA (503) 685-0732 bob_ross@mentor.com From owner-ibis Fri Jan 28 22:45:06 2000 Received: from mail-srv1.micron.com (masquerade.micron.com [137.201.242.130]) by server.eda.org (8.8.5/8.8.3) with ESMTP id WAA15915 for ; Fri, 28 Jan 2000 22:45:06 -0800 (PST) Received: from mail-srv1.micron.com (localhost [127.0.0.1]) by mail-srv1.micron.com (8.9.2/8.9.2) with ESMTP id XAA00668 for ; Fri, 28 Jan 2000 23:43:33 -0700 (MST) Received: from ntxsing01.sing.micron.com (ntxsing01.sing.micron.com [10.160.129.21]) by mail-srv1.micron.com (8.9.2/8.9.2) with ESMTP id XAA00657 for ; Fri, 28 Jan 2000 23:43:32 -0700 (MST) Received: by ntxsing01.sing.micron.com with Internet Mail Service (5.5.2650.21) id ; Sat, 29 Jan 2000 14:43:34 +0800 Message-ID: <356BECDFCC89D21182080008C71E417301946575@ntxsing02.sing.micron.com> From: subas To: ibis@eda.org Subject: Free IBIS model generation tools Date: Sat, 29 Jan 2000 14:43:29 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi, Does anybody know of any free IBIS model generation packages? I am currently using SPECCTRAQUEST and it creates something very much like IBIS for its SigNoise but the format is totally different (dml format). Thank you very much in advance. With best regards, Subas Bastola