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

ibis-users         Thursday, January 23 2003         Volume 01 : Number 016

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

Date: Mon, 6 Jan 2003 10:44:40 -0500
From: "Ingraham, Andrew" <[email-masked]>
Subject: RE: [IBIS-Users] Validation of IBIS model

Hello Anshuli,

One thing that I think you haven't mentioned yet, is what simulator you used
for testing your IBIS model.  Maybe that's part of the problem.

Regarding the Timestep issue.  Sometimes merely changing the timestep
fixes a problem.  But more often than not, it is just a symptom of another
problem somewhere else: changing the timestep changes the results, but
neither set of results might be correct.  In such a case, you need to look to
somewhere other than the timestep to fix the problem.

Sometimes the timestep was the problem, and reducing it by several
orders of magnitude can indeed fix it.  To get more confidence that you
did the right thing, try a few more simulations, reducing the stepsize even
further (perhaps by one and two more orders of magnitude) and verify that
there is no further change.  The timestep ought to be at least one, and
probably several, orders of magnitude smaller than the one that starts to
show reasonable results.  If you are using a timestep that is even remotely
close to one that causes problems, you should ignore those simulations
entirely, even if they look right.

The results that you posted on Friday are clearly not right, but there is
no way to tell from it what's wrong.  It is odd that the waveform is wildly
erratic but then suddenly seems to stabilize at 2.3V.

One way to get the waveform that you posted today (straight-line edges), is
if the timestep of the waveform being plotted, is much too large.  If the only
waveform points are when the waveform is low and high, then the plotting
program connects them by straight lines and the result could be what you
saw.  Can you highlight just the individual datapoints being plotted, as a
"sanity check"?

The four waveforms that Hazen Hegazy mentions, are:

(1) Rising edge, with V_fixture = Ground
(2) Rising edge, with V_fixture = VDD
(3) Falling edge, with V_fixture = VDD
(4) Falling edge, with V_fixture = Ground

These would be more useful too if R_fixture is reasonably close to the
load impedance seen by the driver.  In many cases, this would be the
characteristic impedance of any trace normally connected to the output pin,
unless the trace is expected to be shorter than the rise+fall times.

Regards,
Andy

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

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

Date: Mon, 06 Jan 2003 09:45:17 -0800 (PST)
From: [email-masked]
Subject: Re: [IBIS-Users] Validation of IBIS model

Hi,
Sorry for my late response.
Actually it’s hard to tell why you have overlay with
spice in short and open circuit condition. I also agree
with Andrew as the problem might be somewhere else.
This why I’ve suggested the former model regeneration
and corrections in order to be sure from the model
quality before we provide more effort on it.

By the way, I still see IBIS steady state =2.4V while
SPICE steady state = 2.7V. This might be the entrance
of why this is happening.

I hope it helps

On Mon, 06 Jan 2003, Anshuli Goel wrote:

Hello Hazem
Sorry for bombarding you with so many mails.
I picked up the data for rising and falling waveform
from directly
the files made by s2ibis2 script and now I don't see
and ringing. So I
guess the problem that I had was due to bigger
timestep. Now I am
closely matching with the results of spice and IBIS
model but except one
trouble.
IBIS output

SPICE output

If you see at the waveforms the edges of IBIS output is
sharper as compared
to spice output. Otherwise the rise time and voltage
level is closely matching
. Why I am getting these sharp edges. I still have only
1 Rising and 1
falling waveform  . So does it have to do something
with this ? ???
Thanx for the help .
Regards
Anshuli
 
Anshuli Goel wrote:
Hello Hazem
Thanx for pointing out these problems with the model .
I have a few
questions though ?
1. Why the response at short and open load matching ?
(Is it because
there I don't have any load resistance )
2. How do I change the step size of rising and falling
waveforms in
s2ibis2 scripts ? (By default it is 0.2ns)
3. How do I take into account of the load which is
capacitive in nature
( I had posted this question earlier on this reflector
and I got the
answer from ("Mike LaBonte" <[email-masked]>) that
for this
purpose
I should use the
R_f  V_f  V_f_min  V_f_max  L_f  C_f 
R_d  C_d  L_d  etc parameters for
that purpose)
4. I don't understand about the four    waveforms that
you have
referred.  Can you point me out to some doc or some
thing on that
. How
does s2ibis2 generates these 4 waveforms or do I need
to do smiulations
in spice and put the waveforms in IBIS. if I do that
what is the syntax
in IBIS model for that ?
Regards
Anshuli
Hazem Hegazy wrote:
I'm not sure of the model quality because of the
followings:
   -         
The number of point in the rising and falling edges is
quit a few before it
     reach steady state.
   -         
There are Rising to gnd and Falling to VDD only V-T
data,
I strongly recommend
     to have the other two (Rising to VDD and Falling
to ground).
   -         
There is C_Fixture = 30p in the V-T data!! This is not
recommended while you
     generate the IBIS model wave forms, Please
regenerate the V-T
tables without these
     capacitance.
   -         
The C_comp value must be calculated and optimized in
order
to get complete
     overlay with SPICE.
I think that all of these might be the cause.
One more thing, I noticed also from the validation you
sent in this
mail
the SPICE
simulation reaches 2.7 as a steady state, while the
IBIS simulation
reached 2.4 !!
BR,
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email
[email-masked]
|with just the appropriate command message(s) in the
body:
|
|  help
|  subscribe   ibis      
<optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address,
if different>
|  unsubscribe ibis       <optional
e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if
different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/ 
Recent
|  http://www.eda.org/pub/ibis/users_archive/ 
Recent
|  http://www.eda.org/pub/ibis/email/         
E-mail since 1993

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

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

Date: Mon, 6 Jan 2003 13:59:49 -0800 
From: "Peters, Stephen" <[email-masked]>
Subject: [IBIS-Users] BIRD80.1 - Add External Reference Column to Pin Mapping Keyword

Greetings:

  Per the last IBIS teleconference, Michael Mirmak has updated BIRD80.  We
will be discussing the changes at the January 10, 2002 IBIS teleconfence.

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

****************************************************************************
*
****************************************************************************
*
                    BUFFER ISSUE RESOLUTION DOCUMENT (BIRD)

BIRD ID#:       80.1
ISSUE TITLE:    Add External Reference Column to Pin Mapping Keyword
REQUESTOR:      Michael Mirmak, Intel Corporation
DATE SUBMITTED: November 25, 2002
DATE REVISED:   January 6, 2003                      
DATE ACCEPTED BY IBIS OPEN FORUM: Pending     

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

STATEMENT OF THE ISSUE:

The [Pin Mapping] keyword does not contain any means by which users can
designate [Component] pins or pads as connected to a buffer's [External
Reference] supply voltage.  This BIRD expands [Pin Mapping] by adding a
sixth column for external voltage supply data, to allow [External Reference]
supplies to be mapped to particular pad or pin groups.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Changes to the IBIS 4.0 text are marked with the * character.
Changes from BIRD 80 to BIRD 80.1 are marked with the ** characters.

|===========================================================================
=
|     Keyword: [Pin Mapping]
|    Required: No
|** Description: Used to indicate the power and/or ground buses to which a 
|**              given driver, receiver or terminator is connected.
|*  Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref,  
|**              ext_ref
|** Usage Rules: The [Pin Mapping] keyword names the connections between 
|**              POWER and/or GND pins and buffer and/or terminator voltage 
|**              supply references using unique bus labels.  All buses with 
|**              identical labels are assumed to be connected with an ideal 
|**              short.  Each label must be associated with at least one pin

|**              whose model_name is POWER or GND.  Bus labels must not 
|**              exceed 15 characters.
|
|              Each line must contain either three, five or six entries.
|**              Use the reserved word NC where an entry is required but a 
|**              bus connection is not made (see below).
|
|              The first column contains a pin name.  Each pin name must 
|              match one of the pin names declared in the [Pin] section of 
|**              the [Component].  
|
|**              For buffers and terminators, the remaining columns 
|**              correspond to the voltage supply references for the named 
|**              pin.  Each [Model] supply reference is connected to a 
|**              particular bus through a bus label in the corresponding 
|              column.
|
|              The second column, pulldown_ref, designates the ground 
|              bus connections for the buffer or termination associated 
|**              with that pin.  The bus named under pulldown_ref is 
|**              associated with the [Pulldown] I-V table for non-ECL 
|**              [Model]s.  This is also the bus associated with the 
|**              [GND Clamp] I-V table and the [Rgnd] model unless 
|**              overridden by a label in the gnd_clamp_ref column.
|
|              The third column, pullup_ref, designates the power bus 
|**              connection for the buffer or termination.  The bus named 
|              under pullup_ref is associated with the [Pullup] table for 
|**              non-ECL [Model]s (for ECL models, this bus is associated 
|**              with the [Pulldown] table).  This is also the bus label 
|**              associated with the [POWER Clamp] I-V table and the 
|**              [Rpower] model unless overridden by a label in the 
|**              power_clamp_ref column.
|
|              The fourth and fifth columns, gnd_clamp_ref and 
|              power_clamp_ref, contain entries, if needed, to specify 
|              additional ground bus and power bus connections for clamps.
|**              Finally, the sixth column, ext_ref, contains entries to 
|**              specify external reference supply bus connections.  
|
|**              The usage of the columns changes for GND and POWER pins.
|**              For GND pins, the pulldown_ref column contains the name of 
|**              the bus to which the pin connects; the pullup_ref 
|**              column in this case must contain the reserved word NC.  
|**              Similarly, for POWER (including external reference) pins, 
|**              the pullup_ref column contains the name of the bus to 
|**              which the pin connects; the pulldown_ref column in this 
|**              case must contain the reserved word NC.
| 
|
|              If the [Pin Mapping] keyword is present, then the bus
|              connections for EVERY pin listed under the [Pin] keyword
|              must be given.
|
|              If a pin has no connection, then both the pulldown_ref and
|              pullup_ref subparameters for it will be NC.
|
|              The column length limits are:
|                     [Pin Mapping]     5 characters max
|                     pulldown_ref     15 characters max
|                     pullup_ref       15 characters max
|                     gnd_clamp_ref    15 characters max
|                     power_clamp_ref  15 characters max
|**                     ext_ref          15 characters max
|
|*              For compatibility with models developed under previous IBIS
|**              versions, [Pin Mapping] lines which contain ext_ref column 
|*              entries must also explicitly include entries for the 
|*              pulldown_ref, pullup_ref, gnd_clamp_ref and power_clamp_ref 
|**              columns.  These entries can be NC, as explained above.
|
|**              When six columns of data are specified, the headings 
|**              gnd_clamp_ref, power_clamp_ref and ext_ref must be used on 
|**              the line containing the [Pin Mapping] keyword.  Otherwise, 
|**              these headings can be omitted.
|
|---------------------------------------------------------------------------
- -
**[Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref
ext_ref
|
1                 GNDBUS1    PWRBUS1   | Signal pins and their associated
* 2               GNDBUS2    PWRBUS2   | ground, power and external 
|*                                     | reference connections
3                 GNDBUS1    PWRBUS1      GNDCLMP        PWRCLAMP
4                 GNDBUS2    PWRBUS2      GNDCLMP        PWRCLAMP
* 5               GNDBUS2    PWRBUS2      NC             PWRCLAMP REFBUS1
6                 GNDBUS2    PWRBUS2      GNDCLMP        NC
* 7               GNDBUS2    PWRBUS2      GNDCLMP        NC       REFBUS2
|*                                     | Some possible clamping 
|*                                     | connections are shown above 
|  .                                   | for illustration purposes
|  .
11                GNDBUS1    NC        | One set of ground connections.
12                GNDBUS1    NC        | NC indicates no connection to
13                GNDBUS1    NC        | power bus.
|  .    
21                GNDBUS2    NC        | Second set of ground connections
22                GNDBUS2    NC
23                GNDBUS2    NC
|  .    
31                NC         PWRBUS1   | One set of power connections.
32                NC         PWRBUS1   | NC indicates no connection to
** 33                NC         PWRBUS1   | ground bus.
|  .
41                NC         PWRBUS2   | Second set of power connections
42                NC         PWRBUS2
43                NC         PWRBUS2
|  .
51                GNDCLMP    NC        | Additional power connections
52                NC         PWRCLMP   | for clamps
|
|*  .
** 71               NC         REFBUS1   | External reference connections
** 72               NC         REFBUS2   
|
|** The following [Pin] list corresponds to the [Pin Mapping] shown above.
|**
** [Pin] signal_name model_name R_pin L_pin C_pin
| ** 
** 1     OUT1         output_buffer1      | Output buffers 
** 2     OUT2         output_buffer2      |
** 3     IO3          io_buffer1          | Input/output buffers
** 4     IO4          io_buffer2          | 
** 5     SPECIAL1     ref_buffer1         | Buffers with POWER CLAMP but no 
** 6     SPECIAL2     io_buffer_term1     | GND CLAMP I-V tables; two use 
** 7     SPECIAL3     ref_buffer2         | external reference voltages
** 11    VSS1          GND 
** 12    VSS1          GND 
** 13    VSS1          GND 
** 21    VSS2          GND 
** 22    VSS2          GND 
** 23    VSS2          GND 
** 31    VCC1          POWER
** 32    VCC1          POWER
** 33    VCC1          POWER
** 41    VCC2          POWER
** 42    VCC2          POWER
** 43    VCC2          POWER
** 51    VSSCLAMP      GND                | Power connections for clamps
** 52    VCCCLAMP      POWER              |
** 71    V_EXTREF1     POWER              | External reference voltage pins
** 72    V_EXTREF2     POWER              |
|
****************************************************************************
*

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

The addition of the external reference voltage keyword, [External
Reference], effectively created a "fifth" voltage for many IBIS buffers
which previously could only use the four basic ones: [Pullup Reference],
[Pulldown Reference], [Power Clamp Reference] and [Ground Clamp Reference]
([Pullup Reference] and [Power Clamp Reference] can be addressed
simultaneously through the [Voltage Range] keyword).  The IBIS 2.1 keyword
[Pin Mapping] establishes a means by which model authors can connect
buffer or terminator supply references to particular POWER and GND pins. 
However, the [Pin Mapping] definition was limited to the four basic
supplies assumed by the [Model] keyword in IBIS 2.1.  BIRD 80 expands [Pin
Mapping] by adding a sixth column for external voltage supply reference
labels, to allow [External Reference] supplies to be mapped to particular 
pins.

BIRD 80.1 is issued in response to comments by Frank Dunlap, Arpad Muranyi
and Bob Ross.  Accordingly, the "external_reference" column is changed to 
"ext_ref" to be compliant with the current 80 column IBIS line-length 
requirement.  Several other changes have been made in BIRD 80.1, as 
explained below.

In IBIS 4.0 and previous versions, the "pulldown_ref" and "pullup_ref"
columns served two functions.  For signal pins, these columns contained 
the labels of the bus connections for the pulldown and pullup supplies,
respectively.  Additionally, these columns were used to declare to which
buses POWER and GND pins were connected.  Even if a buffer used a particular
bus and its associated POWER pin only for its [POWER Clamp] I-V tables,
the bus name for that POWER pin was required to be listed under the
pullup_ref column, with an NC listed under the pulldown_ref column.

BIRD 80.1 maintains this approach, for consistency.  Therefore, ext_ref 
supply pins can only be declared under the pulldown_ref or pullup_ref 
columns and in no other column.  The IBIS parser should check the placement 
of ext_ref bus labels as appropriate.

In addition, the word "previously" in reference to the [Pin] section of an
IBIS model has been removed in BIRD 80.1.  There are no explicit rules in 
the IBIS specification which require that the [Pin] keyword must appear
before the [Pin Mapping] keyword.

Other grammatical and clarity issues, some found in versions as early as 
IBIS 2.1, have been corrected in BIRD 80.1, with no impact to the 
usage model of the keyword.

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

ANY OTHER BACKGROUND INFORMATION:

Note that this BIRD assumes that IBIS has been expanded to allow more than
80 characters of data per line.  At least 85 characters must be allowed in
order to accommodate four columns of 15 characters each, plus a
five-character name column and the spaces between each column.

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

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

Date: Tue, 7 Jan 2003 11:29:41 -0500
From: "Timothy Coyle" <[email-masked]>
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.

 It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird
seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.
Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do,
won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have
the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was
only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have
the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current
state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.

Regards,
Tim

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

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

Date: Tue, 7 Jan 2003 09:32:57 -0800 
From: "Reid, Chris" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Timothy,

I'm glad you are interested in Bird 75 and 77.

Yes, this is quite a leap for IBIS.  Fundamentally it defines a way that VHDL-AMS or SPICE models can be registered for use in an automated SI tool by using an IBIS wrapper.  This makes it possible to go far beyond what IBIS alone can do in terms of modeling real device characteristics, for example power and ground supplies inside the package.

As you know, SPICE models direct from vendors are difficult to use because they tend to be poorly documented.  The IBIS wrapper for these models, if correctly constructed, will help eliminate this confusion.

I share your enthusiasm for IBIS models.  They make SI simulations much faster than SPICE, and in some cases even more accurate.  It is not true that IBIS models are only translations from SPICE.  Many IBIS models are made by measuring the actual device responses.  In many cases the simulated results are actually closer to actual device performance than the SPICE models that are supposed to represent the part.

Thus, classic IBIS models should be used where possible because:
  1) They are faster to simulate.
  2) They are, at least in some cases, more accurate.

