From owner-ibis Sat Mar  3 09:59:55 2001
Received: from nwcst286.netaddress.usa.net (nwcst286.netaddress.usa.net [204.68.23.31])
	by server.eda.org (8.11.0/8.11.0) with SMTP id f23Hxt114505
	for <ibis-users@eda.org>; Sat, 3 Mar 2001 09:59:55 -0800 (PST)
Received: (qmail 5795 invoked by uid 60001); 3 Mar 2001 10:04:05 -0000
Message-ID: <20010303100405.5794.qmail@nwcst286.netaddress.usa.net>
Received: from 204.68.23.31 by nwcst286 for [202.169.129.72] via web-mailer() on Sat Mar  3 10:04:05 GMT 2001
Date:  3 Mar 2001 03:04:05 MST
From: nikhil p <nikil.p@usa.net>
To: ibis-users@eda.org
Subject: 
X-Mailer: USANET web-mailer ()
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f23I1G114506

I wants to do ibis connector modelling .For modelling purpose, how should i
determine the inductance,capacitance and resistance values of the pins of a
connector . in the datasheets nothing is given about  
these values. please help me out. thanks in advance.

..nikhil

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
 
From owner-ibis Mon Mar  5 07:08:36 2001
Received: from ausxc08.us.dell.com (ausxc08.us.dell.com [143.166.99.216])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f25F8Z124183
	for <ibis-users@eda.org>; Mon, 5 Mar 2001 07:08:35 -0800 (PST)
Received: by ausxc08.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <F3MKT8Y8>; Mon, 5 Mar 2001 09:03:43 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F83E@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: nikil.p@usa.net, ibis-users@eda.org
Subject: RE: connector modeling for IBIS
Date: Mon, 5 Mar 2001 09:03:33 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0A585.76C474D6"

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

------_=_NextPart_000_01C0A585.76C474D6
Content-Type: text/plain;
	charset="iso-8859-1"

Nikhil,
You didn't say whether you wanted to use measurements or a field solver or
both (recommended) to determine the values or whether you need help
understanding the IBIS specification.

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


> -----Original Message-----
> From: nikhil p [mailto:nikil.p@usa.net]
> Sent: Saturday, March 03, 2001 4:04 AM
> To: ibis-users@eda.org
> Subject: 
> 
> 
> I wants to do ibis connector modelling .For modelling 
> purpose, how should i
> determine the inductance,capacitance and resistance values of 
> the pins of a
> connector . in the datasheets nothing is given about  
> these values. please help me out. thanks in advance.
> 
> ..nikhil
> 
> ____________________________________________________________________
> Get free email and a permanent address at 
> http://www.netaddress.com/?N=1
> 


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

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

------_=_NextPart_000_01C0A585.76C474D6--
 
From owner-ibis Mon Mar  5 13:04:51 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f25L4n125888;
	Mon, 5 Mar 2001 13:04:49 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id NAA16491; Mon, 5 Mar 2001 13:04:53 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FW9BGNA7; Mon, 5 Mar 2001 13:04:52 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3AA3FF72.B3313EC1@mentor.com>
Date: Mon, 05 Mar 2001 13:04:50 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: si-list@silab.eng.sun.com, ibis@eda.org, ibis-users@eda.org
CC: "Ross, Bob" <bob_ross@mentorg.com>
Subject: EUROPEAN IBIS SUMMIT MEETING DRAFT AGENDA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

Here is a draft Agenda of the European IBIS Summit Meeting
scheduled on Friday, March 16, 2001 in Munich Germany.
We will have a full, all day meeting with interesting
presentations and discussions.

If you plan to attend and have not yet signed up, please
notify Karine Loudet:

  karine_loudet@mentor.com

If any of the presenters have problems with the time
slots, let me know.  A final agenda will be sent out
later this week.

Bob Ross
Mentor Graphics
bob_ross@mentor.com

                         EUROPEAN IBIS SUMMIT MEETING
                           Astron Hotel/Neue Messe
                  Eggenfeldener Strasse 100, Munich Germany
                               MARCH 16, 2001

8:30    REFRESHMENTS

9:00    INTRODUCTIONS AND PROGRAM
        Bob Ross, Mentor Graphics, USA 

9:30    Experiences with and Tips for IBIS Models
        Eckhard Lenski, Siemens AG, Germany

10:00   Extraction of Key IBIS Parameters for Easier Model Selection
        John Barrie, Zuken, England

10:30   BREAK

10:45   DOGEN, A Siemens Internal Model Tool, Extension 1999 - 2001
        Hans Pichlmaier, Siemens AG, Germany

11:15   LVDS Modeling
        Hazem Hegazy and Mohammed Korany, Mentor Graphics, Egypt

12:00   LUNCH

13:00   STTL-2 Modeling Experiences
        Bernhard Unger, Siemens AG, Germany

13:30   CAN (Controller Area Network) Bus Modeling
        Manfred Maurer, Siemens AG, Germany

14:00   EMC Standardization Progress
        Jean-Claude Perrin, Texas Instruments, France

14:15   EMC Models
        Christian Marot, Siemens, France

14:30   Parasitic IC Emisson Modeling
        Etienne Sicard, National Institute of Applied Science, Toulouse, France

15:00   BREAK

15:15   Ground-Noise Model
        Mariusz Faferko, Fraunhofer Institute Reliability and Microintegration,
        Germany

15:45   Radiated Emission Model for IC
        Peter Kralicek, Fraunhofer Institute Reliability and Microintegration,
        Germany

16:15   Points of View for High Frequency IBIS Models
        Gerald Bannert, Siemens AG, Germany
  
16:30   IBIS-X
        Arpad Muranyi, Intel, USA

16:55   CONCLUDING ITEMS
        Bob Ross, Mentor Graphics, USA 

17:00   END
 
From owner-ibis Tue Mar  6 16:21:31 2001
Received: from mail02-oak.pilot.net (mail-oak-2.pilot.net [198.232.147.17])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f270LP102515
	for <ibis-users@eda.org>; Tue, 6 Mar 2001 16:21:26 -0800 (PST)
Received: from newsgate.xilinx.com (mailgate.xilinx.com [149.199.60.204]) by mail02-oak.pilot.net with ESMTP id QAA24273 for <ibis-users@eda.org>; Tue, 6 Mar 2001 16:21:35 -0800 (PST)
Received: from cliff.xsj.xilinx.com (cliff [149.199.38.103])
	by newsgate.xilinx.com (8.9.3/8.8.7) with ESMTP id QAA12789
	for <ibis-users@eda.org>; Tue, 6 Mar 2001 16:21:07 -0800 (PST)
Received: from newman.xilinx.com (newman [149.199.37.215])
	by cliff.xsj.xilinx.com (8.9.3/8.8.7) with ESMTP id QAA14657
	for <ibis-users@eda.org>; Tue, 6 Mar 2001 16:21:01 -0800 (PST)
Received: from xilinx.com ([149.199.9.124]) by newman.xilinx.com
          (Netscape Messaging Server 4.15) with ESMTP id G9SWZ400.AGV for
          <ibis-users@eda.org>; Tue, 6 Mar 2001 16:21:04 -0800 
Message-ID: <3AA57DCF.187384A1@xilinx.com>
Date: Tue, 06 Mar 2001 16:16:15 -0800
From: "Prasad Rau" <Prasad.Rau@xilinx.com>
Organization: Xilinx, Inc.
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@eda.org
Subject: Rise and Fall times in IBIS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I have a question regarding the dv/dt_r and dv/dt_f  values that IBIS
reports.
It is unclear to me whether IBIS models an unloaded buffer in
determining these
values or it simulates using  Cref capacitance value to determine
values for dv/dt_r and dv/dt_f. It was not obvious to me from the IBIS
documentation.

Appreciate any feedback I can get in this regard.


Thanks,


Prasad Rau

 
From owner-ibis Tue Mar  6 16:42:20 2001
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f270gH102605
	for <ibis-users@eda.org>; Tue, 6 Mar 2001 16:42:18 -0800 (PST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA15436;
	Wed, 7 Mar 2001 00:41:24 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 07 Mar 2001 00:41:24 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <GLBGG7V4>; Tue, 6 Mar 2001 16:41:21 -0800
Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A7551@orsmsx49.jf.intel.com>
From: "Peters, Stephen" <stephen.peters@intel.com>
To: "'Prasad Rau'" <Prasad.Rau@xilinx.com>, ibis-users@eda.org
Subject: RE: Rise and Fall times in IBIS
Date: Tue, 6 Mar 2001 16:41:11 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"


Hi Prasad:

  The dv/dt_r and dv/dt_f values are taken with a pure resistive load.
C_comp
is included in the circuit (it is unavoidable), but there should be no Cref.

  By the way, the same rules also apply when taking the [Rising Waveform]
and [Falling Waveform] data.

  Regards,
  Stephen Peters
  Intel Corp.



-----Original Message-----
From: Prasad Rau [mailto:Prasad.Rau@xilinx.com]
Sent: Tuesday, March 06, 2001 4:16 PM
To: ibis-users@eda.org
Subject: Rise and Fall times in IBIS


Hi,

I have a question regarding the dv/dt_r and dv/dt_f  values that IBIS
reports.
It is unclear to me whether IBIS models an unloaded buffer in
determining these
values or it simulates using  Cref capacitance value to determine
values for dv/dt_r and dv/dt_f. It was not obvious to me from the IBIS
documentation.

Appreciate any feedback I can get in this regard.


Thanks,


Prasad Rau


 
From owner-ibis Tue Mar  6 18:01:22 2001
Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2721K102969
	for <ibis-users@eda.org>; Tue, 6 Mar 2001 18:01:21 -0800 (PST)
Received: from labonte.com (sj-natpool-220.cisco.com [128.107.248.220])
	by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f2721MI12619;
	Tue, 6 Mar 2001 18:01:22 -0800
Message-ID: <3AA59669.BF0DF7E0@labonte.com>
Date: Tue, 06 Mar 2001 21:01:13 -0500
From: Mike LaBonte <mike@labonte.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BDP81800  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Prasad Rau <Prasad.Rau@xilinx.com>
CC: ibis-users@eda.org
Subject: Re: Rise and Fall times in IBIS
References: <3AA57DCF.187384A1@xilinx.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Prasad,

The IBIS spec mentions R_load, as shown below:

|=============================================================================
|     Keyword:  [Ramp]
|    Required:  Yes, except for inputs, terminators, Series and Series_switch
|               model types.
| Description:  Defines the rise and fall times of a buffer.  The ramp rate
|               does not include packaging but does include the effects of the
|               C_comp parameter.
|  Sub-Params:  dV/dt_r, dV/dt_f, R_load
| Usage Rules:  The rise and fall time is defined as the time it takes the
|               output to go from 20% to 80% of its final value.  The ramp
|               rate is defined as:
|
|               dV          20% to 80% voltage swing
|               -- = ----------------------------------------
|               dt   Time it takes to swing the above voltage
|
|               The ramp rate must be specified as an explicit fraction and
|               must not be reduced.  The [Ramp] values can use "NA" for the
|               min and max values only.  The R_load subparameter is optional
|               if the default 50 ohm load is used.  The R_load subparameter
|               is required if a non-standard load is used.
|-----------------------------------------------------------------------------
[Ramp]
| variable      typ             min             max
dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
R_load = 300ohms

Admittedly it fails to say much about it, but Ramp is determined with a
purely resistive load. Bear in mind that simulators may not use Ramp data
where Rising and Falling Waveforms exist. These are where dynamic behavior
and capacitive loads are really considered.

Mike LaBonte

Prasad Rau wrote:
> 
> Hi,
> 
> I have a question regarding the dv/dt_r and dv/dt_f  values that IBIS
> reports.
> It is unclear to me whether IBIS models an unloaded buffer in
> determining these
> values or it simulates using  Cref capacitance value to determine
> values for dv/dt_r and dv/dt_f. It was not obvious to me from the IBIS
> documentation.
> 
> Appreciate any feedback I can get in this regard.
> 
> Thanks,
> 
> Prasad Rau
 
From owner-ibis Wed Mar  7 05:56:43 2001
Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f27Due106377
	for <ibis-users@eda.org>; Wed, 7 Mar 2001 05:56:42 -0800 (PST)
Received: (from smtpd@localhost)
	by ns01.newbridge.com (8.9.2/8.9.2) id IAA08580
	for <ibis-users@eda.org>; Wed, 7 Mar 2001 08:45:16 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com"
 via SMTP by ns01.newbridge.com, id smtpdAAARAFcc_; Wed Mar  7 08:45:13 2001
Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ibis-users@eda.org; Wed, 7 Mar 2001 08:51:06 -0500
Received: from cid.alcatel.com ([138.120.63.177])
          by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6)
           with ESMTP id AAA3CD3 for <ibis-users@eda.org>;
          Wed, 7 Mar 2001 08:51:05 -0500
Sender: "Jason Leung" <jleung@cid.alcatel.com>
Message-Id: <3AA63CEE.74E57619@cid.alcatel.com>
Date: Wed, 07 Mar 2001 08:51:43 -0500
From: Jason Leung <jleung@cid.alcatel.com>
Organization: Alcatel
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: ibis-users@eda.org
Subject: rising and falling time in IBIS and XTK
Content-Type: multipart/mixed;
 boundary="------------BF4423C4194A4C6051FA3765"

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

  Hello:
I have a question regarding the rising and falling time, I understand
that the ibis2xtk is going to translate the ibis model to Quad (xtk)
model, but when I compare the original rising and falling waveform (ibis
model) with the  rising and falling waveform after the translation( Quad
model), I have found a big difference in the  rising and falling time
(150 ps) between those two models.
I know that the translator is going to remove the non-monotonic points
inside the ibis model , in addition to that is there any more reasons
why so large in the time difference.
Is there any remedy to correct the rise time and make it closer to the
values with the ibis model?

I appreciate any feedback I can get in this regard.

Thanks

Jason Leung


--------------BF4423C4194A4C6051FA3765
Content-Type: text/x-vcard; charset=us-ascii;
 name="jleung.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jason Leung
Content-Disposition: attachment;
 filename="jleung.vcf"

begin:vcard 
n:Leung;Jason
tel;fax:613-5993642
tel;work:613-7844425
x-mozilla-html:FALSE
org:Alcatel CID;EMC ENGINEERING
adr:;;600 March Road;Kanata;Ontario;K2K 2E6;CANADA
version:2.1
email;internet:jleung@cid.alcatel.com
title:SI/EMC ENGINEER
x-mozilla-cpt:;-31088
fn:Jason Leung
end:vcard

--------------BF4423C4194A4C6051FA3765--

 
From owner-ibis Wed Mar  7 06:48:52 2001
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f27Emh106646
	for <ibis-users@eda.org>; Wed, 7 Mar 2001 06:48:47 -0800 (PST)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA16081;
	Wed, 7 Mar 2001 15:48:50 +0100 (MET)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA26006;
	Wed, 7 Mar 2001 15:48:49 +0100 (MET)
Received: by MCHH246E with Internet Mail Service (5.5.2653.19)
	id <GM75S5DK>; Wed, 7 Mar 2001 15:48:49 +0100
Message-ID: <AFC76835727DD211A7C20008C71EAF1E01BB1473@MCHH230E>
From: Lenski Eckhard <Eckhard.Lenski@icn.siemens.de>
To: "'Jason Leung'" <jleung@cid.alcatel.com>
Cc: ibis-users@eda.org
Subject: AW: rising and falling time in IBIS and XTK
Date: Wed, 7 Mar 2001 15:48:46 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f27EnH106647

Jason,

You have to be aware, that in IBIS the rise and the falltime are only for the specific waveform.

When You look at the QUAD-Model, there is one risetime and one falltime for both rising/falling curves.

What happens is that if there is a delaytime for the lets say rising to GND waveform compared with the rising waveform to vcc, this delay will be added to the QUAD overall risetime.

In other words:
for IBIS 

rise  50 gnd starts at 0ns and end at 5ns   (  risetime will be  5ns )
rise  50 vcc starts at 0.5ns and ends at 6 ns  ( risetime will  be 5.5ns )

but the risetime in QUAD will now be    6ns


I hope this solves your problem

Eckhard  



Eckhard Lenski
Siemens AG		ICN M TC 6
Hofmannstr.51	81359 München
Tel :	0049 89 722 27776
Fax:	0049 89 722 44692
Email:	eckhard.lenski@icn.siemens.de

> -----Ursprüngliche Nachricht-----
> Von:	Jason Leung [SMTP:jleung@cid.alcatel.com]
> Gesendet am:	Mittwoch, 7. März 2001 14:52
> Cc:	ibis-users@eda.org
> Betreff:	rising and falling time in IBIS and XTK
> 
>   Hello:
> I have a question regarding the rising and falling time, I understand
> that the ibis2xtk is going to translate the ibis model to Quad (xtk)
> model, but when I compare the original rising and falling waveform (ibis
> model) with the  rising and falling waveform after the translation( Quad
> model), I have found a big difference in the  rising and falling time
> (150 ps) between those two models.
> I know that the translator is going to remove the non-monotonic points
> inside the ibis model , in addition to that is there any more reasons
> why so large in the time difference.
> Is there any remedy to correct the rise time and make it closer to the
> values with the ibis model?
> 
> I appreciate any feedback I can get in this regard.
> 
> Thanks
> 
> Jason Leung
>  << Datei: Card for Jason Leung >> 
 
From owner-ibis Thu Mar  8 18:21:32 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f292LV115744;
	Thu, 8 Mar 2001 18:21:32 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id SAA06643; Thu, 8 Mar 2001 18:21:38 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FW9BGY1Q; Thu, 8 Mar 2001 18:21:37 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3AA83E31.6FAF545E@mentor.com>
Date: Thu, 08 Mar 2001 18:21:37 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org, ibis-users@eda.org, si-list@silab.eng.sun.com
Subject: EUROPEAN IBIS SUMMIT AGENDA 3/16/01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

Here is the Agenda for the European IBIS Summit Meeting .  It
has some updated titles and slight changes in the presentation
order.

If you plan to attend and have not yet signed up, please
let me know.

We are looking forward to a productive meeting.

Bob Ross
Mentor Graphics
bob_ross@mentor.com

                         EUROPEAN IBIS SUMMIT MEETING
                           Astron Hotel/Neue Messe
                  Eggenfeldener Strasse 100, Munich Germany
                               MARCH 16, 2001

8:30    REFRESHMENTS

9:00    INTRODUCTIONS AND PROGRAM
        Bob Ross, Mentor Graphics, USA 

9:30    Experiences with and Tips for IBIS Models
        Eckhard Lenski, Siemens AG, Germany

10:00   Extraction of Key IBIS Parameters for Easier Model Selection
        John Berrie, Zuken, England and Michael Schaeder, Zuken Germany

10:30   BREAK

10:45   DOGEN, A Siemens Internal Model Tool, Extensions 1999 - 2001
        Hans Pichlmaier, Siemens AG, Germany

11:15   LVDS Modeling
        Hazem Hegazy and Mohammed Korany, Mentor Graphics, Egypt

12:00   LUNCH

13:00   SSTL-2 Modeling Experiences
        Bernhard Unger, Siemens AG, Germany

13:30   CAN (Controller Area Network) Bus Modeling
        Manfred Maurer, Siemens AG, Germany

14:00   Parasitic IC Emission Modeling
        Etienne Sicard, National Institute of Applied Science, France

14:30   EMC Models
        Christian Marot, Siemens, France

14:45   EMC Standardization Progress
        Jean Claude Perrin, Texas Instruments, France

15:00   BREAK

15:15   Modelling of Ground-Noise for Circuits with Short-Channel Transistors
        Mariusz Faferko, Fraunhofer Institute Reliability and
        Microintegration, Germany

15:45   An Electromagnetic Emission Model for Integrated Circuits
        Peter Kralicek, Fraunhofer Institute Reliability and
        Microintegration, Germany

16:15   Points of View for High Frequency IBIS Models
        Gerald Bannert, Siemens AG, Germany
  
16:30   IBIS-X and the IBIS Macro Language
        Stephen Peters and Arpad Muranyi, Intel, USA

16:55   CONCLUDING ITEMS
        Bob Ross, Mentor Graphics, USA 

17:00   END
 
From owner-ibis Fri Mar  9 06:43:04 2001
Received: from showboat.teradyne.com (showboat.teradyne.com [198.51.251.10])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f29Eh2120000;
	Fri, 9 Mar 2001 06:43:03 -0800 (PST)
Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195])
	by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id JAA22557;
	Fri, 9 Mar 2001 09:43:12 -0500 (EST)
