Subject: ibis-users V1 #26
From: owner-ibis-users@ (ibis-users)
To: [email-masked]

ibis-users            Friday, July 11 2003            Volume 01 : Number 026

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

Date: Fri, 20 Jun 2003 11:00:32 -0700
From: Tessa Trethewey <[email-masked]>
Subject: Re: [IBIS-Users] IBIS VMEAS and VREF Question.

Hi Rick

Question: is the Vmeas Vcc-relative?  While the voltage of the part is varied over Vmin to Vmax, the
Vref and Vmeas are held constant and this can cause the error you mention.  

If you use the [Model spec] keyword you can give Vmeas min, typ and max values so it follows your
Vcc from Min to max.  Apparnatly some simulators will also allow Vref to be defined this way, but I
got errors in the Vis. IBIS editor 3.0 so check your particular simulator.

EG:
[Model]          CMLOUT
		Model_type       Output
		Polarity         Non-Inverting
		Enable           Active-High
		Vref  = 2.6V 
		Cref  = 0pF
		Rref  = 50
		C_comp     1.8305pF    1.6406pF     1.9862pF
		[Model spec]
		Vmeas  		2.6		2.45		2.75	
		|Vref		2.6		2.45		2.75

Hope this helps!
Tessa Trethewey
Cypress Applications Engineering
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Wed, 25 Jun 2003 17:44:17 +0530
From: [email-masked]
Subject: [IBIS-Users] Why we make data VCC and GND relative

Hi,
   Why we need to make our pullup, pulldown, powerclamp and groundclamp
data too VCC and GND relative.
Regards
Akhilesh
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Wed, 25 Jun 2003 11:06:26 -0700
From: "Duane Mattheisen" <[email-masked]>
Subject: Re: [IBIS-Users] Why we make data VCC and GND relative

Hello akhilesh
  In  the IBIS spec there  is reference to the Vcc relative, this so
that simulators can calculate the diode clamp current so that when the
Vtable is at 0 volts the clamp current is at zero current.

                 Thanks Duane M

[email-masked] wrote:
> 
> Hi,
>    Why we need to make our pullup, pulldown, powerclamp and groundclamp
> data too VCC and GND relative.
> Regards
> Akhilesh
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 26 Jun 2003 11:43:57 +0200
From: [email-masked]
Subject: [IBIS-Users] damped oscillations in V-T curve

This is a multipart message in MIME format.
- --=_alternative 0035A9ABC1256D51_=
Content-Type: text/plain; charset="us-ascii"

Hello,

In my V-T curve I see a damped oscillation in the falling waveform (diff 
PECL).
When I do a HSPICE simulation with different load resistances  I observe 
that the amplitude of the first peak increases dramatically while this is 
not the case in a simulation of the original buffer in Spectre.
What should I do to model this behaviour correctly. And what causes this 
increase in amplitude?

With kind regards,

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334
- --=_alternative 0035A9ABC1256D51_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2 face="sans-serif">In my V-T curve I see a damped oscillation in the falling waveform (diff PECL).</font>
<br><font size=2 face="sans-serif">When I do a HSPICE simulation with different load resistances &nbsp;I observe that the amplitude of the first peak increases dramatically while this is not the case in a simulation of the original buffer in Spectre.</font>
<br><font size=2 face="sans-serif">What should I do to model this behaviour correctly. And what causes this increase in amplitude?</font>
<br>
<br><font size=2 face="sans-serif">With kind regards,</font>
<br>
<br><font size=2 face="sans-serif"><br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
- --=_alternative 0035A9ABC1256D51_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 26 Jun 2003 12:23:32 +0200
From: [email-masked]
Subject: RE: [IBIS-Users] damped oscillations in V-T curve

Hi Eric,

I am not sure whether this will address your issue, but I noticed a while back that HSpice's B-element when used for PECL buffers simulates best when the actual load (in a system) does not deviate too much from the load that was used to record the waveforms. This was certainly true for older versions (2001.2), but may have been rectified in newer releases. It has probably to do with the way HSpice interpolates between the "high" and "low" state when switching PECL buffers. This is only an issue for PECL buffers and not that much for other buffer types. 

Another issue with buffer simulations is that HSpice does not like "overclocking", that means a Vt transition needs to be finished before the buffer is switched again. 

As an aside, I tend to use "effective" loads so that eg. ac-coupled PECL buffers are well behaved in the intended application. Please see example below. This has worked well so far.

I hope this gives you some ideas where to look,

Best Regards,

	Herbert.

| **************************************************************
|
| The V_fixture and R_fixture values for the waveform tables 
| are equivalent values which produce the right loadline for 
| a PECL output with a 130 Ohm dc-bias resistor and an ac-coupled 
| (50+15) Ohm load. The bit pattern is assumed to be balanced so  
| that the ac-coupling capacitor is charged to (Vol + Voh)/2.
|
|
|                          15 Ohms          50 Ohms
|                                     | |
|    PECL-Output -----------/\/\/\----| |----/\/\/\------
|                      |              | |                |
|                      |                                 |
|                      \                                 |
|                      /                                 |
|                      \  130 Ohms                       |
|                      /                                 |
|                      |                                 |
|                      |                                 |
|                    -----                             -----
|                     ---                               ---
|                      -                                 -
| 
| **************************************************************
|
[Falling Waveform]
|
R_fixture = 43.33
V_fixture = 1.300
V_fixture_min = 1.147  
V_fixture_max = 1.487
|
| time           V(typ)              V(min)          V(max)
| 
   0.000E+00s      2.316E+00V      1.985E+00V      2.633E+00V   
   1.000E-11s      2.316E+00V      1.985E+00V      2.633E+00V   
   2.000E-11s      2.316E+00V      1.986E+00V      2.633E+00V   
   3.000E-11s      2.316E+00V      1.986E+00V      2.633E+00V   
      .                .                .              .
      .                .                .              .
      .                .                .              .

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 26 June 2003 11:44
To: [email-masked]
Subject: [IBIS-Users] damped oscillations in V-T curve

Hello, 

In my V-T curve I see a damped oscillation in the falling waveform (diff PECL). 
When I do a HSPICE simulation with different load resistances  I observe that the amplitude of the first peak increases dramatically while this is not the case in a simulation of the original buffer in Spectre. 
What should I do to model this behaviour correctly. And what causes this increase in amplitude? 

With kind regards, 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 26 Jun 2003 13:48:43 -0400
From: "Lauzums, Andris" <[email-masked]>
Subject: [IBIS-Users] Diff Pin Question

Hello-

I had a question about the [Diff_Pin] parameter in the IBIS specification.  In reference to t_delay, (min, typ, and max), where my non-inverting ouput is output A, and my inverting output is B, I am unclear about the following:

Does a positive (as opposed to negative) value in the t_delay column mean that A occurs after B, or that B occurs after A?  I have read the IBIS specification for this parameter, and it states that "(t-delay contains) launch delays of the non-inverting pins relative to the inverting pins.  The values can be of either polarity".  It does not seem to specify which way is positive, and which way is negative.  This is the source of my confusion.

Thank you for the help-

Andris Lauzums
Intersil Corporation
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 26 Jun 2003 11:08:21 -0700
From: "Derwin Mattos" <[email-masked]>
Subject: [IBIS-Users] Clamp curve subtraction

This is a multi-part message in MIME format.

- ------=_NextPart_000_0034_01C33BD3.41B3B360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

IBIS developers/users,

I'm attempting to work through the non-monotonic
issues raised in the standard.

Can someone tell me if I'm missing something?

The IBIS standard recommends the subtraction of clamp curves from
pull-up and pull-down curves.  This can cause "non-monotonic"
warning messages to pop up during a syntax check.

When I want to replace my clamp curves with curves
measured from silicon (to improve clamp accuracy), the
combined curve has the potential of being non-monotonic
because the pull-down/pull-up curve has the original clamp
subtracted from it.

I'm thinking that double-counting clamps at the outputs
is not a significant issue (most signal overshoot occurs
at receiving-ends, not driving-ends), so would like to NOT do the
clamp subtraction.  A simple note explaining why would
be included in the model.

My preference is for input clamp curve accuracy, not output driver
clamp curve accuracy.

Are there any write-ups on this particular issue?

As an IBIS user, what is your preference?  Do you require that
the clamp curves be subtracted?  Why?  Is it a technical reason?

Thanks so much for any feedback/guidance.  It would be much
appreciated.

Regards,
Derwin

- ------=_NextPart_000_0034_01C33BD3.41B3B360
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

- ------=_NextPart_000_0034_01C33BD3.41B3B360--

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 26 Jun 2003 22:27:13 -0700
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] Why we make data VCC and GND relative

Actually, all of the IV curves have now a corresponding [*** Reference]
keyword.
These were introduced so that each IV curve could have an independent
supply voltage reference, and the original Vcc relative idea was
therefore
extended to be more general.  This whole idea is necessary to allow the
simulator
to account for the correct current path for (power delivery
simulations).

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

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 25, 2003 5:14 AM
To: [email-masked]
Subject: [IBIS-Users] Why we make data VCC and GND relative

Hi,
   Why we need to make our pullup, pulldown, powerclamp and groundclamp
data too VCC and GND relative. Regards Akhilesh
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked] with just

|the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent  
| http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 27 Jun 2003 15:13:20 +0200
From: [email-masked]
Subject: RE: [IBIS-Users] damped oscillations in V-T curve

This is a multipart message in MIME format.
- --=_alternative 0048D55FC1256D52_=
Content-Type: text/plain; charset="us-ascii"

__________________

Hello Herbert,

Thanks for your reaction. Iam using HSPICE2002.2.2. Indeed when I use 50 
Ohm load (equal to Rfix) everything is OK. With 70 ohm load this peaking 
occurs. I tried to use two wave forms in the IBIS model, one with Rfix=50 
and one with Rfix=70. But SPICE gave an waring that only one curve is 
used, I don't know why. Could this method help to get better results?  I 
don't know what a simulator exactly does with two waveform tables.

Are there more users who can comment on this issue?

With kind regards,
Erik.

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334

[email-masked]
Sent by: 
[email-masked]
06/26/03 12:23 PM

        To:     Erik van der Ven/NYM/SC/PHILIPS@EMEA2
[email-masked]
        cc: 
        Subject:        RE: [IBIS-Users] damped oscillations in V-T curve
        Classification: 

Hi Eric,

I am not sure whether this will address your issue, but I noticed a while 
back that HSpice's B-element when used for PECL buffers simulates best 
when the actual load (in a system) does not deviate too much from the load 
that was used to record the waveforms. This was certainly true for older 
versions (2001.2), but may have been rectified in newer releases. It has 
probably to do with the way HSpice interpolates between the "high" and 
"low" state when switching PECL buffers. This is only an issue for PECL 
buffers and not that much for other buffer types. 

Another issue with buffer simulations is that HSpice does not like 
"overclocking", that means a Vt transition needs to be finished before the 
buffer is switched again. 

As an aside, I tend to use "effective" loads so that eg. ac-coupled PECL 
buffers are well behaved in the intended application. Please see example 
below. This has worked well so far.

I hope this gives you some ideas where to look,

Best Regards,

                 Herbert.

| **************************************************************
|
| The V_fixture and R_fixture values for the waveform tables 
| are equivalent values which produce the right loadline for 
| a PECL output with a 130 Ohm dc-bias resistor and an ac-coupled 
| (50+15) Ohm load. The bit pattern is assumed to be balanced so 
| that the ac-coupling capacitor is charged to (Vol + Voh)/2.
|
|
|                          15 Ohms          50 Ohms
|                                     | |
|    PECL-Output -----------/\/\/\----| |----/\/\/\------
|                      |              | |                |
|                      |                                 |
|                      \                                 |
|                      /                                 |
|                      \  130 Ohms                       |
|                      /                                 |
|                      |                                 |
|                      |                                 |
|                    -----                             -----
|                     ---                               ---
|                      -                                 -
| 
| **************************************************************
|
[Falling Waveform]
|
R_fixture = 43.33
V_fixture = 1.300
V_fixture_min = 1.147 
V_fixture_max = 1.487
|
| time           V(typ)              V(min)          V(max)
| 
   0.000E+00s      2.316E+00V      1.985E+00V      2.633E+00V 
   1.000E-11s      2.316E+00V      1.985E+00V      2.633E+00V 
   2.000E-11s      2.316E+00V      1.986E+00V      2.633E+00V 
   3.000E-11s      2.316E+00V      1.986E+00V      2.633E+00V 
      .                .                .              .
      .                .                .              .
      .                .                .              .

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 26 June 2003 11:44
To: [email-masked]
Subject: [IBIS-Users] damped oscillations in V-T curve

Hello, 

In my V-T curve I see a damped oscillation in the falling waveform (diff 
PECL). 
When I do a HSPICE simulation with different load resistances  I observe 
that the amplitude of the first peak increases dramatically while this is 
not the case in a simulation of the original buffer in Spectre. 
What should I do to model this behaviour correctly. And what causes this 
increase in amplitude? 

With kind regards, 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

- --=_alternative 0048D55FC1256D52_=
Content-Type: text/html; charset="us-ascii"

<br>
<br><font size=2 face="sans-serif">__________________</font>
<br>
<br><font size=2 face="sans-serif">Hello Herbert,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for your reaction. Iam using HSPICE2002.2.2. Indeed when I use 50 Ohm load (equal to Rfix) everything is OK. With 70 ohm load this peaking occurs. I tried to use two wave forms in the IBIS model, one with Rfix=50 and one with Rfix=70. But SPICE gave an waring that only one curve is used, I don't know why. Could this method help to get better results? &nbsp;I don't know what a simulator exactly does with two waveform tables.</font>
<br>
<br><font size=2 face="sans-serif">Are there more users who can comment on this issue?</font>
<br>
<br><font size=2 face="sans-serif">With kind regards,</font>
<br><font size=2 face="sans-serif">Erik.</font>
<br>
<br><font size=2 face="sans-serif"><br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>[email-masked]</b></font>
<p><font size=1 face="sans-serif">Sent by: </font>
<br><font size=1 face="sans-serif">[email-masked]</font>
<p><font size=1 face="sans-serif">06/26/03 12:23 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Erik van der Ven/NYM/SC/PHILIPS@EMEA2<br>
[email-masked]</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: [IBIS-Users] damped oscillations in V-T curve</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New">Hi Eric,<br>
<br>
I am not sure whether this will address your issue, but I noticed a while back that HSpice's B-element when used for PECL buffers simulates best when the actual load (in a system) does not deviate too much from the load that was used to record the waveforms. This was certainly true for older versions (2001.2), but may have been rectified in newer releases. It has probably to do with the way HSpice interpolates between the &quot;high&quot; and &quot;low&quot; state when switching PECL buffers. This is only an issue for PECL buffers and not that much for other buffer types. <br>
<br>
Another issue with buffer simulations is that HSpice does not like &quot;overclocking&quot;, that means a Vt transition needs to be finished before the buffer is switched again. <br>
<br>
As an aside, I tend to use &quot;effective&quot; loads so that eg. ac-coupled PECL buffers are well behaved in the intended application. Please see example below. This has worked well so far.<br>
<br>
I hope this gives you some ideas where to look,<br>
<br>
Best Regards,<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Herbert.<br>
<br>
<br>
| **************************************************************<br>
|<br>
| The V_fixture and R_fixture values for the waveform tables <br>
| are equivalent values which produce the right loadline for <br>
| a PECL output with a 130 Ohm dc-bias resistor and an ac-coupled <br>
| (50+15) Ohm load. The bit pattern is assumed to be balanced so &nbsp;<br>
| that the ac-coupling capacitor is charged to (Vol + Voh)/2.<br>
|<br>
|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 Ohms &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;50 Ohms<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | |<br>
| &nbsp; &nbsp;PECL-Output -----------/\/\/\----| |----/\/\/\------<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\ &nbsp;130 Ohms &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;----- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -----<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; --- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ---<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -<br>
| <br>
| **************************************************************<br>
|<br>
[Falling Waveform]<br>
|<br>
R_fixture = 43.33<br>
V_fixture = 1.300<br>
V_fixture_min = 1.147 &nbsp;<br>
V_fixture_max = 1.487<br>
|<br>
| time &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; V(typ) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;V(min) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;V(max)<br>
| <br>
 &nbsp; 0.000E+00s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.985E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp; 1.000E-11s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.985E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp; 2.000E-11s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.986E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp; 3.000E-11s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.986E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.<br>
 &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.<br>
 &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.<br>
<br>
<br>
<br>
- -----Original Message-----<br>
From: [email-masked] [mailto:[email-masked]]<br>
Sent: 26 June 2003 11:44<br>
To: [email-masked]<br>
Subject: [IBIS-Users] damped oscillations in V-T curve<br>
<br>
<br>
<br>
Hello, <br>
<br>
In my V-T curve I see a damped oscillation in the falling waveform (diff PECL). <br>
When I do a HSPICE simulation with different load resistances &nbsp;I observe that the amplitude of the first peak increases dramatically while this is not the case in a simulation of the original buffer in Spectre. <br>
What should I do to model this behaviour correctly. And what causes this increase in amplitude? <br>
<br>
With kind regards, <br>
<br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334<br>
|------------------------------------------------------------------<br>
|For help or to subscribe/unsubscribe, email [email-masked]<br>
|with just the appropriate command message(s) in the body:<br>
|<br>
| &nbsp;help<br>
| &nbsp;subscribe &nbsp; ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;subscribe &nbsp; ibis-users &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis-users &lt;optional e-mail address, if different&gt;<br>
|<br>
|or email a written request to [email-masked].<br>
|<br>
|IBIS reflector archives exist under:<br>
|<br>
| &nbsp;http://www.eda.org/pub/ibis/email_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/users_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/email/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;E-mail since 1993</font>
<br><font size=2 face="Courier New"><br>
</font>
<br>
<br>
- --=_alternative 0048D55FC1256D52_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 27 Jun 2003 11:36:04 -0400
From: "Ingraham, Andrew" <[email-masked]>
Subject: Re: [IBIS-Users] Clamp curve subtraction

If this is an output-only pin, then I would agree with you that overshoot is
probably not that significant (although light loads might lead to enough
ringing to activate the clamps).  But in this case I believe you would omit
the clamp tables anyway; i.e., your model would have Pullup and Pulldown
tables which include the clamp diodes, and no separate Clamp tables; so
clamp subtraction would not be an issue.

