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

ibis-users          Friday, October 19 2001          Volume 01 : Number 001

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

Date: Thu, 06 Sep 2001 18:13:40 +0300
From: yoked erlich <[email-masked]>
Subject: Ibis_model

This is a multi-part message in MIME format.
- --------------EF07218DFAB6BDC3FDA80A4C
Content-Type: multipart/alternative;
 boundary="------------CD917FB6AF485967046CAD24"

- --------------CD917FB6AF485967046CAD24
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi ,

I've got the next warning about [falling Waveform] simulation,

WARNING - Model ipad6wd: The [Falling Waveform]
      with [R_fixture]=50 Ohms and [V_fixture_min]=3V
      has MIN column DC endpoints of  1.29V and  3.00v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.27V and  2.94V),
      a difference of  1.64% and  2.18%, respectively.

I understood the first part of the warning , but I can't figure out how
does the checker find the second voltage range
(as it appear in the warning the range is yields from the I/V tables and
I couldn't find any sign to this voltage in I/V tables)

- --

With regards,

Yoked.

_____________________________________
E-mail:           [email-masked]
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP
MOTOROLA     SEMICONDUCTOR     ISRAEL

- --------------CD917FB6AF485967046CAD24
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<font color="#330000">Hi ,</font><font color="#330000"></font>
<p><font color="#330000">I've got the next warning about [falling Waveform]
simulation,</font><font color="#3333FF"></font>
<p><font color="#3333FF">WARNING - Model ipad6wd: The [Falling Waveform]</font>
<br><font color="#3333FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with [R_fixture]=50
Ohms and [V_fixture_min]=3V</font>
<br><font color="#3333FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; has MIN column
DC endpoints of&nbsp; 1.29V and&nbsp; 3.00v, but</font>
<br><font color="#3333FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an equivalent
load applied to the model's I-V tables yields</font>
<br><font color="#3333FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different voltages
( 1.27V and&nbsp; 2.94V),</font>
<br><font color="#3333FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a difference of&nbsp;
1.64% and&nbsp; 2.18%, respectively.</font><font color="#3333FF"></font>
<p><font color="#333300">I&nbsp;understood the first part of the warning
, but I can't figure out how does the checker find the second voltage range</font>
<br><font color="#333300">(as it appear in the warning the range is yields
from the I/V tables and I couldn't find any sign to this voltage in I/V
tables)</font>
<pre>--&nbsp;

With regards,

Yoked.

_____________________________________
E-mail:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS&nbsp;&nbsp;&nbsp;&nbsp; CIRCUIT&nbsp; - IO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GROUP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MOTOROLA&nbsp;&nbsp;&nbsp;&nbsp; SEMICONDUCTOR&nbsp;&nbsp;&nbsp;&nbsp; ISRAEL</pre>
&nbsp;</html>

- --------------CD917FB6AF485967046CAD24--

- --------------EF07218DFAB6BDC3FDA80A4C
Content-Type: text/x-vcard; charset=us-ascii;
 name="yokede.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for yoked erlich
Content-Disposition: attachment;
 filename="yokede.vcf"

begin:vcard 
n:Erlich;Yoked
tel;cell:051-957314
tel;fax:09-9522888
tel;home:09-8985166
tel;work:09-9522482
x-mozilla-html:FALSE
org:Motorola Semiconductor L.T.D;IO - WIRELESS
adr:;;Hadolev 20a;Zuran;;;ISRAEL
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;-32248
fn:Yoked Erlich
end:vcard

- --------------EF07218DFAB6BDC3FDA80A4C--

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

Date: Thu, 06 Sep 2001 12:17:05 -0400
From: Steve Grout <[email-masked]>
Subject: test - please ignore

This is a test of [email-masked] list - please ignore

- [email-masked]

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

Date: Thu, 6 Sep 2001 13:47:13 -0400 
From: "Ross, Bob" <[email-masked]>
Subject: IBIS SUMMIT MEETING AGENDA 9/13/01

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_01C136FC.49BF0B00
Content-Type: text/plain

To IBIS Participants:

Here is the Agenda for the IBIS Summit Meeting.  We do expect
interactive discussions and some possible Ad Hoc presentations
to fill out the day.

If you plan to come, but have not notified anyone, please let
Kathy Breda know to help us plan the refreshment and free lunch
participation.  E-mail is [email-masked].

We am looking forward to seeing you in Worcester and having a
productive meeting.

Bob Ross
Mentor Graphics

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

I B I S   S U M M I T   M E E T I N G   A G E N D A

Time/Date:      8:30 AM - 5:00 PM, Thursday, September 13, 2001

Location:       The Crowne Plaza Hotel
                10 Lincoln Square
                Worcester, Massachusetts
                Tel:  (508) 791-1600
                Fax:  (508) 791-1796

Content:        IBIS Presentations and Discussions

Purpose:        Solicit and Exchange IBIS Model Related Information and
                Ideas.

Sponsors:       Mentor Graphics
                North East Systems Associates, Inc.
                IBIS Open Forum
                IBIS Users Group

PCB Conference: September 10-14, 2001
East            Worcester's Centrum Centre
                Worcester, Massachusetts
                See http://www.pcbeast.com/ for more information.

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

IBIS SUMMIT AGENDA

8:30 AM   MORNING REFRESHMENTS

9:00 AM   Introductions and Business
          Stephen Peters, Intel

9:15 AM   Keynote Remarks
          Ed Sayre, North East Systems Associates (NESA)

9:30 AM   From Model Creator to Model User
          Bob Haller, Cereva Networks

10:00 AM  A Proposal for s2ibis3
          Paul Franzon, North Carolina State University 

10:30 AM  BREAK AND REFRESHMENTS

10:45 AM  Modeling the Radiated Emission of Micro-controllers
          Etienne Sicard, National Institute of Applied Science (INSA)

11:30 AM  Power/Ground Simulation with IBIS Models and Pin Mapping
          Issues
          Raj Raghuram, Sigrity, Inc.  

12:00 PM  LUNCH (Free to Attendees)

1:00 PM   Progress and Update in the Connector Specification
          Stephen Peters, Intel Corporation

1:30 PM   Progress and Issues in IBIS-X
          Stephen Peters, Intel Corporation

2:00 PM   IBIS-X Primitives and Example
          Lynne Green, Cadence Design Systems

2:30 PM   BREAK AND REFRESHMENTS

2:45 PM   Unscheduled Ad Hoc Topics

3:15 PM   Roundtable - Other Topics
          Stephen Peters, Intel, Ed Sayre, NESA

5:00 PM   FINAL BUSINESS AND ADJOURN

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

- ------_=_NextPart_001_01C136FC.49BF0B00
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>IBIS SUMMIT MEETING AGENDA 9/13/01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>To IBIS Participants:</FONT>
</P>

<P><FONT SIZE=3D2>Here is the Agenda for the IBIS Summit Meeting.&nbsp; =
We do expect</FONT>
<BR><FONT SIZE=3D2>interactive discussions and some possible Ad Hoc =
presentations</FONT>
<BR><FONT SIZE=3D2>to fill out the day.</FONT>
</P>

<P><FONT SIZE=3D2>If you plan to come, but have not notified anyone, =
please let</FONT>
<BR><FONT SIZE=3D2>Kathy Breda know to help us plan the refreshment and =
free lunch</FONT>
<BR><FONT SIZE=3D2>participation.&nbsp; E-mail is =
[email-masked].</FONT>
</P>

<P><FONT SIZE=3D2>We am looking forward to seeing you in Worcester and =
having a</FONT>
<BR><FONT SIZE=3D2>productive meeting.</FONT>
</P>

<P><FONT SIZE=3D2>Bob Ross</FONT>
<BR><FONT SIZE=3D2>Mentor Graphics</FONT>
</P>

<P><FONT =
SIZE=3D2>************************************************************</F=
ONT>
</P>

<P><FONT SIZE=3D2>I B I S&nbsp;&nbsp; S U M M I T&nbsp;&nbsp; M E E T I =
N G&nbsp;&nbsp; A G E N D A</FONT>
</P>

<P><FONT SIZE=3D2>Time/Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8:30 AM - =
5:00 PM, Thursday, September 13, 2001</FONT>
</P>

<P><FONT SIZE=3D2>Location:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
Crowne Plaza Hotel</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; 10 Lincoln Square</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Worcester, Massachusetts</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Tel:&nbsp; (508) 791-1600</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Fax:&nbsp; (508) 791-1796</FONT>
</P>

<P><FONT SIZE=3D2>Content:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
IBIS Presentations and Discussions</FONT>
</P>

<P><FONT SIZE=3D2>Purpose:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Solicit and Exchange IBIS Model Related Information and</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Ideas.</FONT>
</P>

<P><FONT SIZE=3D2>Sponsors:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mentor =
Graphics</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; North East Systems Associates, Inc.</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; IBIS Open Forum</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; IBIS Users Group</FONT>
</P>

<P><FONT SIZE=3D2>PCB Conference: September 10-14, 2001</FONT>
<BR><FONT =
SIZE=3D2>East&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; Worcester's Centrum Centre</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Worcester, Massachusetts</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; See <A HREF=3D"http://www.pcbeast.com/" =
TARGET=3D"_blank">http://www.pcbeast.com/</A> for more =
information.</FONT>
</P>

<P><FONT =
SIZE=3D2>************************************************************</F=
ONT>
</P>

<P><FONT SIZE=3D2>IBIS SUMMIT AGENDA</FONT>
</P>

<P><FONT SIZE=3D2>8:30 AM&nbsp;&nbsp; MORNING REFRESHMENTS</FONT>
</P>

<P><FONT SIZE=3D2>9:00 AM&nbsp;&nbsp; Introductions and Business</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stephen =
Peters, Intel</FONT>
</P>

<P><FONT SIZE=3D2>9:15 AM&nbsp;&nbsp; Keynote Remarks</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ed =
Sayre, North East Systems Associates (NESA)</FONT>
</P>

<P><FONT SIZE=3D2>9:30 AM&nbsp;&nbsp; From Model Creator to Model =
User</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bob =
Haller, Cereva Networks</FONT>
</P>

<P><FONT SIZE=3D2>10:00 AM&nbsp; A Proposal for s2ibis3</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Paul =
Franzon, North Carolina State University </FONT>
</P>

<P><FONT SIZE=3D2>10:30 AM&nbsp; BREAK AND REFRESHMENTS</FONT>
</P>

<P><FONT SIZE=3D2>10:45 AM&nbsp; Modeling the Radiated Emission of =
Micro-controllers</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Etienne =
Sicard, National Institute of Applied Science (INSA)</FONT>
</P>

<P><FONT SIZE=3D2>11:30 AM&nbsp; Power/Ground Simulation with IBIS =
Models and Pin Mapping</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Issues</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Raj =
Raghuram, Sigrity, Inc.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>12:00 PM&nbsp; LUNCH (Free to Attendees)</FONT>
</P>

<P><FONT SIZE=3D2>1:00 PM&nbsp;&nbsp; Progress and Update in the =
Connector Specification</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stephen =
Peters, Intel Corporation</FONT>
</P>

<P><FONT SIZE=3D2>1:30 PM&nbsp;&nbsp; Progress and Issues in =
IBIS-X</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stephen =
Peters, Intel Corporation</FONT>
</P>

<P><FONT SIZE=3D2>2:00 PM&nbsp;&nbsp; IBIS-X Primitives and =
Example</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lynne =
Green, Cadence Design Systems</FONT>
</P>

<P><FONT SIZE=3D2>2:30 PM&nbsp;&nbsp; BREAK AND REFRESHMENTS</FONT>
</P>

<P><FONT SIZE=3D2>2:45 PM&nbsp;&nbsp; Unscheduled Ad Hoc Topics</FONT>
</P>

<P><FONT SIZE=3D2>3:15 PM&nbsp;&nbsp; Roundtable - Other Topics</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stephen =
Peters, Intel, Ed Sayre, NESA</FONT>
</P>

<P><FONT SIZE=3D2>5:00 PM&nbsp;&nbsp; FINAL BUSINESS AND ADJOURN</FONT>
</P>

<P><FONT =
SIZE=3D2>************************************************************</F=
ONT>
</P>

</BODY>
</HTML>
- ------_=_NextPart_001_01C136FC.49BF0B00--

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

Date: Thu, 6 Sep 2001 13:21:23 -0700 
From: "Ross, Bob" <[email-masked]>
Subject: IBIS SUMMIT MEETING AGENDA 9/13/01 (re-sent)

To IBIS Participants:

Here is the Agenda for the IBIS Summit Meeting.  We do expect
interactive discussions and some possible Ad Hoc presentations
to fill out the day.

If you plan to come, but have not notified anyone, please let
Kathy Breda know to help us plan the refreshment and free lunch
participation.  E-mail is [email-masked].

We am looking forward to seeing you in Worcester and having a
productive meeting.

Bob Ross
Mentor Graphics

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

I B I S   S U M M I T   M E E T I N G   A G E N D A

Time/Date:      8:30 AM - 5:00 PM, Thursday, September 13, 2001

Location:       The Crowne Plaza Hotel
                10 Lincoln Square
                Worcester, Massachusetts
                Tel:  (508) 791-1600
                Fax:  (508) 791-1796

Content:        IBIS Presentations and Discussions

Purpose:        Solicit and Exchange IBIS Model Related Information and
                Ideas.

Sponsors:       Mentor Graphics
                North East Systems Associates, Inc.
                IBIS Open Forum
                IBIS Users Group

PCB Conference: September 10-14, 2001
East            Worcester's Centrum Centre
                Worcester, Massachusetts
                See http://www.pcbeast.com/ for more information.

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

IBIS SUMMIT AGENDA

8:30 AM   MORNING REFRESHMENTS

9:00 AM   Introductions and Business
          Stephen Peters, Intel

9:15 AM   Keynote Remarks
          Ed Sayre, North East Systems Associates (NESA)

9:30 AM   From Model Creator to Model User
          Bob Haller, Cereva Networks

10:00 AM  A Proposal for s2ibis3
          Paul Franzon, North Carolina State University 

10:30 AM  BREAK AND REFRESHMENTS

10:45 AM  Modeling the Radiated Emission of Micro-controllers
          Etienne Sicard, National Institute of Applied Science (INSA)

11:30 AM  Power/Ground Simulation with IBIS Models and Pin Mapping
          Issues
          Raj Raghuram, Sigrity, Inc.  

12:00 PM  LUNCH (Free to Attendees)

1:00 PM   Progress and Update in the Connector Specification
          Stephen Peters, Intel Corporation

1:30 PM   Progress and Issues in IBIS-X
          Stephen Peters, Intel Corporation

2:00 PM   IBIS-X Primitives and Example
          Lynne Green, Cadence Design Systems

2:30 PM   BREAK AND REFRESHMENTS

2:45 PM   Unscheduled Ad Hoc Topics

3:15 PM   Roundtable - Other Topics
          Stephen Peters, Intel, Ed Sayre, NESA

5:00 PM   FINAL BUSINESS AND ADJOURN

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

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

Date: Mon, 10 Sep 2001 08:42:05 -0700
From: "Mirmak, Michael" <[email-masked]>
Subject: IBIS techniques for Pre-emphasis ?

All,

A lot of buffer designs are beginning to include pre-emphasis to enhance the
strength of drivers for certain types of data pattern (a notable older
example is EIA/RS-485).  [Driver Schedule] and [Submodel] keyword sections
can be used to add "boosts" to driven signals, but not necessarily in any
way related to a particular signal pattern.

At present, are there any known techniques for including pre-emphasis in
IBIS buffers?  If not, are there plans to do so in IBIS 4.x/IBIS-X?

Thanks!

- - Michael Mirmak, Intel Corp.

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

Date: Mon, 10 Sep 2001 10:38:42 -0700
From: "Peters, Stephen" <[email-masked]>
Subject: RE: IBIS techniques for Pre-emphasis ?

Hi Michael:

  The issue of modeling a buffer with data stream pre-emphasis has been
raised before with respect to modeling the latest SCSI buffers.  It is
possible to model a buffer with data stream dependent pre-emphasis, although
there are limitations and  caveats.  For the details, refer to several
presentations at the June IBIS summit.
Click on

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

then go to the readme for a list of the presentation. I believe you want the
ones from Larry Barnes, Hegazy and Bob Ross.

  Regards,
  Stephen Peters
  Intel Corp.

- -----Original Message-----
From: Mirmak, Michael [mailto:[email-masked]]
Sent: Monday, September 10, 2001 8:42 AM
To: [email-masked]'
Subject: IBIS techniques for Pre-emphasis ?

All,

A lot of buffer designs are beginning to include pre-emphasis to enhance the
strength of drivers for certain types of data pattern (a notable older
example is EIA/RS-485).  [Driver Schedule] and [Submodel] keyword sections
can be used to add "boosts" to driven signals, but not necessarily in any
way related to a particular signal pattern.

At present, are there any known techniques for including pre-emphasis in
IBIS buffers?  If not, are there plans to do so in IBIS 4.x/IBIS-X?

Thanks!

- - Michael Mirmak, Intel Corp.

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

Date: Tue, 11 Sep 2001 15:24:53 -0700
From: "Peters, Stephen" <[email-masked]>
Subject: Changes to IBIS East Summit

Greetings:

  Due to the disruption in air travel, many of the officers and presenters
will not be able attend Thursday's IBIS East summit in person.
Nevertheless, the IBIS Summit and Users Group meeting WILL be held, albeit
in a scaled down fashion.  Ed Sayer (NESA) has agreed to host a Users Group
meeting with the attendees already at PCB East.  As for the IBIS Summit
itself, Intel has arranged for a teleconference connection to the Users
Group meeting.  The teleconference will be from 6:00am - 9:00am Pacific time
(9:00am - 12:00pm Eastern).  We will conduct whatever IBIS business required
and then work thru the presentations, especially Paul Fanzon's S2IBIS3
presentation and Mr. Sicard's EMI work with IBIS.  We can extend the
teleconference if folks desire and there are topics to discuss.  The dial in
number, bridge number and passcode are as follows:

Dial in number: 1-916-356-2663
Bridge number:  Bridge 3
Passcode:       5127881

Presenters, if you have not already done so please mail your presentation
(electronic format) to [email-masked] for placement on the IBIS web
site.

Thanks everyone for you patience and understanding.

  Regards,
  Stephen Peters
  Intel Corp.
  Chair, EIA/IBIS Open Forum

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

Date: Mon, 17 Sep 2001 16:11:34 -0700 (PDT)
From: john austin <[email-masked]>
Subject: ibis

If I want to create a behavioral model out of a spec.
Could you please let me know what I should watch for?
Also, if there is any documents or paper out there
that facilitate the task?

Thanks 

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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

Date: Tue, 18 Sep 2001 08:20:29 -0400
From: [email-masked]
Subject: Re: ibis

John,  could you be more specific?

Adam

john austin <[email-masked]>@eda.org on 09/17/2001 07:11:34 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Subject:  ibis

If I want to create a behavioral model out of a spec.
Could you please let me know what I should watch for?
Also, if there is any documents or paper out there
that facilitate the task?

Thanks

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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

Date: Tue, 18 Sep 2001 08:58:23 -0700 (PDT)
From: john austin <[email-masked]>
Subject: Re: ibis

I have  spec which specify the AC, DC requirement.
The specs contain V/I curves pullup & pulldown.  Also,
the references curves of the pullup and pulldown.

I am looking to write an approximate behavioral model
for it.  So I want to know what equations or portions
of the specs I need to pay attention to, to create V/I
tables, rising & falling waveforms.

I have some idea on how to proceed( based on other
IBIS models) but still I wanted to see a methodology
or guidelines already used by an expert.

Thanks

- --- [email-masked] wrote:
> 
> John,  could you be more specific?
> 
> Adam
> 
> 
> 
> 
> 
> 
> john austin <[email-masked]>@eda.org on
> 09/17/2001 07:11:34 PM
> 
> Sent by:  [email-masked]
> 
> 
> To:   [email-masked]
> cc:
> 
> Subject:  ibis
> 
> 
> If I want to create a behavioral model out of a
> spec.
> Could you please let me know what I should watch
> for?
> Also, if there is any documents or paper out there
> that facilitate the task?
> 
> Thanks
> 
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/
> 
> 
> 

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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

Date: Tue, 18 Sep 2001 11:44:15 -0700
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: ibis

You could start with reading the documents on the
IBIS web site.

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

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

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 5:20 AM
To: john austin
Cc: [email-masked]
Subject: Re: ibis

John,  could you be more specific?

Adam

john austin <[email-masked]>@eda.org on 09/17/2001 07:11:34 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Subject:  ibis

If I want to create a behavioral model out of a spec.
Could you please let me know what I should watch for?
Also, if there is any documents or paper out there
that facilitate the task?

Thanks

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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

Date: Tue, 18 Sep 2001 15:38:19 -0400
From: [email-masked]
Subject: Re: ibis

John,

My apologies for the delay in this response.

I am still not clear as to what you have or what you want to create.
Perhaps some very general and simplified advice can get you started.

First inspect the material available at the IBIS site mentioned by Arpad,
especially the specification itself.  IBIS models ( datasheets ) contain DC
and Vt data in addition to other parameters associated with  the buffer
being modeled.  The DC and Vt data can be gained via simulation ( SPICE to
IBIS ) or through lab measurement.  Most of the additional parameters can
be gained from the device's datasheet such as Vinh and Vinl.  Collectively
this data comprises a IBIS datasheet which can be used by various
simulators to perform limited SI simulation and analysis.  These simulators
read a IBIS datasheet and create their own behavioral model based on the
information contained therein.  Creating your own behavioral model from a
IBIS datasheet is not a trivial task.

Hope this helps,
Adam Tambone

john austin <[email-masked]>@eda.org on 09/18/2001 11:58:23 AM

Sent by:  [email-masked]

To:   Adam Tambone/SouthPortland/Fairchild@Fairchild
cc:   [email-masked]

Subject:  Re: ibis

I have  spec which specify the AC, DC requirement.
The specs contain V/I curves pullup & pulldown.  Also,
the references curves of the pullup and pulldown.

I am looking to write an approximate behavioral model
for it.  So I want to know what equations or portions
of the specs I need to pay attention to, to create V/I
tables, rising & falling waveforms.

I have some idea on how to proceed( based on other
IBIS models) but still I wanted to see a methodology
or guidelines already used by an expert.

Thanks

- --- [email-masked] wrote:
>
> John,  could you be more specific?
>
> Adam
>
>
>
>
>
>
> john austin <[email-masked]>@eda.org on
> 09/17/2001 07:11:34 PM
>
> Sent by:  [email-masked]
>
>
> To:   [email-masked]
> cc:
>
> Subject:  ibis
>
>
> If I want to create a behavioral model out of a
> spec.
> Could you please let me know what I should watch
> for?
> Also, if there is any documents or paper out there
> that facilitate the task?
>
> Thanks
>
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/
>
>
>

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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

Date: Tue, 18 Sep 2001 14:41:17 -0700 (PDT)
From: john austin <[email-masked]>
Subject: Re: ibis

Thank you Adam and to all to those who responded. 
- --- [email-masked] wrote:
> 
> John,
> 
> My apologies for the delay in this response.
> 
> I am still not clear as to what you have or what you
> want to create.
> Perhaps some very general and simplified advice can
> get you started.
> 
> First inspect the material available at the IBIS
> site mentioned by Arpad,
> especially the specification itself.  IBIS models (
> datasheets ) contain DC
> and Vt data in addition to other parameters
> associated with  the buffer
> being modeled.  The DC and Vt data can be gained via
> simulation ( SPICE to
> IBIS ) or through lab measurement.  Most of the
> additional parameters can
> be gained from the device's datasheet such as Vinh
> and Vinl.  Collectively
> this data comprises a IBIS datasheet which can be
> used by various
> simulators to perform limited SI simulation and
> analysis.  These simulators
> read a IBIS datasheet and create their own
> behavioral model based on the
> information contained therein.  Creating your own
> behavioral model from a
> IBIS datasheet is not a trivial task.
> 
> Hope this helps,
> Adam Tambone
> 
> 
> 
> 
> 
> 
> john austin <[email-masked]>@eda.org on
> 09/18/2001 11:58:23 AM
> 
> Sent by:  [email-masked]
> 
> 
> To:   Adam Tambone/SouthPortland/Fairchild@Fairchild
> cc:   [email-masked]
> 
> Subject:  Re: ibis
> 
> 
> I have  spec which specify the AC, DC requirement.
> The specs contain V/I curves pullup & pulldown. 
> Also,
> the references curves of the pullup and pulldown.
> 
> I am looking to write an approximate behavioral
> model
> for it.  So I want to know what equations or
> portions
> of the specs I need to pay attention to, to create
> V/I
> tables, rising & falling waveforms.
> 
> I have some idea on how to proceed( based on other
> IBIS models) but still I wanted to see a methodology
> or guidelines already used by an expert.
> 
> Thanks
> 
> --- [email-masked] wrote:
> >
> > John,  could you be more specific?
> >
> > Adam
> >
> >
> >
> >
> >
> >
> > john austin <[email-masked]>@eda.org on
> > 09/17/2001 07:11:34 PM
> >
> > Sent by:  [email-masked]
> >
> >
> > To:   [email-masked]
> > cc:
> >
> > Subject:  ibis
> >
> >
> > If I want to create a behavioral model out of a
> > spec.
> > Could you please let me know what I should watch
> > for?
> > Also, if there is any documents or paper out there
> > that facilitate the task?
> >
> > Thanks
> >
> > __________________________________________________
> > Terrorist Attacks on U.S. - How can you help?
> > Donate cash, emergency relief information
> >
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/
> >
> >
> >
> 
> 
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/
> 
> 
> 

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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

Date: Tue, 18 Sep 2001 15:58:02 -0700
From: "Dagostino, Tom" <[email-masked]>
Subject: RE: ibis

Going from a released spec, one that a semiconductor manufacturer will send out will lead you to a much weaker model than the actual silicon.  For example a typical part will have a Vol of 0.4V at 8 mA.  In reality that driver will be 3 to 5 times stronger, 24 to 40 mA at 0.4V.  The same applies to Voh.  Most semiconductor datasheets do not specify rise and fall times so you will have to guess a transition time.  You cannot just look at the underlying process used and make a guess because there may be structures in the output that control the slew rate.  If you have rise and fall time specs in the datasheet they are likely to be accurate.

You will also need to know if there is a power clamp in the device.

For inputs the major items are what clamps and Ccomp.  The rest of the data can be pulled from the datasheet.

Your best bet is to find another part from that manufacturer's process and copy that model assuming you can find one with the same output buffer used.  If you have a sample you can make some measurements if you have power supplies, a high speed scope and some means of measuring the IV characteristics.

Tom Dagostino
Modeling Manager
Mentor Graphics Corp.
SAE
[email-masked]
503-685-1613

- -----Original Message-----
From: john austin [mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 8:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: ibis

I have  spec which specify the AC, DC requirement.
The specs contain V/I curves pullup & pulldown.  Also,
the references curves of the pullup and pulldown.

I am looking to write an approximate behavioral model
for it.  So I want to know what equations or portions
of the specs I need to pay attention to, to create V/I
tables, rising & falling waveforms.

I have some idea on how to proceed( based on other
IBIS models) but still I wanted to see a methodology
or guidelines already used by an expert.

Thanks

- --- [email-masked] wrote:
> 
> John,  could you be more specific?
> 
> Adam
> 
> 
> 
> 
> 
> 
> john austin <[email-masked]>@eda.org on
> 09/17/2001 07:11:34 PM
> 
> Sent by:  [email-masked]
> 
> 
> To:   [email-masked]
> cc:
> 
> Subject:  ibis
> 
> 
> If I want to create a behavioral model out of a
> spec.
> Could you please let me know what I should watch
> for?
> Also, if there is any documents or paper out there
> that facilitate the task?
> 
> Thanks
> 
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/
> 
> 
> 

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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

Date: Wed, 19 Sep 2001 13:48:13 -0700
From: [email-masked] (Guy de Burgh)
Subject: EIA IBIS Open Forum Meeting Minutes

9/19/01
Due to technical problems with the [email-masked] reflector I am
resending these minutes to the [email-masked] reflector address.

Guy de Burgh
Secretary.

DATE: 9/18/01

SUBJECT: September 13, 2001 EIA IBIS Summit Meeting Minutes

VOTING MEMBERS AND 2001 PARTICIPANTS LIST:
3Com (& CommWorks)             Roy Leventhal
Ansoft Corporation             (Eric Bracken)
Apple Computer                 John Figueroa
Applied Simulation Technology  [Raj Raghuram], Norio Matsui,
                               Fred Balistreri
Avanti                         (Chen Hongyu)
Cadence Design                 [Ian Dodd], Patrick Dos Santos, Heiko Dudek,
                               Lynne Green*, Lance Wang*
Cisco Systems                  Syed Huq, Lungfu Chen
Cypress Semiconductor          (Rajesh Manapat)
EMC Corporation                Brian Arsenault, Jinhua Chen
Fairchild Semiconductor        Adam Tambone
Huawei Technologies            Rachild Chen
IBM                            Michael Cohen, Greg Edlund, Wes Martin,
                               Yeon-Chang Hahm, Bill DeVey, Pravin Patel
Innoveda (& HyperLynx)         Guy de Burgh, John Angulo, Cary Mandel, 
                               Matthew Flora, Steve Kaufer
Intel Corporation              Stephen Peters**, Arpad Muranyi*,
                               Dave Lorang, Michael Mirmak, Qinglun Chen,
                               Will Hobbs, Wei-hsing Huang
LSI Logic                      Larry Barnes
Mentor Graphics                Bob Ross**, Tom Dagostino, Chris Reid,
                               Mike Donnelly, Hazem Hegazy, Tony Dunbar,
                               Griff Derryberry, Dan Lake, Sherif Hammad,
                               Mohammed Korany, Weston Beal, Chris Swaim*,
                               Ali Samii, Eric Ronger, Karine Loudet,
                               Daisaku Shiga, Kenji Kushima, Ian Dodd
Micron Technology              Randy Wolff, Yong Phan
Mitsubishi                     Pat Hefferan
Molex Incorporated             Gus Panella, Brian O'Malley
National Semiconductor         Milt Schwartz
North East Systems Associates  Edward Sayre*
Philips Semiconductor          Zack Ciccone, Rob Mataheroe
Quantic EMC                    (Mike Ventham)
Signal Integrity Software      Douglas Burns, Barry Katz, Walter Katz
Sigrity                        Raj Raghuram*, Winson Yu*
SiQual                         Scott McMorrow*, Rob Hinz, Bernard Voss,
                               Chris Brewster
Texas Instruments              Thomas Fisher, Stephen Nolan, Ramzi Ammar,
                               Jean Claude Perrin, Moshiul Haque
Time Domain Analysis Systems   Dima Smolyansky, Steve Corey
Tyco Electronics               (Russell Moser)
Via Technologies               (Weber Chuang)
Zuken (& Incases)              John Berrie, Ralf Bruening

OTHER PARTICIPANTS IN 2001:
Actel Corporation              Silvia Montoya
Acuson                         Kim Helliwell
AMCC                           Jeff Smith
ASIS Ltd                       David Wright
Brocade Communications         Robert Badal
BMW                            Friedrich Hasinger
Cereva Networks                Bob Haller*
Compaq                         [Peter LaFlamme], Ron Bellomio, Quang Dam,
                               Bill Ham
EADS Airbus Industry           Claude Huet
  (Aerospatiale)
EFM                            Ekkehard Miersch, Horle Raines
EIA                            Cecilia Fleming
Ericsson Radio Systems         Anders Ekholm
FCI                            Sercu Stefaan
Foundary Networks              Bertram Chan
Framatom Conectors             Danny Morlion
Fraunhofer Institute           Mariusz Faferko, Peter Kralicek
  Reliability and
  Integration
Fujitsu Ltd                    Tadashi Arai, Takeshi Murakami
Heidelberger Druchmaschinen AG Wolfgang Kleinfeldt
Hyundai Electronics            Jongho Kang
Idaho State University         Al Davis
Infineon Technologies          Christian Sporrer
Intrinsix Corporation          Steven Chin
KAW/USA                        Shinichi Maeda*
Motorola                       (Rick Kingen)
National Institute of Applied  Etienne Sicard**
  Science (INSA)
Nokia                          Tapani von Ravner, Mika Castren,
                               Janne Uusitalo
North Carolina State U.        Paul Franzon**
Nortel Networks                Calvin Trowell
Oak Technology                 Darmin Jin
Plexus Technology Group        Joseph Socha
Siemens (& Automotive) AG      Bernhard Unger, Helmut Katzier,
                               Katja Koller, Wolfram Meyer, Eckhard Lenski,
                               Gerald Bannert, Burkhard Muller,
                               Christian Marot, Manfred Maurer,
                               Amir Motamedi, Hans Pichlmaier
Sintecs                        Hans Klos
STMicroelectronics             Peter Hirt, Fabrice Boissieres
Sun                            Adrian Udenze
Toshiba Corp.                  Hirokaza Kato, Yuichi Koga, Toshio Sudo
Xilinx                         Susan Wu

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

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

  Date                Bridge Number    Reservation #    Passcode
  October 5, 2001     1-888-316-5901   none             6159969
  October 26, 2001    1-916-356-2663   3                0776283

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

Four people who attended by teleconference are designate by **.

NOTE: "AR" = Action Required.

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

                  IBIS SUMMIT MEETING LOGISTICS NOTE
The IBIS Summit meeting was held on Thursday, September 13, 2001 in the 
Crowne Plaza Hotel located in Worcester, Massachusetts at the same time as 
the PCB Conference East 2001.  Because of the tragic attack on America on 
September 11, 2001, the arrangements needed to be adjusted.  Several people
were already attending the PCB Conference East, but others could not travel
to the site.  After some consultation, we decided to hold the meeting as a
combined on-site/teleconference meeting.  Intel provided the phone bridge.
A total of 14 people representing 11 organizations participated and 4 of
these people participated by telephone.  Four of the presentations were
delivered by telephone and copies were available on-site.

INTRODUCTIONS AND BUSINESS
Stephen Peters welcomed the participants and thanked the co-sponsors Mentor 
Graphics, North East Systems Associates, the IBIS Users Group and IBIS Open 
Forum.  Stephen also thanked Kathy Breda and North East Systems Associates
for the arrangements and for the last minute logistical adjustments.  All
of the meeting presentation slides were available at the meeting and had
also been uploaded at the site:

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

Stephen stated that there were no business issues.  Stephen asked for any
open topics.  None were offered at that time, but at the end of the
meeting Arpad Muranyi gave a brief presentation:

Arpad Muranyi - Correlation Study for DDR Style Terminations with IBIS
                Models

KEYNOTE REMARKS
Stephen Peters introduced Ed Sayre, Chair of the IBIS Users Group for some 
keynote remarks.  

After thanking Intel for the bridge, Ed expressed concern that the IBIS
specification was becoming too complex for the middle ground user and
becoming too hard to use.  A tutorial is needed to understand the
specification, and a paper or presentation detailing the theoretical basis
behind IBIS behavioral modeling would be helpful.  He also felt that while
the model developer needs to be concerned about the syntactical issues, the
user needs more graphical information content. In short, the basic concepts
need to be communicated better. Ed suggested that money and resources be set
aside for IBIS training.

The group commented and discussed Ed's remarks.  Arpad Muranyi state that
complexity was added in Version 3.2 to deal with new technologies beyond the
original scope of IBIS.  Bob Haller stated that the IBIS Cookbook (which
needs to be updated) has some graphical representations.  Lynne Green commented
that users buy tools to do the work and engineers are more software literate,
and the participants agreed that most IBIS models are created by junior level
engineers.  Raj Raghuram suggested that a university professor could write a 
book or produce more information on IBIS.  Bob Ross noted that EDA Vendors and
other commercial vendors often provide model training and model development
support and also stated that Arpad Muranyi has a four hour Real-Time video IBIS
tutorial that is available.  Stephen Peters did acknowledge that the IBIS 
Specification could be clearer.

                  PRESENTATIONS AND DISCUSSION TOPICS
The rest of the meeting consisted of presentations and discussions.  These
notes capture some of the content and discussion.  See the uploaded documents
for more detail.

FROM MODEL CREATOR TO MODEL USER
Bob Haller, Cereva Networks
Bob Haller started by showing that some public IBIS models still have a
large number of errors.  Bob showed an AC termination simulation where IBIS
produced good results quickly.  He also showed a simulation result where
the Spice model was appropriate.

Moving from model creator to model user, Bob now sees good and bad models.
He commented that he can identify and fix models and provide some vendor
feedback.  Bob noted that given today's short design cycles one has to request
models early. Market forces are generally driving model quality, but he still
recommends verifying IBIS models in the lab.

Bob then went on to give examples of typical model problems.  He noted that
the additional PCI loads will be handled in IBIS Version 4.0.  However, 
there are improvements and vendors are more responsive. Bob stated that work
is continuing on advances (Connector Specification, IBIS-X), and pointed to a
number of resources.  These includes Syed Huq's DesignCon 2000 paper as well
as friends and colleagues.

Bob Ross commented that some good models are produced by EDA and commercial
vendors, and some of these vendor also help semiconductor vendors produce
models.

A PROPOSAL FOR s2ibis3
Paul Franzon and Michael Steer, North Carolina State University (NCSU)
Paul Franzon via teleconference gave some background showing strong
industrial connections and support for analog, RF and mixed mode research
based on federal funding.  Paul is proud of the earlier NCSU s2ibis and
s2ibis2 contributions to IBIS and industry.  A multi-university DARPA
project covers a number of advanced modeling and simulation abstractions:

  Global Environment, Michael Steer, NCSU
  Digital Behavioral Modeling and SSN Macromodeling, Paul Franzon, NCSU
  Parasitic Extraction and Full Wave Modeling of Interconnect, Andreas
    Cangellaris, U. of Illinois
  Optoelectronic Modeling, Mark Neifeld, University of Arizona

Paul gave an overview of the other activities.  Regarding his topic, he
planned a macromodeling tool for automatic accurate reduced-order SSN
modeling of on-chip digital structures from full circuit descriptions.  Its
unique feature is a macromodel production tool similar to Spice2IBIS and
a complete SSN macromodel conversion tool.

Paul then covered point-by-point the s2ibis3 project requirements that were
issued by the IBIS sub-committee.  Some notable points include:

  C++ based, JAVA for graphics
  Flex and Bison and portability through GNU and Cygwin in MS Windows
  A separate IBIS parser may be developed
  Improved algorithms and configuration options.
  Improved Spice controls for improved convergence (e.g., Vdd ramping,
    more .options, fixing some clamping problems, data point and time,
    voltage step options, etc.)

In addition, the goals are to support:

  GNU public license
  Class structures to support digital and analog macromodeling with IBIS
    as a subset
  Be applicable for board level modeling and modeling of segments of mixed
    signal chips

The research agenda includes support of IBIS-X with SSN macromodeling, 3-D
models, and testing and validating against Spice and measurement.  Paul
intends to have industrial collaborators.  This 3-year DARPA effort will
produce a spice2ibis3 and have strong industrial collaboration.

Several questions and suggestions were discussed during the presentation.
Ed Sayre and Lynne Green commented that the s2ibis3 utility should handle
differential models and models with strong feedback (such as those having
gate modulation).  Numerical stability presents a challenge, and there was
a long discussion regarding the utility of models and simulators supporting
VDD ramping.  Several people stated that they would investigate providing
some industrial support.

PROGRESS AND UPDATE ON THE CONNECTOR SPECIFICATION
Stephen Peters, Intel Corporation
Because of a conflicting meeting, Stephen Peters' two presentations
were moved up to this position in the meeting.  

Stephen, via teleconference, stated that the IBIS Connector header and
about three-fourths of the technical description have been reviewed.
The Working Group plans to add the conductance matrix (G Matrix) for
losses and also frequency dependent simulations.  Both the LRGC and
S-parameter formats are being considered.  We expect a specification
completion by the end of January 2002 if there are no unexpected 
technical issues.

Stephen gave some more detail on changes including even_mode, odd_mode,
and quiescent model types and Fork and Endfork under a [Path Description]
keyword.  Electrical matrix "row" order can be random, so a pin number
to matrix map has been added.

Stephen and others then discussed the advantages of using
S-parameters versus RLGC matrices.  S-parameters are more natural for
frequency domain simulations while RLGC are more natural and familiar to
engineers for time domain simulations.  Ed asked if the inductance
matrix was for partial or loop inductances.  Bob Ross indicated that
for full matrix the inductance is partial, however, there was some
discussion on whether loop inductances are appropriate for single
line models.  After much discussion Stephen agreed to make sure that
the connector specification fully documents partial vs. loop inductances
and when each are used.

PROGRESS AND ISSUES IN IBIS-X
Stephen Peters, Intel Corporation
Stephen Peters stated that a simpler path into IBIS is being pursued.
Shortly after IBIS Version 4.0 is approved, the Working Group intends to
issue a BIRD to add the [Define 'class name'] concept.  The work is now
focusing on the macro-language reference manual (IBIS-ML).  This is being
reviewed and should be available in January 2002.

Stephen listed some technical milestones that have been met or are being
tracked.  Then Stephen described the [Define "class name"] keyword.  He
showed the syntax.  It can be used in the IBIS file itself.  Defines can
be collected in a library file.  Once an object is defined, it can be
customized in the IBIS file.

Ed Sayre asked about backward compatibility with IBIS Version 3.2, and
Stephen said that IBIS Version 3.2 (and 4.0) will be supported by being
defined in the macro language.

MODELING THE RADIATED EMISSION OF MICRO-CONTROLLERS
Christian Marot, Siemens, Andre Peyre Lavigne, Motorola, Claud Huet, Eads
Airbus, Etienne Sicard, National Institute of Applied Science (INSA)
After lunch, Etienne Sicard, via teleconference, introduced the need for EMC
modeling of ICs.  The industry is working with 0.12u, 6 metal technology 
with up to 200,000,000 devices and CPU frequencies of 1 GHz.  The dI/dt
switching speeds have become faster causing increased EMC problems.  Etienne
showed identical devices from different vendors.  One device designed without
considering radiation showed to be out of compliance by 20 to 40 dB compared
to other chip.  Currently EMC problems are found after the fact and
require costly design iterations to correct.

The IERSET (a European research institution for research in transportation)
EMC project for ICs is co-sponsored by EADS Airbus, Siemens Automotive,
Motorola, Alcatel, INSA, and IERSET.  The objectives are to define and
validate a model for PCB CAD tools to guarantee the EMC of electronic
systems.  Its focus is on a model from 1 MHz to 1 GHz for conducted and
radiated emission.  The French standards organization UTE has issued a
draft Integrated Circuit Electromagnetic compatibility Model (ICEM) and
forwarded it to IEC as a Committee Draft for Voting 62014-3.  An ICEM
Cookbook Version 1c is available.  ICEM presentations and papers are
planned at conferences, at company sites and at IBIS Summit meetings.

Etienne described the core emission model and its basic parameters Cd and
core noise generator Ib and advanced parameters for secondary resonance
Rvdd, Lvdd, Rvss, Lvss and Cb.  He gave typical values and showed some
good measurement and simulation comparisons.  In response to a question
by Raj Raghuram, Etienne clarified that the measurements and simulations
were for near field emissions.  Scott McMorrow and others commented on the
resonance terminology since the since all resonances including the
"primary" resonance were many multiples above the 8 MHz fundamental clock
frequency.  In response to Lynne Green's question some typical values of
all parameters were given (Cd - 300 pF to 20 nF, Cb - 1 nF, Lvdd and Lvss -
15 nH).

The equivalent current generator was extracted through Verilog gate level
simulation and simple statistical considerations.  Spice and interpolated
transistor level methods had either size or number of device limitations.

The core emission model can be extended with an IBIS I/O model.  An I/O
buffer is added along with a Cio decoupling capacitor and a substrate
resistance Zsub (typically 1 to 10 ohms).  Etienne showed good simulation
predictions with TEM cell measurements up to 300 MHz with the core emission
model alone, and improved correlation up to 800 MHz when the I/O model was
added.

Etienne stressed that this is a relatively simple model that can be used for
predicting parasitic emission of complex chips.  Bob Ross added that a link
to Etienne's work that includes several presentations and draft documents
exists under:

  http://intrage.insa-tlse.fr/~etienne/Emc/index.html

POWER/GND SIMULATION USING IBIS MODELS AND PIN MAPPING ISSUES
Raj Raghuram, Sigrity, Inc. 
In introducing the subject Raj Raghuram stated that analysis based on ideal
planes are no longer sufficient.  Routing of traces through multiple layers
and with vias is now common.  Advanced signal and power integrity now
combines the circuit along with trace transmission lines the pin RLC and
non-ideal ground and power plane simulation.  This can take care of power
ground noise (SSN or Delta-I or ground bounce), effects of vias and return
path discontinuity, effects of decoupling capacitors, and edge radiation
from boards due to SSN.

The approach he takes is to do combined circuit/transmission line/power/
ground simulation with IBIS models in the time domain (in contrast to a
separate frequency domain power/ground analysis).  He does need the [Pin
Mapping] keyword for the IBIS models.  Raj showed some topologies and some
results.  Full analysis distorts the signal, but well-placed decoupling
capacitors can produce a nearly ideal response since return path and
other discontinuities are bypassed.  Raj provided plots illustrating the
improvement provided by decoupling capacitors.

Raj also illustrated some several types of devices with unique pin mapping
requirements. These included separating different supplies and possible
different clamp references from the buffer, core and I/O parts of the IC,
and separating analog and digital ground pins.

Raj stressed that [Pin Mapping] is essential and is a zeroth order effect
in simulation that includes more accurate ground and power effects.

Lynne Green asked if the decoupling capacitors had parasitic elements.  Raj
responded that they did not, but the RL information was available form the
manufacturers and easy to add.

IBIS-X PRIMITIVES AND EXAMPLE
Lynne Green, Cadence Design Systems
Lynne Green introduced IBIS Version 3.2 as having a fixed topology with
some flexibility regarding values and allowable IBIS setups.

She listed some usages of "model" in IBIS as a "circuit" model for a
predefined topology, a "component" model for pins and packages and a
"buffer" model for numbers, vectors, and data tables.  IBIS-X retains the
last two usages, but introduces a "behavioral" model where the model maker
defines the topology.

Lynne then used some examples to show some of the IBIS-X capability.  The
simple model under [Define Model] inherited an existing IBIS Version 3.2
buffer model as a "model_base", but added voltage and temperature dependent
capacitor and resistor elements.  Another example showed how resistor and
capacitor tables could be specified.  As second buffer had the same tables
with different data.

IBIS-X "behavioral" models add components that model effects (such as
vsource), has symbolic values such as C_comp, has tables and equations for
components, and can deal with other variables such as time and temperature.

Lynne showed some primitives (resistor, capacitor, inductor, voltage and
current sources, voltage controlled voltage and current sources, and
transmission lines.  She illustrated variations of the resistor primitive.

The model maker provides the model behavior, the model data, and pin list.
The users may provide pin lists (such as for FPGAs) and model selector
information.

Much discussion occurred during the presentation.  Ed Sayre and others did
feel that the syntax and terminology was confusing and did not relate to
what engineers already know and use.  We should use words with a common
context.  This should be raised as an issue for the Futures committee.
It was not clear whether the set of primitives does or should include
current and voltage controlled current sources.  Engineers are already
familiar with the set of four controlled sources.  Options regarding coupled
transmission line modeling were discussed.  One suggestion was to have
local temperature controlled resistors modeling thermal hot spots.  IBIS-X
will continue to support MKS units.  There was some concern over how EDA
vendors would support IBIS-X.

Lynne concluded that IBIS-X should be regarded as an extension of IBIS.

CORRELATION STUDY FOR DDR STYLE TERMINATIONS WITH IBIS MODELS
(Unscheduled Presentation)
Arpad Muranyi, Intel Corporation
Arpad Muranyi investigated the accuracy of the recommended waveform loads
with respect to the DDR style terminations such as 50 ohms to Vdd/2.

He showed two sets of results:

  (1) V_fixture = 0, 5 V and R_fixture = 50 ohms
  (2) V_fixture = 2.5 V, R_fixture = 50 ohms

Arpad's concern was that the results for (1) did not overlay for the 
DDR termination.  Also the results for (2) overlayed for the DDR termination
(same as the load), but gave bad results for 50 ohms to ground and Vdd for
both the rising and falling edges.  His results were based on the HSPICE
B-element.

Scott McMorrow suggested a larger load resistance such as 100 ohms for (1)
because the voltages of the existing waveforms did not overlap center
region.  Bob Ross suggested exploring Vdd/2 and 2Vdd/3 voltages with 50 ohm
loads to center the four waveform loads.

Arpad plans to send the ibis model to EDA vendors to test in their own tools
since they may have different algorithms.

[Added note, the uploaded presentations show that Scott's and Bob's
suggestions did not produce improved results]

FINAL BUSINESS
Bob Ross reported that the next IBIS Summit Meeting is scheduled on January 
28, 2002 at DesignCon2002 in Santa Clara, California.  We are also working 
on arrangements for an IBIS Summit Meeting on March 8, 2002 at Date 2002 in
Paris, France.  The weekly IBIS Working Groups on the Connector Specification
and on IBIS-X will continue next week.

Ed Sayre offered space at NESA to those who needed working facilities while
waiting for their return trips.

NEXT MEETING:
The next teleconference meeting will be on Friday October 5, 2001

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

IBIS CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-1831
            [email-masked]
            Senior Hardware Engineer, Intel Corporation
            M/S JF4-215
            2111 NE 25th Ave.
            Hillsboro, OR 97124-5961

VICE CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897
            [email-masked]
            Modeling Engineer, Mentor Graphics
            8005 S.W. Boeckman Road, Wilsonville, OR 97070

SECRETARY:  Guy de Burgh (805) 988-8250, Fax: (805) 988-8259
            [email-masked]
            Senior Manager, Innoveda
            1369 Del Norte Rd.
            Camarillo, CA 93010-8437

LIBRARIAN:  Roy Leventhal (837) 797-2152, Fax: (847) 222-2799
            [email-masked]
            Senior Engineer, CommWorks Corp. (a wholly owned 3Com
            subsidiary)
            1800 W. Central Rd.
            Mt. Prospect, IL 60056-2293

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

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

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

The following e-mail addresses are used:

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

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

      Help and other commands:
      help

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

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

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

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

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

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

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

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

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

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

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

Date: Thu, 20 Sep 2001 15:34:16 -0400
From: tcoyle <[email-masked]>
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Thu, 20 Sep 2001 16:34:26 -0700
From: "Lorang, David D" <[email-masked]>
Subject: RE: Duty Cycle

Tim,

I think you have it right. 

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.  

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.  

Where exactly the output edges occur is dependent on internal buffer delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Thu, 20 Sep 2001 23:13:12 -0700 (PDT)
From: Majordomo Account <majordom>
Subject: test  - please ignore

this is a test - please ignore.
- [email-masked]

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

Date: Fri, 21 Sep 2001 11:00:17 -0700
From: Frederic Giral <[email-masked]>
Subject: ECL modeling

- --------------A8AB4F56F4A95D722606C4A9
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

Hello,

I'm trying to built an IBIS model from a spice netlist using the s2ib2
software from the university of North Carolina.
Would you have by chance an example of .s2i file to send me ? I would
need a file including models for both differential ECL input and output.

Regards, Frederic.

- --
**********************************
Frederic GIRAL

Tel:408-586-6891
Fax:408-586-4677
Pager:408-697-6195
Email:[email-masked]

SCHLUMBERGER ATE
150 Baytech Dr, San Jose, CA 95134
**********************************

- --------------A8AB4F56F4A95D722606C4A9
Content-Type: text/html; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello,
<p>I'm trying to built an IBIS&nbsp;model from a spice netlist using the
s2ib2 software from the university of North Carolina.
<br>Would you have by chance an example of .s2i file to send me ? I would
need a file including models for both differential ECL input and output.
<p>Regards, Frederic.
<pre>--&nbsp;
**********************************
Frederic GIRAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Tel:408-586-6891
Fax:408-586-4677
Pager:408-697-6195&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Email:[email-masked]

SCHLUMBERGER ATE
150 Baytech Dr, San Jose, CA 95134&nbsp;&nbsp;
**********************************</pre>
&nbsp;</html>

- --------------A8AB4F56F4A95D722606C4A9--

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

Date: Sat, 22 Sep 2001 09:01:24 -0700
From: "Jon Powell" <[email-masked]>
Subject: RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Sat, 22 Sep 2001 09:09:33 -0700
From: "Jon Powell" <[email-masked]>
Subject: RE: ECL modeling

This is a multi-part message in MIME format.

- ------=_NextPart_000_0027_01C14346.4BD449E0
Content-Type: text/plain;
	charset="iso-8859-15"
Content-Transfer-Encoding: 7bit

Just a Note:
I don't know how well s2ibis will work on ECL, because it is a current
controled technology.
On the other hand, it is also very linear and a thevinen equivalent model
made by hand from
from spice measurements would probably be very accurate.

jon

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of Frederic Giral
  Sent: Friday, September 21, 2001 11:00 AM
  To: [email-masked]
  Subject: ECL modeling

  Hello,
  I'm trying to built an IBIS model from a spice netlist using the s2ib2
software from the university of North Carolina.
  Would you have by chance an example of .s2i file to send me ? I would need
a file including models for both differential ECL input and output.

  Regards, Frederic.

- --
**********************************
Frederic GIRAL

Tel:408-586-6891
Fax:408-586-4677
Pager:408-697-6195
Email:[email-masked]

SCHLUMBERGER ATE
150 Baytech Dr, San Jose, CA 95134
**********************************

- ------=_NextPart_000_0027_01C14346.4BD449E0
Content-Type: text/html;
	charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D534020816-22092001><FONT face=3DArial color=3D#0000ff =
size=3D2>Just a=20
Note:</FONT></SPAN></DIV>
<DIV><SPAN class=3D534020816-22092001><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
don't know how well s2ibis will work on ECL, because it is a current =
controled=20
technology.</FONT></SPAN></DIV>
<DIV><SPAN class=3D534020816-22092001><FONT face=3DArial color=3D#0000ff =
size=3D2>On the=20
other hand, it is also very linear and a thevinen equivalent model made =
by hand=20
from</FONT></SPAN></DIV>
<DIV><SPAN class=3D534020816-22092001><FONT face=3DArial color=3D#0000ff =
size=3D2>from=20
spice measurements would probably be very accurate.</FONT></SPAN></DIV>
<DIV><SPAN class=3D534020816-22092001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D534020816-22092001><FONT face=3DArial color=3D#0000ff =

size=3D2>jon</FONT></SPAN></DIV>
<DIV><SPAN class=3D534020816-22092001></SPAN>&nbsp;</DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Frederic=20
  Giral<BR><B>Sent:</B> Friday, September 21, 2001 11:00 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> ECL =
modeling<BR><BR></FONT></DIV>Hello,=20
  <P>I'm trying to built an IBIS&nbsp;model from a spice netlist using =
the s2ib2=20
  software from the university of North Carolina. <BR>Would you have by =
chance=20
  an example of .s2i file to send me ? I would need a file including =
models for=20
  both differential ECL input and output.=20
  <P>Regards, Frederic. <PRE>--&nbsp;
**********************************
Frederic =
GIRAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Tel:408-586-6891
Fax:408-586-4677
Pager:408-697-6195&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Email:[email-masked]

SCHLUMBERGER ATE
150 Baytech Dr, San Jose, CA 95134&nbsp;&nbsp;
**********************************</PRE>&nbsp; =
</BLOCKQUOTE></BODY></HTML>

- ------=_NextPart_000_0027_01C14346.4BD449E0--

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

Date: Sat, 22 Sep 2001 18:28:43 -0700 (PDT)
From: john austin <[email-masked]>
Subject: RE: ibis

Thank You Tom.
- --- "Dagostino, Tom" <[email-masked]>
wrote:
> Going from a released spec, one that a semiconductor
> manufacturer will send out will lead you to a much
> weaker model than the actual silicon.  For example a
> typical part will have a Vol of 0.4V at 8 mA.  In
> reality that driver will be 3 to 5 times stronger,
> 24 to 40 mA at 0.4V.  The same applies to Voh.  Most
> semiconductor datasheets do not specify rise and
> fall times so you will have to guess a transition
> time.  You cannot just look at the underlying
> process used and make a guess because there may be
> structures in the output that control the slew rate.
>  If you have rise and fall time specs in the
> datasheet they are likely to be accurate.
> 
> You will also need to know if there is a power clamp
> in the device.
> 
> For inputs the major items are what clamps and
> Ccomp.  The rest of the data can be pulled from the
> datasheet.
> 
> Your best bet is to find another part from that
> manufacturer's process and copy that model assuming
> you can find one with the same output buffer used. 
> If you have a sample you can make some measurements
> if you have power supplies, a high speed scope and
> some means of measuring the IV characteristics.
> 
> Tom Dagostino
> Modeling Manager
> Mentor Graphics Corp.
> SAE
> [email-masked]
> 503-685-1613
> 
> 
> -----Original Message-----
> From: john austin [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2001 8:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: ibis
> 
> 
> I have  spec which specify the AC, DC requirement.
> The specs contain V/I curves pullup & pulldown. 
> Also,
> the references curves of the pullup and pulldown.
> 
> I am looking to write an approximate behavioral
> model
> for it.  So I want to know what equations or
> portions
> of the specs I need to pay attention to, to create
> V/I
> tables, rising & falling waveforms.
> 
> I have some idea on how to proceed( based on other
> IBIS models) but still I wanted to see a methodology
> or guidelines already used by an expert.
> 
> Thanks
> 
> --- [email-masked] wrote:
> > 
> > John,  could you be more specific?
> > 
> > Adam
> > 
> > 
> > 
> > 
> > 
> > 
> > john austin <[email-masked]>@eda.org on
> > 09/17/2001 07:11:34 PM
> > 
> > Sent by:  [email-masked]
> > 
> > 
> > To:   [email-masked]
> > cc:
> > 
> > Subject:  ibis
> > 
> > 
> > If I want to create a behavioral model out of a
> > spec.
> > Could you please let me know what I should watch
> > for?
> > Also, if there is any documents or paper out there
> > that facilitate the task?
> > 
> > Thanks
> > 
> > __________________________________________________
> > Terrorist Attacks on U.S. - How can you help?
> > Donate cash, emergency relief information
> >
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/
> > 
> > 
> > 
> 
> 
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

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

Date: Sat, 22 Sep 2001 18:34:20 -0700 (PDT)
From: john austin <[email-masked]>
Subject: Archives

Is there archives for the questions and responses of
this list?

Thanks

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

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

Date: Mon, 24 Sep 2001 09:54:21 -0400
From: [email-masked]
Subject: RE: Duty Cycle

hmmm...  OK, here is another two cents, but I do not believe it disagrees
with the previous remarks.

I have found through experience that the raw rising and falling waveform
data does not in itself represent correct duty cycle.  Instead this data
must be modified to 'fit' the devices actual duty cycle.  One can modify
the R/F V-t data in a number of ways including editing the delay region (
before the rising and falling edges occur ) to fit duty cycles at specific
frequencies found thorough laboratory measurement.  Since duty cycle can
vary over frequency I have found it best to leave R/F V-t data in it's raw
state, and with R and F relative to each other as David described.

Here is an example with HSPICE that illustrates that the raw R/F V-t data
itself does not represent correct duty cycle.  One has R/F V-t data through
HSPICE simulation and has included this data in an IBIS datasheet.  Then
this IBIS datasheet is used in  HSPICE simulation comparing it to the
original HSPICE sims used to generate the IBIS datasheet.  I have found
through experience that the duty cycles of the simulated IBIS datasheet
will not be the same as the duty cycles of the HSPICE model of the device,
especially as frequency varies.  Like Jon said, simulator vendors have
their own algorithms to process R/F V-t data in order to form a desired
duty cycle.

Adam Tambone

"Jon Powell" <[email-masked]>@eda.org on 09/22/2001 12:01:24 PM

Sent by:  [email-masked]

To:   "'Lorang, David D'" <[email-masked]>
cc:   <[email-masked]>

Subject:  RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run
two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer
delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same
way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you
would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you
correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Mon, 24 Sep 2001 08:33:36 -0700
From: "Ross, Bob" <[email-masked]>
Subject: Re: Archives

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_01C1450E.A6009800
Content-Type: text/plain

John:

Current email archives are available under:

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

and

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

Older email archives since 1993 for the IBIS
reflector and ibis-users reflectors are under:

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

Bob Ross
Mentor Graphics

john austin wrote:
> 
> Is there archives for the questions and responses of
> this list?
> 
> Thanks
> 
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
Messenger. http://im.yahoo.com

- ------_=_NextPart_001_01C1450E.A6009800
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Re: Archives</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John:</FONT>
</P>

<P><FONT SIZE=3D2>Current email archives are available under:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; <A =
HREF=3D"http://www.eda.org/pub/ibis/users_archive" =
TARGET=3D"_blank">http://www.eda.org/pub/ibis/users_archive</A></FONT>
</P>

<P><FONT SIZE=3D2>and</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; <A =
HREF=3D"http://www.eda.org/pub/ibis/email_archive" =
TARGET=3D"_blank">http://www.eda.org/pub/ibis/email_archive</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Older email archives since 1993 for the IBIS</FONT>
<BR><FONT SIZE=3D2>reflector and ibis-users reflectors are =
under:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; <A HREF=3D"http://www.eda.org/pub/ibis/email/" =
TARGET=3D"_blank">http://www.eda.org/pub/ibis/email/</A></FONT>
</P>

<P><FONT SIZE=3D2>Bob Ross</FONT>
<BR><FONT SIZE=3D2>Mentor Graphics</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>john austin wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is there archives for the questions and =
responses of</FONT>
<BR><FONT SIZE=3D2>&gt; this list?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
__________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>&gt; Get email alerts &amp; NEW webcam video instant =
messaging with Yahoo! Messenger. <A HREF=3D"http://im.yahoo.com" =
TARGET=3D"_blank">http://im.yahoo.com</A></FONT>
</P>

</BODY>
</HTML>
- ------_=_NextPart_001_01C1450E.A6009800--

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

Date: Mon, 24 Sep 2001 09:13:42 -0700
From: "Lorang, David D" <[email-masked]>
Subject: RE: Duty Cycle

Jon,

I'm not sure I understand what you are disagreeing with, but let me take
another shot an see if I can clear things up a little more.   Please
understand that although originally it wasn't clear in IBIS how the timing
between rising and falling edges were related, BIRD 68.1 was written to
clarify that some information could be conveyed in the IBIS file regarding
the relationship between rising and falling edges (Rising vs. falling edge
timing will affect the duty cycle of a periodic waveform.)  So before BIRD
68.1, it was no surprise that simulation engines interpreted the waveform
data in a variety of ways.  Even now that BIRD 68.1 is approved, it is
probably safe to say that simulation engines still interpret the waveform
data in a variety of ways. Any changes that do happen won't occur overnight.
Hence IBIS, even with BIRD 68.1 applied, cannot guarantee that, for example,
the duty cycle of a waveform will come out as expected, (i.e. matching what
is happening in the silicon.)  It is likely that the waveform timings will
often still need to be "manually" adjusted, and there are tools in at least
some simulation engines to do that.  

What BIRD 68.1 does do is to specify that the relative timing information
will be there in the IBIS file, so that simulation engine developers at
least have a chance (in a specified, and perhaps more automated manner) to
eventually maintain timing relationships between rising and falling edges.
So now, at least, the hooks are there.

Dave Lorang  

- -----Original Message-----
From: Jon Powell [mailto:[email-masked]]
Sent: Saturday, September 22, 2001 9:01 AM
To: 'Lorang, David D'
Cc: [email-masked]
Subject: RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Mon, 24 Sep 2001 09:38:29 -0700 (PDT)
From: Syed Huq <[email-masked]>
Subject: ibischk3 and Open Drain

For ibischk3 ver 3.2.6, it looks for the Pullup table for a "I/O_open_drain"
buffer. Why is that ?

WARNING - [Model] GTL has no description of the buffer's high state
         DC drive characteristics (no [Pullup] table).  This warning
         can be silenced by changing the Model_type or by adding a
         [Pullup] table.

- -Syed

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

Date: Mon, 24 Sep 2001 12:45:43 -0400
From: "Todd Westerhoff" <[email-masked]>
Subject: RE: Duty Cycle

I agree with Jon.  IBIS models are not meant, by default, to represent a
device's duty cycle.  You can get the model to produce the correct behavior
if you're careful with your modeling - but the tools typically used to
create IBIS models will not automatically produce a model that reflects the
device's duty cycle.

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Monday, September 24, 2001 9:54 AM
To: Jon Powell
Cc: [email-masked]
Subject: RE: Duty Cycle

hmmm...  OK, here is another two cents, but I do not believe it disagrees
with the previous remarks.

I have found through experience that the raw rising and falling waveform
data does not in itself represent correct duty cycle.  Instead this data
must be modified to 'fit' the devices actual duty cycle.  One can modify
the R/F V-t data in a number of ways including editing the delay region (
before the rising and falling edges occur ) to fit duty cycles at specific
frequencies found thorough laboratory measurement.  Since duty cycle can
vary over frequency I have found it best to leave R/F V-t data in it's raw
state, and with R and F relative to each other as David described.

Here is an example with HSPICE that illustrates that the raw R/F V-t data
itself does not represent correct duty cycle.  One has R/F V-t data through
HSPICE simulation and has included this data in an IBIS datasheet.  Then
this IBIS datasheet is used in  HSPICE simulation comparing it to the
original HSPICE sims used to generate the IBIS datasheet.  I have found
through experience that the duty cycles of the simulated IBIS datasheet
will not be the same as the duty cycles of the HSPICE model of the device,
especially as frequency varies.  Like Jon said, simulator vendors have
their own algorithms to process R/F V-t data in order to form a desired
duty cycle.

Adam Tambone

"Jon Powell" <[email-masked]>@eda.org on 09/22/2001 12:01:24 PM

Sent by:  [email-masked]

To:   "'Lorang, David D'" <[email-masked]>
cc:   <[email-masked]>

Subject:  RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run
two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer
delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same
way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you
would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you
correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Mon, 24 Sep 2001 10:26:42 -0700
From: "Mirmak, Michael" <[email-masked]>
Subject: RE: ibischk3 and Open Drain

Syed,

This was covered in Bug 53 (an amendment to Bug 34).  It will most likely
get fixed in the next IBISCHK3 release; Bob Ross can confirm when this will
be available.

- - Michael Mirmak, Intel Corp.

- -----Original Message-----
From: Syed Huq [mailto:[email-masked]]
Sent: Monday, September 24, 2001 9:38 AM
To: [email-masked]
Subject: ibischk3 and Open Drain

For ibischk3 ver 3.2.6, it looks for the Pullup table for a "I/O_open_drain"
buffer. Why is that ?

WARNING - [Model] GTL has no description of the buffer's high state
         DC drive characteristics (no [Pullup] table).  This warning
         can be silenced by changing the Model_type or by adding a
         [Pullup] table.

- -Syed

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

Date: Mon, 24 Sep 2001 10:38:35 -0700
From: "Matthew Flora" <[email-masked]>
Subject: Re: ibischk3 and Open Drain

Hi Syed,

That bug was fixed some time ago.  Grab a copy of ibischk3 ver 3.2.7 from the
EIA IBIS page and the problem should go away.

Cheers,
Matthew Flora

- ----- Original Message -----
From: "Syed Huq" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 24, 2001 9:38 AM
Subject: ibischk3 and Open Drain

> For ibischk3 ver 3.2.6, it looks for the Pullup table for a "I/O_open_drain"
> buffer. Why is that ?
>
> WARNING - [Model] GTL has no description of the buffer's high state
>          DC drive characteristics (no [Pullup] table).  This warning
>          can be silenced by changing the Model_type or by adding a
>          [Pullup] table.
>
> -Syed
>

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

Date: Mon, 24 Sep 2001 14:37:47 -0700 (PDT)
From: john austin <[email-masked]>
Subject: Re: Archives

Thank You.
- --- "Ross, Bob" <[email-masked]> wrote:
> John:
> 
> Current email archives are available under:
> 
>   http://www.eda.org/pub/ibis/users_archive
> 
> and
> 
>   http://www.eda.org/pub/ibis/email_archive
> 
> 
> Older email archives since 1993 for the IBIS
> reflector and ibis-users reflectors are under:
> 
>   http://www.eda.org/pub/ibis/email/
> 
> Bob Ross
> Mentor Graphics
> 
>   
> 
> 
> john austin wrote:
> > 
> > Is there archives for the questions and responses
> of
> > this list?
> > 
> > Thanks
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Get email alerts & NEW webcam video instant
> messaging with Yahoo!
> Messenger. http://im.yahoo.com
> 

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

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

Date: Tue, 25 Sep 2001 18:15:30 -0400
From: "Todd Westerhoff" <[email-masked]>
Subject: RE: Duty Cycle

Dave, et al.,

Well, now I realize my comment was out of context, as I was referring to
IBIS as-is-in-current-practice, instead of IBIS as-it-would-be with BIRD
68.1.  I can see that BIRD 68.1 would allow IBIS models to do a better job
of predicting ISI caused by duty cycle assymetry in the driver.

If I'm reading the BIRD correctly, this is a modeling issue, and not a tool
issue, correct?  It seems to me there are no tool changes required,
providing the SI tools do not "alter" the V/T data in the IBIS waveforms
prior to their use.
If that were the case, it would seem to me that we could start producing
models to the updated spec immediately.

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Monday, September 24, 2001 12:14 PM
To: 'Jon Powell'; Lorang, David D
Cc: [email-masked]
Subject: RE: Duty Cycle

Jon,

I'm not sure I understand what you are disagreeing with, but let me take
another shot an see if I can clear things up a little more.   Please
understand that although originally it wasn't clear in IBIS how the timing
between rising and falling edges were related, BIRD 68.1 was written to
clarify that some information could be conveyed in the IBIS file regarding
the relationship between rising and falling edges (Rising vs. falling edge
timing will affect the duty cycle of a periodic waveform.)  So before BIRD
68.1, it was no surprise that simulation engines interpreted the waveform
data in a variety of ways.  Even now that BIRD 68.1 is approved, it is
probably safe to say that simulation engines still interpret the waveform
data in a variety of ways. Any changes that do happen won't occur overnight.
Hence IBIS, even with BIRD 68.1 applied, cannot guarantee that, for example,
the duty cycle of a waveform will come out as expected, (i.e. matching what
is happening in the silicon.)  It is likely that the waveform timings will
often still need to be "manually" adjusted, and there are tools in at least
some simulation engines to do that.

What BIRD 68.1 does do is to specify that the relative timing information
will be there in the IBIS file, so that simulation engine developers at
least have a chance (in a specified, and perhaps more automated manner) to
eventually maintain timing relationships between rising and falling edges.
So now, at least, the hooks are there.

Dave Lorang

- -----Original Message-----
From: Jon Powell [mailto:[email-masked]]
Sent: Saturday, September 22, 2001 9:01 AM
To: 'Lorang, David D'
Cc: [email-masked]
Subject: RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Tue, 25 Sep 2001 16:07:40 -0700
From: "Jeremy Plunkett" <[email-masked]>
Subject: RE: Duty Cycle

Todd,
I don't know the intentions of the authors of the IBIS spec, however there
are some simple choices in the process of generating an IBIS model and using
the data that will guarantee that duty cycle will be preserved.  This has
been the case with IBIS models that I have developed myself and compared to
the original spice netlist using the hspice B element(barring other
simulation errors and B-element bugs, that is).

At the time the original IBIS spec was defined, Tco differences between
rising and falling edges were a small fraction of the data bit cell width,
so many tools may have been sloppy(relative to our current requirements) in
their implementation and traded off accurate preservation of rise-fall
timing in order to make the model smaller or simpler to process.  Whatever
the reason, these implementations cause problems today--if the duty cycle
information is not accurately preserved in the IBIS model, then the user is
required to manually adjust the duty cycle based on part specs in order to
have the correct duty cycle in simulation(as you mention below).  Since the
duty cycle error if this is not done affects the waveforms and their
accuracy with respect to ISI/crosstalk but does not cause any blatant timing
violation (due to the use of time-to-Vm adjustment), it is likely to be
missed by users unless it is visually obvious when looking at the waveforms.

It would be a very good thing for makers of SI tools to see what they can do
to preserve the rise-fall relationships present in the IBIS model Vt
waveforms(per bird 68.1).  Also, anyone generating IBIS models today should
be sure to generate all Vt curves off of the same internal clock edge if
they don't do so already, and if they remove any portion of the curves do it
to all curves equally.

regards,
Jeremy Plunkett
Signal Integrity Engineer
ServerWorks Corporation
[email-masked]

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Todd Westerhoff
Sent: Monday, September 24, 2001 9:46 AM
To: [email-masked]
Subject: RE: Duty Cycle

I agree with Jon.  IBIS models are not meant, by default, to represent a
device's duty cycle.  You can get the model to produce the correct behavior
if you're careful with your modeling - but the tools typically used to
create IBIS models will not automatically produce a model that reflects the
device's duty cycle.

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Monday, September 24, 2001 9:54 AM
To: Jon Powell
Cc: [email-masked]
Subject: RE: Duty Cycle

hmmm...  OK, here is another two cents, but I do not believe it disagrees
with the previous remarks.

I have found through experience that the raw rising and falling waveform
data does not in itself represent correct duty cycle.  Instead this data
must be modified to 'fit' the devices actual duty cycle.  One can modify
the R/F V-t data in a number of ways including editing the delay region (
before the rising and falling edges occur ) to fit duty cycles at specific
frequencies found thorough laboratory measurement.  Since duty cycle can
vary over frequency I have found it best to leave R/F V-t data in it's raw
state, and with R and F relative to each other as David described.

Here is an example with HSPICE that illustrates that the raw R/F V-t data
itself does not represent correct duty cycle.  One has R/F V-t data through
HSPICE simulation and has included this data in an IBIS datasheet.  Then
this IBIS datasheet is used in  HSPICE simulation comparing it to the
original HSPICE sims used to generate the IBIS datasheet.  I have found
through experience that the duty cycles of the simulated IBIS datasheet
will not be the same as the duty cycles of the HSPICE model of the device,
especially as frequency varies.  Like Jon said, simulator vendors have
their own algorithms to process R/F V-t data in order to form a desired
duty cycle.

Adam Tambone

"Jon Powell" <[email-masked]>@eda.org on 09/22/2001 12:01:24 PM

Sent by:  [email-masked]

To:   "'Lorang, David D'" <[email-masked]>
cc:   <[email-masked]>

Subject:  RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run
two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer
delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same
way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you
would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you
correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Wed, 26 Sep 2001 14:21:17 -0700
From: "Jon Powell" <[email-masked]>
Subject: RE: Duty Cycle

Are we really talking "Duty Cycle" here or is this really a difference of
internal delay between rising and falling signals.

example:
We have a simple clock buffer.
The data takes longer go through the buffer on 0-1 than on 1-0

is that what we are talking about?
(if not, please give real example)
jon

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jeremy Plunkett
Sent: Tuesday, September 25, 2001 4:08 PM
To: 'Todd Westerhoff'; [email-masked]
Subject: RE: Duty Cycle

Todd,
I don't know the intentions of the authors of the IBIS spec, however there
are some simple choices in the process of generating an IBIS model and using
the data that will guarantee that duty cycle will be preserved.  This has
been the case with IBIS models that I have developed myself and compared to
the original spice netlist using the hspice B element(barring other
simulation errors and B-element bugs, that is).

At the time the original IBIS spec was defined, Tco differences between
rising and falling edges were a small fraction of the data bit cell width,
so many tools may have been sloppy(relative to our current requirements) in
their implementation and traded off accurate preservation of rise-fall
timing in order to make the model smaller or simpler to process.  Whatever
the reason, these implementations cause problems today--if the duty cycle
information is not accurately preserved in the IBIS model, then the user is
required to manually adjust the duty cycle based on part specs in order to
have the correct duty cycle in simulation(as you mention below).  Since the
duty cycle error if this is not done affects the waveforms and their
accuracy with respect to ISI/crosstalk but does not cause any blatant timing
violation (due to the use of time-to-Vm adjustment), it is likely to be
missed by users unless it is visually obvious when looking at the waveforms.

It would be a very good thing for makers of SI tools to see what they can do
to preserve the rise-fall relationships present in the IBIS model Vt
waveforms(per bird 68.1).  Also, anyone generating IBIS models today should
be sure to generate all Vt curves off of the same internal clock edge if
they don't do so already, and if they remove any portion of the curves do it
to all curves equally.

regards,
Jeremy Plunkett
Signal Integrity Engineer
ServerWorks Corporation
[email-masked]

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Todd Westerhoff
Sent: Monday, September 24, 2001 9:46 AM
To: [email-masked]
Subject: RE: Duty Cycle

I agree with Jon.  IBIS models are not meant, by default, to represent a
device's duty cycle.  You can get the model to produce the correct behavior
if you're careful with your modeling - but the tools typically used to
create IBIS models will not automatically produce a model that reflects the
device's duty cycle.

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Monday, September 24, 2001 9:54 AM
To: Jon Powell
Cc: [email-masked]
Subject: RE: Duty Cycle

hmmm...  OK, here is another two cents, but I do not believe it disagrees
with the previous remarks.

I have found through experience that the raw rising and falling waveform
data does not in itself represent correct duty cycle.  Instead this data
must be modified to 'fit' the devices actual duty cycle.  One can modify
the R/F V-t data in a number of ways including editing the delay region (
before the rising and falling edges occur ) to fit duty cycles at specific
frequencies found thorough laboratory measurement.  Since duty cycle can
vary over frequency I have found it best to leave R/F V-t data in it's raw
state, and with R and F relative to each other as David described.

Here is an example with HSPICE that illustrates that the raw R/F V-t data
itself does not represent correct duty cycle.  One has R/F V-t data through
HSPICE simulation and has included this data in an IBIS datasheet.  Then
this IBIS datasheet is used in  HSPICE simulation comparing it to the
original HSPICE sims used to generate the IBIS datasheet.  I have found
through experience that the duty cycles of the simulated IBIS datasheet
will not be the same as the duty cycles of the HSPICE model of the device,
especially as frequency varies.  Like Jon said, simulator vendors have
their own algorithms to process R/F V-t data in order to form a desired
duty cycle.

Adam Tambone

"Jon Powell" <[email-masked]>@eda.org on 09/22/2001 12:01:24 PM

Sent by:  [email-masked]

To:   "'Lorang, David D'" <[email-masked]>
cc:   <[email-masked]>

Subject:  RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run
two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer
delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same
way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you
would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you
correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Wed, 26 Sep 2001 15:51:03 -0400
From: "Todd Westerhoff" <[email-masked]>
Subject: RE: Duty Cycle

Jon,

I think the answer here is: yes and no.  Yes, because we want to model the
effect of the differing prop delays on the output, and no, because we're not
trying to be able to explicitly isolate the delay through the output buffer.

The BIRD talks about being able to correctly predict ISI - and that's just
what I took away from it.  If the IBIS model won't correctly predict the
percentages of time the signal spends high and low in a cycle - then doing
any kind of random data / eye diagram analysis is pointless.  We find that
kind of analysis very useful, and want to be able to interchange IBIS and
HSpice modeling with consistent results.  If the model doesn't follow the
points outlined in BIRD 68.1, then it seems unlikely that the two sets of
results would correlate.

Make sense?

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: Jon Powell [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 5:21 PM
To: 'Jeremy Plunkett'; 'Todd Westerhoff'; [email-masked]
Subject: RE: Duty Cycle

Are we really talking "Duty Cycle" here or is this really a difference of
internal delay between rising and falling signals.

example:
We have a simple clock buffer.
The data takes longer go through the buffer on 0-1 than on 1-0

is that what we are talking about?
(if not, please give real example)
jon

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jeremy Plunkett
Sent: Tuesday, September 25, 2001 4:08 PM
To: 'Todd Westerhoff'; [email-masked]
Subject: RE: Duty Cycle

Todd,
I don't know the intentions of the authors of the IBIS spec, however there
are some simple choices in the process of generating an IBIS model and using
the data that will guarantee that duty cycle will be preserved.  This has
been the case with IBIS models that I have developed myself and compared to
the original spice netlist using the hspice B element(barring other
simulation errors and B-element bugs, that is).

At the time the original IBIS spec was defined, Tco differences between
rising and falling edges were a small fraction of the data bit cell width,
so many tools may have been sloppy(relative to our current requirements) in
their implementation and traded off accurate preservation of rise-fall
timing in order to make the model smaller or simpler to process.  Whatever
the reason, these implementations cause problems today--if the duty cycle
information is not accurately preserved in the IBIS model, then the user is
required to manually adjust the duty cycle based on part specs in order to
have the correct duty cycle in simulation(as you mention below).  Since the
duty cycle error if this is not done affects the waveforms and their
accuracy with respect to ISI/crosstalk but does not cause any blatant timing
violation (due to the use of time-to-Vm adjustment), it is likely to be
missed by users unless it is visually obvious when looking at the waveforms.

It would be a very good thing for makers of SI tools to see what they can do
to preserve the rise-fall relationships present in the IBIS model Vt
waveforms(per bird 68.1).  Also, anyone generating IBIS models today should
be sure to generate all Vt curves off of the same internal clock edge if
they don't do so already, and if they remove any portion of the curves do it
to all curves equally.

regards,
Jeremy Plunkett
Signal Integrity Engineer
ServerWorks Corporation
[email-masked]

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Todd Westerhoff
Sent: Monday, September 24, 2001 9:46 AM
To: [email-masked]
Subject: RE: Duty Cycle

I agree with Jon.  IBIS models are not meant, by default, to represent a
device's duty cycle.  You can get the model to produce the correct behavior
if you're careful with your modeling - but the tools typically used to
create IBIS models will not automatically produce a model that reflects the
device's duty cycle.

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Monday, September 24, 2001 9:54 AM
To: Jon Powell
Cc: [email-masked]
Subject: RE: Duty Cycle

hmmm...  OK, here is another two cents, but I do not believe it disagrees
with the previous remarks.

I have found through experience that the raw rising and falling waveform
data does not in itself represent correct duty cycle.  Instead this data
must be modified to 'fit' the devices actual duty cycle.  One can modify
the R/F V-t data in a number of ways including editing the delay region (
before the rising and falling edges occur ) to fit duty cycles at specific
frequencies found thorough laboratory measurement.  Since duty cycle can
vary over frequency I have found it best to leave R/F V-t data in it's raw
state, and with R and F relative to each other as David described.

Here is an example with HSPICE that illustrates that the raw R/F V-t data
itself does not represent correct duty cycle.  One has R/F V-t data through
HSPICE simulation and has included this data in an IBIS datasheet.  Then
this IBIS datasheet is used in  HSPICE simulation comparing it to the
original HSPICE sims used to generate the IBIS datasheet.  I have found
through experience that the duty cycles of the simulated IBIS datasheet
will not be the same as the duty cycles of the HSPICE model of the device,
especially as frequency varies.  Like Jon said, simulator vendors have
their own algorithms to process R/F V-t data in order to form a desired
duty cycle.

Adam Tambone

"Jon Powell" <[email-masked]>@eda.org on 09/22/2001 12:01:24 PM

Sent by:  [email-masked]

To:   "'Lorang, David D'" <[email-masked]>
cc:   <[email-masked]>

Subject:  RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run
two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer
delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same
way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you
would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you
correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Wed, 26 Sep 2001 11:13:34 -0700
From: "Muranyi, Arpad" <[email-masked]>
Subject: Thank you messages?

While it is a nice gesture to thank someone for the response
they wrote, it is also annoying to have to open a bunch of
meaningless messages on these reflectors (which are quite
active already as it is).

I would suggest that if someone really wants to say thanks for
the answers they got they should ONLY send it to the person
they got it from.  This could reduce unnecessary network traffic
and could save some time for the rest of us...

Thanks,

Arpad Muranyi
Itel Corporation
================================================================

- -----Original Message-----
From: john austin [mailto:[email-masked]]
Sent: Monday, September 24, 2001 2:38 PM
To: Ross, Bob
Cc: [email-masked]; [email-masked]
Subject: Re: Archives

Thank You.
- --- "Ross, Bob" <[email-masked]> wrote:
> John:
> 
> Current email archives are available under:
> 
>   http://www.eda.org/pub/ibis/users_archive
> 
> and
> 
>   http://www.eda.org/pub/ibis/email_archive
> 
> 
> Older email archives since 1993 for the IBIS
> reflector and ibis-users reflectors are under:
> 
>   http://www.eda.org/pub/ibis/email/
> 
> Bob Ross
> Mentor Graphics

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

Date: Wed, 26 Sep 2001 16:46:04 -0700
From: "Jeremy Plunkett" <[email-masked]>
Subject: RE: Duty Cycle

Well said, Todd.

I would just like to add that even without bird 68.1, the default method of
generating IBIS data from a spice netlist will in most cases produce Vt
curves with accurate rising and falling Tco delays included.  However, the
person formatting the data into the model and the simulation tool using the
model must both be conscientious in doing all editing/removal of time points
on all curves together to maintain the rising/falling relationship.  This
has not been the case for many models and simulation tools to date, but it
isn't difficult.

In answer to Jon's original question, in the typical situations where I use
IBIS models, it's the same thing--the duty cycle of the signal(at the driver
output pad) is determined by the difference in output delay on rising and
falling transitions.  This is because the internal logic for most
source-synchronous busses uses one edge of a clock at 2x the bus frequency
to generate the output transitions.

Regards,
Jeremy

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Todd Westerhoff
Sent: Wednesday, September 26, 2001 12:51 PM
To: [email-masked]
Subject: RE: Duty Cycle

Jon,

I think the answer here is: yes and no.  Yes, because we want to model the
effect of the differing prop delays on the output, and no, because we're not
trying to be able to explicitly isolate the delay through the output buffer.

The BIRD talks about being able to correctly predict ISI - and that's just
what I took away from it.  If the IBIS model won't correctly predict the
percentages of time the signal spends high and low in a cycle - then doing
any kind of random data / eye diagram analysis is pointless.  We find that
kind of analysis very useful, and want to be able to interchange IBIS and
HSpice modeling with consistent results.  If the model doesn't follow the
points outlined in BIRD 68.1, then it seems unlikely that the two sets of
results would correlate.

Make sense?

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: Jon Powell [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 5:21 PM
To: 'Jeremy Plunkett'; 'Todd Westerhoff'; [email-masked]
Subject: RE: Duty Cycle

Are we really talking "Duty Cycle" here or is this really a difference of
internal delay between rising and falling signals.

example:
We have a simple clock buffer.
The data takes longer go through the buffer on 0-1 than on 1-0

is that what we are talking about?
(if not, please give real example)
jon

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jeremy Plunkett
Sent: Tuesday, September 25, 2001 4:08 PM
To: 'Todd Westerhoff'; [email-masked]
Subject: RE: Duty Cycle

Todd,
I don't know the intentions of the authors of the IBIS spec, however there
are some simple choices in the process of generating an IBIS model and using
the data that will guarantee that duty cycle will be preserved.  This has
been the case with IBIS models that I have developed myself and compared to
the original spice netlist using the hspice B element(barring other
simulation errors and B-element bugs, that is).

At the time the original IBIS spec was defined, Tco differences between
rising and falling edges were a small fraction of the data bit cell width,
so many tools may have been sloppy(relative to our current requirements) in
their implementation and traded off accurate preservation of rise-fall
timing in order to make the model smaller or simpler to process.  Whatever
the reason, these implementations cause problems today--if the duty cycle
information is not accurately preserved in the IBIS model, then the user is
required to manually adjust the duty cycle based on part specs in order to
have the correct duty cycle in simulation(as you mention below).  Since the
duty cycle error if this is not done affects the waveforms and their
accuracy with respect to ISI/crosstalk but does not cause any blatant timing
violation (due to the use of time-to-Vm adjustment), it is likely to be
missed by users unless it is visually obvious when looking at the waveforms.

It would be a very good thing for makers of SI tools to see what they can do
to preserve the rise-fall relationships present in the IBIS model Vt
waveforms(per bird 68.1).  Also, anyone generating IBIS models today should
be sure to generate all Vt curves off of the same internal clock edge if
they don't do so already, and if they remove any portion of the curves do it
to all curves equally.

regards,
Jeremy Plunkett
Signal Integrity Engineer
ServerWorks Corporation
[email-masked]

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Todd Westerhoff
Sent: Monday, September 24, 2001 9:46 AM
To: [email-masked]
Subject: RE: Duty Cycle

I agree with Jon.  IBIS models are not meant, by default, to represent a
device's duty cycle.  You can get the model to produce the correct behavior
if you're careful with your modeling - but the tools typically used to
create IBIS models will not automatically produce a model that reflects the
device's duty cycle.

Todd.

Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:[email-masked] - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- - John Mellencamp

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Monday, September 24, 2001 9:54 AM
To: Jon Powell
Cc: [email-masked]
Subject: RE: Duty Cycle

hmmm...  OK, here is another two cents, but I do not believe it disagrees
with the previous remarks.

I have found through experience that the raw rising and falling waveform
data does not in itself represent correct duty cycle.  Instead this data
must be modified to 'fit' the devices actual duty cycle.  One can modify
the R/F V-t data in a number of ways including editing the delay region (
before the rising and falling edges occur ) to fit duty cycles at specific
frequencies found thorough laboratory measurement.  Since duty cycle can
vary over frequency I have found it best to leave R/F V-t data in it's raw
state, and with R and F relative to each other as David described.

Here is an example with HSPICE that illustrates that the raw R/F V-t data
itself does not represent correct duty cycle.  One has R/F V-t data through
HSPICE simulation and has included this data in an IBIS datasheet.  Then
this IBIS datasheet is used in  HSPICE simulation comparing it to the
original HSPICE sims used to generate the IBIS datasheet.  I have found
through experience that the duty cycles of the simulated IBIS datasheet
will not be the same as the duty cycles of the HSPICE model of the device,
especially as frequency varies.  Like Jon said, simulator vendors have
their own algorithms to process R/F V-t data in order to form a desired
duty cycle.

Adam Tambone

"Jon Powell" <[email-masked]>@eda.org on 09/22/2001 12:01:24 PM

Sent by:  [email-masked]

To:   "'Lorang, David D'" <[email-masked]>
cc:   <[email-masked]>

Subject:  RE: Duty Cycle

I have to disagree.
This isn't how IBIS is defined and speifically isn't how most simulation
engines interpret the waveform data.

The Waveform data cannot be used to specify duty cycle, however, this is
an option in most native IBIS simulators and you should contact your
simulator vendor for specifics on implementing different duty cycles
for different clocks etc.

regards,
Jon Powell
Innoveda Consulting Services

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lorang, David D
Sent: Thursday, September 20, 2001 4:34 PM
To: 'tcoyle'
Cc: [email-masked]
Subject: RE: Duty Cycle

Tim,

I think you have it right.

Let's take the example of a clocked synchronous design where a chip has a
some clock input and a data output.  Suppose output data changes on every
rising clock edge.  You might have a specification for Tco delay of maybe
2ns, or whatever, for both rising edge and falling edge data.

Then suppose you are using a SPICE simulation of some buffer to generate
your voltage vs. time data to create an IBIS file.   You would might run
two
simulations each where the rising edge of the input clock starts at time
0ns: one for rising data, one for falling data.  The two simulations would
generate two output V-T tables that would have their rising and falling
edges correlated, because they both were timed from a clock starting at the
same time  (0 ns).   From the tabular output files, for those two sims you
could  create two IBIS V-T tables.

Where exactly the output edges occur is dependent on internal buffer
delays,
and that is not important, but where the two edges occur relative to each
other is important.  So you make sure you handle both tables in the same
way
when you import them into the IBIS file.  You may decide to eliminate the
internal buffer delay--commonly done to make sure that the tables contain
mostly edge data--and if you took 1.5ns out of the front of one VT table,
you would want to take the same amount out of the other.  All of this is
just to make sure that the IBIS file retains information concerning the
timing relationship between the two edges.   For this example so far I am
assuming only one load configuration, perhaps, a 50 Ohm resistor to ground.
For the other load configuration (resistor to supply), you would go through
the same steps again and observe the same precautions.  In the end you
would
have four V-T tables, with their waveforms all correlated.  So, in summary,
you need to correlate rising and falling edges in the same way you
correlate
the two load configurations.

Have I answered your question?

Dave Lorang

- -----Original Message-----
From: tcoyle [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 12:34 PM
To: [email-masked]
Subject: Duty Cycle

Dear List,
I have some questions regarding Bird 68.1 and duty cycle. I understand
that IBIS does not guarantee propogation delays,
but if the rising and falling waveform data is correlated then duty
cycle can be maintained. I'm not sure I understand how you
taking rising /falling data to ensure duty cycle? Is it a matter of
doing the same transient analysis for rising/falling edges?

Thank you for any information provided

Tim

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

Date: Sat, 29 Sep 2001 13:29:00 -0700 (PDT)
From: Mohanasankar Sivaprakasam <[email-masked]>
Subject: Some clarifications reg IBIS3.2

Hello,
I am Mohanasankar, student at North Carolina State
University.
Can some body help me with the following:

1.What is the difference between  Vinl/Vinh in [Model]
keyword and Vinl/Vinh in [Model Spec] keyword?

What different purposes do they serve?

2.I got confused with [Add Submodel]..
Is it a way of reusing models. that is using some
charcteristics of a model into another??

3.Are there any examples of models conforming to
IBIS3.2 Specifications which would cover all the
syntaxes??

Thanks for you cooperation.

Mohanasankar.

=====
"There are new problems to solve.
Engineers who can solve these problems will define the future"
Mohanasankar Sivaprakasam,
Research Assistant,
Electrical Engineering,
North Carolina State University,
Raleigh, NC,USA.

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

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

Date: Mon, 1 Oct 2001 17:08:43 -0700
From: [email-masked]
Subject: question about s2ibis2

Hi,
I used free software v2.1 s2ibis2 which download from
http://www.eigroup.org/ibis/ibis.htm. I create IBIS model for output_ECL. I
cannot get the right model.  I check the output list for pullup & pulldown,
DC sweep is from -2.2V to 0, this is correct. But in side of IBIS model, DC
sweep is from -0.14V to 0. Did anyone know what's wrong with it?
Thanks

Tina Liu
Semtech Corp.
858-547-6615

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

Date: Mon, 01 Oct 2001 17:50:56 -0700
From: Bob Ross <[email-masked]>
Subject: Re: Some clarifications reg IBIS3.2

Hello:

Some brief responses are in your text.

Bob Ross
Mentor Graphics

Mohanasankar Sivaprakasam wrote:
> 
> Hello,
> I am Mohanasankar, student at North Carolina State
> University.
> Can some body help me with the following:
> 
> 1.What is the difference between  Vinl/Vinh in [Model]
> keyword and Vinl/Vinh in [Model Spec] keyword?> 
> What different purposes do they serve?
> 

The [Model Spec] Vinh/l subparamters allow you to specify min
and max values that may change with [Voltage Range] or some
other reference voltage.  PECL technology is an example
where this would be important.  Vinh/l subparameter of
[Model] only allows fixed values over the entire range.

The [Model Spec] values always override the [Model]
subparameter specification.

> 2.I got confused with [Add Submodel]..
> Is it a way of reusing models. that is using some
> charcteristics of a model into another??

Some technologies add some functional details to
the buffer.  The [Add Submodel] and [Submodel]
keywords provide a way to "add" on some detail
that is of practical interest.

> 
> 3.Are there any examples of models conforming to
> IBIS3.2 Specifications which would cover all the
> syntaxes??

There exists some examples that demonostrate some
of the Version 3.2 syntax under

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

for subdirectories ver3.0 and above.

Bob Ross
Mentor Graphics

> 
> Thanks for you cooperation.
> 
> Mohanasankar.
> 
> =====
> "There are new problems to solve.
> Engineers who can solve these problems will define the future"
> Mohanasankar Sivaprakasam,
> Research Assistant,
> Electrical Engineering,
> North Carolina State University,
> Raleigh, NC,USA.
> 
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com

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

Date: Tue, 02 Oct 2001 17:13:34 +0100
From: "Peter Rowe" <[email-masked]>
Subject: request for info

- --------------24BC98E783DF34BAE10CD6DA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

HI,
    I'm looking to answer a basic question on IBIS  models. Please can
you tell me upto what frequencies IBIS models are useful?

Peter Rowe

- --------------24BC98E783DF34BAE10CD6DA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
HI,
<br>&nbsp;&nbsp;&nbsp; I'm looking to answer a basic question on IBIS&nbsp;
models. Please can you tell me upto what frequencies IBIS&nbsp;models are
useful?
<pre>Peter Rowe</pre>
&nbsp;</html>

- --------------24BC98E783DF34BAE10CD6DA--

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

Date: Tue, 2 Oct 2001 22:11:38 -0700 (PDT)
From: suresh np <[email-masked]>
Subject: Abt IBIS models........

Hi all
Pls find the below questions (or my doubts).
1) For which all devices, IBIS models are valid?  Is  
the IBIS model for a Analog to Digital converter 
valid? Is it applicable only for high speed IC's? 

2)Suppose i have a SPICE model for an IC. How I can
collect the datas for V/I and V/T curve? (i want to
know the circuit to collect data [pull up] [pull
down]....) .(in  *.dsn or *.opj format. I have orcad
in my system).(atleast a jpg file)

3) Can i simulate or test the IBIS model using 
Spectra  Quest?

Pls help out in these regards.
Thanks
Best Regards
- --Suresh

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

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

Date: Wed, 3 Oct 2001 08:48:38 -0700 
From: "Peters, Stephen" <[email-masked]>
Subject: RE: Abt IBIS models........

Hi Suresh:

  My answers are below.

  Regards,
  Stephen Peters
  Intel Corp.

- -----Original Message-----
From: suresh np [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 10:12 PM
To: [email-masked]
Subject: Abt IBIS models........

Hi all
Pls find the below questions (or my doubts).
1) For which all devices, IBIS models are valid?  Is  
the IBIS model for a Analog to Digital converter 
valid? Is it applicable only for high speed IC's? 

The data in an IBIS model is intended for modeling digital
output buffers (and digital input receivers).  You can
certainly build an IBIS model of an Analog to Digital 
converter, but the model would only represent the 
digital output portion of the device.

2)Suppose i have a SPICE model for an IC. How I can
collect the datas for V/I and V/T curve? (i want to
know the circuit to collect data [pull up] [pull
down]....) .(in  *.dsn or *.opj format. I have orcad
in my system).(atleast a jpg file)

The IBIS cookbook explains how to extract V/I and V/T curves 
from a spice model.  The cookbook is available from the 
IBIS website in the tools area:

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

The s2ibis (spice to ibis) program is also available.

3) Can i simulate or test the IBIS model using 
Spectra  Quest?

  Yes.  Contact your EDA vendor for more details.

Pls help out in these regards.
Thanks
Best Regards
- --Suresh

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

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

Date: Wed, 3 Oct 2001 12:56:32 -0700
From: [email-masked]
Subject: Did anyone familiar with s2ibis2?

Hi All,
Did anyone know how to use s2ibis2? I create .s2i file and .sp file. After
ran s2ibis2, I got .spi, .msg and .out files. The data in .out files looked
good, but model didn't show up the same DCsweep range on pullup & pulldown
curves. s2ibis  I used is free software download from web. Do we have any
other updated version to help solve this problem?

Thanks for any help

Tina Liu

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

Date: Wed, 3 Oct 2001 14:09:22 -0700 (PDT)
From: Syed Huq <[email-masked]>
Subject: Re: Did anyone familiar with s2ibis2?

Tina,

You need to share your .out file and .ibs as well as our .spi files before any 
conclusion can be drawn.

I am assuming you are using the s2ibis2_fix version. This is the most current 
version.

I would be more than happy to provide some inputs..

Syed
Cisco Systems, Inc

> Subject: Did anyone familiar with s2ibis2?
> To: [email-masked]
> From: [email-masked]
> Date: Wed, 3 Oct 2001 12:56:32 -0700
> X-MIMETrack: Serialize by Router on Mail/SMTC(Release 5.0.6a |January 17, 
2001) at 10/03/2001 01:01:04 PM
> MIME-Version: 1.0
> 
> Hi All,
> Did anyone know how to use s2ibis2? I create .s2i file and .sp file. After
> ran s2ibis2, I got .spi, .msg and .out files. The data in .out files looked
> good, but model didn't show up the same DCsweep range on pullup & pulldown
> curves. s2ibis  I used is free software download from web. Do we have any
> other updated version to help solve this problem?
> 
> Thanks for any help
> 
> Tina Liu
> 
> 

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

Date: Sun, 7 Oct 2001 17:47:14 -0700
From: [email-masked]
Subject: Can anyone help me out those questions?

Hi All,

I got some replies regarding the questions I put to ibis-user last week.
I tried them all, but I still have the following questions.

The circuit I'm working on is Bipolar process, high voltage with power
supply VCC and VEE.

1. After I ran s2ibis2, I got .spi, .out and IBIS model. But model didn't
create the right table for pullup and pulldown curves. I checked
puxx.out & pdxx.out, they looked good. Do you know why the table in the
model is scrued up?

2. Sometimes I ran s2ibis2, I couldn't get model generated after all
simulations were completed. It show me "BUS ERROR (core dumped)". Do you
know what can cause this problem? I think it's not memory issue
since I was runing the simulation in a machine with 1G memory.

3. How differential pin works? I defined [Diff Pin], but when I ran
s2ibis2, I cannot see diff pin is set to any value, is it floating?

Any reply will be appreciated.

Tina Liu
Semtech Corp.
858-547-6615

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

Date: Thu, 11 Oct 2001 17:02:41 -0600
From: Yan Tang <[email-masked]>
Subject: Non-monotonic IBIS data

Hello,

I am trying to figure out what the following 
warning message meant after I ran the IBIS 
validation check using HyperLynx visual IBIS
editor.

"WARNING (line  538) - Pulldown Minimum data is non-monotonic"

Although the file passed, I am wondering if such
a warning had any effect on the modeling result.

Your help is greatly appreciated. Thanks in advance.

Regards,

Yanny

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

Date: Thu, 18 Oct 2001 15:09:52 -0500
From: Brian Young <[email-masked]>
Subject: ibischk3 problems

Hello,

I am getting errors from ibischk3, but I can't figure out what
the problem is.  The IBIS file was generated by a methodology in
development, so there are lots of little problems.  Right now,
there are also big problems:

IBISCHK3 V3.2.7

Checking test.ibs for IBIS 2.1 Compatibility...

ERROR - Model mod.A35_2.5V: The [Rising Waveform] 
      with [R_fixture]=50 Ohms and [V_fixture]=2.5V
      has TYP column DC endpoints of  1.15V and  2.45v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 2.52V and  2.50V),
      a difference of 54.34% and  1.87%, respectively.