However, there are many devices IBIS cannot model.  With these Birds, for example, it is possible to model the whole component from input to output with a mixture of IBIS, SPICE, and VHDL-AMS all working together to describe some complex behavior.

IBIS is a very complex standard, and trying to extend it to handle everything that needs to be modeled in every case is hopeless.  Thus these Birds.

In short, use classic IBIS models where possible.  Otherwise use the new [external model] and [external circuit] structures.

Chris

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.

 It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird
seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.
Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do,
won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have
the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was
only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have
the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current
state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.

Regards,
Tim

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

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

Date: Tue, 7 Jan 2003 10:17:20 -0800
From: "Mirmak, Michael" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Tim, 
Thanks for taking a look at BIRD 75.8. You raise several important points, which I address below 
- - BIRD 75.8 does not allow just any SPICE to be used with IBIS. Only the "original" Berkeley SPICE -- which includes passive elements and simple sources as well as diode structures and BSIM3 transistor elements -- is permitted. The BIRD as written specifically prohibits proprietary SPICE variants, which would certainly include the kind of encrypted models you mention. 
The BIRD includes Berkeley SPICE for several reasons, but chiefly because Berkeley is the closest to being a standard SPICE and is most likely to share features with proprietary SPICE variants.  While buffer modeling is possible with Berkeley SPICE, the higher flexibility of AMS languages (see below) means that Berkeley SPICE will more often be seen describing on-die interconnect structures under BIRD 75.8 (for example, through the [External Circuit] keyword).  
- - I completely agree that IBIS is badly misused in many applications. Unfortunately, this isn't the only problem IBIS has. IBIS is simply not well-suited to describe today's newest technologies. For example, because IBIS was initially designed around the single-ended complementary "totem pole" design, serial differential buses like PCI-Express and Serial ATA are extremely hard to model accurately using the keywords currently available and commonly supported.  Similarly, effects like data-, frequency- and voltage-dependency of c_comp can't easily be captured under today's IBIS specification. 
Moreover, the problem can't be quickly or easily solved through the introduction of new keywords.  IBIS relies on a set of assumptions which underlie each keyword. Unfortunately, as seen with c_comp, our modeling problems result less from missing keywords than from keywords whose fundamental assumptions have changed.  In addition, each keyword change means a change to the spec and to the tools which support IBIS, causing a lag of months or years while the features are defined and implemented.  BIRD 75 allows the use of much more flexible behavioral languages, VHDL-AMS and Verilog-AMS, at the user level, to describe buffer behavior without relying on "canned" assumptions. 
So, we can certainly continue to encourage the correct use of IBIS 4.0 keywords in the industry.  But, BIRD 75.8 is still required to address today's "bleeding edge" technologies and to prepare us for the future. 
I hope this helps answer your questions. 
- - Michael Mirmak, Intel Corp. 

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello, 
I have been trying to follow along with the multilingual model discussions. 
I have read through the bird and have some comment/questions. 
My comments are more towards the purpose of the bird rather than technical 
content.  It seems the purpose of this bird undermines what IBIS was originally 
intended for: an adequate substitute for SPICE. (for most situations) This 
bird seems to be the death of IBIS. Why would I bother using IBIS at all when I 
can use SPICE? Was the intention to use faster, less complex IBIS "blocks", 
combined with SPICE "blocks" for the more complex parts? A vendor can right 
now give out encrypted SPICE models.  Why try to include these SPICE models 
into a complex IBIS format? If the goal is to try to tie together the 
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the 
scope of the IBIS spec. 

Most vendors don't want to give out SPICE models, even if they are 
encrypted. Will this bird force the hand of vendors? Once end users realize 
what this bird can do, won't they want the original SPICE model or hardware language code for 
every device? IBIS is merely a "translated" SPICE model.  Why use imitation 
when you can have the real thing? 

I also question the need for this bird.  I think this bird takes a huge 
leap, and the gap left behind will swallow the IBIS community.  I believe 
it was only last year at DesignCon where several papers were presented showing how 
many rudimentary errors there were in IBIS files on the web. To this 
day, I do not know of any IBIS files that are on the web that are 
accompanied by any correlation documentation.  To me, IBIS, as a standard, 
does not have the respect that it deserves. It is constantly being misused and abused. 
And while an enhancement bird like this might be beneficial, I would think 
that the current state of IBIS would garner more attention. 

As a model creator myself, I find the scope of this bird confusing, and I 
find the future of IBIS questionable. 
Regards, 
Tim 

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

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

Date: Tue, 7 Jan 2003 10:11:56 -0800
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Tim,

Thank you very much for taking some time to comment on BIRD75.8.  I wish
there were more messages discussing it...

As one of the co-authors of the BIRD, I would like to answer your concerns.
Regarding your "death of IBIS" and going back to SPICE subject, I have to
disagree some.  The main purpose of this BIRD was not to go back to SPICE
under IBIS covers.

Please keep in mind that the SPICE language supported in this BIRD is
Berkeley SPICE, and not any of the proprietary company-name-SPICE
flavors.  This is very important, because IBIS must remain a vendor
independent modeling language.  Having said that, you can forget about
encrypted HSPICE models, etc... under IBIS.  Since most companies don't
like to hand out unencrypted SPICE buffer models, the SPICE extension
will most likely not be used for buffer modeling purposes.

Since Berkeley SPICE has only limited behavioral capabilities, this is
where the AMS languages come into the picture.  Those languages are fairly
unlimited in writing equations.  You can write a totally behavioral
description of your buffer if you want (fast), but you can also rewrite
your transistor equations and a full netlist of a buffer with them,
just as if it was SPICE (slow).  It is up to you, the model maker.

So I see this BIRD as an extension of the behavioral modeling capabilities
of IBIS, not as going back to SPICE.

Regarding your second concern on the quality of existing IBIS models and the
need for even more complications in the specification, you are right, we
have problems.  However, if you ask why some companies don't / can't use
IBIS models, you will find out that it is because of the shortcomings of
the IBIS capabilities for the bleeding edge, high tech buffers and buses.
It is not that they wouldn't like to run their simulations faster, it is
that they feel that IBIS models do not have the detail they need in their
simulations.  I feel that we must have these extensions to IBIS so that
even the most advanced SI tasks could be done with IBIS (i.e. behavioral)
models.  (Remember, behavioral is good because it is fast, and hides all
those proprietary things for which we do not like to send SPICE models to
our customers).

On the other hand, I agree that we should do something about the quality 
of the every-day models.  I am committed to give IBIS modeling classes
whenever there is a need.  However, I also feel that some of these
problems exist because the specification itself was not written very
well (none of us were professional spec writers).  Having learnt from the
past mistakes I was working very hard with the other authors of this BIRD
to make this specification addition as clean as possible with potentials
for leaving the old baggage behind when it gets that outdated.

I hope this gives you a better insight for this BIRD.  Thanks again for
your comments,

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

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.

 It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird
seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.
Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do,
won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have
the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was
only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have
the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current
state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.

Regards,
Tim

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

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

Date: Tue, 7 Jan 2003 14:02:43 -0500
From: "Timothy Coyle" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Chris,
Thank you for your response. Some additional comment/questions.

Why use an IBIS wrapper? I believe that XTK already supports the use of
Berkeley SPICE and SpecctraQuest supports HSPICE. I'm sure these tool
vendors could incorporate
the hardware languages as well. (but I think they tend to sell those as
separate tools)

An undocumented IBIS file with only the minimum required keywords can be
just as confusing as a SPICE file.

You are correct in that IBIS data can be generated from the bench or from
SPICE translation. Bench data can really only include typical case, but as
you say, can match
actual silicon better. There are advantages and disadvantages for both.

Describing the whole input to output of a device violates the IBIS spec
with relation to timing? Is this going to change where the IBIS spec will
include internal timing?

Regards,
Tim

|---------+---------------------------->
|         |           chris_reid@mentor|
|         |           g.com            |
|         |                            |
|         |           01/07/2003 12:33 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       Timothy Coyle/Americas/NSC@NSC, [email-masked]@Internet                                           |
  |       cc:                                                                                                                    |
  |       Subject:  RE: [IBIS-Users] Questions Regarding Bird 75.8                                                               |
  >------------------------------------------------------------------------------------------------------------------------------|

Timothy,

I'm glad you are interested in Bird 75 and 77.

Yes, this is quite a leap for IBIS.  Fundamentally it defines a way that VHDL-AMS or SPICE models can be registered for use in an automated SI tool
by using an IBIS wrapper.  This makes it possible to go far beyond what IBIS alone can do in terms of modeling real device characteristics, for
example power and ground supplies inside the package.

As you know, SPICE models direct from vendors are difficult to use because they tend to be poorly documented.  The IBIS wrapper for these models,
if correctly constructed, will help eliminate this confusion.

I share your enthusiasm for IBIS models.  They make SI simulations much faster than SPICE, and in some cases even more accurate.  It is not true
that IBIS models are only translations from SPICE.  Many IBIS models are made by measuring the actual device responses.  In many cases the
simulated results are actually closer to actual device performance than the SPICE models that are supposed to represent the part.

Thus, classic IBIS models should be used where possible because:
  1) They are faster to simulate.
  2) They are, at least in some cases, more accurate.

However, there are many devices IBIS cannot model.  With these Birds, for example, it is possible to model the whole component from input to
output with a mixture of IBIS, SPICE, and VHDL-AMS all working together to describe some complex behavior.

IBIS is a very complex standard, and trying to extend it to handle everything that needs to be modeled in every case is hopeless.  Thus these Birds.

