From owner-ibis  Thu Mar  2 22:06:33 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 WAA20247 for <ibis@eda.org>; Thu, 2 Mar 2000 22:06:32 -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 XAA26681
	for <ibis@eda.org>; Thu, 2 Mar 2000 23:04:46 -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 XAA26670
	for <ibis@eda.org>; Thu, 2 Mar 2000 23:04:44 -0700 (MST)
Received: by ntxsing01.sing.micron.com with Internet Mail Service (5.5.2650.21)
	id <FDXQ710R>; Fri, 3 Mar 2000 14:04:54 +0800
Message-ID: <356BECDFCC89D21182080008C71E4173019465C2@ntxsing02.sing.micron.com>
From: subas <subas@micron.com>
To: ibis@eda.org
Subject: .ebd support
Date: Fri, 3 Mar 2000 14:04:32 +0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"

Hi IBISians,

Which SI tools support .ebd (IBIS Version 3.2)format to simulate board-level
components such as DIMM/SIMM boards?


Side question (you will get a bonus mark):

Is there any higher frequency limit on the suitability of IBIS models? The
L, C and R values (for each pin and for the inter-pin matrix in the package
model) change due to frequency (due to the change in relative permeability,
relative permittivity and skin effects respectively). Is it possible to
simply interpolate the values to your operating freqency? What are the other
effects that can degrade IBIS' usability?


With best regards,
Subas Bastola
From owner-ibis  Fri Mar  3 16:49:36 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 QAA24824 for <ibis@eda.org>; Fri, 3 Mar 2000 16:49:35 -0800 (PST)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id QAA29439
	for <ibis@eda.org>; Fri, 3 Mar 2000 16:48:17 -0800 (PST)
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Sat, 04 Mar 2000 00:48:15 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0)
	id <FFKTQ75B>; Fri, 3 Mar 2000 16:48:14 -0800
Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069A82@orsmsx49.jf.intel.com>
From: "Peters, Stephen" <stephen.peters@intel.com>
To: "'ibis@eda.org'" <ibis@eda.org>
Subject: Bird 62.5 -- Enhanced Specification of Receiver Thresholds
Date: Fri, 3 Mar 2000 16:48:12 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"


Hello All:

    Below is a revised version of Bird 62.  This version will be
voted on at the next IBIS teleconference.  The major change 
from Bird 62.4 is the breaking the Input_edge_rate subparameter 
into two seperate subparameters, one for single ended, the other for
differential receivers.  In addition, there where a few typo corrections.
Please review, and let me know soon of any other issues.

   Regards,
   Stephen Peters
   Intel Corp.




                  Buffer Issue Resolution Document  (BIRD)
 
 BIRD ID#:      62.5
 ISSUE TITLE:   Enhanced Specification of Receiver Thresholds
 REQUESTER:     DC Sessions (Philips), Stephen Peters, Richard Mellitz,
                Arpad Muranyi (Intel Corp).
 DATE SUBMITTED:  Aug 24, 1999, Dec 28, 1999, Jan 6, 2000, Feb 18, 2000,
                  Feb 25, 2000, Mar 3, 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.  This bird also provides for 
 specifying differential receivers and minimum edge rates.
 
****************************************************************************
 
 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,