If the pin can be tri-stated (whether or not it is an I/O), and the net to
which this device is attached can be driven by another device on the net,
then the clamps ARE significant and should be modeled relatively well.

But, if the non-monotonicity starts happening only when your outputs are
well into the clamping region, then it could be argued that the accuracy
"out there" (especially when driving) is less important, since the device
should spend very little, if any, time that far out along the clamp curves.
At -3V, or at Vcc+3V, accuracy is less important than just being in the
ballpark with a reasonable slope to pull the simulator back to the "normal"
operating region.

Also, if the non-monotonicity is slight and due to measurement noise,
another option to consider is to smooth out the measured data, perhaps by
reducing the number of points.

Personally, I really don't care very much if subtracting the clamps causes
the raw Pullup and Pulldown tables to become non-monotonic.  Monotonicity is
not an IBIS requirement!  When the IBIS model is used by a simulator, and
the simulator adds the Clamp tables back to the Pullup and Pulldown tables
before using them, the non-monotonicity goes away and the simulator engine
never sees it.

It's just that the IBIS syntax checker doesn't add the tables back together
(I assume in part because it would need to do some interpolation or spline
curve approximation), so it looks only at the raw curves, which could be
non-monotonic.  It calls it out as a warning ... not an error.  Don't get
too hung up on that.

Regards,
Andy

- ----- Original Message -----
From: "Derwin Mattos" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 26, 2003 02:08 PM
Subject: [IBIS-Users] Clamp curve subtraction

> IBIS developers/users,
>
> I'm attempting to work through the non-monotonic
> issues raised in the standard.
>
> Can someone tell me if I'm missing something?
>
> The IBIS standard recommends the subtraction of clamp curves from
> pull-up and pull-down curves.  This can cause "non-monotonic"
> warning messages to pop up during a syntax check.
>
> When I want to replace my clamp curves with curves
> measured from silicon (to improve clamp accuracy), the
> combined curve has the potential of being non-monotonic
> because the pull-down/pull-up curve has the original clamp
> subtracted from it.
>
> I'm thinking that double-counting clamps at the outputs
> is not a significant issue (most signal overshoot occurs
> at receiving-ends, not driving-ends), so would like to NOT do the
> clamp subtraction.  A simple note explaining why would
> be included in the model.
>
> My preference is for input clamp curve accuracy, not output driver
> clamp curve accuracy.
>
> Are there any write-ups on this particular issue?
>
> As an IBIS user, what is your preference?  Do you require that
> the clamp curves be subtracted?  Why?  Is it a technical reason?
>
> Thanks so much for any feedback/guidance.  It would be much
> appreciated.
>
> Regards,
> Derwin
>

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 27 Jun 2003 11:53:16 -0400
From: "Ingraham, Andrew" <[email-masked]>
Subject: Re: [IBIS-Users] damped oscillations in V-T curve

This is a multi-part message in MIME format.

- ------=_NextPart_000_046C_01C33CA2.B1ED6700
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I don't know if this has any bearing on this particular issue, but ...

You noted that the discrepancy was with the first peak, implying that =
the damped oscillations that followed it were not that bad.  This =
implies a nonlinear effect.

It should also be noted that PECL outputs are very nonlinear, and this =
is most evident on falling edges.

I wonder how well Spectre handles that much nonlinearity.

Likewise, it might also be that IBIS models, or the HSPICE =
implementation of IBIS models, do not function all that well when there =
is that much nonlinearity.

Check to see whether HSPICE has an option to make it use more than just =
the first V-T curve.  Also try changing the order of the V-T curves in =
the model, to force it to use the R_fixture=3D70 ohm curve.

Regards,
Andy

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Thursday, June 26, 2003 05:43 AM
  Subject: [IBIS-Users] damped oscillations in V-T curve

  Hello,=20

  In my V-T curve I see a damped oscillation in the falling waveform =
(diff PECL).=20
  When I do a HSPICE simulation with different load resistances  I =
observe that the amplitude of the first peak increases dramatically =
while this is not the case in a simulation of the original buffer in =
Spectre.=20
  What should I do to model this behaviour correctly. And what causes =
this increase in amplitude?=20

  With kind regards,=20

  Ir. Erik van der Ven
  Room DB1032
  Business Line Networking Infrastructure
  Philips Semiconductors BV
  Gerstweg 2
  6534 AE Nijmegen
  The Netherlands
  Phone: +31-24-3534334