From: owner-si-list@silab.eng.sun.com
Received: from jaypeak.corp.teradyne.com (jaypeak.corp.teradyne.com [131.101.17.23]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with ESMTP id JAA07370; Fri, 9 Mar 2001 09:43:11 -0500 (EST)
Received: from chorus.teradyne.com ([131.101.1.195]) by madriver.corp.teradyne.com (Lotus
 Domino Release 5.0.4a) with ESMTP id 2001030821350999:97611 ; Thu, 8 Mar
 2001 21:35:09 -0500
Received: from kiki.icd.teradyne.com (kiki.icd.teradyne.com [131.101.10.126]) by
 chorus.teradyne.com (8.8.8+Sun/8.7.1) with ESMTP id VAA13441 for <charles_bishop@notes.teradyne.com>; Thu, 8
 Mar 2001 21:36:33 -0500 (EST)
Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by kiki.icd.teradyne.com
 (8.9.3+Sun/8.9.3) with ESMTP id VAA19326 for <bishop@ICD.teradyne.com>; Thu, 8
 Mar 2001 21:36:33 -0500 (EST)
Received: from showboat.teradyne.com (showboat.teradyne.com [198.51.251.10]) by
 chorus.teradyne.com (8.8.8+Sun/8.7.1) with ESMTP id VAA13435 for <bishop@ICD.Teradyne.COM>; Thu, 8
 Mar 2001 21:36:32 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by showboat.teradyne.com
 (8.8.8+Sun/8.8.8) with ESMTP id VAA12330 for <bishop@ICD.Teradyne.COM>; Thu, 8
 Mar 2001 21:36:32 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with
 ESMTP id SAA07635; Thu, 8 Mar 2001 18:35:09 -0800 (PST)
Received: from silab.eng.sun.com (silab.Eng.Sun.COM [129.146.121.121]) by engmail2.Eng.Sun.COM
 (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA07196; Thu, 8 Mar 2001 18:35:02
 -0800 (PST)
Received: by silab.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA08848; Thu, 8 Mar 2001 18:22:09
 -0800
Received: from engmail1.Eng.Sun.COM by silab.eng.sun.com (SMI-8.6/SMI-SVR4) id
 SAA08844; Thu, 8 Mar 2001 18:22:03 -0800
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM
 (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05123 for <si-list@silab.eng.sun.com>; Thu, 8
 Mar 2001 18:21:47 -0800 (PST)
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by patan.sun.com
 (8.9.3+Sun/8.9.3) with ESMTP id SAA10555 for <si-list@silab.eng.sun.com>; Thu, 8
 Mar 2001 18:21:46 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id
 SAA06643; Thu, 8 Mar 2001 18:21:38 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com
 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id
 FW9BGY1Q; Thu, 8 Mar 2001 18:21:37 -0800
Message-ID: <3AA83E31.6FAF545E@mentor.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
Subject: [SI-LIST] : EUROPEAN IBIS SUMMIT AGENDA 3/16/01
Reply-To: Bob Ross <bob_ross@mentorg.com>
X-MIMETrack: Itemize by SMTP Server on MadRiver/Bos/Teradyne(Release 5.0.4a |July 24, 2000) at
 03/08/2001 09:35:10 PM,
	MIME-CD by Router on Aspen/Bos/Teradyne(Release 5.0.6a |January 17, 2001) at
 03/08/2001 09:35:18 PM,
	MIME-CD complete at 03/08/2001 09:35:18 PM,
	Serialize by Router on JayPeak/Teradyne(Release 5.0.4a |July 24, 2000) at
 03/09/2001 09:41:33 AM
To: ibis@eda.org, ibis-users@eda.org, si-list@silab.eng.sun.com
Sender: charles_bishop@notes.teradyne.com
Date: Fri, 9 Mar 2001 09:41:53 -0500
Content-type: text/plain; charset=us-ascii


To All:

Here is the Agenda for the European IBIS Summit Meeting .  It
has some updated titles and slight changes in the presentation
order.

If you plan to attend and have not yet signed up, please
let me know.

We are looking forward to a productive meeting.

Bob Ross
Mentor Graphics
bob_ross@mentor.com

                         EUROPEAN IBIS SUMMIT MEETING
                           Astron Hotel/Neue Messe
                  Eggenfeldener Strasse 100, Munich Germany
                               MARCH 16, 2001

8:30    REFRESHMENTS

9:00    INTRODUCTIONS AND PROGRAM
        Bob Ross, Mentor Graphics, USA

9:30    Experiences with and Tips for IBIS Models
        Eckhard Lenski, Siemens AG, Germany

10:00   Extraction of Key IBIS Parameters for Easier Model Selection
        John Berrie, Zuken, England and Michael Schaeder, Zuken Germany

10:30   BREAK

10:45   DOGEN, A Siemens Internal Model Tool, Extensions 1999 - 2001
        Hans Pichlmaier, Siemens AG, Germany

11:15   LVDS Modeling
        Hazem Hegazy and Mohammed Korany, Mentor Graphics, Egypt

12:00   LUNCH

13:00   SSTL-2 Modeling Experiences
        Bernhard Unger, Siemens AG, Germany

13:30   CAN (Controller Area Network) Bus Modeling
        Manfred Maurer, Siemens AG, Germany

14:00   Parasitic IC Emission Modeling
        Etienne Sicard, National Institute of Applied Science, France

14:30   EMC Models
        Christian Marot, Siemens, France

14:45   EMC Standardization Progress
        Jean Claude Perrin, Texas Instruments, France

15:00   BREAK

15:15   Modelling of Ground-Noise for Circuits with Short-Channel
Transistors
        Mariusz Faferko, Fraunhofer Institute Reliability and
        Microintegration, Germany

15:45   An Electromagnetic Emission Model for Integrated Circuits
        Peter Kralicek, Fraunhofer Institute Reliability and
        Microintegration, Germany

16:15   Points of View for High Frequency IBIS Models
        Gerald Bannert, Siemens AG, Germany

16:30   IBIS-X and the IBIS Macro Language
        Stephen Peters and Arpad Muranyi, Intel, USA

16:55   CONCLUDING ITEMS
        Bob Ross, Mentor Graphics, USA

17:00   END

**** To unsubscribe from si-list or si-list-digest: send e-mail to
majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at  http://www.qsl.net/wb6tpu
****


 
From owner-ibis Sun Mar 11 19:50:17 2001
Received: from palgong.knu.ac.kr (palgong.kyungpook.ac.kr [155.230.12.2])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2C3oE105174
	for <ibis-users@eda.org>; Sun, 11 Mar 2001 19:50:16 -0800 (PST)
Received: from adagio ([155.230.13.223])
	by palgong.knu.ac.kr (8.11.0/8.11.0) with SMTP id f2C3pLj08096
	for <ibis-users@eda.org>; Mon, 12 Mar 2001 12:51:21 +0900 (KST)
Message-ID: <000d01c0aaa7$a2fd6630$df0de69b@knu.ac.kr>
From: =?ks_c_5601-1987?B?w9a5q7+t?= <adagio@palgong.knu.ac.kr>
To: <ibis-users@eda.org>
Subject: I'm concern of IBIS model...
Date: Mon, 12 Mar 2001 12:50:52 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01C0AAF3.125FFFB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C0AAF3.125FFFB0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGVsbG8sDQoNCk15IG5hbWUgaXMgTW9vLXlldWwgQ2hvaSBhbmQgSSdtIGEgZ3JhZHV0ZSBzdHVk
ZW50IG9mIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYS4NCkkgYW0gY29uY2Vy
bmVkIG9mIElCSVMgdG8gU3BpY2UoZm9yIGNvbnZpbmVuY2Ugb2Ygc3BpY2Ugc2ltdWxhdGlvbiBm
b3IgZGlnaXRhbCBjaGlwKSBhbmQgaGF2ZSBzdHVkaWVkIGEgZmV3IG1vbnRocyBvbiB0aGUgYmFz
aXMgb2YgdGhpcyBJQklTIGZvcnVtLg0KV2VsbCwgdGhlIG1lYW5pbmdzIG9mIERVVChSX2R1dCwg
TF9kdXQsIENfZHV0KSBpcyBub3QgY2xlYXIgdG8gbWUgYW5kIEkgZG9uJ3QgdW5kZXJzdGFuZCB0
aGUgZGlmZmVyZW5jZSBvZiBQS0cgYW5kIERVVC4NClBsZWFzZSBzZW5kIHlvdXIgb3BpbmlvbiB0
byBtZSBmb3IgdGhpcyBxdWVzdGlvbi4NClBsZWFzZSBkbyAgbWUgYSBmYXZvciBhbmQgSSBhbSBs
b29raW5nIGZvd2FyZCB0byB5b3VyIHJlcGx5Lg0KSGF2ZSBhIG5pY2UgIGRheS4NCg0KQmVzdCBy
ZWdhcmRzLA0KTW9vLXlldWwgQ2hvaQ0KZ3JhZHVhdGUgc3R1ZGVudCBvZiBLTlUNCg==

------=_NextPart_000_000A_01C0AAF3.125FFFB0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB
RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLDwvRk9O
VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5NeSBuYW1lIGlz
IE1vby15ZXVsIENob2kgYW5kIEknbSBhIGdyYWR1dGUgc3R1ZGVudCBvZiANCkt5dW5ncG9vayBO
YXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9
Mj5JIGFtIGNvbmNlcm5lZCBvZiBJQklTIHRvIFNwaWNlKGZvciBjb252aW5lbmNlIG9mIHNwaWNl
IA0Kc2ltdWxhdGlvbiZuYnNwO2ZvciBkaWdpdGFsIGNoaXApIGFuZCBoYXZlIHN0dWRpZWQgYSBm
ZXcgbW9udGhzIG9uIHRoZSBiYXNpcyBvZiANCnRoaXMgSUJJUyBmb3J1bS48L0ZPTlQ+PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj5XZWxsLCB0aGUgbWVhbmluZ3Mgb2YgRFVUKFJfZHV0LCBMX2R1
dCwgQ19kdXQpIGlzIG5vdCBjbGVhciB0byANCm1lIGFuZCBJIGRvbid0IHVuZGVyc3RhbmQgdGhl
IGRpZmZlcmVuY2Ugb2YgUEtHIGFuZCBEVVQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl
PTI+UGxlYXNlIHNlbmQgeW91ciBvcGluaW9uIHRvIG1lIGZvciB0aGlzIHF1ZXN0aW9uLjwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48Rk9OVCBzaXplPTI+UGxlYXNlIGRv
Jm5ic3A7IG1lIGEgZmF2b3IgYW5kIEkgYW0gbG9va2luZyBmb3dhcmQgdG8geW91ciANCnJlcGx5
LjxCUj5IYXZlIGEgbmljZSZuYnNwOyBkYXkuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPkJlc3QgcmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG
T05UIHNpemU9Mj5Nb28teWV1bCBDaG9pPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+
Z3JhZHVhdGUgc3R1ZGVudCBvZiANCktOVTwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZ
PjwvSFRNTD4NCg==

------=_NextPart_000_000A_01C0AAF3.125FFFB0--

 
From owner-ibis Sun Mar 11 20:26:22 2001
Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2C4QM105343
	for <ibis-users@eda.org>; Sun, 11 Mar 2001 20:26:22 -0800 (PST)
Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345)
	id A9E5D182B; Sun, 11 Mar 2001 22:26:33 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42])
	by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 72C4419F8
	for <ibis-users@eda.org>; Sun, 11 Mar 2001 22:26:33 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <FT2J15K9>; Sun, 11 Mar 2001 23:26:32 -0500
Message-ID: <212CC57E84B8D111AD780000F84AA0490C713D82@mroexc2.tay.cpqcorp.net>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: ibis-users@eda.org
Subject: RE: I'm concern of IBIS model...
Date: Sun, 11 Mar 2001 23:22:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain

The expression "DUT" is an acronym that means "device under test" and is
frequently used by test engineers.  But this probably has only little
relevance to your question.

R_pkg, L_pkg, and C_pkg are the actual parameters of the IC package that the
customer gets with his IC.  But some of the measurements that become part of
the IBIS data sheet are done with no IC package or perhaps with a different
package.

R_dut, L_dut, and C_dut are sub-parameters of the [Rising Waveform] and
[Falling Waveform] sections.  They are the values of package resistance,
inductance, and capacitance used when these waveforms were measured, and
should usually be zero, that is, the measurements are best done on a die
alone without an IC package.  If these waveforms were measured with the
normal package, then R_dut, L_dut, and C_dut would equal R_pkg, L_pkg, and
C_pkg respectively.

Andy

 
From owner-ibis Tue Mar 13 06:36:05 2001
Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2DEa1114704
	for <ibis-users@eda.org>; Tue, 13 Mar 2001 06:36:03 -0800 (PST)
Received: (from smtpd@localhost)
	by ns01.newbridge.com (8.9.2/8.9.2) id JAA21235
	for <ibis-users@eda.org>; Tue, 13 Mar 2001 09:26:27 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com"
 via SMTP by ns01.newbridge.com, id smtpdHAAsOmJN_; Tue Mar 13 09:26:23 2001
Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ibis-users@eda.org; Tue, 13 Mar 2001 09:32:23 -0500
Received: from cid.alcatel.com ([138.120.63.177])
          by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6)
           with ESMTP id AAA60A6 for <ibis-users@eda.org>;
          Tue, 13 Mar 2001 09:32:22 -0500
Sender: "Jason Leung" <jleung@cid.alcatel.com>
Message-Id: <3AAE2FA9.FF73460D@cid.alcatel.com>
Date: Tue, 13 Mar 2001 09:33:13 -0500
From: Jason Leung <jleung@cid.alcatel.com>
Organization: Alcatel
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@eda.org
Subject: some questions with the IBIS models
Content-Type: multipart/mixed;
 boundary="------------1A3560193430DB4F67CEDE6A"

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

Hi All:
This is my second time to pose a question in the Si list. I just start
working as a Si engineer a few weeks ago
,and the problems that I am facing right now is trying to verifly the
IBIS model.
The procedure that I am following is like this:
1.use ibis2xtk to transfer the file from ibis to QUAD
2. then I use the scratchpad to build the schematic according to the
spec for the R-fix and Voltage
(i.e. I am building the six files for XNS)
3. then I use XNS to observe the waveform and check the rising and
falling waveform

My problem is even though I am building my schematic use scratchpad
according to the spec,
but my waveform can not acheive its full voltage swing . I wanted to
know why , and The way that
I should approach to fix this problem.

thanks to all of you that they can help to solve this problem as this is
very important for me to get this concept

thanks
Jason Leung ( Alcatel)



--------------1A3560193430DB4F67CEDE6A
Content-Type: text/x-vcard; charset=us-ascii;
 name="jleung.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jason Leung
Content-Disposition: attachment;
 filename="jleung.vcf"

begin:vcard 
n:Leung;Jason
tel;fax:613-5993642
tel;work:613-7844425
x-mozilla-html:FALSE
org:Alcatel CID;EMC ENGINEERING
adr:;;600 March Road;Kanata;Ontario;K2K 2E6;CANADA
version:2.1
email;internet:jleung@cid.alcatel.com
title:SI/EMC ENGINEER
x-mozilla-cpt:;-31088
fn:Jason Leung
end:vcard

--------------1A3560193430DB4F67CEDE6A--

 
From owner-ibis Tue Mar 13 08:34:06 2001
Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2DGY5115367
	for <ibis-users@eda.org>; Tue, 13 Mar 2001 08:34:06 -0800 (PST)
Received: from labonte.com (sj-natpool-220.cisco.com [128.107.248.220])
	by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f2DGYEI03030;
	Tue, 13 Mar 2001 08:34:14 -0800
Message-ID: <3AAE4BEF.1AC4CEB3@labonte.com>
Date: Tue, 13 Mar 2001 11:33:51 -0500
From: Mike LaBonte <mike@labonte.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BDP81800  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jason Leung <jleung@cid.alcatel.com>
CC: ibis-users@eda.org
Subject: Re: some questions with the IBIS models
References: <3AAE2FA9.FF73460D@cid.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jason,

Does ibischk3 pass the IBIS file without warnings? Ibischk3 will try
to warn you if the Rising and/or Falling waveforms are not matched to
the Pullup/Pulldown IV curves. A mismatch could cause the symptoms
you describe, but there could be other causes too. Check the XTK files
to see if the DRIVERSPEC V scale goes from 0.0 to 1.0 with the endpoints
at about the right times.

Mike LaBonte

Jason Leung wrote:
> 
> Hi All:
> This is my second time to pose a question in the Si list. I just start
> working as a Si engineer a few weeks ago
> ,and the problems that I am facing right now is trying to verifly the
> IBIS model.
> The procedure that I am following is like this:
> 1.use ibis2xtk to transfer the file from ibis to QUAD
> 2. then I use the scratchpad to build the schematic according to the
> spec for the R-fix and Voltage
> (i.e. I am building the six files for XNS)
> 3. then I use XNS to observe the waveform and check the rising and
> falling waveform
> 
> My problem is even though I am building my schematic use scratchpad
> according to the spec,
> but my waveform can not acheive its full voltage swing . I wanted to
> know why , and The way that
> I should approach to fix this problem.
> 
> thanks to all of you that they can help to solve this problem as this is
> very important for me to get this concept
> 
> thanks
> Jason Leung ( Alcatel)
 
From owner-ibis Tue Mar 13 15:49:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2DNnk500252
	for <ibis-users@eda.org>; Tue, 13 Mar 2001 15:49:47 -0800 (PST)
Received: from phys-ha1mpka.eng.sun.com ([129.146.122.34])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08537
	for <ibis-users@eda.org>; Tue, 13 Mar 2001 15:46:59 -0800 (PST)
Received: from rogue5 (rogue5 [129.146.121.231])
	by phys-ha1mpka.eng.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id PAA20426
	for <ibis-users@eda.org>; Tue, 13 Mar 2001 15:46:58 -0800 (PST)
Message-Id: <200103132346.PAA20426@phys-ha1mpka.eng.sun.com>
Date: Tue, 13 Mar 2001 15:46:58 -0800 (PST)
From: Stephen Muller <Stephen.Muller@Sun.COM>
Reply-To: Stephen Muller <Stephen.Muller@Sun.COM>
Subject: more on ibischk3 errors
To: ibis-users@eda.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: W9viyBS3YZ2bfLMlN1/vXQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 

All,

I am trying to validate an IBIS file that I created from s2ibis2.  I am 
comparing the simulated IBIS file(using Cadence tools) versus the simulation 
results obtained in spice.  At present the IBIS simulation doesn't quite reach 
the same high value as the spice.  I ran the ibis file through ibischk3(which I 
don't believe is used by the Cadence software that converts an IBIS file to a 
DML format).  This gave me errors that several people have commented on, namely 
that the endpoint values obtained from the Rising/Falling waveforms don't match 
those obtained when an equivalent load applied to the model's I-V tables.

What type of things should one look for when they get these errors?  How is 
ibischk3 calculating what values should be obtained from the I-V tables for the 
endpoints?  And how does ibischk3 decide if there is an error?  It reports back 
by what percentage the values are off, but how close do these have to be to 
avoid an error?

Thanks,
Stephen Muller



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

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

 
From owner-ibis Wed Mar 14 07:29:13 2001
Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2EFTA506188
	for <ibis-users@eda.org>; Wed, 14 Mar 2001 07:29:12 -0800 (PST)
Received: from labonte.com (sj-natpool-220.cisco.com [128.107.248.220])
	by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f2EFQBI15275;
	Wed, 14 Mar 2001 07:26:11 -0800
Message-ID: <3AAF8D7A.5BF1A164@labonte.com>
Date: Wed, 14 Mar 2001 10:25:46 -0500
From: Mike LaBonte <mike@labonte.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BDP81800  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Muller <Stephen.Muller@Sun.COM>
CC: ibis-users@eda.org
Subject: Re: more on ibischk3 errors
References: <200103132346.PAA20426@phys-ha1mpka.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen,

The Cadence software does run IBIS files through ibischk3, then it runs
additional checks. If there is even a 2% mismatch between the waveforms
and the IV tables, you really should find out why.

For example, using the Pulldown table and the test fixture values you can
figure out what the output voltage should be in the low state. This is what
ibischk3 does, and it prints the voltage for you. Now look at the waveforms.
Does the Rising waveform start at that voltage, and does the Falling waveform
end at that voltage? A common problem is that the simulation was not long enough,
and it never fully settled at the static level.

Take a plot of the Pulldown curve, and draw a line from I=0/V=V_fixture, at the
R_fixture resistor slope. The intersection of this line with the Pulldown curve
gives the static low state voltage and current. Ibischk3 takes the difference
between this voltage and the endpoint voltages. To get a percentage, it divides
by the difference between the high and low start voltages, I think (I no longer
have access to the source code).