|               Threshold_sensitivity, Reference_supply, Vcross_low, 
|               Vcross_high, Vdiff_ac, Vdiff_dc, Input_edge_rate_ser,
|               Input_edge_rate_der.
|  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
|               voltages 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.  Vinl_dc is 
|               expressed as an offset from Vth.
|
|               Threshold_sensitivity is a unit less number that specifies
|               how Vth varies with respect to the supply voltage defined 
|               by the Reference_supply subparameter. Threshold_sensitivity
|               is defined as:
|
|                                   change in input threshold voltage
|         Threshold_sensitivity = ------------------------------------
|                                  change in referenced supply voltage
|
|               Threshold_sensitivity must be entered as a whole number or
|               decimal, not as a fraction.
|
|               Reference_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 as follows:
|               Power_clamp_ref (the supply voltage defined by the
|                                [POWER Clamp Reference] keyword)
|               Gnd_clamp_ref   (the supply voltage defined by the 
|                                [GND Clamp Reference] keyword)
|               Pullup_ref      (the supply voltage defined by the
|                                [Pullup reference] keyword)
|               Pulldown_ref    (the supply voltage defined by the
|                                [Pulldown reference] keyword)
|               Ext_ref         (the supply voltage defined by the 
|                                [External Reference] keyword)
|
|
|               Input_edge_rate_ser documents the minimum edge rate 
|               condition under which a single ended receivers' input 
|               setup and hold timings are valid.  Note that minimum
|               edge rate correspondes to the maximum transistion time.
|               The input signals edge rate is calculated as shown below:
|
|                                       Vinh_ac - Vinl_ac
| Input_edge_rate_ser  = ------------------------------------------------
|                        time in transition between the above two voltages.
|
|               Input_edge_rate_ser must be entered as an unreduced 
|               fraction with the numerator representing the actual deltaV 
|               and the denominator representing the actual deltaT.
|
|
|               Input_edge_rate_ser documents the minimum edge rate 
|               condition under which a differential receivers' input 
|               setup and hold timings are valid.  Note that minimum
|               edge rate correspondes to the maximum transistion time.
|               The input signals edge rate is calculated as shown below:
|
|                                         Vdiff_ac
| Input_edge_rate_der  = ------------------------------------------------
|                        time in transition across the above voltage
|
|
|               Input_edge_rate_der must be entered as an unreduced
fraction,
|               with the numerator representing the actual deltaV and the
|               denominator representing the actual deltaT.
|
|               Vcross_low is the least positive voltage at which a 
|               differential receivers' input signals may cross while 
|               switching and still allow the receiver to meet its timing 
|               and functional specifications.  Vcross_low is specified
|               with respect to 0V.
|
|               Vcross_high is the most positive voltage at which a 
|               differential receivers' input signals may cross while 
|               switching and still allow the receiver to meet its timing 
|               and functional specifications.  Vcross_high is specified
|               with respect to 0V.
|
|               Vdiff_dc is the minimum voltage difference between the 
|               inputs of a differential receiver that guarantees the
|               receiver will not change state.
|
|               Vdiff_ac is the minimum voltage difference between the 
|               inputs of a differential receiver that guarantees the 
|               receiver will change state.
|
|
|
| Usage Rules:  The [Receiver Thresholds] keyword is valid if the model type
|               includes any reference to input or I/O.  For single ended
|               receivers the Vinh_ac, Vinh_dc, Vinl_ac, Vinh_dc, Vth and
|               Input_edge_rate_ser subparameters are required and override 
|               the Vinh, Vinl, Vinh+/- and Vinl+/- subparameters declared 
|               under the [Model] or [Model Spec] keywords.  For single
ended
|               receivers the Vth_min, Vth_max, Threshold_sensitivity and 
|               Reference_supply subparameters are optional.  However, if 
|               the Threshold_sensitivity subparameter is present then the 
|               Reference_supply subparameter must also be present.
|
|               For differential receivers (i.e. the [Receiver Thresholds]
|               keyword is part of a [Model] statement that describes a pin 
|               listed in the [Diff Pin] keyword) then the Vcross_low,
|               Vcross_high, Vdiff_ac, Vdiff_dc and Input_edge_rate_der
|               subparameters are required. The rest of the subparameters
|               are not applicable.  The Vdiff_ac and Vdiff_dc values 
|               override the value of the Vdiff subparameter specified by 
|               the [Diff Pin] keyword.  Note that Vcross_low and 
|               Vcross_high are valid over the device's minimum and maximum 
|               operating conditions. 
|
|               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
|               Reference_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* + [(Threshold_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
|               Reference_Supply subparameter.
|
|
|
| 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
Input_edge_rate_ser = 450mV/1.5ns
|
|
| A single ended receiver using an external threshold reference.  In this
| case the input threshold is the external reference voltage so
| Threshold_sensitivity equals 1.
|
Vth = 1.0V
Threshold_sensitivity = 1
Reference_Supply Ext_ref
Vinh_ac = +200mV
Vinh_dc = +100mV
Vinl_ac = -200mV
Vinl_dc = -100mV
Input_edge_rate_ser = 400mV/0.4ns
|
|
| A fully specified single ended 3.3v CMOS receiver
|
Vth = 1.5V
Vth_min = 1.45V
Vth_max = 1.53V
Threshold_sensitivity = 0.45
Reference_supply Power_clamp_ref
Vinh_ac = +200mV
Vinh_dc = +100mV
Vinl_ac = -200mV
Vinl_dc = -100mV
Input_edge_rate_ser = 400mV/0.4ns
|
|
| A differential receiver
|
Vcross_low = 0.65V
Vcross_high = 0.90V
Vdiff_ac = +200mV
Vdiff_dc = +100mV
Input_edge_rate_der = 200mV/0.5ns

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.
|               Note that the numerically largest value should be placed in
|               'max' column, while the numerically smallest value should
|               be placed in the 'min' column. 
|               
|--------------------------------------------------------------------------
| variable              typ          min           max
[External Reference]    1.0v         0.95v        1.05v


***************************************************************************
 
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 separating arguments from subparameters.
Updated examples with this change.

Update for 62.3
  The subparameter Input_Ref_Supply was renamed to Reference_supply
(this is to be consistent with other subparameter names).  The
list of arguments to the Reference_supply subparameter was expanded
and clarified. A note was added to the [External Reference]
keyword clarifying which values go in the min and max columns of this
keyword. Finally, four new subparameters that describe differential
receivers were added.

Update for 62.4
  Renamed Vth_sensitivity to Threshold_sensitivity.  Remaned the
voltage cross parameters to Vcross_low and Vcross_high.  Added the
Input_edge_rate subparameter from Bird 63.3.  Input_edge_rate now 
follows the precise JEDEC definition.  Finally, removed the section
that made the arguments to the Reference_supply subparameter reserved
words.  They are simply enumerated arguments with a defined value,
not reserved words with special meanings.

Update for 62.5
  Broke the Input_edge_rate subparameter into one for single ended and
one for differential receivers.  Removed the clause regarding Vcross_low
and Vcross_high tracking the min/max corners. Corrected a few typos.

***************************************************************************

ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a
request by the JEDEC JC-16 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 Mellitz and Arpad Muranyi of Intel Corp.
 
****************************************************************************





From owner-ibis  Mon Mar  6 09:26:17 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 JAA04364; Mon, 6 Mar 2000 09:26:16 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id JAA11165; Mon, 6 Mar 2000 09:24:27 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id JAA02270; Mon, 6 Mar 2000 09:24:26 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38C3E9C9.51735238@mentor.com>
Date: Mon, 06 Mar 2000 09:24:25 -0800
From: Bob Ross <bob_ross@mentorg.com>
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 - DesignCon 2000 [Fwd: CD Rom Discounts]
Content-Type: multipart/mixed;
 boundary="------------8F040FA1B8AC3341D761B41E"

This is a multi-part message in MIME format.
--------------8F040FA1B8AC3341D761B41E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

I am forwarding this offer to the IBIS reflectors for
DesignCon 2000 Proceedings.  

Note, that employees of EIA IBIS Open Forum Members will
receive the best discount.

Bob Ross
Mentor Graphics
--------------8F040FA1B8AC3341D761B41E
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 LAA26241; Fri, 3 Mar 2000 11:56:38 -0800 (PST)
Received: from relay1.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id LAA26241; Fri, 3 Mar 2000 11:56:38 -0800 (PST)
Received: from dns.ripco.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id LAA11184; Fri, 3 Mar 2000 11:56:39 -0800 (PST)
Received: from mail2.iec.org [204.242.115.66] by dns.ripco.com with esmtp
	(RIPCO #1) id m12QyBw-003AQAC; Fri, 3 Mar 2000 13:56:52 -0600 (CST)
Received: by MAIL2 with Internet Mail Service (5.5.2448.0)
	id <FPADS0K7>; Fri, 3 Mar 2000 14:04:07 -0600
Message-ID: <90F13E4F338DD3119CAD009027CC8297054AFC@MAIL2>
From: David Erickson <DErickson@iec.org>
To: "'bobross@mentor.com'" <bob_ross>
Subject: CD Rom Discounts
Date: Fri, 3 Mar 2000 14:03:59 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF854B.A18802B0"
X-Mozilla-Status2: 00000000

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_01BF854B.A18802B0
Content-Type: text/plain;
	charset="iso-8859-1"

Bob, thank you, and IBIS for all of your participation at DesignCon 2000.
We are looking forward to continuing the relationship in 2001.  Below is the
text for our CD-Rom Discounts, that we request be placed on the IBIS
reflector, and included in an e-mail to your recipients, as appropriate.
Please let me know your thoughts about this, and get back to me when you
have a moment.  

 

Save more than 25% with post conference discounts!  <?xml:namespace prefix =
o ns = "urn:schemas-microsoft-com:office:office" />

DesignCon 2000 educational sessions were well attended by design engineers
searching for new techniques and strategies from the industry's leading
experts. The DesignCon 2000 CD-ROM Proceedings offer the most valuable
conference information at an affordable price, allowing you to build upon
your library of knowledge in design engineering. 

 View the entire list of presentations on line at
www.designcon.com/2001/2000proceedings.html and order on-line today!

 Single CD-ROM was $95.00 - now $75.00!

Full CD-ROM was $325.00 - now $240.00! 

 

Take advantage of these special discounts: 

 Receive an additional 10% off the discounted price if your company is a
member or you are an employee of any sponsor. Full Proceedings: $216.00,
Single Proceedings: $67.50.  

 Our sponsors are Agilent Technologies, Cahner's Electronics Group, IBIS,
SIA, PCI-SIG, VSIA, VCX, and RAPID. 

 Special Student Discount:  Receive a full 30% off the already discounted
price!  

Full Proceedings: $168.00, Single Proceedings: $52.50 (proper ID required) 

  


System-on-Chip Design 

 

$75.00 (28 Papers)

 


High-Performance System Design

 

$75.00 (34 Papers)

 


Wireless and Broadband Design

 

$75.00 (30 Papers)

 


Intellectual Property World Forum

 

$75.00 (29 Papers)

 

 

 Best Value:      The full set of proceedings            $240.00 (121
papers)                 

 


Subtotal

 

 

$____________

 

 

 


Domestic Order Processing

$10.00

 

$____________

 

 

 


International Order Processing

$25.00

 

$____________

 

 

 


Total

 

 

$____________

 

 

 

 

To order via credit card, return this fax form today to +1-312-559-4111 or
call Julie Brandt at +1-312-559-4609. 

 

 

Credit Card #______________________________________________

 

EXP _____/______  (MM/YY)

 

Name of Cardholder: _______________________________________

 

[  ] VISA  [  ]   MASTERCARD  [  ] AMEX   [  ] DISCOVER   [  ] DINERS


------_=_NextPart_001_01BF854B.A18802B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY><FONT size=2>
<DIV class=Section1>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><SPAN 
class=634124219-03032000>Bob, thank you, and IBIS for all of your participation 
at DesignCon 2000.&nbsp; We are looking forward to continuing the relationship 
in 2001.&nbsp; Below is the text for our CD-Rom Discounts, that we request be 
placed on the IBIS reflector, and included in an e-mail to your recipients, as 
appropriate.&nbsp; Please let me know your thoughts about this, and get back to 
me when you have a moment.&nbsp; </SPAN></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"></SPAN>&nbsp;</P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Save 
more than 25% with post conference discounts!<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN></SPAN></B><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><?xml:namespace 
prefix = o ns = "urn:schemas-microsoft-com:office:office" 
/><o:p></o:p></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><SPAN 
class=634124219-03032000>D</SPAN></SPAN><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">esignCon 
2000 educational sessions were well attended by design engineers searching for 
new techniques and strategies from the industry&#8217;s leading experts. The <B 
style="mso-bidi-font-weight: normal">DesignCon 2000 CD-ROM Proceedings</B> offer 
the most valuable conference information at an affordable price, allowing you to 
build upon your library of knowledge in design engineering. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;</SPAN><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">View 
the entire list of presentations on line at<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN><U><SPAN 
style="COLOR: blue">www.designcon.com/2001/2000proceedings.html</SPAN></U> and 
order on-line today!<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;</SPAN><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Single 
CD-ROM was $95.00 - <B style="mso-bidi-font-weight: normal">now 
$75.00!<o:p></o:p></B></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Full 
CD-ROM was $325.00 - <B style="mso-bidi-font-weight: normal">now $240.00! 
<o:p></o:p></B></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Take 
advantage of these special discounts: <o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;</SPAN></B><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Receive 
an additional 10% off the discounted price if your company is a member or you 
are an employee of any sponsor.<B style="mso-bidi-font-weight: normal"> Full 
Proceedings: $216.00, Single Proceedings: $67.50. </B><SPAN 
style="mso-spacerun: yes">&nbsp;</SPAN><o:p></o:p></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-style: italic">&nbsp;</SPAN><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Our 
sponsors are Agilent Technologies, Cahner&#8217;s Electronics Group,&nbsp;<SPAN 
class=634124219-03032000>IBIS, </SPAN>SIA, PCI-SIG, VSIA, VCX, and RAPID. 
<o:p></o:p></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;</SPAN><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Special 
Student Discount: </SPAN></B><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><SPAN 
style="mso-spacerun: yes">&nbsp;</SPAN>Receive a full 30% off the already 
discounted price!<SPAN style="mso-spacerun: yes">&nbsp; 
</SPAN><o:p></o:p></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><B><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Full 
Proceedings: $168.00, Single Proceedings: $52.50 (proper ID required) 
<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;</SPAN></B>
<TABLE border=0 cellPadding=0 cellSpacing=0 
style="BORDER-COLLAPSE: collapse; WIDTH: 483.3pt; mso-padding-alt: 0in 5.4pt 0in 5.4pt" 
width=644>
  <TBODY>
  <TR>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 162.9pt" 
    vAlign=top width=217>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">System-on-Chip 
      Design <o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 99pt" 
    vAlign=top width=132>
      <P class=MsoNormal style="MARGIN-LEFT: 17.1pt; mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$75.00 
      (28 Papers)<o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD></TR>
  <TR>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 162.9pt" 
    vAlign=top width=217>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">High-Performance 
      System Design<o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 99pt" 
    vAlign=top width=132>
      <P class=MsoNormal style="MARGIN-LEFT: 17.1pt; mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$75.00 
      (34 Papers)<o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD></TR>
  <TR>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 162.9pt" 
    vAlign=top width=217>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Wireless 
      and Broadband Design<o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 99pt" 
    vAlign=top width=132>
      <P class=MsoNormal style="MARGIN-LEFT: 17.1pt; mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$75.00 
      (30 Papers)<o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD></TR>
  <TR>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 162.9pt" 
    vAlign=top width=217>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Intellectual 
      Property World Forum<o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 99pt" 
    vAlign=top width=132>
      <P class=MsoNormal style="MARGIN-LEFT: 17.1pt; mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$75.00 
      (29 Papers)<o:p></o:p></SPAN></P></TD>
    <TD 
    style="PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 110.7pt" 
    vAlign=top width=148>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD></TR></TBODY></TABLE></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal style="mso-pagination: none"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;</SPAN><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Best 
Value:<SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>The 
full set of proceedings<SPAN 
style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN>$240.00 (121 papers)<SPAN 
style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN><SPAN 
style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN><o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></B></P>
<TABLE border=0 cellPadding=0 cellSpacing=0 
style="BORDER-COLLAPSE: collapse; mso-padding-alt: 0in 5.4pt 0in 5.4pt; mso-table-layout-alt: fixed">
  <TBODY>
  <TR style="HEIGHT: 27.4pt">
    <TD 
    style="HEIGHT: 27.4pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 171.9pt" 
    vAlign=top width=229>
      <P class=MsoNormal style="mso-pagination: none"><B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Subtotal<o:p></o:p></SPAN></B></P></TD>
    <TD 
    style="HEIGHT: 27.4pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.75in" 
    vAlign=top width=72>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 27.4pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.5in" 
    vAlign=top width=48>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 27.4pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 94.5pt" 
    vAlign=top width=126>
      <P class=MsoNormal style="mso-pagination: none"><B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$____________<o:p></o:p></SPAN></B></P></TD>
    <TD 
    style="HEIGHT: 27.4pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 37.65pt" 
    vAlign=top width=50>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 27.4pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 27.4pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD></TR>
  <TR style="HEIGHT: 26.95pt">
    <TD 
    style="HEIGHT: 26.95pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 171.9pt" 
    vAlign=top width=229>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Domestic 
      Order Processing<o:p></o:p></SPAN></P></TD>
    <TD 
    style="HEIGHT: 26.95pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.75in" 
    vAlign=top width=72>
      <P class=MsoNormal 
      style="MARGIN-LEFT: 3pt; TEXT-INDENT: -3.9pt; mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$10.00<o:p></o:p></SPAN></P></TD>
    <TD 
    style="HEIGHT: 26.95pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.5in" 
    vAlign=top width=48>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="HEIGHT: 26.95pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 94.5pt" 
    vAlign=top width=126>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$____________<o:p></o:p></SPAN></P></TD>
    <TD 
    style="HEIGHT: 26.95pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 37.65pt" 
    vAlign=top width=50>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="HEIGHT: 26.95pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="HEIGHT: 26.95pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD></TR>
  <TR style="HEIGHT: 45.9pt">
    <TD 
    style="HEIGHT: 45.9pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 171.9pt" 
    vAlign=top width=229>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">International 
      Order Processing<o:p></o:p></SPAN></P></TD>
    <TD 
    style="HEIGHT: 45.9pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.75in" 
    vAlign=top width=72>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$25.00<o:p></o:p></SPAN></P></TD>
    <TD 
    style="HEIGHT: 45.9pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.5in" 
    vAlign=top width=48>
      <P class=MsoNormal style="mso-pagination: none"><FONT 
      face=Arial>&nbsp;<SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></FONT></P></TD>
    <TD 
    style="HEIGHT: 45.9pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 94.5pt" 
    vAlign=top width=126>
      <P class=MsoNormal style="mso-pagination: none"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$____________<B 
      style="mso-bidi-font-weight: normal"><o:p></o:p></B></SPAN></P></TD>
    <TD 
    style="HEIGHT: 45.9pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 37.65pt" 
    vAlign=top width=50>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 45.9pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 45.9pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD></TR>
  <TR style="HEIGHT: 26.05pt">
    <TD 
    style="HEIGHT: 26.05pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 171.9pt" 
    vAlign=top width=229>
      <P class=MsoNormal style="mso-pagination: none"><B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Total<o:p></o:p></SPAN></B></P></TD>
    <TD 
    style="HEIGHT: 26.05pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.75in" 
    vAlign=top width=72>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 26.05pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 0.5in" 
    vAlign=top width=48>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 26.05pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 94.5pt" 
    vAlign=top width=126>
      <P class=MsoNormal style="mso-pagination: none"><B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">$____________<o:p></o:p></SPAN></B></P></TD>
    <TD 
    style="HEIGHT: 26.05pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 37.65pt" 
    vAlign=top width=50>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 26.05pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD>
    <TD 
    style="HEIGHT: 26.05pt; PADDING-BOTTOM: 0in; PADDING-LEFT: 5.4pt; PADDING-RIGHT: 5.4pt; PADDING-TOP: 0in; WIDTH: 83.1pt" 
    vAlign=top width=111>
      <P class=MsoNormal style="mso-pagination: none"><FONT face=Arial>&nbsp;<B 
      style="mso-bidi-font-weight: normal"><SPAN 
      style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><o:p></o:p></SPAN></B></FONT></P></TD></TR></TBODY></TABLE>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'"><SPAN 
style="mso-tab-count: 1">&nbsp;</SPAN></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">To 
order via credit card, return this fax form today to +1-312-559-4111 or call 
Julie Brandt at +1-312-559-4609. <o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Credit 
Card #______________________________________________<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">EXP 
_____/______<SPAN style="mso-spacerun: yes">&nbsp; 
</SPAN>(MM/YY)<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">Name 
of Cardholder: _______________________________________<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=MsoNormal style="mso-pagination: none"><B 
style="mso-bidi-font-weight: normal"><SPAN 
style="FONT-FAMILY: Arial; LAYOUT-GRID-MODE: line; mso-bidi-font-family: 'Times New Roman'">[<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>] VISA<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>[<SPAN style="mso-spacerun: yes">&nbsp; 
</SPAN>]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>MASTERCARD<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>[<SPAN style="mso-spacerun: yes">&nbsp; 
</SPAN>] AMEX<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>[<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>] DISCOVER<SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>[<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>] 
DINERS</SPAN></B></P></DIV></FONT></BODY></HTML>

------_=_NextPart_001_01BF854B.A18802B0--

--------------8F040FA1B8AC3341D761B41E--

From owner-ibis  Tue Mar  7 17:30: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 RAA12961; Tue, 7 Mar 2000 17:30:11 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id RAA23105; Tue, 7 Mar 2000 17:28:21 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id RAA13192; Tue, 7 Mar 2000 17:28:19 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38C5ACB3.E489EBDB@mentor.com>
Date: Tue, 07 Mar 2000 17:28:19 -0800
From: Bob Ross <bob_ross@mentorg.com>
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: IBIS EUROPEAN SUMMIT MEETING THIRD ANNOUNCEMENT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

Please signup if you plan to attend.  Note, the signup person
has changed.  If you have any questions, contact me at the 
number at the end.

Bob Ross
Mentor Graphics

            E U R O P E A N   I B I S   S U M M I T   M E E T I N G
                      T H I R D   A N N O U N C E M E N T

Time/Date:     8:30 AM - 2 PM, Friday, March 31, 2000

Location:      Concorde-Lafayette Hotel (adjacent to Le Palais des 
               Congress de Paris Porte 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:      Cadence, 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
  

TENTATIVE AGENDA SO FAR (titles may change)

Agenda includes presentations, discussions and a free lunch.  Some
presentations planned so far include:

Siemens IBIS Modeling Requirements for Semiconductor Vendors
Gerald Bannert, Siemens

IEC EMC/EMI Standardization Update
Jean Claude Perrin, Texas Instruments

Tips and Techniques for Creating IBIS Models
Cary Mandell, Viewlogic

IBIS Accuracy Study
Sherif Hammad, Mentor Graphics

Behavioral Receiver Modeling
Patrick Dos Santos, Cadence Design Systems

IBIS Future Directions
Bob Ross, Mentor Graphic


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:

  Francoise Lindecker (francoise_lindecker@mentor.com

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)


FOR FURTHER INFORMATION:

Bob Ross,
Chair, EIA/IBIS Open Forum
Mentor Graphics
8005 S.W. Boeckman Road
Wilsonville, Oregon 97070
USA

(503) 685-0732
bob_ross@mentor.com
From owner-ibis  Wed Mar  8 14:52:16 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 OAA18655 for <ibis@eda.org>; Wed, 8 Mar 2000 14:52:15 -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 RAA11133
	for <ibis@eda.org>; Wed, 8 Mar 2000 17:50:21 -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 RAA22960
	for <ibis@eda.org>; Wed, 8 Mar 2000 17:50:20 -0500 (EST)
Received: from pc-chrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id OAA10473
	for <ibis@eda.org>; Wed, 8 Mar 2000 14:48:54 -0800 (PST)
From: "Chris Rokusek" <crokusek@viewlogic.com>
To: "Ibis@Eda. Org" <ibis@eda.org>
Subject: Bus Clamp vs Dynamic Clamp
Date: Wed, 8 Mar 2000 14:52:43 -0800
Message-ID: <002501bf8951$038027f0$aac2b58b@pc-chrisr.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

Hi Ibis-gurus,

I've got a question:

I'm wondering what the differences are between:

  1) "Static Mode" of a Dynamic Clamp Sub-model

        vs.

  2) Bus Hold Sub-Model.


If there are no differences, is there any reason we really need the
redundancy and extra confusing verbage defining what Static Mode is?

Chris

From owner-ibis  Thu Mar  9 13:04:58 2000
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA25291 for <ibis@vhdl.org>; Thu, 9 Mar 2000 13:04:57 -0800 (PST)
From: gedlund@us.ibm.com
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA382654
	for <ibis@vhdl.org>; Thu, 9 Mar 2000 16:02:16 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33])
	by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id QAA51600
	for <ibis@vhdl.org>; Thu, 9 Mar 2000 16:03:35 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525689D.0073A962 ; Thu, 9 Mar 2000 16:03:20 -0500