- ------=_NextPart_000_046C_01C33CA2.B1ED6700
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>I don't know if this has any bearing on this =
particular issue,=20
but ...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>You noted that the discrepancy was with the first =
peak,=20
implying that the&nbsp;damped oscillations that followed it were not =
that=20
bad.&nbsp; This implies a nonlinear effect.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>It should also be noted that PECL&nbsp;outputs are =
very=20
nonlinear, and this is most evident on falling edges.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I wonder how well Spectre handles that much=20
nonlinearity.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Likewise, it might also be that IBIS models, or the =
HSPICE=20
implementation of IBIS models, do not function all that well when there =
is that=20
much nonlinearity.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Check to see whether HSPICE has an option to make it =
use more=20
than just the first V-T curve.&nbsp; Also try changing the order of the =
V-T=20
curves in the model, to force it to use the R_fixture=3D70 ohm =
curve.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2>Andy</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[email-masked]"=20
  title=[email-masked]>[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, June 26, 2003 =
05:43=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [IBIS-Users] damped =
oscillations=20
  in V-T curve</DIV>
  <DIV><BR></DIV><BR><FONT face=3Dsans-serif size=3D2>Hello,</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D2>In my V-T curve I see a damped oscillation =
in the=20
  falling waveform (diff PECL).</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>When I=20
  do a HSPICE simulation with different load resistances &nbsp;I observe =
that=20
  the amplitude of the first peak increases dramatically while this is =
not the=20
  case in a simulation of the original buffer in Spectre.</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>What should I do to model this behaviour =
correctly. And=20
  what causes this increase in amplitude?</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>With kind regards,</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2><BR>Ir.=20
  Erik van der Ven<BR>Room DB1032<BR>Business Line Networking=20
  Infrastructure<BR>Philips Semiconductors BV<BR>Gerstweg 2<BR>6534 AE=20
  Nijmegen<BR>The Netherlands<BR>Phone:=20
+31-24-3534334</FONT></BLOCKQUOTE></BODY></HTML>

- ------=_NextPart_000_046C_01C33CA2.B1ED6700--

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 27 Jun 2003 12:14:41 -0500
From: Gang Huo <[email-masked]>
Subject: [IBIS-Users] Direct input/Output buffer modeling

Hi All,

I am having some issues when generating IBIS models for following kind of
buffers:

                   |----------|
input---- |Protect circuit |---------output
                   |----------|

Basically, output is directly connected to input with the add-on of ESD
protection circuit.

Is the "series" the only good way to model this kind of buffer? Is there a
good way to model this buffer in IBIS spec 2.1?

The problem I met using the "traditional" IBIS model is that the ramp time
won't change with respect to input, but will stay at the value stated in the
IBIS model.

For example, when generating the IBIS model, I use a signal with ramp of
1V/1E-10s on the input to simulate the ramp time. The generated IBIS model
will have a ramp time in the same range. But when doing simulation with the
generated IBIS model, the simulated output will stay at about the same ramp
time (1V/1E-10s), even if I changed the ramp time for the input signal to
(1V/1E-8S), which is not the correct way the buffer works.

Anyone has met the same issues before? Any feedback will be greatly
appreciated.

Thanks,
Gang

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: 27 Jun 2003 16:55:59 -0700
From: Syed Huq <[email-masked]>
Subject: [IBIS-Users] Mid Year Roster Cleanup - Pls respond

Hello,

Pls take a moment to review your roster entry on the IBIS page:

http://www.vhdl.org/pub/ibis/roster/roster.html

If certain information needs to be updated, pls provide the changes to
me. We want your information to be current for the IBIS community.

If no changes are needed, still respond back to me and confirm.

Failure to provide a response may result in the removal of your entries
from the roster so your quick response will be highly appreciated.

Regards,
Syed
Cisco Systems, Inc
Webmaster

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Mon, 30 Jun 2003 09:37:31 +0200
From: [email-masked]
Subject: RE: [IBIS-Users] damped oscillations in V-T curve

This is a multipart message in MIME format.
- --=_alternative 002A1750C1256D55_=
Content-Type: text/plain; charset="us-ascii"

__________________

Tom,

I am just using an ideal resistive load and I have no package model. 
Herbert suggested that HSPICE does not accept two waveform tables because 
this is not needed for ECL models according to the IBIS specification.
The ringing is likely caused by the internal feedback mechanism in the 
PECL buffer. 
Perhaps it is best just to truncate the falling waveform when it has 
reached the zero level. But I don't know SI-engineers will miss relevant 
information for their simulations. I wonder if simulators can handle 
ringing caused by internal feedback anyway, since simulator have not 
enough information to estimate the loop behaviour from just a data table.

With kind regards,
erik.

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334

"Tom Dagostino" <[email-masked]>
06/27/03 06:22 PM
Please respond to tom

        To:     Erik van der Ven/NYM/SC/PHILIPS@EMEA2
        cc: 
        Subject:        RE: [IBIS-Users] damped oscillations in V-T curve
        Classification: 

Eric
 
For the rest of us to help you you will need to be more specific about 
what you are simulating.  Is this a circuit with a transmission line in it 
or just a buffer into a load R?  What is your package model?  What else 
can you tell us?
 
Tom Dagostino
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
2926 SE Yamhill St.                Device Modeling Division
Portland, OR 97214                 13610 SW Harness Lane
                                   Beaverton, OR 97008
http://www.teraspeed.com           503-430-1065 
[email-masked] 
- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Friday, June 27, 2003 6:13 AM
To: [email-masked]
Subject: RE: [IBIS-Users] damped oscillations in V-T curve

__________________ 

Hello Herbert, 

Thanks for your reaction. Iam using HSPICE2002.2.2. Indeed when I use 50 
Ohm load (equal to Rfix) everything is OK. With 70 ohm load this peaking 
occurs. I tried to use two wave forms in the IBIS model, one with Rfix=50 
and one with Rfix=70. But SPICE gave an waring that only one curve is 
used, I don't know why. Could this method help to get better results?  I 
don't know what a simulator exactly does with two waveform tables. 

Are there more users who can comment on this issue? 

With kind regards, 
Erik. 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334 

[email-masked] 
Sent by: 
[email-masked] 
06/26/03 12:23 PM 
        
        To:        Erik van der Ven/NYM/SC/PHILIPS@EMEA2
[email-masked] 
        cc:         
        Subject:        RE: [IBIS-Users] damped oscillations in V-T curve 
        Classification:         

Hi Eric,

I am not sure whether this will address your issue, but I noticed a while 
back that HSpice's B-element when used for PECL buffers simulates best 
when the actual load (in a system) does not deviate too much from the load 
that was used to record the waveforms. This was certainly true for older 
versions (2001.2), but may have been rectified in newer releases. It has 
probably to do with the way HSpice interpolates between the "high" and 
"low" state when switching PECL buffers. This is only an issue for PECL 
buffers and not that much for other buffer types. 

Another issue with buffer simulations is that HSpice does not like 
"overclocking", that means a Vt transition needs to be finished before the 
buffer is switched again. 

As an aside, I tend to use "effective" loads so that eg. ac-coupled PECL 
buffers are well behaved in the intended application. Please see example 
below. This has worked well so far.

I hope this gives you some ideas where to look,

Best Regards,

                Herbert.

| **************************************************************
|
| The V_fixture and R_fixture values for the waveform tables 
| are equivalent values which produce the right loadline for 
| a PECL output with a 130 Ohm dc-bias resistor and an ac-coupled 
| (50+15) Ohm load. The bit pattern is assumed to be balanced so 
| that the ac-coupling capacitor is charged to (Vol + Voh)/2.
|
|
|                          15 Ohms          50 Ohms
|                                     | |
|    PECL-Output -----------/\/\/\----| |----/\/\/\------
|                      |              | |                |
|                      |                                 |
|                      \                                 |
|                      /                                 |
|                      \  130 Ohms                       |
|                      /                                 |
|                      |                                 |
|                      |                                 |
|                    -----                             -----
|                     ---                               ---
|                      -                                 -
| 
| **************************************************************
|
[Falling Waveform]
|
R_fixture = 43.33
V_fixture = 1.300
V_fixture_min = 1.147 
V_fixture_max = 1.487
|
| time           V(typ)              V(min)          V(max)
| 
  0.000E+00s      2.316E+00V      1.985E+00V      2.633E+00V 
  1.000E-11s      2.316E+00V      1.985E+00V      2.633E+00V 
  2.000E-11s      2.316E+00V      1.986E+00V      2.633E+00V 
  3.000E-11s      2.316E+00V      1.986E+00V      2.633E+00V 
     .                .                .              .
     .                .                .              .
     .                .                .              .

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 26 June 2003 11:44
To: [email-masked]
Subject: [IBIS-Users] damped oscillations in V-T curve

Hello, 

In my V-T curve I see a damped oscillation in the falling waveform (diff 
PECL). 
When I do a HSPICE simulation with different load resistances  I observe 
that the amplitude of the first peak increases dramatically while this is 
not the case in a simulation of the original buffer in Spectre. 
What should I do to model this behaviour correctly. And what causes this 
increase in amplitude? 

With kind regards, 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993 

- --=_alternative 002A1750C1256D55_=
Content-Type: text/html; charset="us-ascii"

<br>
<br><font size=2 face="sans-serif">__________________</font>
<br>
<br><font size=2 face="sans-serif">Tom,</font>
<br>
<br><font size=2 face="sans-serif">I am just using an ideal resistive load and I have no package model. Herbert suggested that HSPICE does not accept two waveform tables because this is not needed for ECL models according to the IBIS specification.</font>
<br><font size=2 face="sans-serif">The ringing is likely caused by the internal feedback mechanism in the PECL buffer. </font>
<br><font size=2 face="sans-serif">Perhaps it is best just to truncate the falling waveform when it has reached the zero level. But I don't know SI-engineers will miss relevant information for their simulations. I wonder if simulators can handle ringing caused by internal feedback anyway, since simulator have not enough information to estimate the loop behaviour from just a data table.</font>
<br>
<br><font size=2 face="sans-serif">With kind regards,</font>
<br><font size=2 face="sans-serif">erik.</font>
<br>
<br><font size=2 face="sans-serif"><br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>&quot;Tom Dagostino&quot; &lt;[email-masked]&gt;</b></font>
<p><font size=1 face="sans-serif">06/27/03 06:22 PM</font>
<br><font size=1 face="sans-serif">Please respond to tom</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Erik van der Ven/NYM/SC/PHILIPS@EMEA2</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: [IBIS-Users] damped oscillations in V-T curve</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Arial">Eric</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">For the rest of us to help you you will need to be more specific about what you are simulating. &nbsp;Is this a circuit with a transmission line in it or just a buffer into a load R? &nbsp;What is your package model? &nbsp;What else can you tell us?</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=3 face="Courier New">Tom Dagostino</font>
<br><font size=3 face="Courier New">Teraspeed Consulting Group LLC &nbsp; &nbsp; Teraspeed Consulting Group LLC</font>
<br><font size=3 face="Courier New">2926 SE Yamhill St. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Device Modeling Division</font>
<br><font size=3 face="Courier New">Portland, OR 97214 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 13610 SW Harness Lane</font>
<br><font size=3 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Beaverton, OR 97008</font>
<br><font size=3 face="Courier New">http://www.teraspeed.com &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 503-430-1065 </font>
<p><font size=3 face="Courier New">[email-masked]</font><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Tahoma">-----Original Message-----<b><br>
From:</b> [email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>[email-masked]<b><br>
Sent:</b> Friday, June 27, 2003 6:13 AM<b><br>
To:</b> [email-masked]<b><br>
Subject:</b> RE: [IBIS-Users] damped oscillations in V-T curve<br>
</font>
<br><font size=3 face="Times New Roman"><br>
</font><font size=2 face="sans-serif"><br>
__________________</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Hello Herbert,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Thanks for your reaction. Iam using HSPICE2002.2.2. Indeed when I use 50 Ohm load (equal to Rfix) everything is OK. With 70 ohm load this peaking occurs. I tried to use two wave forms in the IBIS model, one with Rfix=50 and one with Rfix=70. But SPICE gave an waring that only one curve is used, I don't know why. Could this method help to get better results? &nbsp;I don't know what a simulator exactly does with two waveform tables.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Are there more users who can comment on this issue?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
With kind regards,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Erik.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font><font size=3 face="Times New Roman"> <br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=2%>
<td width=31%><font size=3 face="Times New Roman"><br>
<br>
<br>
<br>
</font><font size=1 face="sans-serif"><b><br>
[email-masked]</b></font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">Sent by: <br>
[email-masked]</font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">06/26/03 12:23 PM</font><font size=3 face="Times New Roman"> </font>
<td width=65%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;Erik van der Ven/NYM/SC/PHILIPS@EMEA2<br>
[email-masked]</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: [IBIS-Users] damped oscillations in V-T curve</font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3 face="Times New Roman"> </font></table>
<p><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 face="Courier New"><br>
Hi Eric,<br>
<br>
I am not sure whether this will address your issue, but I noticed a while back that HSpice's B-element when used for PECL buffers simulates best when the actual load (in a system) does not deviate too much from the load that was used to record the waveforms. This was certainly true for older versions (2001.2), but may have been rectified in newer releases. It has probably to do with the way HSpice interpolates between the &quot;high&quot; and &quot;low&quot; state when switching PECL buffers. This is only an issue for PECL buffers and not that much for other buffer types. <br>
<br>
Another issue with buffer simulations is that HSpice does not like &quot;overclocking&quot;, that means a Vt transition needs to be finished before the buffer is switched again. <br>
<br>
As an aside, I tend to use &quot;effective&quot; loads so that eg. ac-coupled PECL buffers are well behaved in the intended application. Please see example below. This has worked well so far.<br>
<br>
I hope this gives you some ideas where to look,<br>
<br>
Best Regards,<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Herbert.<br>
<br>
<br>
| **************************************************************<br>
|<br>
| The V_fixture and R_fixture values for the waveform tables <br>
| are equivalent values which produce the right loadline for <br>
| a PECL output with a 130 Ohm dc-bias resistor and an ac-coupled <br>
| (50+15) Ohm load. The bit pattern is assumed to be balanced so &nbsp;<br>
| that the ac-coupling capacitor is charged to (Vol + Voh)/2.<br>
|<br>
|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;15 Ohms &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;50 Ohms<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | |<br>
| &nbsp; &nbsp;PECL-Output -----------/\/\/\----| |----/\/\/\------<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\ &nbsp;130 Ohms &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;----- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -----<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; --- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ---<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -<br>
| <br>
| **************************************************************<br>
|<br>
[Falling Waveform]<br>
|<br>
R_fixture = 43.33<br>
V_fixture = 1.300<br>
V_fixture_min = 1.147 &nbsp;<br>
V_fixture_max = 1.487<br>
|<br>
| time &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; V(typ) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;V(min) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;V(max)<br>
| <br>
 &nbsp;0.000E+00s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.985E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp;1.000E-11s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.985E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp;2.000E-11s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.986E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp;3.000E-11s &nbsp; &nbsp; &nbsp;2.316E+00V &nbsp; &nbsp; &nbsp;1.986E+00V &nbsp; &nbsp; &nbsp;2.633E+00V &nbsp; <br>
 &nbsp; &nbsp; . &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.<br>
 &nbsp; &nbsp; . &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.<br>
 &nbsp; &nbsp; . &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.<br>
<br>
<br>
<br>
- -----Original Message-----<br>
From: [email-masked] [mailto:[email-masked]]<br>
Sent: 26 June 2003 11:44<br>
To: [email-masked]<br>
Subject: [IBIS-Users] damped oscillations in V-T curve<br>
<br>
<br>
<br>
Hello, <br>
<br>
In my V-T curve I see a damped oscillation in the falling waveform (diff PECL). <br>
When I do a HSPICE simulation with different load resistances &nbsp;I observe that the amplitude of the first peak increases dramatically while this is not the case in a simulation of the original buffer in Spectre. <br>
What should I do to model this behaviour correctly. And what causes this increase in amplitude? <br>
<br>
With kind regards, <br>
<br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334<br>
|------------------------------------------------------------------<br>
|For help or to subscribe/unsubscribe, email [email-masked]<br>
|with just the appropriate command message(s) in the body:<br>
|<br>
| &nbsp;help<br>
| &nbsp;subscribe &nbsp; ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;subscribe &nbsp; ibis-users &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis-users &lt;optional e-mail address, if different&gt;<br>
|<br>
|or email a written request to [email-masked].<br>
|<br>
|IBIS reflector archives exist under:<br>
|<br>
| &nbsp;http://www.eda.org/pub/ibis/email_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/users_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/email/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;E-mail since 1993</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
</font><font size=3 face="Times New Roman"><br>
<br>
</font>
<p>
<p>
- --=_alternative 002A1750C1256D55_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Mon, 30 Jun 2003 10:49:57 +0200
From: [email-masked]
Subject: Re: [IBIS-Users] damped oscillations in V-T curve

This is a multipart message in MIME format.
- --=_alternative 0030B8ACC1256D55_=
Content-Type: text/plain; charset="us-ascii"

Hello Andrew,

The oscillation/ringing is damped such  that the next peaks become 
negligible. I cannot image that these calculations are a problem for 
Spectre. HSPICE has the possiblity to use 2 waveforms instead of one. But 
I get a warning that it only uses one waveform, probably because it is not 
needed for ECL according to the IBIS specification.
Do you have any idea how to deal with oscillations/ringing in general and 
how simulators deal with it? 

With kind regards,
Erik.

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334

"Ingraham, Andrew" <[email-masked]>
Sent by: 
[email-masked]
06/27/03 05:53 PM

        To:     <[email-masked]>
        cc:     (bcc: Erik van der Ven/NYM/SC/PHILIPS)
        Subject:        Re: [IBIS-Users] damped oscillations in V-T curve
        Classification: 

I don't know if this has any bearing on this particular issue, but ...
 
You noted that the discrepancy was with the first peak, implying that the 
damped oscillations that followed it were not that bad.  This implies a 
nonlinear effect.
 
It should also be noted that PECL outputs are very nonlinear, and this is 
most evident on falling edges.
 
I wonder how well Spectre handles that much nonlinearity.
 
Likewise, it might also be that IBIS models, or the HSPICE implementation 
of IBIS models, do not function all that well when there is that much 
nonlinearity.
 
Check to see whether HSPICE has an option to make it use more than just 
the first V-T curve.  Also try changing the order of the V-T curves in the 
model, to force it to use the R_fixture=70 ohm curve.
 
Regards,
Andy

- ----- Original Message ----- 
From: [email-masked] 
To: [email-masked] 
Sent: Thursday, June 26, 2003 05:43 AM
Subject: [IBIS-Users] damped oscillations in V-T curve

Hello, 

In my V-T curve I see a damped oscillation in the falling waveform (diff 
PECL). 
When I do a HSPICE simulation with different load resistances  I observe 
that the amplitude of the first peak increases dramatically while this is 
not the case in a simulation of the original buffer in Spectre. 
What should I do to model this behaviour correctly. And what causes this 
increase in amplitude? 

With kind regards, 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334

- --=_alternative 0030B8ACC1256D55_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Hello Andrew,</font>
<br>
<br><font size=2 face="sans-serif">The oscillation/ringing is damped such &nbsp;that the next peaks become negligible. I cannot image that these calculations are a problem for Spectre. HSPICE has the possiblity to use 2 waveforms instead of one. But I get a warning that it only uses one waveform, probably because it is not needed for ECL according to the IBIS specification.</font>
<br><font size=2 face="sans-serif">Do you have any idea how to deal with oscillations/ringing in general and how simulators deal with it? </font>
<br>
<br><font size=2 face="sans-serif">With kind regards,</font>
<br><font size=2 face="sans-serif">Erik.</font>
<br>
<br><font size=2 face="sans-serif"><br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>&quot;Ingraham, Andrew&quot; &lt;[email-masked]&gt;</b></font>
<p><font size=1 face="sans-serif">Sent by: </font>
<br><font size=1 face="sans-serif">[email-masked]</font>
<p><font size=1 face="sans-serif">06/27/03 05:53 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;(bcc: Erik van der Ven/NYM/SC/PHILIPS)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: [IBIS-Users] damped oscillations in V-T curve</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 face="Times New Roman">I don't know if this has any bearing on this particular issue, but ...</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 face="Times New Roman">You noted that the discrepancy was with the first peak, implying that the damped oscillations that followed it were not that bad. &nbsp;This implies a nonlinear effect.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 face="Times New Roman">It should also be noted that PECL outputs are very nonlinear, and this is most evident on falling edges.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 face="Times New Roman">I wonder how well Spectre handles that much nonlinearity.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 face="Times New Roman">Likewise, it might also be that IBIS models, or the HSPICE implementation of IBIS models, do not function all that well when there is that much nonlinearity.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 face="Times New Roman">Check to see whether HSPICE has an option to make it use more than just the first V-T curve. &nbsp;Also try changing the order of the V-T curves in the model, to force it to use the R_fixture=70 ohm curve.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 face="Times New Roman">Regards,</font>
<br><font size=2 face="Times New Roman">Andy</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=3 face="Times New Roman">----- Original Message ----- </font>
<br><font size=3 face="Times New Roman"><b>From:</b> </font><a href=mailto:[email-masked]><font size=3 color=blue face="Times New Roman"><u>[email-masked]</u></font></a><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman"><b>To:</b> </font><a href="mailto:[email-masked]"><font size=3 color=blue face="Times New Roman"><u>[email-masked]</u></font></a><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman"><b>Sent:</b> Thursday, June 26, 2003 05:43 AM</font>
<br><font size=3 face="Times New Roman"><b>Subject:</b> [IBIS-Users] damped oscillations in V-T curve</font>
<br>
<br><font size=2 face="sans-serif"><br>
Hello,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
In my V-T curve I see a damped oscillation in the falling waveform (diff PECL).</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
When I do a HSPICE simulation with different load resistances &nbsp;I observe that the amplitude of the first peak increases dramatically while this is not the case in a simulation of the original buffer in Spectre.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
What should I do to model this behaviour correctly. And what causes this increase in amplitude?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
With kind regards,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
<br>
<br>
- --=_alternative 0030B8ACC1256D55_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Mon, 30 Jun 2003 09:26:26 -0400
From: "Lauzums, Andris" <[email-masked]>
Subject: [IBIS-Users] IBIS Functionality Question

Hello-

I had a question concerning pin interfunctionality with the IBIS specification.  I will be characterizing simple analog switches, and I would like to know if there is any way to have specific pins in the IBIS model change their state because of a change in signal on another pin?  For instance, is there a way to "syntax" my model so that when pin A goes logic high, pin B or C would complete a SPST circuit?  Could I then specify it to not complete the circuit if pin A goes logic low?   I have looked at some models online, and I have not been able to find an answer.  I appreciate your help on this matter.

Thank You-

Andris Lauzums
Intersil Corporation
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 1 Jul 2003 09:08:57 -0700
From: "Mirmak, Michael" <[email-masked]>
Subject: [IBIS-Users] IBIS Interconnect Modeling Specification - Request for Feedback

The IBIS Open Forum has completed and is now reviewing a new draft 
document called the IBIS Interconnect Modeling Specification (ICM).  
In brief, the ICM specification permits model authors to represent a 
wide variety of interconnects, including connectors, cables and 
packages, using a regular, ASCII-based, human-readable format.  
Interconnect topologies can be described using implicit (tree) or 
explicit (nodal) connections, and conductor swathing is supported.  
Coupling can be represented through RLGC matrices or S-parameter data 
in Touchstone(R) format. 

This new specification is a significant improvement on the current 
IBIS EBD and PKG formats.  In order to help make it as useful as 
possible to the industry, the IBIS Open Forum requests your input.  
Please take a moment to review the draft specification, available 
at the following location:

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

Comments may be sent to the IBIS reflector, to me or to any IBIS 
Open Forum officer.  Your feedback is important!  The Open Forum 
intends to vote on approving or disapproving the specification on 
or before August 29.

Thank you in advance for your support.

- - Michael Mirmak
  [email-masked]
  Intel Corp. 
  Chair, EIA/IBIS Open Forum

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 1 Jul 2003 12:08:19 -0400
From: "Ingraham, Andrew" <[email-masked]>
Subject: Re: [IBIS-Users] damped oscillations in V-T curve

This is a multi-part message in MIME format.

- ------=_NextPart_000_00FC_01C33FC9.760F5AC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Depending on the internal feedback, feedback could screw up a simulation =
when using an IBIS model, because IBIS does not handle feedback very =
well if at all.  If the feedback just reduces the output impedance or =
establishes a more stable operating point or something similar, then it =
might be OK.  But the positive feedback that is used to make a =
"bus-hold" circuit, for example, is not handled by conventional IBIS =
models at all.

Feedback should not be a problem with a SPICE-like simulator and =
structural (transistor-level) models.

Truncating a waveform table does not sound good.  On the other hand, =
what the simulator does with a waveform table is implementation =
dependent, and I believe that many simulators make little use of them =
... just as a guide for how the simulator should ramp its drivers =
between Low and High states.  (In which case the simulator might ignore =
everything after the waveform first reaches 100% anyway.)  Most of the =
characteristics of the driver come from the I-V curves, and the waveform =
tables are just a second-order tweak in some cases.  But again, I stress =
the "implementation dependent" part.  You might find that your model =
works well with one simulator but horribly with another.

The reason I brought up the nonlinearity, is that (as I recall) Spectre =
is a frequency-domain simulator, and (P)ECL drivers are extremely =
nonlinear at the cutoff point, where they abruptly go from ~5 ohm drive =
strength to open-circuit, in a matter of millivolts.  Representing such =
behavior with reasonable accuracy might require a very large number of =
harmonics, or else you could get ringing as an artifact.

Regards,
Andy

- ------=_NextPart_000_00FC_01C33FC9.760F5AC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Depending on the internal feedback,&nbsp;feedback =
could screw=20
up a simulation&nbsp;when using an IBIS model, because IBIS does =
not&nbsp;handle=20
feedback very well if at all.&nbsp; If the feedback just reduces the =
output=20
impedance or establishes a more stable operating point or something =
similar,=20
then it&nbsp;might be OK.&nbsp; But the&nbsp;positive feedback that is=20
used&nbsp;to make a "bus-hold" circuit, for example, is not handled=20
by&nbsp;conventional IBIS models at all.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Feedback should not be a problem with a SPICE-like =
simulator=20
and structural (transistor-level) models.</FONT></DIV>
<DIV><FONT size=3D2>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV><FONT size=3D2>Truncating a waveform table does not sound =
good.&nbsp; On the=20
other hand, what the simulator does with&nbsp;a waveform table is =
implementation=20
dependent, and I believe that many simulators make&nbsp;little use of =
them ...=20
just as a guide for how the simulator should ramp its drivers between =
Low and=20
High states.&nbsp; (In which case the simulator might ignore everything =
after=20
the waveform first reaches 100% anyway.)&nbsp; </FONT><FONT =
size=3D2>Most of the=20
characteristics of the driver come from the I-V curves, and the waveform =
tables=20
are just a second-order tweak in some cases.&nbsp; But again, I stress =
the=20
"implementation dependent" part.&nbsp; You might find that your model =
works well=20
with&nbsp;one simulator but horribly with another.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>The reason I brought up the nonlinearity, is that =
(as I=20
recall) Spectre is a frequency-domain simulator, and (P)ECL drivers are=20
extremely nonlinear at the cutoff point, where they abruptly go from ~5 =
ohm=20
drive strength to open-circuit, in a matter of millivolts.&nbsp; =
Representing=20
such behavior with reasonable accuracy might require a very large number =
of=20
harmonics, or else you could get ringing as an artifact.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2>Andy</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <P></P></BLOCKQUOTE></BODY></HTML>

- ------=_NextPart_000_00FC_01C33FC9.760F5AC0--

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 1 Jul 2003 13:22:28 -0600
From: [email-masked]
Subject: [IBIS-Users] [IBIS] IBIS Summit minutes (06/23/03)

- ----------------------------------------------------------------------------
DATE: 7/1/02

SUBJECT: June 23, 2003 EIA IBIS Summit Meeting Minutes

VOTING MEMBERS AND 2003 PARTICIPANTS LIST:
Ansoft Corporation             (Eric Bracken)
Apple Computer                 Kim Helliwell
Applied Simulation Technology  Fred Balistreri
Cadence Design                 Lynne Green*, Lance Wang*
Cisco Systems                  Syed Huq, Michael LaBonte*,
                               Val Mandruson, Hung Pham, 
                               Todd Westerhoff*                               
Fairchild Semiconductor        (Graham Connolly)
Hitachi ULSI Systems           Kazuyoshi Shoji*
Intel Corporation              Stephen Peters*, Michael Mirmak*,
                               Arpad Muranyi*, Eric Magnusson
LSI Logic                      Frank Gasparik
Matsushita (Panasonic)         Atsuji Ito
Mentor Graphics                [Bob Ross], Ian Dodd*, Guy de Burgh,
                               John Angulo, Weston Beal, Mike Donnelly,  
Micron Technology              Randy Wolff
Molex Incorporated             Gus Panella
Motorola                       (Rick Kingen)
National Semiconductor         [Milt Schwartz], [Tim Coyle]
NEC Electric Corporation       (Itsuki Yamada)
Philips Semiconductor          (D.C. Sessions), Stephanie Goedecke
Siemens (& Automotive) AG      Eckhard Lenski, Michael Kindij, 
                               Burkhard Muller, Katja Koller, 
                               Andre Goerisch, Manfred Maurer, 
                               Bernard Unger, Amir Motamedi, 
                               Hartmut Ibowski, Gerald Bannert
Signal Integrity Software      Bob Haller*, Barry Katz*, Doug Burns
Sigrity                        [Raj Raghuram]
Synopsys                       Warren Wong, Edmund Cheng
Texas Instruments              Thomas Fisher
Teraspeed                      Scott McMorrow*, Tom Dagostino*,
                               Kevin Simpson, Bob Ross*
Time Domain Analysis Systems   Dima Smolyansky, Steve Corey
Zuken (& Incases)              Michael Schaeder, Ralf Bruening

OTHER PARTICIPANTS IN 2003:
Agilent Technologies           Herbert Lage
Brocade                        Frank Yuan, Yongrue Yu
Conexant                       Gary Felker
EADS CCR                       Alix de la Villeguerin
EFM                            Ekkehard Miersch
EMC Corporation                Brian Arsenault*, John Fernandez*,
                               Simba Julian* 
Fraunhofer IZM                 Ege Engin
Fujitsu                        Tadashi Arai
GEIA                           (Chris Denham)
Huawei Technologies            (Jiang Xiang Zhong)
Independent                    Kelly Green, Luca Giacotto
Infineon Tech AG               Christian Sporrer
Marvell Semiconductor          Itzik Peleg
NetLogic Microsystems          Eric Hsu
North East Systems Associates  Edward Sayre 
Plexus                         Joseph Socha
Politechnico de Torino         Igor Stievano
Qlogic                         Larry Barnes
Sintecs BV                     Hans Klos, Bob te Nijenhuis
SiQual                         (Rob Hinz)
Sun Microsystems               Tim Coyle*
Via Technologies               (Weber Chuang)
Xilinx                         Susan Wu

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

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

  Date                Bridge Number    Reservation #    Passcode
  July 18, 2003       (916) 356-2663        2           381-4012          

All meetings are 8:00 AM to 9:55 AM Pacific Time.  We try to have agendas
out 7 days before each Open Forum, and meeting minutes out within 7 days
after.  When you call into the meeting, ask for the IBIS Open Forum hosted
by Michael Mirmak and give the reservation number and passcode.

NOTE: "AR" = Action Required.

- -------------------------------- MINUTES -----------------------------------

INTRODUCTIONS AND MEETING QUORUM
The IBIS Summit Meeting was held in Marlborough, Massachusetts at the
Western Royal Plaza Hotel in conjunction with the DesignCon East Conference
(DesignCon East 2003).  The summit was co-sponsored by IBIS and Signal
Integrity Software (SiSoft).  About 18 people representing 9 organizations
attended, including 5 people who attended via teleconference.

The notes below capture some of the content and discussions.  The meeting
presentations and other documents are uploaded at:

  http://www.eda.org/pub/ibis/summits/jun03b/

Michael Mirmak opened the meeting and asked everyone in the room and on the
teleconference bridge to introduce themselves.  The group was 
well-attended by semiconductor vendors and model providers, EDA tool 
vendors and users of IBIS models.  Michael thanked Signal Integrity 
Software (SiSoft) for their logistical support on-site.  Finally, Michael 
thanked the presenters and participants for attending.

Michael asked if there were any new issues or discussion items to put on
the agenda.  No issues were raised.

PRESENTATIONS AND DISCUSSION TOPICS
The rest of the meeting consisted of presentations and discussions.  These
notes capture some of the content and discussion.  More details are 
available in the documents uploaded to the location noted above.

STATE OF IBIS REPORT
Michael Mirmak, Intel Corporation
Michael opened the presentations with a summary of the summit agenda,
a look back at the previous year, and a look ahead at the coming years'
challenges.  Michael noted that IBIS 3.2 is truly an international
standard, as evidenced by European and Japanese interest, and that,
despite the weak economy, the IBIS Open forum membership remained constant
at 25 paid members.  The organization remains financially healthy.

Significant events this year included the passage of IBIS 4.0, the adoption
of multi-lingual modeling, and the introduction of the Interconnect
Modeling (ICM) specification for review by the forum.  The biggest 
challenges for the coming year include enabling the future roadmap by 
passing IBIS 4.1 and adopting the ICM Specification. In addition, 
Michael described the need for an updated IBIS cookbook and for providing 
AMS modeling guidance to the industry.  The IBIS Open Forum must also 
continue to work to improve model quality.  Michael would also like to
continue to track European EMC/EMI developments and determine the need
for XML-based parsers.  Finally, Michael offered his thanks to outgoing
Chair Stephen Peters, the officers and other members of the organization 
for their support and help during the past year.

IBIS QUALITY COMMITTEE UPDATE
Kim Helliwell, Apple Computer and Barry Katz, Signal Integrity Software
(SiSoft)
Barry began his presentation by noting that, as cycle times decrease and 
edge rates increase, quality models are becoming more important.  On recent
accomplishments, the committee has completed review of seven of the 10
quality document sections. In addition, BUG 71 dealing with non-monotonic
error due to individual I-V table checking has been passed.  Barry noted 
that this was the most common warning from the parser, and with the parser 
now checking summed tables this warning will now have meaning.

Barry reviewed the IBIS quality levels, noting that for a model to be valid
at a level then it must have passed all previous levels.  

Regarding future items, Barry noted that there are 3 documents left to 
review (Vt curves and ramps, model correlation, and possible errors).  
Lynne Green will be compiling the sections into the final documentation. 
All documents will be correlated to the Quality Spreadsheet, forming a 
complete data set that developers and users can use for guidance in creation
and evaluation of models.  The final step after the documents are compiled 
and the checklist updated is to present the entire set to the Open Forum for
approval.  In response to a question, Barry mentioned that the committee 
plans to have this effort completed for review in time for the IBIS East 
summit meeting in October, 2003.  

Finally, Barry mentioned that the committee is interested in feedback on the 
document, even on the chapters that have not been completed.

For additional information on the quality committee and to be included on
the mailing list send mail to [email-masked].  The IBIS quality
committee web site is available on the IBIS web page or at

  http://www.sisoft.com/ibis-quality

IBIS INTERCONNECT MODELING SPECIFICATION (ICM) STATUS
Michael Mirmak, Intel Corp
Michael stated that the purpose of the IBIS Interconnect Modeling 
Specification (ICM specification) is to establish a human-readable
standard format for exchanging interconnect modeling data.  At a high 
level, the specification uses a two part format.  The first part describes 
the model in terms of a 'section', with sections either joined in a tree 
arrangement according to implicit connections or in a nodal arrangement 
with explicitly described nodes.  The second part of an ICM file supplies 
the electrical data for each section.  Electrical data is in the form of 
either RLGC matrices or S-parameters.

Michael noted that since September, 2002 over 63 issues have been formally
logged.  Most were editorial changes, but there were also some technical
limitations and clarifications added.  RLGC and S-parameter sections are
not permitted within the same model.  S-parameter data is only to be used 
with the [Nodal Path Description] keyword. 

Michael noted that the draft 1.0 specification was officially introduced at 
the May 30, 2003 meeting and a parser is in development.  Michael asked for
example models from the summit participants.

Some technical advancements have been proposed for future revisions.
One suggestion would permit mixing RLGC and S-parameter data within a 
single model description.  Requests have also been made to include support 
for frequency dependent RLGC matrices.  Enhancements and BUGS will be 
handled by a process similar to the existing BIRD process for the IBIS 
specification.  For the longer term, suggestions have been made that 
explicit links between IBIS and ICM be made in one or both specifications.
At present, tools are implicitly assumed to handle the use of ICM models as 
package data for IBIS models.  A larger issue involves Touchstone(R) 
support for mixed-mode S-parameters. At present, Touchstone(R) is 
understood to support only standard single-ended S11, S12, etc. 
S-parameters.  While the format can be used to distribute mixed-mode data 
(SDD12, SCD22, etc.), the specification includes no guidance for users or 
tools for interpreting the placement of the data points in a standard way.  
Feedback from participants, including Scott McMorrow, suggested that
single-ended data was more than adequate for complete modeling of 
interconnects.  Finally, Michael mentioned that to best support and 
encourage ICM usage, a cookbook is needed.

A VHDL-AMS BUFFER MODEL USING IBIS V3.2 DATA
Arpad Muranyi, Intel Corp. and Luca Giacotto, Université Joseph Fourier
Arpad stated that the motivation for the presentation was to develop
algorithms for simulating a basic I/O buffer model IBIS description 
using VHDL-AMS.  Source code for this effort will be made freely available 
to anyone interested. Arpad noted that his presentation was not 
intended as a tutorial on the VHDL-AMS language.

Arpad first presented a standard IBIS I/O model with four IV curves
(pullup, pulldown, clamps) and Vt tables that describe switching.
Arpad then introduced the classic equations which define the Vt and
IV curve relationship, where the IV curves scale the Vt curves through
coefficients called K factors (here, Kpu and Kpd for the pullup and
pulldown factors, respectively).  Arpad noted that Kpu and Kpd are assumed 
to be identical which may not be accurate in all cases.

Arpad then went on to show the equations as implemented in VHDL-AMS code, 
where the two equations are solved to find the value of K.  The equations 
are placed into a for loop, and K is resolved for each point on the pullup 
or pulldown curve.  Arpad noted that the K values are calculated and stored 
from the model data when the simulator is initialized, not at run time.

Arpad showed results comparing HSPICE B-element and AMS implementation 
results to data from the source transistor model.  In general, the B-element 
and AMS curves matched closely, but were not identical. Then he presented a 
slightly different version of the code with separate structures defining the 
pullup, pulldown and clamp behaviors.  The top-level code contained only the 
concurrent statements of the digital logic and transistors.

Arpad then went on to explain how to solve an existing problem first noted
when creating models for DDR memory interfaces.  These models connect
their terminations to VCC/2 when used, but the model is extracted with 
fixture voltages of VCC and GND.  The best approach to using this data
in these cases is that, while some simulators can only use two Vt tables 
at a time, different sets of Vt tables may be used at different times or 
depending on the model's initial conditions.  Arpad described a four-curve
data set, with fixture voltages set to 0, 1/3*Vcc, 2/3*Vcc and Vcc.  With 
this set of waveforms, the AMS implementation overlays transistor level 
model results across the entire run time.  Arpad noted that this approach 
still assumes that all Vt tables have the same R_fixture, which generally 
matches the target system impedance.

Arpad's files are available on the IBIS web site.

IBIS MODELS AT 1.25 GHZ AND BEYOND
Bob Haller, Barry Katz, Kevin Fisher, Signal Integrity Software (SiSoft)
Bob began by summarizing high speed design challenges that face signal 
integrity engineers today. They include, but are not limited to, 
interconnect (etch, packages and connectors), return paths, and high speed 
links. A frequently asked question is, "can IBIS be utilized?"

The answer is a resounding yes!

Bob reviewed LVDS (Low Voltage Differential Signaling) and some of the 
advantages it provides (high signaling speeds, lower voltage swing, less 
power consumption, less susceptibility to noise and reduced EMI.

Bob then reviewed challenges creating IBIS models at 1.25 GHz and beyond. 
IBIS was originally designed to be single-ended and IV curves show current 
as a function of voltage on a single pad.  In contrast, the current of an 
LVDS buffer is dependent on voltage at both pads and the common mode 
voltage.

Bob walked through the process he uses to extract and generate LVDS IBIS 
models and cautioned that models are generated under specific operating, 
termination, and topology conditions. Often times these models are only 
accurate under the same conditions as the data was taken.  He presented 
waveforms demonstrating excellent correlation between HSPICE and the IBIS 
model created and summarized the issues a model maker or user may 
encounter. He demonstrated this by showing the effect I/O voltage (VDDQ) 
has on the IBIS model.

There was a discussion of modeling on-die termination that was tabled until
later in the day, when on-die termination was going to be addressed.

Finally, Bob reiterated that we can generate models for 1.25 GHz and
beyond, but it takes significant effort and attention to detail. Improper 
use of, or improper building of models can and will lead to inaccurate 
results.

IBIS 4.1 STATUS AND UPDATE
Lynne Green, Cadence Design Systems
Lynne began her presentation by noting that IBIS 4.0 was approved in July,
2002 and a parser is expected in the third quarter of 2003.  IBIS 4.1 will
include five additional BIRDs, including the major addition of multi-lingual
modeling support.  Lynne also noted that there is one outstanding BIRD
that will probably not be included in IBIS 4.1.

The remaining BIRDS to be included in IBIS 4.1 address several different
issues.  Improved support for differential buffers is addressed through
BIRD 77.  BIRD 80 added ext_ref as a new [Pin Mapping] column, helping to
drive adoption of BIRD 78 to extend the line length limit to 120 characters.  
Finally, BIRD 81 clarifies [Series Pin Mapping] and series model usage.

The next step in IBIS specification development is presentation of
the draft version of IBIS 4.1 to the Open Forum for an approval vote.  
Once the specification is approved, a parser is written and any issues 
which arise from parser development are folded into IBIS
4.2 (which may include an EMC specification as defined by BIRD 74).  
When the IBIS 4.2 parser is stable, the specification will be presented 
to ANSI/EIA for approval through a formal letter ballot. 

IBIS ALGORITHMS REVISITED
Bob Ross, Teraspeed Consulting Group
Bob stated that his slides were part of a larger presentation given
at the IEEE SPI Conference in Siena, Italy earlier this year.  Bob noted
that, early on, IBIS tools settled on a data-processing algorithm 
involving two waveforms, but there are other algorithms possible.  These
include using multiple tables with dynamic interpolation and modeling the 
transistors themselves as was done for the Japanese IMIC specification.  
Recently, radial base functions have also been considered.

Bob first explained a very simple algorithm using only ramp data and
assuming a 5 volt linear device driving into a 50 ohm resistive load.
Additional variations, including Norton and Thevenin linear transitions
plus table multipliers, were addressed along with a comparison to actual 
waveforms.  Bob showed how two waveforms were required to get independent 
K values for IBIS pullup and pulldown data.

More advanced simulation techniques must handle generalized loading cases, 
rather than loads which are purely resistive.  Bob used a SPICE netlist to 
address the problem, incorporating two models in a feedback loop of an 
operational amplifier, where the amplifier itself drove the scaling or K 
table values.  The input of the amplifier, being connected to the output 
node, would then converge on an appropriate solution for the load used.

Finally, Bob addressed overclocking IBIS buffers, where IBIS models are
driven in simulation over shorter periods than allowed by the length
of the Vt waveforms.  Unfortunately, no immediate solution to this
problem is currently available.  

AN ALGORITHM TO MODEL OVER-CLOCKING MORE ACCURATELY
Arpad Muranyi, Intel Corp.
In addition to his scheduled presentations, Arpad provided an ad-hoc
set of slides addressing the driver overclocking problem.  Using several
image overlays, Arpad demonstrated that overclocked buffers show a 
relatively constant delay between pulldown turning off and pullup
turning on, and vice-versa.  Arpad proposed that this delay could be
characterized and included with other IBIS data as a parameter. 

MODELING ON-DIE TERMINATIONS IN IBIS (WITHOUT DOUBLE COUNTING)
Arpad Muranyi, Intel Corp.
Arpad began his presentation by noting some of the more advanced
design features now commonly available, including dynamic clamps,
staged buffers, kicker circuits and the like.  While many of these
features may be difficult to model without intimate knowledge of the
buffer design, a general rule of thumb is that any design aspect 
which is static should be represented through the IBIS clamp tables.  
Users and model makers observing this rule for terminations should 
be careful to use the appropriate rail for correct power and ground 
bounce simulations.  Most especially, double counting of these 
termination features should be avoided whenever possible.

Arpad classified the types of termination as series, parallel or 
switched parallel.  Series termination does not require any special 
analysis for inclusion in IBIS as it will naturally be included in
the IV curve shapes.  Parallel termination behaviors should be placed 
in clamp tables by sweeping the voltage on the pad from -Vcc to
2*Vcc, both using ground referencing and Vcc referencing.  By 
finding the curve which passes through the origin, one can find
the curve set most appropriate in which to include the resistor.  This
curve will be cut at Vcc, while the other will be cut at ground.  The 
curve without the resistor can then be normalized or shifted to pass 
through the IV origin.  Both curves can then be extrapolated to 2*Vcc.

Switch parallel terminations are commonly implemented by leaving either
the pullup or pulldown active when the device receives.  In this case,
normal I/O IV curves may be created and the appropriate pullup or 
pulldown curve may be copied to a [Submodel] and renamed to be a
dynamic, non-driving clamp.  Example IBIS text for this implementation
was provided.

Finally, Arpad addressed the case where both pullup and pulldown 
terminations are present in a design.  The model maker in this case cannot
be sure how to determine the value of each termination separately when 
only the Thevenin equivalent can be observed. Lynne Green and
Bob Ross suggested that analysis of the slopes can be used to
help determine where non-linear resistive termination data can be
included.

ON-DIE TERMINATION COMMENTS
Bob Ross, Teraspeed Consulting Group
Bob commented that he investigated the on-die termination problem with
parallel terminators and composite I-V extraction.  After several false
starts, Bob stated that more information is required.  He illustrated a
case where a straight line I-V table can be modeled as two linear resistors
or as two quadratic resistors.  The second case mimics the situation that
a MOSFET is used.  Bob created a quadratic solution that had 0 slope at
one voltage and a prescribed slope at the other.  The combination produced
a linear I-V table.

Bob concluded that either more constraints are necessary, or preferably,
a separate power or ground current extraction should be used.  Bob had 
attempted deriving a quadratic interpolation algorithm, but the equations 
were not independent.

OTHER DISCUSSIONS AND AD HOC PRESENTATIONS 

Todd Westerhoff added some humor with a closing "IBIS prayer." 
Our Founder, who art in California,
Arpad be thy name.
Thy mastery IBIS,
thy will be modeled,
industry-wide, as it is at Intel.
Give us this day a better spec.
Forgive us our S.W.A.G.'s,
as we forgive those who S.W.A.G. against us.
And lead us not unto error,
but deliver us from non-convergence.
For thine are The Research, The Algorithms and The Standard
forever and ever. AMEN

CONCLUDING ITEMS
Barry Katz thanked the presenters for the great and informative 
presentations.  After reminding the participants regarding the next 
teleconference meeting, Barry closed the IBIS Summit Meeting.

NEXT MEETING:
The next Open Forum meeting will be held on Friday, July 18, 2003 from
8:00 AM to 10:00 AM Pacific time.  

============================================================================

                                      NOTES

IBIS CHAIR: Michael Mirmak (916) 356-4261, Fax: (916) 377-1046
            [email-masked]
            Senior Analog Engineer, Intel Corporation
            M/S FM6-45
            1900 Prairie City Rd.
            Folsom, CA  95630

VICE CHAIR: Lynne Green (425) 788-0412, Fax (425) 451-1871
            [email-masked]
            Senior Modeling Engineer, Cadence Design Systems
            320 120th Ave NE, Suite B-103, Bellevue, WA 98005-3016

SECRETARY:  Randy Wolff (208) 363-1764, Fax: (208) 368-3475
            [email-masked]
            Simulation Engineer, Micron Technology, Inc.
            8000 S. Federal Way
            Mail Stop: 1-711
            Boise, ID 83707-0006
        
LIBRARIAN:  Roy Leventhal (847) 590-9398
            [email-masked]
            Consultant, Leventhal Design and Communications
            1924 North Burke Drive
            Arlington Heights, Illinois 60004

WEBMASTER:  Syed Huq (408) 525-3399, Fax: (408) 526-5504
            [email-masked]
            Manager, Hardware Engineering, Cisco Systems
            170 West Tasman Drive
            San Jose, CA 95134-1706

POSTMASTER: John Angulo (425) 497-5077, Fax: (425) 881-1008
            [email-masked]
            Development Engineer, Mentor Graphics
            14715 N.E. 95th Street, Suite 200
            Redmond, WA 98052

This meeting was conducted in accordance with the EIA Legal Guides and EIA
Manual of Organization and Procedure.

The following e-mail addresses are used:

  [email-masked]
      In the body, for the IBIS Open Forum Reflector:
      subscribe ibis <your e-mail address>

      In the body, for the IBIS Users' Group Reflector:
      subscribe ibis-users <your e-mail address>

      Help and other commands:
      help

  [email-masked]
      To join, change, or drop from either the IBIS Open Forum Reflector
      ([email-masked]), the IBIS Users' Group Reflector ([email-masked])
      or both.  State your request.

  [email-masked]
      To obtain general information about IBIS, to ask specific questions
      for individual response, and to inquire about joining the EIA-IBIS
      Open Forum as a full Member.

  [email-masked]
      To send a message to the general IBIS Open Forum Reflector.  This
      is used mostly for IBIS Standardization business and future IBIS
      technical enhancements.  Job posting information is not permitted.

  [email-masked]
      To send a message to the IBIS Users' Group Reflector.  This is
      used mostly for IBIS clarification, current modeling issues, and
      general user concerns.  Job posting information is not permitted.

  [email-masked]
      To report ibischk2/3 parser bugs.  The Bug Report Form Resides on
      eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported
      bugs.

      To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms
      which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt,
      /pub/ibis/bugs/s2ibis2/bugs2i2.txt, and
      /pub/ibis/bugs/s2iplt/bugsplt.txt respectively.

Information on IBIS technical contents, IBIS participants, and actual
IBIS models are available on the IBIS Home page found by selecting the
Electronic Information Group under:

  http://www.eigroup.org/ibis/ibis.htm

Check the pub/ibis directory on eda.org for more information on previous
discussions and results.  You can get on via FTP anonymous.

============================================================================
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 1 Jul 2003 13:42:55 -0600
From: [email-masked]
Subject: [IBIS-Users] [IBIS] Open forum minutes (06/27/03)

DATE: 7/1/03

SUBJECT: June 27, 2003 EIA IBIS Summit Meeting Minutes

VOTING MEMBERS AND 2003 PARTICIPANTS LIST:
Ansoft Corporation             (Eric Bracken)
Apple Computer                 Kim Helliwell
Applied Simulation Technology  Fred Balistreri
Cadence Design                 Lynne Green*
Cisco Systems                  Syed Huq, Val Mandruson, Hung Pham 
Fairchild Semiconductor        (Graham Connolly)
Hitachi ULSI Systems           Kazuyoshi Shoji
Intel Corporation              Stephen Peters*, Michael Mirmak*,
                               Arpad Muranyi, Eric Magnusson
LSI Logic                      Frank Gasparik*
Matsushita (Panasonic)         Atsuji Ito
Mentor Graphics                [Bob Ross], Ian Dodd, Guy de Burgh*,
                               John Angulo*, Mike Donnelly, Weston Beal 
Micron Technology              Randy Wolff*
Molex Incorporated             Gus Panella
Motorola                       (Rick Kingen)
National Semiconductor         [Milt Schwartz], [Tim Coyle]
NEC Electric Corporation       (Itsuki Yamada)
Philips Semiconductor          (D.C. Sessions), Stephanie Goedecke
Siemens (& Automotive) AG      Eckhard Lenski, Michael Kindij, 
                               Burkhard Muller, Katja Koller, 
                               Andre Goerisch, Manfred Maurer, 
                               Bernard Unger, Amir Motamedi, 
                               Hartmut Ibowski, Gerald Bannert
Signal Integrity Software      Bob Haller, Barry Katz, Doug Burns
Sigrity                        [Raj Raghuram]
Synopsys                       Warren Wong, Edmund Cheng
Texas Instruments              Thomas Fisher
Teraspeed                      Scott McMorrow, Tom Dagostino,
                               Kevin Simpson, Bob Ross*
Time Domain Analysis Systems   Dima Smolyansky, Steve Corey
Zuken (& Incases)              Michael Schaeder, Ralf Bruening

OTHER PARTICIPANTS IN 2003:
Agilent Technologies           Herbert Lage
Brocade                        Frank Yuan, Yongrue Yu
Conexant                       Gary Felker
EADS CCR                       Alix de la Villeguerin
EFM                            Ekkehard Miersch
EMC Corporation                Brian Arsenault
Fraunhofer IZM                 Ege Engin
Fujitsu                        Tadashi Arai
GEIA                           (Chris Denham)
Huawei Technologies            (Jiang Xiang Zhong)
Independent                    Kelly Green, Luca Giacotto
Infineon Tech AG               Christian Sporrer
Marvell Semiconductor          Itzik Peleg
NetLogic Microsystems          Eric Hsu
North East Systems Associates  Edward Sayre 
Plexus                         Joseph Socha
Politechnico de Torino         Igor Stievano
Qlogic                         Larry Barnes
Sintecs BV                     Hans Klos, Bob te Nijenhuis
SiQual                         (Rob Hinz)
Sun Microsystems               Tim Coyle
Via Technologies               (Weber Chuang)
Xilinx                         Susan Wu

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

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

  Date                Bridge Number    Reservation #    Passcode
  July 18, 2003       1-916-356-2663        2           381-4012

All meetings are 8:00 AM to 9:55 AM Pacific Time.  We try to have agendas 
out 7 days before each Open Forum, and meeting minutes out within 7 days 
after.  When you call into the meeting, ask for the IBIS Open Forum hosted 
by Stephen Peters and give the reservation number and passcode.

NOTE: "AR" = Action Required.

- -------------------------------- MINUTES -----------------------------------
INTRODUCTIONS AND MEETING QUORUM
No new introductions.

CALL FOR PATENTS
Michael Mirmak called for any patents or pending patents related to the 
IBIS Version 4.0 Standard. No companies declared a patent.

MEMBERSHIP UPDATE AND TREASURER'S REPORT
Michael Mirmak reported that based on the May ledger report from GEIA and 
e-mail confirmation of payment the current membership stands at 25 paid 
members.  Michael noted that the "Voting members and 2003 participants list"
at the top of the minutes will be updated to reflect the names of the 
companies that have not paid.  The names of non-member companies that have
not had a representative attend a meeting this year will also be removed.

REVIEW OF MINUTES AND AR'S
The May 30, 2003 minutes were approved without changes.
The June 5, 2003 summit meeting minutes were approved without changes.

ARs will be discussed during the meeting.

MISCELLANY/ANNOUNCEMENTS
Bob Ross noted that NCSU now has a beta version of the SPICE2IBIS3 
application available for testing.  Those interested in trying the beta 
version may address themselves directly to NCSU.

PRESS AND WEB PAGE UPDATES
Michael Mirmak reported that he asked Syed Huq to do an update of the IBIS
roster to reflect the current membership list.  In addition, Syed will
send out a notice to all companies listed on the roster page to submit
updates to the roster.  Non-responding companies will be removed.

NEW MODELS AVAILABLE, LIBRARY UPDATE
No new models or library updates.

OPENS FOR NEW ISSUES
No new issues.

INTERNATIONAL/EXTERNAL PROGRESS
- - IEC 62014-3 (ICEM) Integrated Circuit Electromagnetic Model Proposal
  (formerly, IEC 93/67/NP IBIS and EMC Simulation)
  No report.
- - JEDEC Activity Report. 
  Nothing to report.

DAC2003 SUMMIT REPORT
Michael Mirmak asked for comments on the IBIS summit held at DAC.
Stephen responded that the presentations and discussions were
of high quality and positively received.  He also noted that
the logistics of the room, refreshments and luncheon presented
no difficulties for the organizers or the participants.  John
Angulo observed that he had not yet received any reimbursement
for Mentor's expenses for the summit.  He will arrange for 
billing directly to the GEIA and estimates the total cost to
be between $1500 and $1600.  Lynne Green will check with 
Cadence and similarly arrange for GEIA billing for Cadence's
contribution to the DAC Summit.

DESIGNCON EAST 2003 SUMMIT REPORT
Michael Mirmak asked for comments regarding DesignCon2003.  Bob
observed that IBIS had made good use of the opportunity to have
a real presence at an event not normally part of the IBIS
summit schedule.  He added that the teleconference bridge was 
a positive addition and the extra involvement from those on-line 
was worth the absence of an IBIS booth on the event's display floor.  
In future, the Open Forum will revisit whether both a booth and
a teleconference bridge provide returns on the required time
and monetary investments for summits.  Guy de Burgh requested
that, as he now holds the booth, any request for the booth
to be used at a summit be made to him as far in advance as
possible.  He will make tentative arrangements to bring the
booth to DesignCon 2004.

Michael thanked the participants and organizers from both Summits,
including Cadence, Mentor and SiSoft, for their help in making the
gatherings successful.

DATE SUMMIT DISCUSSION
Lynne Green raised the topic of planning for the DATE 2003 Summit in 
October.  An IBIS Summit is tentatively planned for Tuesday,
October 21, but specific locations and times have not yet been
determined.  Michael Mirmak accepted the action item to contact NESA
regarding hosting and other logistics of a DATE Summit.  Bob Ross suggested 
that, while October summits have traditionally been held on the East 
Coast of the US, the Open Forum should consider potential summit
meeting opportunities overseas, particularly in Japan.  

IBIS VERSION 4.0 PARSER FUNDING AND STATUS
Michael Mirmak reported that we have parser payments from eight companies.  
Unfortunately, one company had to decommit from funding, leaving us one 
short of our goal.  Several officers are working to obtain other sources
for parser finances.

Stephen Peters reported that Atul Agarwal has completed adding version 4.0
features and is in the process of adding the bug fixes.  Atul indicated 
that he will be able to add all bug fixes except BUG68, BUG73 and BUG78. 
Stephen suggested that we review these bugs and figure out how to 
incorporate fixes into the delivered code.  Stephen noted that he expects 
Atul to send a beta copy of the code to the forum by the end of the month.  
The current alpha version of the parser has been compiled for several 
platforms (for Windows by John Angulo, for UNIX/Linux by Lynne Green) and 
checking continues by several members of the Open Forum.

IBIS VERSION 4.1 DISCUSSION
Bob Ross reported that he has posted a cleaned up text version of IBIS
version 4.1 to the web.  In addition, Arpad Muranyi has created a .pdf 
version that is also posted to the web.  Both documents are available at:

  http://www.vhdl.org/pub/ibis/wip/

There are also several minor editorial corrections that will be included.
Stephen Peters will provide a list of suggested improvements to the 
Open Forum via the reflector.  

IBIS QUALITY COMMITTEE
Lynne Green reported that the Quality Committee continues to meet every
two weeks and is working on an updated quality checklist.  Lynne also 
reported that the Quality Committe is preparing a BIRD related to IV 
currents which will be filed for consideration at the next Open Forum 
meeting.

IBIS MODEL REVIEW COMMITTEE
Lynne Green reported that models have been sent to the Committee from 
Lightspeed and Texas Instruments.  These have been distributed to the 
Committee members.  

NEW ADMINISTRATIVE ISSUES
No new issues.

IBIS FUTURES AND CONNECTOR WORKING GROUP REPORT
No meetings have been held since the last Open Forum teleconference.  Bob 
Ross proposed that this committee be disbanded, as its work is complete; 
new committees may be formed to address issues as needed.  Without 
objection, the Open Forum accepted Bob's proposal and the Committee members 
were thanked for their contributions.

IBIS ICM SPECIFICATION REVIEW
Michael Mirmak reported that no feedback on the IBIS Interconnect 
Specification (ICM) had been received, though some comments for 
consideration in the longer term were noted at both summits.  He proposed 
sending a message on behalf of the Open Forum to the IBIS and industry 
e-mail reflectors to request review of the specification and sample models.  
No objections were raised.

BIRD74.4 - EMI Parameters
Guy de Burgh reported that he had received substantial comments on the 
syntax of BIRD 74.4 from Bob Ross and others.  These issues involved 
separating keywords from subparameters and including more details from the 
available documentation from the University of Missouri at Rolla.  
Consequently, Guy requested that any vote on the BIRD be deferred, pending 
his issuing of a corrected BIRD 74.5.  

IBISCHK3 & BUG TRACKING STATUS
John Angulo reported that work is still in progress on BUG73, "Extreme
Non-monotonic I-V Tables Cause End Point Test to Fail."  John continues
testing of the BUG73 example data with the latest beta parser, and will
deliver all results to Atul.  Bob Ross reiterated that the more complete
the analysis of the parser and related bugs by the IBIS community is, the
faster a quality parser will be made available to the industry.

John also reported that he has submitted a BUG to address a potential 
issue with the placement of [Model Selector] relative to [Diff Pin]
within a component.  Having [Model Selector] occur after [Diff Pin] is
accepted by the parser, but [Model Selector] occuring before
[Diff Pin] causes an ambiguous warning.  Bob Ross confirmed that he had 
received the BUG report and raised the possibility of an ambiguity in 
the IBIS specification between the scope of the [Component] keyword
and the ordering of [Diff Pin] and [Model Selector].  Bob also suggested 
that the example IBIS text be shortened to only include the minimum data 
to illustrate the issue and pass the other parser rules.  John agreed to 
resubmit an edited version of the report after checking the exact syntax of 
the specification regarding the scope of the keywords involved.

Michael Mirmak closed the meeting.

NEXT MEETINGS:
The next teleconference meeting is scheduled for July 18, 2003 from 8:00
AM to 10:00 AM Pacific Daylight Time. 

============================================================================
                               NOTES

IBIS CHAIR: Michael Mirmak (916) 356-4261, Fax: (916) 377-1046
            [email-masked]
            Senior Analog Engineer, Intel Corporation
            M/S FM6-45
            1900 Prairie City Rd.
            Folsom, CA  95630

VICE CHAIR: Lynne Green (425) 788-0412, Fax (425) 451-1871
            [email-masked]
            Senior Modeling Engineer, Cadence Design Systems
            320 120th Ave NE, Suite B-103, Bellevue, WA 98005-3016

SECRETARY:  Randy Wolff (208) 363-1764, Fax: (208) 368-3475
            [email-masked]
            Simulation Engineer, Micron Technology, Inc.
            8000 S. Federal Way
            Mail Stop: 1-711
            Boise, ID 83707-0006
        
LIBRARIAN:  Roy Leventhal (847) 590-9398
            [email-masked]
            Consultant, Leventhal Design and Communications
            1924 North Burke Drive
            Arlington Heights, Illinois 60004

WEBMASTER:  Syed Huq (408) 525-3399, Fax: (408) 526-5504
            [email-masked]
            Manager, Hardware Engineering, Cisco Systems
            170 West Tasman Drive
            San Jose, CA 95134-1706

POSTMASTER: John Angulo (425) 497-5077, Fax: (425) 881-1008
            [email-masked]
            Development Engineer, Mentor Graphics
            14715 N.E. 95th Street, Suite 200
            Redmond, WA 98052

This meeting was conducted in accordance with the EIA Legal Guides and EIA 
Manual of Organization and Procedure.

The following e-mail addresses are used:

  [email-masked]
      In the body, for the IBIS Open Forum Reflector:
      subscribe ibis <your e-mail address>

      In the body, for the IBIS Users' Group Reflector:
      subscribe ibis-users <your e-mail address>

      Help and other commands:
      help

  [email-masked]
      To join, change, or drop from either the IBIS Open Forum Reflector
      ([email-masked]), the IBIS Users' Group Reflector ([email-masked])
      or both.  State your request.

  [email-masked]
      To obtain general information about IBIS, to ask specific questions
      for individual response, and to inquire about joining the EIA-IBIS
      Open Forum as a full Member.

  [email-masked]
      To send a message to the general IBIS Open Forum Reflector.  This
      is used mostly for IBIS Standardization business and future IBIS
      technical enhancements.  Job posting information is not permitted.

  [email-masked]
      To send a message to the IBIS Users' Group Reflector.  This is
      used mostly for IBIS clarification, current modeling issues, and
      general user concerns.  Job posting information is not permitted.

  [email-masked]
      To report ibischk2/3 parser bugs.  The Bug Report Form Resides on
      eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported
      bugs.

      To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms
      which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt,
      /pub/ibis/bugs/s2ibis2/bugs2i2.txt, and
      /pub/ibis/bugs/s2iplt/bugsplt.txt respectively.

Information on IBIS technical contents, IBIS participants, and actual IBIS 
models are available on the IBIS Home page found by selecting the Electronic 
Information Group under:

  http://www.eigroup.org/ibis/ibis.htm

Check the pub/ibis directory on eda.org for more information on previous 
discussions and results.  You can get on via FTP anonymous.

============================================================================
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Wed, 2 Jul 2003 11:17:17 -0700
From: "Anuj Chakrapani" <[email-masked]>
Subject: [IBIS-Users] Temperature range for creating IBIS models

Hi:
I would like to know about the temperature range over which IBIS models are
generated. Do we generate the I-V tables over the ambient temperature range
(range specified in datasheets) or the junction temperature range (die
temperature). Since the two temperature ranges are different, I would
appreciate inputs from IBIS developers as well as from IBIS users, on what
their preference is.

Thanks,
- -Anuj.

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 3 Jul 2003 09:49:16 +0200
From: [email-masked]
Subject: Re: [IBIS-Users] Temperature range for creating IBIS models

This is a multipart message in MIME format.
- --=_alternative 002B2ACDC1256D58_=
Content-Type: text/plain; charset="us-ascii"

Hello Anuj,

I think you should use the junction temperature, since this is the 
temperature that is relevant for the behaviour of your IC-circuitry. 

With kind regards,
Erik. (IBIS-developer)

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334

"Anuj Chakrapani" <[email-masked]>
Sent by: 
[email-masked]
07/02/03 08:17 PM

        To:     <[email-masked]>
        cc:     (bcc: Erik van der Ven/NYM/SC/PHILIPS)
        Subject:        [IBIS-Users] Temperature range for creating IBIS models
        Classification: 

Hi:
I would like to know about the temperature range over which IBIS models 
are
generated. Do we generate the I-V tables over the ambient temperature 
range
(range specified in datasheets) or the junction temperature range (die
temperature). Since the two temperature ranges are different, I would
appreciate inputs from IBIS developers as well as from IBIS users, on what
their preference is.

Thanks,
- -Anuj.

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

- --=_alternative 002B2ACDC1256D58_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Hello Anuj,</font>
<br>
<br><font size=2 face="sans-serif">I think you should use the junction temperature, since this is the temperature that is relevant for the behaviour of your IC-circuitry. </font>
<br>
<br><font size=2 face="sans-serif">With kind regards,</font>
<br><font size=2 face="sans-serif">Erik. (IBIS-developer)</font>
<br><font size=2 face="sans-serif"><br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>&quot;Anuj Chakrapani&quot; &lt;[email-masked]&gt;</b></font>
<p><font size=1 face="sans-serif">Sent by: </font>
<br><font size=1 face="sans-serif">[email-masked]</font>
<p><font size=1 face="sans-serif">07/02/03 08:17 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;(bcc: Erik van der Ven/NYM/SC/PHILIPS)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[IBIS-Users] Temperature range for creating IBIS models</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New">Hi:<br>
I would like to know about the temperature range over which IBIS models are<br>
generated. Do we generate the I-V tables over the ambient temperature range<br>
(range specified in datasheets) or the junction temperature range (die<br>
temperature). Since the two temperature ranges are different, I would<br>
appreciate inputs from IBIS developers as well as from IBIS users, on what<br>
their preference is.<br>
<br>
Thanks,<br>
- -Anuj.<br>
<br>
|------------------------------------------------------------------<br>
|For help or to subscribe/unsubscribe, email [email-masked]<br>
|with just the appropriate command message(s) in the body:<br>
|<br>
| &nbsp;help<br>
| &nbsp;subscribe &nbsp; ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;subscribe &nbsp; ibis-users &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis-users &lt;optional e-mail address, if different&gt;<br>
|<br>
|or email a written request to [email-masked].<br>
|<br>
|IBIS reflector archives exist under:<br>
|<br>
| &nbsp;http://www.eda.org/pub/ibis/email_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/users_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/email/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;E-mail since 1993<br>
<br>
</font>
<br>
<br>
- --=_alternative 002B2ACDC1256D58_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 08 Jul 2003 09:18:38 +0530
From: "ramesh reddy" <[email-masked]>
Subject: [IBIS-Users] Inclusion of RLGC package info in IBIS

<html><div style='background-color:'><DIV><FONT size=2>
<P>Hello all,</P>
<P>I have to include package data which is in the RLGC matrix format (derived from Hspice) in IBIS files. There are different sets of matrices specified for the different sections like breakout2, via and the transmission line as shown below. Also the length parameter is given for package trace. </P>
<P>Seg 1(Break&nbsp;out&nbsp;)&nbsp;&nbsp;&nbsp; Seg 2(Short trace)&nbsp;&nbsp;&nbsp;&nbsp; Seg 3(Via)&nbsp;&nbsp;&nbsp;&nbsp; Seg 4&nbsp;(Package long trace)&nbsp;&nbsp;Seg 5(Via and Solderball)</P>
<P></P>
<P>My problem is :</P>
<P>1&gt; The package model section of the IBIS file does not provide an option to include RLGC matrices for multiple sections.</P>
<P>2&gt; Also there is no keyword to specify the length for the traces when the "model data" option is used. This option is provided only when "Number of sections" is used. But since "Number of sections" and "model data" option is mutually exclusive I cannot use this.</P>
<P>Hence how do I go about including multiple sets of matrices in the IBIS file?</P>
<P>Looking forward for your reply.</P>
<P>Thanks,</P>
<P>Granthana</P>
<P>Force Computers (India)Pvt Ltd</P>
<P>Ph: +91-80-5356060 Ext 253</P>
<P>Fax: +91-80-5354025</P>
<P>E-mail: [email-masked]</P>
<P></FONT><BR><BR></P></DIV></div><br clear=all><hr>Reconnect with old pals. Relive the happy times. <a href="http://g.msn.com/8HMGENIN/2737??PS=">With just one click.</a> </html>
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 08 Jul 2003 09:18:38 +0530
From: "ramesh reddy" <[email-masked]>
Subject: [IBIS-Users] Inclusion of RLGC package info in IBIS

<html><div style='background-color:'><DIV><FONT size=2>
<P>Hello all,</P>
<P>I have to include package data which is in the RLGC matrix format (derived from Hspice) in IBIS files. There are different sets of matrices specified for the different sections like breakout2, via and the transmission line as shown below. Also the length parameter is given for package trace. </P>
<P>Seg 1(Break&nbsp;out&nbsp;)&nbsp;&nbsp;&nbsp; Seg 2(Short trace)&nbsp;&nbsp;&nbsp;&nbsp; Seg 3(Via)&nbsp;&nbsp;&nbsp;&nbsp; Seg 4&nbsp;(Package long trace)&nbsp;&nbsp;Seg 5(Via and Solderball)</P>
<P></P>
<P>My problem is :</P>
<P>1&gt; The package model section of the IBIS file does not provide an option to include RLGC matrices for multiple sections.</P>
<P>2&gt; Also there is no keyword to specify the length for the traces when the "model data" option is used. This option is provided only when "Number of sections" is used. But since "Number of sections" and "model data" option is mutually exclusive I cannot use this.</P>
<P>Hence how do I go about including multiple sets of matrices in the IBIS file?</P>
<P>Looking forward for your reply.</P>
<P>Thanks,</P>
<P>Granthana</P>
<P>Force Computers (India)Pvt Ltd</P>
<P>Ph: +91-80-5356060 Ext 253</P>
<P>Fax: +91-80-5354025</P>
<P>E-mail: [email-masked]</P>
<P></FONT><BR><BR></P></DIV></div><br clear=all><hr>Reconnect with old pals. Relive the happy times. <a href="http://g.msn.com/8HMGENIN/2737??PS=">With just one click.</a> </html>
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 08 Jul 2003 08:53:52 -0700
From: Lieby David <[email-masked]>
Subject: Re: [IBIS-Users] IBIS Interconnect Modeling Specification - Request for Feedback

Hi,

I have one comment about the draft.  Under
Keyword: [Begin ICM Model],
Usage Rules:

'The name must be one of the model names listed under
the "model name" column of the preceding [ICM Model List]
keyword.'

If the specification allowed for additional models, not
included in the model name column, it would allow for
configuration of different connectors using the same
body of models.  I presently use IBIS models for FPGA
designs where all the possible models for the chip are
included and use the Pin Mapping section.  It may be a
minor usage but the flexibility may be nice to have.

dav0

Mirmak, Michael wrote:
> The IBIS Open Forum has completed and is now reviewing a new draft 
> document called the IBIS Interconnect Modeling Specification (ICM).  
> In brief, the ICM specification permits model authors to represent a 
> wide variety of interconnects, including connectors, cables and 
> packages, using a regular, ASCII-based, human-readable format.  
> Interconnect topologies can be described using implicit (tree) or 
> explicit (nodal) connections, and conductor swathing is supported.  
> Coupling can be represented through RLGC matrices or S-parameter data 
> in Touchstone(R) format. 
> 
> This new specification is a significant improvement on the current 
> IBIS EBD and PKG formats.  In order to help make it as useful as 
> possible to the industry, the IBIS Open Forum requests your input.  
> Please take a moment to review the draft specification, available 
> at the following location:
> 
> http://www.eda.org/pub/ibis/connector/
> 
> Comments may be sent to the IBIS reflector, to me or to any IBIS 
> Open Forum officer.  Your feedback is important!  The Open Forum 
> intends to vote on approving or disapproving the specification on 
> or before August 29.
> 
> Thank you in advance for your support.
> 
> - Michael Mirmak
>   [email-masked]
>   Intel Corp. 
>   Chair, EIA/IBIS Open Forum
> 
> 
> 
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
> 

- -- 
David Lieby, SI Engineering
Siemens Medical Solutions USA, Inc.
Ultrasound Division
1230 Shorebird Way
Building 04, Mail Stop 4.1
Mountain View, CA 94043
(650)694-5030 work
(831)332-4303 cell
    ____    __      _____
   /  __|  /  \    / __  \
   | /    / /\ \  / /   \ |
   | \___/ /  \ \/ /  __/ |
   \______/    \__/  |___/

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 8 Jul 2003 08:56:13 -0700
From: "Peters, Stephen" <[email-masked]>
Subject: RE: [IBIS-Users] Inclusion of RLGC package info in IBIS

This is a multi-part message in MIME format.

- ------_=_NextPart_001_01C34569.75360D5E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Granthana:
=20
  Unfortunetly, the current .pkg package model description format does
not support cascaded or multiple matrices.  However, the IBIS committee
has just release a draft version of the ICM (interconnect modeling)
specification, which does support cascaded RLGC matrices in a format
similar to the .pkg file.  The specification is currently undergoing
review, and a copy is available at the following URL:
http://www.eda.org/pub/ibis/connector/.
=20
 Regards,
 Stephen Peters
 Intel Corp.
=20
 =20

	-----Original Message-----
	From: ramesh reddy [mailto:[email-masked]]=20
	Sent: Monday, July 07, 2003 8:49 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: [IBIS-Users] Inclusion of RLGC package info in IBIS
=09
=09
	Hello all,

	I have to include package data which is in the RLGC matrix
format (derived from Hspice) in IBIS files. There are different sets of
matrices specified for the different sections like breakout2, via and
the transmission line as shown below. Also the length parameter is given
for package trace.=20

	Seg 1(Break out )    Seg 2(Short trace)     Seg 3(Via)     Seg 4
(Package long trace)  Seg 5(Via and Solderball)

=09

	My problem is :

	1> The package model section of the IBIS file does not provide
an option to include RLGC matrices for multiple sections.

	2> Also there is no keyword to specify the length for the traces
when the "model data" option is used. This option is provided only when
"Number of sections" is used. But since "Number of sections" and "model
data" option is mutually exclusive I cannot use this.

	Hence how do I go about including multiple sets of matrices in
the IBIS file?

	Looking forward for your reply.

	Thanks,

	Granthana

	Force Computers (India)Pvt Ltd

	Ph: +91-80-5356060 Ext 253

	Fax: +91-80-5354025

	E-mail: [email-masked]

=09
=09
=09

  _____ =20

	Reconnect with old pals. Relive the happy times. With just one
click. <http://g.msn.com/8HMGENIN/2737??PS=3D>
|------------------------------------------------------------------ |For
help or to subscribe/unsubscribe, email [email-masked] |with just the
appropriate command message(s) in the body: | | help | subscribe ibis |
subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or
email a written request to [email-masked]. | |IBIS reflector
archives exist under: | | http://www.eda.org/pub/ibis/email_archive/
Recent | http://www.eda.org/pub/ibis/users_archive/ Recent |
http://www.eda.org/pub/ibis/email/ E-mail since 1993=20

- ------_=_NextPart_001_01C34569.75360D5E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D945564615-08072003>Hello=20
Granthana:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D945564615-08072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D945564615-08072003>&nbsp;=20
Unfortunetly, the current .pkg package&nbsp;model description =
format&nbsp;does=20
not&nbsp;support cascaded or multiple matrices.&nbsp; However, the IBIS=20
committee has&nbsp;just release a draft version of the ICM (interconnect =

modeling) specification, which does&nbsp;support cascaded RLGC matrices =
in a=20
format similar to the .pkg file.&nbsp; The specification is currently =
undergoing=20
review, and a copy is available at the following URL: <A=20
href=3D"http://www.eda.org/pub/ibis/connector/">http://www.eda.org/pub/ib=
is/connector/</A>.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D945564615-08072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D945564615-08072003>&nbsp;Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D945564615-08072003>&nbsp;Stephen Peters</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D945564615-08072003>&nbsp;Intel Corp.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D945564615-08072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D945564615-08072003>&nbsp;=20
</SPAN></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
ramesh reddy=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Monday, July 07, =
2003 8:49=20
  PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> [IBIS-Users] Inclusion of RLGC =
package=20
  info in IBIS<BR><BR></FONT></DIV>
  <DIV>
  <DIV><FONT size=3D2>
  <P>Hello all,</P>
  <P>I have to include package data which is in the RLGC matrix format =
(derived=20
  from Hspice) in IBIS files. There are different sets of matrices =
specified for=20
  the different sections like breakout2, via and the transmission line =
as shown=20
  below. Also the length parameter is given for package trace. </P>
  <P>Seg 1(Break&nbsp;out&nbsp;)&nbsp;&nbsp;&nbsp; Seg 2(Short=20
  trace)&nbsp;&nbsp;&nbsp;&nbsp; Seg 3(Via)&nbsp;&nbsp;&nbsp;&nbsp; Seg=20
  4&nbsp;(Package long trace)&nbsp;&nbsp;Seg 5(Via and Solderball)</P>
  <P></P>
  <P>My problem is :</P>
  <P>1&gt; The package model section of the IBIS file does not provide =
an option=20
  to include RLGC matrices for multiple sections.</P>
  <P>2&gt; Also there is no keyword to specify the length for the traces =
when=20
  the "model data" option is used. This option is provided only when =
"Number of=20
  sections" is used. But since "Number of sections" and "model data" =
option is=20
  mutually exclusive I cannot use this.</P>
  <P>Hence how do I go about including multiple sets of matrices in the =
IBIS=20
  file?</P>
  <P>Looking forward for your reply.</P>
  <P>Thanks,</P>
  <P>Granthana</P>
  <P>Force Computers (India)Pvt Ltd</P>
  <P>Ph: +91-80-5356060 Ext 253</P>
  <P>Fax: +91-80-5354025</P>
  <P>E-mail: [email-masked]</P>
  <P></FONT><BR><BR></P></DIV></DIV><BR clear=3Dall>
  <HR>
  Reconnect with old pals. Relive the happy times. <A=20
  href=3D"http://g.msn.com/8HMGENIN/2737??PS=3D">With just one =
click.</A>=20
  |------------------------------------------------------------------ =
|For help=20
  or to subscribe/unsubscribe, email [email-masked] |with just the=20
  appropriate command message(s) in the body: | | help | subscribe ibis=20
  <OPTIONAL different if address, e-mail>| subscribe ibis-users =
<OPTIONAL=20
  different if address, e-mail>| unsubscribe ibis <OPTIONAL different if =

  address, e-mail>| unsubscribe ibis-users <OPTIONAL different if =
address,=20
  e-mail>| |or email a written request to [email-masked]. | |IBIS=20
  reflector archives exist under: | | =
http://www.eda.org/pub/ibis/email_archive/=20
  Recent | http://www.eda.org/pub/ibis/users_archive/ Recent |=20
  http://www.eda.org/pub/ibis/email/ E-mail since 1993 =
</BLOCKQUOTE></BODY></HTML>
=00
- ------_=_NextPart_001_01C34569.75360D5E--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Wed, 09 Jul 2003 16:00:14 -0500
From: John Phillippe <[email-masked]>
Subject: [IBIS-Users] Spice vs Signal Explorer simulations.

I have been running ibis simulations using Signal Explorer, and then 
checking the results against spice simulations to get my models 
accurate.  My test setup is simple.  I just run 1 pulse through the 
buffers, to get a rising and falling edge.  My load is a transmission 
line, then then a cap.  I have noticed on a few simulations, that the 
signal explorer simulations give a rising edge twice as fast as my spice 
simulations.  I'm wondering if this is cause for concern or not.  Anyone 
have any ideas?

- -- 
John Phillippe
SPS, 32 Bit Embedded Controller Division, IC Creation
Motorola      -  512-895-1835
Austin, TX    -  [email-masked]

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 10 Jul 2003 11:28:35 -0500
From: "Rick Kingen" <[email-masked]>
Subject: [IBIS-Users] LVDS Modelling Question

This is a multi-part message in MIME format.

- ------=_NextPart_000_001E_01C346D6.66C57C70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello All,

I have generated a model of an LVDS using s2ibis2.  I hand edited the =
V2.1 ibis model to add V3.2 keywords ot model the LVDS buffers.  I have =
tested the buffer using WINIBIS and LINESIM and see good differential =
signalling when terminated into a 100 ohm resistor.  I have a customer =
that is asking about the [Rising Waveform] and [Falling Waveform] for =
the negative driver stating that they are inverted.  My question is two =
fold:  1) should the [Rising Waveform] and [Falling Waveform] for the =
negative driver be inverted from the [Rising Waveform] and [Falling =
Waveform] for the positive driver. and 2) does the simulator take the =
information in the [DIFF PIN] section and determine the polarity of the =
positive and negative waveform such that the [Rising Waveform] and =
[Falling Waveform] table are not reversed?

Regards,

Rick Kingen
_______________________________________________
This email communication along with any attachments
is classified as:
=20
[ X]  General business information
[ ]  Motorola internal use only
[ ]  Motorola confidential proprietary
=20

- ------=_NextPart_000_001E_01C346D6.66C57C70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hello All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have generated a model of an LVDS =
using=20
s2ibis2.&nbsp; I hand edited the V2.1 ibis model to add V3.2 keywords ot =
model=20
the LVDS buffers.&nbsp; I have tested the buffer using WINIBIS and =
LINESIM and=20
see good differential signalling when terminated into a 100&nbsp;ohm=20
resistor.&nbsp; I have a customer that is asking about the [Rising =
Waveform] and=20
[Falling Waveform] for the negative driver stating that they are =
inverted.&nbsp;=20
My question is two fold:&nbsp; 1) should the [Rising Waveform] and =
[Falling=20
Waveform] for the negative driver be inverted from the [Rising Waveform] =
and=20
[Falling Waveform] for the positive driver. and 2) does the simulator =
take the=20
information in the [DIFF PIN] section and determine the polarity of the =
positive=20
and negative waveform such that the [Rising Waveform] and [Falling =
Waveform]=20
table are not reversed?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Rick Kingen</DIV></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>_______________________________________________<BR>This email=20
communication along with any attachments<BR>is classified =
as:<BR>&nbsp;<BR>[=20
X]&nbsp; General business information<BR>[ ]&nbsp; Motorola internal use =