In short, use classic IBIS models where possible.  Otherwise use the new [external model] and [external circuit] structures.

Chris

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.

 It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird
seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.
Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do,
won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have
the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was
only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have
the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current
state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.

Regards,
Tim

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

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

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

Date: Tue, 7 Jan 2003 14:11:49 -0500
From: "Timothy Coyle" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Michael,
Thank you for your response. I have some more comment/questions.

I'm confused about only allowing the use of "original" Berkeley SPICE.  So
whatever flavor of SPICE I have, I have to make sure it is fully compatible
with Berkeley? And even if
it is, if I provide transistor models, will they not be encrypted then?
What about IP protection? I'm not sure how compatible Berkeley is with
other flavors. I believe that there are several
transistor parameters in HSPICE that are not compatible with Berkeley.  So
Berkeley SPICE is not really intended to model the buffer, but "on-die
interconnect"?

So high-level behavioral languages should be used to model the buffer?
Aren't there tools that already do this? Can't you do a mixed mode
simulation in Cadence?

Regards,
Tim

|---------+---------------------------->
|         |           michael.mirmak@in|
|         |           tel.com          |
|         |                            |
|         |           01/07/2003 01:18 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       Timothy Coyle/Americas/NSC@NSC, [email-masked]@Internet                                                  |
  |       cc:                                                                                                                    |
  |       Subject:  RE: [IBIS-Users] Questions Regarding Bird 75.8                                                               |
  >------------------------------------------------------------------------------------------------------------------------------|

Tim,
Thanks for taking a look at BIRD 75.8. You raise several important points, which I address below
- - BIRD 75.8 does not allow just any SPICE to be used with IBIS. Only the "original" Berkeley SPICE -- which includes passive elements and simple
sources as well as diode structures and BSIM3 transistor elements -- is permitted. The BIRD as written specifically prohibits proprietary SPICE
variants, which would certainly include the kind of encrypted models you mention.
The BIRD includes Berkeley SPICE for several reasons, but chiefly because Berkeley is the closest to being a standard SPICE and is most likely
to share features with proprietary SPICE variants.  While buffer modeling is possible with Berkeley SPICE, the higher flexibility of AMS languages
(see below) means that Berkeley SPICE will more often be seen describing on-die interconnect structures under BIRD 75.8 (for example, through the
[External Circuit] keyword).
- - I completely agree that IBIS is badly misused in many applications. Unfortunately, this isn't the only problem IBIS has. IBIS is simply not
well-suited to describe today's newest technologies. For example, because IBIS was initially designed around the single-ended complementary
"totem pole" design, serial differential buses like PCI-Express and Serial ATA are extremely hard to model accurately using the keywords currently
available and commonly supported.  Similarly, effects like data-, frequency- and voltage-dependency of c_comp can't easily be captured under today's
 IBIS specification.
Moreover, the problem can't be quickly or easily solved through the introduction of new keywords.  IBIS relies on a set of assumptions which
underlie each keyword. Unfortunately, as seen with c_comp, our modeling problems result less from missing keywords than from keywords whose
fundamental assumptions have changed.  In addition, each keyword change means a change to the spec and to the tools which support IBIS, causing
a lag of months or years while the features are defined and implemented.  BIRD 75 allows the use of much more flexible behavioral languages,
VHDL-AMS and Verilog-AMS, at the user level, to describe buffer behavior without relying on "canned" assumptions.
So, we can certainly continue to encourage the correct use of IBIS 4.0 keywords in the industry.  But, BIRD 75.8 is still required to address
today's "bleeding edge" technologies and to prepare us for the future.
I hope this helps answer your questions.
- - Michael Mirmak, Intel Corp.

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.  It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.

Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do, won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.
Regards,
Tim

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

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

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

Date: Tue, 7 Jan 2003 14:36:39 -0500
From: "Todd Westerhoff" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

A HA!

After all this years, the quote I needed!

"IBIS is a very complex standard, and trying to extend it to handle
everything that needs to be modeled in every case is hopeless."

Which give me the chance to say (once again):

Kumar Was Right.

Sorry - couldn't help myself!

Todd ;-}

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

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

- - Bonnie Raitt, "Nick of Time"

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Reid, Chris
Sent: Tuesday, January 07, 2003 12:33 PM
To: 'Timothy Coyle'; [email-masked]
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Timothy,

I'm glad you are interested in Bird 75 and 77.

Yes, this is quite a leap for IBIS.  Fundamentally it defines a way that
VHDL-AMS or SPICE models can be registered for use in an automated SI tool
by using an IBIS wrapper.  This makes it possible to go far beyond what IBIS
alone can do in terms of modeling real device characteristics, for example
power and ground supplies inside the package.

As you know, SPICE models direct from vendors are difficult to use because
they tend to be poorly documented.  The IBIS wrapper for these models, if
correctly constructed, will help eliminate this confusion.

I share your enthusiasm for IBIS models.  They make SI simulations much
faster than SPICE, and in some cases even more accurate.  It is not true
that IBIS models are only translations from SPICE.  Many IBIS models are
made by measuring the actual device responses.  In many cases the simulated
results are actually closer to actual device performance than the SPICE
models that are supposed to represent the part.

Thus, classic IBIS models should be used where possible because:
  1) They are faster to simulate.
  2) They are, at least in some cases, more accurate.

However, there are many devices IBIS cannot model.  With these Birds, for
example, it is possible to model the whole component from input to output
with a mixture of IBIS, SPICE, and VHDL-AMS all working together to describe
some complex behavior.

IBIS is a very complex standard, and trying to extend it to handle
everything that needs to be modeled in every case is hopeless.  Thus these
Birds.

In short, use classic IBIS models where possible.  Otherwise use the new
[external model] and [external circuit] structures.

Chris

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.

 It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird
seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.
Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do,
won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have
the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was
only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have
the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current
state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.

Regards,
Tim

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

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

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

Date: Tue, 7 Jan 2003 16:01:20 -0500
From: "Timothy Coyle" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Hi Arpad,
Thank you and to others for your responses. I think I initially
misunderstood how the SPICE language was going to
be supported. While I understand the advantages of including the AMS
languages, I'm still not sure of the full
ramifications.  It will be interesting to see how this bird is implemented.

Regards,
Tim

|---------+---------------------------->
|         |           arpad.muranyi@int|
|         |           el.com           |
|         |                            |
|         |           01/07/2003 03:21 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       [email-masked]@Internet                                                                           |
  |       cc:       (bcc: Timothy Coyle/Americas/NSC)                                                                            |
  |       Subject:  RE: [IBIS-Users] Questions Regarding Bird 75.8                                                               |
  >------------------------------------------------------------------------------------------------------------------------------|

Tim,

Thank you very much for taking some time to comment on BIRD75.8.  I wish
there were more messages discussing it...

As one of the co-authors of the BIRD, I would like to answer your concerns.
Regarding your "death of IBIS" and going back to SPICE subject, I have to
disagree some.  The main purpose of this BIRD was not to go back to SPICE
under IBIS covers.

Please keep in mind that the SPICE language supported in this BIRD is
Berkeley SPICE, and not any of the proprietary company-name-SPICE
flavors.  This is very important, because IBIS must remain a vendor
independent modeling language.  Having said that, you can forget about
encrypted HSPICE models, etc... under IBIS.  Since most companies don't
like to hand out unencrypted SPICE buffer models, the SPICE extension
will most likely not be used for buffer modeling purposes.

Since Berkeley SPICE has only limited behavioral capabilities, this is
where the AMS languages come into the picture.  Those languages are fairly
unlimited in writing equations.  You can write a totally behavioral
description of your buffer if you want (fast), but you can also rewrite
your transistor equations and a full netlist of a buffer with them,
just as if it was SPICE (slow).  It is up to you, the model maker.

So I see this BIRD as an extension of the behavioral modeling capabilities
of IBIS, not as going back to SPICE.

Regarding your second concern on the quality of existing IBIS models and the
need for even more complications in the specification, you are right, we
have problems.  However, if you ask why some companies don't / can't use
IBIS models, you will find out that it is because of the shortcomings of
the IBIS capabilities for the bleeding edge, high tech buffers and buses.
It is not that they wouldn't like to run their simulations faster, it is
that they feel that IBIS models do not have the detail they need in their
simulations.  I feel that we must have these extensions to IBIS so that
even the most advanced SI tasks could be done with IBIS (i.e. behavioral)
models.  (Remember, behavioral is good because it is fast, and hides all
those proprietary things for which we do not like to send SPICE models to
our customers).

On the other hand, I agree that we should do something about the quality
of the every-day models.  I am committed to give IBIS modeling classes
whenever there is a need.  However, I also feel that some of these
problems exist because the specification itself was not written very
well (none of us were professional spec writers).  Having learnt from the
past mistakes I was working very hard with the other authors of this BIRD
to make this specification addition as clean as possible with potentials
for leaving the old baggage behind when it gets that outdated.

I hope this gives you a better insight for this BIRD.  Thanks again for
your comments,

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

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.

 It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird
seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.
Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do,
won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have
the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was
only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have
the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current
state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.

Regards,
Tim

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

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

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

Date: Tue, 7 Jan 2003 13:17:23 -0800
From: "Tom Dagostino" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Tim

Measurement based models can and have represented the full min/typ/max
extremes of silicon.  I have made models based on rainbow die to yield the
full spectrum of characteristics over the full temperature, voltage and
process range.

Tom Dagostino
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
2926 SE Yamhill St.                Device Modeling Division
Portland, OR 97214                 13610 SW Harness Lane
                                   Beaverton, OR 97008
http://www.teraspeed.com           503-430-1065
[email-masked]

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Timothy Coyle
Sent: Tuesday, January 07, 2003 11:03 AM
To: chris_reid
Cc: [email-masked]
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Chris,
Thank you for your response. Some additional comment/questions.

Why use an IBIS wrapper? I believe that XTK already supports the use of
Berkeley SPICE and SpecctraQuest supports HSPICE. I'm sure these tool
vendors could incorporate
the hardware languages as well. (but I think they tend to sell those as
separate tools)

An undocumented IBIS file with only the minimum required keywords can be
just as confusing as a SPICE file.

You are correct in that IBIS data can be generated from the bench or from
SPICE translation. Bench data can really only include typical case, but as
you say, can match
actual silicon better. There are advantages and disadvantages for both.

Describing the whole input to output of a device violates the IBIS spec
with relation to timing? Is this going to change where the IBIS spec will
include internal timing?

Regards,
Tim

|---------+---------------------------->
|         |           chris_reid@mentor|
|         |           g.com            |
|         |                            |
|         |           01/07/2003 12:33 |
|         |           PM               |
|         |                            |
|---------+---------------------------->

>---------------------------------------------------------------------------
- ---------------------------------------------------|
  |
|
  |       To:       Timothy Coyle/Americas/NSC@NSC,
[email-masked]@Internet
|
  |       cc:
|
  |       Subject:  RE: [IBIS-Users] Questions Regarding Bird 75.8
|

>---------------------------------------------------------------------------
- ---------------------------------------------------|

Timothy,

I'm glad you are interested in Bird 75 and 77.

Yes, this is quite a leap for IBIS.  Fundamentally it defines a way that
VHDL-AMS or SPICE models can be registered for use in an automated SI tool
by using an IBIS wrapper.  This makes it possible to go far beyond what IBIS
alone can do in terms of modeling real device characteristics, for
example power and ground supplies inside the package.

As you know, SPICE models direct from vendors are difficult to use because
they tend to be poorly documented.  The IBIS wrapper for these models,
if correctly constructed, will help eliminate this confusion.

I share your enthusiasm for IBIS models.  They make SI simulations much
faster than SPICE, and in some cases even more accurate.  It is not true
that IBIS models are only translations from SPICE.  Many IBIS models are
made by measuring the actual device responses.  In many cases the
simulated results are actually closer to actual device performance than the
SPICE models that are supposed to represent the part.

Thus, classic IBIS models should be used where possible because:
  1) They are faster to simulate.
  2) They are, at least in some cases, more accurate.

However, there are many devices IBIS cannot model.  With these Birds, for
example, it is possible to model the whole component from input to
output with a mixture of IBIS, SPICE, and VHDL-AMS all working together to
describe some complex behavior.

IBIS is a very complex standard, and trying to extend it to handle
everything that needs to be modeled in every case is hopeless.  Thus these
Birds.

In short, use classic IBIS models where possible.  Otherwise use the new
[external model] and [external circuit] structures.

Chris