More info can be gleaned from the IBIS BIRDs (http://www.vhdl.org/pub/ibis/birds)
and from the ibischk3 bug list (ftp://ftp.eda.org/pub/ibis/bugs/ibischk). Also, a
handy trick is to run ibis2signoise with the -curvedir switch, making it save all
waveforms and IV curves into .sim files so that sigwave can view them. Sigwave can
then import the waveforms produced by s2ibis2 simulation runs and those from
Cadence simulation runs, for comparison.

Mike LaBonte

Stephen Muller wrote:
> 
> All,
> 
> I am trying to validate an IBIS file that I created from s2ibis2.  I am
> comparing the simulated IBIS file(using Cadence tools) versus the simulation
> results obtained in spice.  At present the IBIS simulation doesn't quite reach
> the same high value as the spice.  I ran the ibis file through ibischk3(which I
> don't believe is used by the Cadence software that converts an IBIS file to a
> DML format).  This gave me errors that several people have commented on, namely
> that the endpoint values obtained from the Rising/Falling waveforms don't match
> those obtained when an equivalent load applied to the model's I-V tables.
> 
> What type of things should one look for when they get these errors?  How is
> ibischk3 calculating what values should be obtained from the I-V tables for the
> endpoints?  And how does ibischk3 decide if there is an error?  It reports back
> by what percentage the values are off, but how close do these have to be to
> avoid an error?
> 
> Thanks,
> Stephen Muller
> 
>   Stephen Muller
>   Electronic Component & Interconnect Technologies
>   Engineer
>   Phone: 650-786-3374 or x83374
>   e-mail Stephen.Muller@eng.sun.com
> 
>    _/_/_/  _/    _/  _/     _/
>   _/      _/    _/  _/_/   _/
>   _/_/_/ _/    _/  _/  _/ _/
>      _/ _/    _/  _/   _/_/
> _/_/_/  _/_/_/   _/     _/
> M  I  C  R  O  S  Y  S  T  E  M  S
>
 
From owner-ibis Mon Mar 19 12:23:42 2001
Received: from ext-ch1gw-3.online-age.net (ext-ch1gw-3.online-age.net [216.34.191.37])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2JKNe521740
	for <ibis-users@eda.org>; Mon, 19 Mar 2001 12:23:42 -0800 (PST)
Received: from int-ch1gw-1.online-age.net (int-ch1gw-1 [3.159.232.65])
	by ext-ch1gw-3.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id PAA25792
	for <ibis-users@eda.org>; Mon, 19 Mar 2001 15:20:25 -0500 (EST)
Received: from uswaumsxb4medge.med.ge.com (localhost [127.0.0.1])
	by int-ch1gw-1.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id PAA00345
	for <ibis-users@eda.org>; Mon, 19 Mar 2001 15:20:30 -0500 (EST)
Received: by USWAUMSXB4MEDGE with Internet Mail Service (5.5.2653.19)
	id <HG1KW889>; Mon, 19 Mar 2001 14:20:43 -0600
Message-ID: <EF3C4DA34DEFD411AE6200A0C9F2A35847EABB@uswaumsx06medge.med.ge.com>
From: "Mathew, Elizabeth (MED)" <Elizabeth.Mathew@med.ge.com>
To: ibis-users@eda.org
Subject: S2ibis
Date: Mon, 19 Mar 2001 14:20:38 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"


Hi IBIS Gurus,
                When I ran s2ibis I got an error "Technology must be
CMOS or BIPOLAR". I am trying to convert the spice model for HDMP-1024
Receiver into an IBIS model.
Please help.

Thanks,
Elizabeth

Elizabeth Mathew
Signal Integrity Expert,
Global Electrical Technology Center,
GE Medical Systems,
Phone:(262)544-3776
Fax:(262)548-2315
<mailto:Elizabeth.Mathew@med.ge.com>

 
From owner-ibis Tue Mar 20 12:46:31 2001
Received: from exchserv.linsang (66.linscomp.com [63.141.210.66])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2KKkS527989
	for <ibis-users@eda.org>; Tue, 20 Mar 2001 12:46:30 -0800 (PST)
Received: from vgavagan (66.linscomp.com [63.141.210.66]) by exchserv.linsang with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id HDK2DVZF; Tue, 20 Mar 2001 13:45:52 -0700
Message-ID: <007e01c0b17e$f3872590$1c00a8c0@vgavagan>
From: "Vince Gavagan" <vgavagan@linscomp.com>
To: <ibis-users@eda.org>
Subject: ibis usage for timing diagrams
Date: Tue, 20 Mar 2001 13:47:17 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007B_01C0B144.4712C9C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01C0B144.4712C9C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My understanding is that ibis is used to determine flight time =
information.  I am trying to perform an analysis of two IC's.  For the =
sake of this question, lets take a pin that is bi-directional on each =
IC.  Each datasheet specifies a "clk to valid."

One gives a value and condition of 20pF, with no additional information.

The other gives an "at the pin" value with conditions of purely =
resistive 50ohm load.  They also say that the value is from 2.4V to 0.8V =
(which isn't going to happen with a 50 ohm load).

1.  Should I be able to verify a value given in the data sheet with the =
ibis model?  I have tried each and neither come close to the value in =
the spec.  What about all of the parameters that are not given in the =
data sheet?  I can assign values of Xo, propagation velocity, and delay.

2.  How does the ibis simulation fit into a timing diagram?  I assume =
there will be a base value, say "clk to valid" to which I will add the =
flight time given by the simulation.  Is this the correct way to look at =
it?  If so, what do I do about the different conditions listed above =
(20pF vs 50ohm)?

------=_NextPart_000_007B_01C0B144.4712C9C0
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>My understanding is that ibis is used =
to determine=20
flight time information.&nbsp; I am trying to perform an analysis of two =

IC's.&nbsp; For the sake of this question, lets take a pin that is=20
bi-directional on each IC.&nbsp; Each datasheet specifies a "clk to=20
valid."</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>One gives a value and condition of =
20pF, with no=20
additional information.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The other gives an "at the&nbsp;pin" =
value with=20
conditions of purely resistive 50ohm load.&nbsp; They also say that the =
value is=20
from 2.4V to 0.8V (which isn't going to happen with a 50 ohm =
load).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1.&nbsp; Should I be able to verify a =
value given=20
in the data sheet with the ibis model?&nbsp; I have tried each and =
neither come=20
close to the value in the spec.&nbsp; What about all of the parameters =
that are=20
not given in the data sheet?&nbsp; I can assign values of Xo, =
propagation=20
velocity, and delay.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2.&nbsp; How does the ibis simulation =
fit into a=20
timing diagram?&nbsp; I assume there will be a base value, say "clk to =
valid" to=20
which I will add the flight time given by the simulation.&nbsp; Is this =
the=20
correct way to look at it?&nbsp; If so, what do I do about the different =

conditions listed above (20pF vs 50ohm)?</FONT></DIV></BODY></HTML>

------=_NextPart_000_007B_01C0B144.4712C9C0--

 
From owner-ibis Tue Mar 20 14:19:09 2001
Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2KMJ5528472
	for <ibis-users@eda.org>; Tue, 20 Mar 2001 14:19:08 -0800 (PST)
Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345)
	id 632A8813; Tue, 20 Mar 2001 16:16:10 -0600 (CST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53])
	by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 2E4A9BB8
	for <ibis-users@eda.org>; Tue, 20 Mar 2001 16:16:10 -0600 (CST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <HCAKLRWC>; Tue, 20 Mar 2001 17:16:09 -0500
Message-ID: <212CC57E84B8D111AD780000F84AA0490C713DAE@mroexc2.tay.cpqcorp.net>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: ibis-users@eda.org
Subject: RE: ibis usage for timing diagrams
Date: Tue, 20 Mar 2001 17:16:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain

> 1.  Should I be able to verify a value given in the data sheet with the
> ibis model?
 
No.  IBIS "models", like most SPICE models, represent only a portion of the
IC.  A SPICE model usually includes only the output buffer.  The IBIS
"model" simulates nothing more than the output characteristics (for output
pins).  Nothing else in the IC is included.  There is no "clk".

Either representation should produce a reasonable facsimile of the output
waveforms, under varying load conditions, but there is no absolute timing
information.  All the timing is relative.

What you would do, is simulate with your IBIS model connected to the spec
sheet's test load, find the time where the output waveform crosses whatever
voltage they used to measure the spec sheet's delay, and then use that as a
reference when you try different loads.

For example, if the spec sheet says the clk-to-output delay is 4.5 ns when
the falling edge crosses 0.8V, take the point where your simulator shows the
falling waveform crossing 0.8V, and re-calibrate your time axis so that you
now call that point "4.5 ns."  Then simulate using the circuit you want, and
see how the delay differs from that with the test load.

When the vendor's spec sheet information is incomplete or faulty, you are
out of luck as far as absolute timing is concerned.  (But if it's a standard
logic family, there may be conventions that you can use that aren't stated
on each data sheet.)  Regardless, you can still simulate to get waveforms,
and compare their timing to whatever "standard" test load you choose.

Regards,
Andy

 
From owner-ibis Tue Mar 20 15:41:38 2001
Received: from cisco.com (ups.cisco.com [171.69.18.21])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2KNfa528756
	for <ibis-users@eda.org>; Tue, 20 Mar 2001 15:41:37 -0800 (PST)
Received: from shuq-u10.cisco.com (shuq-u10.cisco.com [10.34.20.148])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA09964;
	Tue, 20 Mar 2001 15:38:41 -0800 (PST)
Message-Id: <200103202338.PAA09964@cisco.com>
Date: Tue, 20 Mar 2001 15:38:41 -0800 (PST)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Re: S2ibis
To: ibis-users@eda.org, Elizabeth.Mathew@med.ge.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: uVB+PFgDT6FLhNOehULZMg==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 

Elizabeth,

This is a s2ibis issue. It can only handle either CMOS or BIPOLAR technology.
This version is old and should not be used.

You should download the s2ibis2 and s2ibis2_fix version which takes care of
this problem.

From: http://www.eda.org/pub/ibis/s2ibis/s2ibis2_v1.1

s2ibis2.tar.Z
s2ibis2_fix.tar.Z

Regards,
Syed

> From: "Mathew, Elizabeth (MED)" <Elizabeth.Mathew@med.ge.com>
> To: ibis-users@eda.org
> Subject: S2ibis
> Date: Mon, 19 Mar 2001 14:20:38 -0600
> MIME-Version: 1.0
> 
> 
> Hi IBIS Gurus,
>                 When I ran s2ibis I got an error "Technology must be
> CMOS or BIPOLAR". I am trying to convert the spice model for HDMP-1024
> Receiver into an IBIS model.
> Please help.
> 
> Thanks,
> Elizabeth
> 
> Elizabeth Mathew
> Signal Integrity Expert,
> Global Electrical Technology Center,
> GE Medical Systems,
> Phone:(262)544-3776
> Fax:(262)548-2315
> <mailto:Elizabeth.Mathew@med.ge.com>
> 

 
From owner-ibis Wed Mar 21 11:24:03 2001
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2LJO1504430
	for <ibis-users@eda.org>; Wed, 21 Mar 2001 11:24:02 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA123312
	for <ibis-users@eda.org>; Wed, 21 Mar 2001 14:19:51 -0500
From: hasf@us.ibm.com
Received: from d01ml221.pok.ibm.com (d01ml221.pok.ibm.com [9.117.200.51])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id OAA165822
	for <ibis-users@eda.org>; Wed, 21 Mar 2001 14:16:39 -0500
Importance: Normal
To: ibis-users@eda.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFDA0954BF.5FB8D758-ON85256A16.00695A0C@pok.ibm.com>
Date: Wed, 21 Mar 2001 14:20:51 -0500
X-MIMETrack: Serialize by Router on D01ML221/01/M/IBM(Release 5.0.6a |January 17, 2001) at
 03/21/2001 02:21:03 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi All,
     I was having trouble using a particular keyword that is not supported
in a certain model_type.  For example, the [R Series] keyword is supported
for a model_type "Series" , but not for "Input" model_types.  At the same
time,  POWER/GND clamps are not supporeted under a "Series" model_type
model.  Is there a way to manipulate that?  Maybe by calling another
[Submodel] within the top level model and specify that as a "Series"
submodel_type.  I've tried it but wasn't successful.

Regards,
Hirut

Hirut Asfaw
ASIC I/O Developement
IBM Microelectronics Division
External:  (802) 769-0652   T/L: 6-0652
hasf@us.ibm.com


 
From owner-ibis Wed Mar 21 23:32:53 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2M7Wo507444
	for <ibis-users@eda.org>; Wed, 21 Mar 2001 23:32:52 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id XAA12974; Wed, 21 Mar 2001 23:29:49 -0800 (PST)
Received: from mentor.com (dhcp-27-176.egc.mentorg.com [137.202.27.176]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id HCZDSVTH; Wed, 21 Mar 2001 23:29:48 -0800
Message-ID: <3AB9A9E6.61C3E58E@mentor.com>
Date: Wed, 21 Mar 2001 23:29:43 -0800
From: Bob Ross <bob_ross@mentorg.com>
Organization: Mentor Graphics Corporation
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD   (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hasf@us.ibm.com
CC: ibis-users@eda.org
Subject: Re: 
References: <OFDA0954BF.5FB8D758-ON85256A16.00695A0C@pok.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hirut:

The Series and Series Switch models must be positioned under the
[Series Pin Mapping] keyword to document connections between
two pins.  The other types of models still are put under the [Pin]
keyword.  Input or Output models can be attached to the same pin
as Series models.

Bob Ross
Mentor Graphics


hasf@us.ibm.com wrote:

> Hi All,
>      I was having trouble using a particular keyword that is not supported
> in a certain model_type.  For example, the [R Series] keyword is supported
> for a model_type "Series" , but not for "Input" model_types.  At the same
> time,  POWER/GND clamps are not supporeted under a "Series" model_type
> model.  Is there a way to manipulate that?  Maybe by calling another
> [Submodel] within the top level model and specify that as a "Series"
> submodel_type.  I've tried it but wasn't successful.
>
> Regards,
> Hirut
>
> Hirut Asfaw
> ASIC I/O Developement
> IBM Microelectronics Division
> External:  (802) 769-0652   T/L: 6-0652
> hasf@us.ibm.com

 
From owner-ibis Thu Mar 22 11:37:21 2001
Received: from dfw-gate3.raytheon.com (dfw-gate3.raytheon.com [199.46.199.232])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2MJbJ511273
	for <ibis-users@eda.org>; Thu, 22 Mar 2001 11:37:21 -0800 (PST)
Received: from ds02c00.directory.ray.com (ds02c00.rsc.raytheon.com [147.25.138.118])
	by dfw-gate3.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f2MJYSf26963
	for <ibis-users@eda.org>; Thu, 22 Mar 2001 13:34:28 -0600 (CST)
Received: from rcsmail02.gar.esys.com (localhost [127.0.0.1])
	by ds02c00.directory.ray.com (8.9.3/8.9.3) with ESMTP id NAA26416
	for <ibis-users@eda.org>; Thu, 22 Mar 2001 13:33:41 -0600 (CST)
To: ibis-users@eda.org
Subject: Spice to IBIS conversion - 25 ohmns vs. 50 ohms
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OFB9D8DE30.7A61A422-ON86256A17.006AFB68@gar.esys.com>
From: Stacy_L_Gore@raytheon.com
Date: Thu, 22 Mar 2001 13:25:39 -0600
X-MIMETrack: Serialize by Router on RCSMAIL02/SRV/Raytheon/US(Release 5.0.5 |September
 22, 2000) at 03/22/2001 01:25:20 PM,
	Serialize complete at 03/22/2001 01:25:20 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006B8D3186256A17_="

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

What is the ramifications of creating an IBIS model from a SPICE deck 
setup into a 25 ohm load vs. a 50 ohm load.
My contractor that is doing the work claims that the Waveform doesn't look 
right going into 50 ohms (which is what the IC manufacture claim is the 
test load) but looks better going into 25 ohms.
What does this mean to me?
Possible incorrect AC parameters?
What?

Thanks in advance,
Stacy
--=_alternative 006B8D3186256A17_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">What is the ramifications of creating an IBIS model from a SPICE deck setup into a 25 ohm load vs. a 50 ohm load.</font>
<br><font size=2 face="sans-serif">My contractor that is doing the work claims that the Waveform doesn't look right going into 50 ohms (which is what the IC manufacture claim is the test load) but looks better going into 25 ohms.</font>
<br><font size=2 face="sans-serif">What does this mean to me?</font>
<br><font size=2 face="sans-serif">Possible incorrect AC parameters?</font>
<br><font size=2 face="sans-serif">What?</font>
<br>
<br><font size=2 face="sans-serif">Thanks in advance,</font>
<br><font size=2 face="sans-serif">Stacy</font>
--=_alternative 006B8D3186256A17_=--
 
From owner-ibis Thu Mar 22 13:39:49 2001
Received: from cisco.com (ups.cisco.com [171.69.18.21])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2MLdh511781
	for <ibis-users@vhdl.org>; Thu, 22 Mar 2001 13:39:48 -0800 (PST)
Received: from shuq-u10.cisco.com (shuq-u10.cisco.com [10.34.20.148])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id NAA23404
	for <ibis-users@vhdl.org>; Thu, 22 Mar 2001 13:36:47 -0800 (PST)
Message-Id: <200103222136.NAA23404@cisco.com>
Date: Thu, 22 Mar 2001 13:36:47 -0800 (PST)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Mar01 European IBIS summit paper uploaded
To: ibis-users@vhdl.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 1NM+/2CQHeYvAaVEJ1Plug==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 

IBIS gurus,

The Mar'01 European IBIS summit papers have been uploaded to:

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

Read the 00readme.txt file for details.

Most of the papers are available as .zip, .ppt and .pdf formats.

If you see any problems with downloads/access, let me know..

Syed
Webmaster
Cisco Systems, Inc

 
From owner-ibis Thu Mar 22 15:22:40 2001
Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2MNMb512232
	for <ibis-users@vhdl.org>; Thu, 22 Mar 2001 15:22:38 -0800 (PST)
Received: from labonte.com (sj-natpool-220.cisco.com [128.107.248.220])
	by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f2MNJeI14778
	for <ibis-users@vhdl.org>; Thu, 22 Mar 2001 15:19:40 -0800
Message-ID: <3ABA8865.D928E3E8@labonte.com>
Date: Thu, 22 Mar 2001 18:19:01 -0500
From: Mike LaBonte <mike@labonte.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BDP81800  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "ibis-users@vhdl.org" <ibis-users@vhdl.org>
Subject: different rising and falling Ramp dV
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Many IBIS models have different values for dV in the dV/dt_r and dV/dt_f.
The clipping below from IBIS spec shows an example. But the usage rules
imply that dV must be 60% of the voltage swing. If the voltage swing is
measured between the 2 steady-state voltages, then how could you have
different values for rise and fall dV? If there is variation in how
simulators handle the Ramp dV values, then this may matter.

Mike LaBonte

|=============================================================================
|     Keyword:  [Ramp]
|    Required:  Yes, except for inputs, terminators, Series and Series_switch
|               model types.
| Description:  Defines the rise and fall times of a buffer.  The ramp rate
|               does not include packaging but does include the effects of the
|               C_comp parameter.
|  Sub-Params:  dV/dt_r, dV/dt_f, R_load
| Usage Rules:  The rise and fall time is defined as the time it takes the
|               output to go from 20% to 80% of its final value.  The ramp
|               rate is defined as:
|
|               dV          20% to 80% voltage swing
|               -- = ----------------------------------------
|               dt   Time it takes to swing the above voltage
|
|               The ramp rate must be specified as an explicit fraction and
|               must not be reduced.  The [Ramp] values can use "NA" for the
|               min and max values only.  The R_load subparameter is optional
|               if the default 50 ohm load is used.  The R_load subparameter
|               is required if a non-standard load is used.
|-----------------------------------------------------------------------------
[Ramp]
| variable      typ             min             max
dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
R_load = 300ohms
 
From owner-ibis Fri Mar 23 01:01:10 2001
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2N917514499
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 01:01:08 -0800 (PST)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA16762;
	Fri, 23 Mar 2001 09:57:55 +0100 (MET)
Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA28436;
	Fri, 23 Mar 2001 09:57:55 +0100 (MET)
Received: by MCHH274E with Internet Mail Service (5.5.2653.19)
	id <HB39VCKR>; Fri, 23 Mar 2001 09:57:53 +0100
Message-ID: <AFC76835727DD211A7C20008C71EAF1E01A91197@MCHH230E>
From: Koller Katja <Katja.Koller@icn.siemens.de>
To: "'Mike LaBonte'" <mike@labonte.com>, ibis-users@vhdl.org
Subject: AW: different rising and falling Ramp dV
Date: Fri, 23 Mar 2001 09:57:41 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f2N91l514500

The ibis models do only have the same value of dV, if the load AND the
termination voltage have the same value.
The ibis-ramp termination voltage is defined for
rising: 0V
falling: vcc

But you can get the exact dV out of the pullup and pulldown-curves.

Katja

> -----Urspr> üngliche Nachricht-----
> Von:	Mike LaBonte [SMTP:mike@labonte.com]
> Gesendet am:	Freitag, 23. März 2001 00:19
> An:	ibis-users@vhdl.org
> Betreff:	different rising and falling Ramp dV
> 
> Many IBIS models have different values for dV in the dV/dt_r and dV/dt_f.
> The clipping below from IBIS spec shows an example. But the usage rules
> imply that dV must be 60% of the voltage swing. If the voltage swing is
> measured between the 2 steady-state voltages, then how could you have
> different values for rise and fall dV? If there is variation in how
> simulators handle the Ramp dV values, then this may matter.
> 
> Mike LaBonte
> 
> |=============================================================================
> |     Keyword:  [Ramp]
> |    Required:  Yes, except for inputs, terminators, Series and Series_switch
> |               model types.
> | Description:  Defines the rise and fall times of a buffer.  The ramp rate
> |               does not include packaging but does include the effects of the
> |               C_comp parameter.
> |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> | Usage Rules:  The rise and fall time is defined as the time it takes the
> |               output to go from 20% to 80% of its final value.  The ramp
> |               rate is defined as:
> |
> |               dV          20% to 80% voltage swing
> |               -- = ----------------------------------------
> |               dt   Time it takes to swing the above voltage
> |
> |               The ramp rate must be specified as an explicit fraction and
> |               must not be reduced.  The [Ramp] values can use "NA" for the
> |               min and max values only.  The R_load subparameter is optional
> |               if the default 50 ohm load is used.  The R_load subparameter
> |               is required if a non-standard load is used.
> |-----------------------------------------------------------------------------
> [Ramp]
> | variable      typ             min             max
> dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> R_load = 300ohms
 
From owner-ibis Fri Mar 23 01:02:34 2001
Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2N92W514507
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 01:02:33 -0800 (PST)
Received: from hobbes (c207-202-218-223.sea1.cablespeed.com [207.202.218.223])
	by mail.cablespeed.com (8.9.3/8.9.3) with SMTP id AAA02640;
	Fri, 23 Mar 2001 00:59:34 -0800
From: Al Davis <aldavis@ieee.org>
To: Mike LaBonte <mike@labonte.com>,
   "ibis-users@vhdl.org" <ibis-users@vhdl.org>
Subject: Re: different rising and falling Ramp dV
Date: Fri, 23 Mar 2001 00:58:44 -0800
X-Mailer: KMail [version 1.1.61]
Content-Type: text/plain
References: <3ABA8865.D928E3E8@labonte.com>
In-Reply-To: <3ABA8865.D928E3E8@labonte.com>
MIME-Version: 1.0
Message-Id: <01032300584400.14951@hobbes>
Content-Transfer-Encoding: 8bit

On Thu, 22 Mar 2001, Mike LaBonte wrote:
> Many IBIS models have different values for dV in the dV/dt_r and
> dV/dt_f. The clipping below from IBIS spec shows an example. But
> the usage rules imply that dV must be 60% of the voltage swing. If
> the voltage swing is measured between the 2 steady-state voltages,
> then how could you have different values for rise and fall dV? If
> there is variation in how simulators handle the Ramp dV values,
> then this may matter.

There is definitely variation in how simulators handle it.  I am 
aware of some that look only at dt, assuming the changes in load 
change the voltages, and it really is 20% to 80%.  I am aware of 
others that look only at the quotient, assuming that the 20% and 80% 
are only suggestions, and the modeler specified what was actually 
tested.  I have seen other variations, too.

 
From owner-ibis Fri Mar 23 05:45:07 2001
Received: from s6.mailbank.com (proxy.mailbank.com [208.49.167.126])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NDj5515800
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 05:45:06 -0800 (PST)
Received: from labonte.com (sj-natpool-220.cisco.com [128.107.248.220])
	by s6.mailbank.com (8.11.1/8.11.1) with ESMTP id f2NDVVI22312;
	Fri, 23 Mar 2001 05:31:31 -0800
Message-ID: <3ABB500B.79417C67@labonte.com>
Date: Fri, 23 Mar 2001 08:30:51 -0500
From: Mike LaBonte <mike@labonte.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BDP81800  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Koller Katja <Katja.Koller@icn.siemens.de>
CC: ibis-users@vhdl.org
Subject: Re: AW: different rising and falling Ramp dV
References: <AFC76835727DD211A7C20008C71EAF1E01A91197@MCHH230E>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Katja,

I searched through the IBIS spec, and at the very end there is indeed
a description of what you have stated. I should have remembered this,
but the issues of IBIS 1.1 seem so far in the past.

Al's comment about simulator differences is no doubt true. So we have
at least 2 areas that simulators possibly handle differently:

1) IBIS models with no waveforms, and different Ramp dV for rise and fall.
2) IBIS models with waveform endpoint that do not match the I/V curves.

Maybe I have missed others, like C_comp de-embedding? Anyway, from now on
I will be more watchful of simulations involving models without waveforms.
Correlating has never been optional, I suppose, for any model. With luck,
all of the models I see from now on will have waveforms and perfectly
matching I/V curves :-)

Mike

Koller Katja wrote:
> 
> The ibis models do only have the same value of dV, if the load AND the
> termination voltage have the same value.
> The ibis-ramp termination voltage is defined for
> rising: 0V
> falling: vcc
> 
> But you can get the exact dV out of the pullup and pulldown-curves.
> 
> Katja
> 
> > -----Urspr> üngliche Nachricht-----
> > Von:  Mike LaBonte [SMTP:mike@labonte.com]
> > Gesendet am:  Freitag, 23. März 2001 00:19
> > An:   ibis-users@vhdl.org
> > Betreff:      different rising and falling Ramp dV
> >
> > Many IBIS models have different values for dV in the dV/dt_r and dV/dt_f.
> > The clipping below from IBIS spec shows an example. But the usage rules
> > imply that dV must be 60% of the voltage swing. If the voltage swing is
> > measured between the 2 steady-state voltages, then how could you have
> > different values for rise and fall dV? If there is variation in how
> > simulators handle the Ramp dV values, then this may matter.
> >
> > Mike LaBonte
> >
> > |=============================================================================
> > |     Keyword:  [Ramp]
> > |    Required:  Yes, except for inputs, terminators, Series and Series_switch
> > |               model types.
> > | Description:  Defines the rise and fall times of a buffer.  The ramp rate
> > |               does not include packaging but does include the effects of the
> > |               C_comp parameter.
> > |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> > | Usage Rules:  The rise and fall time is defined as the time it takes the
> > |               output to go from 20% to 80% of its final value.  The ramp
> > |               rate is defined as:
> > |
> > |               dV          20% to 80% voltage swing
> > |               -- = ----------------------------------------
> > |               dt   Time it takes to swing the above voltage
> > |
> > |               The ramp rate must be specified as an explicit fraction and
> > |               must not be reduced.  The [Ramp] values can use "NA" for the
> > |               min and max values only.  The R_load subparameter is optional
> > |               if the default 50 ohm load is used.  The R_load subparameter
> > |               is required if a non-standard load is used.
> > |-----------------------------------------------------------------------------
> > [Ramp]
> > | variable      typ             min             max
> > dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> > dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> > R_load = 300ohms
 
From owner-ibis Fri Mar 23 08:31:20 2001
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NGVI516862
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 08:31:20 -0800 (PST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id QAA07484
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 16:28:21 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 23 Mar 2001 16:28:21 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <HLKCSDFV>; Fri, 23 Mar 2001 08:28:19 -0800
Message-ID: <10C8636AE359D4119118009027AE99870515535B@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV
Date: Fri, 23 Mar 2001 08:28:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

Mike,

The reason dV can be different for rising and falling edges is because
the voltage swing does not have to be the same (in contrary of your
statement).

A falling edge ramp requires that the R_load resistor is connected to
the supply rail.  This means that the falling edge characterizes the
pulldown turning on.  A rising edge ramps requires that the R_load
resistor is connected to GND.  This means that the rising edge ramp
characterizes how the pullup turns on.  Since the pullup and pulldown
IV curves do not have to be the same (strength), you can get different
swings for these two edges, hence the dV numbers will also be different.

Now, if you consider an open drain type buffer, where the rising and
falling edges are characterized with R_load connected to the same rail,
your statement is correct, the swing will be the same, therefore dV
should also be the same.  However, notice that in this case one edge
describes how the device turns on, the other edge describes how the
same device turns off.

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

-----Original Message-----
From: Mike LaBonte [mailto:mike@labonte.com]
Sent: Thursday, March 22, 2001 3:19 PM
To: ibis-users@vhdl.org
Subject: different rising and falling Ramp dV


Many IBIS models have different values for dV in the dV/dt_r and dV/dt_f.
The clipping below from IBIS spec shows an example. But the usage rules
imply that dV must be 60% of the voltage swing. If the voltage swing is
measured between the 2 steady-state voltages, then how could you have
different values for rise and fall dV? If there is variation in how
simulators handle the Ramp dV values, then this may matter.

Mike LaBonte

|===========================================================================
==
|     Keyword:  [Ramp]
|    Required:  Yes, except for inputs, terminators, Series and
Series_switch
|               model types.
| Description:  Defines the rise and fall times of a buffer.  The ramp rate
|               does not include packaging but does include the effects of
the
|               C_comp parameter.
|  Sub-Params:  dV/dt_r, dV/dt_f, R_load
| Usage Rules:  The rise and fall time is defined as the time it takes the
|               output to go from 20% to 80% of its final value.  The ramp
|               rate is defined as:
|
|               dV          20% to 80% voltage swing
|               -- = ----------------------------------------
|               dt   Time it takes to swing the above voltage
|
|               The ramp rate must be specified as an explicit fraction and
|               must not be reduced.  The [Ramp] values can use "NA" for the
|               min and max values only.  The R_load subparameter is
optional
|               if the default 50 ohm load is used.  The R_load subparameter
|               is required if a non-standard load is used.
|---------------------------------------------------------------------------
--
[Ramp]
| variable      typ             min             max
dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
R_load = 300ohms

 
From owner-ibis Fri Mar 23 09:05:33 2001
Received: from ammexh01.amp.com (nat012026084081.amp.com [12.26.84.81])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NH5V517024
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 09:05:32 -0800 (PST)
Received: by ammexh01.amp.com with Internet Mail Service (5.5.2653.19)
	id <HPK75F7R>; Fri, 23 Mar 2001 12:01:47 -0500
Received: from ammex001.amp.com ([163.241.175.7]) by ammexh01.amp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id HPK75FYZ; Fri, 23 Mar 2001 12:01:29 -0500
Received: by ammex001.amp.com with Internet Mail Service (5.5.2653.19)
	id <HQLQWA89>; Fri, 23 Mar 2001 12:01:22 -0500
From: "Minnick, Timothy R" <tim.minnick@tycoelectronics.com>
To: ibis-users@vhdl.org
Message-ID: <2700772BAE3BD311A2DB00805F6F78070D60A5DE@ammex007.amp.com>
Subject: simulation error for 'max' process (but not 'min' or 'typ') 
Date: Fri, 23 Mar 2001 11:59:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

Dear IBIS Gurus,

I've recently run into a simulation problem, that I believe to be IBIS model
dependent, and am hoping to verify my assumption.  I am presently using the
B-element in an HSPICE environment (which I have used successfully many
times in the past), and am calling a vendor's model which has options for
'min', 'typ', and 'max' process parameters.  The 'min' and 'typ' versions of
the models run just fine.  However, when I (only) change the process
parameter in the file to 'max', I receive the following error:


[snip]
find_root_2:ERR26     f1<0, f0<0, f2<0, wrong data
 x1 x0 x2 =   -0.500000        0.00000       0.500000    
 f1 f0 f2 =   -0.300000      -0.150000      -0.222045E-15
 find_root_1:ERR26  f1<0, f0<0, f2<0, wrong data
 x1 x0 x2 =   -0.500000        0.00000       0.500000    
 f1 f0 f2 =   -0.300000      -0.150000      -0.222045E-15

  ** error** in fd_bisp_iob:903:
     cannot find root
[snip]


Unfortunately, I am not extremely familiar with the errors that IBIS models
may end up generating through HSPICE, and was wondering if anyone else
recognized or understood the error being generated (I know HSPICE can be
rather vague in its error descriptions as it is).  Since my simulation file
does not change otherwise, I suspect there could be an error in the data
within the IBIS model itself, specifically in the 'max' data.


Any help you can provide would be greatly appreciated.  Thank you.


Tim Minnick
Tyco Electronics
717-986-5284
 
From owner-ibis Fri Mar 23 10:52:41 2001
Received: from ausxc07.us.dell.com (ausxc07.us.dell.com [143.166.99.215])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NIqb517528
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 10:52:39 -0800 (PST)
Received: by ausxc07.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <GVTTMDDK>; Fri, 23 Mar 2001 12:48:48 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F8B7@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: arpad.muranyi@intel.com, ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV
Date: Fri, 23 Mar 2001 12:48:38 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0B3C9.E4DA5088"

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

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

Arpad,
Would you comment on what you expect for something like AGTL+ which is
almost an open drain, but has a weak pullup?  The weak pullup alone can't
pull a 50 ohm resistor up very far.

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


> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Friday, March 23, 2001 10:28 AM
> To: ibis-users@vhdl.org
> Subject: RE: different rising and falling Ramp dV
> 
> 
> Mike,
> 
> The reason dV can be different for rising and falling edges is because
> the voltage swing does not have to be the same (in contrary of your
> statement).
> 
> A falling edge ramp requires that the R_load resistor is connected to
> the supply rail.  This means that the falling edge characterizes the
> pulldown turning on.  A rising edge ramps requires that the R_load
> resistor is connected to GND.  This means that the rising edge ramp
> characterizes how the pullup turns on.  Since the pullup and pulldown
> IV curves do not have to be the same (strength), you can get different
> swings for these two edges, hence the dV numbers will also be 
> different.
> 
> Now, if you consider an open drain type buffer, where the rising and
> falling edges are characterized with R_load connected to the 
> same rail,
> your statement is correct, the swing will be the same, therefore dV
> should also be the same.  However, notice that in this case one edge
> describes how the device turns on, the other edge describes how the
> same device turns off.
> 
> Arpad
> ==============================================================
> =========
> 
> -----Original Message-----
> From: Mike LaBonte [mailto:mike@labonte.com]
> Sent: Thursday, March 22, 2001 3:19 PM
> To: ibis-users@vhdl.org
> Subject: different rising and falling Ramp dV
> 
> 
> Many IBIS models have different values for dV in the dV/dt_r 
> and dV/dt_f.
> The clipping below from IBIS spec shows an example. But the 
> usage rules
> imply that dV must be 60% of the voltage swing. If the 
> voltage swing is
> measured between the 2 steady-state voltages, then how could you have
> different values for rise and fall dV? If there is variation in how
> simulators handle the Ramp dV values, then this may matter.
> 
> Mike LaBonte
> 
> |=============================================================
> ==============
> ==
> |     Keyword:  [Ramp]
> |    Required:  Yes, except for inputs, terminators, Series and
> Series_switch
> |               model types.
> | Description:  Defines the rise and fall times of a buffer.  
> The ramp rate
> |               does not include packaging but does include 
> the effects of
> the
> |               C_comp parameter.
> |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> | Usage Rules:  The rise and fall time is defined as the time 
> it takes the
> |               output to go from 20% to 80% of its final 
> value.  The ramp
> |               rate is defined as:
> |
> |               dV          20% to 80% voltage swing
> |               -- = ----------------------------------------
> |               dt   Time it takes to swing the above voltage
> |
> |               The ramp rate must be specified as an 
> explicit fraction and
> |               must not be reduced.  The [Ramp] values can 
> use "NA" for the
> |               min and max values only.  The R_load subparameter is
> optional
> |               if the default 50 ohm load is used.  The 
> R_load subparameter
> |               is required if a non-standard load is used.
> |-------------------------------------------------------------
> --------------
> --
> [Ramp]
> | variable      typ             min             max
> dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> R_load = 300ohms
> 
> 


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

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

------_=_NextPart_000_01C0B3C9.E4DA5088--
 
From owner-ibis Fri Mar 23 12:28:00 2001
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NKRw518003
	for <ibis-users@eda.org>; Fri, 23 Mar 2001 12:27:59 -0800 (PST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id UAA22354;
	Fri, 23 Mar 2001 20:24:56 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 23 Mar 2001 20:24:56 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <HLJ64PY1>; Fri, 23 Mar 2001 12:24:55 -0800
Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A75B2@orsmsx49.jf.intel.com>
From: "Peters, Stephen" <stephen.peters@intel.com>
To: "'Stacy_L_Gore@raytheon.com'" <Stacy_L_Gore@raytheon.com>,
   ibis-users@eda.org
Subject: RE: Spice to IBIS conversion - 25 ohmns vs. 50 ohms
Date: Fri, 23 Mar 2001 12:24:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0B3D7.50ABC9B0"

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

 
Hi Stacy:
 
  I'm not sure what your contractor means by 'don't look right', but in
general a 25 ohm load means a reduced output voltage swing.  This may be a
problem if your are trying to capture a detailed VT curve and the transition
is so small you have to make the time step very small to get any detail.
Also, (and this may be more important) assuming the device your modeling is
intended to work into a 40-60 ohm load (i.e. a typical PCB trace), then VT
curves taken with a 50 ohms load will reflect device operation better than
ones taken at 25 ohms.  If I were you I'd enquire further about what doesn't
look right with the waveforms into 50 ohms.
 
  Regards,
  Stephen Peters
  Intel Corp.
 

-----Original Message-----
From: Stacy_L_Gore@raytheon.com [mailto:Stacy_L_Gore@raytheon.com]
Sent: Thursday, March 22, 2001 11:26 AM
To: ibis-users@eda.org
Subject: Spice to IBIS conversion - 25 ohmns vs. 50 ohms



What is the ramifications of creating an IBIS model from a SPICE deck setup
into a 25 ohm load vs. a 50 ohm load. 
My contractor that is doing the work claims that the Waveform doesn't look
right going into 50 ohms (which is what the IC manufacture claim is the test
load) but looks better going into 25 ohms. 
What does this mean to me? 
Possible incorrect AC parameters? 
What? 

Thanks in advance, 
Stacy


------_=_NextPart_001_01C0B3D7.50ABC9B0
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=563100420-23032001>Hi 
Stacy:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=563100420-23032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=563100420-23032001>&nbsp; 
I'm not sure what your contractor means by 'don't look right', but in general a 
25 ohm load&nbsp;means a reduced output voltage swing.&nbsp; This may be a 
problem if your are trying to capture a detailed VT curve and the transition is 
so small you have to make the time step very small to get any detail.&nbsp; 
Also, (and this may be more important) assuming the device your modeling is 
intended to work into a 40-60 ohm load (i.e. a typical PCB trace), then&nbsp;VT 
curves taken with&nbsp;a 50 ohms load&nbsp;will reflect&nbsp;device operation 
better&nbsp;than ones taken at 25 ohms.&nbsp; If I were you I'd enquire further 
about what doesn't look right with the waveforms into 50 
ohms.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=563100420-23032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=563100420-23032001>&nbsp; 
Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=563100420-23032001>&nbsp; 
Stephen Peters</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=563100420-23032001>&nbsp; 
Intel Corp.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=563100420-23032001>&nbsp;</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stacy_L_Gore@raytheon.com 
  [mailto:Stacy_L_Gore@raytheon.com]<BR><B>Sent:</B> Thursday, March 22, 2001 
  11:26 AM<BR><B>To:</B> ibis-users@eda.org<BR><B>Subject:</B> Spice to IBIS 
  conversion - 25 ohmns vs. 50 ohms<BR><BR></DIV></FONT><BR><FONT 
  face=sans-serif size=2>What is the ramifications of creating an IBIS model 
  from a SPICE deck setup into a 25 ohm load vs. a 50 ohm load.</FONT> <BR><FONT 
  face=sans-serif size=2>My contractor that is doing the work claims that the 
  Waveform doesn't look right going into 50 ohms (which is what the IC 
  manufacture claim is the test load) but looks better going into 25 
  ohms.</FONT> <BR><FONT face=sans-serif size=2>What does this mean to 
  me?</FONT> <BR><FONT face=sans-serif size=2>Possible incorrect AC 
  parameters?</FONT> <BR><FONT face=sans-serif size=2>What?</FONT> <BR><BR><FONT 
  face=sans-serif size=2>Thanks in advance,</FONT> <BR><FONT face=sans-serif 
  size=2>Stacy</FONT></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0B3D7.50ABC9B0--

 
From owner-ibis Fri Mar 23 12:54:57 2001
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NKsr518127
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 12:54:55 -0800 (PST)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id UAA19070
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 20:52:03 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 23 Mar 2001 20:52:03 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <HLKKGJVR>; Fri, 23 Mar 2001 12:52:00 -0800
Message-ID: <10C8636AE359D4119118009027AE99870515535D@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV
Date: Fri, 23 Mar 2001 12:51:56 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

Aubrey,

In light of the original question from Mike and my answer to it,
I don't expect anything different in this case.  I assume that
the weak pullup you are talking about is always on.  So the
two Vt curves you will make will be generated with a resistor
to ground, and the rising and falling edge will characterize
how the switched pulldown is turning on and off.  The amplitude
of the rising and falling edge will be the same, but may not
start or end on the rail (GND) exactly due to the weak pullup.

I am not sure if this answered your question, or whether I
understood your question fully.  Did this help?

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

-----Original Message-----
From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
Sent: Friday, March 23, 2001 10:49 AM
To: arpad.muranyi@intel.com; ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV


Arpad,
Would you comment on what you expect for something like AGTL+ which is
almost an open drain, but has a weak pullup?  The weak pullup alone can't
pull a 50 ohm resistor up very far.

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


> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Friday, March 23, 2001 10:28 AM
> To: ibis-users@vhdl.org
> Subject: RE: different rising and falling Ramp dV
> 
> 
> Mike,
> 
> The reason dV can be different for rising and falling edges is because
> the voltage swing does not have to be the same (in contrary of your
> statement).
> 
> A falling edge ramp requires that the R_load resistor is connected to
> the supply rail.  This means that the falling edge characterizes the
> pulldown turning on.  A rising edge ramps requires that the R_load
> resistor is connected to GND.  This means that the rising edge ramp
> characterizes how the pullup turns on.  Since the pullup and pulldown
> IV curves do not have to be the same (strength), you can get different
> swings for these two edges, hence the dV numbers will also be 
> different.
> 
> Now, if you consider an open drain type buffer, where the rising and
> falling edges are characterized with R_load connected to the 
> same rail,
> your statement is correct, the swing will be the same, therefore dV
> should also be the same.  However, notice that in this case one edge
> describes how the device turns on, the other edge describes how the
> same device turns off.
> 
> Arpad
> ==============================================================
> =========
> 
> -----Original Message-----
> From: Mike LaBonte [mailto:mike@labonte.com]
> Sent: Thursday, March 22, 2001 3:19 PM
> To: ibis-users@vhdl.org
> Subject: different rising and falling Ramp dV
> 
> 
> Many IBIS models have different values for dV in the dV/dt_r 
> and dV/dt_f.
> The clipping below from IBIS spec shows an example. But the 
> usage rules
> imply that dV must be 60% of the voltage swing. If the 
> voltage swing is
> measured between the 2 steady-state voltages, then how could you have
> different values for rise and fall dV? If there is variation in how
> simulators handle the Ramp dV values, then this may matter.
> 
> Mike LaBonte
> 
> |=============================================================
> ==============
> ==
> |     Keyword:  [Ramp]
> |    Required:  Yes, except for inputs, terminators, Series and
> Series_switch
> |               model types.
> | Description:  Defines the rise and fall times of a buffer.  
> The ramp rate
> |               does not include packaging but does include 
> the effects of
> the
> |               C_comp parameter.
> |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> | Usage Rules:  The rise and fall time is defined as the time 
> it takes the
> |               output to go from 20% to 80% of its final 
> value.  The ramp
> |               rate is defined as:
> |
> |               dV          20% to 80% voltage swing
> |               -- = ----------------------------------------
> |               dt   Time it takes to swing the above voltage
> |
> |               The ramp rate must be specified as an 
> explicit fraction and
> |               must not be reduced.  The [Ramp] values can 
> use "NA" for the
> |               min and max values only.  The R_load subparameter is
> optional
> |               if the default 50 ohm load is used.  The 
> R_load subparameter
> |               is required if a non-standard load is used.
> |-------------------------------------------------------------
> --------------
> --
> [Ramp]
> | variable      typ             min             max
> dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> R_load = 300ohms
> 
> 


 
From owner-ibis Fri Mar 23 13:00:50 2001
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NL0m518151
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 13:00:49 -0800 (PST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id UAA02759
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 20:57:57 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 23 Mar 2001 20:57:57 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <HLJ64SV9>; Fri, 23 Mar 2001 12:57:56 -0800
Message-ID: <10C8636AE359D4119118009027AE99870515535E@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV
Date: Fri, 23 Mar 2001 12:57:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry, I got dyslexic a bit...  For the open-drain GTL buffer
the resistor is not connected to GND, but to Vtt, and the
"ON" endpoints of the Vt curve will definitely not go to GND,
but the "OFF" endpoints should be at Vtt.

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

-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Friday, March 23, 2001 12:52 PM
To: ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV


Aubrey,

In light of the original question from Mike and my answer to it,
I don't expect anything different in this case.  I assume that
the weak pullup you are talking about is always on.  So the
two Vt curves you will make will be generated with a resistor
to ground, and the rising and falling edge will characterize
how the switched pulldown is turning on and off.  The amplitude
of the rising and falling edge will be the same, but may not
start or end on the rail (GND) exactly due to the weak pullup.

I am not sure if this answered your question, or whether I
understood your question fully.  Did this help?

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

-----Original Message-----
From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
Sent: Friday, March 23, 2001 10:49 AM
To: arpad.muranyi@intel.com; ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV


Arpad,
Would you comment on what you expect for something like AGTL+ which is
almost an open drain, but has a weak pullup?  The weak pullup alone can't
pull a 50 ohm resistor up very far.

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


> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Friday, March 23, 2001 10:28 AM
> To: ibis-users@vhdl.org
> Subject: RE: different rising and falling Ramp dV
> 
> 
> Mike,
> 
> The reason dV can be different for rising and falling edges is because
> the voltage swing does not have to be the same (in contrary of your
> statement).
> 
> A falling edge ramp requires that the R_load resistor is connected to
> the supply rail.  This means that the falling edge characterizes the
> pulldown turning on.  A rising edge ramps requires that the R_load
> resistor is connected to GND.  This means that the rising edge ramp
> characterizes how the pullup turns on.  Since the pullup and pulldown
> IV curves do not have to be the same (strength), you can get different
> swings for these two edges, hence the dV numbers will also be 
> different.
> 
> Now, if you consider an open drain type buffer, where the rising and
> falling edges are characterized with R_load connected to the 
> same rail,
> your statement is correct, the swing will be the same, therefore dV
> should also be the same.  However, notice that in this case one edge
> describes how the device turns on, the other edge describes how the
> same device turns off.
> 
> Arpad
> ==============================================================
> =========
> 
> -----Original Message-----
> From: Mike LaBonte [mailto:mike@labonte.com]
> Sent: Thursday, March 22, 2001 3:19 PM
> To: ibis-users@vhdl.org
> Subject: different rising and falling Ramp dV
> 
> 
> Many IBIS models have different values for dV in the dV/dt_r 
> and dV/dt_f.
> The clipping below from IBIS spec shows an example. But the 
> usage rules
> imply that dV must be 60% of the voltage swing. If the 
> voltage swing is
> measured between the 2 steady-state voltages, then how could you have
> different values for rise and fall dV? If there is variation in how
> simulators handle the Ramp dV values, then this may matter.
> 
> Mike LaBonte
> 
> |=============================================================
> ==============
> ==
> |     Keyword:  [Ramp]
> |    Required:  Yes, except for inputs, terminators, Series and
> Series_switch
> |               model types.
> | Description:  Defines the rise and fall times of a buffer.  
> The ramp rate
> |               does not include packaging but does include 
> the effects of
> the
> |               C_comp parameter.
> |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> | Usage Rules:  The rise and fall time is defined as the time 
> it takes the
> |               output to go from 20% to 80% of its final 
> value.  The ramp
> |               rate is defined as:
> |
> |               dV          20% to 80% voltage swing
> |               -- = ----------------------------------------
> |               dt   Time it takes to swing the above voltage
> |
> |               The ramp rate must be specified as an 
> explicit fraction and
> |               must not be reduced.  The [Ramp] values can 
> use "NA" for the
> |               min and max values only.  The R_load subparameter is
> optional
> |               if the default 50 ohm load is used.  The 
> R_load subparameter
> |               is required if a non-standard load is used.
> |-------------------------------------------------------------
> --------------
> --
> [Ramp]
> | variable      typ             min             max
> dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> R_load = 300ohms
> 
> 



 
From owner-ibis Fri Mar 23 14:53:00 2001
Received: from ausxc10.us.dell.com (ausxc10.us.dell.com [143.166.98.229])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2NMqv518545
	for <ibis-users@vhdl.org>; Fri, 23 Mar 2001 14:52:59 -0800 (PST)
Received: by ausxc10.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <GXNF7W5V>; Fri, 23 Mar 2001 16:40:08 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F8BD@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: arpad.muranyi@intel.com, ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV
Date: Fri, 23 Mar 2001 16:41:42 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0B3EA.6E6A18E0"

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

------_=_NextPart_000_01C0B3EA.6E6A18E0
Content-Type: text/plain;
	charset="iso-8859-1"

The case I had in mind has the dV rising about 1/3 the dV falling.  The dV
rising seems to be taken from the Rising V/T curve with 50 ohms to ground
and the dV falling seems to be taken from the Falling V/T curve with 50 ohms
to Vtt.  There is no pullup in the power clamp for this buffer.  I didn't
ask my supplier whether the pullup was always on but I don't think it is.
This buffer is used on a bus that has at least one pullup.  This seems to be
a little different from what you discussed; perhaps an alternate method?
Perhaps I am missing something?

BTW, my simulator seems to be OK with this as my simulations match what we
measure in the lab.

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


> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Friday, March 23, 2001 2:58 PM
> To: ibis-users@vhdl.org
> Subject: RE: different rising and falling Ramp dV
> 
> 
> Sorry, I got dyslexic a bit...  For the open-drain GTL buffer
> the resistor is not connected to GND, but to Vtt, and the
> "ON" endpoints of the Vt curve will definitely not go to GND,
> but the "OFF" endpoints should be at Vtt.
> 
> Arpad
> ==============================================================
> 
> -----Original Message-----
> From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> Sent: Friday, March 23, 2001 12:52 PM
> To: ibis-users@vhdl.org
> Subject: RE: different rising and falling Ramp dV
> 
> 
> Aubrey,
> 
> In light of the original question from Mike and my answer to it,
> I don't expect anything different in this case.  I assume that
> the weak pullup you are talking about is always on.  So the
> two Vt curves you will make will be generated with a resistor
> to ground, and the rising and falling edge will characterize
> how the switched pulldown is turning on and off.  The amplitude
> of the rising and falling edge will be the same, but may not
> start or end on the rail (GND) exactly due to the weak pullup.
> 
> I am not sure if this answered your question, or whether I
> understood your question fully.  Did this help?
> 
> Arpad
> ===============================================================
> 
> -----Original Message-----
> From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> Sent: Friday, March 23, 2001 10:49 AM
> To: arpad.muranyi@intel.com; ibis-users@vhdl.org
> Subject: RE: different rising and falling Ramp dV
> 
> 
> Arpad,
> Would you comment on what you expect for something like AGTL+ which is
> almost an open drain, but has a weak pullup?  The weak pullup 
> alone can't
> pull a 50 ohm resistor up very far.
> 
> Aubrey Sparkman
> Signal Integrity
> Aubrey_Sparkman@Dell.com
> (512) 723-3592
> 
> 
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Friday, March 23, 2001 10:28 AM
> > To: ibis-users@vhdl.org
> > Subject: RE: different rising and falling Ramp dV
> > 
> > 
> > Mike,
> > 
> > The reason dV can be different for rising and falling edges 
> is because
> > the voltage swing does not have to be the same (in contrary of your
> > statement).
> > 
> > A falling edge ramp requires that the R_load resistor is 
> connected to
> > the supply rail.  This means that the falling edge characterizes the
> > pulldown turning on.  A rising edge ramps requires that the R_load
> > resistor is connected to GND.  This means that the rising edge ramp
> > characterizes how the pullup turns on.  Since the pullup 
> and pulldown
> > IV curves do not have to be the same (strength), you can 
> get different
> > swings for these two edges, hence the dV numbers will also be 
> > different.
> > 
> > Now, if you consider an open drain type buffer, where the rising and
> > falling edges are characterized with R_load connected to the 
> > same rail,
> > your statement is correct, the swing will be the same, therefore dV
> > should also be the same.  However, notice that in this case one edge
> > describes how the device turns on, the other edge describes how the
> > same device turns off.
> > 
> > Arpad
> > ==============================================================
> > =========
> > 
> > -----Original Message-----
> > From: Mike LaBonte [mailto:mike@labonte.com]
> > Sent: Thursday, March 22, 2001 3:19 PM
> > To: ibis-users@vhdl.org
> > Subject: different rising and falling Ramp dV
> > 
> > 
> > Many IBIS models have different values for dV in the dV/dt_r 
> > and dV/dt_f.
> > The clipping below from IBIS spec shows an example. But the 
> > usage rules
> > imply that dV must be 60% of the voltage swing. If the 
> > voltage swing is
> > measured between the 2 steady-state voltages, then how 
> could you have
> > different values for rise and fall dV? If there is variation in how
> > simulators handle the Ramp dV values, then this may matter.
> > 
> > Mike LaBonte
> > 
> > |=============================================================
> > ==============
> > ==
> > |     Keyword:  [Ramp]
> > |    Required:  Yes, except for inputs, terminators, Series and
> > Series_switch
> > |               model types.
> > | Description:  Defines the rise and fall times of a buffer.  
> > The ramp rate
> > |               does not include packaging but does include 
> > the effects of
> > the
> > |               C_comp parameter.
> > |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> > | Usage Rules:  The rise and fall time is defined as the time 
> > it takes the
> > |               output to go from 20% to 80% of its final 
> > value.  The ramp
> > |               rate is defined as:
> > |
> > |               dV          20% to 80% voltage swing
> > |               -- = ----------------------------------------
> > |               dt   Time it takes to swing the above voltage
> > |
> > |               The ramp rate must be specified as an 
> > explicit fraction and
> > |               must not be reduced.  The [Ramp] values can 
> > use "NA" for the
> > |               min and max values only.  The R_load subparameter is
> > optional
> > |               if the default 50 ohm load is used.  The 
> > R_load subparameter
> > |               is required if a non-standard load is used.
> > |-------------------------------------------------------------
> > --------------
> > --
> > [Ramp]
> > | variable      typ             min             max
> > dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> > dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> > R_load = 300ohms
> > 
> > 
> 
> 
> 
> 


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

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

------_=_NextPart_000_01C0B3EA.6E6A18E0--
 
From owner-ibis Sat Mar 24 00:40:47 2001
Received: from techst02.technion.ac.il (techst02.technion.ac.il [132.68.7.4])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2O8ej519942
	for <ibis-users@vhdl.org>; Sat, 24 Mar 2001 00:40:46 -0800 (PST)
Received: by techst02.technion.ac.il (Postfix, from userid 19755)
	id DE1CF14D74; Sat, 24 Mar 2001 10:37:51 +0200 (IST)
Received: from localhost (localhost [127.0.0.1])
	by techst02.technion.ac.il (Postfix) with ESMTP id C4FDE11F02
	for <ibis-users@vhdl.org>; Sat, 24 Mar 2001 10:37:51 +0200 (IST)
Date: Sat, 24 Mar 2001 10:37:51 +0200 (IST)
From: Offer Kaye <sofferk@techst02.technion.ac.il>
To: ibis-users@vhdl.org
Subject: IBIS usage rules
Message-ID: <Pine.SOL.4.10.10103241034560.24836-100000@techst02.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all,
Just a simple usage question- when using keywords such as "[Source]" or
"[Notes]", if the text continues on the following lines, should I use the
pipe char to comment these lines, or is it legal to just continue the
text?

Thanks in advance,
Offer Kaye
sofferk@techst02.technion.ac.il

 
From owner-ibis Sun Mar 25 22:04:03 2001
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2Q641529675
	for <ibis-users@vhdl.org>; Sun, 25 Mar 2001 22:04:02 -0800 (PST)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA05449;
	Mon, 26 Mar 2001 08:01:05 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA17127;
	Mon, 26 Mar 2001 08:01:05 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2653.19)
	id <HBM4STX8>; Mon, 26 Mar 2001 08:01:05 +0200
Message-ID: <AFC76835727DD211A7C20008C71EAF1E01BB1494@MCHH230E>
From: Lenski Eckhard <Eckhard.Lenski@icn.siemens.de>
To: "'Aubrey_Sparkman@Dell.com'" <Aubrey_Sparkman@dell.com>,
   arpad.muranyi@intel.com, ibis-users@vhdl.org
Subject: AW: different rising and falling Ramp dV  ( AGTL+)
Date: Mon, 26 Mar 2001 08:00:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f2Q68i529676

May it be, that this should be modelled ( or is modelled ) with a  driver schedule?

This is my experience with AGTL+, as the weak pullup-transistor is not always on.
It is modelled in a driverschedule, with the pulldown as the top-level-model
and the pullup as a 'sub-model'
Furthermore there appear now models, which includes the termination on chip,
( and the termination is always 'on' ) 
which is then modeled in the powerclamp of the top-level-model.


Eckhard Lenski
Siemens AG		ICN M TC 6
Hofmannstr.51	81359 München
Tel :	0049 89 722 27776
Fax:	0049 89 722 44692
Email:	eckhard.lenski@icn.siemens.de

> -----Ursprüngliche Nachricht-----
> Von:	Aubrey_Sparkman@Dell.com [SMTP:Aubrey_Sparkman@Dell.com]
> Gesendet am:	Freitag, 23. März 2001 23:42
> An:	arpad.muranyi@intel.com; ibis-users@vhdl.org
> Betreff:	RE: different rising and falling Ramp dV
> 
> The case I had in mind has the dV rising about 1/3 the dV falling.  The dV
> rising seems to be taken from the Rising V/T curve with 50 ohms to ground
> and the dV falling seems to be taken from the Falling V/T curve with 50 ohms
> to Vtt.  There is no pullup in the power clamp for this buffer.  I didn't
> ask my supplier whether the pullup was always on but I don't think it is.
> This buffer is used on a bus that has at least one pullup.  This seems to be
> a little different from what you discussed; perhaps an alternate method?
> Perhaps I am missing something?
> 
> BTW, my simulator seems to be OK with this as my simulations match what we
> measure in the lab.
> 
> Aubrey Sparkman
> Signal Integrity
> Aubrey_Sparkman@Dell.com
> (512) 723-3592
> 
> 
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Friday, March 23, 2001 2:58 PM
> > To: ibis-users@vhdl.org
> > Subject: RE: different rising and falling Ramp dV
> > 
> > 
> > Sorry, I got dyslexic a bit...  For the open-drain GTL buffer
> > the resistor is not connected to GND, but to Vtt, and the
> > "ON" endpoints of the Vt curve will definitely not go to GND,
> > but the "OFF" endpoints should be at Vtt.
> > 
> > Arpad
> > ==============================================================
> > 
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Friday, March 23, 2001 12:52 PM
> > To: ibis-users@vhdl.org
> > Subject: RE: different rising and falling Ramp dV
> > 
> > 
> > Aubrey,
> > 
> > In light of the original question from Mike and my answer to it,
> > I don't expect anything different in this case.  I assume that
> > the weak pullup you are talking about is always on.  So the
> > two Vt curves you will make will be generated with a resistor
> > to ground, and the rising and falling edge will characterize
> > how the switched pulldown is turning on and off.  The amplitude
> > of the rising and falling edge will be the same, but may not
> > start or end on the rail (GND) exactly due to the weak pullup.
> > 
> > I am not sure if this answered your question, or whether I
> > understood your question fully.  Did this help?
> > 
> > Arpad
> > ===============================================================
> > 
> > -----Original Message-----
> > From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> > Sent: Friday, March 23, 2001 10:49 AM
> > To: arpad.muranyi@intel.com; ibis-users@vhdl.org
> > Subject: RE: different rising and falling Ramp dV
> > 
> > 
> > Arpad,
> > Would you comment on what you expect for something like AGTL+ which is
> > almost an open drain, but has a weak pullup?  The weak pullup 
> > alone can't
> > pull a 50 ohm resistor up very far.
> > 
> > Aubrey Sparkman
> > Signal Integrity
> > Aubrey_Sparkman@Dell.com
> > (512) 723-3592
> > 
> > 
> > > -----Original Message-----
> > > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > > Sent: Friday, March 23, 2001 10:28 AM
> > > To: ibis-users@vhdl.org
> > > Subject: RE: different rising and falling Ramp dV> 
> > > 
> > > 
> > > Mike,
> > > 
> > > The reason dV can be different for rising and falling edges 
> > is because
> > > the voltage swing does not have to be the same (in contrary of your
> > > statement).
> > > 
> > > A falling edge ramp requires that the R_load resistor is 
> > connected to
> > > the supply rail.  This means that the falling edge characterizes the
> > > pulldown turning on.  A rising edge ramps requires that the R_load
> > > resistor is connected to GND.  This means that the rising edge ramp
> > > characterizes how the pullup turns on.  Since the pullup 
> > and pulldown
> > > IV curves do not have to be the same (strength), you can 
> > get different
> > > swings for these two edges, hence the dV numbers will also be 
> > > different.
> > > 
> > > Now, if you consider an open drain type buffer, where the rising and
> > > falling edges are characterized with R_load connected to the 
> > > same rail,
> > > your statement is correct, the swing will be the same, therefore dV
> > > should also be the same.  However, notice that in this case one edge
> > > describes how the device turns on, the other edge describes how the
> > > same device turns off.
> > > 
> > > Arpad
> > > ==============================================================
> > > =========
> > > 
> > > -----Original Message-----
> > > From: Mike LaBonte [mailto:mike@labonte.com]
> > > Sent: Thursday, March 22, 2001 3:19 PM
> > > To: ibis-users@vhdl.org
> > > Subject: different rising and falling Ramp dV
> > > 
> > > 
> > > Many IBIS models have different values for dV in the dV/dt_r 
> > > and dV/dt_f.
> > > The clipping below from IBIS spec shows an example. But the 
> > > usage rules
> > > imply that dV must be 60% of the voltage swing. If the 
> > > voltage swing is
> > > measured between the 2 steady-state voltages, then how 
> > could you have
> > > different values for rise and fall dV? If there is variation in how
> > > simulators handle the Ramp dV values, then this may matter.
> > > 
> > > Mike LaBonte
> > > 
> > > |=============================================================
> > > ==============
> > > ==
> > > |     Keyword:  [Ramp]
> > > |    Required:  Yes, except for inputs, terminators, Series and
> > > Series_switch
> > > |               model types.
> > > | Description:  Defines the rise and fall times of a buffer.  
> > > The ramp rate
> > > |               does not include packaging but does include 
> > > the effects of
> > > the
> > > |               C_comp parameter.
> > > |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> > > | Usage Rules:  The rise and fall time is defined as the time 
> > > it takes the
> > > |               output to go from 20% to 80% of its final 
> > > value.  The ramp
> > > |               rate is defined as:
> > > |
> > > |               dV          20% to 80% voltage swing
> > > |               -- = ----------------------------------------
> > > |               dt   Time it takes to swing the above voltage
> > > |
> > > |               The ramp rate must be specified as an 
> > > explicit fraction and
> > > |               must not be reduced.  The [Ramp] values can 
> > > use "NA" for the
> > > |               min and max values only.  The R_load subparameter is
> > > optional
> > > |               if the default 50 ohm load is used.  The 
> > > R_load subparameter
> > > |               is required if a non-standard load is used.
> > > |-------------------------------------------------------------
> > > --------------
> > > --
> > > [Ramp]
> > > | variable      typ             min             max
> > > dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> > > dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> > > R_load = 300ohms
> > > 
> > > 
> > 
> > 
> > 
> > 
>  << Datei: Sparkman, Aubrey.vcf >> 
 
From owner-ibis Mon Mar 26 08:39:29 2001
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2QGdQ502911
	for <ibis-users@vhdl.org>; Mon, 26 Mar 2001 08:39:28 -0800 (PST)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id QAA07774;
	Mon, 26 Mar 2001 16:35:15 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 26 Mar 2001 16:35:14 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <HT0GK0R0>; Mon, 26 Mar 2001 08:35:13 -0800
Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A75B4@orsmsx49.jf.intel.com>
From: "Peters, Stephen" <stephen.peters@intel.com>
To: "'Offer Kaye'" <sofferk@techst02.technion.ac.il>, ibis-users@vhdl.org
Subject: RE: IBIS usage rules
Date: Mon, 26 Mar 2001 08:33:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Offer:

   There is no need to use the comment character.  For the two keywords you
mention, the text can span multipule lines.  The ending of the text is
marked by the occurance of the next keyword. 

  Regards,
  Stephen Peters
  Intel Corp.


-----Original Message-----
From: Offer Kaye [mailto:sofferk@techst02.technion.ac.il]
Sent: Saturday, March 24, 2001 12:38 AM
To: ibis-users@vhdl.org
Subject: IBIS usage rules


Hi all,
Just a simple usage question- when using keywords such as "[Source]" or
"[Notes]", if the text continues on the following lines, should I use the
pipe char to comment these lines, or is it legal to just continue the
text?

Thanks in advance,
Offer Kaye
sofferk@techst02.technion.ac.il


 
From owner-ibis Mon Mar 26 09:00:49 2001
Received: from ausxc10.us.dell.com (ausxc10.us.dell.com [143.166.98.229])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2QH0k502985
	for <ibis-users@vhdl.org>; Mon, 26 Mar 2001 09:00:48 -0800 (PST)
Received: by ausxc10.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <HW1XTM8S>; Mon, 26 Mar 2001 10:51:46 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F8C5@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: stephen.peters@intel.com, sofferk@techst02.technion.ac.il,
   ibis-users@vhdl.org
Subject: RE: IBIS usage rules
Date: Mon, 26 Mar 2001 10:53:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0B615.49C83580"

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

------_=_NextPart_000_01C0B615.49C83580
Content-Type: text/plain;
	charset="iso-8859-1"

At least that's the way the spec says it's supposed to work.

However, I have seen an IBIS reader/converter complain when it found the
word "copyright" (in lowercase without brackets) in the notes section.  I
had to move the copyright to the [Copyright] section and remove other
instances of the word "copyright".

So ask your customers...

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


> -----Original Message-----
> From: Peters, Stephen [mailto:stephen.peters@intel.com]
> Sent: Monday, March 26, 2001 10:34 AM
> To: 'Offer Kaye'; ibis-users@vhdl.org
> Subject: RE: IBIS usage rules
> 
> 
> Hi Offer:
> 
>    There is no need to use the comment character.  For the 
> two keywords you
> mention, the text can span multipule lines.  The ending of the text is
> marked by the occurance of the next keyword. 
> 
>   Regards,
>   Stephen Peters
>   Intel Corp.
> 
> 
> -----Original Message-----
> From: Offer Kaye [mailto:sofferk@techst02.technion.ac.il]
> Sent: Saturday, March 24, 2001 12:38 AM
> To: ibis-users@vhdl.org
> Subject: IBIS usage rules
> 
> 
> Hi all,
> Just a simple usage question- when using keywords such as 
> "[Source]" or
> "[Notes]", if the text continues on the following lines, 
> should I use the
> pipe char to comment these lines, or is it legal to just continue the
> text?
> 
> Thanks in advance,
> Offer Kaye
> sofferk@techst02.technion.ac.il
> 
> 
> 


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

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

------_=_NextPart_000_01C0B615.49C83580--
 
From owner-ibis Tue Mar 27 05:21:25 2001
Received: from mailhost.avanticorp.com (mailhost.avanticorp.com [63.167.1.13])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RDLM512213
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 05:21:24 -0800 (PST)
Received: from mailhost.avanticorp.com (localhost [127.0.0.1])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2RDIJl24961
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 05:18:19 -0800 (PST)
Received: from ally.china.avanticorp.com (nat-68.avanticorp.com.cn [202.96.225.68])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2RDIGu24929
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 05:18:17 -0800 (PST)
Received: from avanticorp.com (scottie.china.avanticorp.com [172.21.18.23])
	by ally.china.avanticorp.com (8.9.1b+Sun/8.9.3) with ESMTP id VAA01030
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 21:15:56 +0800 (CST)
Sender: wqzhang@avanticorp.com
Message-ID: <3AC091A7.152C9F8D@avanticorp.com>
Date: Tue, 27 Mar 2001 21:12:07 +0800
From: Wenqing Zhang <wqzhang@avanticorp.com>
Reply-To: wqzhang@avanticorp.com
Organization: Avant!
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@vhdl.org
Subject: about IO_Buffer model's ac analysis
Content-Type: multipart/alternative;
 boundary="------------12B97F71DB929BABB9F863E7"


--------------12B97F71DB929BABB9F863E7
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

hi, all,

I has a problem.
I think that ibs model was generated  by spice's dc analysis and
transient analysis,
so ibs model don't contain frequency response information.

now I want to realize ac analysis  to ibs model version3.2 in
Star-Hspice , but the simulation results
were very bad.
perhaps ibs model should contain frequency response information which
were generated with spice's
ac analysis.

do you think my idea? pls help me.

I am not a member of ibis-user, so pls email to:
wqzhang@avanticorp.com

--
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
 No.55, West Huaihai Road, Shanghai, 200030, P.R.China



--------------12B97F71DB929BABB9F863E7
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi, all,
<p>I has a problem.
<br>I think that ibs model was generated&nbsp; by spice's dc analysis and
transient analysis,
<br>so ibs model don't contain frequency response information.
<p>now I want to realize ac analysis&nbsp; to ibs model version3.2 in Star-Hspice
, but the simulation results
<br>were very bad.
<br>perhaps ibs model should contain frequency response information which
were generated with spice's
<br>ac analysis.
<p>do you think my idea? pls help me.
<p>I am not a member of ibis-user, so pls email to:
<br>wqzhang@avanticorp.com
<pre>--&nbsp;
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
&nbsp;Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
&nbsp;No.55, West Huaihai Road, Shanghai, 200030, P.R.China</pre>
&nbsp;</html>

--------------12B97F71DB929BABB9F863E7--

 
From owner-ibis Tue Mar 27 05:21:43 2001
Received: from mailhost.avanticorp.com (mailhost.avanticorp.com [63.167.1.13])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RDLf512216
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 05:21:42 -0800 (PST)
Received: from mailhost.avanticorp.com (localhost [127.0.0.1])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2RDIh025033
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 05:18:43 -0800 (PST)
Received: from ally.china.avanticorp.com (nat-68.avanticorp.com.cn [202.96.225.68])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2RDIeu25029
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 05:18:41 -0800 (PST)
Received: from avanticorp.com (scottie.china.avanticorp.com [172.21.18.23])
	by ally.china.avanticorp.com (8.9.1b+Sun/8.9.3) with ESMTP id VAA01086
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 21:16:20 +0800 (CST)
Sender: wqzhang@avanticorp.com
Message-ID: <3AC091BF.2B36F125@avanticorp.com>
Date: Tue, 27 Mar 2001 21:12:31 +0800
From: Wenqing Zhang <wqzhang@avanticorp.com>
Reply-To: wqzhang@avanticorp.com
Organization: Avant!
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@eda.org
Subject: about ibs model's ac analysis
Content-Type: multipart/alternative;
 boundary="------------72A702926725767143F6F591"


--------------72A702926725767143F6F591
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

hi, all,

I has a problem.
I think that ibs model was generated  by spice's dc analysis and
transient analysis,
so ibs model don't contain frequency response information.

now I want to realize ac analysis  to ibs model version3.2 in
Star-Hspice , but the simulation results
were very bad.
perhaps ibs model should contain frequency response information which
were generated with spice's
ac analysis.

do you think my idea? pls help me.

I am not a member of ibis-user, so pls email to:
wqzhang@avanticorp.com

--
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
 No.55, West Huaihai Road, Shanghai, 200030, P.R.China



--------------72A702926725767143F6F591
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi, all,
<p>I has a problem.
<br>I think that ibs model was generated&nbsp; by spice's dc analysis and
transient analysis,
<br>so ibs model don't contain frequency response information.
<p>now I want to realize ac analysis&nbsp; to ibs model version3.2 in Star-Hspice
, but the simulation results
<br>were very bad.
<br>perhaps ibs model should contain frequency response information which
were generated with spice's
<br>ac analysis.
<p>do you think my idea? pls help me.
<p>I am not a member of ibis-user, so pls email to:
<br>wqzhang@avanticorp.com
<pre>--&nbsp;
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
&nbsp;Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
&nbsp;No.55, West Huaihai Road, Shanghai, 200030, P.R.China</pre>
&nbsp;</html>

--------------72A702926725767143F6F591--

 
From owner-ibis Tue Mar 27 07:36:47 2001
Received: from ausxc07.us.dell.com (ausxc07.us.dell.com [143.166.99.215])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RFah513119
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 07:36:45 -0800 (PST)
Received: by ausxc07.us.dell.com with Internet Mail Service (5.5.2650.21)
	id <HYCFLZGT>; Tue, 27 Mar 2001 09:33:01 -0600
Message-ID: <CDF99E351003D311A8B0009027457F1405C5F8CC@ausxmrr501.us.dell.com>
From: Aubrey_Sparkman@Dell.com
To: Eckhard.Lenski@icn.siemens.de, arpad.muranyi@intel.com,
   ibis-users@vhdl.org
Subject: RE: different rising and falling Ramp dV  ( AGTL+)
Date: Tue, 27 Mar 2001 09:32:58 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f2RFbH513121

Eckhard,
I have seen buffers modeled in IBIS ver 3.2 as you describe with the strong
pull down in the top level model, the "on die" termination in the power
clamp, and the weak pullup in a sub model.  But the case I mentioned below
was a ver 2.1 level model and the IC has no "on die" termination.  My intent
was to encourage further discussion about (alternate?) ways to model
buffers.

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

-----Original Message-----
From: Lenski Eckhard [mailto:Eckhard.Lenski@icn.siemens.de]
Sent: Monday, March 26, 2001 12:01 AM
To: 'Aubrey_Sparkman@Dell.com'; arpad.muranyi@intel.com;
ibis-users@vhdl.org
Subject: AW: different rising and falling Ramp dV ( AGTL+)


May it be, that this should be modelled ( or is modelled ) with a  driver
schedule?

This is my experience with AGTL+, as the weak pullup-transistor is not
always on.
It is modelled in a driverschedule, with the pulldown as the top-level-model
and the pullup as a 'sub-model'
Furthermore there appear now models, which includes the termination on chip,
( and the termination is always 'on' ) 
which is then modeled in the powerclamp of the top-level-model.


Eckhard Lenski
Siemens AG		ICN M TC 6
Hofmannstr.51	81359 München
Tel :	0049 89 722 27776
Fax:	0049 89 722 44692
Email:	eckhard.lenski@icn.siemens.de

> -----Ursprüngliche Nachricht-----
> Von:	Aubrey_Sparkman@Dell.com [SMTP:Aubrey_Sparkman@Dell.com]
> Gesendet am:	Freitag, 23. März 2001 23:42
> An:	arpad.muranyi@intel.com; ibis-users@vhdl.org
> Betreff:	RE: different rising and falling Ramp dV
> 
> The case I had in mind has the dV rising about 1/3 the dV falling.  The dV
> rising seems to be taken from the Rising V/T curve with 50 ohms to ground
> and the dV falling seems to be taken from the Falling V/T curve with 50
ohms
> to Vtt.  There is no pullup in the power clamp for this buffer.  I didn't
> ask my supplier whether the pullup was always on but I don't think it is.
> This buffer is used on a bus that has at least one pullup.  This seems to
be
> a little different from what you discussed; perhaps an alternate method?
> Perhaps I am missing something?
> 
> BTW, my simulator seems to be OK with this as my simulations match what we
> measure in the lab.
> 
> Aubrey Sparkman
> Signal Integrity
> Aubrey_Sparkman@Dell.com
> (512) 723-3592
> 
> 
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Friday, March 23, 2001 2:58 PM
> > To: ibis-users@vhdl.org
> > Subject: RE: different rising and falling Ramp dV
> > 
> > 
> > Sorry, I got dyslexic a bit...  For the open-drain GTL buffer
> > the resistor is not connected to GND, but to Vtt, and the
> > "ON" endpoints of the Vt curve will definitely not go to GND,
> > but the "OFF" endpoints should be at Vtt.
> > 
> > Arpad
> > ==============================================================
> > 
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > Sent: Friday, March 23, 2001 12:52 PM
> > To: ibis-users@vhdl.org
> > Subject: RE: different rising and falling Ramp dV
> > 
> > 
> > Aubrey,
> > 
> > In light of the original question from Mike and my answer to it,
> > I don't expect anything different in this case.  I assume that
> > the weak pullup you are talking about is always on.  So the
> > two Vt curves you will make will be generated with a resistor
> > to ground, and the rising and falling edge will characterize
> > how the switched pulldown is turning on and off.  The amplitude
> > of the rising and falling edge will be the same, but may not
> > start or end on the rail (GND) exactly due to the weak pullup.
> > 
> > I am not sure if this answered your question, or whether I
> > understood your question fully.  Did this help?
> > 
> > Arpad
> > ===============================================================
> > 
> > -----Original Message-----
> > From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> > Sent: Friday, March 23, 2001 10:49 AM
> > To: arpad.muranyi@intel.com; ibis-users@vhdl.org
> > Subject: RE: different rising and falling Ramp dV
> > 
> > 
> > Arpad,
> > Would you comment on what you expect for something like AGTL+ which is
> > almost an open drain, but has a weak pullup?  The weak pullup 
> > alone can't
> > pull a 50 ohm resistor up very far.
> > 
> > Aubrey Sparkman
> > Signal Integrity
> > Aubrey_Sparkman@Dell.com
> > (512) 723-3592
> > 
> > 
> > > -----Original Message-----
> > > From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
> > > Sent: Friday, March 23, 2001 10:28 AM
> > > To: ibis-users@vhdl.org
> > > Subject: RE: different rising and falling Ramp dV> 
> > > 
> > > 
> > > Mike,
> > > 
> > > The reason dV can be different for rising and falling edges 
> > is because
> > > the voltage swing does not have to be the same (in contrary of your
> > > statement).
> > > 
> > > A falling edge ramp requires that the R_load resistor is 
> > connected to
> > > the supply rail.  This means that the falling edge characterizes the
> > > pulldown turning on.  A rising edge ramps requires that the R_load
> > > resistor is connected to GND.  This means that the rising edge ramp
> > > characterizes how the pullup turns on.  Since the pullup 
> > and pulldown
> > > IV curves do not have to be the same (strength), you can 
> > get different
> > > swings for these two edges, hence the dV numbers will also be 
> > > different.
> > > 
> > > Now, if you consider an open drain type buffer, where the rising and
> > > falling edges are characterized with R_load connected to the 
> > > same rail,
> > > your statement is correct, the swing will be the same, therefore dV
> > > should also be the same.  However, notice that in this case one edge
> > > describes how the device turns on, the other edge describes how the
> > > same device turns off.
> > > 
> > > Arpad
> > > ==============================================================
> > > =========
> > > 
> > > -----Original Message-----
> > > From: Mike LaBonte [mailto:mike@labonte.com]
> > > Sent: Thursday, March 22, 2001 3:19 PM
> > > To: ibis-users@vhdl.org
> > > Subject: different rising and falling Ramp dV
> > > 
> > > 
> > > Many IBIS models have different values for dV in the dV/dt_r 
> > > and dV/dt_f.
> > > The clipping below from IBIS spec shows an example. But the 
> > > usage rules
> > > imply that dV must be 60% of the voltage swing. If the 
> > > voltage swing is
> > > measured between the 2 steady-state voltages, then how 
> > could you have
> > > different values for rise and fall dV? If there is variation in how
> > > simulators handle the Ramp dV values, then this may matter.
> > > 
> > > Mike LaBonte
> > > 
> > > |=============================================================
> > > ==============
> > > ==
> > > |     Keyword:  [Ramp]
> > > |    Required:  Yes, except for inputs, terminators, Series and
> > > Series_switch
> > > |               model types.
> > > | Description:  Defines the rise and fall times of a buffer.  
> > > The ramp rate
> > > |               does not include packaging but does include 
> > > the effects of
> > > the
> > > |               C_comp parameter.
> > > |  Sub-Params:  dV/dt_r, dV/dt_f, R_load
> > > | Usage Rules:  The rise and fall time is defined as the time 
> > > it takes the
> > > |               output to go from 20% to 80% of its final 
> > > value.  The ramp
> > > |               rate is defined as:
> > > |
> > > |               dV          20% to 80% voltage swing
> > > |               -- = ----------------------------------------
> > > |               dt   Time it takes to swing the above voltage
> > > |
> > > |               The ramp rate must be specified as an 
> > > explicit fraction and
> > > |               must not be reduced.  The [Ramp] values can 
> > > use "NA" for the
> > > |               min and max values only.  The R_load subparameter is
> > > optional
> > > |               if the default 50 ohm load is used.  The 
> > > R_load subparameter
> > > |               is required if a non-standard load is used.
> > > |-------------------------------------------------------------
> > > --------------
> > > --
> > > [Ramp]
> > > | variable      typ             min             max
> > > dV/dt_r         2.20/1.06n      1.92/1.28n      2.49/650p
> > > dV/dt_f         2.46/1.21n      2.21/1.54n      2.70/770p
> > > R_load = 300ohms
> > > 
> > > 
> > 
> > 
> > 
> > 
>  << Datei: Sparkman, Aubrey.vcf >> 
 
From owner-ibis Tue Mar 27 08:52:57 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RGqs513645
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 08:52:56 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id IAA04655; Tue, 27 Mar 2001 08:49:49 -0800 (PST)
Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19)
	id <HCZDS8K1>; Tue, 27 Mar 2001 08:49:48 -0800
Message-ID: <2179BC5B6583D311B44700508B441469041775A0@svr-orw-exc-02.wv.mentorg.com>
From: "Reid, Chris" <chris_reid@mentorg.com>
To: "'wqzhang@avanticorp.com'" <wqzhang@avanticorp.com>, ibis-users@vhdl.org
Subject: RE: about IO_Buffer model's ac analysis
Date: Tue, 27 Mar 2001 08:49:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0B6DD.EADBB9B0"

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_01C0B6DD.EADBB9B0
Content-Type: text/plain;
	charset="gb2312"

Wenqing,
 
You are right.  IBIS contains only static information in the IV curves.  The
dynamic information is only in the VT curves, which should be given for
load conditions similar to the environment the part will be used in.  This
still leaves IBIS with fundamentally a static model.  For most devices this
model seems to be accurate enough.  However, as you may know the
IBIS committee is in the process of defining IBIS-X, which will allow more
general modeling for difficult cases.
 
Chris Reid

-----Original Message-----
From: Wenqing Zhang [mailto:wqzhang@avanticorp.com]
Sent: Tuesday, March 27, 2001 5:12 AM
To: ibis-users@vhdl.org
Subject: about IO_Buffer model's ac analysis


hi, all, 

I has a problem. 
I think that ibs model was generated  by spice's dc analysis and transient
analysis, 
so ibs model don't contain frequency response information. 


now I want to realize ac analysis  to ibs model version3.2 in Star-Hspice ,
but the simulation results 
were very bad. 
perhaps ibs model should contain frequency response information which were
generated with spice's 
ac analysis. 


do you think my idea? pls help me. 


I am not a member of ibis-user, so pls email to: 
wqzhang@avanticorp.com 

-- 

Thanks

Wenqing Zhang

______________End Forwarded Message_________

o:62834978-701

 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza

 No.55, West Huaihai Road, Shanghai, 200030, P.R.China
  


------_=_NextPart_001_01C0B6DD.EADBB9B0
Content-Type: text/html;
	charset="gb2312"

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


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001>Wenqing,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>You 
are right.&nbsp; IBIS contains only static information in the IV curves.&nbsp; 
The</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001>dynamic information is only in the VT curves, which 
should be given for</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>load 
conditions similar to the environment the part will be used in.&nbsp; 
This</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>still 
leaves IBIS with fundamentally a static model.&nbsp; For most devices 
this</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>model 
seems to be accurate enough.&nbsp; However, as you may know 
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>IBIS 
committee is in the process of defining IBIS-X, which will allow 
more</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001>general modeling for difficult 
cases.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>Chris 
Reid</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Wenqing Zhang 
  [mailto:wqzhang@avanticorp.com]<BR><B>Sent:</B> Tuesday, March 27, 2001 5:12 
  AM<BR><B>To:</B> ibis-users@vhdl.org<BR><B>Subject:</B> about IO_Buffer 
  model's ac analysis<BR><BR></DIV></FONT>hi, all, 
  <P>I has a problem. <BR>I think that ibs model was generated&nbsp; by spice's 
  dc analysis and transient analysis, <BR>so ibs model don't contain frequency 
  response information. 
  <P>now I want to realize ac analysis&nbsp; to ibs model version3.2 in 
  Star-Hspice , but the simulation results <BR>were very bad. <BR>perhaps ibs 
  model should contain frequency response information which were generated with 
  spice's <BR>ac analysis. 
  <P>do you think my idea? pls help me. 
  <P>I am not a member of ibis-user, so pls email to: <BR>wqzhang@avanticorp.com 
<PRE>--&nbsp;
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
&nbsp;Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
&nbsp;No.55, West Huaihai Road, Shanghai, 200030, P.R.China</PRE>&nbsp; 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0B6DD.EADBB9B0--
 
From owner-ibis Tue Mar 27 08:59:21 2001
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RGxF513700
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 08:59:16 -0800 (PST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id QAA07210;
	Tue, 27 Mar 2001 16:54:57 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 27 Mar 2001 16:54:56 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <HT9GL17Y>; Tue, 27 Mar 2001 08:54:55 -0800
Message-ID: <10C8636AE359D4119118009027AE99870515536F@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: "'wqzhang@avanticorp.com'" <wqzhang@avanticorp.com>, ibis-users@eda.org
Subject: RE: about ibs model's ac analysis
Date: Tue, 27 Mar 2001 08:54:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0B6DE.A1270DA0"

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_01C0B6DE.A1270DA0
Content-Type: text/plain;
	charset="gb2312"

Wenqing,
 
Your observation is true, but not totally.  It is true that the
IV curves of IBIS models are made with .DC or .TRAN mode.  This
can only provide a frequency independent impedance (or R) for a
given operating point (voltage).  However, IBIS models also have
a parameter called C_comp, which is a primitive way of introducing
some AC characteristics.  This C_comp is typically in parallel
with the IV curve's non linear impedance (R), so the overall effect
is basically a parallel RC circuit.  With the new feature of C_comp
being split into four parts the situation can get a little more
complicated, but in an AC analysis sense this is still pretty simple.
 
Now, I agree that this simple RC circuit is not very sophisticated
for a frequency domain analysis.  However, in this initial 
implementation the emphasis should not be on the buffer's AC accuracy.
The IBIS open forum is already working on improvements to the
specification which will enable us to make more accurate AC models
also (IBIS-X) in the future.
 
Currently, frequency domain analysis in Signal Integrity Engineering
of digital products (such as computer boards) is used primarily to
detect problems with the characteristics of the interconnects.  In
some cases it is desirable to include the driving or terminating
impedances of the buffers and receivers in the AC analysis.  When
we have nothing but IBIS models available, it would be useful to be
able to this with the B-elements.  However crude it may be, it is
still better than nothing.
 
On the other hand, since I am working on this issue now, I have discovered
that a MOSFET transistor is actually not all that complicated in terms
of frequency domain analysis.  I can replace the transistor with a
one-port equivalent (as if I was looking into it from the die pad)
using a transfer function with two or three terms in the (numerator
and) denominator or with a few poles.  (I tried this with the pole/zero,
and the Laplace elements in HSPICE).
 
I found a problem, though.  I ran a pole/zero analysis to find the
poles (and zeroes) of such a one port of a MOSFET.  (It didn't have
zeroes).  I ran this at multiple DC bias points to be able to include
voltage dependencies.  Then I made an equivalent circuit using
voltage dependent resistors and capacitors, and ran a time domain
simulation to see whether the step or natural response of this
equivalent circuit will give me the same result as the original
MOSFET.  Well, it DOESN'T!  I tried to look for mistakes etc...,
but the only conclusion I get is that the .AC and the .TRAN models
of the MOSFET are not the same in HSPICE, and that is where the
difference comes from.  I would like someone interested in this
to verify it for me.
 
Now, the philosophical question is this:  The above story tells us
that the transfer function of a MOSFET is different for the AC and
TRAN modes in HSPCIE.  Should they not be the same?  If they are
different, my AC analysis will not give me the same picture of what
my system does compared with a TRAN analysis.  Is that right?
 
Arpad Muranyi
Intel Corporation
=================================================================
 
 
-----Original Message-----
From: Wenqing Zhang [mailto:wqzhang@avanticorp.com]
Sent: Tuesday, March 27, 2001 5:13 AM
To: ibis-users@eda.org
Subject: about ibs model's ac analysis


hi, all, 

I has a problem. 
I think that ibs model was generated  by spice's dc analysis and transient
analysis, 
so ibs model don't contain frequency response information. 


now I want to realize ac analysis  to ibs model version3.2 in Star-Hspice ,
but the simulation results 
were very bad. 
perhaps ibs model should contain frequency response information which were
generated with spice's 
ac analysis. 


do you think my idea? pls help me. 


I am not a member of ibis-user, so pls email to: 
wqzhang@avanticorp.com 

-- 

Thanks

Wenqing Zhang

______________End Forwarded Message_________

o:62834978-701

 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza

 No.55, West Huaihai Road, Shanghai, 200030, P.R.China
  

------_=_NextPart_001_01C0B6DE.A1270DA0
Content-Type: text/html;
	charset="gb2312"

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


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>Wenqing,</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Your 
observation is true, but not totally.&nbsp; It is true that 
the</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>IV curves of 
IBIS models are made with .DC or .TRAN mode.&nbsp; This</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>can only 
provide a frequency independent impedance (or R) for a</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>given 
</SPAN></FONT><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>operating point (voltage).&nbsp; However, IBIS models 
also have</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>a 
</SPAN></FONT><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>parameter called C_comp, which is a primitive way of 
introducing</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>some AC 
characteristics.&nbsp; This C_comp is typically in parallel</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>with the IV 
curve's non linear impedance (R), so the overall effect</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>is basically 
</SPAN></FONT><FONT face="Courier New" size=2><SPAN class=223040516-27032001>a 
parallel RC circuit.&nbsp; With the new feature of C_comp</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>being split 
into four parts the situation can get a little more</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>complicated, 
but in an AC analysis sense this is still pretty simple.</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Now, I agree 
that this simple RC circuit is not very sophisticated</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>for a 
frequency domain analysis.&nbsp; However, in this initial </SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>implementation the emphasis should not be 
</SPAN></FONT><FONT face="Courier New" size=2><SPAN class=223040516-27032001>on 
the buffer's AC accuracy.</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>The IBIS 
open forum is already working on improvements to the</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>specification which will enable us to make more 
accurate AC models</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>also 
(IBIS-X) in the future.</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Currently, 
frequency domain analysis in Signal Integrity Engineering</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>of digital 
products (such as computer boards) </SPAN></FONT><FONT face="Courier New" 
size=2><SPAN class=223040516-27032001>is used primarily to</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>detect 
</SPAN></FONT><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>problems </SPAN></FONT><FONT face="Courier New" 
size=2><SPAN class=223040516-27032001>with the characteristics of the 
interconnects.&nbsp; In</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>some cases 
it is desirable to include the </SPAN></FONT><FONT face="Courier New" 
size=2><SPAN class=223040516-27032001>driving or terminating</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>impedances 
of the buffers and receivers in the AC analysis.&nbsp; When</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>we have 
nothing but IBIS models available, it would be useful to be</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>able to this 
with the B-elements.&nbsp; However crude it may be, it is</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>still better 
than nothing.</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>On the other 
hand, since I am working on this issue now, I have 
discovered</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>that a 
MOSFET transistor is actually not all that complicated in 
terms</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>of frequency 
domain analysis.&nbsp; I can replace the transistor with a</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>one-port 
equivalent (as if I was looking into it from the die pad)</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>using a 
transfer function with two or three terms in the (numerator</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>and) 
denominator or </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>with a few poles.&nbsp; (I tried this with the 
pole/zero,</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>and the 
Laplace elements in HSPICE).</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>I found a 
problem, though.&nbsp; I ran a pole/zero analysis to find 
the</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>poles (and 
zeroes) of such a one port of a MOSFET.&nbsp; (It didn't 
have</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>zeroes).&nbsp; I ran this at multiple DC bias points to 
be able to include</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>voltage 
dependencies.&nbsp; Then I made an equivalent </SPAN></FONT><FONT 
face="Courier New" size=2><SPAN class=223040516-27032001>circuit 
using</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>voltage 
dependent resistors and capacitors, and ran a time domain</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>simulation 
to see whether the step or natural response of this</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>equivalent 
circuit will give me the same result as the original</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>MOSFET.&nbsp; Well, it DOESN'T!&nbsp; I tried to look 
for mistakes etc...,</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>but the only 
conclusion I get is that the .AC and the .TRAN models</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>of the 
MOSFET are not the same in HSPICE, and that is where the</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>difference 
comes from.&nbsp; I would like someone interested in this</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>to verify it 
for me.</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Now, the 
philosophical question is this:&nbsp; The above story tells 
us</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>that the 
transfer function of a MOSFET is different for the AC and</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>TRAN modes 
in HSPCIE.&nbsp; Should they not be the same?&nbsp; If they 
are</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>different, 
</SPAN></FONT><FONT face="Courier New" size=2><SPAN class=223040516-27032001>my 
AC analysis will not give me the same picture of what</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>my system 
d</SPAN></FONT><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>oes compared with a TRAN analysis.&nbsp; Is that 
right?</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Arpad 
Muranyi</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Intel 
Corporation</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001>=================================================================</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Wenqing Zhang 
[mailto:wqzhang@avanticorp.com]<BR><B>Sent:</B> Tuesday, March 27, 2001 5:13 
AM<BR><B>To:</B> ibis-users@eda.org<BR><B>Subject:</B> about ibs model's ac 
analysis<BR><BR></FONT></DIV>hi, all, 
<P>I has a problem. <BR>I think that ibs model was generated&nbsp; by spice's dc 
analysis and transient analysis, <BR>so ibs model don't contain frequency 
response information. 
<P>now I want to realize ac analysis&nbsp; to ibs model version3.2 in 
Star-Hspice , but the simulation results <BR>were very bad. <BR>perhaps ibs 
model should contain frequency response information which were generated with 
spice's <BR>ac analysis. 
<P>do you think my idea? pls help me. 
<P>I am not a member of ibis-user, so pls email to: <BR>wqzhang@avanticorp.com <PRE>--&nbsp;
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
&nbsp;Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
&nbsp;No.55, West Huaihai Road, Shanghai, 200030, P.R.China</PRE>&nbsp; 
</BODY></HTML>

------_=_NextPart_001_01C0B6DE.A1270DA0--

 
From owner-ibis Tue Mar 27 09:06:51 2001
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RH6m513740
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 09:06:50 -0800 (PST)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id RAA12053;
	Tue, 27 Mar 2001 17:03:48 GMT
Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 27 Mar 2001 17:03:48 0000 (GMT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <HQ92TW96>; Tue, 27 Mar 2001 09:03:46 -0800
Message-ID: <10C8636AE359D4119118009027AE998705155370@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: "'Reid, Chris'" <chris_reid@mentorg.com>,
   "'wqzhang@avanticorp.com'"
	 <wqzhang@avanticorp.com>, ibis-users@vhdl.org
Subject: RE: about IO_Buffer model's ac analysis
Date: Tue, 27 Mar 2001 09:03:45 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0B6DF.E20C8F10"

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_01C0B6DF.E20C8F10
Content-Type: text/plain;
	charset="gb2312"

Chris,
 
Don't forget about the C_comp...
 
Arpad
==================================
-----Original Message-----
From: Reid, Chris [mailto:chris_reid@mentorg.com]
Sent: Tuesday, March 27, 2001 8:50 AM
To: 'wqzhang@avanticorp.com'; ibis-users@vhdl.org
Subject: RE: about IO_Buffer model's ac analysis


Wenqing,
 
You are right.  IBIS contains only static information in the IV curves.  The
dynamic information is only in the VT curves, which should be given for
load conditions similar to the environment the part will be used in.  This
still leaves IBIS with fundamentally a static model.  For most devices this
model seems to be accurate enough.  However, as you may know the
IBIS committee is in the process of defining IBIS-X, which will allow more
general modeling for difficult cases.
 
Chris Reid

-----Original Message-----
From: Wenqing Zhang [mailto:wqzhang@avanticorp.com]
Sent: Tuesday, March 27, 2001 5:12 AM
To: ibis-users@vhdl.org
Subject: about IO_Buffer model's ac analysis


hi, all, 

I has a problem. 
I think that ibs model was generated  by spice's dc analysis and transient
analysis, 
so ibs model don't contain frequency response information. 


now I want to realize ac analysis  to ibs model version3.2 in Star-Hspice ,
but the simulation results 
were very bad. 
perhaps ibs model should contain frequency response information which were
generated with spice's 
ac analysis. 


do you think my idea? pls help me. 


I am not a member of ibis-user, so pls email to: 
wqzhang@avanticorp.com 

-- 

Thanks

Wenqing Zhang

______________End Forwarded Message_________

o:62834978-701

 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza

 No.55, West Huaihai Road, Shanghai, 200030, P.R.China
  


------_=_NextPart_001_01C0B6DF.E20C8F10
Content-Type: text/html;
	charset="gb2312"

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


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Courier New" size=2><SPAN 
class=033500217-27032001>Chris,</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=033500217-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN class=033500217-27032001>Don't forget 
about the C_comp...</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=033500217-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=033500217-27032001>Arpad</SPAN></FONT></DIV>
<DIV><FONT face="Courier New" size=2><SPAN 
class=033500217-27032001>==================================</SPAN></FONT></DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Reid, Chris 
[mailto:chris_reid@mentorg.com]<BR><B>Sent:</B> Tuesday, March 27, 2001 8:50 
AM<BR><B>To:</B> 'wqzhang@avanticorp.com'; 
ibis-users@vhdl.org<BR><B>Subject:</B> RE: about IO_Buffer model's ac 
analysis<BR><BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001>Wenqing,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>You 
are right.&nbsp; IBIS contains only static information in the IV curves.&nbsp; 
The</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001>dynamic information is only in the VT curves, which 
should be given for</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>load 
conditions similar to the environment the part will be used in.&nbsp; 
This</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>still 
leaves IBIS with fundamentally a static model.&nbsp; For most devices 
this</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>model 
seems to be accurate enough.&nbsp; However, as you may know 
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>IBIS 
committee is in the process of defining IBIS-X, which will allow 
more</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001>general modeling for difficult 
cases.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925424516-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925424516-27032001>Chris 
Reid</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Wenqing Zhang 
  [mailto:wqzhang@avanticorp.com]<BR><B>Sent:</B> Tuesday, March 27, 2001 5:12 
  AM<BR><B>To:</B> ibis-users@vhdl.org<BR><B>Subject:</B> about IO_Buffer 
  model's ac analysis<BR><BR></DIV></FONT>hi, all, 
  <P>I has a problem. <BR>I think that ibs model was generated&nbsp; by spice's 
  dc analysis and transient analysis, <BR>so ibs model don't contain frequency 
  response information. 
  <P>now I want to realize ac analysis&nbsp; to ibs model version3.2 in 
  Star-Hspice , but the simulation results <BR>were very bad. <BR>perhaps ibs 
  model should contain frequency response information which were generated with 
  spice's <BR>ac analysis. 
  <P>do you think my idea? pls help me. 
  <P>I am not a member of ibis-user, so pls email to: <BR>wqzhang@avanticorp.com 
<PRE>--&nbsp;
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
&nbsp;Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
&nbsp;No.55, West Huaihai Road, Shanghai, 200030, P.R.China</PRE>&nbsp; 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0B6DF.E20C8F10--

 
From owner-ibis Tue Mar 27 09:17:11 2001
Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RHH8513810
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 09:17:10 -0800 (PST)
Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345)
	id 19D8CF14; Tue, 27 Mar 2001 09:14:08 -0800 (PST)
Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53])
	by zcamail03.zca.compaq.com (Postfix) with ESMTP
	id 9B4EEFBF; Tue, 27 Mar 2001 09:14:07 -0800 (PST)
Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <H40ZB2ZQ>; Tue, 27 Mar 2001 12:14:08 -0500
Message-ID: <212CC57E84B8D111AD780000F84AA0490C713DC1@mroexc2.tay.cpqcorp.net>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: "'wqzhang@avanticorp.com'" <wqzhang@avanticorp.com>
Cc: ibis-users@vhdl.org
Subject: RE: about IO_Buffer model's ac analysis
Date: Tue, 27 Mar 2001 12:14:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain

> I think that ibs model was generated  by spice's dc analysis and transient
> analysis, 
> so ibs model don't contain frequency response information. 
Frequency response information IS available in an IBIS model for its package
parasitics, and I think that's what matters here.

When I do an AC analysis, I am interested in the transfer function FROM some
point TO some other point in the circuit.

The first thing you need to think about, is where might the FROM and TO
nodes be when you have IBIS models?

It makes sense to look at transfer functions that might involve the device's
pad node, either FROM (driving out) or TO (as an input).  The IBIS model
ought to have sufficient information about the device's package parasitics
(between the pad and the pin), for the simulator to be able to do an AC
analysis, within the accuracy limits of that package representation.

For a buffer driving out, you would replace the I/V curves with your AC
source.  For a receiver, find the slopes of the I/V curves where they
intercept the DC operating point, and include that resistance, along with
c_comp, as the "load" on the end of the package.

It doesn't make sense to try to analyze THROUGH a buffer that is represented
by an IBIS model.  The IBIS model of a buffer has no input, so there is no
such thing as a transfer function that includes that of the buffer itself.



> ----------
> From: 	Wenqing Zhang[SMTP:wqzhang@avanticorp.com]
> Reply To: 	wqzhang@avanticorp.com
> Sent: 	Tue, 27 March 2001, 08:12
> To: 	ibis-users@vhdl.org
> Subject: 	about IO_Buffer model's ac analysis
> 
> hi, all, 
> 
> I has a problem. 
> I think that ibs model was generated  by spice's dc analysis and transient
> analysis, 
> so ibs model don't contain frequency response information. 
> 
> now I want to realize ac analysis  to ibs model version3.2 in Star-Hspice
> , but the simulation results 
> were very bad. 
> perhaps ibs model should contain frequency response information which were
> generated with spice's 
> ac analysis. 
> 
> do you think my idea? pls help me. 
> 
> I am not a member of ibis-user, so pls email to: 
> wqzhang@avanticorp.com 
> -- 
> Thanks
> Wenqing Zhang
> ______________End Forwarded Message_________
> o:62834978-701
>  Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
>  No.55, West Huaihai Road, Shanghai, 200030, P.R.China
>  
> 
 