ERROR - Model mod.A35_2.5V: The [Rising Waveform] 
      with [R_fixture]=50 Ohms and [V_fixture]=0V
      has TYP column DC endpoints of  0.00V and  1.20v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.43V and  1.38V),
      a difference of 100.00% and 13.05%, respectively.
ERROR - Model mod.A35_2.5V: The [Falling Waveform] 
      with [R_fixture]=50 Ohms and [V_fixture]=2.5V
      has TYP column DC endpoints of  1.25V and  2.50v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 2.52V and  2.50V),
      a difference of 50.37% and  0.13%, respectively.
ERROR - Model mod.A35_2.5V: The [Falling Waveform] 
      with [R_fixture]=50 Ohms and [V_fixture]=0V
      has TYP column DC endpoints of  0.05V and  1.35v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.43V and  1.38V),
      a difference of 96.51% and  2.18%, respectively.

Errors  : 4

File Failed

Take for example the first error.  Before the start of the rising edge,
the NFET is holding the voltage low.  I can find the holding low voltage
by finding the point on the PULLDOWN IV curve where 2.5V=V+50*I.  Using
the IV curve entry 1.10 27.69m, I find the voltage to be 1.1V.  From the
[Rising Waveform], R_fixture = 50, V_fixture = 2.500 curve, I get the
starting voltage as 1.15V.  That looks like a match to me, but ibischk3
comes up with an error and different numbers.