only<BR>[ ]&nbsp; Motorola confidential=20
proprietary<BR>&nbsp;<BR></FONT></DIV></BODY></HTML>

- ------=_NextPart_000_001E_01C346D6.66C57C70--

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 10 Jul 2003 09:40:08 -0700
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] LVDS Modeling Question

This is a multi-part message in MIME format.

- ------_=_NextPart_001_01C34701.ECA28D62
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Rick,
=20
Do not mess with the [*** Waveform]s.  The [Rising Waveform]
should always have a rising edge, and the [Falling Waveform]
should always have a falling edge in it.
=20
The [Diff Pin] keyword will tell the simulator to put a stimulus
of reversed polarity on the second model's input to make that
work in the opposite direction from the non inverted model.
=20
Even if you just had a single ended buffer, you should not
reverse the [*** Waveform] data.  If an inverted output is
needed, use the sub-parameter "Polarity" under the [Model]
keyword.
=20
Arpad Muranyi
Intel Corporation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
- -----Original Message-----
From: Rick Kingen [mailto:[email-masked]]
Sent: Thursday, July 10, 2003 9:29 AM
To: [email-masked]
Subject: [IBIS-Users] LVDS Modelling Question

Hello All,
=20
I have generated a model of an LVDS using s2ibis2.  I hand edited the =
V2.1 ibis model to add V3.2 keywords ot model the LVDS buffers.  I have =
tested the buffer using WINIBIS and LINESIM and see good differential =
signalling when terminated into a 100 ohm resistor.  I have a customer =
that is asking about the [Rising Waveform] and [Falling Waveform] for =
the negative driver stating that they are inverted.  My question is two =
fold:  1) should the [Rising Waveform] and [Falling Waveform] for the =
negative driver be inverted from the [Rising Waveform] and [Falling =
Waveform] for the positive driver. and 2) does the simulator take the =
information in the [DIFF PIN] section and determine the polarity of the =
positive and negative waveform such that the [Rising Waveform] and =
[Falling Waveform] table are not reversed?
=20
Regards,
=20
Rick Kingen
_______________________________________________
This email communication along with any attachments
is classified as:
=20
[ X]  General business information
[ ]  Motorola internal use only
[ ]  Motorola confidential proprietary
=20

