From owner-ibis Fri Jan  5 18:25:36 2001
Received: from zulu.us-power.com (IDENT:root@zulu.us-power.com [216.161.16.1])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f062PZj28929
	for <ibis-users@eda.org>; Fri, 5 Jan 2001 18:25:35 -0800 (PST)
Received: from cardinal (msp-65-25-219-87.mn.rr.com [65.25.219.87])
	by zulu.us-power.com (8.9.1a/8.9.1) with SMTP id VAA17365
	for <ibis-users@eda.org>; Fri, 5 Jan 2001 21:25:49 -0600
From: "John Synesiou" <jsynesio@us-power.com>
To: <ibis-users@eda.org>
Subject: unsubscribe
Date: Fri, 5 Jan 2001 20:21:51 -0600
Message-ID: <NEBBJIEAILHNOHOAGFBEEEALCGAA.jsynesio@us-power.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A13EBC1.E1436E9D@mchr2.siemens.de>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit

unsubscribe

 
From owner-ibis Fri Jan  5 18:31:11 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f062V9j28943;
	Fri, 5 Jan 2001 18:31:10 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id SAA26468; Fri, 5 Jan 2001 18:27:27 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CDTAQK10; Fri, 5 Jan 2001 18:27:27 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A56828E.12081CCF@mentor.com>
Date: Fri, 05 Jan 2001 18:27:26 -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: New IBIS ibischk3 Executables
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

New ibischk3 executables designate Version 3.2.6 have been uploaded
in the ibischk3 link from the EIA IBIS home page Free Tools site.

These executables are available at

  http://www.eda.org/pub/ibis/ibischk3/

Thanks to Guy de Burgh and Matthew Flora for generating them.  The
Linux executable should be available shortly.  The older Version 3.2.5
executables are archived under the same directory.

Bob Ross
Mentor Graphics
 
From owner-ibis Sun Jan  7 16:35:27 2001
Received: from comm.sec.samsung.co.kr ([168.219.245.5])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f080ZPj04015
	for <ibis-users@eda.org>; Sun, 7 Jan 2001 16:35:26 -0800 (PST)
Received: by COMM with Internet Mail Service (5.5.2650.21)
	id <CD7YD9ZZ>; Mon, 8 Jan 2001 09:30:24 +0900
Message-ID: <33B300B06FDDD411AEAB00A0C9ACAD7E5F74@COMM>
From: Sung Ki LIM - Computer <lsk1101@comm.sec.samsung.co.kr>
To: ibis-users@eda.org
Subject: 
Date: Mon, 8 Jan 2001 09:30:14 +0900 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="KS_C_5601-1987"

unsubscribe
 
From owner-ibis Tue Jan  9 16:52:18 2001
Received: from cisco.com (ups.cisco.com [171.69.18.21])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0A0qFj14943
	for <ibis-users@eda.org>; Tue, 9 Jan 2001 16:52:18 -0800 (PST)
Received: from ups.cisco.com (ups.cisco.com [171.69.18.21])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA08942
	for <ibis-users@eda.org>; Tue, 9 Jan 2001 16:48:32 -0800 (PST)
Message-Id: <200101100048.QAA08942@cisco.com>
Date: Tue, 9 Jan 2001 16:48:32 -0800 (PST)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: new ibischk3 V3.2.6
To: ibis-users@eda.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: /bkaFp+trCcHNB/n8IFS1g==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 

I ran a model with the NEW ibischk3 ver3.2.6 and get this:

new version:
ERROR - Model XYZ_IO: The [Rising Waveform] 
      with [R_fixture]=50 Ohms and [V_fixture]=2.5V
      has TYP column DC endpoints of  0.41V and  2.50v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages (-0.70V and  2.50V),


In the earlier version(V3.2.5),this would show up as a WARNING. Since now
it shows up as ERROR, the file fails.

old version:
WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,  2.50V) not within 
          0.042V (2%) of (-0.70V,  2.50V) on VI curves for 50 Ohms to 2.5V

Why was this changed to ERROR ? 

Syed

 
From owner-ibis Tue Jan  9 17:26:47 2001
Received: from selene.cps.intel.com (selene.cps.intel.com [192.198.165.10])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0A1Qjj15071
	for <ibis-users@eda.org>; Tue, 9 Jan 2001 17:26:46 -0800 (PST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id RAA19397;
	Tue, 9 Jan 2001 17:23:01 -0800 (PST)
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 10 Jan 2001 01:23:00 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <Z4N00B2D>; Tue, 9 Jan 2001 17:22:59 -0800
Message-ID: <B277BC01AFFAD211AC4E00A0C95D74030666BF1C@fmsmsx66.fm.intel.com>
From: "Mirmak, Michael" <michael.mirmak@intel.com>
To: Syed Huq <shuq@cisco.com>, ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6
Date: Tue, 9 Jan 2001 17:22:56 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"


Syed,

This looks to be the implementation of BUG47, which flags extreme (greater
than 10%) IV-to-VT mismatches as errors instead of merely warnings.  See the
BUG47 filing for details.

- Michael Mirmak, Intel Corp.

-----Original Message-----
From: Syed Huq [mailto:shuq@cisco.com]
Sent: Tuesday, January 09, 2001 4:49 PM
To: ibis-users@eda.org
Subject: new ibischk3 V3.2.6


I ran a model with the NEW ibischk3 ver3.2.6 and get this:

new version:
ERROR - Model XYZ_IO: The [Rising Waveform] 
      with [R_fixture]=50 Ohms and [V_fixture]=2.5V
      has TYP column DC endpoints of  0.41V and  2.50v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages (-0.70V and  2.50V),


In the earlier version(V3.2.5),this would show up as a WARNING. Since now
it shows up as ERROR, the file fails.

old version:
WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,  2.50V) not
within 
          0.042V (2%) of (-0.70V,  2.50V) on VI curves for 50 Ohms to 2.5V

Why was this changed to ERROR ? 

Syed


 
From owner-ibis Tue Jan  9 17:29:26 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0A1TMj15088
	for <ibis-users@eda.org>; Tue, 9 Jan 2001 17:29:24 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id RAA00482; Tue, 9 Jan 2001 17:25:38 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CDTARZ9R; Tue, 9 Jan 2001 17:25:37 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A5BBA0F.579B0077@mentor.com>
Date: Tue, 09 Jan 2001 17:25:35 -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: Syed Huq <shuq@cisco.com>
CC: ibis-users@eda.org
Subject: Re: new ibischk3 V3.2.6
References: <200101100048.QAA08942@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Syed:

The new ibischk3 changed the Warning message to an Error
message when the mismatch exceeded 10%.  In your example,
the mismatch between 0.41 and -0.71 exceeds the 10% value
of the range (.21v).  There may exist a real problem that
needs to be examined.  This change is documented as BUG47:

  http://www.eda.org/pub/ibis/bugs/ibischk/bug47  

However, the -0.71 value is suspicious.  I have seen a
similar problem when some of the end point I-V currents are
extremely large (such as 1e20) and cause ibischk3 to
not properly converge to the correct DC endpoints.  You
might check this and try smaller values if such large
values exist.  Your model might actually be correct.

Bob Ross
Mentor Graphics


Syed Huq wrote:
> 
> I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> 
> new version:
> ERROR - Model XYZ_IO: The [Rising Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
>       has TYP column DC endpoints of  0.41V and  2.50v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages (-0.70V and  2.50V),
> 
> In the earlier version(V3.2.5),this would show up as a WARNING. Since now
> it shows up as ERROR, the file fails.
> 
> old version:
> WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,  2.50V) not within
>           0.042V (2%) of (-0.70V,  2.50V) on VI curves for 50 Ohms to 2.5V
> 
> Why was this changed to ERROR ?
> 
> Syed
 
From owner-ibis Tue Jan  9 22:03:22 2001
Received: from cisco.com (ups.cisco.com [171.69.18.21])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0A63Lj15764
	for <ibis-users@eda.org>; Tue, 9 Jan 2001 22:03:22 -0800 (PST)
Received: from ups.cisco.com (ups.cisco.com [171.69.18.21])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id VAA20929
	for <ibis-users@eda.org>; Tue, 9 Jan 2001 21:59:37 -0800 (PST)
Message-Id: <200101100559.VAA20929@cisco.com>
Date: Tue, 9 Jan 2001 21:59:37 -0800 (PST)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: another new parser question ibischk3 V3.2.6
To: ibis-users@eda.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 2fWHqSFQpuNw2LDCJGEZcQ==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 

Dear Gurus:

I am quite amazed by the amount of information the parser reports. 
Let me explain and I would like to understand the reasons too:

1) For every pin of this 456BGA package, it reports that the R_pin, L_pin
and C_pin are missing. I already know this simply by opening the IBIS file
and looking at the [Pin] list section.

Why do I need to scroll thru all these:
.
<parser output>
.
PIN:signal_name:<DQ[71]>
PIN:model_name:<XYZ_IO>
PIN:R_Pin:NOT SET
PIN:L_Pin:NOT SET
PIN:C_Pin:NOT SET
PIN:Pin:<A3>
PIN:signal_name:<VDDQ>
PIN:model_name:<POWER>
PIN:R_Pin:NOT SET
PIN:L_Pin:NOT SET
PIN:C_Pin:NOT SET
PIN:Pin:<A4>
PIN:signal_name:<DQ[67]>
PIN:model_name:<XYZ_IO>
PIN:R_Pin:NOT SET
PIN:L_Pin:NOT SET
PIN:C_Pin:NOT SET
.
.

2) Why does the parser output print all the V/I and V/T table data ?
.
Pulldown:
Voltage:-2.5, Typ:-0.12, Min:-0.09518, Max:-0.13
Voltage:-2.3, Typ:-0.12, Min:-0.09518, Max:-0.13
Voltage:-2.1, Typ:-0.12, Min:-0.09518, Max:-0.13
.
.

3) Why does the parser not show the value of Cref clearly defined in
the IBIS model ?

Parser:
Model Name:XYZ_TRI
Model_type:3-state
Polarity:Non-Inverting
Enable:Active-High
Vinl:NOT SET
Vinh:NOT SET
Vmeas:1.500000
Cref:0.000000	<------ ??

IBIS:
[Model]          XYZ_TRI
Model_type       3-state
Polarity         Non-Inverting
Enable           Active-High
Vmeas =   1.50V
Cref =  50.00pF	<------ It's there ..

4) Why does the parser not show the dT values for Ramp ?

<parser output>
dV/dt_r:Typ:1.150000/0.000000, Min:0.820000/0.000000, Max:1.280000/0.000000
dV/dt_f:Typ:1.250000/0.000000, Min:1.050000/0.000000, Max:1.360000/0.000000

IBIS model:
dV/dt_r          1.15/0.31n          0.82/0.37n          1.28/0.22n
dV/dt_f          1.25/0.22n          1.05/0.32n          1.36/0.15n


5) Is there a switch a user could use to minimize a lot of these messages ?

Regards,
Syed


 
From owner-ibis Wed Jan 10 09:05:10 2001
Received: from ausxc08.us.dell.com (ausxc08.us.dell.com [143.166.99.216])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AH58j18608
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 09:05:09 -0800 (PST)
Received: by ausxc08.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <CG0J363C>; Wed, 10 Jan 2001 11:01:07 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F69B@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: bob_ross@mentorg.com, shuq@cisco.com
Cc: ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6
Date: Wed, 10 Jan 2001 11:00:56 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C07B26.EBC56AB2"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C07B26.EBC56AB2
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,
I'm not sure I agree with your statement that a model with end point I-V
currents that are "extremely large (such as 1e20)" "might actually be
correct" even if those data points are produced from a valid spice deck.
The purpose of a model is to reflect reality where possible and 1e20
amps????

Aubrey Sparkman
Signal Integrity
Aubrey_Sparkman@Dell.com
(512) 723-3592