X-Lotus-FromDomain: IBMUS
To: ibis@vhdl.org
Message-ID: <8525689D.00733CAE.00@D51MTA05.pok.ibm.com>
Date: Thu, 9 Mar 2000 14:58:44 -0600
Subject: Re: Bus Clamp vs Dynamic Clamp
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

As long as we're on the subject, what determines the current-voltage
behavior of a dynamic clamp in triggered mode once it's on?  Is the [GND
Clamp] keyword defined under the [Submodel] intended to supply the IV
characteristics of the ground dynamic clamp?  And the [GND Pulse Table] is
supposed to supply a voltage offset to the [GND Clamp] table for each point
in time that the clamp is on?  So if I'm a simulator and I notice that Vpin
has tripped V_trigger_f, I calculate Vpin-Vpulse and dump the current that
I find at the corresponding entry in [GND Clamp]?

Sounds like some stuff I can't measure directly from the pin, right?

Greg Edlund
Advisory Engineer, Critical Net Analysis
IBM
3650 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
gedlund@us.ibm.com


From owner-ibis  Fri Mar 10 12:10:13 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 MAA00537 for <ibis@eda.org>; Fri, 10 Mar 2000 12:10:12 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id MAA24023; Fri, 10 Mar 2000 12:08:22 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id MAA21213; Fri, 10 Mar 2000 12:08:19 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38C95634.F6C25F41@mentor.com>
Date: Fri, 10 Mar 2000 12:08:20 -0800
From: Bob Ross <bob_ross@mentorg.com>
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
CC: bob_ross@mentorg.com
Subject: IBIS Meeting Agenda 3/17/2000
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


                     IBIS Open Forum Meeting Agenda 
                               for 3/17/00

                 Bridge Number    Reservation #   Passcode
                 (916) 356-9200   4-299298        8432634

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
    
     DATE2000 IBIS Summit Planning                           Ross

     DAC2000 IBIS Summit Meeting Planning                    Ross

     Cookbook Status                                         Peters

     IBIS Model Review Committee                             Flora

     New Administrative Issues                               All

8:45 Technical Discussion (some topics may be deferred)

     BIRD62.5 - Enhanced Chararcterization of Receiver       Peters
              Thresholds (Vote)

     BIRD63.3 - Documentation of Receiver Setup and Hold     Peters
              Timing Conditions (Vote)

     BIRD66 - [Model Spec] Vref Addition                     McMorrow/Ross

     Connector Proposal Review (Continued)              Panella/Chrisafulli

     ibischk3 Bug Tracking                                   Ross
     - BUG34 - No Error Reported for Missing V/I Tables      Flora
             in Output Buffers
     - Repeated Voltage
     - 8.3 Version 2.1 Error
     - Series element does not work with I/O models

     IBIS Futures Group Report (IBIS-X, API, BIRDxx)         Peters

     BIRD61.1 - Enhanced Characterization of Receivers       Peters

     BIRD64.1 - Package Model Selector                       Muranyi

     BIRD65 - C_comp Refinements                             Muranyi

     New Technical Issues                                    All

9:50 Wrap Up and Next Meetings Plans                         Peters

9:55 Sign Off
From owner-ibis  Fri Mar 10 12:46: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 MAA00645 for <ibis@eda.org>; Fri, 10 Mar 2000 12:45:59 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id MAA26738; Fri, 10 Mar 2000 12:44:09 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id MAA28271; Fri, 10 Mar 2000 12:44:05 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38C95E96.BA38B4BC@mentor.com>
Date: Fri, 10 Mar 2000 12:44:06 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris Rokusek <crokusek@viewlogic.com>
CC: "Ibis@Eda. Org" <ibis@eda.org>
Subject: Re: Bus Clamp vs Dynamic Clamp
References: <002501bf8951$038027f0$aac2b58b@pc-chrisr.camarillo.viewlogic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris:

Briefly, the Bus Hold submodel always
always operates in the triggered mode
and optionally with an Off_delay.  So
it does not have a Static mode.

Bob Ross
Mentor Graphics


Chris Rokusek wrote:
> 
> Hi Ibis-gurus,
> 
> I've got a question:
> 
> I'm wondering what the differences are between:
> 
>   1) "Static Mode" of a Dynamic Clamp Sub-model
> 
>         vs.
> 
>   2) Bus Hold Sub-Model.
> 
> If there are no differences, is there any reason we really need the
> redundancy and extra confusing verbage defining what Static Mode is?
> 
> Chris
From owner-ibis  Fri Mar 10 12:54:36 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 MAA00687 for <ibis@vhdl.org>; Fri, 10 Mar 2000 12:54:35 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id MAA27293; Fri, 10 Mar 2000 12:52:38 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id MAA29829; Fri, 10 Mar 2000 12:52:35 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38C96094.2FEC8ED1@mentor.com>
Date: Fri, 10 Mar 2000 12:52:36 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: gedlund@us.ibm.com
CC: ibis@vhdl.org
Subject: Re: Bus Clamp vs Dynamic Clamp
References: <8525689D.00733CAE.00@D51MTA05.pok.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg:

I have some brief responses are in your text.

Bob Ross
Mentor Graphics


gedlund@us.ibm.com wrote:
> 
> As long as we're on the subject, what determines the current-voltage
> behavior of a dynamic clamp in triggered mode once it's on?  Is the [GND
> Clamp] keyword defined under the [Submodel] intended to supply the IV
> characteristics of the ground dynamic clamp? 

Yes?  This supplies the characteristics of a clamp portion that may be
shifted in time.

> And the [GND Pulse Table] is
> supposed to supply a voltage offset to the [GND Clamp] table for each point
> in time that the clamp is on?  

Yes

> So if I'm a simulator and I notice that Vpin
> has tripped V_trigger_f, I calculate Vpin-Vpulse and dump the current that
> I find at the corresponding entry in [GND Clamp]?

I do not understand this question.

> 
> Sounds like some stuff I can't measure directly from the pin, right?

You can measure the combined effects, but you may not have information
from measurement that can decompose the effects into the mainline
and submodel elements.  This along with some other keywords are to
provide models by construction to emulate some known effects that
might be extracted or known by decomposing a buffer circuit.

> 
> Greg Edlund
> Advisory Engineer, Critical Net Analysis
> IBM
> 3650 Hwy. 52 N, Dept. HDC
> Rochester, MN 55901
> gedlund@us.ibm.com
From owner-ibis  Fri Mar 10 14:09:33 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 OAA00900 for <ibis@eda.org>; Fri, 10 Mar 2000 14:09:32 -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 RAA09732
	for <ibis@eda.org>; Fri, 10 Mar 2000 17:07:41 -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 RAA25443
	for <ibis@eda.org>; Fri, 10 Mar 2000 17:07:40 -0500 (EST)
Received: from pc-chrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id OAA25208
	for <ibis@eda.org>; Fri, 10 Mar 2000 14:06:15 -0800 (PST)
From: "Chris Rokusek" <crokusek@viewlogic.com>
To: "Ibis@Eda. Org" <ibis@eda.org>
Subject: RE: Bus Clamp vs Dynamic Clamp
Date: Fri, 10 Mar 2000 14:10:09 -0800
Message-ID: <001b01bf8add$660d33d0$aac2b58b@pc-chrisr.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
In-Reply-To: <38C95E96.BA38B4BC@mentor.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

Let me rephrase:

If a Static Mode Dynamic Clamp submodel can be described as a Bus Hold
model, why do we need a static mode?

Think about this:

	There are two submodel types.

	Their are multiple modes for each type.

	The submodel itself is a type (in so much as its not a model).

	The submodel type can only be used under certain conditions of the parent
Model.

That's a lot of IF's just to effectively add a node to a circuit.

Customers keep calling asking me to interpret the IBIS Spec.  Therefore, I
conclude the spec must be difficult to understand.

The more TYPE's, RULE's, IF's, and MODE's there are in this spec, the more
difficult it becomes to comprehend and maintain.  Hey look that makes an
acronym:  TRIM!

Of course its MY FAULT just as much as anyone else's for allowing some of
these BIRDS to contain redundancies.  I'm hoping that we become more careful
as to what we are adding to the spec and perhaps we can even reduce and
simplify at some point.

Thanks for reading!

Chris Rokusek
Viewlogic Systems



> -----Original Message-----
> From: bob_ross@mentorg.com [mailto:bob_ross@mentorg.com]
> Sent: Friday, March 10, 2000 12:44 PM
> To: Chris Rokusek
> Cc: Ibis@Eda. Org
> Subject: Re: Bus Clamp vs Dynamic Clamp
>
>
> Chris:
>
> Briefly, the Bus Hold submodel always
> always operates in the triggered mode
> and optionally with an Off_delay.  So
> it does not have a Static mode.
>
> Bob Ross
> Mentor Graphics
>
>
> Chris Rokusek wrote:
> >
> > Hi Ibis-gurus,
> >
> > I've got a question:
> >
> > I'm wondering what the differences are between:
> >
> >   1) "Static Mode" of a Dynamic Clamp Sub-model
> >
> >         vs.
> >
> >   2) Bus Hold Sub-Model.
> >
> > If there are no differences, is there any reason we really need the
> > redundancy and extra confusing verbage defining what Static Mode is?
> >
> > Chris
>

From owner-ibis  Fri Mar 10 16:04:05 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 QAA01286 for <ibis@eda.org>; Fri, 10 Mar 2000 16:03:58 -0800 (PST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id AAA00370;
	Sat, 11 Mar 2000 00:02:03 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Sat, 11 Mar 2000 00:01:21 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <GPNYYGYL>; Fri, 10 Mar 2000 16:01:20 -0800
Message-ID: <4575832C8E71D111AC4100A0C96B51270645893F@fmsmsx36.fm.intel.com>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: "'Chris Rokusek'" <crokusek@viewlogic.com>,
        "Ibis@Eda. Org"
	 <ibis@eda.org>
Subject: RE: Bus Clamp vs Dynamic Clamp
Date: Fri, 10 Mar 2000 16:01:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

Chris,

These two were implemented for two completely different circuit
behaviors.  The dynamic clamp shifts the knee voltage of the clamp
based on some triggering events.  The bus hold circuit's I-V cure
goes through the origin, but it switches from a pullup to a pulldown
shape when it detects a certain voltage.  I don't see how these two
are the same, or how they could be described with only one of these two
keywords.

Arpad
====================================================================

-----Original Message-----
From: Chris Rokusek [mailto:crokusek@viewlogic.com]
Sent: Friday, March 10, 2000 2:10 PM
To: Ibis@Eda. Org
Subject: RE: Bus Clamp vs Dynamic Clamp


Let me rephrase:

If a Static Mode Dynamic Clamp submodel can be described as a Bus Hold
model, why do we need a static mode?

Think about this:

	There are two submodel types.

	Their are multiple modes for each type.

	The submodel itself is a type (in so much as its not a model).

	The submodel type can only be used under certain conditions of the
parent
Model.

That's a lot of IF's just to effectively add a node to a circuit.

Customers keep calling asking me to interpret the IBIS Spec.  Therefore, I
conclude the spec must be difficult to understand.

The more TYPE's, RULE's, IF's, and MODE's there are in this spec, the more
difficult it becomes to comprehend and maintain.  Hey look that makes an
acronym:  TRIM!

Of course its MY FAULT just as much as anyone else's for allowing some of
these BIRDS to contain redundancies.  I'm hoping that we become more careful
as to what we are adding to the spec and perhaps we can even reduce and
simplify at some point.

Thanks for reading!

Chris Rokusek
Viewlogic Systems



> -----Original Message-----
> From: bob_ross@mentorg.com [mailto:bob_ross@mentorg.com]
> Sent: Friday, March 10, 2000 12:44 PM
> To: Chris Rokusek
> Cc: Ibis@Eda. Org
> Subject: Re: Bus Clamp vs Dynamic Clamp
>
>
> Chris:
>
> Briefly, the Bus Hold submodel always
> always operates in the triggered mode
> and optionally with an Off_delay.  So
> it does not have a Static mode.
>
> Bob Ross
> Mentor Graphics
>
>
> Chris Rokusek wrote:
> >
> > Hi Ibis-gurus,
> >
> > I've got a question:
> >
> > I'm wondering what the differences are between:
> >
> >   1) "Static Mode" of a Dynamic Clamp Sub-model
> >
> >         vs.
> >
> >   2) Bus Hold Sub-Model.
> >
> > If there are no differences, is there any reason we really need the
> > redundancy and extra confusing verbage defining what Static Mode is?
> >
> > Chris
>


From owner-ibis  Fri Mar 10 16:55:11 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 QAA01402 for <ibis@eda.org>; Fri, 10 Mar 2000 16:55:10 -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 TAA11322
	for <ibis@eda.org>; Fri, 10 Mar 2000 19:53:21 -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 TAA29710
	for <ibis@eda.org>; Fri, 10 Mar 2000 19:53:19 -0500 (EST)
Received: from pc-chrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id QAA26417
	for <ibis@eda.org>; Fri, 10 Mar 2000 16:51:54 -0800 (PST)
From: "Chris Rokusek" <crokusek@viewlogic.com>
To: "Ibis@Eda. Org" <ibis@eda.org>
Subject: RE: Bus Clamp vs Dynamic Clamp
Date: Fri, 10 Mar 2000 16:55:49 -0800
Message-ID: <003601bf8af4$8aa1dc20$aac2b58b@pc-chrisr.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
In-Reply-To: <4575832C8E71D111AC4100A0C96B51270645893F@fmsmsx36.fm.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

Arpad,

The question was in regard to the ***STATIC MODE*** of Dynamic Clamp.  You
answered a different question.

After ten minutes of reading the spec I conlude that there are two ways to
specify additional static clamping of a given parent model when in a
particular state.