- ------_=_NextPart_001_01C34701.ECA28D62
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003>Rick,</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>Do not mess=20
with the [*** Waveform]s.&nbsp; The [Rising =
Waveform]</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>should=20
always have a rising edge, and the [Falling =
Waveform]</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>should=20
always have a falling edge in it.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>The [Diff=20
Pin] keyword will tell the simulator to put a =
stimulus</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>of reversed=20
polarity on the second model's input to make that</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>work in the=20
opposite direction from the non inverted model.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>Even if you=20
just had a single ended buffer, you should not</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>reverse the=20
[*** Waveform] data.&nbsp; If an inverted output is</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>needed, use=20
the sub-parameter "Polarity" under the [Model]</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003>keyword.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>Arpad=20
Muranyi</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D823073616-10072003>Intel=20
Corporation</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SP=
AN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D823073616-10072003></SPAN></FONT>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Rick Kingen=20
[mailto:[email-masked]]<BR><B>Sent:</B> Thursday, July 10, =
2003 9:29=20
AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> [IBIS-Users] LVDS =

Modelling Question<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hello All,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have generated a model of an LVDS =
using=20
s2ibis2.&nbsp; I hand edited the V2.1 ibis model to add V3.2 keywords ot =
model=20
the LVDS buffers.&nbsp; I have tested the buffer using WINIBIS and =
LINESIM and=20
see good differential signalling when terminated into a 100&nbsp;ohm=20
resistor.&nbsp; I have a customer that is asking about the [Rising =
Waveform] and=20
[Falling Waveform] for the negative driver stating that they are =
inverted.&nbsp;=20
My question is two fold:&nbsp; 1) should the [Rising Waveform] and =
[Falling=20
Waveform] for the negative driver be inverted from the [Rising Waveform] =
and=20
[Falling Waveform] for the positive driver. and 2) does the simulator =
take the=20
information in the [DIFF PIN] section and determine the polarity of the =
positive=20
and negative waveform such that the [Rising Waveform] and [Falling =
Waveform]=20
table are not reversed?</FONT></DIV>
<DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV>Rick Kingen</DIV></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>_______________________________________________<BR>This email=20
communication along with any attachments<BR>is classified =
as:<BR>&nbsp;<BR>[=20
X]&nbsp; General business information<BR>[ ]&nbsp; Motorola internal use =