Can someone ID the problem with these errors?

Thanks,
Brian

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

[ibiS ver] 2.1
[File Name] test.ibs
[File Rev] 2.0
[Date] date
[Source] rev x.x
[Copyright] test
[Component] test1
[Manufacturer] Motorola
[Package]
R_pkg 1m NA NA
L_pkg 1p NA NA
C_pkg 1f NA NA
[Pin] signal_name    model_name
|
D9    A35            mod.A35_2.5V

[Model] mod.A35_2.5V
Model_type I/O
Polarity Non-Inverting
Enable Active-High
Vinh = 1.23V
Vinl = 1.21V
Cref = 0
Rref = 0
Vref = 0
C_comp 4p 3p 6p
[Temperature Range] 27 NA NA
[Pullup Reference] 2.5V NA NA
[Pulldown Reference] 2.5V NA NA
[Power Clamp Reference] 2.5V NA NA
[GND Clamp Reference] 0.0V NA NA

[Ramp]
|variable typ           min      max
 dV/dt_r  0.75/0.24n     NA       NA
 dV/dt_f  0.75/0.09n     NA       NA

[Rising Waveform]
R_fixture = 50
V_fixture = 2.500
C_fixture = 0p
L_fixture = 0n
C_dut = 0p
R_dut = 0m
L_dut = 0n
|Time      V(typ)    V(min)    V(max)
  1.45ns    1.15V      NA        NA
  1.46ns    1.20V      NA        NA
  1.47ns    1.95V      NA        NA
  1.49ns    2.00V      NA        NA
  1.51ns    2.05V      NA        NA
  1.52ns    2.10V      NA        NA
  1.54ns    2.15V      NA        NA
  1.57ns    2.20V      NA        NA
  1.60ns    2.25V      NA        NA
  1.64ns    2.30V      NA        NA
  1.75ns    2.35V      NA        NA
  2.57ns    2.40V      NA        NA
  8.05ns    2.45V      NA        NA