> -----Original Message-----
> From: Bob Ross [mailto:bob_ross@mentorg.com]
> Sent: Tuesday, January 09, 2001 7:26 PM
> To: Syed Huq
> Cc: ibis-users@eda.org
> Subject: Re: new ibischk3 V3.2.6
> 
> 
> Syed:
> 
> The new ibischk3 changed the Warning message to an Error
> message when the mismatch exceeded 10%.  In your example,
> the mismatch between 0.41 and -0.71 exceeds the 10% value
> of the range (.21v).  There may exist a real problem that
> needs to be examined.  This change is documented as BUG47:
> 
>   http://www.eda.org/pub/ibis/bugs/ibischk/bug47  
> 
> However, the -0.71 value is suspicious.  I have seen a
> similar problem when some of the end point I-V currents are
> extremely large (such as 1e20) and cause ibischk3 to
> not properly converge to the correct DC endpoints.  You
> might check this and try smaller values if such large
> values exist.  Your model might actually be correct.
> 
> Bob Ross
> Mentor Graphics
> 
> 
> Syed Huq wrote:
> > 
> > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > 
> > new version:
> > ERROR - Model XYZ_IO: The [Rising Waveform]
> >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> >       has TYP column DC endpoints of  0.41V and  2.50v, but
> >       an equivalent load applied to the model's I-V tables yields
> >       different voltages (-0.70V and  2.50V),
> > 
> > In the earlier version(V3.2.5),this would show up as a 
> WARNING. Since now
> > it shows up as ERROR, the file fails.
> > 
> > old version:
> > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,  
> 2.50V) not within
> >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for 
> 50 Ohms to 2.5V
> > 
> > Why was this changed to ERROR ?
> > 
> > Syed
> 


------_=_NextPart_000_01C07B26.EBC56AB2
Content-Type: application/octet-stream;
	name="Sparkman, Aubrey.vcf"
Content-Disposition: attachment;
	filename="Sparkman, Aubrey.vcf"

BEGIN:VCARD
VERSION:2.1
N:Sparkman;Aubrey
FN:Sparkman, Aubrey
EMAIL;PREF;INTERNET:Aubrey_Sparkman@Dell.com
REV:19990728T212924Z
END:VCARD

------_=_NextPart_000_01C07B26.EBC56AB2--
 
From owner-ibis Wed Jan 10 09:59:35 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AHxXj18731
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 09:59:34 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id JAA25204; Wed, 10 Jan 2001 09:55:46 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CDTASDLF; Wed, 10 Jan 2001 09:55:46 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A5CA21F.F45D3E15@mentor.com>
Date: Wed, 10 Jan 2001 09:55:43 -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: Aubrey_Sparkman@dell.com
CC: bob_ross@mentorg.com, shuq@cisco.com, ibis-users@eda.org
Subject: Re: new ibischk3 V3.2.6
References: <CDF99E351003D311A8B0009027457F1405C5F69B@ausxmrr501.us.dell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aubrey:

I agree that a large current does not reflect reality.  It turns
out that if such a current exists at the ends of certain I-V
tables, the ibischk3 DC algorithm may not converge to the
correct set of DC values for a given Waveform table load - thus
causing an Error or Warning message in cases where the V-T
table amplitudes are correct and consistent with the I-V tables.

It turned out that Syed found a repeated voltage point at -0.71V
in one of the tables that caused the false I-V voltage point.
Removing one line in the table eliminated the Error message.

For the purposes of accurate simulation in the regions of
interest, extreme currents well outside of these regions of
interest theoretically should not be a problem because they
would never be encountered in practice.  However, such currents
might cause unexpected numerical problems.

The general statement is that all Warnings and Errors should
be examined, understood, and fixed, if possible.  Sometimes
they may be issued because of some unrelated serious problem.

Bob
Mentor Graphics



Aubrey_Sparkman@Dell.com wrote:
> 
> Bob,
> I'm not sure I agree with your statement that a model with end point I-V
> currents that are "extremely large (such as 1e20)" "might actually be
> correct" even if those data points are produced from a valid spice deck.
> The purpose of a model is to reflect reality where possible and 1e20
> amps????
> 
> Aubrey Sparkman
> Signal Integrity
> Aubrey_Sparkman@Dell.com
> (512) 723-3592
> 
> > -----Original Message-----
> > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > Sent: Tuesday, January 09, 2001 7:26 PM
> > To: Syed Huq
> > Cc: ibis-users@eda.org
> > Subject: Re: new ibischk3 V3.2.6
> >
> >
> > Syed:
> >
> > The new ibischk3 changed the Warning message to an Error
> > message when the mismatch exceeded 10%.  In your example,
> > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > of the range (.21v).  There may exist a real problem that
> > needs to be examined.  This change is documented as BUG47:
> >
> >   http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> >
> > However, the -0.71 value is suspicious.  I have seen a
> > similar problem when some of the end point I-V currents are
> > extremely large (such as 1e20) and cause ibischk3 to
> > not properly converge to the correct DC endpoints.  You
> > might check this and try smaller values if such large
> > values exist.  Your model might actually be correct.
> >
> > Bob Ross
> > Mentor Graphics
> >
> >
> > Syed Huq wrote:
> > >
> > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > >
> > > new version:
> > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > >       has TYP column DC endpoints of  0.41V and  2.50v, but
> > >       an equivalent load applied to the model's I-V tables yields
> > >       different voltages (-0.70V and  2.50V),
> > >
> > > In the earlier version(V3.2.5),this would show up as a
> > WARNING. Since now
> > > it shows up as ERROR, the file fails.
> > >
> > > old version:
> > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > 2.50V) not within
> > >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for
> > 50 Ohms to 2.5V
> > >
> > > Why was this changed to ERROR ?
> > >
> > > Syed
> >
 
From owner-ibis Wed Jan 10 09:59:44 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AHxgj18734
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 09:59:43 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id JAA25232; Wed, 10 Jan 2001 09:55:58 -0800 (PST)
Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19)
	id <CDTASDLK>; Wed, 10 Jan 2001 09:55:58 -0800
Message-ID: <2179BC5B6583D311B44700508B44146901BACE77@svr-orw-exc-02.wv.mentorg.com>
From: "Dunbar, Tony" <tony_dunbar@mentorg.com>
To: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: RE: new ibischk3 V3.2.6
Date: Wed, 10 Jan 2001 09:55:57 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

Aubrey,

First of all, let me just set the scene. In this e-mail, I am ONLY referring
to the situation of gross currents in the V-I tables.

From a purist stand-point, I agree with you. Unfortunately, in my experience
the reality is that many, many IBIS models derived from SPICE exhibit these
giga-amp characteristics. I think what Bob means is that the model is
correct in that it reflects what the SPICE model has. A further reality is
that the IBIS forum is not going to change the world; these decks and models
are not going to change to satisfy this anomoly. Fortunately, they usually
occur well away from the normal operating region and normal clamping region
so, in actual operation, they don't give us a problem.

Given that this is reality and it's not going to change, I think we (the
IBIS forum) need to look at what, if anything, we are going to change to
deal with it? Maybe we need to change things a little to be closer to this
normal operation. One question is, 'what is the reasoning behind the
(somewhat large) range of (2xVCC to -1xVCC) for the V-I tables?'; can this
be truncated? Or, better (IMHO), check that the clamp currents are
reasonable(?) within a tighter range; i.e. closer to the normal operating
region and to a limit more aligned with an expected clamping event; e.g.
VCC+1.0V and GND-1.0V.

Yes, it sounds like capitulation, but I think it's the only practical
course.

-----Original Message-----
From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
Sent: Wednesday, January 10, 2001 11:01 AM
To: bob_ross@mentorg.com; shuq@cisco.com
Cc: ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6


Bob,
I'm not sure I agree with your statement that a model with end point I-V
currents that are "extremely large (such as 1e20)" "might actually be
correct" even if those data points are produced from a valid spice deck.
The purpose of a model is to reflect reality where possible and 1e20
amps????

Aubrey Sparkman
Signal Integrity
Aubrey_Sparkman@Dell.com
(512) 723-3592


> -----Original Message-----
> From: Bob Ross [mailto:bob_ross@mentorg.com]
> Sent: Tuesday, January 09, 2001 7:26 PM
> To: Syed Huq
> Cc: ibis-users@eda.org
> Subject: Re: new ibischk3 V3.2.6
> 
> 
> Syed:
> 
> The new ibischk3 changed the Warning message to an Error
> message when the mismatch exceeded 10%.  In your example,
> the mismatch between 0.41 and -0.71 exceeds the 10% value
> of the range (.21v).  There may exist a real problem that
> needs to be examined.  This change is documented as BUG47:
> 
>   http://www.eda.org/pub/ibis/bugs/ibischk/bug47  
> 
> However, the -0.71 value is suspicious.  I have seen a
> similar problem when some of the end point I-V currents are
> extremely large (such as 1e20) and cause ibischk3 to
> not properly converge to the correct DC endpoints.  You
> might check this and try smaller values if such large
> values exist.  Your model might actually be correct.
> 
> Bob Ross
> Mentor Graphics
> 
> 
> Syed Huq wrote:
> > 
> > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > 
> > new version:
> > ERROR - Model XYZ_IO: The [Rising Waveform]
> >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> >       has TYP column DC endpoints of  0.41V and  2.50v, but
> >       an equivalent load applied to the model's I-V tables yields
> >       different voltages (-0.70V and  2.50V),
> > 
> > In the earlier version(V3.2.5),this would show up as a 
> WARNING. Since now
> > it shows up as ERROR, the file fails.
> > 
> > old version:
> > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,  
> 2.50V) not within
> >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for 
> 50 Ohms to 2.5V
> > 
> > Why was this changed to ERROR ?
> > 
> > Syed
> 

 
From owner-ibis Wed Jan 10 11:13:31 2001
Received: from odin.acuson.com (odin.acuson.com [157.226.230.71])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AJDPj19005
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 11:13:29 -0800 (PST)
Received: from acuson.com ([157.226.45.34]) by odin.acuson.com
          (Netscape Messaging Server 3.54)  with ESMTP id AAA1A91;
          Wed, 10 Jan 2001 11:13:51 -0800
Sender: "Kim Helliwell" <khelliwe@acuson.com>
Message-ID: <3A5CB2B0.581934B1@acuson.com>
Date: Wed, 10 Jan 2001 11:06:24 -0800
From: Kim Helliwell <khelliwe@acuson.com>
Organization: Acuson
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dunbar, Tony" <tony_dunbar@mentorg.com>
CC: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: Re: new ibischk3 V3.2.6
References: <2179BC5B6583D311B44700508B44146901BACE77@svr-orw-exc-02.wv.mentorg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have another perspective. This problem is almost certainly caused
by diode models in the SPICE netlist that are "ideal" models; that
is, there is no series parasitic resistance (RS) specified.

And I think it's more than reasonable for the IBIS community to demand
that suppliers of SPICE or IBIS models do not use such ideal components
in the model.  This is a well-known SPICE trouble spot, and anyone who
still perpetrates that sin appears to me to be a rank amateur. It causes
me to wonder what other inaccuracies exist in the models that exhibit this
problem.

Kim