only<BR>[ ]&nbsp; Motorola confidential=20
proprietary<BR>&nbsp;<BR></FONT></DIV></BODY></HTML>

- ------_=_NextPart_001_01C34701.ECA28D62--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 10 Jul 2003 21:19:43 -0700
From: "Mirmak, Michael" <[email-masked]>
Subject: [IBIS-Users] BIRD82 - Clarification of Clamp Table Use

The following BIRD is posted on behalf of Lynne Green and Robert Haller.

It will be discussed at the July 18, 2003 IBIS Open Forum
teleconference.

- - Michael Mirmak
  Intel Corp.
  Chair, EIA/IBIS Open Forum

************************************************************************
****
************************************************************************
****
                       Buffer Issue Resolution Document  (BIRD)

BIRD ID#:       82
ISSUE TITLE:    Clarification of Clamp Table Use
REQUESTOR:      Lynne Green, Cadence, and Robert Haller, SiSoft
DATE SUBMITTED: June 27, 2003
DATE ACCEPTED BY IBIS OPEN FORUM:  Pending

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

STATEMENT OF THE ISSUE:

Double-counting of clamp currents is the result of confusion over how
the
clamp currents are summed by the tools.  Model makers are often unsure
if
clamps are always active, or whether the [Power Clamp] works only with
the
[Pullup] and the [GND Clamp] only with the [Pulldown].  This is
difficult,
if not impossible, to detect with a parser.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Old text:
|         It is assumed that the simulator sums the clamp tables
|         together with the appropriate [Pullup] or [Pulldown] table
|         when a buffer is driving high or low, respectively.  From this
|         assumption and the nature of 3-statable buffers, it follows
|         that the data in the clamping table sections are handled as
|         constantly present tables and the [Pullup] and [Pulldown]
|         tables are used only when needed in the simulation.