[Falling Waveform]
R_fixture = 50
V_fixture = 2.500
C_fixture = 0p
L_fixture = 0n
C_dut = 0p
R_dut = 0m
L_dut = 0n
|Time      V(typ)    V(min)    V(max)
  1.54ns    2.50V      NA        NA
  1.57ns    1.80V      NA        NA
  1.67ns    1.75V      NA        NA
  1.76ns    1.70V      NA        NA
  1.84ns    1.65V      NA        NA
  1.89ns    1.60V      NA        NA
  1.92ns    1.55V      NA        NA
  1.95ns    1.50V      NA        NA
  1.98ns    1.45V      NA        NA
  2.03ns    1.40V      NA        NA
  2.07ns    1.35V      NA        NA
  2.13ns    1.30V      NA        NA
  2.22ns    1.25V      NA        NA

[Rising Waveform]
R_fixture = 50
V_fixture = 0
C_fixture = 0p
L_fixture = 0n
C_dut = 0p
R_dut = 0m
L_dut = 0n
|Time      V(typ)    V(min)    V(max)
  1.47ns    0.00V      NA        NA
  1.49ns    0.70V      NA        NA
  1.51ns    0.75V      NA        NA
  1.54ns    0.80V      NA        NA
  1.56ns    0.85V      NA        NA
  1.60ns    0.90V      NA        NA
  1.64ns    0.95V      NA        NA
  1.72ns    1.00V      NA        NA
  1.85ns    1.05V      NA        NA
  2.16ns    1.10V      NA        NA
  2.38ns    1.15V      NA        NA
  2.69ns    1.20V      NA        NA