- -----Original Message-----
From: Timothy Coyle [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 8:30 AM
To: [email-masked]
Subject: [IBIS-Users] Questions Regarding Bird 75.8

Hello,
I have been trying to follow along with the multilingual model discussions.
I have read through the bird and have some comment/questions.
My comments are more towards the purpose of the bird rather than technical
content.

 It seems the purpose of this bird undermines what IBIS was originally
intended for: an adequate substitute for SPICE. (for most situations) This
bird
seems to be the death of IBIS. Why would I bother using IBIS at all when I
can use SPICE? Was the intention to use faster, less complex IBIS "blocks",
combined with SPICE "blocks" for the more complex parts? A vendor can right
now give out encrypted SPICE models.  Why try to include these SPICE models
into a complex IBIS format? If the goal is to try to tie together the
"best" of IBIS, SPICE, and hardware languages I'm not sure that is the
scope of the IBIS spec.
Most vendors don't want to give out SPICE models, even if they are
encrypted. Will this bird force the hand of vendors? Once end users realize
what this bird can do,
won't they want the original SPICE model or hardware language code for
every device? IBIS is merely a "translated" SPICE model.  Why use imitation
when you can have
the real thing?

I also question the need for this bird.  I think this bird takes a huge
leap, and the gap left behind will swallow the IBIS community.  I believe
it was
only last year at DesignCon where several papers were presented showing how
many rudimentary errors there were in IBIS files on the web. To this
day, I do not know of any IBIS files that are on the web that are
accompanied by any correlation documentation.  To me, IBIS, as a standard,
does not have
the respect that it deserves. It is constantly being misused and abused.
And while an enhancement bird like this might be beneficial, I would think
that the current
state of IBIS would garner more attention.

As a model creator myself, I find the scope of this bird confusing, and I
find the future of IBIS questionable.

Regards,
Tim

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

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

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

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

Date: Wed, 8 Jan 2003 01:36:15 -0700
From: Al Davis <[email-masked]>
Subject: Re: [IBIS-Users] Questions Regarding Bird 75.8

Can someone please post examples of mixed IBIS-Spice, 
IBIS-Verilog, and IBIS-VHDL models so we can review them?

I asked for this several times before and so far have gotten no 
useful responses.  If the proponents of this BIRD are serious, 
they will have made some examples manually to demonstrate the 
concept.  It is only by doing so that you can know enough about 
it to proceed further.  

I agree with the need, but I agree with Timothy that this 
approach is confusing.  I further believe that it doesn't even 
come close to solving the problem that it is intended to solve.

The examples should demonstrate that it works, and is superior 
to a Spice only (or *-AMS only) approach.

If such examples cannot be produced and published, it should be 
rejected.  It is the responsibility of those who think it is 
good to prove it.

The proponents should also be able to explain:

1. How this impacts simulators that use only the [Model] 
portion of an IBIS file. (not [Component])

2. How it is superior to documenting an equivalence between the 
languages, like the equivalence between Spice and Verilog-A is 
documented.

3. How it impacts mixed-mode simulators.

4. How such a model can be developed and tested.

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

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

Date: Wed, 8 Jan 2003 10:57:48 -0500
From: [email-masked]
Subject: [IBIS-Users] IBIS for ECL?

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

I need to create IBIS models for some ECL parts.  I've never made an ECL 
IBIS model before, so I thought that I would ask if anyone has any 
pointers for me or general guidelines for ECL?  I'm guessing that there 
will be a few different steps to create ECL IBIS.

Thanks,
Dana Staples
- ----=_NextPart_ST_10_55_12_Wednesday_January_08_2003_17756
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">I need to create IBIS models for some ECL parts. &nbsp;I've never made an ECL IBIS model before, so I thought that I would ask if anyone has any pointers for me or general guidelines for ECL? &nbsp;I'm guessing that there will be a few different steps to create ECL IBIS.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Dana Staples</font>
- ----=_NextPart_ST_10_55_12_Wednesday_January_08_2003_17756--

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

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

Date: Wed, 8 Jan 2003 13:01:45 -0500
From: "Lynne Green" <[email-masked]>
Subject: [IBIS-Users] Third Call for Papers for IBIS DesignCon Summit

- ------------------------------------------------------------------------
- ---------
		IBIS SUMMIT
		THIRD CALL FOR
	PARTICIPATION & PRESENTATIONS
- ------------------------------------------------------------------------
- ---------

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

Time/Date:  Monday January 27, 2003,  8:00 AM to 5:00 PM

Location:   Magnolia Room 
            Santa Clara Convention Center
            Santa Clara, CA

Content:    Presentations and Discussions

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

Sponsors:   DesignCon, National Semiconductor

DesignCon:  January 27-30, 2003
		Santa Clara Convention Center
		Santa Clara, California
		See <http://www.designcon.com/2003/> for more
information.

BACKGROUND

DesignCon is the premier annual Silicon Valley event for the electronic
design automation (EDA) and semiconductor industry.  Topics of current
interest to the EIA IBIS Open Forum are addressed at DesignCon.

This meeting will be conducted as a formal IBIS Summit Meeting.
Presentations are expected to be available and archived in an electronic
format, and minutes of the meeting will be issued.  Any pending formal
decisions (votes) will be announced at least two weeks prior to the
meeting.

CALL FOR PARTICIPANTS

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

   Name:
   E-mail address:
   Company:
   Telephone:

Send to:

    Milt Swartz at National Semiconductor ([email-masked])

CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have IBIS experiences
or issues.

Format of Presentation:  Overhead Projections.
			LCD Projection may be available.  It is
recommended
			that those wishing to use LCD projection bring
their
			presentation on a CD or send it electronically.
Time:			15-30 Minutes
Electronic Archival:	We request electronic versions so that the
			presentations can be archived and also made
			available to non-attendees.  Formats used in
			the past have been text, Power Point, Word,
			Postscript, and Acrobat.  Electronic
presentations
			should be made available by January 22, 2003
			for uploading and copying.

If you plan a presentation, please supply

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

   Estimate Time:

Send this to:

  Lynne Green ([email-masked])

AGENDA

The agenda includes presentations, discussions, breaks, and a luncheon
(which
will be provided).  This will be developed as presentation proposals are
received.

The following individuals have signed up to present at the summit
(presentation
titles are tentative)
 - Stephen Peters, IBIS Report
 - Dima Smolysansky, TDA Systems, TBD
 - Barry Katz, Signal Integrity Software, Quality Committee Report
 - Tim Coyle, IBIS Modeling Experiences

Other presentations are encouraged.

LIST OF NEARBY HOTELS

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

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

Date: Wed, 8 Jan 2003 09:46:09 -0800
From: "Muranyi, Arpad" <[email-masked]>
Subject: [IBIS-Users] Re: [IBIS] IBIS open forum minutes (12/13/02)

All,

I am posting this message on behalf of Luca Giacotto.
While I am at it, I also want to apologize for giving
an incorrect answer to this question in the last Open
Forum Teleconference.  Unfortunately I didn't remember
this detail correctly.  Luca has the correct answer.

Thanks,

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

Just a correction to a statement in the last forum minutes.

Concerning the question from Bob Haller reported in the minutes (see
copy below), I would correct the reply. I think the answer is "yes":
the parameters in the BIRD give to the model maker the maximum of
freedom. He can model the "voltage-dependent" and "frequency-dependent"
behaviour of "C_comp" in EACH ONE of the three possible states.
The 24 parameters in the actual BIRD include
*) 8 parameters to describe "C_comp" in the OUTPUT-LOW state;
*) 8 parameters to describe "C_comp" in the OUTPUT-HIGH state;
*) 8 parameters to describe "C_comp" in the INPUT state;

Also, I would like to point out that with the proposed description of
the die-capacitance the currents flowing in the four references ([Pullup
Reference], [Pulldown Reference], [POWER Clamp Reference] and [GND Clamp
Reference]) are "correct". Which should be useful to investigate
ground-bounce and radiation problems.

Happy new year!
Luca

**********From the minutes****************
> 
> BIRD79 - Non-linear buffer impedance (extension to C_comp)
> Larry Barnes indicated that he felt this BIRD will be useful for modeling
> buffers that run at a clock rate greater than 1GhZ.  In response to a 
> question, Arpad Muranyi clarified that this BIRD attempts to model
> C_comp variations due to both frequency and voltage.  Bob Haller then
> asked if this BIRD gave the model maker the ability to model different
> C_comp values for receiving and driving.  Arpad replied that this
> functionality was not covered by the current list of subparameters, but
> this case could be handled by implementing the functionality of this BIRD
> using the proposed multi-lingual modeling extensions. 
> 
===========================================================================
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Wed, 8 Jan 2003 10:36:09 -0800
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Al,

Thank you for your comments on BIRD75.8.  I would like to respond
to it giving some answers and asking some questions.

1)  Your request for examples are well taken.  We are working on
them now, but can't promise them by this coming Friday's meeting.

Regarding your request for the examples demonstrating that this
approach is superior to a SPICE or *-AMS only approach I wonder
what kind of superiority you think of?  A SPICE or *-AMS model
will result in the same waveforms and/or accuracy, regardless 
whether they are embedded in this IBIS wrapper, or not.  So from that
point of view I don't see any difference there.  However, from the
user's perspective, there are some usage model differences which
makes the life of the user easier.  The IBIS wrapper provides
additional information for the simulation tool, helping in automating
the measurement tasks, and providing information about reference
loads, etc... without effecting the model behavior itself.  That 
is the benefit of having these languages embedded in IBIS.

2)  You mention that this approach is confusing.  Could you please
elaborate on what the confusing part is, so that we could address
it if possible?

3)  You say that "it doesn't even come close to solving the problem".
I am not sure what you are referring to.  Could you please give a
problem statement as you see it?  We can't solve a problem if we
have a different opinion on what it is...

4)  The BIRD allows for an "old fashioned" model under the [Model]
statement to coexist with the new [External Model] keyword that
provides the SPICE or *-AMS description of a device.  It is up to
the model maker to make a duplicate model of the device both ways.
If they write such a duplicate with the old [Model] keyword, tools
which cannot process the new keywords can simulate just like today.
If the model maker doesn't care to do that, you may be out of luck.

5)  I do not understand your question: "How it is superior to
documenting an equivalence between the languages, like the
equivalence between Spice and Verilog-A is documented."  Please
explain what you mean by "documenting equivalence between languages".

6)  Regarding "How it impacts mixed mode simulators", it depends on
whether they have a parser that can read the IBIS file.  They should
certainly be able to process the *-AMS portion of the IBIS file without
difficulty.  However, in order to read and make use of the rest of the
information, an IBIS parser would need to be implemented.  This should
not be a large undertaking, however.

7)  Regarding "How such a model can be developed and tested", this is
a complicated question, because of the freedom these languages provide.
There are zillions of ways to write a model.  One way would be an
equivalent IV and Vt table based equivalent in one of the AMS languages.
Another way would be to use the same data, but curve fit them to equations
and write those equations up in AMS syntax.  For SPICE lovers, I could
imagine someone to write up the transistor equations in AMS syntax, and
provide the usual process file information and netlist of transistors
in the AMS file.  I can also envision many other ways using higher level
behavioral techniques, some of which may even be proprietary and patentable.

However, your question is well taken, and guidelines in form of a cook book
should be written to get people started.  I am certainly planning to extend
my IBIS class materials in this direction too.

I hope I answered some of your concerns.  Please give me more information
on those questions I didn't understand so we can find the answers to those
too.

Thanks,

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

- -----Original Message-----
From: Al Davis [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 12:36 AM
To: [email-masked]
Subject: Re: [IBIS-Users] Questions Regarding Bird 75.8

Can someone please post examples of mixed IBIS-Spice, 
IBIS-Verilog, and IBIS-VHDL models so we can review them?

I asked for this several times before and so far have gotten no 
useful responses.  If the proponents of this BIRD are serious, 
they will have made some examples manually to demonstrate the 
concept.  It is only by doing so that you can know enough about 
it to proceed further.  

I agree with the need, but I agree with Timothy that this 
approach is confusing.  I further believe that it doesn't even 
come close to solving the problem that it is intended to solve.

The examples should demonstrate that it works, and is superior 
to a Spice only (or *-AMS only) approach.

If such examples cannot be produced and published, it should be 
rejected.  It is the responsibility of those who think it is 
good to prove it.

The proponents should also be able to explain:

1. How this impacts simulators that use only the [Model] 
portion of an IBIS file. (not [Component])

2. How it is superior to documenting an equivalence between the 
languages, like the equivalence between Spice and Verilog-A is 
documented.

3. How it impacts mixed-mode simulators.

4. How such a model can be developed and tested.

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

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

Date: Wed, 08 Jan 2003 12:00:56 -0800
From: "Ross, Bob" <[email-masked]>
Subject: Re: [IBIS-Users] Questions Regarding Bird 75.8

Al:

I have uploaded a very generic sample cmos_3_state.ibs
CMOS buffer that reference an IBIS buffer and a Generic
SPICE test buffer under cmos_3_state.sp

The SPICE model is a reconfigurable to other modes.

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

I wish I had more time for more models and variations, 
but this is a start.  Arpad Muranyi stated that he is
also working on some samples to be posted later.

We are unable to offer some actual operating models
because they contain proprietary data, but the overall
concept has proven to be successful in actual test
cases with nearly identical syntax as the proposed BIRDs.

Bob Ross
Mentor Graphics

Al Davis wrote:
> 
> Can someone please post examples of mixed IBIS-Spice,
> IBIS-Verilog, and IBIS-VHDL models so we can review them?
> 
> I asked for this several times before and so far have gotten no
> useful responses.  If the proponents of this BIRD are serious,
> they will have made some examples manually to demonstrate the
> concept.  It is only by doing so that you can know enough about
> it to proceed further.
> 
> I agree with the need, but I agree with Timothy that this
> approach is confusing.  I further believe that it doesn't even
> come close to solving the problem that it is intended to solve.
> 
> The examples should demonstrate that it works, and is superior
> to a Spice only (or *-AMS only) approach.
> 
> If such examples cannot be produced and published, it should be
> rejected.  It is the responsibility of those who think it is
> good to prove it.
> 
> The proponents should also be able to explain:
> 
> 1. How this impacts simulators that use only the [Model]
> portion of an IBIS file. (not [Component])
> 
> 2. How it is superior to documenting an equivalence between the
> languages, like the equivalence between Spice and Verilog-A is
> documented.
> 
> 3. How it impacts mixed-mode simulators.
> 
> 4. How such a model can be developed and tested.
> 
> If these questions cannot be adequately answered in this public
> forum, it should be rejected.
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 9 Jan 2003 02:47:59 -0700
From: Al Davis <[email-masked]>
Subject: Re: [IBIS-Users] Questions Regarding Bird 75.8

I am beginning to see some value, and it is clearing up.

On Wednesday 08 January 2003 11:36 am, Muranyi, Arpad wrote:
> Regarding your request for the examples demonstrating that
> this approach is superior to a SPICE or *-AMS only approach I
> wonder what kind of superiority you think of? 

There must be some, otherwise the proposal has no value.  You 
tell me!

> ...... A SPICE or
> *-AMS model will result in the same waveforms and/or
> accuracy, regardless whether they are embedded in this IBIS
> wrapper, or not.  So from that point of view I don't see any
> difference there. 

That's what I mean.  If there is no difference, why bother?

> .... However, from the user's perspective,
> there are some usage model differences which makes the life
> of the user easier.  The IBIS wrapper provides additional
> information for the simulation tool, helping in automating
> the measurement tasks, and providing information about
> reference loads, etc... without effecting the model behavior
> itself.  That is the benefit of having these languages
> embedded in IBIS.

ok.  That's what I was looking for.

With the examples, I see that now ....

It is for things like Vmeas, which isn't represented in Spice.  
The BIRD should say this.

> 2)  You mention that this approach is confusing.  Could you
> please elaborate on what the confusing part is, so that we
> could address it if possible?