From owner-ibis Tue Mar 27 09:23:09 2001
Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RHN6513854
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 09:23:08 -0800 (PST)
Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345)
	id F0D929E9; Tue, 27 Mar 2001 11:20:07 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42])
	by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id B2FFCA44
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 11:20:02 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <HM8FBHY9>; Tue, 27 Mar 2001 12:20:02 -0500
Message-ID: <212CC57E84B8D111AD780000F84AA0490C713DC2@mroexc2.tay.cpqcorp.net>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: 'wqzhang@avanticorp.com'
Cc: "'ibis-users@vhdl.org'" <ibis-users@vhdl.org>
Subject: RE: about IO_Buffer model's ac analysis
Date: Tue, 27 Mar 2001 12:19:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain

Sorry, this was sent prematurely when a keyboard key got stuck.

You wrote:

> I think that ibs model was generated  by spice's dc analysis and transient
> analysis, 
> so ibs model don't contain frequency response information. 
 
> Frequency response information IS available in an IBIS model for its
> package parasitics, and I think that's what matters here.
> 
> When I do an AC analysis, I am interested in the transfer function FROM
> some point TO some other point in the circuit.
> 
> The first thing you need to think about, is where might the FROM and TO
> nodes be when you have IBIS models?
> 
> It makes sense to look at transfer functions that might involve the
> device's pad node, either FROM (driving out), or TO (as an input).  The
> IBIS model ought to have sufficient information about the device's package
> parasitics (between the pad and the pin), for the simulator to be able to
> do an AC analysis, within the accuracy limits of that package
> representation.
> 
> For a buffer driving out, you would replace the I/V curves with your AC
> source.  For a receiver, find the slopes of the I/V curves where they
> intercept the DC operating point, and include that resistance, along with
> c_comp, as the "load" on the end of the package.
> 
> It doesn't make sense to try to analyze THROUGH a buffer that is
> represented by an IBIS model.  The IBIS model of a buffer has no input, so
> there is no such thing as a transfer function that includes that of the
> buffer itself.  (HSPICE's B-elements do have inputs, but they are just
> there to make the B-elements work.)
> 
Regards,
Andy

 
From owner-ibis Tue Mar 27 09:53:14 2001
Received: from atlexchange4.ceridian-ces.com (atlexchange4.ceridian-ces.com [170.153.64.15])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RHrA514026
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 09:53:13 -0800 (PST)
Received: by ATLEXCHANGE4 with Internet Mail Service (5.5.2650.21)
	id <HT69YLGS>; Tue, 27 Mar 2001 12:50:19 -0500