[Falling Waveform]
R_fixture = 50
V_fixture = 0
C_fixture = 0p
L_fixture = 0n
C_dut = 0p
R_dut = 0m
L_dut = 0n
|Time      V(typ)    V(min)    V(max)
  1.78ns    1.35V      NA        NA
  1.79ns    0.80V      NA        NA
  1.82ns    0.60V      NA        NA
  1.86ns    0.55V      NA        NA
  1.90ns    0.50V      NA        NA
  1.93ns    0.45V      NA        NA
  1.96ns    0.40V      NA        NA
  2.00ns    0.35V      NA        NA
  2.04ns    0.30V      NA        NA
  2.10ns    0.25V      NA        NA
  2.17ns    0.20V      NA        NA
  2.30ns    0.15V      NA        NA
  3.17ns    0.10V      NA        NA
  8.77ns    0.05V      NA        NA

[Pulldown]
|Voltage    I(typ)   I(min)   I(max)
- -0.60V    -17.34m     NA       NA
- -0.55V    -16.16m     NA       NA
- -0.50V    -14.83m     NA       NA
- -0.45V    -13.48m     NA       NA
- -0.40V    -12.14m     NA       NA
- -0.35V    -10.78m     NA       NA
- -0.30V     -9.38m     NA       NA
- -0.25V     -7.99m     NA       NA
- -0.20V     -6.55m     NA       NA
- -0.15V     -5.17m     NA       NA
- -0.10V     -3.74m     NA       NA
- -0.05V     -2.24m     NA       NA
 0.00V     -0.89m     NA       NA
 0.05V      0.57m     NA       NA
 0.10V      2.05m     NA       NA
 0.15V      3.42m     NA       NA
 0.20V      4.89m     NA       NA
 0.25V      6.31m     NA       NA
 0.30V      7.66m     NA       NA
 0.35V      9.08m     NA       NA
 0.40V     10.46m     NA       NA
 0.45V     11.87m     NA       NA
 0.50V     13.16m     NA       NA
 0.55V     14.50m     NA       NA
 0.60V     15.83m     NA       NA
 0.65V     17.06m     NA       NA
 0.70V     18.42m     NA       NA
 0.75V     19.64m     NA       NA
 0.80V     20.86m     NA       NA
 0.85V     22.04m     NA       NA
 0.90V     23.22m     NA       NA
 0.95V     24.39m     NA       NA
 1.00V     25.54m     NA       NA
 1.05V     26.60m     NA       NA
 1.10V     27.69m     NA       NA
 1.15V     28.75m     NA       NA
 1.20V     29.73m     NA       NA
 1.25V     30.75m     NA       NA
 1.30V     31.71m     NA       NA
 1.35V     32.66m     NA       NA
 1.40V     33.56m     NA       NA
 1.45V     34.46m     NA       NA
 1.50V     35.33m     NA       NA
 1.55V     36.15m     NA       NA
 1.60V     36.95m     NA       NA
 1.65V     37.76m     NA       NA
 1.70V     38.48m     NA       NA
 1.75V     39.22m     NA       NA
 1.80V     39.94m     NA       NA
 1.85V     40.63m     NA       NA
 1.90V     41.29m     NA       NA
 1.95V     41.91m     NA       NA
 2.00V     42.53m     NA       NA
 2.05V     43.10m     NA       NA
 2.10V     43.69m     NA       NA
 2.15V     44.22m     NA       NA
 2.20V     44.71m     NA       NA
 2.25V     45.21m     NA       NA
 2.30V     45.63m     NA       NA
 2.35V     46.07m     NA       NA
 2.40V     46.48m     NA       NA
 2.45V     46.86m     NA       NA
 2.50V     47.20m     NA       NA
 2.55V     47.52m     NA       NA
 2.60V     47.82m     NA       NA
 2.65V     48.11m     NA       NA
 2.70V     48.38m     NA       NA
 2.75V     48.63m     NA       NA
 2.80V     48.95m     NA       NA
 2.85V     49.38m     NA       NA
 2.90V     49.78m     NA       NA
 2.95V     49.78m     NA       NA
 3.00V     49.78m     NA       NA
 3.05V     49.78m     NA       NA
 3.10V     49.78m     NA       NA