I must confess ....  It is a lot better in .7 ..  Bob's files 
help, too.  It would be clearer if [External Model] and 
[External Circuit] were different BIRDs, since they don't 
depend on each other.

> 3)  You say that "it doesn't even come close to solving the
> problem". I am not sure what you are referring to.  Could you
> please give a problem statement as you see it?  We can't
> solve a problem if we have a different opinion on what it
> is...

Let me think about this one.

> 4)  The BIRD allows for an "old fashioned" model under the
> [Model] statement to coexist with the new [External Model]
> keyword that provides the SPICE or *-AMS description of a
> device.  It is up to the model maker to make a duplicate
> model of the device both ways. If they write such a duplicate
> with the old [Model] keyword, tools which cannot process the
> new keywords can simulate just like today. If the model maker
> doesn't care to do that, you may be out of luck.

That is another thing that I found unclear, but I think I see 
it now.

It said those keywords are optional when [External] is used, 
but didn't say how it is resolved.  I interpreted it to mean 
that both circuits are present, and the external one is added 
to the old style one.

Apparently, what you mean is that when both are present, the 
simulator must choose one or the other.  Both cannot be active 
at the same time.  If I interpret it this way, it makes sense 
and answers #3.

Given this approach, it is unreasonable to have only one old 
style keyword, say [Pullup] without the complete set.  The BIRD 
makes it look like you can have only one.  I propose that it be 
documented that if any old style parameters are present, there 
must be a complete model.  It should also be documented that if 
both new and old forms are present, they are treated as 
alternatives.

I think a better approach is to disallow the old-style 
parameters when [External Model] is used.  The functionality 
can be provided with [Model Selector].

I noticed that the list of optional old-style keywords did not 
include driver schedule and submodels.

Please confirm that my new interpretation is correct.

> 5)  I do not understand your question: "How it is superior to
> documenting an equivalence between the languages, like the
> equivalence between Spice and Verilog-A is documented." 
> Please explain what you mean by "documenting equivalence
> between languages".

What I mean is to say something like: an IBIS [Model] is 
equivalent to a Spice ".subckt" with a specified name 
convention, and a particular node list.  That way, it could be 
substituted easily in the simulator's native way.

If you look at mixed Spice - Verilog-A simulators, they don't 
distinguish which is which externally.  A Verilog-A "module" 
looks just like a subckt (X...) in Spice format.  Likewise, a 
Spice .subckt can be called by Verilog mode, just like a module.

Some simulators do this already, but all different.  There 
would be significant value in standardising this.

> 6)  Regarding "How it impacts mixed mode simulators", it
> depends on whether they have a parser that can read the IBIS
> file.  They should certainly be able to process the *-AMS
> portion of the IBIS file without difficulty.  However, in
> order to read and make use of the rest of the information, an
> IBIS parser would need to be implemented.  This should not be
> a large undertaking, however.

Well, obviously to read an IBIS file it must be capable of 
reading an IBIS file.  I was thinking of analog-digital 
interfacing.  IBIS can provide significant advantages here, but 
I need to be convinced that this version does.

> 7)  Regarding "How such a model can be developed and tested",
> this is a complicated question, because of the freedom these
> languages provide. There are zillions of ways to write a
> model.  One way would be an equivalent IV and Vt table based
> equivalent in one of the AMS languages. Another way would be
> to use the same data, but curve fit them to equations and
> write those equations up in AMS syntax.  For SPICE lovers, I
> could imagine someone to write up the transistor equations in
> AMS syntax, and provide the usual process file information
> and netlist of transistors in the AMS file.  I can also
> envision many other ways using higher level behavioral
> techniques, some of which may even be proprietary and
> patentable.

This comment was directed at the fact that developing and 
testing models is now a problem, and has always been.  Certain 
issues seem to come up way to often, and are often answered 
incorrectly, so the confusion continues.  IBIS 3 and 4 added 
several new features that are difficult to measure and validate 
in practice.

By the way ....  How do you measure the 4-part C_comp on a real 
circuit?

There is a new validation capability here that probably should 
be exploited.  The external and old style can be validated 
against each other.  It was not clear originally that this 
could be done.

> I hope I answered some of your concerns. 

Yes.  Thank you.

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

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

Date: Thu, 9 Jan 2003 14:58:16 -0800
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8

Al, 
I am glad that we are converging...  and thanks for your continued comments 
and suggestions.  Here are a few responses. 

> It is for things like Vmeas, which isn't represented in Spice.  
> The BIRD should say this. 

We could add something to the "Introduction" of Section 6b to make this 
clearer, but I will have to consult the other authors of the BIRD too before 
it will happen.  Also, there is another, non-technical reason for keeping IBIS 
as a wrapper with these languages.  

Current tools include or accept much more information than just buffer data.
Package, board and system interconnects are modeled today using a variety of
methods: physical geometries (through field solvers), s-parameters and the like.
While many of these formats and methods can be duplicated in AMS, there isn't
yet an open library of such solutions available, nor do most SI engineers have
the AMS background to create them.  Having an AMS-IBIS interface enables
users and tools to continue to model and simulate non-buffer system components
under these other methods while taking advantage of AMS's flexibility in
modeling buffers.  Your implication is correct: were a standard library or 
set of conversion routines available, an AMS-only simulation environment might 
indeed be able to model system SI as well as or better than today's methods
allow.

> I must confess ....  It is a lot better in .7 ..  Bob's files 
> help, too.  It would be clearer if [External Model] and 
> [External Circuit] were different BIRDs, since they don't 
> depend on each other. 

Thanks!  FYI, the latest is 75.8, not .7 (just in case you missed it), but the 
changes are minimal.  Regarding making two separate BIRDS, I think there is 
a strong relationship between the keywords -- the same external languages are
used in both, plus many other details -- which would make two 
independent BIRDs have big overlaps and probably too repetitious.  Either way, 
none of us wants to start over rewriting these.  It took long enough as it is... 

> It said those keywords are optional when [External] is used, 
> but didn't say how it is resolved.  I interpreted it to mean 
> that both circuits are present, and the external one is added 
> to the old style one. 
> 
> Apparently, what you mean is that when both are present, the 
> simulator must choose one or the other.  Both cannot be active 
> at the same time.  If I interpret it this way, it makes sense 
> and answers #3. 

Yes, they were intended to be alternates, not additive.  We should perhaps 
make the text clearer on that.  Good comment. 

> Given this approach, it is unreasonable to have only one old 
> style keyword, say [Pullup] without the complete set.  The BIRD 
> makes it look like you can have only one.  I propose that it be 
> documented that if any old style parameters are present, there 
> must be a complete model. 

> I think a better approach is to disallow the old-style 
> parameters when [External Model] is used.  The functionality 
> can be provided with [Model Selector]. 

There are two problems with completely disallowing the "old-style 
parameters": 

1) measurement and voltage supply levels, and reference loads
2) backward compatibility

For (1), we have required some traditional IBIS threshold information
to ensure that tools can evaluate system response using the new
buffer data according to user needs.  The voltage supply information
ensures that the buffer is correctly powered in simulation and that
corner variations are correctly included.  Put another way, [External Model]
provides the "training wheels" necessary to get IBIS users into
the AMS world while maintaining familiar and useful aspects of
traditional IBIS.

For (2), BIRD 75 makes it possible for model makers to provide both 
AMS/SPICE model data and native IBIS model data to users, in case 
their tools do not support the new keywords.  [Driver Schedule],
you may recall, does much the same thing.

Besides being a hassle, to require complete native IBIS 
model data means that model makers would no longer have the choice of 
whether to be a good "IBIS citizen" and provide both sets of data or not.  
This would make it nearly impossible to "move beyond" the current IBIS 
keyword limitations, which was the whole intent behind BIRD 75.  You are 
right that having a [Pullup] by itself is permitted under the current BIRD
language.  Though not what we intended nor very likely, this could be 
used as a kind of "golden waveform" for comparison against the AMS or 
SPICE data.

> I noticed that the list of optional old-style keywords did not 
> include driver schedule and submodels. 
> 
> Please confirm that my new interpretation is correct. 

You saw this correctly, however, I need to explain it, because I 
don't think you understood it completely.  The list of "optional 
old-style keywords" was intended to tell you which keywords that 
used to be required are not required any more.  The [Driver Schedule] 
and [Submodel] keywords were not required, so they do not need to be 
listed in that list.  Whatever was optional still remains optional 
and doesn't need to be talked about in that context. 

> What I mean is to say something like: an IBIS [Model] is 
> equivalent to a Spice ".subckt" with a specified name 
> convention, and a particular node list.  That way, it could be 
> substituted easily in the simulator's native way. 
> 
> If you look at mixed Spice - Verilog-A simulators, they don't 
> distinguish which is which externally.  A Verilog-A "module" 
> looks just like a subckt (X...) in Spice format.  Likewise, a 
> Spice .subckt can be called by Verilog mode, just like a module. 
> 
> Some simulators do this already, but all different.  There 
> would be significant value in standardizing this. 

I wonder what you would like to standardize.  The syntax of the 
ports of a *-AMS module and SPICE subcircuit, so that this BIRD 
wouldn't have to handle them as different cases?  Or the number
of ports an [External Model] has (perhaps 7)?  If so, I think 
that would be a much bigger task than this BIRD can handle.  If 
not, I would like you to explain this a bit more to me. 

> Well, obviously to read an IBIS file it must be capable of 
> reading an IBIS file.  I was thinking of analog-digital 
> interfacing.  IBIS can provide significant advantages here, but 
> I need to be convinced that this version does. 

I am not sure I understand what you are getting at here.  Please 
explain more what you mean by "analog-digital interfacing". 

> This comment was directed at the fact that developing and 
> testing models is now a problem, and has always been.  Certain 
> issues seem to come up way to often, and are often answered 
> incorrectly, so the confusion continues.  IBIS 3 and 4 added 
> several new features that are difficult to measure and validate 
> in practice. 
> 
> By the way ....  How do you measure the 4-part C_comp on a real 
> circuit? 

Yes, in later version of IBIS we started to deviate from the original 
goal of having only such data in IBIS that can be measured on the 
bench.  However, there are tricks you can do.  For example, if you 
can't measure the C_comp_pullup and C_comp_pulldown, etc. separately 
on the bench, you can measure the total C_comp, correlate that to the 
total C_comp you measure on your SPICE model, then get proportions 
off of your SPICE model for the 4 subsets of that capacitance through 
simulations and apply those coefficients to the measured value.  This 
is just one way I could think of.  But this is a subject that will 
require cleverness on the part of the model maker, and just as I can't 
teach the ***art*** of circuit design to a student, I can't teach the 
***art*** of modeling either.  This subject goes way beyond the scope 
of this BIRD or even the spec itself. 

Arpad Muranyi
Michael Mirmak
======================================================================

- -----Original Message-----
From: Al Davis [mailto:[email-masked]]
Sent: Thursday, January 09, 2003 1:48 AM
To: Muranyi, Arpad; [email-masked]
Subject: Re: [IBIS-Users] Questions Regarding Bird 75.8

I am beginning to see some value, and it is clearing up.

On Wednesday 08 January 2003 11:36 am, Muranyi, Arpad wrote:
> Regarding your request for the examples demonstrating that
> this approach is superior to a SPICE or *-AMS only approach I
> wonder what kind of superiority you think of? 

There must be some, otherwise the proposal has no value.  You 
tell me!

> ...... A SPICE or
> *-AMS model will result in the same waveforms and/or
> accuracy, regardless whether they are embedded in this IBIS
> wrapper, or not.  So from that point of view I don't see any
> difference there. 

That's what I mean.  If there is no difference, why bother?

> .... However, from the user's perspective,
> there are some usage model differences which makes the life
> of the user easier.  The IBIS wrapper provides additional
> information for the simulation tool, helping in automating
> the measurement tasks, and providing information about
> reference loads, etc... without effecting the model behavior
> itself.  That is the benefit of having these languages
> embedded in IBIS.

ok.  That's what I was looking for.

With the examples, I see that now ....

It is for things like Vmeas, which isn't represented in Spice.  
The BIRD should say this.