Message-ID: <03CDD2744F8DD3118EC60080D870100E0292C0AD@cp2boexch.ceridian.net>
From: "Raymond, Keith" <Keith.Raymond@Ceridian.com>
To: "'Ingraham, Andrew'" <Andrew.Ingraham@compaq.com>,
   "'wqzhang@avanticorp.com'" <wqzhang@avanticorp.com>
Cc: ibis-users@vhdl.org
Subject: RE: about IO_Buffer model's ac analysis
Date: Tue, 27 Mar 2001 12:52:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Why am I receiving this email.... what is it pertaining to?



Keith E. Raymond
Project Manager - Real Estate & Facilities Management
930 Commonwealth Avenue
Boston, MA  02215-1212
617/278-4043
617/593-6396 (Cellular)



> -----Original Message-----
> From:	Ingraham, Andrew [SMTP:Andrew.Ingraham@compaq.com]
> Sent:	Tuesday, March 27, 2001 12:14 PM
> To:	'wqzhang@avanticorp.com'
> Cc:	ibis-users@vhdl.org
> Subject:	RE: about IO_Buffer model's ac analysis
> 
> > I think that ibs model was generated  by spice's dc analysis and
> transient
> > analysis, 
> > so ibs model don't contain frequency response information. 
> Frequency response information IS available in an IBIS model for its
> package
> parasitics, and I think that's what matters here.
> 
> When I do an AC analysis, I am interested in the transfer function FROM
> some
> point TO some other point in the circuit.
> 
> The first thing you need to think about, is where might the FROM and TO
> nodes be when you have IBIS models?
> 
> It makes sense to look at transfer functions that might involve the
> device's
> pad node, either FROM (driving out) or TO (as an input).  The IBIS model
> ought to have sufficient information about the device's package parasitics
> (between the pad and the pin), for the simulator to be able to do an AC
> analysis, within the accuracy limits of that package representation.
> 
> For a buffer driving out, you would replace the I/V curves with your AC
> source.  For a receiver, find the slopes of the I/V curves where they
> intercept the DC operating point, and include that resistance, along with
> c_comp, as the "load" on the end of the package.
> 
> It doesn't make sense to try to analyze THROUGH a buffer that is
> represented
> by an IBIS model.  The IBIS model of a buffer has no input, so there is no
> such thing as a transfer function that includes that of the buffer itself.
> 
> 
> 
> > ----------
> > From: 	Wenqing Zhang[SMTP:wqzhang@avanticorp.com]
> > Reply To: 	wqzhang@avanticorp.com
> > Sent: 	Tue, 27 March 2001, 08:12
> > To: 	ibis-users@vhdl.org
> > Subject: 	about IO_Buffer model's ac analysis
> > 
> > hi, all, 
> > 
> > I has a problem. 
> > I think that ibs model was generated  by spice's dc analysis and
> transient
> > analysis, 
> > so ibs model don't contain frequency response information. 
> > 
> > now I want to realize ac analysis  to ibs model version3.2 in
> Star-Hspice
> > , but the simulation results 
> > were very bad. 
> > perhaps ibs model should contain frequency response information which
> were
> > generated with spice's 
> > ac analysis. 
> > 
> > do you think my idea? pls help me. 
> > 
> > I am not a member of ibis-user, so pls email to: 
> > wqzhang@avanticorp.com 
> > -- 
> > Thanks
> > Wenqing Zhang
> > ______________End Forwarded Message_________
> > o:62834978-701
> >  Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
> >  No.55, West Huaihai Road, Shanghai, 200030, P.R.China
> >  
> > 
 