"Dunbar, Tony" wrote:
> 
> Aubrey,
> 
> First of all, let me just set the scene. In this e-mail, I am ONLY referring
> to the situation of gross currents in the V-I tables.
> 
> >From a purist stand-point, I agree with you. Unfortunately, in my experience
> the reality is that many, many IBIS models derived from SPICE exhibit these
> giga-amp characteristics. I think what Bob means is that the model is
> correct in that it reflects what the SPICE model has. A further reality is
> that the IBIS forum is not going to change the world; these decks and models
> are not going to change to satisfy this anomoly. Fortunately, they usually
> occur well away from the normal operating region and normal clamping region
> so, in actual operation, they don't give us a problem.
> 
> Given that this is reality and it's not going to change, I think we (the
> IBIS forum) need to look at what, if anything, we are going to change to
> deal with it? Maybe we need to change things a little to be closer to this
> normal operation. One question is, 'what is the reasoning behind the
> (somewhat large) range of (2xVCC to -1xVCC) for the V-I tables?'; can this
> be truncated? Or, better (IMHO), check that the clamp currents are
> reasonable(?) within a tighter range; i.e. closer to the normal operating
> region and to a limit more aligned with an expected clamping event; e.g.
> VCC+1.0V and GND-1.0V.
> 
> Yes, it sounds like capitulation, but I think it's the only practical
> course.
> 
> -----Original Message-----
> From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> Sent: Wednesday, January 10, 2001 11:01 AM
> To: bob_ross@mentorg.com; shuq@cisco.com
> Cc: ibis-users@eda.org
> Subject: RE: new ibischk3 V3.2.6
> 
> Bob,
> I'm not sure I agree with your statement that a model with end point I-V
> currents that are "extremely large (such as 1e20)" "might actually be
> correct" even if those data points are produced from a valid spice deck.
> The purpose of a model is to reflect reality where possible and 1e20
> amps????
> 
> Aubrey Sparkman
> Signal Integrity
> Aubrey_Sparkman@Dell.com
> (512) 723-3592
> 
> > -----Original Message-----
> > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > Sent: Tuesday, January 09, 2001 7:26 PM
> > To: Syed Huq
> > Cc: ibis-users@eda.org
> > Subject: Re: new ibischk3 V3.2.6
> >
> >
> > Syed:
> >
> > The new ibischk3 changed the Warning message to an Error
> > message when the mismatch exceeded 10%.  In your example,
> > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > of the range (.21v).  There may exist a real problem that
> > needs to be examined.  This change is documented as BUG47:
> >
> >   http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> >
> > However, the -0.71 value is suspicious.  I have seen a
> > similar problem when some of the end point I-V currents are
> > extremely large (such as 1e20) and cause ibischk3 to
> > not properly converge to the correct DC endpoints.  You
> > might check this and try smaller values if such large
> > values exist.  Your model might actually be correct.
> >
> > Bob Ross
> > Mentor Graphics
> >
> >
> > Syed Huq wrote:
> > >
> > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > >
> > > new version:
> > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > >       has TYP column DC endpoints of  0.41V and  2.50v, but
> > >       an equivalent load applied to the model's I-V tables yields
> > >       different voltages (-0.70V and  2.50V),
> > >
> > > In the earlier version(V3.2.5),this would show up as a
> > WARNING. Since now
> > > it shows up as ERROR, the file fails.
> > >
> > > old version:
> > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > 2.50V) not within
> > >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for
> > 50 Ohms to 2.5V
> > >
> > > Why was this changed to ERROR ?
> > >
> > > Syed
> >

-- 
Kim Helliwell
Senior CAE Engineer
Acuson Corporation
Phone: 650 694 5030  FAX: 650 943 7260
 
From owner-ibis Wed Jan 10 11:41:54 2001
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AJfqj19142
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 11:41:53 -0800 (PST)
Received: from ix.netcom.com (pool-63.50.101.135.rlgh.grid.net [63.50.101.135])
	by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA11899;
	Wed, 10 Jan 2001 14:38:08 -0500 (EST)
Message-ID: <3A5CBA41.22C776A2@ix.netcom.com>
Date: Wed, 10 Jan 2001 11:38:41 -0800
From: AC <comeral@ix.netcom.com>
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Dunbar, Tony" <tony_dunbar@mentorg.com>
CC: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: Re: new ibischk3 V3.2.6
References: <2179BC5B6583D311B44700508B44146901BACE77@svr-orw-exc-02.wv.mentorg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Howdy:

I have also obtained models with unphysical currents of up to 1e25amps
(mostly in the diode clamp tables), which I think means that the diode
in question would supposedly dissipate more heat than is generated by
the sun.

Although it may seem easier for the model-builder to be able to throw
anything they want into a model, I personally think that requiring
models to pass "sanity checks" on the order of astronomical units is not
asking too much, especially if it is likely to cause numerical problems
in the simulators. 

Perhaps it would be useful for the parser to have a
"model-builder/model-user" or "verbose/quiet" switch, which would
perform more-detailed checks when a model is being constructed. It seems
to me that an "unphysical current" test in the parser would be
appropriate, at least in verbose mode -

Alan Comer


"Dunbar, Tony" wrote:
> 
> Aubrey,
> 
> First of all, let me just set the scene. In this e-mail, I am ONLY referring
> to the situation of gross currents in the V-I tables.
> 
> >From a purist stand-point, I agree with you. Unfortunately, in my experience
> the reality is that many, many IBIS models derived from SPICE exhibit these
> giga-amp characteristics. I think what Bob means is that the model is
> correct in that it reflects what the SPICE model has. A further reality is
> that the IBIS forum is not going to change the world; these decks and models
> are not going to change to satisfy this anomoly. Fortunately, they usually
> occur well away from the normal operating region and normal clamping region
> so, in actual operation, they don't give us a problem.
> 
> Given that this is reality and it's not going to change, I think we (the
> IBIS forum) need to look at what, if anything, we are going to change to
> deal with it? Maybe we need to change things a little to be closer to this
> normal operation. One question is, 'what is the reasoning behind the
> (somewhat large) range of (2xVCC to -1xVCC) for the V-I tables?'; can this
> be truncated? Or, better (IMHO), check that the clamp currents are
> reasonable(?) within a tighter range; i.e. closer to the normal operating
> region and to a limit more aligned with an expected clamping event; e.g.
> VCC+1.0V and GND-1.0V.
> 
> Yes, it sounds like capitulation, but I think it's the only practical
> course.
> 
> -----Original Message-----
> From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> Sent: Wednesday, January 10, 2001 11:01 AM
> To: bob_ross@mentorg.com; shuq@cisco.com
> Cc: ibis-users@eda.org
> Subject: RE: new ibischk3 V3.2.6
> 
> Bob,
> I'm not sure I agree with your statement that a model with end point I-V
> currents that are "extremely large (such as 1e20)" "might actually be
> correct" even if those data points are produced from a valid spice deck.
> The purpose of a model is to reflect reality where possible and 1e20
> amps????
> 
> Aubrey Sparkman
> Signal Integrity
> Aubrey_Sparkman@Dell.com
> (512) 723-3592
> 
> > -----Original Message-----
> > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > Sent: Tuesday, January 09, 2001 7:26 PM
> > To: Syed Huq
> > Cc: ibis-users@eda.org
> > Subject: Re: new ibischk3 V3.2.6
> >
> >
> > Syed:
> >
> > The new ibischk3 changed the Warning message to an Error
> > message when the mismatch exceeded 10%.  In your example,
> > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > of the range (.21v).  There may exist a real problem that
> > needs to be examined.  This change is documented as BUG47:
> >
> >   http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> >
> > However, the -0.71 value is suspicious.  I have seen a
> > similar problem when some of the end point I-V currents are
> > extremely large (such as 1e20) and cause ibischk3 to
> > not properly converge to the correct DC endpoints.  You
> > might check this and try smaller values if such large
> > values exist.  Your model might actually be correct.
> >
> > Bob Ross
> > Mentor Graphics
> >
> >
> > Syed Huq wrote:
> > >
> > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > >
> > > new version:
> > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > >       has TYP column DC endpoints of  0.41V and  2.50v, but
> > >       an equivalent load applied to the model's I-V tables yields
> > >       different voltages (-0.70V and  2.50V),
> > >
> > > In the earlier version(V3.2.5),this would show up as a
> > WARNING. Since now
> > > it shows up as ERROR, the file fails.
> > >
> > > old version:
> > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > 2.50V) not within
> > >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for
> > 50 Ohms to 2.5V
> > >
> > > Why was this changed to ERROR ?
> > >
> > > Syed
> >
 
From owner-ibis Wed Jan 10 11:52:59 2001
Received: from ausxc07.us.dell.com (ausxc07.us.dell.com [143.166.99.215])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AJqwj19187
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 11:52:59 -0800 (PST)
Received: by ausxc07.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <CD3P2J9S>; Wed, 10 Jan 2001 13:47:22 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F69D@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: khelliwe@acuson.com, tony_dunbar@mentorg.com
Cc: ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6
Date: Wed, 10 Jan 2001 13:47:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C07B3E.24CEE402"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C07B3E.24CEE402
Content-Type: text/plain;
	charset="iso-8859-1"

Thank you Tony, I was hoping for a discussion of what the IBIS community
could do about this problem.

And Thank you Kim, for pointing out one of the reasons I might receive IBIS
data with unrealistic currents.  Can anyone out there describe a realistic
scenerio (not caused by ideal models) that might cause "giga-amp
characteristics"?

Thanks!

Aubrey Sparkman
Signal Integrity
Aubrey_Sparkman@Dell.com
(512) 723-3592


> -----Original Message-----
> From: Kim Helliwell [mailto:khelliwe@acuson.com]
> Sent: Wednesday, January 10, 2001 1:06 PM
> To: Dunbar, Tony
> Cc: 'ibis-users@eda.org'
> Subject: Re: new ibischk3 V3.2.6
> 
> 
> I have another perspective. This problem is almost certainly caused
> by diode models in the SPICE netlist that are "ideal" models; that
> is, there is no series parasitic resistance (RS) specified.
> 
> And I think it's more than reasonable for the IBIS community to demand
> that suppliers of SPICE or IBIS models do not use such ideal 
> components
> in the model.  This is a well-known SPICE trouble spot, and anyone who
> still perpetrates that sin appears to me to be a rank 
> amateur. It causes
> me to wonder what other inaccuracies exist in the models that 
> exhibit this
> problem.
> 
> Kim
> 
> "Dunbar, Tony" wrote:
> > 
> > Aubrey,
> > 
> > First of all, let me just set the scene. In this e-mail, I 
> am ONLY referring
> > to the situation of gross currents in the V-I tables.
> > 
> > >From a purist stand-point, I agree with you. 
> Unfortunately, in my experience
> > the reality is that many, many IBIS models derived from 
> SPICE exhibit these
> > giga-amp characteristics. I think what Bob means is that 
> the model is
> > correct in that it reflects what the SPICE model has. A 
> further reality is
> > that the IBIS forum is not going to change the world; these 
> decks and models
> > are not going to change to satisfy this anomoly. 
> Fortunately, they usually
> > occur well away from the normal operating region and normal 
> clamping region
> > so, in actual operation, they don't give us a problem.
> > 
> > Given that this is reality and it's not going to change, I 
> think we (the
> > IBIS forum) need to look at what, if anything, we are going 
> to change to
> > deal with it? Maybe we need to change things a little to be 
> closer to this
> > normal operation. One question is, 'what is the reasoning behind the
> > (somewhat large) range of (2xVCC to -1xVCC) for the V-I 
> tables?'; can this
> > be truncated? Or, better (IMHO), check that the clamp currents are
> > reasonable(?) within a tighter range; i.e. closer to the 
> normal operating
> > region and to a limit more aligned with an expected 
> clamping event; e.g.
> > VCC+1.0V and GND-1.0V.
> > 
> > Yes, it sounds like capitulation, but I think it's the only 
> practical
> > course.
> > 
> > -----Original Message-----
> > From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> > Sent: Wednesday, January 10, 2001 11:01 AM
> > To: bob_ross@mentorg.com; shuq@cisco.com
> > Cc: ibis-users@eda.org
> > Subject: RE: new ibischk3 V3.2.6
> > 
> > Bob,
> > I'm not sure I agree with your statement that a model with 
> end point I-V
> > currents that are "extremely large (such as 1e20)" "might 
> actually be
> > correct" even if those data points are produced from a 
> valid spice deck.
> > The purpose of a model is to reflect reality where possible and 1e20
> > amps????
> > 
> > Aubrey Sparkman
> > Signal Integrity
> > Aubrey_Sparkman@Dell.com
> > (512) 723-3592
> > 
> > > -----Original Message-----
> > > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > > Sent: Tuesday, January 09, 2001 7:26 PM
> > > To: Syed Huq
> > > Cc: ibis-users@eda.org
> > > Subject: Re: new ibischk3 V3.2.6
> > >
> > >
> > > Syed:
> > >
> > > The new ibischk3 changed the Warning message to an Error
> > > message when the mismatch exceeded 10%.  In your example,
> > > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > > of the range (.21v).  There may exist a real problem that
> > > needs to be examined.  This change is documented as BUG47:
> > >
> > >   http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> > >
> > > However, the -0.71 value is suspicious.  I have seen a
> > > similar problem when some of the end point I-V currents are
> > > extremely large (such as 1e20) and cause ibischk3 to
> > > not properly converge to the correct DC endpoints.  You
> > > might check this and try smaller values if such large
> > > values exist.  Your model might actually be correct.
> > >
> > > Bob Ross
> > > Mentor Graphics
> > >
> > >
> > > Syed Huq wrote:
> > > >
> > > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > > >
> > > > new version:
> > > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > > >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > > >       has TYP column DC endpoints of  0.41V and  2.50v, but
> > > >       an equivalent load applied to the model's I-V 
> tables yields
> > > >       different voltages (-0.70V and  2.50V),
> > > >
> > > > In the earlier version(V3.2.5),this would show up as a
> > > WARNING. Since now
> > > > it shows up as ERROR, the file fails.
> > > >
> > > > old version:
> > > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > > 2.50V) not within
> > > >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for
> > > 50 Ohms to 2.5V
> > > >
> > > > Why was this changed to ERROR ?
> > > >
> > > > Syed
> > >
> 
> -- 
> Kim Helliwell
> Senior CAE Engineer
> Acuson Corporation
> Phone: 650 694 5030  FAX: 650 943 7260
> 