> 2)  You mention that this approach is confusing.  Could you
> please elaborate on what the confusing part is, so that we
> could address it if possible?

I must confess ....  It is a lot better in .7 ..  Bob's files 
help, too.  It would be clearer if [External Model] and 
[External Circuit] were different BIRDs, since they don't 
depend on each other.

> 3)  You say that "it doesn't even come close to solving the
> problem". I am not sure what you are referring to.  Could you
> please give a problem statement as you see it?  We can't
> solve a problem if we have a different opinion on what it
> is...

Let me think about this one.

> 4)  The BIRD allows for an "old fashioned" model under the
> [Model] statement to coexist with the new [External Model]
> keyword that provides the SPICE or *-AMS description of a
> device.  It is up to the model maker to make a duplicate
> model of the device both ways. If they write such a duplicate
> with the old [Model] keyword, tools which cannot process the
> new keywords can simulate just like today. If the model maker
> doesn't care to do that, you may be out of luck.

That is another thing that I found unclear, but I think I see 
it now.

It said those keywords are optional when [External] is used, 
but didn't say how it is resolved.  I interpreted it to mean 
that both circuits are present, and the external one is added 
to the old style one.

Apparently, what you mean is that when both are present, the 
simulator must choose one or the other.  Both cannot be active 
at the same time.  If I interpret it this way, it makes sense 
and answers #3.

Given this approach, it is unreasonable to have only one old 
style keyword, say [Pullup] without the complete set.  The BIRD 
makes it look like you can have only one.  I propose that it be 
documented that if any old style parameters are present, there 
must be a complete model.  It should also be documented that if 
both new and old forms are present, they are treated as 
alternatives.

I think a better approach is to disallow the old-style 
parameters when [External Model] is used.  The functionality 
can be provided with [Model Selector].

I noticed that the list of optional old-style keywords did not 
include driver schedule and submodels.

Please confirm that my new interpretation is correct.

> 5)  I do not understand your question: "How it is superior to
> documenting an equivalence between the languages, like the
> equivalence between Spice and Verilog-A is documented." 
> Please explain what you mean by "documenting equivalence
> between languages".

What I mean is to say something like: an IBIS [Model] is 
equivalent to a Spice ".subckt" with a specified name 
convention, and a particular node list.  That way, it could be 
substituted easily in the simulator's native way.

If you look at mixed Spice - Verilog-A simulators, they don't 
distinguish which is which externally.  A Verilog-A "module" 
looks just like a subckt (X...) in Spice format.  Likewise, a 
Spice .subckt can be called by Verilog mode, just like a module.

Some simulators do this already, but all different.  There 
would be significant value in standardising this.

> 6)  Regarding "How it impacts mixed mode simulators", it
> depends on whether they have a parser that can read the IBIS
> file.  They should certainly be able to process the *-AMS
> portion of the IBIS file without difficulty.  However, in
> order to read and make use of the rest of the information, an
> IBIS parser would need to be implemented.  This should not be
> a large undertaking, however.

Well, obviously to read an IBIS file it must be capable of 
reading an IBIS file.  I was thinking of analog-digital 
interfacing.  IBIS can provide significant advantages here, but 
I need to be convinced that this version does.

> 7)  Regarding "How such a model can be developed and tested",
> this is a complicated question, because of the freedom these
> languages provide. There are zillions of ways to write a
> model.  One way would be an equivalent IV and Vt table based
> equivalent in one of the AMS languages. Another way would be
> to use the same data, but curve fit them to equations and
> write those equations up in AMS syntax.  For SPICE lovers, I
> could imagine someone to write up the transistor equations in
> AMS syntax, and provide the usual process file information
> and netlist of transistors in the AMS file.  I can also
> envision many other ways using higher level behavioral
> techniques, some of which may even be proprietary and
> patentable.

This comment was directed at the fact that developing and 
testing models is now a problem, and has always been.  Certain 
issues seem to come up way to often, and are often answered 
incorrectly, so the confusion continues.  IBIS 3 and 4 added 
several new features that are difficult to measure and validate 
in practice.

By the way ....  How do you measure the 4-part C_comp on a real 
circuit?

There is a new validation capability here that probably should 
be exploited.  The external and old style can be validated 
against each other.  It was not clear originally that this 
could be done.

> I hope I answered some of your concerns. 

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

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

Date: Fri, 10 Jan 2003 00:35:19 -0800
From: Shee Kian Wong <[email-masked]>
Subject: [IBIS-Users] IBIS model driver impedance

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_01C2B883.359AA8F0
Content-Type: text/plain

Hi all,

Can anyone suggest a way to measure the driver impedance of an IBIS buffer?
Do the look-up tables in the IBIS file carry this information?

Regards,

SK

- ------_=_NextPart_001_01C2B883.359AA8F0
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
- -->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Hi all,</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Can anyone suggest a way to measure the driver impedance of
an IBIS buffer? Do the look-up tables in the IBIS file carry this information?</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Regards,</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>SK</span></font></p>

</div>

</body>

</html>

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

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

Date: Fri, 10 Jan 2003 00:51:52 -0800
From: "Scott McMorrow" <[email-masked]>
Subject: Re: [IBIS-Users] IBIS model driver impedance

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

 From ohms law

V=IR

therefore

R =V/I

In the ibis model is a V/I table.

The impedance is real, thus at any point in the table the impedance is:

Z = V/I

As you will see, the impedance will change depending upon the output 
voltage.  If you want to find a good average impedance, then find the 
current at approximately half of the voltage swing of the driver. You 
can compute this for the pullup and the pulldown curves at all three 
corners.

best regards,

scott

- -- 
Scott McMorrow
Teraspeed Consulting Group LLC
2926 SE Yamhill St.
Portland, OR 97214
(503) 239-5536
http://www.teraspeed.com

Shee Kian Wong wrote:

> Hi all,
>
>  
>
> Can anyone suggest a way to measure the driver impedance of an IBIS 
> buffer? Do the look-up tables in the IBIS file carry this information?
>
>  
>
> Regards,
>
> SK
>

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
From ohms law<br>
<br>
V=IR<br>
<br>
therefore<br>
<br>
R =V/I<br>
<br>
In the ibis model is a V/I table.<br>
<br>
The impedance is real, thus at any point in the table the impedance is:<br>
<br>
Z = V/I<br>
<br>
As you will see, the impedance will change depending upon the output voltage.
&nbsp;If you want to find a good average impedance, then find the current at approximately
half of the voltage swing of the driver. You can compute this for the pullup
and the pulldown curves at all three corners.<br>
<br>
best regards,<br>
<br>
scott<br>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Scott McMorrow
Teraspeed Consulting Group LLC
2926 SE Yamhill St.
Portland, OR 97214
(503) 239-5536
<a class="moz-txt-link-freetext" href="http://www.teraspeed.com">http://www.teraspeed.com</a>
</pre>
<br>
Shee Kian Wong wrote:<br>
<blockquote type="cite"
 cite="[email-masked]"> 
  
  <meta http-equiv="Content-Type" content="text/html; ">
   
  <meta name="Generator" content="Microsoft Word 10 (filtered)">
  
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
- -->
  </style>    
  <div class="Section1">  
  <p class="MsoNormal"><font size="2" face="Arial"><span
 style="font-size: 10pt; font-family: Arial;">Hi all,</span></font></p>
  
  <p class="MsoNormal"><font size="2" face="Arial"><span
 style="font-size: 10pt; font-family: Arial;">&nbsp;</span></font></p>
  
  <p class="MsoNormal"><font size="2" face="Arial"><span
 style="font-size: 10pt; font-family: Arial;">Can anyone suggest a way to
measure the driver impedance of an IBIS buffer? Do the look-up tables in
the IBIS file carry this information?</span></font></p>
  
  <p class="MsoNormal"><font size="2" face="Arial"><span
 style="font-size: 10pt; font-family: Arial;">&nbsp;</span></font></p>
  
  <p class="MsoNormal"><font size="2" face="Arial"><span
 style="font-size: 10pt; font-family: Arial;">Regards,</span></font></p>
  
  <p class="MsoNormal"><font size="2" face="Arial"><span
 style="font-size: 10pt; font-family: Arial;">SK</span></font></p>
  </div>
  </blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">
</pre>
<br>
</body>
</html>

- --------------080109050000060409040902--

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

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

Date: Fri, 10 Jan 2003 10:52:47 +0100
From: [email-masked]
Subject: RE: [IBIS-Users] IBIS model driver impedance

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.

- ------=_NextPartTM-000-cf8c3023-5fff-4645-ab0b-2aff6024a560
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2B88E.07B1E100"

- ------_=_NextPart_001_01C2B88E.07B1E100
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Shee Kian,
 
As a variation on Scott's explanation, I usually determine the impedance differentially which allows me to calculate it as a function of the buffer voltage.
 
To determine the impedance Z at a voltage V you can do the following:
 
   * Choose a  voltage V1 in the tables where V1 < V, current is I1
   * Choose a voltage V2 in the tables where V2 > V, current is I2
 
   * Then calculate    Z(V) = (V2 - V1) / (I2 - I1)
 
This can be easily done if you import the IBIS file into a spreadsheet. If the voltages you are interested in are below Gnd or higher than Vcc, you may have to add the Power/Gnd clamp tables to the Pullup/Pulldown tables.
 
Best Regards,
 
   Herbert.

- -----Original Message-----
From: Scott McMorrow [mailto:[email-masked]]
Sent: 10 January 2003 09:52
To: Shee Kian Wong; [email-masked]
Subject: Re: [IBIS-Users] IBIS model driver impedance

From ohms law

V=IR

therefore

R =V/I

In the ibis model is a V/I table.

The impedance is real, thus at any point in the table the impedance is:

Z = V/I

As you will see, the impedance will change depending upon the output voltage.  If you want to find a good average impedance, then find the current at approximately half of the voltage swing of the driver. You can compute this for the pullup and the pulldown curves at all three corners.

best regards,

scott

- -- 

Scott McMorrow

Teraspeed Consulting Group LLC

2926 SE Yamhill St.

Portland, OR 97214

(503) 239-5536

http://www.teraspeed.com <http://www.teraspeed.com> 

Shee Kian Wong wrote:

Hi all,

Can anyone suggest a way to measure the driver impedance of an IBIS buffer? Do the look-up tables in the IBIS file carry this information?

Regards,

SK

- ------_=_NextPart_001_01C2B88E.07B1E100
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></TITLE>

<META content="MSHTML 5.50.4919.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=302064509-10012003>
<DIV><SPAN class=451083009-10012003><FONT face=Arial><FONT color=#0000ff><FONT 
size=2><SPAN 
class=302064509-10012003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=451083009-10012003><FONT face=Arial><FONT color=#0000ff><FONT 
size=2><SPAN class=302064509-10012003></SPAN>Hi Shee 
Kian,</FONT></FONT></FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=451083009-10012003><FONT face=Arial><FONT color=#0000ff><FONT 
size=2>As a variation on Scott's explanation, I usually determine the impedance 
differentially which allows me to calculate&nbsp;it as a function of the buffer 
voltage<SPAN class=302064509-10012003>.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=451083009-10012003>To 
determine the impedance Z at a voltage V&nbsp;you can do the 
following:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003>&nbsp;&nbsp; *&nbsp;Choose a &nbsp;voltage V1 in the 
tables where V1 &lt; V, current is I1</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003>&nbsp;&nbsp; * Choose a voltage V2 in the tables where 
V2 &gt; V, current is I2</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=451083009-10012003>&nbsp;&nbsp; * Then calculate&nbsp;&nbsp;&nbsp; 
Z(V)&nbsp;=&nbsp;(V2 - V1) / (I</SPAN><SPAN class=451083009-10012003>2 - 
I1)</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=451083009-10012003>This 
can be easily done if you import the IBIS file into a spreadsheet. If the 
voltages you are interested in&nbsp;are below Gnd or&nbsp;<SPAN 
class=302064509-10012003>higher than </SPAN>Vcc, you may have to add the 
Power/Gnd clamp tables to the Pullup/Pulldown tables.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=451083009-10012003>Best 
Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003>&nbsp;&nbsp; Herbert.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=451083009-10012003></SPAN></FONT>&nbsp;</DIV></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Scott McMorrow 
  [mailto:[email-masked]]<BR><B>Sent:</B> 10 January 2003 
  09:52<BR><B>To:</B> Shee Kian Wong; 
  [email-masked]<BR><B>Subject:</B> Re: [IBIS-Users] IBIS model 
  driver impedance<BR><BR></FONT></DIV>From ohms 
  law<BR><BR>V=IR<BR><BR>therefore<BR><BR>R =V/I<BR><BR>In the ibis model is a 
  V/I table.<BR><BR>The impedance is real, thus at any point in the table the 
  impedance is:<BR><BR>Z = V/I<BR><BR>As you will see, the impedance will change 
  depending upon the output voltage. &nbsp;If you want to find a good average 
  impedance, then find the current at approximately half of the voltage swing of 
  the driver. You can compute this for the pullup and the pulldown curves at all 
  three corners.<BR><BR>best regards,<BR><BR>scott<BR><BR><PRE class=moz-signature cols="$mailwrapcol">-- 