Proposed text:
|         It is assumed that the simulator will sum both clamp tables
|         (power and ground), if they exist, to the Pulldown table when
|         the buffer is driving high. The simulator will sum both clamp
|         tables (power and ground), if they exist, to the Pulldown
table
|         when the buffer is driving low.  The simulator will sum both
|         clamp tables when the buffer is not driving (input or 3-state
|         operation).
|         It follows that the data in the clamping table sections are
|         handled as constantly present tables, while the [Pullup] and
|         [Pulldown] tables are used only when needed in the simulation.

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Comments from members of the Quality committee, as well as others,
indicated that some models double-count clamp currents.

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

ANY OTHER BACKGROUND INFORMATION:

Initially, it was suggested that this be detected by the parser, but
it was decided that this was too difficult.  This led to further
discussion of why double-counting occurred, and how clarification of
the spec could help address the issue.

************************************************************************
****
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 11 Jul 2003 10:40:13 +0200
From: [email-masked]
Subject: [IBIS-Users] Re: [IBIS] BIRD82 - Clarification of Clamp Table Use

This is a multipart message in MIME format.
- --=_alternative 0025723BC1256D60_=
Content-Type: text/plain; charset="us-ascii"

:Michael,

Isn't there a typing error in the proposed text? In my opinion both clamp 
tables should be summed to the Pullup table when the buffer is driving 
high.
|         It is assumed that the simulator will sum both clamp tables
|         (power and ground), if they exist, to the Pullup table when
|         the buffer is driving high.

Kind regards,

Rob
__________________________________________________________________________
Rob Mataheroe                              Philips Semiconductors bv
P.G. Logic Product Group PD&S              Building AM1.108
Senior Design Modeling Engineer            Gerstweg 2
Tel. ++31 (0)24 353 2370                         6534 AE Nijmegen
Fax. ++31 (0)24 353 2820                        The Netherlands
Telework: 036-5225406 (From PS Nijm.: **0731)
Email: [email-masked] 
Seri: matahero@nyhp04

"Mirmak, Michael" <[email-masked]>
Sent by: 
[email-masked]
07/11/03 06:19 AM

        To:     <[email-masked]>
<[email-masked]>
        cc:     (bcc: Rob Mataheroe/NYM/SC/PHILIPS)
        Subject:        [IBIS] BIRD82 - Clarification of Clamp Table Use
        Classification: 

The following BIRD is posted on behalf of Lynne Green and Robert Haller.

It will be discussed at the July 18, 2003 IBIS Open Forum
teleconference.

- - Michael Mirmak
  Intel Corp.
  Chair, EIA/IBIS Open Forum

************************************************************************
****
************************************************************************
****
                       Buffer Issue Resolution Document  (BIRD)

BIRD ID#:       82
ISSUE TITLE:    Clarification of Clamp Table Use
REQUESTOR:      Lynne Green, Cadence, and Robert Haller, SiSoft
DATE SUBMITTED: June 27, 2003
DATE ACCEPTED BY IBIS OPEN FORUM:  Pending

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

STATEMENT OF THE ISSUE:

Double-counting of clamp currents is the result of confusion over how
the
clamp currents are summed by the tools.  Model makers are often unsure
if
clamps are always active, or whether the [Power Clamp] works only with
the
[Pullup] and the [GND Clamp] only with the [Pulldown].  This is
difficult,
if not impossible, to detect with a parser.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Old text:
|         It is assumed that the simulator sums the clamp tables
|         together with the appropriate [Pullup] or [Pulldown] table
|         when a buffer is driving high or low, respectively.  From this
|         assumption and the nature of 3-statable buffers, it follows
|         that the data in the clamping table sections are handled as
|         constantly present tables and the [Pullup] and [Pulldown]
|         tables are used only when needed in the simulation.

Proposed text:
|         It is assumed that the simulator will sum both clamp tables
|         (power and ground), if they exist, to the Pulldown table when
|         the buffer is driving high. The simulator will sum both clamp
|         tables (power and ground), if they exist, to the Pulldown
table
|         when the buffer is driving low.  The simulator will sum both
|         clamp tables when the buffer is not driving (input or 3-state
|         operation).
|         It follows that the data in the clamping table sections are
|         handled as constantly present tables, while the [Pullup] and
|         [Pulldown] tables are used only when needed in the simulation.

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Comments from members of the Quality committee, as well as others,
indicated that some models double-count clamp currents.

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

ANY OTHER BACKGROUND INFORMATION:

Initially, it was suggested that this be detected by the parser, but
it was decided that this was too difficult.  This led to further
discussion of why double-counting occurred, and how clarification of
the spec could help address the issue.

************************************************************************
****
- -----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

- --=_alternative 0025723BC1256D60_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">:Michael,</font>
<br>
<br><font size=2 face="sans-serif">Isn't there a typing error in the proposed text? In my opinion both clamp tables should be summed to the Pullup table when the buffer is driving high.</font>
<br><font size=2 face="Courier New">| &nbsp; &nbsp; &nbsp; &nbsp; It is assumed that the simulator will sum both clamp tables<br>
| &nbsp; &nbsp; &nbsp; &nbsp; (power and ground), if they exist, to the Pullup table when<br>
| &nbsp; &nbsp; &nbsp; &nbsp; the buffer is driving high.</font><font size=2 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif">Kind regards,</font>
<br>
<br><font size=2 face="sans-serif">Rob</font>
<br><font size=2 face="sans-serif">__________________________________________________________________________<br>
Rob Mataheroe &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Philips Semiconductors bv<br>
P.G. Logic Product Group PD&amp;S &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Building AM1.108<br>
Senior Design Modeling Engineer &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Gerstweg 2<br>
Tel. ++31 (0)24 353 2370 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 6534 AE Nijmegen<br>
Fax. ++31 (0)24 353 2820 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The Netherlands<br>
Telework: 036-5225406 (From PS Nijm.: **0731)<br>
Email: [email-masked] &nbsp; &nbsp;<br>
Seri: matahero@nyhp04<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>&quot;Mirmak, Michael&quot; &lt;[email-masked]&gt;</b></font>
<p><font size=1 face="sans-serif">Sent by: </font>
<br><font size=1 face="sans-serif">[email-masked]</font>
<p><font size=1 face="sans-serif">07/11/03 06:19 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;<br>
&lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;(bcc: Rob Mataheroe/NYM/SC/PHILIPS)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[IBIS] BIRD82 - Clarification of Clamp Table Use</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
The following BIRD is posted on behalf of Lynne Green and Robert Haller.<br>
<br>
It will be discussed at the July 18, 2003 IBIS Open Forum<br>
teleconference.<br>
<br>
- - Michael Mirmak<br>
 &nbsp;Intel Corp.<br>
 &nbsp;Chair, EIA/IBIS Open Forum<br>
<br>
<br>
************************************************************************<br>
****<br>
************************************************************************<br>
****<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Buffer Issue Resolution Document &nbsp;(BIRD)<br>
<br>
BIRD ID#: &nbsp; &nbsp; &nbsp; 82<br>
ISSUE TITLE: &nbsp; &nbsp;Clarification of Clamp Table Use<br>
REQUESTOR: &nbsp; &nbsp; &nbsp;Lynne Green, Cadence, and Robert Haller, SiSoft<br>
DATE SUBMITTED: June 27, 2003<br>
DATE ACCEPTED BY IBIS OPEN FORUM: &nbsp;Pending<br>
<br>
************************************************************************<br>
****<br>
************************************************************************<br>
****<br>
<br>
STATEMENT OF THE ISSUE:<br>
<br>
Double-counting of clamp currents is the result of confusion over how<br>
the<br>
clamp currents are summed by the tools. &nbsp;Model makers are often unsure<br>
if<br>
clamps are always active, or whether the [Power Clamp] works only with<br>
the<br>
[Pullup] and the [GND Clamp] only with the [Pulldown]. &nbsp;This is<br>
difficult,<br>
if not impossible, to detect with a parser.<br>
<br>
************************************************************************<br>
****<br>
<br>
STATEMENT OF THE RESOLVED SPECIFICATIONS:<br>
<br>
Old text:<br>
| &nbsp; &nbsp; &nbsp; &nbsp; It is assumed that the simulator sums the clamp tables<br>
| &nbsp; &nbsp; &nbsp; &nbsp; together with the appropriate [Pullup] or [Pulldown] table<br>
| &nbsp; &nbsp; &nbsp; &nbsp; when a buffer is driving high or low, respectively. &nbsp;From this<br>
| &nbsp; &nbsp; &nbsp; &nbsp; assumption and the nature of 3-statable buffers, it follows<br>
| &nbsp; &nbsp; &nbsp; &nbsp; that the data in the clamping table sections are handled as<br>
| &nbsp; &nbsp; &nbsp; &nbsp; constantly present tables and the [Pullup] and [Pulldown]<br>
| &nbsp; &nbsp; &nbsp; &nbsp; tables are used only when needed in the simulation.<br>
<br>
Proposed text:<br>
| &nbsp; &nbsp; &nbsp; &nbsp; It is assumed that the simulator will sum both clamp tables<br>
| &nbsp; &nbsp; &nbsp; &nbsp; (power and ground), if they exist, to the Pulldown table when<br>
| &nbsp; &nbsp; &nbsp; &nbsp; the buffer is driving high. The simulator will sum both clamp<br>
| &nbsp; &nbsp; &nbsp; &nbsp; tables (power and ground), if they exist, to the Pulldown<br>
table<br>
| &nbsp; &nbsp; &nbsp; &nbsp; when the buffer is driving low. &nbsp;The simulator will sum both<br>
| &nbsp; &nbsp; &nbsp; &nbsp; clamp tables when the buffer is not driving (input or 3-state<br>
| &nbsp; &nbsp; &nbsp; &nbsp; operation).<br>
| &nbsp; &nbsp; &nbsp; &nbsp; It follows that the data in the clamping table sections are<br>
| &nbsp; &nbsp; &nbsp; &nbsp; handled as constantly present tables, while the [Pullup] and<br>
| &nbsp; &nbsp; &nbsp; &nbsp; [Pulldown] tables are used only when needed in the simulation.<br>
<br>
<br>
************************************************************************<br>
****<br>
<br>
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:<br>
<br>
Comments from members of the Quality committee, as well as others,<br>
indicated that some models double-count clamp currents.<br>
<br>
<br>
************************************************************************<br>
****<br>
<br>
ANY OTHER BACKGROUND INFORMATION:<br>
<br>
Initially, it was suggested that this be detected by the parser, but<br>
it was decided that this was too difficult. &nbsp;This led to further<br>
discussion of why double-counting occurred, and how clarification of<br>
the spec could help address the issue.<br>
<br>
<br>
************************************************************************<br>
****<br>
- -----------------------------------------------------------------<br>
|For help or to subscribe/unsubscribe, email [email-masked]<br>
|with the appropriate command message(s) in the body:<br>
|<br>
| &nbsp;help<br>
| &nbsp;subscribe &nbsp; ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;subscribe &nbsp; ibis-users &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<br>
| &nbsp;unsubscribe ibis-users &lt;optional e-mail address, if different&gt;<br>
|<br>
|or email a request to [email-masked].<br>
|<br>
|IBIS reflector archives exist under:<br>
|<br>
| &nbsp;http://www.eda.org/pub/ibis/email_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/users_archive/ &nbsp;Recent<br>
| &nbsp;http://www.eda.org/pub/ibis/email/ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;E-mail since 1993<br>
</font>
<br>
<br>
- --=_alternative 0025723BC1256D60_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 11 Jul 2003 09:57:25 -0700
From: "Mirmak, Michael" <[email-masked]>
Subject: [IBIS-Users] Agenda, IBIS Open Forum Teleconference 7/18

		     IBIS Open Forum Meeting Agenda
			      for 7/18/03

		 Bridge Number    Reservation #   Passcode
             1-916-356-2663       2           381-4012 
              (International Dial-In: 1-617-801-9781)

All meetings are 8:00 AM to 9:55 AM Pacific Time.  When you call into
the meeting, ask for the IBIS Open Forum hosted by Michael Mirmak and 
give the Reservation Number and Passcode.

8:00 Check-In, Intros, Announcements                       Mirmak

     - Intros of New IBIS Participants, Meeting Quorum     Mirmak
     - Call for Patents                                    Mirmak
     - Membership Update and Treasurers Report             Mirmak
     - Review of Previous Meeting's Minutes (and ARs)      Mirmak
         June 23 Summit Minutes
         June 27 Open Forum Minutes
     - Miscellany/Announcements                            All
     - Press & Web Page Updates                            Huq, All
     - New Models Available, Library Update                Leventhal
     - Opens for New Issues                                All

8:15 Administrative and Project Discussions

     International/External Progress
     - IEC 62014-3 (ICEM) Integrated Circuits Electromagnetic 
       Model Proposal (IEC 93/67/NP IBIS 
       and EMC Simulation)                                 Perrin/Peters
     - JEDEC Committee Report                              Green

     PCB East Summit Planning                              Mirmak

     IBIS Version 4.0 Parser Funding and Status            Mirmak/Peters

     IBIS Version 4.1 Discussion                           Peters/Ross

     IBIS Quality Committee Report                         Katz

     IBIS Model Review Committee                           Green

     New Administrative Issues                             All

8:45 Technical Discussion

     BIRD82 - Clarification of Clamp Table Use             Green/Haller

     BIRD74.4 - EMI Parameters                             de Burgh

     IBISCHK4 Status                                       Ross/Angulo

     S2IBIS3 Discussion                                    Ross

     ICM Specification Discussion                          Mirmak, All

     New Technical Issues                                  All