From owner-ibis Tue Mar 27 10:36:10 2001
Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RIa6514441
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 10:36:08 -0800 (PST)
Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35])
	by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id NAA07155
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 13:33:06 -0500 (EST)
Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20])
	by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id NAA18106
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 13:33:02 -0500 (EST)
Received: from pcchrisr (pc-chrisr.camarillo.innoveda.com [139.181.194.170])
	by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id KAA06184
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 10:32:58 -0800 (PST)
From: "Chris Rokusek" <crokusek@innoveda.com>
To: <ibis-users@eda.org>
Subject: RE: about ibs model's ac analysis
Date: Tue, 27 Mar 2001 10:34:00 -0800
Message-ID: <NCBBIPNACIFLPPLOIJECOEHCCOAA.crokusek@innoveda.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0112_01C0B6A9.6FE99080"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <10C8636AE359D4119118009027AE99870515536F@FMSMSX34>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0112_01C0B6A9.6FE99080
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit

Arpad,

I am interested in your frequency domain work here...

Do the Laplace pole/zero locations vary significantly based on the DC bias
point?  If yes, then it seems you are attempting to compare a "small-signal"
equivalent with a "large-signal".

I am reading that you created an equivalent circuit that attempts takes into
account these different bias's, however I didn't think that was possible in
general.  Is there a standard procedure to synthesize a circuit given
multiple small signal equivalents?  The reason this seems difficult is
because in the time domain, the "small-singnal" model would need to be
changing between the biases in a (perhaps complex) manner.

Basically I am asking how you "morphed" the small-signal equivalent over
time to account for biases.

Chris

  -----Original Message-----
  From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
  Sent: Tuesday, March 27, 2001 8:55 AM
  To: 'wqzhang@avanticorp.com'; ibis-users@eda.org
  Subject: RE: about ibs model's ac analysis


  Wenqing,

  Your observation is true, but not totally.  It is true that the
  IV curves of IBIS models are made with .DC or .TRAN mode.  This
  can only provide a frequency independent impedance (or R) for a
  given operating point (voltage).  However, IBIS models also have
  a parameter called C_comp, which is a primitive way of introducing
  some AC characteristics.  This C_comp is typically in parallel
  with the IV curve's non linear impedance (R), so the overall effect
  is basically a parallel RC circuit.  With the new feature of C_comp
  being split into four parts the situation can get a little more
  complicated, but in an AC analysis sense this is still pretty simple.

  Now, I agree that this simple RC circuit is not very sophisticated
  for a frequency domain analysis.  However, in this initial
  implementation the emphasis should not be on the buffer's AC accuracy.
  The IBIS open forum is already working on improvements to the
  specification which will enable us to make more accurate AC models
  also (IBIS-X) in the future.

  Currently, frequency domain analysis in Signal Integrity Engineering
  of digital products (such as computer boards) is used primarily to
  detect problems with the characteristics of the interconnects.  In
  some cases it is desirable to include the driving or terminating
  impedances of the buffers and receivers in the AC analysis.  When
  we have nothing but IBIS models available, it would be useful to be
  able to this with the B-elements.  However crude it may be, it is
  still better than nothing.

  On the other hand, since I am working on this issue now, I have discovered
  that a MOSFET transistor is actually not all that complicated in terms
  of frequency domain analysis.  I can replace the transistor with a
  one-port equivalent (as if I was looking into it from the die pad)
  using a transfer function with two or three terms in the (numerator
  and) denominator or with a few poles.  (I tried this with the pole/zero,
  and the Laplace elements in HSPICE).

  I found a problem, though.  I ran a pole/zero analysis to find the
  poles (and zeroes) of such a one port of a MOSFET.  (It didn't have
  zeroes).  I ran this at multiple DC bias points to be able to include
  voltage dependencies.  Then I made an equivalent circuit using
  voltage dependent resistors and capacitors, and ran a time domain
  simulation to see whether the step or natural response of this
  equivalent circuit will give me the same result as the original
  MOSFET.  Well, it DOESN'T!  I tried to look for mistakes etc...,
  but the only conclusion I get is that the .AC and the .TRAN models
  of the MOSFET are not the same in HSPICE, and that is where the
  difference comes from.  I would like someone interested in this
  to verify it for me.

  Now, the philosophical question is this:  The above story tells us
  that the transfer function of a MOSFET is different for the AC and
  TRAN modes in HSPCIE.  Should they not be the same?  If they are
  different, my AC analysis will not give me the same picture of what
  my system does compared with a TRAN analysis.  Is that right?

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


------=_NextPart_000_0112_01C0B6A9.6FE99080
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dgb2312" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001>Arpad,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D187445817-27032001>I am=20
interested in your frequency domain work here...</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D187445817-27032001>Do the=20
Laplace pole/zero locations vary significantly based on the DC bias =
point?&nbsp;=20
If yes, then it seems you are attempting to compare a "small-signal" =
equivalent=20
with a "large-signal".</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D187445817-27032001>I am=20
reading that you created an equivalent circuit that attempts takes into =
account=20
these different bias's, however I&nbsp;didn't think that was possible in =

general.&nbsp; Is there a standard procedure to synthesize a circuit =
given=20
multiple small signal equivalents?&nbsp; The reason this seems difficult =
is=20
because in the time domain, the "small-singnal" model would need to be =
changing=20
between the biases in a (perhaps complex) manner.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001>Basically I am asking how you&nbsp;"morphed" =
the=20
small-signal equivalent over time to account for =
biases.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D187445817-27032001>Chris</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Muranyi, Arpad=20
  [mailto:arpad.muranyi@intel.com]<BR><B>Sent:</B> Tuesday, March 27, =
2001 8:55=20
  AM<BR><B>To:</B> 'wqzhang@avanticorp.com';=20
  ibis-users@eda.org<BR><B>Subject:</B> RE: about ibs model's ac=20
  analysis<BR><BR></DIV></FONT>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>Wenqing,</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>Your=20
  observation is true, but not totally.&nbsp; It is true that=20
  the</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>IV curves=20
  of IBIS models are made with .DC or .TRAN mode.&nbsp; =
This</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>can only=20
  provide a frequency independent impedance (or R) for =
a</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>given=20
  </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>operating point (voltage).&nbsp; However, =
IBIS models=20
  also have</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>a=20
  </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>parameter called C_comp, which is a =
primitive way of=20
  introducing</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>some AC=20
  characteristics.&nbsp; This C_comp is typically in=20
parallel</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>with the=20
  IV curve's non linear impedance (R), so the overall =
effect</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>is=20
  basically </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>a parallel RC circuit.&nbsp; With the new =
feature of=20
  C_comp</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>being=20
  split into four parts the situation can get a little =
more</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>complicated, but in an AC analysis sense =
this is=20
  still pretty simple.</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>Now, I=20
  agree that this simple RC circuit is not very=20
sophisticated</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>for a=20
  frequency domain analysis.&nbsp; However, in this initial =
</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>implementation the emphasis should not be=20
  </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>on the buffer's AC =
accuracy.</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>The IBIS=20
  open forum is already working on improvements to =
the</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>specification which will enable us to make =
more=20
  accurate AC models</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>also=20
  (IBIS-X) in the future.</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>Currently,=20
  frequency domain analysis in Signal Integrity =
Engineering</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>of digital=20
  products (such as computer boards) </SPAN></FONT><FONT face=3D"Courier =
New"=20
  size=3D2><SPAN class=3D223040516-27032001>is used primarily =
to</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>detect=20
  </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>problems </SPAN></FONT><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN class=3D223040516-27032001>with the characteristics of =
the=20
  interconnects.&nbsp; In</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>some cases=20
  it is desirable to include the </SPAN></FONT><FONT face=3D"Courier =
New"=20
  size=3D2><SPAN class=3D223040516-27032001>driving or=20
  terminating</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>impedances=20
  of the buffers and receivers in the AC analysis.&nbsp;=20
When</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>we have=20
  nothing but IBIS models available, it would be useful to=20
be</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>able to=20
  this with the B-elements.&nbsp; However crude it may be, it=20
  is</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>still=20
  better than nothing.</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>On the=20
  other hand, since I am working on this issue now, I have=20
  discovered</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>that a=20
  MOSFET transistor is actually not all that complicated in=20
  terms</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>of=20
  frequency domain analysis.&nbsp; I can replace the transistor with=20
  a</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>one-port=20
  equivalent (as if I was looking into it from the die =
pad)</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>using a=20
  transfer function with two or three terms in the=20
(numerator</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>and)=20
  denominator or </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN =

  class=3D223040516-27032001>with a few poles.&nbsp; (I tried this with =
the=20
  pole/zero,</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>and the=20
  Laplace elements in HSPICE).</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>I found a=20
  problem, though.&nbsp; I ran a pole/zero analysis to find=20
  the</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>poles (and=20
  zeroes) of such a one port of a MOSFET.&nbsp; (It didn't=20
  have</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>zeroes).&nbsp; I ran this at multiple DC =
bias points=20
  to be able to include</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>voltage=20
  dependencies.&nbsp; Then I made an equivalent </SPAN></FONT><FONT=20
  face=3D"Courier New" size=3D2><SPAN class=3D223040516-27032001>circuit =

  using</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>voltage=20
  dependent resistors and capacitors, and ran a time =
domain</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>simulation=20
  to see whether the step or natural response of =
this</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>equivalent=20
  circuit will give me the same result as the =
original</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>MOSFET.&nbsp; Well, it DOESN'T!&nbsp; I =
tried to look=20
  for mistakes etc...,</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>but the=20
  only conclusion I get is that the .AC and the .TRAN =
models</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>of the=20
  MOSFET are not the same in HSPICE, and that is where =
the</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>difference=20
  comes from.&nbsp; I would like someone interested in =
this</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>to verify=20
  it for me.</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>Now, the=20
  philosophical question is this:&nbsp; The above story tells=20
  us</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>that the=20
  transfer function of a MOSFET is different for the AC =
and</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>TRAN modes=20
  in HSPCIE.&nbsp; Should they not be the same?&nbsp; If they=20
  are</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>different,=20
  </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>my AC analysis will not give me the same =
picture of=20
  what</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>my system=20
  d</SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001>oes compared with a TRAN analysis.&nbsp; Is =
that=20
  right?</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  class=3D223040516-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>Arpad=20
  Muranyi</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D223040516-27032001>Intel=20
  Corporation</SPAN></FONT></DIV>
  <DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
  =
class=3D223040516-27032001>=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=3D<=
/SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0112_01C0B6A9.6FE99080--

 
From owner-ibis Tue Mar 27 11:26:54 2001
Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2RJQp514868
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 11:26:53 -0800 (PST)
Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345)
	id 94C14AF1; Tue, 27 Mar 2001 13:23:52 -0600 (CST)
Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42])
	by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 67068971
	for <ibis-users@vhdl.org>; Tue, 27 Mar 2001 13:23:52 -0600 (CST)
Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <HM8FBRT5>; Tue, 27 Mar 2001 14:23:51 -0500
Message-ID: <212CC57E84B8D111AD780000F84AA0490C713DC4@mroexc2.tay.cpqcorp.net>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: ibis-users@vhdl.org
Subject: Mail screw-up  (was RE: about IO_Buffer model's ac analysis)
Date: Tue, 27 Mar 2001 14:23:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain

Everyone,

It's worse than I thought.  When my message got inadvertently sent before I
was done writing it, it somehow got sent to another (at least one other)
maillist.  One that has nothing whatsoever to do with IBIS.

Their address was apparently added as a BCC: (blind CC:), which means they
have no idea why they got it.

So if you see replies to the list asking to be taken off the list, IT'S ALL
MY FAULT (or my computer's), and I APOLOGIZE to everyone for causing this
mess.

(Now, if I can only figure out what went wrong.  Norton is always running
and says I haven't got a virus.  I didn't know a stuck key could do quite so
much ... hopefully I'll still have a job tomorrow....)

Arrggghhh!!!

Sorry, everyone!
Andy

 
From owner-ibis Tue Mar 27 17:13:36 2001
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2S1DW516322
	for <ibis-users@eda.org>; Tue, 27 Mar 2001 17:13:33 -0800 (PST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id BAA21892
	for <ibis-users@eda.org>; Wed, 28 Mar 2001 01:10:39 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 28 Mar 2001 01:10:38 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <HYMD4VCY>; Tue, 27 Mar 2001 17:10:37 -0800
Message-ID: <10C8636AE359D4119118009027AE998705155375@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: ibis-users@eda.org
Subject: RE: about ibs model's ac analysis
Date: Tue, 27 Mar 2001 17:10:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0B723.E4912630"

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_01C0B723.E4912630
Content-Type: text/plain;
	charset="gb2312"

Chris,
 
Answers to your questions:
 
1)  Yes, the pole/zero or the transfer function does change significantly
due to the
DC bias point.  One of the most obvious change is that the term which
represents
the resistance corresponds to the slope of the IV curve.  Near the origin I
can get
a few Ohms, in the saturation region I can get hundreds of Ohms.  Reading
Fred's
response (and the manual) I agree that this is due to the difference between
small
signal vs. large signal model of the same MOSFET in (H)SPICE.
 
2)  Regarding the equivalent circuit, there are multiple ways to make a
voltage
dependent model.  This is how I did it:  First I generated the Z11 data for
a MOSFET.
at various operating points.  Then I ran an optimization routine to fit
either R and C
values or coefficients for a transfer function (using the Laplace element)
to get the
same Z11 response.  Then I curve fitted these parameters and built an RC
circuit
and a Laplace source using the tansfer function with these voltage dependent
parameters.
 (Yes the Laplace source works this way if you don't have more than three
terms in it).
Then I overlayed the original MOSFET with the RC circuit and the Laplace
source's AC
response to make sure I get the same Z11 response with respect to DC bias
changes.
So far so good.  Then I ran the same three circuits in .TRAN mode to see if
the
natural responses will be the same.  The RC and Laplace matches with each
other, but
they don't match the MOSFET.  I kind of knew that the reason is as explained
above,
I just wanted to get other's views also.  (By the way, this discrepancy onyl
exists when
the original device is a MOSFET.  If I used an RC circuit as the original
element, the
process that I just described ends up giving the same results after all this
rigamour).
 
Now, I understand that the small and large signal models of transistors are
different.
But my concern is that those who worship SPICE models may be in for a big
surprise
if they run all kinds of frequency domain simulations (using .AC) thinking
that they are
solving resonance problems and all of the sudden their fixed circuit will
not work in the
time domain!
 
Arpad
============================================================
 -----Original Message-----
From: Chris Rokusek [mailto:crokusek@innoveda.com]
Sent: Tuesday, March 27, 2001 10:34 AM
To: ibis-users@eda.org
Subject: RE: about ibs model's ac analysis



Arpad,
 
I am interested in your frequency domain work here...
 
Do the Laplace pole/zero locations vary significantly based on the DC bias
point?  If yes, then it seems you are attempting to compare a "small-signal"
equivalent with a "large-signal".
 
I am reading that you created an equivalent circuit that attempts takes into
account these different bias's, however I didn't think that was possible in
general.  Is there a standard procedure to synthesize a circuit given
multiple small signal equivalents?  The reason this seems difficult is
because in the time domain, the "small-singnal" model would need to be
changing between the biases in a (perhaps complex) manner.
 
Basically I am asking how you "morphed" the small-signal equivalent over
time to account for biases.
 
Chris
 

-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Tuesday, March 27, 2001 8:55 AM
To: 'wqzhang@avanticorp.com'; ibis-users@eda.org
Subject: RE: about ibs model's ac analysis


Wenqing,
 
Your observation is true, but not totally.  It is true that the
IV curves of IBIS models are made with .DC or .TRAN mode.  This
can only provide a frequency independent impedance (or R) for a
given operating point (voltage).  However, IBIS models also have
a parameter called C_comp, which is a primitive way of introducing
some AC characteristics.  This C_comp is typically in parallel
with the IV curve's non linear impedance (R), so the overall effect
is basically a parallel RC circuit.  With the new feature of C_comp
being split into four parts the situation can get a little more
complicated, but in an AC analysis sense this is still pretty simple.
 
Now, I agree that this simple RC circuit is not very sophisticated
for a frequency domain analysis.  However, in this initial 
implementation the emphasis should not be on the buffer's AC accuracy.
The IBIS open forum is already working on improvements to the
specification which will enable us to make more accurate AC models
also (IBIS-X) in the future.
 
Currently, frequency domain analysis in Signal Integrity Engineering
of digital products (such as computer boards) is used primarily to
detect problems with the characteristics of the interconnects.  In
some cases it is desirable to include the driving or terminating
impedances of the buffers and receivers in the AC analysis.  When
we have nothing but IBIS models available, it would be useful to be
able to this with the B-elements.  However crude it may be, it is
still better than nothing.
 
On the other hand, since I am working on this issue now, I have discovered
that a MOSFET transistor is actually not all that complicated in terms
of frequency domain analysis.  I can replace the transistor with a
one-port equivalent (as if I was looking into it from the die pad)
using a transfer function with two or three terms in the (numerator
and) denominator or with a few poles.  (I tried this with the pole/zero,
and the Laplace elements in HSPICE).
 
I found a problem, though.  I ran a pole/zero analysis to find the
poles (and zeroes) of such a one port of a MOSFET.  (It didn't have
zeroes).  I ran this at multiple DC bias points to be able to include
voltage dependencies.  Then I made an equivalent circuit using
voltage dependent resistors and capacitors, and ran a time domain
simulation to see whether the step or natural response of this
equivalent circuit will give me the same result as the original
MOSFET.  Well, it DOESN'T!  I tried to look for mistakes etc...,
but the only conclusion I get is that the .AC and the .TRAN models
of the MOSFET are not the same in HSPICE, and that is where the
difference comes from.  I would like someone interested in this
to verify it for me.
 
Now, the philosophical question is this:  The above story tells us
that the transfer function of a MOSFET is different for the AC and
TRAN modes in HSPCIE.  Should they not be the same?  If they are
different, my AC analysis will not give me the same picture of what
my system does compared with a TRAN analysis.  Is that right?
 
Arpad Muranyi
Intel Corporation
=================================================================
 


------_=_NextPart_001_01C0B723.E4912630
Content-Type: text/html;
	charset="gb2312"

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


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>Chris,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>Answers to your questions:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>1)&nbsp; Yes, the pole/zero or the transfer function 
does change significantly due to the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>DC 
bias point.&nbsp; One of the most obvious change is that the term which 
represents</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>the 
resistance corresponds to the slope of the IV curve.&nbsp; Near the origin I can 
get</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>a few 
Ohms, in the saturation region I can get hundreds of Ohms.&nbsp; Reading 
Fred's</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>response (and the manual) I agree that this is due to 
the difference between small</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>signal 
vs. large signal model </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>of the same MOSFET in (H)SPICE.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>2)&nbsp; Regarding the equivalent circuit, there are 
multiple ways to make a voltage</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>dependent </SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=046593800-28032001>model.&nbsp; This is how I did it:&nbsp; 
First I generated the Z11 data for a MOSFET.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>at 
various operating points.&nbsp; Then I&nbsp;ran an optimization routine to fit 
either R and C</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>values 
or coefficients for a transfer function (using the Laplace element) to get 
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>same 
Z11 </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>response.&nbsp; Then I </SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>curve fitted 
these parameters and built an RC circuit</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>and a 
Laplace source using </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>the tansfer </SPAN></FONT><FONT color=#0000ff 
face=Arial size=2><SPAN class=046593800-28032001>function with these 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>voltage dependent parameters.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>&nbsp;(Yes the Laplace </SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>source works this 
way if you don't have more than three terms in it).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>Then I 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>overlayed the original MOSFET with the RC circuit and 
the Laplace source's AC</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>response to make sure I get the same Z11 response with 
respect to DC bias changes.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>So far 
so good.&nbsp; Then I ran the same three circuits in .TRAN mode to see if 
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>natural responses will be the same.&nbsp; The RC and 
Laplace matches with each other, but</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>they 
don't match the MOSFET.&nbsp; I kind of knew that the reason is as explained 
above,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>I just 
wanted to get other's views also.&nbsp; (By the way, this discrepancy onyl 
exists when</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>the 
original device is a MOSFET.&nbsp; If I used an RC circuit as the original 
element, the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>process that I just described ends up giving the same 
results after all this rigamour).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>Now, I 
understand that the small and large signal models of transistors are 
different.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>But my 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>concern is that those who worship SPICE models may be 
in for a big surprise</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>if 
they </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>run all kinds of frequency domain simulations (using 
.AC) thinking that they are</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>solving </SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=046593800-28032001>resonance problems </SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>and all of the 
sudden their fixed circuit will not work in the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=046593800-28032001>time 
domain!</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>Arpad</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=046593800-28032001>============================================================</SPAN></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=046593800-28032001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Chris Rokusek [mailto:crokusek@innoveda.com]<BR><B>Sent:</B> Tuesday, March 27, 
2001 10:34 AM<BR><B>To:</B> ibis-users@eda.org<BR><B>Subject:</B> RE: about ibs 
model's ac analysis<BR><BR></DIV></FONT>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001>Arpad,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=187445817-27032001>I am 
  interested in your frequency domain work here...</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=187445817-27032001>Do 
  the Laplace pole/zero locations vary significantly based on the DC bias 
  point?&nbsp; If yes, then it seems you are attempting to compare a 
  "small-signal" equivalent with a "large-signal".</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=187445817-27032001>I am 
  reading that you created an equivalent circuit that attempts takes into 
  account these different bias's, however I&nbsp;didn't think that was possible 
  in general.&nbsp; Is there a standard procedure to synthesize a circuit given 
  multiple small signal equivalents?&nbsp; The reason this seems difficult is 
  because in the time domain, the "small-singnal" model would need to be 
  changing between the biases in a (perhaps complex) manner.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001>Basically I am asking how you&nbsp;"morphed" the 
  small-signal equivalent over time to account for biases.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=187445817-27032001>Chris</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Muranyi, Arpad 
    [mailto:arpad.muranyi@intel.com]<BR><B>Sent:</B> Tuesday, March 27, 2001 
    8:55 AM<BR><B>To:</B> 'wqzhang@avanticorp.com'; 
    ibis-users@eda.org<BR><B>Subject:</B> RE: about ibs model's ac 
    analysis<BR><BR></DIV></FONT>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>Wenqing,</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Your 
    observation is true, but not totally.&nbsp; It is true that 
    the</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>IV 
    curves of IBIS models are made with .DC or .TRAN mode.&nbsp; 
    This</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>can only 
    provide a frequency independent impedance (or R) for a</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>given 
    </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>operating point (voltage).&nbsp; However, IBIS 
    models also have</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>a 
    </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>parameter called C_comp, which is a primitive way 
    of introducing</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>some AC 
    characteristics.&nbsp; This C_comp is typically in 
    parallel</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>with the 
    IV curve's non linear impedance (R), so the overall 
    effect</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>is 
    basically </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>a parallel RC circuit.&nbsp; With the new feature 
    of C_comp</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>being 
    split into four parts the situation can get a little 