One can use a

	1) "Static Mode" Dynamic Clamp sub-model (means it doesn't have pulse
tables).

	2) "Bus Hold" with NULL I-V Pullup/Pulldown.

Right?

Chris




> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Friday, March 10, 2000 4:01 PM
> To: 'Chris Rokusek'; Ibis@Eda. Org
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Chris,
>
> These two were implemented for two completely different circuit
> behaviors.  The dynamic clamp shifts the knee voltage of the clamp
> based on some triggering events.  The bus hold circuit's I-V cure
> goes through the origin, but it switches from a pullup to a pulldown
> shape when it detects a certain voltage.  I don't see how these two
> are the same, or how they could be described with only one of these two
> keywords.
>
> Arpad
> ====================================================================
>
> -----Original Message-----
> From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> Sent: Friday, March 10, 2000 2:10 PM
> To: Ibis@Eda. Org
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Let me rephrase:
>
> If a Static Mode Dynamic Clamp submodel can be described as a Bus Hold
> model, why do we need a static mode?
>
> Think about this:
>
> 	There are two submodel types.
>
> 	Their are multiple modes for each type.
>
> 	The submodel itself is a type (in so much as its not a model).
>
> 	The submodel type can only be used under certain conditions of the
> parent
> Model.
>
> That's a lot of IF's just to effectively add a node to a circuit.
>
> Customers keep calling asking me to interpret the IBIS Spec.  Therefore, I
> conclude the spec must be difficult to understand.
>
> The more TYPE's, RULE's, IF's, and MODE's there are in this spec, the more
> difficult it becomes to comprehend and maintain.  Hey look that makes an
> acronym:  TRIM!
>
> Of course its MY FAULT just as much as anyone else's for allowing some of
> these BIRDS to contain redundancies.  I'm hoping that we become
> more careful
> as to what we are adding to the spec and perhaps we can even reduce and
> simplify at some point.
>
> Thanks for reading!
>
> Chris Rokusek
> Viewlogic Systems
>
>
>
> > -----Original Message-----
> > From: bob_ross@mentorg.com [mailto:bob_ross@mentorg.com]
> > Sent: Friday, March 10, 2000 12:44 PM
> > To: Chris Rokusek
> > Cc: Ibis@Eda. Org
> > Subject: Re: Bus Clamp vs Dynamic Clamp
> >
> >
> > Chris:
> >
> > Briefly, the Bus Hold submodel always
> > always operates in the triggered mode
> > and optionally with an Off_delay.  So
> > it does not have a Static mode.
> >
> > Bob Ross
> > Mentor Graphics
> >
> >
> > Chris Rokusek wrote:
> > >
> > > Hi Ibis-gurus,
> > >
> > > I've got a question:
> > >
> > > I'm wondering what the differences are between:
> > >
> > >   1) "Static Mode" of a Dynamic Clamp Sub-model
> > >
> > >         vs.
> > >
> > >   2) Bus Hold Sub-Model.
> > >
> > > If there are no differences, is there any reason we really need the
> > > redundancy and extra confusing verbage defining what Static Mode is?
> > >
> > > Chris
> >
>
>
>

From owner-ibis  Sun Mar 12 12:41:39 2000
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA07423 for <ibis@vhdl.org>; Sun, 12 Mar 2000 12:41:38 -0800 (PST)
From: gedlund@us.ibm.com
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA36634
	for <ibis@vhdl.org>; Sun, 12 Mar 2000 15:38:55 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33])
	by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id PAA136704
	for <ibis@vhdl.org>; Sun, 12 Mar 2000 15:40:15 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568A0.00718A8D ; Sun, 12 Mar 2000 15:40:10 -0500
X-Lotus-FromDomain: IBMUS
To: ibis@vhdl.org
Message-ID: <852568A0.00716DE0.00@D51MTA05.pok.ibm.com>
Date: Sun, 12 Mar 2000 14:38:56 -0600
Subject: Re: Bus Clamp vs Dynamic Clamp
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


[GREG]
> So if I'm a simulator and I notice that Vpin
> has tripped V_trigger_f, I calculate Vpin-Vpulse and dump the current
that
> I find at the corresponding entry in [GND Clamp]?

[BOB] I do not understand this question.

[GREG]
I was trying to understand the relationship between [GND Clamp] and [GND
Pulse Table].  It seems to me that [GND Pulse Table] is providing a link
between the voltage at the device pin and the current in the [GND Clamp]
table.  The links seems to be an offset voltage from the pin voltage that
can change from one timepoint to the next as defined by the VT table in
[GND Pulse Table].  Furthermore, the VT table isn't activated until the pin
voltage crosses V_trigger_r/f.  Am I understanding this correctly?

Greg Edlund
Advisory Engineer, Critical Net Analysis
IBM
3650 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
gedlund@us.ibm.com


From owner-ibis  Mon Mar 13 11:47: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 LAA11497 for <ibis@vhdl.org>; Mon, 13 Mar 2000 11:47:46 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id LAA20786; Mon, 13 Mar 2000 11:45:55 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id LAA15031; Mon, 13 Mar 2000 11:45:52 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38CD4571.B9F013EA@mentor.com>
Date: Mon, 13 Mar 2000 11:45:53 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: gedlund@us.ibm.com
CC: ibis@vhdl.org
Subject: Re: Bus Clamp vs Dynamic Clamp
References: <852568A0.00716DE0.00@D51MTA05.pok.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg:

Now I understand, and your point of view is correct.

The [GND Pulse Table] is an offset from the [GND Clamp Reference]
voltage (normally 0 V) that gets started at the the time that
the pin voltage passes through V_trigger_f.  That is
equivalent to locating Vpin - Vpulse on the table and dumping
that current into the pin.

Bob Ross
Mentor Graphics
 


gedlund@us.ibm.com wrote:
> 
> [GREG]
> > So if I'm a simulator and I notice that Vpin
> > has tripped V_trigger_f, I calculate Vpin-Vpulse and dump the current
> that
> > I find at the corresponding entry in [GND Clamp]?
> 
> [BOB] I do not understand this question.
> 
> [GREG]
> I was trying to understand the relationship between [GND Clamp] and [GND
> Pulse Table].  It seems to me that [GND Pulse Table] is providing a link
> between the voltage at the device pin and the current in the [GND Clamp]
> table.  The links seems to be an offset voltage from the pin voltage that
> can change from one timepoint to the next as defined by the VT table in
> [GND Pulse Table].  Furthermore, the VT table isn't activated until the pin
> voltage crosses V_trigger_r/f.  Am I understanding this correctly?
> 
> Greg Edlund
> Advisory Engineer, Critical Net Analysis
> IBM
> 3650 Hwy. 52 N, Dept. HDC
> Rochester, MN 55901
> gedlund@us.ibm.com
From owner-ibis  Mon Mar 13 14:58:57 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 OAA12155 for <ibis@eda.org>; Mon, 13 Mar 2000 14:58:50 -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 RAA01601
	for <ibis@eda.org>; Mon, 13 Mar 2000 17:56:58 -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 RAA12656
	for <ibis@eda.org>; Mon, 13 Mar 2000 17:56:57 -0500 (EST)
Received: from pc-chrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id OAA05593
	for <ibis@eda.org>; Mon, 13 Mar 2000 14:55:29 -0800 (PST)
From: "Chris Rokusek" <crokusek@viewlogic.com>
To: "Ibis@Eda. Org" <ibis@eda.org>
Subject: RE: Bus Clamp vs Dynamic Clamp
Date: Mon, 13 Mar 2000 14:59:29 -0800
Message-ID: <005001bf8d3f$c9ec8400$aac2b58b@pc-chrisr.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
In-Reply-To: <4575832C8E71D111AC4100A0C96B51270645893F@fmsmsx36.fm.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

Arpad,

> Even though I agree that it is not always good to have redundancy,
> I also may argue that some times it will happen.  For example,
> think how many different ways you can write a resistor in HSPICE.
> You can do it as an R-element, and also as either one of the
> four controlled sources.  Is that bad?

Yes, that is extrememly BAD if I am a user that only cares about R/L/C
circuits because my manual is thicker than it needs to be.  And if the
manually gets as big as my car because HSPICE can also beat Big Blue at
chess, then I won't use HSPICE to solve my linear circuit problem if I can
find an alternate easy to use solution that minimizes my time to solution
(and I don't have a garage/hard drive to hold the manual).

If I am a user that needs controlled sources then I answer no.

Of course Avanti will satisfy the majority of its users and better yet will
try to add features without increasing the user learning curve.

The point I was trying to make in the 3/10/2000 reply was that if it's
possible to simplify something that has many rules (e.g. order of
precedence):

1 + 2 * 5 * pi
-----------------
10 * pi + 1/1*1+0

Then do it!

The trick is to offer flexibility WITHOUT over-complicating things.  This is
not a new concept, software development goes through this process all the
time.  Start with a simple solution to a problem.  Then, add, add, and add
features to it.  Eventually you have something that needs to be simplified
because the added features "weigh" more than the original solution.

What are the examples in Hardware?  RISC, FPGA's?

Chris


> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Monday, March 13, 2000 2:12 PM
> To: 'Chris Rokusek'
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Chris,
>
> This sounds believable, but I have to admit that I would have
> to re-read the spec. to see whether it is correct.  This was not
> the intention, though.
>
> Even though I agree that it is not always good to have redundancy,
> I also may argue that some times it will happen.  For example,
> think how many different ways you can write a resistor in HSPICE.
> You can do it as an R-element, and also as either one of the
> four controlled sources.  Is that bad?
>
> Arpad
> ================================================================
>
> -----Original Message-----
> From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> Sent: Friday, March 10, 2000 4:56 PM
> To: Ibis@Eda. Org
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Arpad,
>
> The question was in regard to the ***STATIC MODE*** of Dynamic Clamp.  You
> answered a different question.
>
> After ten minutes of reading the spec I conlude that there are two ways to
> specify additional static clamping of a given parent model when in a
> particular state.
>
> One can use a
>
> 	1) "Static Mode" Dynamic Clamp sub-model (means it doesn't have
> pulse
> tables).
>
> 	2) "Bus Hold" with NULL I-V Pullup/Pulldown.
>
> Right?
>
> Chris
>
>
>
>
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Friday, March 10, 2000 4:01 PM
> > To: 'Chris Rokusek'; Ibis@Eda. Org
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Chris,
> >
> > These two were implemented for two completely different circuit
> > behaviors.  The dynamic clamp shifts the knee voltage of the clamp
> > based on some triggering events.  The bus hold circuit's I-V cure
> > goes through the origin, but it switches from a pullup to a pulldown
> > shape when it detects a certain voltage.  I don't see how these two
> > are the same, or how they could be described with only one of these two
> > keywords.
> >
> > Arpad
> > ====================================================================
> >
> > -----Original Message-----
> > From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> > Sent: Friday, March 10, 2000 2:10 PM
> > To: Ibis@Eda. Org
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Let me rephrase:
> >
> > If a Static Mode Dynamic Clamp submodel can be described as a Bus Hold
> > model, why do we need a static mode?
> >
> > Think about this:
> >
> > 	There are two submodel types.
> >
> > 	Their are multiple modes for each type.
> >
> > 	The submodel itself is a type (in so much as its not a model).
> >
> > 	The submodel type can only be used under certain conditions of the
> > parent
> > Model.
> >
> > That's a lot of IF's just to effectively add a node to a circuit.
> >
> > Customers keep calling asking me to interpret the IBIS Spec.
> Therefore, I
> > conclude the spec must be difficult to understand.
> >
> > The more TYPE's, RULE's, IF's, and MODE's there are in this
> spec, the more
> > difficult it becomes to comprehend and maintain.  Hey look that makes an
> > acronym:  TRIM!
> >
> > Of course its MY FAULT just as much as anyone else's for
> allowing some of
> > these BIRDS to contain redundancies.  I'm hoping that we become
> > more careful
> > as to what we are adding to the spec and perhaps we can even reduce and
> > simplify at some point.
> >
> > Thanks for reading!
> >
> > Chris Rokusek
> > Viewlogic Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: bob_ross@mentorg.com [mailto:bob_ross@mentorg.com]
> > > Sent: Friday, March 10, 2000 12:44 PM
> > > To: Chris Rokusek
> > > Cc: Ibis@Eda. Org
> > > Subject: Re: Bus Clamp vs Dynamic Clamp
> > >
> > >
> > > Chris:
> > >
> > > Briefly, the Bus Hold submodel always
> > > always operates in the triggered mode
> > > and optionally with an Off_delay.  So
> > > it does not have a Static mode.
> > >
> > > Bob Ross
> > > Mentor Graphics
> > >
> > >
> > > Chris Rokusek wrote:
> > > >
> > > > Hi Ibis-gurus,
> > > >
> > > > I've got a question:
> > > >
> > > > I'm wondering what the differences are between:
> > > >
> > > >   1) "Static Mode" of a Dynamic Clamp Sub-model
> > > >
> > > >         vs.
> > > >
> > > >   2) Bus Hold Sub-Model.
> > > >
> > > > If there are no differences, is there any reason we really need the
> > > > redundancy and extra confusing verbage defining what Static Mode is?
> > > >
> > > > Chris
> > >
> >
> >
> >
>
>
>

From owner-ibis  Mon Mar 13 16:14:25 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 QAA12374 for <ibis@eda.org>; Mon, 13 Mar 2000 16:14:24 -0800 (PST)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id AAA08156
	for <ibis@eda.org>; Tue, 14 Mar 2000 00:13:44 GMT
Received: from fmsmsx28.FM.INTEL.COM ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 14 Mar 2000 00:13:02 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <GPN7207T>; Mon, 13 Mar 2000 16:13:01 -0800
Message-ID: <4575832C8E71D111AC4100A0C96B512706458950@fmsmsx36.fm.intel.com>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: "Ibis@Eda. Org" <ibis@eda.org>
Subject: RE: Bus Clamp vs Dynamic Clamp
Date: Mon, 13 Mar 2000 16:13:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"

Chris,

First you call it a bad thing to have more than one way to do the same
thing.
Then, in your last paragraph you say:

"The trick is to offer flexibility WITHOUT over-complicating things."