9:50 Wrap Up and Next Meetings Plans                       Mirmak

9:55 Sign Off

  
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 11 Jul 2003 11:08:59 -0700
From: "Angulo, John" <[email-masked]>
Subject: RE: [IBIS-Users] Re: [IBIS] BIRD82 - Clarification of Clamp Table Use

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

- ------_=_NextPart_001_01C347D7.80781C09
Content-Type: text/plain

If I understand, then, one source of double counting is that people sometimes put both diode curves into each clamp table because they're worried that only one clamp table actually will be used - [GND Clamp] in the low state, [POWER Clamp] in the high state.  Clarifying that both clamp tables are always present will prevent this.
 
I also may have seen a model or two that double counted the currents because the model maker didn't realize the tables were added as parallel electrical elements.  He or she thought that the tables would be "added" by concatenation to form a bigger table containing the currents of both tables and spanning their combined voltage range.  Not so, of course - if the buffer contains an internal pullup resistor, and the current through that resistor appears in both tables, it will be double counted, both by EDA tools and the committee parser.  At least the I-V/V-T mismatch check will detect the problem if V-T tables are present.  I wonder if this is worth an additional clarifying comment in the BIRD.
 
John Angulo 
Hyperlynx Products 
Mentor Graphics Corp. 
[email-masked] 
425-869-2320 

 -----Original Message-----
From: Todd Westerhoff [mailto:[email-masked]]
Sent: Friday, July 11, 2003 7:42 AM
To: [email-masked]
Subject: RE: [IBIS-Users] Re: [IBIS] BIRD82 - Clarification of Clamp Table Use

I agree.  I believe both clamp curves are summed together with the driving device's V-I curve.
 
However, in all matters of Algorithms, I defer to Arpad.
 
Todd ;-)

Todd Westerhoff
High Speed Design Specialist
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:[email-masked]
ph: 978-936-2149
============================================

"When did the choices get so hard, with so much more at stake?
 Life gets mighty precious when there's less of it to waste"

- - Bonnie Raitt, "Nick of Time"

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Friday, July 11, 2003 4:40 AM
To: Mirmak, Michael
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [IBIS-Users] Re: [IBIS] BIRD82 - Clarification of Clamp Table Use

:Michael, 

Isn't there a typing error in the proposed text? In my opinion both clamp tables should be summed to the Pullup table when the buffer is driving high. 
|         It is assumed that the simulator will sum both clamp tables
|         (power and ground), if they exist, to the Pullup table when
|         the buffer is driving high.

Kind regards, 

Rob 
__________________________________________________________________________
Rob Mataheroe                                                                                           Philips Semiconductors bv
P.G. Logic Product Group PD&S                                                           Building AM1.108
Senior Design Modeling Engineer                                                       Gerstweg 2
Tel. ++31 (0)24 353 2370                                                                           6534 AE Nijmegen
Fax. ++31 (0)24 353 2820                                                                          The Netherlands
Telework: 036-5225406 (From PS Nijm.: **0731)
Email: [email-masked]    
Seri: matahero@nyhp04

	

"Mirmak, Michael" <[email-masked]> 

Sent by: 
[email-masked] 

07/11/03 06:19 AM 

        
        To:        <[email-masked]>
<[email-masked]> 
        cc:        (bcc: Rob Mataheroe/NYM/SC/PHILIPS) 
        Subject:        [IBIS] BIRD82 - Clarification of Clamp Table Use 

        Classification:         

The following BIRD is posted on behalf of Lynne Green and Robert Haller.

It will be discussed at the July 18, 2003 IBIS Open Forum
teleconference.

- - Michael Mirmak
 Intel Corp.
 Chair, EIA/IBIS Open Forum

************************************************************************
****
************************************************************************
****
                      Buffer Issue Resolution Document  (BIRD)

BIRD ID#:       82
ISSUE TITLE:    Clarification of Clamp Table Use
REQUESTOR:      Lynne Green, Cadence, and Robert Haller, SiSoft
DATE SUBMITTED: June 27, 2003
DATE ACCEPTED BY IBIS OPEN FORUM:  Pending

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

STATEMENT OF THE ISSUE:

Double-counting of clamp currents is the result of confusion over how
the
clamp currents are summed by the tools.  Model makers are often unsure
if
clamps are always active, or whether the [Power Clamp] works only with
the
[Pullup] and the [GND Clamp] only with the [Pulldown].  This is
difficult,
if not impossible, to detect with a parser.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Old text:
|         It is assumed that the simulator sums the clamp tables
|         together with the appropriate [Pullup] or [Pulldown] table
|         when a buffer is driving high or low, respectively.  From this
|         assumption and the nature of 3-statable buffers, it follows
|         that the data in the clamping table sections are handled as
|         constantly present tables and the [Pullup] and [Pulldown]
|         tables are used only when needed in the simulation.

Proposed text:
|         It is assumed that the simulator will sum both clamp tables
|         (power and ground), if they exist, to the Pulldown table when
|         the buffer is driving high. The simulator will sum both clamp
|         tables (power and ground), if they exist, to the Pulldown
table
|         when the buffer is driving low.  The simulator will sum both
|         clamp tables when the buffer is not driving (input or 3-state
|         operation).
|         It follows that the data in the clamping table sections are
|         handled as constantly present tables, while the [Pullup] and
|         [Pulldown] tables are used only when needed in the simulation.

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Comments from members of the Quality committee, as well as others,
indicated that some models double-count clamp currents.

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

ANY OTHER BACKGROUND INFORMATION:

Initially, it was suggested that this be detected by the parser, but
it was decided that this was too difficult.  This led to further
discussion of why double-counting occurred, and how clarification of
the spec could help address the issue.

************************************************************************
****
- -----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

- ------_=_NextPart_001_01C347D7.80781C09
Content-Type: text/html

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

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=631271516-11072003>If I 
understand, then, one source of double counting is that people sometimes put 
both diode curves into each clamp table because they're worried that only one 
clamp table actually will be used - [GND Clamp] in the low state, [POWER Clamp] 
in the high state.&nbsp; Clarifying that both clamp tables are always present 
will prevent this.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=631271516-11072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=631271516-11072003>I also 
may have seen a model or two that double counted the currents because the model 
maker didn't realize the tables were added as parallel electrical 
elements.&nbsp; He or she thought that the tables would be "added" by 
concatenation to form a bigger table containing the currents of both tables and 
spanning their combined voltage range.&nbsp; Not so,&nbsp;of course -&nbsp;if 
the buffer contains an internal pullup resistor,&nbsp;and the 
current&nbsp;through that resistor appears in both tables, it will 
be&nbsp;double counted, both by EDA tools and the committee parser.&nbsp; At 
least the I-V/V-T mismatch check&nbsp;will detect the problem if V-T tables are 
present.&nbsp; I wonder if this is worth an additional clarifying comment in the 
BIRD.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=631271516-11072003><FONT 
face=Arial size=2></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=631271516-11072003><FONT 
face=Arial size=2>John Angulo</FONT> <BR><FONT face=Arial size=2>Hyperlynx 
Products</FONT> <BR><FONT face=Arial size=2>Mentor Graphics Corp.</FONT> 
<BR><FONT face=Arial size=2>[email-masked]</FONT> <BR><FONT face=Arial 
size=2>425-869-2320</FONT> </DIV></SPAN></FONT>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=631271516-11072003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><BR><FONT size=2><SPAN class=631271516-11072003><FONT 
face=Arial color=#0000ff>&nbsp;</FONT></SPAN>-----Original 
Message-----<BR><B>From:</B> Todd Westerhoff 
[mailto:[email-masked]]<BR><B>Sent:</B> Friday, July 11, 2003 7:42 
AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> RE: [IBIS-Users] Re: [IBIS] 
BIRD82 - Clarification of Clamp Table Use<BR><BR></FONT></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV><SPAN class=470054014-11072003><FONT face=Arial color=#0000ff size=2>I 
  agree.&nbsp; I believe both clamp curves are summed together with the driving 
  device's V-I curve.</FONT></SPAN></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=470054014-11072003><FONT face=Arial color=#0000ff 
  size=2>However, in all matters of Algorithms, I defer to 
  Arpad.</FONT></SPAN></DIV>
  <DIV><SPAN class=470054014-11072003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=470054014-11072003><FONT face=Arial color=#0000ff size=2>Todd 
  ;-)</FONT></SPAN></DIV>
  <P><FONT size=2>Todd Westerhoff<BR>High Speed Design Specialist<BR>Cisco 
  Systems<BR>1414 Massachusetts Ave - Boxboro, MA - 
  01719<BR>email:[email-masked]<BR>ph: 
  978-936-2149<BR>============================================<BR><BR>"When did 
  the choices get so hard, with so much more at stake?<BR>&nbsp;Life gets mighty 
  precious when there's less of it to waste"<BR><BR>- Bonnie Raitt, "Nick of 
  Time"<BR></FONT></P>
  <BLOCKQUOTE>
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
    [mailto:[email-masked]]<B>On Behalf Of 
    </B>[email-masked]<BR><B>Sent:</B> Friday, July 11, 2003 4:40 
    AM<BR><B>To:</B> Mirmak, Michael<BR><B>Cc:</B> [email-masked]; 
    [email-masked]; [email-masked]<BR><B>Subject:</B> [IBIS-Users] Re: 
    [IBIS] BIRD82 - Clarification of Clamp Table 
    Use<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>:Michael,</FONT> 
    <BR><BR><FONT face=sans-serif size=2>Isn't there a typing error in the 
    proposed text? In my opinion both clamp tables should be summed to the 
    Pullup table when the buffer is driving high.</FONT> <BR><FONT 
    face="Courier New" size=2>| &nbsp; &nbsp; &nbsp; &nbsp; It is assumed that 
    the simulator will sum both clamp tables<BR>| &nbsp; &nbsp; &nbsp; &nbsp; 
    (power and ground), if they exist, to the Pullup table when<BR>| &nbsp; 
    &nbsp; &nbsp; &nbsp; the buffer is driving high.</FONT><FONT face=sans-serif 
    size=2><BR></FONT><BR><FONT face=sans-serif size=2>Kind regards,</FONT> 
    <BR><BR><FONT face=sans-serif size=2>Rob</FONT> <BR><FONT face=sans-serif 
    size=2>__________________________________________________________________________<BR>Rob 
    Mataheroe &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; Philips Semiconductors bv<BR>P.G. Logic Product Group 
    PD&amp;S &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Building 
    AM1.108<BR>Senior Design Modeling Engineer &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; Gerstweg 2<BR>Tel. ++31 (0)24 353 2370 &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    6534 AE Nijmegen<BR>Fax. ++31 (0)24 353 2820 &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
    &nbsp;The Netherlands<BR>Telework: 036-5225406 (From PS Nijm.: 
    **0731)<BR>Email: [email-masked] &nbsp; &nbsp;<BR>Seri: 
    matahero@nyhp04<BR></FONT><BR><BR><BR>
    <TABLE width="100%">
      <TBODY>
      <TR vAlign=top>
        <TD>
        <TD><BR><BR><BR><BR><BR><FONT face=sans-serif size=1><B>"Mirmak, 
          Michael" &lt;[email-masked]&gt;</B></FONT> 
          <P><FONT face=sans-serif size=1>Sent by: </FONT><BR><FONT 
          face=sans-serif size=1>[email-masked]</FONT> 
          <P><FONT face=sans-serif size=1>07/11/03 06:19 AM</FONT> <BR></P>
        <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; 
          </FONT><BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; 
          To: &nbsp; &nbsp; &nbsp; 
          &nbsp;&lt;[email-masked]&gt;<BR>&lt;[email-masked]&gt;</FONT> 
          <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; cc: 
          &nbsp; &nbsp; &nbsp; &nbsp;(bcc: Rob Mataheroe/NYM/SC/PHILIPS)</FONT> 
          <BR><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: 
          &nbsp; &nbsp; &nbsp; &nbsp;[IBIS] BIRD82 - Clarification of Clamp 
          Table Use</FONT> 
          <P><FONT face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; 
          Classification: &nbsp; &nbsp; &nbsp; &nbsp;</FONT> 
      <BR></P></TD></TR></TBODY></TABLE><BR><BR><BR><FONT face="Courier New" 
    size=2><BR>The following BIRD is posted on behalf of Lynne Green and Robert 
    Haller.<BR><BR>It will be discussed at the July 18, 2003 IBIS Open 
    Forum<BR>teleconference.<BR><BR>- Michael Mirmak<BR>&nbsp;Intel 
    Corp.<BR>&nbsp;Chair, EIA/IBIS Open 
    Forum<BR><BR><BR>************************************************************************<BR>****<BR>************************************************************************<BR>****<BR>&nbsp; 
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Buffer 
    Issue Resolution Document &nbsp;(BIRD)<BR><BR>BIRD ID#: &nbsp; &nbsp; &nbsp; 
    82<BR>ISSUE TITLE: &nbsp; &nbsp;Clarification of Clamp Table 
    Use<BR>REQUESTOR: &nbsp; &nbsp; &nbsp;Lynne Green, Cadence, and Robert 
    Haller, SiSoft<BR>DATE SUBMITTED: June 27, 2003<BR>DATE ACCEPTED BY IBIS 
    OPEN FORUM: 
    &nbsp;Pending<BR><BR>************************************************************************<BR>****<BR>************************************************************************<BR>****<BR><BR>STATEMENT 
    OF THE ISSUE:<BR><BR>Double-counting of clamp currents is the result of 
    confusion over how<BR>the<BR>clamp currents are summed by the tools. 
    &nbsp;Model makers are often unsure<BR>if<BR>clamps are always active, or 
    whether the [Power Clamp] works only with<BR>the<BR>[Pullup] and the [GND 
    Clamp] only with the [Pulldown]. &nbsp;This is<BR>difficult,<BR>if not 
    impossible, to detect with a 
    parser.<BR><BR>************************************************************************<BR>****<BR><BR>STATEMENT 
    OF THE RESOLVED SPECIFICATIONS:<BR><BR>Old text:<BR>| &nbsp; &nbsp; &nbsp; 
    &nbsp; It is assumed that the simulator sums the clamp tables<BR>| &nbsp; 
    &nbsp; &nbsp; &nbsp; together with the appropriate [Pullup] or [Pulldown] 
    table<BR>| &nbsp; &nbsp; &nbsp; &nbsp; when a buffer is driving high or low, 
    respectively. &nbsp;From this<BR>| &nbsp; &nbsp; &nbsp; &nbsp; assumption 
    and the nature of 3-statable buffers, it follows<BR>| &nbsp; &nbsp; &nbsp; 
    &nbsp; that the data in the clamping table sections are handled as<BR>| 
    &nbsp; &nbsp; &nbsp; &nbsp; constantly present tables and the [Pullup] and 
    [Pulldown]<BR>| &nbsp; &nbsp; &nbsp; &nbsp; tables are used only when needed 
    in the simulation.<BR><BR>Proposed text:<BR>| &nbsp; &nbsp; &nbsp; &nbsp; It 
    is assumed that the simulator will sum both clamp tables<BR>| &nbsp; &nbsp; 
    &nbsp; &nbsp; (power and ground), if they exist, to the Pulldown table 
    when<BR>| &nbsp; &nbsp; &nbsp; &nbsp; the buffer is driving high. The 
    simulator will sum both clamp<BR>| &nbsp; &nbsp; &nbsp; &nbsp; tables (power 
    and ground), if they exist, to the Pulldown<BR>table<BR>| &nbsp; &nbsp; 
    &nbsp; &nbsp; when the buffer is driving low. &nbsp;The simulator will sum 
    both<BR>| &nbsp; &nbsp; &nbsp; &nbsp; clamp tables when the buffer is not 
    driving (input or 3-state<BR>| &nbsp; &nbsp; &nbsp; &nbsp; operation).<BR>| 
    &nbsp; &nbsp; &nbsp; &nbsp; It follows that the data in the clamping table 
    sections are<BR>| &nbsp; &nbsp; &nbsp; &nbsp; handled as constantly present 
    tables, while the [Pullup] and<BR>| &nbsp; &nbsp; &nbsp; &nbsp; [Pulldown] 
    tables are used only when needed in the 
    simulation.<BR><BR><BR>************************************************************************<BR>****<BR><BR>ANALYSIS 
    PATH/DATA THAT LED TO SPECIFICATION:<BR><BR>Comments from members of the 
    Quality committee, as well as others,<BR>indicated that some models 
    double-count clamp 
    currents.<BR><BR><BR>************************************************************************<BR>****<BR><BR>ANY 
    OTHER BACKGROUND INFORMATION:<BR><BR>Initially, it was suggested that this 
    be detected by the parser, but<BR>it was decided that this was too 
    difficult. &nbsp;This led to further<BR>discussion of why double-counting 
    occurred, and how clarification of<BR>the spec could help address the 
    issue.<BR><BR><BR>************************************************************************<BR>****<BR>-----------------------------------------------------------------<BR>|For 
    help or to subscribe/unsubscribe, email [email-masked]<BR>|with the 
    appropriate command message(s) in the body:<BR>|<BR>| &nbsp;help<BR>| 
    &nbsp;subscribe &nbsp; ibis &nbsp; &nbsp; &nbsp; &lt;optional e-mail 
    address, if different&gt;<BR>| &nbsp;subscribe &nbsp; ibis-users 
    &lt;optional e-mail address, if different&gt;<BR>| &nbsp;unsubscribe ibis 
    &nbsp; &nbsp; &nbsp; &lt;optional e-mail address, if different&gt;<BR>| 
    &nbsp;unsubscribe ibis-users &lt;optional e-mail address, if 
    different&gt;<BR>|<BR>|or email a request to 
    [email-masked].<BR>|<BR>|IBIS reflector archives exist 
    under:<BR>|<BR>| &nbsp;http://www.eda.org/pub/ibis/email_archive/ 
    &nbsp;Recent<BR>| &nbsp;http://www.eda.org/pub/ibis/users_archive/ 
    &nbsp;Recent<BR>| &nbsp;http://www.eda.org/pub/ibis/email/ &nbsp; &nbsp; 
    &nbsp; &nbsp; &nbsp;E-mail since 
1993<BR></FONT><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

- ------_=_NextPart_001_01C347D7.80781C09--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

End of ibis-users V1 #26
************************