more</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>complicated, but in an AC analysis sense this is 
    still pretty simple.</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Now, I 
    agree that this simple RC circuit is not very 
    sophisticated</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>for a 
    frequency domain analysis.&nbsp; However, in this initial 
    </SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>implementation the emphasis should not be 
    </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>on the buffer's AC accuracy.</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>The IBIS 
    open forum is already working on improvements to the</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>specification which will enable us to make more 
    accurate AC models</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>also 
    (IBIS-X) in the future.</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>Currently, frequency domain analysis in Signal 
    Integrity Engineering</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>of 
    digital products (such as computer boards) </SPAN></FONT><FONT 
    face="Courier New" size=2><SPAN class=223040516-27032001>is used primarily 
    to</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>detect 
    </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>problems </SPAN></FONT><FONT face="Courier New" 
    size=2><SPAN class=223040516-27032001>with the characteristics of the 
    interconnects.&nbsp; In</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>some 
    cases it is desirable to include the </SPAN></FONT><FONT face="Courier New" 
    size=2><SPAN class=223040516-27032001>driving or 
    terminating</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>impedances of the buffers and receivers in the AC 
    analysis.&nbsp; When</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>we have 
    nothing but IBIS models available, it would be useful to 
    be</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>able to 
    this with the B-elements.&nbsp; However crude it may be, it 
    is</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>still 
    better than nothing.</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>On the 
    other hand, since I am working on this issue now, I have 
    discovered</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>that a 
    MOSFET transistor is actually not all that complicated in 
    terms</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>of 
    frequency domain analysis.&nbsp; I can replace the transistor with 
    a</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>one-port 
    equivalent (as if I was looking into it from the die 
pad)</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>using a 
    transfer function with two or three terms in the 
    (numerator</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>and) 
    denominator or </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>with a few poles.&nbsp; (I tried this with the 
    pole/zero,</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>and the 
    Laplace elements in HSPICE).</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>I found 
    a problem, though.&nbsp; I ran a pole/zero analysis to find 
    the</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>poles 
    (and zeroes) of such a one port of a MOSFET.&nbsp; (It didn't 
    have</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>zeroes).&nbsp; I ran this at multiple DC bias 
    points to be able to include</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>voltage 
    dependencies.&nbsp; Then I made an equivalent </SPAN></FONT><FONT 
    face="Courier New" size=2><SPAN class=223040516-27032001>circuit 
    using</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>voltage 
    dependent resistors and capacitors, and ran a time 
domain</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>simulation to see whether the step or natural 
    response of this</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>equivalent circuit will give me the same result as 
    the original</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>MOSFET.&nbsp; Well, it DOESN'T!&nbsp; I tried to 
    look for mistakes etc...,</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>but the 
    only conclusion I get is that the .AC and the .TRAN 
    models</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>of the 
    MOSFET are not the same in HSPICE, and that is where the</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>difference comes from.&nbsp; I would like someone 
    interested in this</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>to 
    verify it for me.</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Now, the 
    philosophical question is this:&nbsp; The above story tells 
    us</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>that the 
    transfer function of a MOSFET is different for the AC 
and</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>TRAN 
    modes in HSPCIE.&nbsp; Should they not be the same?&nbsp; If they 
    are</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>different, </SPAN></FONT><FONT face="Courier New" 
    size=2><SPAN class=223040516-27032001>my AC analysis will not give me the 
    same picture of what</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>my 
    system d</SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>oes compared with a TRAN analysis.&nbsp; Is that 
    right?</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Arpad 
    Muranyi</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN class=223040516-27032001>Intel 
    Corporation</SPAN></FONT></DIV>
    <DIV><FONT face="Courier New" size=2><SPAN 
    class=223040516-27032001>=================================================================</SPAN></FONT></DIV>
    <DIV>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0B723.E4912630--

 
From owner-ibis Wed Mar 28 10:20:12 2001
Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75])
	by server.eda.org (8.11.0/8.11.0) with SMTP id f2SIK7521251
	for <ibis-users@eda.org>; Wed, 28 Mar 2001 10:20:09 -0800 (PST)
Received: (qmail 26559 invoked from network); 28 Mar 2001 18:15:31 -0000
Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76)
  by ns02.newbridge.com with SMTP; 28 Mar 2001 18:15:31 -0000
Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ibis-users@eda.org; Wed, 28 Mar 2001 13:16:49 -0500
Received: from cid.alcatel.com ([138.120.63.177])
          by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6)
           with ESMTP id AAA494 for <ibis-users@eda.org>;
          Wed, 28 Mar 2001 13:16:48 -0500
Sender: "Jason Leung" <jleung@cid.alcatel.com>
Message-Id: <3AC22A69.5B9EC26F@cid.alcatel.com>
Date: Wed, 28 Mar 2001 13:16:09 -0500
From: Jason Leung <jleung@cid.alcatel.com>
Organization: Alcatel
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "ibis-users@eda.org" <ibis-users@eda.org>
Subject: try to verify a ibis model for a series_switch
Content-Type: multipart/mixed;
 boundary="------------E7C68910D42FA72552750CA1"

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

Hi Folks:
 I am trying to verfify a ibis model consists of a series MOSFET and the
type of that model is Series_switch.
Can anyone tell me how I can start to verify this model?
I am also using Scratchpad to create the schematics , do you know how
can I do that?

Thanks Very Much
Best regards
Jason Leung (Alcatel)


--------------E7C68910D42FA72552750CA1
Content-Type: text/x-vcard; charset=us-ascii;
 name="jleung.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jason Leung
Content-Disposition: attachment;
 filename="jleung.vcf"

begin:vcard 
n:Leung;Jason
tel;fax:613-5993642
tel;work:613-7844425
x-mozilla-html:FALSE
org:Alcatel CID;EMC ENGINEERING
adr:;;600 March Road;Kanata;Ontario;K2K 2E6;CANADA
version:2.1
email;internet:jleung@cid.alcatel.com
title:SI/EMC ENGINEER
x-mozilla-cpt:;168
fn:Jason Leung
end:vcard

--------------E7C68910D42FA72552750CA1--

 
From owner-ibis Wed Mar 28 18:47:29 2001
Received: from mailhost.avanticorp.com (mailhost.avanticorp.com [63.167.1.13])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2T2lR522903
	for <ibis-users@vhdl.org>; Wed, 28 Mar 2001 18:47:28 -0800 (PST)
Received: from mailhost.avanticorp.com (localhost [127.0.0.1])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2T2iSG12183
	for <ibis-users@vhdl.org>; Wed, 28 Mar 2001 18:44:28 -0800 (PST)
Received: from ally.china.avanticorp.com (nat-68.avanticorp.com.cn [202.96.225.68])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2T2iPu12179
	for <ibis-users@vhdl.org>; Wed, 28 Mar 2001 18:44:26 -0800 (PST)
Received: from avanticorp.com (scottie.china.avanticorp.com [172.21.18.23])
	by ally.china.avanticorp.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA04661
	for <ibis-users@vhdl.org>; Thu, 29 Mar 2001 10:42:04 +0800 (CST)
Sender: wqzhang@avanticorp.com
Message-ID: <3AC2A016.3737BA86@avanticorp.com>
Date: Thu, 29 Mar 2001 10:38:14 +0800
From: Wenqing Zhang <wqzhang@avanticorp.com>
Reply-To: wqzhang@avanticorp.com
Organization: Avant!
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@vhdl.org
Subject: ac analysi to ibs model
Content-Type: multipart/alternative;
 boundary="------------8646A6718E4B8E371F7E05BB"


--------------8646A6718E4B8E371F7E05BB
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

hi, all,

firstly, thanks for your reply and help to my yesterday's question.
now my question is the following:

I ran a AC analysis to  a "output" buffer with Star-Hspice, but
simulation results of the ouput termination of that out buffer were
zero.
I think the reasons are the following:

     AC source is in the input terminal of that output buffer, but the
     input part has no electrical relation with   pullup circuit,
pulldown circuit,
     power clamp circuit, ground clamp circuit in frequency domain.
     this will lead to that PU, PD, PC, GC circuit have no AC source, so

     the output of that out buffer  is zero in AC frequency analysis.

in fact We did a AC analysis to a "input"    buffer with Star-Hspice,
simulation results also were zero.

I think we can't do ac analysis to ibs model version3.2.
Perhaps AC source should not be placed in the input terminal of buffer.
where should  we place ac source?

perhaps we should increase four frequency response curve in ibs model.
that is corresponding to PU, PD, PC, GC circuit.

How do you think about it?

thanks for your help.

I am not a member of ibis-user, so pls email to:
wqzhang@avanticorp.com

how can I become a member of this group? who teach me?

best regards,
wenqing




--
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
 No.55, West Huaihai Road, Shanghai, 200030, P.R.China



--------------8646A6718E4B8E371F7E05BB
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi, all,
<p>firstly, thanks for your reply and help to my yesterday's question.
<br>now my question is the following:
<p>I ran a AC analysis to&nbsp; a "output" buffer with Star-Hspice, but
<br>simulation results of the ouput termination of that out buffer were
zero.
<br>I think the reasons are the following:
<p>&nbsp;&nbsp;&nbsp;&nbsp; AC source is in the input terminal of that
output buffer, but the
<br>&nbsp;&nbsp;&nbsp;&nbsp; input part has no electrical relation with&nbsp;&nbsp;
pullup circuit, pulldown circuit,
<br>&nbsp;&nbsp;&nbsp;&nbsp; power clamp circuit, ground clamp circuit
in frequency domain.
<br>&nbsp;&nbsp;&nbsp;&nbsp; this will lead to that PU, PD, PC, GC circuit
have no AC source, so
<br>&nbsp;&nbsp;&nbsp;&nbsp; the output of that out buffer&nbsp; is zero
in AC frequency analysis.
<p>in fact We did a AC analysis to a "input"&nbsp;&nbsp;&nbsp; buffer with
Star-Hspice,
<br>simulation results also were zero.
<p>I think we can't do ac analysis to ibs model version3.2.
<br>Perhaps AC source should not be placed in the input terminal of buffer.
<br>where should&nbsp; we place ac source?
<p>perhaps we should increase four frequency response curve in ibs model.
<br>that is corresponding to PU, PD, PC, GC circuit.
<p>How do you think about it?
<p>thanks for your help.
<p>I am not a member of ibis-user, so pls email to:
<br>wqzhang@avanticorp.com
<p>how can I become a member of this group? who teach me?
<p>best regards,
<br>wenqing
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<pre>--&nbsp;
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
&nbsp;Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
&nbsp;No.55, West Huaihai Road, Shanghai, 200030, P.R.China</pre>
&nbsp;</html>

--------------8646A6718E4B8E371F7E05BB--

 
From owner-ibis Wed Mar 28 18:48:48 2001
Received: from mailhost.avanticorp.com (mailhost.avanticorp.com [63.167.1.13])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2T2me522912
	for <ibis-users@eda.org>; Wed, 28 Mar 2001 18:48:42 -0800 (PST)
Received: from mailhost.avanticorp.com (localhost [127.0.0.1])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2T2jfB12445
	for <ibis-users@eda.org>; Wed, 28 Mar 2001 18:45:41 -0800 (PST)
Received: from ally.china.avanticorp.com (nat-68.avanticorp.com.cn [202.96.225.68])
	by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f2T2jcu12432
	for <ibis-users@eda.org>; Wed, 28 Mar 2001 18:45:39 -0800 (PST)
Received: from avanticorp.com (scottie.china.avanticorp.com [172.21.18.23])
	by ally.china.avanticorp.com (8.9.1b+Sun/8.9.3) with ESMTP id KAA04886
	for <ibis-users@eda.org>; Thu, 29 Mar 2001 10:43:17 +0800 (CST)
Sender: wqzhang@avanticorp.com
Message-ID: <3AC2A05F.CE960705@avanticorp.com>
Date: Thu, 29 Mar 2001 10:39:27 +0800
From: Wenqing Zhang <wqzhang@avanticorp.com>
Reply-To: wqzhang@avanticorp.com
Organization: Avant!
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@eda.org
Subject: ac analysis to ibs model
Content-Type: multipart/alternative;
 boundary="------------BB6FEDDC9EDB54C080F6EFAD"


--------------BB6FEDDC9EDB54C080F6EFAD
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

hi, all,

firstly, thanks for your reply and help to my yesterday's question.
now my question is the following:

I ran a AC analysis to  a "output" buffer with Star-Hspice, but
simulation results of the ouput termination of that out buffer were
zero.
I think the reasons are the following:

     AC source is in the input terminal of that output buffer, but the
     input part has no electrical relation with   pullup circuit,
pulldown circuit,
     power clamp circuit, ground clamp circuit in frequency domain.
     this will lead to that PU, PD, PC, GC circuit have no AC source, so

     the output of that out buffer  is zero in AC frequency analysis.

in fact We did a AC analysis to a "input"    buffer with Star-Hspice,
simulation results also were zero.

I think we can't do ac analysis to ibs model version3.2.
Perhaps AC source should not be placed in the input terminal of buffer.
where should  we place ac source?

perhaps we should increase four frequency response curve in ibs model.
that is corresponding to PU, PD, PC, GC circuit.

How do you think about it?

thanks for your help.

I am not a member of ibis-user, so pls email to:
wqzhang@avanticorp.com

how can I become a member of this group? who teach me?

best regards,
wenqing



--
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
 No.55, West Huaihai Road, Shanghai, 200030, P.R.China



--------------BB6FEDDC9EDB54C080F6EFAD
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi, all,
<p>firstly, thanks for your reply and help to my yesterday's question.
<br>now my question is the following:
<p>I ran a AC analysis to&nbsp; a "output" buffer with Star-Hspice, but
<br>simulation results of the ouput termination of that out buffer were
zero.
<br>I think the reasons are the following:
<p>&nbsp;&nbsp;&nbsp;&nbsp; AC source is in the input terminal of that
output buffer, but the
<br>&nbsp;&nbsp;&nbsp;&nbsp; input part has no electrical relation with&nbsp;&nbsp;
pullup circuit, pulldown circuit,
<br>&nbsp;&nbsp;&nbsp;&nbsp; power clamp circuit, ground clamp circuit
in frequency domain.
<br>&nbsp;&nbsp;&nbsp;&nbsp; this will lead to that PU, PD, PC, GC circuit
have no AC source, so
<br>&nbsp;&nbsp;&nbsp;&nbsp; the output of that out buffer&nbsp; is zero
in AC frequency analysis.
<p>in fact We did a AC analysis to a "input"&nbsp;&nbsp;&nbsp; buffer with
Star-Hspice,
<br>simulation results also were zero.
<p>I think we can't do ac analysis to ibs model version3.2.
<br>Perhaps AC source should not be placed in the input terminal of buffer.
<br>where should&nbsp; we place ac source?
<p>perhaps we should increase four frequency response curve in ibs model.
<br>that is corresponding to PU, PD, PC, GC circuit.
<p>How do you think about it?
<p>thanks for your help.
<p>I am not a member of ibis-user, so pls email to:
<br>wqzhang@avanticorp.com
<p>how can I become a member of this group? who teach me?
<p>best regards,
<br>wenqing
<br>&nbsp;
<br>&nbsp;
<pre>--&nbsp;
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
&nbsp;Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
&nbsp;No.55, West Huaihai Road, Shanghai, 200030, P.R.China</pre>
&nbsp;</html>

--------------BB6FEDDC9EDB54C080F6EFAD--

 
From owner-ibis Thu Mar 29 07:34:25 2001
Received: from pollux.asml.nl (ns.asml.nl [195.109.200.66])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2TFYL526486
	for <ibis-users@eda.org>; Thu, 29 Mar 2001 07:34:24 -0800 (PST)
Received: from titan.asml.nl (titan [146.106.1.9])
	by pollux.asml.nl (8.8.8+Sun/8.8.8) with ESMTP id RAA12841
	for <ibis-users@eda.org>; Thu, 29 Mar 2001 17:31:26 +0200 (MET DST)
Received: from selar.asml.nl (selar-ent1.asml.nl [146.106.15.250])
	by titan.asml.nl (8.9.3+Sun/8.9.3) with ESMTP id RAA08126
	for <ibis-users@eda.org>; Thu, 29 Mar 2001 17:31:25 +0200 (MET DST)
Received: from wselc191.asml.nl (wselc191 [146.106.3.36])
	by selar.asml.nl (8.8.8+Sun/8.8.8) with ESMTP id RAA24192;
	Thu, 29 Mar 2001 17:31:25 +0200 (MET DST)
Received: from wselc191 (wselc191 [146.106.3.36])
	by wselc191.asml.nl (8.8.8+Sun/8.8.8) with SMTP id RAA25388;
	Thu, 29 Mar 2001 17:31:23 +0200 (MET DST)
Message-Id: <200103291531.RAA25388@wselc191.asml.nl>
Date: Thu, 29 Mar 2001 17:31:23 +0200 (MET DST)
From: Alex Hilbers <Alex.Hilbers@asml.nl>
Reply-To: Alex Hilbers <Alex.Hilbers@asml.nl>
Subject: ABTE model verification
To: ibis-users@eda.org
Cc: pdinther@wselc191.asml.nl, emil.peters@wselc191.asml.nl
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: eL4ig4wVbs1876Ads2VFRQ==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 


Dear Ibis-Users,

I have done verification of measurements and simulation of an ABT and ABTE IBIS 
model.

When using the IBIS model of the ABT16245 the simulated and measured waveforms 
are comparable.

When using the IBIS model of the ABTE16245 the results are far from comparable.
Due to less capacitive loading of the ABTE device the simulations look better, 
nevertheless the measurements are a lot worse than the ABT case. 

Does anybody have the same experience with ABTE IBIS models?

Regards,

Alex

------------------------------------------------------
Alex Hilbers          Email:      alex.hilbers@asml.nl
ASML                  Tel:        +31(0)402685587
P.O. Box 324          Fax:        +31(0)402685530
5500 AH  Veldhoven    Building    7K-1005
The Netherlands       Department: EDEV
to glow or not to, that is the e = mission  
------------------------------------------------------



------------- End Forwarded Message -------------


------------------------------------------------------
Alex Hilbers          Email:      alex.hilbers@asml.nl
ASML                  Tel:        +31(0)402685587
P.O. Box 324          Fax:        +31(0)402685530
5500 AH  Veldhoven    Building    7K-1005
The Netherlands       Department: EDEV
to glow or not to, that is the e = mission  
------------------------------------------------------


 
From owner-ibis Thu Mar 29 10:08:56 2001
Received: from smitty.utmc.com (smitty.utmc.com [12.10.147.52])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2TI8r527065
	for <ibis-users@eda.org>; Thu, 29 Mar 2001 10:08:56 -0800 (PST)
Received: from pony.utmc.utc.com ([10.1.1.1]) by smitty.utmc.com  with Microsoft SMTPSVC(5.5.1877.197.19);
	 Thu, 29 Mar 2001 11:04:23 -0700
Received: from utmc.aeroflex.com (neon.utmc.utc.com [172.24.106.12]) by pony.utmc.utc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id HPBB1R9W; Thu, 29 Mar 2001 11:06:05 -0700
Sender: haynes
Message-ID: <3AC3798A.E11DD31E@utmc.aeroflex.com>
Date: Thu, 29 Mar 2001 11:06:02 -0700
From: Greg Haynes <haynes@utmc.aeroflex.com>
Reply-To: Greg.Haynes@utmc.aeroflex.com
Organization: UTMC Microelectronic Systems
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "ibis-users@eda.org" <ibis-users@eda.org>
Subject: LVDS model question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I'm using s2ibis2 to create an IBIS model for
an LVDS driver.  Is there documentation somewhere
that discusses how to do this?

I presume the SPICE netlist should contain the
100 ohm terminating resistor between the outputs.
Then the current at one output is dependent on the
voltage at both outputs.  What should the SPICE
setup be?

(We are the manufacturer of the part)

-Greg Haynes
UTMC Microelectronic Systems
 
From owner-ibis Thu Mar 29 10:19:02 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2TIIp527108
	for <ibis-users@eda.org>; Thu, 29 Mar 2001 10:19:01 -0800 (PST)
Received: from svr-orw-exc-01.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id KAA19421; Thu, 29 Mar 2001 10:15:51 -0800 (PST)
Received: by svr-orw-exc-01.wv.mentorg.com with Internet Mail Service (5.5.2653.19)
	id <H6M76MFP>; Thu, 29 Mar 2001 10:15:51 -0800
Message-ID: <0B30C465AF9FD311BB6B00508B449DEE069952AD@svr-orw-exc-01.wv.mentorg.com>
From: "Beal, Weston" <weston_beal@mentorg.com>
To: ibis-users@eda.org
Subject: RE: LVDS model question
Date: Thu, 29 Mar 2001 10:15:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain


Greg,

The modeling group from Mentor Graphics presented a good technique at
DesignCon IBIS summit about creating good IBIS models of LVDS drivers.  The
presentation should be available for download on the IBIS web site.
http://www.eda.org/pub/ibis/summits/mar01/hegazy.pdf

Regards,
Weston

-----Original Message-----
From: Greg Haynes [mailto:haynes@utmc.aeroflex.com]
Sent: Thursday, March 29, 2001 10:06 AM
To: ibis-users@eda.org
Subject: LVDS model question


Hi,

I'm using s2ibis2 to create an IBIS model for
an LVDS driver.  Is there documentation somewhere
that discusses how to do this?

I presume the SPICE netlist should contain the
100 ohm terminating resistor between the outputs.
Then the current at one output is dependent on the
voltage at both outputs.  What should the SPICE
setup be?

(We are the manufacturer of the part)

-Greg Haynes
UTMC Microelectronic Systems
 
From owner-ibis Fri Mar 30 09:26:24 2001
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2UHQF502459
	for <ibis-users@vhdl.org>; Fri, 30 Mar 2001 09:26:23 -0800 (PST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id RAA19621
	for <ibis-users@vhdl.org>; Fri, 30 Mar 2001 17:25:34 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 30 Mar 2001 17:25:34 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <H9J7M180>; Fri, 30 Mar 2001 09:25:33 -0800
Message-ID: <10C8636AE359D4119118009027AE99870515537C@FMSMSX34>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: ibis-users@vhdl.org
Subject: RE: ac analysis to ibs model
Date: Fri, 30 Mar 2001 09:25:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="gb2312"

Wenqing,

The input and enable nodes of the B-element is purely for control,
and these are digital, i.e. an analog signal applied to them will
result only in a logic "1" or "0" on the output.  You should not
view the B-element as if it was an op-amp.  You cannot do an AC
analysis stimulating the input and look at the response at the
output. This simply does not make sense with the B-element (or
for any digital buffer for that matter).

You can only look at the B-element as a one-port (I/O node to GND,
or I/O node to power) and look into it at its analog side, the
I/O node.  If you did that, you should see the complex impedance
that is composed from the IV curve and C_comp values.

Arpad
==========================================================
-----Original Message-----
From: Wenqing Zhang [mailto:wqzhang@avanticorp.com]
Sent: Wednesday, March 28, 2001 6:38 PM
To: ibis-users@vhdl.org
Subject: ac analysi to ibs model


hi, all, 
firstly, thanks for your reply and help to my yesterday's question. 
now my question is the following: 
I ran a AC analysis to  a "output" buffer with Star-Hspice, but 
simulation results of the ouput termination of that out buffer were zero. 
I think the reasons are the following: 
     AC source is in the input terminal of that output buffer, but the 
     input part has no electrical relation with   pullup circuit, pulldown
circuit, 
     power clamp circuit, ground clamp circuit in frequency domain. 
     this will lead to that PU, PD, PC, GC circuit have no AC source, so 
     the output of that out buffer  is zero in AC frequency analysis. 
in fact We did a AC analysis to a "input"    buffer with Star-Hspice, 
simulation results also were zero. 
I think we can't do ac analysis to ibs model version3.2. 
Perhaps AC source should not be placed in the input terminal of buffer. 
where should  we place ac source? 
perhaps we should increase four frequency response curve in ibs model. 
that is corresponding to PU, PD, PC, GC circuit. 
How do you think about it? 
thanks for your help. 
I am not a member of ibis-user, so pls email to: 
wqzhang@avanticorp.com 
how can I become a member of this group? who teach me? 
best regards, 
wenqing 
  
  
  
-- 
Thanks
Wenqing Zhang
______________End Forwarded Message_________
o:62834978-701
 Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
 No.55, West Huaihai Road, Shanghai, 200030, P.R.China
  

 
From owner-ibis Fri Mar 30 14:34:02 2001
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42])
	by server.eda.org (8.11.0/8.11.0) with ESMTP id f2UMXx503775;
	Fri, 30 Mar 2001 14:34:01 -0800 (PST)
Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id OAA04887; Fri, 30 Mar 2001 14:33:31 -0800 (PST)
Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id H6NA0XZX; Fri, 30 Mar 2001 14:33:30 -0800
Sender: bobr@relay1.mentorg.com
Message-ID: <3AC509B8.B7F4A864@mentor.com>
Date: Fri, 30 Mar 2001 14:33:28 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org, ibis-users@eda.org
Subject: New ibischk3 Version 3.2.7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

New ibischk3 Version 3.2.7 executables have been
uploaded under

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

The older executables are archived under the same
directory.  The new executables correct a defect
where Warning messages are issued for correct
*Open_drain and *Open_sink or *Open_source
models.

Thanks to Matthew Flora for making the correction
and producing the Windows executable and thanks to
Guy de Burgh for producing the new Unix executables.

A Linux executable still needs to be created and
uploaded.

The new Source code has been distributed to the
companies holding the source code licence.

Bob Ross
Mentor Graphics