Being able to do things more than just one way is a flexibility of some
kind.
The real issue here is that the IBIS spec is getting "over-complicated".
However,
I don't think that this is due to the fact that there are multiple ways of
doing
things.  It really is due to the way the syntax is constructed.

Otherwise I agree with you 100%, and I hope that the future IBIS syntax will
not
fall into the same mistake.

The example you brought up with the bus hold and dynamic clamp is a case
when the main features allow for some overlapping "side effects".  Since
these
are not the primary intent of those keywords, this may have been an
unintentional
"feature" or an oversight.  Of course, on the principle of "if something can
be
done, it will be done" we should not have allowed it if it causes problems
or
confusion.


Arpad
============================================================================
=====


-----Original Message-----
From: Chris Rokusek [mailto:crokusek@viewlogic.com]
Sent: Monday, March 13, 2000 2:59 PM
To: Ibis@Eda. Org
Subject: RE: Bus Clamp vs Dynamic Clamp


Arpad,

> Even though I agree that it is not always good to have redundancy,
> I also may argue that some times it will happen.  For example,
> think how many different ways you can write a resistor in HSPICE.
> You can do it as an R-element, and also as either one of the
> four controlled sources.  Is that bad?

Yes, that is extrememly BAD if I am a user that only cares about R/L/C
circuits because my manual is thicker than it needs to be.  And if the
manually gets as big as my car because HSPICE can also beat Big Blue at
chess, then I won't use HSPICE to solve my linear circuit problem if I can
find an alternate easy to use solution that minimizes my time to solution
(and I don't have a garage/hard drive to hold the manual).

If I am a user that needs controlled sources then I answer no.

Of course Avanti will satisfy the majority of its users and better yet will
try to add features without increasing the user learning curve.

The point I was trying to make in the 3/10/2000 reply was that if it's
possible to simplify something that has many rules (e.g. order of
precedence):

1 + 2 * 5 * pi
-----------------
10 * pi + 1/1*1+0

Then do it!

The trick is to offer flexibility WITHOUT over-complicating things.  This is
not a new concept, software development goes through this process all the
time.  Start with a simple solution to a problem.  Then, add, add, and add
features to it.  Eventually you have something that needs to be simplified
because the added features "weigh" more than the original solution.

What are the examples in Hardware?  RISC, FPGA's?

Chris


> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Monday, March 13, 2000 2:12 PM
> To: 'Chris Rokusek'
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Chris,
>
> This sounds believable, but I have to admit that I would have
> to re-read the spec. to see whether it is correct.  This was not
> the intention, though.
>
> Even though I agree that it is not always good to have redundancy,
> I also may argue that some times it will happen.  For example,
> think how many different ways you can write a resistor in HSPICE.
> You can do it as an R-element, and also as either one of the
> four controlled sources.  Is that bad?
>
> Arpad
> ================================================================
>
> -----Original Message-----
> From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> Sent: Friday, March 10, 2000 4:56 PM
> To: Ibis@Eda. Org
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Arpad,
>
> The question was in regard to the ***STATIC MODE*** of Dynamic Clamp.  You
> answered a different question.
>
> After ten minutes of reading the spec I conlude that there are two ways to
> specify additional static clamping of a given parent model when in a
> particular state.
>
> One can use a
>
> 	1) "Static Mode" Dynamic Clamp sub-model (means it doesn't have
> pulse
> tables).
>
> 	2) "Bus Hold" with NULL I-V Pullup/Pulldown.
>
> Right?
>
> Chris
>
>
>
>
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Friday, March 10, 2000 4:01 PM
> > To: 'Chris Rokusek'; Ibis@Eda. Org
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Chris,
> >
> > These two were implemented for two completely different circuit
> > behaviors.  The dynamic clamp shifts the knee voltage of the clamp
> > based on some triggering events.  The bus hold circuit's I-V cure
> > goes through the origin, but it switches from a pullup to a pulldown
> > shape when it detects a certain voltage.  I don't see how these two
> > are the same, or how they could be described with only one of these two
> > keywords.
> >
> > Arpad
> > ====================================================================
> >
> > -----Original Message-----
> > From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> > Sent: Friday, March 10, 2000 2:10 PM
> > To: Ibis@Eda. Org
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Let me rephrase:
> >
> > If a Static Mode Dynamic Clamp submodel can be described as a Bus Hold
> > model, why do we need a static mode?
> >
> > Think about this:
> >
> > 	There are two submodel types.
> >
> > 	Their are multiple modes for each type.
> >
> > 	The submodel itself is a type (in so much as its not a model).
> >
> > 	The submodel type can only be used under certain conditions of the
> > parent
> > Model.
> >
> > That's a lot of IF's just to effectively add a node to a circuit.
> >
> > Customers keep calling asking me to interpret the IBIS Spec.
> Therefore, I
> > conclude the spec must be difficult to understand.
> >
> > The more TYPE's, RULE's, IF's, and MODE's there are in this
> spec, the more
> > difficult it becomes to comprehend and maintain.  Hey look that makes an
> > acronym:  TRIM!
> >
> > Of course its MY FAULT just as much as anyone else's for
> allowing some of
> > these BIRDS to contain redundancies.  I'm hoping that we become
> > more careful
> > as to what we are adding to the spec and perhaps we can even reduce and
> > simplify at some point.
> >
> > Thanks for reading!
> >
> > Chris Rokusek
> > Viewlogic Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: bob_ross@mentorg.com [mailto:bob_ross@mentorg.com]
> > > Sent: Friday, March 10, 2000 12:44 PM
> > > To: Chris Rokusek
> > > Cc: Ibis@Eda. Org
> > > Subject: Re: Bus Clamp vs Dynamic Clamp
> > >
> > >
> > > Chris:
> > >
> > > Briefly, the Bus Hold submodel always
> > > always operates in the triggered mode
> > > and optionally with an Off_delay.  So
> > > it does not have a Static mode.
> > >
> > > Bob Ross
> > > Mentor Graphics
> > >
> > >
> > > Chris Rokusek wrote:
> > > >
> > > > Hi Ibis-gurus,
> > > >
> > > > I've got a question:
> > > >
> > > > I'm wondering what the differences are between:
> > > >
> > > >   1) "Static Mode" of a Dynamic Clamp Sub-model
> > > >
> > > >         vs.
> > > >
> > > >   2) Bus Hold Sub-Model.
> > > >
> > > > If there are no differences, is there any reason we really need the
> > > > redundancy and extra confusing verbage defining what Static Mode is?
> > > >
> > > > Chris
> > >
> >
> >
> >
>
>
>


From owner-ibis  Mon Mar 13 19:26:38 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 TAA13104 for <ibis@eda.org>; Mon, 13 Mar 2000 19:26:37 -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 WAA03759
	for <ibis@eda.org>; Mon, 13 Mar 2000 22:24:45 -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 WAA19184
	for <ibis@eda.org>; Mon, 13 Mar 2000 22:24:43 -0500 (EST)
Received: from pc-chrisr (pc-chrisr.camarillo.viewlogic.com [139.181.194.170])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id TAA07246
	for <ibis@eda.org>; Mon, 13 Mar 2000 19:23:15 -0800 (PST)
From: "Chris Rokusek" <crokusek@viewlogic.com>
To: "Ibis@Eda. Org" <ibis@eda.org>
Subject: RE: Bus Clamp vs Dynamic Clamp
Date: Mon, 13 Mar 2000 19:27:16 -0800
Message-ID: <000101bf8d65$32575220$aac2b58b@pc-chrisr.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
In-Reply-To: <4575832C8E71D111AC4100A0C96B512706458950@fmsmsx36.fm.intel.com>

Arpad,

> First you call it a bad thing to have more than one way to do the same
> thing.
> Then, in your last paragraph you say:
>
> "The trick is to offer flexibility WITHOUT over-complicating things."
>
> Being able to do things more than just one way is a flexibility of some
> kind.

Yes!  Actually I called it BOTH a BAD thing and a GOOD thing each within a
given context so that I could explain that the "win-win" for both answers is
"The trick".

> The real issue here is that the IBIS spec is getting "over-complicated".
> However,
> I don't think that this is due to the fact that there are multiple ways of
> doing
> things.  It really is due to the way the syntax is constructed.

I agree that "multiple-ways" in itself is not the problem either.

However I disagree that that the reason that the IBIS spec is overly
complicated is because of the way syntax is contructed.

SYNTAX to me is the wording used to describe the data and its relationships
and includes the rules used to contruct the wording.

CONTENT to me is the relationships among the data and the data itself.  I
usually think of that tree view on the IBIS ftp site plus all the rules of
the tree as content.

I think Syntax and Content are intimately intertwined.  Introduction of
"Sub-Model" was one solution to the Bus_Hold/Dynamic_Clamp problem.  Is
"Sub-Model" a syntax or content concept?  Seems like both to me.

To clarify, I am MOST interested in reducing the Content
TYPES/RULES/IFS/MODES in the future.  And of course if we can reduce the
Syntax TYPES/RULES/IFS/MODES as well I'm all for that too.  And since I
claim that they're intertwined, reducing one will probably naturally lead to
reducing the other.

Chris

(BTW: I have no problem with Sub-Model in particular, we could "pick on"
nearly any keyword!)


> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Monday, March 13, 2000 4:13 PM
> To: Ibis@Eda. Org
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Chris,
>
> First you call it a bad thing to have more than one way to do the same
> thing.
> Then, in your last paragraph you say:
>
> "The trick is to offer flexibility WITHOUT over-complicating things."
>
> Being able to do things more than just one way is a flexibility of some
> kind.
> The real issue here is that the IBIS spec is getting "over-complicated".
> However,
> I don't think that this is due to the fact that there are multiple ways of
> doing
> things.  It really is due to the way the syntax is constructed.
>
> Otherwise I agree with you 100%, and I hope that the future IBIS
> syntax will
> not
> fall into the same mistake.
>
> The example you brought up with the bus hold and dynamic clamp is a case
> when the main features allow for some overlapping "side effects".  Since
> these
> are not the primary intent of those keywords, this may have been an
> unintentional
> "feature" or an oversight.  Of course, on the principle of "if
> something can
> be
> done, it will be done" we should not have allowed it if it causes problems
> or
> confusion.
>
>
> Arpad
> ==================================================================
> ==========
> =====
>
>
> -----Original Message-----
> From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> Sent: Monday, March 13, 2000 2:59 PM
> To: Ibis@Eda. Org
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Arpad,
>
> > Even though I agree that it is not always good to have redundancy,
> > I also may argue that some times it will happen.  For example,
> > think how many different ways you can write a resistor in HSPICE.
> > You can do it as an R-element, and also as either one of the
> > four controlled sources.  Is that bad?
>
> Yes, that is extrememly BAD if I am a user that only cares about R/L/C
> circuits because my manual is thicker than it needs to be.  And if the
> manually gets as big as my car because HSPICE can also beat Big Blue at
> chess, then I won't use HSPICE to solve my linear circuit problem if I can
> find an alternate easy to use solution that minimizes my time to solution
> (and I don't have a garage/hard drive to hold the manual).
>
> If I am a user that needs controlled sources then I answer no.
>
> Of course Avanti will satisfy the majority of its users and
> better yet will
> try to add features without increasing the user learning curve.
>
> The point I was trying to make in the 3/10/2000 reply was that if it's
> possible to simplify something that has many rules (e.g. order of
> precedence):
>
> 1 + 2 * 5 * pi
> -----------------
> 10 * pi + 1/1*1+0
>
> Then do it!
>
> The trick is to offer flexibility WITHOUT over-complicating
> things.  This is
> not a new concept, software development goes through this process all the
> time.  Start with a simple solution to a problem.  Then, add, add, and add
> features to it.  Eventually you have something that needs to be simplified
> because the added features "weigh" more than the original solution.
>
> What are the examples in Hardware?  RISC, FPGA's?
>
> Chris
>
>
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Monday, March 13, 2000 2:12 PM
> > To: 'Chris Rokusek'
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Chris,
> >
> > This sounds believable, but I have to admit that I would have
> > to re-read the spec. to see whether it is correct.  This was not
> > the intention, though.
> >
> > Even though I agree that it is not always good to have redundancy,
> > I also may argue that some times it will happen.  For example,
> > think how many different ways you can write a resistor in HSPICE.
> > You can do it as an R-element, and also as either one of the
> > four controlled sources.  Is that bad?
> >
> > Arpad
> > ================================================================
> >
> > -----Original Message-----
> > From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> > Sent: Friday, March 10, 2000 4:56 PM
> > To: Ibis@Eda. Org
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Arpad,
> >
> > The question was in regard to the ***STATIC MODE*** of Dynamic
> Clamp.  You
> > answered a different question.
> >
> > After ten minutes of reading the spec I conlude that there are
> two ways to
> > specify additional static clamping of a given parent model when in a
> > particular state.
> >
> > One can use a
> >
> > 	1) "Static Mode" Dynamic Clamp sub-model (means it doesn't have
> > pulse
> > tables).
> >
> > 	2) "Bus Hold" with NULL I-V Pullup/Pulldown.
> >
> > Right?
> >
> > Chris
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > > Sent: Friday, March 10, 2000 4:01 PM
> > > To: 'Chris Rokusek'; Ibis@Eda. Org
> > > Subject: RE: Bus Clamp vs Dynamic Clamp
> > >
> > >
> > > Chris,
> > >
> > > These two were implemented for two completely different circuit
> > > behaviors.  The dynamic clamp shifts the knee voltage of the clamp
> > > based on some triggering events.  The bus hold circuit's I-V cure
> > > goes through the origin, but it switches from a pullup to a pulldown
> > > shape when it detects a certain voltage.  I don't see how these two
> > > are the same, or how they could be described with only one of
> these two
> > > keywords.
> > >
> > > Arpad
> > > ====================================================================
> > >
> > > -----Original Message-----
> > > From: Chris Rokusek [mailto:crokusek@viewlogic.com]
> > > Sent: Friday, March 10, 2000 2:10 PM
> > > To: Ibis@Eda. Org
> > > Subject: RE: Bus Clamp vs Dynamic Clamp
> > >
> > >
> > > Let me rephrase:
> > >
> > > If a Static Mode Dynamic Clamp submodel can be described as a Bus Hold
> > > model, why do we need a static mode?
> > >
> > > Think about this:
> > >
> > > 	There are two submodel types.
> > >
> > > 	Their are multiple modes for each type.
> > >
> > > 	The submodel itself is a type (in so much as its not a model).
> > >
> > > 	The submodel type can only be used under certain conditions of the
> > > parent
> > > Model.
> > >
> > > That's a lot of IF's just to effectively add a node to a circuit.
> > >
> > > Customers keep calling asking me to interpret the IBIS Spec.
> > Therefore, I
> > > conclude the spec must be difficult to understand.
> > >
> > > The more TYPE's, RULE's, IF's, and MODE's there are in this
> > spec, the more
> > > difficult it becomes to comprehend and maintain.  Hey look
> that makes an
> > > acronym:  TRIM!
> > >
> > > Of course its MY FAULT just as much as anyone else's for
> > allowing some of
> > > these BIRDS to contain redundancies.  I'm hoping that we become
> > > more careful
> > > as to what we are adding to the spec and perhaps we can even
> reduce and
> > > simplify at some point.
> > >
> > > Thanks for reading!
> > >
> > > Chris Rokusek
> > > Viewlogic Systems
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: bob_ross@mentorg.com [mailto:bob_ross@mentorg.com]
> > > > Sent: Friday, March 10, 2000 12:44 PM
> > > > To: Chris Rokusek
> > > > Cc: Ibis@Eda. Org
> > > > Subject: Re: Bus Clamp vs Dynamic Clamp
> > > >
> > > >
> > > > Chris:
> > > >
> > > > Briefly, the Bus Hold submodel always
> > > > always operates in the triggered mode
> > > > and optionally with an Off_delay.  So
> > > > it does not have a Static mode.
> > > >
> > > > Bob Ross
> > > > Mentor Graphics
> > > >
> > > >
> > > > Chris Rokusek wrote:
> > > > >
> > > > > Hi Ibis-gurus,
> > > > >
> > > > > I've got a question:
> > > > >
> > > > > I'm wondering what the differences are between:
> > > > >
> > > > >   1) "Static Mode" of a Dynamic Clamp Sub-model
> > > > >
> > > > >         vs.
> > > > >
> > > > >   2) Bus Hold Sub-Model.
> > > > >
> > > > > If there are no differences, is there any reason we
> really need the
> > > > > redundancy and extra confusing verbage defining what
> Static Mode is?
> > > > >
> > > > > Chris
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>