[Pullup]
|Voltage    I(typ)   I(min)   I(max)
 3.10V    -47.76m     NA       NA
 3.05V    -47.50m     NA       NA
 3.00V    -47.27m     NA       NA
 2.95V    -46.99m     NA       NA
 2.90V    -46.73m     NA       NA
 2.85V    -46.46m     NA       NA
 2.80V    -46.18m     NA       NA
 2.75V    -45.89m     NA       NA
 2.70V    -45.59m     NA       NA
 2.65V    -45.31m     NA       NA
 2.60V    -44.99m     NA       NA
 2.55V    -44.69m     NA       NA
 2.50V    -44.38m     NA       NA
 2.45V    -44.03m     NA       NA
 2.40V    -43.66m     NA       NA
 2.35V    -43.31m     NA       NA
 2.30V    -42.91m     NA       NA
 2.25V    -42.50m     NA       NA
 2.20V    -42.06m     NA       NA
 2.15V    -41.59m     NA       NA
 2.10V    -41.10m     NA       NA
 2.05V    -40.57m     NA       NA
 2.00V    -40.04m     NA       NA
 1.95V    -39.46m     NA       NA
 1.90V    -38.82m     NA       NA
 1.85V    -38.21m     NA       NA
 1.80V    -37.51m     NA       NA
 1.75V    -36.82m     NA       NA
 1.70V    -36.07m     NA       NA
 1.65V    -35.33m     NA       NA
 1.60V    -34.55m     NA       NA
 1.55V    -33.73m     NA       NA