Scott McMorrow
Teraspeed Consulting Group LLC
2926 SE Yamhill St.
Portland, OR 97214
(503) 239-5536
<A class=moz-txt-link-freetext href="http://www.teraspeed.com">http://www.teraspeed.com</A>
</PRE><BR>Shee Kian Wong wrote:<BR>
  <BLOCKQUOTE 
  cite="[email-masked]" 
  type="cite">
    <META content="Microsoft Word 10 (filtered)" name=Generator>
    <STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: \@MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>

    <DIV class=Section1>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi all,</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Can anyone suggest a way to 
    measure the driver impedance of an IBIS buffer? Do the look-up tables in the 
    IBIS file carry this information?</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Regards,</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">SK</SPAN></FONT></P></DIV></BLOCKQUOTE><BR><PRE class=moz-signature cols="$mailwrapcol"></PRE><BR></BLOCKQUOTE></BODY></HTML>

- ------_=_NextPart_001_01C2B88E.07B1E100--

- ------=_NextPartTM-000-cf8c3023-5fff-4645-ab0b-2aff6024a560--

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

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

Date: Fri, 10 Jan 2003 14:41:04 -0800
From: "Hazem Hegazy" <[email-masked]>
Subject: RE: [IBIS-Users] IBIS model driver impedance

This is a multi-part message in MIME format.

- ------=_NextPart_000_0003_01C2B8B6.50F55810
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In addition to all that, it should be noted that the buffer impedance in
a complex one.This means it vary with frequency also as the output stage
capacitance (Drain-Bulk, Drain-Gate and Drain-Source)  and its
equivalents vary in frequency.
BR,
 
Hazem Hegazy, M.Sc.
IBIS Modeling Engineer
QualiM
http://www.qualim.com/
Phone: (+20) 106052154
E-mail: [email-masked]
 
- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Shee Kian Wong
Sent: Friday, January 10, 2003 12:35 AM
To: [email-masked]
Subject: [IBIS-Users] IBIS model driver impedance
 
Hi all,
 
Can anyone suggest a way to measure the driver impedance of an IBIS
buffer? Do the look-up tables in the IBIS file carry this information?
 
Regards,
SK

- ------=_NextPart_000_0003_01C2B8B6.50F55810
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"Monotype Corsiva";
	panose-1:3 1 1 1 1 2 1 1 1 1;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.emailstyle17
	{mso-style-name:emailstyle17;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
- -->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In addition to all that, it should =
be
noted that the buffer impedance in a complex one&#8230;This means it =
vary with
frequency also as the output stage capacitance (Drain-Bulk, Drain-Gate =
and
Drain-Source) <span style=3D'mso-spacerun:yes'>&nbsp;</span>and its =
equivalents
vary in frequency.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>BR,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><b style=3D'mso-bidi-font-weight:normal'><font =
size=3D3
color=3Dblue face=3D"Monotype Corsiva"><span =
style=3D'font-size:12.0pt;font-family:
"Monotype =
Corsiva";color:blue;font-weight:bold;mso-bidi-font-weight:normal;
mso-no-proof:yes'>Hazem Hegazy</span></font></b><font color=3Dnavy><span
style=3D'color:navy;mso-no-proof:yes'>, =
M.Sc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>IBIS Modeling =
Engineer<o:p></o:p></span></font></p>

<p class=3DMsoNormal><b style=3D'mso-bidi-font-weight:normal'><font =
size=3D4
color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:14.0pt;color:red;
font-weight:bold;mso-bidi-font-weight:normal;mso-no-proof:yes'>QualiM<o:p=
></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'><a
href=3D"http://www.qualim.com/">http://www.qualim.com/</a><o:p></o:p></sp=
an></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>Phone: (+20) =
106052154<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>E-mail: <a
href=3D"mailto:[email-masked]">[email-masked]</a><o:p></o:p></span></=
font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Shee Kian Wong<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January 10, =
2003
12:35 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [IBIS-Users] =
IBIS model
driver impedance</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Hi =
all,</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font><o:p></o=
:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Can anyone suggest a way to =
measure
the driver impedance of an IBIS buffer? Do the look-up tables in the =
IBIS file
carry this information?</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font><o:p></o=
:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Regards,</span></font><o:p><=
/o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>SK</span></font><o:p></o:p><=
/p>

</div>

</body>

</html>

- ------=_NextPart_000_0003_01C2B8B6.50F55810--

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

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

Date: Tue, 14 Jan 2003 17:26:31 -0600
From: "Rick Kingen" <[email-masked]>
Subject: [IBIS-Users] Spice to IBIS for Ver3.2 and Ver4.0?

This is a multi-part message in MIME format.

- ------=_NextPart_000_0056_01C2BBF2.14197E50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can anyone give the status of the Spice to IBIS tool from NCSU?  When =
and if this is or will be available. =20

Also, is there a commercial version available?  If you need to respond =
in offline to avoid compromissing the rules of no vendor discussions via =
the users mail list, please do so.

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

- ------=_NextPart_000_0056_01C2BBF2.14197E50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Can anyone give the status of the Spice =
to IBIS=20
tool from NCSU?&nbsp; When and if this is or will be available.&nbsp;=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Also, is there a commercial version=20
available?&nbsp; If you need to respond in offline to avoid =
compromissing the=20
rules of no vendor discussions via the users mail list, please do=20
so.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>_______________________________________________<BR>This email=20
communication along with any attachments<BR>is classified =
as:<BR>&nbsp;<BR>[=20
X]&nbsp; General business information<BR>[ ]&nbsp; Motorola internal use =

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

- ------=_NextPart_000_0056_01C2BBF2.14197E50--

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

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

Date: Tue, 14 Jan 2003 19:07:36 -0500
From: "Lynne Green" <[email-masked]>
Subject: RE: [IBIS-Users] Spice to IBIS for Ver3.2 and Ver4.0?

Hello, Rick,

The tool is available as s2ibis2.  Information and Source code:
http://www.eda.org/pub/ibis/s2ibis/s2ibis2_v1.1/

IBIS 3.2 and 4.0 features can be added manually to the IBIS
file created by s2ibis2 (with updated [IBIS Ver]).  Or you can
modify s2ibis2 for your own use.

At this time, there are no scheduled upgrades for s2ibis2.

Best regards,
Lynne

Lynne Green
Cadence Design Systems
Vice Chair, IBIS Open Forum

- -----Original Message-----
From: Rick Kingen [mailto:[email-masked]] 
Sent: Tuesday, January 14, 2003 3:27 PM
To: [email-masked]
Subject: [IBIS-Users] Spice to IBIS for Ver3.2 and Ver4.0?

Can anyone give the status of the Spice to IBIS tool from NCSU?  When
and if this is or will be available.  

Also, is there a commercial version available?  If you need to respond
in offline to avoid compromissing the rules of no vendor discussions via
the users mail list, please do so.

Thanks in advance.
_______________________________________________
This email communication along with any attachments
is classified as:
 
[ X]  General business information
[ ]  Motorola internal use only
[ ]  Motorola confidential proprietary
 
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Tue, 14 Jan 2003 23:00:22 -0500 (EST)
From: Ambrish Kant Varma <[email-masked]>
Subject: Re: [IBIS-Users] Spice to IBIS for Ver3.2 and Ver4.0?

Hi Rick,
We are in the final stages of writing a JAVA version of S2IBIS2 and while
I would not like to promise a date for S2IBIS3, I presume that extending
the JAVA version of S2IBIS2 to come up with S2IBIS3 should not take a long
time.
Hope that answers your question.
Regards,

Ambrish K Varma
[email-masked]
(919)513-2015

 On Tue, 14 Jan 2003, Rick Kingen wrote:

> Can anyone give the status of the Spice to IBIS tool from NCSU?  When and if this is or will be available.
>
> Also, is there a commercial version available?  If you need to respond in offline to avoid compromissing the
> rules of no vendor discussions via the users mail list, please do so.
>
> Thanks in advance.

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

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

Date: Wed, 15 Jan 2003 08:45:19 -0800
From: "Ross, Bob" <[email-masked]>
Subject: [IBIS-Users] European IBIS Summit Announcement

To All:

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

The meeting is free and open to everyone.  However, you will have
to register for the exhibition at DATE (to get access to the
meeting room).  Refreshments are planned.

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

Bob Ross
Mentor Graphics

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

Time/Date:     9:00 PM - 2:00 PM, Friday, March 7, 2003

Location:      Meeting room in ICM (International Congress Center)
               Messe Munich, Germany (where DATE 2003 is being held)

               (Free DATE 2003 exhibition registration for room entry,
               see URL below)

Content:       Presentations and Discussions

Purpose:       Solicit and Exchange IBIS Model Related Information and Ideas

Sponsors:      Mentor Graphics, Zuken, Siemens

DATE 2003:     March 3-7, 2003.  The IBIS meeting is scheduled the day
               after the exhibition and on the last day of DATE 2003.

Location:      International Congress Center, Munich, Germany

DATE URL:      http://www.date-conference.com

BACKGROUND

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

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

CALL FOR PARTICIPANTS

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

  Name:
  E-mail address:
  Company:
  Telephone:

Send to:

Ralf Bruening ([email-masked])
  
CALL FOR PRESENTATIONS

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

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

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

If you plan a presentation, please supply

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

  Estimate Time:

Send this to both:

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

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

Date: Thu, 16 Jan 2003 18:35:23 +0530
From: Anshuli Goel <[email-masked]>
Subject: [IBIS-Users] Ramp and Rising waveform Load

Hello IBIS Gurus

While generating IBIS model I use 50 ohm as rload for calculation of
Ramp rate.

Should my rising and falling waveform also be generated for same load
fixture. ?

If I use 50 ohm as load fixture for rising and falling waveform ,the
voltage level in rising and falling waveform reaches only to maybe 50 %
of VDD.But when I use some high resistance as 500 ohm for load fixture
for rising and falling waveform (keeping Rload for ramp rate still as 50
ohm ) gives me waveform reaching to VDD. What is the best way to get
both ramp rate and rising and falling waveform ..

What significance does this Rload ( for ramp rate ) and R_fixture ( For
waveforms) hold ?
In case of simple I/O buffer what both these parameters define if
I think of physical entity of package and board ? What is the mean of
test structure the buffer is supposed to see ?

Regards
Anshuli

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

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

Date: Thu, 16 Jan 2003 08:20:01 -0800
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] Ramp and Rising waveform Load

Anshuli,

You should use an R_fixture around 50 Ohms, not 500.  The best
value for R_fixture is the transmission line impedance that
the buffer is designed to drive.  This is usually in the range
below 100 Ohms.

I don't have the time to explain it now, but if you have
waveforms which go almost rail to rail, you do not have a
very good IBIS model.

Arpad Muranyi
Intel Coproration
==============================================================