From owner-ibis  Tue Mar 14 00:31:55 2000
Received: from mink.ecitele.com (mink.ecitele.com [147.234.1.100]) by server.eda.org (8.8.5/8.8.3) with ESMTP id AAA13995 for <ibis@eda.org>; Tue, 14 Mar 2000 00:31:53 -0800 (PST)
From: Irena.Berkovich@ecitele.com
Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125])
	by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id KAA01259
	for <ibis@eda.org>; Tue, 14 Mar 2000 10:29:57 +0200 (IST)
Subject: Order
To: ibis@eda.org
Date: Tue, 14 Mar 2000 10:28:04 +0200
Message-ID: <OF68036302.431C0583-ON422568A2.002D4782@ecitele.com>
X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.2b (Intl)|16
 December 1999) at 14/03/2000 10:28:53
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Dear Sirs,

We would like to order the following:

DesignCon 2000 CD-ROM-"High-Performance System Design" for $75-
Please send us an invoice included shipment.

Our Address is  LIBRARY
                               ECI Telecom Ltd.
                               30 Hasivim Str., POB 3083
                                Petach-Tikva 49130, Israel.
                                Tel. (972-3)9287087
                                 Fax (972-3)9287137.
You can fax us the invoice.

Regards,
Irena Berkovich
Library.



From owner-ibis  Mon Mar 20 02:15:00 2000
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by server.eda.org (8.8.5/8.8.3) with ESMTP id CAA12741 for <ibis@vhdl.org>; Mon, 20 Mar 2000 02:14:59 -0800 (PST)
From: janne.ikavalko@nokia.com
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id MAA15884
	for <ibis@vhdl.org>; Mon, 20 Mar 2000 12:13:33 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id MAA14846
	for <ibis@vhdl.org>; Mon, 20 Mar 2000 12:13:28 +0200 (EET)
Received: by esebh01nok with Internet Mail Service (5.5.2650.10)
	id <H1H51K2F>; Mon, 20 Mar 2000 12:13:16 +0200
Message-ID: <25B79E9476BAD211811B0008C7894CDC01FB714B@treis04nok>
To: ibis@vhdl.org
Date: Mon, 20 Mar 2000 11:48:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Everybody!

It came to my mind, that how does simulation with IBIS models take into
account 
parasitics which comes from power supply and ground pins and bonding wires?
As I understand only signal line's pin and bonding parasitics are included
into the simulation.
However, I think that in real life parasitics from power supply and ground
bonding wires has some effect also.

My current opinion is that effect from power supply and ground bonding wires
are not taken into account. Connection to power supply and ground are
considered ideal.
Am I right?

I tried to find information about this from IBIS specifications, but I
couldn't find any. 

What is Your opinion, how (much) does this effect to the correctness of the
simulation result? 
 

Best Regards,
                    Janne Ikavalko

-- Janne Ikavalko 
-- NMP Tampere, Finland
-- GSM +358 50 3655120
-- Janne.Ikavalko@nokia.com

From owner-ibis  Mon Mar 20 05:43:41 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 FAA13554 for <ibis@vhdl.org>; Mon, 20 Mar 2000 05:43:41 -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 FAA21374
	for <ibis@vhdl.org>; Mon, 20 Mar 2000 05:42:15 -0800 (PST)
Received: from cadence.com (d15814010582 [158.140.105.82])
	by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id IAA08860
	for <ibis@vhdl.org>; Mon, 20 Mar 2000 08:42:14 -0500 (EST)
Message-ID: <38D62AB1.BD7ED888@cadence.com>
Date: Mon, 20 Mar 2000 08:42:09 -0500
From: Mike LaBonte <mikelabonte@cadence.com>
Organization: Cadence Design Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@vhdl.org
Subject: Re: 
References: <25B79E9476BAD211811B0008C7894CDC01FB714B@treis04nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Received: By mailgate.Cadence.COM as FAA21374 at Mon Mar 20 05:42:15 2000

Janne,

Let us separate the power and ground parasitics into 3 categories:

- package parasitics
- bond wire parasitics
- on-die interconnect parasitics

IBIS has multiple methods for handling package parasitics. One of them, the
[Define Package Model] section, can include bond wire parasitics. There is no
good solution for on-die interconnect yet, but the IBIS committee has begun
considering this. The summary is that a good portion of the path from power
and ground pins to the buffers they supply is covered by IBIS, but not all of it.

I would expect that most, if not all, IBIS simulators will use the power and
ground parasitic information if it is present in an IBIS file.

Mike LaBonte

janne.ikavalko@nokia.com wrote:
> 
> Hi Everybody!
> 
> It came to my mind, that how does simulation with IBIS models take into
> account
> parasitics which comes from power supply and ground pins and bonding wires?
> As I understand only signal line's pin and bonding parasitics are included
> into the simulation.
> However, I think that in real life parasitics from power supply and ground
> bonding wires has some effect also.
> 
> My current opinion is that effect from power supply and ground bonding wires
> are not taken into account. Connection to power supply and ground are
> considered ideal.
> Am I right?
> 
> I tried to find information about this from IBIS specifications, but I
> couldn't find any.
> 
> What is Your opinion, how (much) does this effect to the correctness of the
> simulation result?
> 
> 
> Best Regards,
>                     Janne Ikavalko
> 
> -- Janne Ikavalko
> -- NMP Tampere, Finland
> -- GSM +358 50 3655120
> -- Janne.Ikavalko@nokia.com
From owner-ibis  Mon Mar 20 08:35:19 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 IAA14189 for <ibis@vhdl.org>; Mon, 20 Mar 2000 08:35:18 -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.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id QAA03225
	for <ibis@vhdl.org>; Mon, 20 Mar 2000 16:34:37 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 20 Mar 2000 16:33:54 0000 (GMT)
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <GTQPP8ZQ>; Mon, 20 Mar 2000 08:33:53 -0800
Message-ID: <4575832C8E71D111AC4100A0C96B512706458993@fmsmsx36.fm.intel.com>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: ibis@vhdl.org
Subject: RE: 
Date: Mon, 20 Mar 2000 08:33:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

Janne,

You are correct that the power supply and ground package
parasitics will also effect the behavior of the buffers.

However, you are not correct in saying that IBIS assumes
ideal supply rails around the buffers.  You can define
package parasitics for Vcc and GND pins as well as for
signals in the IBIS model.  IBIS is only lacking in the
description of die interconnects.  In other words, it 
doesn't give you enough detail on how the power pins (or
die pads) are connected with the buffers on the die.

It is another question whether simulator tools connect
the buffer model through the package parasitics or just
to an ideal source.

Arpad Muranyi
Intel Corporation
===========================================================



-----Original Message-----
From: janne.ikavalko@nokia.com [mailto:janne.ikavalko@nokia.com]
Sent: Monday, March 20, 2000 1:48 AM
To: ibis@vhdl.org
Subject: 


Hi Everybody!

It came to my mind, that how does simulation with IBIS models take into
account 
parasitics which comes from power supply and ground pins and bonding wires?
As I understand only signal line's pin and bonding parasitics are included
into the simulation.
However, I think that in real life parasitics from power supply and ground
bonding wires has some effect also.

My current opinion is that effect from power supply and ground bonding wires
are not taken into account. Connection to power supply and ground are
considered ideal.
Am I right?

I tried to find information about this from IBIS specifications, but I
couldn't find any. 

What is Your opinion, how (much) does this effect to the correctness of the
simulation result? 
 

Best Regards,
                    Janne Ikavalko

-- Janne Ikavalko 
-- NMP Tampere, Finland
-- GSM +358 50 3655120
-- Janne.Ikavalko@nokia.com


From owner-ibis  Mon Mar 20 08:55:42 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 IAA14245 for <ibis@vhdl.org>; Mon, 20 Mar 2000 08:55:41 -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.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id QAA16810
	for <ibis@vhdl.org>; Mon, 20 Mar 2000 16:55:00 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 20 Mar 2000 16:54:16 0000 (GMT)
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <GTQPP9MX>; Mon, 20 Mar 2000 08:54:15 -0800
Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069ADA@orsmsx49.jf.intel.com>
From: "Peters, Stephen" <stephen.peters@intel.com>
To: "'ibis@vhdl.org'" <ibis@vhdl.org>
Subject: Bird 62.6 -- Enhanced Specification of Receiver Thresholds
Date: Mon, 20 Mar 2000 08:54:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"


Hello All:

   Below is Bird 62.6, incorporating the change tallked about at the last
IBIS teleconference.  Input_edge_rate has been replaced by the Tslew_ac
and Tdiffslew_ac parameters.  Please review, and direct all comments to the
reflector.  Thanks.  

   Regards,
   Stephen Peters
   Intel Corp.

---------------------
                  Buffer Issue Resolution Document  (BIRD)
 
 BIRD ID#:      62.6
 ISSUE TITLE:   Enhanced Specification of Receiver Thresholds
 REQUESTER:     DC Sessions (Philips), Stephen Peters, Richard Mellitz,
                Arpad Muranyi (Intel Corp).
 DATE SUBMITTED:  Aug 24 1999, Dec 28 1999, Jan 6 2000, Feb 18 2000,
                  Feb 25 2000, Mar 3 2000, Mar 20 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.  This bird also provides for 
 specifying differential receivers and maximum slew times.
 
****************************************************************************
 
 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,