| 1.50V    -32.88m     NA       NA
 1.45V    -32.08m     NA       NA
| 1.40V    -31.27m     NA       NA
 1.35V    -30.42m     NA       NA
| 1.30V    -30.80m     NA       NA
 1.25V    -29.87m     NA       NA
| 1.20V    -28.94m     NA       NA
 1.15V    -27.96m     NA       NA
| 1.10V    -26.99m     NA       NA
 1.05V    -25.92m     NA       NA
| 1.00V    -24.89m     NA       NA
 0.95V    -23.89m     NA       NA
| 0.90V    -22.83m     NA       NA
 0.85V    -21.66m     NA       NA
| 0.80V    -20.50m     NA       NA
 0.75V    -19.33m     NA       NA
 0.70V    -18.14m     NA       NA
 0.65V    -17.00m     NA       NA
 0.60V    -15.75m     NA       NA
 0.55V    -14.53m     NA       NA
 0.50V    -13.26m     NA       NA
 0.45V    -12.00m     NA       NA
 0.40V    -10.61m     NA       NA
 0.35V     -9.30m     NA       NA
 0.30V     -7.99m     NA       NA
 0.25V     -6.63m     NA       NA
 0.20V     -5.32m     NA       NA
 0.15V     -3.93m     NA       NA
 0.10V     -2.54m     NA       NA
 0.05V     -1.16m     NA       NA
 0.00V      0.18m     NA       NA
- -0.05V      1.58m     NA       NA
- -0.10V      2.95m     NA       NA
- -0.15V      4.38m     NA       NA
- -0.20V      5.79m     NA       NA
- -0.25V      7.12m     NA       NA
- -0.30V      8.52m     NA       NA
- -0.35V     10.01m     NA       NA
- -0.40V     11.30m     NA       NA
- -0.45V     12.67m     NA       NA
- -0.50V     14.08m     NA       NA
- -0.55V     15.49m     NA       NA
- -0.60V     16.82m     NA       NA

[GND Clamp]
|Voltage    I(typ)   I(min)   I(max)
- -0.60V     -5.08m     NA       NA
- -0.55V     -4.04m     NA       NA
- -0.50V     -3.04m     NA       NA
- -0.45V     -2.12m     NA       NA
- -0.40V     -1.33m     NA       NA
- -0.35V     -0.71m     NA       NA
- -0.30V     -0.29m     NA       NA
- -0.25V     -0.10m     NA       NA
- -0.20V     -0.02m     NA       NA
- -0.15V     -0.02m     NA       NA
- -0.10V     -0.01m     NA       NA
- -0.05V     -0.01m     NA       NA
 0.00V     -0.01m     NA       NA

[POWER Clamp]
|Voltage    I(typ)   I(min)   I(max)
 0.00V     -0.02m     NA       NA
- -0.05V     -0.01m     NA       NA
- -0.10V     -0.01m     NA       NA
- -0.15V      0.00m     NA       NA
- -0.20V      0.03m     NA       NA
- -0.25V      0.14m     NA       NA
- -0.30V      0.43m     NA       NA
- -0.35V      0.95m     NA       NA
- -0.40V      1.61m     NA       NA
- -0.45V      2.41m     NA       NA
- -0.50V      3.39m     NA       NA
- -0.55V      4.41m     NA       NA
- -0.60V      5.50m     NA       NA

[End]

- -- 
***************************************************************
* Brian Young                           phone: (512) 996-6099 *
* Somerset Design Center                  fax: (512) 996-7434 *
* Motorola, Austin, TX               [email-masked] *
***************************************************************

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

Date: Thu, 18 Oct 2001 15:04:53 -0700
From: Bob Ross <[email-masked]>
Subject: Re: ibischk3 problems

Brian:

The problem is in the [Pulldown Reference] line.  I believe
you wanted it to be 0V.

You will still get some Errors and Warnings, for smaller
mismatches.  One of the Warning messages has an incorrect
percentage calculation, and I believe that problem needs
to be filed as a BUG.

Bob Ross
Mentor Graphics

Brian Young wrote:
> 
> Hello,
> 
> I am getting errors from ibischk3, but I can't figure out what
> the problem is.  The IBIS file was generated by a methodology in
> development, so there are lots of little problems.  Right now,
> there are also big problems:
> 
> IBISCHK3 V3.2.7
> 
> Checking test.ibs for IBIS 2.1 Compatibility...
> 
> ERROR - Model mod.A35_2.5V: The [Rising Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
>       has TYP column DC endpoints of  1.15V and  2.45v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 2.52V and  2.50V),
>       a difference of 54.34% and  1.87%, respectively.
> ERROR - Model mod.A35_2.5V: The [Rising Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=0V
>       has TYP column DC endpoints of  0.00V and  1.20v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 1.43V and  1.38V),
>       a difference of 100.00% and 13.05%, respectively.
> ERROR - Model mod.A35_2.5V: The [Falling Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
>       has TYP column DC endpoints of  1.25V and  2.50v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 2.52V and  2.50V),
>       a difference of 50.37% and  0.13%, respectively.
> ERROR - Model mod.A35_2.5V: The [Falling Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=0V
>       has TYP column DC endpoints of  0.05V and  1.35v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 1.43V and  1.38V),
>       a difference of 96.51% and  2.18%, respectively.
> 
> Errors  : 4
> 
> File Failed
> 
> Take for example the first error.  Before the start of the rising edge,
> the NFET is holding the voltage low.  I can find the holding low voltage
> by finding the point on the PULLDOWN IV curve where 2.5V=V+50*I.  Using
> the IV curve entry 1.10 27.69m, I find the voltage to be 1.1V.  From the
> [Rising Waveform], R_fixture = 50, V_fixture = 2.500 curve, I get the
> starting voltage as 1.15V.  That looks like a match to me, but ibischk3
> comes up with an error and different numbers.
> 
> Can someone ID the problem with these errors?
> 
> Thanks,
> Brian
> 

- ---

> [Model] mod.A35_2.5V
> Model_type I/O
> Polarity Non-Inverting
> Enable Active-High
> Vinh = 1.23V
> Vinl = 1.21V
> Cref = 0
> Rref = 0
> Vref = 0
> C_comp 4p 3p 6p
> [Temperature Range] 27 NA NA
> [Pullup Reference] 2.5V NA NA
> [Pulldown Reference] 2.5V NA NA
> [Power Clamp Reference] 2.5V NA NA
> [GND Clamp Reference] 0.0V NA NA
>

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

Date: Thu, 18 Oct 2001 18:19:34 -0400
From: Mike LaBonte <[email-masked]>
Subject: Re: ibischk3 problems

Brian,

You probably are seeing an s2ibis2 function call bug. It depends
on how s2ibis2 was compiled, and on which platform. Check all of
the waveform test .spi files (like a00XXX.spi), and you may see
a test fixture resistor RFIXS2I with both terminals attached to
the same node. So the buffer is running open circuit and goes full
swing.

If you are willing to fix the code, the bug lines are in s2ispice.c,
and looks like this:

sprintf( dummyBuffer, resString[spiceType], "RFIXS2I", nodeList[nodeIndex],
         nodeList[++nodeIndex], currentWave_P->R_fixture );

The problem is that order of argument evaluation in C is indeterminate,
and the ++nodeIndex may be evaluated first. Change it to:

sprintf( dummyBuffer, resString[spiceType], "RFIXS2I", nodeList[nodeIndex],
         nodeList[nodeIndex+1], currentWave_P->R_fixture );
++nodeIndex;

The same bug appears at other places in that file. If your RFIXS2I
terminals are not shorted, then I don't know what the problem is :-)

Mike LaBonte

Brian Young wrote:
> 
> Hello,
> 
> I am getting errors from ibischk3, but I can't figure out what
> the problem is.  The IBIS file was generated by a methodology in
> development, so there are lots of little problems.  Right now,
> there are also big problems:
> 
> IBISCHK3 V3.2.7
> 
> Checking test.ibs for IBIS 2.1 Compatibility...
> 
> ERROR - Model mod.A35_2.5V: The [Rising Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
>       has TYP column DC endpoints of  1.15V and  2.45v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 2.52V and  2.50V),
>       a difference of 54.34% and  1.87%, respectively.
> ERROR - Model mod.A35_2.5V: The [Rising Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=0V
>       has TYP column DC endpoints of  0.00V and  1.20v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 1.43V and  1.38V),
>       a difference of 100.00% and 13.05%, respectively.
> ERROR - Model mod.A35_2.5V: The [Falling Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=2.5V
>       has TYP column DC endpoints of  1.25V and  2.50v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 2.52V and  2.50V),
>       a difference of 50.37% and  0.13%, respectively.
> ERROR - Model mod.A35_2.5V: The [Falling Waveform]
>       with [R_fixture]=50 Ohms and [V_fixture]=0V
>       has TYP column DC endpoints of  0.05V and  1.35v, but
>       an equivalent load applied to the model's I-V tables yields
>       different voltages ( 1.43V and  1.38V),
>       a difference of 96.51% and  2.18%, respectively.
> 
> Errors  : 4
> 
> File Failed
> 
> Take for example the first error.  Before the start of the rising edge,
> the NFET is holding the voltage low.  I can find the holding low voltage
> by finding the point on the PULLDOWN IV curve where 2.5V=V+50*I.  Using
> the IV curve entry 1.10 27.69m, I find the voltage to be 1.1V.  From the
> [Rising Waveform], R_fixture = 50, V_fixture = 2.500 curve, I get the
> starting voltage as 1.15V.  That looks like a match to me, but ibischk3
> comes up with an error and different numbers.
> 
> Can someone ID the problem with these errors?
> 
> Thanks,
> Brian
> 
> -------------------------------------
> 
> [ibiS ver] 2.1
> [File Name] test.ibs
> [File Rev] 2.0
> [Date] date
> [Source] rev x.x
> [Copyright] test
> [Component] test1
> [Manufacturer] Motorola
> [Package]
> R_pkg 1m NA NA
> L_pkg 1p NA NA
> C_pkg 1f NA NA
> [Pin] signal_name    model_name
> |
> D9    A35            mod.A35_2.5V
> 
> [Model] mod.A35_2.5V
> Model_type I/O
> Polarity Non-Inverting
> Enable Active-High
> Vinh = 1.23V
> Vinl = 1.21V
> Cref = 0
> Rref = 0
> Vref = 0
> C_comp 4p 3p 6p
> [Temperature Range] 27 NA NA
> [Pullup Reference] 2.5V NA NA
> [Pulldown Reference] 2.5V NA NA
> [Power Clamp Reference] 2.5V NA NA
> [GND Clamp Reference] 0.0V NA NA
> 
> [Ramp]
> |variable typ           min      max
>  dV/dt_r  0.75/0.24n     NA       NA
>  dV/dt_f  0.75/0.09n     NA       NA
> 
> [Rising Waveform]
> R_fixture = 50
> V_fixture = 2.500
> C_fixture = 0p
> L_fixture = 0n
> C_dut = 0p
> R_dut = 0m
> L_dut = 0n
> |Time      V(typ)    V(min)    V(max)
>   1.45ns    1.15V      NA        NA
>   1.46ns    1.20V      NA        NA
>   1.47ns    1.95V      NA        NA
>   1.49ns    2.00V      NA        NA
>   1.51ns    2.05V      NA        NA
>   1.52ns    2.10V      NA        NA
>   1.54ns    2.15V      NA        NA
>   1.57ns    2.20V      NA        NA
>   1.60ns    2.25V      NA        NA
>   1.64ns    2.30V      NA        NA
>   1.75ns    2.35V      NA        NA
>   2.57ns    2.40V      NA        NA
>   8.05ns    2.45V      NA        NA
> 
> [Falling Waveform]
> R_fixture = 50
> V_fixture = 2.500
> C_fixture = 0p
> L_fixture = 0n
> C_dut = 0p
> R_dut = 0m
> L_dut = 0n
> |Time      V(typ)    V(min)    V(max)
>   1.54ns    2.50V      NA        NA
>   1.57ns    1.80V      NA        NA
>   1.67ns    1.75V      NA        NA
>   1.76ns    1.70V      NA        NA
>   1.84ns    1.65V      NA        NA
>   1.89ns    1.60V      NA        NA
>   1.92ns    1.55V      NA        NA
>   1.95ns    1.50V      NA        NA
>   1.98ns    1.45V      NA        NA
>   2.03ns    1.40V      NA        NA
>   2.07ns    1.35V      NA        NA
>   2.13ns    1.30V      NA        NA
>   2.22ns    1.25V      NA        NA
> 
> [Rising Waveform]
> R_fixture = 50
> V_fixture = 0
> C_fixture = 0p
> L_fixture = 0n
> C_dut = 0p
> R_dut = 0m
> L_dut = 0n
> |Time      V(typ)    V(min)    V(max)
>   1.47ns    0.00V      NA        NA
>   1.49ns    0.70V      NA        NA
>   1.51ns    0.75V      NA        NA
>   1.54ns    0.80V      NA        NA
>   1.56ns    0.85V      NA        NA
>   1.60ns    0.90V      NA        NA
>   1.64ns    0.95V      NA        NA
>   1.72ns    1.00V      NA        NA
>   1.85ns    1.05V      NA        NA
>   2.16ns    1.10V      NA        NA
>   2.38ns    1.15V      NA        NA
>   2.69ns    1.20V      NA        NA
> 
> [Falling Waveform]
> R_fixture = 50
> V_fixture = 0
> C_fixture = 0p
> L_fixture = 0n
> C_dut = 0p
> R_dut = 0m
> L_dut = 0n
> |Time      V(typ)    V(min)    V(max)
>   1.78ns    1.35V      NA        NA
>   1.79ns    0.80V      NA        NA
>   1.82ns    0.60V      NA        NA
>   1.86ns    0.55V      NA        NA
>   1.90ns    0.50V      NA        NA
>   1.93ns    0.45V      NA        NA
>   1.96ns    0.40V      NA        NA
>   2.00ns    0.35V      NA        NA
>   2.04ns    0.30V      NA        NA
>   2.10ns    0.25V      NA        NA
>   2.17ns    0.20V      NA        NA
>   2.30ns    0.15V      NA        NA
>   3.17ns    0.10V      NA        NA
>   8.77ns    0.05V      NA        NA
> 
> [Pulldown]
> |Voltage    I(typ)   I(min)   I(max)
> -0.60V    -17.34m     NA       NA
> -0.55V    -16.16m     NA       NA
> -0.50V    -14.83m     NA       NA
> -0.45V    -13.48m     NA       NA
> -0.40V    -12.14m     NA       NA
> -0.35V    -10.78m     NA       NA
> -0.30V     -9.38m     NA       NA
> -0.25V     -7.99m     NA       NA
> -0.20V     -6.55m     NA       NA
> -0.15V     -5.17m     NA       NA
> -0.10V     -3.74m     NA       NA
> -0.05V     -2.24m     NA       NA
>  0.00V     -0.89m     NA       NA
>  0.05V      0.57m     NA       NA
>  0.10V      2.05m     NA       NA
>  0.15V      3.42m     NA       NA
>  0.20V      4.89m     NA       NA
>  0.25V      6.31m     NA       NA
>  0.30V      7.66m     NA       NA
>  0.35V      9.08m     NA       NA
>  0.40V     10.46m     NA       NA
>  0.45V     11.87m     NA       NA
>  0.50V     13.16m     NA       NA
>  0.55V     14.50m     NA       NA
>  0.60V     15.83m     NA       NA
>  0.65V     17.06m     NA       NA
>  0.70V     18.42m     NA       NA
>  0.75V     19.64m     NA       NA
>  0.80V     20.86m     NA       NA
>  0.85V     22.04m     NA       NA
>  0.90V     23.22m     NA       NA
>  0.95V     24.39m     NA       NA
>  1.00V     25.54m     NA       NA
>  1.05V     26.60m     NA       NA
>  1.10V     27.69m     NA       NA
>  1.15V     28.75m     NA       NA
>  1.20V     29.73m     NA       NA
>  1.25V     30.75m     NA       NA
>  1.30V     31.71m     NA       NA
>  1.35V     32.66m     NA       NA
>  1.40V     33.56m     NA       NA
>  1.45V     34.46m     NA       NA
>  1.50V     35.33m     NA       NA
>  1.55V     36.15m     NA       NA
>  1.60V     36.95m     NA       NA
>  1.65V     37.76m     NA       NA
>  1.70V     38.48m     NA       NA
>  1.75V     39.22m     NA       NA
>  1.80V     39.94m     NA       NA
>  1.85V     40.63m     NA       NA
>  1.90V     41.29m     NA       NA
>  1.95V     41.91m     NA       NA
>  2.00V     42.53m     NA       NA
>  2.05V     43.10m     NA       NA
>  2.10V     43.69m     NA       NA
>  2.15V     44.22m     NA       NA
>  2.20V     44.71m     NA       NA
>  2.25V     45.21m     NA       NA
>  2.30V     45.63m     NA       NA
>  2.35V     46.07m     NA       NA
>  2.40V     46.48m     NA       NA
>  2.45V     46.86m     NA       NA
>  2.50V     47.20m     NA       NA
>  2.55V     47.52m     NA       NA
>  2.60V     47.82m     NA       NA
>  2.65V     48.11m     NA       NA
>  2.70V     48.38m     NA       NA
>  2.75V     48.63m     NA       NA
>  2.80V     48.95m     NA       NA
>  2.85V     49.38m     NA       NA
>  2.90V     49.78m     NA       NA
>  2.95V     49.78m     NA       NA
>  3.00V     49.78m     NA       NA
>  3.05V     49.78m     NA       NA
>  3.10V     49.78m     NA       NA
> 
> [Pullup]
> |Voltage    I(typ)   I(min)   I(max)
>  3.10V    -47.76m     NA       NA
>  3.05V    -47.50m     NA       NA
>  3.00V    -47.27m     NA       NA
>  2.95V    -46.99m     NA       NA
>  2.90V    -46.73m     NA       NA
>  2.85V    -46.46m     NA       NA
>  2.80V    -46.18m     NA       NA
>  2.75V    -45.89m     NA       NA
>  2.70V    -45.59m     NA       NA
>  2.65V    -45.31m     NA       NA
>  2.60V    -44.99m     NA       NA
>  2.55V    -44.69m     NA       NA
>  2.50V    -44.38m     NA       NA
>  2.45V    -44.03m     NA       NA
>  2.40V    -43.66m     NA       NA
>  2.35V    -43.31m     NA       NA
>  2.30V    -42.91m     NA       NA
>  2.25V    -42.50m     NA       NA
>  2.20V    -42.06m     NA       NA
>  2.15V    -41.59m     NA       NA
>  2.10V    -41.10m     NA       NA
>  2.05V    -40.57m     NA       NA
>  2.00V    -40.04m     NA       NA
>  1.95V    -39.46m     NA       NA
>  1.90V    -38.82m     NA       NA
>  1.85V    -38.21m     NA       NA
>  1.80V    -37.51m     NA       NA
>  1.75V    -36.82m     NA       NA
>  1.70V    -36.07m     NA       NA
>  1.65V    -35.33m     NA       NA
>  1.60V    -34.55m     NA       NA
>  1.55V    -33.73m     NA       NA
> | 1.50V    -32.88m     NA       NA
>  1.45V    -32.08m     NA       NA
> | 1.40V    -31.27m     NA       NA
>  1.35V    -30.42m     NA       NA
> | 1.30V    -30.80m     NA       NA
>  1.25V    -29.87m     NA       NA
> | 1.20V    -28.94m     NA       NA
>  1.15V    -27.96m     NA       NA
> | 1.10V    -26.99m     NA       NA
>  1.05V    -25.92m     NA       NA
> | 1.00V    -24.89m     NA       NA
>  0.95V    -23.89m     NA       NA
> | 0.90V    -22.83m     NA       NA
>  0.85V    -21.66m     NA       NA
> | 0.80V    -20.50m     NA       NA
>  0.75V    -19.33m     NA       NA
>  0.70V    -18.14m     NA       NA
>  0.65V    -17.00m     NA       NA
>  0.60V    -15.75m     NA       NA
>  0.55V    -14.53m     NA       NA
>  0.50V    -13.26m     NA       NA
>  0.45V    -12.00m     NA       NA
>  0.40V    -10.61m     NA       NA
>  0.35V     -9.30m     NA       NA
>  0.30V     -7.99m     NA       NA
>  0.25V     -6.63m     NA       NA
>  0.20V     -5.32m     NA       NA
>  0.15V     -3.93m     NA       NA
>  0.10V     -2.54m     NA       NA
>  0.05V     -1.16m     NA       NA
>  0.00V      0.18m     NA       NA
> -0.05V      1.58m     NA       NA
> -0.10V      2.95m     NA       NA
> -0.15V      4.38m     NA       NA
> -0.20V      5.79m     NA       NA
> -0.25V      7.12m     NA       NA
> -0.30V      8.52m     NA       NA
> -0.35V     10.01m     NA       NA
> -0.40V     11.30m     NA       NA
> -0.45V     12.67m     NA       NA
> -0.50V     14.08m     NA       NA
> -0.55V     15.49m     NA       NA
> -0.60V     16.82m     NA       NA
> 
> [GND Clamp]
> |Voltage    I(typ)   I(min)   I(max)
> -0.60V     -5.08m     NA       NA
> -0.55V     -4.04m     NA       NA
> -0.50V     -3.04m     NA       NA
> -0.45V     -2.12m     NA       NA
> -0.40V     -1.33m     NA       NA
> -0.35V     -0.71m     NA       NA
> -0.30V     -0.29m     NA       NA
> -0.25V     -0.10m     NA       NA
> -0.20V     -0.02m     NA       NA
> -0.15V     -0.02m     NA       NA
> -0.10V     -0.01m     NA       NA
> -0.05V     -0.01m     NA       NA
>  0.00V     -0.01m     NA       NA
> 
> [POWER Clamp]
> |Voltage    I(typ)   I(min)   I(max)
>  0.00V     -0.02m     NA       NA
> -0.05V     -0.01m     NA       NA
> -0.10V     -0.01m     NA       NA
> -0.15V      0.00m     NA       NA
> -0.20V      0.03m     NA       NA
> -0.25V      0.14m     NA       NA
> -0.30V      0.43m     NA       NA
> -0.35V      0.95m     NA       NA
> -0.40V      1.61m     NA       NA
> -0.45V      2.41m     NA       NA
> -0.50V      3.39m     NA       NA
> -0.55V      4.41m     NA       NA
> -0.60V      5.50m     NA       NA
> 
> [End]
> 
> --
> ***************************************************************
> * Brian Young                           phone: (512) 996-6099 *
> * Somerset Design Center                  fax: (512) 996-7434 *
> * Motorola, Austin, TX               [email-masked] *
> ***************************************************************

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