------_=_NextPart_000_01C07B3E.24CEE402
Content-Type: application/octet-stream;
	name="Sparkman, Aubrey.vcf"
Content-Disposition: attachment;
	filename="Sparkman, Aubrey.vcf"

BEGIN:VCARD
VERSION:2.1
N:Sparkman;Aubrey
FN:Sparkman, Aubrey
EMAIL;PREF;INTERNET:Aubrey_Sparkman@Dell.com
REV:19990728T212924Z
END:VCARD

------_=_NextPart_000_01C07B3E.24CEE402--
 
From owner-ibis Wed Jan 10 12:10:04 2001
Received: from paloalto-smrly2.gtei.net (paloalto-smrly2.gtei.net [131.119.246.6])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AKA1j19237
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 12:10:03 -0800 (PST)
Received: from fairchild-cp.fairchildsemi.com (fairchild-cp.fairchildsemi.com [192.233.132.79])
	by paloalto-smrly2.gtei.net (Postfix) with SMTP id D35AC3F28
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 20:06:19 +0000 (GMT)
Received: FROM fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Wed Jan 10 15:03:41 2001 -0800
Received: from spor02.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4)
	id PAA21978; Wed, 10 Jan 2001 15:05:16 -0500
Received: from CONVERSION-DAEMON by spf.fairchildsemi.com (PMDF V5.2-33 #43442)
 id <01JYQVU12QJKHL1OPC@spf.fairchildsemi.com> for ibis-users@eda.org; Wed,
 10 Jan 2001 15:06:56 EST
Received: from spf.fairchildsemi.com
 (gconnolly-fm.fairchildsemi.com [172.21.63.117])
 by spf.fairchildsemi.com (PMDF V5.2-33 #34675)
 with ESMTP id <01JYQVU0J306GZU3EO@spf.fairchildsemi.com> for
 ibis-users@eda.org; Wed, 10 Jan 2001 15:06:55 -0500 (EST)
Date: Wed, 10 Jan 2001 15:06:15 -0500
From: Graham Connolly <graham@spf.fairchildsemi.com>
Subject: Subscribe
To: ibis-users@eda.org
Reply-To: Graham.Connolly@fairchildsemi.com
Message-id: <3A5CC0B7.740B58D4@spf.fairchildsemi.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en



 
From owner-ibis Wed Jan 10 12:29:25 2001
Received: from ptldpop5.ptld.uswest.net ([198.36.160.5])
	by server.eda.org (8.11.0/8.11.0) with SMTP id f0AKTNj19301
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 12:29:25 -0800 (PST)
Received: (qmail 77973 invoked by alias); 10 Jan 2001 20:25:43 -0000
Delivered-To: fixup-ibis-users@eda.org@fixme
Received: (qmail 77925 invoked by uid 0); 10 Jan 2001 20:25:42 -0000
Received: from unknown (HELO vasthorizons.com) (63.225.95.1)
  by 198.36.160.5 with SMTP; 10 Jan 2001 20:25:42 -0000
Message-ID: <3A5CC53E.2A2A93E4@vasthorizons.com>
Date: Wed, 10 Jan 2001 12:25:34 -0800
From: Scott McMorrow <scott@vasthorizons.com>
Organization: SiQual
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kim Helliwell <khelliwe@acuson.com>
CC: "Dunbar, Tony" <tony_dunbar@mentorg.com>,
   "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: Re: new ibischk3 V3.2.6
References: <2179BC5B6583D311B44700508B44146901BACE77@svr-orw-exc-02.wv.mentorg.com> <3A5CB2B0.581934B1@acuson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kim,

The problem may be due to ideal diodes.  Or it may be due
to a voltage sweep which is beyond the operational limits of
the device, where the device and the spice model breakdown.
In essence, a spice to Ibis extraction can easily drive the
transistor models of the device beyond their assumptions that
the models are based upon.

At SiQual, when we create models from Spice, we make sure
to limit these overcurrents in the final model by truncating the
curves at a reasonable point, well beyond the normal operating
range of the device.

Then, to be sure, we correlate the ibis simulation results obtained
with the model to spice. (In a "real" reflected wave transmission line
circuit.)

In the future, we will begin "closing the loop" by performing
correlations of real devices in test boards.


regards,

scott


--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com


Kim Helliwell wrote:

> I have another perspective. This problem is almost certainly caused
> by diode models in the SPICE netlist that are "ideal" models; that
> is, there is no series parasitic resistance (RS) specified.
>
> And I think it's more than reasonable for the IBIS community to demand
> that suppliers of SPICE or IBIS models do not use such ideal components
> in the model.  This is a well-known SPICE trouble spot, and anyone who
> still perpetrates that sin appears to me to be a rank amateur. It causes
> me to wonder what other inaccuracies exist in the models that exhibit this
> problem.
>
> Kim
>
> "Dunbar, Tony" wrote:
> >
> > Aubrey,
> >
> > First of all, let me just set the scene. In this e-mail, I am ONLY referring
> > to the situation of gross currents in the V-I tables.
> >
> > >From a purist stand-point, I agree with you. Unfortunately, in my experience
> > the reality is that many, many IBIS models derived from SPICE exhibit these
> > giga-amp characteristics. I think what Bob means is that the model is
> > correct in that it reflects what the SPICE model has. A further reality is
> > that the IBIS forum is not going to change the world; these decks and models
> > are not going to change to satisfy this anomoly. Fortunately, they usually
> > occur well away from the normal operating region and normal clamping region
> > so, in actual operation, they don't give us a problem.
> >
> > Given that this is reality and it's not going to change, I think we (the
> > IBIS forum) need to look at what, if anything, we are going to change to
> > deal with it? Maybe we need to change things a little to be closer to this
> > normal operation. One question is, 'what is the reasoning behind the
> > (somewhat large) range of (2xVCC to -1xVCC) for the V-I tables?'; can this
> > be truncated? Or, better (IMHO), check that the clamp currents are
> > reasonable(?) within a tighter range; i.e. closer to the normal operating
> > region and to a limit more aligned with an expected clamping event; e.g.
> > VCC+1.0V and GND-1.0V.
> >
> > Yes, it sounds like capitulation, but I think it's the only practical
> > course.
> >
> > -----Original Message-----
> > From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> > Sent: Wednesday, January 10, 2001 11:01 AM
> > To: bob_ross@mentorg.com; shuq@cisco.com
> > Cc: ibis-users@eda.org
> > Subject: RE: new ibischk3 V3.2.6
> >
> > Bob,
> > I'm not sure I agree with your statement that a model with end point I-V
> > currents that are "extremely large (such as 1e20)" "might actually be
> > correct" even if those data points are produced from a valid spice deck.
> > The purpose of a model is to reflect reality where possible and 1e20
> > amps????
> >
> > Aubrey Sparkman
> > Signal Integrity
> > Aubrey_Sparkman@Dell.com
> > (512) 723-3592
> >
> > > -----Original Message-----
> > > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > > Sent: Tuesday, January 09, 2001 7:26 PM
> > > To: Syed Huq
> > > Cc: ibis-users@eda.org
> > > Subject: Re: new ibischk3 V3.2.6
> > >
> > >
> > > Syed:
> > >
> > > The new ibischk3 changed the Warning message to an Error
> > > message when the mismatch exceeded 10%.  In your example,
> > > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > > of the range (.21v).  There may exist a real problem that
> > > needs to be examined.  This change is documented as BUG47:
> > >
> > >   http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> > >
> > > However, the -0.71 value is suspicious.  I have seen a
> > > similar problem when some of the end point I-V currents are
> > > extremely large (such as 1e20) and cause ibischk3 to
> > > not properly converge to the correct DC endpoints.  You
> > > might check this and try smaller values if such large
> > > values exist.  Your model might actually be correct.
> > >
> > > Bob Ross
> > > Mentor Graphics
> > >
> > >
> > > Syed Huq wrote:
> > > >
> > > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > > >
> > > > new version:
> > > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > > >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > > >       has TYP column DC endpoints of  0.41V and  2.50v, but
> > > >       an equivalent load applied to the model's I-V tables yields
> > > >       different voltages (-0.70V and  2.50V),
> > > >
> > > > In the earlier version(V3.2.5),this would show up as a
> > > WARNING. Since now
> > > > it shows up as ERROR, the file fails.
> > > >
> > > > old version:
> > > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > > 2.50V) not within
> > > >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for
> > > 50 Ohms to 2.5V
> > > >
> > > > Why was this changed to ERROR ?
> > > >
> > > > Syed
> > >
>
> --
> Kim Helliwell
> Senior CAE Engineer
> Acuson Corporation
> Phone: 650 694 5030  FAX: 650 943 7260



 
From owner-ibis Wed Jan 10 13:21:35 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0ALLTj19599
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 13:21:35 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id NAA20371; Wed, 10 Jan 2001 13:17:42 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CDTASHN4; Wed, 10 Jan 2001 13:17:41 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A5CD173.E61C3EC2@mentor.com>
Date: Wed, 10 Jan 2001 13:17:39 -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: Syed Huq <shuq@cisco.com>
CC: ibis-users@eda.org
Subject: Re: another new parser question ibischk3 V3.2.6
References: <200101100559.VAA20929@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Syed:

The problem is that the uploaded executables were uploaded with
the print flag for debugging turned on.  Replacement executables
with the PRINT switch turned off (at least for Unix) are
now uploaded at:

  http://www.eda.org/pub/ibis/ibischk3/

Bob Ross
Mentor Graphics


Syed Huq wrote:
> 
> Dear Gurus:
> 
> I am quite amazed by the amount of information the parser reports.
> Let me explain and I would like to understand the reasons too:
> 
> 1) For every pin of this 456BGA package, it reports that the R_pin, L_pin
> and C_pin are missing. I already know this simply by opening the IBIS file
> and looking at the [Pin] list section.
> 
> Why do I need to scroll thru all these:
> .
> <parser output>
> .
> PIN:signal_name:<DQ[71]>
> PIN:model_name:<XYZ_IO>
> PIN:R_Pin:NOT SET
> PIN:L_Pin:NOT SET
> PIN:C_Pin:NOT SET
> PIN:Pin:<A3>
> PIN:signal_name:<VDDQ>
> PIN:model_name:<POWER>
> PIN:R_Pin:NOT SET
> PIN:L_Pin:NOT SET
> PIN:C_Pin:NOT SET
> PIN:Pin:<A4>
> PIN:signal_name:<DQ[67]>
> PIN:model_name:<XYZ_IO>
> PIN:R_Pin:NOT SET
> PIN:L_Pin:NOT SET
> PIN:C_Pin:NOT SET
> .
> .
> 
> 2) Why does the parser output print all the V/I and V/T table data ?
> .
> Pulldown:
> Voltage:-2.5, Typ:-0.12, Min:-0.09518, Max:-0.13
> Voltage:-2.3, Typ:-0.12, Min:-0.09518, Max:-0.13
> Voltage:-2.1, Typ:-0.12, Min:-0.09518, Max:-0.13
> .
> .
> 
> 3) Why does the parser not show the value of Cref clearly defined in
> the IBIS model ?
> 
> Parser:
> Model Name:XYZ_TRI
> Model_type:3-state
> Polarity:Non-Inverting
> Enable:Active-High
> Vinl:NOT SET
> Vinh:NOT SET
> Vmeas:1.500000
> Cref:0.000000   <------ ??
> 
> IBIS:
> [Model]          XYZ_TRI
> Model_type       3-state
> Polarity         Non-Inverting
> Enable           Active-High
> Vmeas =   1.50V
> Cref =  50.00pF <------ It's there ..
> 
> 4) Why does the parser not show the dT values for Ramp ?
> 
> <parser output>
> dV/dt_r:Typ:1.150000/0.000000, Min:0.820000/0.000000, Max:1.280000/0.000000
> dV/dt_f:Typ:1.250000/0.000000, Min:1.050000/0.000000, Max:1.360000/0.000000
> 
> IBIS model:
> dV/dt_r          1.15/0.31n          0.82/0.37n          1.28/0.22n
> dV/dt_f          1.25/0.22n          1.05/0.32n          1.36/0.15n
> 
> 5) Is there a switch a user could use to minimize a lot of these messages ?
> 
> Regards,
> Syed
 