|               Threshold_sensitivity, Reference_supply, Vcross_low, 
|               Vcross_high, Vdiff_ac, Vdiff_dc, Tslew_ac, Tdiffslew_ac.
|  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
|               voltages 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.  Vinl_dc is 
|               expressed as an offset from Vth.
|
|               Threshold_sensitivity is a unit less number that specifies
|               how Vth varies with respect to the supply voltage defined 
|               by the Reference_supply subparameter. Threshold_sensitivity
|               is defined as:
|
|                                   change in input threshold voltage
|         Threshold_sensitivity = ------------------------------------
|                                  change in referenced supply voltage
|
|               Threshold_sensitivity must be entered as a whole number or
|               decimal, not as a fraction.
|
|               Reference_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 as follows:
|               Power_clamp_ref (the supply voltage defined by the
|                                [POWER Clamp Reference] keyword)
|               Gnd_clamp_ref   (the supply voltage defined by the 
|                                [GND Clamp Reference] keyword)
|               Pullup_ref      (the supply voltage defined by the
|                                [Pullup reference] keyword)
|               Pulldown_ref    (the supply voltage defined by the
|                                [Pulldown reference] keyword)
|               Ext_ref         (the supply voltage defined by the 
|                                [External Reference] keyword)
|
|
|               Tslew_ac and Tdiffslew_ac measures the absolute difference 
|               in time between the point at which an input waveform 
|               crosses Vinl_ac and the point it crosses Vinh_ac.  The 
|               purpose of this parameter is to document the maximum amount
|               of time an input signal may take to transition between 
|               Vinh_ac and Vinl_ac and still allow the device to meet its 
|               input setup and hold specifications.  Tslew_ac is the 
|               parameter used for single ended receivers while
|               Tdiffslew_ac must be used for receivers with differential 
|               inputs. 
|               
|               Vcross_low is the least positive voltage at which a 
|               differential receivers' input signals may cross while 
|               switching and still allow the receiver to meet its timing 
|               and functional specifications.  Vcross_low is specified
|               with respect to 0V.
|
|               Vcross_high is the most positive voltage at which a 
|               differential receivers' input signals may cross while 
|               switching and still allow the receiver to meet its timing 
|               and functional specifications.  Vcross_high is specified
|               with respect to 0V.
|
|               Vdiff_dc is the minimum voltage difference between the 
|               inputs of a differential receiver that guarantees the
|               receiver will not change state.
|
|               Vdiff_ac is the minimum voltage difference between the 
|               inputs of a differential receiver that guarantees the 
|               receiver will change state.
|
|
|
| Usage Rules:  The [Receiver Thresholds] keyword is valid if the model type
|               includes any reference to input or I/O.  For single ended
|               receivers the Vinh_ac, Vinh_dc, Vinl_ac, Vinh_dc, Vth and
|               Tslew_ac subparameters are required and override 
|               the Vinh, Vinl, Vinh+/- and Vinl+/- subparameters declared 
|               under the [Model] or [Model Spec] keywords.  For single
ended
|               receivers the Vth_min, Vth_max, Threshold_sensitivity and 
|               Reference_supply subparameters are optional.  However, if 
|               the Threshold_sensitivity subparameter is present then the 
|               Reference_supply subparameter must also be present.
|
|               For differential receivers (i.e. the [Receiver Thresholds]
|               keyword is part of a [Model] statement that describes a pin 
|               listed in the [Diff Pin] keyword) then the Vcross_low,
|               Vcross_high, Vdiff_ac, Vdiff_dc and Tdiffslew_ac
|               subparameters are required. The rest of the subparameters
|               are not applicable.  The Vdiff_ac and Vdiff_dc values 
|               override the value of the Vdiff subparameter specified by 
|               the [Diff Pin] keyword.  Note that Vcross_low and 
|               Vcross_high are valid over the device's minimum and maximum 
|               operating conditions. 
|
|               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
|               Reference_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* + [(Threshold_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
|               Reference_Supply subparameter.
|
|
|
| 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
Tslew_ac = 1.2ns
|
|
| A single ended receiver using an external threshold reference.  In this
| case the input threshold is the external reference voltage so
| Threshold_sensitivity equals 1.
|
Vth = 1.0V
Threshold_sensitivity = 1
Reference_Supply Ext_ref
Vinh_ac = +200mV
Vinh_dc = +100mV
Vinl_ac = -200mV
Vinl_dc = -100mV
Tlsew_ac = 400ps
|
|
| A fully specified single ended 3.3v CMOS receiver
|
Vth = 1.5V
Vth_min = 1.45V
Vth_max = 1.53V
Threshold_sensitivity = 0.45
Reference_supply Power_clamp_ref
Vinh_ac = +200mV
Vinh_dc = +100mV
Vinl_ac = -200mV
Vinl_dc = -100mV
Tslew_ac = 400ps
|
|
| A differential receiver
|
Vcross_low = 0.65V
Vcross_high = 0.90V
Vdiff_ac = +200mV
Vdiff_dc = +100mV
Tdiffslew_ac = 200ps

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.
|               Note that the numerically largest value should be placed in
|               'max' column, while the numerically smallest value should
|               be placed in the 'min' column. 
|               
|--------------------------------------------------------------------------
| variable              typ          min           max
[External Reference]   1.00V        0.95V         1.05V


***************************************************************************
 
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 separating arguments from subparameters.
Updated examples with this change.

Update for 62.3
  The subparameter Input_Ref_Supply was renamed to Reference_supply
(this is to be consistent with other subparameter names).  The
list of arguments to the Reference_supply subparameter was expanded
and clarified. A note was added to the [External Reference]
keyword clarifying which values go in the min and max columns of this
keyword. Finally, four new subparameters that describe differential
receivers were added.

Update for 62.4
  Renamed Vth_sensitivity to Threshold_sensitivity.  Renamed the
voltage cross parameters to Vcross_low and Vcross_high.  Added the
Input_edge_rate subparameter from Bird 63.3.  Input_edge_rate now 
follows the precise JEDEC definition.  Finally, removed the section
that made the arguments to the Reference_supply subparameter reserved
words.  They are simply enumerated arguments with a defined value,
not reserved words with special meanings.

Update for 62.5
  Broke the Input_edge_rate subparameter into one for single ended and
one for differential receivers.  Removed the clause regarding Vcross_low
and Vcross_high tracking the min/max corners. Corrected a few typos.

Update for 62.6
  Per Bob Ross's suggestion, changed the Input_edge_rate subparameter to
Tslew_ac that documents time only, not a rate.  Updated examples.

***************************************************************************

ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a
request by the JEDEC JC-16 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 Mellitz and Arpad Muranyi of Intel Corp.
 
****************************************************************************












From owner-ibis  Tue Mar 21 14:04:24 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 OAA20628 for <ibis@eda.org>; Tue, 21 Mar 2000 14:04:23 -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 RAA11554
	for <ibis@eda.org>; Tue, 21 Mar 2000 17:02:28 -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 RAA05106
	for <ibis@eda.org>; Tue, 21 Mar 2000 17:02:26 -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 OAA02060
	for <ibis@eda.org>; Tue, 21 Mar 2000 14:00:49 -0800 (PST)
Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4)
	id OAA01921; Tue, 21 Mar 2000 14:04:46 -0800
Date: Tue, 21 Mar 2000 14:04:46 -0800
From: guy@camarillo.viewlogic.com (Guy de Burgh)
Message-Id: <200003212204.OAA01921@f22.viewlogic.com>
To: ibis@eda.org
Subject: EIA IBIS Open Forum Meeting Minutes (3/17/00)


DATE: 3/21/00

SUBJECT: 3/17/00 EIA IBIS Open Forum Meeting Minutes

VOTING MEMBERS AND 2000 PARTICIPANTS LIST:
3Com                           Roy Leventhal*
Agilent (EEsof, etc.)          Mark Chang
  Hewlett Packard              Paul Gregory
Applied Simulation Technology  Raj Raghuram*, Norio Matsui, Fred Ballesteri
Avanti                         Nikolai Bannov
Cadence Design                 Mike LaBonte*, Todd Westerhoff, Ian Dodd*,
                               Donald Telian
Cisco Systems                  Syed Huq, Irfan Elahi, John Fisher
Compaq                         Bob Haller*, Peter LaFlamme, Ron Bellomio,
                               Shafier Rahman, Doug Burns
Cypress                        (Rajesh Manapat)
EMC Corporation                (Fabrizio Zanella),
Fairchild Semiconductor        Craig Klem
H.A.S. Electronics             (Haruny Said)
HyperLynx (& Pads Software)    Matthew Flora*, Kellee Crisafulli*, Gene Garat,
                               John Angulo*, Al Davis, Lynne Green
IBM                            Michael Cohen*
Incases                        (Werner Rissiek)
Intel Corporation              Stephen Peters*, Arpad Muranyi*, Will Hobbs,
                               Richard Mellitz
LSI Logic                      (Larry Barnes)
Mentor Graphics (& Veribest)   Bob Ross*, Tom Dagostino, Malcolm Ash,
                               Kim Owen
Mitsubishi                     Shahab Ahmed
Molex Incorporated             Gus Panella*
Motorola                       Ron Werner
National Semiconductor         Milt Schwartz*
North East Systems Associates  Edward Sayre, Tony Sinker
NEC                            (Hiroshi Matsumoto)
Nortel Networks                Steve Coe, Calvin Trowell*, Hassan Ali*
Philips Semiconductor          D.C. Sessions
  (& VLSI Technology)
Quantic EMC                    (Mike Ventham)
Siemens                        Bernhard Unger
SiQual                         Scott McMorrow, Wis Macomson
Texas Instruments              Stephen Nolan, Ramzi Ammar, Mac McCaughey,
                               Thomas Fisher
Time Domain Analysis Systems   Dima Smolyansky, Steven Corey
Via Technologies               (Weber Chuang)
Viewlogic Systems              Chris Rokusek, Guy de Burgh*, Jun Tian,
                               (Jon Powell)

OTHER PARTICIPANTS IN 2000:
Actel Corp.                    Silvia Montoya
Advansis                       Mikio Kiyono
Brocade Communications         Robert Badal
EIA                            Cecilia Fleming*
Jet Propulsion Lab             John Treichlew
Rockwell Collins               Ron Hau
Signals & Systems Engineering  Tom Hawkins
Sun Microsystems               Victor Chang
Xilinx, Inc.                   Susan Wu

In the list above, attendees at the meeting are indicated by *. Principal
members or other active members who have not attended are in parentheses.
Participants who no longer are in the organization are in square brackets.

Upcoming Meetings:  The bridge numbers for future IBIS teleconferences are as
follows:

  Date                Bridge Number    Reservation #    Passcode
  March 31, 2000 - DATE 2000 IBIS Summit Meeting (No Bridge)
  April 14, 2000      (916) 356-9200   8-97978          5851557

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 noted that Viewlogic Systems plans to officially ratify its name
change to Innoveda on Monday March 27th.

Hassan Ali, an Engineer from Nortel Networks joined and is interested in
IBIS in relationship to the high-speed board issues at the tools level.


MEMBERSHIP UPDATE AND TREASURER'S REPORT
Cecilia Fleming stated that there were no new updates on new members or
payments.  Reminder invoices have been sent out.  Bob Ross asked Guy de Burgh
to work with Bob and Cecilia to follow up on some of the members to find out
what their payment status is.


REVIEW OF MINUTES AND AR'S
Bob Ross reported that the February 25, 2000 minutes had a used an incorrect
heading for the JC-16.2 report.  Also, Stephen Nolan sent a note to Bob that
the reference to JC-42 should be changed to JC-40 for the Atlanta JEDEC
meeting under the JEDEC/IBIS Working Group meeting report.

The above minutes were approved as modified above.

The AR's will be discussed during the meeting.


MISCELLANY/ANNOUNCEMENTS
Bob Ross briefly noted that the anonymous FTP access to eda.org was down
while more security measures were installed to track access.  It is now up
again.

Bob noted that the DesignCon 2000 proceedings and CDs are available at
a discount to IBIS Member companies employees.  A form was sent out on
the reflectors.  The intent was to FAX the form back, since there was not
any return e-mail address on the form.


PRESS AND WEB PAGE UPDATES
Bob Ross noted that Syed Huq updated the Upcoming Events links and also made
some IBIS Participation Roster phone number changes and also added a link.


NEW MODELS AVAILABLE, LIBRARY UPDATE
None


OPENS FOR NEW ISSUES
Michael Cohen on New Technologies - introduced near the end of the meeting.


INTERNATIONAL/EXTERNAL PROGRESS
- IEC 62014-1 (IBIS Version 3.2) - Cecilia Fleming reported that she is
finding out more about the status.  The publication time should take only
two months, not eight.  IEC approved the document December, 1999.

- pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits
(IMIC) - Bob Ross stated hearing from Dr. Hideki Fukuda (on short sabbatical)
that a write-up of the last IBIS Summit Meeting appeared in the Nikkei News.
The IMIC group is interested in looking at proposed improvements that were
discussed and are meeting on March 23, 2000 to discuss their future plans.
The group is interested in how IBIS future specifications will relate to IMIC.

- 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
still plans to meet with the group in Paris on Thursday, March 30, 2000, just
before the IBIS Summit Meeting.

- JEDEC JC-16 - (Heading is changed to JC-16 since D.C. Sessions now is the
Chair of JC-16).   Bob Ross did not have a report of the JEDEC meeting held
last week in Atlanta, Georgia.


DATE2000 IBIS SUMMIT PLANNING
Bob Ross reported on 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
about 8:30 AM to early afternoon to allow people to return that evening.  The
co-sponsors of the meeting are Cadence Design, Incases, Mentor Graphics and
Viewlogic Systems.

The meeting will be held in the Concorde-Lafayette Hotel, adjacent to where
DATE2000 is being held.   The arrangements include refreshments and a free
lunch for all participants.

The tentative agenda for presentations is as follows:

  Siemens IBIS Modeling Requirements for Semiconductor Vendors
  Gerald Bannert, Siemens

  Tips and Tricks for Creating IBIS Models
  Cary Mandel, Viewlogic Systems

  IBIS Accuracy Studies
  Sherif Hammad, Mentor Graphics

  TC93WG6 EMC/EMI IC Model Standardization Report
  Jean Claude Perrin, Texas Instruments

  Behavioral Receiver Modeling
  Patrick Dos Santos, Cadence Design Systems

  IBIS Future Activities (and Discussion)
  Bob Ross, Mentor Graphics

So the content of this meeting is to share information on IBIS modeling
techniques and discuss future technical and specification needs.  Open
discussions and Ad hoc presentations will be encouraged on these and other
topics during the meeting.

The official agenda will be sent out next week.


DAC2000 IBIS Summit Meeting
Bob Ross discussed the plans for the IBIS Summit Meeting held annually along
with the Design Automation Conference (DAC).  The meeting will take place in
Los Angeles, California, and a room has been reserved for Thursday, June 8,
2000.  The trade show portion of DAC is held from Monday through Wednesday
June 5-7, 2000 at the Los Angeles Convention Center.  Along with election of
IBIS Open Forum officers, Bob indicated that the IBIS Summit Meeting would
probably have a few presentations and discussions related to topics of
current interest.  Connector Specification ratification issues would probably
be discussed.

Michael Cohen stressed that the IBIS Meeting should not conflict with the
DAC2000 show.  Kellee Crisafulli thought it would useful to also hold an
all day IBIS futures meeting at that time.  Bob suggested that the morning
could be devoted to the IBIS Open Forum issues, and the afternoon could be
reserved for the working group status.  Kellee indicated that a full day
would be more useful.  So the likely plan is to have the IBIS meeting on
Thursday, and the Working Group meeting on Friday.

Bob asked Guy de Burgh to handle the registration logistics.  Bob noted that
the IBIS home page Upcoming events link already contains Guy's name and some
information about DAC2000 and the IBIS Summit Meeting.


COOKBOOK STATUS
Stephen Peters had no report.


IBIS MODEL REVIEW COMMITTEE DISCUSSION
Matthew Flora reported that a model from Tundra Semiconductor has been sent
out for review.  Matthew received another model, but it needs some corrections
before being sent out.


BIRD62.5 ENHANCED CHARACTERIZATION OF RECEIVER THRESHOLDS
Stephen Peters briefly summarized some changes made since the last meeting.
A few editorial corrections were made.  The input edge rate subparameter was
split into Input_edge_rate_ser and Input_edge_rate_der to document separately
single ended receiver (_ser) and differential receiver (_der) entries.  Also,
incorrect references to relationship of the Vcross_low and Vcross_high
subparameters to min and max columns were removed.

Bob Ross spotted several more minor spelling errors and noted the examples
for Input_edge_rate_* still had the "=" sign.

Bob then indicated that he really preferred using Tslew_ac and Tdiffslew_ac
instead of the Input_edge_rate_ser and Input_edge_rate_der.  Often a generic
1V/1ns is used as the basis.  Since we are defining the Input_edge_rate for
just the delta Vin*_ac or Vdiff_ac value, we will have to calculate the
delta T.  Furthermore, since the simulators are interested only in the delta
T between crossing the Vin*_ac or Vdiff_ac voltages, the Tslew_ac and
Tdiffslew_ac subparameters would give directly the test times of interest.

Bob indicated that we scheduled BIRD62.5 for a vote.  John Angulo questioned
whether we wait on voting because the IBIS future plans were not resolved.
Several others indicated that BIRD62.5 was considered important by the JEDEC
committee.  Bob indicated that current IBIS future plans would need to
deal with this same specification.  So BIRD62.5 was applicable to both the
current upgrade of IBIS (Version 4.0) and some future direction of IBIS.

Bob suggested that we amend BIRD62.5 at the meeting to have the revised
subparameters and vote on BIRD62.5.  However, Bob noted that the text
describing the subparameters would have to be updated.  Kellee Crisafulli
stated that we really needed to see the changes before voting on them.  Bob
agreed.  Michael Cohen suggested quickly issuing BIRD62.6 and holding an
e-mail vote.  After some discussion about the urgency of BIRD62.6, we agreed
that the committee in effect agreed with pending BIRD62.6, but would hold the
formal ratification vote at the next teleconference meeting (scheduled on
April 14, 2000).  Bob noted that it is possible to modify the content as part
of the overall next version of IBIS ratification process.

AR - Stephen Peters make the changes discussed at the meeting as noted above,
and issue BIRD62.6. [Done]


BIRD63.3 DOCUMENTATION OF RECEIVER SETUP AND HOLD TIMING CONDITIONS
Bob Ross called for a vote on BIRD63.3.  We planned to reject BIRD63.3 since
the information of interest was added to BIRD62.5.

BIRD63.3 was rejected by a 0 Yes, 12 No vote.


BIRD66 - [Model Spec] Vref ADDITION
Bob Ross indicated that there may be some discussion on this topic in the
future since there were some conflicting interpretation of how Vmeas should
be used.


IBIS BUG TRACKING
Bob Ross stated that he had planned to issue BUG34 for review and issue
several other BUG reports per some previous IBIS meeting discussions.
However, he did not have time to this.  So this topic is deferred again.


CONNECTOR PROPOSAL REVIEW (CONTINUED)
Bob Ross reported that Bob, Gus Panella, and Kellee Crisafulli held telephone
"editorial committee" meetings on March 8, 2000 and March 14, 2000 to resolve
off-line a number of editorial and technical issues.  This will save using
IBIS Open Forum teleconferences to deal with minor points.  Bob stated that
the group reached agreement on many issues.

Kellee stressed that we still want to finalize the Connector Specification
and vote on it by the DAC2000 time frame.  Gus reaffirmed the pressure to
get the Connector Specification finalized as soon as possible.  Bob stated
that he expects that mid-2000 ratification is possible.  He has enlisted the
help of several connector experts to review the proposed specification after
it is stabilized.

Bob briefly listed (without elaboration) the points of agreement:

  Keep proposed keyword convention including having four words
  Keep Revision History Section, but clear the existing history in the
    ratified Version 1.0
  Keep reserved words PWRGND and RET
  Line limit of 120 characters (agreed at the January 31, 2000 meeting)
  Make the 100,000 pin limit a warning, not a requirement
  Keep the number of decimal digits at five recommended, 15 maximum
  Keep the Begin/End syntax for descriptions
  Allow file names of 40 characters (IBIS has 20) to resolve an inconsistency
  Use the extension .icm (as agreed at the January 31, 2000 meeting)
  Make the specified number of text lines a recommendation
  Have only one occurrence of [Begin_Cn_Model_Family]
  Use [Support] instead of [Email] and [Web] (as agreed at the January 31,
    2000 meeting)
  Keep [Redistribution], but allow Yes, No, and Specified where the actual
    conditions are stated
  Keep the requirement that .jpg or .txt are the only formats for pictures
    since other formats could be added later
  Keep SGR for SLM formats only, but some details are still being resolved
  Allow Cn_section to have more that one cascaded section named on the same
    line (still resolving details)
  Several other editorial changes including [Comment_Char] can follow first
    keyword as in IBIS

Individuals are still permitted to question these decisions as part of the
ratification processes, but we have agreed on the above points regarding the
content of the proposed Connector Specification document.  More points will
be considered at subsequent meetings.

Kellee plans to provide an updated Version 0.94 version.  Upon further
review another revision or two may be needed.  Bob stated that when we reach
further agreement on these details, we will need to update at least some of
the examples.  Gus plans to do this.

Bob stated that one nice technical feature was to support a variety connector
formats for

  Physical connectors using a Defined Physical Pin
  Physical connectors using Swath Matrix ([Begin_Cn_Swath])
  Auto generated connectors using the Swath Matrix and [Begin_Cn_Auto_Map].

The user would specify the number of connector pins for the auto generated
connector and the simulator would read the information contained in the .icm
file to generate that connector.

The technical challenge is to ensure that all the rules and information are
consistent.  Just simultaneously specifying number of pins, number of rows,
and number of columns may introduce an inconsistency that must be checked.
Bob gave an example illustrating further complication.  The physical connector
could have between 10 and 200 pins spanning the smallest 2 rows, 5 column
connector to the largest one with 2 rows and 100 columns.  The Swath Matrix
could be defined as a 2 by 3 matrix.  We need to check that all of the
information and stated rules work in consistent manner.  Bob noted that there
already was a conflict between required ModelPinMap entry of [Begin_Cn_Model]
and the fact that the keyword [Begin_Cn_Pin_Map] is optional and not used
when [Begin_Cn_Auto_Map] is specified.  These and other syntactical
contradictions have to be checked and resolved.  Otherwise, they will become
parser development issues.

Kellee wanted these meeting to continue on a regular basis.  Because of the
IBIS Summit Meeting in Paris and other travels, Bob cannot attend these
meetings until after April 3, 2000.  Bob stated that these meetings are open
to any who is interested and requested the Guy de Burgh and Mike LaBonte join
in this editorial review activity.  The main concern will be to discuss ideas
related to the above technical issues to deal with some syntactical changes
to simplify some of the keyword parameter variations and reduce some possible
occurrences of conflicting information.


IBIS FUTURES (IBIS-X, API, BIRDxx)
Stephen Peters reported that he held some internal meetings with Arpad
Muranyi and Dave Coleman and plans to hold an IBIS Futures Working Group
meeting on March 30, 2000 or March 31, 2000 at some West Coast location.
So far there is sufficient interest to hold the meeting.  Stephen named
several individuals likely to attend.  The purpose of the meeting is to
gather people who have ideas on future directions to review their proposals
and reach a consensus that will lead to a draft proposal.  While several
people are members of the IBIS Futures Working Group, other people who are
interested are welcome to attend.  Arpad commented that he wants a smaller
group who are willing to contribute and produce a consensus proposal.  It
might be counter-productive to have too large of a group.  Bob Ross does not
expect that the group will be too large.


BIRD61.1 - ENHANCED CHARACTERIZATION OF RECEIVERS
Not Discussed.


BIRD64.1 - PACKAGE MODE SELECTOR
Not Discussed.


BIRD65 - C_comp REFINEMENTS
Arpad Muranyi stated that the BIRD65 concept of specifying what rails
portions of C_comp are attached has been implemented commercially.  However,
the implementation format was based on using percentage rather than actual
capacitance values, as proposed in BIRD65.  Arpad asked whether he should
change BIRD65.

After some consideration, the group felt that the BIRD65 format was all right
as is.  Values are translatable into the percentage format and also the
direct entry of actual data was consistent with nearly all other subparameter
specifications.


NEW TECHNOLOGIES
Michael Cohen questioned how to the IBIS Open Forum would deal with some
new technologies that are being realized in silicon by some major vendors.
These deal with new current sensitive or current steering techniques.  The
details are still proprietary.

Bob Ross stated that if it is possible to describe in a behavioral manner the
fundamental aspects, then a BIRD should be proposed.  This has been done for
some other additions to IBIS.  Bob agreed to work off-line with Michael to
clarify this issue further.


NEXT MEETING:
The next meeting will be the IBIS Summit Meeting in Paris, France on Friday,
March 31, 2000 from 8:30 A.M. to 2:00 P.M.  There are no teleconference
connections for this meeting.

The next teleconference meeting will be on Friday, April 14, 2000 from
8:00 AM to 10:00 AM.  BIRD62.6 will be scheduled for voting.

==============================================================================
                                      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  Wed Mar 22 11:53:01 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 LAA26246; Wed, 22 Mar 2000 11:53:00 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id LAA28728; Wed, 22 Mar 2000 11:51:01 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id LAA21679; Wed, 22 Mar 2000 11:51:00 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38D92424.CB7C435F@mentor.com>
Date: Wed, 22 Mar 2000 11:51:00 -0800
From: Bob Ross <bob_ross@mentorg.com>
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
CC: "Lindecker, Francoise" <Francoise_Lindecker@mentorg.com>
Subject: EUROPEAN IBIS SUMMIT MEETING AGENDA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

Below is the planned agenda of the European IBIS Summit Meeting
in Paris, France.  The meeting consists of discussions and
presentations.

The meeting is free to people interested in IBIS modeling, digital
circuit design and related EDA tool development.  Refreshments and
a buffet lunch are included.

If you plan to attend, please notify Francoise Lindecker at the
address at the end.

Bob Ross
Mentor Graphics
Chair, EIA IBIS Open Forum

------------------------------------------------------------------

               AGENDA, EUROPEAN IBIS SUMMIT MEETING
                     Friday, March 31, 2000

                  Room: Salon Van Gogh/Pissarro
                     Concorde-Lafayette Hotel                  
                          Paris, France
   
------------------------------------------------------------------

8:30     REFRESHMENTS & SIGN IN

9:00     INTRODUCTIONS
          - Welcome to Summit - Bob Ross, Mentor Graphics
          - Introductions 

9:15     SIEMENS IBIS MODELING REQUIREMENTS
         Gerald Bannert, Siemens

9:45     TIPS AND TRICKS FOR CREATING IBIS MODELS
         Cary Mandel, Viewlogic Systems

10:15    BREAK

10:30    IBIS ACCURACY STUDIES
         Sherif Hammad, Mentor Graphics

11:00    TC93 WG6 EMC/EMI IC MODEL STANDARDIZATION REPORT
         Jean-Claude Perrin, Texas Instruments

11:45    BUFFET LUNCH (Hosted by Cadence Design)

12:30    BEHAVIORAL RECEIVER MODELING
         Patrick Dos Santos, Cadence Design

13:15    IBIS FUTURE ACTIVITIES (and Discussion)
         Bob Ross, Mentor Graphics

13:45    OPEN DISCUSSIONS

14:00    BREAK AND END OF MEETING

         CONTINUATION OF OPEN DISCUSSIONS

------------------------------------------------------------------

Sponsors:      Cadence, 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.

SIGNUP

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 attend, please supply the information below:

  Name:
  E-mail address:
  Company:
  Telephone:

Send to:

  Francoise Lindecker (francoise_lindecker@mentor.com)
From owner-ibis  Sun Mar 26 19:21:19 2000
Received: from g23.relcom.ru (g23.relcom.ru [193.125.152.117]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA13425 for <ibis@eda.org>; Sun, 26 Mar 2000 19:21:16 -0800 (PST)
Received: from d217.z194-58-100.relcom.ru (d217.z194-58-100.relcom.ru [194.58.100.217]) by g23.relcom.ru (8.8.8/Relcom-2A) with SMTP
	 id GAA03047 ;Mon, 27 Mar 2000 06:13:31 +0300 (MSK)
Message-ID: <001401bf979a$3c598240$d9643ac2@gena>
From: "Gennadiy" <G.Garber@g23.relcom.ru>
To: <ibis@eda.org>
Cc: <ibis-info@vhdl.org>
Subject: ICS
Date: Mon, 27 Mar 2000 07:11:11 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0011_01BF97BB.A1BAB6B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01BF97BB.A1BAB6B0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

Hi Colleagues,


I've developed new version of program ICS (IBIS Circuit Simulator) - =
harmonic balance engine for simulations of connections of digital =
integrated circuits. The driver is given by IBIS model.


ICS allows using S-parameters of elements (transmission lines, for =
example) in simulations of the connections. S-parameters may be measured =
or EM simulated. ICS has open library of elements.


The main difference of new Version 1.11 from previous Version 1.1 is =
using Waveforms in IBIS.=20


If anybody is interested in this program, write me please.


Best regards,

Gennadiy


------=_NextPart_000_0011_01BF97BB.A1BAB6B0
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Dkoi8-r http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D4>
<P>Hi Colleagues,</P>
<P align=3Djustify></P>
<P align=3Djustify>I&rsquo;ve developed new version of program ICS (IBIS =
Circuit=20
Simulator) - harmonic balance engine for simulations of connections of =
digital=20
integrated circuits. The driver is given by IBIS model.</P>
<P align=3Djustify></P>
<P align=3Djustify>ICS allows using S-parameters of elements =
(transmission lines,=20
for example) in simulations of the connections. S-parameters may be =
measured or=20
EM simulated. ICS has open library of elements.</P>
<P align=3Djustify></P>
<P align=3Djustify>The main difference of new Version 1.11 from previous =
Version=20
1.1 is using Waveforms in IBIS. </P>
<P align=3Djustify></P>
<P align=3Djustify>If anybody is interested in this program, write me =
please.</P>
<P align=3Djustify></P>
<P align=3Djustify>Best regards,</P>
<P align=3Djustify>Gennadiy</P></FONT><FONT =
size=3D2></FONT></DIV></BODY></HTML>