Date: Fri, 19 Oct 2001 15:40:41 -0400
From: "Chao Su" <[email-masked]>
Subject: High frequency performance of IBIS model

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

Hi,

I'm working in signal integrity of optical transceivers. I'm considering of
using IBIS model for my simulation, our optical transciever is operated at
2.5Gb/s. Somebody told me that IBIS model is not good to predict high
frequency behavior for the device. I would like you can give me advice about
what issue I need to concern when I get my IBIS model from vendors and how I
can make sure the model is good in high frequency simulations.

Thanks 

Chao Su
Optical Systems Design (Dept. QF11)
Nortel Networks
P. O. Box 3511
Station C, Ottawa, ON, K1Y 4H7
Canada
- ----------------------------------------------------------------
*Phone:	(613) 765-7688 (ESN 395-7688)
*E-mail:	[email-masked]
*Mail Stop:	045/12/E06

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>High frequency performance of IBIS model</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm working in signal integrity of =
optical transceivers. I'm considering of using IBIS model for my =
simulation, our optical transciever is operated at 2.5Gb/s. Somebody =
told me that IBIS model is not good to predict high frequency behavior =
for the device. I would like you can give me advice about what issue I =
need to concern when I get my IBIS model from vendors and how I can =
make sure the model is good in high frequency simulations.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks </FONT>
</P>

<P><I><FONT COLOR=3D"#0000FF" SIZE=3D5 FACE=3D"Monotype Corsiva">Chao =
Su</FONT></I>
<BR><I><B><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Optical =
Systems Design (Dept. QF11)</FONT></B></I>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Nortel =
Networks</FONT>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">P. O. Box =
3511</FONT>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Station C, Ottawa, =
ON, K1Y 4H7</FONT>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Canada</FONT>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
- -------</FONT>
<BR><FONT COLOR=3D"#000080" FACE=3D"Wingdings">(</FONT><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Phone: (613) 765-7688 (ESN =
395-7688)</FONT>
<BR><FONT COLOR=3D"#000080" FACE=3D"Wingdings">*</FONT><FONT =
COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">E-mail:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT COLOR=3D"#000080" FACE=3D"Wingdings">+</FONT><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Mail =
Stop:&nbsp;&nbsp;&nbsp;&nbsp; 045/12/E06</FONT>
</P>
<BR>

</BODY>
</HTML>
- ------_=_NextPart_001_01C158D5.EF661E90--

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

Date: Fri, 19 Oct 2001 12:52:41 -0700
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: High frequency performance of IBIS model

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

IBIS models have only a constant capacitance to account for 
the die capacitance, which means that there is no frequency
dependency in their impedance.  If the value is correct at
your frequency I think you could still use it, but if you
need frequency dependency you may need to find other ways.
 
I don't know if you are also planning to using the IBIS file
for describing the package for your device, but the IBIS
package parameters only use RLC (no G) and none of these are
frequency dependent either.
 
Arpad Muranyi
Intel Corporation
============================================================

- -----Original Message-----
From: Chao Su [mailto:[email-masked]]
Sent: Friday, October 19, 2001 12:41 PM
To: [email-masked]
Subject: High frequency performance of IBIS model

Hi, 

I'm working in signal integrity of optical transceivers. I'm considering of
using IBIS model for my simulation, our optical transciever is operated at
2.5Gb/s. Somebody told me that IBIS model is not good to predict high
frequency behavior for the device. I would like you can give me advice about
what issue I need to concern when I get my IBIS model from vendors and how I
can make sure the model is good in high frequency simulations.

Thanks 

Chao Su 
Optical Systems Design (Dept. QF11) 
Nortel Networks 
P. O. Box 3511 
Station C, Ottawa, ON, K1Y 4H7 
Canada 
- ---------------------------------------------------------------- 
*Phone: (613) 765-7688 (ESN 395-7688) 
*E-mail:        [email-masked] 
*Mail Stop:     045/12/E06 

- ------_=_NextPart_001_01C158D7.9D1497F0
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">
<TITLE>High frequency performance of IBIS model</TITLE>

<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>IBIS models 
have only a constant capacitance to account for </FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>the die 
capacitance, which means that there is no frequency</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>dependency 
in their impedance.&nbsp; If the value is correct at</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>your 
frequency I think you could still use it, but if you</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>need 
frequency dependency you may need to find other ways.</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>I don't know 
if you are also planning to using the IBIS file</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>for 
describing the package for your device, but the IBIS</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>package 
parameters only use RLC (no G) and none of these are</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>frequency 
dependent either.</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>Arpad 
Muranyi</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>Intel 
Corporation</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
size=2>============================================================</FONT></SPAN></DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Chao Su 
[mailto:[email-masked]]<BR><B>Sent:</B> Friday, October 19, 2001 12:41 
PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> High frequency 
performance of IBIS model<BR><BR></FONT></DIV>
<P><FONT face=Arial size=2>Hi,</FONT> </P>
<P><FONT face=Arial size=2>I'm working in signal integrity of optical 
transceivers. I'm considering of using IBIS model for my simulation, our optical 
transciever is operated at 2.5Gb/s. Somebody told me that IBIS model is not good 
to predict high frequency behavior for the device. I would like you can give me 
advice about what issue I need to concern when I get my IBIS model from vendors 
and how I can make sure the model is good in high frequency 
simulations.</FONT></P>
<P><FONT face=Arial size=2>Thanks </FONT></P>
<P><I><FONT face="Monotype Corsiva" color=#0000ff size=5>Chao Su</FONT></I> 
<BR><I><B><FONT face=Arial color=#000080 size=2>Optical Systems Design (Dept. 
QF11)</FONT></B></I> <BR><FONT face=Arial color=#000080 size=2>Nortel 
Networks</FONT> <BR><FONT face=Arial color=#000080 size=2>P. O. Box 3511</FONT> 
<BR><FONT face=Arial color=#000080 size=2>Station C, Ottawa, ON, K1Y 4H7</FONT> 
<BR><FONT face=Arial color=#000080 size=2>Canada</FONT> <BR><FONT face=Arial 
color=#000080 
size=2>----------------------------------------------------------------</FONT> 
<BR><FONT face=Wingdings color=#000080>(</FONT><FONT face=Arial color=#000080 
size=2>Phone: (613) 765-7688 (ESN 395-7688)</FONT> <BR><FONT face=Wingdings 
color=#000080>*</FONT><FONT face=Arial color=#000080 
size=2>E-mail:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
[email-masked]</FONT> <BR><FONT face=Wingdings 
color=#000080>+</FONT><FONT face=Arial color=#000080 size=2>Mail 
Stop:&nbsp;&nbsp;&nbsp;&nbsp; 045/12/E06</FONT> </P><BR></BODY></HTML>

- ------_=_NextPart_001_01C158D7.9D1497F0--

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

Date: Fri, 19 Oct 2001 13:57:25 -0700
From: "Mellitz, Richard" <[email-masked]>
Subject: RE: High frequency performance of IBIS model

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

When the return loss of the buffer over the required frequency range is
relatively flat, db-log(f) linear (3-6 db/octave) , or small IBIS will be
suffucient.
 
...Rich

- -----Original Message-----
From: Muranyi, Arpad [mailto:[email-masked]]
Sent: Friday, October 19, 2001 3:53 PM
To: [email-masked]
Subject: RE: High frequency performance of IBIS model

IBIS models have only a constant capacitance to account for 
the die capacitance, which means that there is no frequency
dependency in their impedance.  If the value is correct at
your frequency I think you could still use it, but if you
need frequency dependency you may need to find other ways.
 
I don't know if you are also planning to using the IBIS file
for describing the package for your device, but the IBIS
package parameters only use RLC (no G) and none of these are
frequency dependent either.
 
Arpad Muranyi
Intel Corporation
============================================================

- -----Original Message-----
From: Chao Su [mailto:[email-masked]]
Sent: Friday, October 19, 2001 12:41 PM
To: [email-masked]
Subject: High frequency performance of IBIS model

Hi, 

I'm working in signal integrity of optical transceivers. I'm considering of
using IBIS model for my simulation, our optical transciever is operated at
2.5Gb/s. Somebody told me that IBIS model is not good to predict high
frequency behavior for the device. I would like you can give me advice about
what issue I need to concern when I get my IBIS model from vendors and how I
can make sure the model is good in high frequency simulations.

Thanks 

Chao Su 
Optical Systems Design (Dept. QF11) 
Nortel Networks 
P. O. Box 3511 
Station C, Ottawa, ON, K1Y 4H7 
Canada 
- ---------------------------------------------------------------- 
*Phone: (613) 765-7688 (ESN 395-7688) 
*E-mail:        [email-masked] 
*Mail Stop:     045/12/E06 

- ------_=_NextPart_001_01C158E0.A7F9D050
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">
<TITLE>High frequency performance of IBIS model</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=020120420-19102001>When 
the return loss of the buffer over the required frequency range is relatively 
flat,&nbsp;db-log(f) linear (3-6 db/octave) , or small&nbsp;IBIS will be 
suffucient.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=020120420-19102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=020120420-19102001>...Rich</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Muranyi, Arpad 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, October 19, 2001 3:53 
  PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> RE: High frequency 
  performance of IBIS model<BR><BR></DIV></FONT>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>IBIS 
  models have only a constant capacitance to account for </FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>the die 
  capacitance, which means that there is no frequency</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>dependency 
  in their impedance.&nbsp; If the value is correct at</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>your 
  frequency I think you could still use it, but if you</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>need 
  frequency dependency you may need to find other ways.</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>I don't 
  know if you are also planning to using the IBIS file</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>for 
  describing the package for your device, but the IBIS</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>package 
  parameters only use RLC (no G) and none of these are</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>frequency 
  dependent either.</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>Arpad 
  Muranyi</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" size=2>Intel 
  Corporation</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
  size=2>============================================================</FONT></SPAN></DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=706074519-19102001><FONT face="Courier New" 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Chao Su 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, October 19, 2001 12:41 
  PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> High frequency 
  performance of IBIS model<BR><BR></FONT></DIV>
  <P><FONT face=Arial size=2>Hi,</FONT> </P>
  <P><FONT face=Arial size=2>I'm working in signal integrity of optical 
  transceivers. I'm considering of using IBIS model for my simulation, our 
  optical transciever is operated at 2.5Gb/s. Somebody told me that IBIS model 
  is not good to predict high frequency behavior for the device. I would like 
  you can give me advice about what issue I need to concern when I get my IBIS 
  model from vendors and how I can make sure the model is good in high frequency 
  simulations.</FONT></P>
  <P><FONT face=Arial size=2>Thanks </FONT></P>
  <P><I><FONT color=#0000ff face="Monotype Corsiva" size=5>Chao Su</FONT></I> 
  <BR><I><B><FONT color=#000080 face=Arial size=2>Optical Systems Design (Dept. 
  QF11)</FONT></B></I> <BR><FONT color=#000080 face=Arial size=2>Nortel 
  Networks</FONT> <BR><FONT color=#000080 face=Arial size=2>P. O. Box 
  3511</FONT> <BR><FONT color=#000080 face=Arial size=2>Station C, Ottawa, ON, 
  K1Y 4H7</FONT> <BR><FONT color=#000080 face=Arial size=2>Canada</FONT> 
  <BR><FONT color=#000080 face=Arial 
  size=2>----------------------------------------------------------------</FONT> 
  <BR><FONT color=#000080 face=Wingdings>(</FONT><FONT color=#000080 face=Arial 
  size=2>Phone: (613) 765-7688 (ESN 395-7688)</FONT> <BR><FONT color=#000080 
  face=Wingdings>*</FONT><FONT color=#000080 face=Arial 
  size=2>E-mail:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  [email-masked]</FONT> <BR><FONT color=#000080 
  face=Wingdings>+</FONT><FONT color=#000080 face=Arial size=2>Mail 
  Stop:&nbsp;&nbsp;&nbsp;&nbsp; 045/12/E06</FONT> 
</P><BR></BLOCKQUOTE></BODY></HTML>

- ------_=_NextPart_001_01C158E0.A7F9D050--

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

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