From owner-ibis Wed Jan 10 14:02:39 2001
Received: from mako.hhnetwk.com (mail.hammerheadnetworks.com [64.55.108.178])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0AM2Zj19821
	for <ibis-users@eda.org>; Wed, 10 Jan 2001 14:02:38 -0800 (PST)
Received: from westerhoff (westerhoff.hhnetwk.com [10.2.4.2])
	by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f0ALwhm28366;
	Wed, 10 Jan 2001 16:58:43 -0500
From: "Todd Westerhoff" <twester@hhnetwk.com>
To: <Aubrey_Sparkman@dell.com>, <khelliwe@acuson.com>,
   <tony_dunbar@mentorg.com>
Cc: <ibis-users@eda.org>
Subject: RE: new ibischk3 V3.2.6
Date: Wed, 10 Jan 2001 16:59:22 -0500
Message-ID: <JHEBLEFOHFBGBDHNDEKDGEJICAAA.twester@hhnetwk.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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <CDF99E351003D311A8B0009027457F1405C5F69D@ausxmrr501.us.dell.com>

I believe that if you connect your circuit to metal plates on opposite sides
of a black hole, you could see such currents.

There are two problems, however:

a) finding conductors that can handle the current, and
b) keeping the whole thing from getting pulled into the black hole in the
first place

Sorry.  Couldn't resist!

Todd ;-)

-----Original Message-----
From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
Sent: Wednesday, January 10, 2001 2:47 PM
To: khelliwe@acuson.com; tony_dunbar@mentorg.com
Cc: ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6


Thank you Tony, I was hoping for a discussion of what the IBIS community
could do about this problem.

And Thank you Kim, for pointing out one of the reasons I might receive IBIS
data with unrealistic currents.  Can anyone out there describe a realistic
scenerio (not caused by ideal models) that might cause "giga-amp
characteristics"?

Thanks!

Aubrey Sparkman
Signal Integrity
Aubrey_Sparkman@Dell.com
(512) 723-3592


> -----Original Message-----
> From: Kim Helliwell [mailto:khelliwe@acuson.com]
> Sent: Wednesday, January 10, 2001 1:06 PM
> To: Dunbar, Tony
> Cc: 'ibis-users@eda.org'
> Subject: Re: new ibischk3 V3.2.6
>
>
> I have another perspective. This problem is almost certainly caused
> by diode models in the SPICE netlist that are "ideal" models; that
> is, there is no series parasitic resistance (RS) specified.
>
> And I think it's more than reasonable for the IBIS community to demand
> that suppliers of SPICE or IBIS models do not use such ideal
> components
> in the model.  This is a well-known SPICE trouble spot, and anyone who
> still perpetrates that sin appears to me to be a rank
> amateur. It causes
> me to wonder what other inaccuracies exist in the models that
> exhibit this
> problem.
>
> Kim
>
> "Dunbar, Tony" wrote:
> >
> > Aubrey,
> >
> > First of all, let me just set the scene. In this e-mail, I
> am ONLY referring
> > to the situation of gross currents in the V-I tables.
> >
> > >From a purist stand-point, I agree with you.
> Unfortunately, in my experience
> > the reality is that many, many IBIS models derived from
> SPICE exhibit these
> > giga-amp characteristics. I think what Bob means is that
> the model is
> > correct in that it reflects what the SPICE model has. A
> further reality is
> > that the IBIS forum is not going to change the world; these
> decks and models
> > are not going to change to satisfy this anomoly.
> Fortunately, they usually
> > occur well away from the normal operating region and normal
> clamping region
> > so, in actual operation, they don't give us a problem.
> >
> > Given that this is reality and it's not going to change, I
> think we (the
> > IBIS forum) need to look at what, if anything, we are going
> to change to
> > deal with it? Maybe we need to change things a little to be
> closer to this
> > normal operation. One question is, 'what is the reasoning behind the
> > (somewhat large) range of (2xVCC to -1xVCC) for the V-I
> tables?'; can this
> > be truncated? Or, better (IMHO), check that the clamp currents are
> > reasonable(?) within a tighter range; i.e. closer to the
> normal operating
> > region and to a limit more aligned with an expected
> clamping event; e.g.
> > VCC+1.0V and GND-1.0V.
> >
> > Yes, it sounds like capitulation, but I think it's the only
> practical
> > course.
> >
> > -----Original Message-----
> > From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> > Sent: Wednesday, January 10, 2001 11:01 AM
> > To: bob_ross@mentorg.com; shuq@cisco.com
> > Cc: ibis-users@eda.org
> > Subject: RE: new ibischk3 V3.2.6
> >
> > Bob,
> > I'm not sure I agree with your statement that a model with
> end point I-V
> > currents that are "extremely large (such as 1e20)" "might
> actually be
> > correct" even if those data points are produced from a
> valid spice deck.
> > The purpose of a model is to reflect reality where possible and 1e20
> > amps????
> >
> > Aubrey Sparkman
> > Signal Integrity
> > Aubrey_Sparkman@Dell.com
> > (512) 723-3592
> >
> > > -----Original Message-----
> > > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > > Sent: Tuesday, January 09, 2001 7:26 PM
> > > To: Syed Huq
> > > Cc: ibis-users@eda.org
> > > Subject: Re: new ibischk3 V3.2.6
> > >
> > >
> > > Syed:
> > >
> > > The new ibischk3 changed the Warning message to an Error
> > > message when the mismatch exceeded 10%.  In your example,
> > > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > > of the range (.21v).  There may exist a real problem that
> > > needs to be examined.  This change is documented as BUG47:
> > >
> > >   http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> > >
> > > However, the -0.71 value is suspicious.  I have seen a
> > > similar problem when some of the end point I-V currents are
> > > extremely large (such as 1e20) and cause ibischk3 to
> > > not properly converge to the correct DC endpoints.  You
> > > might check this and try smaller values if such large
> > > values exist.  Your model might actually be correct.
> > >
> > > Bob Ross
> > > Mentor Graphics
> > >
> > >
> > > Syed Huq wrote:
> > > >
> > > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > > >
> > > > new version:
> > > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > > >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > > >       has TYP column DC endpoints of  0.41V and  2.50v, but
> > > >       an equivalent load applied to the model's I-V
> tables yields
> > > >       different voltages (-0.70V and  2.50V),
> > > >
> > > > In the earlier version(V3.2.5),this would show up as a
> > > WARNING. Since now
> > > > it shows up as ERROR, the file fails.
> > > >
> > > > old version:
> > > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > > 2.50V) not within
> > > >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for
> > > 50 Ohms to 2.5V
> > > >
> > > > Why was this changed to ERROR ?
> > > >
> > > > Syed
> > >
>
> --
> Kim Helliwell
> Senior CAE Engineer
> Acuson Corporation
> Phone: 650 694 5030  FAX: 650 943 7260
>


 
From owner-ibis Thu Jan 11 07:00:35 2001
Received: from ausxc10.us.dell.com (ausxc10.us.dell.com [143.166.98.229])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0BF0Xj23145
	for <ibis-users@eda.org>; Thu, 11 Jan 2001 07:00:35 -0800 (PST)
Received: by ausxc10.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <CFWPV834>; Thu, 11 Jan 2001 08:48:25 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F6AA@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: twester@hhnetwk.com, Aubrey_Sparkman@Dell.com, khelliwe@acuson.com,
   tony_dunbar@mentorg.com
Cc: ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6
Date: Thu, 11 Jan 2001 08:51:08 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C07BDD.EE62DFE0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C07BDD.EE62DFE0
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks, Todd.  :-)

Perhaps I should phrased my request differently to ask for other COMMON
causes including ideal models.  I'm not interested in what would happen if
the models used **Superconductors** for traces..... 

Aubrey Sparkman
Signal Integrity
Aubrey_Sparkman@Dell.com
(512) 723-3592