- -----Original Message-----
From: Anshuli Goel [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 5:05 AM
To: [email-masked]'
Subject: [IBIS-Users] Ramp and Rising waveform Load

Hello IBIS Gurus

While generating IBIS model I use 50 ohm as rload for calculation of
Ramp rate.

Should my rising and falling waveform also be generated for same load
fixture. ?

If I use 50 ohm as load fixture for rising and falling waveform ,the
voltage level in rising and falling waveform reaches only to maybe 50 %
of VDD.But when I use some high resistance as 500 ohm for load fixture
for rising and falling waveform (keeping Rload for ramp rate still as 50
ohm ) gives me waveform reaching to VDD. What is the best way to get
both ramp rate and rising and falling waveform ..

What significance does this Rload ( for ramp rate ) and R_fixture ( For
waveforms) hold ?
In case of simple I/O buffer what both these parameters define if
I think of physical entity of package and board ? What is the mean of
test structure the buffer is supposed to see ?

Regards
Anshuli

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

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

Date: Thu, 16 Jan 2003 11:24:26 -0800
From: "Angulo, John" <[email-masked]>
Subject: [IBIS-Users] HCSL Buffer Model

The following is posted on behalf of Ben Manor of Intel Israel.  Please send any private replies to [email-masked] only.

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

Hi,

Looking for an HCSL buffer ibis model.
Any accessible?

Thanks,

Ben Manor
Intel Israel
Phone +972-4-865-6214
Fax     +972-4-865-6957
Cell     +972-54-448324
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Fri, 17 Jan 2003 18:02:33 -0500
From: "Lynne Green" <[email-masked]>
Subject: [IBIS-Users] Agenda, IBIS DesignCon Summit

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

                   AGENDA, IBIS SUMMIT MEETING
                        JANUARY 27, 2003

                          Westin Hotel
                  Santa Clara Convention Center
                     Santa Clara, California

                Room: Magnolia Room, Westin Hotel
                      (check signs at site)

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

8:00 AM     Refreshments & Sign In

8:30 AM     Introductions
            - Welcome to Summit
            - Introductions
            - IBIS Booth
            - Opens for Issues, Discussion Topics

8:45 AM     IBIS Chair's Report
	Stephen Peters, Intel Corporation

9:00 AM     Reflections on IBIS
            Bob Ross, Mentor Graphics

9:30 AM     The Case Study of Board Simulation
            Atsuji Ito, Panasonic, JEITA EDA WG Chair

10:00 AM    Break

10:15 AM    IBIS Quality Committee Update / Practical Use of IQ
checklist
            Barry Katz, Signal Integrity Software Inc.

11:00 PM    IBIS Modeling Experiences
            Tim Coyle, National Semiconductor

11:30 AM    Data Dependent Buffer Characteristics
            Arpad Muranyi, Intel Corporation

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

1:00 PM     Lossy Line Simulation and Analysis
            Dima Smolysansky, TDA Systems, Inc.

1:30 PM     IBIS Connector Modeling Specification: Status and Proposed
Changes
            Kelly Green, Consultant; Michael Mirmak, Intel Corporation

2:00 PM     IBIS Interconnect Specification Draft
            Open discussion

2:30 PM     Break

2:45 AM     A BIRD 75 Multi-lingual Example
            Lynne Green, Cadence Design Systems, Inc.

3:15 PM     IBIS 4.1 Discussions
            All

3:30 PM     Open Discussion and Ad Hoc Topics
            All

4:45 PM     Concluding Items
            - Next Open Forum Meeting February 14, 2003
            - DATE 2003, March 7, 2003, Munich, Germany

5:00 PM     End of IBIS Summit Meeting

- ------------------------------------------------------------------
REGISTRATION INFORMATION

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

   Name:
   E-mail address:
   Company:
   Telephone:

Send to:

    Milt Swartz at National Semiconductor ([email-masked])

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

Sponsors:   DesignCon, National Semiconductor

DesignCon:  January 27-30, 2003
		Santa Clara Convention Center
		Santa Clara, California
		See <http://www.designcon.com/2003/> for more
information.

LIST OF NEARBY HOTELS

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

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

Date: Thu, 23 Jan 2003 09:10:25 +0900
From: "Jongho Kang" <[email-masked]>
Subject: [IBIS-Users]  ODT(On-Die-Termination) modeling ?

This is a multi-part message in MIME format.

- ------=_NextPart_000_0004_01C2C2BF.4442B640
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

- ------=_NextPart_000_0004_01C2C2BF.4442B640
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

- ------=_NextPart_000_0004_01C2C2BF.4442B640--

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

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

Date: Wed, 22 Jan 2003 17:47:56 -0800
From: bpanos <[email-masked]>
Subject: [IBIS-Users] PSPICe

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

With respect to Cadence PSPICe,  has anyone used the general laplace
expressions to model frequency dependent skin and dielectric losses
(general expressions for G and R), and if so, where does one insert the
expression? (my fear is that this might be a post process analysis). I'm
using either a TLOSSY or TLUMPED

thanks
Bill

- --------------E3214CB0C9B692C83770EDEE
Content-Type: text/x-vcard; charset=us-ascii;
 name="bill.panos.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for bpanos
Content-Disposition: attachment;
 filename="bill.panos.vcf"

begin:vcard 
n:Panos;Bill 
tel;fax:408.904.2095
tel;work:408.904.2060
x-mozilla-html:FALSE
org:Sanmina-SCI Corp.
version:2.1
email;internet:[email-masked]
title:Signal Integrity Engineer
adr;quoted-printable:;;2000 Ringwood=0D=0ASan Jose, Ca 95131;;;;
fn:Bill Panos
end:vcard

- --------------E3214CB0C9B692C83770EDEE--

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

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

Date: Wed, 22 Jan 2003 18:20:30 -0800 (PST)
From: Syed Huq <[email-masked]>
Subject: Re: [IBIS-Users]  ODT(On-Die-Termination) modeling ?

Yes, IBIS supports this feature.

You create "two" models. One 'with termination' and the other 'without
termination'. THen use the [Model Selector] option to choose which
one you wish to use for simulations.

Syed

>From: "Jongho Kang" <[email-masked]>
>To: <[email-masked]>
>Subject: [IBIS-Users]  ODT(On-Die-Termination) modeling ?
>Date: Thu, 23 Jan 2003 09:10:25 +0900
>MIME-Version: 1.0
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
>
>DDR2 Dram has on-die-termination resistor.
>The ODT feature is designed to improve signal integrity
>of the memory channel by allowing the DRAM controller
>to independently turn on/off termination resistance for
>any or all DRAM device.
>Turning on/off termination resistance changes I/O buffer's
>I/V characteristics & rising/falling waveform.
>Does IBIS support ODT function?
>If not, how can I make I/O buffer IBIS including ODT function?
>Any comment will be appreciated.
>
>Thanks.
>
>====================================
>Jongho Kang
>E-mail : [email-masked]
>Office : 82-31-639-1675/1971
>Mobile : 82-18-221-7806
>Product Application Engineering,
>Memory R&D, Hynix Semiconductor Inc.
>====================================

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

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

Date: Thu, 23 Jan 2003 11:48:25 -0500
From: "Lynne Green" <[email-masked]>
Subject: RE: [IBIS-Users] PSPICe

Hi, Bill,

Since this is a product-specific question, you might want to
also post this on the Cadence PSPICE reflector.
http://www.orcadpcb.com/

- - Lynne

- -----Original Message-----
From: bpanos [mailto:[email-masked]] 
Sent: Wednesday, January 22, 2003 5:48 PM
Cc: [email-masked]
Subject: [IBIS-Users] PSPICe

With respect to Cadence PSPICe,  has anyone used the general laplace
expressions to model frequency dependent skin and dielectric losses
(general expressions for G and R), and if so, where does one insert the
expression? (my fear is that this might be a post process analysis). I'm
using either a TLOSSY or TLUMPED

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

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

Date: Thu, 23 Jan 2003 12:00:10 -0500
From: Peter LaFlamme <[email-masked]>
Subject: Re: [IBIS-Users]  ODT(On-Die-Termination) modeling ?

Hi Jongho, 
The real question/s is which simulators actually support this IBIS feature. The only way I have ever seen this feature implementable (in an IBIS model) is using the dynamic clamp submodel.  I have asked about this before but there are apparently very few
people that know exactly how to implement it, or are willing to share their knowledge. I have never seen the procedure actually documented, so I can assume it has been implemented in many ways, some of which do not properly model the resistor termination
(my experience).

There are other ways using IBIS syntax, these are also not well documented, so you need an IBIS syntax expert to lead you through them. Additionally, I have tried these on 2 commonly used software programs and found that the syntax is ignored. 

It would be a great service to the ibis community if someone who actually knows how to do this would document the procedure for publication on the IBIS webpage. It is my opinion that the ibis committee needs to focus on providing model creators with
standard ways of implementing all of the new features that they concieve. This will most likely improve the quality of models. This may already be something on the ibis agenda. 

I am not looking to pick apart the IBIS committee or specs, or fingerpoint. I know they all do good work. I just hope that, other than accuracy, they should look at feature implementation, and that software companies let users of their tools know what IBIS
features are actually useable with their tools. I think we would all benefit.

Peter

> Jongho Kang wrote:
> 
> DDR2 Dram has on-die-termination resistor.
> The ODT feature is designed to improve signal integrity
> of the memory channel by allowing the DRAM controller
> to independently turn on/off termination resistance for
> any or all DRAM device.
> Turning on/off termination resistance changes I/O buffer's
> I/V characteristics & rising/falling waveform.
> Does IBIS support ODT function?
> If not, how can I make I/O buffer IBIS including ODT function?
> Any comment will be appreciated.
> 
> Thanks.
> 
> ====================================
> Jongho Kang
> E-mail : [email-masked]
> Office : 82-31-639-1675/1971
> Mobile : 82-18-221-7806
> Product Application Engineering,
> Memory R&D, Hynix Semiconductor Inc.
> ====================================

- -- 
Peter LaFlamme

Applied Micro Circuits Corp.
System Applications Engineer
200 Minuteman Rd, 3rd Floor
Andover, MA 01810

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

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

Date: Thu, 23 Jan 2003 11:10:28 -0800
From: "Angulo, John" <[email-masked]>
Subject: [IBIS-Users] Waveform mismatch question

The following is posted on behalf of John Phillippe at Motorola.  Please send any private replies to [email-masked] only.

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

Ibis Guru's,
   I get quite a few waveform mismatches between the rising/falling 
edges and the I/V curves like the one shown below.

WARNING - Model pad_26v_fast: The [Falling Waveform]
       with [R_fixture]=50 Ohms and [V_fixture_max]=0V
       has MAX column DC endpoints of  0.05V and  1.75v, but
       an equivalent load applied to the model's I-V tables yields
       different voltages ( 0.16V and  1.91V),
       a difference of  6.66% and  8.94%, respectively.

I'm curious if this is a common problem, or if there are some simple 
solutions to get everything to match up.  I check the waveforms and set 
the sim time long enough to make sure the waveforms are stable.  Any 
help/suggestions would be greatly appreciated.

- -- 
John Phillippe
SPS, 32 Bit Embedded Controller Division, IC Creation
Motorola      -  512-895-1835
Austin, TX    -  [email-masked]
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 23 Jan 2003 11:51:06 -0800
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] Waveform mismatch question

John,

Theoretically there should be no mismatch messages.  If there
are, something is wrong.  However, this is an area where the
parser was also corrected numerous times, so first I would
suggest that you get the latest version if you don't have it
yet.

If you still get this message, than you need to check your
model data.  What this means is that the IV curves of your
model would give you different waveform voltages than what
your waveform tables have.  It all boils down to Ohm's law.
If the model has such relatively large mismatches, Ohm's
law is violated somewhere.  Depending on the simulator's
algorithms, this may or may not be a problem, but then you
don't know what they did to make it work either.

Arpad Muranyi
Intel Corporation
=============================================================
- -----Original Message-----
From: Angulo, John [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 11:10 AM
To: [email-masked]'
Subject: [IBIS-Users] Waveform mismatch question

The following is posted on behalf of John Phillippe at Motorola.  Please send any private replies to [email-masked] only.

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

Ibis Guru's,
   I get quite a few waveform mismatches between the rising/falling 
edges and the I/V curves like the one shown below.

WARNING - Model pad_26v_fast: The [Falling Waveform]
       with [R_fixture]=50 Ohms and [V_fixture_max]=0V
       has MAX column DC endpoints of  0.05V and  1.75v, but
       an equivalent load applied to the model's I-V tables yields
       different voltages ( 0.16V and  1.91V),
       a difference of  6.66% and  8.94%, respectively.

I'm curious if this is a common problem, or if there are some simple 
solutions to get everything to match up.  I check the waveforms and set 
the sim time long enough to make sure the waveforms are stable.  Any 
help/suggestions would be greatly appreciated.

- -- 
John Phillippe
SPS, 32 Bit Embedded Controller Division, IC Creation
Motorola      -  512-895-1835
Austin, TX    -  [email-masked]
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 23 Jan 2003 13:17:39 -0700
From: "Duane Mattheisen" <[email-masked]>
Subject: Re: [IBIS-Users] Waveform mismatch question

John  Take out as much fixture resistance as possible in the DC
measurement. 
  Also for the AC measurement put a big capacitor (0.1uf and a >2.2uF
tantalum cap) to ground on the Rfixture having the other side of the
Rfixture that connects to the output as close as possible to the
output.   
                                    Sincerely Duane Mattheisen
"Angulo, John" wrote:
> 
> The following is posted on behalf of John Phillippe at Motorola.  Please send any private replies to [email-masked] only.
> 
> --------------------------------------------------
> 
> Ibis Guru's,
>    I get quite a few waveform mismatches between the rising/falling
> edges and the I/V curves like the one shown below.
> 
> WARNING - Model pad_26v_fast: The [Falling Waveform]
>        with [R_fixture]=50 Ohms and [V_fixture_max]=0V
>        has MAX column DC endpoints of  0.05V and  1.75v, but
>        an equivalent load applied to the model's I-V tables yields
>        different voltages ( 0.16V and  1.91V),
>        a difference of  6.66% and  8.94%, respectively.
> 
> I'm curious if this is a common problem, or if there are some simple
> solutions to get everything to match up.  I check the waveforms and set
> the sim time long enough to make sure the waveforms are stable.  Any
> help/suggestions would be greatly appreciated.
> 
> --
> John Phillippe
> SPS, 32 Bit Embedded Controller Division, IC Creation
> Motorola      -  512-895-1835
> Austin, TX    -  [email-masked]
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

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

Date: Thu, 23 Jan 2003 17:41:41 -0500
From: "Lynne Green" <[email-masked]>
Subject: [IBIS-Users] Final Agenda, IBIS Summit Meeting

All presentations received so far are available at

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

There is no teleconference for this Summit.

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

         AGENDA, IBIS SUMMIT MEETING
              JANUARY 27, 2003

8:30 AM     Introductions
            - Welcome to Summit
            - Introductions
            - IBIS Booth
            - Opens for Issues, Discussion Topics

8:45 AM     IBIS Chair's Report
		Stephen Peters, Intel Corporation

9:00 AM     Reflections on IBIS
            Bob Ross, Mentor Graphics

9:30 AM     The Case Study of Board Simulation
            Atsuji Ito, Panasonic, JEITA EDA WG Chair

10:00 AM    Break

10:15 AM    IBIS Quality Committee Update / Practical Use of IQ
checklist
            Barry Katz, Signal Integrity Software Inc.

11:00 PM    IBIS Modeling Experiences
            Tim Coyle, National Semiconductor

11:30 AM    Data Dependent Buffer Characteristics
            Arpad Muranyi, Intel Corporation

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

1:00 PM     Lossy Line Simulation and Analysis
            Dima Smolysansky, TDA Systems, Inc.

1:30 PM     IBIS Connector Modeling Specification: Status and Proposed
Changes
            Kelly Green, Consultant; Michael Mirmak, Intel Corporation

2:00 PM     IBIS Interconnect Specification Draft
            Open discussion

2:30 PM     Break

2:45 AM     A BIRD 75 Multi-lingual Example
            Lynne Green, Cadence Design Systems, Inc.

3:15 PM     IBIS 4.1 Discussions
            All

3:30 PM     Open Discussion and Ad Hoc Topics
            All

4:45 PM     Concluding Items
            - Next Open Forum Meeting February 14, 2003
            - DATE 2003, March 7, 2003, Munich, Germany

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

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

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