> -----Original Message-----
> From: Todd Westerhoff [mailto:twester@hhnetwk.com]
> Sent: Wednesday, January 10, 2001 3:59 PM
> To: Aubrey_Sparkman@exchange.dell.com; khelliwe@acuson.com;
> tony_dunbar@mentorg.com
> Cc: ibis-users@eda.org
> Subject: RE: new ibischk3 V3.2.6
> 
> 
> I believe that if you connect your circuit to metal plates on 
> opposite sides
> of a black hole, you could see such currents.
> 
> There are two problems, however:
> 
> a) finding conductors that can handle the current, and
> b) keeping the whole thing from getting pulled into the black 
> hole in the
> first place
> 
> Sorry.  Couldn't resist!
> 
> Todd ;-)
> 
> -----Original Message-----
> From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> Sent: Wednesday, January 10, 2001 2:47 PM
> To: khelliwe@acuson.com; tony_dunbar@mentorg.com
> Cc: ibis-users@eda.org
> Subject: RE: new ibischk3 V3.2.6
> 
> 
> Thank you Tony, I was hoping for a discussion of what the 
> IBIS community
> could do about this problem.
> 
> And Thank you Kim, for pointing out one of the reasons I 
> might receive IBIS
> data with unrealistic currents.  Can anyone out there 
> describe a realistic
> scenerio (not caused by ideal models) that might cause "giga-amp
> characteristics"?
> 
> Thanks!
> 
> Aubrey Sparkman
> Signal Integrity
> Aubrey_Sparkman@Dell.com
> (512) 723-3592
> 
> 
> > -----Original Message-----
> > From: Kim Helliwell [mailto:khelliwe@acuson.com]
> > Sent: Wednesday, January 10, 2001 1:06 PM
> > To: Dunbar, Tony
> > Cc: 'ibis-users@eda.org'
> > Subject: Re: new ibischk3 V3.2.6
> >
> >
> > I have another perspective. This problem is almost certainly caused
> > by diode models in the SPICE netlist that are "ideal" models; that
> > is, there is no series parasitic resistance (RS) specified.
> >
> > And I think it's more than reasonable for the IBIS 
> community to demand
> > that suppliers of SPICE or IBIS models do not use such ideal
> > components
> > in the model.  This is a well-known SPICE trouble spot, and 
> anyone who
> > still perpetrates that sin appears to me to be a rank
> > amateur. It causes
> > me to wonder what other inaccuracies exist in the models that
> > exhibit this
> > problem.
> >
> > Kim
> >
> > "Dunbar, Tony" wrote:
> > >
> > > Aubrey,
> > >
> > > First of all, let me just set the scene. In this e-mail, I
> > am ONLY referring
> > > to the situation of gross currents in the V-I tables.
> > >
> > > >From a purist stand-point, I agree with you.
> > Unfortunately, in my experience
> > > the reality is that many, many IBIS models derived from
> > SPICE exhibit these
> > > giga-amp characteristics. I think what Bob means is that
> > the model is
> > > correct in that it reflects what the SPICE model has. A
> > further reality is
> > > that the IBIS forum is not going to change the world; these
> > decks and models
> > > are not going to change to satisfy this anomoly.
> > Fortunately, they usually
> > > occur well away from the normal operating region and normal
> > clamping region
> > > so, in actual operation, they don't give us a problem.
> > >
> > > Given that this is reality and it's not going to change, I
> > think we (the
> > > IBIS forum) need to look at what, if anything, we are going
> > to change to
> > > deal with it? Maybe we need to change things a little to be
> > closer to this
> > > normal operation. One question is, 'what is the reasoning 
> behind the
> > > (somewhat large) range of (2xVCC to -1xVCC) for the V-I
> > tables?'; can this
> > > be truncated? Or, better (IMHO), check that the clamp currents are
> > > reasonable(?) within a tighter range; i.e. closer to the
> > normal operating
> > > region and to a limit more aligned with an expected
> > clamping event; e.g.
> > > VCC+1.0V and GND-1.0V.
> > >
> > > Yes, it sounds like capitulation, but I think it's the only
> > practical
> > > course.
> > >
> > > -----Original Message-----
> > > From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> > > Sent: Wednesday, January 10, 2001 11:01 AM
> > > To: bob_ross@mentorg.com; shuq@cisco.com
> > > Cc: ibis-users@eda.org
> > > Subject: RE: new ibischk3 V3.2.6
> > >
> > > Bob,
> > > I'm not sure I agree with your statement that a model with
> > end point I-V
> > > currents that are "extremely large (such as 1e20)" "might
> > actually be
> > > correct" even if those data points are produced from a
> > valid spice deck.
> > > The purpose of a model is to reflect reality where 
> possible and 1e20
> > > amps????
> > >
> > > Aubrey Sparkman
> > > Signal Integrity
> > > Aubrey_Sparkman@Dell.com
> > > (512) 723-3592
> > >
> > > > -----Original Message-----
> > > > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > > > Sent: Tuesday, January 09, 2001 7:26 PM
> > > > To: Syed Huq
> > > > Cc: ibis-users@eda.org
> > > > Subject: Re: new ibischk3 V3.2.6
> > > >
> > > >
> > > > Syed:
> > > >
> > > > The new ibischk3 changed the Warning message to an Error
> > > > message when the mismatch exceeded 10%.  In your example,
> > > > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > > > of the range (.21v).  There may exist a real problem that
> > > > needs to be examined.  This change is documented as BUG47:
> > > >
> > > >   http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> > > >
> > > > However, the -0.71 value is suspicious.  I have seen a
> > > > similar problem when some of the end point I-V currents are
> > > > extremely large (such as 1e20) and cause ibischk3 to
> > > > not properly converge to the correct DC endpoints.  You
> > > > might check this and try smaller values if such large
> > > > values exist.  Your model might actually be correct.
> > > >
> > > > Bob Ross
> > > > Mentor Graphics
> > > >
> > > >
> > > > Syed Huq wrote:
> > > > >
> > > > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > > > >
> > > > > new version:
> > > > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > > > >       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > > > >       has TYP column DC endpoints of  0.41V and  2.50v, but
> > > > >       an equivalent load applied to the model's I-V
> > tables yields
> > > > >       different voltages (-0.70V and  2.50V),
> > > > >
> > > > > In the earlier version(V3.2.5),this would show up as a
> > > > WARNING. Since now
> > > > > it shows up as ERROR, the file fails.
> > > > >
> > > > > old version:
> > > > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > > > 2.50V) not within
> > > > >           0.042V (2%) of (-0.70V,  2.50V) on VI curves for
> > > > 50 Ohms to 2.5V
> > > > >
> > > > > Why was this changed to ERROR ?
> > > > >
> > > > > Syed
> > > >
> >
> > --
> > Kim Helliwell
> > Senior CAE Engineer
> > Acuson Corporation
> > Phone: 650 694 5030  FAX: 650 943 7260
> >
> 
> 
> 


------_=_NextPart_000_01C07BDD.EE62DFE0
Content-Type: application/octet-stream;
	name="Sparkman, Aubrey.vcf"
Content-Disposition: attachment;
	filename="Sparkman, Aubrey.vcf"

BEGIN:VCARD
VERSION:2.1
N:Sparkman;Aubrey
FN:Sparkman, Aubrey
EMAIL;PREF;INTERNET:Aubrey_Sparkman@Dell.com
REV:19990728T212924Z
END:VCARD

------_=_NextPart_000_01C07BDD.EE62DFE0--
 
From owner-ibis Thu Jan 11 09:40:31 2001
Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0BHeTj23764
	for <ibis-users@eda.org>; Thu, 11 Jan 2001 09:40:30 -0800 (PST)
Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345)
	id E2AB43F3; Thu, 11 Jan 2001 11:36:43 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42])
	by ztxmail04.ztx.compaq.com (Postfix) with ESMTP
	id 5B722387; Thu, 11 Jan 2001 11:36:43 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <CH6ADB5D>; Thu, 11 Jan 2001 12:36:42 -0500
Message-ID: <212CC57E84B8D111AD780000F84AA0490C713C7C@mroexc2.tay.cpqcorp.net>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: "'Aubrey_Sparkman@Dell.com'" <Aubrey_Sparkman@dell.com>
Cc: ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6
Date: Thu, 11 Jan 2001 12:36:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain

> Perhaps I should phrased my request differently to ask for other COMMON
> causes including ideal models.  I'm not interested in what would happen if
> the models used **Superconductors** for traces..... 
 
Hey, don't ALL models use superconductors for traces?  :-)  The normal
connection in a simulator is a zero resistance, zero delay "wire".  Even the
old standard SPICE transmission line, has delay but no loss, i.e., a
superconductor.

Perhaps like Todd, I got confused when you said "realistic scenario".  I
thought you meant what in the REAL world might give you giga-amps.

Nothing on an IC or a PC board will give you those kinds of currents.  If
you see that much current in a simulation, you can say with 100% certainty
that the simulation, or the model, is wrong.

Some possible causes of such currents in a simulation:

(1)  Ideal models where something, such as Rs, was left out.  I believe the
parasitic diodes in many MOS models do not even provide for an Rs, so you
must add discrete resistor elements to fully represent the transistor.

(2)  Models where the wrong units were used.  For example, tables of Pullup,
Pulldown currents in microamps rather than amps.

(3)  Improper use (or any use!?) of SCALE or SCALM in Hspice.  Using models
that require different SCALE/SCALM parameters in the same simulation.
(BOYCOTT SCALE & SCALM!)

(4)  Anything that causes the simulator to become unstable, usually showing
big oscillations when none should exist.

(5)  Extrapolating a table beyong its endpoints without thinking.  (Isn't
that why IBIS requires complete tables to unreasonable overshoot voltages so
the simulator doesn't have to extrapolate?)

(6)  Anything that causes a model to be used beyond its intended and/or
tested and verified range.

(7)  Improper use of global nodes, which can result in "sneak path" or "back
door" connections with no or very little resistance.

(8)  Any number of model usage mistakes, typos, sloppy editing, etc.

Regards,
Andy

 
From owner-ibis Thu Jan 11 10:54:43 2001
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0BIsfj24063
	for <ibis-users@eda.org>; Thu, 11 Jan 2001 10:54:42 -0800 (PST)
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345)
	id 976771061; Thu, 11 Jan 2001 13:50:55 -0500 (EST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id 907BA1374
	for <ibis-users@eda.org>; Thu, 11 Jan 2001 13:50:55 -0500 (EST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <CJWKZXBM>; Thu, 11 Jan 2001 13:50:53 -0500
Message-ID: <212CC57E84B8D111AD780000F84AA0490C713C7D@mroexc2.tay.cpqcorp.net>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: RE: new ibischk3 V3.2.6
Date: Thu, 11 Jan 2001 13:50:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain

Several years ago I experimented with Ken Kundert's Spectre simulator.  One
of its error messages was something like:

	Warning, your transistors are melting!

We could use more messages like that from our simulators today.

Andy

 
From owner-ibis Fri Jan 12 11:03:13 2001
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0CJ3Bj29046
	for <ibis-users@eda.org>; Fri, 12 Jan 2001 11:03:12 -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.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id TAA17530
	for <ibis-users@eda.org>; Fri, 12 Jan 2001 19:00:53 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 12 Jan 2001 18:59:30 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <CCV9WYTK>; Fri, 12 Jan 2001 10:59:29 -0800
Message-ID: <10C8636AE359D4119118009027AE998705155174@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: Large diode currents
Date: Fri, 12 Jan 2001 10:59:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"

All,

I renamed the subject to reflect what we are talking about.

Aside from all that has been mentioned already, I would like
make another point.  One side of the argument regarding the
necessity of extending the IV curves to -Vcc and 2*Vcc
says that a device will never see such high voltages, so
why bother...

This is probably the philosophy of those SPICE model
makers who do not care to put in the resistive properties
of those parasitic diodes.  However, they fail to realize 
one thing.  These diodes "turn on" at about 0.6 volts outside
the rails.  If there is no resistance included in the model,
such a diode can draw several tens of amps (if not more) very
easily at say one volt of forward bias.

Now, think about the signal integrity consequences of this.
It is not too hard to "design" a system that over or undershoots
one volt (or more) outside the rails.  The amount of under
and overshoot, and consequently the resulting ringback will
greatly DEPEND on how these waveforms are clamped by the
parasitic diodes in the drivers AND(!) receivers.

A circuit designer usually doesn't think of this, and feels
that "there shall be no signals outside the rails".  The SI
guy MUST fix his problems to avoid that.  Unfortunately
real life is different, and under and overshoots will
happen whether we like it or not.

So the issue here is not so much whether the end point of 
an IV curve in an IBIS model is at so many tera amps.  The
problem revolves more around getting better information on
what the signals will look like when they go outside the
rail, and upon returning from being outside the rail.  By
the way, this will also change the picture on Inter Symbol
Interference (ISI) effects, which DO directly effect the
timing of the edges also.

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

 
From owner-ibis Fri Jan 12 18:02:03 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0D222j00203
	for <ibis-users@eda.org>; Fri, 12 Jan 2001 18:02:03 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id RAA08960; Fri, 12 Jan 2001 17:58:16 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CY6D9QRR; Fri, 12 Jan 2001 17:58:16 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A5FB636.846F4386@mentor.com>
Date: Fri, 12 Jan 2001 17:58:14 -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-users@eda.org
Subject: IBIS Directory
Content-Type: multipart/mixed;
 boundary="------------F93F67B6579F27D70CA077D8"

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

To All:

IBIS is an acronym that stands for many things.  You
can be involved with IBIS in many aspects of your life.

Here is an IBIS directory giving a sampling of IBIS links
related to IBIS products, services and content.  Many of
theses links also have interesting IBIS logos.

Bob Ross
Mentor Graphics
--------------F93F67B6579F27D70CA077D8
Content-Type: text/html; charset=us-ascii;
 name="ibisdirectory.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ibisdirectory.html"

<HTML>
<TITLE> IBIS DIRECTORY </TITLE>
<H2 ALIGN=center> IBIS DIRECTORY </H2>
<BODY BGCOLOR="f8f7d9">

<H4> <B>AIRCRAFT</B> </H4>
<LI> <A HREF="http://www.ibisaerospace.com">
IBIS Aerospace Ltd.</A>
<LI> <A HREF="http://www.bundabergonthe.net/hinkler/aircraft_pic4.htm">
The Ibis</A>

<H4> <B>ARTS AND CRAFTS</B> </H4>
<LI> <A HREF="http://www.ibis.wserv.com">
IBIS Images</A>
<LI> <A HREF="http://www.ibisart.com/">
Ibis Art Wall Clocks</A>

<H4> <B>BOOKS AND BOOKSTORES</B> </H4>
<LI> <A HREF="http://www.ibisbooks.com">
Ibis Books</A>
<LI> <A HREF="http://www.ibiservice.com">
International Book Import Service</A>

<H4> <B>BUSINESS SERVICES</B> </H4>
<LI> <A HREF="http://www.ibcl.com/cgi-bin/www.ibcl.com/info.pl?/info.htm">
IBIS Business Consultants Ltd.</A>
<LI> <A HREF="http://www.epowersuite.com">
IBIS Business Internet Solutions</A>
<LI> <A HREF="http://www.ibisresearch.com">
Ibis Research, Inc.</A>
<LI> <A HREF="http://www.indiaconnect.com/ibis.htm">
India Business Information Service</A>
<LI> <A HREF="http://www.lib.uwaterloo.ca/IBIS.html">
Industrial and Business Information Service</A>
<LI> <A HREF="http://www.kig.pl/biura/infodata/12-ibis/">
Industry & Business Information System</A>
<LI> <A HREF="http://www.ibisuva.nl/">
Institute for Business and Industrial Statistics</A>
<LI> <A HREF="http://www.intbis.com/">
Integrated Business Information System Ltd.</A>
<LI> <A HREF="http://www.ibisinc.com/ibiswww/downloadie.htm">
Interactive Business Information Systems, Inc.</A>
<LI> <A HREF="http://www.unido.org/doc/310757.htmls">
International Business Incubation Systems</A>
<LI> <A HREF="http://www.ibis-ca.com">
International Business Information Search (IBIS Consultants Associated)</A>

<H4> <B>COFFEE</B> </H4>
<LI> <A HREF="http://www.caffeibis.com">
Caffee IBIS</A>

<H4> <B>HEALTH</B> </H4>
<LI> <A HREF="http://www.sirv.org/index.htm">
Improved Biofeedback Integrated System</A>
<LI> <A HREF="http://www.vtt.fi/tte/samba/projects/ibis/index.html">
Improved Monitoring for Brain Dysfunction in Intensive Care and Surgery</A>
<LI> <A HREF="http://www.ibismedical.com/ibis.html">
Integrative BodyMind Information System</A>
<LI> <A HREF="http://ibis-birthdefects.org/start/ibisis.htm">
International Birth Defects Information Systems</A>
<LI> <A HREF="http://www.lif.icnet.uk/studies/mse/ibis/ibis.html">
International Breast Cancer Intervention Study</A>
<LI> <A HREF="http://www.powerup.com.au/~ibis/">
Irritable Bowel Information & Support Association of Australia, Inc.</A>

<H4> <B>IBIS HOTELS</B> </H4>
<LI> <A HREF="http://www.ibis.co.jp">
Hotel IBIS Roppongi</A>
<LI> <A HREF="http://www.ibishotel.com">
ibis Hotel</A>

<H4> <B>INTERNET AND ELECTRONIC MAIL</B> </H4>
<LI> <A HREF="http://www.ibisinternational.com/about/">
International Business Internet Service  (IBIS International)</A>
<LI> <A HREF="http://www.info.bw/">
Info Botswana Internet Services</A>
<LI> <A HREF="http://www.ipac.caltech.edu/ipac/services/ibis/ibis.html">
IRSKY Batch Inquiry System</A>

<H4> <B>LAW ENFORCEMENT</B> </H4>
<LI> <A HREF="http://www.digitalbiometrics.com/products/ibis.htm">
Identification Based Information System</A>
<LI> <A HREF="http://www.co.montgomery.tx.us/sheriff/Id/ibis.htm">
Integrated Ballistics Identification System</A>

<H4> <B>LIBRARY AND INFORMATION</B> </H4>
<LI> <A HREF="http://www.gdss.com/wp/IBIS.htm">
Issue-Based Information System</A>
<LI> <A HREF="http://www.ilcso.uiuc.edu/Web/docs/sdi_faq.html">
Illinois Bibliographic Information Service</A>

<H4> <B>LOANS</B> </H4>
<LI> <A HREF="http://ibis.gsfc.org/ibis_start.htm">
Internet Borrower Inquiry Services</A>

<H4> <B>MAGAZINES AND PUBLISHING</B> </H4>
<LI> <A HREF="http://www.bou.org.uk/pubibis.html">
IBIS (The International Journal of Avian Science)</A>
<LI> <A HREF="http://www.ibiscom.com/ibis.htm">
Ibis Communications, Inc.</A>
<LI> <A HREF="http://www.homeoffice.gov.uk/ibis/ibisnews.htm">
Integrating Business & Information Systems (IBIS) News </A>
<LI> <A HREF="http://www.ibisnews.org/">
International Benefits Information Service (IBIS News)</A>

<H4> <B>REAL ESTATE AND HOMES</B> </H4>
<LI> <A HREF="http://www.ibisgolf.com/main.html">
Ibis Golf and Country Club</A>
<LI> <A HREF="http://www.heronsglen.com/pages/ch_ibis.htm">
The Ibis</A>

<H4> <B>SCHOOLS AND COLLEGES</B> </H4>
<LI> <A HREF="http://www6.general-hosting.com/hlfrlmc/ibishealingarts.html">
IBIS Healing Arts</A>
<LI> <A HREF="http://www.ibis-school.com/ibis/">
Independent Bonn International School</A>
<LI> <A HREF="http://www.ucd.ie/~ibis/">
Institute for British-Irish Studies</A>
<LI> <A HREF="http://x.biochem.northwestern.edu/ibis/front.html">
Interdepartmental Biological Sciences Program</A>

<H4> <B>SCIENTIFIC AND INSTRUMENTATION </B> </H4>
<LI> <A HREF="http://www.ibis.com">
Ibis Technology Corporation</A>
<LI> <A HREF="http://www.kfki.hu/~ionhp/">
Ion Beam Information System</A>
<LI> <A HREF="http://astro.esa.int/Integral/integ_payload_imager.html">
Imager IBIS (Imager on Board the Integral Satellite)</A>
<LI> <A HREF="http://www.rbgkew.org.uk/ibis/">
Internet Botanical Information Server</A>
<LI> <A HREF="http://www.windsor-ltd.co.uk/ibis.htm">
Instrument for Biomolecular Interaction Sensing</A>

<H4> <B> SOFTWARE AND SYSTEMS</B> </H4>
<LI> <A HREF="http://www.ibis-research.com/ModelEditor.htm">
IBIS Model Editor</A>
<LI> <A HREF="http://www.math.utah.edu/IBIS/">
Immersed Boundary and Interface Software</A>
<LI> <A HREF="http://intel1.fe.dis.titech.ac.jp/~ibis2000/">
2000 Workshop on Information Based Induction Sciences (IBIS2000)</A>

<H4> <B>TRAVEL AND TOURS</B> </H4>
<LI> <A HREF="http://www.netcolony.com/members/ibis/">
IBIS Bird-Watching Tours</A>
<LI> <A HREF="http://www.ibis-excursions.dk">
Ibis Excursions</A>
<LI> <A HREF="http://www.ibistours.com">
Ibis Tours</A>

<H4> <B>WEB DESIGN, PRINTING AND PUBLISHING</B> </H4>
<LI> <A HREF="http://www.ibis-digital.com/rev_what.html">
IBIS Digital</A>
<LI> <A HREF="http://www.tode.demon.co.uk/ibis/">
IBiS Multimedia</A>
<LI> <A HREF="http://www.ibiswebcreations.com/">
IBIS Web Creations</A>
<LI> <A HREF="http://weblife.bangor.ac.uk/ibis/eng/intro.html">
Interfaces for Bilingual Information Systems</A>

</BODY>
</HTML>

--------------F93F67B6579F27D70CA077D8--

 
From owner-ibis Sun Jan 14 09:32:19 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0EHWHj06539
	for <ibis-users@eda.org>; Sun, 14 Jan 2001 09:32:18 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id JAA07008; Sun, 14 Jan 2001 09:28:32 -0800 (PST)
Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19)
	id <CY6D96VA>; Sun, 14 Jan 2001 09:28:31 -0800
Message-ID: <2179BC5B6583D311B44700508B44146901BACEAD@svr-orw-exc-02.wv.mentorg.com>
From: "Dunbar, Tony" <tony_dunbar@mentorg.com>
To: "Ross, Bob" <bob_ross@mentorg.com>
Cc: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: RE: IBIS Directory
Date: Sun, 14 Jan 2001 09:28:29 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,

It looks to me that many of these may be a darned better source of models
than we have today!

Tony

-----Original Message-----
From: Bob Ross [mailto:bob_ross@mentorg.com]
Sent: Friday, January 12, 2001 7:58 PM
To: ibis-users@eda.org
Subject: IBIS Directory


To All:

IBIS is an acronym that stands for many things.  You
can be involved with IBIS in many aspects of your life.

Here is an IBIS directory giving a sampling of IBIS links
related to IBIS products, services and content.  Many of
theses links also have interesting IBIS logos.

Bob Ross
Mentor Graphics
 
From owner-ibis Wed Jan 17 15:38:29 2001
Received: from cisco.com (ups.cisco.com [171.69.18.21])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0HNcSj01104
	for <ibis-users@eda.org>; Wed, 17 Jan 2001 15:38:29 -0800 (PST)
Received: from ups.cisco.com (ups.cisco.com [171.69.18.21])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA24126
	for <ibis-users@eda.org>; Wed, 17 Jan 2001 15:34:41 -0800 (PST)
Message-Id: <200101172334.PAA24126@cisco.com>
Date: Wed, 17 Jan 2001 15:34:41 -0800 (PST)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Linux executable for parser v3.2.6 uploaded
To: ibis-users@eda.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5TFEqcw2gUtqAGibOMEzJA==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 

Hi,

The Linux executable for IBIS parser V3.2.6 has been uploaded to:

http://www.eda.org/pub/ibis/ibischk3/linux

Regards,
Syed
Cisco Systems, Inc

 
From owner-ibis Fri Jan 19 10:14:02 2001
Received: from www.sigrity.com ([208.203.156.190])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0JIE0j11095
	for <ibis-users@eda.org>; Fri, 19 Jan 2001 10:14:01 -0800 (PST)
Received: from si104 ([208.203.156.180])
	by www.sigrity.com (8.10.2/8.10.2) with SMTP id f0JIAG818762
	for <ibis-users@eda.org>; Fri, 19 Jan 2001 10:10:16 -0800
From: "Jin Zhao" <jzhao@sigrity.com>
To: <ibis-users@eda.org>
Subject: subscribe please
Date: Fri, 19 Jan 2001 10:10:16 -0800
Message-ID: <HKEKJJMCCKLJHFLLNEJLAEGACAAA.jzhao@sigrity.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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400


 
From owner-ibis Mon Jan 22 11:55:13 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0MJtBH10020;
	Mon, 22 Jan 2001 11:55:12 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id LAA02729; Mon, 22 Jan 2001 11:51:22 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CY61B4RC; Mon, 22 Jan 2001 11:51:22 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A6C8F39.3B2C9875@mentor.com>
Date: Mon, 22 Jan 2001 11:51:21 -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 SUMMIT MEETING AGENDA 1/29/01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To IBIS Summit Attendees:

If you have not done so already, please let Milt Schwartz know
if you are attending:

  schwartz@galaxy.nsc.com

People who are presenting: please send the presentations to
Milt for copying at the above address.  Otherwise, plan to
bring 50 copies for distribution at the meeting.

We will have an overhead slide projector and also a projector
for laptop presentations.  I prefer using slides, if practical,
to maximize interaction during discussions and for Ad Hoc
presentations.

Bob Ross
Mentor Graphics

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

                   AGENDA, IBIS SUMMIT MEETING
                        JANUARY 29, 2001

                          Westin Hotel
                  Santa Clara Convention Center
                     Santa Clara, California
                  Check Signs for Meeting Room

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

8:00 AM     Refreshments & Sign In

8:30 AM     Introductions
            - Welcome to Summit
            - Introductions
            - IBIS Booth #861 Placards
            - IBIS Program - Bob Ross, Mentor Graphics
            - Opens for Issues, Discussion           

9:00 AM     The Joy of Web Models
            Tom Dagostino, Mentor Graphics

9:30 AM     Spice 2 IBIS Accuracy Report
            Scott McMorrow, Siqual

10:00 AM    Break

10:15 AM    LVDS Buffer Modeling
            Hazem Hegany and Mohammed Korany, Mentor Graphics

10:45 AM    LSI Power and Ground Model for EMI Simulation
            Norio Matsui, Applied Simulation Technology

11:15 AM    SCSI-3 Compensation Modeling
            Larry Barnes, LSI Logic

12:00 PM    Lunch - (Hosted by National Semiconductor)
            Westin Hotel

1:00 PM     API Questions and Issues
            Al Davis, Consultant

1:30 PM     Connector Specification
            Gus Panella, Molex

1:45 PM     Connector Pin Name Syntax
            Ian Dodd, Cadence

2:00 PM     Connector Specification Discussion
            Gus Panella, Molex

2:30 PM     Break

2:45 PM     IBIS Futures
            Stephen Peters, Intel

3:00 PM     IBIS-X Prototype
            Al Davis, Consultant

3:15 PM     IBIS Futures Discussion
            Stephen Peters, Intel

3:45 AM     Open Discussion and Ad Hoc Topics
            All

4:45 PM     Concluding Items
            - Date2000 IBIS Summit
            - Next Meeting February 16, 2001
            - ??

5:00 PM     End of IBIS Summit Meeting

------------------------------------------------------------------
 
From owner-ibis Thu Jan 25 09:31:41 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0PHVdH25652;
	Thu, 25 Jan 2001 09:31:40 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id JAA24024; Thu, 25 Jan 2001 09:27:48 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CY61B8C3; Thu, 25 Jan 2001 09:27:47 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A706211.9A4853FB@mentor.com>
Date: Thu, 25 Jan 2001 09:27:45 -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: Revised IBIS AGENDA 1/29/01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To IBIS Summit Meeting Attendees:

This is a slightly revised Agenda with some time adjustments,
order and content adjustments.  We expect a full program,
so presentors please plan to stay within the time limits.

A new work in progress connector specification Version
0.960 has been uploaded in 

  http://www.eda.org/pub/ibis/connector/

Looking forward to seeing you at the meeting.

Bob Ross,
Mentor Graphics

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

                   AGENDA, IBIS SUMMIT MEETING
                        JANUARY 29, 2001

                          Westin Hotel
                  Santa Clara Convention Center
                     Santa Clara, California
                  Check Signs for Meeting Room

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

8:00 AM     Refreshments & Sign In

8:30 AM     Introductions
            - Welcome to Summit
            - Introductions
            - IBIS Booth #861 Placards
            - IBIS Today - Bob Ross, Mentor Graphics
            - Opens for Issues, Discussion           

9:00 AM     The Joy of Web Models
            Tom Dagostino, Mentor Graphics

9:30 AM     Spice 2 IBIS Accuracy Report
            Scott McMorrow, Siqual

10:00 AM    Break

10:15 AM    LVDS Modeling
            Hazem Hegany and Mohammed Korany, Mentor Graphics

11:00 AM    LSI Power and Ground Model for EMI Simulation
            Norio Matsui, Applied Simulation Technology

11:30 AM    SCSI-3 Compensation Modeling
            Larry Barnes, LSI Logic

12:00 PM    Lunch - (Hosted by National Semiconductor)
            Westin Hotel

1:00 PM     Connector Specification
            Gus Panella, Molex

1:15 PM     Connector Pin Name Syntax
            Ian Dodd, Cadence

1:30 PM     Connector Specification Discussion
            Gus Panella, Molex

2:00 PM     API Questions and Issues
            Al Davis, Consultant

2:30 PM     Break

2:45 PM     IBIS Futures
            Stephen Peters, Intel

3:00 PM     IBIS-X Technical Overview
            Ian Dodd, Cadence

3:15 PM     IBIS-X Prototype
            Al Davis, Consultant

3:30 PM     IBIS-X Pros and Cons
            Ian Dodd, Cadence

3:45 PM     IBIS Futures Discussion
            Stephen Peters, Intel

4:15 PM     Open Discussion and Ad Hoc Topics
            All

4:45 PM     Concluding Items
            - Date2000 IBIS Summit
            - Next Meeting February 16, 2001

5:00 PM     End of IBIS Summit Meeting

------------------------------------------------------------------
 
From owner-ibis Thu Jan 25 09:46:59 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0PHkuH25701;
	Thu, 25 Jan 2001 09:46:58 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id JAA26098; Thu, 25 Jan 2001 09:43:04 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CY61B8F1; Thu, 25 Jan 2001 09:43:02 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3A7065A5.DC29A55E@mentor.com>
Date: Thu, 25 Jan 2001 09:43:01 -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: EUROPEAN IBIS SUMMIT MEETING ANNOUNCEMENT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

We have been holding successful European IBIS Summit Meetings for the
last three years.  This year we are again holding a meeting along with
DATE 2001 on Friday, March 16, 2001.  The purpose is to promote
communication among users and developers of IBIS models in Europe.

The meeting is free and open to everyone.  Refreshments and a hot
lunch will be provided to all attendees.

Below is some information on the IBIS Summit and some related events.
You are invited to register and also to submit presentation proposals.
We already have three or four presentations.

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
                    F I R S T   A N N O U N C E M E N T 

Time/Date:     8:30 PM - 5:00 PM, Friday, March 16, 2001

Location:      ASTRON HOTEL/Neue Messe
               Eggenfeldener Strasse 100
               Munich, Germany 

               This hotel is near the DATE 2001 Conference

Content:       Presentations and Discussions

Purpose:       Solicit and Exchange IBIS Model Related Information and Ideas

Sponsors:      Cadence Design, Innoveda, Mentor Graphics, Zuken

DATE 2001:     March 13 - 16, 2001.  The IBIS meeting is scheduled
               the day after the DATE 2001 exhibition ends.

Location:      International Congress Center, Munich, Germany

               See http://www.date-conference.com for more information.

BACKGROUND

We have been holding interesting European IBIS Summit Meetings for the
last three years.  This year we are planning another meeting to include:

  Submitted Presentations on IBIS Topics (See below)
  Information about IBIS Version 3.2 and Activities
  Less formal Ad Hoc Presentations and Discussions
  IBIS Questions and Answers
  
Below is an invitation to register and also to submit presentations.

CALL FOR PARTICIPANTS

People involved in IBIS Model development, EDA tool development, and digital
circuit design are invited to participate in the European IBIS Summit meeting.
If you plan to participate, please register with the information below
(deadline, March 9, 2001):

  Name:
  E-mail address:
  Company:
  Telephone:

Send to:

  Karine Loudet (karine_loudet@mentor.com)  +33 1 40 94 74 54
  
CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have IBIS experiences
or issues.  Some suggested subjects of interest are:

  IBIS Model Development Experiences
  Company IBIS Standards and Requirements
  Generating and Validating IBIS Models
  Future IBIS Requirements
  EMC/EMI IBIS Issues

Format of Presentation:  Overhead Projections
Time:                    15-30 Minutes
Electronic Archival:     We request electronic versions so that the
                         presentations can be archived and also made
                         available to non-attendees.  Formats used in
                         the past have been text, Power Point, Word, 
                         Postscript, and Acrobat.  Electronic presentations
                         should be made available by March 6, 2001.
                         Otherwise the presentor will be expected to provide
                         50 copies for distribution.

If you plan a presentation, please supply

  Title:
  Presenter:
  E-mail address:
  Company:
  Telephone:

  Estimate Time:

Send this to:

  Karine Loudet (karine_loudet@mentor.com)
  Bob Ross (bob_ross@mentor.com)

AGENDA

The agenda includes presentations, discussions.  A free lunch is scheduled
for all attendees.

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 Jan 31 11:21:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0VJL7H25787
	for <ibis-users@eda.org>; Wed, 31 Jan 2001 11:21:08 -0800 (PST)
Received: from phys-ha1mpka.eng.sun.com ([129.146.122.34])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22596
	for <ibis-users@eda.org>; Wed, 31 Jan 2001 11:17:17 -0800 (PST)
Received: from rogue5 (rogue5 [129.146.121.231])
	by phys-ha1mpka.eng.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id LAA22736
	for <ibis-users@eda.org>; Wed, 31 Jan 2001 11:17:17 -0800 (PST)
Message-Id: <200101311917.LAA22736@phys-ha1mpka.eng.sun.com>
Date: Wed, 31 Jan 2001 11:17:16 -0800 (PST)
From: Stephen Muller <Stephen.Muller@eng.sun.com>
Reply-To: Stephen Muller <Stephen.Muller@eng.sun.com>
Subject: rising/falling waveform granularity
To: ibis-users@eda.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: bYURqZ0kwDSg783w1a8YFw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 

Hi,

I am new to the IBIS game so pardon my simplistic question.  At present I am 
having an issue with s2ibis2 and how it generates the rising/falling waveform 
tables.  I edited the .spi files for the rising waveform so that data is taken 
every 50ps for the first 5ns.  Then I set the simulation time to 5ns.  The 
individual .out files that result contain the information I want in my table but 
when the .ibs file is written, the granularity is 100ps instead of the desired 
50ps.  The specification states that 100 points can be in the table but the 
table only has 50 points in it.  Last time I checked 50ps into 5ns is 100.

My question is: How can I set up(or manipulate) the s2ibis2 run so that I get 
the granularity that I want?  Also is there an archive of e-mail that I can 
browse to see if this was discussed in the past?

Thank you,
Stephen


  
  Stephen Muller
  Electronic Component & Interconnect Technologies
  Engineer
  Phone: 650-786-3374 or x83374
  e-mail Stephen.Muller@eng.sun.com

   _/_/_/  _/    _/  _/     _/     
  _/      _/    _/  _/_/   _/       
  _/_/_/ _/    _/  _/  _/ _/  
     _/ _/    _/  _/   _/_/        
_/_/_/  _/_/_/   _/     _/         			 				     		 
M  I  C  R  O  S  Y  S  T  E  M  S    
   				     	

 
From owner-ibis Wed Jan 31 13:03:16 2001
Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f0VL3FH26174
	for <ibis-users@eda.org>; Wed, 31 Jan 2001 13:03:15 -0800 (PST)
Received: from labonte.com (mail.hammerheadnetworks.com [64.55.108.178])
	by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f0VKwMk27933;
	Wed, 31 Jan 2001 12:58:37 -0800
Message-ID: <3A787C86.566ED9ED@labonte.com>
Date: Wed, 31 Jan 2001 15:58:46 -0500
From: Mike LaBonte <mike@labonte.com>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD BDP81800  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Muller <Stephen.Muller@eng.sun.com>
CC: ibis-users@eda.org
Subject: Re: rising/falling waveform granularity
References: <200101311917.LAA22736@phys-ha1mpka.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen,

The public s2ibis2 code always resamples the simulated waveforms down
to 51 points. It does this because the typical, minimum, and maximum
curves in the IBIS file have to share the same set of time points,
even though the 3 simulated waveforms may not have the same set of
time points. It is a mystery to me how the number 51 was chosen,
although I have been conversing with the author, Alan Glaser.

I have a version of s2ibis2 with some fixes, including the ability to
output waveforms with any number of points (98 by default). If you are
interested I can send this to you. We have used it for our IBIS model
making. I was going to make more improvements in the waveform point
picking algorithm before posting it publicly, but things got busy and
it may be a while before I revisit this.

Mike LaBonte

Stephen Muller wrote:
> 
> Hi,
> 
> I am new to the IBIS game so pardon my simplistic question.  At present I am
> having an issue with s2ibis2 and how it generates the rising/falling waveform
> tables.  I edited the .spi files for the rising waveform so that data is taken
> every 50ps for the first 5ns.  Then I set the simulation time to 5ns.  The
> individual .out files that result contain the information I want in my table but
> when the .ibs file is written, the granularity is 100ps instead of the desired
> 50ps.  The specification states that 100 points can be in the table but the
> table only has 50 points in it.  Last time I checked 50ps into 5ns is 100.
> 
> My question is: How can I set up(or manipulate) the s2ibis2 run so that I get
> the granularity that I want?  Also is there an archive of e-mail that I can
> browse to see if this was discussed in the past?
> 
> Thank you,
> Stephen
> 
> 
>   Stephen Muller
>   Electronic Component & Interconnect Technologies
>   Engineer
>   Phone: 650-786-3374 or x83374
>   e-mail Stephen.Muller@eng.sun.com
> 
>    _/_/_/  _/    _/  _/     _/
>   _/      _/    _/  _/_/   _/
>   _/_/_/ _/    _/  _/  _/ _/
>      _/ _/    _/  _/   _/_/
> _/_/_/  _/_/_/   _/     _/
> M  I  C  R  O  S  Y  S  T  E  M  S
>